요약
마이크로소프트가 AI 에이전트의 접근 범위를 정책으로 묶어 두는 격리 도구 MXC를 정식 출시했습니다.
윈도 플랫폼·개발자 부문 부사장 로건 아이어가 윈도 개발자 블로그에서 발표했습니다. 에이전트에 권한을 다 주거나 아예 막는 두 선택지 대신, 필요한 만큼만 허용하는 격리 계층을 내놓았습니다.
왜 중요한가
- 에이전트가 스스로 권한을 정하지 못하게 하고, 에이전트 밖의 정책이 경계를 강제합니다.
- JSON 설정 하나로 윈도, macOS, 리눅스의 서로 다른 격리 기술을 함께 다룰 수 있습니다.
- GitHub Copilot, OpenAI Codex, Replit이 이미 지원하고 Claude Code도 지원을 예고했습니다.
핵심 내용
- 개발자가 필요한 파일과 네트워크 대상을 선언하면 MXC가 알맞은 컨테이너로 그 경계를 지킵니다.
- 격리 방식은 프로세스 컨테이너, 세션 컨테이너, WSL 컨테이너, 마이크로VM(하드웨어 가상화로 격리하는 경량 가상 머신) 네 가지입니다.
- 프로세스 컨테이너는 윈도의 AppContainer, macOS의 Seatbelt, 리눅스의 Bubblewrap 같은 운영체제 샌드박스를 씁니다.
- 막힌 접근을 기록하는 학습 모드로 꼭 필요한 권한만 남기도록 정책을 다듬을 수 있습니다.
- 기업은 곧 Microsoft Intune으로 개발자 정책 위에 조직 정책을 덧씌울 수 있게 됩니다.
HN 반응
- 직접 써 본 이용자들은 문서가 부실하고 완성도가 낮아 1.0이 아닌 초기 미리보기 수준이라고 평가했습니다.
- 보안 모델만 점점 복잡해진다는 비판과 함께, 앱이 특정 폴더만 읽고 쓰게 하는 단순한 장치를 원한다는 목소리가 이어졌습니다.
이 문제를 꽤 오래 곰곰이 생각해 봤습니다. 마침내 bubblewrap에 대한 답이 나온 건 반갑지만, 사실 우리 업계는 꽤 오래전부터 권한 관리를 터무니없이 못 해 왔고 이 프로젝트가 그 문제를 해결해 주지는 않습니다. 읽기 전용 리소스 접근이 된다고 하면 듣기에는 좋지만, 거기에 JIRA를 연결하는 순간 갑자기 신원 체계도 다르고 리소스 모델도 다른 데다 감당 못 할 만큼 복잡해집니다.
보안 모델을 갈수록 복잡하게 만드는 지금의 해법은 통하지 않고 있습니다. 결국 일이 터지면 "제대로 설정하지 않았네요"라고 말할 수 있게 해 줄 뿐입니다. 무엇이 올바른 설정인지 설명하기조차 어렵고, 그렇게 설정하기는 더 어려운데도 말입니다.
솔직히 이 프로젝트는 괜찮아 보이지만, 폭주하는 에이전트로부터 우리를 지켜 줄 무언가를 원한다면 보안 전체를 뿌리부터 다시 생각해야 합니다.
마이크로소프트 보안은 양극단입니다. SharePoint나 Azure의 네트워크 리소스는 정교하게 권한을 나눠 놓았을지 몰라도, 소비자용 애플리케이션은 농담 수준이에요.
Excel, VSCode, Outlook 같은 것들의 권한 모델은 "이걸 신뢰하시겠습니까?"라고 묻는 이분법 팝업 하나가 전부이고, 예를 누르면 모든 것에 대한 전체 권한이 켜져 버립니다.
일반 사용자가 보안에 신경 쓰길 기대하지는 않습니다. 신경 쓰는 사용자가 있다 해도 대개 기업 환경에 있어서, 기업 설정으로 알아서 처리됩니다.
좋다 나쁘다를 말하려는 게 아니라, 애초에 목표 시장이 아니라는 뜻입니다.
VSCode는 일반 사용자보다 한 단계 위의 사용자를 겨냥하지만, 거기서조차 확장 프로그램은 샌드박스에 들어 있지 않고 Workspace Trust도 스위치 하나가 전부입니다.
일반 사용자도 보안에 신경 쓰길 기대해야 합니다. 사용자가 유일한 방어선이 되어서는 안 되겠지만, 다층 방어 계획의 일부이기는 합니다.
인사팀이 매년 들으라고 하는데 다들 건너뛰는 그 보안 교육 과정들, 아시죠?
PowerBI 얘기는 꺼내지도 마세요...
정말 그래요. 모바일 기기는 (어떤 면에서는) 이 부분을 더 잘 해냈지만, 기본값이 최소 권한인 것이 표준이 되어야 합니다. 그리고 훨씬, 훨씬 덜 헷갈려야 하고요.
아쉽게도 각 백엔드가 어떻게 동작하는지 설명한 문서를 훑어보니, 이 프로젝트는 거의 전체가 최신 세대 LLM의 작품 같습니다. "신중하게 설계해서 이 용도에 깔끔하고 안전하게 맞추라"가 아니라 "무슨 수를 써서라도 일단 동작하게 만들라"로 지시를 해석한 듯합니다.
bubblewrap 연동 문서조차 의식의 흐름대로 바이브를 흩뿌려 놓은 수준입니다. 결과물을 믿을 만한 구석이 거의 없습니다.
(사실상 같은 글인 다른 게시물에 올렸던 댓글을 옮겼습니다: https://news.ycombinator.com/item?id=50026061)
이 프로젝트를 한동안 지켜보면서 여러 버전을 써 봤습니다. 전부 아주 허술해 보입니다. 문서는 사실상 없다시피 하고요.
이런 추상화 계층을 만든다는 발상 자체는 좋다고 생각하지만, 1.0 릴리스라고 하기엔 아직 한참 멀었습니다.
bubblewrap과 hyperlight 양쪽에 모두 잘 들어맞는 추상화가 어떤 모양일지 상상하기가 정말 어렵습니다. (둘 다 훌륭한 프로젝트입니다. 둘 다 "샌드박스"라는 말에는 들어맞지만, 푸는 문제도 다르고 푸는 방식도 다릅니다.)
어색한 추상화야 저도 만들어 낼 수 있겠지만, 나쁜 추상화로 보안 시스템을 만드는 건 좋은 방법이 아닙니다.
가장 큰 소식이자 가장 반가운 소식은, W11 25H2 8월 누적 업데이트부터 누구나 관리자 권한 없이 앱 컨테이너(App container)를 설정할 수 있게 됐다는 점입니다. 그 위에 mxc를 만든 것이고요.
불확실하고 불안정하며 앞으로 개선할 부분이 많은 첫걸음이지만, 그래도 첫걸음은 첫걸음입니다. 밖에서 새로운 길을 탐험하려는 개척자들에게 문이 열린 셈입니다.
공유해 주셔서 감사합니다!
기업 입장에서는 엄청난 일입니다. 지금은 ChatGPT 데스크톱의 윈도 샌드박스를 사용자에게 설정해 주는 일이 정말 고역이거든요. 두 번째로 큰 소식은 Intune과 agent365를 통한 신원 관리가 곧 나온다는 겁니다!
샌드박스를 어떻게 만들고 계신가요? 아니면 Windows Store에서 설치한 ChatGPT 데스크톱 앱이 요청하는 샌드박스 전반을 말씀하시는 건가요?
ChatGPT Desktop의 윈도 샌드박스를 중앙에서 프로비저닝하는 방법으로 제공되는 경로를 말씀드린 겁니다. https://learn.chatgpt.com/docs/windows/windows-sandbox#it-led-provisioning-for-the-legacy-elevated-sandbox
이걸 쓰다가 여기에 설명된 문제를 그대로 겪었습니다. https://github.com/openai/codex/issues/47383
이 사람들은 뭘 피해 달아나는 걸까요? 아니에요! 이 사람들은 동네에서 가장 혹독한 대결을 향해 달려가고 있는 거라고요!
Most Extreme Elimination Challenge (MXC) (가장 극단적인 탈락 대결)
https://en.wikipedia.org/wiki/Most_Extreme_Elimination_Challenge
써 봤는데 1.0 릴리스가 아닙니다. 초기 기술 프리뷰에 더 가깝습니다.
이 부분을 좀 더 자세히 설명해 주실 수 있나요?
이걸 범용 앱 권한 경계로 쓸 수 있나요, 아니면 어떻게든 "에이전트"인 척 꾸며야 하나요? 제 음악 플레이어가 SSH 키 같은 걸 읽지 못하도록 막을 수 있어야 하는 시점은 이미 한참 전에 지났습니다.
물론 기업 고객한테만 열어 주겠죠. 평민들은 최상위 라이선스 값을 내지 않으면 더 나은 보안을 못 쓰니까요.
정말 훌륭한 질문입니다. 저는 에이전트를 신뢰할 수 없는 사용자 계정으로 실행해서 막아 왔어요(주로 리눅스에서요). 도커 경계조차 그다지 믿음직하지 않거든요. Firecracker는 올바른 방향으로 가는 한 걸음입니다(오래된 기술이긴 하지만 쓸모가 있습니다). 에이전트에게 특정 접근 권한을 줄 수 있는 로컬 hashicorp 식 볼트가 정말 갖고 싶은데, 그런 접근 경계를 검토하고 관리하는 데는 끝도 없이 시간이 걸릴 수 있죠.
그럼 맥을 사야겠네요.
잠가 두면 좋을 것들은 많습니다. NPM install이 바로 떠오르네요.
이걸 개발 컨테이너(dev container)와 연동해서 개발 컨테이너를 더 엄격하게 격리해 돌릴 수 있을지 궁금합니다.
그런 용도로 VS Code 워크스페이스 개념을 쓰는 사람들을 봤습니다. 한계가 좀 있지만 제가 선호하는 방향으로 가는 좋은 한 걸음이에요.
VS Code 워크스페이스는 보호 기능을 전혀 제공하지 않는 것 같은데요.
https://code.visualstudio.com/docs/editing/workspaces/workspaces
GitHub codespaces를 말씀하시는 건 아닌가요?
아니요, VS Code 워크스페이스를 말한 게 맞아요. 이제 경계의 한계를 제대로 이해하려고 토끼굴에 들어가 보겠습니다 :)
문서를 좀 읽어 봤는데, VS Code 워크스페이스에서 도움이 될 만한 건 하나도 못 찾겠습니다.
앱의 읽기/쓰기를 특정 디렉터리로 제한하는 아주 간단한 방법이 있었으면 합니다. 엄청나게 유용한 해법이고 20년도 더 전에 있었어야 하는 건데, 왜 아직도 없는 걸까요? 이것만 있으면 대부분의 보안 문제가 사용자 친화적인 방식으로 바로 해결될 텐데요.
MXC가 이걸 해 준다고는 생각하지 않습니다. 제가 틀렸다면 알려 주세요!
MXC로 임의의 실행 파일을 띄울 수 있지만, 백엔드마다 제공하는 보안 보장 수준이 다릅니다. 윈도의 LPAC 같은 일부 백엔드에서는 실행 파일 상당수가 시작하자마자 그냥 실패합니다(예를 들어 powershell이 그렇습니다).
저는 백엔드니 뭐니 신경 쓰고 싶지 않아요! 저는 프로그래밍 언어, IDE, 고성능 데이터베이스까지 직접 만들어 본 사람인데도요. "평범한" 사용자는 오죽하겠어요! 왜 이렇게 과하게 설계한 걸까요? 아, 정보는 고맙습니다!
...그러면 에이전트를 사람 사용자와는 별개인 고유한 보안 주체(security principal)로 만들면 되는 것 아닌가요?
실행 경계가 있어도 그렇게 판단할 수는 있어요. 중요한 건 실제로 그걸 실행에 옮길 수 있느냐죠.
전반적으로 발표문이 아주 허술하게 쓰였네요. 마치 누가 쓴 것처럼요...