Microsoft MXC 공개, Copilot CLI도 쓰는 에이전트 격리

AI 요약

• 무슨 일: Microsoft가 Build 2026에서 MXC, Windows 365 for Agents, Aion 1.0 로컬 모델을 묶어 Windows 에이전트 실행 환경을 발표했습니다.
  • MXC는 파일, 네트워크, UI 접근을 정책으로 선언하고 agent 실행을 sandbox backend에 연결하는 early preview SDK입니다.
• 의미: GitHub Copilot CLI가 process isolation을 채택했고, Windows는 agent identity와 Cloud PC 실행을 Agent 365 관리면에 붙입니다.
• 주의점: MXC GitHub README는 현재 profile을 security boundary로 취급하지 말라고 경고합니다.
  • Build 블로그는 Windows 365 for Agents GA를 말하지만, Microsoft Learn 문서는 2026년 5월 1일 기준 public preview로 남아 있습니다.

Microsoft가 2026년 6월 2일 Build 2026 Windows Developer Blog에서 Windows를 AI 에이전트를 만들고 실행하는 플랫폼으로 다시 설명했습니다. 발표 목록은 Coreutils for Windows, WSL containers, Intelligent Terminal, Windows Development Skills, Windows 365 Developer configuration까지 넓습니다. AI 개발자에게 가장 직접적인 부분은 Microsoft Execution Containers(MXC), Windows 365 for Agents, Agent 365와 연결되는 agent identity입니다. Windows가 에이전트에게 "무엇을 실행할 수 있는가"와 "그 행동을 누구에게 귀속할 것인가"를 OS와 Cloud PC 단위에서 다루겠다는 발표입니다.

이번 발표는 코딩 모델 점수나 새 LLM 이름보다 실행 위치를 앞에 둡니다. Microsoft는 MXC를 파일, 네트워크, UI 접근을 선언하고 런타임에서 강제하는 policy-driven execution layer라고 소개했습니다. 같은 글에서 GitHub Copilot CLI가 fast process isolation을 채택했다고 적었고, session isolation은 에이전트 실행을 사용자 데스크톱, 클립보드, UI, 입력 장치와 분리한다고 설명했습니다. 에이전트가 터미널 명령을 실행하고, 브라우저를 열고, 파일을 고칠수록 이 경계가 실제 제품 기능이 됩니다.

MXC GitHub 저장소는 발표보다 더 조심스러운 언어를 씁니다. README는 MXC를 Windows, Linux, macOS에서 untrusted code, model output, plugins, tools를 실행하기 위한 sandboxed code execution system이라고 설명합니다. backend 목록에는 ProcessContainer, Windows Sandbox, LXC, Bubblewrap, macOS Seatbelt, MicroVM, Hyperlight, IsolationSession, WSLC가 들어갑니다. 구성은 JSON schema와 TypeScript SDK로 연결됩니다. 개발자가 정책을 선언하고, SDK가 platform-specific sandbox backend로 옮기는 구조입니다.

저장소의 경고 문구는 기사에서 빼면 안 됩니다. MXC repository는 early preview이며 현재 SDK가 생성하는 일부 policy가 과도하게 허용적일 수 있다고 적습니다. 더 강한 문장은 "현재 MXC profile을 security boundary로 취급하지 말라"는 경고입니다. Microsoft의 Build 발표는 Windows를 신뢰할 수 있는 에이전트 플랫폼으로 포지셔닝하지만, 공개 저장소 단계의 MXC는 아직 보안 경계로 운영할 수 있는 완성품이 아닙니다. 지금의 실무 판단은 "미래 방향을 보여주는 SDK preview"와 "운영 보안 통제"를 분리하는 쪽이 맞습니다.

개발자가 바로 확인할 수 있는 세부는 schema와 platform support입니다. MXC README는 0.6.0-alpha를 새 코드에서 선택할 stable schema로 제시하고, Windows 11 24H2 이상, Linux x64/ARM64, macOS ARM64/x64를 문서화합니다. Windows 기본 backend는 processcontainer이고, Linux는 bubblewrap, macOS는 seatbelt로 이어집니다. experimental backend에는 windows_sandbox, wslc, microvm, isolation_session, hyperlight가 포함됩니다. 즉 Microsoft는 한 가지 sandbox 제품을 내놓기보다 여러 격리 수준을 하나의 policy model 뒤에 두려 합니다.

