Claude로 문제를 해결하는 법

구조적 사고 완전 정복 — 올바른 문제 정의가 절반이다

Claude, 나는 이렇게 쓴다 【실행 편 시리즈 11편】 — PART 3 : 사고와 전략 · 첫 번째 편 —

"잘 정의된 문제는 이미 절반이 해결된 것이다."

— 찰스 케터링 (Charles Kettering), GM 연구소장

3개월 동안 같은 문제를 풀고 있었다

부산의 물류 스타트업에서 운영을 총괄하는 신다은(37세) 씨는 석 달째 같은 문제로 팀 회의를 했습니다.

"배송 지연이 늘고 있다."

해결책도 석 달째 비슷했습니다. 인력을 늘리자. 시스템을 바꾸자. 프로세스를 점검하자. 그런데 실행해도 달라지지 않았습니다. 배송 지연은 줄지 않았습니다.

그분은 어느 날 Claude에게 지쳐서 털어놓았습니다.

"배송 지연 문제를 석 달 동안 해결 못 하고 있어. 뭐가 문제인 걸까?"

→ Claude: 혹시 지금까지 '배송 지연을 어떻게 줄일까'라는 질문으로 접근하셨나요?

그 질문 자체가 문제일 수 있습니다.

실제 질문이 '배송 지연이 왜 반복되는가'여야 할 수도 있습니다.

증상을 해결하는 것과 원인을 해결하는 것은 다릅니다.

데이터를 보기 전에, 먼저 문제를 다시 정의해 볼게요.

그날 이후 두 주 만에 문제가 해결됐습니다. 원인은 인력도, 시스템도 아니었습니다. 특정 지역 배송 파트너의 차량 상태가 기준 미달이었고, 그것을 측정하는 지표가 없었던 것이 진짜 문제였습니다.

3개월 동안 틀린 문제를 풀고 있었습니다. 올바른 문제를 정의하는 데 30분이 걸렸습니다.

1. 왜 문제 해결이 계속 실패하는가?

문제 해결이 반복 실패하는 데는 구조적 이유가 있습니다.

• 증상을 문제로 착각한다 — '매출이 떨어진다'는 증상입니다. 왜 떨어지는지가 문제입니다

• 해결책부터 찾는다 — 문제를 충분히 이해하기 전에 설루션을 만들면 틀린 답이 나옵니다

• 문제가 너무 크다 — '조직 문화를 바꿔야 한다'는 해결할 수 없는 문제입니다. 쪼개야 합니다

• 가정을 검증하지 않는다 — '고객이 가격 때문에 이탈한다'는 가정입니다. 사실이 아닐 수 있습니다

Claude는 이 네 가지 함정을 각각 짚어냅니다. 증상과 원인을 분리하고, 문제를 쪼개고, 가정을 드러내고, 올바른 질문을 정의하는 과정을 함께 설계합니다.

모든 분야에서 문제를 정의하고 설계하는데 이 생각의 구조와 설계 방법을 배우는 것은 문제 해결과 성과를 내는데 큰 도움을 줄 것이라고 생각합니다. 이는 Claude 뿐만 아니라 다른 AI와 협업하는데 모든 부분에 인사이트를 주기도 합니다.

Claude는 문제를 대신 풀어주지 않습니다. 여러분이 올바른 문제를 보도록 거울을 들어줍니다.

한 가지를 먼저 말씀드립니다. 문제 해결에서 Claude의 역할은 사고 파트너입니다. 현장의 맥락, 조직의 역학, 사람 간의 관계는 Claude가 모릅니다. 구조를 잡는 것은 Claude가 돕지만, 그 구조 안에 무엇을 채울지는 여러분이 판단해야 합니다.

2. 문제 정의의 4단계 프레임

문제를 해결하기 전에 반드시 거쳐야 할 네 단계입니다. 이 단계를 Claude와 함께 밟으면 대부분의 문제는 30분 안에 재정의됩니다.

1단계 — 증상과 원인 분리

