[2026년 4월 29일] 역기획 프로젝트 회고 : 배달의 민족 앞으로의 성장

1. 프로젝트를 접근한 방식

이번 역기획 프로젝트에서 내가 가장 먼저 집중한 것은 경쟁사를 이기는 기능을 찾는 것보다, 배민이 지금 어떤 방향으로 가야 하는지를 정의하는 것이었다.

처음에는 과제의 경쟁 구도가 배민 vs 쿠팡이츠처럼 보였다. 하지만 너무 쿠팡이츠만 따라가는 방식으로 접근하면 배민만의 강점을 놓칠 수 있다고 생각했다.

그래서 “쿠팡이츠가 잘하는 것을 배민도 해야 한다”가 아니라, 배민이 이미 가지고 있는 자산과 비전을 바탕으로 어떤 성장 방향을 만들 수 있는가를 먼저 보려고 했다.

그 과정에서 내가 잡은 핵심 문제 정의는 다음과 같았다.

배민은 생활 커머스로 확장할 수 있는 자산을 이미 가지고 있지만, 실제 사용자 경험과 사용자 인식은 여전히 음식 배달 중심에 머물러 있다.

즉, 배민은 B마트·장보기·퀵커머스 등 생활 커머스 자산을 이미 가지고 있지만, 사용자는 여전히 배민을 음식 주문 앱으로 먼저 인식하고 있었다. 나는 이 간극을 이번 프로젝트의 핵심 문제로 보았다.

이 문제 정의를 바탕으로, 단순히 새로운 기능을 추가하는 것이 아니라 사용자가 배민을 생활 커머스 탐색 후보로 이해하게 만드는 방향으로 기획을 전개하려고 했다.

---

1-1. 문제를 어떻게 뾰족하게 만들었는가

문제 정의는 한 번에 만들어지지 않았다. 처음에는 “배민이 쿠팡이츠에 밀린다”는 표면적인 인식에서 시작했지만, 데이터를 보고 질문을 바꾸면서 점점 더 뾰족해졌다.

Step 1. 시작점 — “배민이 쿠팡이츠에 밀린다”

처음 문제 인식은 매우 직관적이었다

배민이 쿠팡이츠한테 밀린다.

하지만 이 문장은 너무 넓었다.

무엇에서 밀리는지, 사용자를 잃고 있는 것인지, 결제를 놓치고 있는 것인지, 아니면 수익성이 흔들리는 것인지가 분명하지 않았다.

그래서 먼저 “배민이 정확히 무엇을 놓치고 있는가?”를 분리해 보려고 했다.

---

Step 2. 사용자 수와 결제를 분리해서 보기

데이터를 보니 배민은 여전히 MAU에서 우위에 있었다.

하지만 일부 지표에서는 쿠팡이츠의 결제액이 배민을 앞서는 흐름이 보였다.

이때 문제를 이렇게 다시 정의했다.

문제는 사용자 수가 아니라 결제 비중 하락이다.

즉 배민은 사용자를 완전히 잃고 있다기보다, 실제 주문과 결제가 일어나는 순간을 놓치고 있는 상태에 가까웠다.

이 관점이 중요했다.

단순히 “사용자를 더 데려와야 한다”가 아니라, 이미 배민을 알고 있고 사용하는 사람이 결제 순간에 왜 다른 선택을 하는지를 봐야 했기 때문이다.

---

Step 3. 배달비 경쟁을 같은 방식으로 따라가면 되는지 의심하기

다음으로 자연스럽게 나온 질문은 이것이었다.

그러면 배민도 쿠팡이츠처럼 배달비 경쟁을 더 강화해야 할까?

하지만 배달비 경쟁은 수익성을 압박하는 구조에 가까웠다.

배민의 매출은 증가했지만 영업이익은 감소하고 있었고, 배달 관련 비용 부담도 커지고 있었다.

그래서 나는 같은 방식의 배달비 경쟁만으로는 장기적인 해결책이 되기 어렵다고 판단했다.

배달비 경쟁은 성장 전략이라기보다 수익성을 압박하는 구조다.

