5 Whys

🎯문제 정의 #

형용사 없이, 측정 가능한 한 문장

'배포가 자주 깨진다'가 아니라 '최근 4주간 배포 12회 중 3회가 롤백됐다'처럼 수치와 기간이 든 문장으로 시작한다. 문제 문장이 흐리면 첫 번째 왜부터 참가자들이 각자 다른 문제를 분석하게 된다. 하나의 5 Whys 는 하나의 사건을 다룬다, 여러 사건을 뭉뚱그리면 원인도 뭉개진다.

왜 1 #

직접 원인: 그 순간 무엇이 일어났나

첫 번째 왜의 답은 대부분 눈에 보이는 기술적·물리적 사실이다, 예를 들어 '마이그레이션 스크립트가 실패했다'. 여기서 답이 여러 개 나오면 기여도가 가장 큰 것 하나를 고르고 나머지는 별도 체인으로 분리해 둔다. 이 단계의 답은 로그, 기록, 재현으로 즉시 검증 가능해야 한다.

왜 2 #

그 직접 원인은 왜 발생했나

두 번째부터 답이 사실에서 조건으로 넘어간다, '스테이징에 프로덕션과 같은 데이터가 없었다'처럼. 여기서부터 '~인 것 같다'가 섞이기 시작하므로, 각 답 옆에 확인 방법을 적고 확인 전에는 다음 왜로 내려가지 않는다. 추측 위에 쌓은 세 번째 왜는 전부 헛수고가 된다.

왜 3 #

그 조건은 왜 방치되어 있었나

세 번째쯤에서 개인의 행동이 등장하기 쉽다, '담당자가 확인을 건너뛰었다'. 여기서 멈추고 싶은 유혹이 가장 크다. 사람의 실수가 나오면 질문을 바꾼다, '왜 그 실수가 가능한 구조였나', '왜 실수가 걸러지지 않았나'. 실수를 허용한 시스템이 다음 왜의 대상이다.

왜 4 #

구조와 프로세스의 결함이 드러나는 층

잘 진행된 체인이라면 네 번째쯤에서 답이 특정 사건이 아니라 반복 가능한 패턴이 된다, '체크리스트에 해당 항목이 없다', '그 검증을 담당하는 단계 자체가 없다'. 답이 여전히 특정인이나 특정일의 사정이라면 체인이 옆길로 샌 것이니, 왜 2~3으로 돌아가 갈래를 다시 고른다.

🧨왜 5 = 근본 원인 후보 #

고치면 재발이 막히는 지점

근본 원인의 판정 기준은 깊이가 아니라 효과다, 이것을 고치면 같은 계열의 문제가 다시 일어나지 않는가. 역방향 테스트로 확인한다: 왜 5부터 '그러므로'로 거슬러 올라가 문제 문장까지 자연스럽게 이어지면 체인이 성립한 것이다. 다섯 번을 채우는 것이 목적이 아니므로 세 번째에 도달했으면 세 번째에서 멈춘다.

어디서 멈추나 #

통제 가능한 프로세스에 닿으면 끝

끝없이 내려가는 체인은 분석이 아니라 도피다. 멈추는 지점은 우리 팀이 통제할 수 있는 가장 깊은 프로세스다. 답이 '경기 불황', '인간의 본성'처럼 손 밖의 것이 되면 한 단계 위로 올라와 거기를 근본 원인으로 삼는다. 통제 범위 밖의 원인은 고칠 대상이 아니라 견딜 수 있게 설계할 전제 조건이다.

🛠️대책 수립 #

원인을 제거하거나, 오류를 흡수하거나

대책은 두 종류다, 원인 자체를 없애는 것과 원인이 남아도 사고로 이어지지 않게 하는 완충 장치. '주의한다', '교육한다'는 대책이 아니라 희망 사항이다. 사람의 기억에 의존하지 않는 구조 변경(자동화, 기본값 변경, 강제 체크)이어야 한다. 대책 하나가 만들어낼 새 부작용도 이 단계에서 함께 적는다.

대책 검증 1: 재발 지표 #

효과를 숫자로 관찰할 기간을 정한다

대책을 적용하기 전에 무엇을 얼마나 관찰하면 성공인지 정한다, 예를 들어 '적용 후 8주간 동일 유형 롤백 0건'. 지표와 기간 없이 닫힌 5 Whys 는 다음 사고 때 처음부터 다시 하게 된다. 재발하면 대책 실패보다 원인 진단이 틀렸을 가능성부터 의심한다.

대책 검증 2: 역방향 읽기 #

'그러므로' 테스트로 체인을 감사한다

대책을 확정하기 전에 체인 전체를 거꾸로 읽는다. 근본 원인에서 시작해 '그러므로'로 이으며 올라갔을 때 문장이 어색해지는 지점이 논리 비약이 숨은 곳이다. 제3자에게 역방향으로 읽혀 보는 것이 가장 싸고 빠른 감사다, 작성자는 자기 비약을 못 본다.

⚠️흔한 함정 #

체인을 망치는 세 가지 습관

5 Whys 가 형식적 의식으로 전락하는 이유는 도구가 아니라 운용 때문이다. 사람에서 멈추기, 첫 답에 만족하기, 추측으로 잇기 세 가지가 실패의 대부분을 차지한다. 회의 전에 이 세 가지를 명시적 규칙으로 공지하는 것만으로 체인의 질이 달라진다.

함정 1: 사람 탓에서 멈추기 #

'누가'가 나오면 아직 절반이다

'신입이 실수했다'는 근본 원인이 될 수 없다. 그 사람이 내일 퇴사해도 같은 사고는 또 난다. 이름이 등장하면 질문을 구조로 돌린다: 왜 그 실수가 시스템을 통과했는가. 비난 없는(blameless) 원칙은 온정의 문제가 아니라 정확성의 문제다, 처벌이 예상되는 순간 다음 사고부터 정보가 숨는다.

함정 2: 첫 답에 만족하기 #

그럴듯한 답이 가장 위험하다

첫 번째로 나온 그럴듯한 답은 대개 증상의 재서술이거나 모두가 이미 믿고 있던 가설이다. 각 단계에서 '다른 설명이 가능한가'를 한 번씩 묻는 것만으로 체인이 한 단계 깊어진다. 특히 답이 회의 시작 5분 만에 만장일치로 나왔다면 의심하라, 검증 없는 합의는 분석이 아니라 기억이다.

함정 3: 검증 없이 잇기 #

가설의 사슬은 반드시 무너진다

각 왜의 답은 데이터, 로그, 당사자 확인 중 하나로 뒷받침되어야 한다. 하나라도 추측이면 그 아래 전부가 모래 위에 선다. 확인이 안 되는 답이 나오면 체인을 멈추고 확인부터 한다. 5 Whys 는 한 회의 안에 끝내야 하는 의식이 아니라, 확인 사이에 며칠이 걸려도 되는 조사다.

🌿원인이 갈라질 때 #

체인이 아니라 나무가 된다

현실의 문제는 원인이 하나가 아닌 경우가 많다. 한 왜에서 답이 둘 이상 나오면 억지로 하나를 고르지 말고 갈래마다 체인을 나눈다. 다만 모든 갈래를 같은 깊이로 파지는 않는다, 기여도가 가장 큰 갈래부터 파고 나머지는 명시적으로 보류 표시를 남긴다. 갈래를 나눈 기록 자체가 다음 유사 사고 때의 지도가 된다.