오프라인의 거래를
앱 안에서 끝냅니다.

선상 낚시는 결제까지 거치는 단계가 가장 많은 도메인입니다. 어떤 배에서 어떤 어종을 얼마에 타는지가 한 화면에 정리되지 않으면 사용자는 단톡방과 전화 예약으로 돌아갔습니다.

병목은 수요가 아니라 공급의 분산이었습니다. 선박과 선장이 흩어져 있고 예약과 조황 정보가 메신저에 묶여 있었습니다.

탐색·결제·현장 이용·후기를 한 흐름으로 잇고, 공급은 자사 직판이 아니라 외부 선장 입점으로 채웠습니다. 직판은 재고 위험을 우리가 전부 지는 구조라 초기 회전에 맞지 않았습니다.

선장이 직접 모객하는 것보다 앱에 올리는 편이 이득이 되도록, 입점 선장에게 예약 알림·정산 자동화·조황 연계를 묶어 제공했습니다.

검색→상세→옵션→결제 중 이탈이 가장 큰 옵션 분기를 먼저 손봤습니다. 어종·인원·승선일이 가격에 어떻게 반영되는지 한 화면에 보여주자 다음 단계로 넘어갔습니다.

86배라는 배수는 시작이 10건이라 나온 숫자입니다. 그래서 거래액을 활성 선박 수 × 선박당 결제 건 × 객단가로 분해해 봤습니다. 초기 증가분의 대부분은 공급이 늘어난 몫이고, 제품이 책임진 것은 전환 항이었습니다. 이후 목표를 세울 때도 같은 분해를 써서 필요한 활성 선박 수를 먼저 계산했고, 목표가 공급 상한을 넘는다는 것을 사전에 확인했습니다.

커뮤니티 트래픽은 있는데 구매 동선이 외부 쇼핑몰로 새고 있었습니다. 앱 안에서 끝나는 매출이 없었습니다.

더 큰 문제는 매출이 외부 채널에 쏠려 있어서 자사몰을 고쳐도 개선이 보이지 않는다는 것이었습니다. 합산 지표 안에서는 신호가 묻혔습니다.

외부 채널을 끊는 대신 자사몰 지표만 별도 KPI로 떼어냈습니다. 매출은 그대로 받으면서 학습만 분리하는 쪽을 골랐습니다.

외부 채널 매출은 유지하고 자사몰 결제 1인당 매출만 독립 지표로 관리했습니다. 떼어내자마자 개선점이 보였습니다.

가장 비싼 이탈 지점은 가격 인지였습니다. 쿠폰·할인 표기를 두 색 규칙으로 정리하고, 결제수단 분기와 실패 처리를 한 화면에 통합했습니다.

진열→상세→장바구니→결제의 단계별 이탈을 주·월 단위로 추적하고, 가장 많이 빠지는 구간을 백로그로 올리는 사이클을 정착시켰습니다.

카테고리를 어종·장비 두 축으로 다시 짜고 가입 때 받은 관심어종을 홈으로 끌어왔습니다. 이 정보구조 변경이 재방문 곡선을 올렸습니다.

대회 정산 화면이 출처를 알 수 없는 상수로 금액을 계산하고 있었고, 일부 건에서는 수수료가 음수로 나왔습니다.

산식이 어디에도 문서로 남아 있지 않았습니다. 개발·운영·정산이 같은 숫자를 각자 다른 근거로 설명하고 있었습니다.

코드를 고치기 전에 원장에서 산식을 되찾기로 했습니다. 무엇이 맞는지 모르는 채로 고치면 다음 달에 같은 문제가 다시 납니다.

과세표준이 될 수 있는 후보 다섯 종을 놓고, 실제 원장 값과 원 단위까지 맞아떨어지는 식을 찾았습니다. 맞는 것은 하나였습니다.

확정한 식을 음수 정산이 발생한 실측 여섯 건에 다시 넣어 전부 일치하는지 확인했습니다. 예외 조건에서도 기준 수수료율이 정확히 복원되는지 함께 봤습니다.

결함 두 건의 성격이 서로 반대였습니다. 한쪽은 유효 건이 0인데 지급이 예정돼 있었고, 다른 쪽은 취소분의 원가만 남아 수수료가 음수가 됐습니다. 반대 방향의 두 증상이 같은 뿌리에서 나왔습니다 — 정산 대상이라는 집합이 어디에도 저장돼 있지 않고, 두 화면이 각자 그때그때 집계하고 있었습니다.

정산 대상 명단을 기준일과 함께 저장하도록 하고, 음수 정산을 금지하는 규칙을 정책 문서에 넣었습니다. 화면을 고치는 것보다 정의를 세우는 것이 먼저였습니다.

