증상을 문제라고 착각하지 마라

AI에게 답을 묻기 전에, 문제를 다시 보라 【2편】

— PART 1. 답을 찾기 전에 문제부터 다시 보라 —

"문제를 해결할 시간이 한 시간뿐이라면, 나는 55분을 문제를 정의하는 데 쓸 것이다."

— 알베르트 아인슈타인 (Albert Einstein)

해열제를 세 번 먹었는데 계속 열이 났습니다

아이가 열이 났습니다.

해열제를 먹였습니다. 열이 내렸습니다. 다행이라고 생각했습니다.

네 시간 뒤 다시 열이 올랐습니다. 또 먹였습니다. 또 내렸습니다. 또 올랐습니다.

세 번째에 병원에 갔습니다. 의사가 말했습니다. "중이염입니다. 항생제가 필요합니다."

열은 문제가 아니었습니다. 신호였습니다.

그런데 우리는 조직에서 매일 해열제를 먹입니다.

이직률이 오르면 복지를 늘립니다. 매출이 줄면 프로모션을 합니다. 회의가 길어지면 회의 규칙을 만듭니다. 불량이 나오면 교육을 늘립니다.

열이 내려갑니다. 잠시. 그리고 다시 올라갑니다.

증상을 없애는 것과 병을 고치는 것은 다릅니다. 그리고 우리는 대부분 증상을 없애는 데 시간을 씁니다.

1. 증상과 원인은 어떻게 다른가

먼저 정의를 분명히 하겠습니다. 이 구분이 이 시리즈 전체의 기초입니다.

세 가지 층위

증상 — 겉으로 드러난 현상

측정 가능하고, 눈에 보이고, 보고서에 올라갑니다. 이직률 18%, 매출 12% 감소, 회의 시간 주당 14시간. 대부분 숫자로 표현됩니다.

직접 원인 — 증상을 만든 바로 앞 단계

2년 차 직원의 이탈이 집중된다, 특정 고객군의 재구매가 끊겼다, 회의 전에 자료가 공유되지 않는다. 아직 더 파고들 여지가 있습니다.

근본 원인 — 구조적으로 그것을 만들어내는 것

성장 경로를 보여주는 제도가 없다, 재구매를 관리하는 담당자가 지정돼 있지 않다, 결정 권한이 회의에만 있다. 여기를 고치면 재발하지 않습니다.

왜 이 구분이 어려운가

증상이 더 급하게 느껴집니다

이직률이 오르면 당장 뭔가 해야 할 것 같습니다. 원인을 파고드는 것은 시간이 걸리고, 그동안 아무것도 안 하는 것처럼 보입니다. 조급함이 증상 처방을 부릅니다.

증상 처방은 성과처럼 보입니다

"복지 제도를 세 가지 도입했습니다"는 보고할 수 있습니다. "원인을 분석하는 중입니다"는 보고하기 어렵습니다. 조직의 평가 구조가 증상 처방을 장려합니다.

원인을 마주하는 것이 불편합니다

근본 원인은 종종 우리 자신을 가리킵니다. 제도 설계의 실패, 리더십의 문제, 오래된 관행. 그것을 인정하는 것보다 외부 요인을 찾는 것이 편합니다.

2. 지금 붙들고 있는 것이 증상인지 확인하는 네 가지 신호

실무에서 바로 쓸 수 있는 판별법입니다.

네 가지 판별 신호

네 가지 중 두 개 이상이 왼쪽에 해당하면, 지금 붙들고 있는 것은 증상입니다.
해결바카라을 찾기 전에 한 단계 더 들어가야 합니다.

가장 강력한 판별 질문

"이것을 없애면 재발하지 않는가?"

이 질문 하나로 대부분 구분됩니다. 복지를 늘려도 1년 후 다시 이직률이 오를 것 같다면, 복지는 원인이 아닙니다. 통로를 넓히면 그 사고가 다시 안 날 것 같다면, 통로가 원인입니다.

"이것을 고치면 같은 문제가 다시 일어나지 않는가?"

3. 네 가지 현장 진단

실제 조직에서 자주 나타나는 네 가지 사례입니다. 여러 사례를 섞은 것이지만 구조는 현장 그대로입니다.

사례 1 — 회의가 너무 많다

증상 주당 회의 시간 14시간, 팀원 불만 누적

