-
33일차[역기획 과제]PM 부트캠프 2026. 4. 22. 20:11
배민 퀵커머스 역기획 — 3·4·5단계 공부 기록
오늘은 어제 마친 1·2단계(서비스 구조·수익 구조·회사 목표) 위에, UI/UX 분석 → 문제 정의 → 개선안 도출까지 역기획의 후반부를 마쳤다. 정리 겸 남겨둔다.
1. 리뷰 데이터로 문제를 '숫자'로 보기
개선안을 만들기 전, 먼저 진짜 문제가 뭔지 찾아야 했다. Google Play 리뷰 10,000건 중 퀵커머스 관련 리뷰(140건 · 670건 두 버전)를 필터링해서 정량 분석을 돌렸다.
가장 인상 깊었던 건, 수치가 직관을 뒤집었다는 점이다.
- 평균 평점: 1.79 / 5
- 저평점(1~2점) 비율: 77.9%
- 저평점 확률을 가장 크게 높이는 변수: 품절·재고(OR 2.13), 배송 지연(OR 1.82)
- 가격·배달비 불만: 언급 빈도는 30%로 높지만, 저평점과의 통계적 연관성은 유의하지 않음 (p=1.000)
가격은 표면적 소음일 뿐, 이탈의 진짜 원인은 '약속 이행의 실패'다.
"비싸서 쓰지 않는다"가 아니라 "약속이 깨져서 떠난다"는 것. 이 문장 하나가 이후 모든 개선안의 뼈대가 됐다.
2. 문제의 구조적 뿌리 찾기
3대 문제 영역을 뽑고 나서 흥미로웠던 건, 세 문제가 따로 있는 게 아니라 하나의 구조에서 파생된다는 점이었다.
이중 공급 구조 (B마트 + 배민스토어) └─ 입점 매장 재고 동기화 주기의 한계 └─ 품절 신호가 '주문 이후'에야 드러남 ← 1순위 └─ 라이더 배차가 픽업 불가로 지연 ← 2순위 └─ CS 유입 증가, 환불 중심 처리 ← 3순위재고 정확도가 선행 지표이고, 배송 지연과 CS 불만은 그 후행 지표였다. 문제를 나열하지 말고 '어디가 레버리지 포인트인가'를 찾아야 한다는 역기획의 기본기를 다시 확인한 순간이었다.
3. 개선 방향성을 4단어로 압축
문제를 풀 때 바로 기능부터 떠올리지 않고, 방향성부터 합의했다.
- Prevent — 약속 실패를 사전에 차단 (재고를 주문 이전에 잡자)
- Visibility — 약속이 지켜지는 과정을 보여주자
- Recovery — 약속이 깨졌을 때의 회복 경험 설계
- Alignment — 가격 구조를 실사용 패턴에 맞추자
각 방향성을 구체적 개선안 3가지로 연결했다.
- 멤버십 재설계 (Alignment) — 3,900원 선택형 + 5,900원 통합형 이중 플랜
- 재고 라이팅 플로우 (Prevent + Recovery) — "확인 중 → 확인 완료 → 포장 중", 품절 시 환불이 아닌 대체 제안
- 배차 가시성 UI (Visibility) — 카카오T·Uber 스타일의 실시간 지도 UX
4. 오늘 가장 배운 것
"환불=끝"이 아니라 "대체=전환"
가장 와닿았던 관점 전환. 품절이 생기면 보통 환불로 마무리하는데, 보고서에서는 이걸 이탈 아닌 전환으로 재설계했다. 대체 상품 수락 / 부분 환불 / 전체 취소의 분기로 Recovery 플로우를 명시적으로 만드는 것.
지연의 '이유 공개'가 불만을 완화한다
"배차 중..."이라는 텍스트 한 줄은 모호함만 남기는데, 택시 앱처럼 "주변 1.5km 내 라이더 4명에게 알리고 있어요"로 바꾸면 같은 지연도 체감이 달라진다. 지연 자체보다 '설명 없는 지연'이 불만의 핵심이라는 것. Uber·카카오T·Domino's Pizza Tracker 레퍼런스가 다 여기로 수렴했다.
롤아웃 순서 = 실행 복잡도와 체감 속도의 함수
세 개선안 중 어떤 걸 먼저 해야 할까? 답은 체감 효과가 크고 복잡도가 낮은 순서였다.
- Phase 1 (0~3개월): 배차 가시성 UI — 앱 단에서 닫히는 UX
- Phase 2 (2~4개월): 재고 라이팅 — 백엔드 연동 필요
- Phase 3 (4~6개월): 멤버십 재설계 — 파트너 협의·기존 가입자 이관 필요
좋은 개선안을 만들었어도 롤아웃 순서가 틀리면 조직이 지친다는 걸 배웠다.
5. 한 줄 정리
퀵커머스는 속도의 싸움이 아니라, '약속을 지키는 시스템'의 싸움이다.
역기획 7단계 중 6단계까지 마쳤다. 남은 건 발표와 피드백. 어제 정리한 팀 역기획 방법론의 마인드셋 — "서비스를 만든 사람은 나보다 똑똑하다" — 이 개선안 설계 내내 도움이 됐다. "이 기능 왜 없지?"가 아니라 "왜 이렇게 됐을까?"로 보니까, 비난이 아니라 재설계가 나왔다.
'PM 부트캠프' 카테고리의 다른 글
38일차[숙련 과제 피드백] (0) 2026.04.29 34일차[역기획 과제] (0) 2026.04.23 32일차[역기획 과제 시작] (0) 2026.04.21 27일차[서비스 기획 숙련 과제] (0) 2026.04.14 26일차[서비스 기획 숙련 과제] (0) 2026.04.13