“보냈다는데 왜 안 오지?” 프로덕트 팀 관점으로 디버깅하는 법 (Sent but Not Received)

제품을 운영하다 보면 꼭 한 번은 마주치는 이슈가 있습니다. 시스템에는 Sent(발송 완료)로 찍히는데, 사용자는 “메일이 안 왔다”, “문자가 안 왔다”, “푸시가 안 뜬다”고 말하는 상황이죠. 이 문제는 개발팀만의 영역처럼 보이지만, 실제로는 프로덕트 팀이 사건을 분해하고 재현 가능성을 만들고, 고객 커뮤니케이션을 정리해야 빠르게 해결됩니다.

특히 이메일은 “발송 → 중계(ESP) → 수신사(예: Gmail/네이버/회사 메일) → 스팸/격리/프로모션 분류 → 사용자 앱/웹 표시”처럼 단계가 길어서, 한 단계만 가려져도 “안 받았다”로 체감됩니다. 이 글은 프로덕트 팀이 실제로 쓸 수 있는 방식으로, 원인 범주화 → 확인 질문 → 로그 상관관계 → 재현 → 임시 대응 → 근본 해결 순서로 정리합니다.

1) 먼저 정의부터: “Sent”는 무엇을 의미하나?

내부 대시보드나 DB에 찍힌 Sent는 보통 “우리 시스템이 메시지를 발송 요청했고, 전송 큐에 넣었거나 공급자(ESP/SMS/푸시)에 성공 응답을 받았다” 정도를 뜻합니다. 하지만 이것은 수신함에 도착했다와 동일하지 않습니다.

• Sent: 우리 시스템 기준의 ‘요청 성공’ 또는 ‘공급자 API 호출 성공’
• Delivered: 수신사/단말까지 실제로 도달했음을 의미(채널마다 정의가 다름)
• Opened/Viewed: 사용자가 실제로 열어본 이벤트(이미지 로드/앱 트래킹 등)

따라서 디버깅의 첫 단계는 “Sent만 보이는 상태인지, Delivered까지 확인 가능한 구조인지”를 명확히 하는 것입니다. 프로덕트 팀은 여기에 관여해야 합니다. 지표 정의가 흐리면, 해결도 흐려집니다.

2) 사건을 5구간으로 쪼개면 속도가 빨라집니다

“발송은 됐는데 수신이 안 됨”을 다음 5구간으로 나누면 원인 후보가 급격히 줄어듭니다.

1. 트리거/대상 선정: 누구에게, 어떤 조건에서, 어떤 템플릿으로 보내야 했나?
2. 발송 파이프라인: 큐/워크/레이트리밋/재시도 로직이 정상인가?
3. 공급자(ESP/SMS/푸시): API 응답, 바운스/리젝트/딜레이가 없나?
4. 수신사/단말: 스팸/격리/프로모션 분류, 단말 설정, 차단이 있나?
5. 표시/UX: 앱/웹에서 알림을 숨기거나, 필터링하거나, 잘못된 안내가 있나?

프로덕트 팀이 해야 할 일은 “어느 구간에서 끊겼는지”를 가장 빠르게 특정할 질문과 증거를 준비하는 것입니다.

3) 고객에게 바로 물어봐야 하는 ‘핵심 질문 8개’

이 이슈는 사용자 인터뷰가 디버깅의 절반입니다. 다만 “메일함 확인해보세요” 수준의 질문으로는 해결이 안 납니다. 아래 질문은 원인 분류에 직접적으로 도움이 되는 질문입니다.

• 채널: 이메일/문자/푸시 중 어떤 채널이 안 왔나요? 하나만인가요, 전부인가요?
• 시간: 언제 요청했고, 지금까지 몇 분/몇 시간 지났나요?
• 주소/번호: 등록된 이메일/번호가 맞나요? 오타 가능성은 없나요?
• 메일함 위치: 스팸함/프로모션/사회/광고 탭까지 확인했나요?
• 필터: 메일 규칙(필터)이나 자동 분류가 있나요? 회사 메일이라면 보안 정책이 있나요?
• 클라이언트: 앱(모바일)과 웹(PC) 중 어디서 확인했나요? 둘 다 동일한가요?
• 재시도: 같은 작업을 다시 했을 때도 동일한가요? 다른 이메일로 시도해봤나요?
• 스크린샷/헤더: 스팸함에 있다면 메시지 헤더/발신자 표시를 공유 가능할까요?

