PSM Audit Finding 발생 시 가장 흔한 오류는 무엇인가요?

가장 흔한 오류는 지적사항(Finding) 자체만 수정하고 종료하는 것입니다. 예를 들어 점검 기록이 누락되었을 때 기록만 보완하고 끝내면, 왜 기록이 누락되는지에 대한 근본 원인을 찾지 못해 다음 감사에서 동일한 문제가 반복될 가능성이 높습니다.

Audit Finding과 Root Cause의 차이는 무엇인가요?

Audit Finding은 감사자가 확인한 문제의 결과(예: 점검기록 누락)를 의미하며, Root Cause는 그 문제가 발생하도록 만든 구조적인 원인(예: 점검 책임 불명확, 절차 미흡)을 의미합니다. Finding 자체가 Root Cause는 아닙니다.

근본원인분석(RCA)의 목적은 무엇인가요?

근본원인분석의 목적은 단순히 문제가 발생한 이유를 설명하는 데 그치지 않고, 동일하거나 유사한 문제가 다시 발생하지 않도록 구조적인 해결책을 마련하는 데 있습니다.

PSM 감사지적사항(Audit Finding)의 근본원인(Root Cause) Analysis 방법

Q: Audit Finding을 관리하는 올바른 절차는 어떻게 되나요?

Audit Finding은 'Finding 확인 → 직접원인(Immediate Cause) 확인 → 근본원인(Root Cause) 분석 → 시정조치(Corrective Action) → 효과성 확인(Effectiveness Verification)'의 흐름으로 관리해야 합니다.

Analyst 2026년 9월 1일 최종 수정 8월 30일 읽는 시간 약 16분

PSM 자체감사(PSM Audit)를 수행하면 절차서 미준수, 점검기록 누락, 교육 미실시, 변경관리 미이행, 설비점검 미흡 등 다양한 지적사항(Audit Finding)이 발생합니다.

이때 가장 흔한 오류는 지적사항 자체만 수정하고 종료하는 것입니다.

예를 들어 감사에서

“정기점검 기록이 일부 누락됨”

이라는 지적이 나왔을 때 누락된 기록을 뒤늦게 작성하거나 양식만 보완하면 해당 지적은 형식적으로 종료할 수 있습니다.

하지만 왜 기록이 반복적으로 누락되는지 원인을 찾지 않으면 다음 감사에서 동일한 문제가 다시 발생할 가능성이 높습니다.

따라서 Audit Finding은

Finding 확인 → 직접원인(Immediate Cause) 확인 → 근본원인(Root Cause) 분석 → 시정조치(Corrective Action) → 효과성 확인(Effectiveness Verification)

의 흐름으로 관리하는 것이 중요합니다.

1. Audit Finding과 Root Cause의 차이

감사지적사항(Audit Finding)은 감사자가 확인한 문제의 결과입니다.

근본원인(Root Cause)은 그 문제가 발생하도록 만든 구조적인 원인입니다.

구분	의미	예시
Audit Finding	감사에서 발견된 문제	점검기록 누락
Immediate Cause	직접적으로 문제가 발생한 원인	담당자가 기록하지 않음
Root Cause	반복발생을 가능하게 만든 구조적 원인	점검책임 불명확, 절차 미흡
Corrective Action	원인을 제거하기 위한 조치	책임자 지정 및 전산관리
Verification	조치 효과 확인	3개월간 누락 여부 확인

따라서 Finding 자체가 Root Cause는 아닙니다.

2. Root Cause Analysis의 목적

근본원인분석(Root Cause Analysis, RCA)의 목적은 단순히 문제가 발생한 이유를 설명하는 데 있지 않습니다.

동일하거나 유사한 문제가 다시 발생하지 않도록 원인을 제거하는 것이 목적입니다.

잘못된 접근	올바른 접근
누락된 문서 작성	누락이 발생하는 관리체계 개선
작업자 재교육	왜 교육이 안 됐는지 원인 확인
담당자 주의조치	책임·절차·시스템 문제 확인
양식 수정	양식 오류의 발생원인 확인
감사 Close가 목적	재발방지가 목적

3. Finding을 정확하게 정의

Root Cause Analysis를 시작하기 전에 먼저 지적사항을 명확하게 정의해야 합니다.

