개요
이전에 React Native를 이용해 크로스플랫폼으로 어플을 제작한 경험이 있는데, 이 때는 FCM(Firebase Cloud Messaging) 서비스를 통해 원격 푸시 알림을 구현했었다. 누군가가 나를 초대했을 때 어플에 접속 중이 아니더라도 알림을 보여주어, 유저 리텐션 높이기에 긍정적인 영향을 주었던 기억이 난다.
최근 회사에서는 네이티브 개발을 하면서 똑같이 원격 푸시 알림을 구현하는 업무를 맡게 되었는데, 네이티브의 경우 내가 알던 방식과 구현 방식이 살짝 달랐다.
네이티브로 개발 시에는 어떤 방식으로 원격 푸시 알림을 구현할 수 있는지에 대해 조사해 보았다.
푸시 알림의 종류
원격 푸시 알림에 대해 알아보기에 앞서, 먼저 푸시 알림의 종류에는 어떤 것들이 있는지부터 알아보자.
푸시 알림은 ‘트리거하는 방식’에 따라 크게 두 종류로 나뉜다.

로컬 푸시 알림
로컬 알림은 디바이스 내부에서 직접 트리거된다. 서버와 통신 없이, 앱 내부 로직으로 알림을 예약하거나 즉시 표시할 수 있다.
가령 알림 및 리마인더 등은 별도의 서버 로직이 필요하지 않다. 이러한 요소들은 어플 내부에서 특정 조건에 맞추어 트리거되며, 이를 위해 시간 기반, 위치 기반, 혹은 사용자 행동 기반 등의 트리거를 설정할 수 있다.
원격 푸시 알림
원격 푸시 알림은 서버에서 디바이스로 메세지 데이터를 전달한다.
네트워크를 통해 외부 서버가 알림을 전송하며, 디바이스는 이를 수신해 사용자에게 표시한다.
가령 메신저의 새 메시지, 쇼핑몰의 할인 알림, 은행의 거래 알림 등은 서버 측에서 이벤트를 감지하고, 그에 따라 원하는 시점에 자유롭게 알림을 보낼 수 있다.
이처럼 원격 알림은 서버에서 보다 트리거 시점을 유연하게 관리 가능하다는 점이 특징이다.
정리하자면, 로컬 푸시 알림은 앱 안에서 미리 정해둔 조건(예: 시간, 위치 등)에 따라 기기 스스로 알림을 띄우는 방식이다. 반면 원격 푸시 알림은 서버에서 알림 내용을 만들어 인터넷을 통해 사용자 기기로 보내는 방식이며, 이를 위해 기기 식별용 토큰, 인증 정보, 알림 내용 등을 준비해야 한다.
원격 푸시 알림을 구현하는 방식에는 어떤 것들이 있는지 알아보자.
원격 푸시 알림 구현 방식
iOS에서 원격 푸시 알림을 구현하는 방식은 크게 두 가지가 있다.
첫 번째는 FCM(Firebase Cloud Messaging) 서비스를 이용해 간접적으로 메시지를 전송하는 방법, 두 번째는 APNs(Apple Push Notification service)를 직접 통해 직접적으로 메시지를 전송하는 방법이다.
왜 간접적이고, 왜 직접적인지는 아래에 보다 상세하게 설명하겠다. 각 방식의 특징과 차이점에 대해 아래에서 자세히 알아보자.
[Firebase Cloud Messaging(FCM)]

FCM(Firebase Cloud Messaging)은 Google에서 제공하는 무료 푸시 알림 서비스로, iOS, Android, 웹 등 여러 플랫폼에서 통합적으로 푸시 알림을 관리할 수 있게 해준다. iOS에서도 APNs를 내부적으로 사용하지만, 개발자가 직접 APNs를 다루지 않아도 되도록 중간 계층 역할을 해준다.
특징
- Google에서 제작한, 원격 Notification을 위한 무료 서드파티 서비스
- iOS, Android 등 Cross-Platform을 지원
- FCM 토큰을 기반으로 개별 사용자를 식별 및 메세지 전송
장점
- 간편함: Firebase 측 서버 인프라를 사용하기에, 구현해야 하는 서버 측 코드가 매우 간단한 편. 복잡한 인증 처리, 페이로드(메세지 데이터) 구성 등을 Firebase가 대신 처리해 줌
- 높은 안정성: FCM은 Google의 인프라를 기반으로 작동하기에, 앱과 별개로 독립 실행되어 보다 안정적으로 전송됨
- 부가 기능 존재: 예약 전송, A/B 테스트 등 기존 Firebase 시스템과 연결된 기능들을 별도 구축 없이 바로 사용 가능
단점
- 플랫폼 특화 기능(iOS만의 특정 알림 설정 등)을 직접 다루기 어렵고, 세세한 설정이 제한될 수 있음
- 앱 볼륨 증가 : 다양한 기능을 포함한 Firebase SDK를 포함하면서, 앱 크기가 상대적으로 무거워질 수 있음
[APNs]

