티스토리 뷰

문제를 해결했는데 왜 똑같은 문제가 다시 생기는 걸까요? 이런 일들이 반복되면 답답할 따름입니다. 일정이 늦어지면 담당자를 재촉하고, 자료가 틀리면 수정을 요청했습니다. 그렇게 수십 번 해결을 반복하면서 초반에는 "당장의 문제해결"에 초점을 뒀고 그게 어느정도 되면 스스로 기뻐하기도했습니다. 그러나 이 일이 몇차례 반복되니 스스로 반문하게 됩니다. "나는 정말 "문제해결"을 하고있는가?" 그러다 어느 날 5-whys기법을 보고 깨달았습니다. 저는 문제를 해결한 게 아니라 증상만 눌러왔던 겁니다. 5Why는 그 증상 아래에 있는 진짜 구조적 원인을 찾아가는 분석 기법입니다.

 

반복문제 — 해결했는데 왜 또 생기는가

일반적으로 문제가 생기면 가장 빠른 해결책을 찾는 것이 일 잘하는 사람의 특징이라고 알려져 있습니다. 그런데 제 경험상 이건 좀 다릅니다. 빠른 해결이 오히려 같은 문제를 반복하게 만드는 주범이었습니다.

제가 근무하던 팀에서는 보고서가 자주 늦게 제출되는 문제가 있었습니다. 처음에는 담당자의 작업 속도 문제라고 판단했고, 저는 매번 독촉 메시지를 보내는 방식으로 해결했습니다. 그 주는 해결됩니다. 그런데 다음 달에 또 같은 일이 벌어집니다. 그다음 달에도 마찬가지입니다.

이것이 바로 표면적 해결(symptomatic fix)의 한계입니다. 여기서 표면적 해결이란 문제의 원인을 건드리지 않고 눈에 보이는 결과만 임시로 수정하는 방식을 말합니다. 증상이 반복될 때마다 그때그때 진화만 하는 구조입니다. 결국 팀 전체가 소방관처럼 불만 끄다가 지쳐갑니다.

이 패턴을 벗어나려면 "왜 늦었는가"라는 질문을 최소 서너 번은 더 깊이 파야 합니다. 제 경우를 돌이켜보면, 보고서가 늦은 진짜 이유는 담당자의 게으름이 아니었습니다. 여러 부서에서 자료를 따로 받아야 하는데 형식이 제각각이고, 그것을 취합하고 정리하는 기준 자체가 없었던 겁니다. 사람을 다그쳐서는 절대 해결이 안 되는 구조적 문제였습니다.

이처럼 반복되는 문제는 개인의 태도보다 시스템의 공백에 원인이 있는 경우가 훨씬 많습니다. 

  • 증상만 해결하면 같은 문제가 이름만 바꿔 돌아온다
  • 반복되는 문제의 원인은 사람이 아니라 구조인 경우가 많다
  • 표면적 해결은 단기 효과는 있지만 팀 전체를 소모하게 만든다
요약: 반복되는 문제는 해결을 더 열심히 하기 전에, 내가 지금까지 너무 얕은 곳에서 질문을 멈춰왔던 건 아닌지 먼저 돌아봐야 합니다.

 

근본원인 — "왜"를 다섯 번 파고드는 기술

5Why(파이브 와이즈)는 토요타 생산 시스템을 개발한 도요다 사키치가 고안한 근본 원인 분석(Root Cause Analysis) 기법입니다. 여기서 근본 원인 분석이란 눈에 보이는 증상 뒤에 숨어 있는 진짜 원인을 체계적으로 추적하는 사고 방식을 의미합니다. "왜?"라는 질문을 꼬리에 꼬리를 물며 이어가되, 단순히 다섯 번을 채우는 게 목적이 아닙니다.

