그런데 배포 후 이틀 후 아침, 메일이 왔다. 너 2달러 이미 넘침 ㅋ 진짜 아침부터 말벌 아저씨처럼 AWS에 들어갔다. 지... 진짜잖아......... 왜..?? 왜? 왜 벌써 이렇게? (니가 유료 플랜으로 업그레이드 했잖아....)

알고보니 2025년 7월 15일부터 정책이 바뀌었단다. 이전에 프리티어로 가입했던 건 유지가 되지만, 2025년 7월 15일부터는 예전에 제공했던 여러 (유사)무료 서비스를 제공하지 않는다고 한다. 물론 무료 플랜이면 6개월은 아예 과금되지 않는다. (그런데 여러모로 제한이 있는 것 같음) 그리고 유료 플랜에게는 처음 가입시 100달러의 크레딧과 5개의 활동을 하면 추가로 100달러를 크레딧으로 준다. (한 활동당 20달러) 그리고 뭐든지 다 비용처리? 된다. (이제 EC2 인스턴스 1개만 생성해도 마찬가지) 비용이 나온다고 해도 크레딧에서 먼저 빠져나간다고 한다. (휴!)

그런데 23일에 만든 계정의 26일의 비용 상태이다. (EC2 t3 micro & RDS t3 micro & Route 53 호스팅영역)

4일만에 4-5달러, 그러면 한 달이면 약 4-5만원? 받은 크레딧으로 몇 달정도는 무료로 사용할 수 있겠지만 어떤 단체에서 공적으로 사용할 용도로 만든 거라 비용 청구하기 좀 죄송스러운데.... 잘 사용되면 장기적으로 사용할 수도 있을 것 같으니 비용에서 가장 많은 비중을 차지하는 RDS를 안 쓰고 우분투에 직접 DB를 설치하는 건 어떨지 고민이다.

내가 잘 이해한 거 맞겠지...? 왜 바뀐 걸까....... 프리티어 넘 좋았는데..ㅠ 이제 신규 고객 유치 차원에서 12개월이나 무료로 주기에는 고객이 많아졌나봐...?

자바의 정석 4판이 나와 새로운 마음으로 처음부터 차근차근 읽어보기로 했다.

자바 언어의 특징

1. 운영체제에 독립적

자바 응용프로그램은 운영체제/하드웨어와 통신하는 것이 아니라 JVM과 통신을 한다.

JVM이란?

JVM은 'Java Virtual Machine'으로, 자바를 실행하기 위한 가상 컴퓨터이다. 자바로 작성된 애플리케이션은 모두 JVM에서만 실행된다.

Java 애플리케이션 <-> JVM <-> OS <-> 하드웨어

즉, 자바 애플리케이션이 실행되기 위해서는 JVM이 필요하고, Java 애플리케이션은 JVM과만 상호작용을 하기 때문에 OS와 하드웨어에 독립적으로 실행 가능한 것이다.

JVM은 어떻게 설치하나?

자바로 프로그래밍을 하려면 먼저 JDK(Java Deveopment Kit)를 설치해야 한다. 이것을 설치하면 자바를 개발하는 데 필요한 프로그램들과 함께 JVM도 설치가 된다!

2. 객체지향 언어, 함수형 언어

상속, 캡슐화, 다형성이 잘 적용된 객체지향 언어이다 (함수형 언어라는 것도 적어주셨지만 설명이 없어 찾아보니 람다와 스트림을 말하는 것이었다. )

3. 자동 메모리 관리

자바로 작성된 프로그램이 실행되면 GC(Garbage Collector 가비지 콜렉터)가 자동으로 메모리를 관리해주기 때문에 프로그래머가 메모리를 따로 관리하지 않아도 된다는 장점이 있다.

4. 멀티쓰레드 지원

멀티쓰레드 = 하나의 프로그램을 사용하면서 여러 작업을 동시에 처리할 수 있도록 하는 것이다.

5. 동적 로딩 지원

동적 로딩 = '프로그램 실행 중에' 필요한 시점에 JVM이 특정 클래스를 메모리로 불러오는 과정 즉, 프로그램 실행시 모든 클래스가 한꺼번에 로딩되는 것이 아니라 특정 클래스가 필요할 때 로딩해서 사용한다.

6. 네트워크와 분산처리 지원

자바 언어는 인터넷을 통해 여러 컴퓨터가 데이터를 주고받을 수 있도록 지원한다. 예를 들어 Socket, URLConnection, HttpURLConnection과 같은 클래스를 활용하면 TCP/IP , HTTP 프로토콜 기반의 네트워크 통신을 구현할 수 있다. 이 덕분에 자바 애플리케이션은 다른 컴퓨터/서버와 데이터를 주고받는 기능을 구현할 수 있다.

또한 자바 애플리케이션의 규모가 커지면, 하나의 애플리케이션으로 모든 기능을 처리하기 어려워진다. 이러한 문제를 해결하기 위해 기능을 작은 단위(서비스 단위)로 분리하고, 이를 여러 서버에 배포하여 동시에 분산적으로 처리할 수 있도록 지원한다.
예를 들어, 우리가 잘 사용하는 Spring Boot는 사용자 관리, 주문, 결제 등 각 기능을 독립적인 애플리케이션으로 구성하여 각 서비스는 REST API를 통해 서로 통신할 수 있게 해준다.

[   scheduling-1] c.d.d.notification.NotificationService   : Ping 전송 실패 : userId = 13, error = ServletOutputStream failed to flush: java.io.IOException: Broken pipe
[nio-8080-exec-9] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] threw exception
org.springframework.security.authorization.AuthorizationDeniedException: Access Denied

[nio-8080-exec-9] o.a.c.c.C.[Tomcat].[localhost]           : Exception Processing [ErrorPage[errorCode=0, location=/error]]
jakarta.servlet.ServletException: Unable to handle the Spring Security Exception because the response is already committed.
 Caused by: org.springframework.security.authorization.AuthorizationDeniedException: Access Denied

지난번의 필터로 해결될 문제가 아니었나 싶어 심란한 마음에 앞의 상황 맥락과 로그들을 살펴봤다.

이 로그가 나오는 것의 공통점은 사용자가 로그아웃을 하거나 탈퇴를 했을 때였다.

1. Broken pipe (IOException):

• 사용자가 로그아웃/회원퇴함에 따라 연결은 끊겼는데 서버는 그걸 인식하지 못하고 데이터를 계속 보내려다가 예외가 터진 것이다.

2. AuthorizationDeniedException: Access Denied:

• 나는 로그아웃을 하면 토큰들을 삭제하거나 블랙리스트로 설정했기 때문에 더이상 인증이 되지 않도록 구현했다. 그런데 계속 30초마다 ping으로 SSE에 데이터를 보내려고 하다보니 인증 실패 예외를 터트린 것이다.

그러면 로그아웃, 회원탈퇴를 했을 때 연결이 제대로 끊어지도록 뭔가 조치를 취해야겠지!

해결한 방법

NotificationService 내에

  private void removeEmitter(Long userId, SseEmitter emitter, String reason) {
    emitters.compute(userId, (key, currentEmitter) -> {
      if (currentEmitter == emitter) {
        try {
          emitter.complete();
        } catch (Exception e) {
          log.warn("Emitter 종료 중 예외 발생: userId = {}, error = {}", userId, e.getMessage());
        }
        log.debug("Emitter 제거 완료: userId = {}, 이유 = {}", userId, reason);
        return null;
      }
      return currentEmitter;
    });
  }

이렇게 제거 메서드를 만들어두고, 이 메서드를 사용하여 연결을 끊는 메서드를 만들었다.

public void disconnectEmitter(Long userId) {
    SseEmitter emitter = emitters.remove(userId);
    if (emitter != null) {
      removeEmitter(userId, emitter, "로그아웃/탈퇴에 의한 SSE 연결 종료");
    }
  }

작성하다보니 뭔가.... 부족한 게 느껴지는데 좀 더 보완해야겠다ㅠ 뭔가 명확하질 않네... 아무튼 흐름은 깨달았고, 제대로 돌아가긴 한다.

그리고 로그아웃을 한 후, 회원탈퇴로 사용자를 완전히 delete 하기 전에 disconnectEmitter()를 넣어주면 되겠다!

    notificationService.disconnectEmitter(user.getId());
    log.info("SSE 연결 종료(로그아웃) : userId = {}", user.getId());


    log.info("로그아웃 성공");

    notificationService.disconnectEmitter(user.getId());
    log.info("SSE 연결 종료(회원탈퇴) : userId = {}", user.getId());

    // 사용자 삭제
    userRepository.delete(user);
    log.info("회원탈퇴 완료");

(원래는 UserService 내에 로그인, 로그아웃, 회원탈퇴 등의 인증 관련 로직을 함께 관리하고 있었는데, NotificationService에서 UserService를 참조하고, 이번 작업으로 인해 UserService가 다시 NotificationService를 참조하게 되어 순환 참조 문제가 발생했다. 이를 해결하기 위해 인증 관련 기능은 AuthService로 따로 분리했다.)

그러면 이제 Access Denied 예외는 더이상 터지지 않게 된다!

• 리뷰 상세 페이지 조회시, 업로드된 실제 시간과 9시간 차이 발생
  • 방금 업로드한 리뷰에 업로드 된 시간이 '9시간 후'로 표시됨

리뷰를 작성하고 등록시간이 잘 들어오나 확인을 하던 중 발견한 이슈이다.

최신 리뷰에는 n분 전으로 잘 나오는데 방금 작성한 동일한 리뷰인데도 불구하고 내가 쓴 리뷰 쪽에 나오는 리뷰에는 '약 9시간 후'로 뜨는 게 아닌가! 아니 지금 썼는데 뭐 미래에서 썼슈? 응답은 제대로 잘 나오는데 왜.... 저렇게 나오지? 요상하네... 일단 FE님께 말씀드려야지