이때부터 문제를 “쿠팡이츠처럼 싸게 해보자”가 아니라, 배민이 가진 다른 성장 경로를 찾아야 한다로 바꿔 보기 시작했다.

---

Step 4. 배민이 이미 가진 자산 보기

배민은 이미 음식 배달을 넘어 생활 커머스로 확장할 수 있는 자산을 가지고 있었다.

B마트, 장보기, 편의점, 퀵커머스, 선물하기 가능성 등은 배민이 쿠팡이츠와 똑같은 방식으로만 경쟁하지 않아도 된다는 근거였다.

그래서 나는 이렇게 생각했다.

배민의 다음 성장 방향은 배달비 경쟁이 아니라, 이미 가진 생활 커머스 자산을 사용자 경험 안에서 더 잘 전달하는 것일 수 있다.

여기서 중요한 전환이 있었다.

경쟁사를 따라가는 전략이 아니라, 배민이 이미 가진 무기를 어떻게 사용자에게 이해시킬 것인가로 질문이 바뀌었다.

---

Step 5. 배민클럽에서 배민 앱 전체로 문제 범위를 다시 올리기

처음에는 배민클럽을 중심으로 문제를 보려고 했다.

배민클럽이 배달비 할인 도구로만 인식되면서, 커머스 자산이 충분히 작동하지 않는다고 생각했기 때문이다.

하지만 논의를 이어가다 보니, 문제는 배민클럽 하나에만 있지 않았다.

더 큰 문제는 배민 앱 메인 경험 전체가 여전히 음식 주문 중심으로 해석되고 있다는 점이었다.

그래서 중간에 방향을 바꿨다.

배민클럽이 문제가 아니라, 배민 앱 전체가 생활 커머스 서비스로 충분히 이해되지 않는 것이 문제다.

이 전환은 의미 있었다.

처음 잡은 프레임에 매달리지 않고, 더 상위 문제로 다시 올라간 순간이었기 때문이다.

---

Step 6. 페르소나를 “사람 수”가 아니라 “상황”으로 보기

처음에는 페르소나를 여러 명으로 나눠서 보려고 했다.

하지만 데이터를 다시 보니 중요한 것은 서로 다른 사람이 아니라, 같은 사람이 상황에 따라 다른 앱을 쓴다는 점이었다.

예를 들면 이런 식이었다.

상황	사용 앱
평일 저녁 배고플 때	배민으로 음식 주문
선물을 보내야 할 때	카카오톡 선물하기 / 네이버
갑자기 생활용품이 필요할 때	쿠팡 / 편의점

이때 문제 정의가 더 선명해졌다.

문제는 배민을 안 쓰는 사람이 아니라, 배민을 자주 쓰면서도 특정 상황에서만 쓰는 사용자다.

즉 “누가 문제인가”보다 어떤 상황에서 배민이 떠오르지 않는가가 더 중요했다.

그래서 최종적으로는 배달고정형 사용자를 핵심 페르소나로 잡았다.

배민으로 음식은 자주 주문하지만, 생활용품·선물·갑자기 필요한 물건 상황에서는 배민을 떠올리지 않는 사용자다.

---

Step 7. 최종 문제 정의 — 기능 부재가 아니라 상황과의 연결 부재

발표 직전 인터뷰 데이터 n=35를 다시 확인하면서 문제는 더 명확해졌다.

항목	수치
음식 배달 외 배민 사용 경험 없음	45.7%
B마트 미사용/미인지	54.3%
최근 3개월 내 갑자기 필요한 물건 상황 경험	71.4%
그때 배민 B마트를 전혀 떠올리지 않음	77.1%
최근 3개월 내 선물 경험 있음	85.7%

이 데이터를 보면서 문제는 단순히 기능이 없거나, 노출이 전혀 없다는 것이 아니라는 점을 확인했다.

배민 안에 생활 커머스 자산은 이미 존재한다.

하지만 사용자가 생활용품·선물·갑자기 필요한 물건 상황에서 배민을 자연스럽게 떠올리지 못한다.

