2026년판 MCP on Windows 입문 —— 일반적인 MCP 접속과의 차이점 정리

이전에 Windows/SQL Server/MCP 로드맵을 추적했을 때는, "Windows에 MCP가 내장되면 무엇이 바뀌는가"가 아직 조금 보이지 않는 상태였습니다.

현재는 Microsoft Learn에 MCP on Windows의 공식 문서가 정리되어, MCP server의 탐지, 등록, 접속, containment(격리), 사용자와 관리자에 의한 액세스 제어까지 설명되어 있습니다.

그래서 이번에는 그 이후의 정리로서 다음 의문을 중심으로 살펴보겠습니다.

• 일반적인 MCP 접속과 무엇이 다른가
• Windows는 MCP server를 어디까지 관리하는가
• 에이전트, MCP server, 사용자, IT 관리자는 어떻게 관계하는가

결론부터 말씀드리면, MCP on Windows는 별개의 MCP 사양이라기보다, MCP server를 Windows 상에서 찾아내고, 신뢰와 권한을 확인하며, 관리된 형태로 사용하기 위한 OS 기반이라고 이해하는 것이 쉬울 것 같습니다.

※ 본 기사는 개인적인 정리 메모입니다. 2026년 6월 22일 시점의 Microsoft Learn과 MCP 공식 사양을 바탕으로 하고 있습니다. MCP on Windows는 현재도 프리릴리스(pre-release) 제품에 관한 정보를 포함하고 있으며, 정식 출시 전까지 요구사항이나 동작이 크게 바뀔 가능성이 있습니다.

MCP (Model Context Protocol)는 AI 애플리케이션과 외부 도구(tools)나 데이터 소스를 연결하기 위한 오픈 프로토콜입니다.

기본적인 등장인물은 다음 세 가지입니다.

Host: AI 애플리케이션이나 에이전트 본체 -
Client: Host 내에서 MCP server와의 접속을 담당하는 부품 -
Server: tools, resources, prompts 등을 제공하는 측

예를 들어, AI 에이전트가 파일을 검색할 때, 파일 조작용 MCP server가 search_files와 같은 tool을 공개하고, Host 내의 Client가 그것을 호출합니다.

이 접속만이라면, Host의 설정 파일에 server의 커맨드(command)나 URL을 작성하여 Client에서 직접 접속하는 방법으로도 실현할 수 있습니다.

일반적인 MCP 접속에서는 MCP server의 관리 방법이 Host마다 다릅니다.

예를 들어 개발자가 다음과 같은 설정을 준비합니다.

