Apple과 Google은 푸시 알림에 무엇을 하고 있나

• 푸시 알림은 단순 전달 계층이 아니라 Apple과 Google이 파싱·순위화·요약·재작성하는 플랫폼 편집 채널로 바뀌고 있음
• APNs와 FCM은 배터리 절약을 위한 중앙 중개 구조로 출발했고, 모든 iPhone·Android 알림은 처음부터 플랫폼 서버를 거쳤음
• Android 채널, iOS Focus·Summary, Android 13 권한 전환은 발신자 제어권을 줄이고 사용자 주의를 플랫폼이 방어하는 구조로 만들었음
• 온디바이스 모델은 표시 계층에서 알림을 요약·그룹화·강등하지만, 발신자는 요약·Focus 억제·우선순위 하락 여부를 감지할 API가 거의 없음
• 실무적으로는 푸시를 휴면 사용자 깨우기와 시간 민감 거래성 알림에 제한하고, 세분화·개인화와 인앱 등 소유 표면으로 무게를 옮겨야 함

푸시 알림이 플랫폼 편집 채널로 바뀌는 흐름

• 푸시 알림은 이메일처럼 단순 전달 계층이 아니라 Apple과 Google이 중간에서 파싱·순위화·요약·재작성하는 채널로 이동 중
• Apple과 Google은 iPhone과 Android의 핵심 푸시 경로를 운영하며, 최근 5년 동안 기기 내 모델이 전달과 잠금 화면 사이에 들어와 알림을 요약·재정렬하고 일부 화면에서는 다시 씀
• 이메일에서는 Google, Yahoo, Microsoft, Apple 4개 사업자가 브랜드와 고객 사이의 능동적 중개자가 됐지만, 푸시는 Apple과 Google 2개 사업자가 같은 역할을 맡는 구조임

배터리 문제에서 시작된 푸시 아키텍처

• 푸시는 처음부터 배터리 문제 때문에 중앙 중개 구조로 설계됐음
• 2009년 WWDC에서 Scott Forstall은 설치된 모든 앱이 각자 원격 서버를 백그라운드 폴링하면 iPhone이 감당할 수 없다고 설명했고, Apple은 각 기기가 Apple과 하나의 지속 TLS 연결을 유지한 뒤 제3자가 그 연결로 알림을 전달하는 Apple Push Notification Service를 제안함
• APNs는 초기 2008년 9월 발표 이후 확장성 문제로 지연됐고, 2009년 6월 17일 iPhone OS 3와 함께 출시됨
• Google은 2010년 Cloud to Device Messaging, 2012년 Google Cloud Messaging, 2016년 Firebase Cloud Messaging으로 이어지는 경로를 택함
• iPhone으로 보내는 모든 알림은 Apple 서버를 지나고, Android로 보내는 모든 알림은 Google 서버를 지남
• 플랫폼은 항상 알림을 제한·삭제·기록·낮은 우선순위 처리·거부할 수 있었고, 달라진 점은 Apple과 Google이 예전만큼 자제하지 않는다는 데 있음

15년간 커진 플랫폼 개입

• 초기 소비자 푸시 시대에는 APNs와 Google 서비스들이 사용자가 설치한 앱에 알림을 전달했고, 플랫폼 수준 필터링은 제한적이었음
• 사용자 제어도 대체로 앱별 켜기/끄기 토글 하나에 가까웠음
• Android의 첫 중요한 기기 내 개입은 2017년 8월 Android 8 Oreo의 notification channels였음
  • Android 8 이전에는 개별 알림에 발신자가 정한 우선순위가 붙었지만, 이후에는 개발자가 채널 단위로 정의하고 사용자가 채널 단위로 제어하게 됨
  • 개발자는 앱당 다운로드, 메시지, 프로모션 같은 채널을 선언하고 각 채널에 IMPORTANCE_NONE부터 IMPORTANCE_HIGH까지 중요도를 부여함
  • 사용자는 채널별로 음소거, 중요도 낮추기, 배지 끄기, 완전 차단을 다른 채널에 영향 없이 설정할 수 있음
  • 개발자가 한 번 설정한 채널 중요도는 나중에 올릴 수 없고, Android 8을 대상으로 하는 앱은 채널을 선언하지 않으면 알림이 표시되지 않음
