우리는 일상적으로 어떤 시스템이 “안전하다”고 말한다. 그러나 시스템 안전 공학의 관점에서 이 표현은 단순한 상태의 묘사가 아니라 하나의 주장에 가깝다. 이 주장은 직관이나 경험에 의존해서는 충분하지 않으며, 반드시 체계적인 논리와 객관적인 증거를 통해 뒷받침되어야 한다. 현대의 복잡한 공학 시스템은 단일한 실패 원인으로 설명되지 않으며, 다양한 구성 요소와 상호작용 속에서 예기치 못한 위험이 발생할 수 있다. 따라서 안전은 더 이상 단순히 시험이나 검증으로 “확인”되는 것이 아니라, 설계부터 운영에 이르기까지 전 과정에서 “설명되고 정당화되어야 하는 것”이 된다. 이러한 요구 속에서 등장한 개념이 바로 Safety Case Report (SCR)이며, 이는 안전을 단정하는 문서가 아니라 안전을 주장하고 설득하는 구조로 이해되어야 한다.
Safety Case는 특정 시스템이 주어진 조건과 환경에서 허용 가능한 수준의 안전성을 확보하고 있음을 입증하기 위한 구조화된 논증 체계이다. 이는 단순히 결과를 나열하는 문서가 아니라, 시스템이 안전하다는 주장을 중심으로 그 타당성을 논리적으로 설명하고 이를 객관적인 증거로 뒷받침하는 하나의 일관된 구조를 형성한다. 이러한 구조는 일반적으로 주장(Claim), 논증(Argument), 증거(Evidence)라는 세 가지 핵심 요소로 구성되며, 각각은 서로 긴밀하게 연결되어 안전성에 대한 설득력을 만들어낸다. 즉, 시스템이 안전하다는 결론은 독립적으로 존재할 수 없으며, 왜 그러한 결론에 도달했는지에 대한 명확한 설명과 이를 입증하는 시험 결과, 분석 자료, 검증 기록 등이 함께 제시되어야 한다.
Note.
Claim (주장): 시스템은 안전하다.
Argument (논증): 왜 안전한지에 대한 논리적 설명
Evidence (증거): 테스트 결과, 분석, 검증 데이터 등
이러한 논증 구조는 종종 GSN(Goal Structuring Notation)과 같은 형식을 통해 시각적으로 표현되기도 하며, 이를 통해 복잡한 안전 논리를 보다 명확하게 전달할 수 있다. 그러나 Safety Case의 본질은 단순한 표현 방식이 아니라, 설계 과정 전반에서 형성된 안전에 대한 사고와 판단을 체계적으로 정리하는 데 있다. 이 과정에서 Safety Case는 기술적 사실뿐 아니라 설계자가 전제로 삼은 가정과 시스템의 적용 한계까지 포함하게 되며, 절대적인 안전이 아니라 수용 가능한 위험 수준을 기준으로 안전성을 정의한다. 따라서 Safety Case는 기술적 정확성을 넘어 논리적 일관성과 설득력을 동시에 요구하며, 동시에 우리가 알고 있는 것과 알 수 없는 것의 경계를 드러내는 특징을 갖는다.
Safety Case는 시스템 개발이 완료된 이후에 작성되는 부가적인 문서가 아니라, 개발 과정 전반에 걸쳐 점진적으로 형성되는 산출물이다. 이 문서를 구성하는 데에는 다양한 입력 요소가 필요하며, 그중에서도 시스템 요구사항, 위험 분석 결과, 안전 요구사항, 검증 및 시험 데이터, 운영 개념과 환경 조건 등이 핵심적인 역할을 한다. 이러한 요소들은 각각 독립적으로 존재하는 것이 아니라 서로 긴밀하게 연결되어 하나의 논리 체계를 구성해야 한다. 예를 들어, 특정 위험이 식별되면 그 위험을 줄이기 위한 안전 요구사항이 도출되고, 해당 요구사항이 설계에 반영된 후에는 이를 검증하기 위한 시험과 분석이 수행된다. 이 과정에서 생성된 모든 데이터는 다시 Safety Case의 증거로 사용된다. 결국 Safety Case는 단순한 기록의 집합이 아니라, 위험을 인식하고 이를 통제하려는 일련의 사고 과정이 축적된 결과물이며, 설계를 설명하는 동시에 설계의 방향을 결정짓는 역할을 수행한다.
주요 Input 자료
Safety Case는 다음과 같은 다양한 입력을 기반으로 한다:
시스템 요구사항 (System Requirements)
위험 분석 (Hazard Analysis) FHA (Functional Hazard Assessment) PHA (Preliminary Hazard Analysis) FTA (Fault Tree Analysis) FMEA (Failure Mode and Effects Analysis)
안전 요구사항 (Safety Requirements)
검증 및 시험 결과 (V&V Evidence)
운영 개념 (Concept of Operations, ConOps)
환경 및 인터페이스 정의
이전 시스템 또는 유사 시스템 데이터
이 입력들은 단순히 나열되는 것이 아니라, 하나의 논리적 흐름 속에서 연결되어야 한다.
개발 과정
Safety Case는 다음과 같은 흐름으로 발전한다:
Hazard 식별
Risk 평가 (Severity × Likelihood)
Risk 감소 조치 정의
안전 요구사항 도출
설계 및 구현
검증 및 검증 증거 확보
논증 구조 구성
중요한 점은 Safety Case가 단순히 결과를 정리하는 문서가 아니라, 설계 방향을 결정하는 도구라는 것이다. 좋은 Safety Case는 설계를 설명하는 것이 아니라, 설계를 이끈다.
Safety Case의 구조는 적용되는 산업과 규제 환경에 따라 차이를 보인다. 방산 분야에서는 일반적으로 비교적 유연한 형태의 Safety Case가 사용되며, 프로젝트의 특성에 맞추어 구조가 조정되는 경우가 많다. 이러한 접근에서는 시스템 개요, 위험 목록, 위험 평가 결과, 안전 요구사항, 검증 자료 등이 포함되지만, 이들 간의 논리적 연결이 명시적으로 표현되지 않는 경우도 존재한다. 즉, 다양한 증거가 제시되지만 그 증거들이 어떻게 하나의 안전 주장으로 이어지는지는 독자가 해석해야 하는 경우가 많다.
반면, 철도 분야의 EN50129 표준은 Safety Case의 구조를 매우 엄격하게 정의하고 있으며, 각 구성 요소의 역할과 내용이 명확하게 구분되어 있다. 이 표준에서는 시스템 정의, 품질 관리 보고서, 안전 관리 보고서, 기술 안전 보고서, 위험 로그, 그리고 안전 검증 보고서 등이 체계적으로 구성된다. 특히 철도 분야에서는 Safety Integrity Level(SIL) 개념을 통해 위험을 정량적으로 평가하고, 독립적인 평가 기관의 검토를 통해 안전성을 검증하는 절차가 포함된다. 이러한 구조는 Safety Case를 단순한 문서가 아니라 인증과 승인 과정의 핵심 요소로 만든다.
두 접근 방식의 차이는 본질적으로 안전을 표현하는 방식의 차이로 이해할 수 있다. 방산에서는 다양한 증거를 통해 안전성을 암묵적으로 입증하는 경향이 있는 반면, 철도에서는 명확한 기준과 구조를 통해 안전성을 체계적으로 증명한다. 이는 결국 안전을 “설명하는 방식”의 차이이며, 각 산업의 특성과 요구사항을 반영한 결과라고 볼 수 있다.
Note 정리.
Safety Case는 방산과 철도등 다른 산업에서 다른 접근 방식을 보여준다.
방산 (Defense) Safety Case
방산 분야에서는 일반적으로 다음과 같은 구조를 가진다:
System Overview
Safety Management Plan
Hazard Log
Risk Assessment
Safety Requirements
Verification & Validation Evidence
Residual Risk Assessment
Safety Argument (often implicit or less formal)
특징:
- 유연성이 높다
- 프로젝트마다 맞춤형 구조
- 문서 중심 접근
- 논증 구조가 명시적으로 표현되지 않는 경우도 많음
즉, 방산 Safety Case는 “증거 중심”의 접근이라고 볼 수 있으며, “우리는 충분히 안전하다”를 주장한다.
철도 표준 EN50129
EN50129는 철도 시스템의 안전을 위한 유럽 표준으로, Safety Case 구조를 명확히 정의한다.
주요 구성:
System Definition
Quality Management Report
Safety Management Report
Technical Safety Report
Hazard Log
Safety Validation Report
특징:
- 엄격한 구조와 요구사항
- SIL(Safety Integrity Level) 기반 접근
- 명확한 역할 분리 (Independent Safety Assessor 포함)
- Safety Argument가 더 명시적으로 요구됨
철도에서는 Safety Case가 단순 문서가 아니라 인증을 위한 필수 산출물이며, “우리는 이 기준에 따라 안전함을 증명했다”를 말하고있다.
모든 위험을 완전히 제거하는 것은 현실적으로 불가능하다. 따라서 Safety Case에서는 남아 있는 위험, 즉 Residual Risk를 어떻게 다룰 것인가가 중요한 문제로 등장한다. 위험은 일반적으로 제거, 감소, 그리고 수용이라는 세 단계를 거치며, 이 중 수용 단계에 도달한 위험이 바로 Residual Risk이다. 이러한 위험은 단순히 무시되는 것이 아니라, 명확하게 식별되고 문서화되어야 한다. Hazard Log는 이러한 정보를 체계적으로 관리하는 도구로 사용되며, 각 위험의 상태와 통제 방법, 그리고 수용 여부가 지속적으로 업데이트된다.
Residual Risk를 관리하는 과정에서는 위험이 허용 가능한 수준인지 평가하는 기준이 필요하며, 이 기준은 프로젝트의 특성과 규제 요구사항에 따라 정의된다. 또한 기술적 해결이 어려운 경우에는 운영 절차나 사용자 행동을 통해 위험을 통제하는 방법이 적용되기도 한다. 중요한 점은 이러한 위험을 숨기거나 축소하는 것이 아니라, 명확하게 드러내고 이해 가능한 형태로 전달하는 것이다. 이는 Safety Case가 단순히 안전을 강조하는 문서가 아니라, 위험의 존재를 정직하게 인정하는 문서임을 보여준다.
Note 정리.
Residual Risk는 모든 위험은 다음 세 단계를 거친 후다:
제거 (Elimination)
감소 (Reduction)
수용 (Acceptance)
마지막 단계가 바로 Residual Risk다.
처리 방법
닫히지 않은 위험은 다음과 같이 관리된다:
Hazard Log에 지속적으로 기록
Risk Acceptance 기준과 비교
운영 절차로 통제 (Procedural Mitigation)
사용자 경고 및 제한 조건 명시
여기서 중요한 것은 위험을 숨기는 것이 아니라 명확히 드러내는 것이다.
Safety Case의 또 다른 중요한 기능은 위험에 대한 책임의 경계를 명확히 하는 데 있다. 모든 위험을 설계 단계에서 제거할 수 없기 때문에, 일부 위험은 시스템 사용자나 운영자에게 전달될 수밖에 없다. 이러한 과정은 Risk Transfer라고 불리며, 단순한 책임 회피가 아니라 명확한 조건과 가정을 기반으로 이루어진다. 시스템 설계자는 특정 운영 조건과 사용 방법을 전제로 안전성을 보장하며, 이러한 조건은 문서와 매뉴얼을 통해 명확하게 전달된다.
Risk Transfer를 보면, 모든 위험을 제거할 수 없기 때문에, 일부는 고객에게 전달된다.
이 과정은 다음과 같이 이루어져야한다:
Assumptions 명시
Operating Conditions 정의
Safety Limitations 문서화
사용자 매뉴얼 및 경고 포함
즉, 엔지니어들이 하고자 하는 말은:
“이 조건을 지킨다면 안전합니다. 그러나 이 조건이 깨지면, 위험은 더 이상 우리의 통제 아래에 있지 않습니다.”
이 과정에서 중요한 것은 가정과 제한사항을 명확히 정의하는 것이다. 예를 들어, 특정 환경 조건이나 사용 방식이 유지될 경우에만 안전이 보장된다는 점을 분명히 해야 한다. 만약 이러한 조건이 충족되지 않는다면, 그로 인해 발생하는 위험은 더 이상 설계자의 통제 범위에 속하지 않는다. 이는 안전이 단일 주체의 책임이 아니라, 설계자와 사용자 간에 공유되는 개념임을 의미한다. 따라서 Risk Transfer는 기술적 과정이면서 동시에 책임과 신뢰를 재정의하는 과정이라고 할 수 있다.
“안전은 설계자의 책임이지만, 그 한계는 사용자와 공유된다.”
Safety Case는 단순한 기술 문서가 아니라, 안전에 대한 논리적 설득을 구성하는 체계이다. 이 문서는 시스템이 안전하다는 사실을 선언하는 데 목적이 있는 것이 아니라, 그러한 결론에 도달하기까지의 사고 과정과 근거를 투명하게 드러내는 데 그 의미가 있다. 따라서 우리는 안전을 직관적으로 “믿는” 것이 아니라, 논리와 증거를 통해 “논증”해야 하며, 이 과정 자체가 Safety Case의 본질을 이룬다.
그러나 이 논증은 결코 완전할 수 없다. Safety Case는 언제나 우리가 알고 있는 사실뿐 아니라, 아직 알지 못하는 영역, 그리고 특정 조건 하에서 설정된 가정들을 함께 포함한다. 이러한 불완전성은 결함이 아니라, 오히려 복잡한 시스템을 다루는 데 있어 필연적인 특징이다. 이 점에서 Safety Case는 엄밀한 과학적 접근 위에 서 있으면서도, 동시에 인간의 판단과 한계를 드러내는 인간적인 산출물이라 할 수 있다.
결국 Safety Case는 안전을 고정된 상태로 정의하지 않는다. 시스템과 환경이 끊임없이 변화하는 한, 안전 역시 지속적으로 검토되고 재해석되어야 하는 대상이다. Safety Case는 이러한 변화 속에서 계속해서 수정되고 확장되며, 안전을 단일한 결과가 아닌 지속적인 과정으로 인식하게 만든다. 완벽한 안전이 존재하지 않음에도 불구하고 우리가 Safety Case를 구축하는 이유는 분명하다. 안전은 도달해야 할 종착점이 아니라, 끊임없이 제기되고 검토되어야 하는 질문이기 때문이다.