업무 사건과 멱등 키로 intent를 만들고, 채널은 정책이 고릅니다.
알림 시스템
설계
알림은 메시지를 많이 보내는 문제가 아닙니다. 사용자의 의도·동의·현재 시간과 채널의 실패 제약을 함께 반영해, 중요한 사건을 중복 없이 전달하는 문제입니다.
개념 이해정책 설계장애 대응운영 관점진도 저장
30초 핵심 요약
업무 서비스는 채널 호출 대신 알림 의도(intent)를 기록합니다. 오케스트레이터가 동의·조용한 시간·frequency cap을 판단하고, push·email·SMS worker가 공급자별 제한과 실패를 격리합니다. 사용자 중복은 재시도 횟수만으로 막을 수 없으므로 멱등 키와 inbox 고유성을 함께 둡니다.
입력 경계Intent + Idempotency
정책 경계Preference at send time
성공 의미Provider ≠ user seen
01 · REQUIREMENTS
# 요구사항누구에게, 어떤 이유로, 언제 보낼지 분리한다
수신자가 같은 메시지를 모든 채널에서 원한다는 가정은 위험합니다. 카테고리와 선호 정책을 먼저 모델링하면 발신 서비스가 공급자·토큰·규제를 직접 알 필요가 없습니다.
동의, 조용한 시간, 언어, frequency cap, suppression을 적용합니다.
APNs/FCM, 이메일, SMS의 속도·실패·자격 증명을 worker로 분리합니다.
accepted, suppressed, provider accepted, failed를 하나의 성공으로 합치지 않습니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처의도·정책·전달 시도를 다른 수명으로 둔다
outbox는 업무 트랜잭션과 알림 발행의 틈을 줄이고, 채널 worker는 공급자 장애를 서로 격리합니다. 전달은 at-least-once일 수 있으므로 사용자 노출 중복 방지는 별도 데이터 제약으로 다룹니다.
알림 시스템의 정책과 채널 전달 경로 SVG DIAGRAM · intent / preference / worker / status
중요: 공급자 호출은 성공 응답을 받지 못한 채 실제 수락됐을 수 있습니다. 큐의 at-least-once 재처리는 허용하되, `intent_id`와 inbox의 고유 제약으로 사용자에게 같은 업무 알림이 여러 번 쌓이지 않게 설계합니다.
03 · REQUEST FLOW
# 요청 흐름정책 판단과 공급자 수락을 한 단계씩 남긴다
실패 뒤에 무엇을 다시 해야 하는지 알려면 intent, 정책 결정, 채널 attempt, 사용자 상호작용을 별도 상태로 기록해야 합니다.
업무 이벤트와 멱등 키를 API·outbox에 원자적으로 남깁니다.
동의, quiet hours, suppression, cap을 전송 직전에 확인합니다.
endpoint마다 push·email·SMS의 독립 attempt를 예약합니다.
timeout과 영구 실패를 나누고 backoff·jitter·만료를 적용합니다.
provider 수락, 실패, inbox 표시, 읽음 신호를 분리해 저장합니다.
04 · TRADEOFFS
# 트레이드오프도달률을 높이는 선택은 동의·중복·비용을 함께 바꾼다
최신 선호를 존중하려면 전송 직전 재검사가 유리하지만, 완벽한 순간 일관성을 약속하지는 않습니다. 어떤 category가 예외인지, 변경 전파를 얼마나 빨리 할지까지 계약으로 정합니다.
| 선택 | 장점 | 제약 | 권장 판단 |
|---|---|---|---|
| Intent + channel worker | 공급자 장애 격리, 재시도·감사 가능 | 상태 모델·운영 구성 증가 | 여러 채널 또는 중요 알림에 기본 구조 |
| enqueue 시 정책 고정 | 낮은 지연, 재현 쉬움 | 나중의 해지·quiet 변경을 놓칠 수 있음 | 즉시성 우선 category만 제한적으로 |
| 전송 직전 재검사 | 현재 동의에 더 가까움 | 예약·cache·순서 복잡도 | 마케팅과 예약 알림의 기본 |
| SMS 자동 fallback | 긴급 도달률 보완 가능 | 단가·중복·동의 위험 | 명시된 severity와 동의가 있을 때만 |
| provider accepted = 성공 | 집계가 단순 | 표시·열람을 과장 | 수락·표시·읽음 지표를 분리 |
05 · FAILURE MODES
# 장애 6가지여섯 가지 실패를 사용자 영향과 복구 검증으로 다룬다
outbox 발행 누락
업무는 완료됐지만 알림 intent가 큐로 가지 않아 사용자에게 아무것도 도착하지 않습니다.
대응 · outbox relay 재처리와 업무 이벤트 대비 reconciliation. 기간별 차이를 설명 가능한 수준으로 검증합니다.
timeout 뒤 결과 불명
공급자는 수락했지만 worker는 응답을 못 받아 재시도하고, 사용자는 중복을 볼 수 있습니다.
대응 · 멱등 키, attempt 이력, inbox unique 제약. 동일 intent의 노출 수와 중복률을 확인합니다.
push 공급자 장애
APNs/FCM 오류가 backlog를 늘리고 다른 채널 또는 API 수락을 밀어낼 수 있습니다.
대응 · 채널별 queue, circuit breaker, backoff. 복구 뒤 queue age와 drain 속도를 확인합니다.
만료 endpoint 누적
바뀐 기기 토큰·반송 주소에 계속 시도해 비용과 실패율이 커집니다.
대응 · 영구 실패 분류, endpoint 비활성 후보, 재인증 유도. 비활성 대상 재전송이 0인지 봅니다.
선호 변경 전파 지연
사용자가 해지했는데 예약 작업이 오래된 정책을 보고 발송할 수 있습니다.
대응 · 전송 직전 재검사와 version 지표. 변경 뒤 허용/차단 전환 시간이 목표 안인지 확인합니다.
캠페인 폭주
대량 발송이 보안·거래 알림의 queue와 provider quota를 잠식할 수 있습니다.
대응 · priority queue, quota, 예약 용량. 캠페인 중에도 중요 category의 SLO를 검증합니다.
06 · OPERATIONS
# 운영보안·관측·비용을 채널 호출 밖에서 관리한다
기기 토큰·이메일·전화번호·메시지 본문을 로그에서 분리하고, APNs·FCM·SMTP 자격 증명은 비밀 저장소에서 최소 권한으로 주입합니다.
endpoint_id · masking · audit
intent 수락, policy suppression, provider 수락, queue age, retry, invalid endpoint, inbox dedupe를 stage별로 관측합니다.
queue_age · outcome · version
SMS·email·push 연동 비용뿐 아니라 재시도, endpoint 보관, 템플릿 렌더링, 분석 로그, 수동 반송 대응까지 채널별로 계산합니다.
attempt × channel × retry
면접 모드 · 추가 질문05:00
“하루 1,200만 건의 알림을 푸시·이메일·SMS로 보내야 합니다. 사용자의 해지와 조용한 시간을 지키면서도, 공급자 timeout 뒤 중복을 줄이고 보안 알림이 캠페인에 밀리지 않게 하려면 어떤 데이터 모델·큐·상태 지표를 두겠습니까?”
intent + outboxpreference at sendchannel isolationat-least-once 분리priority SLO
SOURCES
공식·1차 출처
- Apple Developer — Setting up a remote notification server: APNs provider 서버와 원격 알림 설정.
- Firebase — Firebase Cloud Messaging: FCM 전달 모델과 플랫폼별 문서.
- IETF RFC 5321 — Simple Mail Transfer Protocol: SMTP 전송과 응답 모델.
- IETF RFC 9110 — HTTP Semantics: API·webhook의 HTTP 계약 해석.
NEXT CASE STUDY실시간 채팅 시스템 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- Apple Developer — Setting up a remote notification server: APNs provider 서버와 원격 알림 설정의 공식 안내.
- Firebase — Firebase Cloud Messaging: FCM의 메시지 전달 모델과 플랫폼별 문서 진입점.
- IETF RFC 5321 — Simple Mail Transfer Protocol: SMTP의 기본 전송 의미와 응답 모델.
- IETF RFC 9110 — HTTP Semantics: API·webhook HTTP 계약을 읽을 때의 상태 코드와 메시지 의미. 이 출처는 전송 프로토콜과 공급자 경계를 확인하기 위한 1차 자료다. 실제 발송 동의, 보존 기간, 채널 fallback은 서비스가 운영하는 국가·업종·계약을 검토해 별도로 확정한다.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.