• Apple은 2021년 9월 iOS 15에서 Focus, Scheduled Summary, 4단계 interruption taxonomy를 도입함
  • 4단계는 passive, active, time-sensitive, critical이며, 실질적으로 개발자가 다룰 수 있는 수준은 time-sensitive였음
  • Apple은 time-sensitive를 마케팅에 쓰면 안 된다고 명시했고, 이 방침은 계속 유지됨
• Android는 2022년 8월 Android 13에서 POST_NOTIFICATIONS를 런타임 권한으로 바꿔, 암묵적 옵트인 대신 사용자의 명시적 허가를 요구함
  • Pushwoosh의 1,600만 기기 표본에서는 게임 앱이 옵트인 기반의 거의 3분의 1을 잃었고, 뉴스 앱은 19% 감소함
  • Batch의 2025 벤치마크는 10,000개 앱의 8,000억 건 이상 메시지를 바탕으로 Android 옵트인이 1년 만에 85%에서 67%로 떨어지고, 크로스 플랫폼 평균이 61%에 머물렀다고 제시함
• 각 단계는 발신자의 제어권을 줄였고, 수신자의 주의를 플랫폼이 방어해야 하는 희소 자원으로 다루는 방향으로 푸시 채널을 다시 만들었음
• 깨끗하고 피로도가 낮은 알림 표면은 플랫폼의 유지율과 생태계를 보호하고, 삭제를 줄이며, AI 기능을 보여주는 수단이 되므로 플랫폼 편집은 순수한 사용자 옹호만은 아님

이메일이 먼저 겪은 중개화

• 이메일은 푸시보다 앞서 중개화됐고, 푸시에서도 같은 흐름이 한 단계 늦게 병행됨
• 푸시는 이메일보다 더 불리한 채널임
  • 이메일에는 Postmaster Tools와 전달성 대시보드 같은 계측 수단이 있지만, 푸시는 거의 없음
  • 이메일은 받은편지함에 남아 사용자가 스크롤·검색·재방문할 수 있지만, 알림은 알림 센터에서 지워지고, 떨어지고, 요약되며, 안정적으로 보관되지 않음
• Gmail은 2013년 tabbed inbox로 합법적 메일을 Primary, Promotions, Social, Updates로 분류했고, Apple Mail은 2024년에 자체 분류를 추가함
• Mail Privacy Protection은 2021년 9월 iOS 15에 포함되어 Apple Mail이 사용자의 실제 열람 여부와 무관하게 Apple 제어 프록시를 통해 원격 콘텐츠를 미리 가져오도록 만들었음
  • 이 방식은 IP 주소를 가리고, 마케터들이 의존한 open pixel 메커니즘을 깨뜨림
  • Omeda는 Apple로 인한 오픈율이 6개월 동안 22.6%에서 40.5%로 올랐지만, 이는 독자 증가가 아니라 프리페치 때문이라고 관찰함
  • 기존 형태의 오픈율은 회복 불가능해졌고, 클릭률과 하위 전환이 참여 신호를 대신하게 됨
• Yahoo와 Google은 2024년 초부터 개인 받은편지함에 실질적인 볼륨을 보내는 발신자에게 SPF와 DKIM 인증, DMARC 정렬, 원클릭 구독 해지, 낮은 스팸 신고율 유지를 요구함
• 이메일은 개방·연합 프로토콜 위에서 동작하지만, 푸시 구독은 특정 기기의 특정 설치, 네이티브 앱 또는 iOS 16.4 이후 홈 화면 웹앱 안에 있는 권한으로 존재함
• 푸시는 APNs 또는 FCM 토큰에 묶이고, Apple이나 Google이 그 토큰을 임의로 무효화할 수 있으며, 발신자는 다른 곳으로 가져갈 수 있는 목록을 갖지 못함
• Web push는 App Store 다운로드 없이 보낼 수 있어 발신자 범위를 넓히지만, 같은 알림 트레이와 같은 기기 내 편집을 받으므로 편집자를 벗어나지는 못함
• 푸시에서도 발신자는 자신의 알림이 요약됐는지, Focus mode 뒤에 숨었는지, 기기 내 모델에 의해 낮은 우선순위가 됐는지, 조용한 폴더에 들어갔는지 알기 어려워짐

기기 내 편집자

