문서 중심 설계에서 실행 가능한 시스템 모델로 Ansys System Architecture Modeler와 SysML v2가 바꾸는 MBSE의 5가지 축

자율주행차, 도심항공모빌리티(UAM), 우주·방산 시스템과 같은 첨단 산업에서는 시스템이 점차 대형화·지능화되면서 구조적 복잡성이 빠르게 증가하고 있다. 하나의 시스템 안에 기계, 전기·전자, 제어, 소프트웨어 등 다양한 기술 영역이 결합되고, 수많은 구성요소가 서로 복잡한 인터페이스와 상호 연결성을 형성하기 때문이다. 특히 자율주행차에서는 센서와 제어기, 차량 네트워크, 소프트웨어가 유기적으로 동작해야 하며, UAM과 우주·방산 시스템에서는 비행체, 추진, 통신, 항법, 임무 시스템 등이 하나의 통합 시스템으로 운용되어야 한다. 이처럼 시스템을 구성하는 요소와 상호작용이 증가할수록 개별 구성요소의 성능만으로는 전체 시스템의 거동과 요구사항 충족 여부를 판단하기 어려워진다. 또한 하나의 설계 변경이 여러 하위 시스템과 인터페이스에 연쇄적인 영향을 줄 수 있어, 시스템 전체를 일관된 관점에서 정의하고 관리하는 방법론의 중요성이 더욱 커지고 있다. 하지만 기존의 문서 중심 개발 방식에서는 요구사항과 시스템 구조, 인터페이스, 설계 정보가 Word, Excel, PDF 및 개별 엔지니어링 도구를 사용하여 분산되는 경우가 많다. 시스템이 고도화되고 복잡해지면 이러한 방식으로는 정보 간의 관계와 변경에 따른 영향을 추적하기 어려워지고, 중요한 설계 또는 인터페이스 문제가 상세 설계나 시험 단계에서 뒤늦게 발견될 가능성도 높아진다. 이러한 복잡성을 체계적으로 관리하기 위한 접근 방법이 모델 기반 시스템 엔지니어링(Model-Based Systems Engineering, MBSE)이다. MBSE는 요구사항, 시스템 구조, 동작, 인터페이스 및 분석 정보를 하나의 시스템 모델을 중심으로 연결함으로써 복잡한 시스템을 보다 일관되게 정의하고, 설계 초기 단계부터 시스템 수준에서 검토하고 검증할 수 있도록 한다.

그림 1. 모델 기반 시스템 엔지니어링(Model-Based Systems Engineering, MBSE)

Ansys System Architecture Modeler(SAM)는 이러한 변화에 대응하기 위해 SysML v2를 기반으로 개발된 시스템 아키텍처 모델링 환경이다. 최신 SysML v2 표준, 웹 기반 협업, 개방형 API, 시뮬레이션 연결과 모델 실행을 결합하면서 MBSE를 단순한 시스템 다이어그램 작성 도구에서 실행 가능한 디지털 엔지니어링 환경으로 확장하려는 것이 핵심 방향이다.

그림 2. Ansys SAM(System Architecture Modeler)

1. SysML v2: 시스템 모델링 언어의 세대교체

Ansys SAM을 이해하기 위해서는 먼저 SysML v2의 변화를 살펴볼 필요가 있다. SysML v2는 SysML v1에 몇 가지 기능을 추가한 단순한 버전 업그레이드가 아니다. SysML v1이 UML을 기반으로 한 프로파일 형태였다면, SysML v2는 KerML(Kernel Modeling Language)을 기반으로 새롭게 정의된 메타모델을 사용한다. OMG(Object Management Group)는 SysML v2가 기존 SysML에 비해 정밀도(precision), 표현력(expressiveness), 사용성(usability), 상호운용성(interoperability), 확장성(extensibility)을 개선하도록 설계됐다고 설명한다. SysML 2.0과 KerML 1.0은 2025년 9월 공식 표준으로 채택되었으며. 특히 중요한 변화 중 하나는 그래픽 표현과 텍스트 표현을 함께 상호 변환이 가능한 표준 문법으로 확립했다는 점이다. 기존 MBSE 환경에서는 시스템 모델이 특정 모델링 도구의 그래픽 다이어그램에 강하게 종속되는 경우가 많았다. 반면 SysML v2는 동일한 모델을 그래픽뿐 아니라 표준화된 텍스트 형태로 표현할 수 있다. 이는 버전 관리, 모델 자동 생성, 스크립팅 및 API 기반 자동화에 유리하다. 이는 엔지니어가 모델을 직접 작성하는 것뿐 아니라 자동화 프로그램이나 AI가 시스템 모델을 생성하고 분석하는 워크플로도 가능하다는 것이다. SysML v2가 가져오는 가장 중요한 변화는 단순히 새로운 다이어그램을 제공하는 데 있는 것이 아니라 시스템 모델 자체를 보다 정형화되고 기계가 해석 가능한 엔지니어링 데이터로 변화시킬 수 있다는 것이다.