대행사가 제시한 고객 획득 단가를 근거로 광고 예산 증액안이 올라왔습니다. 자사 데이터로 검증된 값이 아니었습니다.

매체가 보고하는 전환 수와 우리 원장의 결제 건수가 서로 달랐습니다. 같은 단어를 쓰면서 다른 것을 세고 있었습니다.

예산을 늘릴지 정하기 전에 양쪽이 무엇을 세는지부터 맞추기로 했습니다.

제시된 단가를 자사 예약 원장으로 다시 계산하자 5.2배 차이가 났습니다. 취소분이 반영되지 않은 것도 확인해 수정본을 받았습니다.

매체 보고 전환과 원장 결제 건이 3.8배 벌어지는 이유를 공통 판정 기준의 부재로 정의하고, 결제 건과 유효 건(일정 기간 취소되지 않은 건) 두 정의를 분리했습니다. 목표는 유효 건으로 두고 계약은 결제 건과 단가 상한으로 쓰도록 권고했습니다.

리포트를 옮겨 적는 대신 광고 계정 다섯 곳을 직접 열었습니다. 어느 문서에도 금액이 잡혀 있지 않던 매체가 전체 집행의 3분의 1을 넘게 쓰고 있었고, 가장 중요한 전환 하나는 기록이 끊긴 상태였습니다.

필요한 결제 건수를 활성 공급으로 역산했습니다. 목표를 채우려면 보유한 배가 한 척도 빠짐없이 결제를 내야 했습니다. 문제는 예산이 아니라 공급이었고, 증액은 단가만 올릴 상황이었습니다.

오픈 일정이 밀리면서 약관 시행일, 딥링크, 스토어 심사 마감이 서로 어긋났습니다. 한 곳을 미루면 다른 곳이 깨졌습니다.

무엇이 남았는지 아는 내용이 사람마다 달랐습니다. 목록이 여러 문서와 각자의 머릿속에 흩어져 있었습니다.

남은 일을 한 문서로 모으고 상태를 실시간으로 공유했습니다. 항목마다 담당과 기한을 붙였습니다.

항목 261건을 14개 카테고리로 묶고 결정 22건과 리스크 34건을 같이 실었습니다. 체크 상태와 담당·메모가 즉시 다른 사람 화면에도 반영되게 만들어, 회의 없이도 현황이 한곳에 모이게 했습니다.

1차를 웹 전환·앱 게시·측정 개시 세 가지로 좁히고, 홈페이지 전면 교체와 신규 상품은 2차로 넘겼습니다. 같은 날 다 하려다 전부 늦어지는 쪽이 더 위험했습니다.

검수 담당이 한 명인 상태로는 앱을 다 볼 수 없었습니다. "검수를 도와 달라"가 아니라 "파트별 기능 파악을 하루에 몰아서 하자"로 프레임을 바꿔 14명을 모았고, 미션 범위는 발견 가능한 양이 아니라 고칠 수 있는 공수에서 역산해 정했습니다. 발견만 쌓이고 수정이 안 되면 검수는 불안만 남깁니다.

되돌릴 수 없는 것을 먼저 적었습니다. 앱은 재심사가 걸리면 그날 되돌릴 수 없으니 되돌림 1순위를 웹으로 두고, 트리거 다섯 개를 문장으로 못 박았습니다. 연기 시나리오 네 개를 비교한 뒤 예정일 유지로 판단했습니다 — 스토어 제출 마감이 이미 지나 있어 미뤄도 앱이 좋아지지 않았기 때문입니다.

직전 쿠폰 실험이 "유의한 군 없음"으로 끝났습니다. 사내 해석은 쿠폰이 효과가 없다는 쪽이었습니다.

효과가 없는 것과 효과를 못 잡는 것은 다릅니다. 당시 모수·홀드아웃·기간으로 잡을 수 있는 최소 효과를 계산해 보니 상대 60% 개선이었습니다. 웬만한 진짜 효과는 애초에 걸리지 않는 설계였습니다.

쿠폰을 없앨지 정하기 전에, 판별할 수 있는 실험부터 다시 만들기로 했습니다.

모수를 활성 회원 전수로 넓히고 홀드아웃을 35%, 관측을 30일로 늘렸습니다. 주지표를 전환율에서 1인당 거래액으로 바꾸고 사전 공변량 보정을 넣어 최소검출효과를 절반 이하로 낮췄습니다.

"쿠폰이 비용을 회수하는가"는 회수 경로 계측이 없는 상태에서 답할 수 없는 질문이었습니다. "끄면 얼마나 빠지는가"로 바꿔 홀드아웃군의 하락폭으로 방어 효과를 재도록 했습니다.

쿠폰을 판관비가 아니라 거래 직접비로 옮겼습니다. 표기 할인율과 실제 적용률을 반영한 실효 할인율이 두 배 이상 차이 나는 것도 분리해 표기했습니다.

