대규모 서비스에서 사용자에게 알림(Notification)을 적시에 전달하는 것은 매우 중요한 기능이다. 알림은 이메일, SMS, Push 등 다양한 채널로 발송될 수 있으며 각 채널마다 속도·비용·신뢰성 특성이 다르다. 또한 사용자 수가 수백만, 수천만으로 확장되면 알림 발송은 단순한 기능이 아니라 대규모 분산 시스템 설계 과제가 된다.
알림 시스템의 목표
알림 시스템은 단순히 메시지를 보내는 것이 아니라 확장성, 신뢰성, 유연성을 갖춘 구조로 설계되어야 한다. 이상적인 알림 시스템은 다음 요구사항을 만족해야 한다.
- 낮은 지연(Low Latency): 실시간 이벤트(주문 확인, 비밀번호 재설정 등)는 즉시 발송.
- 대규모 처리율(High Throughput): 초당 수십만 건 이상의 알림을 안정적으로 처리.
- 확장성(Scalability): 사용자 증가 및 채널 증가에도 시스템이 안정적으로 동작.
- 장애 내성(Fault Tolerance): 외부 서비스(SMS 게이트웨이, 이메일 서버) 장애 시에도 복구 가능.
- 유연한 채널 지원(Flexibility): 이메일, SMS, 푸시 알림 등 다양한 채널을 쉽게 확장.
주요 설계 요소
1. 채널 특성
-
이메일(Email)
발송 단가가 저렴하고 대용량 발송이 가능하지만 스팸 필터링 우회나 수신 지연 문제가 발생할 수 있다. 비밀번호 재설정, 주문 확인, 마케팅 등 다양한 목적에 적합하다. -
SMS
즉시성과 도달률이 뛰어나지만 비용이 높다. OTP, 긴급 알림처럼 중요한 이벤트에 주로 사용된다. 통신사 게이트웨이와의 연결이 안정적이어야 하며 재시도 로직이 필수적이다. -
Push Notification
앱 사용자에게 빠르게 도달할 수 있고 비용이 거의 없지만 앱 설치 여부 및 알림 권한 상태에 따라 성공률이 달라진다. 실시간 참여 유도나 사용자 리텐션에 효과적이다.
2. 아키텍처 개요
알림 시스템은 보통 Producer → Queue → Worker → Channel Provider 구조로 설계된다.
- Producer: 알림 이벤트를 생성하는 서비스(예: 주문 완료 이벤트).
- Queue(Kafka, RabbitMQ 등): 알림 요청을 버퍼링하고 비동기 처리.
- Worker: 큐에서 이벤트를 소비하고 채널별 전송 로직 실행.
- Channel Provider: 실제 발송 담당(이메일 서버, SMS 게이트웨이, 푸시 서버 등).
설계 세부 사항
1. 알림 우선순위
알림에는 긴급도에 따라 우선순위를 다르게 적용해야 한다. OTP, 보안 알림은 실시간 우선 처리가 필요하고 마케팅 알림은 대량 발송을 지원하되 지연 허용이 가능하다. 큐를 분리하거나 우선순위 기반 큐를 사용하면 긴급 알림이 지연되지 않고 발송된다.
2. 사용자 선호도 관리
사용자는 알림 채널별 선호도를 가지고 있다. 예를 들어 "광고성 알림은 이메일만 허용, SMS는 차단" 같은 정책이다. 따라서 알림 시스템은 사용자별 알림 환경설정(User Preference Store)을 참조하여 채널을 선택해야 한다. 이를 통해 불필요한 발송을 줄이고 사용자 경험을 개선할 수 있다.
3. 중복 방지 & 재시도
시스템 오류나 네트워크 불안정으로 동일 알림이 여러 번 발송되는 것은 큰 문제다. 이를 방지하기 위해 Idempotency Key를 활용하여 동일 이벤트는 한 번만 처리하도록 해야 한다. 또한 발송 실패 시에는 즉시 재시도하지 않고 지수적 백오프(Exponential Backoff) 전략을 사용하여 네트워크 안정성을 확보한다.
4. 처리율 향상 기법
알림은 대량 발송이 핵심이므로 배치 처리(batch sending)와 비동기 전송이 필요하다. 예를 들어 이메일은 1000건 단위로 SMTP 서버에 전달하고 SMS도 대량 API를 활용한다. 또한 CDN을 이용해 이미지·링크 리소스를 제공하면 알림 클릭 시 사용자 경험이 빨라진다.
5. 확장성
사용자 수와 알림량이 기하급수적으로 늘어날 수 있기 때문에 시스템은 반드시 수평 확장(scale-out)을 고려해야 한다. 알림 Worker는 컨테이너 기반 오토스케일링으로 확장 가능해야 하며 큐 시스템(Kafka 등)은 파티션 단위로 병렬 처리량을 높인다. 또한 멀티 채널 구조에서 특정 Provider가 장애 시 자동으로 다른 Provider로 fallback 할 수 있도록 설계해야 한다.
알림 시스템 아키텍처 예시
[서비스 이벤트 발생]
↓
[알림 Producer]
↓
[Kafka Topic]
↓
[알림 Worker Pool]
↓
[이메일/SMS/푸시 Provider]
↓
[사용자]📝 느낀점
알림 시스템은 단순한 "메시지 전송 기능"이 아니라 분산 환경에서 신뢰성과 처리율을 동시에 보장해야 하는 시스템 설계 과제라는 점이 인상 깊었다. 특히 OTP 같은 보안 알림은 즉시성과 신뢰성이 중요하고 마케팅 알림은 비용 효율성과 대량 전송 최적화가 중요하다는 점에서 알림의 성격에 따른 차별화된 설계가 필요하다. Kafka 같은 큐 기반 아키텍처를 활용하면 서비스 장애와 알림 채널 장애를 격리할 수 있어 안정성이 크게 향상된다. 앞으로 실무에서 마케팅 알림, 보안 알림 등 유형별로 SLA를 정의하고 이를 반영한 설계를 적용해보고 싶다.
