문제를 쪼개라
- Zoom in/Zoom out
2026 All-Day-Project (132/365)
도넛을 사는 농부의 문제 정의법
3장: 5 Why로 내려가고, JTBD로 다시 올라오기
4장: 문제를 이야기로 써라 - 문제 정의문의 서사 구조
5장: 문제를 쪼개라 - Zoom in/Zoom out (이 글)
프롤로그: 큰 바위와 작은 자갈
농부가 밭을 갈려고 합니다. 그런데 밭 한가운데에 거대한 바위가 하나 있습니다.
농부는 혼자서 그 바위를 들어 올리려다 등을 다칩니다.
지혜로운 이웃이 말합니다.
“바위 전체를 옮기려 하지 말고, 쪼개라. 작은 조각으로.”
농부는 쇠망치와 끌로 바위에 금을 갑니다.
작은 조각이 떨어져 나가고, 또 하나, 또 하나. 결국 바위는 사라집니다.
반대로, 어떤 농부는 너무 작은 자갈 하나하나에 집착합니다.
“여기 자갈 하나, 저기 자갈 하나…” 그는 하루 종일 자갈만 줍다가, 결국 큰 바위는 건드리지 못합니다.
PM도 마찬가지입니다.
어떤 문제는 너무 커서 한 번에 풀 수 없습니다. 쪼개야 합니다.
또 어떤 문제는 너무 작게 쪼개서, 진짜 중요한 근본 문제를 놓치기도 합니다.
이 장에서는 문제를 적절한 크기로 나누는 법을 배웁니다.
1. 왜 문제를 쪼개야 하는가?
이유 1: 실행 가능해진다
“사용자 경험을 개선하라”는 너무 큽니다.
하지만 “회원가입 첫 화면의 ‘다음’ 버튼 클릭률을 10% 높여라”는 실행 가능합니다.
이유 2: 우선순위를 정할 수 있다
하나의 거대한 문제를 놓고 “이거 먼저 할까 저거 먼저 할까” 싸우는 것은 시간 낭비입니다.
문제를 작게 쪼개면, “이 하위 문제는 지금 당장, 저 문제는 나중에”라고 결정할 수 있습니다.
이유 3: 측정과 피드백이 가능해진다
큰 문제를 풀고 나서야 “아, 실패했네”를 아는 것은 너무 늦습니다. 작은 문제를 하나씩 풀어가면서, 중간중간 성공과 실패를 확인할 수 있습니다.
2. 하지만 너무 작게 쪼개면 안 되는 이유
위험 1: 숲을 보지 못하고 나무만 본다
“버튼 색깔을 바꾸자”, “폰트 크기를 늘리자”, “문구를 수정하자” 같은 작은 문제들에 빠지면, “왜 사용자가 가입을 포기하는가”라는 근본 문제를 놓칩니다.
위험 2: 해결바카라이 먼저 정해진다
작은 문제로 쪼개는 순간, 이미 해결바카라의 범위가 좁혀집니다. 예를 들어 “회원가입 폼의 필드를 10개에서 5개로 줄이자”는 문제는, 이미 ‘폼을 줄인다’는 해결바카라을 전제로 한 것입니다.
위험 3: 조정 비용이 커진다
너무 잘게 쪼개면, 수십 개의 작은 문제들이 생겨납니다. 각각을 관리하고, 우선순위를 정하고, 진행 상황을 추적하는 데 드는 비용이 오히려 더 커질 수 있습니다.
3. 쪼개기의 기본 원칙: MECE와 적정 크기
MECE(Mutually Exclusive, Collectively Exhaustive)는 맥킨지에서 유래한 문제 분해 원칙입니다.
- Mutually Exclusive (상호 배타적): 문제들이 서로 겹치지 않아야 한다.
- Collectively Exhaustive (전체 포괄) : 쪼갠 조각들을 모두 모으면 원래 문제가 되어야 한다.
예를 들어, “사용자 가입 전환율 문제”를 쪼개보겠습니다.
세 가지가 서로 겹치지 않으면서, 이 세 가지만 해결하면 전환율 문제의 대부분을 다룰 수 있습니다.
4. Zoom in/Zoom out: 두 가지 렌즈
문제를 쪼갤 때는 두 가지 시점을 번갈아 가며 보는 것이 좋습니다.
Zoom in (확대) – 문제를 더 작게
질문: “이 문제를 구성하는 더 작은 문제들은 무엇인가?”
예: “사용자가 가입을 포기한다”
→ Zoom in:
- 1단계(앱 실행)에서 포기
- 2단계(회원가입 폼 작성)에서 포기
- 3단계(이메일 인증)에서 포기
- 4단계(환영 메시지 이후)에서 포기
이렇게 나누면, “어느 단계에서 가장 많이 포기하는가?”를 알 수 있고, 집중할 지점이 명확해집니다.
Zoom out (축소) – 더 큰 그림 보기
질문: “이 문제가 속한 더 큰 문제는 무엇인가?”
예: “회원가입 폼에서 이탈한다”
→ Zoom out:
- “신규 사용자 온보딩 전체의 문제”
- 더 크게: “제품의 첫인상과 가치 전달 문제”
- 더 크게: “사용자 획득 전략의 효율성 문제”
Zoom out을 하면, 지금 쪼개고 있는 문제가 정말 중요한지,
아니면 더 큰 문제의 일부일 뿐인지 알 수 있습니다.
5. 사례: 문제 쪼개기 연습
원래 문제: “우리 앱의 사용자 리텐션이 낮다.”
1단계 – Zoom out:
“리텐션이 낮다”는 더 큰 문제의 증상일 수 있다.
→ “제품-시장 적합성(PMF)이 아직 부족한가?”
→ “경쟁사 대비 차별점이 없는가?”
2단계 – Zoom in (MECE하게 쪼개기):
리텐션을 다음 단계로 나눈다.
1. Day 0 (가입 직후) 리텐션: 사용자가 앱을 열자마자 꺼버림
2. Day 1-3 리텐션: 처음 며칠 동안 핵심 가치를 경험하지 못함
3. Day 4-7 리텐션: 습관 형성 실패
4. Day 8-30 리텐션: 경쟁사 전환 또는 지루함
3단계 – 각 하위 문제 다시 Zoom in:
예: “Day 1-3 리텐션이 낮다”
→ 온보딩 투어가 너무 길다
→ 첫날 보여줄 핵심 기능이 불분명하다
→ 푸시 알림이 너무 많거나 적다
이렇게 쪼개고 나면, 더 이상 “리텐션이 낮아요”라는 막연한 문제가 아니라,
“온보딩 투어를 5단계에서 3단계로 줄이고, 첫날 핵심 기능 하나에 집중하자”
는 구체적인 액션으로 바뀝니다.
6. 오늘부터 할 수 있는 작은 실천
실천 1: 현재 직면한 문제 하나를 골라 MECE로 쪼개보기
화이트보드에 원 문제를 가운데 적습니다.
그리고 그 문제를 구성하는 3~5개의 하위 문제를 가지처럼 뻗어나가 보세요.
겹치는 것이 없는지, 빠진 것은 없는지 확인합니다.
실천 2: Zoom in과 Zoom out을 번갈아 하기
“이 문제를 더 크게 보면?” (Zoom out)
“이 문제를 더 작게 보면?” (Zoom in)
두 질문을 3번씩 반복해보세요. 어느 순간 문제의 전체 지형이 그려집니다.
실천 3: ‘너무 큰 문제’와 ‘너무 작은 문제’를 구분하는 기준 세우기
팀 룰을 하나 만듭니다.
예: “한 분기 안에 해결 가능한가?” → 너무 크면 쪼갠다.
예: “해결해도 비즈니스 지표가 눈에 띄게 바뀌지 않는가?” → 너무 작으면 합친다.
에필로그: 농부가 밭을 나누는 법
농부는 밭 전체를 한 번에 갈지 않습니다.
그는 밭을 여러 구획으로 나눕니다. 물 빠짐이 좋은 곳, 그늘진 곳, 바람이 많이 부는 곳.
각 구획의 특성에 따라 다른 씨앗을 심고, 다른 방법으로 돌봅니다.
하지만 그는 구획을 너무 잘게 나누지도 않습니다.
1평짜리 구역마다 다른 작물을 심으면, 관리가 불가능해집니다.
그는 적절한 크기로 나눕니다. 한 사람이 하루에 돌볼 수 있는 정도, 한 계절에 수확할 수 있는 정도.
진짜 농부는 말합니다.
“너무 큰 문제는 풀 수 없고, 너무 작은 문제는 풀 가치가 없다. 적절한 크기로 나누는 것이 지혜다.”
이것이 ‘도넛을 사는 농부’의 다섯 번째, 그리고 마지막 성명절기입니다.
여정의 끝, 그리고 새로운 시작
지금까지 우리는 다섯 가지 성명절기를 배웠습니다.
1. 아이디어를 문제로 치환하라 – 요청 뒤에 숨은 진짜 문제를 찾아라.
2. 현상과 원인을 분리하라 – 성급한 결론을 피하고, 사실부터 기록하라.
3. 아래로, 위로, 나선형으로 – 5 Why로 내려가고, JTBD로 올라와라.
4. 문제를 이야기로 써라 – 주인공, 역경, 보상의 서사를 담아라.
5. 문제를 적절히 쪼개라 – Zoom in/Zoom out, MECE하게.
이것이 ‘도넛을 사는 농부’의 문제 정의법입니다.
화려하지 않습니다. 하지만 이 다섯 가지를 반복하다 보면, 당신만의 성명절기가 만들어질 것입니다.