핵심은 질문과 질문 사이의 연결입니다. 앞선 답변에서 핵심 키워드를 포착하고, 그것을 다음 질문의 출발점으로 삼아야 합니다. 제가 직접 써봤는데, 이 연결이 끊기는 순간 5Why는 그냥 대화가 되어버립니다. 논리의 고리가 단단하게 이어져야만 마지막에 도달하는 원칙에 설득력이 생깁니다.

이렇게 파고들다 보면 "명확한 단순함"이라는 핵심 키워드에 도달하게 됩니다. 이 과정에서 중요한 점이 하나 있습니다. 질문의 방향을 반드시 사람이 아닌 시스템으로 향하게 해야 한다는 것입니다. "디자이너가 놓쳤나?"가 아니라 "우리 프로세스에서 어떤 기준이 비어 있었는가?"로 물어야 방어적인 반응 없이 구조적 공백을 찾을 수 있습니다.

또한 출발 질문이 구체적이어야 도착점도 구체적입니다. "왜 서비스가 인기가 없을까?"처럼 모호하게 시작하면 마지막 답도 결국 모호해집니다. "결제 전환율이 지난달 대비 10% 떨어진 이유는 무엇인가?"처럼 데이터나 실제 사용자 행동에서 출발해야 본질에 닿는 속도가 빨라집니다.

 
요약: 5Why의 핵심은 "왜"를 기계적으로 다섯 번 채우는 것이 아니라, 앞 답변의 핵심을 포착해 논리적으로 연결하며 시스템의 구조적 공백까지 내려가는 것입니다.

 

원칙도출 — 키워드를 행동 지침으로 바꾸는 법

5Why를 통해 핵심 키워드를 찾아냈다고 해서 끝이 아닙니다. 솔직히 이건 예상 밖이었습니다. 처음 이 기법을 접했을 때 "왜"를 반복하면 자동으로 실행 가능한 해결책이 나오는 줄 알았습니다. 그런데 아닙니다. 키워드는 상태를 나타내고, 프린시플(Principle)은 그 상태를 만들기 위한 구체적인 행동 지침을 나타냅니다. 이 둘은 다릅니다.

여기서 프린시플이란 팀원 누구나 보고 바로 행동으로 옮길 수 있는 실천적 원칙을 의미합니다. 예를 들어 "신선함"이라는 키워드가 있다고 가정하면, "우리는 신선함을 추구한다"는 선언은 프린시플이 아닙니다. 그런데 "오늘 입고된 재료가 아니면 판매하지 않는다"는 문장은 프린시플입니다. 팀원마다 다르게 해석할 여지가 없기 때문입니다.

앞서 배달앱 예시에서 도출한 "명확한 단순함"이라는 키워드를 프린시플로 치환하면 이렇게 됩니다. "결정의 순간을 방해하지 않도록, 정보의 노출을 간결하게 제한한다." 이 문장 하나가 있으면 어떤 옵션을 넣고 뺄지 고민할 때마다 명확한 판단 기준이 생깁니다. 공급자가 "이 정보도 넣어달라"고 요청해도 원칙에 근거해 설명할 수 있습니다.

프린시플을 만들 때 제가 가장 유용하게 쓰는 방법은 5Why 과정에서 드러난 갈등 지점을 먼저 명확히 하는 겁니다. 공급자가 원하는 것과 사용자가 원하는 것이 어디서 충돌했는지를 보면, 우리 팀이 어느 쪽을 우선해야 하는지 선택의 근거가 보입니다. 그 선택을 문장으로 고정하는 것, 그것이 살아있는 원칙을 만드는 과정입니다.

물론 5Why에도 한계는 있습니다. 질문하는 사람의 관점에 따라 전혀 다른 원인에 도달할 수 있다는 점입니다. 그래서 혼자 분석한 뒤 반드시 관련된 사람들과 함께 검토하는 과정이 필요합니다. 반드시 다섯 번이어야 할 이유도 없습니다. 세 번 만에 구조적 원인이 드러날 수도 있고, 여섯 번이 필요할 수도 있습니다. 중요한 것은 숫자가 아니라 더 이상 표면적인 변명이 아닌, 실제로 바꿀 수 있는 구조에 도달했는가입니다.

 

