[프로젝트] 리마인더 알림 구현 방식 선택 과정

PROJECT

독서 리마인더 알림 구현 방식 선택 과정

목차

• 1. 배경
• 2. 알림 구현 방식 비교
• 3. WebSocket을 선택하지 않은 이유
• 4. 결정 — @Scheduled + SSE

1. 배경

독서 리마인더 알림 기능을 처음 구현해보는 상황에서 어떤 방식으로 구현할지 고민이 있었다. 알림 구현 방법이 여러 가지 있다는 것은 알고 있었지만, SSE 외에는 익숙하지 않은 방식들이었다.

리마인더 예시

 

리마인더 알림은 사용자가 설정한 시간에 맞춰 서버가 알림을 보내주는 기능이다. 따라서 단순히 데이터를 조회하는 API와 달리, 서버가 특정 시점에 사용자를 확인하고 알림을 전달하는 구조가 필요했다.

핵심 기준은 구현 난이도, 현재 서비스 규모, 그리고 알림 방향이었다. Booktine의 리마인더는 클라이언트가 서버로 실시간 메시지를 보내는 기능이 아니라, 서버가 클라이언트로 알림을 전달하는 단방향 구조에 가깝다고 판단했다.

2. 알림 구현 방식 비교

방식	설명	난이도
@Scheduled + SSE	서버가 주기적으로 DB를 확인한 뒤 SSE로 브라우저에 알림을 푸시한다.	낮음
@Scheduled + 이메일	서버가 주기적으로 DB를 확인한 뒤 이메일을 발송한다.	낮음
WebSocket	서버와 클라이언트가 양방향으로 실시간 통신한다.	높음
FCM / APNs	모바일 앱에서 사용하는 푸시 알림 방식이다.	중간

3. WebSocket을 선택하지 않은 이유

WebSocket은 처음에 SSE와 함께 가장 현실적인 선택지로 고려했다. 하지만 실제 구현을 생각해보면 현재 요구사항에 비해 복잡도가 높다고 판단했다.

• spring-boot-starter-websocket 의존성 추가 및 STOMP 브로커 설정이 필요하다.
• 연결과 해제를 처리하는 핸들러 구현이 필요하다.
• 접속 중인 사용자 세션을 별도로 관리해야 한다.
• Spring Security 적용 시 WebSocket 인증 처리를 별도로 고려해야 한다.

무엇보다 리마인더 알림은 서버에서 클라이언트로 알림을 보내는 단방향 통신만으로 충분하다. WebSocket은 채팅처럼 클라이언트도 서버로 실시간 메시지를 보내야 하는 경우에 더 적합하다.

Booktine의 리마인더 알림은 양방향 실시간 통신이 필요한 기능이 아니므로, WebSocket은 현재 요구사항에 비해 과한 선택이라고 판단했다.

4. 결정 — @Scheduled + SSE

@Scheduled를 사용한 주기적 알림 확인

@Scheduled는 서버가 정해진 주기마다 특정 메서드를 실행하도록 하는 Spring의 스케줄링 기능이다. 리마인더 알림에서는 서버가 주기적으로 DB를 조회해서 현재 시간에 알림을

보낼 사용자를 확인하고 처리하는 방식으로 사용했다.

@Scheduled를 사용해 매분 리마인더 대상 사용자를 조회하고 SSE로 알림을 전송하는 코드다.

cron 표현식 0 * * * * *는 매 분 0초에 실행된다는 의미다. 초 단위로 정밀하게 알림을 보낼 필요는 없다고 판단했기 때문에 1분 주기로 설정했다.

 

SSE를 사용한 서버 단방향 알림 전송

SSE(Server-Sent Events)는 서버가 클라이언트에 실시간으로 이벤트를 푸시하는 단방향 통신 방식이다. 클라이언트가 서버에 연결해두면, 서버는 필요한 시점에 이벤트를 내려보낼 수 있다.

Spring MVC에서 SseEmitter를 통해 구현할 수 있어 별도의 복잡한 실시간 통신 인프라를 추가하지 않아도 된다.

SseEmitter를 사용해 브라우저에 리마인더 이벤트를 전송하는 코드다.

 

SSE 연결 관리 방식

SSE 연결은 사용자별로 SseEmitter를 ConcurrentHashMap에 저장하는 방식으로 관리했다. 사용자가 /reminders/connect로 연결하면 해당 사용자의 emitter를 저장하고, 연결이 끊기면 자동으로 제거되도록 처리했다.

이렇게 하면 현재 접속 중인 사용자에게만 리마인더 알림을 보낼 수 있고, 불필요하게 끊어진 연결을 계속 보관하지 않아도 된다.

 

선택 이유

• 리마인더 알림은 서버에서 클라이언트로 보내는 단방향 통신만으로 충분하다.
• 별도 인프라 없이 Spring 기본 기능만으로 구현할 수 있다.
• WebSocket보다 구현 복잡도가 낮다.
• Spring Security 연동 시 추가 설정 부담이 상대적으로 적다.
• 현재 Booktine 서비스 규모에 적합한 방식이다.

---

SSE의 한계

SSE에도 한계는 있다. 서버가 재시작되면 기존 연결은 끊어지므로 클라이언트가 다시 연결해야 한다. 또한 브라우저 탭이 닫히면 SSE 연결도 함께 끊긴다.

다만 현재 서비스 규모에서는 이러한 한계가 치명적이지 않다고 판단했다. Booktine의 리마인더 알림은 고빈도 실시간 메시지 처리보다, 사용자가 설정한 시간에 알림을 전달하는 것이 핵심이기 때문이다.

정리하면, Booktine의 독서 리마인더 알림은 양방향 통신이 필요한 기능이 아니므로 WebSocket보다 @Scheduled와 SSE 조합이 더 단순하고 적합한 선택이라고 판단했다.