• 이메일 편집은 주로 전송 중에 일어나지만, 푸시 편집은 표시 계층에서 일어남
• 알림을 표시할지, 요약할지, 낮은 우선순위로 둘지, 그룹화할지는 기기의 표시 계층에서 결정됨
• 핵심은 네트워크가 아니라 기기 내 모델이며, 그 가중치와 신호는 공개되지 않음
• Apple Intelligence는 30억 파라미터 기기 내 foundation language model과 Private Cloud Compute에서 이용 가능한 더 큰 Parallel-Track Mixture-of-Experts 서버 모델을 사용함
  • 2025년 7월 기술 보고서는 Apple silicon에 맞춘 KV-cache sharing과 2-bit quantization-aware training을 다룸
  • Apple Intelligence 기능은 기반 모델을 직접 쓰기보다 보통 수십 MB 크기의 작은 LoRA 스타일 어댑터를 운영체제가 동적으로 로드해 요약, 엔티티 추출, 문장 다듬기, 알림 우선순위화 같은 작업에 특화함
  • BBC가 요약이 잘못된 헤드라인을 생성한다고 항의한 뒤, Apple은 iOS 18.3에서 News and Entertainment 앱의 요약을 비활성화하고, AI 요약을 이탤릭체로 표시하며, 잠금 화면에서 앱별 끄기 스위치와 오류 가능성 경고를 추가함
• Google의 Gemini Nano는 Android 14에서 도입된 시스템 서비스 AICore 안에서 실행됨
  • AICore는 모델을 시스템 파티션에 두고, 권한 있는 앱들이 가중치를 공유하며, 각 추론 요청을 격리하고 입력·출력 데이터를 저장하지 않음
  • AICore는 Android Private Compute Core 원칙을 따르며, 제한된 package binding, 직접 인터넷 접근 차단, Google Play System Updates를 통한 모델 업데이트를 적용함
  • Gemini Nano는 기기의 NPU, GPU, CPU로 자동 라우팅되고, Low-Rank Adaptation을 통해 Pixel Recorder 요약, 알림 정리, smart reply 같은 기능을 기반 모델 재학습 없이 특화할 수 있음
• 알림별 편집 흐름은 앱이 페이로드를 만들고 APNs 또는 FCM에 제출한 뒤, 운영체제가 Focus modes, Do Not Disturb schedules, channel mutings, per-app blocks 같은 사용자 제어 규칙을 먼저 적용하는 식으로 진행됨
• 이후 알림은 플랫폼의 순위화와 표시 로직으로 들어가며, iOS의 Notification Summaries가 켜져 있으면 운영체제가 결합된 텍스트를 요약 어댑터가 붙은 기기 내 모델에 전달하고 원래 제목과 본문을 생성 문장으로 대체할 수 있음
• Priority Notifications가 켜져 있으면 iOS 18.4 이후 기본값은 꺼짐 상태에서 시스템이 학습된 앱별 순위화를 적용해 일부 알림을 고정하고 다른 알림을 낮출 수 있음
• Reduce Interruptions Focus가 활성화되면 모델은 각 알림이 사용자가 맞춤 설정한 중요도 임계값을 넘는지 평가함
• Microsoft Technology Licensing LLC의 US 11,340,963과 Google LLC의 US 11,609,806, US 8,707,201는 알림 재작성·전달 시점·우선순위화를 학습 모델로 다루는 방향이 iOS 18 논란보다 훨씬 전부터 존재했음을 보여줌

발신자가 제어할 수 있는 제한된 수단

• iOS의 UNNotificationServiceExtension은 앱 코드가 표시 전에 전달된 알림을 짧게 변경할 수 있게 하며, 페이로드 복호화, 이미지 가져오기, 텍스트 수정에 쓰일 수 있음
• UNNotificationContentExtension은 확장 뷰를 위한 맞춤 UI를 정의할 수 있게 함
• 두 확장 모두 플랫폼의 요약 또는 우선순위화 단계 이후에는 실행되지 않음
• apns-priority 헤더는 5와 10 중 하나를 제공하며, 5는 긴급하지 않은 알림을 전력 절약 시점에 전달하고, 10은 실제로 상호작용성이 있는 알림을 즉시 전달하는 용도임
• Android에서 개발자는 NotificationManager에 쓰고 채널 중요도를 선언하지만, 시스템 분류에서 빠져나갈 수는 없음
• NotificationListenerService는 OEM과 접근성 앱이 들어오는 알림을 읽을 때 쓰는 시스템 수준 API임
• 알림이 요약됐는지, Notification Organiser의 Promotions 섹션에 들어갔는지, Focus에 의해 억제됐는지, Priority Notifications에 의해 조용히 낮은 우선순위가 됐는지 감지할 API는 없음

