1. 들어가며
어느 파트든 반복되는 문제가 있습니다.
"이 기능을 유저가 안 쓴다", "회의가 매번 늘어진다", "행사 모객이 목표에 한참 못 미쳤다" 같은 것들이죠.
그런데 우리는 종종 눈에 보이는 증상만 땜질하고 넘어갑니다.
버튼을 키우고, 회의를 줄이고, 홍보비를 더 씁니다. 그리고 같은 문제가 다시 돌아옵니다.
5 Whys는 이걸 막아주는 도구입니다.
어떤 문제에 "왜?"를 반복해 물으면서, 증상이 아니라 진짜 원인까지 내려가는 방법이죠.
도요타 생산 현장에서 시작됐고, 지금은 기획·개발·아트·운영·사업 어디서나 쓰입니다.
방법 자체는 1분이면 이해하지만, 제대로 쓰는 사람은 의외로 드뭅니다.
이 글은 개념을 짧게 짚은 뒤, 실제로 잘 쓰는 요령 위주로 정리했습니다.
2. 5 Whys란 무엇인가
5 Whys는 한마디로, 어떤 문제에 "왜?"를 반복해 물으면서 증상이 아닌 진짜 원인까지 내려가는 도구입니다.
핵심은 '증상'과 '근본 원인'을 구분하는 데 있습니다.
증상은 눈에 보이는 결과고, 근본 원인은 그 결과를 만든 진짜 뿌리입니다.
우리가 흔히 실패하는 이유는 증상만 보고 처방하기 때문입니다.
머리가 아프다고 진통제만 먹으면 잠깐 낫지만, 원인이 수면 부족이라면 내일 또 아픈 것과 같죠.
왜 하필 "왜?"를 반복할까요? 한 번의 "왜?"는 보통 바로 위층의 원인 하나만 들춰냅니다.
그 답에 다시 "왜?"를 물으면 한 층 더 내려가고, 이걸 반복하면 표면에서 뿌리까지 인과의 사슬을 따라 내려가게 됩니다.
진행 순서는 단순합니다. 먼저 문제를 구체적으로 정의하고, 거기에 "왜 그럴까?"를 물어 원인을 찾습니다.
그 원인을 새로운 문제로 삼아 다시 "왜?"를 묻고, 이걸 뿌리에 닿을 때까지 반복합니다.
마지막으로 그 근본 원인을 없앨 해결책을 정하면 끝입니다.
이름은 5번이지만 숫자에 얽매일 필요는 없습니다.
보통 다섯 번쯤 물으면 뿌리에 닿더라는 경험에서 붙은 이름일 뿐, 세 번에 끝나도 일곱 번이 필요해도 괜찮습니다.
말로만 보면 감이 잘 안 오니, 고전적인 예시 하나를 봅시다.
(문제) 기계가 멈췄다
→ (Why 1) 퓨즈가 끊어져서
→ (Why 2) 부품에 윤활유가 부족해서
→ (Why 3) 오일 펌프가 안 돌아서
→ (Why 4) 펌프 입구가 막혀서
→ (Why 5) 거름망이 없어서
=> (Solution) 거름망(필터)을 설치한다.
만약 첫 답인 "퓨즈가 끊어졌다"에서 멈췄다면, 퓨즈만 갈아 끼우고 같은 고장을 끝없이 반복했을 겁니다.
끝까지 파고드니 비로소 진짜 해결책이 보였죠. 이게 5 Whys의 전부입니다.
3. 잘 쓰는 노하우 7가지
여기가 이 글의 핵심입니다. 실제로 5 Whys를 돌릴 때 효과를 가르는 일곱 가지 요령입니다.
① 문제부터 구체적으로 적는다.
"분위기가 안 좋다", "퀄리티가 낮다"로 시작하면 한 발짝도 못 나갑니다.
"최근 3개월 회의가 예정보다 평균 30분 초과했다"처럼 무엇이·얼마나·어떻게인지 숫자와 함께 적고 시작하세요.
출발점이 흐리면 결론도 흐립니다.
② 사람이 아니라 구조를 의심한다.
"담당자가 깜빡했다"로 끝나면 그 사람의 사과로 마무리될 뿐, 다음에 또 터집니다.
"확인할 절차나 체크리스트가 없었다"처럼 시스템 차원까지 내려가야 진짜 해결됩니다.
좋은 근본 원인은 대부분 '사람'이 아니라 '없는 절차'입니다.
③ "왜?" 대신 부드럽게 묻는다.
"왜 그랬어요?"는 본능적으로 추궁처럼 들려서, 회고에서 팀원을 위축시킵니다.
"어쩌다 그렇게 됐을까요?", "조금만 더 들려주세요"로 바꾸면 솔직한 답이 훨씬 잘 나옵니다.
말투만 바꿔도 결과가 달라집니다.
④ 거꾸로 읽어 검산한다.
다 파고들었으면 마지막 원인부터 "~때문에"로 거슬러 올라가 보세요.
"절차가 없어서 → 막판에 몰렸고 → 그래서 늦었다"처럼 인과가 자연스럽게 이어지면 합격입니다.
어딘가 어색하면 그 고리를 다시 보세요.
⑤ 답이 갈리면 가지를 나눈다.
한 단계에서 원인이 두세 개로 갈릴 수 있습니다.
무리하게 하나로 좁히지 말고, 가지를 나눠 각각 끝까지 파보세요. 진짜 원인이 하나가 아닐 때가 많습니다.
⑥ 반드시 '해결책 + 담당 + 기한'으로 닫는다.
근본 원인을 찾고 끝내면 회고가 또 "다음엔 잘하자"로 끝납니다.
"OO가 2주 안에 회의 진행 표준 초안을 만든다"처럼 누가·언제까지를 정해야 비로소 바뀝니다.
⑦ 작은 문제부터 연습한다.
처음부터 거창한 문제에 쓰면 길을 잃기 쉽습니다.
"왜 어제 빌드가 깨졌지?" 같은 작고 명확한 문제로 감을 익힌 뒤 큰 문제로 넘어가세요.
4. 파트별 적용 예시
같은 요령이 파트에 따라 어떻게 쓰이는지 세 갈래로 보여드립니다.
기획 사례 — "신규 기능을 유저가 안 쓴다"
(문제) 신규 기능을 유저가 안 쓴다
→ (Why 1) 버튼을 안 누른다
→ (Why 2) 버튼이 안 보여서
→ (Why 3) 버튼이 너무 작아서
→ (Why 4) 화면이 빽빽해서
→ (Why 5) 많은 기능을 다 넣으려 해서
→ (Why 6) 정보 우선순위를 안 정해서
=> (Solution) 버튼만 키우지 말고(증상), 정보 우선순위를 다시 설계한다(근본).
조직 운영 사례 — "회의가 매번 늘어진다"
(문제) 회의가 매번 늘어진다
→ (Why 1) 즉흥 논의가 끼어서
→ (Why 2) 안건이 사전 공유 안 돼서
→ (Why 3) 안건을 모으는 담당이 없어서
→ (Why 4) 운영 방식 합의가 없어서
→ (Why 5) 회의 진행 표준이 없어서
=> (Solution) 시간만 줄이지 말고(증상), 회의 표준과 사전 안건 공유 절차를 만든다(근본).
사업/운영 사례 — "행사 모객이 목표에 못 미쳤다"
(문제) 행사 모객이 목표에 못 미쳤다
→ (Why 1) 신청 유입이 적어서
→ (Why 2) 홍보 도달이 낮아서
→ (Why 3) 홍보를 3일 전에야 시작해서
→ (Why 4) 홍보물 제작이 막판에 밀려서
→ (Why 5) 준비 일정에 홍보 단계를 고려하지 않아서
=> (Solution) 홍보비만 늘리지 말고(증상), 행사 기획 템플릿에 홍보 일정을 못 박는다(근본).
세 사례 모두 표면 증상(버튼·회의 시간·홍보비)에서 멈추면 임시방편이 되지만, 끝까지 파면 하나같이 '없는 절차'라는 진짜 원인에 닿습니다.
5. 이럴 땐 쓰지 마세요
5 Whys가 만능은 아닙니다.
비밀번호를 자꾸 까먹는 정도의 단순한 문제는 그냥 바로 고치면 되고, 시장 전체가 바뀌는 거대한 문제는 이 도구 하나로 안 풀립니다.
가장 잘 맞는 건 우리 팀이 이해하고 통제할 수 있는, 적당한 크기의 반복 문제입니다.
또 원인이 여러 갈래로 복잡하게 얽혀 있으면, 여러 원인을 펼쳐 보는 피쉬본 다이어그램을 같이 쓰는 게 낫습니다.
5 Whys로 깊게 파고, 피쉬본으로 넓게 보는 조합이죠.
6. 마무리
5 Whys의 진짜 가치는 "왜를 5번 묻는 것"이 아니라, 익숙한 답에서 멈추지 않으려는 태도에 있습니다.
다음 회고나 회의 때, 아쉬웠던 일 하나를 골라 작은 것부터 돌려보세요. 종이와 펜만 있으면 됩니다.
참고 자료: 도요타 생산 시스템(TPS)의 5 Whys 기법, Atlassian Team Playbook 「5 Whys」, Figma Resource Library 「What are the 5 Whys」