Finding이 너무 포괄적이면 원인분석도 모호해집니다.

예를 들어

“설비관리 미흡”

이라는 표현은 너무 넓습니다.

다음처럼 구체적으로 작성하는 것이 좋습니다.

불명확한 Finding	구체적인 Finding
설비관리 미흡	P-101 Pump의 정기점검 3개월 기록 누락
교육관리 부적정	신규작업자 5명 중 2명의 PSM 교육 미실시
MOC 관리 미흡	배관 변경 2건이 MOC 절차 없이 수행됨
SOP 미준수	Reactor Start-up 시 Pre-Start Checklist 미작성

Finding이 구체적일수록 Root Cause를 찾기 쉬워집니다.

4. 사실(Fact)과 추정(Assumption)을 구분

RCA에서는 처음부터 원인을 단정하면 안 됩니다.

예를 들어

“담당자가 업무를 소홀히 했다.”

라는 표현은 사실이 아니라 추정일 수 있습니다.

구분	예시
Fact	점검기록 3건 누락
Fact	점검일정 알림기능 없음
Fact	점검 담당자 변경 후 인수인계 기록 없음
Assumption	담당자가 관심이 없었음
Assumption	업무태도가 불량했음

근본원인은 확인 가능한 사실을 기반으로 분석해야 합니다.

5. Immediate Cause와 Root Cause를 구분

감사 지적에 대한 분석에서 가장 많이 발생하는 오류가 직접원인(Immediate Cause)을 근본원인으로 사용하는 것입니다.

예를 들어 점검 누락이 발생했다면

“담당자가 점검을 하지 않았다.”

는 직접원인입니다.

Root Cause는 그보다 한 단계 더 깊게 들어가야 합니다.

단계	원인
Finding	점검기록 누락
Immediate Cause	담당자가 점검을 수행하지 않음
Intermediate Cause	일정관리 미흡
Root Cause	점검주기 자동관리 체계 없음
Root Cause	담당자 변경 시 업무이관 절차 없음

6. 5 Why 분석방법

PSM Audit Finding의 원인분석에서 가장 간단하게 적용할 수 있는 방법이 5 Why 분석(5 Why Analysis)입니다.

문제에 대해 “왜?”라는 질문을 반복하여 구조적인 원인까지 접근합니다.

예를 들어 정기점검 누락 사례를 보면 다음과 같습니다.

단계	질문	답변
Why 1	왜 점검기록이 누락됐는가?	담당자가 점검하지 않음
Why 2	왜 점검하지 않았는가?	점검일정을 놓침
Why 3	왜 일정을 놓쳤는가?	일정 알림체계가 없음
Why 4	왜 알림체계가 없는가?	개인 일정표로 관리
Why 5	왜 개인관리 방식인가?	공식 점검관리 시스템이 없음

이 경우 Root Cause는 담당자 실수보다 점검일정을 통합관리하는 시스템이 없는 것에 가깝습니다.

7. 5 Why 적용 시 주의사항

5 Why는 간단하지만 질문 방향에 따라 결과가 달라질 수 있습니다.

주의사항	설명
사람 탓으로 종료하지 않음	“담당자 실수”에서 멈추지 않음
사실 기반	확인된 자료를 이용
한 가지 원인만 고집하지 않음	복수 Root Cause 가능
질문을 억지로 5번 하지 않음	필요하면 3회 또는 7회 가능
관리체계까지 확인	절차·책임·시스템 검토

5 Why의 목적은 숫자 5를 맞추는 것이 아니라 재발을 막을 수 있는 수준까지 원인을 찾는 것입니다.

8. Fishbone Diagram 활용

문제가 복잡하거나 여러 부서가 관련된 경우에는 특성요인도(Fishbone Diagram) 방식으로 원인을 분류할 수 있습니다.

PSM Audit에서는 다음과 같은 분류가 유용합니다.

분류	확인내용
사람(People)	교육, 경험, 업무량
절차(Procedure)	절차서, 기준, 승인체계
설비(Equipment)	시스템, 장비, 계측기
관리(Management)	책임, 감독, KPI
문서(Document)	양식, 기록, 버전관리
환경(Environment)	작업조건, 조직변경
시스템(System)	전산관리, 알림, 인터페이스

한 가지 Finding이라도 여러 요인이 동시에 존재할 수 있습니다.

