시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory)

Causal Analysis based on System Theory (CAST)

 

이 포스팅은 CAST Tutorial Causal Analysis using System Theory를 기반으로 작성되었습니다.

 

CAST(Causal Analysis based on System Theory)는 STAMP(System-Theoretic Accident Model and Processes)에 기반을 둔 사고 원인 분석 기법입니다. 이는 전통적인 사고 분석 기법(FMEA, FTA 등)으로는 설명하기 어려운 현대 시스템의 복잡성과 비선형적 상호작용을 다루기 위해 설계되었습니다. STAMP 기반 CAST는 사고를 단순히 고장의 결과로 보는 것이 아니라, 시스템 설계와 제어 구조의 실패로 인한 안전 제약(Safety Constraints) 위반으로 간주합니다. 이를 통해 사고 원인을 체계적으로 분석하고 재발 방지 대책을 도출합니다.

 

 

1. 사고 분석 기법의 목표

사고 분석 기법은 사고의 원인을 체계적으로 이해하고, 사고에 영향을 미친 요인을 식별하여 유사한 사고의 재발을 방지하는 전략을 개발하는 데 목적이 있습니다. 이러한 기법은 사고의 왜와 어떻게를 파악하는 데 중점을 두며, 잘못의 책임을 묻는 것에서 벗어나 근본적인 문제를 해결하려 합니다. 

 

1-1. 사고 전체 과정을 이해할 수 있는 프레임워크 제공

• 시스템적 관점: 사고 분석은 시스템 전체를 대상으로 하여, 개별 구성 요소나 사람만을 고립적으로 분석하지 않고 시스템 전체의 동작을 이해하도록 돕습니다.
• 체계적 요인 식별: 사고의 즉각적인 원인뿐 아니라, 조직적, 절차적, 시스템적 약점을 파악하여 보다 광범위한 문제를 발견할 수 있도록 설계됩니다.

1-2. 책임(“누가”)에서 벗어나 원인(“왜”, “어떻게”)에 초점 맞추기

• 비난 회피: 누가 실수했는지에 초점을 맞추기보다, 왜 그런 행동이 이루어졌는지, 어떤 환경적/구조적 요인이 영향을 미쳤는지 분석합니다.
• 예방 지향: 사고의 근본 원인을 파악함으로써, 향후 유사한 사고를 방지할 수 있는 구체적인 대책을 마련합니다.

1-3. 주요 원인 요소 식별

• 행동 분석: 사고에 관여한 개인이나 그룹이 특정 방식으로 행동하게 된 이유를 조사합니다. 여기에는 환경, 절차, 설계 요소 등이 포함됩니다.
• 안전 제어 구조의 약점 파악: 사고를 발생하게 만든 안전 제어 구조(Safety Control Structure)의 취약점을 식별합니다. 예를 들어:
• 불완전한 피드백 루프.
• 부적절하게 설계된 제어 또는 프로세스.
• 부족한 안전 제약 조건.

1-4. 후행적 편견(Hindsight Bias) 최소화

• 객관적 분석: 사고를 단순화하거나, 사후적으로 잘못된 결정을 단정 짓는 것을 방지합니다. 당시의 정보와 상황을 바탕으로 사고를 평가합니다.
• 복잡성 인정: 사고를 불가피한 결과로 간주하기보다는, 다양한 요인들의 상호작용을 이해하고 분석합니다.

반응형

---

2. Hindsight Bias (후행적 편견)

후행적 편견은 사고나 사건이 발생한 후, 그 원인과 과정을 지나치게 명확하게 이해한다고 착각하며, 당시 상황에서의 어려움을 간과하는 인지적 오류를 말합니다. 이는 과거를 돌아보면서 “이렇게 했어야 했다(shoulda), 할 수도 있었다(coulda), 했었어야 했다(woulda)“는 식의 판단으로 나타납니다.

 

2-1. 후행적 편견의 주요 특징

• 문제점을 쉽게 판단: 사고 이후, 사람들이 어디서 잘못되었는지 쉽게 파악하고 “무엇을 했어야 하는지”에 대해 단순화하여 생각하게 됩니다. (예: “그때 멈췄다면 사고를 막을 수 있었을 텐데.”)
• 정보 결핍에 대한 과소평가: 사고 당시 중요한 정보가 누락되었음을 간과하고, 그 정보가 결과적으로 얼마나 중요한지 과장하여 평가하게 됩니다. (예: “그 정보를 왜 놓쳤는지 이해가 안 간다.”)
• 결과 기반 판단: 결과를 알고 나면, 당시의 사람이나 시스템이 마땅히 “예측했어야 한다”고 판단하는 오류를 범합니다. (예: “왜 그 경고 신호를 못 봤을까?”)

