플레어와 Nulka, 그리고 ‘만약’의 순간들
전투기는 밤하늘을 가르는 화살 같다. 속도는 마하를 넘어, 적의 미사일은 그 뒤를 집요하게 추적한다. 함정 또한 마찬가지다. 바다 위에 홀로 떠 있는 거대한 쇳덩이는 레이더에 가장 먼저 포착되는 표적이다. 누군가는 말한다. “공격이 최선의 방어다”라고. 하지만 진짜 시스템 엔지니어는 그다음 질문을 던진다. “만약 우리가 피해야 한다면?”
그 질문에 답하는 장치가 바로 전투기의 플레어와 함정의 Nulka다.
플레어는 뜨겁게 타오르는 불꽃으로, 미사일의 눈을 속인다. 적 열추적(또는 IR) 미사일의 추적을 분산시키기 위해 고열 신호(플레어)를 방출하는 기능이다.
Nulka(함정용 능동/수동 유인체)는 가짜 신호를 만들어, 적의 레이더가 허공을 쫓도록 유인한다. 적 미사일의 유도체계를 자기/레이더 유사 신호로 오도하여 함정으로부터 유도탄을 분리시킨.
플레어와 Nulka 모두 ‘적 유도탄의 관심을 다른 신호로 끌어내는’ 기능을 수행하므로, 기능 실패는 운용 플랫폼 손실, 아군·민간 피해, 환경적 위험, 규칙·법적 책임 같은 심각한 위해로 이어질 수 있다. 따라서 신뢰성·타이밍·검출의무·인증·로그가 핵심 통제며, 겉으로 보면 단순한 회피기술 같지만, 그 뒤에는 수많은 실패 가능성과 안전 문제들이 숨어 있다. 그리고 바로 그것을 분석하는 기법이 Functional Hazard Analysis(FHA)다.
그렇다면, FHA를 이용하여 함께 분석해 보자.
불이 켜지지 않을 때 – Disfunction (완전 기능불능 — 아예 동작하지 않음)
적 미사일이 다가오는데, 플레어 발사기가 꿈쩍도 하지 않는다면? 혹은 Nulka가 아예 튀어나오지 않는다면?
그 순간, 하늘을 나는 전투기도, 바다를 지키는 함정도 단순한 표적이 되고 만다. 기능 불능은 가장 단순하지만 치명적인 위험이다.
잠재적 위해
미사일 경보 시 회피수단 부재 → 플랫폼(항공기/함정) 피격·손실.
조기 경보에도 방어체계가 작동하지 않아 승무원·민간 피해.
가능한 원인
기계적 결함(발사기·배출장치 고착), 전원 차단, 제어컴퓨터 정지, 소프트웨어 크래시, 인터페이스 오류.
기존 통제
정비 점검(발사기 기능검사), 전원 모니터링, 기본 펌웨어/하드웨어 자가진단(BIT).
권장 안전요구(설계·운영 측면)
이중 전원/백업 모듈; 발사기/배출장치의 최소 고장허용(Graceful degradation).
운항 전 자동 self-test 통합(로그 포함) 및 실패 시 비행·항해 차단 플래그.
Verification
정기적 벤치테스트, 전장 통합 시험, 시뮬레이션 기반 고장 주입(Fault injection) 검증.
삐걱거리는 움직임 – Malfunction (부분적 오작동 — 기능은 있으나 비의도적 거동)
불은 붙었는데 플레어가 반쯤 타다가 꺼진다. 혹은 Nulka가 이상한 신호를 내뿜어 적 미사일을 더 끌어들이기도 한다.
마치 자동차가 급정거 대신 갑자기 튀어나가는 것처럼, 불완전한 오작동은 상황을 더 악화시킨다.
잠재적 위해
불완전·예측불가한 유인체 신호 발생 → 미사일이 오도되지 않거나 오히려 유효 목표를 생성(아군·민간 피해 위험).
발사 시 불완전 연소(플레어)로 화재 위험.
가능한 원인
연소약품 품질문제, 전자신호 왜곡, 펌웨어 버그, 기구적 파손.
기존 통제 출고품 품질관리, 정비 규정, 물질 유효기간 관리.
권장 안전요구
자재·소모품에 대한 lot-traceability와 유효성 검사; 이상 파라미터 모니터링(연속 센싱).
안전 셧오프(불완전 연소 감지 시 즉시 차단) 및 자동보고.
Verification
소재 샘플시험, 환경(온도/진동) 스트레스 시험, 통합 RF/IR 특성 검증(비작전적 수준에서).
늦게 온 구조 – Delay in time (지연적 타이밍 실패 — 너무 늦게 동작)
누군가 SOS를 쳤는데 구조선이 너무 늦게 오는 장면을 상상해 보자.
플레어와 Nulka도 마찬가지다. 타이밍이 늦어 발사된다면, 이미 미사일은 추적락을 마친 뒤다. 이 지연은 곧 파국을 의미한다.
잠재적 위해
미사일 접근 시점보다 늦게 유인체가 방출되면 유도탄이 이미 추적락인 상태 → 회피 실패. 늦은 발사로 인해 회피 시도 자체가 무의미해짐.
가능한 원인
탐지/경보 지연(센서·처리 지연), 통신 지연, 의사결정 소프트웨어 지연, 유인체 발사 메커니즘 작동 지연.
기존 통제
로컬 센서와 중앙 경보의 동기화, 우선순위 스케줄링.
권장 안전요구
탐지→발사 경로의 최대 허용 지연(요구사항) 명시 및 타임아웃/타이머 검증. 실시간 시스템 성능 요구(선형 응답시간 보장) 및 지연 감지 시 자동 보상 절차(안전모드 전환 등).
Verification
실시간 성능 벤치마크, end-to-end latency 측정, worst-case timing 분석(MTC scheduling test).
성급한 손짓 – Early in time (조기 동작 — 너무 빨리 동작)
반대로, 너무 빨리 발사하는 건 어떨까? 미사일이 아직 오지도 않았는데 플레어가 떨어져 나간다. 탄약은 소진되고, 필요한 순간엔 남아 있지 않다. ‘과유불급’이란 말이 여기에 어울린다.
잠재적 위해
적 미사일이 아직 본격 추적하지 않을 때 유인체를 먼저 쓰면 유효성 저하; 자산·탄약 낭비; 아군·민간에게 잠재적 위험(예: 저공에서의 플레어 소각으로 인한 화재). 불필요한 사용으로 향후 결정적 순간에 자원 고갈.
가능한 원인
과민한 감지/알고리즘 노이즈, 잘못된 설정(임계값 낮음), 조작자의 오작동(오발).
기존 통제
임계값 설정, 운영 SOP(발사 조건), 인터락(사람의 승인 요구 등).
권장 안전요구
다중요건(센서 크로스체크) 만족 시만 자동 발사 허용; 오발 방지를 위한 인적 확인 또는 고신뢰 자동 판단 로직.
탄약·유인체 재고 관리 정책 및 발사 로그(누가 언제 왜).
Verification
False positive율 분석, 운영자 의사결정 로그 리뷰, 운용절차 준수 점검.
지나친 몸부림 – Too much action (과다한 동작 — 지나치게 많은 유인체 방출)
두려움에 휩싸여 버튼을 계속 누르는 상황을 떠올려보자. 플레어가 연이어 터지고, Nulka가 마구 방출된다. 하지만 결과는 자원의 낭비, 그리고 오히려 아군 시스템의 혼란이다. 방어는 신중해야 한다.
잠재적 위해
자원 고갈(발사체 소진) → 향후 방어 불능; 주변 환경 피해(화재, 오염); 아군 감지 시스템 오도.
과다 방출로 인한 아군·민항기의 오도 가능성(안전위협).
가능한 원인
제어 로직의 루프/버그(무한 반복 발사), 센서 노이즈로 인한 재발사, 잘못된 운영 모드.
기존 통제
발사 제한 수량 설정, 발사 간 최소 대기시간 설정.
권장 안전요구
발사 카운터·쿨다운 메커니즘, 임계 발사 수 초과 시 수동 재승인 요구.
주변 레이더/항공 교통 연동 알림(비전투구역 안전성 확보).
Verification
한계치(Quota) 테스트, 무결성 검사, 운영 데이터 기반 감사(usage analytics).
부족한 저항 – Too little action
반대로 너무 적게 대응하면? 플레어 한 발로는 충분히 눈을 속이지 못한다. Nulka 한 대로는 적의 여러 발의 미사일을 막아내지 못한다. 이 역시 실패다.
잠재적 위해
유인체가 충분치 않거나 세기가 약해 미사일을 오도하지 못함 → 플랫폼 피격.
가능한 원인
물자 부족(재고·유효기간), 발사기 파손으로 일부만 방출, 계산된 방출량 판단 오류.
기존 통제
정비/보급 프로세스, 발사 장치 상태 모니터링.
권장 안전요구
최소 유인체 효과 요구치 명세(신뢰구간)와 자동 점검·보충 프로세스.
예비 유인체 스톡 정책 및 전술적 보수 지침 포함.
Verification
기능성 테스트(소수·다량 조건), 재고·유효성 관리 감사.
이처럼 한순간의 불빛과 신호에 숨어 있는 실패 가능성은 다양하다. 그래서 엔지니어들은 단순히 ‘작동한다/안 한다’가 아니라, 언제, 얼마나, 어떻게라는 조건을 끝없이 따져 묻는다.
지연은 없는가?
너무 성급하지는 않은가?
충분히, 하지만 과하지 않게 동작하는가?
이 질문들을 정리하는 과정이 바로 FHA다. 그것은 마치 그림자 속까지 비추는 손전등처럼, 보이지 않는 위험을 드러내는 도구다.
전투기의 불빛(플레어)과 함정의 그림자(Nulka).
겉으로는 단순한 회피기술이지만, 그 안에는 수많은 만약의 순간과 보이지 않는 실패가 존재한다.
그리고 그 실패를 하나하나 짚어내는 과정이야말로 시스템 안전 엔지니어가 지닌 가장 강력한 방패다.