iOS 및 Android 푸시 알림: APNs와 FCM 비교

비교 대상과 그 이유

APNs(Apple Push Notification service)와 FCM(Firebase Cloud Messaging)은 메시지를 서버에서 휴대폰으로 옮기는 전달 파이프입니다. 이들은 메시지를 앱이 어떻게 처리할지 결정하지는 않지만, 메시지가 도착하는지, 얼마나 빨리 도착하는지, 그리고 어떤 형태여야 하는지에 큰 영향을 줍니다.

사람들이 “Android에서는 푸시가 되는데 iOS에서는 안 된다” 또는 반대의 상황을 말할 때, 대개 한 가지 버그 때문이 아닙니다. iOS와 Android는 백그라운드 작업, 절전 정책, 권한, 메시지 우선순위를 다르게 처리합니다. 동일한 메시지가 지연되거나, 더 새로운 메시지로 교체되거나, 소리 없이 표시되거나, 앱이 깨어나 처리할 수 없으면 전혀 표시되지 않을 수 있습니다.

이 비교는 실무에서 가장 놀라움을 주는 부분들에 초점을 맞춥니다: 디바이스 토큰이 시간이 지나면서 어떻게 바뀌는지, 페이로드 크기 제한과 구조, 현실적으로 기대할 수 있는 전달 방식, 그리고 알림이 사라지는 일반적인 원인들입니다.

마케팅 전략, 푸시 제공업체 UI 선택, 전체 분석 파이프라인 구축은 다루지 않습니다. 목표는 신뢰성 확보와 빠른 디버깅입니다.

몇 가지 용어:

• 토큰: APNs나 FCM이 발급하는 기기별 주소입니다.
• 토픽: 여러 기기가 구독하는 그룹 주소(주로 FCM에서 사용).
• 채널: 사운드, 중요도, 동작을 제어하는 Android 알림 카테고리.
• Collapse key(또는 collapse identifier): 대기 중인 이전 메시지를 새 메시지로 대체하는 방법.
• TTL(time to live): 메시지가 만료되기 전까지 대기할 수 있는 시간.

기본을 제대로 해두면 iOS와 Android에서 “간단한 푸시”가 다르게 동작할 때 많은 추측 시간을 절약할 수 있습니다.

APNs와 FCM의 높은 수준 동작

APNs와 FCM은 모두 서버와 사용자의 휴대폰 사이의 중개자입니다. 앱이 인터넷을 통해 기기에 직접 신뢰성 있게 푸시를 전달할 수 없기 때문에, Apple(APNs) 또는 Google(FCM)에 그 일을 맡깁니다. 이들은 이미 기기와의 신뢰된 연결을 유지합니다.

전체 흐름은 비슷합니다: 앱이 토큰을 받고, 백엔드는 그 토큰을 사용해 푸시 서비스에 메시지를 보냅니다. 푸시 서비스가 해당 기기로 라우팅합니다.

APNs 간단 설명

iOS에서는 앱이 원격 알림을 등록하고 사용자에게 권한을 요청합니다(보통). Apple은 기기 토큰을 제공합니다. 백엔드(일반적으로 “provider”라 부름)는 그 토큰과 페이로드를 포함해 APNs로 푸시 요청을 보냅니다. APNs는 전달 가능 여부를 판단하고 기기로 포워딩합니다.

백엔드는 보통 토큰 기반 인증(서명 키)을 사용해 APNs에 인증합니다. 오래된 설정은 인증서 기반을 사용합니다.

FCM 간단 설명

Android에서는 앱 인스턴스가 FCM에 등록되고 등록 토큰을 받습니다. 백엔드는 FCM으로 메시지를 보내고, FCM은 이를 올바른 기기로 라우팅합니다. 앱 상태와 메시지 유형에 따라 FCM은 시스템이 자동으로 알림을 표시하거나 데이터를 앱에 전달해 앱이 처리하도록 할 수 있습니다.

백엔드는 서버 자격 증명(API 키 또는 서비스 계정)을 사용해 FCM에 인증합니다.

당신이 제어하는 것: 앱 코드, 권한 요청 시점, 토큰 저장, 백엔드 로직, 전송하는 페이로드. Apple과 Google이 제어하는 것: 전달 네트워크, 도달성, 스로틀링 규칙, 절전 정책 같은 마지막 단계 조건들입니다.

토큰 수명 주기: 발급, 갱신, 무효화

