알림

하나의 시스템에서 모바일 푸시, SMS, 이메일을 지원하되 채널별 전송 파이프라인은 분리해야 합니다. 각 채널은 식별자, 외부 제공자, 비용, 실패 방식이 다르므로 공통 요청 형식만 공유하고 실제 전송은 전용 모듈이 담당합니다.

핵심 요구사항은 연성 실시간, 대규모 처리량, 수신 거부 준수, 장애 격리입니다. 알림은 빠르게 도착해야 하지만 순간적인 부하에서는 잠시 큐에 머무르는 것이 소실되는 것보다 낫습니다.

알림 제공자가 요청을 만들고 APNS에 전송하면 APNS가 대상 iOS 단말로 전달합니다. 요청에는 단말 토큰과 알림 페이로드가 필요하며, 인증 정보는 알림 서버가 안전하게 관리합니다.

Android 푸시는 보통 FCM을 거치고, SMS와 이메일은 각각 전문 전송 서비스를 통해 전달합니다. 외부 서비스의 차이는 채널 어댑터가 흡수하고 알림 서버는 공통 이벤트와 상태만 관리합니다.

사용자가 앱을 설치하거나 계정을 등록할 때 API 서버가 이메일 주소, 전화번호, 단말 토큰을 수집해 데이터베이스에 저장합니다. 알림 서버는 직접 원본 정보를 수집하기보다 사용자 서비스가 관리하는 최신 연락처를 조회합니다.

업무 서비스들은 알림 시스템의 API를 호출하고 알림 시스템은 APNS, FCM, SMS, 이메일 제공자를 통해 사용자 단말로 전달합니다. 운영 환경에서는 알림 서버, 데이터베이스, 캐시, 메시지 큐, 작업 서버를 분리해 확장성과 장애 격리를 확보합니다.

알림 서버는 전송 API, 인증, 요청 검증, 수신 설정 확인, 데이터 조회, 중복 검사, 큐 적재를 담당합니다. 실제 외부 서비스 호출은 작업 서버에 위임해 API 응답 속도와 장애 격리를 확보합니다.

업무 서비스의 요청은 알림 서버에서 검증된 뒤 채널 큐에 들어가고 작업 서버가 이를 꺼내 외부 제공자에게 전달합니다. 각 단계의 결과는 알림 로그에 기록해 재시도, 추적, 운영 분석에 사용합니다.

알림 요청을 영속적인 알림 로그나 이벤트 저장소에 기록한 뒤 메시지 큐에 넣어야 합니다. 작업 서버가 실패하더라도 저장된 상태를 기준으로 다시 처리할 수 있어야 하며, 상태 변경도 추적 가능하게 남겨야 합니다.

각 알림에 고유한 이벤트 ID를 부여하고 처리 전에 이미 성공하거나 진행 중인 이벤트인지 확인합니다. 전송은 at-least-once로 처리하되 멱등성 키와 중복 검사로 사용자에게 보이는 중복을 줄입니다.

알림 템플릿, 사용자 수신 설정, 전송률 제한, 인증과 권한 검사가 필요합니다. 이 기능들은 잘못된 대량 발송과 사용자 피로를 줄이고 메시지 형식을 일관되게 유지합니다.

큐 적재량과 대기 시간, 처리량, 실패율, 재시도 횟수, 외부 제공자 지연을 지속적으로 모니터링해야 합니다. 전송 이후에는 수신, 열람, 클릭, 실제 서비스 이용으로 이어지는 이벤트를 분석 시스템과 연결합니다.