{
"mcpServers": {
"files": {
...

※ 이 JSON은 Host 제품별 설정 예시입니다. mcpServers라는 설정 형식 자체가 MCP 사양으로 공통화되어 있는 것은 아닙니다.

이 경우, 적어도 다음의 판단은 Host나 이용자 측에 달려 있습니다.

• 어떤 server가 설치되어 있는가
• 어떤 실행 파일이나 URL로 접속할 것인가
• 그 server를 신뢰해도 되는가
• 어떤 파일이나 자격 증명(credentials)에 액세스할 수 있는가
• 이용을 어떻게 기록·감사(audit)할 것인가

개발 환경에서는 다루기 쉬운 방법이지만, 여러 AI 앱이 동작하는 일반 사용자 단말기나 기업 단말기에서는 Host마다 설정과 권한 제어가 분산되기 쉽습니다.

MCP on Windows에서는 Windows On-device Agent Registry (ODR)가 중심이 됩니다.

ODR은 로컬 앱이나 원격 server가 제공하는 agent connector를 등록하여, Host에서 탐지할 수 있도록 하는 메커니즘입니다. Microsoft Learn에서는 주요 이점으로 다음과 같은 것들을 꼽고 있습니다.

• 로컬/원격 MCP server의 표준적인 지원
• 등록된 server의 탐지
• MCP server의 기본 containment (격리)
• 사용자와 IT 관리자에 의한 액세스 제어
• 접속 및 조작 로그, 감사
• File Explorer MCP server 등의 Windows connector

중요한 것은, ODR이 MCP Client를 대신하는 것이 아니다라는 점입니다.

공식 quickstart에서도 Host는 ODR로부터 등록된 server를 목록화하고, 반환된 command와 args를 사용하여 StdioClientTransport를 만들어 MCP Client로서 접속합니다. 즉, 실제 tools/list나 tools/call은 계속해서 MCP의 메커니즘입니다.

Windows가 추가하는 것은 그 접속의 전후를 관리하는 계층입니다.

대략적으로 비교하면 다음과 같습니다.

관점	일반적인 MCP 접속	MCP on Windows
server의 소재	Host별 설정 파일 등	ODR에 등록하여 Host에서 검출
...

즉 차이점은 MCP 메시지의 형식보다는, server의 라이프사이클 (Lifecycle)과 신뢰 경계 (Trust Boundary)를 누가 관리하는가에 있습니다.

관계를 순서대로 따라가면 다음과 같은 흐름이 됩니다.

• 앱이나 인스톨러가 MCP server를 Windows에 등록한다
• Host/에이전트가 ODR에서 이용 가능한 server를 검출한다
• 사용자 설정과 관리 정책에 따라 해당 Host에서 이용할 수 있는지 결정된다
• Host 내의 MCP Client가 server에 접속한다
• 에이전트가 server가 공개하는 tool을 선택하고, 필요한 인수를 전달하여 호출한다
• 접속 및 조작을 사용자/관리자가 기록 및 감사할 수 있다

여기서 권한은 단일한 것이 아닙니다.

server를 검출할 수 있는가특정 Host에서 server에 접속할 수 있는가server가 사용자의 파일 등에 접근할 수 있는가****개별 tool 호출을 실행해도 되는가

이것들은 별개의 판단입니다. '목록에 보인다'는 것과 '자유롭게 사용자 데이터에 접근할 수 있다'는 것은 같지 않습니다.

참고로, server의 검출·접속 및 사용자 파일에 대한 접근은 Windows/ODR의 제어 대상이지만, 개별 tool 호출을 어떻게 확인·승인할지는 Host의 구현 방식에도 의존합니다.

ODR을 통해 액세스되는 MCP server 중, Windows가 제공하는 server나 containment 요건을 충족하여 MSIX 또는 external location이 포함된 package로 등록된 server는 기본적으로 별도의 Windows session과 전용 agent user account에서 실행됩니다.

containment된 server는 사용자의 session에 직접 접근할 수 없습니다. 공식 문서에서는 기본적으로 다음과 같은 대상에 직접 접근할 수 없다고 설명되어 있습니다.

• 사용자 파일
• 사용자 설정, 레지스트리, 자격 증명 (Credentials)
• 사용자가 이용 중인 앱이나 창
• 사용자 session을 변경하는 실행 파일

반면, agent 측의 파일이나 레지스트리에 대한 접근, agent user environment에서의 실행 파일 실행, 인터넷 접속은 가능합니다. 또한, 사용자의 동의가 있다면 특정 사용자 파일에 접근할 수 있습니다.

이는 'MCP server라면 안전하다'는 의미가 아닙니다. server의 실행 장소와 초기 권한을 분리하여, prompt injection이나 tool 오용이 발생했을 때의 영향 범위를 최소화하기 위한 경계입니다.

특히 주의해야 할 점은 사용자 파일에 대한 권한입니다.

공식 문서에 따르면, 권한은 MCP server별로 부여되는 것이 아니라 Host에 대해 부여됩니다. 특정 server가 요청한 파일 접근을 사용자가 허용하면, 해당 Host가 동일한 session에서 사용하는 다른 MCP server도 사용자 파일에 접근할 수 있을 가능성이 있습니다.

따라서 Host 측에서도 접속하는 server를 필요 최소한으로 제한하고, 어떤 server가 동일한 session에 참여할지를 신중하게 다뤄야 합니다.

Windows에 등록하는 방법은 크게 세 가지로 정리할 수 있습니다.

MSIX 등으로 package identity를 가진 앱은 패키지의 메타데이터를 통해 MCP server를 등록할 수 있습니다. 앱의 설치/삭제에 맞춰 OS가 server를 등록/해제합니다.

또한, 일반적인 unpackaged app이라도 MSIX의 external location을 이용하여 package identity를 부여할 수 있습니다. MSIX 또는 external location이 포함된 package로 등록되어 containment 요건을 충족하는 server는 contained agent session에서 실행할 수 있습니다.

package identity를 가지지 않는 .exe나 MSI 배포 앱 등은 MCP bundle로 등록할 수 있습니다. 다만, 현재 프리뷰 단계에서 MCP bundle은 contained agent session에서 실행할 수 없습니다. package identity를 부여하여 contained 실행을 하고 싶다면, 앞서 언급한 external location을 이용하는 방법도 있습니다.

ODR에서 이용하려면 Windows Settings의 다음 항목에서 보호 수준을 낮춰야 합니다.

Settings > System > Advanced > AI components
> Reduce protections for agent connectors

공식 문서에서도 이 설정은 서버(server)에 더 넓은 액세스 및 권한을 부여하며, 추가적인 보안 리스크로 이어질 수 있다고 주의를 주고 있습니다.

원격 MCP 서버(remote MCP server)나 로컬 서버(local server)를 세밀하게 제어하여 등록하고 싶다면, ODR의 CLI를 이용합니다.

odr.exe mcp list
odr.exe mcp add <manifest file path>
odr.exe mcp remove <server id>
...

이를 통해 ODR이 단순한 구상이 아니라, 서버의 등록, 목록 확인, 설정, 기동을 다루는 관리 측면을 가지고 있음을 알 수 있습니다.

Windows의 공식 예시로서 이해하기 쉬운 것이 File Explorer MCP connector입니다.

이 커넥터(connector)는 파일 검색, 읽기, 텍스트 편집, 디렉터리 생성, 이동, ZIP 압축/해제 등의 도구(tools)를 제공합니다. Copilot+ PC에서는 자연어를 통한 시맨틱 파일 검색(semantic file search)에 대해서도 설명되어 있습니다.

예를 들어 사용자가 에이전트(agent)에게 다음과 같이 요청했다고 가정해 봅시다.

다운로드 폴더에서 이번 달 청구서를 찾아서 Documents에 정리해 줘

에이전트는 ODR에서 File Explorer connector를 찾아내고, tools/list를 통해 검색이나 이동 도구를 파악한 뒤, 사용자와 관리자가 허가한 범위 내에서 실행합니다.

여기서도 중요한 점은, File Explorer connector가 존재한다고 해서 파일에 자유롭게 액세스할 수 있는 것은 아니라는 사실입니다. 공식 문서에 따르면, 파일 액세스에는 명시적인 사용자 권한이 필요하며, 사용자와 관리자는 액세스를 거부할 수 있다고 명시되어 있습니다.

MCP on Windows를 테스트할 경우, 적어도 다음 사항들을 확인해 두는 것이 좋습니다.

• 대상 Windows 빌드(build)가 프리뷰 요구 사항을 충족하는가
• 호스트(Host)가 패키지 아이덴티티(package identity)를 가지고 있는가
• 서버(server)를 MSIX, MCP 번들(bundle), 수동 등록 중 어떤 방식으로 배포할 것인가
• 컨테인드 실행(contained execution) 요건을 충족하는가
• 요구되는 known folder capability는 무엇인가
• 동일한 호스트 세션(Host session)에서 이용할 서버를 압축하여 관리하고 있는가
• 사용자 동의와 IT 관리 정책을 모두 설계하였는가
• 「Reduce protections for agent connectors」를 안일하게 전제 조건으로 삼고 있지는 않은가

공식 퀵스타트(quickstart)에서는 Windows 빌드 26220.7262 이상을 전제로 하며, 호스트의 패키지 아이덴티티는 퍼블릭 프리뷰(public preview) 단계에서는 강제되지 않으나, 스테이블 릴리스(stable release)에서는 필요할 예정이라고 기재되어 있습니다. 이 부분은 향후 변경될 가능성이 높으므로, 구현 시 최신 페이지를 확인해야 합니다.

MCP on Windows를 일반적인 MCP 접속과 비교했을 때, 정리하기 쉬운 포인트는 다음 세 가지입니다.

• Discovery (발견): 호스트별 설정뿐만 아니라, ODR에서 등록된 서버를 찾아냄
• Trust & Permission (신뢰 및 권한): 컨테인먼트(containment), 사용자 동의, 관리 정책을 통해 이용 범위를 제어함
• Lifecycle & Audit (생명주기 및 감사): 서버의 등록/해제와 접속·조작 로그 기록 및 감사 가능성을 OS 측의 관리로 넘김

MCP on Windows는 MCP 자체를 Windows 전용으로 개조하는 메커니즘이 아닙니다.

MCP라는 공통의 접속 방식에, Windows 단말에서 실용적으로 사용하기 위한 「발견·격리·권한·관리」를 덧입히는 구조입니다. AI 에이전트가 Windows의 기능에 자연스럽게 접근하면 할수록, 이 눈에 띄지 않는 관리 계층이 더욱 중요해질 것으로 보입니다.

• Windows용 Model Context Protocol (MCP) 개요 - Microsoft Learn
• 빠른 시작: Windows용 MCP 호스트 (host) - Microsoft Learn
• Windows용 MCP 서버 (servers) 개요 - Microsoft Learn
• Windows에서 MCP 서버를 안전하게 격리하기 - Microsoft Learn
• Windows 온디바이스 에이전트 레지스트리 명령줄 도구 (odr.exe) - Microsoft Learn
• Windows 파일 탐색기 (File Explorer) MCP 커넥터 - Microsoft Learn
• Model Context Protocol 명세 (specification)