오늘은 Windows 위에서 신뢰할 수 있는 에이전트를 어떻게 만드는지 이야기해 보겠습니다. 자율성이 높은 에이전트일수록 진짜 가드레일이 필요한데요, 그걸 Windows의 기본 요소들로 어떻게 구현하는지 함께 보시죠.
시작하며
본격적으로 들어가기 전에, 우리가 왜 이 문제를 지금 다뤄야 하는지부터 짚어보겠습니다.
더 많은 능력, 더 커진 폭발 반경
AI는 이제 '답하는' 단계를 넘어 '스스로 행동하는' 단계로 넘어왔습니다. 원치 않는 메일을 보내거나, 데이터를 잘못 수정하거나, 민감 정보를 흘리거나, 허가 없이 GitHub에 커밋하는 작은 실수 하나가 엄청나게 큰 폭발 반경을 만들 수 있죠.
행동하는 AI의 무게
능력이 커진 만큼 한 번의 잘못된 행동이 미치는 파장도 그만큼 커졌습니다. 그래서 통제가 중요해집니다.
해답은 플랫폼 계층에 있다
이런 위험들은 결국 플랫폼 계층에서 막아야 하는 문제입니다. 에이전트가 우리가 매일 쓰는 시스템 안에서 행동하게 되면, 좋은 의도나 최선의 프롬프트에만 기뎀 수는 없거든요.
모든 접점이 위험이 된다
에이전트가 상호작용하는 모든 지점이 곰 잠재적인 위험 지점이 됩니다. 하나씩 짚어보겠습니다.
위험 지점 ①
파일 시스템에 접근하는 순간부터 위험은 시작됩니다. 무엇을 읽고 쓸 수 있는지가 통제되지 않으면 문제가 생기죠.
위험 지점 ②
네트워크로 나가는 통신도 마찬가지입니다. 어디로 연결되는지 통제하지 못하면 정보 유출로 이어질 수 있습니다.
위험 지점 ③
설치된 도구와 앱을 호출하는 것도 위험 지점입니다. 에이전트가 쓸 수 있는 능력이 곰 위험 범위가 되니까요.
위험 지점 ④
사용자의 자격 증명과 신원을 다루는 부분도 조심해야 합니다. 사람의 권한을 그대로 물려받으면 안 되거든요.
위험 지점 ⑤
이렇게 접점마다 위험이 쌓입니다. 결국 이 모든 지점을 아우르는 통제 장치가 필요하다는 얘기죠.
현장에서 배운 것
이건 이론이 아니라, 우리가 실제로 겪은 이야기입니다. GitHub에서 관찰한 사례를 공유해 보겠습니다.
GitHub에서 관찰한 것 — Copilot CLI
먼저 Copilot CLI에서는 사용자들이 권한 확인 피로감에 시달렸습니다. 매번 묻다 보니 결국 권한 게이트를 꺼버리는 일이 생기더군요.
GitHub에서 관찰한 것 — Copilot SDK
Copilot SDK 쪽에서는, 통합하는 개발자들이 CLI의 권한 게이트가 당연히 일관되게 동작할 거라고 가정했습니다. 하지만 그 가정이 항상 맞는 건 아니었죠.
GitHub에서 관찰한 것 — Orchestration
오케스트레이션에서는 에이전트가 목표를 기준으로 계획을 세우다 보니, 그 계획이 시스템 불변식에 미치는 모든 영향까지는 고려하지 못했습니다. 사람의 선의만으로는 부족하다는 걸 보여주는 대목입니다.
플랫폼은 무엇을 제공해야 하는가
그렇다면 에이전트를 설계 단계부터 안전하게 만들려면 플랫폼이 무엇을 제공해야 할까요? 이 질문에서 출발해 보겠습니다.
Windows는 계속 진화해 왔다
Windows는 사용자의 필요에 맞춰 끓임없이 진화해 온 플랫폼입니다. 이번에도 새로운 종류의 사용자를 맞이할 차례입니다.
사용자란 무엇인가
여기서 근본적인 질문을 하나 던져보겠습니다. 도대체 '사용자'란 무엇일까요?
이제 사용자는 사람만이 아니다
사용자는 더 이상 사람만을 뜻하지 않습니다. 사람을 대신해 행동하는 에이전트도 이제 사용자에 포함됩니다. 이 관점의 전환이 오늘 이야기의 핵심입니다.
핵심 플랫폼 역량
그래서 우리는 세 가지 핵심 역량을 정의했습니다. 신원, 격리, 그리고 관리입니다. 하나씩 소개하겠습니다.
신원 — Agent Identity
첫째는 신원입니다. 모든 에이전트는 사람 사용자와 구별되는, 인증된 일급 개체로 다뤄져야 합니다. 누가 무엇을 했는지 분명해지죠.
격리 — Containment
둘째는 격리입니다. 에이전트는 통제된 환경 안에서 실행되어, 문제가 생기더라도 그 폭발 반경이 제한되도록 해야 합니다.
관리 — Manageability
셋째는 관리입니다. IT 관리자가 중앙에서 에이전트를 배포하고, 모니터링하고, 정책을 적용하고 강제할 수 있어야 합니다. 이 세 가지를 순서대로 깊이 들어가 보겠습니다.
먼저 첫 번째 기둥, 신원부터 살펴보겠습니다.
에이전트는 당신이 아닙니다
가장 중요한 원칙은 이것입니다. 에이전트는 당신이 아닙니다. 사람의 신원을 그대로 빌려 쓰게 하면 안 된다는 뜻이죠.
에이전트는 새로운 유형의 신원
에이전트는 단순한 프로세스가 아닙니다. 사용자, 앱, 디바이스처럼 일급 신원을 가져야 합니다. 그래야 모든 행동을 명확히 귀속시키고 통제할 수 있죠. 에이전트마다 고유한 권한, 정책, 감사 로그를 갖게 됩니다.
데모: Agent ID로 동작하는 OpenClaw
이제 실제로 보여드리겠습니다. OpenClaw가 자체 Agent ID를 가지고 동작하는 모습을 데모로 확인해 보시죠.
데모 시연
보시는 것처럼 에이전트가 사람과 구별되는 자기 신원으로 인증하고 행동합니다. 모든 행동이 그 신원에 귀속되는 게 핵심입니다.
다음은 두 번째 기둥, 격리입니다.
하나의 정답은 없다
샘드박스는 비결정적인 에이전트를 다루는 핵심 보안 장치입니다. 에이전트의 행동은 런타임에 결정되지만, 예측 불가능하다고 통제 불가능한 건 아닙니다. 경계는 이해 가능해야 하고, 격리는 최소 권한을 가능하게 하며, 작업에 필요한 만큼의 경계로 확장될 수 있어야 합니다.
Microsoft Execution Containers (MXC)
그래서 만든 것이 Microsoft Execution Containers, 줄여서 MXC입니다. 정책 기반 실행 계층으로, 개발자가 에이전트나 작업의 보안 요구사항을 선언하면 그걸 IT·시스템 정책과 맞추고, 다시 네이티브 OS 기본 요소로 번역해 런타임에 경계를 강제합니다.
동적으로 구성되는 컨테이너
게다가 에이전트는 고정된 컨테이너에 묶이지 않습니다. 필요에 따라 동적으로 구성되는 격리 환경을 갖게 되죠.
개발자는 이걸 어떻게 쓰는가
그렇다면 우리 개발자들은 이 모델을 실제로 어떻게 사용할까요? 지금부터 그 방법을 보여드리겠습니다.
선언형 접근 방식
가드레일을 코드 곳곳에 하드코딩하는 대신, 활동이 어떻게 실행되어야 하는지를 정책으로 선언합니다. 컨테이너 구성과 보안 요구사항, 실행 요구사항을 한곳에 기술하는 방식이죠.
정책으로 무엇을 지정하나
이 예시에서는 워크로드 요구사항, 실행 진입점, 읽고 쓸 수 있는 파일 경로, 허용·차단되는 네트워크 접근, 그리고 허용되는 UI 접근까지 정책 하나로 지정하고 있습니다.
파일 시스템 경계
예를 들어 filesystem 항목을 보면, 이 에이전트가 쓸 수 있는 경로를 명시적으로 지정합니다. 그 밖의 파일에는 손대지 못하죠.
네트워크 경계
network 항목에서는 기본 정책을 block으로 두고, 오직 api.github.com 같은 허용된 호스트로만 나갈 수 있게 합니다. 나머지 통신은 전부 차단됩니다.
UI와 클립보드 경계
ui 항목에서는 클립보드를 읽기 전용으로만 허용하는 식으로, UI 접근까지 세밀하게 통제합니다. 이렇게 모든 접점을 정책 하나로 감싸는 거죠.
정책 예시 정리
정리하면, 이 선언형 정책 하나에 실행·파일·네트워크·UI 경계가 전부 담깡니다. 가드레일이 코드가 아니라 정책으로 사는 셈입니다.
데모: MXC 정책 기반 활성화
이제 MXC를 이용해 정책으로 제어되는 활성화를 데모로 보여드리겠습니다. 방금 이야기한 경계들이 실제로 어떻게 강제되는지 확인해 보시죠.
마지막 세 번째 기둥, 관리로 넘어가겠습니다.
정책 안에서 동작하도록
플랫폼은 에이전트가 정해진 정책 안에서만 동작하도록 보장해야 합니다. 이게 관리의 출발점입니다.
무엇을·어떻게·어떻게 관찰
정책은 에이전트가 무엇에 접근할 수 있는지, 무엇을 할 수 있는지, 그리고 그 행동을 어떻게 관찰할지를 통제합니다.
감독을 향해: 우리가 해야 할 일
에이전트는 분명한 감독 아래 동작해야 합니다. 사람이 개입하는 어시스턴트에서 시작해, 신뢰와 컴플라이언스를 잃지 않으면서 점점 더 높은 자율성으로 나아가는 거죠. 자연스러운 지점에서 의도를 드러내고, 에이전트가 틀릴 수 있다고 가정하며, 동의를 지속적으로 다루고, 증거로 자율성을 얻어내야 합니다.
Windows가 하는 일
Windows는 OS에 내장된 기능으로 이 신뢰를 돕습니다. 에이전트 활동을 드러내는 표면, 가드레일과 안전 기본 요소, 신뢰할 수 있는 알림·에스컬레이션 채널, 그리고 출처와 감사 추적까지 제공하죠.
데모: GHCP CLI + SDK
이번에는 GitHub Copilot CLI와 SDK를 함께 쓰는 데모를 보여드리겠습니다. 방금 이야기한 감독 기능들이 실제 개발 흐름에서 어떻게 작동하는지 보시죠.
에이전트 실행 모델: 개방에서 완전 격리로
에이전트 실행 모델은 크게 세 단계로 진화합니다. 어제는 샘드박스 없이 머신에 직접 접근했고, 오늘은 메인 루프는 낮은 권한으로 두고 도구 실행만 격리 컨테이너에 위임합니다. 그리고 내일은 에이전트가 자기가 쓰는 자원과 신원조차 거의 알지 못하는 완전 격리로 갑니다.
로컬 파일 시스템 보호 (Public Preview)
먼저 Public Preview로 제공되는 기능입니다. 로컬 파일 시스템을 보호해서, 에이전트가 접근할 수 있는 파일 범위를 안전하게 제한할 수 있습니다.
아웃바운드 네트워크 제한 (Public Preview)
다음으로 아웃바운드 네트워크 접근을 제한하는 기능입니다. 에이전트가 어디로 나갈 수 있는지 통제해서 정보 유출 위험을 줄여줍니다.
GitHub Copilot SDK에서 제공
그리고 이 기능들은 GitHub Copilot SDK에서 바로 사용할 수 있습니다. 여러분의 에이전트에 곧장 적용해 보실 수 있죠.
생태계와 함께
이 접근이 현실에서 통하는지 검증하기 위해, 우리는 OpenAI, OpenClaw, Manus, Hermes, NVIDIA 같은 선도적인 AI 기업들과 긴밀히 협력했습니다. 실제 에이전트 시스템에서 이 기본 요소들이 제대로 동작하도록 함께 다뒬었습니다.
이제 오늘 이야기를 정리해 보겠습니다.
에이전트가 Windows에서 잘 돌아갈 때 — 식별
첫째, 식별입니다. 모든 에이전트가 자기만의 신원, 권한, 감사 추적을 갖습니다.
격리
둘째, 격리입니다. 모든 행동이 정책에 의해 강제된, 알맞은 샘드박스 안에서 실행됩니다.
관리
셋째, 관리입니다. IT 관리자의 정책이 여러 디바이스에 걸쳐 일관되게 적용되고, 완전한 강제성과 관찰 가능성을 갖습니다. 이 세 가지가 갖춰질 때 에이전트가 Windows에서 제대로 동작합니다.
Agent 365와 MXC의 네이티브 통합
Agent 365가 MXC와 네이티브로 통합되면, Windows에서 실행되는 에이전트가 안전하게 시작해 계속 안전하게 유지될 수 있습니다.
Defender·Entra·Intune·Purview 보호
이 통합은 Defender, Entra, Intune, Purview의 보호를 함께 제공합니다. 그래서 보안·IT 팀이 로컬 에이전트를 제약하고 보호해, 엔터프라이즈 위험을 막을 수 있습니다.
핵심은 '잘 돌아가게' 하는 것
에이전트가 질문에 답하는 걸 넘어 실제 행동으로 넘어갈수록, 가장 큰 과제는 그것들이 잘 돌아가게 만드는 것입니다. Windows가 바로 그 전환을 감당할 토대를 제공합니다.
Windows는 에이전트가 신뢰성 있게 돌아가는 곳
Windows는 단지 에이전트가 실행될 수 있는 곳이 아닙니다. 에이전트가 신뢰성 있게, 안전하게, 대규모로 돌아갈 수 있는 곳입니다.
다음 단계
오늘 바로 시작해 보세요. github.com/microsoft/mxc에서 MXC를 써보실 수 있고, Taskbar Tasks API는 aka.ms/agent-taskbar에서 확인하실 수 있습니다. Agentic 부스에도 들러 주시면 여러분의 질문에 기쁩게 답해 드리겠습니다.
질문
여기까지입니다. 궁금한 점 있으시면 무엇이든 질문해 주세요. 감사합니다.