그래서 최종 문제 정의는 이렇게 정리되었다.

배민의 생활 커머스 자산은 이미 존재하지만, 사용자 경험 안에서 충분히 전달되지 않아 생활용품·선물·갑자기 필요한 물건 상황에서 배민이 탐색 후보로 떠오르지 못하고 있다.

이 문장까지 도달하면서 프로젝트의 방향이 훨씬 분명해졌다.

---

1-2. 문제를 뾰족하게 만들 때 사용한 사고 패턴

이번 프로젝트를 돌아보면, 문제를 뾰족하게 만드는 과정에서 반복적으로 사용한 사고 패턴이 있었다.

사고 패턴	적용한 순간
표면 답을 데이터로 의심하기	“배민이 밀린다”를 MAU와 결제액으로 분리해 본 것
같은 방식의 경쟁을 거부하기	배달비 경쟁 강화가 수익성 압박으로 이어진다는 점을 본 것
한 단계 위로 올라가기	배민클럽 문제가 아니라 배민 앱 전체의 인식 문제로 확장한 것
사용자와 상황을 분리하기	한 사람이 상황에 따라 배민과 다른 앱을 다르게 쓴다는 점을 본 것
내가 정한 프레임을 다시 깨기	처음 잡은 배민클럽 중심 프레임을 버리고 앱 전체 경험으로 올라간 것

이번 경험을 통해, 뾰족한 문제 정의는 처음부터 나오는 것이 아니라 데이터를 보고, 질문을 바꾸고, 기존 프레임을 다시 의심하는 과정에서 만들어진다는 것을 배웠다.

---

2. Keep — 계속 가져가고 싶은 점

1) 상위 문제를 빠르게 구조화한 점

이번 프로젝트에서 가장 잘했다고 느낀 부분은 문제를 비교적 빠르게 상위 레벨에서 잡아낸 것이다.

처음부터 기능 단위로 들어가기보다, 배민의 비전과 현재 사용자 경험 사이의 간극을 먼저 보려고 했다. 그 결과 “배민은 생활 커머스로 확장하고 있지만, 유저는 여전히 음식 배달 앱으로 인식한다”는 문제 정의까지 도달할 수 있었다.

이 관점은 팀 프로젝트의 방향을 잡는 데 중요한 기준이 되었다.

---

2) 경쟁사보다 자사 강점에 집중한 점

쿠팡이츠와의 경쟁 상황을 보면서도, 단순히 쿠팡이츠를 따라가는 방향으로 가지 않으려고 했다.

배민이 이미 가지고 있는 B마트, 장보기, 퀵커머스, 선물하기 가능성 같은 자산을 보고, 배민만의 무기로 성장할 수 있는 방향을 찾으려 했다.

이 점은 PM 관점에서 중요한 접근이었다고 생각한다.

---

3) 문제 정의에서 해결안, 지표까지 하나의 흐름으로 연결하려고 한 점

프로젝트 후반부에 체력적으로 많이 힘들었지만, 문제 정의 → 가설 → 페르소나 → 해결안 → 지표까지 논리가 이어지도록 계속 문서를 다듬었다.

특히 초기에는 배민클럽, 선물하기, B마트 등 해결안이 흩어져 있었지만, 마지막에는 배달고정형 사용자의 인식 전환이라는 하나의 축으로 정리할 수 있었다.

금요일 밤 늦게까지, 그리고 주말 일정 중에도 계속 문서를 다시 보면서 전체 구조를 맞추려고 했다. 힘들었지만 결과적으로는 문서의 완성도를 올리는 데 기여했다고 생각한다.

---

3. Problem — 아쉬웠던 점

1) 해결안을 조율하는 과정에서 핵심 문제 정의가 흐려진 점

처음 문제 정의와 방향성은 비교적 빠르게 잡았지만, 이후 해결안을 논의하는 과정에서 여러 의견을 많이 수용하려고 했다.

팀원들의 의견을 최대한 반영하고 싶었지만, 그 과정에서 해결안이 조금씩 섞이면서 오히려 초기에 잡았던 상위 문제 정의를 해칠 뻔했다.

