많은 사용자가 AI를 우려하는 대표적인 이유는 데이터가 종종 PC나 내부 네트워크를 벗어나 클라우드에서 추론 작업이 처리되기 때문이다. 데이터 보호에 대한 큰 의문이 제기될 수밖에 없다. 마이크로소프트가 ‘코파일럿+ PC’를 내놓은 주요 이유도 바로 이런 문제의식을 해소하기 위해서다. 코파일럿+ PC는 최신 시스템온칩에 내장된 NPU(neural processing units)를 통해 SLM(small language models)과 최적화된 머신러닝 도구를 활용한 로컬 추론을 지원하도록 설계됐다.

장점은 분명했지만, 정작 사용자는 로컬 AI 가속 효과를 제대로 체감하지 못했다. 핵심 개발 프레임워크 지원이 늦어지면서 로컬 AI 기능이 실제 서비스와 애플리케이션에 충분히 반영되지 못했기 때문이다. 이는 코파일럿+ PC 도입 속도가 기대보다 저조한 주된 원인이 됐다.

하지만 2025년 들어 마이크로소프트는 윈도우 앱 SDK(Windows App SDK)와 윈도우 ML(Windows ML) 프레임워크 전반에 새로운 기능을 단계적으로 적용하며 개발 생태계 확장 속도를 높이고 있다. 이 흐름 속에서 파운드리 로컬(Foundry Local) 같은 도구도 등장해 로컬 AI API에 쉽게 접근할 수 있는 방법과 SLM 프롬프트를 직접 테스트·검증할 수 있는 환경을 제공하고 있다.

마이크로소프트는 이그나이트 2025(Ignite 2025)에서 로컬 기반 에이전틱 AI 경험을 구현하겠다는 목표를 내세우며 윈도우 AI 플랫폼의 추가 발전 계획을 공개했다. 이 계획에는 네이티브 MCP(Model Context Protocol) 서버 지원 프리뷰가 포함되며, 윈도우 파일 시스템과 시스템 설정과 직접 연동해 작업을 수행하는 에이전트도 도입된다.

이런 기능은 별도로 비공개 프리뷰로 제공되는 ‘에이전트 워크스페이스(Agent Workspace)’를 뒷받침하는 기반이 된다. 에이전트 워크스페이스는 가상 데스크톱 환경을 활용해 에이전트와 애플리케이션을 실행함으로써 사용자의 일상 작업을 방해하지 않으면서도 다양한 에이전트 기반 기능을 운영할 수 있도록 설계된 공간이다.

마이크로소프트는 윈도우의 미래를 사용자 요청에 더욱 유연하게 반응하는 ‘에이전틱 OS’로 본다. 로컬과 클라우드 자원을 상황에 맞게 조합해 스스로 워크플로우를 구성하는 방식으로, 필요할 때 자동으로 작업을 조율하는 OS를 지향한다. 이런 구조가 구현되면, 윈도우의 로컬 코파일럿은 에이전트를 활용해 사용자의 요청에 따라 여러 애플리케이션을 연동해 작업을 수행하게 된다.

이런 비전을 실현하는 데 있어 MCP 지원의 추가는 핵심 기반 요소로 평가된다. 마이크로소프트는 MCP가 향후 윈도우에서 온디바이스 AI를 어떻게 안전하고 신뢰성 있게 구현할지를 보여주는 중요한 단서가 될 것이라고 내다본다.

윈도우에서 MCP를 활용하는 방식

MCP는 에이전트가 애플리케이션의 데이터와 기능에 접근할 수 있도록 하는 표준 API 형식이다. 예를 들어 비주얼 스튜디오 코드에서 깃허브 코파일럿 에이전트를 사용해 본 적이 있다면, 애저 클라우드 리소스에 접근하거나 서비스 운영 베스트 프랙티스를 참고하는 기능이 어떻게 제공되는지 이미 경험했을 것이다. 다만 현재 방식은 사용자가 직접 MCP 서버 엔드포인트를 찾아 설치해야 한다는 점에서 한계가 있다.

이 방식은 필요한 리소스를 직접 찾아 툴체인에 추가하는 데 익숙한 개발자에게는 큰 문제가 되지 않는다. 그러나 일반 사용자, 심지어 숙련된 사용자에게도 적합한 방식이 아니다. 이들은 윈도우가 스스로 사용하는 도구와 서비스를 관리해 주기를 기대하기 때문이다. 따라서 윈도우에서 로컬 에이전트가 활용할 MCP 서버는 다른 애플리케이션과 동일한 방식으로 설치돼야 하며, 접근 권한과 보안은 윈도우가 직접 관리하는 형태여야 한다.

