쓰고 있는 고객 참여 플랫폼에 네이티브 월렛 패스가 없다면 길은 2가지입니다. 패스 도구를 연결하고 두 시스템을 계속 동기화하거나, 같은 고객 프로필 위에서 Apple Wallet과 Google Wallet 패스를 발급하는 플랫폼으로 옮기는 것입니다. 첫 번째는 시작이 빠르고, 두 번째는 월렛이 고객 여정의 일부가 된 뒤 운영이 단순합니다. 월렛 패스 연동을 고민 중이라면 이 차이부터 정리하는 것이 좋습니다.
이 글은 Braze, OneSignal, CleverTap 같은 플랫폼을 쓰면서, 모든 것을 갈아엎지 않고 월렛 패스를 더하고 싶은 팀을 위해 썼습니다. 공급업체 단위의 비교는 월렛 패스 비교 페이지에서 볼 수 있습니다.
지금 어디에서 출발하는가
고객 참여 플랫폼마다 월렛 지원 수준은 크게 다릅니다. Braze는 PassKit 같은 파트너를 통해 월렛을 붙입니다. OneSignal에는 네이티브 월렛 패스가 없습니다. 이 내용은 바뀌므로, 계획을 세우기 전에 쓰고 있는 플랫폼의 최신 문서를 확인하세요.
네이티브 지원이 없으면 패스는 한 시스템에, 고객은 다른 시스템에 있습니다. 패스를 발급하고, 업데이트하고, 타기팅할 때마다 양쪽 데이터가 모두 필요합니다.
한국 이커머스 앱이라면 장바구니 이탈 알림, 프로모션 푸시, 재구매 유도가 이미 지금 플랫폼에서 돌아가고 있을 가능성이 큽니다. 그래서 질문은 “월렛을 쓸까”가 아니라 “이미 돌아가는 캠페인 옆에 월렛을 어떻게 붙일까”가 됩니다.
방법 A: 지금 쓰는 고객 참여 플랫폼에 패스 도구 추가하기
푸시, 이메일, 세그먼트는 지금 플랫폼에 그대로 두고, Apple Wallet과 Google Wallet용 단독 패스 도구를 연결하는 방식입니다.
보통은 이렇게 작동합니다. 고객 참여 플랫폼이나 백엔드가 웹훅 등을 통해 패스 도구의 API를 호출해 패스를 발급합니다. 패스 도구가 이벤트를 제공한다면, 그 이벤트를 다시 고객 참여 플랫폼으로 보내 패스 보유자를 세그먼트할 수 있습니다.
장점은 분명합니다. 마이그레이션할 것이 없습니다. 팀은 쓰던 도구와 고객 여정을 그대로 유지하고, 멤버십 카드 같은 활용 사례 하나로 시작할 수 있습니다.
단점은 시간이 지나며 쌓입니다. 동기화할 데이터베이스 2개, 구독 2건, 보안 및 GDPR 검토 2번. “포인트가 곧 소멸됩니다”처럼 패스 업데이트와 메시지를 묶는 시나리오는 모두 두 도구에 걸쳐 만들어야 합니다.
방법 B: 네이티브 월렛을 갖춘 플랫폼으로 옮기기
메시징을 월렛 패스를 네이티브로 발급하는 플랫폼으로 옮기는 방식입니다. 패스는 푸시, 인앱, 이메일, SMS와 같은 프로필 위에 있습니다.
패스는 플랫폼 안에서 User ID로 발급됩니다. 세그먼트, 고객 여정, 채널 모두 패스 보유자를 한 명의 고객으로 봅니다. 고객 여정의 한 단계가 패스를 발급하고, 다음 단계가 링크를 보냅니다.
프로필도, 고객 여정도, 계약도 하나입니다. 패스 업데이트와 메시지가 같은 트리거에서 나가고, 계속 지켜봐야 하는 동기화 레이어가 없습니다.
비용은 마이그레이션 자체입니다. SDK 교체, 데이터 가져오기, 고객 여정과 템플릿 재구성이 필요합니다. 월렛이 일회성 캠페인이 아니라 장기 채널일 때 그 비용이 회수됩니다.
| 방법 A: 고객 참여 플랫폼 + 패스 도구 | 방법 B: 네이티브 월렛 | |
|---|---|---|
| 첫 패스까지 걸리는 시간 | 빠름 | 마이그레이션 규모에 따라 다름 |
| 관리할 시스템 | 2개와 동기화 레이어 | 1개 |
| 패스 업데이트가 들어간 고객 여정 | 두 도구에 걸쳐 구성 | 고객 여정 1개 |
| 패스 보유자 세그먼트 | 동기화된 데이터로 | 같은 프로필에서 |
| 계약과 공급업체 심사 | 2건 | 1건 |
| 잘 맞는 경우 | 월렛 활용 사례가 하나뿐일 때 | 월렛을 리텐션 채널로 쓸 때 |
판단 기준
4가지 질문으로 스스로 점검해 보세요.
-
범위
월렛은 캠페인 1건인가요, 몇 년간 운영할 채널인가요? 캠페인 1건이라면 방법 A가 맞습니다.
-
채널
패스와 푸시, 이메일, SMS를 함께 쓰는 시나리오가 몇 개인가요? 많다면 방법 B 쪽입니다.
-
팀
동기화 레이어를 만들고 유지할 개발자가 있나요? 없다면 방법 A는 시간이 갈수록 비싸집니다.
-
데이터 위치
GDPR을 위해 EU 호스팅과 더 적은 수탁자가 필요한가요? 공급업체가 하나 늘 때마다 검토할 수탁자도 하나 늘어납니다.
답 중 2개 이상이 “장기”, “많음”, “개발자 없음”, “수탁자는 적게”라면 방법 B를 진지하게 검토하세요. 하나도 없다면 방법 A도 충분히 좋은 선택이며, 1년 뒤에 다시 판단하면 됩니다.
개인정보 보호에 매우 민감한 한국 시장에서는 네 번째 질문의 무게가 특히 큽니다. 핀테크 앱처럼 보안팀 승인이 출시 일정을 좌우하는 곳이라면, 검토해야 할 공급업체와 수탁자가 하나 줄어든다는 점이 그대로 일정에 반영됩니다.
도구 2개의 비용 계산하기
방법 A는 아무것도 옮기지 않으니 첫날에는 더 저렴해 보입니다. 1년 단위로 보면 패스 공급업체 청구서에 나오지 않는 항목을 더해야 합니다. 연동 개발, 동기화 유지, 중복되는 고객 여정 작업, 두 번째 공급업체 심사입니다.
방법 B는 비용이 앞에 몰립니다. 마이그레이션 작업 후에는 플랫폼 요금 하나입니다. 1개월이 아니라 12~24개월 기준으로 두 방법을 비교하세요.
설날과 추석, 빼빼로데이처럼 시즌 캠페인이 잦은 팀이라면 이 계산에 시즌마다 반복되는 작업도 넣으세요. 방법 A에서는 시즌 쿠폰 패스와 프로모션 푸시를 매번 두 도구에서 따로 준비하고 맞춰야 합니다.
마이그레이션 체크리스트
방법 B를 고른다면 도구가 아니라 고객을 중심으로 이전을 계획하세요.
- 보내고 있는 것을 점검하세요. 옮겨야 할 푸시, 이메일, SMS, 인앱 캠페인과 고객 여정, 세그먼트를 목록으로 만드세요.
- 데이터를 매핑하세요. User ID, 태그, 이벤트, 수신 동의 기록입니다. 패스를 고객과 연결하는 것은 User ID입니다.
- 월렛 설정은 한 번만. Apple Pass Type ID 인증서(Apple Developer 계정, 연 $99)와 Google Issuer ID가 필요하며, 발급자 계정에 Pushwoosh 서비스 계정을 초대해야 합니다. 원화 예산을 잡을 때는 확인한 날의 환율로 다시 계산해 두세요.
- SDK를 연동하세요. 앱의 기존 SDK를 교체하고, 트래픽을 옮기기 전에 푸시를 테스트하세요.
- 핵심 고객 여정부터 다시 만드세요. 웰컴, 장바구니 이탈, 복귀 유도 순서로, 그다음 새 월렛 시나리오입니다.
- 패스 출시를 계획하세요. 고객 여정 단계에서 패스를 발급하고 이메일, SMS, 푸시로 링크를 보내세요.
- 잠시 병행 운영하세요. 기존 플랫폼을 짧게 겹쳐 쓴 뒤 끄세요.
이전하는 동안에는 자체 백엔드에서 API로 패스를 발급하세요.
Pushwoosh로 스택을 단순하게
Pushwoosh는 푸시, 인앱, 이메일, SMS, WhatsApp과 같은 User ID, 세그먼트, 고객 여정 위에서 네이티브 Apple Wallet과 Google Wallet 패스를 발급합니다. 독일과 미국에 있는 자체 인프라에서 호스팅되는 하나의 플랫폼이며, GDPR을 준수하고 SOC 2 Type 2 인증을 받았습니다. 월렛 옵션 사이에서 Pushwoosh의 위치를 확인해 보세요.
월렛을 더한다는 것이 도구를 하나 더 붙인다는 뜻이어서는 안 됩니다. 모든 채널이 움직일 수 있는 하나의 고객 프로필이어야 합니다.
