대형 프로젝트에서 발생하는 사고의 상당수는 아이러니하게도 “큰 결함”이 아니라, 시스템과 시스템이 연결되는 작은 틈에서 나온다. 신호가 제때 전달되지 않거나, 전달해야 할 데이터가 누락되거나, 보내지 말아야 할 방향으로 흘러가는 순간, 아무리 견고한 시스템도 순식간에 오작동할 수 있다. 바로 이 지점을 파고드는 분석 기법이 인터페이스 위험 분석(Interface Hazard Analysis, IHA)이다.
IHA는 “각 시스템이 제 역할을 하는가?”보다 더 중요한 질문,
“이 시스템들은 서로 정확히 소통하고 있는가?”
를 묻는다.
많은 조직이 기능별·장비별·작업별 위험은 세밀하게 분석하지만, 실제 사고는 의외로 복잡한 시스템 내부가 아니라 서로 다른 시스템이 맞닿는 ‘경계’에서 가장 쉽게 발생한다. 이를 설명할 때 철도 시스템 사례를 들면 이해가 쉬워진다. 한 도시철도에서는 신호 제어 장치도, 차량 제어 시스템도 모두 정상적으로 작동하고 있다고 가정해 보자. 문제는 지상 신호장치에서 차량 제어 시스템으로 전달되는 위치 데이터가 평소보다 단 3초 늦게 도착했을 때 이다. 고작 3초라며 생각할 수 있는 시간, 데이터가 안 들어온 것도 아니며, 평소보다 조금 늦었을 뿐이었다면 어땠을까?
각 시스템은 "자기 내부 기준"으로는 이상이 없다고 판단했지만, 바로 이 3초의 간극이 열차 간격을 계산하는 알고리즘을 흔들어 결국 저속 충돌 사고로 이어지는 결과를 가져올 수 있다. 여기서 핵심은 장비 자체의 고장이 아니라, 두 시스템의 연결부, 즉 인터페이스가 신뢰성을 잃는 순간 아무리 견고한 설계도 전체 시스템을 보호하지 못한다는 점이다. 그렇기 때문에 시스템의 기능적 완성도만이 아니라 연결의 신뢰성 자체가 하나의 안전 요소라는 사실을 반드시 이해해야 하며, IHA는 바로 이러한 ‘보이지 않는 약한 고리’를 드러내어 사고의 본질을 파악하게 해주는 가장 현실적이고 실효적인 분석 기법이다.
이제 IHA기법을 이용하여 분석을 한다고 가정해 보면, 가장 먼저 던져야 할 질문은 “이 인터페이스는 무엇을 주고받고, 누가 보내고, 어떻게 받아야 하는가?”다. 인터페이스 분석은 단순히 연결선을 확인하는 작업이 아니라, 시스템들이 서로 어떤 ‘언어’를 사용해 대화를 나누고 있는지 해석하는 과정이다. 풍향·풍속 센서가 제어 시스템에 데이터를 보내는 상황을 예로 들면, 데이터 값·전달 주기·통신 방식·정상 범위 등 모든 사항이 정확히 정의되어 있어야만 그다음 단계에서 위험을 판단할 수 있으며, 이처럼 인터페이스 정의는 곧 위험 식별의 출발점이기 때문에, 여기서 불명확함이 생기면 전체 분석이 흐려지고 시스템 대화의 의미를 오해하게 된다.
Note.
IHA는 시스템 간 전달되는 모든 정보·에너지·물질 흐름을 점검하며 다음 질문을 던진다.
무엇을 주고받아야 하는가?
누가 보내고, 누가 받는가?
언제·어떻게 전달되는가?
전달이 실패한다면 어떤 일이 발생하는가?
이 질문을 바탕으로 IHA는 인터페이스의 구조적 결함, 통신 실패, 타이밍 불일치, 역방향 흐름, 과도한 데이터, 부족한 데이터, 무의미한(Null) 결과 등 다양한 위험을 식별해 낸다.
IHA 절차는 크게 인터페이스를 시각화하여 맵을 만드는 것에서 시작해, 각 인터페이스의 속성을 정의하고, 그 기능적 목적을 파악한 뒤, 해당 목적을 위협할 수 있는 오류 유형을 체계적으로 식별하는 순서로 흐른다. 풍력발전 시스템을 예로 들면, 터빈 제어 시스템·센서·안전 PLC 등 여러 장치의 연결 관계를 맵으로 정리한 후, 각 연결이 가진 데이터 특성과 역할을 규정한다. 그다음 이 인터페이스가 전체 시스템에서 어떤 기능적 의미를 가지는지 분석하면, ‘이 데이터가 늦게 들어오면 어떤 문제가 생기는가?’, ‘이 신호가 잘못된 장치로 들어가면 어떤 결과가 발생하는가?’ 같은 위험 식별 단계로 자연스럽게 넘어갈 수 있다. 즉, IHA 절차는 단계별로 따로 존재하는 것이 아니라, 앞 단계가 반드시 다음 단계를 만들어내는 일종의 ‘논리적 연쇄’다.
① 인터페이스 매핑 (Interface Mapping)
먼저 시스템 간 어떤 연결이 존재하는지 시각화한다. 데이터, 신호, 물리적 힘, 유체, 전기 등 다양한 형태의 인터페이스가 모두 포함된다.
예시: 풍력발전 설비에서
터빈 제어 시스템 ↔ 발전량 모니터링 시스템
풍향·풍속 센서 ↔ 제어 로직
제동 장치 ↔ 안전 PLC
이런 연결들을 하나의 인터페이스 맵으로 정리한다.
② 인터페이스 정의 (Definition of Interface Elements)
각 인터페이스가
무엇을 주고받고
어떤 프로토콜을 따르고
정상 상태가 무엇인지
명확하게 규정한다.
예시: 풍향 센서 → 제어 시스템
데이터: 풍향(도), 풍속(m/s)
주기: 1초
정상 범위: 0~50m/s
전송 방식: RS-485 통신
이 단계가 불명확하면 이후 위험 분석이 모두 흐려진다.
③ 인터페이스 기능 분석 (Functional Analysis)
각 인터페이스가 전체 시스템에서 어떤 역할을 하는지 기능적 목적을 파악한다.
예시: 풍속 데이터는 터빈 회전 속도를 조절하는 핵심 입력이다.
이 기능이 흔들리면 과속 회전 → 기계적 파손 → 대형 사고로 이어질 수 있다.
④ 인터페이스 위험 식별 (Hazard Identification)
인터페이스 고유의 오류 패턴을 기반으로 위험을 찾아낸다.
이렇게 인터페이스를 명확히 정의했다면, 그 인터페이스가 어떻게 실패할 수 있는지 탐색하는 단계로 넘어가게 된다. 대표적인 위험 유형으로는 송신 실패(Failure to Send), 수신 실패(Failure to Receive), 지연(Delay), 과조기 전송(Too Quick), 잘못된 수신자에게 전달되는 오류(Wrong Destination), 범위 밖의 데이터 또는 손상된 데이터(Out-of-Range/Corrupted Data), 그리고 Null Outcome 같은 무의미한 값이 있다. 이러한 위험들은 각기 다른 형태로 보이지만 모두 동일한 메시지를 담고 있습니다: 인터페이스는 언제든지 자신의 역할을 잃을 수 있으며, 그 영향은 시스템 전체로 확산된다. 예를 들어 병원 모니터링 장비가 심박수 데이터를 보내지 못하면 환자 상태 변화가 놓쳐지고, 드론의 GPS 신호가 지연되면 잘못된 위치를 기준으로 비행하게 되며, 철도 플랫폼 도어가 너무 일찍 열리면 승객 안전을 위협하게 된다. 이런 사례는 인터페이스 위험이 단순한 기술 문제가 아니라, 궁극적으로 사람의 생명과 직결되는 문제임을 보여준다.
IHA에서 주로 다루는 위험 유형은 다음과 같다.
1) Failure to Send (송신 실패): 보내야 할 정보·신호가 아예 전송되지 않는 경우.
예시: 병원의 환자 모니터링 장비가 심박수 데이터를 중앙 모니터로 보내지 못하는 순간, 의료진은 환자의 급격한 상태 변화를 포착하지 못해 치명적 지연이 발생할 수 있다.
2) Failure to Receive (수신 실패): 신호가 정상적으로 보내졌지만, 수신 측에서 이를 받지 못하는 경우.
예시: 화학 플랜트에서 압력 센서가 정상 값을 보내고 있었지만, 메인 제어 시스템의 수신 포트가 오류를 일으켜 데이터를 받아들이지 못했다. 센서는 “보냈다”라고 생각하고, 제어기는 “아무것도 없다”라고 판단하는 순간 압력 폭발 사고가 발생할 수 있다.
3) Delay in Transmission (지연): 신호가 제때 도착하지 않는 문제.
예시: 드론 자동비행 시스템에서 GPS 데이터가 1~2초 지연될 경우 비행 제어는 이미 지나간 위치를 기준으로 조종하게 되고 회피 기동이 늦어져 충돌 사고로 이어질 수 있다.
4) Too Quick / Premature Transmission (너무 빠른 전달): 신호가 너무 이른 타이밍에 전달되는 경우.
예시: 지하철 플랫폼 도어 시스템에서 열차 위치 신호가 너무 일찍 들어오면 도어가 실제 열차가 오기 전에 열려 추락 사고로 이어질 수 있다.
5) Wrong Destination (잘못된 수신자): 전달되어서는 안 될 시스템으로 데이터가 흘러가는 경우.
예시: 자동차의 차량 CAN 네트워크에서 브레이크 센서 데이터가 엔터테인먼트 모듈로 잘못 전달되면 필수 제어 모듈은 필요한 데이터를 받지 못하고 브레이크가 의도대로 동작하지 않을 위험이 생긴다.
6) Out-of-Range / Corrupted Data (범위를 벗어난 값, 오류 데이터): 하드웨어 오작동, 전기적 노이즈, 변환 과정 오류 등으로 데이터가 왜곡된 경우.
예시: 풍속 센서가 512m/s라는 불가능한 값을 전송한다면 제어 시스템은 이를 정상값으로 인식하여 터빈을 급정지시켜 설비 전체가 잦은 트립에 시달리는 상황이 발생할 수 있다.
7) Null Outcome (의미 없는 또는 빈 데이터): 데이터가 오긴 왔지만 무의미하거나 내용이 비어 있어 의사결정에 사용할 수 없는 경우.
예시: 버스 자동요금 시스템에서 승객 태깅 정보가 “NULL” 값으로 들어오면 요금 산정 로직이 정지하여 전체 시스템이 다운될 수 있다.
식별한 위험은 이제 평가하고 통제해야 한다. 이 단계에서는 위험의 심각도, 발생 가능성, 탐지 가능성을 기준으로 우선순위를 정하고, 이를 기반으로 수신 확인 절차(handshaking), 이중화(Redundancy), 타임스탬프 기반 타이밍 검증, 범위 검증 로직(Validation), Fail-safe 설계와 같은 통제 전략을 마련한다. 예를 들어 풍속 센서의 잘못된 데이터가 시스템을 불필요하게 정지시키지 않도록 두 개의 센서에서 동일한 오류가 발생할 때만 정지하는 방식의 이중 검증을 적용할 수 있다. 이런 통제 전략은 단순히 위험을 줄이는 기술적 도구가 아니라, 앞서 설명한 인터페이스 위험 유형들을 ‘어떻게 실질적으로 제어할 것인가’라는 교육적 메시지와 이어져 있다. 즉, 인터페이스 위험 분석은 위험을 찾는 데서 끝나지 않고, 그 위험이 다시 발생하지 않도록 시스템의 대화 방식을 교정하는 과정이다.
Note.
주요 통제 전략
이중화(Redundancy): 센서/통신 채널 이중화
검증 로직(Validation Logic): 범위를 벗어난 값 자동 거부
수신 확인(Ack. Mechanism): send/receive handshake
타이밍 체크(Timestamp): 지연·조기 전송 판별
Fail-safe 설계: 데이터 오류 시 안전 모드 진입
대형 시스템일수록 각 구성 요소는 더 정교하고 안정적으로 발전하지만, 정작 이들 사이를 오가는 신호·데이터·명령은 의외로 가장 취약한 부분이 될 수 있다. 지금까지 살펴본 인터페이스 위험 분석(IHA)의 필요성, 절차, 위험 유형, 통제 전략은 모두 이 사실을 똑같이 가리키고 있다. 시스템의 실패는 대개 장비 내부의 결함이 아니라, 서로 주고받는 과정에서 생기는 작은 균열, 즉 인터페이스 실패에서 시작된다는 것이다. 바로 이 지점을 드러내는 것이 IHA이며, 시스템 안전(System Safety)에서는 이러한 인터페이스를 시스템 전체 위험의 ‘첫 번째 경계’로 보고 반드시 초기에 다루어야 하는 핵심 분석으로 간주한다. 왜냐하면 시스템 안전의 관점에서 보면, 어떤 시스템이 얼마나 튼튼하게 설계되었는지는 결국 구성 요소 간의 대화가 얼마나 정확하고 일관되게 유지되느냐에 달려 있기 때문이다. 시스템 내부 결함보다 더 무서운 것은 서로를 정확히 이해하지 못하는 시스템들, 즉 신뢰를 잃은 인터페이스다.
따라서 프로젝트 초기 단계에서 IHA를 적용하면 센서 신호의 몇 밀리초 지연, 제어 명령의 누락, 예상치 못한 Null 값처럼 눈에 잘 보이지 않는 작은 오류들이 대형 사고로 번져가는 경로를 사전에 차단할 수 있다. 이것이 바로 시스템 안전이 IHA를 ‘사전 예방의 핵심 도구’로 간주하는 이유이며, 시스템 안전의 목적은 결함을 문서화하는 것이 아니라, 위험이 경로를 형성하기 전에 그 싹을 잘라내는 것이다. 인터페이스 신뢰성을 다지는 순간 시스템의 전체 안전성은 자연스럽게 올라가고, 시스템은 예측 불가능한 상황에서도 더 견고하게 사용자와 현장을 보호할 수 있게 된다. 결국 IHA는 설비의 효율을 높이기 위한 절차가 아니라, 사람을 지키는 시스템 안전의 본질적인 과정이며, 여러분이 앞으로 설계자·엔지니어·안전 전문가로서 어떤 시스템을 다루더라도 반드시 잡고 가야 할 가장 중요한 기준점이 될 것이다.