BE : FE님! 9시간 차이가 나는데용? 뭔가 시간 계산에 착오가 있는 걸까요? FE : 엥??? 둘 다 똑같은 컴포넌트 쓰는데요...? BE: ???

아니 근데 생각해보니까 9시간? 어디서 많이... 봤는데.....? 타임존...?? 너니...? 나는 KST로 설정해뒀지!

BE : FE님! 9시간 차이인 거 보면 타임존 문제인 것 같아요! FE : 응답에 타임존이 없어서 동일한 시간을

• ~에서는 UTC 기준으로,
• ~~에서는 KST 기준으로 계산한것 같으니 CreatedAt에 타임존을 추가해서 보내주시면 될 것 같아요!

발생 이유

• LocalDateTime에는 타임존이 존재하지 않기 때문에 FE에서는 이게 어떤 기준인지 몰라 UTC와 KST를 혼용하게 되어 9시간 차이 발생한 것

근데 LocalDateTime은 타임존이 없어서 편리했던 거 아닌가? 불필요한 타임존 계산 없이 깔끔하게 날짜와 시간만 다루기 때문에 굉장히 편리하다.

그런데 이걸 FE로 전송할때는 타임존이 없어서 어떤 기준으로 해석할지가 애매해진다. 예를 들어서 createdAt: 2025-06-10T12:30:00을 FE에 보내면 이게 UTC인지 KST인지를 알 수가 없다. 그래서 어떤 곳에서는 UTC로 해석하기도 하고 어떤 곳에서는 브라우저 시간대(KST)로 해석하기도 하기 때문에 동일한 시간인데도 불구하고 화면마다 다르게 보인 것이다.

문제 해결

• 문제가 생긴 ReviewResponseDTO의 createdAt, updatedAt 필드에 KST(+09:00) 타임존 정보를 포함하도록 변경

Entity에는 LocalDateTime으로 저장하되, DTO에는 OffsetDateTime으로 변경하여 +09:00을 포함하여 전송하는 방법이다.

public class ReviewResponseDTO {
  private LocalDateTime createdAt; -> private OffsetDateTime createdAt;
}

이렇게 수정해주고, 서비스 로직에서는

return ReviewREsponseDTO.builder()
.createdAt(review.getCreatedAt().atOffset(ZoneOffset.of("+09:00")))

이렇게 해주면 응답값으로 "createdAt": "2025-06-10T12:30:00.000+09:00" 이렇게 나오게 된다. 그러면 FE쪽에서는 아! 이건 KST구나! 하고 제대로 인식하게 되면서 제시간으로 보여주게 된다.

프로필 사진 등록/수정 multipart/form-data 이걸로 되어있나요? 스웨거에 나와있는대로 application/json 으로 { "file": "string" } 이렇게 보내니 안 돼요

descrption에 "파일 업로드"라고 적어둬서 어련히 알아서 하시는 줄 알았지만 API 명세서 대로 작업하시는 분들이었음 ㅠ 죄송.... 송구...
오른쪽 중단에 보면 application/json이라고 나와있어서 요청 바디에 json으로 계속 요청을 하셨는데 안 되셨던 거였다. FE께서 이런 저런 삽질을 하다가 content-type에 대해 알아보고 혼자 해결을 하셨다고 하여 더욱 송구...... 미리 말씀을 드릴 걸......
이게 본래 코드였는데 스웨거 설정을 더 추가해줬다.

  @Operation(summary = "프로필사진 등록/수정")
  @PutMapping(value = "/profile-image", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
  public ResponseEntity<Map<String, String>> updateProfileImage(
      @Parameter(description = "프로필 사진 파일")
      @RequestPart("file") MultipartFile file) {
    String profileImageUrl = profileImageService.updateProfileImage(file);
    Map<String, String> profileResponse = new HashMap<>();
    profileResponse.put("profileImageUrl", profileImageUrl);
    return ResponseEntity.ok(profileResponse);
  }

이렇게 컨트롤러쪽에 consumes를 추가하여 multipart/form-data로 넣으라고 명시를 해주고, 어떤 파일을 넣어야 하는지 Parameter(description = "~")로 설명해주었다. 그러면 이제 스웨거는 이렇게 나온다. FE 개발자가 삽질하지 않도록 API 명세서를 상세하게 잘 써주자...!

BE: 엥 그걸 제가 어케 알아요

왜냐하면 비번은 PasswordEncoder로 암호화되어 저장되었기 때문이다. Spring Security를 쓰면서

public class SecurityConfig {

  @Bean
  public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
  }
}

이렇게 단방향 해시함수인 BcrptPasswordEncoder를 사용하였기 때문에 평문으로 복호화할 수 없다.

그러면 어떻게 하지...? 이거 관리자 계정이란 말이야...!!!!

DB에 쿼리를 날려서 덮어쓰면 되지 않을까?

UPDATE user SET password = '새 비번' WHERE 조건;

이렇게 하면 될 것 같지만.... 이러면 쉬웠겠쥬... 하지만 Spring Security의 BCrpty는 로그인할 때 입력받은 비번을 암호화하여 DB에 있는 암호화된 비번과 비교를 하기 때문에 DB에 암호화된 비번을 저장해두어야 한다.

그렇다면 비번을 암호화를 내가 어케 하지? 그동안은 Spring Security가 해줬는데 ㅠ

프로젝트의 main() 클래스에서

public static void main(String[] args) {
    BCryptPasswordEncoder encoder = new BCryptPasswordEncoder();
    String encoded = encoder.encode("새 비번");
    System.out.println(encoded);
}

이렇게 하고 메인 메서드를 실행하면 콘솔에 암호화된 비번 문자열이 출력된다.

이렇게 얻은 암호화된 비번으로 쿼리를 날려보자!

UPDATE user
SET password = '암호화된 비번'
WHERE 조건 

이렇게 SQL을 날리면 DB에 새로운 암호화된 비번으로 업데이트 되고, FE 개발자에게는 새로운 비번을 알려주면 된다!

수정 전

@GetMapping("/movie/{tmdbId}")
  public ResponseEntity<PageResponse<ReviewResponseDTO>> getReviewsByMovieId(
      @PathVariable Long tmdbId,
      @RequestParam(value = "certifiedFilter", required = false, defaultValue = "false") Boolean certifiedFilter,
      @PageableDefault(size = 20, sort = "createdAt", direction = Direction.DESC) Pageable pageable
  ) {
    Page<ReviewResponseDTO> reviews = reviewService.getReviewByMovieId(tmdbId, pageable, certifiedFilter);
    return ResponseEntity.ok(new PageResponse<>(reviews));
  }

@PageableDefault로 디폴트 정렬을 사이즈는 20, createdAt 최신순으로 리뷰 데이터를 조회할 수 있도록 했다. 그러면 /api/reviews/movie/{tmdbId}로만 요청을 하면 기본적으로 작성일시 기준 최신순으로 조회가 된다. Review 엔티티에는 좋아요 수(likeCount)도 있기 때문에 /api/reviews/movie/{tmdbId}?sort=likeCount,desc 로 요청을 하면 좋아요 수를 기준으로 내림차순으로 보여준다. 그런데 좋아요 수가 같은 경우가 있지 않은가! 이럴 때를 위해 두 번째 정렬이 필요하기 때문에 /api/reviews/movie/{tmdbId}?sort=likeCount,desc&sort=createdAt,desc 이런 식으로 정렬 기준을 2개를 같이 적어줘야 좋아요 순으로 내림차순 정렬하되, 동수가 발생하면 작성일을 기준으로 최신순으로 보여주게 된다.

• BE : FE님! 좋아요순으로 정렬하고 싶으시면 ?sort=likeCount,desc&sort=createdAt,desc 이런 식으로 요청하시면 됩니다~

• FE : 정렬 기준은 좋아요 수 한 개만 주세요. 근데 동수 발생시 최신순으로는 나오게 해주세요
• BE : 앗...! 넹... (일단 해본다고 한다)

수정 1차

@PageableDafault 대신 @RequestParam을 사용하여 수동으로 정렬로직을 구현해봤다. 디폴트 정렬은 createdAt으로 하되, 좋아요 순 정렬 요청이 들어오면(sortType이 "likeCount"인 경우,) 좋아요 수 내림차순을 정렬을 하고, 좋아요 수가 동점인 경우 createdAt(작성일시) 기준으로 추가 정렬을 해주는 것이다.

@GetMapping("/movie/{tmdbId}")
public ResponseEntity<PageResponse<ReviewResponseDTO>> getReviewsByMovieId(
    @PathVariable Long tmdbId,
    @RequestParam(value = "certifiedFilter", required = false, defaultValue = "false") Boolean certifiedFilter,
    @RequestParam(value = "sort", required = false, defaultValue = "createdAt") String sortType,
    @PageableDefault(size = 20) Pageable pageable
) {
  Sort sort;
  if (sortType.equals("likeCount")) {
    sort = Sort.by(Sort.Order.desc("likeCount"), Sort.Order.desc("createdAt"));
  } else {
    sort = Sort.by(Sort.Order.desc("createdAt"));
  }

  Pageable sortedPageable = PageRequest.of(pageable.getPageNumber(), pageable.getPageSize(), sort);
  Page<ReviewResponseDTO> reviews = reviewService.getReviewByMovieId(tmdbId, sortedPageable, certifiedFilter);

  return ResponseEntity.ok(new PageResponse<>(reviews));
}

특히 likeCount가 정렬 기준으로 들어오면 sort = Sort.by(Sort.Order.desc("likeCount"), 이 부분을 통해 좋아요 수 내림차순 정렬로 고정을 하게 된다. 좋아요 수는 대체로 내림차순 정렬을 하니까 고정하는 게 효율적이라고 생각했다. 그리고 Sort.Order.desc("createdAt")); 이 부분을 통해 좋아요 수 정렬 후, 최신순으로 정렬을 하게 된다.

