애플과 구글이 푸시 알림을 ‘편집’하기 시작했다

푸시 알림은 더 이상 앱이 직접 통제하는 채널이 아님

• 이 글의 핵심 주장은 꽤 세다. 푸시 알림도 이메일처럼 플랫폼의 ‘편집’을 받는 채널이 됐다는 얘기임

  • 예전에는 앱이 알림을 보내면 잠금화면에 거의 그대로 뜬다고 생각해도 됐음
  • 지금은 애플과 구글이 알림을 요약하고, 묶고, 조용히 밀어내고, 우선순위를 바꾸는 중간 편집자가 됨
  • 더 무서운 건 앱 개발자나 마케터가 그 편집 과정을 거의 볼 수 없다는 점임

• 푸시는 애초에 배터리 문제에서 출발한 구조였음

  • 2009년 애플은 모든 앱이 각자 서버를 폴링하면 아이폰 배터리가 버티지 못한다고 봤고, 애플 푸시 알림 서비스를 내놨음
  • 구조는 기기 하나가 애플과 단일 지속 연결을 유지하고, 서드파티 앱 알림은 애플 서버를 통해 들어오는 방식이었음
  • 구글도 2010년 클라우드 투 디바이스 메시징, 2012년 구글 클라우드 메시징, 2016년 파이어베이스 클라우드 메시징으로 같은 방향을 밟음

• 그래서 모든 푸시 알림은 처음부터 애플이나 구글을 지나갔음

  • 아이폰 알림은 애플 서버를 통과하고, 안드로이드 알림은 구글 인프라를 통과함
  • 플랫폼은 이론상 제한, 폐기, 기록, 우선순위 조정, 거부를 할 수 있었음
  • 다만 예전에는 그 개입이 눈에 잘 안 보였고, 지금은 그 자제가 끝났다는 게 글의 문제의식임

15년 동안 발신자의 통제권은 계속 줄었다

• 안드로이드는 2017년 안드로이드 8 오레오에서 알림 채널을 도입하며 첫 큰 변화를 줬음

  • 예전에는 개별 알림의 우선순위를 발신자가 정했지만, 이후에는 앱이 채널을 만들고 사용자가 채널별로 끄거나 낮출 수 있게 됨
  • 다운로드, 메시지, 프로모션 같은 채널을 나눠서 사용자가 각각 배지, 소리, 차단 여부를 제어할 수 있음
  • 앱이 안드로이드 8을 대상으로 하면서 채널을 선언하지 않으면 알림이 표시되지 않음

• 애플은 2021년 아이오에스 15에서 포커스, 예약 요약, 방해 수준 분류를 도입함

  • 알림은 수동, 활성, 시간 민감, 중요 알림 같은 식으로 다뤄지기 시작함
  • 특히 시간 민감 알림은 마케팅에 쓰지 말라고 애플이 명시해왔음
  • 사용자가 알림을 받을 권리를 플랫폼과 직접 협상하는 구조가 강해진 셈임

• 안드로이드 13은 알림 권한 자체를 런타임 승인으로 바꿨고, 이게 숫자로 바로 드러남

  • 푸시우시의 1,600만 기기 샘플에서는 게임 앱의 동의 기반이 거의 3분의 1 줄었고, 뉴스 앱은 19% 감소함
  • 배치의 2025년 벤치마크는 1만 개 앱, 8,000억 개 이상 메시지를 기반으로 안드로이드 동의율이 1년 사이 85%에서 67%로 떨어졌다고 보고함
  • 교차 플랫폼 평균 동의율은 61% 수준으로 정리됨

이메일이 먼저 겪은 일을 푸시가 따라가는 중

• 글은 이메일을 푸시의 미래 예고편으로 봄

  • 지메일은 2013년 기본함, 프로모션, 소셜, 업데이트 탭으로 합법적인 메일까지 분류하기 시작함
  • 애플 메일은 2021년 메일 개인정보 보호로 원격 콘텐츠를 프록시로 미리 가져와 오픈율 측정을 망가뜨림
  • 한 벤더는 애플발 오픈율이 6개월 만에 22.6%에서 40.5%로 뛰는 걸 봤는데, 이건 독자가 더 읽어서가 아니라 미리 가져오기 때문이었음

• 이메일은 그래도 진단 도구와 열린 프로토콜이 있음

  • 에스엠티피, 아이맵, 디케이아이엠, 디마크 같은 공개 표준이 있고, 구글 포스트마스터 도구 같은 일부 진단 수단도 있음
  • 사용자는 같은 메일함을 여러 클라이언트에서 열 수 있고, 발신자는 주소 목록을 보유함
  • 반면 푸시는 특정 기기, 특정 앱 설치, 특정 토큰에 묶이고 애플이나 구글이 토큰을 무효화할 수 있음

