근본원인 분석의 한계

분명히 원인을 찾았는데, 왜 또 터질까

장애가 났다고 해 보자. 팀이 회의실에 모여 '왜'를 묻기 시작한다.

왜 서버가 죽었나? 메모리가 넘쳤으니까. 왜 넘쳤나? 캐시를 안 비웠으니까. 왜 안 비웠나? 배포 스크립트가 그 단계를 빠뜨렸으니까. 왜 빠뜨렸나? 담당자가 실수했으니까. 왜 실수했나? 체크리스트가 없었으니까.

다섯 번의 '왜' 끝에 '근본 원인'이 나왔다. 팀은 체크리스트를 만들었다. 그런데 몇 달 뒤, 비슷한 장애가 또 터진다.

이런 경험이 있다면 팀의 문제가 아니라 도구의 한계다. 5 Whys(다섯 번의 왜)는 1930년대 도요타의 사키치 도요다가 고안한 검증된 기법이다. 하지만 복잡한 시스템 앞에서는 자주 헛발질을 한다. 이 글은 근본원인 분석의 한계가 어디서 오는지, 그리고 '왜' 대신 무엇을 물어야 하는지를 이야기한다.

'왜'라는 질문이 숨기는 세 가지 함정

신뢰성 분석 도구를 만드는 EasyRCA는 5 Whys의 한계를 여덟 가지로 정리한다. 그중 핵심만 추리면 세 가지다.

첫째, 세상을 일직선으로 본다. 5 Whys는 '원인 하나가 결과 하나를 낳는다'는 단선적 인과를 전제로 깔고 있다. 하지만 실제 장애는 도미노처럼 한 줄로 쓰러지지 않는다. 여러 요인이 동시에 겹쳐야 비로소 사고가 된다.

둘째, 사람마다 답이 다르다. 같은 문제를 놓고도 분석하는 사람에 따라 결론이 갈린다. 재현성이 없다는 뜻이다. 게다가 결과는 분석가의 경험과 편향, 그리고 조직의 위계에 크게 휘둘린다. 팀장이 "그거 배포 문제 아니야?"라고 한마디 던지면, 다섯 번의 '왜'는 자연히 그 방향으로 흘러간다.

셋째, 검증을 하지 않는다. 5 Whys에는 찾아낸 원인이 진짜인지 실제로 테스트해 보라는 요구가 없다. 현장을 직접 관찰하지 않으면, 분석은 사실이 아니라 회의실에서 지어낸 그럴듯한 추론으로 끝난다. '기여 요인(contributing factor)'과 '진짜 원인'을 구분하지 못한 채로 말이다.

다섯 번에서 멈추는 순간, 답이 정해진다

세일즈포스 엔지니어링 블로그의 로버트 블루먼(Robert Blumen)은 더 근본적인 문제를 짚는다. 바로 '다섯'이라는 숫자가 임의적이라는 점이다.

"다섯에서 멈추지 않았다면 '여섯 번의 왜', '일곱 번의 왜'도 가능했을 것이다. 그리고 매번 다른 근본 원인을 얻었을 것이다."

— 로버트 블루먼, 세일즈포스 엔지니어링 블로그

곱씹어 보면 섬뜩한 지적이다. 우리가 다섯 번째에서 멈추며 '아, 이게 근본 원인이구나' 하는 이유는, 그것이 진짜 뿌리여서가 아니다. 그냥 다섯 번째였기 때문이다. 멈추는 지점이 곧 답을 결정한다.

블루먼은 인지시스템 공학자 에릭 홀나겔(Erik Hollnagel)의 개념을 빌려 이를 WYLFIWYF라고 부른다. 'What You Look For Is What You Find', 즉 찾으려는 것을 찾게 된다는 뜻이다. 그리고 아주 구체적인 그림을 제시한다. 갈래가 셋씩 뻗는 3단계짜리 장애 트리를 그려 보면 잠재적 원인 노드가 무려 27개나 나온다. 그런데 5 Whys는 이 27개 가운데 단 하나만 '뿌리'로 지목하고 나머지는 지워 버린다. 마치 그 하나만이 유일한 책임자였던 것 같은 거짓 인상을 남기면서 말이다.