• BE : FE님! ?sort=likeCount 이렇게 요청하시면 desc도 작성하실 필요 없고 다른 정렬 기준도 작성하실 필요 없어용! 효율적이죠!!

• FE : 그냥 다른 거 주던 거랑 똑같이 주세요. sort=likeCount,desc 이렇게요. 나중에 다른 정렬 기준도 생길 수 있어서 확장성을 위해서 동일하게 하는 게 낫지 않을까요?
• BE : 앗... 넹.... (이제 어떻게 해야할지 모르겠지만 일단 해본다고 한다)

수정 2차

다시 원상태로 돌아왔다.

?sort=likeCount,desc로든 ?sort=likeCount,asc로든 정렬 기준과 정렬 방향을 적어주되, 동수가 나와서 정렬 기준이 한 개 더 필요함에도 불구하고 정렬 기준은 한 개만 달라..... 어떻게 하면 좋을까?

일단 다시 @PageableDefault를 사용하여 ?sort=정렬기준,정렬방향 형식으로 정렬 요청을 할 수 있도록 수정했다.

추후에 likeCount 외에도 rating(별점)도 정렬 기준으로 사용할 수 있기 때문에 Sort.Order 객체들을 리스트에 담기로 했다. 이를 위해 pageable.getSort().toList 를 이용해서 현재 요청된 정렬 조건을 List<Sort.Order>형태로 꺼내서 새 리스트에 복사했다. 즉, pageable 객체에 들어 있는 정렬 조건들을 꺼내서 리스트로 만든 것이다.

List<Sort.Order> orders = new ArrayList<>(pageable.getSort().toList());

그리고 orders 리스트를 .stream()으로 순회하며 order.getProperty().anyMatch()를 이용하여 좋아요수("likeCount")가 있는지 확인하고 있으면 true를 반환한다.

