▲

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

 (jacquescorbytuech.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 푸시 알림은 단순 전달 계층이 아니라 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년을 통과할 발신자는 가장 많이 보내거나 가장 영리하게 쓰는 쪽이 아니라, 수신자가 어차피 원했기 때문에 플랫폼의 편집자가 방어할 수 있는 메시지를 보내는 쪽임
  • 최고의 작업은 편집자가 앞에 서 있지 않은 표면으로 이미 옮겨 둔 쪽이 유리함
  • 보이지 않는 모델을 위해 쓰고, 그 모델이 닿을 수 없는 채널을 위해 구축해야 함

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 내 폰이 나를 방해한다면, 지금 당장 누군가가 진짜로 내 주의를 필요로 한다는 뜻이어야 하고 아니면 아예 방해하면 안 됨. 내 알림 설정은 전화, 메시지, WhatsApp, Apple Health, 은행 앱 정도만 푸시 알림을 허용함
    그 외 앱이 즉시 나를 호출해야 할 이유는 없음. 대부분의 앱은 중요한 일이 있어서가 아니라 내 주의를 원해서 알림을 보냄
    연속 사용 기록, 할인, 추천, 배송 업데이트 같은 알림은 필요 없고, 내가 앱을 열기로 선택할 때까지 기다려도 충분함

    • 이 글은 꽤 노골적으로 보내는 쪽 관점에서 쓰였고, 플랫폼이 “발신자 통제권”을 가져가는 걸 걱정하고 있음
      하지만 대부분의 앱은 사용자의 주의를 존중할 수 없다는 걸 이미 충분히 증명했음. 불필요한 알림과 내 폰 사이에 플랫폼이 장애물을 더 많이 둘수록 좋고, Apple이나 Google이 영웅이라고 보진 않지만 적어도 티켓 한 번 샀다고 억지로 깔게 된 앱의 마케팅 부서보다는 내 이해관계와 더 잘 맞음
    • 가장 큰 문제는 둘 다 하는 앱임. 예를 들어 Uber는 운전자가 도착했을 때 알려주길 바라지만, 다음 5번 탑승 10% 할인 같은 건 받고 싶지 않음
      필수 알림과 광고 알림을 따로 막기가 쉽지 않음
    • “마케팅은 자신들이 차지하고 싶어 하지 않는 통신 시스템을 만난 적이 없다”는 말이 떠오름
      상업용 앱에 “고객과 소통”하려고 WhatsApp 지원을 넣고 싶다는 고객을 볼 때마다 생각남
      동시에 사용자마다 알림을 원하는 앱의 부분집합은 다름. 교대 근무자는 배정된 근무나 갑자기 열린 근무를 알아야 하고, 어떤 사용자에겐 정말 중요하지만 다른 사용자에겐 스팸임
      유용한 알림은 마케팅 알림으로 쉽게 변질됨. 배송 기사가 밖에 있다는 건 알고 싶지만 이번 주 특가를 알고 싶진 않음
      기술적으로 완전히 풀 수 있는 문제는 아님. 나쁜 행위자는 실제로 나쁘게 행동함. 그래도 시스템은 선량한 앱이 잘 작동하도록 만들어야 하고, 최종적으로 사용자가 무엇을 볼지 정해야 함. Google도 Apple도 아님
      최저공통분모를 기준으로 사회를 만들면 모두에게 별로임. 나쁜 행동을 처벌할 수 있게 하면서 좋은 행동을 적극 장려해야지, “나쁠 수도 있다”는 이유로 전부 금지하면 안 됨
    • “푸시 알림”과 “푸시 알림에 대해 방해받는 것”을 섞어 말하고 있음. 내 폰에는 중요하지만 긴급하지 않은 앱들이 많고, iOS 알림 센터에 조용히 추가되도록 설정해둠
      이렇게 설정한 앱은 알림이 도착해도 배너가 뜨지 않고 잠금 화면에도 보이지 않음. 잠금 화면에 올라오는 시의성 있는 알림을 지나 직접 아래로 스크롤해 모든 알림을 따라잡을 때만 보임
      사실상 원하면 확인하고 아니면 안 봐도 되는 “이메일 받은편지함”으로 격하되는 셈임. 이메일과 달리 알림은 앱 작업 흐름의 필수 경로가 될 수 없으므로, 알림 받은편지함은 언제든 부담 없이 비워도 됨
    • Apple과 Google은 지난 10년 동안 푸시 알림을 쓸 만하게 만드는 데 실패했음. 중요한 알림이 완전히 무관한 쓰레기 알림의 바다에 묻힘
      많은 앱이 아주 작은 화면 공간을 두고 경쟁하는 원시적인 구조이고, 대부분의 푸시 알림은 “뭔가 일어났다!” 이상을 알려주지 않음. 실행 가능한 정보도 적고 실제로 무슨 일이 일어났는지도 모호함
      그 결과 알림이라는 개념 자체의 가치가 떨어졌고, 가끔 흥미로운 게 지나가도 놓치거나 다시 찾기 어려움
      푸시 알림 사용자 경험은 형편없고, 앱 개발자들이 사용자를 마음대로 방해할 수 있는 초능력을 남용하면서 시간이 갈수록 더 나빠졌음. Apple과 Google이 이를 통제하려 했지만 남은 결과는 몇 안 되는 정당한 용도에도 그저 평범한 수준임
      은행 승인, 2단계 인증 같은 건 앱으로 들어가는 딥링크로는 유용하지만, 그 외엔 하던 일을 멈추고 폰을 볼 가치가 없음
      내 Android 폰에서 가장 많이 쓰는 앱은 Firefox와 Gmail, 그리고 몇 가지뿐임. 알림 채널로는 이메일 받은편지함이 모바일 푸시보다 훨씬 유용함. 더 실행 가능하고 정보가 많으며, 개별 수신 거부나 필터링, 재검색도 쉬움. 대부분의 앱은 둘 다 할 수 있으니 푸시 알림은 열등하고 중복됨

  • 이 글은 작성자가 Apple과 Google이 특정 유형의 알림, 즉 스팸성 알림을 막거나 통제하는 데 화가 난 것처럼 읽힘
    “교차판매, 상향판매, 교육, 발견도 푸시에서 작동할 수 있다”지만, 푸시 알림은 거래성 알림에만 써야 함. 쓰레기용 받은편지함을 하나 더 원하지 않음

    • 병원 예약 앱은 리마인더 때문에 알림을 켜두고 싶음. 그런데 최근 그 채널로 마케팅 메시지를 보내기 시작했음
      아마 마케팅 메시지만 끄는 방법이 있겠지만, 대부분은 모르고 바꾸지도 않을 것임. 정말 짜증남
    • Apple이 앱 개발자에게 홍보 알림과 거래성 알림을 서로 다른 알림 채널로 구현하도록 강제했으면 좋겠음. 그래야 사용자가 원하는 것만 고를 수 있음
    • 제목의 “당신의 푸시 알림”에서 “당신”은 사용자가 아니라 마케터임. 그것만 봐도 이 글의 가치가 충분히 드러남
    • 화가 난 건 아니고, 모든 채널이 점점 빅테크의 중개를 거치게 되는 게 걱정됨
    • 경우에 따라 다름. BlackBerry 10 Hub는 iOS나 Android처럼 느슨한 알림 체계가 아니라 공유 받은편지함으로 강하게 설계되어 있었고, 정말 좋았음

  • Uber, Bolt, Airbnb 같은 서비스가 답답함. 핵심 서비스에는 푸시가 필요한데, 제공자가 그 틈을 이용해 스팸을 끼워 넣음

    • Uber는 특히 심함. 시골에 살아서 평소엔 안 쓰지만 여행할 때는 Uber나 가끔 Uber Eats를 씀
      지금은 마케팅 쓰레기가 너무 침습적이라 필요할 것 같을 때만 앱을 설치하고, 아니면 지워둠. 햄버거 배달은 좋지만, 서비스가 우리 집까지 가져다줄 수 있는 건 문자 그대로 아무것도 없다는 점도 더 짜증남
    • Apple과 Google은 서비스들이 알림을 남용하도록 놔둬서 알림을 사실상 가치 없게 만들었음. 내 시간과 주의를 더 존중했으면 좋겠음

  • 사람들은 자기 주의를 훔치는 것들에 너무 수동적이라 늘 놀라움
    내 폰은 24시간 내내 방해 금지 모드임. 앱이 쓸데없는 걸 알리면 삭제하고 웹사이트를 씀
    “unsubscribe”라는 단어가 들어간 이메일은 받은편지함에서 빼서 별도 태그 영역으로 옮기는 메일 규칙도 있음. 며칠마다 들어가서 도착한 것들을 모두 수신 거부함
    소매점 계산대에서 개인정보나 전화번호를 묻거나 클럽 가입을 요구하면 할인해 주는지 묻음. 할인이 없으면 정보도 없음. 내 정보에 정당한 값을 제시하면 고려하겠지만, 지금까지 어떤 소매점도 내 시간과 정보의 가치만큼 지불한 적은 없음

    • 소매점에서 전화번호를 요구할 때는 애초에 검토할 가치도 없어 보임. 한 번 할인을 주고 나서 수년 동안 정보를 보유하고 남용할 수도 있음
    • 이메일의 불필요한 알림을 전부 죽이려고 수신 거부 규칙의 더 발전된 버전을 만들었고, 오픈소스로 공개했음
      https://unfuck.email
    • “수동적”이라는 표현의 요지는 이해하고 타당하다고 보지만, 엄밀히 말하면 대부분은 선택지가 없다고 느낌
      전화를 안 받거나 메시지에 답하지 않는 건 많은 사람에게 금기이고, 그래서 스패머와 소셜 앱이 모든 방향에서 달려드는 군비 경쟁에 놓임. 그런 사람들은 우리가 24시간 방해 금지의 땅에 사는 걸 답답해함
      어떻게 해결할 수 있을지는 모르겠지만, 그 입장도 이해됨

  • 메시지 알림을 제외하고 전부 꺼보고 하루를 보내보면 됨. 죽지 않음. 정말 신경 쓰는 것들은 주기적으로 확인하는 데 금방 익숙해지고, 나머지는 내가 신경 쓸 때까지 기다려야 함
    몇 년째 이렇게 살고 있고, 친구나 동료들은 그 사실을 모르며 알 필요도 없음. 알림은 빠르게 답하게 도와주는 게 아니라, 내가 하려던 일에서 주의를 빼앗음
    오늘 아직 Discord도 이메일도 확인하지 않았음. 친구들이 썼는지, 새 청구서가 있는지, 뭔가 후속 조치가 필요한지 알고 싶어질 때 해당 앱을 열고 처리할 것임
    폰을 몇 시간 동안 옆에 둬도 산만해지지 않을 수 있음

    • “정말 신경 쓰는 것들을 주기적으로 확인하는 데 익숙해진다”가 내게 가장 컸음. 예전에는 알림을 끄면 중요한 걸 놓칠까 봐 불안했지만, 어차피 알림이 있어도 놓치곤 했음
      중요한 것들을 주기적으로 확인하는 습관에는 좋은 부작용도 있었음. 폰이 대신 해주는 데 덜 의존하면서 내 정신적 알림 시스템이 더 좋아졌고, 점점 덜 확인하는 앱과 서비스가 실제로 얼마나 중요하지 않은지도 더 분명해졌음
      지금은 앱과 계정이 훨씬 적고, 오히려 전체적으로 더 시간을 잘 지키게 됨

  • 이 부분은 사실과 다름: “알림은 알림 센터에만 존재하며, 알림 센터는 지나가는 것을 지우고, 버리고, 요약하며, 아무것도 안정적으로 보관하지 않는다”
    알림 센터는 정보를 안정적으로 보관함. 받은편지함 같은 것은 사용자 영역에는 없을 뿐 실제로 존재함: https://www.forbes.com/sites/larsdaniel/2026/04/10/fbi-pulle...

  • “15년 동안 이 채널은 하나의 전제를 중심으로 재구축됐다. 수신자의 주의는 희소한 자원이고 플랫폼은 이를 방어할 의무가 있다. … 발신자로서 당신은 통제가 어느 쪽으로 옮겨가든 그 전제의 반대편에 서 있다”
    저자가 상황을 발신자와 수신자의 이해관계가 대립하는 것으로 공개적으로 틀 짓는 점이 흥미로움

    • 반드시 대립하는 건 아니고 긴장 관계에 가까움
      사용자의 주의를 열성적으로 지키는 장치는 사용자가 보고 싶어 했을 무언가를 가끔 막을 수 있음
      그래도 대부분의 알림은 쓰레기이고 막혀야 함
    • 꽤 박하게 읽은 듯함. 저 문장은 플랫폼이 사용자의 이익이 아니라 플랫폼의 이익에 따라 행동한다고 말하는 것에 가깝다고 봄

  • “이 모든 영향은 고르게 작용하지 않는다. 편집은 방송형·홍보형 푸시에 가장 강하게 떨어지고, 사람들이 실제로 원하는 알림은 그대로 통과하거나 증폭되는 편이다”
    내게는 괜찮게 들림

  • “채널 역사 대부분의 기간 동안 플랫폼은 눈에 띄게는 거의 개입하지 않았다. 구조적으로 개입은 가능했지만, 그저 많이 개입하지 않기로 선택했을 뿐이다. 그 자제가 끝났다”
    항상 눈에 보이진 않았겠지만, 처음부터 어떤 형태로든 개입은 있었음. WhatsApp에서는 푸시 지연, 억제, 병합을 늘 모니터링했고, 기억상 적어도 내가 합류한 2011년부터 시스템의 일부였음
    그 시스템 안에서 제대로 동작하지 않으면 사용자 메시지가 제때 전달되지 않음

    • 흥미롭다. 관련 맥락을 더 알려줄 수 있는지 궁금함. 그렇게 큰 규모의 제품에서 일해본 적이 없어서, 모니터링은 늘 상용 푸시 플랫폼에서 얻을 수 있는 것에 한정됐음

  • USA PATRIOT Act 215조의 전화 메타데이터 대량 수집을 대체한 무엇인가가 Apple Push Notification, Firebase Cloud Messaging 등의 구조에 영향을 준다고 봄
    Apple은 모든 iPhone에 대한 지속 연결을 소유하고, APNs만 앱을 깨울 수 있음. 여기서 “셀프 호스팅”은 Firebase Cloud Messaging, OneSignal, Pusher 같은 제3자에게 맡기지 않고 무엇을 보낼지 결정해 APNs에 넘기는 자체 제공자 백엔드를 운영한다는 뜻임. 하지만 마지막 구간은 결코 내 것이 아님
    모든 사람의 트래픽을 소수의 신원 인식 중개자에게 통과시키는 구조는 설계상 법적 도구만 기다리는 대량 메타데이터 수집 시스템임
    2023년 12월 Ron Wyden 상원의원은 미국 정부와 외국 정부가 Google과 Apple에 푸시 알림 정보, 통신 메타데이터, 때로는 내용을 비밀리에 넘기도록 강제했다는 사실을 공개했음. 개발자가 신경 써야 할 부분은 iPhone과 Android가 의존하는 플랫폼에서 알림을 보내려면 이 관행을 막을 방법이 없다는 점임
    Apple은 이 프로그램이 공개되기 전까지 발설 금지 상태였고, 이후 이런 요청을 투명성 보고서에 자세히 반영하겠다고 밝혔음. 그러니 이 구조적 가설은 추측이 아니라 확인된 메커니즘이며, Section 215와 다른 점은 영역이 통화가 아니라 앱이고, 법적 수단이 §215의 특정 사업 기록 이론이 아니라 일반 소환장, FISA 명령, NSL이라는 정도임
    “그건 그냥 메타데이터일 뿐”이라는 말은 결국 이런 맥락에서 나옴. 물론 농담이고, 이런 일에 단일 개인만 책임 있는 건 아니며 집단적 정치 의지의 결과이고 안타깝게도 우리가 할 수 있는 최선일 수 있음
    https://www.youtube.com/watch?v=9iUdm0QMDM0
    https://epic.org/sen-wyden-reveals-government-surveillance-o...

답변달기