얼마 전 AI 관련 주제로 강연하는 한 엔지니어의 글에서 ‘사라질 수 있는 직업들’의 리스트를 본 적이 있다. 그중 유독 눈에 띄었던 것은 다름 아닌 소프트웨어 개발자였다. AI를 개발한 인재들이 결과적으로 자신의 밥줄을 잘라버리는 아이러니한 상황이 펼쳐지고 있다는 것이다. 여기서 자연스럽게 이런 질문이 따라온다. C#, JAVA, 그리고 수년간의 실무 경험과 숙련을 통해 쌓아 올린 엔지니어들은 과연 어떻게 대체되는가?
이 부분에 답하듯, 프롬프트 엔지니어링이라는 단어가 등장하며, 이제는 사람이 직접 수백, 수천 줄의 코드를 작성하기보다, AI에게 규칙과 의도를 정확히 전달해 프로그램을 만들어내는 방향으로 시장이 움직이고 있다. 이 변화는 소프트웨어 영역에만 국한되지 않는다. 시스템을 다루는 엔지니어들 사이에서도 이미 모델 기반 시스템 엔지니어링(Model-Based Systems Engineering, MBSE)으로 넘어가는 길목에 서 있다.
지난 수십 또는 수백 년간 항공, 철도, 방위, 산업 플랜트 등에서 다양한 안전 필수 시스템을 다뤄왔다. 시간이 지나가는 동안 수많은 방법론이 등장했고, 또 사라졌으나, 지금 마주한 변화는 단순한 도구의 전환이 아니라, 사고하는 방식 자체의 전환이라는 점에서 이전과는 질적으로 다르다. 그리고 이 전환의 연장선에 바로 모델 기반 안전 분석(Model-Based Safety Analysis, MBSA)이 있다.
MBSE(Model-Based Systems Engineering)는 흔히 “문서 대신 모델을 쓰는 시스템 엔지니어링”이라고 요약된다. 그러나 이 정의는 절반만 맞다. MBSE의 본질은 특정 도구를 사용하는 데 있지 않다. 그것은 시스템을 이해하고 통제하는 방식 자체를 바꾸는 사고의 전환에 가깝다.
전통적인 시스템 엔지니어링에서 시스템은 문서의 집합으로 존재했다. 요구사항 문서, 설계 문서, 인터페이스 정의서, 시험 문서, 안전 분석 문서가 각각의 파일과 도구에 흩어져 있었고, 이 문서들을 “잘 관리하는 것”이 엔지니어링 역량으로 여겨졌다. 그러나 시간이 지날수록 문서들은 서로 어긋났고, 변경이 발생할 때마다 “어느 문서가 최신인가”라는 논쟁이 반복되었다.
현실에서는 항상 비슷한 문제가 발생했다. 설계는 바뀌었지만 안전 분석은 그대로 남아 있었고, 요구사항은 충족되었다고 기록되어 있지만 시험 결과와는 연결되지 않았다. 안전팀의 엑셀과 설계팀의 도면이 서로 다른 시스템을 설명하는 상황도 낯설지 않았다.
MBSE는 이 단절을 구조적으로 제거하려는 시도다. 시스템을 문서로 쪼개 관리하는 대신, 요구사항, 기능, 논리 아키텍처, 물리 아키텍처, 인터페이스, 운용 개념을 하나의 중앙 모델로 통합한다. 이 모델은 단순한 그림이 아니다. 요소 간의 관계, 제약 조건, 그리고 시스템의 행위를 포함한 살아 있는 시스템 표현이다.
이러한 접근이 특히 항공, 자동차, 방산과 같은 안전 필수 산업에서 빠르게 전제가 된 이유는 명확하다. 시스템이 지나치게 복잡해졌기 때문이다. 수천 개의 요구사항, 수백 개의 인터페이스, 소프트웨어와 하드웨어, 인간과 자동화가 얽힌 환경에서 더 이상 사람의 기억과 문서만으로는 시스템 전체를 이해할 수 없다. 이 영역에서 MBSE는 효율을 높이기 위한 선택지가 아니라, 복잡성을 관리하기 위한 생존 전략에 가깝다.
안전 필수 산업에서 MBSE가 특히 중요한 이유는, 이것이 단순한 설계 방법론을 넘어 모델 기반 안전 분석(Model-Based Safety Analysis, MBSA)의 토대가 되기 때문이다.
과거의 안전 분석은 시스템 설계가 어느 정도 고정된 이후에 수행되는 경우가 많았다. 별도의 안전 팀이 엑셀과 워드 파일을 사용해 FMEA, FTA, HAZOP과 같은 분석을 수행했고, 그 결과는 설계 문서와 느슨하게 연결되거나 아예 분리된 상태로 관리되었다. 이 구조에서 안전 분석은 자연스럽게 설계를 따라가는 ‘사후 검증 문서’ 혹은 ‘규제 대응 산출물’로 취급될 수밖에 없었다.
MBSA는 이 구조를 근본적으로 바꾼다. MBSE 환경에서는 안전 데이터와 안전 요구사항이 시스템 모델 내부에 직접 통합된다. 안전 분석은 더 이상 독립된 엑셀 시트나 보고서가 아니라, 시스템 모델의 한 구성 요소가 된다. 다시 말해, 안전은 설계 외부에서 확인되는 속성이 아니라, 설계 그 자체에 내재된 특성이 된다.
1. 안전 요구사항과 추적성
가장 대표적인 변화는 안전 요구사항과 추적성이다. ISO 26262나 DO-178C와 같은 안전 요구사항은 모델 안에서 시스템 컴포넌트, 기능, 그리고 시험 케이스와 직접 연결된다. 특정 컴포넌트가 변경되면, 그 변경이 어떤 안전 요구사항과 안전 케이스에 영향을 미치는지 모델이 즉시 보여준다. 이는 단순한 편의 기능이 아니다. “이 변경이 안전에 영향을 미치는가?”라는 질문에 대해, 더 이상 사람의 기억이나 경험에 의존하지 않고 모델이 구조적으로 답하도록 만드는 체계다.
2. 안전 분석 산출물의 자동화와 동기화
또한 MBSE 환경에서는 FMEA나 FTA와 같은 전통적인 안전 분석 산출물이 고립된 문서로 남지 않는다. 논리 아키텍처를 기반으로 분석이 생성되거나 모델과 동기화되고, 시스템 기능과 고장 모드는 설계 요소와 직접 연결된다. 설계가 변경되면 분석 결과도 함께 업데이트된다. 이때 안전 분석은 설계의 ‘사본’이 아니라, 설계와 동시에 움직이는 그림자에 가깝다.
3. 고장 시나리오 시뮬레이션
MBSA의 또 다른 핵심은 고장 시나리오에 대한 모델 기반 시뮬레이션이다. MBSE 모델은 정적인 구조도가 아니라, 시스템의 행위를 포함한다. 엔지니어는 모델을 이용해 고장 주입(Fault Injection)을 수행하고, 특정 컴포넌트가 실패했을 때 시스템이 어떻게 반응하는지를 시뮬레이션할 수 있다.
예를 들어 드론이 추진력을 상실했을 경우, 어떤 기능이 먼저 영향을 받는지, 제어 로직은 어떻게 대응하는지, 안전장치는 충분히 빠르게 작동하는지를 물리적 시험 이전에 검증할 수 있다. 이는 안전 문제를 가장 비용이 낮은 설계 단계에서 발견하게 해 준다.
4. 위험의 시각화
마지막으로 MBSA는 위험을 시각적으로 드러낸다. “위험하다”거나 “문제가 될 수 있다”는 모호한 문장 대신, 두려운 사건(Feared Event)이 무엇인지, 그 사건이 어떤 경로로 전파되는지, 어떤 조건에서 차단되는지가 시퀀스 다이어그램과 행위 다이어그램으로 표현된다. 위험은 더 이상 해석의 대상이 아니라, 모두가 공유하는 구조와 흐름의 사실이 된다.
이 순간부터 안전은 주장이나 설득의 문제가 아니다. 안전은 모델이 강제하는 속성이 되며, 시스템 설계와 분리될 수 없는 하나의 구조가 된다.
1단계: 시스템 경계와 운용 개념 모델링
가장 먼저 해야 할 일은 시스템의 경계와 운용 개념을 명확히 모델로 표현하는 것이다. 여기에는 정상 운용뿐 아니라 비정상 상황, 고장 상태, 인간과의 상호작용까지 포함되어야 한다. 이 단계에서 이미 많은 위험이 드러난다.
2단계: 요구사항과 기능의 모델 기반 연결
요구사항을 단순한 문장이 아니라, 기능과 추적 가능한 형태로 연결한다. 안전 요구사항 역시 이 단계에서 일반 요구사항과 동일한 위상을 가진다. 안전은 부가 조건이 아니라, 시스템 요구사항의 일부다.
3단계: 논리·물리 아키텍처와 안전 연계
논리 아키텍처와 물리 아키텍처를 모델링하면서, 각 요소에 안전 속성을 부여한다. 이 과정에서 FMEA나 FTA와 같은 분석이 자동 생성되거나 모델과 동기화된다. 분석 결과는 다시 아키텍처 설계에 피드백된다.
4단계: 고장 시나리오 시뮬레이션
모델을 이용해 고장 주입(Fault Injection)을 수행하고, 특정 컴포넌트 실패 시 시스템이 어떻게 반응하는지 시뮬레이션한다. 이는 물리적 시험 이전에 안전장치의 유효성을 검증할 수 있게 해 준다.
5단계: 디지털 스레드 유지
설계, 안전 분석, 시험, 인증까지 모든 결과를 하나의 디지털 스레드로 유지한다. 이는 인증 과정에서 강력한 근거 자료가 된다.
MBSE는 시스템을 “더 잘 문서화하는 방법론"이 아니다. 시스템을 사람의 기억과 해석에 맡기지 않기 위해 설계된 구조이며, 안전을 개인의 숙련이나 주의가 아니라 모델 그 자체에 내재시키는 방식이다. 이 구조 위에서 비로소 모델 기반 안전 분석(MBSA)은 자연스럽게 작동할 수 있게 된다.
전통적인 방식에서는 변경이 발생할 때마다 수많은 문서를 수정해야 했고, 그중 일부는 항상 누락되었다. 안전 분석은 설계 변경을 따라가지 못했고, 결국 사고 조사 보고서에서 “문서는 존재했으나 실제 시스템과 불일치했다”는 문장이 반복되었다.
MBSE와 MBSA 환경에서는 모델이 단일 진실의 원천(Single Source of Truth)이 된다. 안전 분석은 설계와 동시에 진화하며, 변경의 영향은 즉시 가시화된다. 이는 단순히 효율의 문제가 아니라, 사고 가능성을 구조적으로 낮추는 변화다.
MBSE와 MBSA는 분명 시스템 안전 엔지니어링의 큰 진보이다. 그러나 이 방법론들이 모든 안전 문제를 해결해 주는 만능 해법이라고 믿는 순간, 우리는 또 다른 형태의 맹점을 만들어낸다. 지난 수십 년간의 사고 분석이 반복해서 보여주듯, 사고는 언제나 우리가 “이미 해결했다고 믿은 영역”에서 발생해 왔다.
MBSE와 MBSA 역시 예외가 아니다.
1. 모델은 현실을 대체하지 못한다
MBSE와 MBSA의 가장 근본적인 한계는 명확하다. 모델은 현실이 아니라, 현실에 대한 선택된 표현이라는 점이며, 모델에는 반드시 경계가 존재하고, 가정이 들어가며, 단순화가 포함된다. 무엇을 포함할지, 무엇을 제외할지는 결국 사람이 결정한다. 잘못된 가정, 누락된 상호작용, 과도한 단순화는 모델 안에서도 그대로 유지된다.
과거에도 우리는 “완벽해 보이는 분석”을 수없이 만들어 왔다. FMEA는 모든 고장 모드를 다뤘고, FTA는 논리적으로 닫혀 있었으며, 절차서는 규정에 완벽히 부합했다. 그럼에도 사고는 발생했다. 이유는 단순하다. 분석이 틀려서가 아니라, 분석의 범위 밖에서 사고가 발생했기 때문이다. MBSE와 MBSA 역시, 보지 않기로 선택한 영역에 대해서는 아무 말도 해주지 않는다.
2. 인간과 조직은 여전히 모델 밖에 있다
MBSE와 MBSA는 기술 시스템을 다루는 데 매우 강력하지만, 조직, 문화, 압박, 권력 구조와 같은 요소를 완전히 포착하지는 못한다.
일정 압박으로 인해 우회되는 절차
형식적으로 수행되는 리뷰
“이번엔 괜찮을 것”이라는 암묵적 합의
책임이 불분명한 조직 구조
이러한 요소들은 수많은 사고에서 결정적인 역할을 해왔지만, 대부분의 MBSE 모델에서는 주변부로 밀려나거나 아예 표현되지 않는다. 인간은 여전히 블록 다이어그램의 ‘외부 행위자’로 단순화되고, 조직은 명확한 의사결정 구조를 가진 이상적인 존재로 가정된다.
과거의 사고 분석이 “인적 오류”라는 말로 책임을 축소했듯, MBSE 환경에서도 우리는 모델에 담기지 않는 인간적·조직적 현실을 과소평가할 위험을 안고 있다.
3. ‘자동화된 안전’이라는 착각
MBSA는 FMEA, FTA, 시나리오 분석을 자동 생성하거나 동기화할 수 있다. 이는 분명 강력한 장점이다. 그러나 동시에 위험한 착각을 낳기도 한다.
모델이 만들어낸 분석 결과는 언제나 그 모델이 가진 사고의 한계를 그대로 반영한다. 자동으로 생성된 분석은 빠르고 정합적일 수 있지만, 그것이 곧 충분하거나 완전하다는 의미는 아니다.
과거에도 우리는 “모든 체크리스트를 완료했다”는 이유로 안심했다. 그러나 체크리스트는 질문을 대신 생각해 주지 않는다. MBSA 역시 마찬가지다. 모델은 답을 계산해 줄 수는 있지만, 어떤 질문을 던져야 하는지는 여전히 사람이 결정해야 한다.
4. 아직 보이지 않는 미래의 위험
MBSE와 MBSA는 현재 우리가 이해하고 있는 시스템 구조와 상호작용을 기반으로 한다. 그러나 복잡한 시스템에서 가장 치명적인 사고는 종종 아직 개념화되지 않은 상호작용에서 발생한다.
새로운 운용 개념의 등장
예상치 못한 시스템 결합(System-of-Systems)
사회적·정치적 압력의 변화
기술은 동일하지만 맥락이 달라진 환경
이러한 변화는 현재의 모델로는 명확히 표현되지 않는다. 우리는 언제나 미래를 과거의 언어로 모델링한다. 이는 피할 수 없는 한계다.
이전에도 그랬다. 설계 당시에는 “합리적”이었던 가정이, 수년 후 완전히 다른 위험의 출발점이 되었다. MBSE와 MBSA는 이 문제를 줄여주지만, 제거하지는 못한다.
5. 방법론보다 중요한 것은 질문이다
가장 큰 한계는 아이러니하게도 기술이 아니라 태도에 있다. MBSE와 MBSA를 도입했다고 해서 안전이 확보되었다고 믿는 순간, 조직은 질문을 멈춘다.
“이 모델이 무엇을 보여주지 않는가?”
“이 구조는 누구에게 불리한가?”
“이 가정이 틀렸을 가능성은 없는가?”
이 질문이 사라질 때, 가장 정교한 모델도 위험한 침묵을 만들어낸다.
사고 보고서는 늘 “예상하지 못했다”는 문장으로 시작하게 된다. 대부분의 사고는 예측 불가능해서가 아니라, 보지 않기로 선택했기 때문에 발생한다는 점을 고려하면, 다양한 기술을 사용하여도 사고가 사라지는 일은 없을 것이다. 결국 다시 말해 MBSE와 MBSA는 사고를 없애지 않는다. 이 방법론들은 해답이 아니라, 시스템을 다루는 기준을 바꾼 것이며, 문서가 아니라 구조로, 주장 대신 관계로, 신뢰가 아니라 증거로 시스템을 설명하라는 요구다. 또한 기술은 변해도 사고의 본질은 변하지 않는다. 시스템은 언제나 인간의 이해를 초과하고, 그 초과된 지점에서 사고는 발생한다. MBSE와 MBSA는 이 간극을 줄이려는 시도일 뿐, 제거하지는 못한다.
안전은 모델 안에 있지 않다. 안전은 모델 밖에서 시작해 잠시 모델 안에 머물다 다시 현실로 돌아간다. 따라서 안전은 도구를 믿는 행위가 아니라, 도구의 한계를 인식하는 태도에서 성립한다.
시스템 안전은 결국 도구의 문제가 아니라, 우리가 무엇을 보려 하는가에 대한 선택의 문제다.