[TIL] 양면 시장(O2O) 플랫폼의 퍼널 병목 해결 및 카운터 메트릭 설계

---

1. 배경 및 문제 정의 (Context & Problem Definition)

1) 서비스 도메인 및 비즈니스 모델(BM)

• 도메인: 홈 케어 / 인테리어 시공 전문가 매칭 플랫폼 (수요자-공급자 양면 시장)
• BM: 고객이 요청서를 제출하면 전문가는 플랫폼에 '견적 발송 수수료'를 지불하고 매칭을 시도하는 구조. 즉, 고객의 요청서 제출 총량이 플랫폼의 최우선 매출 지표와 직결됨.

2) 직면한 위기 (North Star Metric의 하락)

• 최근 3개월간 고객의 '매칭 요청서 작성 완료율'이 45% 급감하는 현상 발생.
• 원인 분석을 위해 데이터 분석 툴을 활용하여 가입자 100명 기준의 단계별 퍼널(Funnel) 데이터를 추출함.

퍼널 단계	사용자 행동 로그	잔존 유저 수	이탈률 (Drop-off)
1단계	요청서 작성 시작 버튼 클릭	100명	-
2단계	시공 주소 및 날짜 입력	95명	5%
3단계	원하는 시공 종류 선택 (객관식)	90명	5%
4단계	시공 현장 사진 첨부 (최소 1장 필수)	30명	★ 60% 급감 (핵심 병목)
5단계	요청서 제출 완료	25명	16%

• 결론: 유저 100명 중 60명이 '4단계: 현장 사진 첨부(필수)' 구간에서 앱을 이탈하고 있음. 깔때기 입구가 막혀 전문가에게 도달하는 요청서가 줄어들고 전체 거래액이 반토막 난 상태.

---

2. 5 Why를 통한 근본 원인(Root Cause) 도출

단순히 "유저가 귀찮아서 나갔다"는 표면적 진단 대신, 유저의 현실적 맥락(Context)을 파악하기 위해 5 Why 방법론을 적용함.

• Why 1. 왜 4단계(사진 첨부)에서 가장 많이 나가는가?
  • Reason: 사진까지 찍어 올리기는 부담스럽고, 유저는 우선 '대략적인 평균 시공 단가'만 빠르게 탐색하고 싶었기 때문.
• Why 2. 왜 평균 단가만 먼저 확인하려고 하는가?
  • Reason: 내 예산 범위 내에 들어오는 작업인지 간을 보고, 실제 시공을 진행할지 말지 의사결정을 하고 싶기 때문.
• Why 3. 왜 우리 서비스에서는 사진을 안 올리면 평균 가격조차 알 수 없는가?
  • Reason: 기획자가 "전문가가 정확한 견적을 내려면 현장 사진이 필수"라는 공급자(전문가) 편의 중심의 마인드로 사진 첨부를 '필수 값(Required)'으로 강제해 놓았기 때문.
• Why 4. 사진을 강제하는 것이 왜 물리적 이탈로 이어지는가?
  • Reason: 현재 직장 사무실에서 폰으로 요청서를 쓰고 있거나, 아직 이사 가기 전이라 집 내부 사진을 촬영할 수 없는 유저는 구조적으로 사진을 등록할 수 없기 때문.
• 근본 원인(Root Cause): 공급자의 가치(정확한 견적)만 고려하느라, '가볍게 가격을 탐색하려는 초기 유저(Low-intent User)'의 진입 장벽을 극단적으로 높여 퍼널을 막아버린 기획의 오류.

---

3. 주니어적 착각과 시니어 PM의 피드백 (Mistakes & Corrections)

문제를 정의한 후 수립했던 초기 가설들의 맹점과, 시니어 PM 멘토링을 통해 교정된 실무적 관점은 다음과 같음.

❌ 교정 전 오류 1: "사용자 이탈을 막기 위해 10% 할인 쿠폰을 뿌리자"

• 나의 착각: 돈(보상)을 주면 사용자가 귀찮음을 참고 사진을 찍을 것이라 생각함.
• 튜터님의 피드백: 인테리어 시공은 건당 수백만 원에 달하는 고관여·저빈도 상품임. 300만 원짜리 시공에 10% 쿠폰을 주면 플랫폼이 30만 원의 마진을 손해 보는데, 플랫폼이 전문가에게 받는 수수료는 몇 천 원 수준이므로 역마진으로 회사가 파산하는 기획임. 또한 저빈도 상품은 푼돈(쿠폰)보다 '업체에 대한 신뢰'가 전환의 핵심 동인임.
• 인사이트: PM은 자본을 태우는 솔루션 이전에 "비용 없이 제품 내부의 논리(Logic)나 UI/UX 넛지로 풀 수 있는 가설"을 우선해야 함.

❌ 교정 전 오류 2: "DB에서 실시간으로 평균가를 계산해 주는 시스템을 만들자"

