AI 에이전트에게 내 PC를 맡겨도 될까요?
요즘 코딩 에이전트에게 '이 버그 고쳐줘'라고 하면, 에이전트가 직접 파일을 열어 고치고 터미널 명령까지 실행하죠. 정말 편한데, 한편으로는 좀 무섭기도 해요. 에이전트가 실수로 엉뚱한 폴더를 지우거나, 웹페이지에 숨겨진 악의적인 지시를 읽고 내 API 키를 외부로 보내 버리면 어떡하죠?
마이크로소프트가 Windows 개발자 블로그를 통해 Microsoft Execution Containers(Mxc) 1.0.0을 발표했어요. 발표 제목에 붙은 설명이 'AI 에이전트를 위한 정책 기반 격리(policy-driven containment)'인데요, 말 그대로 에이전트가 실행되는 공간을 울타리로 감싸고 그 안에서 무엇을 할 수 있는지를 정책으로 정해두겠다는 거예요.
왜 이제 '격리'가 필요해졌을까
예전 AI는 텍스트로 답만 해줬어요. 답이 틀려도 사람이 읽고 걸러내면 그만이었죠. 그런데 에이전트는 직접 행동을 해요. 파일을 쓰고, 네트워크 요청을 보내고, 프로그램을 실행하죠.
여기서 가장 걱정되는 위협이 프롬프트 인젝션(prompt injection)이에요. 이게 뭐냐면, 에이전트가 읽는 문서나 웹페이지, 이슈 댓글 속에 '이전 지시는 무시하고 이걸 해라' 같은 문장을 몰래 숨겨두는 공격이에요. 사람이라면 그냥 넘기겠지만 에이전트는 그걸 진짜 지시로 착각할 수 있거든요. 모델을 아무리 똑똑하게 만들어도 이걸 100% 막기는 어렵다는 게 업계의 공통된 인식이에요.
그래서 나온 발상이 '모델이 속더라도 피해 범위는 제한하자'예요. 신입 사원에게 첫날부터 전사 서버의 관리자 권한을 주지 않는 것과 같아요. 일하는 데 필요한 권한만 딱 주는 거죠. 보안 용어로는 최소 권한 원칙(principle of least privilege)이라고 해요.
'정책 기반 격리'란 무엇인가
정책 기반이라는 건 격리 규칙을 코드 곳곳에 박아두는 게 아니라, 선언적인 규칙으로 따로 관리한다는 뜻이에요. 방화벽 규칙표를 떠올리면 쉬워요. 일반적으로 에이전트 샌드박스의 정책은 이런 축으로 구성돼요.
- 파일 시스템: 프로젝트 폴더는 읽기·쓰기 허용, SSH 키나 브라우저 쿠키가 있는 폴더는 접근 금지
- 네트워크: 패키지 저장소처럼 허용된 도메인만 통신 가능, 나머지는 차단
- 프로세스·시스템: 새 프로세스 생성, 레지스트리 수정, 시스템 설정 변경 제한
- Claude Code는 macOS의 Seatbelt, 리눅스의 bubblewrap 같은 OS 기능으로 파일·네트워크 접근을 제한하는 샌드박스를 제공해요.
- OpenAI Codex CLI도 OS별 샌드박스 위에서 명령을 실행하는 방식을 택했어요.
- E2B 같은 서비스는 Firecracker 마이크로VM으로 클라우드에 격리된 실행 환경을 빌려줘요.
- 구글의 gVisor처럼 커널 호출을 중간에서 가로채 컨테이너를 더 단단하게 격리하는 기술도 있어요.
사실 Windows에는 이런 격리를 위한 재료가 이미 꽤 있어요. 스토어 앱에 쓰이는 AppContainer, 프로세스 묶음의 자원을 제한하는 Job Object, 일회용 가상 환경인 Windows Sandbox, Hyper-V 기반 격리 컨테이너까지요. 다만 각자 쓰임새와 설정 방식이 달라서, 에이전트 개발자가 직접 조합해 쓰기엔 진입 장벽이 높았어요. 발표의 방향으로 보면 Mxc는 이런 격리를 '에이전트 실행'이라는 목적에 맞춰 정책 하나로 묶어 제공하려는 시도예요. 구체적인 정책 문법, 격리 방식, 지원하는 Windows 버전 같은 세부 사항은 공식 문서에서 꼭 확인해 보세요.
업계 흐름: 모두가 샌드박스를 만들고 있어요
이 분야는 지금 정말 빠르게 움직이고 있어요.
한국 개발자에게 주는 시사점
한국 기업 환경은 Windows 비중이 특히 높아요. 금융권, 공공기관, 대기업 사내 PC 대부분이 Windows죠. 그동안 '에이전트를 업무 PC에서 돌리면 보안팀이 허락을 안 해준다'는 고민이 많았을 텐데, OS 차원의 격리 정책이 생기면 보안 심사에서 설명할 근거가 생겨요. 금융권 망분리 규제가 단계적으로 완화되면서 생성형 AI 도입 논의가 늘고 있는 만큼 더 그렇죠.
사내용 에이전트나 자동화 도구를 만드는 분이라면, 지금부터 '이 에이전트는 어떤 폴더와 어떤 도메인에 접근해야 하는가'를 목록으로 정리해 두세요. 어떤 샌드박스를 쓰든 결국 그 목록이 정책의 출발점이 되거든요.
마무리
한 줄 정리: 에이전트를 완벽하게 믿을 수 없다면, 믿지 않아도 안전한 환경을 만들면 된다.
여러분은 코딩 에이전트를 쓸 때 권한을 어디까지 허용하고 계신가요? 회사에서 AI 에이전트 도입을 가로막는 가장 큰 벽이 기술인지, 정책인지도 궁금해요.
🔗 출처: Hacker News