웨어러블은 전화 알림 스트림의 부분집합

• Apple Watch는 기본적으로 iPhone 알림을 미러링하지만, iPhone의 Focus와 Summary 상태를 따름
• watchOS 11부터 Smart Stack은 위치, 시간, 캘린더 같은 기기 내 신호를 사용해 관련 위젯을 표시함
• Wear OS는 기본적으로 휴대폰 알림을 페어링된 워치로 브리지하며, companion watch app이 설치된 경우 중복을 막기 위해 BridgingConfig, setBridgeTag, setDismissalId 같은 개발자 제어를 제공함
• 낮은 우선순위 알림의 워치 전달은 억제할 수 있지만, 사용자가 휴대폰에서 음소거한 알림을 워치로 강제 전달할 수는 없음
• 웨어러블은 휴대폰 알림 스트림의 엄격한 부분집합이며, upstream에서 같은 플랫폼 편집을 받고 downstream에서 브리징 동작과 워치 쪽 complication이라는 추가 필터를 거침

사용자가 알림을 실제로 다루는 방식

• 대부분의 알림은 즉각적인 앱 전환을 만들지 않고, 사용자가 인지한 뒤 하던 일을 이어가게 하는 인지 신호로 작동함
• Sahami Shirazi, Henze, Dingler, Pielot, Weber, Schmidt의 CHI 2014 연구 “Large-Scale Assessment of Mobile Notifications”는 Android 런처 계측으로 4만 명 이상 사용자에게서 약 2억 건의 알림을 수집함
  • 메시징 알림은 일관되게 가장 가치 있게, 홍보 알림은 일관되게 가장 낮게 평가됨
  • 사람에게서 온 메시지와 브랜드에서 온 메시지를 다른 표면으로 다뤄야 한다는 실증적 근거가 됨
• Pielot, Church, de Oliveira의 MobileHCI 2014 연구 “An In-Situ Study of Mobile Phone Notifications”는 사용자가 하루 평균 63.5개의 알림을 받고, 대부분 메신저와 이메일에서 오며, 휴대폰이 무음이어도 몇 분 안에 주의를 기울인다는 결과를 냄
• Okoshi 등이 만든 Attelia는 사용자의 휴대폰 활동 중단 지점을 감지해 그 시점까지 알림을 보류하는 미들웨어였고, 통제 연구에서 인지 부하를 46%, 실제 환경에서 33% 줄임
• 이후 Yahoo! Japan 앱 내부의 대규모 배포에서는 발송 시점 조정만으로 클릭률이 최대 60.7% 증가함
• Localytics는 푸시 알림을 끈 사용자의 52%가 결국 앱에서 완전히 이탈하고, 대부분의 앱에서 주당 2~5개 알림이 최적 범위이며, 세분화된 대상은 전체 발송 대비 약 두 배의 오픈율을 보인다고 발표함
• CleverTap에 편입된 Leanplum은 개인화 알림의 오픈율이 일반 전체 발송보다 약 800% 높고, 열린 푸시 알림의 90%가 1시간 안에 행동으로 이어진다고 발표함
• CleverTap의 2025 핀테크 보고서는 세분화 캠페인의 평균 오픈율을 16.3%, 비타깃 캠페인을 4.7%로 제시함
• 벤더 자체 보고 수치는 할인해서 봐야 하지만, 방향성은 일관됨
  • 발송량은 권한을 죽이고, 관련성이 통제 가능한 유일한 안정적 레버임
  • 발송 시점도 중요하지만 관련성보다 덜 중요함
  • 홍보처럼 보이는 것은 대체로 홍보로 분류되며, 종종 그 판단이 맞음
  • 사용자는 홍보 알림보다 거래성·대화형 알림을 훨씬 높은 빈도로 용인함
