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

— PART 2. 복잡한 문제를 보이는 구조로 바꿔라 · 마지막 편 —

"올바른 질문에 대한 근사한 답이, 잘못된 질문에 대한 정확한 답보다 훨씬 낫다."

— 존 튜키 (John Tukey), 통계학자

2년을 쏟았는데 방향이 틀렸습니다

이 시리즈에서 지금까지 일곱 편을 썼습니다.

증상과 원인을 구분했고, 세 가지로 재정의했고, 왜를 다섯 번 물었고, 문제를 쪼갰고, 네 축으로 펼쳤고, 숨은 가정을 찾았습니다.

그런데 이 모든 것을 잘 해내고도 완전히 틀릴 수 있습니다.

출발점이 틀렸다면 말입니다.

어느 회사가 2년 동안 고객 만족도 향상 프로젝트를 진행했습니다. 분석은 정교했습니다. 원인도 잘 찾았습니다. 실행도 착실했습니다. 만족도 점수는 실제로 올랐습니다.

그런데 매출은 계속 떨어졌습니다.

2년 뒤 외부 컨설턴트가 들어와서 물었습니다. "만족도가 매출로 이어진다는 건 어디서 확인하셨나요?"

아무도 답하지 못했습니다.

나중에 데이터를 보니 만족도가 높은 고객과 재구매하는 고객이 거의 겹치지 않았습니다. 이 회사의 재구매는 만족도가 아니라 납기 정확도와 연결돼 있었습니다.

정확한 답이었습니다. 다만 다른 문제에 대한 답이었습니다.

문제를 잘못 정의하면, 잘할수록 더 멀리 갑니다. 열심히 하는 것이 오히려 손해가 되는 유일한 경우입니다.

1. 틀린 답과 틀린 문제는 다릅니다

통계학에는 두 종류의 오류가 있습니다. 이 개념을 문제 정의에 가져와 보겠습니다.

두 오류의 차이

왜 2종 오류가 더 위험한가?

드러나는 데 오래 걸립니다

해결바카라이 틀리면 몇 주 안에 압니다. 성과가 안 나오니까요. 그런데 문제가 틀리면 성과가 나옵니다. 다만 엉뚱한 성과입니다. 만족도는 올랐는데 매출은 떨어지는 식입니다.

열심히 할수록 깊어집니다

잘못된 방향으로 성실하게 가면 되돌아오기가 더 어려워집니다. 투입한 자원이 많을수록 방향을 바꾸자는 말을 꺼내기 어렵습니다.

아무도 의심하지 않습니다

문제 정의는 프로젝트 초반에 정해집니다. 그리고 그 뒤로는 모든 논의가 그 정의 위에서 일어납니다. 정의 자체를 다시 보는 자리는 거의 없습니다.

그래서 필요한 것이 정기적으로 출발점을 되돌아보는 절차입니다.

2. 문제 정의가 틀렸을 때 나타나는 신호

틀린 문제는 조용히 신호를 보냅니다. 알아채는 사람이 드물 뿐입니다.

네 가지 신호입니다.

신호 1 열심히 했는데 핵심 지표가 안 움직인다

의미 하위 지표는 개선되는데 최종 목표 지표가 그대로라면, 둘 사이 연결 고리가 우리 가정과 다를 수 있습니다

할 일 하위 지표와 최종 지표의 상관관계를 데이터로 확인

신호 2 안 되는 이유가 계속 늘어난다

의미 예외 조건이 자꾸 추가된다면, 이론이 현실을 설명하지 못하고 있다는 뜻입니다

할 일 지금까지 붙인 예외를 전부 나열하고 공통점 찾기

신호 3 현장 사람들이 시큰둥하다

의미 실제로 그 일을 하는 사람들이 공감하지 않는다면, 그들이 보는 문제와 우리가 정의한 문제가 다를 가능성이 높습니다

할 일 현장 담당자에게 "진짜 문제가 뭐라고 보세요" 직접 묻기

신호 4 같은 문제가 다른 이름으로 계속 온다

의미 해결했다고 했는데 비슷한 일이 다른 부서에서 다른 형태로 나타난다면, 근본 원인을 못 잡은 것입니다

할 일 최근 1년간 유사 사안을 모아 공통 구조 확인

네 신호 중 두 개 이상이 보이면, 실행을 멈추고 문제 정의로 돌아가야 합니다.

실행을 멈추는 것이 손해처럼 느껴집니다. 그런데 잘못된 방향으로 계속 가는 것이 훨씬 큰 손해입니다.

3. 출발점을 다시 보는 절차

문제 정의를 재점검하는 것은 프로젝트를 부정하는 일이 아닙니다. 정기 점검입니다.

다섯 가지 점검 항목

가장 중요한 첫 번째 — 결론 선행

답을 먼저 정하고 문제를 맞히는 일은 흔합니다