2-2. 후행적 편견의 문제점

• 비난 초점: 사고 분석이 “누가 실수했는가”에 집중되어 근본 원인이나 시스템적 문제를 놓치게 만듭니다.
• 학습 방해: 당시의 환경과 상황적 어려움을 간과함으로써 실질적인 개선책 도출을 방해합니다.
• 잘못된 예방책: 단순히 개인의 실수에 초점을 맞추어 구조적 문제를 해결하지 못하고 동일한 사고를 반복할 위험이 있습니다.

2-3. 후행적 편견 극복을 위한 접근법

• 객관적 분석: 당시 이용 가능했던 정보와 상황을 기준으로 사고를 평가합니다. (예: “당시 어떤 제약이 있었는가?“에 초점을 맞춥니다.)
• 시스템적 관점: 개인의 실수보다 시스템 설계, 절차, 상호작용의 약점을 분석하여 근본적인 원인을 파악합니다.
• 미래 예방 초점: “어떻게 하면 같은 문제가 다시 발생하지 않도록 설계할 수 있는가?“라는 질문을 중심으로 개선책을 도출합니다.

---

3. Overcoming Hindsight Bias (후행적 편견 극복하기)

후행적 편견을 극복하려면 사고 분석 과정에서 단순히 실수를 지적하거나, “어떻게 했어야 했는지”를 논하는 데 초점을 맞추는 대신, 사고가 발생한 맥락과 사람들이 특정 방식으로 행동한 이유를 이해하는 데 중점을 두어야 합니다. 아래는 후행적 편견을 극복하기 위한 주요 접근법입니다.

 

3-1. 인간적인 관점 이해하기

사람들은 나쁜 결과를 의도하지 않는다.

누구도 의도적으로 잘못된 결정을 내리거나 나쁜 결과를 초래하려고 일하지 않습니다. 사고 당시 그들이 직면한 복잡성, 딜레마, 불확실성 등을 고려해야 합니다.

 

행동의 맥락 분석

단순히 “어떤 실수를 했는가”를 지적하는 것은 문제 해결에 도움이 되지 않습니다. 사람들이 왜 그렇게 행동했는지, 해당 상황에서 그러한 행동이 어떤 의미를 가졌는지를 이해해야 합니다.

 

3-2. 실수 지적이 아닌 이해 중심의 분석

실수만으로는 문제를 설명할 수 없다.

사람들이 무엇을 잘못했는지 지적하는 것은 사고의 근본 원인을 설명하지 못합니다. 실수에 초점을 맞추는 대신, 사고를 유발한 시스템적, 환경적 요소를 분석해야 합니다.

 

“해야 했던 것” 대신 “왜 했는지”에 초점

사람들이 특정 행동을 선택하게 된 배경, 의사결정 과정, 제공된 정보의 한계 등을 분석하여 그들의 행동이 당시 상황에서 합리적이었는지를 평가해야 합니다.

 

3-3. 사고 조사 보고서 작성 시 고려할 점

행동의 논리 설명

보고서는 사람들이 왜 그렇게 행동했는지를 설명해야 합니다. 단순히 그들의 행동을 “잘못”으로 판단하지 않고, 당시 그 행동이 왜 합리적이라고 판단되었는지를 탐구해야 합니다.

 

재발 방지 대책 제안

사람들이 같은 상황에서 동일한 결과를 피할 수 있도록, 시스템적, 절차적, 혹은 환경적 변화를 제안해야 합니다.

예: 교육 개선, 시스템 설계 변경, 피드백 루프 추가 등.

 

3-4. 후행적 편견 극복의 핵심

• 맥락 이해: 행동이 발생한 당시의 상황과 조건을 이해합니다.
• 객관적 접근: 개인의 잘못을 비난하기보다, 시스템 전반의 약점을 분석합니다.
• 미래 지향: 문제를 해결하고 유사 사고가 재발하지 않도록 예방책을 설계합니다.

---

4. CAST (Causal Analysis based on System Theory) 수행 절차

