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

저도 처음엔 프로젝트 일정이 늦어지는 게 팀원 탓이라고만 생각했습니다. 그런데 막상 '왜'라는 질문을 다섯 번 반복하고 나서야 문제의 진짜 얼굴을 마주했습니다. 5Why 기법은 표면적인 증상 뒤에 숨어 있는 근본 원인을 꺼내는 도구입니다. 한 번 써보면, 이전에 내렸던 해결책들이 얼마나 임시방편이었는지 실감하게 됩니다. 

삼성의 전회장인 이건희회장도 자주 이야기했다고 하는 기법이니, 속는 셈 치고 한 번 해 보시길 추천드려요. 

 

근본원인을 찾기 전, 저는 사람을 탓하고 있었습니다

팀 프로젝트 일정이 계속 밀리던 시기가 있었습니다. 처음에는 솔직히 '누군가 느슨하게 일하는 거 아닐까'라는 생각부터 들었습니다. 팀원의 태도를 의심하거나 일정 관리 능력을 탓하는 쪽으로 감정이 먼저 움직였습니다.

그런데 문제가 계속 반복되자, 이건 사람 문제가 아닐 수 있다는 생각이 들었습니다. 그때 적용해본 것이 도요타가 실제 생산 현장에서 사용한 5Why 기법입니다. 5Why란 어떤 문제에 대해 '왜'라는 질문을 최소 다섯 번 반복하면서 표면적 원인을 걷어내고 구조적 결함을 찾아내는 원인 분석 방법론입니다. 단순히 질문을 반복하는 것처럼 보이지만, 실제로 해보면 질문이 하나씩 깊어질수록 전혀 예상하지 못한 지점에서 원인이 튀어나옵니다.

일반적으로 문제가 생기면 눈에 보이는 첫 번째 원인을 제거하는 데서 멈추는 경우가 많습니다. 그런데 제 경험상 그렇게 하면 같은 문제가 몇 주 뒤에 다시 고개를 듭니다. 첫 번째 답이 '보고서 작성에 시간이 너무 오래 걸린다'였다면, 거기서 멈추고 보고서 작성 속도를 높이는 교육을 기획하는 것이 전형적인 임시방편입니다.

• 1차 원인: 보고서 작성 시간이 너무 오래 걸린다
• 2차 원인: 필요한 데이터를 매번 여러 부서에 다시 요청해야 한다
• 3차 원인: 공유 데이터 양식이 통일되지 않아 매번 재가공이 필요하다
• 4차 원인: 부서마다 각자 편한 방식으로 자료를 관리해왔다
• 5차 원인(근본 원인): 표준화된 양식을 만들고 유지할 담당자가 없었다

다섯 번의 질문 끝에 도달한 건 사람의 게으름이 아니라, 처음부터 없었던 프로세스였습니다. 이걸 발견하고 나서야 왜 교육이나 독려로는 아무것도 바뀌지 않았는지 이해할 수 있었습니다.

 

요약: 5Why 기법은 표면적 증상이 아닌 구조적 결함을 찾아내는 원인 분석 방법론으로, 질문을 다섯 번 반복할수록 사람이 아닌 시스템의 문제가 드러난다.

 

반복 문제는 운이 없어서가 아니라, 질문이 얕아서입니다

도요타는 자동차 생산 라인이 갑자기 멈추는 상황에서 이 기법을 정교하게 발전시켰습니다(출처: Toyota Production System 공식 소개). 퓨즈가 끊어졌을 때 퓨즈만 교체하면 당장은 해결됩니다. 그런데 왜 퓨즈가 끊어졌는지, 왜 전력 과부하가 생겼는지, 왜 베어링이 뻑뻑해졌는지를 따라가다 보면 결국 윤활유 펌프 주변의 먼지 누적이라는 아주 단순하지만 핵심적인 원인에 닿게 됩니다.

