5 Whys AI 퍼실리테이터의 설계와 작동 원리
서버가 다운되면 재시작하고, 고객이 불만을 제기하면 사과하고, 납기가 지연되면 야근한다. 우리가 일상에서 마주하는 문제 해결의 대부분은 이런 증상 치료에 머문다. 문제는 같은 일이 반복된다는 것이다. 서버는 다음 주에 또 죽고, 고객은 다음 달에 또 화를 내고, 프로젝트는 또다시 밀린다. 증상만 건드렸을 뿐 진짜 원인을 손대지 못했기 때문이다.
5 Whys는 이 반복의 고리를 끊기 위해 만들어진 도구다. 표면에 드러난 증상에서 출발해 "왜?"를 반복적으로 질문함으로써, 문제의 구조적이고 시스템적인 근본원인(Root Cause)에 도달하는 기법이다. 1930년대 토요다 사키치가 개념을 만들고, 오노 다이이치가 도요타 생산방식(TPS)에 체계화했으며, 이후 구글, 아마존, 넷플릭스 같은 글로벌 테크 기업부터 제조업, 의료, 스타트업까지 전 세계로 퍼져나갔다. 세계에서 가장 널리 쓰이는 근본원인분석(RCA) 도구라 해도 과언이 아니다.
그런데 이 도구에는 역설이 있다. 배우기는 5분이면 되지만, 제대로 쓰는 조직은 극소수라는 사실이다. Al-Rifai(2025)가 산업 현장에서 완료된 91건의 5 Whys 워크시트를 분석한 결과, 인과관계 체인이 올바르게 구성된 사례는 51.6%에 그쳤다. 절반은 원인과 결과의 연결 자체가 잘못되어 있었다는 뜻이다. 근본원인을 실제로 제거하는 데 성공한 사례는 39.6%에 불과했고, 문제 정의부터 원인 분석, 대책 수립, 효과 검증까지 전체 사이클을 완수한 사례는 34.1%뿐이었다. 가장 충격적인 수치는 실무자의 63.2%가 "초보자" 수준으로 분류되었다는 점이다. 교육 없이 사용하면 실패 확률이 압도적이라는 뜻이다.
왜 이렇게 실패율이 높은 것일까. 5 Whys는 극도로 단순하기 때문에 누구나 쓸 수 있다고 착각하게 만든다. "왜?"를 다섯 번 물으면 끝이라고 생각한다. 하지만 올바른 질문을 올바른 순서로 던지고, 추측이 아닌 사실에 기반해 답하고, 사람이 아닌 시스템의 결함까지 파고들고, 분석에서 끝나지 않고 대책까지 완수하는 것은 전혀 다른 차원의 역량을 요구한다. Key(2019)의 실험 연구는 이 문제의 해답을 하나 제시했다. 5 Whys의 성패를 가르는 가장 중요한 변수는 도구도, 양식도, 참여 인원 수도 아니라 훈련된 퍼실리테이터의 존재였다. 통계적으로 유의미한 효과를 보인 유일한 변수였다.
RootCause Agent는 바로 이 지점에서 출발한다. 모든 조직이 숙련된 퍼실리테이터를 확보할 수는 없다. 하지만 AI는 학술 연구가 축적한 실패 패턴과 교정 원칙을 내장한 채, 사용자 옆에 항상 앉아 있을 수 있다. 이 에이전트의 목표는 5 Whys를 대체하는 것이 아니라, 5 Whys가 제대로 작동하지 못하게 만드는 구조적 약점을 실시간으로 교정하는 것이다.
RootCause Agent의 설계는 특정 기업의 경험담이나 베스트 프랙티스 모음이 아니라, 5 Whys에 대한 가장 체계적인 학술 비판 세 편을 기반으로 한다. Card(2017)의 BMJ Quality & Safety 논문, Al-Rifai(2025)의 91건 실증 연구, Barsalou와 Starzyńska(2023)의 문헌·설문 분석이 그것이다. 이 세 편의 연구가 지적한 구조적 결함을 하나하나 대응하는 교정 장치 다섯 개가 에이전트의 골격을 이룬다.
첫 번째 교정 장치는 사실 기반 강제다. Al-Rifai의 연구에서 48.4%의 분석이 적절한 인과관계 순서조차 갖추지 못한 핵심 원인은 추측에 기반한 답변이었다. Barsalou와 Starzyńska의 조사에서도 실제 조직의 41.8%가 경험적 조사 없이 순수 브레인스토밍 도구로 5 Whys를 사용하고 있었다. RootCause Agent는 사용자의 모든 답변에서 추측 신호("아마", "~인 것 같다", "추측이지만")를 감지하고, 도요타의 겐치겐부쓰(現地現物, 현장에 가서 직접 확인하라) 원칙에 따라 로그, 데이터, 기록, 현장 확인 등 구체적 근거를 요구한다. 확인이 당장 어려운 경우에는 "확인 필요"로 표시하고 진행할 수 있지만, 최종 보고서에 분석 신뢰도로 반영된다.
두 번째 교정 장치는 분기형 사고 강제다. Card(2017)의 가장 날카로운 비판은 5 Whys가 단일 인과 경로만 추적하게 만든다는 것이었다. 현실의 문제는 대부분 여러 원인이 복합적으로 작용하지만, "왜?"를 한 번 물으면 하나의 답만 선택하고 다음으로 넘어가는 구조가 복수 원인 탐색을 원천적으로 차단한다. ThinkReliability의 분석에 따르면 오노 다이이치의 유명한 기계 정지 사례조차 실제로는 17개 이상의 기여 원인이 존재한다. RootCause Agent는 매 단계에서 "이 외에 다른 원인도 있을 수 있나요?"라는 분기 확인 질문을 던지고, 복수 답변이 나오면 각 경로를 독립적으로 추적하는 나무 구조 분석을 진행한다.
세 번째 교정 장치는 시스템 원인 도달 규칙이다. 5 Whys가 현장에서 가장 흔하게 실패하는 패턴은 "김 개발자가 실수했다", "영업팀이 열심히 안 했다"처럼 특정 개인의 행동에서 분석이 멈추는 것이다. 에릭 리스가 경고한 "5 Blames의 저주"다. 아마존의 COE(Correction of Errors) 프로세스에는 인과 체인이 반드시 인프라 수준에 도달해야 한다는 규칙이 있다. "엔지니어가 실수했다"에서 멈추면 COE가 반려된다. RootCause Agent는 개인 비난이 감지되면 자동으로 전환 질문을 던진다. "그 실수를 허용한 시스템적 조건은 무엇인가요?" 프로세스에 해당 단계가 정의되어 있었는지, 실수를 방지하는 체크리스트나 자동화가 있었는지, 교육이 충분했는지, 업무량이나 시간 압박이 판단에 영향을 미쳤는지를 구조적으로 탐색한다. 사람의 실수에서 멈추지 말고, 그 실수를 허용한 시스템의 결함까지 파고드는 것이 이 장치의 목적이다.
네 번째 교정 장치는 대책 완수 강제다. Al-Rifai의 연구에서 전체 문제해결 사이클을 완수한 사례가 34.1%에 불과했다는 사실은, 대부분의 조직이 근본원인을 찾고도 대책을 세우지 않거나 대책의 효과를 검증하지 않는다는 뜻이다. 분석만 하고 끝내면 분석은 무의미해진다. RootCause Agent는 근본원인 도출 후 반드시 즉시 조치, 단기 대책, 장기 시스템 변경이라는 세 층위의 대책을 수립하도록 안내하며, 에릭 리스의 비례적 투자 원칙에 따라 인과 체인의 각 단계에도 소규모 방어 조치를 배치한다. 나아가 효과 검증 계획까지 포함시켜, 대책 실행 후 원래 문제가 재발하는지 모니터링하는 지표, 기간, 성공 기준을 함께 정의한다. 도요타가 "솔루션(Solution)" 대신 "대책(Countermeasure)"이라는 단어를 쓰는 이유와 같다. 완전한 해결이라는 오만 대신, 최선의 조치이되 모니터링이 필요하다는 겸손을 내포하는 것이다.
다섯 번째 교정 장치는 한계 인식과 도구 전환이다. Card(2017)의 비판 핵심은 5 Whys가 복잡한 시스템 문제에 구조적으로 부적합하다는 것이었다. 여러 원인이 상호작용하고, 피드백 루프가 존재하고, 창발적 행동이 나타나는 상황에서는 5 Whys의 선형적 질문 구조가 근본적으로 작동하지 않는다. 도요타 내부에서도 5 Whys는 피시본 다이어그램, FTA, PDCA, A3 리포트 등 여러 도구 중 하나로 사용되지, 단독 도구로는 절대 사용되지 않는다. RootCause Agent는 문제 정의 직후 복잡도를 자동 평가하여, 원인이 5개 이상으로 추정되거나 시스템 간 상호작용이 존재하거나 안전 필수 영역의 문제일 경우, 5 Whys의 한계를 솔직히 알리고 피시본, FTA, FMEA, Cause Mapping 등 적절한 대안 도구로의 전환을 권고한다.
RootCause Agent는 사용자와의 대화를 7개의 명확한 단계로 구조화한다. 이 구조는 도요타의 A3 리포트와 PDCA 사이클에서 영감을 받았지만, AI 대화 인터페이스에 맞게 재설계된 것이다. 각 단계는 이전 단계의 출력을 입력으로 받아 자연스럽게 이어지며, 사용자는 전문 지식 없이도 흐름을 따라가기만 하면 된다.
0단계는 맥락 파악이다. 사용자가 처음 대화를 시작하면 에이전트가 자기소개와 함께 분석하고 싶은 문제를 묻는다. 이 단계에서 중요한 것은 사용자의 심리적 부담을 낮추는 것이다. "짧게 말씀하셔도 괜찮습니다"라는 안내가 의도적으로 포함되어 있다.
1단계는 문제 정의다. 전체 프로세스에서 가장 중요한 단계다. 문제 정의가 부실하면 나머지 전체가 무너지기 때문이다. "서버가 자주 죽는다"와 "4월 7일 오후 3시, 프로덕션 서버가 OOM으로 다운되어 30분간 서비스 중단"은 전혀 다른 출발점이다. 에이전트는 사용자의 원래 진술을 받아 "언제, 어디서, 무엇이, 얼마나, 어떤 영향이 있었는가"의 5W 공식에 맞게 재구성한다. 모호한 표현은 구체적 수치와 날짜로 치환을 시도하며, 부족한 정보가 있으면 한 번에 두 개 이하의 질문으로 보충한다. 충분한 정보가 모이면 구조화된 문제 정의서를 제시하고 사용자의 확인을 받는다.
2단계는 복잡도 사전 평가다. 문제 정의가 완료되면 에이전트가 자동으로 문제의 복잡도를 단순, 중간, 복잡으로 분류한다. 추정 원인이 1에서 2개이고 단일 시스템 내 문제이면 5 Whys 단독 사용이 적합하다. 원인이 3에서 5개이고 복수 팀이 관여하면 피시본 다이어그램과 5 Whys를 조합한다. 원인이 5개 이상이거나 시스템 간 피드백 루프가 존재하거나 안전 필수 영역이면 5 Whys 단독 사용이 부적합하다고 솔직히 알리고 대안을 제시한다. 이 단계가 존재하는 이유는 Card(2017)가 지적한 "복잡한 문제에 단순한 도구를 무리하게 적용하는" 실패를 사전에 차단하기 위해서다.
3단계는 피시본 매핑이다. 복잡도가 중간 이상일 때만 활성화된다. 5 Whys에 들어가기 전에 가능한 원인 범주를 먼저 넓게 매핑하는 것이다. 제조나 하드웨어 문제면 6M(사람, 설비, 방법, 재료, 측정, 환경), 소프트웨어 문제면 수정 6M(사람, 인프라, 프로세스, 코드, 데이터, 외부 요인), 비즈니스 문제면 4P(사람, 프로세스, 제품, 정책) 프레임을 문맥에 따라 자동 선택한다. 피시본이 폭을 확보하고, 이후 유력한 가지에 5 Whys가 깊이를 파고드는 구조다.
4단계는 5 Whys 반복 질문이다. 핵심 분석 단계로, 에이전트가 사용자에게 "왜?"를 순차적으로 묻되 앞서 설명한 교정 장치들이 동시에 작동한다. 한 번에 하나의 질문만 던져 사용자를 압도하지 않고, 매 답변마다 사실 기반 여부, 분기 가능성, 비난 패턴을 실시간으로 체크한다. "5"라는 숫자에 집착하지 않는다. 오노 다이이치 본인도 3회에서 8회까지 유동적으로 적용했다. 멈추는 시점은 횟수가 아니라 세 가지 기준으로 판단한다. 더 이상 의미 있는 답이 나오지 않을 때, 우리가 통제할 수 있는 원인에 도달했을 때, 프로세스나 시스템 수준의 원인에 도달했을 때다.
5단계는 역방향 검증이다. 근본원인 후보가 도출되면 마지막 원인부터 첫 번째 문제까지 "그러므로(Therefore)"로 역추적한다. 여과기가 없다, 그러므로 금속 파편이 유입된다, 그러므로 펌프 축이 마모된다, 그러므로 기계가 멈춘다. 모든 연결이 논리적으로 타당해야 근본원인이 맞다. 논리적 비약이 발견되면 해당 지점으로 돌아가 다시 분석한다.
6단계는 대책 수립이다. 즉시 조치(24시간 내), 단기 대책(1~2주), 장기 시스템 변경(1~3개월)의 세 층위로 구분하되, 에릭 리스의 비례적 투자 원칙에 따라 인과 체인의 각 단계에도 소규모 방어 조치를 배치한다. 모든 대책은 담당자, 기한, 측정 가능한 완료 기준을 갖춰야 하며, "영업팀에 더 열심히 하라고 독려한다" 같은 실행 불가능한 대책은 즉시 기각되고 시스템적 대안이 제시된다.
7단계는 효과 검증 계획이다. 대책 실행 후 원래 문제가 재발하는지 확인하기 위한 모니터링 지표, 측정 방법, 검증 기간, 성공 기준, 실패 시 조치를 정의한다. 이 단계까지 완수해야 비로소 하나의 5 Whys 분석 사이클이 닫힌다. Al-Rifai 연구에서 이 전체 사이클을 완수한 사례가 34.1%에 불과했다는 점을 상기하면, 이 마지막 단계를 생략하지 않는 것이 얼마나 중요한지 알 수 있다.
RootCause Agent의 핵심 차별점은 사용자가 빠지기 쉬운 실패 패턴을 대화 진행 중 실시간으로 감지하고 교정한다는 점이다. 이 네 가지 패턴은 Al-Rifai(2025)와 Barsalou(2023)의 실증 데이터에서 가장 빈번하게 관찰된 것들이다.
첫 번째 패턴은 추측 기반 답변이다. "왜 배포가 실패했는가?"라는 질문에 "아마 테스트가 부족했을 것이다"라고 답하는 순간, 분석은 사실 추적이 아니라 소설 쓰기가 된다. 에이전트는 "아마", "~인 것 같다", "추측이지만", "확실하지 않지만" 같은 신호 키워드를 감지하면 즉시 개입한다. "이 답변은 추측에 가까워 보입니다. 로그, 데이터, 현장 확인 등 사실로 뒷받침할 수 있는 근거가 있나요?" 당장 확인이 어려우면 "확인 필요"로 표시하고 넘어갈 수 있지만, 확인되지 않은 항목이 많아질수록 최종 보고서의 분석 신뢰도가 낮아진다는 피드백을 받게 된다. 이 장치는 도요타의 겐치겐부쓰 원칙, 즉 회의실에서 추론하지 말고 현장에 가서 직접 확인하라는 철학을 대화 프로토콜로 번역한 것이다.
두 번째 패턴은 개인 비난 정지다. "왜 잘못된 코드가 배포되었는가?"에 "김 개발자가 실수했기 때문이다"라고 답하면, 대부분의 조직에서 분석은 여기서 끝난다. 그리고 다음에 같은 실수가 반복된다. 사람은 실수하는 존재이기 때문이다. 에이전트는 특정 개인 이름과 부정적 행위가 결합된 답변을 감지하면 자동으로 시스템 전환 질문을 던진다. 그 사람이 그렇게 행동하게 만든 구조적 조건이 무엇인지를 묻는 것이다. 프로세스에 해당 검증 단계가 정의되어 있었는지, 코드 리뷰 체크리스트에 해당 유형의 오류 항목이 있었는지, 자동화된 검증 도구가 존재했는지를 탐색한다. 이렇게 하면 "김 개발자가 실수했다"가 "코드 리뷰 체크리스트에 DB 스키마 변경 검증 항목이 없었다"로 변환되고, 대책은 "김 개발자에게 주의를 준다"가 아니라 "체크리스트에 항목을 추가한다"가 된다. 전자는 한 사람에게만 적용되지만, 후자는 모든 팀원에게 적용된다.
세 번째 패턴은 순환 논리다. "왜 매출이 부족한가?"로 시작한 분석이 다섯 번째 "왜?"에서 "매출이 부족해서"로 돌아오는 경우다. 놀랍도록 흔하게 발생하는 패턴이다. 에이전트는 N차 답변이 원래 문제 정의와 의미적으로 동일한지를 지속적으로 비교하며, 순환이 감지되면 즉시 알린다. "현재 답변은 원래 문제와 실질적으로 동일합니다. 이는 5 Whys의 대표적 실패 패턴입니다." 그리고 이전 단계로 돌아가 다른 방향의 "왜?"를 탐색한다. 순환 논리는 대개 인과 체인의 어딘가에서 논리적 비약이 있었음을 의미하므로, 에이전트는 해당 비약 지점을 찾아 재검토를 유도한다.
네 번째 패턴은 선형 고착이다. 5 Whys의 구조적 한계 중 가장 근본적인 것으로, 하나의 "왜?"에 하나의 답만 선택하고 곧장 다음으로 넘어가는 습관이다. 현실에서 서버가 다운되는 원인은 OOM(메모리 부족)일 수도 있고, 네트워크 장애일 수도 있고, 배포 스크립트 오류일 수도 있다. 이 세 가지가 동시에 기여했을 가능성도 있다. 에이전트는 매 단계에서 "혹시 이 외에 다른 원인도 있을 수 있나요?"를 주기적으로 묻고, 복수 답변이 나오면 각각을 독립 경로로 분리하여 추적한다. 최종 보고서에는 모든 경로의 분석 결과가 포함되므로, 단일 원인에 모든 것을 걸었다가 빗나가는 위험을 줄인다. 이것이 Card(2017)가 제안한 분기형 5 Whys의 실제 구현이다.
RootCause Agent는 사용자가 제시한 문제의 맥락을 파악하여 대화의 프레임워크, 용어, 대책의 방향을 자동으로 조정한다. 소프트웨어 장애, 제조 불량, 비즈니스 이슈, 의료 사고는 같은 5 Whys 기법을 쓰더라도 원인을 분류하는 범주, 사실을 확인하는 방법, 대책의 형태가 완전히 다르기 때문이다.
소프트웨어와 IT 문제가 감지되면 에이전트는 "현장에 가서 확인하라"는 겐치겐부쓰 원칙을 "로그, 메트릭, 트레이스를 직접 확인하라"로 번역한다. 피시본의 범주는 People, Platform, Process, Program, Data, External로 조정되고, 대책에는 자동화 테스트 추가, 모니터링 알림 설정, 롤백 프로세스 정비 같은 DevOps 맥락의 용어가 자연스럽게 사용된다. Google SRE의 비난 없는 포스트모템 문화와 아마존 COE의 인프라 도달 규칙이 참조 프레임으로 작동한다.
제조와 품질 문제가 감지되면 6M 피시본 프레임(Man, Machine, Method, Material, Measurement, Mother Nature)이 자동 선택되고, 대책에는 포카요케(실수 방지 장치), 표준작업서(SOP) 개정, 검사 공정 추가 같은 린 생산 용어가 사용된다. 도요타의 PDCA 사이클과 A3 리포트 프레임이 참조된다.
비즈니스와 조직 문제가 감지되면 4P 프레임(People, Process, Product, Policy)이 선택되고, 정량적 데이터뿐 아니라 인터뷰나 서베이 같은 정성적 근거도 유효한 사실로 인정한다. 대책에는 프로세스 재설계, KPI 변경, 의사결정 구조 변경 같은 조직 맥락의 용어가 사용된다.
의료와 안전 문제가 감지되면 에이전트는 가장 먼저 경고를 발한다. "안전 필수 영역에서는 5 Whys 단독 사용이 권장되지 않습니다." Card(2017)가 BMJ에서 의료 분야에서 5 Whys를 전혀 사용하지 말 것을 권고한 맥락이다. 이 경우 FTA나 FMEA와의 병행을 강력히 권고하며, Swiss Cheese Model을 참조 프레임으로 활용하고, 규제와 프로토콜 수준의 대책을 강조한다.
이 산업별 적응보다 더 중요한 것은 도구 전환의 결단이다. RootCause Agent는 5 Whys가 만능이라는 환상을 갖지 않는다. 문제의 복잡도가 5 Whys의 구조적 수용 범위를 넘어선다고 판단되면, 에이전트는 분석을 강행하는 대신 솔직하게 한계를 인정한다. "이 문제는 여러 원인이 상호작용하는 복잡한 시스템 문제입니다. 5 Whys만으로는 구조적으로 충분한 분석이 어렵습니다." 그리고 Cause Mapping(5 Whys를 10-Why, 25-Why로 확장한 다중 경로 분석), FTA(확률 기반 고장수목분석), FMEA(설계 단계 사전 예방) 같은 대안 도구의 핵심 특징과 적합한 상황을 안내한다. 도요타 내부에서도 5 Whys는 피시본, FTA, 통계 분석 등 여러 도구 중 하나로만 사용되며 단독 도구로는 절대 사용되지 않는다. 이 원칙을 AI 에이전트도 그대로 따르는 것이다.
RootCause Agent가 하는 일을 한 문장으로 요약하면, 5 Whys라는 단순한 도구가 제대로 작동하기 위해 필요한 모든 비가시적 조건들을 AI가 대신 챙겨주는 것이다. 추측이 아닌 사실로 답하게 하고, 사람이 아닌 시스템을 고치게 하고, 하나의 경로가 아니라 여러 갈래를 탐색하게 하고, 분석에서 끝나지 않고 대책까지 완수하게 하고, 도구의 한계를 넘어서는 문제에는 다른 도구로 안내한다.
도요타에서 5 Whys가 90년간 살아남은 이유는 "왜?"라는 질문의 힘이 아니라, 현지현물 문화, 비난 없는 조직 풍토, A3 프레임워크, 숙련된 퍼실리테이터라는 인프라가 그 질문을 둘러싸고 있었기 때문이다. 5 Whys가 도요타 밖에서 자주 실패하는 이유도 같다. 도구만 가져갔지, 도구를 작동시키는 문화와 시스템은 가져가지 못했기 때문이다. RootCause Agent는 그 문화와 시스템의 역할을 AI 프로토콜로 번역한 것이다.
이 에이전트가 답을 대신 찾아주는 것은 아니다. 근본원인은 현장에 있고, 그것을 아는 것은 현장의 사람이다. 에이전트가 하는 일은 그 사람이 올바른 질문을 올바른 순서로 던지도록 돕고, 빠지기 쉬운 함정을 실시간으로 알려주고, 분석이 중간에 멈추지 않고 대책과 검증까지 완주하도록 끝까지 함께 걷는 것이다. Key(2019)가 증명한 것처럼 5 Whys의 성패를 가르는 유일한 유의미 변수는 훈련된 퍼실리테이터였다. RootCause Agent는 모든 팀에, 모든 문제에, 항상 옆에 있는 그 퍼실리테이터를 만들려는 시도다.