• 나의 착각: 유저가 입력한 평수를 기반으로 과거 매칭 DB를 실시간 쿼리(Query) 조회하여 화면에 뿌려주는 자동화 시스템을 기획함.
• 개발 팀장의 블로킹: "서버 부하가 심해져 인프라 아키텍처부터 손대야 하므로 최소 한 달 소요됨." 당장 이번 달 매출이 무너지는 상황에서 일정 관리(Scope Management) 실패.
• 인사이트: 시스템 자동화가 무조건 정답은 아님. PM이 직접 과거 3개월 데이터를 추출해 'Top 5 빈출 평수 구간별 평균가 데이터 테이블'을 하드코딩(Hardcoded)하는 MVP 방식으로 선회하여, 서버 부하 0 및 개발 공수를 한 달에서 반나절(0.5md)로 단축함.

---

4. 최종 솔루션 및 기능 명세 (Solution & PRD)

수요자의 편리함(사진 제외)과 공급자의 신뢰(정확한 정보)가 충돌하는 양면 시장의 Trade-off를 해결하기 위해, 기능 단계를 분리한 '안심 채팅 프로토콜' 전략을 설계함.

1) [수요자 퍼널 개선] 4단계 UI/UX 넛지(Nudge) 설계

• Action: [사진 첨부(필수)]를 삭제하고, 쉽게 입력 가능한 [시공 공간 평수 입력(객관식)]으로 치환.
• 손실 회피(Loss Aversion) UI 배치: 유저가 평수를 선택하면 PM이 미리 계산해 둔 'Top 5 스태틱 평균가 배너'를 노출하되, 하단에 최종 제출을 유도하는 넛지 문구 삽입.

[UI 가이드 예시]

• "현재 확인하신 금액은 과거 평균치이며, 실제 견적은 이보다 최대 20% 이상 낮아질 수 있습니다."
• "지금 요청서를 제출하시면, 사진 없이도 우리 동네 평점 4.8 이상 우수 전문가 3명의 맞춤형 비밀 특가 견적을 1분 만에 받아보실 수 있습니다."

2) [공급자 리스크 방어] 매칭 후 '안심 채팅방' 프로토콜 추가

• 문제: 사진이 없는 요청서를 받은 전문가들이 "정확한 규모를 몰라 허탕을 친다"며 탈퇴하겠다고 반발함.
• Solution: [요청서 ➔ 견적 ➔ 가계약(채팅방) ➔ 최종 계약 확정] 구조로 제품 프로세스 레이어 수정.
• 채팅방 내 기능 제약(Rule Setting):
  1. 컨텍스트의 활용: 관여도가 낮을 때(요청서 작성 시)는 사진을 안 올리던 고객도, 내가 픽한 전문가와 대화하는 단계(High-intent)에서는 사진 제공에 협조적임.
  2. 전문가 전용 [현장 사진 요청] 팝업 버튼 신설 ➔ 채팅창 내에서 유저가 실시간으로 시공 부위 사진을 전송하도록 유도.
  3. [최종 견적 확정] 기능 도입 ➔ 조율된 최종 단가에 고객이 [동의]를 눌러야 시공이 매칭되도록 설계하여 오프라인 대면 분쟁 소지를 원천 차단.

---

5. 지표 설계 및 비즈니스 성과 (KPI & Counter Metric)

기획의 성공 여부를 다각도로 검증하기 위해 핵심 지표와 방어 지표를 상호 보완적으로 세팅함.

• 북스타 지표 (North Star Metric): 요청서 최종 제출 완료율 (Form Completion Rate)
  • 목적: 4단계에 평수 가이드 및 넛지를 도입함으로써 최종 요청서 제출률의 증분(Lift)을 측정.
  • 성과: 기존 45%에서 70%로 완료율 반등 (+25%p 개선)
• 카운터 메트릭 (Counter Metric, 방어 지표): 전문가 견적 발송률 (Quote Response Rate)
  • 목적: 사진이 없는 요청서가 증가했을 때, 전문가들이 매칭을 거부하고 이탈하는지 감시하는 지표.
  • 성과: '안심 채팅방 프로토콜' 도입을 통해 전문가들의 작업 예측 가능성을 확보해 줌으로써, 전문가 이탈률 0% 수렴 및 매칭 거부 현상 방어.
• 최종 비즈니스 임팩트: 퍼널 하단으로 내려오는 요청서 총량(Volume)의 증가로 인해 플랫폼 월간 매칭 거래액(GMV) 전월 대비 20% 견인.

---

6. 회고 및 느낀 점 (Self-Review)

• 양면 시장의 본질 체득: 한쪽 유저(고객)를 편하게 해주는 기획이 반대쪽 유저(전문가)의 비즈니스 생태계를 파괴할 수 있다는 '양면 시장의 Trade-off'를 뼈저리게 깨달음. PM은 한쪽의 편의만 보는 단편적 기획자가 아니라, 두 생태계의 균형을 잡는 '룰 메이커(Rule Maker)'여야 함을 배움.
• 리소스에 대한 태도 변화: 기술적으로 구현이 어렵거나 일정이 밀릴 때 기획을 포기하는 것이 아니라, 제품의 논리를 비틀어 하드코딩 MVP로 스코프를 다운(Scope Down)하고 비즈니스 타임라인을 맞춰내는 순발력이 실무 PM의 가장 강력한 무기임을 알게 됨.