• 플랫폼의 편집은 전체 발송과 홍보성 푸시에 가장 강하게 작동하고, 사용자가 실제로 원하는 알림은 그대로 통과하거나 더 강조되는 경향이 있음
• Live Activities는 가장 명확한 우회 경로임
  • ActivityKit 세션은 알림 트레이와 별도 표면인 잠금 화면과 Dynamic Island에 렌더링되므로 요약기와 그룹화가 건드리지 않음
  • Android의 Live Updates와 진행 중 알림도 같은 역할을 함
  • 차량 호출, 배송, 경기, 타이머처럼 실제로 진행 중인 거래성 콘텐츠에는 플랫폼 편집기를 피하는 가장 깨끗한 경로임
  • 실제 진행 중인 이벤트에만 쓸 수 있으며, 홍보를 Live Activity처럼 포장할 수는 없음
• Dekker, Baumgartner, Sumter, Ohme의 2024년 Media Psychology 연구 “Beyond the Buzz”는 1주일 무작위 실험에서 알림 비활성화가 휴대폰 확인 빈도나 화면 시간을 줄이지 않았고, 사용자가 앱에 직접 들어가는 방식으로 보상 행동을 했다고 보고함

마케터가 볼 수 있는 것

• 마케터의 가시성은 의도적으로 낮고, 더 나빠지고 있음
• 측정 지표는 신뢰도가 높은 순서에서 낮은 순서로 발송, 플랫폼 수락, 기기 전달, 기기 표시, 열기, 기여 전환으로 이어짐
• APNs와 FCM은 서버 제출 시 응답 코드를 주므로 플랫폼 수락은 안정적으로 노출하지만, APNs는 SMTP 같은 전달 확인을 제공하지 않으며 Apple이 페이로드를 수락해 큐에 넣었다는 것까지만 알 수 있음
• FCM은 메시지 ID와 일부 경우 전달 콜백을 제공하지만, “기기에 전달됨”과 “사용자에게 표시됨”의 경계는 여전히 불투명함
• iOS는 오프라인 상태에서 앱별 최신 알림만 저장하므로, 오래된 알림은 사용자에게 도달하기 전에 조용히 삭제될 수 있음
• Braze, Iterable, OneSignal, Airship, CleverTap, MoEngage, Pushwoosh, Customer.io, Batch 같은 라이프사이클 플랫폼은 앱 SDK 기반 측정을 덧붙임
  • SDK는 알림 표시, 사용자 탭, 탭으로 인한 세션 시작 여부를 기록함
  • 세부성은 iOS의 NotificationServiceExtension 또는 Android의 동등한 broadcast receiver 선언 여부에 달려 있음
  • 확장이 없으면 “전달됨”은 다시 “APNs/FCM이 수락함”으로 축소되어, 사용자가 실제로 본 것보다 겉보기 전달률이 부풀려짐
• OneSignal의 자체 가이드 기준으로 클릭률은 관례적으로 탭 수를 전달 수로 나눈 값이며, 전달은 보통 “FCM 또는 APNs를 통과함”을 뜻함
  • 이 방식은 표시되지 않은 알림, 읽지 않고 스와이프된 알림, 조용히 해제된 알림, Focus나 Reduce Interruptions 필터 뒤에 숨은 알림까지 포함함
  • 일부 플랫폼의 “confirmed delivery”는 SDK가 렌더링을 본 알림을 세므로 더 실제에 가깝지만, 사용자가 해제 전에 렌더링된 알림을 실제로 봤는지는 알 수 없음
• AppsFlyer, Adjust, Branch, Singular, Kochava 같은 모바일 측정 파트너는 페이로드에 추적 링크를 넣고 이후 SDK 이벤트와 매칭해 하위 세션을 특정 푸시 캠페인에 귀속함
• Amplitude, Mixpanel, Heap, PostHog 같은 인앱 분석 도구는 하위 세션은 보지만 자체적으로 상위 알림은 보지 못함
• 푸시 플랫폼의 발송·열기 이벤트를 공유 사용자 식별자로 분석 도구에 보내면 알림, 세션, 전환을 연결할 수 있지만, “전달된 알림이 얼마나 자주 표시·요약·강등·Focus에 의해 억제·미확인됐는지”라는 퍼널 중간부는 복구되지 않음
• 플랫폼이 제공하지 않는 신호가 다수 존재함
  • iOS에서 알림이 Notification Summary에 묶였는지 여부
  • Pixel에서 Notification Organiser의 Promotions 섹션에 들어갔는지 여부
  • Reduce Interruptions가 조용히 만들었는지 여부
  • Priority Notifications가 강등했는지 여부
  • iOS에서 사용자가 잠금 화면에서 읽지 않고 스와이프했는지 여부
  • 사용자가 알림을 억제하는 Focus 모드에 있는지 여부
  • iOS 저장 한도 때문에 표시 전 삭제됐는지 여부
  • Samsung One UI 8.5가 요약했는지 여부
