앱 푸시 알림은 왜 늦거나 두 번 올까요? 서버와 앱에서 확인할 구조

앱 푸시 알림 개발은 발송 버튼을 만드는 일에서 끝나지 않습니다. 누구에게 어떤 사건을 알릴지, 어느 기기로 보낼지, 실패하면 어떻게 처리할지, 알림을 누르면 어떤 화면을 보여줄지까지 연결해야 합니다.

먼저 세 가지를 구분하면 원인을 좁히기 쉽습니다. 지연은 어느 구간에서 기다렸는지, 중복은 같은 발송 작업이나 화면 표시가 반복됐는지, 미수신은 발송 대상·권한·기기 등록정보가 유효한지부터 확인합니다.

이 글에서는 가상의 예약 서비스를 예로 들어 구조를 설명합니다. 특정 서비스의 장애 사례나 성능 측정 결과가 아닙니다.

Google의 FCM은 여러 플랫폼에 메시지를 전달하는 서비스이고, Apple 기기로 가는 원격 알림에는 APNs가 관여합니다. FCM을 사용해 iPhone으로 보내는 경우에도 APNs를 거칩니다. 따라서 FCM과 APNs를 모든 상황에서 서로 독립적인 두 배송 경로로만 이해하면 안 됩니다. Firebase의 알림 전달 구조에서 플랫폼별 경로를 확인할 수 있습니다.

설계할 때는 아래 다섯 역할을 나눠 보면 좋습니다. 다섯 개의 서버를 각각 만들어야 한다는 뜻은 아닙니다. 예약 발송이나 재시도가 필요하면 작업 목록을 보관하는 구조가 유용하고, 규모에 따라 기존 서버·예약 작업·관리형 큐를 조합할 수 있습니다. 서버와 관리자의 기본 역할은 앱·관리자·서버·데이터베이스 가이드에서 먼저 살펴볼 수 있습니다.

운영 화면에서는 최소한 발송 요청과 제공사 접수를 구분하고, 기기 표시와 알림 열기는 확인할 수 있는 환경에서만 별도 표시하는 편이 좋습니다. 기록을 수집하지 못한 상태는 “미수신”으로 단정하지 않고 “확인 불가”로 남깁니다. 알림을 눌렀다는 기록도 내용을 이해했거나 예약을 확인했다는 뜻은 아닙니다.

Firebase 역시 발송·수신·표시·열기를 구분합니다. 지표의 지원 범위는 플랫폼과 메시지 유형에 따라 다르고, 일부 보고는 늦게 집계되거나 별도 설정이 필요합니다. 모든 기기의 표시 여부가 자동으로 확인되는 것은 아닙니다. Firebase 알림 전달 지표 안내

고객 한 명이 휴대폰과 태블릿을 함께 사용할 수 있으므로 “회원 한 명에게 주소 하나”로만 저장하면 놓치는 기기가 생깁니다. 반대로 오래된 주소를 계속 남겨 두면 더 이상 사용하지 않는 설치본으로 발송을 시도하게 됩니다. 주소의 최신 상태와 갱신 시점을 관리하고 유효하지 않은 등록정보를 정리해야 합니다. Firebase 기기 등록정보 관리 지침

여러 기기에 각각 한 번 도착한 것과 같은 휴대폰에 두 번 표시된 것도 구분해야 합니다. 모든 로그인 기기로 보낼지 최근 사용 기기만 대상으로 할지는 서비스가 정할 정책입니다. 아래는 그 정책을 안전하게 적용하기 위한 설계 기준입니다.

이때는 단순히 “몇 초 안에 같은 문구면 버리기”보다 무엇에 대한 알림인지 구분하는 기준이 필요합니다. 예를 들어 예약번호·상태 변경 사건·수신 대상·알림 종류를 묶어 같은 작업이 동시에 두 번 만들어지지 않도록 하고, 재시도 이력은 원래 작업 아래에 연결하는 방식입니다. 고객의 정상적인 예약 변경 알림까지 막지 않도록 사건의 구분 기준도 정해야 합니다. 이는 중복을 줄이기 위한 설계이며 기기 표시까지 정확히 한 번을 보장한다는 뜻은 아닙니다.

서버에서는 한 번만 보냈는데 앱에서 두 번 표시될 수도 있습니다. 운영체제가 표시하는 알림과 앱이 직접 만드는 알림이 겹치지 않도록, 앱이 열려 있을 때와 백그라운드에 있을 때의 표시 담당을 정해야 합니다. 메시지에 알림과 데이터가 함께 있다는 이유만으로 무조건 중복이 발생하는 것은 아닙니다. 실제로 어떤 경로가 실행됐는지 확인해야 합니다. 플랫폼별 동작은 Android 수신 처리와 Apple 앱 수신 처리를 기준으로 검수합니다.

