12CODE
지금 읽는 곳 웹뷰 결제에서 전환이 사라지는 근본 원인은 무엇인가 1 / 5
12code 라이브러리 아티클 표지. 모바일 앱 웹뷰(WebView) 결제 시 세션이 끊겨 전환 추적이 누락되는 웹-앱 브릿지 스크립트 에러 해결법
S2› 데이터기술› 과목 246› 레슨 03

모바일 앱 웹뷰(WebView) 결제 시 세션이 끊겨 전환 추적이 누락되는 웹-앱 브릿지 스크립트 에러 해결법

앱에서 결제는 정상적으로 끝났는데 전환만 사라진다면, 웹뷰와 네이티브 사이의 브릿지가 끊긴 것입니다.

이 과목 03 / 12편 고급 4분
과목 ID246
트랙S2
모듈데이터기술
레슨03
난이도고급
플랫폼공통
발행일2026-09-01
검토일2026-09-01
관련 과목66 · 84 · 111
출처4건
핵심요약5개
01

웹뷰 안 자바스크립트는 네이티브 SDK에 직접 접근할 수 없어 브릿지를 거쳐야 한다

02

안드로이드는 addJavascriptInterface로 등록한 AnalyticsWebInterface 객체를 경유한다

03

iOS는 firebase라는 이름으로 등록한 WKScriptMessageHandler에 postMessage로 전달한다

04

브릿지 객체 이름이나 메서드 시그니처가 어긋나면 오류 없이 조용히 전량 누락된다

05

누락을 수동 로깅으로 메울 때는 중복 집계 여부를 주문번호 단위로 함께 검증해야 한다

01

웹뷰 결제에서 전환이 사라지는 근본 원인은 무엇인가

가장 흔한 오해가 "웹뷰도 결국 브라우저니까 웹 태그가 그대로 돌 것"이라는 가정입니다. Google Analytics for Firebase 공식 문서가 안내하는 구조는 다릅니다. 웹뷰 안에서 실행되는 자바스크립트 코드는 네이티브 Firebase Analytics에 직접 접근할 수 없고, 자바스크립트 핸들러가 플랫폼을 판별해 네이티브 브릿지로 데이터를 넘기면 네이티브 구현이 Firebase Analytics를 호출하는 3단 구조를 거칩니다.

즉 앱 안에 웹 결제 페이지를 띄웠을 때, 그 페이지의 전환 이벤트는 기본적으로 앱 세션과 이어지지 않습니다. 브릿지를 구현하지 않았다면 이벤트는 앱 쪽에 존재하지 않고, 웹 쪽으로 보내더라도 앱 사용자로 집계되지 않습니다. "가끔 누락"이 아니라 "구조적으로 안 잡히는" 문제이므로, 원인을 태그 설정이나 네트워크에서 찾으면 시간을 잃습니다.

02

안드로이드 쪽 브릿지는 어떻게 구성되나

안드로이드에서는 네이티브 코드가 addJavascriptInterface로 자바스크립트 인터페이스를 등록합니다. 공식 예시에서 등록 이름은 AnalyticsWebInterface이며, 해당 클래스는 @JavascriptInterface로 표시된 두 메서드를 노출합니다. 하나는 logEvent(String name, String jsonParams)이고 다른 하나는 setUserProperty(String name, String value)입니다.

웹 페이지 쪽에서는 window.AnalyticsWebInterface.logEvent(name, JSON.stringify(params)) 형태로 호출합니다. 여기서 실무 사고가 나는 지점은 세 곳입니다. 등록 이름 오타, 매개변수를 객체 그대로 넘겨서 문자열 직렬화가 빠진 경우, 그리고 결제 완료 페이지가 웹뷰가 아닌 외부 브라우저나 PG사 도메인으로 벗어나 브릿지 객체가 존재하지 않는 경우입니다. 특히 세 번째는 코드가 멀쩡한데도 값이 안 잡히는 대표적 원인입니다.

03

iOS 쪽 브릿지는 어떻게 다른가

