앱 푸시 알림 점검: 발송·수신·노출·클릭을 구분해야 하는 이유

1 발송부터 열기까지 완료 기준을 나눕니다

개발 범위에 “푸시 알림 구현”만 적으면 완료의 의미가 달라질 수 있습니다. 다음 다섯 단계를 기준으로 어느 결과를 확인할지 합의하세요.

1. 발송 요청: 서버가 대상과 내용을 정해 요청을 보냈는가
2. 서비스 접수: 알림 서비스가 요청을 수락했는가
3. 기기 전달: 메시지가 대상 기기에 도착했는가
4. 화면 표시: 알림이 기기의 화면이나 알림 센터에 표시됐는가
5. 열기: 사용자가 알림을 눌러 앱으로 들어왔는가

FCM이 메시지 식별자를 반환해도 기기에 전달됐다는 뜻은 아닙니다. 전달 요청을 수락한 단계입니다. Firebase 메시지 수명 안내를 기준으로 서버의 성공 응답을 해석하세요.

이 흐름은 사용자에게 보여 주는 알림의 점검 기준입니다. 화면 표시를 목적으로 하지 않는 데이터 메시지는 별도로 다뤄야 합니다. 화면 표시도 사용자가 내용을 읽었다는 증거는 아닙니다.

2 알림 권한과 표시 설정을 확인합니다

Android 13 이상에서는 일반적인 알림 표시에 런타임 권한이 필요합니다. 새 설치와 기존 기기의 업데이트는 권한 상태가 다를 수 있으므로 실제 테스트 기기에서 확인하세요. Android 알림 권한을 참고할 수 있습니다.

Android 8.0 이상에서는 알림 종류별 채널 설정도 확인합니다. 앱 전체 알림을 허용해도 특정 채널의 표시나 소리가 제한될 수 있습니다. 서버 발송 우선순위를 높였다는 설명만으로 기기의 채널 설정을 확인했다고 볼 수는 없습니다. Android 알림 채널에 동작 기준이 나와 있습니다.

iOS에서는 알림 허용 여부와 함께 배너, 소리, 배지 등 허용된 표시 방식을 확인합니다. 소리나 배너 없이 전달되는 잠정 승인(provisional authorization) 상태도 있어 “소리가 없었다”와 “수신하지 못했다”를 구분해야 합니다. Apple 알림 권한을 확인하세요.

운영 접수 화면에도 “안 왔음” 한 항목만 두기보다 알림 센터에도 없는지, 배너나 소리만 없는지 구분해 적게 하면 확인할 범위가 좁아집니다.

3 앱 상태와 메시지 종류를 구분합니다

FCM 알림 메시지는 앱을 보고 있는 상태에서 기본적으로 눈에 보이는 알림을 표시하지 않습니다. 앱의 표시 처리에 따라 결과가 달라지므로 앱 사용 중과 백그라운드 상태를 각각 검수해야 합니다. Firebase 앱 상태별 메시지 처리를 참고하세요.

iOS의 무음 백그라운드 알림은 화면 표시 없이 앱의 데이터를 갱신하기 위한 신호입니다. 일반적인 표시 알림과 용도가 다르며, 시스템이 전달을 지연하거나 제한할 수 있습니다. Apple 백그라운드 업데이트는 이 전달을 보장하지 않습니다.

키플은 검수 기록에 앱 사용 중, 백그라운드, 앱이 실행되지 않는 상태를 구분하고 마지막 상태에 이른 방법도 적도록 권합니다. 홈 화면으로 나간 것과 사용자가 강제로 종료한 것을 같은 조건으로 기록하지 않는 편이 좋습니다.

4 기기 등록 정보와 만료 시간을 관리합니다

서버의 알림 대상이 실제 앱 설치와 맞는지 확인합니다. 푸시 토큰 등 등록 정보가 바뀔 때 서버에도 반영되는지, 마지막 갱신 시각과 무효 응답을 관리하는지가 점검 대상입니다. 등록 정보는 영구 고정값으로 가정하지 않습니다.

FCM의 UNREGISTERED 응답은 대상 등록을 정리할 근거입니다. INVALID_ARGUMENT는 메시지 내용의 오류일 수도 있어 등록 정보만의 문제로 단정하면 안 됩니다. Firebase 등록 관리를 기준으로 처리하세요.