그림 3. SysML v2 Language-Graphical Notation 개요

2. 데스크톱 도구에서 웹 기반 협업 플랫폼으로

전통적인 MBSE 도구는 대부분 개별 엔지니어의 PC에 설치되는 데스크톱 애플리케이션을 중심으로 발전해 왔다. 이 방식은 강력한 모델링 기능을 제공하지만, 프로젝트 규모가 커질수록 버전 관리와 배포, 모델 공유 및 협업 관리에 어려움이 있다. Ansys SAM은 이를 웹 기반 시스템 아키텍처 모델링 환경으로 전환하였다. 사용자는 표준 웹 브라우저를 통해 SAM에 접속하며, 시스템 모델은 Ansys SE Platform을 중심으로 관리되어 개별 사용자가 별도의 데스크톱 애플리케이션을 설치하고 프로젝트 파일을 주고받는 방식이 아닌 실시간 동기화 기반의 모델 관리 방식을 사용한다. 여기서 중요한 점은 “인프라가 필요 없다”는 의미는 아니라는 것이다. SAM과 SE Platform은 퍼블릭 클라우드 환경뿐 아니라 기업 내부의 온프레미스 서버나 Air-Gap 환경에도 구축할 수 있도록 설계돼 있다. 즉, 사용자 측의 소프트웨어 설치와 프로젝트 관리 부담을 줄이는 동시에 기업의 보안 및 IT 정책에 따라 배포 방식을 선택할 수 있는 구조에 가깝다. 이러한 구조는 특히 여러 부서나 지역에 분산된 조직에서 의미가 크다. 프로젝트 접근 권한과 모델을 서버 중심으로 관리할 수 있기 때문에 조직 규모가 커지더라도 동일한 시스템 아키텍처를 중심으로 작업할 수 있다. MBSE가 개인 엔지니어의 모델링 도구에서 조직 차원의 엔지니어링 플랫폼으로 변화하는 것이다.

3. 실시간 협업: 파일 교환에서 ‘공유 시스템 모델’로

Ansys SAM의 또 다른 특징은 실시간 협업이다. Ansys는 여러 사용자가 동시에 동일한 시스템 모델 개발에 참여하고 다른 사용자의 변경 사항을 실시간으로 확인할 수 있도록 SAM을 설계했다. 공유 시스템 모델 저장소의 프로젝트에서는 이러한 협업 기능을 이용해 시스템 아키텍처를 중앙에서 관리할 수 있다. 이를 문서 작업에 비유하면 각 엔지니어가 별도의 파일을 수정한 뒤 이를 취합하는 방식에서 여러 사용자가 하나의 공유 문서를 중심으로 작업하는 방식으로 전환되는 것과 유사하다. 시스템 엔지니어링에서 이러한 변화의 의미는 단순한 공동 편집 이상의 의미를 갖는다. 시스템 요구사항, 구조, 인터페이스, 동작 및 분석 관계가 하나의 공유 모델에 연결되면 여러 부서가 서로 다른 버전의 시스템 정보를 참조하는 문제를 줄일 수 있다. 시스템 엔지니어, 소프트웨어 엔지니어, 안전 엔지니어와 해석 엔지니어가 동일한 시스템 아키텍처를 기준으로 업무를 수행하는 ASoT(Authoritative Source of Truth), 즉 신뢰할 수 있는 기준 모델을 구축할 수 있기 때문이다. 궁극적으로 MBSE에서 중요한 것은 ‘예쁜 시스템 다이어그램’을 만드는 것이 아니라 조직의 여러 엔지니어링 활동이 동일한 시스템 정의를 참조하도록 만드는 것이다.

4. 개방형 API와 시뮬레이션 연결: 디지털 스레드의 구축

시스템 모델이 실제 제품 개발의 중심이 되기 위해서는 시스템 아키텍처가 MBSE 도구 내부에 고립되어서는 안 된다. 요구사항 관리 도구, 상세 설계 도구, 물리 기반 시뮬레이션, 임무 분석, 소프트웨어 개발 및 안전 분석과 연결되어야 한다. SysML v2가 기존 SysML과 차별화되는 요소 가운데 하나도 바로 표준 API와 서비스 구조다. OMG는 SysML v2와 함께 ‘Systems Modeling API and Services’를 개방형 표준 API로 제정했으며, 이를 통해 시스템 모델과 다른 엔지니어링 애플리케이션 간의 상호운용성을 높이는 것을 목표로 하고 있다. Ansys SAM 역시 이러한 개방형 구조를 활용해 디지털 엔지니어링 생태계와의 연결을 확대하고 있다. 특히 Ansys ModelCenter와 SAM을 연결하면 시스템 모델의 요구사항 및 파라미터와 다양한 엔지니어링 분석 도구들을 연결할 수 있다. 이를 이용해 CAE 해석이나 자체 개발 프로그램의 결과를 시스템 요구사항 검증에 활용하고, 분석 결과를 다시 시스템 모델에 반영하는 워크플로를 구성할 수 있다. Ansys SAM은 ModelCenter를 통한 요구사항 검증, medini analyze를 통한 기능 안전 분석, Scade One과의 임베디드 소프트웨어 연계 등을 제공한다. 이와 함께 STK를 포함한 미션 엔지니어링 및 멀티피직스 해석과의 연결까지 디지털 엔지니어링 워크플로의 일부로 확대하고 있다.