iOS는 WKWebView에 WKScriptMessageHandler를 firebase라는 이름으로 등록하는 방식입니다. 웹 페이지는 window.webkit.messageHandlers.firebase.postMessage()로 command 값이 logEvent 또는 setUserProperty인 객체를 전달하고, 네이티브 핸들러가 이를 받아 Firebase Analytics를 호출합니다.

호출 형태 자체가 안드로이드와 완전히 다르다는 점이 중요합니다. 웹 페이지 스크립트는 두 인터페이스의 존재를 각각 확인해 분기해야 하며, 한쪽만 구현하면 다른 OS에서 전량 누락됩니다. 실제로 "안드로이드는 잡히는데 iOS만 0건"으로 나타나는 사례 대부분이 이 분기 누락입니다. 진단할 때 OS별로 전환 건수를 나눠 보는 것만으로 원인 범위가 절반으로 줄어듭니다.

04

어떤 순서로 진단해야 원인을 좁힐 수 있나

순서를 지키는 것이 중요합니다. 첫째, 결제 완료 시점의 화면이 여전히 앱 웹뷰 안인지, 외부 브라우저로 이탈했는지 확인합니다. 둘째, OS별로 전환 건수를 분리해 한쪽만 0인지 양쪽 다 0인지 봅니다. 셋째, 웹뷰 안에서 브릿지 객체가 실제로 존재하는지(안드로이드는 window.AnalyticsWebInterface, iOS는 window.webkit.messageHandlers.firebase) 개발팀과 함께 확인합니다. 넷째, 이벤트 이름과 매개변수 규격이 GA4 제약 안에 있는지 점검합니다.

네 번째 단계에서 자주 걸립니다. GA4는 이벤트 이름 40자, 이벤트당 매개변수 최대 25개, 매개변수 이름 40자, 매개변수 값은 일반적으로 100자로 제한합니다. 결제 페이지에서 상품 정보를 통째로 넘기다 값이 잘리면 이벤트는 들어오는데 전자상거래 보고서에 제대로 뜨지 않습니다. 구매 이벤트는 items 배열에 item_id, item_name, price, quantity를 필수로 포함해야 하고, 필수 매개변수가 빠지면 커스텀 이벤트로 처리돼 전자상거래 보고서에 표시되지 않습니다.

05

수정한 뒤에는 무엇을 검증해야 하나

누락을 고쳤다면 이번에는 반대 방향의 사고를 확인해야 합니다. Firebase 웹뷰 문서는 iOS에서 SDK가 가능한 경우 인앱 구매를 계속 자동 기록하며, 수동으로 기록한 인앱 구매 이벤트를 중복 제거하지 않는다고 명시합니다. 누락을 메우려고 수동 로깅을 덧붙였다가 자동 기록과 겹치면 구매가 두 번 집계됩니다.

그래서 검증은 주문번호 단위 유일성으로 합니다. 수정 배포 후 최소 며칠간, 결제 시스템의 주문번호 목록과 분석 도구의 구매 이벤트를 주문번호 기준으로 대조해 일대일로 맞는지 확인합니다. 여기서 한 주문번호가 두 건으로 잡히면 중복이고, 결제 시스템에만 있고 분석 도구에 없으면 여전히 누락입니다. 이 대조표를 만들지 않고 대시보드 총합만 보면 누락과 중복이 서로를 가려 숫자가 맞아 보이는 상황이 생깁니다.

다음 행동

결제 완료 화면을 안드로이드와 iOS 실기기에서 각각 열어, 웹뷰 안에서 브릿지 객체가 존재하는지 개발팀과 함께 확인하세요. 한쪽만 없다면 그 OS의 분기 구현이 빠진 것입니다.

다음 글 · 레슨 04→GA4·광고 플랫폼 원시 데이터를 BigQuery로 적재하는 ETL 파이프라인 기본 구조

← 이전 글 · 레슨 02 조직 간 데이터 거버넌스 실행 전 법무·개인정보·브랜드팀과 합의해야 할 체크리스트

CHALLENGE

배운 걸 실전 문제로 확인

카테고리별 Level Test로 실무 레벨을 점검해보세요.

챌린지 보기 →

MKT TOOLS

실무자를 위한 무료 도구

카피 글자수 검사, CPC·ROAS 계산기, UTM 생성기까지.

워크스페이스 열기 →