CAST는 사고의 근본 원인을 체계적으로 분석하고, 시스템 설계와 제어 구조의 약점을 파악하여 안전성을 향상시키는 기법입니다. 이는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)에 기반하며, 사고를 유발한 시스템적 문제를 심층적으로 이해하고 재발 방지책을 도출하는 데 중점을 둡니다. 아래는 CAST의 주요 단계와 세부 내용입니다.

 

4-1. 위반된 시스템 위험과 안전 설계 제약 식별

CAST(Causal Analysis based on System Theory)의 첫 번째 단계는 사고와 관련된 시스템 위험(Hazard)과 안전 설계 제약(Safety Constraints)을 식별하는 것입니다. 이 단계는 사고가 발생한 원인을 이해하고, 시스템의 안전성을 확보하기 위해 필요한 초기 정보를 제공하는 중요한 과정입니다.

 

시스템 위험(Hazard)이란 시스템이 의도된 기능을 수행하지 못하거나, 부정적인 영향을 초래할 가능성이 있는 상황을 말합니다. 이는 안전 제약 조건이 위반될 때 발생하며, 최종적으로 사고로 이어질 수 있습니다. 이러한 시스템 위험은 시스템의 설계, 운영, 또는 외부 환경과의 상호작용에서 발생할 수 있으며, 단순한 구성 요소의 고장이 아니라, 시스템의 상호작용의 실패로 인한 상황을 포함하는 것이 특징입니다.

 

또한 안전 설계 제약(Safety Constraints)이란 시스템이 안전하게 작동하기 위해 반드시 준수해야 하는 규칙 또는 조건을 의미합니다. 이는 시스템 위험을 방지하고, 안전성을 확보하기 위한 상태 또는 조건으로 설계된 제어 구조에 의해 실현되며, 시스템 구성 요소는 이들 제약 조건을 준수해야 함을 전제로 합니다. 따라서 안전 설계 제약은 시스템 위험을 방지하기 위해 정의되며, 이러한 위험이 현실화되지 않도록 시스템을 설계하는 기준이 됩니다. 

• 시스템 위험(Hazard): "무엇이 잘못 될 수 있는가?"를 정의
• 안전 설계 제약: "무엇을 반드시 준수해야 하는가?"를 정의

예시: 자율주행 차량이 보행자를 인식하지 못하고 충돌했다면, “보행자와 충돌하지 않음”이라는 안전 제약이 위반된 것입니다.

 

다음은 식품 안전과 관련된 주요 위험 요소, 이에 따른 안전 제약, 그리고 제약이 위반된 사례를 정리한 내용입니다. 이 분석은 시스템 약점을 파악하고 개선점을 제안하는 데 목적이 있습니다.

Hazard	안전 제약	위반 사례
병원성 박테리아	소비 시점에서 병원성 박테리아가 없는 상태여야 함.	• 사건: 16개 주에서 Salmonella enterica (Typhimurium)의 35개 분리주가 PulseNet에 의해 검출됨. • 의미: 조리, 취급, 저장 과정에서 병원성 박테리아의 오염을 방지하기 위한 절차가 제대로 작동하지 않았음을 나타냄.
금속 또는 이물질	1mm 이상의 금속 또는 기타 이물질이 식품에 포함되어서는 안 됨.	• 사건: 특정 식품에서 1mm 이상의 금속 이물질이 발견됨. • 의미: 생산 공정 중 이물질 탐지 시스템의 실패나 검사 절차의 부재를 나타냄.
독소 물질	아플라톡신(Aflatoxin)의 농도가 20ppb 이하이어야 함 (FDA, 2000).	• 사건: 곡물 샘플에서 20ppb를 초과하는 아플라톡신이 검출됨. • 의미: 저장 환경 관리 실패로 곰팡이 독소가 생성되었음을 시사.

 

 

4-2. 설계된 안전 제어 구조 재구성

CAST(Causal Analysis based on System Theory)에서 설계된 안전 제어 구조(Safety Control Structure)의 재구성은 사고 분석 과정의 핵심 단계 중 하나입니다. 이 단계에서는 시스템이 설계된 대로 작동했는지 평가하기 위해, 시스템의 구성 요소와 제어 구조를 명확히 재구성하고 분석합니다. 이를 통해 사고의 원인을 체계적으로 이해하고, 재발 방지를 위한 개선점을 도출할 수 있습니다.

 