orders.stream().anyMatch(order -> order.getProperty().equals("likeCount")

만약 이게 참인데 (좋아요 수 정렬 요청했는데) 정렬 조건에 createdAt이 포함되지 않은 경우, 동점 처리용으로 createdAt 기준 내림차순 정렬을 추가로 넣어줬다:

boolean hasCreatedAt = orders.stream()
                             .anyMatch(order -> order.getProperty().equals("createdAt"));
if (!hasCreatedAt) {
  orders.add(Sort.Order.desc("createdAt"));
}

마지막으로 orders 리스트를 기반으로 새로운 Sort 객체를 만들고, 이를 반영한 새로운 Pageable을 생성하여 내가 원하는 복합 정렬 조건이 적용되도록 해줬다.

  @Operation(summary = "특정 영화에 대한 리뷰 조회", description = "댓글은 포함되어있지 않습니다." )
  @GetMapping("/movie/{tmdbId}")
  public ResponseEntity<PageResponse<ReviewResponseDTO>> getReviewsByMovieId(
      @PathVariable Long tmdbId,
      @RequestParam(value = "certifiedFilter", required = false, defaultValue = "false") Boolean certifiedFilter,
      @PageableDefault(size = 20, sort = "createdAt", direction = Direction.DESC) Pageable pageable
  ) {
    List<Sort.Order> orders = new ArrayList<>(pageable.getSort().toList());
    if (orders.stream().anyMatch(order -> order.getProperty().equals("likeCount"))) {
      boolean hasCreatedAt = orders.stream().anyMatch(order -> order.getProperty().equals("createdAt"));
      if (!hasCreatedAt) {
        orders.add(Sort.Order.desc("createdAt"));
      }
    }
    Pageable newPageable = PageRequest.of(pageable.getPageNumber(), pageable.getPageSize(), Sort.by(orders));
    Page<ReviewResponseDTO> reviews = reviewService.getReviewByMovieId(tmdbId, newPageable, certifiedFilter);
    return ResponseEntity.ok(new PageResponse<>(reviews));
  }

이러면 ?sort=likeCount,desc와 같이 정렬 기준을 likeCount 한 개로 요청시, 좋아요 순으로 정렬이 되고, 동수가 발생하면 작성 일시 기준 최신순으로 정렬이 되는 복합 정렬이 잘 이루어진다!

문제는 해결이 됐다만, 그런데 뭔가 좀..... 지저분한 거 같은데 좀 더 좋은 방법이 있으면 알려주시기를 부탁드립니다..!!!!!

그런데 이 인증샷은 필수가 아니라 사용자가 선택적으로 업로드해도 되는 것이다.

그러면 인증샷을 올리지 않은 사용자가 GET /api/certifications/me로 자신의 인증샷을 조회하는 요청을 보내면 기존에는 요청받은 리소스가 존재하지 않으니 404(Not Found) 에러를 내보냈다.

BE 관점에서는 요청한 리소스가 존재하지 않기 때문에 당연히 404가 맞다고 생각했다. FE 개발자는 에러 코드가 있으니 예상 가능한 에러이면 올바른 에러 페이지로 보내는 처리를 해야 한다.

그런데! 인증샷 업로드는 선택사항이므로 없을 수도 있는 리소스인데 이게 존재하지 않는다고 해서 비정상인 것까지는 아니지 않는가...!

그래서 다음과 같은 흐름으로 가는 건 어떨지 의견을 주셔서 응답을 변경했다.

• 인증샷을 올린 사용자의 요청

  ➡️ 200 OK + 인증샷 데이터 반환

• 인증샷을 안 올린 사용자의 요청

  ➡️ 200 OK + {"인증샷url": null, "status": "NONE"}과 같은 빈 값 반환

즉, 에러 대신 정상 응답을 반환하고, 이와 함께 null 데이터를 보내는 방식으로 변경한 것이다. 이런 식으로 반환을 받은 FE 개발자는 인증샷이 아직 업로드 되지 않았다는 것을 인지하고 조건 분기(예를 들어, 업로드 폼 띄우기)를 깔끔하게 처리할 수 있게 된다.

결론

없을 수도 있는 리소스라면

404로 내보내는 것도 좋지만, 각 서비스의 환경에 맞게 200 OK + 빈 응답으로 처리하는 것도 좋은 방법이다.

• 개념 : 몇 번째 페이지인지 기준으로 데이터를 잘라 가져오는 방식

  • 요청 예시 : GET /엔드포인트?page=4&size=20

  • 5번째 페이지의 20개 가져와줘

• Spring Data JPA의 Pageable 인터페이스로 구현이 가능하다.

• 응답 정보

  • 현재 페이지 번호
  • 전체 페이지 수
  • 전체 데이터 수
  • 첫번째/마지막 페이지 여부

• 단점

  데이터가 많을수록 느려질 수 있다. 정적인 데이터에는 적절하지만, 실시간으로 변경되는 데이터가 있는 경우 문제가 생긴다.

• 데이터 추가/삭제로 인한 "밀림 현상"이 일어날 수 있다.
• 예를 들어, 1~3번 데이터를 본 후 다음 페이지로 넘어갔는데, 4번 데이터가 빠지고 5번부터 나올 수 있다.

이처럼 데이터가 실시간으로 변경될 수 있다면 offset 방식은 데이터 누락 문제로 이어질 수 있다. 예를 들어, 관리자 권한으로 대기 ➔ 승인으로 상태를 변경할 시, 실시간으로 데이터가 빠지는 등, 데이터 변동이 잦기 때문에 정확한 이어보기와 부드러운 무한스크롤을 위해 cursor 기반 페이지네이션을 사용하는 게 낫다.

cursor 기반 페이지네이션

• 개념 : 특정 데이터(커서)를 기준으로 그 이후의 데이터를 가져오는 방식 즉, 마지막으로 본 데이터를 기준으로 삼고, 그 다음 데이터를 가져오는 방식이다.

• 응답에 포함되는 정보:

  • 현재 응답 데이터 목록
  • 다음 요청에 사용할 커서 값
  • 다음 페이지 존재 여부 (hasNext)

• 요청 :

  최초 요청 시: 커서 없이 요청 → 첫 번째 커서 기준으로 응답 이후 요청 시: 마지막으로 받은 커서 값을 기준으로 다음 데이터 요청

• 특징 :

  • 데이터가 많아도 성능이 일정하다
  • page 개념이 없고, "어디서부터 이어받을지"만 신경을 쓴다.
    • 몇 번째 페이지를 요쳥하는 게 아니라 어디까지 봤는지를 기억해서 요청하는 것

• 주의할 점

  • 커서로 사용하는 값은 정렬 가능한 고유한 값이어야 함

  • 커서 값이 동일한 데이터가 여러 개 있을 경우, 중복 조회되거나 누락되는 문제 발생 가능 → 두 번째 정렬 기준 필요 (ex. 첫 번째 커서 - createdAt, 두 번째 커서 - id)

    • 이런 식으로 진행하려면 첫 요청에는 첫 번째 정렬기준(커서)를 필수로 넣어야 하고, 두 번째 요청부터는 첫 번째 요청에서부터 응답받은 첫 번째, 두 번째 정렬기준(커서)를 모두 필수로 넣어줘야한다. 그리고 이러한 과정을 hasNext가 true인 동안 반복해서 호출해준다.

• 구현 방식 : Page 처럼 공식적으로 정해진 클래스가 없으니 각자의 서비스에 맞게 CursorPageResponse 커스텀 응답 클래스를 정의해서 사용해야 한다.

  @Getter
  @AllArgsConstructor
  public class CursorPageResponse<T> {
  
  private List<T> content; // 데이터들
  private LocalDateTime nextCreatedAt; // 마지막 인증의 생성시간
  private Long nextCertificationId; // 마지막 인증의 ID
  private boolean hasNext; // 더 많은 데이터가 있는지 여부
  }
  

TMDB API로부터 넷플릭스에서 제공하고 있는 영화 데이터를 받아서 사용중이다. 넷플 내의 인기순으로 받아오기는 쉽지 않았기 때문에 어쩔 수 없이 TMDB 내의 인기도 순으로 정렬을 했다. 그리고 인덱스 페이지에 인기 영화 20위를 보여주는 API를 넣어두었다. 그런데 인도 영화가 인기가 높더라구여......? 인도 영화 당연히 있을 수 있지. 발리우드 재밌지. 응응 그런데 제목이 인도어?힌두어? 되어 있는 영화가 있었다. (아마도 아직 한국에는 정식으로 들어오지 않은 영화가 아닌가 싶다. 제목도 번역이 안 되어 있고, 줄거리조차 적혀있지 않음) 우리는 볼 수도 없는 영화를 봐야하니 꽤나 미관참시가..... 방법을 찾아봐야지... 그래서 일단!

한국어/영어로 번역된 제목만 필터링하기

넷플릭스에서는 어지간하면 영화 제목을 한국어로 번역을 해주고 정 번역이 안 되어 있으면 영어 제목으로 보여주는 것에 착안하여 TMDB의 API에서 반환값 중 title에 한국어, 영어만 조회해오도록 필터링을 거는 것이 좋겠다고 판단했다. (original_title이 아니라 title이다!)

정규식을 사용해서 메서드를 만들어줬다.

  private boolean isKoreanOrEnglishTitle(String title) {
    if (title == null) return false;

    boolean containsKorean = title.matches(".*[ㄱ-ㅎㅏ-ㅣ가-힣]+.*");
    boolean isEnglishOnly = title.matches("^[a-zA-Z0-9\\s.,!?\"'\\-:()]+$");

    return containsKorean || isEnglishOnly;
  }

먼저, containsKorean에는 title 내에 한 글자 이상의 한글 문자가 포함되어 있는지 검사하는 정규식을 사용했다. 일반적인 한글 글자 뿐만 아니라 자음, 모음도 넣어뒀다. (혹시 모르니께.. 나중에 업데이트 되는 영화 제목이 자음 하나일수도 있으니까...? ㅎ )

isEnglishOnly에는 영어/숫자/공백/문장부호가 포함되는지 검사하는 정규식을 넣어줬다.

이렇게 하면

1. 한글이 포함되어 있든지
2. 영어만 있든지 (예. CTRL)
3. 한글과 영어가 섞였든지
4. 숫자나 기호로만 되어있든지 (예. 9-5) 이러한 것들은 true로 반환된다.

/**
 * 인기도 탑 n 영화 세부정보 조회
 * @param size
 */
  public List<MovieDTO> getTopMovies(int size) {
    Pageable pageable = PageRequest.of(0, size);
    Page<Movie> topMovies = movieRepository.findAllByAvailableIsTrueOrderByPopularityDesc(pageable);
    log.info("인기도 탑{} 영화 조회 성공", size);
    return topMovies.stream()
        .filter(movie -> isKoreanOrEnglishTitle(movie.getTitle()))
        .map(this::convertToDtoWithoutReviews)
        .collect(Collectors.toList());
  }

이렇게 JPA로 영화 데이터를 조회하고, .filter(movie -> isKoreanOrEnglishTitle(movie.getTitle())) 를 통해 필터링을 거쳐준다. 그러면 이제 힌두어?로 되어 있는 영화들은 보이지 않게 되었다.

n개가 다 반환이 안 됐어요!

나는 사실 응답이 나온 것만 확인하고 개수까진 확인하지 않았었다. 알아서 20개 나왔으려니 하고 뿌듯해하고 있었음... 그런데 FE 분이 작업하시다가 20개가 아닌 18개의 데이터만 들어왔다는 사실을 알려주셔서 알게 되었다. 분명 캐시 초기화도 해서 새롭게 들어갔을텐데 왜 18개만 들어갔다는 거지? 나는 분명 getTopMovies의 size에 20을 적었는데?

/**
 * 인기도 탑 20 영화 세부정보 조회
 */
  @Transactional(readOnly = true)
  @Cacheable(value = "top20Movies", key = "'top20Movies'")
  public List<MovieDTO> getTop20Movies() {
    return getTopMovies(20);
  }

그럼에도 불구하고 정말로 20개가 반환이 안 된 것이다.

이미 가져온 데이터를 또 필터링한 죄

생각을 해보자... 그러자 너무나 당연한 결과였다. getTopMovies()에서

Pageable pageable = PageRequest.of(0, size);
    Page<Movie> topMovies = movieRepository.findAllByAvailableIsTrueOrderByPopularityDesc(pageable);

여기에서 size를 20으로 잡았으니 데이터에서 20개를 가져오고, '가져온 데이터에서' 필터링을 또! 거치는 로직이었던 것이다.

그래서 상위 20위 중에 존재하던 힌두어 제목의 영화 2개가 제외되면서 18개만 반환된 것이다.

DB의 정규식을 이용해서 필터링된 데이터 조회하여 가져오기

그동안 정규식은 유효성 검사할 때나 써봤다. 정규식을 데이터를 조회할 때도 쓸 수 있지 않을까 하여 적용해보기로 했다.

그런데...!

JPA에서는 정규식 기반의 데이터 조회를 지원하지 않는다

이가 없으면 잇몸이닷! 네이티브 쿼리를 쓰는 방법이 있지!! SQL을 써버려~~!! 어지간하면 쓰지 말라고 했던 것 같지만 네이티브 쿼리가 필요한 게 바로 이런 순간이 아닐까...!!!

네이티브 쿼리 (nativeQuery) 로 SQL 쿼리 작성하기

네이티브 쿼리 쓰는 방법 : @Query(value = SQL 쿼리, nativeQuery = true)

  // 인기도 상위 n개의 영화정보 조회
  @Query(
      value = "SELECT * FROM movie WHERE is_available = true AND" +
          "(title REGEXP '[ㄱ-ㅎㅏ-ㅣ가-힣]' OR title REGEXP '^[a-zA-Z0-9\\s.,!?~&=\\\"'':()\\-\\+\\#\\*\\%\\/]+')" +
          "ORDER BY popularity DESC" +
          "LIMIT :limit",
      nativeQuery = true)
  List<Movie> findAllByAvailableIsTrueOrderByPopularityDesc(@Param("limit") int limit);

value 부분에는 내가 원래 조회하고 싶었던 쿼리를 작성해준다. AND를 사용해서 정규표현식(REGEXP) 두 조건을 넣어 필터링해준다. (두 정규식 사이에는 OR 연산자로 연결해서 조건에 맞는 제목들을 모두 조회하도록 한다.) 그리고 popularity 컬럼 기준 내림차순으로 정렬해주고, LIMIT를 활용해서 결과의 개수를 제한하도록 해준다. 마지막엔 nativeQuery = true를 넣어주어 네이티브 SQL 쿼리를 사용함을 명시해줘야 한다.

주의해야할 것은, DB에서 사용하는 컬럼명과 일치해야 한다는 것이다. 처음에는 isAvailable로 적었다가 컬럼이 존재하지 않는다길래 당황했지만 describe Movie;를 해보니 is_available로 되어있길래 수정했다.

그리고 다시 서비스 코드를 수정해준다. 이제 필터링은 할 필요가 없으니 isKoreanOrEnglishTitle() 메서드는 삭제하고, getTopMovies() 내부에서의 필터링 코드도 삭제해준다.

  /**
   * 인기도 탑 n 영화 세부정보 조회
   * @param size
   */
  public List<MovieDTO> getTopMovies(int size) {
    List<Movie> topMovies = movieRepository.findAllByAvailableIsTrueOrderByPopularityDesc(size);
    log.info("인기도 탑{} 영화 조회 성공", size);
    return topMovies.stream()
        .map(this::convertToDtoWithoutReviews)
        .collect(Collectors.toList());
  }

이러면 이제 문제 없이 의도했던 대로 n개의 데이터가 잘 받아와진다!

ration$PageModule$WarningLoggingModifier : Serializing PageImpl instances as-is is not supported, meaning that there is no guarantee about the stability of the resulting JSON structure! For a stable JSON structure, please use Spring Data's PagedModel (globally via @EnableSpringDataWebSupport(pageSerializationMode = VIA_DTO)) or Spring HATEOAS and Spring Data's PagedResourcesAssembler as documented in https://docs.spring.io/spring-data/commons/reference/repositories/core-extensions.html#core.web.pageables.

이 로그는 PageImpl 객체를 ResponseEntity<Page> 형태로 반환하면, JSON 구조가 불안정할 수 있다고 경고해주는 로그이다.

현재 별 문제는 없이 돌아가고 있지만 뭔가 로그에 찍히면 고치고 싶다.

1. 로그에 적힌 대로 PagedModel과 @EnableSpringDataWebSupport 사용하기

이걸 쓰면 전역 설정이 되어 자동 변환 가능하다
하지만!!!!! PagedModel을 사용하면 반환형이

{
"content": [데이터들......],
"page": {
"size": 10,
"number": 1,
"totalElements": 228,
"totalPages": 23
}
}

이렇게 고정이 되어버린다.

그런데 우리 서비스는

"content": [],              // 데이터들
"number": 1,                // 현재 페이지 (0부터 시작)
"size": 2,                  // 요청한 페이지 크기
"totalPages": 10,           // 전체 페이지 수
"totalElements": 20,        // 전체 아이템 수
"numberOfElements": 2,      // 현재 페이지에 실제 담긴 아이템 수
"first": false,             // 첫 페이지인지 여부
"last": false,              // 마지막 페이지인지 여부
"empty": false              // 현재 페이지가 비었는지

이런 부가적인 정보들이 더 필요했다. 그래서 이 방법 말고, 다른 방법을 사용해야 했다.

2. PageResponse DTO를 커스텀하여 만들어 사용하기

public class PageResponse<T> {
private List<T> content;
private int number;             // 현재 페이지 번호 (0부터 시작)
private int size;               // 페이지당 아이템 수
private int totalPages;         // 전체 페이지 수
private long totalElements;     // 전체 아이템 수
private int numberOfElements;   // 현재 페이지의 아이템 수
private boolean first;          // 첫 페이지 여부
private boolean last;           // 마지막 페이지 여부
private boolean empty;          // 현재 페이지가 비어있는지 여부

public PageResponse(Page<T> page) {
    this.content = page.getContent();
    this.number = page.getNumber();
    this.size = page.getSize();
    this.totalPages = page.getTotalPages();
    this.totalElements = page.getTotalElements();
    this.numberOfElements = page.getNumberOfElements();
    this.first = page.isFirst();
    this.last = page.isLast();
    this.empty = page.isEmpty();
}
}

여기서 private long totalElements; // 전체 아이템 수 이것만 long 타입인 이유는 Spring Data의 Page 인터페이스에서 정해둔 규칙이기 때문이다.

public interface Page<T> extends Slice<T> {  
int getTotalPages();  
long getTotalElements(); 
}

실제 데이터 개수가 int의 범위를 넘을 수도 있기 때문에 더 큰 범위를 표현할 수 있는 long을 사용하는 것이다.

그리고 컨트롤러에서는

Page<ReviewResponseDTO> reviews = ~~~~~~
return ResponseEntity.ok(new PageResponse<>(reviews));

요렇게 내가 만든 응답 객체인 new PageResponse<>()를 사용해주면 더이상 PageImpl 직렬화 경고 로그가 뜨지 않게 된다!

맞습니다. 그러면 안 됩니다.

로그아웃을 해도 이전에 쓰던 엑세스 토큰을 넣어 요청을 하면 응답이 제대로 오는 게 뭔가 이상하다 싶었는데... 역시 문제가 있는 이슈였다!

- Access Token

엑세스 토큰은 한 번 발급 되면 서버가 이를 별도로 저장하지 않고, 클라이이언트가 갖고 있게 된다. 서버는 토큰을 만들어서 클라이언트에게 주기만 할 뿐, 이후에는 해당 토큰의 유효성만 검증을 한다. 즉, 토큰에는 여러 정보가 담겨있는데 서버는 그 정보를 해석해서 인증 처리를 해줄 뿐이다. 엑세스 토큰은 stateless 방식(=상태를 갖지 않음)이기 때문에 서버는 클라이언트의 로그인 상태나 세션 정보를 기억하지 않아 보안적 허점이 생길 수 있다.

🧨 엑세스 토큰의 보안적 허점

1. 로그아웃을 했음에도 유효한 토큰 존재

• 사용자는 로그아웃을 하면 서버는 SecurityContextHolder.clearContext()로 현재 요청의 인증 상태만 초기화할 뿐이다. 엑세스 토큰은 여전히 클라이언트에 남아 있기 때문에 서버는 만료시간 전까지 해당 토큰을 정상적인 토큰으로 받아들인다.

2. 토큰 탈취 시, 피해 복구 불가

브라우저나 디바이스에 저장된 토큰이 탈취(ex.XSS) 되면 해당 토큰으로 타인이 내 인증정보로 요청을 보낼 수 있게 된다. 심지어 사용자가 로그아웃을 해도 소용이 없게 된다. 왜냐하면 그 토큰은 유효한 이상, 공격자는 계속 접근을 할 수 있기 때문..!

🛡️ 사고 대응 방안

로그아웃 시, 엑세스 토큰을 블랙리스트로 관리하기

JwtFilter에 블랙리스트 확인 로직 추가

클라이언트가 요청 시 전달한 토큰이 Redis 블랙리스트에 등록되어 있는 경우, 해당 요청을 즉시 거부(401 Unauthorized)하도록 필터를 추가해준다.

@Component
public class JwtFilter extends OncePerRequestFilter {

  private final JwtProvider jwtProvider;
  private final UserDetailsService userDetailsService;
  private final RedisTemplate<String, String> redisTokenTemplate;

@Override
  protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
      FilterChain filterChain)
      throws ServletException, IOException {

    // jwtProvider에 토큰을 추출하는 로직이 있어야 함! 
    // 요청 헤더 중 Authorization에서 값을 꺼내 "Bearer "를 제외한 JWT 토큰 문자열 추출
    String token = jwtProvider.extractToken(request);

    try {
      if (token != null) {

         // 토큰이 Redis의 블랙리스트에 등록된 토큰인지 확인
        String isBlacked = redisTokenTemplate.opsForValue().get(token);
        // 값이 "logout"이면 블랙리스트
        if ("logout".equals(isBlacked)) {
          log.warn("블랙리스트로 등록된 토큰. 접근 거부");
          setErrorResponse(response, HttpServletResponse.SC_UNAUTHORIZED, "로그아웃된 토큰입니다.");
          return;
        }

        // 토큰이 유효한지 검증 
        if (jwtProvider.validateToken(token)) {
          String email = jwtProvider.extractEmail(token);
          Role role = jwtProvider.getRoleFromToken(token);

          UserDetails userDetails = userDetailsService.loadUserByUsername(email);
          Authentication authentication = new UsernamePasswordAuthenticationToken(
              userDetails,
              null,
              Collections.singletonList(new SimpleGrantedAuthority(role.name())));
          SecurityContextHolder.getContext().setAuthentication(authentication);
        }
      }

      // 위의 로직을 모두 통과했으면 다음 필터나 서블릿으로 요청을 넘김
      filterChain.doFilter(request, response);

    } catch (ExpiredJwtException e) {
      log.warn("만료된 JWT 토큰: {}", e.getMessage());
      setErrorResponse(response, HttpServletResponse.SC_UNAUTHORIZED, "토큰이 만료되었습니다.");
    } catch (JwtException e) {
      log.warn("잘못된 JWT 토큰: {}", e.getMessage());
      setErrorResponse(response, HttpServletResponse.SC_UNAUTHORIZED, "유효하지 않은 토큰입니다.");
    }
  }

로그아웃/회원탈퇴 시, 사용하던 엑세스 토큰을 Redis에 블랙리스트로 등록한다.

토큰이 아직 유효한(만료되지 않은) 토큰이라도, 서버는 그걸 "차단된 토큰"으로 인식하여 강제로 무효화하는 방식이다.

@RestController
@RequestMapping("/api/users")
public class UserController {

   @DeleteMapping("/logout")
  public ResponseEntity<Void> logout(HttpServletRequest request) {
    userService.logout(request);
    return ResponseEntity.noContent().build();

  }
 }


@Service
public class UserService { 
  private final RedisTemplate<String, String> redisTokenTemplate;
  private final JwtProvider jwtProvider;

  public void logout(HttpServletRequest request) {

    ~~~~
    // 리프레시 토큰 삭제
    ~~~

    // 기존의 엑세스토큰은 블랙리스트로 등록
    String accessToken = jwtProvider.extractToken(request);

    if (accessToken != null) {
      // 남은 시간 = 만료시간 - 현재시간
      long remainTime = jwtProvider.getExpirationTimeFromToken(accessToken) - System.currentTimeMillis();

      if (remainTime > 0) {
        // 남은 시간동안 블랙리스트로 등록
        redisTokenTemplate.opsForValue().set(accessToken, "logout", remainTime, TimeUnit.MILLISECONDS);
        log.info("엑세스토큰 블랙리스트로 등록 완료");
      } else {
        log.info("만료된 엑세스 토큰");
      }
    }

    // SecurityContext 초기화
    SecurityContextHolder.clearContext();
    log.info("SecurityContext 초기화");
    log.info("로그아웃 성공");
  }
  }

그런데 왜 Redis에 저장하지?

• Redis는 메모리 기반 NoSQL이기 때문에 빠르게 블랙리스트에 있는지 여부를 확인할 수 있다.
• 또한 Redis는 TTL 설정이 가능하기 때문에 (set(키, 값, ttl)) 자동으로 ttl 시간 뒤에 삭제할 수 있어서 편리하다.

🔥 Problem

첫 구독은 잘 되고, 두 번째 구독은 Access Denied가 뜨면서 emitter가 종료되고, 세 번째 구독부터 다시 정상적으로 구독이 되는 문제가 생겼다.

로그로 흐름을 보자면 다음과 같다.

첫 번째 구독 시도 -> 성공

SSE 구독 시작
SSE 초기 메시지 전송 시도: userId = 2
SSE 초기 메시지 전송 완료
SSE 구독 시작 : userId = 2

두 번째 구독 시도 -> emitter 종료

기존 emitter 존재: userId = 2
기존 emitter 제거 완료: userId = 2
SSE 초기 메시지 전송 시도: userId = 2
SSE 초기 메시지 전송 완료

이렇게 초기 메시지까지는 전송이 완료됐으나

2025-04-23T11:49:27.764+09:00 ERROR 21356 --- [ddv] [nio-8080-exec-9] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] threw exception