✗ 흔한 처방 회의 규칙 제정, 회의 시간 30분 제한, 회의 줄이기 캠페인

실제 원인 팀장에게 단독 결정 권한이 없어 모든 사안이 회의로 올라옴

✔ 진짜 처방 결정 권한 범위를 문서로 명시하고 금액·범위별 위임 기준 설정

회의 규칙을 만들면 회의 수는 줄어듭니다. 그런데 결정이 더 늦어집니다. 문제가 다른 곳으로 이동한 것입니다.

사례 2 — 신입 직원이 자주 그만둔다

증상 입사 1년 이내 퇴사율 31퍼센트

✗ 흔한 처방 채용 면접 강화, 입사 선물 개선, 웰컴 키트 제작

실제 원인 온보딩 후 3개월간 담당 업무와 평가 기준이 정해지지 않음

✔ 진짜 처방 90일 온보딩 로드맵과 30·60·90일 체크포인트 제도화

면접을 강화하면 채용 기준에 맞는 사람이 옵니다. 그런데 들어와서 겪는 경험이 그대로라면 결과도 그대로입니다.

사례 3 — 재고 데이터가 실제와 안 맞는다

증상 월말 실사 시 시스템 대비 오차 평균 4.2퍼센트

✗ 흔한 처방 실사 주기 단축, 담당자 교육, 오차 발생 시 경고 조치

실제 원인 출고 취소가 시스템에 반영되는 절차 자체가 존재하지 않음

✔ 진짜 처방 출고 취소 처리 절차를 신설하고 시스템에 필수 입력 항목 추가

교육을 늘리면 사람이 더 조심합니다. 그런데 반영할 방법이 없는 일을 조심할 수는 없습니다.

사례 4 — 고객 클레임이 늘었다

증상 월 클레임 건수 전년 대비 62퍼센트 증가

✗ 흔한 처방 CS 인력 충원, 응대 매뉴얼 개편, 사과 쿠폰 지급 확대

실제 원인 신규 배송 파트너 도입 후 특정 지역에서만 파손율 급증

✔ 진짜 처방 지역별 파손율 데이터로 파트너 성과 관리 기준 신설

CS 인력을 늘리면 클레임 응대는 빨라집니다. 그런데 클레임 자체는 줄지 않습니다. 손실은 계속됩니다.

네 사례에 공통점이 있습니다. 흔한 처방은 모두 '사람을 더 조심하게 만드는 것'이었고, 진짜 처방은 모두 '구조를 바꾸는 것'이었습니다.

4. 영역별로 자주 나타나는 증상과 원인

여러분의 영역에서 어떤 패턴이 반복되는지 확인해 보십시오.

다섯 영역의 대응 관계

세 번째 열은 통계적 정답이 아닙니다. 자주 나타나는 방향일 뿐입니다.
여러분의 조직에서는 다를 수 있고, 그래서 검증이 필요합니다.

주목할 공통 패턴

진짜 원인은 대개 두 가지 형태입니다

• 특정 지점에 몰려 있다 — 전체 문제로 보였지만 실은 일부에서만 발생

• 구조가 없어서 생긴다 — 담당자, 절차, 기준 중 하나가 비어 있음

이 두 가지를 먼저 확인하면 원인 탐색 시간이 크게 줄어듭니다. 쪼개서 분포를 보고, 없는 것이 무엇인지 찾는 것입니다.

5. 오늘 쓸 수 있는 증상 분리 프롬프트

1편에서 드린 프롬프트를 한 단계 확장한 것입니다. 이번에는 증상과 원인을 명시적으로 분리합니다.

증상 분리 프롬프트

당신은 문제해결 전문가입니다. 저를 대신해 문제를 풀지 마시고,

제가 올바른 문제를 보도록 거울을 들어주십시오.

제가 문제라고 생각하는 것: [현재 정의]

관련 수치: [알고 있는 숫자]

지금까지 시도한 것: [해봤지만 실패한 접근]

그래도 해결되지 않은 이유: [제 추측]

요청 사항:

① 제가 말한 것이 증상인지 원인인지 판별해 주십시오

② 증상이라면 직접 원인과 근본 원인을 각각 제시해 주십시오

③ 각 원인이 '가정'인지 '확인된 사실'인지 표시해 주십시오

④ 이 원인을 검증하려면 무엇을 확인해야 하는지 알려 주십시오