설계된 안전 제어 구조는 시스템의 각 구성 요소(컨트롤러, 센서, 액추에이터 등)가 안전 목표를 달성하기 위해 상호작용하는 방식과 그 역할을 정의한 설계입니다. 이 구조는 시스템의 안정성과 안전성을 유지하기 위해 각 구성 요소가 수행해야 하는 제어 행동(Control Action)과 피드백 루프(Feedback Loop)를 포함합니다.

 

이러한 안전 제어 구조를 재구성하는 목적은 시스템이 설계 의도대로 작동했는지 또는 특정 상황에서 실패 했는지를 평가하는 것입니다. 또한 사고의 원인을 이해하고, 제어 구조에서의 약점을 식별하는 것입니다. 이를 통해 구성 요소 간의 상호작용 및 제어 실패를 파악하여 개선 가능성을 도출할 수 있게 됩니다.

 

(1) 구성 요소의 책임 정의

각 구성 요소(컨트롤러, 센서, 액추에이터 등)가 시스템 내에서 수행해야 할 역할과 요구사항을 명확히 정의합니다.

구성 요소의 책임은 다음을 포함합니다:

• 주요 기능 수행: 설계된 대로 제어 및 감지 작업을 정확히 수행.
• 안전 제약 준수: 시스템 수준의 안전 제약 조건을 위반하지 않도록 설계.
• 정확한 데이터 제공: 다른 구성 요소로 데이터를 전달할 때, 오류 없이 신뢰할 수 있는 정보를 제공.

 

 

예시: 자율주행 차량 시스템에 대한 구성 요소의 책임 정의

• 센서: 주변 환경(보행자, 차량, 장애물 등)을 감지하고 정확한 데이터를 제어 시스템에 전달.

• 제어 시스템: 센서 데이터를 기반으로 차량의 경로를 계획하고, 속도를 제어.

• 액추에이터: 제어 시스템의 명령에 따라 차량을 가속, 감속, 정지.

 

(2) 제어 행동과 피드백 루프

제어 행동(Control Actions)은 시스템 구성 요소가 수행하는 명령이나 작업을 의미하며, 피드백 루프(Feedback Loops)는 시스템이 제어 행동의 결과를 확인하고, 이를 바탕으로 다음 행동을 조정하는 과정을 나타냅니다.

 

제어 행동

각 구성 요소가 다른 구성 요소에 명령이나 정보를 전달하는 과정을 통해 설계된 제어 행동이 안전 제약 조건을 준수하며 작동했는지 확인해야 합니다.

 

 

예시: 자율주행 차량 시스템에서의 제어 행동

• 센서 → 제어 시스템: 보행자 5m 거리에서 감지.

• 제어 시스템 → 액추에이터: 속도를 0으로 줄이기 위한 제동 명령 전달.

 

피드백 루프

구성 요소 간의 상호작용을 통해 시스템의 상태를 지속적으로 확인하고 조정해야 합니다. 만약 피드백 루프가 제대로 작동하지 않으면, 제어 실패로 이어질 수 있습니다.

 

 

예시: 자율주행 차량 시스템에서의 피드백 루프

• 액추에이터 → 제어 시스템: 제동이 성공적으로 이루어졌는지 확인.

• 제어 시스템 → 센서: 차량 정지 후 새로운 환경 데이터 요청.

 

4-3. 구성 요소가 책임을 다했는지 평가

CAST(Causal Analysis based on System Theory)에서 구성 요소의 책임 이행 평가는 사고 발생의 근본 원인을 이해하기 위한 핵심 단계입니다. 이 단계에서는 시스템의 각 구성 요소가 설계된 대로 책임을 수행했는지, 아니면 실패(부적절한 제어 행동)를 제공했는지를 분석합니다. 

 

(1) 설계된 책임 확인

각 구성 요소(컨트롤러, 센서, 액추에이터 등)의 설계된 책임을 명확히 정의합니다. 이때 책임은 시스템 안전 목표를 달성하기 위한 요구사항(Requirements)으로 표현될 수 있습니다.

 

 

예시: 자율주행 차량

• 센서: 주변 환경(보행자, 장애물 등)을 정확히 감지하고 데이터를 제공.

• 제어 시스템: 센서 데이터를 기반으로 경로를 계획하고 차량을 제어.

• 액추에이터: 제어 명령에 따라 정확히 가속, 감속, 정지.

 

(2) 부적절한 제어 행동 분석

구성 요소가 제공한 제어 행동(Control Actions)이 적절했는지 평가하며, 다음 4가지 유형의 부적절한 제어 행동이 사고로 이어질 가능성이 있습니다:

• 명령 실패: 필요한 명령이 전달되지 않음. (예: 센서가 데이터를 전송하지 않음)
• 잘못된 명령: 설계 의도와 다르게 명령이 잘못 전달됨. (예: 제어 시스템이 차량에 잘못된 속도를 명령)
• 명령 누락: 특정 상황에서 명령이 누락됨. (예: 보행자 감지 시 차량 정지 명령이 누락)
• 잘못된 타이밍의 명령: 명령이 너무 이르거나 늦게 실행됨. (예: 차량이 정지 신호를 너무 늦게 받음)

(3) 사고 당시 맥락 분석

구성 요소의 행동을 평가할 때, 해당 구성 요소가 사고 당시 직면했던 환경적, 물리적, 조직적 맥락(Context)을 분석합니다. 구성 요소의 실패는 단순히 기술적 오류뿐만 아니라 외부 조건의 영향을 받을 수 있습니다.

• 환경 요인: 날씨, 조명 조건, 물리적 방해물.
• 조직 요인: 관리자의 부재, 유지 보수 부족, 작업 환경.
• 운영 조건: 작업량 과다, 시간 압박, 재정적 압박.

 

 

예시: 자율주행 차량

• 센서가 빛 반사 또는 악천후로 인해 보행자를 감지하지 못함.

• 공장 관리자가 부재하여 유지 보수가 제대로 이루어지지 않음.

 

(4) 프로세스 모델 결함 분석

구성 요소의 프로세스 모델(Process Model)에서 결함이 있었는지를 분석합니다. 프로세스 모델은 구성 요소가 의사결정을 내리기 위해 사용하는 내부 정보와 상태를 나타냅니다.

 

 

참고: 프로세스 모델 결함 유형:

1. 잘못된 정보: 구성 요소가 부정확한 데이터를 사용.

예: 센서 데이터가 왜곡됨.

2. 정보 누락: 중요한 정보가 전달되지 않음.

예: 보행자 감지 신호가 제어 시스템으로 전달되지 않음.

3. 정보 업데이트 실패: 프로세스 모델이 최신 정보를 반영하지 못함.

예: 차량 속도 변화가 반영되지 않아 잘못된 판단.

4. 모델 논리 결함: 잘못된 논리를 기반으로 결정을 내림.

예: 재테스트 결과만으로 제품을 출하.

 

 

참고: 구성 요소가 책임을 다했는지 평가를 위한 주요 분석 질문 사례

1. 각 구성 요소가 설계된 대로 작동했는가?

2. 부적절한 제어 행동(명령 실패, 누락 등)이 있었는가?

3. 사고 당시 환경적/조직적 맥락이 구성 요소의 실패에 어떤 영향을 미쳤는가?

4. 구성 요소의 프로세스 모델에 결함이 있었는가?

 

4-4. 협조와 의사소통 분석

CAST(Causal Analysis based on System Theory)에서 협조와 의사소통(Cooperation and Communication) 분석은 시스템 내 구성 요소들이 얼마나 효과적으로 상호작용했는지를 평가하는 단계입니다. 이는 사고 발생의 주요 원인 중 하나로, 구성 요소 간 정보 전달이나 협력의 실패가 사고로 이어지는 경우가 많기 때문에 매우 중요합니다.

 

(1) 정보 전달 경로와 메커니즘 분석

시스템 내에서 정보가 어떻게 전달되는지를 조사합니다. 이는 구성 요소 간 정보 흐름이 설계된 대로 작동했는지 확인하는 과정입니다.

 

분석 항목:

• 정보 전달 경로: 센서 → 제어 시스템 → 액추에이터 등.
• 정보 전달 방식: 실시간 데이터, 보고서, 알림 등.
• 정보의 정확성: 전달된 정보가 올바르고 신뢰할 수 있는지 평가.

 

(2) 협조와 책임 분담 분석

구성 요소 간 책임 분담이 명확했는지, 그리고 각 요소가 협력하여 안전 목표를 달성했는지 평가합니다.

 

분석 항목:

• 각 구성 요소의 역할과 책임 정의 여부.
• 다수의 구성 요소가 협력해야 하는 작업에서, 누락된 협력 요소 식별.
• 협조 실패가 사고로 이어진 방식 분석.

 

(3) 의사소통 실패 분석