새 시스템을 도입하고 싶은 사람은 문제를 "시스템 부재"로 정의합니다. 인력을 늘리고 싶은 사람은 "인력 부족"으로 정의합니다. 악의가 아닙니다. 자기가 가진 도구로 풀 수 있는 문제를 보기 때문입니다.

망치를 든 사람에게는 모든 것이 못으로 보입니다.

확인 방법

프로젝트를 시작할 때 해결바카라을 먼저 떠올렸는지, 문제를 먼저 정의했는지 기억해 보십시오. 순서가 뒤바뀌었다면 재점검이 필요합니다.

두 번째로 중요한 것 — 반증 부재

근거가 전부 같은 방향이라면 의심하십시오

자료를 열 개 모았는데 열 개 다 우리 결론을 지지한다면, 그것은 확신의 근거가 아니라 편향의 증거일 수 있습니다. 현실은 대개 그렇게 깨끗하지 않습니다.

의도적으로 반대 증거를 찾아보십시오. 못 찾으면 그때 확신해도 늦지 않습니다.

4. 이 시리즈의 전제도 의심해 보겠습니다

여기서 한 가지를 솔직하게 말씀드려야겠습니다.

지금까지 일곱 편에서 반복된 메시지가 있습니다. "원인은 대개 구조에 있다." "사람 탓하지 말고 시스템을 보라."

이 메시지가 틀렸다면 무엇이 보여야 할까요.

구조 환원의 위험

모든 것이 구조 탓이면 아무도 바카라임지지 않습니다

반복해서 지적받고도 개선하지 않는 사람, 고의로 절차를 무시하는 사람이 있습니다. 이런 경우까지 구조 문제로 돌리면 성실한 사람이 손해를 봅니다.

구조 개선은 시간이 오래 걸립니다

당장 오늘 위험한 상황이라면 구조를 논하기 전에 사람을 조치해야 할 때도 있습니다. 근본 원인 분석이 항상 최우선은 아닙니다.

그렇다면 어떻게 구분하는가

같은 자리에 다른 사람이 있었다면

이 질문이 기준입니다. 다른 사람이었어도 같은 일이 생겼을 가능성이 높다면 구조 문제입니다. 이 사람만 유독 그렇다면 개인 문제일 수 있습니다.

조건을 바꿔줬는데도 반복된다면

6편의 병원 사례처럼 조건을 바꿔서 해결되면 구조 문제였던 것입니다. 조건을 바꿔줬는데도 같은 일이 반복된다면 그때는 다른 판단이 필요합니다.

구조를 먼저 보는 것은 순서의 문제이지 결론의 문제가 아닙니다.

5. 오늘 쓸 수 있는 문제 정의 점검 프롬프트

이번 편의 실전 결과물은 문제 정의 재검토 보고서입니다.

제2종 오류 점검 프롬프트

당신은 비판적 검토 전문가입니다.

제 문제 정의가 틀렸을 가능성을 냉정하게 점검해 주십시오.

현재 문제 정의: [한 문장으로]

이 정의를 내린 시점: [언제]

그동안 한 일: [실행 내역]

현재까지의 성과: [지표 변화]

요청 사항:

① 제가 해결바카라을 먼저 정하고 문제를 맞힌 흔적이 있는지

② 이 정의가 제 부서에서 손댈 수 있는 쪽으로 치우쳐 있는지

③ 이 정의가 틀렸다면 지금 무엇이 보여야 하는지

④ 그 신호가 실제로 나타나고 있는지 제 설명에서 확인

⑤ 지금 정의를 유지해도 되는지, 재정의가 필요한지 판단

제 노력을 위로하지 마시고, 방향이 틀렸다면 그렇게 말해 주십시오.

반증 탐색 프롬프트

우리 결론에 반대되는 증거 찾기

제 결론에 반대되는 가장 강력한 논거를 만들어 주십시오.

제 결론: [현재 판단]

제 근거: [나열]

① 이 결론에 가장 강하게 반대할 사람은 누구이고 뭐라고 할까요

② 제 근거들의 공통된 약점은 무엇입니까

③ 제가 의도적으로 외면했을 가능성이 있는 데이터는

④ 제 결론과 반대되는 사례가 존재한다면 어떤 형태일까요

동의하지 마십시오. 제가 틀렸다고 가정하고 논리를 세워 주십시오.

6. 3년 만에 방향을 바꾼 사람

몇 해 전, 한 슬롯복지관에서 있었던 일입니다.

지역 청소년들의 학업 중단 문제를 다루는 프로그램이 있었습니다. 3년째 운영 중이었습니다.

문제 정의는 이랬습니다. "학업 성취도가 낮아서 학교를 포기한다."

그래서 학습 지원에 집중했습니다. 방과 후 교실을 열고, 대학생 멘토를 붙이고, 교재를 지원했습니다.

성적은 실제로 올랐습니다. 프로그램에 참여한 아이들의 평균 성적이 유의미하게 개선됐습니다.

그런데 학업 중단율은 그대로였습니다.