org.springframework.security.authorization.AuthorizationDeniedException: Access Denied
2025-04-23T11:49:27.772+09:00 ERROR 21356 --- [ddv] [nio-8080-exec-9] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Unable to handle the Spring Security Exception because the response is already committed.] with root cause

org.springframework.security.authorization.AuthorizationDeniedException: Access Denied
2025-04-23T11:49:27.775+09:00 ERROR 21356 --- [ddv] [nio-8080-exec-9] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] threw exception

org.springframework.security.authorization.AuthorizationDeniedException: Access Denied
2025-04-23T11:49:27.776+09:00 ERROR 21356 --- [ddv] [nio-8080-exec-9] o.a.c.c.C.[Tomcat].[localhost]           : Exception Processing [ErrorPage[errorCode=0, location=/error]]

jakarta.servlet.ServletException: Unable to handle the Spring Security Exception because the response is already committed.
Caused by: org.springframework.security.authorization.AuthorizationDeniedException: Access Denied
SSE 연결 종료 : userId = 2

이런 식으로 바로 Access Denied 예외가 터지면서 emitter가 종료됐다. 이 때문에 새로고침을 하면 알림이 바로 오지 않는 문제가 발생했다.

세 번째 구독 시도 -> 성공

여기서는 두 번째 구독에서 기존 emitter를 삭제했기 때문에 마치 처음 구독하는 것처럼 로그가 찍혔다.