지금 보이는 것이 문제인지, 아니면 더 깊은 문제의 증상인지를 먼저 가려야 합니다. 가장 강력한 도구는 '왜?'를 다섯 번 묻는 것입니다.

아래 상황에서 증상과 진짜 원인을 분리해 줘.

현재 상황: [무슨 일이 일어나고 있는가]

지금까지 시도한 해결책: [뭘 해봤는가]

그래도 해결 안 된 이유: [왜 안 됐는가]

'왜?'를 5번 반복해서 근본 원인을 찾아줘.

마지막에 '진짜 문제'를 한 문장으로 정의해 줘.

2단계 — 문제 분해

'회사가 성장을 못 한다'는 해결할 수 없는 문제입니다. 해결 가능한 크기로 쪼개야 합니다. 로직 트리(Logic Tree)로 분해하면 어디서 시작해야 할지 보입니다.

아래 큰 문제를 해결 가능한 단위로 분해해 줘.

큰 문제: [주제]

MECE 원칙(상호 배제, 전체 포괄)으로 하위 문제들을 나눠줘.

각 하위 문제 중 지금 당장 영향력이 가장 큰 것을 골라줘.

그것을 다시 한번 더 분해해서 '오늘 행동 가능한 수준'으로 만들어줘.

3단계 — 가정 드러내기

우리는 항상 어떤 가정 위에서 문제를 정의합니다. 그 가정이 틀리면 해결책도 틀립니다. 가정을 명시적으로 꺼내 검증해야 합니다.

이 문제 정의에 숨어 있는 가정들을 찾아줘.

문제: [정의한 문제]

우리가 당연하게 여기는 것들: [있으면 나열]

이 문제 정의가 '사실'이 아니라 '가정'에 기반한 부분은 어디인지 찾아줘.

각 가정을 검증하려면 어떤 데이터나 확인이 필요한지도 알려줘.

4단계 — 문제 재정의

1~3단계를 거친 후, 처음 정의한 문제가 달라져 있을 것입니다. 이제 해결 가능한 형태로 문제를 다시 씁니다. 좋은 문제 정의는 이 세 가지를 담습니다.

좋은 문제 정의의 조건

① 명확하다 — 누가 읽어도 같은 의미로 이해한다 ② 측정 가능하다 — 해결됐는지 아닌지를 수치로 알 수 있다 ③ 실행 가능하다 — 지금 우리가 영향을 줄 수 있는 범위 안에 있다

아래 문제를 '좋은 문제 정의 조건' 세 가지를 충족하도록 다시 써줘.

원래 문제 정의: [현재 쓰고 있는 문제 문장]

개선된 문제 정의를 3가지 버전으로 써줘.

각 버전이 어떤 접근 방향을 전제하는지도 설명해 줘.

문제를 다시 쓰는 것이 해결책을 쓰는 것보다 어렵습니다. 그리고 훨씬 중요합니다.

3. 실전 대화 — 배송 지연 문제 재정의

신다은 씨와 Claude의 실제 대화 흐름입니다. 30분 안에 3개월 문제가 재정의됐습니다.

이 대화에 전체적인 프레임 설계는 모든 분야에서 적용이 가능하다고 생각됩니다.

▶ 1 턴 — 증상 vs 원인 분리

"배송 지연이 이번 달 12%야. 지난달은 8%였어. 인력 충원도 했고 시스템 점검도 했는데 나아지질 않아."

→ Claude: '왜?'를 다섯 번 물어보겠습니다.

왜 배송이 지연되나요? → 배송 완료 시간이 예상보다 길어집니다

왜 예상보다 길어지나요? → 특정 구간에서 지체가 생깁니다

왜 그 구간에서 지체가 생기나요? → 파트너 배송사마다 차이가 큽니다

왜 파트너사마다 차이가 나나요? → 측정하거나 관리한 적이 없습니다

왜 관리하지 않았나요? → 파트너사 성과 지표 자체가 없었습니다

진짜 문제: '배송 지연'이 아니라 '파트너사 성과를 측정하고 관리하는 시스템이 없다'입니다.