이 구조가 코딩 에이전트에 필요한 이유는 권한의 단위가 IDE plugin을 넘어섰기 때문입니다. Claude Code, Codex, Copilot CLI, Cursor, Windsurf 같은 도구는 저장소 파일을 읽고, command line을 실행하고, test runner를 돌리고, 네트워크로 패키지를 받습니다. 에이전트가 실패하면 단순히 답변이 틀리는 것이 아니라 잘못된 파일 수정, credential 노출, clipboard 접근, UI spoofing, 내부 시스템 접속으로 이어질 수 있습니다. Windows 발표가 network, filesystem, UI policy를 함께 적은 이유도 여기에 있습니다.

Windows 365 for Agents는 이 문제를 로컬 sandbox가 아니라 Cloud PC 실행 환경으로 풉니다. Build 블로그는 Windows 365 for Agents가 Agent 365 안에서 일반 제공된다고 발표했습니다. 에이전트가 앱을 열고, UI를 탐색하고, 입력을 넣고, 데이터를 처리하는 multi-step workflow를 Cloud PC에서 수행한다는 설명입니다. Microsoft Learn 문서는 이 제품을 Agent 365의 execution layer로 설명합니다. API나 connector만으로 끝나지 않는 작업에서 Cloud PC를 호출해 full Windows session을 제공한다는 구조입니다.

여기에도 날짜 확인이 필요합니다. Build 블로그는 2026년 6월 2일 글에서 Windows 365 for Agents를 "now generally available within Agent 365"라고 설명합니다. 반면 Microsoft Learn의 Windows 365 for Agents in Agent 365 문서는 2026년 5월 1일 마지막 업데이트 기준으로 public preview라고 표시합니다. 두 문서는 서로 다른 시점의 상태를 반영할 수 있습니다. 실무 팀은 계약, tenant availability, 지역 제한, 라이선스 FAQ를 기준으로 다시 확인해야 합니다. 기사 제목에서 GA를 단정하지 않은 이유도 이 차이 때문입니다.

Agent 365와 붙는 부분은 identity입니다. Microsoft는 Windows가 agent activity를 local ID 또는 Entra-backed cloud provisioned identity에 귀속해 사람과 agent를 구분하게 한다고 설명했습니다. Entra, Intune, Defender, Purview가 runtime protection과 policy 관리에 들어갑니다. 에이전트 보안에서 중요한 질문은 "모델이 안전한가"만이 아닙니다. "누가 어떤 identity로 어떤 파일을 열었고, 어떤 네트워크에 접근했고, 어떤 UI action을 수행했는가"가 감사와 incident response의 기본 단위가 됩니다.

이 발표가 GitHub Copilot CLI와 연결되는 부분도 작지 않습니다. Windows 블로그는 fast process isolation이 Copilot CLI에 채택됐다고 적었습니다. GitHub Docs의 Copilot sandbox 설명은 Copilot이 도구 실행, command 실행, file modification을 대신할수록 isolation, portability, policy control이 필요하다고 설명합니다. Microsoft 계열 제품 안에서 "agent가 코드를 고친다"는 문장은 이제 모델 capability보다 execution platform, policy, billing, identity까지 포함하는 문장으로 바뀌고 있습니다.

Intelligent Terminal은 이 방향을 개발자 화면에 붙입니다. Microsoft DevBlogs의 Intelligent Terminal 0.1 발표는 Windows Terminal 기반 경험에 agent pane을 붙이고, ACP(Agent Communication Protocol)를 통해 command failure context를 에이전트에 전달한다고 설명합니다. 설치된 agent가 없으면 GitHub Copilot을 시작점으로 쓸 수 있습니다. 터미널에서 오류가 발생했을 때 agent pane이 context를 받아 수정 제안을 내고, 사용자가 실행할 수 있는 흐름입니다. 이 기능은 preview지만, 에이전트가 shell context를 읽는 방식이 제품 UI 안으로 들어오는 예입니다.

또 다른 축은 로컬 모델입니다. Microsoft는 Aion 1.0 Instruct와 Aion 1.0 Plan을 발표했습니다. Aion 1.0 Instruct는 Edge Insider channel에서 preview로 시작하고 2026년 7월 Hugging Face open weights 공개를 예고했습니다. Aion 1.0 Plan은 14B parameter, 32K context의 reasoning and tool-calling model로 설명됩니다. capable device의 Windows inbox component로 제공돼 intent 해석, tool 호출, file management, sub-agent orchestration을 로컬에서 수행한다는 주장입니다.