APNs와 FCM의 가장 큰 일상적 차이는 토큰이 ‘한 번 설정하면 영원히 고정’이 아니라는 점입니다. 토큰을 언제든지 변경될 수 있는 주소로 취급하세요.

iOS에서 APNs 기기 토큰은 기기, 앱, Apple 개발 설정에 묶여 있습니다. 앱 재설치, 기기 복원, 특정 OS 업데이트, 개발 중 push 환경(sandbox vs production) 전환 뒤에 바뀔 수 있습니다.

Android에서는 FCM 등록 토큰이 앱 복원, 사용자가 앱 데이터를 지움, Google이 토큰을 회전할 때, 또는 앱 재설치 후에 새로고침될 수 있습니다. 앱은 새 토큰 이벤트를 기대하고, 새 토큰을 즉시 서버에 보내야 합니다.

간단 규칙: 토큰은 항상 업서트(upsert)하고 절대 ‘삽입하고 잊지 마세요’. 토큰을 저장할 때 중복이나 잘못된 대상이 생기지 않도록 다음 정보를 함께 보관하세요:

• 사용자 또는 계정 ID(해당되는 경우)
• 앱 번들/패키지와 환경
• 플랫폼(iOS/Android)
• 토큰 값과 마지막 본 시각
• 옵트인 상태(권한 허용/거부)

삭제도 중요합니다. 토큰이 죽었다는 사실은 보통 ‘언인스톨’ 신호가 아니라 전달 오류로 알게 됩니다. APNs가 Unregistered(종종 410 상태 코드) 같은 오류를 반환하거나 FCM이 NotRegistered/Unregistered를 반환하면 그 토큰을 즉시 제거해 무한 재시도를 멈추세요.

사소한 실수로 개인정보가 유출될 수 있습니다: 고객이 로그아웃하고 다른 사용자가 같은 전화에 로그인했을 때 토큰을 지우거나 재매핑하지 않으면, 서버는 잘 작동하는 토큰으로 잘못된 사람에게 알림을 보낼 수 있습니다.

페이로드 제약과 메시지 구조 차이

실무에서 가장 큰 차이는 메시지에 얼마나 많은 데이터를 넣을 수 있는지와 도착했을 때 기기가 그것을 어떻게 처리하는지입니다.

대부분 팀은 아래 소수 필드에 의존합니다:

• 제목과 본문 텍스트
• 배지 카운트(iOS)
• 사운드(기본 또는 커스텀)
• 커스텀 키-값 데이터(예: order_id, status)

크기 제한: 푸시는 작게 유지하세요

두 서비스 모두 페이로드 크기 제한이 있고, 제한에는 커스텀 데이터가 포함됩니다. 한도에 도달하면 전달이 실패하거나 메시지가 기대처럼 동작하지 않을 수 있습니다.

신뢰할 수 있는 패턴은 짧은 알림과 ID만 보내고, 세부 정보는 백엔드에서 가져오게 하는 것입니다.

예: 주문 요약 전체를 보내는 대신 { "type": "order_update", "order_id": "123" }만 보내고 앱이 API를 호출해 최신 상태를 불러오게 하세요.

데이터 전용 vs 알림 동작

Android에서는 “notification” 페이로드가 있으면 앱이 백그라운드에 있을 때 시스템이 기본적으로 표시하는 경향이 있습니다. 데이터 전용 메시지는 앱 코드로 전달되지만 백그라운드 제한과 배터리 설정 때문에 지연되거나 차단될 수 있습니다.

iOS에서는 제목/본문 알림은 직관적이지만 백그라운드 업데이트는 더 엄격합니다. 백그라운드 푸시는 코드가 즉시 실행된다는 보장이 아니므로 새로 고침의 힌트로 간주하세요.

신뢰성이 필요하면 페이로드를 최소화하고 안정적인 식별자를 포함하며, 앱이 열리거나 재개될 때 상태를 재동기화하도록 설계하세요.

전달 기대치와 알림을 막는 요인들

APNs와 FCM 모두 전달은 최선의 노력을 기울입니다. 공급자는 메시지를 전달하려고 시도하지만, 기기가 그것을 표시할 것이라는 보장은 없습니다.

도달성(reachability)이 첫 번째 제한입니다. 메시지를 TTL이나 만료 시간과 함께 보냅니다. 기기가 그 윈도우 이후에 온라인이 되면 푸시는 폐기됩니다. TTL이 매우 길면 사용자가 오래된 경고를 나중에 보게 되어 버그처럼 보일 수 있습니다.