▶ 2 턴 — 문제 분해

"그럼 '파트너사 관리 시스템 부재'를 해결 가능하게 쪼개줘."

→ Claude: 세 하위 문제로 분해됩니다.

A. 측정 문제: 파트너사별 성과 지표(KPI)가 없다

B. 데이터 문제: 지연 원인을 파트너사별로 추적하는 데이터가 없다

C. 계약 문제: 성과 미달 시 페널티 또는 인센티브 구조가 없다

지금 당장 영향력이 가장 큰 것은 A입니다.

KPI가 없으면 B와 C도 만들 수 없습니다.

▶ 3 턴 — 가정 검증

"A를 먼저 해결하려면 뭘 가정하고 있는 건지 찾아줘."

→ Claude: 세 가지 숨은 가정이 있습니다.

가정 1: 파트너사들이 KPI 측정에 동의할 것이다 → 검증 필요

가정 2: 지연 원인 데이터를 파트너사로부터 수집할 수 있다 → 검증 필요

가정 3: KPI 개선이 배송 지연 감소로 직접 이어진다 → 가장 중요한 가정

가정 3을 먼저 검증하십시오. 파트너사 KPI와 지연율 간 상관관계가

실제로 존재하는지 기존 데이터로 확인해 보십시오.

▶ 4 턴 — 문제 재정의

"데이터 확인했어. 상관 관계있어. 이제 문제를 다시 정의해 줘."

→ Claude: 재정의된 문제입니다.

원래: '배송 지연을 어떻게 줄일까'

재정의: '파트너사별 배송 완료율 KPI를 설계하고, 30일 내 측정 체계를

구축해서 하위 20% 파트너사를 식별하고 개선 계획을 수립한다'

이 문제는 명확하고(KPI 설계), 측정 가능하고(완료율 %), 실행 가능합니다(30일).

신다은 씨의 팀은 그다음 주부터 KPI 설계에 착수했습니다. 2주 후 하위 파트너사 3곳을 교체했습니다. 배송 지연은 12%에서 5%로 떨어졌습니다.

4. 상황별 문제 해결 프롬프트 12가지

지금 복사해서 [ ] 안만 바꾸면 바로 사용할 수 있습니다.

▶ 문제 정의

① 5 Whys 근본 원인 분석

당신은 문제 해결 전문가입니다.

아래 상황에서 '왜?'를 5번 물어서 근본 원인을 찾아줘.

현상: [무슨 일이 일어나고 있는가]

각 단계마다 가장 가능성 높은 원인 하나를 짚고,

마지막에 '진짜 문제' 한 문장으로 정의해 줘.

② 문제 MECE 분해

아래 문제를 MECE(상호 배제, 전체 포괄) 원칙으로 분해해 줘.

문제: [큰 주제]

3~4개의 하위 문제로 나누고,

각각이 서로 겹치지 않고 전체를 커버하는지 확인해 줘.

가장 영향력 큰 하위 문제를 골라줘.

③ 가정 목록 작성

아래 문제 해결 방안에 숨어 있는 가정들을 전부 꺼내줘.

방안: [해결책 또는 계획]

각 가정이 틀렸을 때 어떤 결과가 나오는지도 보여줘.

가장 위험한 가정(검증 안 되면 전체가 무너지는 것)을 찾아줘.

④ 문제 재정의 (3 버전)

아래 문제 정의를 더 해결 가능한 형태로 다시 써줘.

원래 문제: [현재 정의]

조건: 명확하고 / 측정 가능하고 / 실행 가능하게

세 가지 버전으로 써줘. 각각 다른 접근 방향을 전제하게.

▶ 원인 분석

⑤ 어골도(Fishbone) 분석

아래 문제의 원인을 어골도(이시카와 다이어그램) 구조로 분석해 줘.

문제: [결과 현상]

원인 카테고리: 사람 / 프로세스 / 시스템 / 외부 환경

각 카테고리에서 가장 가능성 높은 원인 2~3가지씩 나열해 줘.