토머스 제퍼슨 기념관 사례도 마찬가지입니다. 대리석이 부식된다고 해서 보수 공사를 먼저 떠올리는 것은 자연스러운 반응입니다. 하지만 5Why 분석을 적용하자 원인의 사슬이 세제 → 비둘기 배설물 → 거미 → 나방 → 조명 점등 시간 → 직원 퇴근 시간이라는 예상 밖의 경로로 이어졌습니다. 해결책은 대리석 보수가 아니라 조명을 켜는 시간을 조금 늦추는 것이었습니다. 비용은 사실상 0에 가까웠습니다.

이 사례들이 공통적으로 보여주는 건, 반복 문제(recurrent problem)의 본질입니다. 반복 문제란 한 번 해결한 것처럼 보이지만 동일한 패턴으로 계속 재발하는 문제를 말합니다. 쉽게 말해 증상만 건드리고 원인은 그대로 두는 상황입니다. 제 경험에서도 데이터 재요청 문제는 프로젝트마다 반복됐는데, 담당자를 정하고 표준 양식을 만든 이후로는 같은 문제가 단 한 번도 다시 나타나지 않았습니다. 이게 구조적 해결과 임시 대응의 차이입니다.

5Why를 실제로 쓸 때 주의해야 할 것들

일반적으로 5Why는 어떤 문제에든 적용 가능한 만능 도구처럼 알려져 있지만, 제 경험상 몇 가지 조건이 맞아야 제대로 작동합니다. 우선 답변은 현재 시점에서 통제 가능한 것이어야 합니다. '왜 이 시장은 불경기인가'처럼 아무도 바꿀 수 없는 외부 요인을 원인으로 삼으면 질문이 공허해집니다.

또한 근거가 검증 가능한 사실 기반이어야 합니다. '팀원의 의욕이 부족해서'라는 답은 검증도 측정도 안 됩니다. 반면 '부서 간 데이터 양식이 3가지 이상으로 혼재하고 있어 평균 재가공 시간이 2시간 이상 소요된다'는 답은 실제로 확인하고 해결할 수 있습니다. 질문의 깊이만큼 답변의 품질도 관리해야 합니다.

 

요약: 반복 문제의 핵심은 증상이 아닌 구조에 있으며, 5Why는 통제 가능하고 검증 가능한 사실 기반의 답변을 통해 진짜 원인을 찾는 도구다.

 

구조적 해결 이후, 문제보다 질문하는 습관이 남았습니다

표준화된 데이터 양식을 만들고 담당자를 지정한 뒤, 보고서 작성에 걸리는 시간이 눈에 띄게 줄었습니다. 솔직히 이건 예상 밖이었습니다. 겨우 양식 하나 통일했을 뿐인데, 부서 간 소통 횟수 자체가 줄어들고 전체적인 업무 흐름이 매끄러워졌습니다. 근원적 원인(root cause)을 건드렸을 때 나타나는 파급 효과였습니다. 근원적 원인이란 문제를 반복적으로 유발하는 가장 깊은 층위의 요인으로, 이것을 제거하면 그 위에 쌓인 여러 증상이 함께 해소되는 경우가 많습니다.

문제 해결 그 자체보다 제게 더 오래 남은 건 습관이었습니다. 이후로 뭔가 잘 안 풀리는 상황이 생기면 자동으로 '왜'를 한 번 더 묻게 됩니다. 업무뿐 아니라 일상에서도 마찬가지입니다. '왜 나는 이 일을 자꾸 미루는가'를 다섯 번 따라가다 보면, 의지의 문제가 아니라 시작 지점이 너무 복잡하게 설계돼 있다는 걸 발견하는 식입니다.

경영 컨설팅 분야에서는 이처럼 반복적 질문을 통해 문제를 구조화하는 접근을 근본 원인 분석(Root Cause Analysis, RCA)이라고 부릅니다. RCA란 문제의 겉모습이 아니라 그것이 발생하게 된 시스템적 이유를 체계적으로 추적하는 방법론 전체를 가리키며, 5Why는 그 안에서 가장 접근하기 쉬운 실행 도구입니다(출처: ASQ(American Society for Quality) - Five Whys). 거창한 도구가 필요한 게 아니라, 질문 하나를 더 참고 던지는 태도가 필요한 것입니다.

 