마이크로소프트는 윈도우에 MCP 레지스트리(MCP registry)를 추가해 로컬 에이전트가 더 안전하게 MCP 리소스를 사용할 수 있도록 지원한다. 이 레지스트리는 보안 래퍼를 적용해 MCP 서버를 보호하며, 에이전트가 활용할 MCP 서버를 쉽게 찾을 수 있도록 검색 기능도 제공한다. 여기에 연결 프록시가 더해져 로컬과 원격 MCP 서버 간 통신을 관리하며, 인증·감사·권한 부여 절차도 처리한다. 기업은 이들 도구를 통해 그룹 정책과 기본 설정을 기반으로 MCP 접근을 제어하고, 각 커넥터에 고유한 ID를 부여할 수 있다.

MCP 서버 등록 과정은 MSIX 패키지를 이용한 설치 방식을 따른다. MCP 서버는 표준 번들 형식을 기반으로 하며, MCP 번들(mcpb)은 NPM 패키지를 사용해 빌드된다. 따라서 개발자는 번들 작업을 시작하기 전에 노드js를 개발 환경에 설치해야 한다. 이후 MCP 번들을 다운로드해 설치한 뒤, MCP 서버 코드를 대상으로 번들을 초기화하고 빌드하면 된다. 완성된 MCP 번들은 애플리케이션 설치 프로그램에 포함할 수 있으며, 최종적으로 MSIX 형식으로 패키징해 배포할 수 있다.

MCP 번들은 수동으로 설치할 수도 있지만, 윈도우 설치 관리자와 MSIX 방식을 사용하면 MCP 서버가 올바르게 등록되고 제한된 에이전트 세션에서 실행되도록 보장할 수 있다. 이런 방식은 시스템 리소스 접근을 제어해 복잡한 프롬프트 인젝션 공격 위험을 줄인다. MCP 서버는 유효한 매니페스트를 갖춘 바이너리 형태여야 등록할 수 있으며, MSIX 패키지 매니페스트에서 com.microsoft.windows.ai.mcpserver 확장으로 포함된다. 이 확장은 호스트 애플리케이션이 제거될 때 MCP 서버도 함께 삭제되도록 관리한다.

MCP 서버는 별도의 세션에서 실행되기 때문에 파일 접근을 위해서는 명시적인 권한 부여가 필요하다. 반대로 레지스트리 접근이나 사용자가 현재 어떤 작업을 하고 있는지 확인하는 기능은 차단된다. 다만 이런 제한이 서버가 자신의 세션에서 코드를 실행하거나 인터넷에 연결하는 것을 막지는 않는다. 사용자 파일 접근 권한은 MCP 서버를 호스팅하는 애플리케이션이 관리한다. 한 MCP 서버에 접근 권한이 부여되면, 같은 호스트에서 실행되는 다른 MCP 서버도 동일한 권한을 자동으로 상속받는다. 또한 서버가 요청하는 기능은 애플리케이션 매니페스트에 명시해야 하며, 시스템은 이 정보를 기반으로 사용자에게 접근 허용 여부를 묻게 된다.

윈도우 에이전트와 MCP 서버의 연동 방식

MCP 서버는 윈도우 에이전트 플랫폼의 한 구성 요소일 뿐이며, 실제로는 에이전트와 등록된 MCP 서버를 연결하는 호스트가 필요하다. 마이크로소프트는 호스트를 어떻게 구축하고 활용하는지 보여주기 위해 자바스크립트 기반 샘플 애플리케이션을 제공한다. 이 샘플은 MCP 서버가 제공하는 JSON을 파싱해 연결을 설정하고, 서버가 지원하는 도구 목록을 확인한 뒤 원하는 기능을 호출하는 과정을 시연한다. 이 샘플 코드는 다른 언어로도 비교적 쉽게 변환할 수 있어, 시맨틱 커널 같은 에이전트 오케스트레이션 프레임워크가 로컬 MCP 서버와 연동하는 데도 활용할 수 있다.

MCP 서버는 AI 애플리케이션과 다른 서비스 사이를 연결하는 매개체 역할을 하며, AI 모델이 외부 서비스를 조회할 수 있도록 다양한 커넥터를 제공한다. 마이크로소프트는 윈도우 에이전트 도구 초기 구성의 하나로 윈도우 파일 탐색기를 위한 MCP 기반 커넥터를 제공하는데, 이를 통해 에이전트는 사용자와 동일한 수준으로 윈도우 파일 시스템에 접근할 수 있다. 물론 사용자와 시스템 관리자는 특정 파일이나 프로젝트 디렉토리에 대한 접근을 언제든지 차단할 수 있다.