시스템 내 의사소통 실패가 사고에 어떻게 영향을 미쳤는지 평가합니다. 이는 명령, 경고, 피드백이 정확히 전달되지 않은 사례를 분석하는 단계입니다.

 

분석 항목:

• 정보 누락: 중요한 정보가 전달되지 않음.
• 지연된 전달: 정보가 너무 늦게 전달되어 대응이 지연됨.
• 잘못된 정보: 정보가 왜곡되거나 부정확하게 전달됨.
• 혼란스러운 전달: 메시지의 내용이 명확하지 않거나 잘못 해석됨.

 

(4) 사고 당시 협조와 의사소통의 맥락 분석

의사소통 실패가 발생한 당시의 상황과 환경을 분석합니다. 사고 당시 환경적, 조직적 요인이 의사소통에 어떤 영향을 미쳤는지 평가합니다.

 

분석 항목:

• 시간 압박: 정보가 긴급히 처리되어야 했는지.
• 조직 문화: 협력과 정보 공유를 장려하는 문화가 있었는지.
• 기술적 한계: 의사소통을 지원하는 기술이 충분했는지.

 

 

참고: 협조와 의사소통 주요 분석 질문 사례

1. 정보가 각 구성 요소 간에 정확하고 명확하게 전달되었는가?

2. 정보 전달 과정에서 누락, 지연, 왜곡이 있었는가?

3. 구성 요소 간 협조가 효과적으로 이루어졌는가?

4. 사고 당시의 환경적, 조직적 맥락이 협조와 의사소통에 어떤 영향을 미쳤는가?

 

4-5. 동적 변화와 위험으로의 이동 분석

CAST(Causal Analysis based on System Theory)에서 **동적 변화와 위험으로의 이동 분석(Dynamics and Migration to Higher Risk)**은 사고가 발생하기까지 시스템이 시간이 지나면서 위험성이 높은 상태로 이동한 과정을 이해하기 위한 단계입니다. 이 분석은 시스템이 설계된 안전 상태에서 점진적으로 벗어나, 위험이 증가하는 상황이 어떻게 발생했는지를 파악하고, 이를 방지하기 위한 개선점을 도출하는 데 목적이 있습니다.

 

(1) 동적 변화와 위험으로의 이동 개념

• 동적 변화(Dynamics): 시스템은 외부 환경 변화, 내부 프로세스 조정, 조직적 압박 등으로 인해 시간이 지남에 따라 상태가 변합니다.
• 위험으로의 이동(Migration to Higher Risk): 시스템이 초기 설계된 안전 상태에서 점진적으로 벗어나 더 높은 위험 상태로 이동하는 과정입니다.
• 특징
  • 변화는 서서히 일어나며, 단기간에는 명확히 드러나지 않을 수 있음.
  • 위험성이 증가하지만, 시스템 내에서는 이를 정상 상태로 간주하여 조기에 수정하지 못할 가능성이 있음(Normalization of Deviance).

 

(2) 동적 변화와 위험으로의 이동 분석 절차

(2-1)초기 안전 상태 분석

시스템이 처음 설계된 안전 상태를 정의하고, 이 상태가 어떻게 유지되도록 설계되었는지 확인합니다.

• 시스템 설계 시 정의된 안전 제약.
• 초기 설계에서 적용된 안전 제어 구조.
• 시스템의 피드백 루프와 모니터링 메커니즘.

(2-2) 위험 상태로의 점진적 이동 경로 분석

• 시스템이 시간이 지나면서 안전 상태에서 벗어나 위험 상태로 이동한 경로를 분석합니다.
• 주요 변화가 발생한 시점과 그 원인을 식별합니다.
• 분석 항목
  • 외부 환경 변화: 법규, 경제 상황, 기술적 요구사항의 변화.
  • 내부 조직 변화: 예산 삭감, 인력 부족, 절차 변경.
  • 운영 압력: 생산성 증가 요구, 시간 압박, 재정적 압박.

(2-3) 위험 증가를 감지하지 못한 이유 분석

• 위험 상태로 이동하는 동안, 시스템이 왜 이를 감지하거나 대응하지 못했는지 분석합니다.
• 분석 항목
  • 경고 시스템 부재: 위험 신호를 감지하거나 경고하지 못함.
  • 피드백 루프 실패: 구성 요소 간의 피드백이 충분하지 않거나 부정확.
  • 정상화된 편차(Normalization of Deviance): 점진적인 변화가 위험으로 인식되지 않고, 정상으로 간주됨.