3년 차 담당 슬롯복지사가 어느 날 회의에서 말했다고 합니다.

"저희가 틀린 문제를 풀고 있는 것 같습니다."

3년 동안 쌓아온 프로그램을 부정하는 말이었습니다. 회의실이 조용해졌습니다.

그 사람은 중단한 아이들 열두 명을 직접 찾아다녔습니다. 성적 이야기는 하지 않았습니다. 그냥 물었습니다. "그때 왜 안 나왔어?"

답들이 비슷했습니다.

"아침에 깨워주는 사람이 없어요."

"동생 챙기고 나면 지각이라 그냥 안 갔어요."

"교복이 작아졌는데 말을 못 했어요."

성적 문제가 아니었습니다. 아침에 학교에 도착할 수 있느냐의 문제였습니다.

문제가 다시 정의됐습니다. "학업 성취도가 낮다"에서 "등교를 지속할 조건이 없다"로.

프로그램이 완전히 바뀌었습니다. 아침 등교 동행, 형제 돌봄 연계, 생필품 지원.

2년 뒤 학업 중단율이 절반 이하로 떨어졌습니다.

그 슬롯복지사가 나중에 이렇게 말했다고 합니다.

"3년을 헛되게 썼다고 생각하니 견디기 힘들었습니다. 그런데 그 3년이 없었으면 틀렸다는 것도 몰랐을 겁니다."

틀린 문제를 인정하는 것은 실패를 인정하는 일처럼 느껴집니다.

그런데 3년 만에 인정한 사람이 있어서, 그 뒤의 아이들은 학교에 남을 수 있었습니다.

방향을 바꾸는 것은 지금까지를 부정하는 일이 아닙니다. 지금까지 배운 것으로 더 나은 곳으로 가는 일입니다.

"저희가 틀린 문제를 풀고 있는 것 같습니다." 이 말을 꺼내는 데는 용기가 필요합니다. 그리고 그 용기가 방향을 바꿉니다.

PART 2를 마치며

여기까지가 문제를 구조로 바꾸는 이야기였습니다.

쪼개고, 네 축으로 펼치고, 가정을 드러내고, 마지막으로 출발점을 의심했습니다.

이 모든 절차의 목적은 하나입니다. 실행하기 전에 방향을 확인하는 것입니다.

지금 진행 중인 일이 하나 있으실 것입니다. |몇 달째하고 있는데 잘 되고 있는지 확신이 없는 그런 일.

오늘 그 일에 네 가지 신호를 대입해 보십시오.

• 핵심 지표가 움직이고 있는가

• 안 되는 이유가 계속 늘어나는가

• 현장 사람들이 공감하는가

• 같은 문제가 다른 이름으로 오는가

두 개 이상 걸린다면, 잠시 멈추고 출발점으로 돌아가십시오.

멈추는 것은 후퇴가 아닙니다. 방향을 확인하는 시간입니다.

잘못된 질문에 대한 정확한 답보다, 올바른 질문에 대한 근사한 답이 훨씬 낫습니다.

◀ 전편 돌아보기

7편 「우리가 사실이라고 믿는 것 중 얼마나 사실일까」에서는 한 문장 안에 확인되지 않은 가정이 네 개나 들어 있는 사례로 시작했습니다. 사실·해석·가정·신념 네 층위를 구분하고, 자주 나오는 문장 네 개를 해부해 확인 방법이 모두 3일 이내라는 것을 확인했습니다. 근속 9년 직원의 '원래 그런 사람'이라는 평판이 실은 아무도 확인하지 않은 가정이었던 이야기로 마무리했습니다.

▶ 다음 편 예고

다음 9편부터 PART 3이 시작됩니다. 드디어 AI가 등장합니다. 「어떤 AI가 최고인가 보다 중요한 질문」에서는 ChatGPT·Claude·Gemini·Perplexity를 경쟁시키는 대신, 문제해결의 어느 단계에서 누구에게 무엇을 맡길 것인지 배치하는 방법을 다룹니다. 지금까지 만든 사고 구조 위에 AI를 얹는 첫 편입니다.

참고 문헌

1. John Tukey, The Future of Data Analysis (1962) — '올바른 질문에 대한 근사한 답' 원전

2. Ian Mitroff, The Subjective Side of Science (1974) — 제3종 오류(잘못된 문제를 정확히 푸는 오류) 개념

3. Karl Popper, Conjectures and Refutations (1963) — 반증을 통한 검증의 원칙

4. Barry Staw, Knee-Deep in the Big Muddy (1976) — 매몰 비용과 실패한 방향에 대한 몰입 상승 연구

5. Chip Heath & Dan Heath, Decisive (2013) — 확증 편향을 줄이는 의사결정 절차

6. Harvard Business Review, "Why Good Projects Fail Anyway" (2023) — 방향 전환 시점을 놓치는 조직의 구조적 원인
✦ ✦ ✦

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

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