다음에는 모든 의견을 동일하게 반영하기보다, 초기 문제 정의와 가설에 맞는 의견인지 먼저 판단하고, 쳐낼 것은 쳐내는 기준이 필요하다고 느꼈다.

---

2) 자연스럽게 리딩 역할을 맡았지만, 역할 경계와 액션을 명확히 나누지 못한 점

이번 프로젝트에서 나는 자연스럽게 문제 정의와 문서 구조를 잡는 역할을 맡게 되었다.

흩어진 리서치와 팀원 의견을 하나의 논리 흐름으로 연결하려고 했다.

하지만 그 역할이 명시적으로 정해진 것은 아니었다.

그러다 보니 어디까지 내가 책임지고, 어디서부터 팀원에게 위임해야 하는지 경계가 흐려졌다.

결과적으로 후반부에 내가 혼자 문서를 정리하고 방향을 다시 잡는 부담이 커졌다.

앞으로는 팀 리딩을 맡게 된다면, 단순히 방향을 제시하는 것에서 끝내지 않고 누가, 언제까지, 무엇을 할지를 더 명확히 정해야 한다.

---

3) 회의가 길어지면서 속도와 이해도가 달라진 점

문제 정의는 회의 안에서 바로 합의하기 어려운 주제였다. 하지만 회의 시간이 길어지면서 점점 논의가 복잡해졌고, 각자가 이해한 내용도 달라졌던 것 같다.

특히 회의록이 명확하지 않으면 팀원마다 “무엇이 결정되었는지”를 다르게 이해할 수 있다.

팀원들과 이해 속도나 작업 속도가 다를 때, 내가 혼자 앞서가서 정리하는 방식은 단기적으로는 빠를 수 있다. 하지만 장기적으로는 팀 전체의 이해도를 맞추기 어렵다는 것을 느꼈다.

다음에는 내가 먼저 이해한 내용을 바로 결론으로 밀기보다, 회의록과 중간 요약을 통해 팀원들이 같은 맥락을 따라올 수 있도록 돕고 싶다.

---

4) 후반부에 체력과 집중력이 크게 떨어진 점

프로젝트 후반부에는 문서의 논리 흐름을 맞추기 위해 늦은 시간까지 혼자 정리하는 시간이 많았다.

금요일 밤, 주말 이동 중, 발표 전 새벽까지 문서를 계속 보면서 완성도를 높이려 했다.

하지만 그만큼 체력적으로 많이 소모되었고, 후반부에는 집중력도 많이 떨어졌다.

좋은 결과물을 만들기 위해 끝까지 책임지는 태도는 필요하다.

하지만 계속 혼자 버티는 방식은 지속 가능하지 않다는 것도 느꼈다.

다음에는 후반부에 몰아서 정리하지 않도록, 초반부터 역할과 마감 단위를 더 작게 쪼개고 중간 산출물을 팀원들과 함께 맞춰가야겠다.

---

4. Try — 다음 프로젝트에서 시도할 것

1) 회의 전, 반드시 목표와 산출물을 정하기

앞으로는 회의에 들어가기 전에 다음 세 가지를 먼저 정하고 시작하고 싶다.

항목	내용
회의 목표	오늘 무엇을 결정할 것인가
산출물	회의가 끝나면 어떤 결과물이 나와야 하는가
액션 아이템	누가, 언제까지, 무엇을 할 것인가

회의는 30~40분 안에 끝내는 것을 기본으로 하고, 그 시간 안에 결론이 나야 하는 안건만 회의에 올리는 방식이 좋을 것 같다.

---

2) 회의록에는 반드시 결정 사항과 액션 아이템을 남기기

회의록은 단순 기록이 아니라 팀의 속도를 맞추는 도구라고 느꼈다.

다음부터는 회의록을 아래 형식으로 남기고 싶다.

구분	내용
오늘 결정한 것	회의에서 합의한 내용
아직 결정하지 않은 것	추가 논의가 필요한 내용
액션 아이템	담당자 / 마감일 / 결과물
다음 회의 전까지 준비할 것	각자 해야 할 준비