프로덕트 팀은 이 질문을 지원팀/CS 매크로로 정리해두면, 엔지니어가 “추측” 대신 “사실”을 가지고 시작할 수 있습니다.

4) 내부에서 가장 먼저 확인할 것: “보낸 대상이 맞았나?”

의외로 많은 경우가 “발송은 성공했는데, 다른 주소로 보냈다” 혹은 “대상이 제외 조건에 걸렸다”입니다. 프로덕트 관점에서 다음을 확인하세요.

(1) 이벤트 트리거가 정말 발생했나?

• 사용자 액션(가입/비번재설정/결제/초대)이 실제로 성공 상태로 기록되었나?
• 트리거 조건이 바뀌거나 A/B로 분기되어 특정 그룹만 발송되었나?
• 템플릿/캠페인 ID가 올바른가? 잘못된 템플릿으로 보내다 차단되는 경우도 있음

(2) 발송 대상이 최신 정보인가?

• 사용자가 이메일을 변경했는데, 캐시/복제 DB/서드파티 CRM이 옛 주소를 쓰고 있지 않나?
• 국문/영문 도메인 혼동, 공백, 전각문자 등 정규화 이슈가 없는가?
• 푸시라면 토큰이 만료되었거나, 멀티 디바이스 토큰이 정리되지 않았나?

“Sent” 로그만 보고 넘어가면, 이 단계에서 시간을 가장 많이 낭비합니다. 먼저 “정확히 누구에게 무엇을 보냈는지”를 확정하세요.

5) 발송 파이프라인: 큐/재시도/딜레이가 가장 흔한 함정

제품이 성장할수록 발송은 비동기로 흘러갑니다. 이때 “Sent”는 사실상 큐에 넣었다일 뿐일 수 있습니다. 다음 포인트는 프로덕트 팀도 이해하고 있어야 이슈 대응이 정확해집니다.

• 큐 적체: 워커가 죽었거나 처리량이 부족하면 몇 분~몇 시간 지연될 수 있음
• 레이트리밋: 공급자 API 제한에 걸려 지연/부분 실패가 발생할 수 있음
• 재시도 정책: 실패 후 재시도 간격이 길면 “안 온다”로 체감됨
• 중복 방지: 동일 요청을 여러 번 눌러도 한 번만 보내도록 막아둔 경우, 사용자 입장에서는 “보냈다는데?”가 됨

프로덕트 팀이 할 수 있는 실무 팁은 간단합니다. 이 구간을 위해 발송 요청 ID(또는 correlation ID)가 화면/로그에 항상 남도록 설계해두면, 사건 하나를 추적하는 시간이 반으로 줄어듭니다.

6) 공급자(ESP/SMS/푸시) 단계: “성공 응답”의 의미를 다시 확인

이메일의 경우 ESP(이메일 발송 서비스)가 “요청 접수”만 성공으로 돌려주는 구조가 흔합니다. 즉 API 200 OK가 와도, 그 뒤에 바운스/리젝트/스팸 처리될 수 있습니다.

(1) 이메일(ESP)에서 반드시 봐야 할 이벤트

• Accepted: ESP가 메시지를 받아 큐에 올림
• Delivered: 수신 서버에 전달 성공
• Bounced: 주소 문제/수신 거부/메일박스 없음
• Deferred: 수신사가 일시적으로 거부(트래픽/정책) → 지연 후 재시도
• Blocked/Rejected: 정책/평판 문제로 전달 자체가 차단
• Complaint: 사용자가 스팸 신고

(2) SMS/푸시에서도 같은 패턴이 존재

