도착한다는 전제를 조회로 확인했다

알림을 보내는 기능의 로그에는 전부 성공으로 남는데 못 받는다는 문의가 있었다. 발송 코드는 호출이 예외를 안 던지면 성공으로 기록하고 있었다.

Open Table of contents

호출 성공과 발송 성공

호출이 예외 없이 끝났다는 것과 그 알림이 실제로 발송됐다는 것은 다른 사실이다. 로그에는 앞의 것만 남고 있었으므로 뒤의 것은 어디에도 기록되지 않았다.

발송 건수라는 숫자 하나만 있었고 실제로 받은 사람이 몇인지는 알 수 없었다. 성공이라는 말이 무엇의 성공인지가 정의돼 있지 않은 상태였다.

호출의 반환값을 열어 보니 성공과 실패 건수와 항목별 결과가 담겨 있었다. 전체의 상당 부분이 실패로 표시돼 있었는데 응답을 안 봐서 몰랐다.

응답을 버리는 코드는 실패를 성공으로 기록하고 그 기록은 아무도 의심하지 않는다. 응답을 파싱해 실패 건수와 사유를 함께 남기게 고쳤다.

사유를 보니 앱을 지운 사용자의 토큰이 대부분이었고 형식이 잘못된 것과 다른 앱의 토큰이 뒤를 이었다. 앞의 두 종류는 재시도해도 계속 실패하는 종류였다.

그런 사유가 오면 해당 토큰을 비활성으로 바꿔 다음부터 안 보내게 했다. 며칠 만에 실패 건수가 한 자릿수 비율로 내려갔다.

발송 성공도 도착을 뜻하지 않아서 기기가 꺼져 있으면 나중에 도착한다. 앱이 수신을 알려 주게 해서 발송과 도착과 열람을 각각 세게 했다.

도착이 발송보다 적은 것은 정상이고 그 차이가 기기 사정을 뜻한다. 어디까지가 우리 책임이고 어디부터가 기기 사정인지가 이 세 숫자로 갈렸다.

같은 방식으로 메일과 문자도 보니 각각 단계가 있었고 메일은 반송을 안 보고 있었다. 없는 주소로 계속 보내면 발송 평판이 나빠져 정상 주소에도 안 가게 된다.

도착 비율을 매일 보게 하니 갑자기 떨어진 날을 잡을 수 있었다. 한 번은 외부 알림 서비스 쪽 장애였고 우리가 먼저 알고 문의하니 그쪽도 인지하고 있었다.