들어가며: 가장 빠른 길이 가장 먼 길일 때
월요일 오전, 팀에 요청이 하나 들어옵니다. "검색 결과 페이지에 무한 스크롤을 넣어주세요."
성실한 엔지니어라면 곧바로 손이 움직입니다. 페이지네이션 로직을 걷어내고, 스크롤 이벤트를 붙이고, 다음 페이지를 미리 불러오는 prefetch를 구현합니다. 사흘 만에 깔끔하게 동작하는 무한 스크롤이 완성됩니다. 코드 리뷰도 통과하고, 배포도 매끄럽게 끝납니다. 모두가 만족스러워 보입니다.
그런데 2주 뒤, 같은 요청자가 다시 찾아옵니다. "사용자들이 여전히 원하는 결과를 못 찾는다고 해요. 무한 스크롤을 넣었는데도요." 이제야 진짜 대화가 시작됩니다. 알고 보니 문제는 "스크롤이 불편하다"가 아니라 "검색 정확도가 낮다"였습니다. 사용자는 페이지를 넘기는 게 귀찮았던 게 아니라, 10페이지를 넘겨도 원하는 항목이 안 나와서 포기했던 것입니다. 무한 스크롤은 그저 나쁜 결과를 더 빠르게, 더 많이 보여주는 장치였을 뿐입니다.
사흘이 통째로 사라졌습니다. 정확히 말하면, 사흘 동안 매우 효율적으로 **잘못된 문제를 풀었습니다.**
이 글은 "더 열심히 일하라"는 이야기가 아닙니다. 오히려 그 반대입니다. 일을 시작하기 전에 잠깐 멈춰서 "우리가 지금 푸는 게 진짜 풀어야 할 문제가 맞나?"를 확인하는, 어쩌면 가장 비용 대비 효과가 큰 습관에 대한 이야기입니다. 답을 잘 내는 능력은 흔합니다. 문제를 잘 고르는 능력은 드뭅니다. 그리고 후자가 거의 항상 더 중요합니다.
1. 잘못된 문제를 푸는 것의 진짜 비용
우리는 보통 "느리게 일하는 것"을 낭비라고 생각합니다. 하지만 실제로 가장 비싼 낭비는 "빠르게 잘못된 답에 도달하는 것"입니다. 왜냐하면 잘못된 답은 그것이 틀렸다는 사실을 한참 뒤에야 알려주기 때문입니다.
낭비의 구조를 펼쳐 보면 이렇습니다.
잘못된 문제를 선택
│
▼
설계 / 구현 (시간 투입)
│
▼
배포 / 출시
│
▼
"왜 효과가 없지?" (지연된 깨달음)
│
▼
원인 분석 / 롤백 / 재작업
│
▼
진짜 문제를 다시 정의 (출발점으로 회귀)
이 흐름에서 가장 무서운 부분은 "지연된 깨달음"입니다. 잘못 푼 문제는 즉시 빨간불을 켜지 않습니다. 코드는 잘 돌아가고, 기능은 멀쩡히 동작합니다. 단지 아무도 원하지 않던 것을 잘 만들었을 뿐입니다. 그 사실이 드러나기까지 며칠, 때로는 몇 달이 걸립니다.
여기에 더해 두 가지 숨은 비용이 따라옵니다.
첫째, **매몰 비용의 함정**입니다. 이미 사흘을 쓴 무한 스크롤을 두고 "사실 이게 문제가 아니었어요"라고 말하기는 어렵습니다. 그래서 많은 팀이 잘못된 해결책 위에 또 다른 기능을 얹으며 문제를 키웁니다.
둘째, **신뢰의 침식**입니다. 요청자 입장에서는 "분명히 해달라는 걸 해줬는데 왜 안 풀리지?"라는 의문이 쌓입니다. 결국 "이 팀은 일은 빨리 하는데 문제를 못 푼다"는 평판이 생깁니다. 빠른 손이 오히려 신뢰를 깎는 역설입니다.
그래서 문제 정의에 쓰는 시간은 비용이 아니라 투자입니다. 30분의 질문이 사흘의 재작업을 막는다면, 그것은 144배의 수익률입니다.
2. 해결책이 아니라 문제를 받아라
대부분의 요청은 문제가 아니라 **이미 해결책의 모습으로** 도착합니다. "무한 스크롤을 넣어주세요", "대시보드에 그래프를 추가해주세요", "알림을 더 자주 보내주세요." 이것들은 전부 누군가가 머릿속에서 한 번 문제를 풀어본 뒤 내놓은 답입니다.
요청자가 해결책을 들고 오는 것은 자연스러운 일입니다. 그들도 바쁘고, 자기 나름의 맥락 안에서 "이렇게 하면 되겠지"라고 생각했기 때문입니다. 문제는 그 답이 그들이 가진 정보와 시간 안에서 나온 임시 해법일 뿐이라는 점입니다. 그 영역을 매일 들여다보는 전문가는 오히려 요청을 받는 쪽입니다.
그래서 첫 번째 동작은 언제나 같습니다. **해결책을 한 단계 거슬러 올라가 문제를 복원하는 것.**
요청자가 말한 것: "무한 스크롤을 넣어주세요" ← 해결책
│ (한 단계 거슬러 올라간다)
▼
실제 불편: "원하는 결과를 못 찾는다" ← 증상
│ (한 단계 더)
▼
진짜 문제: "검색 정확도가 낮다" ← 문제
│ (한 단계 더)
▼
근본 니즈: "빠르게 정확한 정보에 닿고 싶다" ← 니즈
이 거슬러 올라가기를 건너뛰면, 우리는 남의 머릿속 해법을 대신 구현하는 사람이 됩니다. 거슬러 올라가면, 우리는 함께 더 나은 답을 찾는 사람이 됩니다. 그 차이는 작업의 결과뿐 아니라 우리가 일에서 차지하는 위치를 바꿉니다.
3. 5 Whys: 증상에서 원인으로
문제를 거슬러 올라가는 가장 단순하고 강력한 도구는 도요타 생산 방식에서 비롯된 5 Whys입니다. 방법은 이름 그대로입니다. "왜?"를 다섯 번쯤 반복해서, 표면 증상에서 근본 원인까지 파고드는 것입니다. 다섯이라는 숫자는 규칙이 아니라 어림짐작입니다. 보통 다섯 번쯤 물으면 더 이상 통제할 수 없는 영역(시장, 날씨, 인간 본성)에 닿거나, 실제로 손댈 수 있는 원인에 도달합니다.
실제 사례로 풀어보겠습니다. 한 SaaS 팀에 "신규 가입자 수가 줄고 있다"는 문제가 올라왔습니다.
문제: 이번 달 신규 가입자가 전월 대비 20% 감소했다.
왜 가입자가 줄었나?
→ 가입 페이지 방문자 중 가입 완료 비율(전환율)이 떨어졌다.
왜 전환율이 떨어졌나?
→ 가입 폼 마지막 단계에서 이탈하는 사람이 늘었다.
왜 마지막 단계에서 이탈하나?
→ 그 단계에서 "회사 결제 정보"를 먼저 입력하라고 요구한다.
왜 결제 정보를 먼저 요구하나?
→ 지난달 무료 체험 악용을 막으려고 카드 등록을 앞단으로 옮겼다.
왜 카드 등록을 앞단으로 옮겼나?
→ 어뷰징 대응을 "가입 단계 강화"로만 접근했고,
다른 방어 수단(이메일 인증, 사용량 제한)을 검토하지 않았다.
근본 원인: 어뷰징을 막는 방법으로 "가입 마찰을 키우는 것"을 선택했고,
그 부작용으로 정상 사용자까지 함께 막고 있다.
처음 받은 문제는 "가입자가 줄었다"였습니다. 만약 여기서 멈췄다면, 우리는 광고를 더 집행하거나 가입 버튼을 키우는 식으로 대응했을 것입니다. 전부 헛수고였을 것입니다. 5 Whys를 거치고 나니 진짜 문제는 "어뷰징 방어가 정상 사용자를 막고 있다"는, 완전히 다른 문제였습니다. 해결책도 달라집니다. 카드 등록을 뒤로 미루고, 이메일 인증과 사용량 기반 제한으로 어뷰징을 막으면 됩니다.
5 Whys를 쓸 때 주의할 점이 몇 가지 있습니다.
- **사람이 아니라 시스템을 향하라.** "누가 그랬나?"가 아니라 "왜 그런 일이 가능했나?"를 물어야 합니다. 범인 찾기로 흐르면 사람들이 방어적으로 변하고, 진짜 원인은 숨습니다.
- **한 줄기로만 파지 마라.** 어떤 문제는 원인이 여러 갈래입니다. 필요하면 "왜?"에서 가지를 쳐서 여러 경로를 따라가십시오.
- **증거로 확인하라.** "왜?"의 답이 추측이라면, 그것은 또 다른 가설일 뿐입니다. 가능하면 로그, 데이터, 사용자 인터뷰로 각 단계를 검증하십시오.
4. 리프레이밍: 같은 상황을 다른 문제로
5 Whys가 "아래로 파는" 도구라면, 리프레이밍(reframing)은 "옆으로 비트는" 도구입니다. 같은 상황을 전혀 다른 문제로 다시 진술하는 것입니다.
토머스 베델-베델스보르(Thomas Wedell-Wedellsborg)가 든 유명한 예가 있습니다. 한 건물의 입주자들이 "엘리베이터가 너무 느리다"고 끊임없이 불평합니다. 엔지니어의 본능은 명확합니다. 모터를 교체하거나, 알고리즘을 개선하거나, 새 엘리베이터를 설치하는 것. 전부 비싸고 오래 걸립니다.
그런데 건물 관리자는 문제를 다르게 진술했습니다. "엘리베이터가 느리다"가 아니라 **"기다리는 시간이 지루하다."** 이렇게 문제를 바꾸자 해결책이 완전히 달라집니다. 엘리베이터 옆에 거울을 답니다. 사람들은 거울 앞에서 자기 모습을 보거나 다른 사람을 슬쩍 관찰하느라 기다림을 덜 느낍니다. 불평은 사라집니다. 거의 공짜로.
리프레이밍의 핵심은 "이 문제를 다른 방식으로 진술하면 어떻게 될까?"라는 질문입니다. 몇 가지 실전 각도가 있습니다.
원래 진술: "엘리베이터가 느리다"
─────────────────────────────────────
다른 주체로: "관리실이 불평 처리에 시달린다"
다른 감정으로:"기다리는 시간이 지루하다"
반대로: "사람들이 기다린다는 사실 자체를 어떻게 줄일까"
범위 확대: "이 건물의 동선 자체가 비효율적이다"
범위 축소: "출근 시간 8~9시에만 대기가 길다"
각 진술은 서로 다른 해결책의 문을 엽니다. "느리다"는 토목 공사를, "지루하다"는 거울을, "8~9시에만"은 시차 출근이나 한 대를 그 시간대 전용으로 돌리는 운영 변경을 부릅니다. 좋은 문제 정의자는 답을 찾기 전에 진술을 여러 개 만들어 봅니다.
리프레이밍을 일상에 적용하는 작은 습관은 이렇습니다. 문제를 한 문장으로 적은 뒤, **그 문장의 핵심 명사나 동사를 하나씩 바꿔보는 것**입니다. "사용자가 기능을 못 찾는다"에서 "찾는다"를 "필요로 한다"로 바꾸면 "사용자가 그 기능을 정말 필요로 하는가?"라는 더 근본적인 질문이 열립니다.
5. 인버전: 거꾸로 생각하기
찰리 멍거가 즐겨 인용하는 사고법이 인버전(inversion)입니다. "어떻게 성공할까?"를 묻는 대신 "어떻게 하면 확실히 실패할까?"를 묻는 것입니다. 실패의 조건을 나열한 뒤 그것들을 피하면, 종종 정공법보다 더 선명한 길이 보입니다.
문제 정의에 인버전을 적용하면 이렇습니다.
정방향 질문: "어떻게 하면 온보딩을 개선할까?"
→ 막연하다. 무엇이든 답이 될 수 있다.
역방향 질문: "어떻게 하면 신규 사용자가 확실히 떠나게 만들까?"
→ 가입 직후 빈 화면만 보여준다
→ 첫 단계부터 어려운 설정을 강요한다
→ 무엇을 해야 할지 안내하지 않는다
→ 첫 성공 경험까지 너무 오래 걸리게 한다
이제 이 목록을 뒤집으면 = 해야 할 일의 목록이 된다.
→ 가입 직후 의미 있는 첫 화면을 보여준다
→ 설정을 최소화하거나 나중으로 미룬다
→ 다음 행동을 명확히 안내한다
→ 첫 성공 경험을 빠르게 만든다
인버전이 강력한 이유는, 사람은 "무엇을 더할까"보다 "무엇이 망치는가"를 훨씬 구체적으로 떠올리기 때문입니다. 막연한 개선 과제를 받았을 때, 잠깐 방향을 뒤집어 "이걸 확실히 망치는 방법"을 적어보면 의외로 손에 잡히는 행동 목록이 나옵니다.
6. 진짜 니즈를 찾는 법: 해결책 아래의 욕구
문제를 거슬러 올라가다 보면 결국 **근본 니즈(underlying need)**에 닿습니다. 사람들이 요청하는 것과 진짜로 원하는 것은 다를 때가 많습니다. 흔히 인용되는 비유처럼, 사람들은 드릴을 사고 싶은 게 아니라 벽에 구멍을 내고 싶은 것이고, 더 깊게는 벽에 그림을 걸고 싶은 것입니다.
니즈를 캐낼 때 가장 흔한 함정은 "원하는 게 뭐예요?"라고 직접 묻는 것입니다. 사람들은 자기 니즈를 잘 모르거나, 안다고 착각하거나, 이미 해결책의 언어로 답합니다. 그래서 미래의 가정을 묻는 대신 **과거의 사실을 물어야** 합니다. 이것이 롭 피츠패트릭의 "더 맘 테스트(The Mom Test)"가 주는 핵심 교훈입니다. 엄마에게 사업 아이디어를 물으면 거짓말(선의의 칭찬)을 듣지만, 엄마의 실제 행동을 물으면 진실을 듣습니다.
좋은 니즈 발굴 질문과 나쁜 질문을 비교해 보겠습니다.
| 나쁜 질문 (해결책/가정을 묻는다) | 좋은 질문 (사실/행동을 묻는다) |
| --- | --- |
| 이 기능이 있으면 쓰시겠어요? | 마지막으로 이 일을 했을 때 어떻게 하셨나요? |
| 알림이 더 많으면 좋을까요? | 지금은 이걸 어떻게 챙기고 계세요? |
| 가격이 얼마면 사시겠어요? | 비슷한 도구에 지금 얼마를 쓰고 계세요? |
| 이거 좋은 아이디어 같지 않아요? | 이 문제 때문에 마지막으로 곤란했던 게 언제였나요? |
| 대시보드가 필요하신가요? | 그 숫자를 확인하려고 지금 어떤 과정을 거치세요? |
왼쪽 질문들은 모두 미래의 의견이나 가정을 묻습니다. 사람들은 예의상 "네, 좋을 것 같아요"라고 답하고, 우리는 그 칭찬을 근거로 잘못된 것을 만듭니다. 오른쪽 질문들은 이미 일어난 구체적 행동을 묻습니다. 행동은 거짓말을 하지 않습니다. "지난주에 그 숫자를 확인하려고 세 개의 스프레드시트를 열어 손으로 합쳤다"는 답은, 그 어떤 "대시보드 좋아요"보다 진짜 니즈를 정확히 알려줍니다.
7. XY 문제: 해결책에 갇힌 질문
니즈를 못 찾는 전형적인 패턴에 이름이 붙어 있습니다. XY 문제입니다. 진짜 문제 X가 있는데, 자기 나름대로 떠올린 해결책 Y에 막혀서, Y에 대해서만 질문하는 상황입니다.
기술 지원 채널에서 매일 벌어지는 대화로 보겠습니다.
질문자: 파일 이름에서 마지막 세 글자만 어떻게 떼어내나요?
답변자: 잘라낸 세 글자로 뭘 하시려고요?
질문자: 파일 확장자를 바꾸려고요.
답변자: 아... 확장자가 항상 세 글자는 아니에요(.jpeg, .html).
진짜 하려는 건 "확장자 바꾸기"군요. 그건 이렇게 합니다...
질문자는 X("확장자를 바꾸고 싶다")를 풀려고 스스로 Y("마지막 세 글자를 떼어낸다")라는 해결책을 떠올렸고, 그 Y에 막혀서 Y에 대해서만 물었습니다. 답변자가 Y만 풀어줬다면, 질문자는 ".jpeg" 같은 파일에서 조용히 깨지는 코드를 얻었을 것입니다.
XY 문제를 깨는 질문은 언제나 하나입니다. **"그걸로 결국 뭘 하려고 하세요?"** 또는 **"한 단계 위에서, 진짜 풀려는 문제가 뭔가요?"** 이 질문은 상대를 자기 해결책의 우물에서 끌어올려 원래의 문제로 데려옵니다. 우리가 질문을 받는 쪽일 때도, 우리가 질문을 하는 쪽일 때도, 항상 던질 가치가 있는 질문입니다.
8. 좋은 질문의 구조
문제를 잘 정의하는 일은 결국 잘 묻는 일입니다. 질문에도 구조가 있습니다.
8.1 개방형 vs 폐쇄형
폐쇄형 질문은 예/아니오나 정해진 보기 중 하나로 답하게 합니다. 개방형 질문은 상대가 자기 언어로 풀어 말하게 합니다. 둘 다 쓸모가 있지만, **문제를 탐색하는 단계에서는 개방형이, 결정을 좁히는 단계에서는 폐쇄형이** 맞습니다.
| 폐쇄형 (좁힌다, 확인한다) | 개방형 (넓힌다, 탐색한다) |
| --- | --- |
| 이 기능 쓰기 불편하셨어요? | 이 기능을 쓸 때 어떤 경험이셨어요? |
| 마감은 금요일 맞나요? | 이 일정에서 가장 걱정되는 부분은 무엇인가요? |
| A안과 B안 중 뭐가 나아요? | 이 결정에서 가장 중요한 기준은 무엇인가요? |
탐색 단계에서 폐쇄형 질문만 던지면, 우리는 우리가 이미 떠올린 보기 안에서만 답을 듣게 됩니다. 정작 보기 밖에 있던 진짜 문제는 영영 드러나지 않습니다. 그래서 초반에는 "어떻게", "무엇을", "왜", "어떤 경우에" 같은 개방형 어두로 시작하는 질문을 의식적으로 더 많이 던져야 합니다.
8.2 가정을 드러내는 질문
모든 문제 진술에는 숨은 가정이 깔려 있습니다. 좋은 질문은 그 가정을 수면 위로 끌어올립니다.
요청: "결제 페이지 로딩이 느려서 고쳐야 해요."
숨은 가정을 드러내는 질문들:
- 느리다는 건 구체적으로 몇 초를 말하나요? (정량화)
- 모든 사용자에게 느린가요, 특정 조건에서만 느린가요? (범위)
- 느려서 실제로 어떤 일이 벌어지고 있나요? (영향)
- 로딩 속도가 진짜 문제일까요, 아니면 이탈이 진짜 문제일까요? (재정의)
- 지금이 고칠 적기인 이유가 있나요? (우선순위)
"느리다"는 한 단어 안에 "얼마나", "누구에게", "그래서 무엇이 문제인지"라는 세 가지 가정이 압축되어 있습니다. 이 가정을 펼치지 않으면, 우리는 측정되지 않은 목표를 향해 일하게 됩니다. 무엇이 "충분히 빠른 것"인지 합의되지 않은 채로요.
8.3 질문에도 예의가 있다
질문은 자칫 추궁처럼 들립니다. 같은 질문도 어조에 따라 협력으로도, 저항으로도 들립니다. 핵심은 **질문 앞에 의도를 먼저 밝히는 것**입니다.
저항으로 들리는 질문:
"이거 굳이 지금 해야 돼요?"
협력으로 들리는 질문:
"이걸로 달성하려는 목표를 알면 가장 잘 맞는 방법을 제안드릴 수 있을 것 같아요.
혹시 이 일이 어떤 더 큰 목표와 연결되어 있을까요?"
"왜요?"는 따지는 말이 아니라 "더 잘 돕기 위해 맥락을 달라"는 신호여야 합니다. 의도를 먼저 깔면, 같은 질문이 방어가 아니라 협업의 초대가 됩니다.
9. 가설을 세우고 검증하라
문제를 정의했다고 해서 그것이 옳다는 보장은 없습니다. 문제 정의 자체도 하나의 가설입니다. 그래서 좋은 문제 정의는 검증 가능한 형태로 적혀야 합니다.
검증 가능한 가설은 대략 이런 틀을 따릅니다.
[누가] 가 [어떤 상황에서] [무엇 때문에] [어떤 어려움]을 겪고 있다고
우리는 믿는다. 이것이 사실이라면, [관찰 가능한 신호]가 보일 것이다.
우리는 [방법]으로 이것을 확인하겠다.
검색 사례에 적용해 보면 이렇습니다.
우리는 이렇게 믿는다:
검색을 쓰는 사용자가, 결과 정확도가 낮아서, 원하는 항목을
찾지 못하고 이탈하고 있다.
사실이라면 이런 신호가 보일 것이다:
- 검색 후 첫 3개 결과 클릭률이 낮다
- 같은 키워드로 여러 번 재검색한다
- 검색 세션이 클릭 없이 끝나는 비율이 높다
이렇게 확인하겠다:
- 검색 로그에서 위 지표를 측정한다
- 사용자 5명에게 실제 검색 과정을 관찰한다
이렇게 적어두면 두 가지 이점이 있습니다. 첫째, 문제가 틀렸을 때 빨리 알 수 있습니다. 신호가 안 보이면 가설이 틀린 것이니, 사흘을 쓰기 전에 방향을 바꿉니다. 둘째, 나중에 "이 문제를 왜 풀기로 했는지" 근거가 문서로 남습니다. 직감이 아니라 검증된 판단이 됩니다.
작게 검증할 수 있다면 언제나 작게 검증하는 편이 낫습니다. 전체를 만들어 출시한 뒤 시장에서 확인하는 것보다, 프로토타입 하나나 사용자 인터뷰 다섯 건으로 먼저 확인하는 것이 훨씬 쌉니다.
10. 제약과 범위를 명확히 하라
문제를 정의했어도 경계가 흐릿하면 일은 끝없이 번집니다. "검색을 개선하자"는 한 달이 걸릴 수도, 일 년이 걸릴 수도 있습니다. 그래서 문제에는 반드시 제약과 범위가 붙어야 합니다.
세 가지를 명시적으로 적으십시오.
범위 안(In scope):
- 키워드 검색 결과의 순위 알고리즘 개선
- 오타 보정
범위 밖(Out of scope):
- 음성 검색
- 추천 시스템 전면 개편
- 검색 UI 리디자인
제약(Constraints):
- 2주 안에 첫 개선 배포
- 기존 검색 인프라 안에서 해결(새 검색엔진 도입 불가)
- 응답 시간 200밀리초 이내 유지
"범위 밖"을 명시하는 것은 "범위 안"을 정하는 것만큼 중요합니다. 무엇을 안 할지 합의하지 않으면, 좋은 의도를 가진 누군가가 계속 새 요구를 끼워 넣어 문제를 부풀립니다. 이른바 스코프 크리프입니다. 제약은 답답한 울타리가 아니라, 끝낼 수 있게 해주는 트랙입니다. 베이스캠프의 셰이프 업(Shape Up)이 말하는 "고정된 시간, 변동하는 범위(fixed time, variable scope)"도 같은 정신입니다. 시간을 고정해두면 우리는 그 안에서 무엇이 진짜 중요한지를 강제로 골라내게 됩니다.
11. 이해관계자 정렬: 모두가 같은 문제를 보는가
같은 문제를 두고도 사람마다 머릿속 그림이 다릅니다. 영업은 "큰 고객이 검색이 별로라고 한다"를, 디자이너는 "검색 UI가 낡았다"를, 엔지니어는 "검색 인덱싱이 느리다"를 떠올립니다. 세 사람 모두 "검색 문제"를 말하지만, 실은 세 개의 다른 문제를 말하고 있습니다.
문제 정의 단계에서 이 차이를 드러내지 않으면, 나중에 결과물을 두고 충돌합니다. 그래서 한 문장의 합의된 문제 진술을 만드는 일이 중요합니다. 이것을 한 줄로 적고, 관련된 사람 모두에게 "이게 우리가 풀려는 문제가 맞나요?"라고 확인받으십시오.
합의된 문제 진술 (한 문장):
"엔터프라이즈 사용자가 자주 쓰는 키워드로 검색했을 때,
원하는 결과가 상위 3개 안에 나오지 않아 수동으로 자료를
다시 찾는 비효율을 겪고 있다."
확인 질문:
- 영업: "큰 고객이 말한 게 이거 맞나요?"
- 디자인: "UI 문제가 아니라 정확도 문제로 봐도 될까요?"
- 엔지니어: "이 범위라면 2주 안에 첫 개선이 가능한가요?"
이 한 문장이 합의되면, 이후의 모든 논쟁이 짧아집니다. 누군가 새 아이디어를 가져와도 "그게 이 문제 진술에 맞나요?"라는 한 가지 잣대로 빠르게 거를 수 있습니다. 정렬은 회의 시간을 늘리는 절차가 아니라, 나중의 재작업과 갈등을 줄이는 투자입니다.
12. 구체적 사례: 요구사항 뒤집기
문제 재정의가 실제로 어떻게 일을 바꾸는지, 한 사례를 끝까지 따라가 보겠습니다.
영업팀에서 요청이 옵니다. "고객사마다 보고서를 PDF로 내보내는 버튼을 추가해주세요. 고객들이 PDF를 자꾸 요청해요."
성급한 팀은 바로 PDF 생성 기능을 만듭니다. 폰트가 깨지고, 표가 페이지를 넘어가고, 차트 해상도가 안 맞는 등 PDF 렌더링의 온갖 함정에 사흘을 씁니다. 그런데 문제를 거슬러 올라가 봅니다.
요청: "PDF 내보내기 버튼" ← 해결책
│ 왜 PDF가 필요한가?
▼
증상: "고객이 보고서를 PDF로 달라고 한다"
│ 왜 PDF 형태를 원하는가?
▼
이유: "고객이 내부 임원에게 그 보고서를 공유해야 한다"
│ 임원에게 공유할 때 PDF여야만 하는가?
▼
진짜 문제: "고객이 우리 데이터를 자기 조직 안에서 쉽게
공유하지 못한다"
│ 그렇다면 공유를 가장 잘 돕는 방법은?
▼
니즈: "신뢰할 수 있는 형태로, 받는 사람이 별도 로그인 없이
볼 수 있게 공유하고 싶다"
진짜 문제가 "공유"라는 것을 알고 나면, 해결책의 선택지가 넓어집니다. PDF는 그중 하나일 뿐입니다.
가능한 해결책들 (진짜 문제 = "쉬운 공유"):
- 로그인 없이 볼 수 있는 공유 링크(읽기 전용)
- 이메일로 보고서 요약을 자동 발송
- PDF 내보내기 (원래 요청)
- 임원용 한 페이지 요약 뷰
여기서 흥미로운 점은, 공유 링크가 PDF보다 만들기 쉬울 수 있고, 동시에 항상 최신 데이터를 보여준다는 더 큰 가치를 준다는 것입니다(PDF는 만든 순간 낡기 시작합니다). 물론 보안상 외부 공유 링크가 안 되는 고객도 있을 테니, 최종 답은 한 가지가 아닐 수 있습니다. 핵심은 "PDF 버튼"이라는 요청을 곧이곧대로 받았다면 절대 떠오르지 않았을 선택지들이, 문제를 한 단계 거슬러 올라가자 모두 테이블 위에 올라왔다는 점입니다.
13. 안티패턴: 피해야 할 함정들
문제 정의를 망치는 전형적인 패턴들이 있습니다. 알아두면 자기 자신이 그 함정에 빠지는 순간을 알아챌 수 있습니다.
**솔루션부터 제시하기.** 가장 흔하고 가장 비싼 함정입니다. 문제를 듣자마자 "아, 그건 X로 하면 돼요"라고 답이 튀어나옵니다. 머리가 빠르다는 신호처럼 느껴지지만, 사실은 문제를 충분히 이해하기도 전에 자기 경험 안의 익숙한 답으로 점프한 것입니다. 답이 떠오르는 것은 막을 수 없지만, 그 답을 입 밖에 내기 전에 "그런데 진짜 문제가 뭐였더라?"를 한 번 되묻는 습관이 차이를 만듭니다.
**문제를 측정하지 않기.** "느리다", "불편하다", "별로다" 같은 형용사로만 문제를 적으면, 다 풀었는지 영영 알 수 없습니다. "3초가 1초로 줄면 해결"처럼 측정 가능한 형태로 적어야 끝이 있습니다.
**한 사람의 목소리를 전체로 착각하기.** "고객이 PDF를 원한다"의 '고객'이 사실 한 명일 수 있습니다. 한 명의 강한 요청과 다수의 조용한 니즈를 구분하지 못하면, 소수를 위해 다수의 자원을 씁니다.
**증상을 반복해서 끄기.** 같은 문제가 자꾸 다른 모습으로 돌아온다면, 우리는 근본 원인이 아니라 증상만 끄고 있는 것입니다. 5 Whys가 필요한 순간입니다.
**문제 정의에 무한정 머무르기.** 반대 방향의 함정도 있습니다. 분석만 끝없이 하면서 아무것도 시작하지 않는 분석 마비입니다. 문제 정의의 목적은 완벽한 이해가 아니라 "지금 한 발 내디뎌도 좋을 만큼의 충분한 이해"입니다. 검증 가능한 가설을 세웠고 가장 큰 가정을 확인했다면, 그다음은 작게 움직이며 배우는 단계입니다.
균형이 중요합니다. 문제 정의는 일을 미루는 핑계가 아니라, 일을 제대로 시작하기 위한 준비입니다.
14. 실전 체크리스트
요청을 받았을 때, 일을 시작하기 전에 다음을 빠르게 점검해 보십시오. 사소하거나 명백한 일이라면 전부 거칠 필요는 없습니다. 하지만 시간이 많이 드는 일일수록 이 목록의 가치는 커집니다.
[ 문제 복원 ]
- 이 요청은 해결책인가, 문제인가?
- 해결책이라면, 한 단계 거슬러 올라간 진짜 문제는 무엇인가?
- "이걸로 결국 뭘 하려고 하는가?"를 물었는가? (XY 문제 확인)
[ 근본 원인 ]
- 5 Whys로 증상 아래를 파봤는가?
- 각 "왜?"의 답은 추측인가, 증거인가?
- 문제를 다르게 진술해봤는가? (리프레이밍)
[ 니즈와 검증 ]
- 사용자의 "의견"이 아니라 "행동/사실"을 물었는가?
- 문제 정의를 검증 가능한 가설로 적었는가?
- 가장 큰 가정 하나를 싸게 확인할 방법이 있는가?
[ 범위와 제약 ]
- 무엇이 범위 안이고, 무엇이 범위 밖인가?
- 시간/기술/자원의 제약을 적었는가?
- 성공의 측정 기준은 무엇인가?
[ 정렬 ]
- 한 문장으로 된 합의된 문제 진술이 있는가?
- 관련된 사람들이 같은 문제를 보고 있는가?
[ 균형 ]
- 분석 마비에 빠지지 않고 한 발 내디딜 만큼 이해했는가?
마치며: 답을 잘 내는 사람에서 문제를 잘 고르는 사람으로
답을 내는 능력은 점점 더 흔해지고 있습니다. 도구는 빨라지고, 정보는 넘치고, 무엇이든 빠르게 만들 수 있는 시대입니다. 그래서 역설적으로 더 귀해진 능력은 "무엇을 만들지 고르는 능력", 곧 문제를 정의하는 능력입니다.
이 글에서 다룬 도구들은 거창하지 않습니다. "왜?"를 다섯 번 묻기, 같은 상황을 다른 문장으로 적어보기, 거꾸로 뒤집어 보기, 의견 대신 행동을 묻기, 한 문장으로 합의하기. 전부 30분이면 할 수 있는 일들입니다. 하지만 그 30분이 사흘을, 때로는 한 분기를 구합니다.
기억할 것은 단순합니다. 일을 시작하기 전에 잠깐 멈추고 물으십시오. **"우리가 지금 푸는 게, 진짜 풀어야 할 문제가 맞나요?"** 이 질문을 정중하게, 그러나 빠뜨리지 않고 던질 수 있다면, 여러분은 시키는 일을 처리하는 사람을 넘어, 무엇을 할지 함께 정하는 사람이 됩니다. 그리고 거의 모든 조직에서, 그 차이가 결국 신뢰와 영향력을 만듭니다.
좋은 답을 서두르기 전에, 좋은 문제를 먼저 고르십시오. 답보다 문제가 중요합니다.
참고 자료
- Thomas Wedell-Wedellsborg, "Are You Solving the Right Problems?" — Harvard Business Review (hbr.org/2017/01/are-you-solving-the-right-problems)
- Thomas Wedell-Wedellsborg, *What's Your Problem?* (문제 재구성/리프레이밍에 관한 책)
- "5 Whys" 기법 개요 — Wikipedia (en.wikipedia.org/wiki/Five_whys)
- Lean Enterprise Institute (lean.org) — 도요타 생산 방식과 근본 원인 분석
- Rob Fitzpatrick, *The Mom Test* (momtestbook.com) — 진짜 니즈를 캐는 질문법
- XY 문제 설명 (xyproblem.info)
- Will Larson, lethain.com — 전략과 글쓰기, 엔지니어링 의사결정에 관한 글
- Basecamp, *Shape Up* (basecamp.com/shapeup) — 문제를 형상화하고 범위를 고정하는 방법
- Richard Feynman / 제1원리 사고(first principles)에 관한 일반 자료
현재 단락 (1/245)
월요일 오전, 팀에 요청이 하나 들어옵니다. "검색 결과 페이지에 무한 스크롤을 넣어주세요."