의료 안전을 연구한 리처드 쿡은 「복잡한 시스템은 어떻게 실패하는가」에서 실제 시스템은 이렇게 무너진다고 말한다.

작고 겉보기에 무해한 실패들이 결합해 시스템적 사고의 기회를 만든다.

"The small, apparently innocuous failures combine to create the opportunity for a systemic accident."

— 리처드 쿡

각각의 요인은 그 자체만으로는 사고를 일으키기에 부족하다. 필요하지만, 충분하지는 않다. 여러 개가 한꺼번에 존재해야 비로소 장애가 된다. 그런데 우리는 그중 하나만 붙잡고 "원인을 찾았다"고 선언한다. 나머지 26개는 다음 장애를 위해 고스란히 남겨둔 채로. 문제가 자꾸 되풀이되는 진짜 까닭이 여기에 있다.

'왜' 대신 '어떻게'를 물어라

블루먼의 대안은 질문 자체를 바꾸는 것이다. "왜 실패했나(Why)"가 아니라 "시스템이 어떻게 실패했나(How)"를 묻는다.

'왜'는 본능적으로 하나의 시작점, 하나의 범인을 향한다. 그래서 자연히 책임 추궁으로 흐르고, 사람들은 방어적으로 변한다. 반면 '어떻게'는 여러 요인이 어떤 경로로 얽혀 그 결과에 이르렀는지를 묻는다. 시선이 범인에서 시스템으로 옮겨 간다.

실천 방법은 세 단계다.

1. 기여 요인을 눈에 보이게 펼친다. 하나의 뿌리로 좁히지 말고, 함께 작용한 모든 원인을 다이어그램으로 그려 낸다.
2. 지렛대 지점(leverage point)을 찾는다. 그 요인들 중 어디를 손보면 시스템 안정성이 가장 크게 올라가는지를 살핀다.
3. 투입 대비 효과 순으로 우선순위를 매긴다. 모든 노드를 다 고칠 수는 없으니, 들인 노력에 견줘 회복탄력성이 가장 크게 오르는 곳부터 손댄다.

그래도 5 Whys를 쓴다면

오해는 말자. 5 Whys를 버리라는 말이 아니다. 단순하고 원인이 뚜렷한 문제에는 여전히 빠르고 쓸모 있다. 다만 그 한계를 알고, 보완해서 써야 한다. EasyRCA가 권하는 최소한의 보완책은 이렇다.

• 현장 관찰에서 시작하라. 회의실 추론이 아니라, 직접 눈으로 확인한 사실에서 출발한다.
• '왜'의 각 단계마다 증거를 붙여라. 추측이 아니라 데이터로 뒷받침되는지 확인한다.
• 타임라인을 그려라. 사건이 시간 순서로 어떻게 전개됐는지 지도를 만든다.
• 위험도 함께 따져라. 찾아낸 원인이 틀렸을 경우 어떤 영향이 생기는지 가늠한다.
• 위험이 큰 상황에는 FMEA(고장 유형·영향 분석, 각 실패 지점이 어떤 결과로 번질지 미리 따지는 기법) 같은 정식 기법을 함께 쓴다.

되풀이되는 문제 앞에서, 질문을 의심하라

같은 장애가 반복된다면, 답을 더 열심히 찾을 때가 아니다. 질문 자체를 의심할 때다. '왜'를 다섯 번 물어 얻은 단 하나의 근본 원인은, 실은 27개 중에서 임의로 고른 하나였을지 모른다. 그 하나를 고쳐도, 나머지가 다음 사고를 조용히 준비하고 있었던 것이다.

다음 회고 회의에서는 "왜 그랬나"를 다섯 번 반복하는 대신 이렇게 물어보자. "이 시스템이 어떻게 무너졌나? 어떤 요인들이 함께 작용했나?" 회고를 범인 한 명을 지목하는 자리가 아니라 시스템의 약한 고리들을 지도로 펼치는 자리로 바꿀 때, 비로소 같은 문제의 되풀이가 멈춘다.