후기 탐색을 주문 시작으로 잇기 위한 운송후기 탭 실험

운송은 신청한 뒤 조건을 바꾸기 쉽지 않습니다. 고객은 평점보다 먼저 자기 짐과 비슷한 운송 사례를 찾고 싶어 합니다. 냉장고나 침대를 옮긴 경험이 있는지, 어떤 작업 조건이었는지, 파손이나 추가요금은 없었는지가 주문 판단에 필요합니다.

센디에는 후기가 수만 건 있었지만, 고객이 자기 짐과 가까운 사례를 찾는 경로는 홈 일부 영역과 지역별 목록에 흩어져 있었습니다. 후기의 양이 쌓여도 주문 전에 필요한 사례를 찾기 어렵다면 판단 근거로 이어지지 않습니다. 저는 후기 탐색의 진입점과 탐색 기준을 함께 바꿔야 한다고 봤습니다.

이 작업에서 처음으로 문제의 진행과 결과를 맡는 실무 책임자(Directly Responsible Individual, DRI)를 맡았습니다. 제가 세운 가설은 상시 진입점에서 지도와 오더 유형별 후기, 검색, 사진 필터를 제공하면 고객이 자기 상황과 가까운 사례를 찾고 주문을 시작한다는 것이었습니다. 후기 조회 수는 탐색이 일어났다는 신호일 뿐 주문 판단까지 이어졌는지 말해주지 않습니다. 그래서 오더폼 진입과 체크아웃에 연결되는 행동을 주요 결과로 두고, 탐색 지표와 구분했습니다.

이 글에서는 탭을 상시 진입점으로 택한 이유와 그 선택에 따른 제품·기술 비용, 실험에서 확인한 변화와 확인하지 못한 범위를 설명합니다.

운송후기 탭이 풀려던 문제

후기는 운송 경험을 미리 가늠하는 자료였습니다. 평점만으로는 내가 맡기려는 짐이나 작업 조건을 판단하기 어렵습니다. 당시 목록은 지역을 기준으로 볼 수 있었지만, 지역 안에서 오더 유형을 좁혀 찾거나 검색하고 사진이 있는 후기만 모아 보는 흐름은 한곳에 있지 않았습니다.

그래서 전국의 후기 분포를 지도에서 보여주고, 지역을 고르면 해당 지역의 후기와 오더 유형을 이어서 탐색하는 화면을 구상했습니다. 지도는 흩어진 후기를 지역 맥락으로 훑고 탐색을 시작하게 하는 입구였습니다. 동시에 지도에는 지역별 후기 수만 표시했습니다. 운송 건수가 아닌 후기 수를 지도에 올리면 후기 작성 성향까지 서비스 규모처럼 보일 수 있었습니다. 따라서 지도는 지역을 고르는 탐색 도구로 한정하고, 고객이 실제 판단에 쓸 짐과 작업 조건은 후기 목록에서 좁혀 보도록 설계했습니다.

전국 지도에 지역별 운송후기 수를 표시하고, 선택한 부산 지역의 후기 목록과 오더 유형을 보여주는 실제 앱 화면
운송후기 탭의 중심 화면입니다. 지도에서 지역을 고르면 해당 지역의 후기와 오더 유형을 이어서 볼 수 있습니다.

검토한 방향은 홈의 후기 영역을 넓히거나, 기존 지역별 목록을 보강하거나, 후기 탐색을 별도 탭으로 만드는 것이었습니다. 홈 영역을 넓히면 적은 변경으로 노출을 늘릴 수 있지만 홈에서만 발견됩니다. 지역 목록을 보강하면 기존 구조를 유지하는 대신 오더 유형, 검색, 사진 필터를 한 번에 시작할 고정 진입점은 만들기 어렵습니다. 별도 탭은 어디서든 접근하기 쉽지만 메인 탭바의 자리를 계속 차지합니다. 이 자리가 다른 주요 기능보다 가치 있다는 보장은 없었습니다. 그래서 탭 방문 수를 성과로 삼지 않고, 주문 흐름에 차이가 생기는지를 실험으로 확인하기로 했습니다.

