피시본 다이어그램은 관찰 가능한 문제를 머리에 두고 가능한 원인을 범주별로 주요 뼈대와 가지에 배치합니다. 이 도구는 원인 이름만 그리지 않고 상위 원인, 근거 상태, 뒷받침 또는 반박 자료, 다음 검증 단계, 담당자까지 남기므로 내보낸 그림이 브레인스토밍에서 멈추지 않고 조사 작업으로 이어집니다.

기본 여섯 범주는 사람, 기계, 자재, 방법, 환경, 측정이며 서비스나 학습, 생활 장면에 맞게 이름을 바꿀 수 있습니다. 이들은 빠진 항목을 찾도록 돕는 힌트일 뿐 반드시 채워야 하는 답이 아닙니다. 그림의 모든 선은 우선 검증할 설명을 뜻하며 이미 입증된 인과를 뜻하지 않습니다.

1. 01머리에 구체적인 문제를 적습니다. 범위와 관찰 기간, 편차를 포함해 예를 들면 "최근 세 번의 과정 프로젝트 단계 제출이 모두 약속 날짜보다 늦었다"처럼 씁니다. "팀 효율이 낮다"처럼 확인할 수 없는 라벨은 피합니다.
2. 02장면에 맞게 범주를 바꿉니다. 학습 문제라면 능력과 지원, 도구와 장비, 자료와 입력, 학습 절차, 시간과 환경, 피드백과 측정을 쓸 수 있습니다.
3. 03가능한 원인을 추가하고 필요하면 상위 원인을 골라 하위 원인 사슬을 만듭니다. 상위 원인을 지우면 하위 항목도 함께 지워지며 한 번에 되돌릴 수 있습니다.
4. 04중요한 설명마다 근거 상태를 기록합니다. 검증 대기 가설, 뒷받침 근거 있음, 근거로 반박됨 중에서 고릅니다. 뒤의 두 상태는 자료를 반드시 채워야 하며, 뒷받침 근거가 다른 설명을 배제한다는 뜻은 아닙니다.
5. 05어떻게 검증하거나 반박할지, 누가 확인할지 적습니다. 피시본은 PNG 또는 SVG로, 검증 목록은 Markdown 또는 CSV로 내보내고 JSON은 전체 복원에 씁니다.

Kaoru Ishikawa의 품질 관리 저작은 인과 도표를 품질 관리 도구로 체계적으로 소개했습니다. ASQ와 IHI의 방법 설명도 어떤 결과의 가능한 원인을 찾아 정리하는 데 이 도표를 씁니다. 가치는 팀이 설명을 겉으로 드러내고 여러 범주를 훑어 빠진 것을 찾게 하는 데 있으며, 그림을 그린다는 이유만으로 유일한 근본 원인을 발견해 주지는 않습니다.ASQ 방법 설명, IHI 도구 설명

주요 뼈대는 범주를, 가지는 원인이나 더 구체적인 하위 원인을 담습니다. 이 구현은 안정적인 ID가 붙은 부모-자식 참조로 구조를 저장합니다. 캔버스는 범주별 원인 카드를 유지하고 하위 원인에 부모 참조를 표시합니다. 범주를 넘는 부모 참조에는 확인 안내가 뜨는데, 배치만 보고 소속이 확정된 것으로 오해하지 않게 하기 위해서입니다. 순환 참조는 성립하지 않으며 가져오기 단계에서 거부됩니다.

마인드맵과 비교하면 피시본은 하나의 관찰 결과를 둘러싸고 설명을 정리하고, 5 Whys와 비교하면 한 사슬만 파고들지 않고 여러 범주를 가로질러 살피게 합니다. 둘은 함께 쓸 수 있습니다. 후보를 먼저 넓힌 뒤 근거 확인이 필요한 사슬을 고릅니다. 정식 고장 트리 분석과 비교하면 이 도구에는 고장 확률, 논리 게이트 계산, 안전 무결성, 인증 결론이 없습니다.

이런 열린 구조에서 한계도 나옵니다. 참여자는 익숙한 원인을 더 많이 적고, 권위 있는 말을 근거로 삼고, "누가 성실하지 않았다"는 지점에서 멈추기 쉽습니다. 범주와 연결이 실험 설계를 강제하지 않으므로 절차와 정보, 자원, 환경, 반례를 여전히 살펴야 합니다. 피시본을 다 그렸다고 해서 고위험 사건 조사를 대신할 수는 없습니다.

