사고는 언제나 “그럴 줄 몰랐다”라는 말 뒤에 숨어 있다. 하지만 안전의 세계에서 “몰랐다”는 변명은 통하지 않는다. 우리는 반드시 사고를 예상하고, 기록하며, 증명해야 한다. 그 증명의 결과물이 바로 시스템안전 기술서다.
시스템안전에서는 흔히 “안전규칙은 피로 쓰인다”라고 말한다. 그 말속에는 긴 세월의 경험이 담겨 있다. 수많은 사고와 참사를 기록하고, 비슷한 시스템을 다시 설계할 때, 과거의 기억과 경험, 모두가 만든 규칙, 그리고 합당한 규제를 꺼내 신뢰할 수 있는 시스템을 만들어내야 한다는 의미다.
재미있는 사례도 있다. 특정 종교가 강한 나라에서 안전 시스템을 설계할 때, 가장 첫 단계로 “신에게 기도”라고 적어둔 기록이 있다는 것이다. 인간의 손을 떠나 안전이 신에게 맡겨진다면, 우리는 최선을 다해 안전을 설계하고, 안전이 ‘대천명’이 되기를 바라며 작성한다.
그렇다면 궁금하지 않은가? 시스템 안전 엔지니어들은 도대체 어떤 기법으로, 어떻게 안전을 만들어 내는가?
이 질문에서 이야기를 시작해 보자.
우선, 시스템을 제대로 이해하는 것이 무엇보다 중요하다. 안전을 설계하려면, 이 시스템의 경계를 어디까지 잡을지부터 결정해야 한다. 시스템은 단일한 덩어리가 아니라, 작은 서브 시스템으로 나뉘며, 더 작게는 개별 컴포넌트 단위까지 세분화될 수 있다.
이 작은 조각들 하나하나를 이해하고, 서로 어떻게 상호작용하는지를 아는 것이 바로 안전을 설계하는 첫걸음이다. 각 컴포넌트의 역할과 한계를 알아야만, 그 위에 신뢰할 수 있는 안전장치를 쌓을 수 있다.
이해의 첫 단계에서, 가장 높은 관점에서 시작되는 분석이 바로 PHA(Preliminary Hazard Analysis, 예비 위험 분석)다.
아직 안전하다, 위험하다고 단정 짓기 전, 우리는 시스템 전체를 큰 네모 박스로 그려보고, 그 안을 검은색으로 칠한다고 상상해 보자. 이 박스 안이 바로 분석 대상 시스템이다.
그러고 나서 시스템 주변과 연결된 다른 영역, 즉 외부 환경, 사용자, 다른 시스템과의 상호작용을 살펴본다. 이렇게 하면 단순히 ‘위험’과 ‘안전’을 나누는 것을 넘어, 이 시스템이 왜 존재하는지, 무엇을 보호하고 무엇을 제약해야 하는지를 높은 수준에서 이해할 수 있다.
PHA 단계에서 시스템안전 엔지니어들은 다양한 도구와 기법을 활용해 위험을 식별한다. 가장 대표적인 방법은 브레인스토밍, 체크리스트, 과거 사고 사례 분석이다. 각 서브 시스템과 컴포넌트를 하나씩 살펴보며, “무엇이 잘못될 수 있는가?”라는 질문을 던진다.
예를 들어, 브레인스토밍을 통해 설계팀, 운영팀, 유지보수팀 등 다양한 시각에서 발생 가능한 위험을 모두 끌어낸다. 체크리스트는 이미 알려진 위험이나 규제 사항을 놓치지 않도록 도와준다. 과거 사고 사례 분석은 말 그대로 “다른 시스템에서 무엇이 문제였는지”를 통해 교훈을 얻는 과정이다.
이렇게 모아진 위험 요소들은 아직 평가되거나 순위가 매겨진 상태는 아니다. PHA 단계의 목적은 단지 시스템 전체를 큰 그림으로 보고, 어디에 잠재적 위험이 있는지 드러내는 것이다. 마치 어둠 속에서 등불을 들고 길을 살피듯, 막연하지만 전체 윤곽을 잡는 단계다.
이제 이 큰 그림 속에서, 어떤 위험이 실제로 문제가 될지, 어느 정도의 심각성을 가지는지를 평가하는 다음 단계로 넘어갈 준비가 된다.
PHA가 시스템 전체를 큰 박스로 보고 주변과 연결성을 이해하는 단계라면, 서브시스템 레벨에서는 각 서브시스템을 하나의 작은 박스로 나누어 분석한다.
각 서브시스템은 전체 시스템의 기능을 수행하기 위해 필요한 구성단위이며, 더 작은 컴포넌트로도 쪼개질 수 있다.
서브시스템 레벨에서는 다시 “무엇이 잘못될 수 있는가?”라는 질문을 던진다. 이때, 단순히 위험이 존재하는지 여부만 보는 것이 아니라, 서브시스템 내부에서 발생할 수 있는 다양한 실패 모드(Failure Mode)와 그 영향(Effect)까지 고려한다. 여기서 주로 활용되는 두 가지 분석이 SHA(System Hazard Analysis, 시스템 위험 분석)와 FHA(Functional Hazard Analysis, 기능적 위험 분석)다.
Note.
SHA는 서브시스템과 상호작용하는 모든 요소에서 발생할 수 있는 잠재적 위험을 식별하는 데 초점을 둔다.
각 서브시스템이 어떻게 실패할 수 있는지, 그리고 그 실패가 상위 시스템이나 주변 환경에 어떤 영향을 미치는지를 분석한다.
예를 들어, 항공기 연료 시스템을 SHA로 분석할 때, 연료 펌프 고장, 배관 누출, 센서 오류 등 서브시스템 자체에서 발생할 수 있는 위험을 평가한다.
FHA는 같은 서브시스템을 기능 관점에서 분석한다.
즉, “서브시스템이 수행해야 하는 기능이 실패하면 어떤 위험이 발생하는가?”를 평가하는 것이다.
위 연료 시스템 예시를 FHA로 보면, 연료 공급 기능이 실패할 때 엔진 정지, 비행 중 고장, 안전 위험 등 결과 중심으로 분석한다.
분석 방법은 시스템레벨의 분석과 유사하지만, 범위가 더 좁고 구체적이다.
결과적으로, 서브시스템 레벨 분석은 전체 시스템의 큰 그림 속에서 작은 블록 하나하나의 안전성을 확인하고 강화하는 단계다.
시스템레벨에서 잡은 큰 그림이 ‘어둠 속의 윤곽’이라면, 서브시스템 분석은 그 윤곽 안에서 세부 구조를 밝히는 등불과 같다.
서브시스템을 이해하고 위험을 파악했다면, 이제 가장 작은 단위, 컴포넌트까지 내려가 분석을 진행한다. 컴포넌트 레벨에서는 각 부품이나 모듈이 어떻게 실패할 수 있는지, 그리고 그 실패가 상위 서브시스템과 전체 시스템에 어떤 영향을 미치는지를 구체적으로 살핀다.
이 단계에서 가장 대표적인 기법은 FMEA(Failure Modes and Effects Analysis, 고장 양상 및 영향 분석)다.
먼저, 각 컴포넌트가 어떤 방식으로 고장 날 수 있는지(Failure Mode)를 나열한다.
다음으로, 그 고장이 서브시스템과 시스템 전체에 어떤 영향을 미치는지(Effect)를 평가한다.
마지막으로, 발생 가능성과 심각성을 기준으로 우선순위를 정해, 어디에 집중적으로 안전 대책을 적용할지 결정한다.
컴포넌트 분석은 마치 확대경을 들고 작은 부품 하나하나를 들여다보는 과정과 같다. 작은 문제가 모여 큰 사고로 이어질 수 있음을 알기에, 세밀한 관찰과 분석이 필수다.
이 과정을 통해, 시스템에서 그렸던 큰 그림과 서브시스템 분석에서 파악한 블록 안의 세부 구조가 모두 연결된다. 결국 시스템 안전 설계는 큰 그림을 보고, 그 안의 작은 부품 하나까지 이해하며, 모든 잠재적 위험을 확인하는 연속적 과정이다.
안전은 말로 약속할 수 있는 것이 아니다. “괜찮을 거야”라는 막연한 추측도, “지금까지 문제없었다”라는 경험도 근거가 될 수 없다.
시스템안전은 이러한 감각적 판단을 넘어, 위험을 구조적으로 분석하고 기록으로 남기는 도구다.
특히 항공기, 철도, 원자력, 자동차처럼 복잡하고 상호 연결된 시스템일수록, 안전은 눈에 보이지 않는다. 평소에는 아무 문제 없이 작동하는 시스템 속에 위험은 숨어 있고, 사고가 터지고 나서야 비로소 드러나며, 시스템안전에서 사용되는 분석법들은 바로 이 숨은 위험을 미리 찾아내고 드러내는 장치다. 말로는 설명할 수 없는 것들을 수치와 분석, 검증된 근거로 남기는 도구인 셈이다.
어느 참사든 우리 사회에는 너무 큰 상처를 남겼다. 불법 개조, 무리한 운항 등 겉으로 보이는 문제는 많지만, 근본적인 원인은, 이를 경고하고 막아낼 문서와 절차가 없었다는 점이다. 안전 관리, 안정성 검증, 위험 저감 절차가 문서로 남아 있었다면, 그렇게 많은 목숨이 사라지지는 않았을 것이다.
안전은 말로만 존재했고, 그 말은 사고와 함께 산산이 부서졌다.
반대로 항공 분야에서는 상황이 다르다. 비행기 제동 장치의 볼트 하나가 규격에 맞지 않아도, “괜찮아 보인다”는 말로 넘어가지 않는다. 설계 단계에서부터 FMEA(고장 형태 및 영향 분석), FTA(결함수 분석) 같은 기법으로 위험을 예측하고, 그 결과를 문서로 남겨 관리한다. 이상이 발견되면 즉시 보완 조치가 기록되고, 그 기록이 안전을 입증하는 증거가 된다. 덕분에 수천만 명을 매일 실어 나르는 항공기는 여전히 “가장 안전한 교통수단”이라는 이름을 지킬 수 있는 것이다.
안전자료는 단순한 보고서가 아니다. 그것은 위험을 찾아내는 탐지기이자, 안전을 증명하는 계약서다. 말로 “안전하다”라고 선언하는 것이 아니라, 언제, 어떤 근거로, 어떤 분석을 통해 안전을 확보했는지를 명확히 보여준다. 만약 이러한 분석이 없다면, 안전은 신뢰할 수 없는 구두 약속에 불과하다.
실무자의 입장에서 이 가치는 더욱 명확하다. 프로젝트 초기에 위험을 분석하지 않으면, 뒤늦게 문제가 터져 비용과 시간이 몇 배로 들어간다. 하지만 문서화 과정에서 위험을 드러내면, 작은 수정만으로도 큰 사고를 막을 수 있다. 기술서는 규정 준수를 위한 형식이 아니라, 사고를 줄이고 프로젝트를 살리는 가장 경제적인 도구다.
참사가 남긴 교훈은 분명하다. 안전은 말로만 약속할 수 없으며, 오직 문서와 분석, 기록으로만 증명된다는 사실이다. 이 문서들이 쌓일수록, 우리는 사고를 피할 확률을 조금씩 높여간다.
“그럴 줄 몰랐다”는 말은 더 이상 변명이 될 수 없다. 사고를 막는 것은 직감이나 경험이 아니라, 한 장의 분석이 남긴 기록이다. 결국 안전은 말이 아니라, 문서로 증명되는 것이다.
앞으로 우리는 다양한 시스템 안전 분석 기법을 하나씩 살펴볼 것이다. 각 기법이 어떤 지점에서 사용되는지, 왜 필요한지, 그리고 어떤 결과를 도출하며, 어떤 한계와 오류가 존재하는지까지 꼼꼼히 정리할 것이다.
이 과정을 통해 단순히 기법 이름을 외우는 것이 아니라, 실무에서 어떻게 안전을 설계하고, 위험을 줄이는지를 단계별로 이해할 수 있다.
각 분석 기법은 시스템 안전이라는 큰 그림 속에서 서로 연결되며, 때로는 서로 보완하고 때로는 반복 점검을 통해 위험을 최소화하는 역할을 한다.
이제, 가장 높은 관점에서 시작되는 시스템레벨부터 차근차근 알아보며, 서브시스템, 컴포넌트 레벨에 들어가는 분석까지 이어가는 여정을 시작해 보자.