특히 팀원들과 속도가 다를 때는, 회의록이 있어야 각자가 같은 페이지에 있는지 확인할 수 있다.

---

3) 문제 정의와 해결안을 분리해서 합의하기

이번에 가장 크게 배운 점은 문제 정의와 해결안을 동시에 논의하면 쉽게 복잡해진다는 것이다.

다음에는 아래 순서로 합의를 나누고 싶다.

1. 우리가 풀 문제는 무엇인가?
2. 이 문제가 진짜 중요한 이유는 무엇인가?
3. 어떤 사용자에게 먼저 검증할 것인가?
4. 그다음 어떤 해결안을 제안할 것인가?
5. 해결안이 작동했는지는 무엇으로 볼 것인가?

이 순서를 지키면 해결안이 많아져도 문제 정의가 흔들리지 않을 것 같다.

---

4) 팀원 의견을 수용하기 전에 기준을 먼저 세우기

팀원 의견을 듣는 것은 중요하지만, 모든 의견을 다 반영하는 것이 좋은 협업은 아니라는 것을 느꼈다.

앞으로는 의견을 받을 때 다음 기준으로 판단하고 싶다.

판단 기준	질문
문제 정의와 맞는가	이 의견이 우리가 정의한 문제를 해결하는가?
핵심 사용자와 맞는가	이 해결안이 우리가 잡은 페르소나에게 작동하는가?
검증 가능한가	이 해결안이 실제로 효과가 있었는지 측정할 수 있는가?
범위가 적절한가	지금 과제 범위 안에서 다룰 수 있는가?

이 기준이 있으면 팀원 의견을 더 건강하게 수용할 수 있을 것 같다.

---

5. 내가 좋은 팀원으로 성장하기 위해 해야 할 것

이번 프로젝트를 통해 좋은 팀원이란 단순히 일을 많이 하는 사람이 아니라, 팀이 같은 방향을 보고 움직이게 만드는 사람이라는 생각이 들었다.

나는 문제 정의와 방향성을 잡는 데 강점이 있다. 하지만 그 방향을 팀원들이 함께 이해하고 실행할 수 있도록 만드는 과정은 더 훈련이 필요하다.

앞으로는 혼자 많이 끌고 가기보다, 다음을 더 의식하고 싶다.

• 문제 정의를 짧고 명확한 문장으로 공유하기
• 회의 전 목표와 산출물을 정하기
• 회의 후 결정 사항과 액션 아이템을 남기기
• 팀원에게 구체적인 역할과 마감 시간을 주기
• 의견을 받을 때 문제 정의와 가설에 맞는지 기준으로 판단하기
• 내가 혼자 정리하기 전에 팀이 함께 정리할 수 있는 구조 만들기
• 내가 먼저 이해한 내용을 팀원들도 따라올 수 있도록 중간 요약을 자주 공유하기

---

6. 다음 프로젝트에서의 운영 원칙

이번 프로젝트를 통해 다음 프로젝트에서는 아래 원칙을 지키고 싶다.

1. 문제 정의와 해결안은 분리해서 합의한다.
2. 회의는 30~40분 안에 끝내고, 회의 전 산출물을 정한다.
3. 회의록에는 결정 사항과 액션 아이템을 반드시 남긴다.
4. 팀원 의견은 모두 반영하기보다, 문제 정의와 가설에 맞는지 기준으로 판단한다.
5. 내가 먼저 이해한 내용을 팀원들도 따라올 수 있도록 중간 요약을 자주 공유한다.
6. 후반부에 혼자 몰아서 정리하지 않도록, 초반부터 역할과 마감 단위를 작게 나눈다.
7. 좋은 결과물뿐 아니라 지속 가능한 협업 방식을 함께 설계한다.

---

7. 한 문장 회고

이번 프로젝트를 통해 나는 뾰족한 문제 정의만큼이나, 그 문제 정의를 팀이 끝까지 잃지 않도록 회의와 액션을 설계하는 능력이 중요하다는 것을 배웠다.