오프라인 기기의 메시지는 보관 기간이 지나면 폐기될 수 있습니다. Android의 TTL과 iOS의 만료 설정을 알림 용도에 맞게 정하세요. Firebase 메시지 수명 안내에 설명된 보관 기간은 전달 보장 시간이 아닙니다.

예를 들어 이미 종료된 예약의 알림이 늦게 도착했을 때 어떻게 처리할지도 정해야 합니다. 키플은 알림을 누른 뒤 서버에서 현재 상태를 다시 확인하고, 만료된 항목에는 그에 맞는 안내를 제공하도록 권합니다.

5 보고서의 집계 범위를 확인합니다

FCM 보고서의 수신 지표는 Android만 지원합니다. 노출 지표는 Android에서 앱이 백그라운드일 때 표시된 알림 메시지에 한정됩니다. 열기 지표도 백그라운드에서 받은 알림을 대상으로 합니다. 플랫폼과 메시지 종류가 다른 수치를 같은 분모로 비교하지 마세요.

일반 보고 통계는 최대 24시간, Android 집계 데이터 API는 최대 5일 지연될 수 있습니다. 분석 설정과 수집 동의, 표본 및 개인정보 보호 기준도 집계 범위에 영향을 줍니다. Firebase 전달 지표 안내를 확인한 뒤 수치를 해석하세요.

키플은 대시보드 추세와 개별 장애의 확인 기록을 함께 관리하도록 권합니다. 특정 사용자의 문의에는 테스트 식별자와 발생 시각을 연결하고, 관측하지 못한 단계는 실패로 단정하지 말고 “확인되지 않음”으로 남기세요.

6 실기기에서 계정 전환과 이동 경로를 검수합니다

다음 항목은 키플이 제안하는 인수 검수 기준입니다. 실제 Android 기기와 iPhone에서 테스트 계정으로 확인하고, 서비스가 지원하는 운영체제와 앱 버전을 기록합니다.

• 권한을 허용하거나 거부한 뒤 앱의 안내와 실제 표시가 일치하는지 확인합니다.
• 앱 사용 중, 백그라운드, 실행되지 않는 상태에서 정한 동작이 나오는지 확인합니다.
• 같은 기기에서 A 계정을 로그아웃하고 B 계정으로 바꾼 뒤 A 계정의 새 알림 대상 연결이 남지 않는지 확인합니다.
• 알림을 누르면 의도한 상세 화면으로 이동하고, 로그인이 필요하면 로그인 후 올바른 화면으로 이어지는지 확인합니다.
• 삭제되거나 만료된 항목의 알림, 네트워크 복구 뒤 늦게 도착한 알림을 안전하게 안내하는지 확인합니다.

계정 전환 검수에는 알림 내용과 목적 화면의 접근 권한도 포함합니다. 알림에 들어 있는 항목 번호만으로 다른 계정의 정보를 열 수 없어야 합니다.

검수 결과에는 성공 여부만 적지 말고 예상한 동작, 실제 결과, 확인 가능한 기록을 함께 남기세요. 권한이 거부된 조건의 합격 기준은 무조건 표시되는 것이 아니라, 합의한 안내와 처리 방식이 동작하는지입니다.

7 장애 접수와 개발 범위를 구체적으로 정합니다

운영자가 개발팀에 전달할 정보는 발생 시각과 시간대, 기기와 운영체제, 앱 버전, 당시 앱 상태, 알림 종류, 어느 단계까지 확인됐는지입니다. 테스트 식별자로 기록을 연결하고 비밀번호나 전체 푸시 토큰을 일반 문의에 붙이지 마세요.

외주 범위에는 발송 서버, 기기 등록 갱신, 권한 안내, 앱 상태별 처리, 알림을 누른 뒤 이동, 운영 기록과 실기기 검수의 담당자를 정합니다. “테스트 알림 한 번 성공”을 전체 기능의 인수 기준으로 삼지 않는 편이 좋습니다.

모든 점검 항목이 통과해도 모든 환경에서 즉시 전달된다는 보장은 아닙니다. 계약과 운영 기준에는 지원 조건, 지연을 확인하는 방법, 장애 접수 후 조사 범위를 적으세요.

기존 앱을 점검하려면 Flutter 앱 유지보수 안내에서 작업 범위를 확인할 수 있습니다. 처음 문의에는 실제 고객 정보 대신 재현 조건과 확인된 단계를 알려주시면 됩니다.