• 푸시는 이메일보다 더 닫힌 채널임

  • 앱은 잠금화면에 보일 접힌 알림 형태를 거의 플랫폼 템플릿 안에서만 제어함
  • 확장 뷰는 커스텀할 수 있지만, 사용자가 알림을 펼친 뒤에야 의미가 있음
  • 요약 모델이 읽는 건 결국 접힌 알림의 제목과 본문이고, 그 부분은 플랫폼이 편집하기 쉬움

진짜 편집자는 기기 안의 모델이다

• 이메일 편집은 주로 서버에서 일어나지만, 푸시 편집은 기기 표시 단계에서 일어남

  • 전송 경로가 아니라 잠금화면과 알림 센터에 표시되기 직전이 핵심임
  • 사용자 설정, 포커스 모드, 채널 차단, 요약 모델, 우선순위 모델이 겹쳐서 최종 표시 형태를 결정함
  • 이 모델의 가중치와 신호는 공개되지 않음

• 애플 인텔리전스는 30억 매개변수 온디바이스 기반 언어 모델과 더 큰 서버 모델을 함께 쓴다고 설명됨

  • 애플은 2비트 양자화 인식 학습, 키-값 캐시 공유 같은 방식으로 애플 실리콘에 모델을 맞춤
  • 기능별로는 수십 메가바이트짜리 작은 어댑터를 동적으로 불러와 요약, 엔터티 추출, 알림 우선순위 같은 작업을 특화함
  • 뉴스 요약 오류 논란 뒤 애플은 뉴스·엔터테인먼트 요약을 끄고, 인공지능 요약을 이탤릭으로 표시하며, 앱별 끄기 옵션과 오류 경고를 추가함

• 구글 쪽은 제미나이 나노와 에이아이코어가 같은 역할을 함

  • 에이아이코어는 안드로이드 14에서 도입된 시스템 서비스로, 모델을 시스템 파티션에 두고 승인된 앱이 공유하게 함
  • 입력과 출력은 저장하지 않고, 직접 인터넷 접근도 제한되며, 모델 업데이트는 구글 플레이 시스템 업데이트로 배포됨
  • 픽셀 10 시리즈와 삼성 갤럭시 S26 시리즈의 알림 요약과 알림 정리 기능이 이 스택 위에서 동작한다고 설명됨

sequenceDiagram
    participant 앱서버 as 앱 서버
    participant 플랫폼 as 애플·구글 전달망
    participant 운영체제 as 휴대폰 운영체제
    participant 모델 as 온디바이스 모델
    participant 사용자 as 사용자
    앱서버->>플랫폼: 알림 페이로드 제출
    플랫폼->>운영체제: 기기로 전달
    운영체제->>운영체제: 권한·포커스·채널 규칙 적용
    운영체제->>모델: 요약·우선순위 판단 요청
    모델-->>운영체제: 표시 문구와 중요도 반환
    운영체제->>사용자: 잠금화면·알림 센터에 표시 또는 억제

• 발신자가 개입할 수 있는 수단은 생각보다 제한적임
  • 아이오에스의 알림 서비스 확장은 표시 전에 페이로드 복호화, 이미지 가져오기, 텍스트 수정 정도를 할 수 있음
  • 알림 콘텐츠 확장은 펼친 화면의 커스텀 사용자 인터페이스를 만들 수 있지만, 플랫폼 요약이나 우선순위 판단 뒤를 제어하지는 못함
  • 안드로이드에서도 앱은 알림 관리자에 쓰고 채널 중요도를 선언할 수 있지만, 시스템 분류 자체를 끌 수는 없음

사용자는 알림을 많이 탭하지 않는다

• 연구들을 보면 대부분의 알림은 즉시 행동으로 이어지지 않음

  • 2014년 대규모 모바일 알림 연구는 4만 명 이상 사용자에게서 거의 2억 개 알림을 수집했고, 사용자는 사람 간 메시지를 가장 가치 있게 보고 프로모션 알림을 가장 낮게 평가했음
  • 다른 2014년 연구는 사용자가 하루 평균 63.5개 알림을 받는다고 보고함
  • 2017년 연구에서는 하루 동안 푸시 알림을 끄자 참가자들이 더 생산적이었지만 더 불안하고 사회적으로 덜 연결됐다고 느낌

• 타이밍 최적화와 개인화는 효과가 있지만, 핵심은 여전히 관련성임

  • 아텔리아라는 미들웨어는 사용자의 활동 전환점을 감지해 알림을 보류했다가 보여주는 방식으로 인지 부하를 통제 연구에서 46%, 실제 환경에서 33% 줄였다고 함
  • 야후 재팬 앱 내부 대규모 배포에서는 타이밍만으로 클릭률이 최대 60.7% 증가한 사례가 보고됨
  • 클레버탭의 2025년 핀테크 보고서는 세그먼트 캠페인의 평균 오픈율이 16.3%, 비타기팅 캠페인은 4.7%라고 제시함