SSE 구독 시작
SSE 초기 메시지 전송 시도: userId = 2
SSE 초기 메시지 전송 완료
SSE 구독 시작 : userId = 2

이러한 현상이 생기면서 처음 새로고침을 하면 emitter가 종료됨에 따라 30초마다 보내는 ping이 가지 않게 된다. 이 때문에 타임아웃에 따라 구독이 끊기면서 재구독이 되기도 하고, 새로고침을 두 번 해야(= 3번째 구독 시도를 하게 되는 것) 재구독이 되는 식으로 비정상적으로 알림처리가 되는 문제가 생겼다.

엑세스 거절? 나는 로그인 한 사용자만 알림을 받을 수 있도록 구현했고, 동일 유저에게 동일한 토큰으로 테스트를 해 본 건데 왜 접근이 불가능 한거지? 두 번째 구독 요청을 처리하는 중간에 Spring Security 인증이 끊기는 문제 같은데.... 왜 끊기지????

🧨 Reason

SSE는 일반 HTTP 요청과는 달리, 서버와 클라이언트가 계속 연결을 유지하는 통신이다.

Spring Security는 일반적으로 요청-응답을 할 때마다 매번 Authentication을 검사한다. 하지만 SSE 연결은 한 번 열리면 계속 연결을 유지하기 때문에, 그 과정에서 Security Context 관리가 꼬일 수 있다.

특히 SSE에서는 연결이 끊기지 않게 주기적으로 "ping"을 보내는데 이건 새로운 HTTP 요청이 아니라, 기존 열린 연결 안에서 발생하는 데이터 전송이라 Authorization 헤더를 새롭게 보내지 않는다. 이 때문에 서버는 '이게 뭔 요청이여?' 하면서 Security Context를 잃어버리게 되고, 인증이 없다고 판단하여 AccessDeniedException이 발생하게 된 것이다. (즉, 연결은 되어 있는데, 인증 상태가 끊겨버린 상황)

Spring Security의 SecurityContext가 SSE 연결 유지 과정에서 사라짐

그래서 SSE 통신에서는 Authorization: Bearer ~~ 뿐만 아니라 Accept: text/event-stream 이 포함된 경우를 감지해서, SecurityContext를 다시 채워주는 특별한 인증 처리가 추가로 필요하다.

*🧯 Solution *

1. SecurityConfig에서 SSE 구독 엔드포인트를 permitAll()로 열어주기

@Bean
  public SecurityFilterChain securityFilterChain(
      HttpSecurity httpSecurity,
      JwtFilter jwtFilter,
      JwtAuthenticationEntryPoint jwtAuthenticationEntryPoint,
      SseAuthenticationFilter sseAuthenticationFilter)
      throws Exception {
 return httpSecurity
        .cors(cors -> cors.configurationSource(corsConfigurationSource()))
        .csrf(AbstractHttpConfigurer::disable) // REST API이므로 CSRF 비활성화
        .formLogin(AbstractHttpConfigurer::disable) // 폼 로그인 비활성화
        .httpBasic(AbstractHttpConfigurer::disable)
        .authorizeHttpRequests(auth -> auth
            .requestMatchers(AUTH_WHITELIST).permitAll()
            .anyRequest().authenticated()

여기에서 AUTH_WHITELIST에 sse 구독 엔드포인트를 넣어두면 된다. .requestMatchers("엔드포인트").permitAll()로 적어도 된다.

어랏? 이러면 모두가 접근할 수 있잖아. 나는 로그인 한 사람만 알람을 받을 수 있게 하고 싶은건데?

그래서!

2. SseAuthenticationFilter를 구현하여 로그인을 한 사용자인지 체크하는 장치 마련하기

SseAuthenticationFilter를 만들어서 여기에서 다시 JWT 검사를 하면 토큰이 있는 사람만 접근할 수 있게 하면 된다. (문은 누구나 들어올 수는 있지만, 발권 검사를 하는 것으로 생각하면 된다.)

SseAuthenticationFilter가 직접 Authorization 헤더를 읽고, 거기에 들어있는 JWT을 꺼내서 직접 토큰을 검증하도록 다시 인증을 세팅한다. 이 다음부터는 인증된 사용자로 SSE 연결을 안전하게 유지할 수 있게 되어 Access Denied 예외가 터지지 않는다.

@Component
@AllArgsConstructor
public class SseAuthenticationFilter extends OncePerRequestFilter {
  private final JwtProvider jwtProvider;

  @Override
  protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
      FilterChain filterChain) throws ServletException, IOException {

    // 1. 헤더에서 Accept 가져오기
    String acceptHeader = request.getHeader(HttpHeaders.ACCEPT);

    // 2. SSE(text/event-stream)인지 확인
    if (acceptHeader != null && acceptHeader.contains("text/event-stream")) {

      // 3. Authorization 헤더에서 JWT 토큰 추출
      String token = extractTokenForSse(request);

      // 4. 토큰이 없거나 유효하지 않은 경우 401 Unauthorized 반환
      if (token == null || !jwtProvider.validateToken(token)) {
        response.setStatus(HttpStatus.UNAUTHORIZED.value());
        return;
      }

      // 5. 토큰이 유효한 경우, Authentication을 생성해서 SecurityContext에 저장해서 인증 세팅
      Authentication authentication = jwtProvider.getAuthentication(token);
      SecurityContextHolder.getContext().setAuthentication(authentication);
    }

    // 6. 다음에 실행될 Spring Security 필터로 요청 넘김
    filterChain.doFilter(request, response);
  }


  // Authorization 헤더에서 토큰만 추출하는 메서드
  private String extractTokenForSse(HttpServletRequest request) {
    String bearerToken = request.getHeader(HttpHeaders.AUTHORIZATION);
    if (bearerToken != null && bearerToken.startsWith("Bearer ")) {
      return bearerToken.substring(7); // "Bearer " 이후 토큰 부분만 추출
    }
    return null;
  }
}

3. SecurityConfig 마지막 부분에 필터 등록하기

            .anyRequest().authenticated()
)
        .exceptionHandling(exception ->
            exception.authenticationEntryPoint(jwtAuthenticationEntryPoint)) // 401 처리
        .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class)
        .addFilterAfter(sseAuthenticationFilter, JwtFilter.class) // SSE 인증 필터
        .build();
  }

여기에서 .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class) .addFilterAfter(sseAuthenticationFilter, JwtFilter.class)
이 부분의 순서가 중요한데, 꼬옥 JwtFilter 뒤에 SseAuthenticationFilter를 추가해야 한다.

일단 요청이 들어오면 JwtFilter가 JWT을 검증해서 SecurityContext를 세팅한다. (doFilterInternal에서의 SecurityContextHolder.getContext().setAuthentication(authentication) 이 부분을 말한다.) 그런데 SSE 요청이 들어오면 따로 JWT을 다시 인증해서 SecurityContext를 채워주는 흐름으로 가야 한다.

구독을 했다가 재구독을 하면 바로 Access Denied가 나왔었는데 이제는 이런 식으로 로그가 찍히면서 더이상 Access Denied가 나오지 않는 것을 볼 수 있게 된다.

SSE 구독 시작 : userId = 2
SSE 초기 메시지 전송 시도: userId = 2
SSE 초기 메시지 전송 완료

SSE 구독 시작 : userId = 2
기존 emitter 존재: userId = 2
기존 emitter 제거 완료: userId = 2
SSE 초기 메시지 전송 시도: userId = 2
SSE 초기 메시지 전송 완료

일단은 최솟값은 0이 아니라 0.5로 두고 싶기 때문에 DTO쪽에 @Min(value=0.5)로 두려고 했다. 하지만 @Min과 @Max는 int 값만 허용하기 때문에 double 값인 0.5로 설정하면 컴파일 에러가 났다.

이를 해결하기 위해서는 (소수점 이하를 포함하여 검증하기 위해서) @DecimalMin(value = "0.5"), @DecimalMax(value ="5.0") 이렇게 하는 방법도 있으나,

유효성 검사로 0.5 단위만 허용하는 내가 만든 RatingValid라는 이름의 커스텀 Validator를 사용할 수 있다.

ConstraintValidator<A, T> 를 구현한 RatingValidator 클래스 만들기

여기서 A는 애너테이션의 타입이고, T는 검사할 값의 타입이다. 애너테이션은 RatingValid로 이름을 정하고, 0.5 단위이기 때문에 Double로 타입을 적었다. 반환값으로는 0.5 이상, 5.0 이하의 값이면서, 0.5단위로만 값을 받았는지 여부를boolean으로 받도록 했다. (rating == null 이 조건은 내 서비스 내에서는 리뷰 수정시 별점은 수정하지 않을 수도 있게 한 거라 이건 각자의 서비스에 따라 달라지는 조건이다.)

커스텀 애너테이션 RatingValid 만들기

만드는 방법은 아래와 같다. https://jakarta.ee/specifications/bean-validation/3.0/apidocs/jakarta/validation/constraint

@Contraint

단어 그대로 강제하는 기능을 가진 애너테이션이라는 것을 표시한 것이다. 그리고 실제 검증 로직은 (validatedBy = RatingValidator.class)에 따라 RatingValidator 클래스에서 한다는 뜻이다. 이로써 @RatingValid를 넣으면 유효성 검사를 할 수 있게 된다.

@Target({ElementType.FIELD, ElementType.PARAMETER})

이건 어디에 이 애너테이션을 붙일 수 있는지 정하는 것이다. DTO에서 멤버변수에 붙이기 위해서 ElementType.FIELD를, Controller에서 파라미터에 붙이기 위해서 ElementType.PARAMETER를 붙여준 것이다.

Retention(RetnionPolicy.RUNTIME)

요거는 Contraint에 들어가보니 되어 있길래따라 적어줬다. 찾아보니 스프링이 구동중이어야 유효성 검사가 실행되는 것이기 때문이라고 한다.

