AI 모델이 생성한 코드, 서드파티 플러그인, 자동화 도구가 실무 시스템 안으로 밀려들면서 '믿을 수 없는 코드를 어디서 어떻게 실행할 것인가'라는 오래된 보안 문제가 다시 전면에 떠올랐다. 마이크로소프트가 공개한 MXC(Microsoft eXecution Containment)는 바로 이 지점을 겨냥한 샌드박스 코드 실행 시스템이다. 모델 출력, 플러그인, 도구처럼 출처를 온전히 신뢰하기 어려운 워크로드를 윈도우, 리눅스, macOS에서 격리 실행하는 것을 목적으로 한다.
MXC의 핵심 설계 사상은 '정책 기반(policy-driven)의 계층적 격리'다. 운영체제가 제공하는 네이티브 프로세스 샌드박스부터 완전한 가상머신(VM)에 이르기까지 여러 격리 백엔드를 두고, 이를 하나의 통일된 격리 모델과 타입이 지정된 SDK 뒤에 숨긴다. 애플리케이션이 실행 요청을 보내면 MXC가 요청을 검증하고, 적절한 백엔드를 선택한 뒤, 그 결과로 만들어진 컨테이너 안에서 워크로드를 띄운다. 개발자 입장에서는 플랫폼마다 다른 격리 메커니즘을 직접 다루지 않고도 동일한 추상화 위에서 작업할 수 있다는 뜻이다.
별도 서비스가 아니라 앱에 내장되는 의존성
주목할 점은 MXC가 독립 실행되는 서버나 데몬이 아니라 애플리케이션에 빌드되어 들어가는 SDK 의존성이라는 사실이다. 사용자는 저장소를 클론할 필요 없이 패키지 매니저로 SDK를 설치하면 된다. Node와 .NET 패키지는 네이티브 런타임 자산을 함께 포함하고, Rust 크레이트는 MXC SDK와 엔진, 선택한 백엔드를 소비 애플리케이션 안으로 함께 빌드한다. 즉 격리 실행 능력이 외부 프로세스가 아니라 앱 자체의 일부로 들어온다.
SDK를 앱에 임베드할 수 없는 상황을 위한 길도 열려 있다. wxc-exec.exe 같은 플랫폼별 실행기(executor) 바이너리는 안정적인 스키마로 정의된 JSON 형식의 컨테이너 생성 요청을 받아들인다. 테스트 용도이거나 SDK를 내장하기 어려운 환경에서 이 비(非)SDK 방식을 쓸 수 있다. 실제 통합을 시작할 때는 Rust, .NET, Node용 SDK 샘플과 표준 입출력을 스트리밍하는 실행 가능한 예제, 그리고 API 레퍼런스를 참고하도록 안내한다.
정책 튜닝과 '감사 모드'의 양날
MXC를 도입한 애플리케이션은 격리 규칙을 충분히 다듬기 전까지는 샌드박스 안에서 접근 거부 문제에 부딪히기 마련이다. 문서 역시 이 점을 솔직히 인정하며, 실행하려는 도구가 실제로 필요로 하는 파일과 권한을 파악하는 수단으로 감사(audit) 모드를 제시한다. 감사 모드는 접근 거부 실패를 찾아내고, 신뢰할 수 있는 도구가 요구하는 접근을 허용하는 ProcessContainer 정책을 역으로 구성하도록 돕는다. 관찰된 접근 기록을 바탕으로 정책 작성용 산출물을 생성하는 방식이다.
다만 여기에는 분명한 경고가 따른다. --audit 옵션은 분석 대상 워크로드에 대한 샌드박스 보안을 전부 꺼버린다. 따라서 신뢰할 수 없는 코드를 돌리는 데는 절대 사용해서는 안 된다. 감사 모드는 어디까지나 '신뢰하는' 도구의 정책을 재구성하기 위한 개발 단계 도구이며, 운영 환경에서 미지의 코드를 다루는 용도와는 철저히 구분해야 한다. 진단 출력이 필요할 때는 --debug 옵션을 쓰도록 안내하는데, 네이티브 실행기는 평소 표준 입출력과 표준 오류를 워크로드 전용으로 예약해 두기 때문이다.
텔레메트리는 다중 동의가 모두 충족돼야 작동
프라이버시 측면의 설계도 비교적 보수적이다. 공식 마이크로소프트 빌드는 선택적 진단 텔레메트리를 보낼 수 있지만, 이는 개별 실행이 옵트인하고, 윈도우 사용자가 명시적으로 동의했으며, 관리 정책이 수집을 허용하고, 애플리케이션이 격리된 워크로드 요청에서 텔레메트리 옵션을 켠 경우에만 작동한다. 관리자는 텔레메트리를 차단할 수는 있어도 사용자를 대신해 동의를 부여할 수는 없다. 로컬 오픈소스 빌드는 애초에 마이크로소프트로 데이터를 보내도록 구성되어 있지 않고, 비윈도우 플랫폼에서는 텔레메트리 자체가 아무 동작도 하지 않는다.
실무자 관점에서 MXC는 AI 도구와 플러그인 생태계를 다루는 팀에게 격리의 추상화 계층을 표준화할 수 있는 선택지를 제공한다. 다만 공개된 자료만으로는 각 백엔드의 성능 특성, 지원 OS 버전의 구체적 범위, 다른 샌드박스 솔루션 대비 오버헤드 같은 판단 근거가 충분히 드러나지 않는다. 격리 규칙 튜닝에 적지 않은 초기 비용이 든다는 점을 문서 스스로 인정하는 만큼, 도입을 검토하는 팀이라면 샘플과 개발 문서로 자사 워크로드에 맞는 정책을 실제로 구성해 보는 단계가 사실상 필수다. 소스 빌드는 네이티브 런타임을 직접 수정하거나 독립 실행기 바이너리를 쓸 때에 한해 권장된다.