저는 별도 탭을 실험 변수로 정했습니다. 지도와 오더 유형 선택을 중심에 두고, 검색과 사진 필터로 품목이나 작업 조건에 가까운 후기를 찾게 했습니다. 이 구성은 고객이 후기 탐색을 발견하고 원하는 사례를 좁히는 과정을 한 진입점 안에 담는 선택이었습니다. 대신 한 번의 실험으로 탭 자체와 각 탐색 기능의 효과를 나눠 알 수 없었습니다. 우선 탭 경험 전체가 주문 시작에 기여하는지를 확인하고, 결과가 보이면 세부 기능을 분리해 검증하는 순서를 택했습니다.

지역 지도와 짐 종류 카드를 비교하며 고객 관점의 탐색 축을 고민하는 제품 담당자 삽화
지역 지도는 시작점이었습니다. 실제로 검증할 가정은 후기가 주문 판단에 도움이 되는지였습니다.

실험 변수와 대조군

A와 B를 가른 변수는 운송후기 탭을 상시 진입점으로 추가했는지 여부였습니다. A는 기존 3개 탭을 유지했고, B는 더보기 앞에 운송후기 탭을 추가했습니다.

기존 화면과 운송후기 탭 화면을 나란히 놓고 고객을 A와 B 두 그룹으로 나눠 비교하는 A/B 실험 삽화
기존 탭과 운송후기 탭 경험을 두 고객 그룹으로 나눠 비교했습니다.

실험 대상은 로그인한 스탠다드 플랜 고객이었습니다. Hackle 설정에서 사용자 ID 기준 배정을 확인했습니다. 같은 사용자가 어느 경로로 들어와도 같은 경험을 보도록, 탭 구성과 홈 후기 영역의 전체 보기 동작에 동일한 실험군을 적용했습니다. A는 기존 후기 목록을 열고 B는 운송후기 탭을 열었습니다. 탭은 A인데 홈의 전체 보기는 B 화면을 여는 식으로 갈라지면 비교 조건이 달라지기 때문입니다.

이 실험은 지도 하나의 효과를 보는 실험이 아니었습니다. B에는 탭, 지도, 오더 유형 탐색, 검색, 사진 필터, 후기 상세와 예약 연결이 함께 들어갔습니다. 이 묶음은 실제로 제안한 탭 경험이 주문 시작에 영향을 주는지는 볼 수 있지만, 결과가 달라져도 어떤 요소가 차이를 만들었는지는 분리하지 못합니다. 첫 실험의 질문은 탭 경험 전체를 제공했을 때 주문 흐름이 달라지는지였습니다. 기능별 효과는 다음 실험에서 나눠 봐야 했습니다.

실제 검색 화면은 지도와 별도 경로로 열었습니다. 최근 검색어와 추천어에서 탐색을 시작하고, 검색 결과에서는 사진이 첨부된 후기만 남길 수 있었습니다. 지도에서 지역과 오더 유형을 고르는 흐름에 검색과 사진 필터를 더해, 고객이 자기 상황에 가까운 사례를 좁혀 볼 수 있도록 했습니다.

운송후기 검색어와 추천 검색어 화면, 냉장고 검색 결과에서 사진 있는 후기만 남긴 화면을 나란히 배치한 실제 앱 캡처
검색으로 품목 후기를 찾고, 사진이 있는 후기만 골라 확인할 수 있었습니다.

iOS 탭과 웹 화면의 역할 분리

지도와 검색 화면은 실험 중에도 조정될 수 있어 앱 안의 WKWebView로 구성했습니다. 네이티브 화면은 탭과 화면 상태를 한곳에서 관리할 수 있지만, UI 수정에 앱 배포가 필요합니다. 웹 화면은 수정 주기를 줄이는 대신 앱과 웹이 상태와 이동을 나눠 관리해야 합니다. 이 실험에서는 탐색 구성을 빠르게 조정하는 편을 택했습니다. 앱은 탭, 로그인, 위치 권한과 예약·상세 이동을 맡고 웹은 지도와 후기 탐색을 그리도록 경계를 뒀습니다. 앱과 웹에 상태가 나뉘는 비용은 이 경계 안에서 관리해야 했습니다.