마지막에 이 질문에 답해 주십시오.

"이것을 고치면 같은 문제가 다시 일어나지 않겠는가?"

한 단계 더 — 분포 확인 프롬프트

전체 문제로 보이는 것을 쪼개는 도구

이 문제가 전체에 퍼진 것인지 일부에 몰린 것인지 확인하고 싶습니다.

문제 현상: [무엇]

제가 가진 데이터: [있는 것]

① 이 문제를 쪼개볼 수 있는 기준을 다섯 가지 제안해 주십시오

(예: 시점·조직·고객군·제품·담당자·지역)

② 어느 기준으로 쪼갤 때 편차가 가장 클 가능성이 높습니까

③ 데이터가 없다면 어떻게 빠르게 확인할 수 있습니까

제 추측에 동의하지 마시고, 제가 놓친 기준을 지적해 주십시오.

두 번째 프롬프트가 특히 유용합니다. "전체 이직률 18%"가 "2년 차 31%"로 쪼개지는 순간 문제가 완전히 달라집니다.

6. 증상 처방이 필요한 순간도 있습니다

여기서 한 가지 균형을 잡겠습니다. 증상 처방이 언제나 나쁜 것은 아닙니다.

증상을 먼저 잡아야 하는 세 가지 상황

사람이 위험할 때

안전사고가 진행 중이라면 원인 분석보다 즉시 조치가 먼저입니다. 열이 40도면 원인을 찾기 전에 해열제를 씁니다. 다만 그것으로 끝내지 않는 것이 중요합니다.

시간을 벌어야 할 때

고객 이탈이 급격히 진행 중이라면 임시 조치로 시간을 벌면서 원인을 찾을 수 있습니다. 이때 중요한 것은 임시 조치라는 것을 조직이 명확히 아는 것입니다.

원인 규명에 시간이 오래 걸릴 때

구조적 원인을 바꾸는 데 6개월이 걸린다면, 그동안 증상을 관리해야 합니다. 다만 증상 관리가 원인 해결을 대체하지 않도록 병행 계획이 필요합니다.

가장 위험한 것

증상 처방을 해결로 착각하는 것

복지를 늘려서 이직률이 잠시 내려가면 "해결됐다"라고 보고합니다. 그리고 프로젝트가 종료됩니다. 1년 후 같은 문제가 다시 올라오면 다른 사람이 다시 처음부터 시작합니다.

증상 처방을 할 때는 반드시 함께 기록하십시오. "이것은 임시 조치이며, 근본 원인은 아직 미규명이다."

7. 태도 문제라고 불렸던 사람

몇 년 전, 어느 물류센터에서 있었던 일입니다.

한 40대 후반 직원이 있었습니다. 근속 12년. 그런데 최근 1년 사이 평가가 급격히 나빠졌습니다.

보고된 내용은 이랬습니다. "업무 속도 저하, 지시 불이행 빈번, 태도 문제 있음."

현장 관리자는 경고장을 두 번 발부했습니다. 그래도 개선되지 않았습니다. 세 번째면 인사 조치가 논의될 상황이었습니다.

그때 인사 담당자가 다르게 물었습니다. 경고장을 준비하는 대신, 데이터를 쪼개 봤습니다.

그 직원의 업무 오류가 언제 발생했는지 시간대별로 나눠 봤습니다.

이상한 패턴이 나왔습니다. 오전에는 오류가 거의 없었습니다. 오후 3시 이후에 집중돼 있었습니다.

담당자가 직접 만나 물었습니다. "오후에 뭔가 힘든 게 있으신가요?"

그분이 오래 망설이다가 말했습니다.

"작년부터 눈이 안 좋아졌습니다. 오후 되면 라벨 글씨가 잘 안 보여요. 병원에 갔더니 백내장이라고 하는데... 수술비가 부담돼서 미루고 있었습니다."

"말씀을 안 하신 이유가 있으셨나요?"

"이 나이에 눈이 안 보인다고 하면, 그만 나오라고 할까 봐서요."

태도 문제가 아니었습니다. 시력이었습니다.

회사는 사내 의료비 지원 제도로 수술비를 지원했습니다. 그리고 라벨 글씨 크기를 키우는 작업을 했습니다. 다른 고령 직원들에게도 도움이 되는 변경이었습니다.