요약: 핵심 키워드를 찾은 뒤에는 팀원 누구나 보고 바로 행동할 수 있는 프린시플 문장으로 치환해야 비로소 5Why가 실무에서 힘을 발휘합니다.

 

5whys 분석예시

자주 묻는 질문

Q. 5Why는 꼭 다섯 번 물어야 하나요?

A. 아닙니다. "다섯 번"은 경험적으로 대부분의 문제에서 구조적 원인에 닿는 데 충분한 횟수라는 의미입니다. 세 번 만에 근본 원인이 드러날 수도 있고, 여섯 번이 필요한 경우도 있습니다. 중요한 건 숫자를 채우는 것이 아니라 더 이상 개인의 변명이 아닌 바꿀 수 있는 시스템 구조에 도달했는가입니다.

 

Q. 혼자 5Why를 해도 되나요, 팀이 같이 해야 하나요?

A. 혼자서도 할 수 있지만, 질문하는 사람의 관점에 따라 결과가 달라질 수 있다는 것이 5Why의 가장 큰 한계입니다. 일반적으로 혼자 1차 분석을 하고 관련된 팀원들과 함께 검토하는 방식이 가장 효과적입니다. 제 경험상 여러 사람이 함께 하면 혼자 보지 못했던 갈등 지점이 훨씬 잘 드러납니다.

 

Q. 5Why로 찾은 원인이 맞는지 어떻게 확인하나요?

A. 가장 확실한 방법은 도출한 원인을 바탕으로 구조를 바꿨을 때 같은 증상이 사라지는지 확인하는 것입니다. 만약 원칙을 세우고 프로세스를 수정했는데도 같은 문제가 반복된다면, 아직 진짜 원인까지 내려가지 못한 겁니다. 또한 각 단계의 답변이 추측이 아닌 확인 가능한 사실에 기반하고 있는지도 점검해야 합니다.

 

Q. 5Why와 다른 원인 분석 기법의 차이는 무엇인가요?

A. 피시본 다이어그램(특성요인도)처럼 여러 원인을 수평적으로 펼쳐 보는 기법들과 달리, 5Why는 하나의 현상을 수직적으로 깊게 파고드는 방식입니다. 서비스 전체 맥락을 넓게 보기엔 다소 부족할 수 있지만, 특정 반복 문제의 근본 원인을 빠르게 찾을 때는 리서치 비용 없이 팀원들과 즉시 시작할 수 있다는 장점이 있습니다.

 

결론

5Why를 제대로 익히고 나서 업무 방식이 바뀐 부분이 있다면, 문제가 생겼을 때 해결책보다 질문을 먼저 생각하게 됐다는 점입니다. 이전에는 빠르게 움직이는 것이 유능함이라고 생각했습니다. 지금은 방향이 맞는지 먼저 확인하는 것이 훨씬 중요하다는 걸 압니다.

문제가 반복된다면 해결을 더 열심히 하기 전에, 제가 지금까지 너무 얕게 질문해온 건 아닌지 먼저 돌아보는 게 먼저입니다. 현상은 눈에 보이지만 원인은 보이지 않는 경우가 많습니다. 5Why는 그 보이지 않는 구조까지 내려가는 가장 단순하고 강력한 도구입니다. 단, 논리의 연결과 시스템을 향한 질문 방향, 그리고 키워드를 실천 가능한 프린시플로 치환하는 마지막 단계까지 갖춰야 진짜 힘을 냅니다.

 

참고: 유튜브Dewsign

 

 

5Why 기법 (근본원인, 반복문제, 구조적해결)

저도 처음엔 프로젝트 일정이 늦어지는 게 팀원 탓이라고만 생각했습니다. 그런데 막상 '왜'라는 질문을 다섯 번 반복하고 나서야 문제의 진짜 얼굴을 마주했습니다. 5Why 기법은 표면적인 증상

247being.com