9. 절차(Procedure) 문제 확인

PSM Audit Finding의 Root Cause 중 절차 문제가 자주 나타납니다.

절차 관련 문제	확인사항
절차서 없음	업무기준 존재 여부
절차가 모호함	누가·언제·어떻게 명확한지
실제 업무와 불일치	현장 적용 가능성
책임자 불명확	담당자와 승인자 구분
예외상황 미정의	긴급·비정상 상황
최신화 미흡	설비·조직 변경 반영 여부

단순히 절차서가 존재하는 것보다 실제 업무가 절차에 따라 수행될 수 있도록 구체적으로 작성되어 있는지가 중요합니다.

10. 교육(Training) 문제 확인

Finding의 원인을 교육부족으로 판단하는 경우가 많습니다.

하지만 모든 문제를 교육으로 해결하려 하면 같은 문제가 반복될 수 있습니다.

확인사항	질문
교육 실시 여부	실제 교육을 받았는가
교육내용	해당 업무가 포함됐는가
이해도	교육 후 이해 여부를 확인했는가
현장적용	실제 업무에서 적용 가능한가
반복교육	주기적 교육이 필요한가
신규자 관리	전입·신규자 교육체계가 있는가

교육 미흡은 Root Cause가 될 수 있지만, 왜 교육이 누락됐는지까지 확인해야 합니다.

11. 책임과 역할(Role & Responsibility) 문제 확인

업무가 반복적으로 누락된다면 책임체계가 불명확한 경우가 많습니다.

확인항목	문제 예시
담당자	누가 수행하는지 불명확
승인자	누가 검토하는지 불명확
대체자	담당자 부재 시 대체자 없음
부서경계	설비팀과 운전팀 책임 중복
인수인계	담당변경 시 전달 누락
KPI	관리성과 측정기준 없음

따라서 RCA에서는 “담당자가 누구인가?”뿐 아니라 “그 사람이 부재하면 누가 책임지는가?”까지 확인하는 것이 좋습니다.

12. 관리감독(Management Oversight) 문제 확인

업무절차가 존재하고 교육도 수행됐는데 동일한 Finding이 반복된다면 관리감독 체계를 확인해야 합니다.

관리감독 항목	확인내용
주기적 검토	관리자 확인 여부
미완료 관리	Overdue 항목 추적 여부
경영층 보고	반복문제 보고체계
KPI	완료율 관리
Audit Follow-up	Close 후 효과 확인
Trend 분석	동일 Finding 반복 여부

Root Cause가 “관리자가 확인하지 않았다”에서 끝나기보다 왜 관리자가 확인할 수 없는 구조였는지까지 분석하는 것이 필요합니다.

13. 시스템(System) 문제 확인

PSM 관리가 개인의 기억이나 Excel 파일에 지나치게 의존하면 업무 누락 가능성이 높아집니다.

시스템 문제	개선방향
개인 일정관리	통합 일정관리
수기대장	전산관리
Due Date 알림 없음	자동 알림
Overdue 확인 어려움	Dashboard 구축
담당자 변경 반영 지연	자동 담당자 변경
자료 분산	중앙문서관리

Root Cause가 시스템 문제라면 재교육보다 관리시스템 개선이 더 효과적인 조치가 될 수 있습니다.

14. 반복 Finding 여부 확인

같은 지적이 이전 감사에서도 발생했다면 매우 중요한 정보입니다.

반복 Finding은 과거 시정조치가 Root Cause를 제거하지 못했을 가능성을 의미합니다.

확인사항	의미
이전 Audit 동일 지적	재발 가능성
유사부서 동일 문제	시스템적 문제
여러 설비에서 반복	절차 문제 가능
담당자 변경 후 반복	인수인계 문제
Close 후 재발	Corrective Action 부적정

따라서 RCA를 수행할 때는 이전 감사결과(Audit History)를 반드시 확인하는 것이 좋습니다.

15. Root Cause를 작성하는 방법

Root Cause는 가능한 한 구체적으로 작성해야 합니다.

좋지 않은 표현	개선된 표현
담당자 실수	정기점검 일정 자동알림 체계 부재
관리 미흡	점검결과 검토책임자 지정 미흡
교육 부족	신규자 업무배치 전 필수교육 절차 미수립
절차 미흡	MOC 대상 판단기준이 절차서에 구체적으로 정의되지 않음
관심 부족	Overdue 업무를 관리자에게 보고하는 체계 부재