@interface

나만의 애테이션을 만들거야. 그것의 이름은! _ _ ___ __

String message() default "어쩌구저쩌구"

유효성 검사에 실패하면 나올 에러 메시지를 적는 곳이다.

Class<?>[] groups() default {};

Class<? extends Payload>[] payload() default {};

이것들은 실제로 사용되는 부분은 아니다. 하지만 Bean Validation(= Java 표준 유효성 검사)에서 커스텀 제약 조건 애너테이션을 만들 때 message 뿐만 아니라 groupg(), payload()를 필수로 작성해야 한다고 한다. 그래서 안 쓰더라도 형식 맞추기 용도로라도 정의를 해 놓아야 하는 부분이다. 기본값으로 {} 이렇게 비워두면 된다.

이렇게 유효성 검사를 하도록 애너테이션을 만들어두면 잊지말고 Controller에서 @RequestBody만 적는 게 아니라 @Valid를 적어줘야 한다..!

그런데

출처 : MDN

이렇게 DELETE 메서드는 요청 본문을 포함하지 않는 것이 일반적이라고 한다는 것이다..!

그러면 비번 확인을 어떻게 하지...?

요청 바디를 받는 메서드로 바꾸면 되지 않을까? @DeleteMapping -> @PostMapping으로 바꾸면 고민하던 부분이 굉장히 간단히 해결이 된다.

*REST원칙만 따지면 DELETE가 맞지만 서비스 상황(예를 들어 비밀번호 검증)에 따라 POST를 쓰는 게 더 현실적일 때가 있는 듯하다. *

하지만 더 좋은 방안이 있으면 추천 부탁드리겠습니다...!

참고로 쿼리 파라미터로 비밀번호를 전달하는 방법도 있으나, 비밀번호가 URL에 노출될 가능성이 있어 보안상 하지 않는 것을 추천

처음에는 회원탈퇴를 한 후에 그 회원의 토큰으로 뭔가를 시도할 시, 커스텀예외를 날리도록 구현을 해둔 상태였다.

처음 구현을 했을 때의 UserDetailsServiceImpl의 상태

🔥 Problem

그런데 나오라는 예외 메시지는 는 안 나오고

ERROR 202766 : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception

community.ddv.exception.DeepdiviewException: null
        at community.ddv.service.UserDetailsServiceImpl.lambda$loadUserByUsername$0(UserDetailsServiceImpl.java:23) ~[!/:0.0.1-SNAPSHOT]
        at java.base/java.util.Optional.orElseThrow(Optional.java:403) ~[na:na]
        at community.ddv.service.UserDetailsServiceImpl.loadUserByUsername(UserDetailsServiceImpl.java:23) ~[!/:0.0.1-SNAPSHOT]
        at community.ddv.component.JwtFilter.doFilterInternal(JwtFilter.java:42) ~[!/:0.0.1-SNAPSHOT]

이런 에러 로그가 뜨는 게 아닌가! 왜 null로 나오는거얏.....

유저 정보를 삭제했기 때문에, UserDetailsServiceImpl.loadUserByUsername()에서 유저를 찾지 못하게 되면서 orElseThrow()로 커스텀 예외를 던졌어야 한다. 그런데 그 예외 메시지가 null이라고......? 저렇게 USER NOT FOUND가 잘 써 있는데?

🧨 Reason

Spring Security는 유저가 존재하지 않는 경우 기본적으로 UsernameNotFoundException을 기대한다. 그런데 커스텀 예외인 DeepdiviewException을 넣으면서
Security 내부에서 처리하지 못하고 500 오류가 나오게 된 것이다. (떼잉...)

🧯 Try to solve (1)

그래서
이렇게 Security가 기대하는 예외로 수정하여 넣어주었다.

🧯 Try to solve (2)

이 뿐만 아니라 회원탈퇴 후 로그아웃 처리도 추가해주었다. 이전에는 Redis에 저장된 리프레시 토큰 삭제까지만 구현해놓았으나

SecurityContext를 초기화하여 탈퇴가 되면 로그아웃 처리가 되도록 수정했다. Spring Security 메모리에는 탈퇴한 사용자 인증 정보도 들어 있기 때문에 이를 초기화해줘야, 이후 요청에서 해당 사용자가 더 이상 인증된 상태로 인식되지 않게 된다.

이 덕분에 탈퇴 후에도 토큰으로 요청이 들어오면 500 에러가 아닌 401 에러가 나오게 된다.

로그를 보다 보면 하루에 한 번씩은 꼭 보게 되는 로그가 있다.

o.apache.coyote.http11.Http11Processor   
: Error parsing HTTP request header
 Note
: further occurrences of HTTP request parsing errors will be logged at DEBUG level.

java.lang.IllegalArgumentException
: Invalid character found in the request target
 [/index.php?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=Hello ]. 
The valid characters are defined in RFC 7230 and RFC 3986

처음에는 '이 ...이게 뭐여?' 하고 당황했지만 아무리 모니터링을 해봐도 내 프로젝트에는 아무런 영향이 없었다. INFO 레벨 로그이기도 하고 해서 그냥 넘어가려다가 요청 URL에 PHP가 써 있는 것을 보고 '흠... PHP쓰는 프로젝트에 봇이 뭔가 이상한 요청을 보내는 건가?' 라는 생각이 들었다.

🪴 왜 이런 게 로그에 찍히지?

조금 찾아보니 역시 예상대로 PHP 기반의 ThinkPHP 프레임워크를 노리는 봇 스캐닝 공격이었다. 여기서 ThinkPHP는 중국에서 많이 사용하는 프레임워크인데, 취약점이 많아 자동화된 봇이 무차별적으로 스캔을 해서 해킹을 시도하는 것이라고 한다.

도둑놈: 이 집 털 수 있나? (덜컹덜컹) 도둑놈: 에이... 안 되네.

🌲 그럼 내 서버는 괜찮은 건가?

YES!

일단 나는 PHP를 사용한 것도 아니고, SpringBoot는 요청 URI에 RFC(인터넷 기술들의 공식 규칙)에 맞지 않는 문자(\, [, ] )가 들어오면 요청 자체를 거부해버려서 컨트롤러까지 도달조차 안 된다.
그래서 로그에는 남지만, 실제로 내 애플리케이션 로직에는 아무 영향이 없다.

엔드포인트가 /api/reviews/{reviewId} 이런 식으로 되어 있고, reviewId는 Long 타입으로 해두었던 상태였다. 그런데 테스트를 해보며 파라미터에 Long 타입이 아닌 String 을 넣었을 때, 401(Unauthorized) 예외가 터지면서 엑세스 토큰을 넣으라는 메시지가 나왔다. 토큰에는 죄가 없는걸!

🧨 Reason

요청한 URL이 '/api/reviews/{Long} 형식이어야 하는데 예를 들어 /api/reviews/{String} 이런 식으로 요청을 하면 String을 파라미터로 인식하지 않고 인증이 필요한 다른 URL로 인식되어 401 에러가 발생하게 된 것이다. 즉, 컨트롤러에서 타입 매핑 오류가 발생한 것인데 Spring Security에서 인증 실패로 오해를 하고 401 응답을 보낸 것이다.

🧯 Try to solve

다른 타입으로 들어왔을 때 발생하는 MethodArgumentTypeMismatchException에 대해 전역 예외 처리를 추가했다.

ErrorCode에는 이렇게 추가해주고

  INVALID_INPUT_VALUE("입력값이 올바르지 않습니다.", HttpStatus.BAD_REQUEST);

GlobalExceptionHandler에는

@ExceptionHandler(MethodArgumentTypeMismatchException.class)
  public ResponseEntity<ErrorResponse> handleTypeMismatchException(MethodArgumentTypeMismatchException e) {
    ErrorCode errorCode = ErrorCode.INVALID_INPUT_VALUE;
    ErrorResponse errorResponse = new ErrorResponse(errorCode.name(), errorCode.getDescription());
    return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(errorResponse);
  }

이렇게 추가해줬다.

그 후 다시 Long이 아닌 값을 넣고 테스트를 해보면 400(존재하지 않는 게 아니라 요청이 잘못됐으니까 Bad Request)에러가 뜨면서

{
  "errorCode": "INVALID_INPUT_VALUE",
  "errorMessage": "입력값이 올바르지 않습니다."
}

이렇게 이쁘게 예외 메시지가 나오게 된다.

참고 (400 vs. 404)

• 400: 요청 자체가 잘못됐을 때
• 404: 리소스가 존재하지 않을 때

1. 초기 메시지 보내기

일단, 클라이언트 쪽에서 SSE를 구독하면 초기 메시지를 서버로부터 받아야 한다. 이 메시지를 받아야 SSE 연결이 성공적으로 되었는지 확인할 수 있다. 또한 프록시 서버 (Nginx)는 일정 시간동안 응답이 없으면 내가 설정한 타임아웃(자원 낭비 방지를 위해 설정)과 관계없이 자체적으로 연결을 끊어버린다. 그래서 SSE 구독 시, 초기 메시지를 전송하는 메서드를 넣어두었다. (다만 subscribe() 메서드는 조금 불안정 한 것 같으니 참고만 부탁드리겠습니다...! 기존 emitter가 제대로 제거되지 않는 느낌.... )

public class NotificationService {

  // SSE 연결을 저장할 Map
  private final Map<Long, SseEmitter> emitters = new ConcurrentHashMap<>();