(2-4) 사고 전 상태 평가

• 사고 발생 직전, 시스템의 상태를 평가하고 위험이 어떤 방식으로 현실화되었는지 분석합니다.
• 분석 항목
  • 위험 상태에서 안전 제약이 어떻게 위반되었는지 확인.
  • 사고 직전의 결정이 위험을 증가시켰는지 또는 방지할 기회를 놓쳤는지 평가.

 

 

참고: 주요 분석 질문

1. 시스템이 초기 설계된 안전 상태에서 어떻게 벗어나게 되었는가?

2. 위험 상태로 이동한 주요 요인(외부 압력, 운영 변화 등)은 무엇인가?

3. 위험 증가를 감지하거나 대응하지 못한 이유는 무엇인가?

4. 위험 증가가 사고로 이어지기 직전, 이를 막을 기회는 있었는가?

 

4-6. 재발 방지를 위한 변경 사항 결정

CAST(Causal Analysis based on System Theory)의 마지막 단계 중 하나는 사고의 근본 원인을 해결하고, 유사한 사고가 다시 발생하지 않도록 시스템의 설계, 운영, 관리에 필요한 구체적인 변경 사항을 결정하는 것입니다. 이 단계는 사고로 드러난 시스템적 약점을 개선하고, 안전성을 강화하기 위한 실질적인 방안을 도출하는 데 목적이 있습니다.

 

(1) 사고 원인의 체계적 검토

이전 단계에서 식별된 사고의 근본 원인과 기여 요인을 바탕으로 변경 사항을 도출하며, 시스템 설계, 제어 구조, 운영 환경에서 발생한 약점을 종합적으로 검토합니다.

• 구성 요소의 책임 이행 실패.
• 제어 행동 및 피드백 루프의 부적절함.
• 협조와 의사소통 실패.
• 동적 변화로 인한 위험 증가.

예시: 자율주행 차량 사고에서 센서 데이터 누락이 주요 원인으로 파악되었다면, 센서 데이터의 신뢰성을 높이는 방안을 검토.

 

(2) 변경 대상 영역 식별

변경이 필요한 구체적인 시스템 구성 요소와 영역을 식별합니다.

 

주요 영역

• 설계 개선: 제어 구조를 강화하여 제어 실패를 방지 / 안전 제약 조건이 효과적으로 작동하도록 설계.
• 운영 절차 개선: 작업 매뉴얼 및 프로세스를 재설계하여 실수 가능성 최소화.
• 조직 및 문화 개선: 협력 및 의사소통 체계를 강화하여 팀 간 상호작용 문제 해결 / 사고 예방을 위한 조직 내 안전 문화 조성.
• 기술 개선: 기존 기술의 한계를 보완하거나 새로운 기술 도입.

예시: 항공기 시스템에서 피드백 루프 부족이 사고 원인으로 파악되었다면, 실시간 모니터링 시스템 추가를 검토.

 

(3) 실행 가능한 변경 사항 설계

변경 사항이 실현 가능하고, 시스템 전반에 통합될 수 있는지 검토합니다. 이때 변경 사항은 구체적이고 명확하게 정의되어야 합니다.

 

변경 사항 설계 예시

• 단기 조치: 특정 센서 데이터를 교차 검증하는 소프트웨어 업데이트, 현장 작업자 교육 강화.

• 장기 조치: 시스템 아키텍처 변경, 자동화된 경고 시스템 도입.

 

(4) 변경 사항의 안전성 및 실행 가능성 평가

제안된 변경 사항이 실제로 안전성을 개선하는지, 부작용이 없는지 평가합니다. 그런다음 실행 가능성과 비용, 시간 등을 고려하여 실현 가능한 변경 사항으로 우선순위를 정합니다.

 

평가 요소

• 안전성: 변경 사항이 안전 제약 준수에 어떻게 기여하는가?

• 실현 가능성: 실행에 필요한 자원, 기술, 인력은 충분한가?

• 효율성: 변경 사항이 안전성을 개선하는 데 얼마나 효과적인가?

 

예시: 데이터 교차 검증 시스템 도입으로 비용이 증가하더라도, 사고 예방 효과가 뛰어나다면 우선순위에 포함.

 

(5) 변경 사항 시행 계획 수립

변경 사항을 시스템에 적용하기 위한 구체적인 실행 계획을 수립합니다.

 

계획 내용

• 작업 범위: 어떤 구성 요소와 프로세스가 변경 대상인지 정의.