"배포 후 복구 실패" 예시의 문제는 이렇습니다. 사용자가 오래된 초안을 열었더니 빈 화면이 나오고, 데이터가 없는 것인지 복구가 실패한 것인지 구분할 수 없습니다. 방법 범주에서는 버전 간 복구 검증 부족을 제기하고 하위 원인으로 이전 형식 샘플 부족을 둡니다. 기계 범주에서는 저장 공간 제한을, 측정 범주에서는 오류 안내 부족을 검토합니다. 각 가설은 점검 행동으로 이어집니다. 예를 들어 이전 릴리스 보관본으로 복구 과정을 재현해 보는 식이며, 특정 개발자가 원인이라고 바로 선언하지 않습니다.

"학습 과제가 반복해서 밀림" 예시는 과제 분할, 자료 도착 시점, 업무와 돌봄 일정, 피드백 방식을 나눠 봅니다. 쓸 수 있는 시간과 제출물을 함께 대조하면 설명이 달라질 수 있고, 학습 시간만 세어서는 이해가 충분한지 판단할 수 없습니다.

문제: 오래된 초안을 열면 빈 화면이 나온다
범주: 방법
상위 원인 r1: 버전 간 복구 검증 부족
하위 원인 r2 → r1: 이전 버전 데이터 샘플 부족
상태: 검증 대기 가설
검증: 과거 릴리스 샘플을 확인하고 복구 과정을 재현
담당자: 테스트 리드

• 원인은 최대 80개, 부모-자식 구조는 20단계, 이름을 바꿀 수 있는 범주는 여섯 개입니다.

• 기본 범주가 모든 업종에 맞지는 않으므로 이름은 조정할 수 있지만, 이 페이지는 임의의 그래픽 편집기를 제공하지 않습니다.

• 원인과 문제가 길면 캔버스가 커지고 PNG 비율이 낮아질 수 있습니다. SVG는 벡터 디테일을, JSON은 편집 가능한 구조를 유지합니다.

• "근거로 반박됨"은 사용자가 기록한 판단이며 도구가 자료를 자동 검증하지 않습니다. 그림을 깔끔하게 만들려고 반박 기록을 지우면 안 됩니다.

• 근본 원인을 자동 식별하거나 확률을 추론하거나 인과를 검증하는 기능은 없습니다.

• 의료, 산업 안전, 법적 책임 사안은 자격을 갖춘 담당자가 해당 공식 절차에 따라 처리해야 합니다.

해결책을 원인 자리에 그대로 넣지 마세요. "교육이 필요하다"는 어떤 능력 부족을 관찰했는지 말해 주지 않습니다. 증상을 다시 서술한 것을 설명으로 삼아도 안 됩니다. "마감을 못 맞춰서 늦었다"가 그런 예입니다. 자료로 뒷받침하거나 반박할 수 있는 구체적인 메커니즘을 먼저 세우고 점검 행동을 정하세요.

여섯 범주를 균형 있게 채우려고 근거 없는 원인을 넣지 마세요. "사람" 범주에서는 지원과 인수인계, 역량 조건을 다룰 수 있지만 책임 추궁 칸이 되어서는 안 됩니다. 다른 설명과 반례를 남기고, 어떤 결과가 나오면 현재 가설이 힘을 잃는지 기록하세요.

• 소프트웨어 회귀 조사, 서비스 대기 시간, 과정 프로젝트 지연, 반복 재작업, 일상 절차 회고에 맞습니다.
• 이미 행동이 분명하면 행동 매트릭스를, 해결책을 비교해야 하면 의사결정 매트릭스를 사용합니다.
• 고위험 사건은 이 페이지의 출력만으로 최종 처리할 수 없습니다.

원인 정리와 그리기, 내보내기는 브라우저에서 끝나며 계정 동기화를 제공하지 않습니다. 자동 저장은 백업이 아니고 브라우저 정리로 사라질 수 있습니다. 공유 링크에는 암호화되지 않은 문서 전체가 담기며 가진 사람은 누구나 읽을 수 있습니다. 8 KB를 넘으면 JSON 파일로 전환하세요. 조사 기록에는 개인정보나 고객 정보가 섞이기 쉬우니 먼저 익명화하고 원본 민감 자료를 링크에 넣지 마세요. 가져오기에 실패해도 현재 작업이 교체되지 않습니다.

• Kaoru Ishikawa, Guide to Quality Control, Asian Productivity Organization, 1986: 품질 관리와 인과 도표에 관한 저자 저작.
• ASQ: 피시본 다이어그램: 가능한 원인과 범주, 작도 과정에 대한 기관 방법 설명.(열람일: 2026-09-22)
• IHI: 특성 요인도: 개선 활동에서 인과 도표를 쓰는 방식. 이 도구의 출력을 의료나 안전 인증으로 볼 수는 없습니다.(열람일: 2026-09-22)