우리는 비행기를 타고 이동하거나 열차를 이용할 때 그 시스템이 어떻게 설계되었는지 깊이 생각하지 않는다. 비행기에 탑승한다고 해서 항공기의 안전 분석 보고서를 읽는 사람은 없고, 열차를 탈 때 신호 시스템의 알고리즘을 떠올리는 사람도 거의 없다. 대부분의 사람들에게 시스템이란 단지 문제없이 작동하면 되는 기술일 뿐이다.
그러나 시스템 안전 엔지니어의 시선에서 보면 그 이면에는 전혀 다른 세계가 존재한다. 현대의 기술 시스템은 단순한 기계가 아니라 소프트웨어, 하드웨어, 인간의 운영 절차, 그리고 조직의 의사결정이 서로 얽혀 있는 복잡한 구조다. 이런 환경에서 사고는 보통 하나의 부품 고장으로 발생하지 않는다. 많은 경우 사고는 보이지 않는 가정, 충분하지 않은 위험 분석, 혹은 충분히 검증되지 않은 설계 결정에서 시작된다. 그래서 안전 공학에서는 “이 시스템은 안전하다”라는 말을 쉽게 사용하지 않는다.
안전은 선언이 아니라 하나의 논증(argument) 이기 때문이다. 시스템이 안전하다는 주장이 설득력을 가지려면 위험이 충분히 식별되었는지, 위험을 줄이기 위한 조치가 설계에 반영되었는지, 그리고 그 결과가 실제로 검증되었는지를 확인해야 한다. 바로 이 지점에서 시스템 안전 감사(System Safety Audit)가 등장한다. 시스템 안전 감사는 단순한 문서 확인 절차가 아니라, 한 시스템이 정말로 안전하다고 말할 수 있는지를 독립적인 시각에서 질문하는 과정이다.
내가 근무했던 외국계 엔지니어링 회사에서도 형태만 다를 뿐 내부 시스템 안전 감사와 외부 시스템 안전 감사가 항상 진행된다. 예를 들어 철도 프로젝트에서는 Independent Safety Assessor라는 이름의 외부 평가 기관이 참여해 프로젝트와 시스템 개발 과정에서 생성된 문서와 안전 산출물을 검토하고, 그것이 실제 안전 절차와 기준에 부합하는지 확인한다. 이 과정에서 평가자는 단순히 문서의 존재 여부를 확인하는 것이 아니라, 우리가 구축한 시스템이 정말로 안전하다고 주장할 수 있는지에 대해 질문을 던진다.
결국 시스템 안전 감사는 결함을 찾기 위한 절차라기보다 하나의 질문에서 시작된다. 우리가 만든 이 시스템이 정말로 안전하다고 말할 수 있는가, 그리고 그 주장에 대해 우리는 충분한 근거를 가지고 있는가 하는 질문이다.
시스템 안전 감사(System Safety Audit)는 시스템의 개발과 운영 과정에서 수행된 안전 활동과 안전 분석, 그리고 안전 근거를 독립적으로 평가하는 과정이다. 이 과정의 핵심 목적은 단순히 규정 준수를 확인하는 것이 아니라, 시스템이 안전하다는 주장 자체가 논리적으로 정당한지를 검토하는 데 있다. 다시 말해, 감사는 “안전 활동이 수행되었는가”라는 질문을 넘어서 “그 활동이 실제로 안전을 입증하는가”라는 더 근본적인 질문을 던진다.
예시로,
위험이 체계적으로 식별되었는가
위험을 줄이기 위한 조치가 실제로 설계에 반영되었는가
안전 주장을 뒷받침할 객관적인 증거가 존재하는가
남아있는 위험(residual risk)이 정당하게 수용되었는가
등의 질문들이 존재한다. 이를 위해 감사자는 다양한 안전 산출물을 검토하게 된다. 대표적인 문서들로는
System Safety Program Plan (SSPP)
Hazard Log
Preliminary Hazard Analysis (PHA)
System Hazard Analysis (SHA)
Subsystem Hazard Analysis (SSHA)
Fault Tree Analysis (FTA)
Failure Modes and Effects Analysis (FMEA)
Safety Case 또는 Safety Assurance Report와 같은 문서들이 포함된다.
이러한 문서들은 각각 위험을 식별하고, 위험을 줄이기 위한 조치를 정의하며, 그 조치가 실제로 작동하는지를 설명한다. 그러나 중요한 것은 문서의 개수가 아니라 그 사이의 논리적 구조와 연결성이다. 아무리 많은 안전 문서가 존재하더라도 위험과 통제 조치, 그리고 검증 증거 사이의 연결이 명확하지 않다면 그 시스템의 안전은 충분히 설명되지 않는다. 시스템 안전 감사는 바로 이 논리 구조를 검토하는 과정이라고 할 수 있다.
시스템 안전 감사에서 핵심적인 역할을 수행하는 존재는 Independent Safety Assessor(ISA) 다. ISA는 시스템을 설계하거나 개발한 조직과 독립된 위치에서 해당 시스템의 안전성을 평가하는 전문가 혹은 기관을 의미한다. 여기서 말하는 독립성은 단순히 조직 구조상의 분리를 의미하는 형식적인 조건이 아니라, 안전 평가의 신뢰성을 유지하기 위한 본질적인 요소다. 만약 시스템을 설계하고 구현한 조직이 동시에 그 시스템의 안전성을 판단하게 된다면, 의도하지 않더라도 이해관계가 판단 과정에 영향을 미칠 가능성이 존재한다. 따라서 안전 공학에서는 안전 주장을 검증하는 과정에서 반드시 제3자의 시선이 개입해야 한다고 본다.
ISA의 역할은 단순히 프로젝트 문서를 검토하는 수준을 넘어선다. 그들은 시스템 개발 과정에서 수행된 위험 분석이 충분한 범위와 깊이를 가지고 있는지를 평가하며, 식별된 위험을 줄이기 위한 설계 조치가 실제로 시스템 구조와 운영 절차에 적절히 반영되었는지를 검토한다. 또한 시스템이 안전하다는 주장이 논리적으로 설득력을 가지는지, 그리고 그 주장에 대해 시험 결과나 검증 활동과 같은 객관적인 증거가 존재하는지를 확인한다. 다시 말해 ISA는 시스템이 안전하다는 주장 자체를 그대로 받아들이는 것이 아니라, 그 주장에 담긴 논리와 근거가 독립적인 검증을 견딜 수 있는지를 평가하는 역할을 수행한다.
이러한 평가 과정의 결과는 일반적으로 독립 안전 평가 보고서(Independent Safety Assessment Report) 형태로 정리된다. 이 보고서는 규제기관, 시스템 운영자, 혹은 프로젝트 발주처에게 제공되며, 시스템이 실제 운영 단계로 넘어가기 전에 안전 논증이 충분히 신뢰할 수 있는지 판단하는 근거로 활용된다. 특히 철도, 항공, 방위 산업과 같이 안전 요구 수준이 높은 분야에서는 ISA의 평가가 시스템 승인 과정에서 중요한 역할을 한다.
결국 ISA의 역할은 단순한 검토자가 되는 것이 아니다. 그들은 시스템 안전 논증을 외부의 시각에서 바라보며, 그 논증이 스스로의 주장만으로 성립하는 것이 아니라 객관적인 분석과 증거에 의해 정당화되고 있는지를 확인하는 전문가다. 이러한 독립적인 검증 과정이 존재하기 때문에 시스템 개발 조직이 제시한 안전 주장은 보다 높은 신뢰성을 갖게 된다.
시스템 안전 감사는 일반적으로 체계적인 단계에 따라 수행된다. 먼저 감사의 범위와 목적을 정의하는 단계가 있다. 이 단계에서는 어떤 시스템이 평가 대상인지, 어떤 안전 기준이 적용되는지, 그리고 어떤 안전 산출물이 검토될 것인지가 결정된다. 이 과정은 이후 감사의 방향을 결정하기 때문에 매우 중요하다.
1. 감사 계획 수립
먼저 감사의 범위를 정의한다.
- 어떤 시스템을 평가할 것인지
- 어떤 안전 기준을 적용할 것인지
- 어떤 안전 산출물이 검토 대상인지
이 단계는 전체 감사의 방향을 결정한다.
2. 안전 문서 검토
다음 단계에서는 프로젝트 팀이 작성한 안전 문서를 검토한다.
이때 중요한 것은 단순히 문서가 존재하는지가 아니라 다음과 같은 질문이다.
- 위험 식별이 충분한가
- 위험 통제 조치가 설계에 반영되었는가
- 안전 요구사항이 명확하게 정의되어 있는가
그 다음 단계에서는 프로젝트 팀이 작성한 안전 문서들이 검토된다. 감사자는 위험 식별이 충분히 이루어졌는지, 위험을 줄이기 위한 설계 조치가 실제 시스템 설계에 반영되었는지, 그리고 안전 요구사항이 명확하게 정의되어 있는지를 확인한다. 특히 중요한 부분은 추적성(traceability)이다. 시스템 안전에서는 하나의 위험이 식별되면 그 위험을 줄이기 위한 요구사항이 정의되고, 그 요구사항이 설계에 반영되며, 마지막으로 시험이나 검증 활동을 통해 확인되는 일련의 흐름이 존재해야 한다. 이 연결이 끊어지는 순간 안전 논증은 설득력을 잃기 시작한다.
3. 추적성 확인
시스템 안전에서 가장 중요한 개념 중 하나가 추적성(traceability)이다.
감사 과정에서는 다음의 연결 관계를 확인한다.
위험 → 안전 요구사항 → 설계 조치 → 검증 활동
이 연결이 끊어지는 순간 안전 논증은 무너지기 시작한다.
마지막 단계에서는 안전 주장을 뒷받침하는 증거가 충분한지를 평가한다. 이때 중요한 개념이 바로 Objective Quality Evidence, 즉 OQE다. 시스템이 안전하다는 주장이 단순한 설명이 아니라 실제 시험 결과나 검증 자료와 같은 객관적인 증거로 입증되어야 한다는 의미다. 감사자는 이러한 증거를 검토한 후 관찰 사항과 개선 권고를 포함한 감사 보고서를 작성하게 된다.
4. 증거 평가
안전 주장에는 반드시 객관적 증거가 필요하다. 이를 OQE (Objective Quality Evidence)라고 한다. 예를 들어 다음과 같은 자료들이 OQE가 될 수 있다.
- 시험 보고서
- 검증 결과
- 설계 검토 기록
- 시뮬레이션 분석 결과
- 운영 절차 검증 결과
안전 감사에서 중요한 질문은 이것이다.
“이 시스템이 안전하다는 주장에 대해 실제로 증거가 존재하는가?”
5. 감사 결과 보고
감사 결과는 일반적으로 다음의 형태로 정리된다.
- Observation - Finding
- Non-conformance
- Recommendation
이 결과는 프로젝트 팀에게 개선 활동을 요구하거나 추가적인 분석을 수행하도록 만든다.
내부 안전 감사와 외부 안전 감사
시스템 안전 감사는 수행 주체에 따라 내부 감사와 외부 감사로 구분된다. 내부 안전 감사는 시스템을 개발하거나 운영하는 조직 내부에서 수행되는 감사 활동이다. 이러한 감사는 주로 프로젝트 진행 과정에서 안전 활동이 제대로 수행되고 있는지를 확인하고, 잠재적인 문제를 조기에 발견하기 위한 목적으로 이루어진다. 내부 감사의 가장 큰 장점은 신속한 피드백이다. 프로젝트 팀은 발견된 문제를 즉시 수정하고 안전 활동을 개선할 수 있다.
Note. 정리
내부 감사는 조직 내부에서 수행되는 안전 점검이다. 주로 다음과 같은 목적을 가진다.
안전 프로세스 준수 여부 확인
위험 관리 활동 점검
프로젝트 진행 중 문제 조기 발견
내부 감사의 장점은 빠른 피드백이다. 문제를 조기에 발견하고 개선할 수 있기 때문이다. 그러나 한 가지 한계가 있다. 같은 조직 안에서 수행되는 감사는 무의식적인 편향을 완전히 피하기 어렵다.
반면 외부 안전 감사는 조직 외부의 독립적인 기관이나 전문가에 의해 수행된다. 여기에는 규제기관, 인증기관, 그리고 Independent Safety Assessor가 포함될 수 있다. 외부 감사의 가장 큰 특징은 객관성이다. 외부 평가자는 시스템 개발에 직접 관여하지 않았기 때문에 보다 중립적인 관점에서 안전 논증을 평가할 수 있다. 많은 안전 산업에서 시스템을 실제 운영에 투입하기 전에 외부 안전 평가가 요구되는 이유도 바로 이러한 객관성을 확보하기 위함이다.
Note. 정리
외부 감사는 독립적인 기관이나 평가자가 수행한다. 대표적으로 다음과 같은 조직이 참여할 수 있다.
규제기관
인증기관
Independent Safety Assessor
외부 감사의 가장 큰 장점은 객관성이다. 개발 조직과 이해관계가 없기 때문에 더 강한 질문을 던질 수 있다. 많은 안전 산업에서 시스템 운영 이전에 외부 안전 평가가 요구되는 이유도 여기에 있다.
시스템 안전에서 OQE, 즉 Objective Quality Evidence는 매우 중요한 개념이다. OQE는 시스템이 안전하다는 주장을 뒷받침하는 객관적이고 검증 가능한 증거를 의미한다. 예를 들어 단순히 “분석 결과 시스템이 안전하다”고 서술하는 것은 충분한 증거가 되지 않는다. 반면 특정 시험 보고서가 존재하고 그 보고서가 시스템이 정의된 조건에서 안전 요구사항을 만족한다는 것을 보여준다면 그것은 강력한 OQE가 된다. 예시로, “Verification Test Report VTR-045에 따르면 비상 정지 기능은 모든 시험 조건에서 200ms 이내에 작동하였다.” 이러한 문장들은 강한 증거가 된다.
이러한 증거는 시험 결과, 검증 보고서, 설계 검토 기록, 시뮬레이션 분석 자료, 운영 절차 검증 결과 등 다양한 형태로 존재할 수 있다. 중요한 것은 이러한 자료들이 안전 요구사항과 명확하게 연결되어 있어야 한다는 점이다. OQE는 단순한 문서가 아니라 안전 논증을 실제 사실과 연결시키는 다리라고 볼 수 있다.
차이는 명확하다.
시스템 안전 감사는 매우 중요한 안전 보증 활동이지만 동시에 몇 가지 한계를 가지고 있다.
첫째, 감사는 안전을 보장하지 않는다. 감사의 목적은 시스템이 안전하다는 주장을 검증하는 것이지, 그 시스템이 미래에도 절대적으로 안전할 것이라고 보증하는 것은 아니다. 감사자는 안전 논증의 논리와 근거를 평가할 수는 있지만, 실제 운영 환경에서 발생할 수 있는 모든 상황이나 사고를 미리 예측하는 것은 불가능하다. 따라서 감사 결과는 안전에 대한 신뢰도를 높이는 역할을 할 뿐, 절대적인 보장을 제공하는 것은 아니다.
둘째, 감사는 제공된 정보에 의존한다. 감사자는 시스템 개발 과정에 직접 참여하지 않기 때문에 프로젝트 팀이 제공한 문서, 분석 결과, 시험 자료와 같은 증거를 중심으로 평가를 수행한다. 만약 중요한 정보가 기록되지 않았거나 제공되지 않았다면 감사의 범위 역시 자연스럽게 제한될 수밖에 없다. 이러한 이유로 안전 감사의 품질은 결국 프로젝트 팀이 얼마나 투명하고 체계적으로 정보를 기록하고 공유했는지에 크게 영향을 받는다.
셋째, 감사는 조직 문화를 완전히 평가하기 어렵다. 문서와 절차만으로는 실제 조직 내부에서 안전이 어떻게 다뤄지고 있는지 모두 파악하기 어렵기 때문이다. 안전 문화가 취약한 조직에서도 형식적으로는 매우 정교한 문서를 작성하는 것이 가능하다. 그러나 설계 과정에서 위험이 충분히 논의되지 않았거나 안전 문제가 적극적으로 제기되지 않는 환경이라면, 아무리 완성도 높은 문서라도 실제 상황을 충분히 반영하지 못할 수 있다. 그래서 때로는 이런 말이 나오기도 한다.
문서는 완벽했지만 사고는 발생했다.
시스템 안전 감사는 이러한 위험을 줄이기 위한 중요한 도구이지만, 그것만으로 모든 문제를 해결할 수는 없다.
시스템 안전 감사는 겉으로 보기에 많은 문서를 검토하고 보고서를 작성하는 복잡한 절차처럼 보일 수 있다. 그러나 그 핵심은 매우 단순하다. 그것은 한 시스템이 안전하다는 주장에 대해 독립적인 시각에서 질문을 던지고, 그 주장이 충분한 근거와 증거에 의해 뒷받침되고 있는지를 확인하는 과정이다. 위험이 제대로 식별되었는지, 그 위험을 줄이기 위한 조치가 설계와 운영에 반영되었는지, 그리고 그 조치가 실제로 효과적으로 작동한다는 것을 설명할 수 있는지가 이 과정의 중심이 된다.
결국 시스템 안전 감사의 목적은 단순히 문서를 확인하거나 결함을 찾는 데 있지 않다. 그보다 중요한 것은 시스템이 안전하다는 주장에 대해 스스로 납득할 수 있는 수준의 설명과 책임이 존재하는지를 확인하는 일이다. 안전은 단순한 선언이 아니라 논증이며, 그 논증은 반드시 명확한 근거와 함께 제시되어야 한다. 시스템 안전 감사는 바로 그 논증이 충분히 설득력 있는지 마지막으로 확인하는 과정이라고 할 수 있다.