요약: 구조적 해결(근원적 원인 제거)은 단순히 문제 하나를 닫는 것이 아니라 관련된 여러 증상을 함께 해소하며, 5Why는 이를 실현하는 가장 실용적인 진입점이다.

 

자주 묻는 질문

Q. 5Why 기법, 꼭 다섯 번을 채워야 하나요?

A. 반드시 다섯 번일 필요는 없습니다. 일반적으로 다섯 번이 근본 원인에 도달하기에 충분한 깊이라고 알려져 있지만, 제 경험상 세 번 만에 원인이 명확해지는 경우도 있고 일곱 번이 필요한 경우도 있었습니다. 핵심은 '더 이상 왜라고 물을 수 없는 지점'까지 파고드는 것이고, 숫자 자체에 집착할 필요는 없습니다.

 

Q. 5Why를 혼자 하는 것과 팀이 같이 하는 것, 어느 쪽이 효과적인가요?

A. 저는 처음엔 혼자 정리해보고, 이후 관련 팀원들과 함께 검토하는 방식을 선호합니다. 혼자 할 때는 자신의 관점에 갇혀 편향된 원인에 도달할 수 있습니다. 팀이 함께 하면 서로 다른 시각이 더해져 놓쳤던 원인이 드러나는 경우가 많습니다. 특히 부서 간 문제라면 반드시 관련 부서가 함께 참여하는 것이 구조적 해결에 훨씬 유리합니다.

 

Q. 5Why로 원인을 찾았는데 해결이 어려운 경우엔 어떻게 하나요?

A. 근본 원인이 통제 불가능한 외부 요인이라면 5Why의 방향을 조금 바꿔야 합니다. 외부 원인 자체를 제거할 수 없다면, 그 원인의 영향을 최소화할 수 있는 내부 구조를 다시 질문의 출발점으로 삼는 것이 현실적입니다. 제 경험상 해결이 막막하게 느껴질 때는 대부분 질문의 출발점이 잘못 설정된 경우가 많았습니다.

 

Q. 5Why랑 근본 원인 분석(RCA)은 같은 건가요?

A. 같지 않습니다. 근본 원인 분석(RCA)은 문제의 시스템적 원인을 추적하는 방법론 전체를 가리키는 넓은 개념입니다. 5Why는 그 안에서 사용할 수 있는 하나의 실행 도구입니다. RCA에는 특성 요인도(피쉬본 다이어그램), 결함 수 분석(FTA) 등 다른 도구들도 포함되며, 5Why는 그중 가장 진입 장벽이 낮고 일상적으로 쓰기 쉬운 방법입니다.

 

결론

5Why 기법을 직접 써보고 나서 가장 크게 달라진 건 문제를 바라보는 첫 반응이었습니다. 예전엔 문제가 생기면 해결책을 먼저 떠올렸다면, 지금은 질문을 먼저 떠올립니다. 올바른 질문이 없으면 아무리 좋은 해결책도 엉뚱한 곳을 겨누게 됩니다.

지금 반복되는 문제가 있다면, 가장 먼저 했던 해결책을 돌아보시길 권합니다. 그게 증상을 건드린 것이라면, 한 번만 더 '왜'라고 물어볼 가치가 있습니다. 근본 원인 분석은 거창한 프레임워크가 필요한 게 아닙니다. 질문 하나를 더 해보는 것, 거기서 시작됩니다.

 

저 같은 경우 문제를 손으로 적어 보는게 편하다보니 아래의 워크시트를 만들어서 사용하고 있습니다. 참고로 파일을 올려드립니다. 

 

참고: https://youtu.be/8YYRe0ex6wg?si=DK-Pw7EUAvWf5eyg

5Why_분석_워크시트_1.pdf

0.40MB