  /**
   * SSE 구독 메서드
   * @param userId
   */
  public SseEmitter subscribe(Long userId) {

    log.info("SSE 구독 시작 : userId = {}", userId);

    // 1. 기존 emitter 끊기
    SseEmitter previousEmitter = emitters.remove(userId);

    if (previousEmitter != null) {
      log.info("기존 emitter 존재 -> 제거 완료 userId = {}", userId);
    }

    // 2. 새 emitter 저장
    SseEmitter newEmitter = new SseEmitter(30 * 60 * 1000L); // 30 * 60 초 (타임아웃 30분)
    emitters.put(userId, newEmitter);

    // 3. 초기 메시지 전송
    sendFirstMessage(userId, newEmitter);

    newEmitter.onCompletion(() -> {
      log.info("SSE 연결 종료 : userId = {}", userId);
      emitters.remove(userId);
    });

    newEmitter.onTimeout(() -> {
      log.warn("SSE 연결 타임아웃 : userId = {}", userId);
      emitters.remove(userId);
    });

    newEmitter.onError((e) -> {
      log.error("SSE 연결 에러 발생 : userId = {}, error = {}", userId, e.getMessage());
      emitters.remove(userId);
    });

    log.info("SSE emitter 등록 완료 : userId = {}, 현재 emitter 수 = {}", userId, emitters.size());
    return newEmitter;
  }

  //  SSE 초기 메시지 전송 메서드
  private void sendFirstMessage(Long userId, SseEmitter emitter) {
    try {
      log.info("SSE 초기 메시지 전송 시도: userId = {}", userId);
      emitter.send(SseEmitter.event()
          .name("connect")
          .data("SSE connect success"));
      log.info("SSE 초기 메시지 전송 완료");
    } catch (IOException e) {
      log.error("SSE 초기 메시지 전송 실패: userId = {}, error = {}", userId, e.getMessage());
      emitter.completeWithError(e);
      emitters.remove(userId);
    }
  }

@RestController
@RequestMapping("/api/notifications")
@RequiredArgsConstructor
public class NotificationController {

  private final NotificationService notificationService;

  // 클라이언트가 SSE 연결 구독
  @Operation(summary = "SSE 연결 구독")
  @GetMapping(value = "/subscribe", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
  public SseEmitter subscribe(@RequestParam Long userId) {

    return notificationService.subscribe(userId);
  }

cf) Postman으로도 테스트가 가능하다. Header에는 Accept: text/event-stream을 넣어주어야 한다. cf) 추후 수정하면서 파라미터로 userId를 넣지 않는 것으로 바뀌었다.

로컬 환경에서 테스트를 해보니 초기 메시지도 잘 오고 알림도 잘 온다! 굿! 알림 구현했구나!생각보다 SSE 까다로운 게 아니었네~ 하고 편안하게 있었다.

그런데....

2. 주기적인 Ping 메시지 보내기

BE님~ 서버에서 SSE를 구독하면 45초마다 연결이 끊겨요!

엥??? 왜요? 로컬에선 잘 되는디...?

위에서도 썼지만 프록시 서버(나의 경우, Nginx)는 일정 시간동안 응답이 없으면 타임아웃과 관계없이 자체적으로 연결을 끊어버린다. 내가 구현한 알림은 내가 작성한 글에 좋아요가 달리거나 댓글이 달렸을 때, 일주일에 한 번 인증상태가 변경되었을 때 오도록 구현했기 때문에 지속적으로 알림이 와다다닥 오지 않는다. (그래서 SSE를 쓴 거기도 하고!) 그래서 응답이 계속 없으니 Nginx가 연걸을 끊어버린 것이다. (나는 로컬에서 진행을 했으니 연결을 끊어버릴 주체가 없어서 계속 연결이 유지됐던 거였다.) 따라서 서버 환경에서는 연결 유지를 위해 주기적으로 핑 메시지를 보내면 연결이 끊기는 것을 막을 수 있다.

// 30초마다 ping 보내기
  @Scheduled(fixedRate = 30000)
  public void sendPingToClients() {
    if (emitters.isEmpty()) {
      return; // ping 보낼 구독자가 없으면 return
    }

    emitters.forEach((userId, emitter) -> {
      if (emitter != null) {
        try {
          emitter.send(SseEmitter.event()
              .name("ping")
              .data("keep-alive"));
        } catch (IOException | IllegalStateException e) {
          log.warn("Ping 전송 실패 : userId = {}, error = {}", userId, e.getMessage());
          emitter.completeWithError(e); // 오류 발생 시 연결 종료 처리
          emitters.remove(userId); // 연결 종료
        }
      }
    });
  }

이렇게 30초마다 핑 메시지를 보내면 응답이 계속 있는 거라고 여기고 Nginx는 연결을 끊지 않고 유지하게 해주는 것이다.

Postman으로 테스트를 해보면 이런 식으로 나온다.

자! FE님~ 초기 메시지랑 핑 메시지 받고 계시죠?

3. Nginx 설정 수정하기

BE님~ 계속 끊기는데요? ㅠ 그리고 초기 메시지부터 안 와요 ㅠ

사실 이 말을 하시기 전까지 Nginx 설정을 수정해야 한다는 생각을 못했다.

*로컬에서는 되는데 서버에서는 안 된다 *

이걸 진작 생각했으면 내 멀쩡한 초기/핑 메시지 보내는 코드를 누덕누덕 고치지 않아도 됐을 것이다. 나는 내가 잘못 짜서 메시지가 안 가는 것이라고 여겨서 대체 뭐가 문제지 하며 하루종일 화면만 노려보고 있었다. 그런데 그동안 Postman에서 http://탄력적IP 이거로 테스트를 했는데 분위기 환기겸(?) https://도메인주소 이거로 테스트를 해보니 나도 안 되는 게 아닌가!!!! 아!!!! HTTPS일 때 문제가 생긴다??? 프록시 서버 Nginx 너...? 너 설마....? 너였냐? 알아보니 Nginx 설정에서 수정을 해줘야 했던 것이다.

특히 HTTP/1.1을 사용해야 SSE 연결이 유지된다고 한다. SSE는 지속적인 연결을 유지하면서 서버에서 클라이언트로 이벤트를 스트리밍하는 방식인데, HTTP/1.1에서는 Connection: keep-alive가 기본값이므로, 한 번 연결을 열면 지속적으로 데이터를 보낼 수 있게 된다.

sudo nano /etc/nginx/sites-available/default

여기에서 알림 부분만 설정을 추가해줘야 한다.

server {

        location / {
                proxy_pass http://탄력적 IP 주소:8080;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
        }

        location /api/notifications {
                proxy_pass http://탄력적 IP 주소:8080;
                proxy_http_version 1.1;
                proxy_set_header Connection '';
                proxy_buffering off;


        }

나는 이렇게 설정을 해줬다. 추가적인 설정이 필요하면 더 넣어도 좋다.

사실 Connection 부분을 저렇게 해도 되는 건지는 확실하지 않다. 
어디서는 keep-alive를 쓰라고 하고, 어디서는 ''를 쓰라고 하기도 하고....  
HTTP/1.1에서 keep-alive가 디폴트라면서 뭘 쓰라고 하는 게 사람의 맴을 힘들게 해요잉.... 
아무튼 나는 ''만 적었는데 이제 모든 오류가 사라지게 되어 일단은 ''로 두고 
문제가 생기면 keep-alive로 수정할 예정이다. 
챗지피티에게 물어보니 장기적으로는 keep-alive로 설정하는 게 낫다고 한다..!

그리고 SSE 메시지가 즉시 클라이언트로 전달되도록 설정한다.

proxy_buffering off;

이제 설정창을 닫고, 설정 파일에 오류가 있난 확인하기 위해

sudo nginx -t

오류가 없으면 Nginx를 재시작해준다.

sudo systemctl restart nginx

이제 서버 환경에서도 알림이 잘 오게 되었다! 문제 해결~

로컬에서는 되는데 서버 환경에서 안 될 땐? 코드도 코드지만 다른 것도 고려를 해봐야 한다~

원래의 패키지 구조는 이러했다. 계층형으로 Controller, Service, Repository, Dto, Entity 나누어 작업하고 있었다.

작은 프로젝트라면 확실히 계층형이 익숙하고 직관적이라 작업하기 편하다. 그런데 작업량이 많아지고 저 폴더들을 열어둔 채 작업을 하다보면 뭐가 어디에 박혀있는지 마우스 휠을 계속 오르락내리락 해야하는 귀찮음이 생긴다.
그리고 함께 작업하는 다른 개발자와 소통을 하다보면 그 자리에서 관련된 코드들을 까봐야하는 경우가 생기는데 관련된 곳을 찾아가기 위해 뭔가 헤매는 모습을 보이는 게 스스로 영 신통치 않아보였다. "코드 좀 봐볼게요~ 서비스에서... NotificationService... 여기서 DTO.. DTO.. 아 여깄네" 이런 나의 모습이 보기 좋지 않다고 생각되었다. (물론 인텔리제이에서는 컨트롤 + 마우스 왼쪽 클릭을 하면 바로 관련된 곳으로 이동이 됩니다) 또한 설정들이 추가되면서 계속 다른 폴더들이 생기게 되는데 이런 애들까지 같은 계층에 있게 되니 보기가 영 좋지 않았다. .

도메인형 패키지

그래서 도메인형으로 나눠봤다.

주요 기능들을 domain 패키지로 묶고 관련된 코드들을 모아 두었다. 그리고 전역적으로 쓰는 건 global 패키지로 두면 깔끔하게 정리가 된다.

열어보면 이런 모습이다. 응집도가 높아져 유지보수하거나 확장하기에 좋을 듯하다. 또한 협업을 할 때는 자신의 도메인 폴더 내에서 작업을 하기 좋아 협업시에도 좀 더 도움이 되지 않을까 생각한다. 그런데 폴더가 꽤나 많아져서 처음에는 오히려 더 복잡하게 느껴질 수도 있을 것 같다. 지금 사실 좀 어색한 상태;;;

뭐가 더 좋지?

더 좋은 건 없고.... 그냥 자신의 상황에 맞게 하는 게 옳은 듯 하다. 초기에는, 혹은 작은 프로젝트를 하게된다면 직관적인 계층형으로 하다가 기능이 많아지거나 큰 프로젝트를 하게 된다면 도메인형으로 변경하는 것도 괜찮을 것 같다.