손절 기준을 집행 전에 못 박았습니다. 판독일에 유의하지 않으면 남은 기간 쿠폰 예산을 전액 삭감한다고 먼저 적어두었습니다. 실험이 끝난 뒤에 기준을 정하면 결과에 맞춰 기준이 움직입니다.

청구와 지급이 전부 수작업이라 매달 6명이 매달렸고, 종이와 엑셀로 흐르는 돈은 데이터로 남지 않았습니다.

풀 스코프를 한 번에 지으면 1년이 걸릴 일이었습니다. 그동안 현금흐름의 통증은 그대로 남습니다.

통증이 가장 큰 청구·지급만 잘라 0.5개월 사이클로 먼저 검증했습니다. 맞는지 확인한 뒤에 나머지를 붙이는 순서로 갔습니다.

실수령 → 청구 자동생성 → 지급 결재 → 정산의 정합을 한 화면에 놓아, 운영팀이 한 줄에서 조회·수정·결재를 끝내게 했습니다.

부서 간 핸드오프를 줄이는 일이 곧 공수 절감이었습니다. 서류가 오가는 횟수가 그대로 시간이었습니다.

부서마다 다르던 청구서를 같은 그리드로 묶고 고유 컬럼은 접었습니다. 공통 입력 포맷에 합의하는 것이 시스템을 만드는 것보다 어려웠고, 그게 정착의 실제 조건이었습니다.

줄어든 공수만큼 인원을 줄이지 않았습니다. 청구·지급에 묶여 있던 3인은 영업·재고 트랙으로 재배치했습니다. 감원 없이 같은 인원으로 다른 일을 하게 만드는 것이 목표였습니다.

자동 리포트가 예약 퍼널의 한 단계를 건너뛴 채 집계해, 고쳐야 할 화면을 잘못 지목했습니다. 그대로 따라갔으면 엉뚱한 곳에 개발 공수를 썼을 상황이었습니다.

예약 건수가 네 가지 계열로, 취소율이 세 가지 정의로 돌아다녔습니다. 회의에서 숫자가 다르면 결론이 아니라 숫자를 두고 다투게 됩니다.

화면을 만들기 전에 정의부터 정했습니다. 무엇을 세는지 합의되지 않은 대시보드는 출처를 하나 더 만들 뿐입니다.

정의가 갈리는 지표 여섯 개를 골라 채택값과 제외 조건을 문서에 적었습니다. 테스트 결제를 분모에서 빼자 취소율이 제자리를 찾았습니다.

원장을 전량 대조해 결손이 없는지 확인한 뒤에 화면을 붙였습니다. 순서를 바꾸면 틀린 숫자를 예쁘게 보여주게 됩니다.

자동 리포트가 낸 개선 목표가 산술적으로 불가능하다는 것을 상한 계산으로 반박했습니다. 앞 단계 진입률이 상한인데 뒤 단계 목표가 그보다 높았습니다. 자동화한 숫자를 그대로 믿지 않는 것이 자동화를 계속 쓰는 조건입니다.

v2를 부분 패치로 버텼습니다. 화면 하나를 고치면 다른 화면의 규칙이 어긋났습니다.

정보구조가 이미 깨져 있는데 그 위에 패치를 얹고 있었습니다. 이것이 고칠 문제가 아니라 다시 지을 문제라는 것을 인정하는 데 6개월이 걸렸습니다. 그 반년이 제가 이 프로젝트에서 한 가장 비싼 실수입니다. 이후로는 같은 유형의 수정이 세 번 반복되면 구조를 의심하는 것을 기준으로 삼았습니다.

부분 패치를 멈추고 풀리뉴얼로 전환했습니다. 세 앱을 우선순위로 줄 세워 순서대로 갔습니다.

근로자 134명 설문과 인터뷰로 어느 단계에서 멈추는지 확인했습니다. 주 사용자가 40~50대라 화면의 문제가 아니라 절차의 문제였습니다.

일자리에 나가려면 필요한 계좌·이수증 인증을 가입 단계로 당겼습니다. 나중에 요구하면 이미 이탈한 뒤입니다. 회원가입도 휴대폰 점유인증으로 바꿔 단계를 줄였습니다.

일을 고르는 첫 기준은 거리입니다. 현재 위치를 기준으로 주변 일자리를 홈에서 리스트와 지도로 보여줬습니다.

승격 직후 후임 PM 두 명에게 근로자·관리자 트랙을 넘기고 본인은 백오피스로 옮겼습니다. 세 트랙을 혼자 쥐고 있으면 같은 이유로 다시 깨집니다. 인계가 늦었으면 구조가 또 어긋났을 것입니다.