금융 앱 그로스 팀이라면 이 상황이 낯설지 않을 겁니다. 사용자가 앱을 설치하고 회원가입 버튼을 눌렀습니다. 주민등록번호 인증, 계좌 연동, 약관 동의까지 3~5단계가 남아 있습니다. 그리고 2단계에서 앱을 닫습니다.
이 사람을 다시 잡을 수 있을까요?
ATT(앱 추적 투명성) 정책 도입 이후, iOS 사용자의 최대 96%가 앱 추적을 거부합니다. ADID(광고 식별자)가 없으니 기존 방식의 리타겟팅 광고는 작동하지 않습니다. 더 큰 문제는 금융 앱의 가입 절차 상당 부분이 인앱 웹뷰(WebView)로 구현된다는 점입니다. 빠른 업데이트와 유연한 UI 수정을 위해 웹 기반으로 가입 퍼널을 만들다 보니, 앱 영역과 웹 영역 사이에서 사용자 식별 정보가 단절됩니다.
결과적으로 마케팅팀은 "2단계에서 이탈한 사람이 몇 명인지"는 알아도, "그 사람이 앱을 다시 켰을 때 어떻게 말을 걸어야 하는지"를 모르는 상황에 처하게 됩니다.
가장 먼저 시도하는 방법은 자바스크립트로 쿠키를 심어 사용자를 식별하는 것입니다. 하지만 Safari와 iOS 웹뷰는 ITP(지능형 추적 방지) 정책으로 인해 자바스크립트가 생성한 쿠키의 유효기간을 최대 7일로 제한합니다. 가입 이탈 후 일주일이 지나면 식별자가 사라집니다.
일부 팀은 어트리뷰션 MMP나 서드파티 핑거프린팅 SDK를 활용합니다. 하지만 iOS 19+ 환경에서 Apple은 CNAME 클로킹(단순 도메인 별칭으로 추적 서버를 우회하는 방식)에 대한 모니터링을 강화했습니다. 서드파티 SDK가 수집한 데이터는 기업이 직접 통제하지 못하고, 금융 규제 환경에서 감사(Audit) 대응도 어렵습니다.
핵심 문제는 식별자가 없는 것이 아니라, 기업이 직접 소유하고 통제할 수 있는 식별자가 없다는 것입니다.
이 문제를 해결하는 구조는 세 개의 레이어로 구성됩니다.
[웹뷰 레이어]
sGTM 퍼스트 파티 쿠키(FPID) 발급
↓ JavaScript Bridge
[네이티브 앱 레이어]
Braze SDK 커스텀 속성 동기화
↓ S2S API
[CRM 레이어]
Braze 인앱 메시지 트리거 → 재가입 유도각 레이어가 어떻게 작동하는지 실무 관점에서 살펴보겠습니다.
sGTM(서버사이드 구글 태그 매니저)을 단순히 구글 클라우드에 올리는 것만으로는 부족합니다. 기업 자체 도메인의 서브도메인(예: analytics.yourfintech.com)으로 매핑해야 합니다.
이렇게 하면 서버 측에서 발급하는 쿠키가 퍼스트 파티 쿠키로 인식되어 ITP 제한을 받지 않습니다. 클라이언트 자바스크립트가 만든 쿠키가 아니라, 서버가 직접 Set-Cookie 헤더로 내려주는 HTTP-only 쿠키이기 때문입니다. 유효기간을 최대 2년으로 설정할 수 있습니다.
analytics.yourfintech.com)을 sGTM 서버 IP로 매핑하고 SSL 인증서를 발급합니다.HttpOnly, Secure, SameSite=Lax 플래그를 설정합니다. 금융 앱 보안 규정상 XSS 공격으로 인한 식별자 탈취를 방지하는 필수 조건입니다.이렇게 발급된 쿠키를 FPID(First Party ID)라고 부릅니다. 이것이 이후 모든 식별의 기준점이 됩니다.
웹뷰에서 발급된 FPID를 네이티브 앱이 알아야 브레이즈에 전달할 수 있습니다. 이 연결을 자바스크립트 브릿지(JavaScript Bridge)가 담당합니다.
가입 웹뷰가 로드될 때 아래 코드가 실행됩니다. sGTM이 심어둔 FPID 쿠키 값을 읽어 네이티브 앱으로 전송합니다.
function getCookie(name) {
const value = `; ${document.cookie}`;
const parts = value.split(`; ${name}=`);
if (parts.length === 2) return parts.pop().split(';').shift();
}
const fpid = getCookie('FPID');
if (fpid && window.webkit && window.webkit.messageHandlers.sendGtmClientId) {
window.webkit.messageHandlers.sendGtmClientId.postMessage(fpid);
}func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) {
if message.name == "sendGtmClientId", let clientId = message.body as? String {
Appboy.shared()?.user.setCustomAttributeWithKey("webview_anonymous_id", andStringValue: clientId)
}
}이 코드가 실행되면 브레이즈 사용자 프로필에 webview_anonymous_id 속성이 저장됩니다.
네트워크 불안정이나 앱 초기 로딩 지연으로 브릿지 전송이 누락될 수 있습니다. 웹뷰 스크립트에 재시도(Retry) 로직과 Fallback ID(로컬 스토리지 기반 임시 식별자)를 반드시 구현해야 합니다. 이 부분을 빠뜨리면 데이터 유실률이 예상보다 훨씬 높아집니다.
사용자가 웹뷰 내에서 각 단계를 진행할 때마다(약관 동의 완료, 인증 실패, 계좌 연동 이탈 등) sGTM으로 이벤트를 발송합니다. sGTM 컨테이너 내 Braze Tag Template을 활용해 이 이벤트를 브레이즈 REST API(/users/track)로 서버 간(S2S) 전송합니다.
이때 사용자 식별자로 앞서 발급한 webview_anonymous_id(FPID)를 매핑합니다. ADID가 없어도 됩니다.
브레이즈 대시보드에서 다음 조건으로 캠페인을 구성합니다.
트리거 조건: Session Start — 사용자가 앱을 다시 실행하는 순간
타겟 오디언스 필터:
webview_anonymous_id 속성 값이 존재함 (웹뷰 가입 시도 이력 있음)is_registered 속성이 false이거나 존재하지 않음 (가입 미완료)abandoned_at_step_2)메시지 내용: "OO님, 가입을 마저 완료하고 혜택을 받아보세요!" + 이탈 지점 딥링크
브레이즈 공식 데이터에 따르면, 인앱 메시지를 수신한 사용자는 수신하지 않은 사용자보다 참여율이 131% 높습니다. 개인화된 Custom HTML 인앱 메시지는 일반 캠페인 대비 평균 27% 높은 전환율을 기록합니다.
사용자가 최종적으로 가입을 완료하면, 브레이즈의 changeUser API를 호출해 webview_anonymous_id(익명 식별자)와 내부 회원 ID(Secure External ID)를 안전하게 병합합니다. 이 단계가 없으면 익명 사용자와 가입 완료 사용자가 분리된 채로 남아 데이터가 중복됩니다.
| 구분 | 기존 방식 | sGTM FPID × Braze 하이브리드 |
|---|---|---|
| 식별자 | ADID (ATT 동의 필요) | sGTM 퍼스트 파티 쿠키 UUID |
| 쿠키 수명 | 클라이언트 JS: 최대 7일 | 서버 HTTP-only: 최대 2년 |
| 데이터 소유권 | 서드파티 SDK 의존 | 기업 자체 인프라 완전 통제 |
특히 금융·핀테크 환경에서 데이터 소유권은 규제 감사 대응과 직결됩니다. sGTM 인프라는 어떤 데이터가 어디로 흐르는지 기업이 직접 확인하고 차단할 수 있습니다.
HttpOnly + Secure + SameSite=Lax 필수 설정Q1. ADID 동의를 아예 받지 못한 사용자도 이 구조로 타겟팅할 수 있나요?
네. 이 구조의 핵심이 바로 그 점입니다. ADID 없이도 sGTM이 발급한 퍼스트 파티 쿠키(FPID)로 웹뷰 내 사용자를 식별하고, 브레이즈 인앱 메시지로 재가입을 유도합니다. 단, 사용자가 앱을 완전히 삭제하고 재설치하면 식별자가 초기화됩니다.
Q2. sGTM 구축 비용이 부담스럽습니다. 꼭 필요한가요?
Stape 같은 관리형 서비스를 활용하면 GCP 직접 운영보다 초기 비용을 낮출 수 있습니다. 다만 금융 앱의 경우 보안 감사와 데이터 통제 요건 때문에 자체 인프라가 장기적으로 유리합니다. 트래픽 규모와 보안 요건에 따라 판단하세요.
Q3. 브레이즈 없이 다른 CRM 툴로도 같은 구조를 만들 수 있나요?
가능합니다. 브레이즈 대신 Clevertap, Insider 등 인앱 메시지와 S2S API를 지원하는 CRM이라면 동일한 원리로 구현할 수 있습니다. 다만 브레이즈는 sGTM 전용 Tag Template이 공식 지원되어 연동 공수가 상대적으로 적습니다.
Q4. 웹뷰-네이티브 브릿지 구현은 개발팀 없이 가능한가요?
이 부분은 iOS 개발자가 반드시 참여해야 합니다. WKUserContentController 설정과 Swift 수신 코드는 네이티브 개발 영역입니다. 마케팅팀 단독으로는 구현할 수 없으며, 기획 단계에서 개발팀과 함께 설계하는 것이 중요합니다.
Q5. 이 구조가 애플 앱스토어 정책을 위반하지 않나요?
퍼스트 파티 쿠키는 ATT 정책의 규제 대상이 아닙니다. ATT는 기기 간 추적(Cross-app tracking)을 위한 ADID 수집을 규제하는 것이며, 자사 서비스 내 사용자 식별을 위한 퍼스트 파티 데이터 수집은 허용됩니다. 단, 개인정보 처리방침에 명확히 고지해야 합니다.
ATT 이후 금융·핀테크 앱의 가입 퍼널 이탈 문제는 "광고 소재를 바꾼다"거나 "리타겟팅 예산을 늘린다"고 해결되지 않습니다. 식별 인프라 자체를 재설계해야 합니다.
sGTM 퍼스트 파티 쿠키로 웹뷰 이탈자를 잡고, 자바스크립트 브릿지로 네이티브 앱에 연결하고, 브레이즈 인앱 메시지로 재가입을 유도하는 이 구조는 서드파티 SDK 의존에서 벗어나 기업이 직접 데이터를 소유하고 통제하는 방향으로의 전환입니다.
구조 자체는 복잡하지 않지만, 금융 보안 요건과 iOS 정책 변화를 동시에 고려하면서 구현하는 과정에서 놓치기 쉬운 지점들이 많습니다.
에이달(ADALL)은 금융·핀테크 앱의 sGTM 퍼스트 파티 데이터 인프라 구축부터 브레이즈 인앱 메시지 캠페인 설계까지 전 과정을 함께합니다. 현재 가입 퍼널 이탈 문제를 겪고 있다면, 구체적인 아키텍처 검토를 위해 문의해 주세요.
📞 02-2664-8631 | 📧 master@adall.co.kr
무료 컨설팅 받아보고 싶다면?
무료 컨설팅 신청하기