우선순위는 타이밍에 영향을 주지만 공짜 업그레이드가 아닙니다. 높은 우선순위는 특히 기기가 절전 상태일 때 민감한 메시지가 더 빨리 도착하도록 도울 수 있습니다. 과도하게 사용하면 스로틀링, 배터리 소모 증가, 또는 OS가 앱을 ‘시끄럽다’고 판단해 제재할 수 있습니다.

두 시스템 모두 collapsing을 지원해 새 메시지가 이전 것을 대체하게 할 수 있습니다. APNs는 collapse identifier를 사용하고, FCM은 collapse key를 사용합니다. order_status 같은 키로 collapse하면 사용자는 모든 단계를 보는 대신 최신 상태만 보게 될 수 있습니다.

공급자가 성공적으로 전달했더라도 전화기가 사용자가 보지 못하게 차단할 수 있습니다:

• 방해 금지(Do Not Disturb)나 집중 모드가 알림을 무음 처리하거나 숨길 수 있음
• 앱 알림 설정이 꺼져 있거나 조용한 전달로 설정되어 있을 수 있음
• Android 알림 채널이 특정 카테고리에서 꺼져 있을 수 있음
• 백그라운드 제한이나 배터리 세이버가 전달을 지연시킬 수 있음
• 앱이 유사한 알림을 많이 게시하면 OS가 반복을 억제할 수 있음

푸시는 신뢰할 수 없는 전송 수단으로 간주하세요: 중요한 상태는 백엔드에 보관하고, 알림이 전혀 표시되지 않더라도 앱이 열릴 때 현재 상태를 새로 고치도록 하세요.

권한과 기기 설정이 전달에 미치는 영향

많은 “전달 문제”는 실제로 권한과 설정 문제입니다.

iOS에서는 처음 권한 프롬프트가 중요합니다. 사용자가 “허용 안 함”을 누르면 설정을 변경할 때까지 알림이 표시되지 않습니다. 허용 후에도 잠금 화면, 알림 센터, 배너, 사운드, 배지 등을 개별적으로 비활성화할 수 있습니다. 집중 모드와 예약 요약도 알림을 숨기거나 지연시킬 수 있습니다.

Android에서는 OS 버전에 따라 요구 사항이 다릅니다. 최신 버전에서는 런타임 알림 권한이 필요하므로 앱 업데이트 후 사용자가 다시 승인하기 전까지 알림이 갑자기 보이지 않을 수 있습니다. 표시 여부는 알림 채널에도 좌우됩니다. 채널이 음소거되었거나 낮은 중요도로 설정되어 있으면 푸시는 도착하지만 방해하지 않을 수 있습니다.

백그라운드 제한도 기대를 깨뜨릴 수 있습니다. iOS의 저전력 모드와 Android의 배터리 최적화는 백그라운드 작업을 지연시키거나 데이터 수신을 차단하고, 데이터 전용 메시지 처리를 방해할 수 있습니다.

무슨 일이 일어나는지 확인하려면 서버가 보낸 것만 기록하지 말고 기기가 실제로 본 것을 기록하세요:

• 앱 내 로그: “권한 허용”, “토큰 등록됨”, “알림 수신”, “알림 표시됨” 등
• OS 상태: 알림 설정(활성/음소거/채널 중요도), 배터리 모드
• 푸시 콜백: 앱이 포그라운드/백그라운드에서 메시지를 수신했는지

백엔드가 노코드 도구로 되어 있더라도 클라이언트 측 로깅은 “메시지를 못 받았다”와 “받았지만 억제되었다”를 구분해줍니다.

단계별: 누락된 알림을 디버그하는 방법

푸시가 누락되면 체인처럼 생각하세요: 토큰 → 공급자 → 페이로드 → 앱 동작. 증상은 iOS와 Android에서 비슷하게 보일 수 있으니 동일한 점들을 순서대로 확인하세요.

• 현재 토큰으로 전송 중인지 확인하세요. 서버에 저장된 토큰과 앱이 최근에 보고한 토큰을 비교하세요. 각 토큰을 마지막에 받은 시각을 기록하세요.
• 전송 전에 페이로드를 검증하세요. 플랫폼 한도 이내인지, 필수 필드를 포함했는지, 잘못된 JSON은 아닌지 확인하세요. 데이터 전용 메시지를 보낸다면 앱이 이를 처리하도록 빌드되어 있는지 확인하세요.
• 공급자 자격증명과 환경을 확인하세요. APNs는 키/인증서, 팀, 번들 ID, 그리고 개발용(sandbox)과 운영용(production) 대상이 맞는지 확인하세요. FCM은 올바른 프로젝트 자격증명을 사용 중인지 확인하세요.

