문제 정의의 기술 ③ | 문제의 원인 찾기- 증상과 원인을 구분하는 기술

📘 문제 정의의 기술 ③ | 문제의 원인 찾기

- 증상과 원인을 구분하는 기술 -

우리가 문제를 해결하지 못하는 이유는
능력이 부족해서가 아니라,
초점이 잘못된 지점에 머물러 있기 때문입니다.

대부분의 사람은 ‘증상’을 해결하는 데 시간을 쓰고,
진짜 성과를 내는 사람은 ‘원인’을 먼저 찾아냅니다.

이 차이가 사고의 깊이를 만들고,
일의 속도를 바꾸며,
결과물의 질을 결정합니다.

1. 문제는 항상 ‘겉모습’과 ‘속 구조’로 나뉜다

모든 문제는 두 개의 층위를 갖고 있습니다.

겉모습 = 증상(Symptom)
속 구조 = 원인(Root Cause)

예를 들어:

일정이 밀린다 → 증상
작업 단위 불명확 / 우선순위 변경 / 의존 관계 미정 → 원인
고객 불만 증가 → 증상
기능 설명 부족 / 온보딩 미흡 / 서비스 흐름 난해 → 원인

증상은 “보이는 문제”이고,
원인은 “문제를 만들어내는 작동 방식의 어긋남”입니다.

문제 해결은
겉모습을 고치는 것이 아니라
속 구조를 바로잡는 일입니다.

2. 증상을 원인으로 착각할 때 생기는 대표적 오류

문제가 잘 안 풀리는 사람들에게는 다음과 같은 패턴이 있습니다.

(1) 증상이 곧 원인이라고 믿는다

예: “조회수가 안 나와 → 그래서 제목만 바꾸면 되겠지”
→ 하지만 실제 원인은 타깃 부정확, 콘텐츠 구조 문제, 제작 리듬 불안정일 수 있음.

(2) 문제를 ‘결과’ 수준에서만 본다

겉으로 드러난 현상만 보고
그 아래의 과정·흐름·시스템을 보지 못한다.

(3) 데이터 없이 감정으로 판단한다

“느낌상”, “대충 그런 것 같아”는
문제 해결에서 가장 위험한 방식이다.

(4) 너무 빨리 결론을 내린다

빠른 결론이 날카로운 사고가 아니라,
검증 없이 뛰어가는 조급함일 때가 많다.

잘못된 정의에서 출발하면,
해결은 방향을 잃고 악순환이 반복된다.

3. 원인을 찾는 가장 강력한 도구: ‘Why를 5번 묻기’

Why 5 Times(5 Why 분석법)는
도요타(TOYOTA)의 TPS(Toyota Production System)에서 시작된
전통적인 문제 분석 방법입니다.

이 방식은 단순하지만,
맥킨지(McKinsey), BCG, 베인, 구글, 애플과 같은
글로벌 기업에서도 사용되는 가장 기본적이고 강력한 문제 접근법입니다.

(1) 방법은 아주 간단합니다

① 문제를 적는다

② 왜? 를 묻는다

③ 나온 답에 다시 왜? 를 묻는다

④ 근본 원인에 도달할 때까지 반복한다

참고: 기업별 대표적 문제 분석 도구
ㅇ 도요타(TOYOTA) → 5 Why Analysis, Root Cause
ㅇ 맥킨지(McKinsey) → MECE, Logic Tree, Issue Tree
ㅇ 구글·애플 → 회고(Review), 사후 분석(Postmortem), 원인 분석 문화

즉, “문제를 깊게 파고드는 사고” 자체가
세계적인 조직들이 공통적으로 강조하는 역량입니다.

(2) 예시: “프로젝트가 자꾸 늦어진다”

왜 늦어지는가?
→ 작업 분량이 실제보다 많다
왜 실제보다 많은가?
→ 처음에 작업 단위가 정확히 정의되지 않았다
왜 작업 단위가 정확히 정의되지 않았는가?
→ 팀원마다 작업 방식과 기준이 달랐다
왜 기준이 다른가?
→ 작업 기준 문서가 없다
왜 기준 문서가 없는가?
→ 시작 전에 스코프 확인 시간이 없었다

➡ 근본 원인(Root Cause): 스코프·기준 부재
➡ 해결 방향: 일정 관리가 아니라 ‘기준 만들기’가 우선

근본 원인( Root Cause )을 발견하는 순간
문제는 이미 절반 해결된 것이나 다름없습니다.

4. 원인을 찾아내는 사람들의 3가지 관찰 습관

(1) 감정이 아니라 사실로 사고한다

“느낌상”이 아니라
데이터, 기록, 실제 행동, 흐름, 패턴을 기반으로 본다.

(2) 과정을 거꾸로 추적한다 (Backtracking)

결과 → 직전 단계 → 이전 단계 → 시작점
흐름을 역방향으로 보면 문제 지점이 선명해진다.

(3) 시스템 관점으로 바라본다

“누가 잘못했나?”보다
“어떤 구조가 이 문제를 반복시키는가?”에 초점을 둔다.

사람보다 구조를 보아야 문제의 재발을 막을 수 있다.

5. 원인을 명확히 확인하는 4가지 체크 질문

문제가 발생했을 때
아래 네 가지 질문만 사용해도 원인 파악의 정확도가 크게 올라간다.

(1) 문제는 언제 발생하는가?

시간·상황·조건 파악

(2) 문제는 어디에서 발생하는가?

프로세스 단계, 콘텐츠 구조, 업무 흐름 중 어느 지점인가?)

(3) 반복되는가?

반복된다면 문제는 사람의 실수가 아니라 구조의 문제다.

(4) 문제에 가장 크게 연결된 요소는 무엇인가?

영향도가 높은 원인부터 제거해야 한다.

이 네 질문은
문제가 표면인지, 구조인지 자연스럽게 구분해준다.

6. 실전 예시 — 직장인 · 크리에이터 · 1인 기업 모두에게

A. 직장인

문제: “상사가 원하는 보고서와 다르다”
원인: 상사가 중요하게 보는 **결정 기준(핵심 질문)**을 먼저 파악하지 않음
해결: 보고 전 핵심 질문 3개 먼저 확인하기

B. 크리에이터

문제: “조회수가 계속 흔들린다”
원인: 트렌드만 따라가고, 타깃·포맷·콘셉트가 고정되지 않음
해결: ‘기준 콘텐츠(Reference Format)’ 구축 후 반복

C. 1인 기업·프리랜서

문제: “고객 문의가 계속 늘어난다”
원인: 제품/서비스 설명 구조가 불명확
해결: FAQ·온보딩 콘텐츠·사용 흐름 정비

문제는 다 달라 보이지만,
원인을 보면 대부분 ‘구조적 결함’이 공통으로 존재합니다.

📘 마무리

문제를 해결할 때 가장 위험한 말은
“이게 원인이겠지?”입니다.

좋은 해결은
좋은 원인 파악에서 나오고,
좋은 원인 파악은
좋은 질문과 검증,
그리고 사고의 ‘천천함’에서 나옵니다.

증상을 고치는 사람은 바쁜 사람이고,
원인을 고치는 사람은 성장하는 사람입니다.

문제를 해결하는 힘의 절반은
문제를 정확히 보는 시선에서 시작됩니다