생산 현장의 근본 원인 분석: 5 Whys와 피시본 실전 활용

By Mirko Peters · 2026-11-11

생산 현장에서 근본 원인 분석을 단계별로 설명합니다. 5 Whys와 피시본 다이어그램을 언제 써야 하는지, 원인을 검증하는 방법, 수치를 활용한 설비 정지 사례까지 다룹니다.

Automatically translated with AI from the original post. Read the English original

근본 원인 분석(RCA)은 문제의 근본 원인을 찾아, 조치가 문제의 재발을 막도록 하는 방법입니다. 생산 현장에서는 보통 5 Whys와 피시본 다이어그램을 사용합니다. 이 글은 오늘 라인의 문제를 해결해야 하고, 그 문제가 다시 생기지 않기를 바라는 생산 관리자를 위한 글입니다. 명확한 실행 절차, 두 도구 중 선택하는 기준, 수치를 활용한 설비 정지 사례, 흔히 저지르는 실수 목록을 제공합니다.

핵심 요약

• 근본 원인 분석은 문제의 근본 원인을 찾아, 증상이 아니라 재발 자체를 막는 조치를 가능하게 합니다.
• 원인과 결과의 연쇄가 명확하면 5 Whys를 사용하고, 여러 원인이 서로 얽혀 있을 수 있으면 먼저 피시본 다이어그램을 사용합니다.
• 모든 Why에 대한 답은 가설이 아니라 관찰된 사실이나 측정 데이터로 뒷받침해야 하며, 조치하기 전에 원인을 검증해야 합니다.
• 파레토 관점에서 손실이 가장 큰 항목부터 시작하고, 병목 공정에 우선순위를 둡니다. 병목에서 잃은 시간은 라인 전체의 손실이 되기 때문입니다.
• 조치의 효과는 문제가 다시 나타나지 않는다는 점검 결과로 입증됩니다. 따라서 이를 작은 PDCA 시험으로 운영합니다.

생산 현장에서 근본 원인 분석이란 무엇입니까?

iSixSigma는 근본 원인 분석을 공정이나 제품 불량의 근본적인 원인을 찾는 방법으로 설명합니다. 먼저 사실에 기반한 문제 정의로 시작할 것을 권장합니다. 여기에는 불량 제품이나 공정, 관찰 내용, 불량 수량, 고객의 설명이 포함됩니다. 관련 글은 Ishikawa diagrams and the 5 whys에서 확인할 수 있습니다.

다음 세 용어는 혼동하기 쉽습니다.

• Containment는 오늘 고객이나 라인을 보호하는 조치입니다. 예를 들어 의심 부품을 선별하는 것입니다. 원인을 제거하지는 않습니다.
• Corrective action은 원인을 제거하는 변경 조치입니다.
• Root cause는 제거했을 때 유사한 조건에서 재발을 막는 원인입니다.

봉쇄 조치만 하면 같은 불량이나 정지가 다시 발생합니다. 검증되지 않은 원인을 두고 바로 시정 조치로 넘어가면 엉뚱한 부분을 고칠 수 있습니다. RCA는 두 단계 사이에서 이 간극을 메웁니다.

5 Whys는 언제 사용합니까?

ASQ 용어집은 Five Whys를 "왜?"를 반복해서 묻는 기법으로 설명합니다. 보통 다섯 번 정도 묻지만, 그보다 적거나 많아도 괜찮다고 합니다. 이 기법을 개발한 사람으로는 도요다 사키치(Sakichi Toyoda)를 꼽습니다. 실무 규칙은 다음과 같습니다.

1. 데이터에 근거한 명확한 문제 정의를 작성합니다.
2. 문제가 왜 발생했는지 묻고, 관찰 가능한 가장 가까운 원인을 기록합니다.
3. 각 답변에 대해 사실에 근거하여 계속 왜라고 묻습니다.
4. 재발을 막을 수 있는 실행 가능한 원인에 도달하면 멈춥니다.
5. 근본 원인을 검증합니다. 이 원인이 문제를 일으키는가, 그리고 이를 제거하면 문제가 사라지는가?
6. 대응책을 적용하고, 후속 측정으로 문제가 재발하지 않는지 확인합니다.

같은 페이지는 각 답변이 "가설이 아닌 관찰된 사실이나 측정 데이터 포인트여야 한다"고 덧붙입니다. 또한 이 방법은 근본 원인이 하나인 선형 인과 연쇄에서 가장 잘 작동하며, 복잡한 문제에는 피시본 다이어그램을 권장한다고 설명합니다.