• 실행 일정: 변경 사항의 단계별 구현 일정.

• 책임 분배: 각 단계별 책임자와 관련 팀 지정.

• 테스트 및 검증: 변경 사항이 시스템에 통합되기 전 안전성을 검증.

 

예시: 공장 설비 개선 계획에서 유지 보수 주기 변경, 새로운 점검 시스템 도입 일정 포함.

 

 

4-7. 개선안 및 권고사항 도출

CAST(Causal Analysis based on System Theory)에서 개선안 및 권고사항 도출은 사고 분석의 마지막 단계로, 사고의 근본 원인을 해결하고 시스템의 안전성을 강화하기 위한 구체적이고 실현 가능한 조치를 제안하는 과정입니다. 

 

(1) 사고 원인에 따른 권고사항 분류

사고 분석 결과에서 도출된 원인을 기반으로 권고사항을 분류합니다. 주요 원인과 관련된 각각의 영역에서 구체적인 개선안을 제시합니다.

 

분류 항목

• 설계 문제: 제어 구조, 피드백 루프, 시스템 상호작용 설계.

• 운영 절차 문제: 작업 매뉴얼, 프로세스 실행, 검사 및 유지보수.

• 조직적 문제: 책임 분담, 의사소통, 협력 체계.

• 환경적 문제: 외부 요인, 예산, 시간 압박.

 

(2) 개선안의 구체화

권고사항은 구체적이고 실현 가능해야 하며, 시스템 내 특정 구성 요소나 절차에 적용할 수 있어야 합니다.

 

개선안 구체화 방법

• 변경 대상: 개선이 필요한 구성 요소, 절차, 조직.

• 개선 방법: 변경 방법과 적용 방식.

• 기대 효과: 권고사항이 적용되었을 때 예상되는 안전성 향상.

 

(3) 실행 가능성 평가

개선안의 실현 가능성과 효과를 검토하여 실행 우선순위를 정합니다.

 

평가 항목

• 안전성: 개선안이 안전성 향상에 기여하는 정도.

• 실행 가능성: 개선안을 구현하는 데 필요한 시간, 비용, 자원.

• 부작용: 개선안이 시스템의 다른 부분에 미칠 수 있는 부정적 영향.

• 지속 가능성: 개선안을 장기적으로 유지하고 관리할 수 있는지 여부.

 

(4) 권고사항 문서화

도출된 개선안을 체계적으로 문서화하여 실행 가능성을 높이고 이해관계자들에게 명확히 전달합니다.

 

문서화 내용

• 권고사항 개요: 사고 원인과 관련된 문제 및 개선안.

• 실행 계획: 개선안을 실행하기 위한 세부 단계.

• 필요 자원: 실행에 필요한 예산, 인력, 기술.

• 우선순위: 가장 시급하고 효과적인 개선안에 대한 강조.

 

(5) 이해관계자와의 협력

권고사항의 실행 가능성을 높이기 위해 이해관계자와 협력합니다. 이를 통해 권고사항의 실현 가능성과 실행 의지를 높이고, 예상되는 장애 요소를 사전에 해결합니다.

 

협력 대상

• 시스템 설계자: 기술적 변경 사항 협의.

• 운영 관리자: 절차 개선 사항 논의.

• 조직 리더십: 정책 및 자원 지원.

 

---

마치며...

CAST(Causal Analysis based on System Theory)는 현대 시스템의 복잡성과 비선형적 상호작용에서 발생하는 사고를 분석하고, 안전성을 강화하기 위한 강력한 도구입니다. 이 분석 기법은 기존의 고장 중심 접근법(FMEA, FTA)과 달리 시스템 사고(Systems Thinking)를 바탕으로 제어 구조, 피드백 루프, 구성 요소 간의 상호작용을 중심으로 사고의 근본 원인을 파악합니다.

 

이러한 CAST는 단순히 사고 원인을 파악하는 기법을 넘어, 시스템의 설계와 운영을 개선하고 안전성을 향상시키는 데 중점을 둡니다. 이를 통해 사고를 예방하고, 시스템의 복잡성이 증가하는 현대 사회에서 안전한 환경을 구축하는 데 중요한 역할을 할 수 있습니다. 향후 시스템의 안전성을 강화하기 위해 CAST를 적절히 활용하여 보다 강력하고 신뢰성 있는 시스템 개발이 이루어질 수 있기를 기대합니다.