“관리자 화면에는 발송 성공인데 고객은 알림을 못 받았대요.” 모바일 서비스를 운영하면 자주 듣는 말입니다. 여기서 발송 성공이 뜻하는 것은 대개 앱 서버가 푸시 제공자에게 메시지를 넘겼다는 사실입니다. 기기에 도착했는지, 운영체제가 화면에 표시했는지, 사용자가 열어 봤는지는 서로 다른 사건입니다. 이 차이를 한 가지 ‘성공’ 상태로 뭉개면 지원팀도 원인을 찾기 어렵습니다.
푸시는 기록이 아니라 전달 시도다
알림 경로에는 앱의 발송 요청, 제공자 수락, 기기 전달, 운영체제 표시, 사용자의 열람이 있습니다. 기기 토큰 만료, 네트워크 부재, 알림 권한 거부, 집중 모드, 앱 상태, 우선순위 설정 등 여러 조건이 영향을 줍니다. 제공자가 수락했다는 응답만으로 화면 노출을 보장할 수 없습니다. 중요한 업무 알림을 푸시 메시지 하나에만 실어 보내면, 보이지 않았을 때 무엇을 놓쳤는지도 알기 어렵습니다.
따라서 알림의 원본은 서버에 별도 이벤트로 저장하고, 푸시는 “새 알림이 있으니 앱에서 확인하라”는 신호로 다루는 편이 안전합니다. 서버 이벤트에는 고유 ID, 사용자, 알림 종류, 생성 시각, 만료 기준, 연결되는 업무 객체를 넣습니다. 민감한 상세 내용은 잠금 화면에 노출될 수 있으므로 메시지 본문에 모두 싣지 않습니다.
상태를 정직하게 표현한다
관리 화면의 상태를 생성됨 → 발송 요청됨 → 제공자 수락됨 → 앱에서 확인됨처럼 구분해 보세요. 확인 이벤트가 없는 경우에는 ‘미확인’이지 ‘미전달’이라고 단정할 수 없습니다. 반대로 사용자에게 안 보였다고 해서 서버가 발송을 시도하지 않았다는 뜻도 아닙니다. 상태 이름을 정확하게 붙이는 것만으로 고객 응대의 오해가 크게 줄어듭니다.
중복 발송을 막으려면 알림 이벤트 ID를 기준으로 처리합니다. 네트워크 타임아웃 후 재시도할 때 새 알림을 만들지 말고 같은 사건의 전송 시도를 기록해야 합니다. 기기 토큰은 사용자와 일대일이 아닙니다. 한 사람이 여러 기기를 쓰거나 기기를 교체할 수 있으므로 대상·토큰 수명·로그아웃 시 정리를 함께 설계해야 합니다.
지원팀이 조사할 수 있는 기록도 준비합니다. 특정 알림의 이벤트 ID로 생성 시각, 발송 대상, 제공자 응답, 재시도 횟수, 앱 내 열람 시각을 연결해서 볼 수 있어야 합니다. 다만 기기에서 실제 배너를 보았는지는 앱이 확실히 알기 어려우므로 ‘노출 확인’이라는 이름을 남용하지 않습니다. 개인정보가 포함된 메시지 전문을 운영 로그에 오래 저장하지 않는 것도 중요합니다.
앱이 열리면 알림함을 다시 동기화한다
앱 시작과 화면 복귀 시 서버의 미확인 알림 목록을 가져와 기기 상태와 맞춥니다. 푸시를 놓쳤더라도 앱 안에서는 중요한 사건을 볼 수 있습니다. 읽음 상태는 가능하면 서버를 기준으로 두고, 여러 기기에서 같은 알림을 열었을 때 일관되게 반영합니다. 알림을 눌렀을 때 해당 업무 화면이 이미 이동·삭제되었으면 오류 대신 현재 상태를 안내해야 합니다.
알림 정책도 중요합니다. 즉시 행동이 필요한 사고·승인 요청은 푸시와 인앱 알림을 함께 쓰되, 기한이 지나면 과거 푸시가 뒤늦게 의미 없는 행동을 유도하지 않도록 만료를 적용합니다. 단순 요약이나 홍보성 알림에는 사용자의 수신 선택과 조용한 시간을 존중합니다. 푸시가 반복해서 실패한다고 무조건 같은 내용을 여러 번 보내는 것은 경험을 악화시킬 수 있습니다.
운영 체크리스트
① 알림 원본 이벤트가 서버에 저장되는가 ② 제공자 응답과 사용자 확인을 다른 상태로 표시하는가 ③ 기기 토큰 만료·로그아웃을 처리하는가 ④ 앱 재진입 시 미확인 목록을 동기화하는가 ⑤ 재시도와 중복 표시를 막는 ID가 있는가 ⑥ 알림이 오래되어 업무 상태가 바뀌었을 때 안전한 화면을 보여주는가. 이 여섯 항목을 기기·네트워크 조건별로 시험해 보면 “보냈는데 못 봤다”는 문제를 추적 가능한 운영 문제로 바꿀 수 있습니다.