전체 중 가장 영향력 큰 원인 하나를 골라줘.

⑥ 데이터 없는 상황의 가설 검증

데이터가 부족한 상황에서 원인 가설을 검증하는 방법을 알려줘.

가설: [우리가 생각하는 원인]

가진 것: [현재 알고 있는 사실들]

이 가설이 맞다면 / 틀리다면 어떤 증거가 있어야 하는지,

빠르게 검증할 수 있는 가장 작은 실험을 설계해 줘.

▶ 해결책 설계

⑦ 해결책 옵션 발산

아래 문제에 대한 해결책을 다양하게 발산해 줘.

문제: [재정의된 문제]

제약 조건: [예산 / 시간 / 인력]

단기(1개월) / 중기(3개월) / 장기(1년) 해결책으로 나눠줘.

지금 당장 실행 가능한 것과 준비가 필요한 것을 구분해 줘.

⑧ 해결책 평가 매트릭스

아래 해결책 옵션들을 평가해 줘.

옵션들: [A안, B안, C안 각각 한 줄 설명]

평가 기준: 효과성 / 실행 용이성 / 비용 / 리스크

각 기준에서 1~5점으로 점수 내고,

어떤 옵션을 언제 실행해야 하는지 우선순위를 정해줘.

⑨ 실행 계획 설계

당신은 프로젝트 매니저입니다.

아래 해결책을 실행하는 30일 계획을 만들어줘.

해결책: [선택한 방안]

목표: [30일 후 어떤 상태인가]

주차별 마일스톤 + 담당자 + 성공 지표를 포함해 줘.

첫 번째 주에 반드시 해야 할 세 가지만 뽑아줘.

▶ 사고 심화

⑩ 반대 관점 검토

아래 결론에 대한 반론을 만들어줘.

우리 결론: [문제 정의 또는 해결책]

가장 강력한 반론 3가지를 만들고,

각 반론에 어떻게 대응할 수 있는지도 알려줘.

우리 생각에서 놓치고 있는 맹점이 무엇인지 짚어줘.

⑪ 제2종 오류 점검

우리가 이 문제를 잘못 정의하고 있을 가능성이 있는지 점검해 줘.

현재 문제 정의: [문장]

만약 이 정의가 틀렸다면 어떤 신호가 있어야 하는가?

우리가 지금 '답을 먼저 정하고 문제를 끼워 맞추고 있는' 건 아닌지

비판적으로 검토해 줘.

⑫ 스케일업 전 검증

이 해결책을 전면 도입하기 전에 소규모 검증을 설계해 줘.

해결책: [방안] 전면 도입 계획: [규모와 시간]

가장 적은 비용으로 가장 빠르게 검증할 수 있는

파일럿 실험을 설계해 줘.

어떤 결과가 나와야 전면 도입을 진행할 수 있는지도 정의해 줘.

처음부터 다 쓸 필요 없습니다. 지금 석 달째 해결 안 되는 문제 하나를 골라 ①번 '5 Whys 분석'부터 시작해 보십시오. 문제가 달라 보이기 시작할 것입니다.

5. 신다은 씨가 발견한 것

신다은 씨는 배송 지연 문제를 해결한 뒤 이런 말을 했습니다.

"가장 충격적이었던 건, 우리가 3개월 동안 풀고 있던 문제 자체가 틀렸다는 거예요. '배송을 어떻게 빠르게 하나'가 아니라, '왜 어떤 파트너는 느리고 어떤 파트너는 빠른지 우리가 모른다'가 문제였어요."

그분은 이어서 말했습니다.

"Claude가 해결책을 준 게 아니에요. Claude가 제게 '지금 어떤 문제를 풀고 있냐'라고 물어봤고, 저는 그 질문에 대답하다가 스스로 깨달았어요."

좋은 파트너는 답을 주는 사람이 아닙니다. 올바른 질문을 던지는 사람입니다.

문제 해결에서 Claude의 역할이 정확히 그것입니다. 풀어줌이 아니라 드러냄. 답을 주는 것이 아니라, 당신이 이미 알고 있지만 보지 못했던 것을 보게 만드는 것.