네이티브 앱 화면과 웹 페이지를 분리해 조정하는 과정을 보여주는 개념 삽화
지도와 검색 화면을 수정해도 앱의 탭 이동 흐름은 유지했습니다.

이 분리에는 비용이 있었습니다. 검색은 별도 화면으로 열고, 후기 상세에서 돌아왔을 때 검색 상태를 유지해야 했습니다. 위치 권한도 앱에서 다루되, 첫 화면의 주변 지역 자동 선택은 권한이 이미 허용된 경우에만 했습니다. 고객이 현재 위치를 직접 요청하는 경우에 권한을 확인했습니다.

주문 흐름을 기준으로 한 측정

초기 PRD는 오더폼 진입율과 체크아웃 전환율이 기존 기준보다 5% 이상 높아지는지를 목표로 두었습니다. 탭 진입, 지역 선택, 유형 필터, 검색, 후기 상세, 예약 시작은 어느 단계에서 탐색이 이어지는지 보는 진단 지표였습니다. 지도 확대나 후기 열람을 성공으로 두지 않은 이유는 화면을 오래 보는 것과 주문을 시작하는 것이 같은 결과가 아니기 때문입니다.

결과는 Mixpanel의 사용자 기준 7일 전환으로 확인했습니다. 제가 확인한 요약 자료에는 체크아웃 시작과 구매 전환 수치가 있었고, 오더폼 진입률은 별도 결과로 기록돼 있지 않았습니다. PRD의 오더폼 진입율·체크아웃 전환율 목표와 이 결과 지표가 어떻게 연결되는지도 확인하지 못했습니다. 그룹별 분모와 신뢰구간도 자료에 없어 검정의 정밀도를 독립적으로 재현할 수 없었습니다. 따라서 기록된 A/B 지표를 보고하고 PRD의 5% 목표 달성 여부는 판정하지 않았습니다.

탭 노출과 선로딩

화면 동작을 계측하려면 먼저 실제 노출과 선로딩을 구분해야 했습니다. 운송후기 화면은 앱 진입 때 미리 로드해 탭을 눌렀을 때 빈 화면을 줄였습니다. 이 선택은 첫 화면을 빨리 보여주는 대신, 화면이 준비된 시점과 고객이 실제로 본 시점이 달라지는 문제를 만들었습니다. 선로딩을 방문으로 세면 탭을 보지 않은 사람까지 방문자 분모에 들어갑니다.

제가 맡은 iOS 연결부에서는 viewDidAppear 시점에 탭이 실제로 보인다는 신호를 웹에 전달했습니다.

탭이 먼저 보이고 웹 문서가 나중에 로드되면 처음 보낸 신호는 사라진 문서에 남습니다. 웹은 계속 선로딩 중이라고 판단해 실제 진입을 기록하지 못했습니다. 그래서 didFinish 때도 탭이 보이는 중이면 신호를 다시 보냈습니다. 선로딩의 응답 속도를 유지하면서 노출 계측의 분모가 부풀거나 빠지는 문제를 줄이려는 처리였습니다.

iOS에서 WKWebView를 미리 준비하고, 고객이 탭을 실제로 볼 때 가시성 신호를 전달하며 웹 로딩이 늦으면 현재 상태를 다시 전달하는 흐름도
화면 선로딩과 실제 노출을 구분하고, 웹 로딩이 늦어져도 현재 탭 상태를 전달했습니다.

실험 전에 탭 첫 진입 속도와 바로 나가는 비율도 가드레일로 정했습니다. 선로딩은 기다림을 줄이지만, 실제 노출 신호와 맞지 않으면 계측을 왜곡합니다. 지도 로딩이 느려 바로 나가는 사용자가 늘어도 체크아웃 지표만으로는 새 탭 경험을 성공이라고 부를 수 없습니다.

체크아웃 시작과 구매 전환의 차이

