[Lobsters 요약] Microsoft MXC 내부 분석: AI 에이전트 코드 격리를 위한 다중 플랫폼 샌드박스 기술
44
설명
최근 AI 에이전트의 부상과 함께, 신뢰할 수 없는 코드를 안전하게 실행하는 샌드박싱 기술의 중요성이 커지고 있습니다. OpenAI의 Codex CLI, Anthropic의 Claude Cowork, Google의 GKE Agent Sandbox 등 다양한 솔루션이 등장했지만, OS 공급업체 차원의 통합된 네이티브 솔루션은 부재했습니다. Microsoft는 Build 2026에서 MIT 라이선스 기반의 오픈소스 프로젝트 MXC(Microsoft eXecution Container)를 공개하며 이러한 격차를 해소하고자 합니다. 이 글은 MXC의 내부 구조와 다양한 OS 환경에서 에이전트 코드를 격리하는 방식을 심층적으로 분석합니다.
### 배경 설명
AI 에이전트가 사용자 대신 코드를 실행하는 시나리오가 보편화되면서, 이 코드가 시스템에 미칠 수 있는 잠재적 위협을 최소화하는 것이 핵심 과제로 떠올랐습니다. 악의적인 코드나 버그가 있는 코드가 시스템 자원에 무제한으로 접근하는 것을 막기 위해 강력한 격리 메커니즘이 필수적입니다. 기존에는 각 애플리케이션 벤더가 OS 네이티브 프리미티브(macOS Seatbelt, Linux Landlock/seccomp)를 활용하거나, 자체 VM/컨테이너 환경을 구축하여 샌드박싱을 구현해왔습니다.
MXC는 이러한 파편화된 접근 방식에 대한 Microsoft의 통합적인 답변입니다. Windows, Linux, macOS 등 주요 운영체제 전반에 걸쳐 신뢰할 수 없는 코드(모델 출력, 플러그인, 도구 등)를 샌드박스 환경에서 실행할 수 있는 시스템을 제공합니다. 특히, 이 프로젝트가 오픈소스로 공개됨으로써 개발자들은 Microsoft가 OS 수준에서 코드 격리를 어떻게 설계하고 구현하는지에 대한 전례 없는 통찰력을 얻을 수 있게 되었습니다. 이는 단순히 AI 에이전트뿐만 아니라, 서드파티 플러그인, CI/CD 작업, 사용자 입력 코드 등 모든 종류의 '신뢰할 수 없는 코드'를 안전하게 실행해야 하는 광범위한 IT 환경에 중요한 시사점을 던집니다.
### MXC의 기본 구성 및 아키텍처
MXC는 세 가지 핵심 요소로 구성됩니다. 첫째, Windows의 `wxc-exec.exe`, Linux의 `lxc-exec`, macOS의 `mxc-exec-mac` 등 각 OS에 맞는 단일 네이티브 바이너리입니다. 둘째, 실행할 명령과 정책(파일 시스템 접근 권한, 네트워크 설정, UI 제한 등)을 기술하는 버전 관리되는 JSON 설정 파일입니다. 셋째, 이러한 설정을 구축하고 바이너리를 호출하는 TypeScript SDK(`@microsoft/mxc-sdk`)입니다. MXC 바이너리는 설정 파일을 읽고 적절한 격리 백엔드를 선택한 후, 정책을 해당 백엔드의 네이티브 강제 메커니즘으로 변환하여 명령을 실행하고 결과를 스트리밍합니다. 이는 순수한 실행 계층이며, WSL 이미지 풀링이나 Hyperlight 스냅샷 준비와 같은 VM 관련 작업은 MXC 외부에서 처리해야 합니다.
### 다양한 OS별 격리 백엔드
MXC는 각 OS의 고유한 격리 프리미티브를 활용하기 위해 10가지 이상의 백엔드를 제공합니다. Windows에서는 AppContainer, BaseContainer, Isolation Session, Windows Sandbox(Hyper-V VM), WSLC(WSL2 + OCI 컨테이너), NanVix/Hyperlight 마이크로 VM 등이 있습니다. Linux에서는 Bubblewrap(비특권 리눅스 네임스페이스)과 LXC(시스템 컨테이너)를 사용합니다. macOS에서는 Seatbelt(커널 샌드박스)를 활용합니다. 각 백엔드는 요청의 'containment' 필드에 따라 선택되며, 안정성 수준(Stable, Experimental)이 명시되어 있습니다. 이처럼 MXC는 단일 정책 모델을 다양한 OS별 격리 기술로 번역하여 적용하는 유연한 아키텍처를 가지고 있습니다.
### Windows 격리 백엔드 심층 분석
Windows의 기본 백엔드인 `ProcessContainer`는 AppContainer와 BaseContainer를 활용합니다. AppContainer는 보안 ID(SID), 기능(capabilities), Job Object를 통해 프로세스 격리를 구현하며, 파일 시스템 접근은 NTFS ACE(Tier 3) 또는 Brokered File System(BFS, Tier 2)을 통해 제어됩니다. `Isolation Session`은 최신 Windows 백엔드로, 별도의 에이전트 사용자 계정을 프로비저닝하여 워크로드를 실행하고, 명시적인 폴더 공유를 통해 접근을 제어합니다. `Windows Sandbox`는 일회용 Hyper-V VM을 사용하여 가장 강력한 격리를 제공하며, 호스트와 게스트 간의 TCP 연결을 통해 통신합니다. `WSLC`는 WSL2 마이크로 VM 내에서 OCI/Linux 컨테이너를 실행하며, 호스트 경로를 WSL 마운트 지점으로 변환하고 `WslcContainerVolume`을 통해 파일 시스템 정책을 적용합니다. 특히 `CreateProcessInSandbox`와 같은 새로운 API는 향후 Windows 컨테이너화의 방향을 제시합니다.
### Linux 및 macOS 격리 백엔드
Linux의 기본 백엔드인 `bubblewrap`은 `bwrap` 도구를 사용하여 비특권 리눅스 네임스페이스 격리를 구현합니다. `--unshare-user`, `--unshare-pid` 등의 인자를 통해 격리된 환경을 구축하고, `--ro-bind`, `--bind`, `--tmpfs`를 통해 파일 시스템 정책을 적용합니다. 네트워크 격리는 `--unshare-net`을 사용하거나 협력적 HTTP 프록시를 통해 이루어집니다. `LXC` 백엔드는 `lxc-*` CLI 도구를 사용하여 전체 LXC 시스템 컨테이너를 구동하며, `lxc.mount.entry`를 통해 파일 시스템 정책을, 컨테이너별 `iptables` 체인을 통해 네트워크 필터링을 구현합니다. macOS의 `seatbelt` 백엔드는 TinyScheme SBPL(Sandbox Profile Language) 프로파일을 생성하여 `sandbox_init()`으로 커널 샌드박스를 적용합니다. `deny default` 정책을 기반으로 파일 시스템, 네트워크, UI 접근에 대한 명시적인 허용 규칙을 정의합니다.
### 교차 설계 원칙 및 시사점
MXC의 모든 백엔드는 동일한 교차 플랫폼 정책 모델(파일 시스템, 네트워크, UI 제한)을 소비하고 이를 각 OS의 네이티브 강제 메커니즘으로 번역합니다. '기본적으로 거부(default-deny)' 원칙이 일관되게 적용되며, UI 정책은 기본적으로 비활성화되고 네트워크는 차단됩니다. 격리 강도는 백엔드에 따라 다르며, 커널 강제(AppContainer 토큰, Win32k 비활성화, 네임스페이스 분리)와 협력적 강제(프록시 환경 변수를 따르는 클라이언트만 필터링)가 혼재합니다. 이러한 설계는 MXC가 단순히 AI 에이전트뿐만 아니라, 모든 종류의 신뢰할 수 없는 코드를 안전하게 실행하기 위한 범용적인 컨테이너 시스템임을 보여줍니다.
### 가치와 인사이트
MXC는 개발자와 IT 전문가에게 신뢰할 수 없는 코드를 안전하게 실행할 수 있는 표준화된 다중 플랫폼 솔루션을 제공합니다. 이는 보안 취약점을 줄이고, 개발자가 복잡한 OS별 격리 메커니즘을 직접 구현할 필요 없이 일관된 정책 모델을 통해 샌드박스를 구성할 수 있게 합니다. 특히 오픈소스 프로젝트로서 Microsoft의 내부 보안 설계 원칙과 최신 OS 격리 기술에 대한 투명한 접근을 가능하게 하여, 보안 인프라를 구축하거나 공격하는 전문가들에게 귀중한 학습 자료가 됩니다. AI 에이전트, 플러그인, CI/CD 파이프라인 등 다양한 시나리오에서 코드 실행의 안정성과 보안을 크게 향상시킬 잠재력을 가지고 있습니다.
### 기술·메타
- Rust
- TypeScript
- JSON
- AppContainer
- BaseContainer
- Isolation Session
- Windows Sandbox (Hyper-V)
- WSL2 / WSLC (OCI containers)
- NanVix (WHP/KVM micro-VM)
- Hyperlight (Unikraft micro-VM)
- Bubblewrap (Linux namespaces)
- LXC (Linux containers)
- macOS Seatbelt (SBPL)
- Win32 API (CreateAppContainerProfile, DeriveCapabilitySidsFromName, CreateProcessW, SetInformationJobObject, SetEntriesInAclW, SetNamedSecurityInfoW, LoadLibraryExW, GetProcAddress)
- Windows Firewall COM API
- Brokered File System (BFS)
- FlatBuffer
- WinRT (Windows.AI.IsolationSession.IsoSessionOps)
- iptables
- TinyScheme (SBPL)
- PTY (Pseudo-Terminal)
### 향후 전망
MXC는 현재 '초기 프리뷰' 단계이며, 문서화된 여러 'rough edges'(예: `Experimental_` 접두사, 폴더 공유 필터의 임시 조치, 암호화되지 않은 TCP 채널)가 존재합니다. 그러나 `CreateProcessInSandbox`와 같은 새로운 OS API의 공개와 `Isolation Session`, `BaseContainer`와 같은 최신 백엔드는 Windows 컨테이너화의 미래 방향을 명확히 보여줍니다. 향후 MXC는 이러한 실험적 기능들이 안정화되고 일반에 공개되면서, AI 에이전트 및 기타 신뢰할 수 없는 코드 실행을 위한 사실상의 표준 샌드박싱 프레임워크로 자리매김할 가능성이 큽니다. 오픈소스 커뮤니티의 기여와 피드백을 통해 보안 및 기능이 더욱 강화될 것이며, 이는 경쟁 제품 및 서비스에도 영향을 미쳐 전반적인 보안 수준을 끌어올릴 것으로 전망됩니다.
📝 원문 및 참고
- Source: Lobsters
- 토론(Lobsters): [lobste.rs](https://lobste.rs/s/3kniw7/mxc_internals_how_microsoft_s_execution)
- 원문: [링크 열기](https://www.originhq.com/research/mxc-execution-containers-internals)
---
출처: Lobsters · [원문 링크](https://www.originhq.com/research/mxc-execution-containers-internals)
제목글쓴이조회
- [AI Breakfast] OpenAI는 6억 명 이상의 사용자를 대상으로 에이전트 슈퍼앱 전환을 추진합니다. 구글은 2026년 10월부터 SpaceX와 월 9억 2천만 달러 규모의 GPU 컴퓨팅 계약을 체결했습니다. Anthropic은 2025년 후반 모델을 능가하는 미공개 모델과 맞춤형 칩 개발에 집중하고 있습니다.[0]Nedai11
- [The Verge] 마이크로소프트 AI 총괄, '초지능 임박했지만 일자리는 빼앗지 않아' 선언[0]Nedai10
- [The Verge] 구글 NotebookLM, 제미니 3.5 업그레이드로 클라우드 기반 연구 역량 강화[0]Nedai12
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.