• 다만 벤더 숫자는 할인해서 봐야 함

  • 개인화 알림이 일반 브로드캐스트보다 훨씬 낫다는 방향성은 여러 자료가 일관되게 말함
  • 하지만 정확한 배수나 최적 발송 빈도는 벤더가 자기 제품을 팔기 위해 만든 자료라는 점을 감안해야 함
  • 그래도 “볼륨은 권한을 죽이고, 관련성만 살아남는다”는 결론은 꽤 강하게 남음

마케팅 푸시가 가장 크게 맞고, 거래성 알림은 상대적으로 살아남는다

• 플랫폼 편집은 모든 알림에 똑같이 작동하지 않음

  • 사람에게서 온 메시지, 중요한 보안 알림, 배달·차량 호출·경기·타이머처럼 사용자가 기다리는 상태 업데이트는 필터를 통과하기 쉬움
  • 라이브 액티비티나 안드로이드의 진행 중 알림은 알림함과 별도 표면에 표시되므로 요약과 묶기의 영향을 덜 받음
  • 하지만 프로모션을 라이브 액티비티처럼 위장하는 건 불가능하고, 해도 오래 못 감

• 마케팅성 브로드캐스트 푸시는 가장 취약함

  • 운영체제 입장에서는 사용자의 주의를 보호해야 하고, 프로모션은 가장 쉽게 줄일 수 있는 소음임
  • 안드로이드 알림 정리의 프로모션 영역은 지메일 프로모션 탭과 비슷한 중심지가 될 가능성이 있음
  • 결국 사용자가 직접 요청한 알림, 자기 계정 상태와 연결된 알림, 지금 처리해야 하는 알림이 살아남음

측정은 점점 어두워진다

• 푸시 퍼널에서 확실한 건 ‘플랫폼이 받았다’ 정도임

  • 애플 푸시 알림 서비스와 파이어베이스 클라우드 메시징은 서버 제출 응답을 제공함
  • 하지만 애플은 에스엠티피 같은 전달 영수증을 주지 않고, 애플이 페이로드를 받아 큐에 넣었다는 것 이상을 알기 어려움
  • 파이어베이스 클라우드 메시징은 일부 배송 콜백을 제공하지만, 기기에 도착한 것과 사용자에게 표시된 것 사이의 간극은 여전히 불투명함

• 푸시 플랫폼 대시보드도 중간층을 못 본다

  • 브레이즈, 원시그널, 에어십, 클레버탭 같은 도구는 앱 소프트웨어 개발 키트 기반으로 표시, 탭, 세션 시작을 집계함
  • 하지만 알림 서비스 확장이나 수신 확인 장치가 없으면 ‘전달됨’이 사실상 애플·구글에 접수됐다는 뜻으로 뭉개질 수 있음
  • 요약됐는지, 포커스 모드에 막혔는지, 조용한 영역에 들어갔는지, 우선순위에서 밀렸는지는 플랫폼이 알려주지 않음

이제 푸시 문구는 ‘모델이 줄여도 살아남는 문장’이어야 한다

• 글쓴이는 알림 제목을 자연어로 된 구조화 데이터처럼 쓰라고 조언함

  • “배송이 15분 뒤 도착해요”는 요약돼도 의미가 남음
  • “좋은 소식이 있어요!”는 정보가 없어서 요약 모델이 보존할 핵심이 없음
  • 금액, 이름, 시간, 행동, 상태 같은 구체 정보를 앞에 둬야 함

• 브랜드 보이스는 잠금화면에서 점점 약해짐

  • 말장난, 이모지, 감탄사는 모델이 요약하면서 버리거나 엉뚱하게 남길 수 있음
  • 사용자는 문학성보다 정보 유형과 발신 맥락을 보고 알림 가치를 판단함
  • 알림 첫 몇 단어만 남아도 사용자에게 쓸모 있는 정보가 있는지 자체 점검하는 습관이 필요함

• 시간 민감 알림 남용은 자해에 가깝다

  • 배치 개발자 가이드는 시간 민감 알림이 자주 상호작용되지 않으면 아이오에스가 잠금화면에서 사용자의 비활성화를 유도할 수 있다고 설명함
  • 사용자가 한 번 끄면 앱별로 꺼지고, 발신자에게 항소 창구는 없음
  • 마케팅을 긴급 알림처럼 포장하면 잠깐은 뚫릴지 몰라도 권한 자체를 태워먹을 수 있음

앱 안의 자기 채널이 다시 중요해진다