피시본 다이어그램은 언제 더 적합합니까?

피시본(Fishbone), 즉 이시카와(Ishikawa) 다이어그램은 가설을 그림으로 나타낸 것입니다. "3번 프레스의 쇼트 불량"과 같은 결과는 머리 부분에 두고, 가지는 가능한 원인을 보여 줍니다. 팀은 흔히 가지를 설비, 방법, 자재, 사람, 측정, 환경으로 묶습니다. 이 다이어그램은 팀이 많은 가능한 원인을 한눈에 보고, 어떤 원인을 검증할지 합의하는 데 도움이 됩니다.

iSixSigma는 도구들을 결합하는 명확한 방법을 권장합니다. 먼저 문제 기술서를 작성하고 데이터를 수집합니다. 관찰 가능한 결과를 설명하는 가설을 바탕으로 다이어그램을 만들고, 가장 가능성이 높은 가지에 5 whys를 적용하며, 각 가설에 담당자와 기한을 두고 추적합니다. 또한 브레인스토밍으로 만든 다이어그램에는 기여하지 않는 원인이 자주 포함되며, "조명"처럼 모호한 범주는 실패로 이어지는 경로를 거의 보여 주지 못한다고 경고합니다.

경험 법칙: 하나의 명확한 연쇄만 있다면 5 whys로 충분합니다. 기여할 수 있는 요인이 여럿이거나 팀의 의견이 엇갈린다면 먼저 피시본을 사용합니다.

많은 생산 문제에는 둘 이상의 근본 원인이 작용하고 있습니다. 짧은 정지는 마모된 부품, 누락된 점검, 교육 공백이 동시에 원인이 될 수 있습니다. 근본 원인을 찾았을 때는 하나의 근본 원인을 찾은 것인지, 아니면 모든 근본 원인을 찾은 것인지 자문해 보십시오. 문제를 잘 정의하는 것이 답의 절반입니다. "야간 조 3번 스테이션에서 정지"처럼 좁게 정의한 기술서는 넓은 기술서보다 잠재 원인의 수를 줄여 줍니다. 반복되는 불량의 근본 원인을 찾으려면 양호한 생산 주기와 불량 주기를 비교하고, 무엇이 다른지 나열하십시오. 그다음 검증된 원인마다 시정 조치를 하나씩 적용하여 어느 것이 효과가 있는지 확인하십시오. 이것은 단순한 문제 해결 방식입니다. 사실을 먼저, 가설을 다음에, 조치는 마지막에 둡니다.

현장에서 RCA는 어떻게 수행합니까?

1. 격리. 고객과 라인을 먼저 보호하십시오. 의심 제품을 격리하고 안전한 상태를 복구합니다.
2. 문제 선택. 모든 것을 분석하지 마십시오. 손실을 가장 큰 것부터 작은 순으로 순위화한 파레토 보기를 활용하여 가장 큰 항목을 선택합니다. 먼저 생산량을 제한하는 공정인 병목을 살펴보십시오. 그곳에서 잃은 1분은 라인 전체에서 잃은 시간이지만, 여유 용량이 있는 공정에서 잃은 1분은 아무 비용도 들지 않을 수 있습니다.
3. 데이터로 정의. 무엇, 어디서, 언제, 얼마나, 무엇과 비교하여 그러한가? 숫자로 표현하십시오.
4. 현장을 직접 확인. 일본어로 "실제 장소"를 뜻하는 겐바(gemba), 즉 생산 현장에서 실제 공정을 살펴보십시오. 당시 현장에 있었던 작업자와 이야기하십시오.
5. 후보 원인 찾기. 작업자, 설비 보전, 품질, 감독자로 구성된 부서 간 팀과 함께 5 whys 또는 피시본을 사용하십시오.
6. 검증. 유력한 원인을 시험하십시오. 실제 원인이라면 제거했을 때 결과가 바뀌고, 다시 가져왔을 때 문제가 되돌아와야 합니다.
7. 실행과 확인. 대책을 소규모 시험으로 실행하고 결과를 측정하십시오. PDCA 사이클이 이 단계의 틀을 잡아 주며, A3 보고서에는 전체 과정을 한 페이지에 기록할 수 있습니다.

예시: 한 라인의 가동 중단 시간

이 예시는 가정한 수치를 사용합니다.

4번 라인은 8시간 2교대로 5일간 가동하므로 계획 가동 시간은 80시간입니다. 지난주에는 정지로 14시간을 잃었고, 이는 14 ÷ 80 = 17.5%입니다.