SMS는 통신사 구간에서 딜레이/차단이 생길 수 있고, 푸시는 토큰 만료나 디바이스 설정으로 “전송은 됐는데 표시가 안 됨”이 흔합니다. 결국 제품팀이 해야 할 것은 “공급자 이벤트를 내부 로그와 연결해서 한 화면에서 본다”입니다.

7) 수신사 단계: 스팸/격리/프로모션 분류가 ‘안 받았다’의 1순위

사용자는 “받은 메일함(기본 탭)”에 없으면 안 온 것으로 느낍니다. 특히 Gmail은 프로모션 탭, 회사 메일은 격리(Quarantine) 같은 체계가 있어서 실제로는 도착했는데 사용자가 못 찾는 일이 많습니다.

(1) 제품팀이 알아야 할 인증 3종: SPF / DKIM / DMARC

이메일 신뢰도는 대략 이 3가지로 설명됩니다. 제품팀이 깊은 설정까지 할 필요는 없지만, 이게 틀리면 “도착률”이 흔들린다는 감각은 있어야 합니다.

• SPF: 이 도메인이 “이 서버에서 보낸 게 맞다”고 허용 목록을 선언
• DKIM: 메일 내용이 위변조되지 않았고 도메인이 서명했다는 증명
• DMARC: SPF/DKIM 실패 시 처리 정책(격리/거부) + 보고 체계

갑자기 수신이 떨어졌다면, 최근에 도메인/발신 경로/ESP를 바꾸지 않았는지, DNS 변경이 있었는지, From 주소가 바뀌었는지 같은 “제품 변경” 히스토리를 먼저 의심해보세요. 프로덕트 변경은 곧 전달률 변경으로 이어질 수 있습니다.

(2) “보안상 격리”는 사용자에게 보이지 않습니다

B2B 고객(회사 메일)을 상대하면 자주 겪습니다. 회사 보안 정책으로 메일이 격리되면, 사용자는 받은함에서도 스팸함에서도 못 찾습니다. 이 경우는 기술적으로는 Delivered인데, 사용자 체감은 Not Received입니다. 프로덕트 팀은 고객사 IT/보안팀에게 전달할 수 있는 안내 문구를 준비해두는 게 좋습니다.

8) 표시/UX 단계: 사실은 “도착했지만 제품이 숨겼다”

이메일이 아니라 푸시/인앱 알림에서 특히 많은 케이스입니다. 사용자 설정에서 알림이 꺼져 있거나, 앱이 백그라운드 제한을 받거나, 알림 센터에서 자동으로 묶여서 보이는 등 “표시 문제”가 발생합니다.

• 사용자 알림 설정(마케팅/서비스)이 분리되어 있고, 잘못된 토글이 영향을 주지 않는가?
• 앱 권한(알림 허용)이 OS 업데이트 이후 초기화되지 않았는가?
• 특정 버전에서만 누락되는 버그(알림 채널 ID 변경 등)가 없는가?
• 웹에서는 스팸/알림 차단, 브라우저 권한이 꺼져 있지 않은가?

제품팀 관점에서는 이 구간을 위해 “사용자에게 보여주는 상태”가 필요합니다. 예를 들어 “최근 알림 발송 기록”을 앱 내에서 보여주거나, 최소한 “최근 발송 요청 시간”과 “설정 상태”를 한 화면에서 확인할 수 있으면 CS 비용이 크게 줄어듭니다.

9) 재현 전략: 한 번에 잡기 위한 ‘최소 재현 세트’

이슈가 산발적으로 발생하면 엔지니어가 잡기 어렵습니다. 프로덕트 팀은 재현을 ‘실험’으로 만들어줘야 합니다. 아래는 실무에서 가장 효율적인 재현 세트입니다.

1. 테스트 계정 3종: Gmail / 네이버 / 회사메일(가능하면)로 동일 플로우 실행
2. 시간 창: 동일 요청을 3회(간격 두고) 실행해서 지연 여부 확인
3. 템플릿 비교: 동일 채널이라도 템플릿(제목/본문/링크)별로 차이가 나는지 확인
4. 환경 분리: 모바일/PC, 앱/웹을 교차 확인
5. 로그 키: 요청 ID, 사용자 ID, 캠페인/템플릿 ID를 한 줄로 묶어 기록