그다음 메시지 내용인지 기기/앱 동작인지 좁혀가세요:

• 최소한의 테스트 알림을 보내세요. 아주 작은 제목/본문 페이로드로 전송 경로가 작동하는지 확인하세요.
• 앱 측 핸들러와 포그라운드 동작을 검증하세요. 많은 ‘누락’된 알림이 실제로 수신은 되었지만 표시되지 않습니다. 일부 앱은 포그라운드일 때 배너를 숨기도록 설계되어 있기도 합니다.
• 한 번에 하나의 변수만 바꿔보세요. 다른 기기, 다른 OS 버전, Wi‑Fi 대 셀룰러, 다른 사용자 계정을 시도하세요. 하나의 계정만 실패하면 오래된 토큰이나 서버 측 타깃팅 문제일 가능성이 높습니다.

실용적 패턴: iOS 사용자가 누락을 보고하고 Android는 문제가 없다면 iOS에 최소 알림을 먼저 보내세요. 작동하면 페이로드 구조와 앱 처리를 집중적으로 살피고, 작동하지 않으면 토큰과 APNs 자격증명/환경을 점검하세요.

무음 실패를 유발하는 흔한 실수

대부분의 푸시 문제는 장애가 아니라 앱이 기대하는 것과 APNs/FCM이 허용하는 것, 또는 기기가 허용하는 것 사이의 작은 불일치에서 옵니다.

가장 흔한 문제는 더 이상 유효하지 않은 토큰으로 보내는 것입니다. 토큰은 재설치, 복원, 새로고침 후 바뀔 수 있습니다. 서버가 오래된 값을 계속 사용하면 푸시는 도달하지 않습니다.

또 다른 문제는 푸시 전달을 보장된 것으로 여기는 것입니다. 최선의 노력 전달이므로 기기가 오프라인이거나 절전 규칙이 적용되면 메시지가 늦거나 누락되는 것이 정상입니다. 중요한 이벤트(주문 업데이트, 보안 알림 등)는 앱 내 폴백(앱 열기 시 최신 상태 가져오기)을 준비해야 합니다.

누락 원인 요약:

• 재설치/새로고침 후에도 남아 있는 오래된 iOS 또는 Android 토큰
• 푸시 페이로드 한도 초과(커스텀 데이터가 너무 많거나 큰 이미지 등)
• 백그라운드 전달에 의존했다가 OS의 백그라운드 제한으로 인해 스로틀링된 경우
• iOS 환경 개발/운영 혼동(sandbox vs production)으로 토큰과 APNs 엔드포인트 불일치
• 사용자 옵트아웃 무시, 집중 모드/방해 금지, 비활성화된 알림 채널(Android), 앱 권한 미허용

예: 리테일 앱이 ‘주문 발송’ 알림에 추적 이력을 큰 JSON으로 모두 넣어 보냈습니다. 전송 호출은 성공처럼 보였지만 페이로드가 거부되거나 잘려 사용자에게 아무것도 보이지 않았습니다. 푸시는 작게 두고 세부 정보는 API로 가져가세요.

공급자 탓하기 전에 빠르게 확인할 체크리스트

공급자가 문제라고 가정하기 전에 다음 기본 점검을 하세요:

• 토큰이 사용자와 기기에 맞는지 확인하세요. 존재하고 최근에 업데이트되었으며 올바른 세션에 매핑되어 있어야 합니다.
• 공급자 자격증명이 현재 유효한지 확인하세요. APNs 키/인증서와 FCM 자격증명이 올바른 앱/프로젝트와 일치하는지 확인하세요.
• 페이로드 형태와 크기를 검증하세요. 한도 내인지, 올바른 필드를 사용했는지 확인하세요.
• TTL, 우선순위, collapse를 의도적으로 설정하세요. 짧은 TTL은 기기가 온라인이 될 때까지 만료될 수 있고, 낮은 우선순위는 전달을 지연시킬 수 있으며, collapse는 이전 메시지를 대체할 수 있습니다.
• ‘서버가 수락’과 ‘디바이스가 표시’는 분리하세요. 서버 로그(요청/응답/메시지 ID)와 클라이언트 로그(사용된 토큰, 핸들러 호출)를 비교하세요.