• 푸시가 플랫폼 편집을 받는다면, 앱 안의 표면은 상대적으로 가치가 커짐

  • 인앱 카드, 앱 내부 메시지 센터, 세션 기반 배너나 모달, 제품 흐름 안에 박힌 메시지는 애플 푸시나 파이어베이스 클라우드 메시징을 거치지 않음
  • 애플 인텔리전스나 제미나이 나노가 요약하거나 포커스 모드가 막지도 않음
  • 렌더, 닫기, 클릭 같은 이벤트도 앱이 끝까지 측정할 수 있음

• 단점은 앱을 열지 않은 사용자를 못 만난다는 점임

  • 14일 동안 앱을 열지 않은 사용자는 인앱 메시지로 닿을 수 없음
  • 그래서 푸시는 휴면 사용자를 깨우거나, 정말 시간 민감한 거래성 알림을 보내는 역할로 좁아짐
  • 앱 안 표면은 크로스셀, 업셀, 콘텐츠 발견, 교육, 부가 가치 전달을 맡는 쪽이 자연스러움

• 배치의 2025년 데이터는 프로모션 코드 캠페인에서 인앱 메시지 클릭률이 안드로이드 16.1%, 아이오에스 17.9%였다고 함

  • 푸시보다 도달 가능한 모수는 작지만, 일단 앱에 들어온 사용자에게는 훨씬 선명하게 작동함
  • 푸시는 사용자를 제품 안으로 데려오는 역할, 제품 안에서는 자체 표면이 이어받는 구조가 더 합리적임

다음 단계는 에이전트가 알림을 읽고 대신 행동하는 세계

• 온디바이스 모델이 인프라가 되면, 알림 요약은 시작일 뿐임

  • 애플은 아이오에스 18.4 이후 개발자가 같은 기반 모델을 호출할 수 있는 파운데이션 모델 프레임워크를 제공함
  • 구글도 에이아이코어 위의 생성형 인공지능 API로 요약, 교정, 재작성, 이미지 설명을 제공함
  • 모델은 기능 하나가 아니라 운영체제 인프라가 되어가고 있음

• 시리와 제미나이가 알림에 반응해 행동하는 단계가 오면 클릭률의 의미도 흔들림

  • 알림을 열고 앱에 들어가는 대신, 에이전트가 예약을 완료하거나 답장을 초안으로 만들거나 알림을 정리할 수 있음
  • 애플의 앱 인텐트, 안드로이드의 앱 액션은 앱 기능을 시스템 에이전트가 호출할 수 있게 하는 통로임
  • 그러면 알림은 목적지가 아니라 에이전트가 소비하는 트리거가 됨

• 결론은 단순함. 푸시는 소유 채널이 아니라 임대한 채널이었고, 임대료가 오르는 중임

  • 많이 보내는 쪽이 이기는 게 아니라, 사용자가 실제로 원한 알림을 보내는 쪽이 살아남음
  • 모델이 요약해도 의미가 남는 문장, 사용자의 상태와 직접 연결된 트리거, 앱 안에서 이어지는 자체 채널이 중요해짐
  • 앞으로 푸시 전략은 “어떻게 더 크게 방해할까”가 아니라 “플랫폼 편집자가 막을 이유가 없게 만들 수 있나”에 가까워짐

기술 맥락

• 푸시 알림은 앱 서버에서 사용자 폰으로 바로 가는 메시지가 아니에요. 아이오에스는 애플 푸시 알림 서비스, 안드로이드는 파이어베이스 클라우드 메시징을 거치기 때문에 플랫폼이 전달과 표시 사이에 들어올 수밖에 없어요. 예전에는 그 개입이 작았고, 이제는 운영체제 모델이 적극적으로 편집하는 쪽으로 바뀐 거예요.

• 애플과 구글이 온디바이스 모델을 쓰는 이유는 개인정보와 지연 시간 때문이에요. 알림 본문을 서버로 매번 보내지 않고 기기 안에서 요약·분류하면 개인정보 명분도 세울 수 있고, 잠금화면 표시 직전에 빠르게 판단할 수 있거든요. 대신 발신자는 그 판단 과정을 들여다볼 수 없어요.

• 개발자 입장에서 제일 큰 변화는 측정의 빈칸이에요. 서버는 플랫폼이 알림을 받았다는 응답을 보고, 앱 소프트웨어 개발 키트는 사용자가 탭한 뒤의 행동을 볼 수 있어요. 그런데 그 사이에서 알림이 요약됐는지, 조용히 밀렸는지, 포커스 모드에 막혔는지는 운영체제가 알려주지 않아요.

• 그래서 실무 전략도 바뀌어야 해요. “전송 수를 늘리면 더 많은 클릭이 나온다”는 식의 캠페인 사고보다, 사용자가 직접 설정했거나 기다리는 이벤트를 정확하게 보내는 쪽이 유리해요. 모델이 편집해도 남을 만큼 구체적인 제목과, 앱 안에서 이어지는 자체 메시지 표면을 같이 설계해야 하는 이유가 여기에 있어요.