SAM의 의미는 모든 도구를 하나의 애플리케이션으로 대체하는 데 있는 것이 아니라, 시스템 아키텍처를 중심으로 서로 다른 엔지니어링 도구를 연결할 수 있는 디지털 스레드의 중심점을 만드는 데 있다.

그림 4. Open Ecosystem

5. ‘그려 보는 모델’에서 ‘실행해 보는 모델’로

최근 SysML v2와 Ansys SAM에서 가장 주목할 변화는 시스템 모델을 단순히 표현하는 데서 벗어나 실행 가능한 모델로 발전시키려는 움직임이다. 전통적인 시스템 아키텍처 모델은 시스템의 구조와 인터페이스, 요구사항 및 동작을 정의하는 데 주로 사용됐다. 실제 시스템 성능과 동작을 확인하려면 별도의 시뮬레이션 모델을 구축해야 하는 경우가 많았다. Ansys는 SysML v2 Model Execution을 통해 이 간극을 줄이고 있다. 2026 R1에서는 SysML v2로 정의된 시스템 Behavior를 실행하면서 애니메이션 다이어그램, timing-accurate semantics, breakpoint 및 interactive debugging을 활용할 수 있는 초기 Model Execution 기능이 제공된다. 또한 STK와 같은 분석 도구를 실행 과정에 연결함으로써 시스템의 논리적 동작과 실제 임무·물리 기반 분석을 연계하는 방향으로 확장되고 있다. 이는 MBSE의 역할을 크게 바꿀 가능성이 있다. 시스템 아키텍처가 단순히 설계 정보를 설명하는 정적 모델이라면 오류를 발견하기 위해서는 결국 상세 설계나 별도의 시뮬레이션 단계까지 기다려야 한다. 반면 모델의 동작을 초기 아키텍처 단계부터 실행할 수 있다면 상태 전이, 이벤트 순서, 인터페이스 및 요구사항 사이의 문제를 보다 이른 시점에 검토할 수 있다. 물론 현재의 SysML v2 Model Execution을 모든 물리 현상을 직접 계산하는 멀티피직스 시뮬레이터와 동일하게 볼 수는 없다. 핵심은 시스템 Behavior와 전문 시뮬레이션 도구를 연결하는 실행 프레임워크에 가깝다. 예를 들어 위성 시스템의 운용 시퀀스는 SysML v2에서 정의하고, 궤도와 통신 환경은 STK에서 분석하며, 다른 시스템 성능은 별도의 물리 기반 해석 모델과 연결하는 형태다. 이처럼 시스템 모델과 시뮬레이션을 하나의 워크플로에서 연결하면 설계 후반에 발생하는 ‘Late Finding’을 줄이고, 보다 이른 단계에서 설계 대안을 비교하고 요구사항 충족 여부를 검토할 수 있다.

그림 5. Ansys MBSE Framework

MBSE의 다음 단계는 ‘모델을 만드는 것’이 아니라 ‘모델을 연결하고 실행하는 것’

SysML v2와 Ansys System Architecture Modeler의 의미를 단순히 “새로운 MBSE 도구가 등장했다”는 관점에서 보는 것은 충분하지 않다. 변화의 핵심은 엔지니어링 정보가 관리되는 방식 자체에 있다. 문서와 파일 중심이었던 시스템 정보를 정형화된 모델로 전환하고, 이를 웹 기반 환경에서 조직 전체가 공유하며, 개방형 API를 통해 요구사항과 소프트웨어, 안전 분석 및 CAE 시뮬레이션에 연결한다. 나아가 시스템의 Behavior를 실행함으로써 아키텍처 설계 단계에서부터 요구사항과 시스템 동작을 검증하는 방향으로 발전하고 있다. 이러한 변화는 MBSE가 단순한 시스템 설계 방법론에서 디지털 엔지니어링의 연결 계층(Integration Layer)으로 발전하고 있음을 보여준다.

앞으로는 개별 해석 도구의 정확성뿐만 아니라 요구사항이 시스템 아키텍처로 연결되고, 아키텍처가 소프트웨어와 시뮬레이션으로 이어지며, 그 결과가 다시 요구사항 검증으로 이어지는 디지털 연속성(Digital Continuity)을 얼마나 효과적으로 구축하는지가 더욱 중요해질 것이다. 시스템을 더 많이 문서화하는 것이 아니라 시스템을 하나의 연결된 엔지니어링 모델로 이해하고, 공유하고, 분석하고, 실행하는 것. 그것이 시스템의 복잡성이 빠르게 증가하는 시대에 MBSE가 향하고 있는 다음 단계다.