피시본 다이어그램: 근본 원인 분석 단계별 가이드 (예시 포함)

문제가 반복될 때, 눈에 보이는 증상만 고치는 것으로는 팀이 바빠질 뿐 더 나아지지 않습니다. 피시본 다이어그램 — 이시카와 다이어그램 또는 특성요인도라고도 불리는 — 은 팀이 무언가를 “고치기” 시작하기 전에 증상과 원인을 분리하도록 강제하는 가장 가벼운 방법입니다. 이 가이드에서는 NeatForge 마인드맵 생성기를 이용해 약 30분 만에 제대로 진행하는 방법을 알려드립니다.

피시본 다이어그램이란 무엇인가

피시본 다이어그램은 옆으로 누운 물고기 뼈대처럼 생겼습니다:

• 물고기 머리는 영향(effect) — 정밀하게 정의된 문제입니다.
• 등뼈는 탐구의 흐름을 나타내는 기준선입니다.
• 큰 뼈는 사전에 확정해 둔 원인 카테고리입니다.
• 작은 뼈는 구체적인 원인이며, 그 아래에 하위 원인이 달릴 수 있습니다.

규율은 바로 큰 뼈에 있습니다. 모든 원인을 반드시 하나의 카테고리에 넣도록 강제하면, 팀이 특정인이 가장 잘 아는 영역만 깊게 파고 나머지를 외면하는 일을 막을 수 있습니다.

1단계: 영향을 정밀하게 정의하기

“매출이 부진하다”는 영향이 아니라 불평입니다. “Q2에 엔터프라이즈 체험판의 유료 전환율이 12%에서 7%로 하락했다”가 영향입니다. 판단 기준은 명확합니다. 정밀한 영향에는 지표, 방향, 기간이 모두 포함되어야 합니다. 이 문장을 맵의 중심 아이디어로 작성해 주세요. 중심이 흐릿하면 이후의 모든 뼈가 흔들립니다.

2단계: 4~6개 카테고리 선택

시스템 전체를 아우르는 카테고리를 고르세요. 교과서에서 그대로 가져오지 마세요:

• 소프트웨어 팀: 사람 · 프로세스 · 도구 · 환경 · 데이터
• 운영·지원: 방법 · 장비 · 재료 · 인력 · 측정
• 마케팅: 오디언스 · 메시지 · 채널 · 타이밍 · 오퍼

적게 하되 정직하게 채운 카테고리 4개가, 하나가 비어 있는 카테고리 7개보다 낫습니다. 카테고리가 많다고 분석이 정교해지는 것이 아닙니다. 비어 있는 큰 뼈는 팀이 그 관점을 진지하게 고려하지 않았다는 신호일 뿐입니다.

3단계: 5 Whys로 원인 도출

각 큰 뼈마다 “왜 이것이 영향에 기여하는가?”라고 물어보세요. 그리고 그 답변에 다시 “왜?”를 최대 다섯 단계까지 반복합니다. 실제 디버깅 세션에서 나온 예시는 다음과 같습니다:

1. 빌드가 간헐적으로 실패한다 (사람) → 왜?
2. 개발자가 전체 테스트를 실행하지 않고 머지한다 → 왜?
3. 전체 테스트에 40분이 걸린다 → 왜?
4. 테스트 스위트가 직렬로 실행된다 → 왜?
5. CI 설정을 담당하는 사람 없음 → 근본 원인: 주인이 없는 인프라

구체적인 수정 방법(테스트 병렬화)보다 소유권의 공백이 더 중요합니다. 누가 CI 설정을 책임지는지 명확하지 않으니 아무도 개선하지 못한 것입니다. 생성기에서는 각 “왜” 단계가 자식 노드가 됩니다 — 더 깊이 들어가려면 Tab을, 같은 수준에서 다음 원인을 추가하려면 Enter를 눌러 주세요.

4단계: 실행 가능한 원인 표시

피시본 하나에서는 보통 15~30개의 후보 원인이 나옵니다. 그중 다음 두 가지 필터를 모두 통과하는 원인에 동그라미를 치세요:

• 증거: 이 원인이 실제로 일어나고 있음을 관찰하거나 측정할 수 있습니다.
• 통제 가능성: 조직 개편 없이 한 분기 안에 팀이 직접 바꿀 수 있습니다.

나머지는 맥락으로 남겨두세요. 지우지 마세요 — 오늘 실행할 수 없는 원인은 다음 회고의 안건이 됩니다. 맵에 남겨두면 잊히지 않고, 다음 분기에 다시 검토할 수 있습니다.

5단계: 수정 전 검증

가장 실행 가능한 원인 두세 개를 고르고 가장 저렴한 검증 방법을 설계하세요. “이것이 정말 원인이라면, X를 바꾸면 Y일 안에 지표가 움직여야 한다”는 형태의 가설을 세워 보세요. 피시본이 만드는 것은 가설이지 판결이 아닙니다. 이 단계를 건너뛰는 팀은 검증되지 않은 가정 하나를 다른 가정으로 교체할 뿐이며, 결국 같은 문제를 반복하게 됩니다.

흔한 실수

• 위원회 쇼: 스무 명이 한 맵을 실시간으로 함께 편집합니다. 더 나은 방식은 세 명이 초안을 만들고, 5분 리뷰, 10분 토론으로 진행하는 것입니다. 모두가 동시에 타이핑하면 깊이가 사라집니다.
• 영향의 표류: 맵이 “전환율이 떨어졌다”에서 시작해 서서히 “모든 게 다 나쁘다”로 변합니다. 큰 뼈가 계속 늘어나면 맵을 나누세요. 문제는 하나씩 다루어야 합니다.
• 비난용 큰 뼈: 한 카테고리에 사람 이름만 가득하다면 비난 맵을 만든 것입니다. 원인을 사람 이름이 아닌 시스템 조건으로 다시 쓰세요. “철수가 리뷰를 안 한다”가 아니라 “필수 리뷰어가 지정되지 않았다”로 표현해 주세요.
• 한 번으로 끝내기: 피시본은 스냅샷입니다. 첫 번째 수정이 배포된 뒤 다시 실행해 어떤 뼈가 실제로 움직였는지 확인하세요. 움직이지 않았다면 가설이 틀렸다는 뜻입니다.

화이트보드가 아닌 브라우저에서 하는 이유

화이트보드에 남긴 사진은 한 달 뒤면 알아보기 어렵고, 사진을 찍은 사람의 휴대폰에만 남습니다. 마인드맵 생성기에서 만든 텍스트 기반 피시본은 회의가 끝난 뒤에도 계속 편집할 수 있고, 문서화를 위해 깔끔한 PNG로 내보낼 수 있습니다. 그리고 모든 것이 로컬에서 실행되므로 고객 데이터가 포함된 장애 회고의 민감한 내용이 제3자 서버를 거치지 않습니다 — 이 점은 사후 분석에서 특히 중요합니다.

더 알아보기

• 마인드맵 템플릿과 예시 10가지 — 기획·학습·의사결정을 위한 복사-붙여넣기 구조 10가지, 5 Whys 변형 포함
• 마인드맵 생성기 사용법 — 레이아웃, 단축키, 가져오기/내보내기 완벽 가이드
• 마인드맵으로 브레인스토밍 — 발산적 사고가 필요할 때 선택하세요