시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.
이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다.
STPA의 단계별 절차
STPA: 시스템 안전분석 - (1) 분석 목적 정의 (현재 글)
STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링
STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별
STPA: 시스템 안전분석 - (4) 손실(Loss) 시나리오 식별
STPA 관련글
시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory, STAMP)
이 포스팅은 2018 3월, Nancy G. Leveson, John P. Thomas가 작성한 "STPA Handbook"을 한국정보통신기술협회(TTA)에서 한글로 번역한 STPA Handbook 한글판 v1.1을 참고하여 작성되었습니다.
분석 목적 정의
분석의 첫 단계는 시스템이 달성해야 할 목적과 안전 목표를 명확히 정의하는 것입니다. STPA에서 분석 목적 정의는 시스템 수준의 손실(Loss)을 식별하고, 시스템 경계를 활용하여 위험을 정의하며, 이를 바탕으로 안전 제약사항(Safety Constraints)을 설정하는 과정으로 이루어집니다.
1. 손실 식별
■ 손실(Loss) 정의
손실(Loss)은 시스템에서 발생할 수 있는 바람직하지 않은 결과로, 인간의 생명, 재산, 환경, 또는 시스템의 기능적 목표에 부정적인 영향을 미치는 사건을 의미합니다. 손실은 단순한 물리적 고장을 넘어 시스템의 기능적 목표를 방해하거나 심각한 위험을 초래하는 상황을 포함합니다.
일반적으로 손실의 특징으로 손실은 단순한 부품과 장치들의 물리적 고장을 의미하는 것이 아닙니다. 다만, 이들 부품과 장치들이 언제든지 불완전한 기능을 수행할 수 있다는 점을 인정하고, 이러한 불완전한 기능 수행에 의해 야기되는 시스템 수순에서의 바람직하지 않은 결과를 모두 손실이라고 정의합니다. 따라서 시스템이 안전하게 작동하기 위해 어떤 결과(손실)를 반드시 방지애햐 하는지를 가장 먼저 정의해야 합니다.
STPA에서의 손실은 부품과 장치들의 제어 실패, 상호작용 문제, 운영 환경 변화 등 다양한 요인으로 발생할 수 있기 때문에, 방지하고자 하는 손실을 정의함으로써, 시스템이 안전하게 작동해야 하는 이유를 명확하게 정의할 수 있게 됩니다.
■ 손실(Loss) 유형
STPA 수행 중 고려할 수 있는 대표적인 손실의 유형은 다음과 같습니다.
- 인명 손실: 차량이 보행자나 다른 차량과 충돌 또는 기타 행위로 인해 운전자, 보행자 또는 탑승자가 부상을 입거나 사망할 수 있습니다.
- 재산 손실: 차량 충돌 또는 기타 행위로 인해 차량 또는 도로 인프라(신호등, 가드레인, 도로 표지판 등)가 파손될 수 있습니다.
- 법적 문제: 차량이 교통법규를 위한하거나, 충돌 사고 발생 시 책임 소재가 불분명하여 법적 분쟁을 야기할 수 있습니다.
- 운행 장애: 차량이 갑자기 멈추거나 기타 행위로 인해 갑자기 시스템이 멈추거나 오작동하여 정상적인 주행이 불가능 해 질 수 있습니다.
- 환경 손실: 차량 제어 오류로 인해 연료가 과다 소모되거나, 배출가스 증가로 환경 오염을 초래할 수 있습니다.
손실 식별 Tip
- 손실 식별에서는 손실이 발생하는 구체적인 사례(시나리오)를 도출해야 합니다. 이는 이후 위험 식별 및 안전 제약 도출의 기반이 됩니다.
- 손실에는 어떤 이해관계자에게든 수용할 수 없는 손실이면 포함될 수 있습니다.
- 손실은 개별 컴포넌트 또는 "인적 오류" 및 "브레이크 오류"와 같은 특정 원인을 참조해서는 안됩니다.
- 손실은 시스템 설계자가 직접 제어하지 않는 환경 측면을 포함할 수 있습니다.
- 명시적으로 제외된 손실과 같이 특별한 고려사항이나 가정을 문서화해야 합니다.
■ 손실(Loss) 식별 절차
- 시스템 주요 목표 확인: 시스템이 정상적으로 작동할 때 달성해야 하는 목표를 정의합니다. 이 목표는 시스템이 존재하는 이유와 운영 목적에 해당한다고 볼 수 있습니다. 예를 들어 인명 손실 관점에서 "차량이 주행 중 다른 차량이나 보행자, 그리고 장애물과 충돌하지 않아야 한다.", 법적 문제 관점에서 "차량이 제한속도를 넘지 말아야 하며, 도로 신호를 위반하지 않아야 한다" 등을 시스템의 주요 목표로 정의 할 수 있습니다.
- 손실 시나리오 도출: 시스템이 정상적으로 작동하지 않거나, 잘못된 운영상황의 조합을 통해 발생할 수 있는 손실 시나리오를 도출합니다. 이는 시스템 설계적 결함이나, 환경적 요인, 운영적 행위들의 잘못된/비정상적 조합으로 인해 초래될 수 있는 모든 잠재적 결과를 포함해야 합니다. 예를 들어 "차량 주행 중 신호를 위반하여 교차로에서 다른 차량 또는 보행자와 충돌", "차량 시스템 조작 중 도로 중앙에서 멈춤" 등이 될 수 있습니다.
- 손실 유형별 정의: 시스템 주요 목표와 손실 시나이로를 이용하여 다음과 같이 손실을 유형별로 정의합니다. 예를 들어 다른 차량 충돌에 의한 인명피해 (인명 손실), 차량 사고에 의한 도로 인프라 손상(재산 손실), 법규 위한에 의한 법적 책임 발생 (법적 문제), 차량 주행 불가 (운행 장애), 배출가스 초과 (환경 손실)
■ 손실 사례
다음 목록은 STPA에서 정의되는 몇가지 손실의 사례입니다.
- L-1: 운전자 생명 손실이나 부상
- L-2: 보행자의 생명 손실이나 부상
- L-3: 탑승객의 생명 손실이나 부상
- L-4: 차량 내/외부 장치 또는 기구들에 대한 손실 또는 손상
- L-5: 임무 손실 (예를 들어 승객 이송, 물류 운송, 차량 모니터링 등)
- L-6: 고객 만족의 손실
- L-7: 민감한 정보 손실
- L-8: 환경 손실
- L-9: 전력 발전 손실
2. 시스템 수준의 위험 식별
■ 위험 및 시스템 정의
위험은 특정한 최악의 환경 조건들의 집합 하에서 손실로 이어질 수 있는 시스템 상태 또는 조건들의 집합을 의미합니다.
또한 시스템이란 몇가지 공통의 목표 또는 목적, 결과를 달성하기 위하여 전체적으로 함께 동작하는 컴포넌트들의 집합을 의미합니다. 시스템은 서브 시스템을 포함할 수 있으며, 더 큰 시스템의 일부일 수도 있습니다.
STPA에서 시스템 수준의 위험 식별은 사고 발생 가능성을 줄이기 위해 시스템이 직면할 수 있는 위험 상태나 조건을 명확하게 정의하는 과정입니다. 이를 통해 손실 예방을 목표로 하며, 시스템 경계를 명확히 설정하고, 시스템 동작 상태를 분석하여 위험 요소를 체계적으로 파악하는 것이 핵심입니다.
■ 시스템과 시스템 경계 식별
시스템 수준의 위험을 정의하기 전에 가장 먼저 시스템과 시스템 경계(System Boundary)를 명확히 해야 합니다. 앞에서 정의한 것처럼 시스템은 특정 목적을 달성하기 위해 상호작용하는 여러 구성 요소(컴포넌트)로 이루어직 복합 구조입니다. 이를 통해 분석 대상이 되는 시스템이 무엇인지, 이 시스템이 어떤 목표를 수행해야 하는지 정의합니다. 다음으로는 시스템 구성 요소(컴포넌트)들을 식별해야 합니다. 시스템이 정상적으로 작동하기 위한 필수 구성요소로는 Controller, Sensor, Actuator 등이 있으며, 이들 구성 요소간 상호작용과 역할을 명확히 이해해야 합니다.
그런 다음 시스템 경계를 설정해야 합니다. 즉, 시스템이 상호작용하는 외부 요소와 내부 요소로 구분하여 경계를 설정하고, 이를 기반으로 해당 시스템에서 발생할 수 있는 최악의 환경 조건이나 손실을 초래 할 수 있는 상태나 조건(위험)을 식별합니다.
■ 시스템 수준의 위험 정의 기준
- 시스템 수준의 위험은 시스템 상태 또는 조건이며, 제어 범위를 벗어난 외부 환경 상태는 해당되지 않습니다. 또한 물리적 컴포넌트의 고장과 같은 상세 컴포넌트 수준의 원인을 나타내서는 안됩니다.
- 위험이 손실로 이어지는 최악의 환경 조건들이 반드시 기술되어야 합니다. 하지만 이러한 환경 조건들이 위험이 항상 손실로 이어지는 것을 의미하지는 않습니다.
- 위험은 예방되어야 할 상태 또는 조건입니다. 즉, 위험은 예방되어야 할 상태로서 시스템이 절대로 진입하지 않았으면 하는 상태이며, 목표 달성을 위해 시스템이 정상적인 상황에서 진입해서는 안되는 상태입니다.
위험 정의 시 전체 시스템 및 시스템 상태를 반드시 언급해야 합니다.
<위험 명세> = <시스템> & <안전하지 않은 상태> & <손실에 대한 링크>
예: H-1: 차량제어 시스템이 차량 정차 상태를 유지하지 못해 갑작스런 차량 움직임으로 탑승객이 부상을 당함
- <시스템> : 차량제어 시스템
- <안전하지 않은 상태> : 차량 정차 상태를 유지 하지 못함
- <손실에 대한 링크> : 탑승객의 부상 등
시스템 수준의 위험을 식별할때 흔히 저지르는 실수
- 위험과 위험 원인을 혼동하지 말아야 합니다. 이를 위해 시스템의 개별 컴포넌트를 언급하지 않도록 해야 합니다. (예: 브레이크 고장 미경고, 운영자 산만함, 엔진 고장, 유압 누출 등)
- 불필요한 세부 사항이 포함되지 말아야 합니다. 일반적으로 시스템 수준 위험이 약 7-10개 이상인 경우 위험을 그룹핑하거나 결합하여 보다 관리하기 쉬운 목록을 만드는 것이 좋습니다.
- 모호하거나 재귀적인 표현을 사용하지 말아야 합니다. 시스템 수준의 위험은 "안전하지 않은"의 의미를 정확히 정의하는 것입니다. 따라서 위험 정의 시, "안전하지 않은", "의도치 않은", "우연한" 등과 같은 표현을 사용하지 않는 것이 좋습니다.
- 모든 위험은 방지되어야 할 시스템 수준의 조건(Condition)을 기술해야 합니다.
3. 안전 제약사항 정의
■ 시스템 수준의 안전 제약사항 정의
시스템 수준의 안전 제약사항은 위험을 방지(궁극적으로는 손실을 방지)하기 위해 충족되어야 할 시스템의 조건(Condition) 또는 동작(Behavior)을 기술합니다.
시스템 수준의 위험이 식별되면 반드시 지켜져야 하는 시스템 수준의 안전 제약사항을 바로 파악할 수 있습니다. 간단히 조건을 뒤집으면 됩니다.
예: SC-1: 차량제어 시스템이 차량 정차 상태를 유지해야 한다.
<위험 명세> = <시스템> & <안전하지 않은 상태> & <손실에 대한 링크>
<안전 제약사항> = <시스템> & <지켜져야 하는 조건> & <손실에 대한 링크>
하나의 안전 제약사항은 하나 이상의 위험을 방지하기 위해 사용될 수 있으며, 여러 안전 제약사항이 하나의 위험과 관련될 수 있고, 각 위험은 하나 이상의 손실을 초래할 수 있습니다.
안전 제약사항은 위험이 발생할 경우 시스템이 손실을 어떻게 최소화해야 하는지도 정의할 수 있습니다.
<안전 제약사항> = 만약 <위험>이 발생하면 <손실을 방지하거나 최소화하기 위해 해야 할 일>
예: SC-1: 탑승객이 승/하차 시 정차 상태를 유지해야 하지 못하는 경우, 탑승객 승하차 상황을 인식하고, 정차 상태를 지속적으로 유지해야 한다.
마치며...
STPA(System-Theoretic Process Analysis)의 첫 번째 단계인 분석 목적 정의는 시스템의 안전성을 보장하기 위한 필수적인 출발점입니다. 이 단계에서 수행되는 손실(Loss)과 시스템 수준 위험(Risk)의 식별은, 이후 모든 안전 분석 과정의 토대가 됩니다. 시스템이 직면할 수 있는 최악의 상황을 고려하고, 그로 인해 발생할 수 있는 손실을 명확히 정의함으로써, 설계와 운영에서의 사고 예방이 가능해집니다.
특히 복잡한 현대 시스템에서는 단순한 고장이 아닌 구성 요소 간의 상호작용과 외부 환경적 요인에 의해 사고가 발생할 수 있습니다. 이러한 특성을 고려한 위험 식별은 시스템 사고(Systems Thinking) 접근법의 핵심이며, 안전 제약(Safety Constraints) 도출을 통해 시스템이 안전하게 작동하도록 제어 구조를 설계하는 데 기여합니다.
분석 목적 정의 단계가 성공적으로 수행될 때, 시스템의 안전 목표가 명확히 설정되고, 위험을 예방하기 위한 효과적인 대책이 마련될 수 있습니다. 이를 통해 시스템의 안정성과 신뢰성을 높이고, 사고 발생 가능성을 최소화하는 체계적인 안전 관리가 가능해집니다. 궁극적으로 이 과정은 인간과 환경을 보호하는 데 기여하며, 안전 중심의 설계 문화를 확립하는 데 중요한 역할을 합니다.
STPA의 단계별 절차
STPA: 시스템 안전분석 - (1) 분석 목적 정의 (현재 글)
STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링
STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별
STPA: 시스템 안전분석 - (4) 손실(Loss) 시나리오 식별
STPA 관련글
시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory, STAMP)
'System Engineering > SE Methodology' 카테고리의 다른 글
| STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별 (0) | 2025.01.31 |
|---|---|
| STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링 (0) | 2025.01.31 |
| TOWS 분석: SWOT 확장으로 전략을 세우는 실질적 도구 (0) | 2025.01.27 |
| SWOT 분석: 강점과 약점을 넘어 기회와 위협을 활용한 전략적 성공 비결 (0) | 2025.01.26 |
| 시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory, STAMP) (0) | 2025.01.20 |