그다음 빠른 기기 점검: 앱 알림 허용 여부, 올바른 채널/카테고리(Android), 집중 모드/방해 금지, 백그라운드 제한 여부를 확인하세요. Android 채널 관련 문제가 자주 발생합니다.

예시: 누락된 주문 업데이트 알림 진단하기

지원 담당자가 주문 #1842에 대해 “주문 업데이트 전송”을 눌렀습니다. 백엔드 로그에는 “notification sent”가 기록되어 있지만 고객은 iPhone이나 Android 폰에서 아무것도 보지 못합니다.

백엔드부터 시작하세요. 대부분의 누락 알림은 푸시 서비스에서 받아들이지 않았거나, 받아들였지만 기기가 표시할 수 없어서 폐기된 경우입니다.

먼저 백엔드 확인 사항

하나의 추적 가능한 전송 시도가 있는지 확인하세요(한 주문 업데이트에 한 번의 푸시 요청). 그런 다음 다음을 검증하세요:

• 사용된 토큰이 그 사용자·기기용으로 저장된 최신 토큰인지
• 푸시 공급자 응답이 성공인지, 오류 코드를 저장했는지
• 페이로드가 플랫폼 규칙(크기 제한, 필수 필드, 유효한 JSON)에 맞는지
• 인증이 유효한지(APNs 키/인증서와 팀/번들 ID, 또는 FCM 자격증명)
• 올바른 iOS 환경(sandbox vs production)을 타깃팅했는지

로그에 “unregistered/invalid token” 같은 거부가 나오면 토큰 수명 주기 문제입니다. 공급자가 메시지를 수락했지만 아무 것도 도착하지 않으면 페이로드 유형과 OS 동작에 초점을 맞추세요.

기기에서 확인할 사항

이제 전화기가 경고를 표시할 수 있는 상태인지 검증하세요:

• 앱에 대한 알림이 활성화되어 있는가(잠금 화면/배너 허용 등)
• 집중 모드/방해 금지/알림 요약이 숨기고 있지 않은가
• 배터리 세이버 모드가 백그라운드 작업을 제한하고 있지 않은가(특히 Android)
• 메시지 유형에 따라 앱 상태가 맞는가(포그라운드 처리로 알림이 소거될 수 있음)

흔한 결과: 토큰은 정상인데 메시지가 data-only(또는 iOS에서 백그라운드 처리 설정 누락)라서 OS가 알림을 표시하지 않는 경우입니다. 해결책은 표시형 알림과 백그라운드 업데이트 중 원하는 동작에 맞게 올바른 페이로드를 보내고, 토큰 업데이트와 공급자 응답을 깨끗하게 로그로 남기는 것입니다.

다음 단계: 제품에서 푸시 신뢰성 개선하기

푸시 알림은 핵심 기능이 될 때까지는 단순해 보입니다. 신뢰성은 당신이 제어할 수 있는 부분에서 옵니다: 토큰 위생, 페이로드 규율, 그리고 폴백 경로.

누락을 대비하세요. 푸시는 ‘지금 보라’는 순간에는 좋지만 중요한 이벤트의 유일한 전달 수단이 되어선 안 됩니다. 인앱 인박스를 만들어 사용자가 나중에 따라잡을 수 있게 하고, 비밀번호 재설정이나 결제 문제 같은 고가치 행동은 이메일이나 SMS로 보완하세요.

페이로드를 가볍게 유지하세요. 푸시 페이로드를 전체 메시지가 아니라 프롬프트로 취급하세요. 이벤트 타입과 ID를 보내고, 앱이 열리거나 적절한 백그라운드 업데이트를 받을 때 당신의 백엔드 API에서 세부 정보를 가져오게 하세요.

팀을 위한 짧은 런북을 작성하세요: 옵트인 상태, 토큰 신선도, 공급자 응답 코드, 페이로드 크기/형태, 환경/자격증명 항목을 포함하면 디버깅이 일관되게 진행됩니다.

AppMaster를 사용해 빌드하는 경우, 토큰 저장, 감사 로그, 푸시 트리거 비즈니스 로직을 하나의 백엔드에 모아두면 편리합니다. 그렇게 하더라도 네이티브 iOS와 Android 앱이 APNs와 FCM을 올바르게 처리하도록 구현해야 합니다.