2026년 8월 17일부터 9월 3일까지의 결과입니다. 체크아웃 시작률은 A 51.4%, B 54.9%였습니다. B가 3.5%p, 상대 기준 6.8% 높았습니다. 실험 결과 요약에 기록된 두 비율 z검정의 p값은 약 0.004였습니다. 자료에 그룹별 분모와 신뢰구간은 없어 효과 크기의 정밀도를 독립적으로 판단하기 어렵습니다.

구매 전환은 A 16.7%, B 17.8%로 1.1%p 차이가 났지만 p값은 약 0.22였습니다. 체크아웃 이후 구매율은 두 그룹 모두 32%였습니다. 결과 자료에서 차이가 확인된 지점은 체크아웃 시작률입니다. 구매 개선이나 탭 안의 개별 기능 기여를 확인한 것은 아니며, 대시보드의 사용자 수 증감도 전환 결과와 분리해 해석했습니다.

출처: Mixpanel 사용자 기준 7일 전환 결과 요약. 수치와 p값은 기록된 결과를 옮겼습니다.

출시 뒤 다시 본 탐색 흐름

9월 4일 실험군을 B로 고정해 탭을 전체 사용자에게 노출했습니다. 이후 9월 4일부터 21일까지의 탭 행동을 다시 살폈습니다. 이 구간은 대조군이 없는 출시 후 관찰이므로, 어떤 화면 요소가 행동을 만들었다고 인과관계를 주장할 수는 없습니다. 대신 다음 개선에서 확인할 질문을 좁히는 자료로 봤습니다.

후기 상세 진입과 카테고리 선택은 각각 26.5%, 17.5%였고, 지역 선택과 지도 확대는 12.8%, 12.0%였습니다. 검색 이용률은 2.7%였습니다. 제가 확인한 요약 자료에는 이 비율의 분모와 절대 건수가 없어, 행동 규모를 비교하는 지표로 해석하기는 어렵습니다. 8월 1일 이후 검색어에는 오토바이, 침대, 스타일러, 동승, 사다리차처럼 짐과 작업 조건이 나타났습니다. 검색 사용자가 적어 빈도보다 어떤 종류의 조건을 찾았는지 확인하는 참고 자료로 활용했습니다.

후기 상세에서 바로 예약으로 집계된 이벤트는 0건이었습니다. 이와 별도로 탭 안 예약 버튼을 누른 고객 중 절반은 예약 화면에서 서비스 종류를 다시 선택했습니다. 두 관찰은 서로 다른 경로의 기록입니다. 서비스 종류 재선택은 후기에서 예약 화면으로 선택 정보가 유지되지 않았을 가능성을 보여주지만, 고객이 확인을 위해 다시 선택했을 가능성도 남아 있습니다. 당시 계측으로는 두 경우를 구분할 수 없었고, 이 관찰만으로 A/B 결과의 원인을 설명할 수도 없습니다.

출처: 출시 후 9월 4일부터 21일까지의 탭 행동 분석. 검색어는 8월 1일 이후 기록분이며 검색 사용자가 적어, 빈도보다 검색 의도의 종류를 참고했습니다. 체크아웃과 구매 이벤트에는 진입 출처가 없어 후기 탭의 기여 경로를 따로 분리하지 못했습니다.

출시 후 관찰은 다음 검증 질문을 남겼습니다. 예약 버튼을 누른 뒤 서비스 종류가 예약 화면에 전달됐는지, 고객이 확인을 위해 다시 선택했는지를 이벤트와 화면 상태로 구분해야 했습니다. 지도와 필터를 더 촘촘히 만들기 전에 이 경로부터 확인할 필요가 있었습니다. 후속 개선안은 리서치 단계에서 요구사항을 확정하지 못해 실행하지 않았습니다. 구매 전환과 예약 화면 재선택의 원인은 확인되지 않은 채 남았습니다.

이전 글차주 위치를 실시간으로 공유하는 운송 추적다음 글CRM 캠페인에서 시작한 앱 진입 시스템 구축기 (3): 웹뷰와 네이티브를 잇는 브릿지