정지의 파레토:

• 센서 오인식: 6.3시간(45%)
• 교체 작업 초과: 4.2시간(30%)
• 자재 대기: 2.1시간(15%)
• 기타: 1.4시간(10%)

가장 큰 두 원인이 손실의 75%를 차지합니다. 팀은 센서 오인식부터 시작합니다.

5 whys.

1. 라인이 왜 멈췄습니까? 센서가 부품 위치를 잘못 인식했습니다.
2. 왜 그랬습니까? 센서 렌즈에 먼지가 있었습니다.
3. 왜 먼지가 있었습니까? 교대 중에 아무도 렌즈를 청소하지 않습니다.
4. 왜 청소하지 않습니까? 청소는 작업자의 표준 작업에 포함되어 있지 않습니다.
5. 왜 포함되어 있지 않습니까? 표준 작업이 센서 설치 전에 작성되었습니다.

근본 원인은 결함 있는 센서가 아니라 표준 작업의 공백입니다. 대책은 교대 시작 루틴에 렌즈 점검을 추가하고 작은 덮개를 설치하는 것입니다.

예상 효과. 이 조치로 센서 정지의 80%를 없앤다면 6.3 × 0.8 = 5.04시간을 줄일 수 있습니다. 새로운 가동 중단 시간은 14 − 5.04 = 8.96시간, 즉 8.96 ÷ 80 = 11.2%입니다. 2주 후 점검을 통해 실제 결과가 예상과 맞는지 확인합니다. 맞지 않으면 팀은 다이어그램으로 되돌아갑니다.

선택한 원인이 올바른지 어떻게 확인합니까?

수정에 투자하기 전에 발견 사항을 먼저 검증하십시오. 다음 두 가지 간단한 질문이 도움이 됩니다.

• 원인이 다르게 파악되었다면 결과도 달라졌을까요?
• 그 원인을 제거하면 비슷한 조건에서 같은 장애가 재발할 가능성은 낮아질까요?

개선 전후의 데이터를 수집하십시오. 좋은 RCA는 측정된 결과와 변경된 표준으로 마무리되며, 그래야 단순한 진화(firefighting)에 그치지 않고 지속적 개선으로 이어질 수 있습니다. 또한 교육이나 도구처럼 해결하지 못한 기여 요인도 따로 기록해 두어 놓치지 않도록 하십시오.

"휴먼 에러"는 신중하게 다뤄야 합니다. 그것은 근본 원인인 경우가 드뭅니다. 작업자가 실수했다면, 프로세스가 왜 그 실수를 허용했는지 물어보십시오. 지침이 명확했는지, 도구가 적합했는지, 시간은 충분했는지를 확인해야 합니다. 그 답은 거의 항상 시스템에 있습니다.

흔한 실수

• 첫 번째 "왜"에서 멈추기. 첫 번째 답은 대개 증상일 뿐입니다.
• 의견으로 답하기. 각각의 "왜"에는 관찰된 사실이나 측정값이 필요합니다.
• 사람 탓하기. 비난은 대화를 끝내고 실제 원인을 가립니다.
• 작은 문제부터 분석하기. 파레토 관점을 사용하고 가장 큰 손실부터 시작하십시오.
• 검증 생략하기. 검증되지 않은 원인은 효과가 없는 조치로 이어집니다.
• 표준을 바꾸지 않기. 표준 작업이 그대로라면 문제는 다시 돌아옵니다.

소프트웨어가 도움이 되는 방법

좋은 분석에는 좋은 데이터가 필요합니다. 소프트웨어는 정지가 발생하는 순간 각 원인을 기록하고, 파레토 차트를 자동으로 만들며, 조치 후 문제가 재발하는지 보여줄 수 있습니다. 이는 RCA의 초기 단계에서 시간을 절약하고, 팀에 기억이 아닌 사실을 제공합니다. 도구가 생각을 대신해 주지는 않습니다. 사람이 여전히 현장(현장 작업장)에 가서 "왜"를 물어야 합니다.

다음 단계

지난주 라인에서 가장 큰 손실을 하나 고르고, 숫자가 포함된 문제 기술서를 작성한 뒤, 당시 현장에 있었던 작업자들과 5 Whys를 진행하십시오. 그다음 소규모 시험으로 원인을 검증하십시오. 이것이 생산 현장에서 근본 원인 분석을 적용하는 실질적인 방법입니다.