APNs(Apple Push Notification service)는 Apple에서 제공하는 공식 푸시 알림 서비스로, iOS 앱에서 가장 직접적이고 네이티브한 방식으로 알림을 전송할 수 있다. Firebase 없이도 자체 서버를 통해 APNs에 연결하면, iOS의 알림 기능을 세밀하게 제어할 수 있다.
특징
- Apple이 직접 운영하는 iOS 전용 푸시 시스템
- p8 인증 키(또는 p12 인증서) 기반으로 보안 연결 수행
- 디바이스 토큰을 기반으로 개별 사용자를 식별 및 메세지 전송
- Android, Web 등 타 플랫폼은 지원하지 않음(iOS only)
장점
- Apple 공식 지원 서비스 : FCM과 달리 중간 계층 없이, iOS에 최적화된 알림 기능 직접 활용 가능
- 제한 없는 도메인 사용: FCM의 구글과 같이 특정 도메인 기반의 인프라에 의존하지 않고, 자체 도메인을 기반으로 유연하게 구성이 가능함
- 앱 볼륨 증가 X : APNs는 iOS 기본 내장 서비스이므로, 추가 SDK 설치 없이도 구현 가능
단점
- 구현 복잡도 높음 : 자체 서버 구축, 인증 키 추가, 디바이스 토큰 관리 등을 직접 해야 함
- FCM처럼 전송 성공률, 알림 수신 여부 등 알림 상태에 대한 통계나 모니터링 기능이 제공되지 않음
APNs 작동 방식

실제 APNs를 통한 Notification 전달 방식은 아래와 같다.
- Provider 서버에서, 실제 유저의 디바이스 토큰을 대상으로 request 생성
- 해당 request를 APNs로 전송
- APNs는 디바이스로 데이터 전송, 디바이스 OS에서 생성된 데이터를 앱으로 전달
- 앱 내의 Notification Handler가 해당 이벤트 처리
이 중 APNs 서비스를 이용하는 개발자의 경우, Provider 서버와 Notification Handler를 구성한다. 적절한 인증 방식(p8 키 기반의 JWT 생성 또는 p12 인증서 등록)을 통해 APNs와 보안 연결을 설정하고, 정해진 형식의 JSON 페이로드를 포함한 request를 전송함으로써 푸시 알림을 전달할 수 있다. 또한 앱 내부에서는 알림 수신 시 실행할 로직을 Notification Handler를 통해 정의해야 한다.
FCM vs APNs : 어떤 푸시 알림 서비스를 사용해야 할까
지금까지 FCM과 APNs에 대해 표로 짧게 정리하면 아래와 같다.
선택 기준
|
FCM
|
APNs 직접 구현
|
개발 편의성
|
✅ 매우 쉬움
|
❌ 상대적으로 복잡
|
크로스 플랫폼
|
✅ Android + iOS 지원
|
❌ iOS 전용
|
세밀한 알림 제어
|
❌ 한계 있음
|
✅ iOS 전용 기능까지 제어 가능
|
앱 용량 최적화
|
❌ SDK 포함 → 증가 가능
|
✅ 추가 SDK 불필요
|
서버 유연성
|
❌ Google 인프라 의존
|
✅ 도메인·서버 구조 자유
|
두 서비스는 장단점이 분명하게 존재한다. 그렇다면 어느 상황에 어떤 서비스를 채택해야 할까?
사실 해답은 간단한데, React Native 또는 Flutter를 통한 크로스플랫폼 개발 시에는 FCM을 네이티브 코드를 통해 각각의 플랫폼을 별도 개발한다면 APNs를 통한 푸시 알림 서비스 구현이 적합하다.
현재 프로젝트의 기술 스택, 인프라 상황 등을 모두 적절히 고려하여 적합한 푸시 알림 서비스를 이용하자!
'앱 개발 > iOS' 카테고리의 다른 글
[iOS/Swift] Closure 정리 : 기초 문법(1/2) (0) | 2025.04.01 |
---|---|
[iOS] 딥 링킹 환경에서 콘솔 출력하기 (0) | 2025.03.25 |
[iOS] 생애주기 및 AppDelegate, SceneDelegate의 역할 (2) | 2025.03.10 |
[iOS] XCode 단축키 VSCode처럼 설정하기 (1) | 2025.02.22 |