중요한 건 “한 번 안 왔다”가 아니라, “어떤 조건에서 재현된다”를 만들어주는 것입니다. 그 순간부터는 확률 게임이 아니라 원인 추적이 됩니다.

10) 프로덕트 팀이 챙겨야 할 관측(Observability) 설계

장기적으로는 이 문제를 “사건 대응”이 아니라 “제품 지표”로 만들어야 합니다. 특히 다음 4가지는 제품팀이 우선순위를 잡아 투자할 가치가 큽니다.

• 상관관계 ID: 사용자 액션 → 발송 요청 → 공급자 메시지 ID → 이벤트(Delivered/Bounce) 연결
• 퍼널 지표: Requested → Sent → Delivered → Opened의 전환율을 일/주 단위로 보기
• 도메인/수신사별 분해: Gmail/네이버/기업메일 별로 전달률 차이를 보기
• 알림 품질 알람: 특정 시간대에 Bounce/Deferred 급증 시 자동 경보

이게 갖춰지면 “사용자가 안 받았대요”가 들어왔을 때, 팀이 감으로 싸우지 않고 데이터로 말할 수 있습니다.

11) 임시 대응과 근본 해결을 분리해서 커뮤니케이션하기

이 이슈는 해결까지 시간이 걸릴 수 있습니다. 그래서 제품팀은 임시 대응과 근본 해결을 분리해 고객에게 안내해야 신뢰를 잃지 않습니다.

(1) 임시 대응 예시

• 대체 채널 제공: 이메일이 안 되면 코드 화면 표시, SMS 대체, 고객센터 인증
• 재전송 버튼 제공: 단, 남용 방지(쿨다운)와 실패 사유 안내 포함
• 도메인 화이트리스트 안내: 기업 고객에게 발신 도메인/ IP 정보를 제공

(2) 근본 해결 예시

• SPF/DKIM/DMARC 정비, From 도메인 정책 일관화
• ESP 이벤트 수집 강화(Delivered/Bounce/Deferred) 및 내부 대시보드 연결
• 큐/워커 처리량 확장, 재시도 정책 개선, 레이트리밋 전략 재설계

고객 입장에서는 “언제 되나요?”가 핵심입니다. 내부적으로는 원인을 추적하되, 외부적으로는 “지금 당장 할 수 있는 우회”를 제공하는 것이 제품팀의 역할입니다.

12) 현장에서 바로 쓸 수 있는 CS 안내 문구(요약형)

아래 문구는 지원팀이 바로 복붙해서 쓸 수 있는 형태로 정리한 예시입니다. 제품에 맞게 표현만 다듬어 사용하세요.

안내드립니다. 현재 “발송은 완료로 표시되지만 수신함에 보이지 않는” 경우는 메일 서비스의 스팸/프로모션 분류 또는 회사 보안 정책에 의해 격리되는 상황에서 발생할 수 있습니다. 우선 스팸함/프로모션 탭을 확인해주시고, 회사 메일을 사용 중이시라면 보안 격리함(Quarantine) 여부도 확인 부탁드립니다. 동일 문제가 반복되면 사용 중인 이메일 주소, 요청 시간, 확인하신 화면(PC/모바일) 정보를 알려주시면 빠르게 확인하겠습니다.

마무리: “Sent”만으로는 성공이 아닙니다

프로덕트 팀 관점에서 가장 중요한 메시지는 하나입니다. 사용자가 “받았다”고 느끼는 순간은 Sent가 아니라 도착과 표시입니다. 그래서 이 문제는 기술 이슈이면서 동시에 제품 이슈입니다.

사건을 구간으로 쪼개고, 고객 질문을 정교하게 만들고, 로그를 연결하고, 재현 세트를 구성하고, 임시 대응과 근본 해결을 분리해 커뮤니케이션하면 “가끔 안 와요” 같은 애매한 이슈도 빠르게 통제 가능한 문제로 바뀝니다.