두 달 뒤, 그분의 업무 오류는 이전 수준으로 돌아왔습니다.

만약 세 번째 경고장이 나갔다면 어떻게 됐을까요.

12년 일한 사람이 태도 나쁜 사람으로 기록되고 조직을 떠났을 것입니다. 그리고 조직은 이유를 영원히 몰랐을 것입니다.

"태도 문제"는 증상이었습니다. 원인은 보이지 않는 곳에 있었습니다.

증상과 원인을 구분한다는 것은 분석 기법이 아닙니다. 한 사람을 잃지 않는 일입니다.

우리가 '태도 문제'라고 부르는 것 뒤에는, 말하지 못한 사정이 있을 수 있습니다. 한 번 더 묻는 것이 사람을 지킵니다.

이 분석에서 가장 불확실한 가정

"근본 원인은 대개 구조에 있다"는 전제입니다. 실제로는 개인 역량이나 의도가 진짜 원인인 경우도 존재합니다. 구조만 보다가 바카라임 소재를 흐리게 만들 위험이 있습니다. 이 균형은 6장에서 일부 다뤘고, 4편 5 Whys 편에서 더 정교하게 다룰 예정입니다.

한 번 더 묻는 데 3분이면 됩니다

증상을 처방하는 것은 빠릅니다. 원인을 찾는 것은 느립니다.

그런데 증상 처방은 매년 반복해야 하고, 원인 해결은 한 번이면 됩니다. 결국 어느 쪽이 빠른지는 시간을 길게 놓고 보면 분명합니다.

아인슈타인은 문제 해결 시간 한 시간 중 55분을 문제 정의에 쓰겠다고 했습니다. 우리가 그렇게까지 할 필요는 없습니다.

다만 3분만 더 써 보십시오. 지금 붙들고 있는 문제에 이 질문 하나를 던지는 데 3분입니다.

"이것을 고치면 같은 문제가 다시 일어나지 않겠는가?"

답이 "아니요"라면, 아직 원인에 도달하지 않은 것입니다.

그리고 그 3분이 누군가의 12년을 지킬 수도 있습니다.

"이 나이에 눈이 안 보인다고 하면 그만 나오라고 할까 봐서요." 우리가 묻지 않으면 아무도 말하지 않습니다.

◀ 전편 돌아보기

1편 「답은 넘쳐나는데 왜 문제는 그대로일까」에서는 AI 시대에 정보 탐색과 초안 작성의 값이 떨어지고 질문 설계와 문제 정의의 값이 올랐다는 것을 다뤘습니다. 이직률 문제를 반년 동안 잘못 풀었던 사례와 밀크셰이크 사례를 통해 같은 데이터에 다른 질문을 던지면 해법이 완전히 달라진다는 것을 확인했고, 제조 현장에서 '작업자가 규정을 안 지킨다'가 '규정을 지킬 수 없는 동선'으로 재정의되며 사고가 멈춘 이야기로 마무리했습니다.

▶ 다음 편 예고

다음 3편 「같은 상황을 세 가지 문제로 다시 정의하라」입니다. 하나의 상황을 고객 관점·조직 관점·시스템 관점에서 각각 다르게 정의하면 세 개의 전혀 다른 해결바카라이 나옵니다. 문제 리프레이밍의 구체적 방법과, 어느 정의를 선택해야 하는지 판단하는 기준을 다룹니다.

참고 문헌

1. Albert Einstein — '한 시간 중 55분을 문제 정의에 쓴다' 인용 원전

2. Taiichi Ohno, Toyota Production System (1978) — 증상과 근본 원인 분리 및 5 Whys 원전

3. Peter Senge, The Fifth Discipline (1990) — 증상 해결이 문제를 이동시키는 시스템 사고 원리

4. Donella Meadows, Thinking in Systems (2008) — 시스템 개입 지점과 증상 대응의 한계

5. Harvard Business Review, "Stop Blaming Your Employees" (2024) — 개인 바카라임으로 귀속되는 조직 문제의 구조적 원인 분석

6. Amy Edmondson, The Fearless Organization (2018) — 심리적 안전감이 없을 때 문제가 은폐되는 메커니즘

✦ ✦ ✦

이 시리즈는 Claude와 함께 세계를 읽고, 개인의 생존 전략을 설계하는 25편의 여정입니다.

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