Android의 일반 우선순위 메시지는 절전 상태에서 지연될 수 있습니다. 높은 우선순위는 사용자에게 보여줄 시간 민감한 알림에 맞게 사용해야 하며, 모든 알림에 적용한다고 즉시 도착이 보장되지는 않습니다. Firebase Android 우선순위 안내

알림에는 늦어도 의미가 있는 시점도 정해야 합니다. 오후 2시 상담의 사전 안내가 상담이 끝난 뒤 도착한다면 정확하게 발송됐더라도 고객에게는 혼란을 줍니다. 제공사에 설정하는 유효 시간과 우리 서버에서 정한 발송 마감 시각을 함께 관리합니다. FCM의 TTL을 0으로 설정하면 즉시 전달할 수 없을 때 버리는 방식이지, 즉시 도착을 보장하는 설정은 아닙니다. Firebase 메시지 유효 시간 안내

취소된 예약도 확인해야 합니다. 13시 50분에 보낼 안내를 미리 예약했는데 고객이 13시 45분에 취소했다면, 발송 직전에 현재 예약 상태를 다시 조회해 작업을 중단하는 기준이 필요합니다. 이미 제공사에 넘긴 알림을 언제나 회수할 수 있다고 가정해서는 안 됩니다. 그래서 알림을 눌렀을 때도 서버의 최신 상태를 보여주는 설계가 중요합니다.

사용자에게 배너를 보여주는 알림과, 조용히 앱 데이터를 갱신하려는 백그라운드 알림도 구분해야 합니다. Apple의 백그라운드 알림은 전달이 보장되지 않고 지연·제한될 수 있어, 중요한 업무 처리를 반드시 실행시키는 수단으로 가정하면 안 됩니다. Apple 백그라운드 업데이트 안내

고객 문의를 받을 때는 다음 정보를 모으면 확인할 범위를 줄일 수 있습니다. 운영 기록에는 토큰 원문이나 상담 내용 같은 불필요한 개인정보를 노출하지 않고, 제한된 식별 정보로 해당 발송을 찾도록 구성하는 편이 좋습니다.

특히 요청 시간이 초과된 경우에는 “접수되지 않았다”와 “접수됐지만 응답을 받지 못했다”를 구분하기 어려울 수 있습니다. 발송 시도 번호, 제공사 응답과 작업의 원래 식별자를 남겨야 같은 건을 추적할 수 있습니다. 중요 알림은 재시도 횟수와 종료 시각, 운영자 확인으로 넘길 조건을 서비스에 맞게 정합니다.

운영 화면은 업무 사건과 알림 이력을 연결하는 방향으로 설계할 수 있습니다. 예를 들어 같은 예약의 확정·변경·취소 안내를 구분하고, 각 안내의 생성 시각과 시도 내역을 나란히 보는 방식입니다. 아래는 권장 점검 항목이며, 모든 서비스에 동일한 관리자 화면을 요구하는 것은 아닙니다.

이 원칙은 상태가 여러 번 바뀌는 서비스에서 특히 중요합니다. 다나르다 지역 배송 플랫폼 사례에서는 활동 지역에 따른 배송 요청 안내와 보내는 사람·배송 수행자의 역할, 단계별 배송 상태가 연결됩니다. 같은 메시지를 모든 회원에게 보내는 것보다 누가 어떤 상태를 알아야 하는지가 먼저 정해져야 하는 유형입니다. 이 글의 재시도·중복 방지 기준은 일반 설계 제안이며, 해당 사례에 모든 세부 처리가 구현됐다는 의미는 아닙니다.

예약 서비스라면 어떤 상태에서 누구에게 알릴지 예약 앱 운영 규칙 가이드를 함께 참고할 수 있습니다. 알림을 여는 것은 업무를 확인하는 입구이고, 실제 확정·변경·취소 여부는 앱 안의 현재 기록이 기준이 되어야 합니다.

좋은 알림 구조는 발송 횟수가 많은 구조가 아니라, 필요한 사람에게 필요한 시점의 정보를 전하고 문제가 생겼을 때 원인을 좁힐 수 있는 구조입니다. 현재 서비스의 예약·주문·상담 흐름을 기준으로 필요한 기록과 예외 처리를 정리해 보세요.

앱 알림·운영 흐름 30분 무료 상담