한 번의 배달 주문만으로도 “주문 확인”부터 “배달 완료”까지 푸시 알림이 57회 전송됩니다. 일주일에 몇 번 주문하면 앱이 순식간에 스팸처럼 느껴지기 시작합니다. 일반 스마트폰 사용자는 이미 하루 46개의 푸시 알림을 받고 있으며, 주 25회 발송되는 앱의 푸시 알림 중 43%는 사용자가 차단합니다.
사용자는 매 순간 어떤 일이 벌어지는지 알고 싶어합니다. 하지만 그 과정에서 다섯 번씩 방해받고 싶지는 않습니다. 참여와 이탈의 차이는, 어떤 순간에 푸시 알림이 필요하고 어떤 순간에는 단순히 눈에 보이기만 하면 되는지를 구별하는 데 있습니다.
이 가이드에서는 실시간 시나리오에서 푸시 알림과 Live Activities를 언제 어떻게 사용해야 하는지, 3-메시지 룰, 실제 적용 사례, 업종별 활용법, 그리고 기존 스택을 재구축하지 않고 시작하는 방법을 다룹니다. 그리고 Pushwoosh가 어떻게 이 두 채널을 하나의 고객 여정에서 오케스트레이션할 수 있는지 함께 살펴봅니다.
알림 vs. 라이브 상태: 꼭 알아야 할 단 하나의 구분
대부분의 팀은 실시간 관련된 모든 것에 기본적으로 푸시 알림을 사용합니다. 주문 확인, 푸시. 라이더 배정, 푸시. 라이더 이동 중, 푸시. 라이더 도착 중, 푸시. 배달 완료, 푸시. 사용자가 직접 요청하고 이미 예상하고 있는 하나의 이벤트를 위해 다섯 번의 방해가 발생합니다.
이 업데이트들은 모두 중요하지만, 모두가 푸시 알림일 필요는 없습니다. 실시간 시나리오에는 근본적으로 다른 2가지 커뮤니케이션 역할이 있습니다.
**알림(Alerts)**은 “무언가 일어났습니다! 지금 확인하세요”라고 말합니다. 사용자를 방해하고 주의를 요구합니다. 결정이나 행동 변화가 반드시 필요한 순간에 쓰입니다: 항공편 게이트 변경, 결제 실패, 차량 도착 등.
**라이브 상태(Live State)**는 “지금 이런 상황이 진행 중입니다. 원할 때 확인하세요”라고 말합니다. 배경에 머물며 지속적으로 업데이트됩니다. 라이더 위치, 조리 시간, 배달 예상 시간(ETA), 경기 점수, 운동 거리처럼 사용자가 반응할 필요 없이 추적하고 싶은 정보를 담당합니다.
푸시 알림은 알림용으로 설계되었습니다. Live Activities는 라이브 상태용으로 설계되었습니다. 상태 추적에 푸시를 사용한다는 것은, 사용자가 방해받기를 원하지 않은 내용으로 사용자를 방해한다는 뜻입니다.
3-메시지 룰
모든 실시간 시나리오에서 필요한 푸시 알림은 최대 3개입니다.
시작(Start). 프로세스가 시작되었음을 확인합니다. “주문이 접수되었습니다.” “결제가 시작되었습니다.” “차량이 출발했습니다.” 사용자에게 기대치를 설정하고 안심시키며, 이후 상태를 이어받을 Live Activity를 활성화합니다.
예외(Exception). 문제가 발생했거나 조치가 필요할 때입니다. “상품 품절.” “라이더가 입구를 찾지 못하고 있습니다.” “결제가 거절되었습니다. 카드를 업데이트하세요.” “항공편이 2시간 지연되었습니다.” 행동이 필요하기 때문에 정당한 방해입니다.
종료(Finish). 프로세스가 완료되었습니다. “주문이 배달되었습니다.” “결제가 완료되었습니다.” “목적지에 도착했습니다.” 루프를 마무리하고 Live Activity를 종료합니다.
시작과 종료 사이의 모든 것은 잠금 화면에 Live Activity로 유지됩니다: 조리 시간 카운트다운, 지도 위 라이더 이동, 점수 업데이트, ETA 재계산. 자동으로 업데이트되며, 방해는 전혀 없습니다.
실제 적용 사례: 배달 앱 주문 플로우
표준적인 배달 플로우를 변경 전후로 비교해봅니다. 한국에서는 배달의민족, 쿠팡이츠, 요기요 같은 앱에서 일반적으로 볼 수 있는 패턴입니다.
변경 전(푸시 전용 방식), 약 45분간 5개의 알림:
- 🔔 “주문이 접수되었습니다”
- 🔔 “음식이 조리 중입니다”
- 🔔 “라이더가 음식을 픽업했습니다”
- 🔔 “라이더가 근처에 도착했습니다”
- 🔔 “배달이 완료되었습니다”
점심 주문 한 건에 다섯 번의 방해. 주 23회 주문하면 앱 하나가 1015개의 알림을 보내는 셈입니다. 이 지점이 사용자가 알림을 아예 꺼버리기 시작하는 임계점입니다.
변경 후(3-푸시 룰 + Live Activity):
- 🔔 푸시: “주문이 접수되었습니다” → Live Activity 시작
- 📱 Live Activity가 조용히 업데이트: 조리 중 → 픽업 완료 → 라이더 위치 → ETA 카운트다운
- 🔔 푸시(필요 시에만): “라이더가 건물에 진입하지 못하고 있습니다. 앱을 확인해주세요”
- 📱 Live Activity: ETA 카운트다운 지속
- 🔔 푸시: “배달이 완료되었습니다” → Live Activity 종료
사용자는 5번의 방해에서 2번으로(문제가 있다면 3번) 줄어듭니다. 잠금 화면은 깔끔해지고, 실시간 가시성은 오히려 더 좋아집니다. 분산된 다섯 번의 핑 대신, 사용자는 수 초마다 새로고침되는 라이더 위치와 ETA가 담긴 연속적인 실시간 트래커를 보게 됩니다.
결과: 알림 차단율 감소, “내 주문 어디 있나요” 관련 고객 문의 감소, 그리고 앱이 다섯 번 깜빡이다 사라지는 대신 30~45분간 잠금 화면에 계속 노출됩니다.
업종별 적용 방법
같은 룰은 사용자가 실시간으로 무언가를 추적하는 모든 곳에서 작동합니다.
| 앱 유형 | 푸시: 시작 | Live Activity | 푸시: 예외 | 푸시: 종료 |
|---|---|---|---|---|
| 모빌리티 (카카오T 등) | 기사 배정 | 위치, ETA, 차량 정보 | 기사 취소 / 경로 변경 | 운행 완료 + 요금 |
| 이커머스 (쿠팡, 11번가) | 상품 출고 | 포장 → 배송 중 → 배송 출발 → 근처 도착 | 배송 지연 또는 실패 | 배송 완료 |
| 핀테크 (토스, 카카오페이) | 거래 시작 | 처리 상태 (해외 송금, 본인 인증) | 결제 실패 / 이상 거래 감지 | 거래 완료 |
| 게임 | 토너먼트 시작 / 에너지 회복 | 리더보드 순위, 보스 타이머, 진행도 | 상대 매칭 / 연승 위기 | 경기 결과 |
| 뉴스 & 미디어 (네이버, 다음) | 속보 / 라이브 이벤트 | 라이브 티커: 점수, 투표수, 헤드라인 | 주요 전개 | 이벤트 종료 |
각 사례에서 푸시 알림은 중요한 전환점을 표시하고, Live Activity는 그 사이의 상태를 이어줍니다.
스택을 재구축하지 않고 시작하는 방법
보통 이런 반론이 나옵니다: “Live Activities를 추가하려면 대규모 리팩토링이 필요합니다.” 실제로는 3단계 접근으로 한 스프린트 안에 충분히 들어갑니다.
-
현재 푸시 플로우 감사
하나의 실시간 여정(주문 추적, 운행, 경기 등)을 선택하고, 트리거되는 모든 푸시 알림을 나열하세요. 각각에 대해 확인합니다: 사용자가 무언가를 해야 하거나 새롭게 알아야 하는 내용인가, 아니면 스스로 확인 가능한 상태 업데이트인가? 일반적으로 5
7개 푸시 중 23개만 이 필터를 통과합니다. -
억제 및 대체
상태 업데이트 푸시를 끕니다. 시작 푸시 시점에 Live Activity를 실행하고, 종료 푸시 시점에 종료합니다. 이전에 푸시를 보내던 모든 지점에서 API를 통해 Live Activity를 업데이트합니다.
-
측정
2~4주간 세 가지 지표를 추적하세요. 알림 차단율은 감소해야 합니다. Live Activities가 셀프서비스 가시성을 제공하면서 '내 주문 어디 있나요' 관련 고객 문의 수가 줄어듭니다. 그리고 세션 빈도는 감소하는 대신 오히려 증가하는 경향이 있습니다. 활성 Live Activity가 있는 사용자는 잠금 화면이 재진입 포인트가 되기 때문에 앱을 더 자주 엽니다.