로컬 모델 발표는 비용 문제와 연결됩니다. Windows 블로그는 agentic workflow가 continuous compute를 요구하고 cloud cost를 키운다고 적었습니다. Microsoft는 frontier model은 frontier problem에 쓰고, 나머지는 로컬에서 돌리는 tiered execution을 말합니다. GitHub Copilot CLI의 /fleet 예시는 primary agent가 cloud에서 plan을 만들고, task complexity를 평가한 뒤 일부 subtask를 local model에 위임하는 방식으로 소개됐습니다. 이 문장은 아직 제품 세부보다 방향성에 가깝지만, agent runtime이 "클라우드 모델 하나"에서 "cloud planner plus local worker"로 나뉘는 설계를 보여줍니다.

개발자 팀이 지금 바로 얻는 행동 항목은 세 가지입니다. 첫째, coding agent 도입 문서에서 파일, 네트워크, shell, UI, clipboard 접근을 따로 분류해야 합니다. 둘째, local sandbox와 Cloud PC 실행을 같은 위험 등급으로 취급하지 말아야 합니다. 셋째, agent identity와 audit log가 없는 자동화는 production workflow로 올리기 어렵다는 기준을 세워야 합니다. MXC가 아직 security boundary가 아니라는 경고는 이 기준을 낮추라는 말이 아니라, preview SDK와 운영 정책을 구분하라는 말입니다.

이번 발표는 Microsoft만의 독립 행보라기보다 에이전트 실행 인프라 경쟁의 일부입니다. Vercel Sandbox, E2B, Modal sandbox, GitHub cloud sandbox 같은 도구는 이미 agent code execution을 격리된 환경에서 다루려 합니다. Microsoft의 차이는 Windows desktop, Intune, Entra, Cloud PC, Copilot CLI, Agent 365를 한 묶음으로 연결한다는 점입니다. enterprise Windows fleet을 가진 조직에서는 이 연결이 새 도구 선택보다 procurement, policy, audit의 문제로 들어갑니다.

커뮤니티 반응은 아직 제품 성숙도만큼 조용합니다. Build 발표 직후 Hacker News나 GeekNews에서 MXC 자체에 대한 깊은 토론은 많이 보이지 않았습니다. Reddit 쪽에서는 Agent 365 라이선스, agent version 배포, 관리 콘솔의 identity 표시 같은 운영 질문이 올라옵니다. 이 반응은 자연스럽습니다. MXC처럼 실행 경계를 다루는 발표는 demo보다 tenant 설정, policy propagation, false positive, developer friction에서 평가가 갈립니다.

한국 개발자에게 이 발표가 중요한 지점은 Windows 자체보다 에이전트 운영 언어입니다. "AI가 코드를 짠다"는 문장은 이미 낡았습니다. 2026년의 질문은 AI가 어떤 identity로 실행되는지, 어느 sandbox에서 shell을 여는지, 외부 네트워크가 막혀 있는지, 사람이 넘겨받을 수 있는지, 사고 후 어떤 로그로 복기할 수 있는지입니다. Microsoft는 Build 2026에서 이 질문에 Windows식 답을 내기 시작했습니다. 다만 MXC의 early preview 경고와 Windows 365 for Agents 문서 상태를 보면, 지금 필요한 태도는 도입 선언보다 작은 범위의 검증입니다.

현실적인 검증 순서는 간단합니다. 내부 저장소 하나를 골라 에이전트가 읽기 전용으로 접근해야 할 경로와 쓰기 가능한 임시 경로를 구분합니다. network outbound가 필요한 작업과 필요 없는 작업을 나눕니다. Cloud PC에서 legacy UI를 조작해야 하는 작업은 Windows 365 for Agents 후보로 두고, API로 끝나는 작업은 Agent 365 connector나 기존 backend workflow로 남깁니다. 이 표를 먼저 만들면 MXC, Copilot sandbox, 다른 execution sandbox를 비교할 때 benchmark 점수보다 운영 위험이 먼저 보입니다.

Microsoft 발표에서 가장 강한 문장은 "Windows가 에이전트 플랫폼이 된다"가 아닙니다. 더 실무적인 문장은 에이전트 활동을 사람과 구분 가능한 identity에 묶고, desktop·clipboard·UI·input device에서 격리하며, Cloud PC와 local model 사이에서 실행 위치를 나누겠다는 설명입니다. 이 조합이 완성되면 에이전트 도입의 기준은 모델 이름보다 권한, 실행 위치, 감사 가능성, 비용 예측성으로 이동합니다. MXC preview는 그 기준을 미리 보여주는 공개 실험입니다.