• 푸시가 이메일보다 나은 한 지점은 Android의 delete-intent임
  • 사용자가 표시된 알림을 스와이프해 지울 때 이벤트가 발생해 의도적 해제를 기록할 수 있음
  • Android 전용이고, 표시된 알림에만 발생하며, 숙고한 스와이프와 전체 지우기를 구분할 수 없음
• 2026년의 푸시 측정은 Mail Privacy Protection 이후 이메일 측정처럼, 보이지 않는 편집 계층 아래에 있는 지표를 실제 행동한 사용자만 포착하는 전환 데이터로 보정하는 방식이 됨

파이프 안의 모델을 위한 작성법

• 전체 발송 문구는 더 이상 온전하게 살아남지 않음
• 온디바이스 요약기는 알림을 요지로 압축하므로, 전달되는 것은 브랜드 톤이 아니라 구체적 사실임
• 금액, 이름, 시간, 행동 같은 핵심 payload를 앞에 두면 요약기가 보존할 대상이 생김
• 브랜드식 도입부, 감탄사, 이모지, 말장난 뒤에 핵심을 묻으면 요약기가 이모지만 남기고 의미를 버리거나 잘못된 절반을 남길 수 있음
• 제목은 자연어로 쓰인 구조화 데이터 필드처럼 다뤄야 함
  • “Your delivery is 15 minutes away”는 요약에 안정적임
  • “We've got great news!”는 사실을 담지 않아 안정적이지 않음
  • 제목의 앞 몇 단어만 남겨도 사용자에게 유용한 정보를 주는지 확인하는 방식이 거친 자가 점검이 될 수 있음
  • 이는 보장이 아니라 습관으로 다뤄야 함
• Live Activities와 Live Updates에도 같은 원칙이 적용되며, 핵심 제안은 ETA, 점수, 걸음 수 같은 필드이지 브랜드 포장이 아님
• 시간 민감 인터럽션 레벨을 남용하지 말아야 하는 근거는 Batch의 개발자 가이드에 명시돼 있음
  • “If your time-sensitive notifications are not often interacted with, iOS will prompt your users from the lock screen to let them disable time-sensitive alerts for your app”
  • 사용자는 잠금 화면에서 한 번의 탭으로 앱별 시간 민감 알림을 끌 수 있고, 발신자에게 동등한 항소 절차는 없음

소유 표면으로 무게중심 이동

• 푸시는 라이프사이클 프로그램에서 더 작은 역할을 맡아야 함
• 앱 내부에서 소유하는 표면은 침해성이 낮은 순서로 나눌 수 있음
  • 사용자가 의도적으로 도달하는 피드 안의 수동적 인제품 카드
  • 사용자가 다시 돌아올 수 있는 영구적 인앱 메시지 센터 또는 인박스
  • 활성 세션 중에만 표시되는 세션 이벤트 기반 타깃 인앱 메시지
  • 사용자가 작업을 완료하려고 이미 방문하는 화면에 배치된 제품 플로우 내부의 임베디드 메시징 요소
• 이 소유 표면들은 APNs나 FCM을 거치지 않으며, Apple Intelligence나 Gemini Nano가 건드리지 않음
• 요약·Focus 억제 없이 SDK가 렌더링, 해제, 상호작용 이벤트를 기록하므로 플랫폼 매개 공백 없이 관측 가능함
• 한계는 소유 표면이 활성 사용자에게만 도달한다는 점임
  • 14일 동안 앱을 열지 않은 사용자는 인앱 메시지로 도달할 수 없고 푸시로만 도달 가능함
  • 푸시는 휴면 사용자 재참여와 활성 사용자 대상 거래성·시간 민감 알림 채널이 됨
  • 교차판매, 상향판매, 콘텐츠 발견, 교육, 가치 추가는 인제품 표면이 맡음
