시스템 안전(System Safety)을 이야기하다 보면 많은 엔지니어들이 자연스럽게 기능(Function)을 중심으로 사고하는 경향을 보인다. 시스템이 무엇을 해야 하는지, 어떤 기능을 수행해야 하는지, 그리고 그 기능이 실패했을 때 어떤 결과가 발생하는지를 분석하는 접근은 오랫동안 공학 설계의 핵심적인 방법이었다. 그러나 이러한 관점에 지나치게 집중하다 보면 시스템을 구성하는 부품과 구조보다 각 기능 자체에만 관심이 쏠리게 되고, 그 결과 시스템 전체가 어떻게 작동하는지에 대한 전체적인 그림을 이해하기 어려워지는 상황이 종종 발생한다. 특히 복잡한 시스템에서는 개별 기능이 정상적으로 작동하더라도 구성요소 간의 상호작용이나 인터페이스의 불일치로 인해 예상하지 못한 위험이 발생할 수 있기 때문에, 단순히 기능 중심의 사고만으로는 시스템의 안전성을 충분히 설명하기 어렵다. 이러한 이유로 시스템을 다시 정의하고, 시스템 수준에서 위험이 어떻게 형성되는지를 이해하려는 접근이 필요하다.
시스템 안전 분야에서 위험 분석은 여러 가지 형태로 수행된다. 대표적으로 Functional Hazard Assessment(FHA), System Hazard Analysis(SHA), Subsystem Hazard Analysis(SSHA), 그리고 Operating Hazard Analysis(OHA)와 같은 분석 방법이 널리 사용된다. 각각의 분석은 시스템의 서로 다른 측면을 이해하기 위해 설계되었으며, 적용되는 시점과 분석의 관점 또한 다르다. 그러나 실제 산업 현장에서는 이러한 분석들이 명확히 구분되지 않은 채 사용되는 경우가 적지 않다. 특히 FHA와 SHA는 모두 위험을 식별하는 활동이라는 공통점 때문에 동일한 분석처럼 이해되거나, 단순히 분석 단계의 차이 정도로 설명되는 경우도 많다. 하지만 두 분석은 출발점과 질문 방식이 근본적으로 다르며, 분석이 다루는 대상 또한 서로 다르다.
Functional Hazard Assessment는 이름에서 드러나듯이 시스템이 수행해야 하는 기능을 중심으로 위험을 이해하려는 분석이다. 특정 기능이 실패하거나 의도된 성능을 충족하지 못할 때 어떤 결과가 발생하는지를 평가하며, 이러한 실패가 시스템 운영에 어떤 영향을 미칠 수 있는지를 분석한다. 예를 들어 항공기에서 비행 제어 기능이 상실되었을 때 어떤 위험이 발생하는지, 또는 탐지 시스템이 목표물을 발견하지 못했을 때 어떤 결과가 나타나는지를 평가하는 방식이 바로 FHA의 전형적인 접근이다.
반면 System Hazard Analysis는 분석의 출발점을 기능이 아니라 시스템 자체에 둔다. 즉, 시스템을 구성하는 요소들이 어떻게 연결되어 있고 어떤 방식으로 상호작용하며, 이러한 구조 속에서 어떤 위험이 발생할 수 있는지를 탐색한다. 이는 단순히 기능의 실패를 분석하는 것과는 다른 질문을 던지는 접근이다. 예를 들어 서로 다른 시스템이 동일한 데이터를 서로 다른 방식으로 해석할 가능성, 인터페이스의 시간 지연이 시스템 행동에 어떤 영향을 줄 수 있는지, 혹은 자동화 시스템의 판단을 인간 운용자가 제대로 이해할 수 있는지와 같은 문제들이 SHA의 주요 분석 대상이 된다. 이러한 차이는 단순한 분석 절차의 차이가 아니라 위험을 바라보는 관점의 차이라고 할 수 있다.
실제 시스템 사고를 살펴보면 많은 경우 단일 기능의 실패 때문이 아니라 구성요소 간의 상호작용, 인터페이스의 불일치, 잘못된 설계 가정, 또는 인간과 자동화 시스템 간의 이해 차이에서 발생한다. 각각의 구성요소가 개별적으로는 정상적으로 작동하고 있음에도 불구하고, 시스템 전체의 구조 속에서 예상하지 못한 결과가 나타나는 것이다. 이러한 문제를 이해하기 위해 수행되는 분석이 바로 System Hazard Analysis이다.
따라서 SHA는 단순히 시스템 수준에서 위험을 나열하는 분석으로 이해되어서는 안 된다. 그것은 시스템이 어떤 구조와 경계를 가지고 있으며, 그 구조 속에서 위험이 어떻게 생성될 수 있는지를 이해하려는 과정이다. 더 나아가 시스템 안전의 핵심은 미래의 사고를 완벽하게 예측하는 것이 아니라 설계가 어떤 가정 위에서 안전하다고 주장되는지를 검증하는 것에 있다. 이러한 관점에서 System Hazard Analysis는 단순한 분석 기법을 넘어, 시스템 설계가 어디까지 책임질 수 있는지 그리고 어떤 경계 안에서 안전을 보장하려 하는지를 탐구하는 과정이라고 볼 수 있다.
시스템과 기능은 서로 밀접하게 연결된 개념이지만, 위험 분석의 관점에서는 명확하게 구분되어야 한다. 기능(Function)은 시스템이 수행해야 하는 행위나 역할을 의미하며, 시스템이 존재하는 목적을 설명한다. 예를 들어 항공기의 비행 제어 시스템을 생각해 보면, 항공기의 자세를 안정적으로 유지하는 것, 조종사의 입력을 받아 제어 신호로 변환하는 것, 그리고 엔진의 출력을 조절하는 것과 같은 활동들이 모두 기능에 해당한다. 이러한 기능들은 시스템이 무엇을 수행해야 하는지를 정의하며, 시스템의 성능 요구사항과 직접적으로 연결된다.
그러나 시스템(System)은 단순히 이러한 기능들의 집합으로 이해될 수 있는 개념이 아니다. 시스템은 여러 구성요소가 일정한 구조 속에서 연결되어 서로 영향을 주고받으며 작동하는 전체적인 구조를 의미한다. 이 구조에는 하드웨어와 소프트웨어뿐 아니라 인간 운용자, 운영 절차, 외부 환경, 그리고 서로 다른 시스템 간의 인터페이스까지 포함된다. 따라서 기능이 시스템이 수행하는 행동을 설명한다면, 시스템은 그 행동이 어떤 구조와 관계 속에서 이루어지는지를 설명하는 개념이라고 할 수 있다.
이러한 구분은 위험 분석에서 매우 중요한 의미를 갖는다. 기능 중심의 분석에서는 특정 기능이 실패했을 때 어떤 결과가 발생하는지를 중심으로 위험을 평가한다. 예를 들어 항공기의 자동 조종 기능이 상실될 경우 비행 안정성에 어떤 영향을 미치는지, 또는 레이더 탐지 기능이 실패할 경우 목표물을 놓칠 가능성이 얼마나 되는지를 분석하는 방식이 이에 해당한다. 이러한 접근은 Functional Hazard Assessment(FHA)의 기본적인 질문 구조를 형성한다.
반면 시스템 관점에서 바라보면 위험은 반드시 기능의 실패에서만 발생하지 않는다. 실제로 많은 시스템 사고는 구성요소 간의 상호작용이나 인터페이스의 불일치에서 비롯된다. 예를 들어 레이더 시스템이 목표물을 정확하게 탐지하고 미사일 시스템이 발사 명령을 정상적으로 수행한다고 가정해 보자. 두 기능 모두 의도한 대로 작동하고 있음에도 불구하고, 두 시스템이 사용하는 좌표 기준(reference frame)이 서로 다르게 정의되어 있다면 미사일은 전혀 다른 위치로 발사될 수 있다. 이 경우 문제의 원인은 특정 기능의 실패가 아니라 시스템 간 인터페이스와 설계 가정의 불일치에 있다.
이처럼 기능이 정상적으로 작동하더라도 시스템 구조 속에서 예상하지 못한 결과가 발생할 수 있으며, 이러한 유형의 위험을 분석하는 접근이 바로 System Hazard Analysis(SHA)이다. SHA는 개별 기능의 실패를 넘어 시스템 구성요소 간의 관계와 상호작용을 이해함으로써, 설계 구조 속에서 발생할 수 있는 잠재적인 위험을 식별하는 데 목적이 있다.
정리 note.
기능(Function)은 시스템이 무엇을 해야 하는가에 대한 질문이다. 예를 들어 항공기의 기능은 다음과 같이 정의될 수 있다.
항공기를 조종한다.
항공기의 위치를 계산한다.
조종사의 입력을 처리한다.
엔진 출력을 제어한다.
이러한 기능 중심 사고는 FHA의 출발점이 된다. FHA는 특정 기능이 실패했을 때 어떤 위험이 발생하는지를 평가하는 분석이다. 예를 들어 “항공기의 자세 제어 기능이 상실되면 어떤 결과가 발생하는가?”와 같은 질문을 던진다.
반면 시스템(System)은 무엇이 존재하며 그것들이 어떻게 상호작용하는가에 대한 질문이다. 시스템은 다음과 같은 요소들로 구성된다.
하드웨어
소프트웨어
인간 운용자
인터페이스
환경
절차
즉 시스템은 구조(structure)를 가진다. 시스템 안전 문제는 대부분 기능의 실패보다는 구조적 상호작용에서 발생한다.
System Hazard Analysis는 시스템 수준에서 위험이 어떻게 발생할 수 있는지를 식별하고 분석하는 과정이다. 이 분석은 단일 구성요소의 결함보다는 구성요소 간의 관계와 상호작용에 초점을 둔다. 따라서 SHA는 시스템 아키텍처, 데이터 흐름, 인터페이스 구조, 운영 환경, 인간과 자동화 시스템의 상호작용 등을 함께 고려한다. FHA가 기능의 실패를 중심으로 위험을 탐색한다면, SHA는 다음과 같은 질문을 던진다.
시스템 구성요소 간 인터페이스는 안전하게 설계되었는가
서로 다른 하위 시스템의 가정이 충돌하지 않는가
데이터 흐름이 잘못 해석될 가능성은 없는가
인간과 자동화 시스템 간 상호작용은 안전한가
환경 조건이 시스템 행동에 어떤 영향을 미치는가
이 분석에서 중요한 질문은 특정 기능이 실패하는지 여부가 아니라 시스템이 어떤 방식으로 예상과 다른 행동을 할 수 있는가이다. 예를 들어 데이터가 지연되거나 잘못 해석될 가능성, 서로 다른 시스템이 동일한 정보를 다른 방식으로 처리할 가능성, 또는 자동화 시스템이 내린 결정이 인간 운용자에게 충분히 이해될 수 있는지와 같은 문제가 모두 SHA의 분석 대상이 된다. 즉 SHA는 “어떤 기능이 실패하는가”보다 “시스템이 어떻게 실패할 수 있는가”를 이해하는 분석이다.
예를 들어 미사일 방어 시스템을 생각해 보자. 이 시스템은 탐지 레이더, 추적 알고리즘, 교전 관리 시스템, 통신 네트워크, 미사일 발사 시스템 등 여러 구성요소로 이루어져 있다. 각각의 요소가 독립적으로는 정상적으로 작동할 수 있지만, 네트워크 지연으로 인해 추적 데이터가 늦게 전달된다면 교전 관리 시스템은 오래된 정보를 기반으로 결정을 내릴 수 있다. 이 경우 미사일은 이미 사라진 목표를 향해 발사될 수도 있다. 이러한 위험은 특정 기능의 실패가 아니라 시간적 상호작용과 시스템 구조에서 발생하는 문제다.
SHA는 이러한 상황을 사전에 이해하고 설계 단계에서 위험을 줄이기 위한 안전 요구사항을 도출하는 데 목적이 있다.
SHA는 단순히 체크리스트를 채우는 작업이 아니다. 효과적인 SHA는 시스템을 이해하는 과정에서 시작된다. 다음은 실제 프로젝트에서 사용할 수 있는 SHA 수행 절차이다.
1단계: 시스템 경계 정의
첫 번째 단계는 시스템의 경계(system boundary)를 정의하는 것이다. 시스템 안전 문제는 종종 경계 밖에서 시작된다. 예를 들어 항공 교통 관리 시스템을 분석할 경우 다음과 같은 질문을 해야 한다.
조종사는 시스템의 일부인가
위성 시스템은 시스템 경계에 포함되는가
외부 통신 네트워크는 어디까지 고려해야 하는가
경계를 명확히 하지 않으면 책임의 공백이 생긴다.
2단계: 시스템 구조 이해
다음 단계는 시스템의 구조를 이해하는 것이다. 이를 위해 다음과 같은 자료가 필요하다.
시스템 아키텍처 다이어그램
인터페이스 정의 문서(ICD)
데이터 흐름 다이어그램
운영 개념(CONOPS)
이 단계에서 중요한 질문은 다음과 같다.
어떤 구성요소가 존재하는가
구성요소는 어떻게 연결되어 있는가
어떤 데이터가 이동하는가
인간 운용자는 어디에 개입하는가
3단계: 잠재적 위험 시나리오 도출
이제 시스템 상호작용을 기반으로 위험 시나리오를 도출한다. 다음과 같은 질문이 유용하다.
데이터가 잘못 해석되면 어떤 일이 발생하는가
인터페이스 타이밍이 어긋나면 어떤 일이 발생하는가
서로 다른 시스템이 동일한 데이터를 다르게 해석하면 어떤 일이 발생하는가
자동화 시스템이 잘못된 결정을 내리면 인간은 이를 인지할 수 있는가
예시
상황: 미사일 발사 시스템이 목표 좌표를 수신한다.
잠재 위험: 좌표 단위가 서로 다르게 정의되어 있다.
결과: 미사일이 잘못된 위치로 발사된다.
4단계: 위험 평가
위험이 식별되면 심각도(severity)와 발생 가능성(likelihood)을 평가한다.
예를 들어 다음과 같은 평가가 가능하다.
미사일 오발사 → catastrophic
잘못된 경고 메시지 → major
데이터 지연 → minor
이 단계는 단순한 점수 계산이 아니라 운용 맥락을 이해하는 과정이다.
5단계: 안전 요구사항 도출
마지막 단계는 위험을 줄이기 위한 안전 요구사항(safety requirements)을 도출하는 것이다.
예시:
좌표 단위 검증 로직 추가
데이터 타임스탬프 검증
운용자 확인 절차 추가
인터페이스 표준화
이 단계에서 중요한 것은 설계팀과의 협력이다. SHA는 설계를 비판하기 위한 활동이 아니라 설계를 개선하기 위한 대화 과정이다.
SHA는 강력한 분석 방법이지만 몇 가지 중요한 한계를 가진다.
첫째, SHA는 분석가의 이해 수준에 크게 의존한다. 복잡한 시스템에서는 모든 상호작용을 완전히 이해하기 어렵기 때문에 일부 위험이 분석에서 누락될 가능성이 있다. 시스템을 충분히 이해하지 못하면 위험을 놓칠 가능성이 높다.
둘째, SHA는 종종 시스템 구조를 기준으로 수행되기 때문에 시간에 따른 동적 변화나 실제 운영 중 발생하는 예외 상황을 충분히 반영하지 못할 수 있다. 실제 사고는 정적인 구조보다는 시간적 상호작용과 운영 상황의 변화에서 발생하는 경우가 많다.
셋째, 조직적 의사결정이나 운영 절차와 같은 요소는 기술적 분석에서 충분히 다뤄지지 않는 경우가 있다. 그러나 많은 시스템 사고는 기술적 결함보다 잘못된 가정이나 의사결정 과정에서 발생한다.
이러한 한계를 보완하기 위해서는 다양한 분석 방법을 함께 사용하는 것이 중요하다. 시스템 이론 기반 분석 방법을 활용하거나, 실제 운영 시나리오를 기반으로 분석을 수행하고, 인간과 자동화 시스템의 상호작용을 보다 깊이 이해하려는 접근이 필요하다. 또한 서로 다른 분야의 전문가들이 함께 분석에 참여할 때 시스템을 보다 입체적으로 이해할 수 있다.
System Hazard Analysis(SHA)는 단순히 위험을 식별하거나 목록화하는 활동으로 이해되어서는 안 된다. 이 분석의 핵심 목적은 시스템이 어떤 구조로 이루어져 있으며, 그 구조 속에서 예상하지 못한 결과가 어떤 방식으로 나타날 수 있는지를 이해하는 데 있다. 따라서 효과적인 SHA는 가능한 많은 위험을 찾아내는 데 초점을 두기보다, 설계가 어떤 가정 위에서 안전하다고 판단되고 있는지를 드러내는 과정에 가깝다. 이러한 분석을 통해 시스템이 의존하고 있는 조건과 전제들이 명확해지고, 그 전제가 실제 환경에서도 유지될 수 있는지에 대한 검토가 이루어진다.
복잡한 시스템에서 사고는 대부분 명확한 기능 고장보다는 구성요소 간의 상호작용, 인터페이스 해석의 차이, 또는 설계 과정에서 암묵적으로 받아들여진 전제에서 비롯된다. 그렇기 때문에 SHA의 중요한 역할은 이미 알려진 위험을 반복적으로 정리하는 것이 아니라, 설계 과정에서 충분히 고려되지 않았던 가능성을 드러내는 질문을 만들어내는 데 있다. 이러한 질문은 시스템이 실제 환경에서 어떻게 동작할 것인지, 그리고 서로 다른 구성요소가 어떤 방식으로 영향을 주고받을 것인지를 다시 바라보게 만든다.
시스템 안전의 목적 역시 절대적인 안전을 증명하거나 모든 사고를 예측하는 데 있지 않다. 현실의 복잡한 시스템에서 이러한 목표는 달성될 수 없다. 대신 중요한 것은 시스템의 경계를 명확히 하고, 구성요소와 그 관계를 깊이 이해하며, 예상과 다른 결과가 나타날 수 있는 지점을 지속적으로 탐색하는 것이다. 이러한 탐색 과정 속에서 설계의 취약한 전제가 드러나고, 필요한 개선이 이루어질 수 있다.
결국 System Hazard Analysis의 가치는 결과로 작성된 위험 목록보다 분석 과정에서 제기된 질문과 통찰에 있다. 시스템을 구조적으로 이해하고, 그 속에서 위험이 시작될 수 있는 지점을 끊임없이 탐색하려는 태도 자체가 SHA의 본질이며, 복잡성이 증가하는 현대 기술 환경에서 이러한 접근은 더욱 중요한 의미를 갖는다.