2월의 마지막 날, 미국은 이란을 공격했고, 이후 이란은 보복에 나섰다. 중동 전역의 긴장이 폭발적으로 상승한 이 상황은 US-Iran conflict로 불리는 군사적 충돌의 연장선에 놓여 있다. 이란은 역내 미군 기지와 함께 이스라엘을 향해 미사일을 발사했다. 그리고 세계의 시선은 이스라엘의 다층 방공 체계에 집중되었다.
이스라엘은 3단계 방공 구조를 갖추고 있다.
단거리 로켓과 포탄을 요격하는 Iron Dome, 중거리 위협에 대응하는 David's Sling, 그리고 탄도미사일을 고고도에서 요격하는 Arrow 체계다. 이 구조는 단순한 무기 배열이 아니라, 탐지–추적–판단–우선순위 결정–요격으로 이어지는 통제 사슬의 계층적 설계다.
Iron Dome는 발사 직후의 단거리 위협을 탐지해 낙하지점을 예측하고, 인구 밀집 지역에 떨어질 가능성이 있는 목표만을 선택적으로 요격한다. 이는 자원 최적화를 전제로 하며, David’s Sling은 그보다 장거리의 순항미사일이나 전술 탄도미사일을 상대하고, Arrow는 대기권 밖 또는 상층에서 장거리 탄도미사일을 파괴하도록 설계되었다. 이 세 체계는 서로를 보완하며, 하나가 실패하더라도 다른 계층이 위험을 흡수하도록 의도되어 있다.
그러나 실제 교전 상황에서 일부 미사일이 방어망을 통과했다면, 우리는 무엇을 실패로 정의해야 하는가. 요격 확률의 통계적 한계인가? 포화 공격으로 인한 자원 고갈인가? 탐지 지연인가? 정치적 교전 규칙에 따른 발사 승인 지체인가? 아니면 애초에 “이 정도면 충분하다”고 판단한 설계 철학의 문제인가?
여기서 시스템 안전 감사의 출발점이 생긴다. 실패는 단일 부품의 고장이 아니라, 통제 구조 어딘가에서 발생한 균열일 가능성이 크다. 안전 감사는 그 균열의 위치를 묻는다. 레이더의 감지 범위인가, 알고리즘의 우선순위 로직인가, 운영자의 의사결정 체계인가, 혹은 전략적 가정 자체인가.
전쟁은 기술의 시험장이 아니라 가정의 시험장이다. 우리가 설정한 위협 모델, 동시다발 공격의 한계, 자원 소모 속도, 인간 판단의 안정성에 대한 믿음이 현실과 충돌하는 순간, 시스템의 진짜 구조가 드러난다.
따라서 시스템 안전 감사는 “왜 맞추지 못했는가”를 묻는 절차가 아니다. 그것은 “우리는 무엇을 통제하고 있다고 믿었는가”를 묻는 과정이다. 그리고 그 질문은 전쟁과 같은 극단적 상황에서 더욱 선명해진다.
시스템 안전 감사는 “규정 준수 확인”이 아니다. 오히려 시스템이 위험을 어떻게 인식하고, 어떻게 통제하며, 어떤 가정 위에서 운용되는지를 구조적으로 검증하는 활동이다. 전통적 품질 감사가 결과의 적합성을 본다면, 시스템 안전 감사는 통제 구조의 적절성을 본다. 여기서 핵심은 세 가지다.
- 위험 정의의 타당성 – 우리는 무엇을 위험으로 정의했는가?
우리는 항상 어떤 전제를 두고 설계한다. 위협의 규모, 동시다발 공격 가능성, 센서의 정확도, 운영자의 판단 능력. 감사는 이 전제가 여전히 유효한지 묻는다.
- 통제 수단의 충분성 – 정의된 위험을 줄이기 위한 통제는 충분한가?
안전은 구성요소의 신뢰성에서 나오지 않는다. 그것은 통제의 구조에서 나온다. Iron Dome의 실패 사례를 가정해 보자. 요격 미사일이 충분히 존재했더라도, 탐지·식별·우선순위 결정·발사 승인 과정 중 하나가 지연되면 전체 시스템은 실패로 인식된다.
- 운용 현실과의 일치성 – 설계 문서 속 통제가 실제 운용 환경에서도 작동하는가?
설계 문서와 실제 전장 환경 사이에는 언제나 차이가 있다. 감사는 그 간극을 확인하는 행위다.
이번 Iron Dome 실패 사례를 예로 들면, 감사는 단순히 “요격률이 몇 %인가”를 묻지 않는다. 대신 다음을 묻는다.
위협 모델은 최신 정보에 기반했는가?
동시 다발적 공격에 대한 가정은 현실적인가?
포화 공격 시 우선순위 결정 알고리즘은 정책과 일치하는가?
인간 운영자의 개입 여지는 적절했는가?
따라서 안전 감사는 “규정 준수 확인”이 아니라, “통제의 현실성 검증”이다.
시스템 안전 감사는 단순 체크리스트가 아니라, 구조화된 탐색 과정이다. 다음과 같은 단계로 진행할 수 있다.
Step 1: 감사 범위와 목적 정의
감사는 모든 것을 다루지 않는다. 어디까지를 시스템으로 볼 것인가? 이 범위를 잡는것이 중요하다.
Iron Dome의 경우, 레이더 탐지, 위협 분류 알고리즘, 요격 미사일 발사 통제, 통신 네트워크, 정치적 교전 규칙까지 포함할 것인지 결정해야 한다.
이 단계에서 이미 선택이 이루어진다. 시스템 경계를 좁게 정의할수록 감사는 쉬워지며 책임의 범위는 줄어들지만, 의미또한 줄어든다.
Step 2: 위험 모델 및 가정 검토
기존 위험 분석(STPA, FMEA, FHA 등)이 있다면 그 가정을 재검토한다. 단순히 기존 자료와 결과를 확인하는 단계가 아니다.
동시 위협 수는 몇 개인가?
오탐(false positive) 허용 수준은?
통신 지연은 최대 얼마까지 허용되는가?
이런 질문들은
동시다발 포화 공격
의도적 기만(Decoy)
사이버 공격에 의한 센서 지연
정치적 제약으로 인한 발사 승인 지연
등을 다시한번 보며, US-Iran 전면전 상황에서는 기존 위협 모델이 저강도 분쟁 기준으로 설정되었을 가능성이 있는지 확인해야한다. 감사는 “전제의 유효성”을 공격적으로 의심해야 한다.
Step 3: 통제 구조 분석
시스템 안전 엔지니어의 관점에서 가장 중요한 단계다. 여기서 핵심은 “누가 무엇을 통제하는가?”이다.
통제 루프는 완결되어 있는가?
피드백은 실시간인가?
인간과 자동화의 역할 분담은 명확한가?
Iron Dome 실패가 발생했다면, 단순히 미사일 성능 문제가 아니라 다음을 본다.
포화 공격 시 자원 할당 알고리즘의 의사결정 지연
상위 지휘 체계와의 통신 지연
정치적 교전 규칙(ROE)이 기술적 대응을 제한했는지 여부
이단계에서 감사는 기술, 조직, 정책을 하나의 통제 체계로 본다.
Step 4: 운영 환경과의 일치성 확인
문서 속 시스템과 실제 시스템은 다르다. 실제 교전 데이터, 근접 실패 사례(near miss), 경보 오탐률 등을 분석한다. Iron Dome의 일부 요격 실패가 단순히 기술적 확률 문제인지, 아니면 우선순위 알고리즘의 한계인지 구분해야 한다. 여기서 중요한 것은 숫자가 아니라 해석이다. 숫자는 사건을 설명하지만, 통제 실패의 구조를 설명하지는 않는다.
훈련은 실제 시나리오와 유사했는가?
경고 피로(alert fatigue)는 없었는가?
사이버 공격 가능성은 충분히 고려되었는가?
이런 질문들은 감사는 “운용 현실”을 묻는다. 시스템은 평시를 위해 설계되지만, 실패는 전시에서 발생한다.
Step 5: 독립적 판단 및 리스크 재평가
감사팀은 설계팀과 독립적이어야 한다. 이 단계에서는 다음 질문이 핵심이다.
“현재 통제 수준은 ALARP/SFARP 기준에서 정당화 가능한가?”
Iron Dome의 경우, 더 많은 요격체를 배치할 수 있었는지, 알고리즘을 개선할 시간과 자원이 있었는지, 그 비용이 사회적으로 수용 가능했는지를 검토한다.
시스템 안전 감사 이후의 이야기는 보고서 제출로 끝나지 않는다. 오히려 그 순간이 시작이다. 감사는 문제를 기록하기 위한 문서 작업이 아니라, 통제 구조를 다시 설계하기 위한 출발점이기 때문이다. 감사 결과에 따라 기술적 수정이 이루어지고, 운용 절차가 변경되며, 필요하다면 정책 자체가 개정된다. 동시에 우리는 모든 위험을 제거할 수 없다는 현실을 직시해야 한다. 줄일 수 없는 위험에 대해서는 그것이 무엇인지 명확히 규정하고, 왜 수용 가능한지 설명하며, 조직 차원에서 책임 있게 받아들여야 한다. 그리고 개선 조치가 실제로 효과를 내는지 재검증하고 지속적으로 모니터링하는 체계를 구축해야 한다.
만약 Iron Dome의 요격 실패 이후라면 조치는 더욱 구체적이어야 한다. 위협 모델을 재설계하여 동시다발 포화 공격을 기본 가정으로 삼을 것인지, 우선순위 결정 알고리즘을 수정해 자원 배분 논리를 강화할 것인지, 추가 요격 자산을 확보해 물리적 한계를 보완할 것인지 판단해야 한다. 더 나아가 다층 방공 체계 간 통합성을 점검하고, 정보 공유 및 국제 협력 체계를 강화하는 문제도 검토 대상이 된다. 이는 단순한 장비 보강이 아니라 통제 사슬 전체의 재구성이다.
감사 보고서는 통제 구조 재설계, 교전 규칙 수정, 알고리즘 검증 강화, 그리고 독립적 안전 검토 체계 구축으로 이어져야 한다. 여기서 핵심은 “조치를 했다”는 선언이 아니다. 왜 그 조치가 합리적이며, 어떤 위험을 줄였고 어떤 위험을 남겼는지 설명할 수 있어야 한다. 감사 이후의 단계는 기술적 개선이라기보다 의사결정 구조의 개선에 가깝다.
그러나 현실은 단순하지 않다. 군사 기밀 보호, 정치적 책임 문제, 예산 제약이 개입하면서 학습의 과정은 쉽게 왜곡된다. 감사의 목적은 비난이 아니라 학습이지만, 조직은 종종 책임 회피와 이미지 관리에 더 민감하다. 그래서 감사 이후의 단계가 가장 어렵다. 안전은 기술에서 완성되지 않는다. 오히려 실패를 인정하고 구조를 바꾸는 용기에서 완성된다.
시스템 안전 감사에는 한계가 있다.
1) 사후적 편향 (Hindsight Bias)
감사는 본질적으로 사후적 성격을 가진다. 실패가 발생한 이후 우리는 원인을 논리적으로 재구성하며 모든 것이 예측 가능했던 것처럼 설명하려는 유혹에 빠진다. 그러나 이러한 사후적 편향은 미래의 불확실성을 과소평가하게 만든다. 감사는 이미 존재하는 체계를 분석할 뿐, 아직 정의되지 않은 위협까지 완전히 포착할 수는 없다.
2) 문서 중심주의
감사는 문서를 중심으로 이루어진다. 절차서, 설계 보고서, 시험 결과, 승인 기록이 주요 분석 대상이 된다. 하지만 실제 사고는 종종 문서 밖에서 발생한다. 전장에서는 피로, 압박, 정보 지연, 예외적 상황이 겹치며 통제 사슬이 흔들린다. 예를 들어 Iron Dome과 같은 체계에서도 기술 사양은 완전해 보일 수 있으나, 포화 공격 상황에서의 실시간 의사결정은 문서가 가정하지 못한 변수를 만들어낸다.
3) 권력 구조의 영향
권력 구조와 정치적 영향은 감사의 깊이를 제한한다. 군사 시스템에서는 기술적 판단보다 전략적 메시지가 우선될 수 있다. US-Iran conflict과 같은 고강도 분쟁 상황에서는 실패의 원인을 투명하게 공개하는 것이 정치적으로 부담이 될 수 있으며, 그 결과 감사의 결론이 완화되거나 범위가 축소될 위험이 있다. 조직은 비판을 본능적으로 방어하고, 이는 학습의 기회를 줄인다.
이러한 한계를 극복하기 위해서는 몇 가지 구조적 노력이 필요하다. 첫째, 지휘 체계와 분리된 독립적 감사 기구를 확보해야 한다. 둘째, 기존 가정을 체계적으로 흔드는 “가정 도전 세션(Assumption Challenge Workshop)”을 정례화하여 위협 모델과 통제 논리를 반복적으로 검증해야 한다. 셋째, 실전 기반 시뮬레이션과 Red Team 운용을 통해 의도적으로 체계를 압박하고 취약성을 노출시켜야 한다. 넷째, 기술 분석과 정책 결정을 분리하지 않는 통합 감사 프레임워크를 구축해야 한다. 안전은 부품의 신뢰성만으로 결정되지 않기 때문이다.
결국 안전 감사의 질을 결정하는 것은 절차의 복잡성이 아니라 질문의 깊이다. 실패를 설명하는 능력이 아니라, 아직 발생하지 않은 실패를 상상하려는 용기. 그리고 무엇보다 실패를 숨기지 않는 문화가 있을 때 비로소 감사는 방어가 아니라 학습의 도구가 된다.
시스템 안전 감사는 단순히 결함을 찾아내는 절차가 아니다. 그것은 우리가 이 시스템을 어디까지 통제할 수 있다고 믿어왔는지, 그리고 그 통제의 한계에 대해 어디까지 책임질 준비가 되어 있는지를 묻는 과정이다. 예컨대 Iron Dome의 실패를 “요격률 90%”라는 수치로만 설명한다면 우리는 본질을 비켜가게 된다. 중요한 것은 성공한 90%가 아니라, 통과한 10%가 무엇을 의미하는지 묻는 일이다. 그것이 단순한 기술적 오차인지, 위협 모델을 축소해 정의한 우리의 가정 때문인지, 시스템 경계를 지나치게 낙관적으로 설정한 결과인지, 혹은 책임의 범위를 모호하게 남겨둔 조직적 선택 때문인지 성찰해야 한다. 특히 US-Iran conflict과 같은 극단적 갈등 환경에서는 요격 실패 자체보다 그 배후에 있는 사회–기술적 취약성이 더 분명하게 드러난다. 전쟁은 기술의 문제가 아니라 가정과 판단의 문제를 확대해 보여주기 때문이다. 감사는 완벽함을 보장하지 않는다. 그러나 적어도 우리로 하여금 이렇게 묻게 만든다. 우리는 무엇을 알고 있었는가, 그리고 그 사실을 알면서도 왜 그 지점에서 멈추었는가. 결국 감사란 시스템을 공격하기 위한 절차가 아니라 우리의 확신을 시험하는 장치이며, 시스템 안전 엔지니어에게 그것은 기술적 검토를 넘어서는 윤리적 선언에 가깝다. 안전은 계산으로 완성되지 않는다.
안전은 끝까지 질문하려는 태도에서 시작된다.