Root Cause는 누가 잘못했는가보다 어떤 관리체계가 부족했는가를 설명하는 방식이 좋습니다.

16. Corrective Action과 Root Cause 연결

시정조치(Corrective Action)는 Finding이 아니라 Root Cause를 제거해야 합니다.

예를 들어

Finding: 점검기록 누락

Root Cause: 일정관리 시스템 부재

라면 다음과 같이 연결해야 합니다.

조치	평가
누락기록 작성	임시조치
담당자 재교육	보조조치
점검관리 시스템 구축	Root Cause 개선
자동 Due Date 알림	재발방지
관리자 Overdue 검토	관리감독 강화

Finding을 단순히 수정하는 조치와 재발을 막는 조치를 구분하는 것이 중요합니다.

17. Corrective Action의 수준 구분

Audit Finding에 대한 조치는 다음과 같이 구분할 수 있습니다.

조치 유형	목적	예시
Correction	현재 문제 수정	누락 문서 보완
Corrective Action	원인 제거	절차 개정
Preventive Action	유사 문제 예방	전 부서 확대 적용
System Improvement	관리체계 개선	전산시스템 구축

좋은 Audit Closure는 단순 Correction에서 끝나지 않고 Corrective Action과 필요 시 Preventive Action까지 연결합니다.

18. 효과성 확인(Effectiveness Verification)

시정조치를 완료했다고 바로 Finding을 완전히 종료하는 것은 적절하지 않을 수 있습니다.

조치가 실제로 문제를 해결했는지 확인해야 합니다.

이를 효과성 확인(Effectiveness Verification)이라고 합니다.

확인방법	예시
재점검	3개월 후 점검기록 확인
표본감사	10개 설비 Sample 확인
Trend 분석	Overdue 비율 비교
인터뷰	담당자 이해도 확인
현장확인	절차 실제 적용 여부
재감사	차기 Audit에서 재발 여부 확인

즉,

Action Complete ≠ Effective

입니다.

19. Audit Finding RCA 사례

변경관리(MOC) 누락 사례를 예로 들어보겠습니다.

Finding

배관 재질변경 3건 중 1건이 변경관리(MOC) 절차 없이 수행됨.

단계	분석내용
Immediate Cause	담당자가 MOC 대상이라고 판단하지 않음
Why 1	단순 Replacement라고 생각
Why 2	Replacement와 Change 구분이 불명확
Why 3	MOC 절차에 판단기준이 구체적으로 없음
Why 4	실제 사례 중심 교육자료 없음
Root Cause 1	MOC 대상 판단기준 부족
Root Cause 2	변경판단 검토체계 부재
Corrective Action 1	MOC 판단 Checklist 작성
Corrective Action 2	승인 전 기술검토 단계 추가
Preventive Action	유사 변경사례 전수점검
Verification	6개월간 MOC 누락 여부 확인

이 사례에서 담당자 재교육만 수행하면 동일한 판단오류가 다시 발생할 수 있습니다.

20. PSM Audit Finding의 RCA 관리 정리

PSM Audit Finding의 근본원인분석(Root Cause Analysis)은 감사 지적을 빠르게 Close하는 작업이 아니라 동일한 문제가 반복되지 않도록 관리체계를 개선하는 과정입니다.

전체 흐름은 다음과 같이 정리할 수 있습니다.

단계	주요 활동
①	Finding 명확화
②	사실(Fact) 확인
③	직접원인(Immediate Cause) 확인
④	5 Why 또는 Fishbone 분석
⑤	절차(Procedure) 검토
⑥	교육(Training) 검토
⑦	역할과 책임(Role & Responsibility) 검토
⑧	관리감독(Management Oversight) 검토
⑨	시스템(System) 문제 확인
⑩	반복 Finding 확인
⑪	Root Cause 확정
⑫	Correction 실시
⑬	Corrective Action 수립
⑭	Preventive Action 검토
⑮	담당자(Owner) 지정
⑯	완료기한(Due Date) 설정
⑰	조치 완료
⑱	효과성 확인(Effectiveness Verification)
⑲	재발 여부 확인
⑳	Audit Closure