고객이 승인 요청을 기다리는데 ‘알림 메일을 보냈다’는 운영 기록만 있다. 시스템은 메일 서비스 API에서 성공 응답을 받았지만, 수신 주소는 오래전에 바뀌었고 메일은 반송됐다. 비슷한 문제가 생기면 담당자는 발송 버튼을 다시 누른다. 그러다 같은 승인 요청이 두 번 전달된다. 업무 알림은 메시지를 만드는 기능이 아니라 업무 사건을 적절한 사람에게 적시에 전달하고, 전달되지 않았을 때 다음 행동을 정하는 기능이다.
Amazon SES의 발송 이벤트 문서는 발송 요청 성공, 수신 서버 전달, 반송, 지연, 스팸 신고 등을 다른 사건으로 구분한다. SES를 사용하지 않아도 이 구분은 중요하다. API 성공은 전송 시도를 맡겼다는 뜻이고, 수신 서버 전달도 사람이 읽었다는 보장은 아니다.
알림을 업무 상태와 같은 트랜잭션으로 보지 않는다
계약 승인 같은 업무가 저장되었는데 메일 서비스가 잠시 멈췄다고 계약 자체를 실패시킬 필요는 없다. 반대로 DB 저장이 실패했는데 ‘승인 완료’ 메일을 보내도 안 된다. 업무 사건이 확정되면 알림 요청을 별도 작업으로 기록하고, 발송 작업자가 이를 처리하는 구조가 안전하다. 같은 사건에서 여러 채널로 보낼 때는 각 채널의 상태를 따로 둔다. 이 구조가 무조건 정확히 한 번만 전달한다는 뜻은 아니므로, 재시도와 중복 방지도 설계해야 한다.
알림 요청의 식별자는 ‘업무 사건+수신자+알림 유형+채널’처럼 안정적인 키로 만들 수 있다. 네트워크 타임아웃 뒤 같은 작업이 재실행돼도 새 알림으로 간주하지 않게 하기 위해서다. 템플릿 버전, 언어, 수신자 주소가 어떤 시점의 값인지도 남긴다. 한 요청이 여러 수신자에게 가는 경우에는 수신자별 전송 상태를 구분해야 반송 한 건이 전체 성공으로 덮이지 않는다.
발송 상태를 한 단어로 압축하지 않는다
최소한 대기, 제공자 접수, 전달 확인, 지연, 반송, 영구 실패 같은 상태가 필요하다. 제공자마다 이벤트 명칭은 다르지만, 운영 화면에는 직원이 취할 행동 중심으로 보여 준다. ‘제공자 접수’ 뒤 일정 시간이 지났다고 자동으로 ‘고객이 읽음’으로 바꾸지 않는다. 클릭이나 열람 추적도 메일 앱의 이미지 차단·프라이버시 기능 때문에 완전한 확인 수단이 아니다. 중요한 업무 완료 확인은 웹앱 안의 명시적인 수락이나 확인 버튼으로 받아야 한다.
수신 결과 이벤트는 중복되거나 순서가 뒤바뀌어 도착할 수 있다. SES 알림 안내도 여러 방법으로 피드백을 설정하면 같은 사건의 알림이 중복될 수 있다고 설명한다. 그래서 제공자 메시지 ID와 내부 알림 ID를 매핑하고, 피드백 이벤트 자체에도 중복 방지 키를 둔다. 늦게 도착한 ‘전달’ 이벤트가 이미 확인된 영구 반송 상태를 무작정 덮지 않도록 상태 전이를 정의한다.
재시도할 오류와 멈출 오류를 구분한다
일시적인 네트워크 실패나 제공자 처리 지연은 간격을 늘려 재시도할 수 있다. 그러나 주소가 존재하지 않는다는 영구 반송이나 명시적인 수신 거부는 같은 주소로 즉시 계속 보내면 안 된다. 영구 실패는 관리자에게 연락처 정정이나 다른 채널 확인을 요청한다. 재시도 횟수와 최대 대기 시간을 정하고, 시간이 중요한 알림은 만료 이후 ‘늦은 성공’보다 담당자 수동 확인으로 넘길 수 있게 한다.
본문 내용에도 주의한다. 메일에 고객의 민감한 신청서나 결제 정보를 전부 붙여 보내면 전달 실패와 별개로 노출 위험이 커진다. 가능한 경우 ‘처리할 일이 있다’는 짧은 알림과 인증 후 열리는 업무 링크를 사용한다. 링크에는 권한과 만료 검사를 넣고, 다른 고객사의 링크를 추측해 열 수 없게 한다. 메일이 늦게 도착했을 때 이미 완료된 작업으로 연결된다면 현재 상태를 정확히 보여 주어야 한다.
수신자 설정은 채널과 중요도별로
모든 알림을 메일·문자·푸시로 동시에 보내면 소음이 된다. 고객이 선택할 수 있는 항목을 중요도와 목적별로 나눈다. 보안 경고나 거래 상태처럼 놓치면 안 되는 알림은 인앱 알림과 메일을 조합할 수 있고, 주간 요약은 묶어서 보낼 수 있다. 단순히 전역 ‘알림 끄기’ 하나로 처리하지 말고, 어떤 알림은 필수 운영 통지인지, 어떤 것은 선택 가능한 안내인지 제품 정책을 명확히 한다.
실무에서 알림 정책이 바뀌면 기존 수신 설정과의 관계도 정해야 한다. 새 알림 유형을 추가할 때 기본값이 무엇인지, 관리자가 조직 전체를 대신 설정할 수 있는지, 개인이 다시 바꿀 수 있는지 결정한다. 시간대에 따른 방해 금지 시간도 비긴급 알림에는 유용하지만, 장애·보안 경고에는 예외가 필요할 수 있다. 이 경계는 UI 문구에도 분명하게 설명한다.
운영 지표는 ‘보낸 건수’가 아니라 전달 가능한 경로
알림의 대기 시간, 제공자 접수에서 전달까지의 지연, 반송률, 실패 후 복구율, 중복 전송 건수, 수신자별 비활성 주소를 본다. 특정 템플릿에서 실패가 늘었는지, 한 고객사에서 수신 주소 정정이 반복되는지도 확인한다. 장애가 나면 개별 메일을 재발송하기 전에 어떤 업무 사건이 알림을 기다리는지 정확히 조회할 수 있어야 한다.
점검 체크리스트
- 업무 사건과 알림 작업을 분리했는가?
- 수신자·유형·채널별 중복 방지 키가 있는가?
- 제공자 접수와 수신 서버 전달을 구별하는가?
- 반송·신고 피드백을 내부 상태로 되돌리는가?
- 일시 실패와 영구 실패의 재시도 정책이 다른가?
- 민감한 내용은 메일 본문 대신 인증된 화면에서 보여 주는가?
- 사용자가 중요도별 수신 채널을 이해하고 선택할 수 있는가?
좋은 알림 시스템은 ‘메일 발송 성공’이 끝이 아니다. 어떤 고객이 어떤 업무를 알 수 있었는지, 실패하면 누가 무엇을 해야 하는지까지 설명할 수 있어야 한다.