• Batch의 2025년 데이터에서 프로모션 코드 캠페인의 인앱 메시지 클릭률은 Android 16.1%, iOS 17.9%로 푸시 CTR보다 높았음
• 같은 데이터에서 인앱은 세션이 필요하기 때문에 도달 가능한 대상이 푸시보다 작음
• 푸시는 사용자를 제품으로 다시 데려오기 위해 존재하고, 사용자가 들어온 뒤에는 소유 표면이 이어받음

다음 변화: 알림을 처리하는 에이전트

• 온디바이스 언어 모델은 일단 탑재되면 요약을 넘어 여러 용도로 쓰임
• Apple의 Foundation Models framework는 iOS 18.4부터 개발자가 운영체제가 쓰는 같은 모델을 요약, 엔티티 추출, 텍스트 이해, 다듬기, 짧은 대화에 호출할 수 있게 함
• Google의 ML Kit GenAI APIs는 AICore 위에서 요약, 교정, 재작성, 이미지 설명을 노출함
• 다음 단계는 모델이 알림에 응답해 사용자를 대신해 행동하는 방향임
  • 가능한 행동은 앱 열기, 예약 완료, 알림 해제, 답장 초안 작성 등임
  • 더 무거운 추론은 기기 안에서만 실행되기보다 Apple Private Cloud Compute나 Google 클라우드 모델 같은 서버 측에서 실행될 가능성이 큼
• Apple의 App Intents 프레임워크는 개발자가 Siri와 Apple Intelligence에 타입이 지정된 앱 행동을 노출하게 함
• Android에서는 App Actions와 Gemini가 서드파티 앱 안에서 행동하는 신흥 역량이 동등한 역할을 함
• 발신자는 요약기가 망가뜨리지 않을 알림을 쓰는 데서 그치지 않고, 알림 뒤의 행동을 노출해 에이전트가 사용자가 앱을 열지 않아도 예약을 완료하거나 알림을 지울 수 있게 해야 함
• 알림은 목적지가 아니라 에이전트가 소비하는 트리거가 되고, 10년간 푸시 측정의 중심이었던 클릭률 지표는 의미를 크게 잃게 됨

푸시 알림을 다루는 실무 원칙

• 푸시는 다른 채널이 못 하는 일에만 사용

  • 푸시는 몇 주 동안 앱을 열지 않은 사용자에게도 닿는 채널이므로, 휴면 사용자 깨우기와 정말 시간에 민감한 거래성 알림에 가장 적합함
  • 교차판매, 상향판매, 교육, 발견 목적의 알림도 시의성과 개인화가 충분하면 가능하지만, 기본적으로 홍보성으로 분류되며 사용자의 방해 예산을 두고 가장 불리하게 경쟁함
  • 홍보성 메시지는 사용자가 의도적으로 연 화면에서 더 효과적이고 위험도도 낮음

• 사용자의 활동과 요청을 중심으로 설계

  • 플랫폼의 중간 편집을 통과하기 쉬운 알림은 사용자가 직접 설정한 신호와 제품이 사용자의 상태에서 생성한 이벤트임
  • 가격 인하, 재입고, 관심목록, 임계값 트리거, 기다리는 항목의 상태 알림은 사용자가 직접 설정한 신호에 해당함
  • 공유된 문서, 작업물에 달린 댓글이나 답글, 완료된 작업, 초과된 한도, 진행 중인 과업의 다음 단계는 제품이 사용자의 상태에서 생성한 이벤트에 해당함
  • 두 유형 모두 수신자의 “자기 것”에 관한 알림이므로 관련성 기준을 자연스럽게 통과하며, 사용자가 바로 행동할 수 있는 제품 내 위치로 딥링크해야 함

• 권한 요청은 첫 실행이 아니라 맥락 안에서 수행

  • Android 13이 알림 권한을 명시적 런타임 승인으로 바꾼 뒤 옵트인 비율이 크게 하락함
  • 첫 실행 직후 시스템 프롬프트를 띄우기보다, 사용자가 알림을 받고 싶어 할 기능과 연결해 가치를 보여준 뒤 요청해야 함
  • 알림 권한은 채널 전체에 해당하므로, 차가운 첫 요청에 낭비하면 안 됨

• 세분화와 개인화가 기본

  • 벤더 데이터는 방향성 자료이지만 10년 동안 같은 결론을 가리켜 왔고, 세분화·개인화 알림은 브로드캐스트보다 대략 두 배 수준의 오픈율을 보임
  • 일반적인 일괄 발송은 성과가 낮고, 되돌릴 수 없는 권한을 소모함
  • 특정한 이유로 특정한 사람에게 보낼 수 없는 메시지라면 모두에게 보내지 않는 편이 맞음