생각하는 사람이 이기는 이유

AI 시대에 자주 하는 이야기가 있습니다. "AI가 반복 업무를 대체한다." 맞는 말입니다.

그런데 그다음 문장은 자주 빠집니다. "반복 업무가 없어진 자리에, 사람은 무엇을 해야 하는가?"

답은 이것입니다. 올바른 문제를 정의하는 것. 어떤 질문을 던져야 하는지 아는 것. 데이터와 현장 사이에서 판단하는 것.

이것은 AI가 대신할 수 없는 능력입니다. 왜냐하면 이 능력은 경험과 맥락과 책임감에서 나오기 때문입니다. Claude는 그 과정을 더 빠르고 명확하게 만들 수 있지만, 문제를 바라보는 눈은 여전히 여러분의 것입니다.

더 빠르게 일하는 것이 PART 2였습니다. 더 깊이 생각하는 것이 PART 3입니다. 그 차이가 AI 시대의 실력 격차입니다.

오늘 딱 한 가지만 해보십시오. 지금 가장 해결이 안 되는 문제를 Claude에게 가져가서 이렇게 말해보십시오.

"이 문제를 풀려고 하는데, 혹시 내가 잘못된 문제를 풀고 있는 건 아닐까? 왜를 다섯 번 물어봐줘."

그 대화 하나가 3개월짜리 막힘을 30분 만에 열어줄 수 있습니다.

◀ 전편 돌아보기

10편 「Claude로 프레젠테이션을 만드는 법」에서는 아리스토텔레스의 명언을 출발점으로, 사업개발 담당 박준혁 씨의 이야기를 통해 슬라이드 50장이 아니라 스토리 하나가 청중을 움직인다는 것을 탐구했습니다. 황금 5단계(청중 분석 → 핵심 메시지 → 스토리 구조 → 슬라이드 설계 → 오프닝·클로징)로 발표 전날 밤 30분 만에 투자자를 설득한 발표 뼈대를 완성했습니다. 이 편으로 PART 2 '업무 자동화 실전'이 완결됐습니다.

▶ 다음 편 예고

다음 12편 「Claude로 아이디어를 발산하는 법」은 PART 3 두 번째 편입니다. 혼자 생각하면 3개가 나올 아이디어가 Claude와 함께 30분 만에 20개가 되는 법을 탐구합니다. 브레인스토밍의 함정을 피하고, 전혀 다른 분야의 관점을 빌려오고, 아이디어의 질을 높이는 창의 시스템을 공개합니다. 좋은 아이디어는 재능에서 나오는 것이 아니라 구조에서 나온다는 것을 보여드립니다.

참고 문헌

6. Charles Kettering, 문제 정의 원칙 (1920s) — "잘 정의된 문제는 이미 절반이 해결된 것이다" 원전

7. Taiichi Ohno, Toyota Production System (1978) — 5 Whys 근본 원인 분석 기법의 원전

8. Barbara Minto, The Pyramid Principle (1987) — MECE 구조적 사고와 로직 트리 분해 방법론

9. McKinsey & Company, Problem Solving Practice (2025) — 구조적 문제 정의가 프로젝트 성공률에 미치는 영향

10. Stanford d.School, Design Thinking Field Guide (2024) — 문제 재정의(Reframing)의 혁신 효과 실증 연구

11. Harvard Business Review, "Are You Solving the Right Problem?" (2024) — 기업의 85%가 문제 정의 단계에서 실패한다는 연구

✦ ✦ ✦

이 시리즈는 Claude와 함께 세계를 읽고, 개인의 생존 전략을 설계하는 25편의 여정입니다. ①구독을 위한 팔로우를 하시고 난 후 댓글, 하단에 ② 응원해 주시고, ③ 개인 메일을 남겨 주시면 클로드 글쓰기의 최고 전문가 마스터 시리즈와 메타프롬프트 자동화 생성기를 별도로 보내 드리겠습니다.