📘SSE + FCM : 실시간성과 안정성 모두 잡은 알림 시스템 설계
실시간 통신 기술 선택의 요점
- 알림 시스템을 설계할 때 중요한 건 "모든 상황에서 빠르고 안정적으로 알림을 전달하는 것"
- 특히 앱이 켜져 있을 때와 꺼져 있을 때는 동작 방식이 달라, 단일 방식으로는 한계 명확
- 우리 서비스는 모바일 백그라운드 상황까지 안정적으로 커버하는 것이 핵심
실시간 통신 기술 4가지 비교
- SSE
- 웹 기반의 단방향 알림에 가장 적합하다.
- 구현이 간단하고, 리소스 소모가 적으며 HTTP 기반이라 안정성이 높다.
- FCM
- FCM은 앱이 종료되었거나 백그라운드 상태에서도 전송 가능하다.
- 대부분의 경우 안정적인 도달을 보장하지만, 기기 설정이나 절전 모드에 따라 차이가 날 수 있다.
- 대규모 사용자에게 신뢰성 있게 메시지를 전달해야 할 때 가장 유리하다.
- WebSocket
- 양방향 통신이 필요한 기능(예: 채팅, 실시간 상호작용)에 적합하다.
- WebSocket은 많은 연결을 유지할 때 서버 리소스 부담이 증가하고, 스케일링이 복잡해질 수 있음
- Polling
- 간단한 기능이나 초기 개발 단계에서 빠르게 구현할 수 있다.
- 짧은 간격의 주기적 Polling은 서버 리소스 소모가 크며 실시간성도 떨어진다.
가장 적합한 기술 조합 (SSE + FCM)
1. 앱이 켜져 있을 땐 SSE로 즉시 전달
- 클라이언트가 서버에 연결만 되어 있다면, 알림이 발생하자마자 즉시 전송이 가능
- Web이나 iOS 앱이 포그라운드 상태일 때 실시간성 확보 가능
- Push 대신 UI 요소로 알림을 노출하는 데 적합
2. 앱이 꺼져 있을 땐 FCM으로 보완
- 앱이 백그라운드이거나 종료되어 있는 상태에서는 SSE 연결이 끊기기 때문에 실시간 전달이 불가
- 이때는 FCM을 통해 사용자에게 알림을 전달
- 백그라운드나 오프라인 상태에서도 유실 전송 보장
3. 플랫폼 대응성
- Android: FCM
- iOS: FCM (내부적으로 APNs를 통해 알림을 전달하며, Apple의 제한을 따름)
- Web: SSE
하나의 서버 알림 로직에서 클라이언트 플랫폼에 따라 분기 처리하면, 전 플랫폼에서 대응이 가능
4. 구현은 분리, 로직은 통합 가능
- SSE는 클라이언트 접속 기반,
- FCM은 디바이스 토큰 기반
전송 방식은 다르지만, 서버에서는 하나의 알림 생성 로직에서 두 채널로 동시에 전송하는 구조가 가능
이를 통해 도메인 로직과 전달 채널을 깔끔하게 분리 가능
실무 사례
- 카카오톡은 앱이 켜져 있을 땐 실시간 수신(SSE/WebSocket 등), 꺼져 있을 땐 FCM 으로 ****알림을 처리
- 슬랙(Slack) 또한 웹에서는 WebSocket 또는 SSE를 사용하고, 모바일에서는 FCM 으로 전송
이처럼 대규모 서비스에서도 검증된 방식
단점
- 앱 재설치나 기기 변경 시 토큰이 바뀌므로, 유효성 검증 및 갱신 로직 필요
- Android, iOS, Web의 알림 처리 방식이 달라 분기 처리 필요
- 두 채널(SSE, FCM)을 함께 운영하므로 설계 및 에러 처리의 복잡도가 높아짐
- 백엔드로만 처리시 토큰 발급 방식은 별도의 구현 필요(프론트엔드)
하지만 이러한 복잡도는 서비스의 실시간성과 안정성을 모두 확보하는 데 필요한 요소로 판단
결론
- SSE + FCM 조합은 실시간성과 도달률 모두를 확보할 수 있는 현실적인 선택
- 앱 상태나 플랫폼에 따라 유동적으로 분기 처리하면, 알림 유실 없이 안정적인 처리 가능
- 실무에서도 널리 사용되고 있는 방식
기어 올라가는 개발