MCP 기반 커넥터는 에이전트가 활용할 수 있는 여러 파일 도구를 제공하며, 여기에는 기본적인 파일 접근과 수정, 파일·디렉터리 생성 기능이 포함된다. 다만 파일 삭제 기능은 별도로 제공되지 않기 때문에 에이전트는 새로운 파일을 작성하거나 기존 파일을 이동하고 텍스트 내용을 편집하는 방식으로 작업을 수행한다. 이런 기능은 윈도우 파일 시스템 자체에 변화를 주기 때문에 파괴적(destructive) 작업으로 분류된다.

따라서 에이전트가 윈도우 파일 시스템에 접근할 수 있도록 설정할 때는 주의가 필요하다. 파일 시스템 접근과 관련된 위험을 줄일 수 있도록 기본 프롬프트(base prompt)를 신중하게 설계해야 한다. 특히 처음 에이전트를 구축하는 단계라면, 커넥터 기능을 검색 기능(윈도우 내장 파이 소형 언어모델의 시맨틱 검색 기능을 활용)과 텍스트 읽기 정도로 제한해 두는 것이 바람직하다.

에이전트 코드가 PC에서 실행될 때 발생할 수 있는 위험을 최소화하려면, 개발자가 직접 가드레일을 마련해야 한다. 예를 들어, 에이전트가 수행할 수 있는 작업을 읽기 전용으로 제한하거나 가능한 한 접근 권한을 좁히는 방식이다. 마이크로소프트가 향후 윈도우 사용자 환경에 최소 권한 모델을 적용하려는 계획도 이런 위험을 줄이는 데 도움이 될 것으로 보인다. 이 모델이 도입되면 에이전트는 필요한 최소 수준의 권한만 부여받고, 권한 상승 가능성도 차단된다.

윈도우에서 MCP 서버를 구축하고 실행하기 위한 도구 외에도, 마이크로소프트는 에이전트 레지스트리 관리용 명령줄 도구를 제공하고 있다. 이를 통해 사용자는 자신이 개발한 MCP 서버가 정상적으로 설치됐는지 확인할 수 있다. 또한 이 도구는 PC에서 실행 중인 애플리케이션이 등록한 서드파티 MCP 서버 목록도 표시한다. 소프트웨어 업데이트 과정에서 새로운 서버가 설치될 수 있기 때문에 주기적으로 이 도구를 실행해 변화가 있는지 점검하는 것이 바람직하다.

에이전틱 OS로 가는 길

에이전틱 OS를 구축하는 일은 쉽지 않다. 기반 기술이 기존 윈도우 애플리케이션과 작동 방식이 크게 다르기 때문이다. 마이크로소프트는 클라우드에서 멀티테넌시 환경을 운영해온 경험을 바탕으로, 이를 지원할 적절한 보호장치를 마련하고 있다. 마이크로소프트가 그리는 에이전틱 OS는 각 에이전트와 해당 MCP 서버를 PC 내 하나의 테넌트로 취급해, 애플리케이션과 데이터와의 불필요한 상호작용을 최소화하는 제한된 환경에서 운영되도록 설계된 모습에 가깝다.

비슷한 접근은 과거에도 있었다. 예를 들어 윈도우 로그인 서비스는 크립톤(Krypton) 하이퍼바이저를 사용해 독립적인 가상 머신 내에서 실행된다. 가상화 기반 보안은 윈도우 11의 핵심 요소이기도 하며, 이런 구조가 윈도우에서 자율형 에이전트를 구현하는 데 핵심이 되는 것도 놀라운 일은 아니다. 마이크로소프트가 에이전트 기술을 탐색하던 초기 단계에서 가장 큰 걸림돌은 원격 시스템에서 임의 코드를 실행해야 한다는 점이었는데, 이번에는 컬레이더(Kaleida)와 제너럴 매직(General Magic) 같은 과거 사례에서 얻은 교훈을 바탕으로 처음부터 에이전트 기능을 샌드박스로 분리하는 방식을 채택하고 있다.

아직 초기 단계이긴 하지만, 로컬과 원격 리소스를 조합해 다양한 작업을 수행하면서도 보안 샌드박스 밖으로 벗어나지 않는 복합적 에이전트 애플리케이션을 개발할 수 있는 도구가 등장한 것은 고무적인 변화다. 마이크로소프트가 이 비전을 실현하고 개발자가 이를 적극적으로 활용할 수 있다면 상당히 흥미로운 결과가 나올 것이다.

dl-itworldkorea@foundryco.com