• 얻지 못한 방해권을 쓰지 않기

  • 마케팅 메시지를 시간 민감 알림처럼 꾸미면 안 됨
  • iOS에서는 사용자가 잠금 화면에서 앱별로 시간 민감 알림을 끌 수 있고, 발신자는 이에 이의제기할 수 없음
  • 발송량 증가는 권한을 죽이며, 발신자가 유지할 수 있는 유일한 레버는 관련성임

• 참여도가 전달 가능성을 좌우

  • 플랫폼의 랭킹은 사용자가 알림에 행동하는지 학습하므로, 탭하지 않는 대규모 수신 기반은 모델이 앱을 낮게 평가하도록 학습시키고 사용자가 알림을 끄도록 밀어붙임
  • 푸시에는 이메일의 발신자 평판 체계만큼 체계적인 장치가 없고 효과도 앱·OS별로 다르지만, 방향은 같음
  • 조용해진 구독은 정리해야 하며, 무시되는 큰 기반보다 참여하는 작은 기반이 더 넓은 도달을 유지함

• 문체보다 사실을 앞세우기

  • 제목 앞부분에는 브랜드 톤의 도입부보다 구체적 payload를 둬야 함: 금액, 이름, 시간, 행동 같은 정보가 우선임
  • 요약기는 핵심으로 압축하고 기계가 읽기 쉬운 내용을 보존하므로, 사실 중심 제목은 톤 중심 제목보다 재작성 뒤에도 살아남기 쉬움
  • 이는 측정된 규칙이 아니라 합리적 기본값이며, 공개된 테스트는 없고 근거도 간접적임

• 푸시 대시보드를 맹신하지 않기

  • 오픈과 클릭은 보이지 않는 편집 계층 뒤에 있으며, 측정 가능한 전환은 플랫폼이 이미 우대하기로 한 알림의 편향된 표본임
  • 다운스트림 전환은 가장 덜 나쁜 신호지만, 푸시 전환 이벤트는 희소해 일반적인 발송량에서는 캠페인별 통계적 유의성에 도달하기 어려움
  • SDK로 렌더링을 확인할 수 있으면 확인하고, 캠페인을 묶고 관측 창을 늘린 뒤 숫자를 신뢰해야 함
  • 참여도 상승은 “카피가 좋아졌다”만큼이나 “플랫폼이 나를 더 신뢰한다”로 읽을 수 있음

• 소유한 표면으로 무게 이동

  • 인앱 받은편지함, 로그인된 제품 화면, 실물 우편, 직접 운영하는 로열티 표면에는 파이프 안의 모델이 없음
  • 이 표면들은 요약·랭킹·무음 처리되지 않으며, 끝까지 측정할 수 있음
  • 푸시와 소유 표면은 경쟁 채널이 아니라 하나의 포트폴리오로 운영해야 함

• 잠금 화면이 아니라 에이전트를 위해 설계

  • Siri와 Gemini가 알림에 대해 행동하기 시작하면, 에이전트가 실행할 수 있는 것은 깔끔하고 기계가 읽을 수 있는 제안임
  • 알림 뒤의 행동은 UI 안에서 세 번 탭해야 하는 위치에 묻히면 안 되고, iOS의 App Intents나 Android의 App Actions를 통해 호출 가능한 형태로 노출돼야 함
  • 모델이 사람이 읽지 않아도 메시지를 수행할 수 있도록 작성해야 함

결론

• 푸시는 이메일처럼 완전히 소유한 채널이 아니었고, 소셜보다 덜 임대한 채널에 가까웠음
• 플랫폼은 매 릴리스마다 임대 조건을 자기 쪽에 유리하게 다시 매기고 있음
• 다음 10년을 통과할 발신자는 가장 많이 보내거나 가장 영리하게 쓰는 쪽이 아니라, 수신자가 어차피 원했기 때문에 플랫폼의 편집자가 방어할 수 있는 메시지를 보내는 쪽임
• 최고의 작업은 편집자가 앞에 서 있지 않은 표면으로 이미 옮겨 둔 쪽이 유리함
• 보이지 않는 모델을 위해 쓰고, 그 모델이 닿을 수 없는 채널을 위해 구축해야 함