Windows On-device Agent Registry (ODR) 대략적으로 이해하기

Windows On-device Agent Registry, 약칭 ODR에 대해 우선 개념부터 정리하겠습니다.

※본 기사는 개인적인 정리 메모입니다. 2026년 6월 18일 시점의 Microsoft Learn에서는 MCP on Windows가 프리뷰 단계의 정보로서 공개되어 있습니다. 정식 출시 전까지 사양, 화면, 커맨드, 용어 등이 변경될 가능성이 있습니다.

Microsoft Learn의 「Model Context Protocol (MCP) on Windows overview」에서는 MCP on Windows가 **Windows On-device Agent Registry (ODR)**를 제공한다고 설명하고 있습니다.

ODR은 로컬 앱이나 원격 서버에서 제공되는 agent connector를 Model Context Protocol (MCP)을 사용하여 발견·이용하기 위한, 안전하고 관리 가능한 인터페이스입니다.

대략적으로 말하자면, 다음과 같이 파악하면 이해하기 쉽습니다.

Windows 상의 AI 에이전트가 이용 가능한 로컬/원격 MCP server를 찾아내고, 사용자나 관리자의 제어 하에 이용하기 위한 레지스트리

여기서 말하는 「레지스트리」는 Windows의 레지스트리 에디터 그 자체라기보다, 이용 가능한 MCP server와 그 정보를 등록·발견·관리하기 위한 메커니즘이라는 의미에 가깝습니다.

이전에는 "ODR이라는 이름의 1차 정보를 찾을 수 없는 것 아닌가"라고 생각했으나, 이는 저의 확인 부족이었습니다. 현재는 Microsoft Learn에 ODR의 개요와 커맨드라인 도구인 odr.exe에 대한 설명이 공개되어 있습니다.

기존의 애플리케이션은 인간이 화면을 보고, 버튼을 누르고, 파일을 선택하고, 설정 화면을 열어 조작했습니다.

반면, AI 에이전트는 자연어로 된 지시를 받고, 필요에 따라 외부 도구, 데이터 소스, 로컬 기능 등을 호출합니다.

예를 들어, 다음과 같은 요청을 생각해 봅시다.

문서 폴더에서 지난달 청구서로 보이는 파일을 찾아서 요약해줘

이 처리를 실행하려면 적어도 다음과 같은 정보나 제어가 필요합니다.

• 파일을 검색할 수 있는 MCP server나 tool이 존재하는가
• 해당 server에 어떻게 접속하는가
• 어느 폴더에 대한 액세스가 허용되어 있는가
• tool 실행에 대해 사용자의 동의를 얻었는가
• 취득한 데이터를 어디까지 server나 모델에 전달해도 되는가
• 실행 내용을 나중에 확인·감사할 수 있는가

이 "이용 가능한 능력을 찾는다", "접속에 필요한 정보를 얻는다", "사용자나 관리자의 제어 하에 이용한다"라는 부분을 각 AI 앱이 저마다 독자적으로 구현하면, 설정 방법이나 관리 방법이 제각각이 됩니다.

그래서 Windows 상에서 이용할 수 있는 agent connector와 이를 통해 제공되는 MCP server를 발견·관리하는 공통의 메커니즘이 필요하게 됩니다.

ODR은 이를 위한 Windows 측의 기반으로서 위치하고 있습니다.

ODR을 이해하는 데 있어 MCP는 거의 전제 지식이 됩니다.

MCP, 즉 Model Context Protocol은 AI 애플리케이션을 외부 데이터 소스나 도구에 연결하기 위한 오픈 프로토콜입니다.

MCP의 기본적인 구성에는 주로 다음과 같은 역할이 있습니다.

• Host: 사용자가 조작하는 LLM 애플리케이션이나 AI 앱
• Client: Host 내에서 MCP server와의 접속을 담당하는 컴포넌트
• Server: 데이터나 기능을 MCP를 통해 제공하는 서비스

MCP server는 주로 다음과 같은 기능을 제공할 수 있습니다.

• Resources: AI 앱이나 모델이 이용하는 데이터나 컨텍스트
• Tools: 모델이 호출할 수 있는 함수나 조작
• Prompts: 정형화된 메시지나 워크플로우

여기서 Windows 측의 과제가 되는 것은 Host가 "이용 가능한 MCP server를 어떻게 찾는가"입니다.

개발자의 손에서 테스트하는 정도라면 설정 파일에 접속처를 직접 적는 방법도 괜찮을지 모릅니다. 하지만 일반 이용자나 기업이 사용하는 Windows 환경에서는 이용자가 MCP server마다 설정 파일을 매번 편집한다는 전제를 두기 어렵습니다.

따라서 MCP server의 등록 정보, 제공되는 tool, 접속에 필요한 정보 등을 Windows 측에서 관리하고, Host가 이를 발견할 수 있는 메커니즘이 중요해집니다.

ODR은 Windows에서 사용할 수 있는 MCP server를 Host가 발견하기 위한 공통 입구라고 이해하면 쉽습니다.

참고로, MCP에서의 사용자 동의나 tool 실행의 안전성은 ODR만이 담당하는 것은 아닙니다. MCP 사양에 따르면, Host 측에서도 사용자 동의, 데이터 공유, tool 실행 등을 적절히 제어할 필요가 있다고 명시되어 있습니다.

상당히 단순화하면, ODR을 이용하는 흐름은 다음과 같이 정리할 수 있습니다.

• 앱 설치나 odr.exe 등을 통해 MCP server가 ODR에 등록됨
• AI 앱이나 에이전트 Host가 ODR에서 이용 가능한 MCP server를 검색함
• ODR이 등록 정보 및 접속에 필요한 정보를 Host에 반환함. 등록 방식에 따라 manifest에 포함된 정적인 tool 정보도 발견에 활용됨
• Host 내의 MCP Client가 대상 MCP server에 접속함
• 실제 이용 시에는 사용자 동의, Windows의 액세스 제어, 관리 정책 등이 관여함

여기서 주의해야 할 점은 ODR을 모든 MCP 통신이 통과하는 프록시(Proxy)로 간주해서는 안 된다는 것입니다.

ODR의 핵심적인 역할은 MCP server를 등록·발견·관리하는 것입니다. Host는 ODR로부터 얻은 정보를 이용하며, Host 내의 MCP Client를 통해 MCP server에 접속합니다.

Microsoft Learn에서는 ODR의 주요 이점으로 다음 내용들을 꼽고 있습니다.

• 로컬 앱과 원격 서버를 포함한 표준화된 MCP 지원
• MCP server의 발견 가능성 (Discoverability)
• agent session을 통한 격리 (Containment) 등의 보안
• Windows Settings 및 Microsoft Intune을 이용한 사용자/관리자의 제어
• MCP Client와 Server 간의 상호작용에 대한 로그 및 감사 (Audit)
• File Explorer MCP server 등의 Windows 커넥터 (Connector)

즉, ODR은 단순한 MCP server 목록표가 아닙니다.

다만, ODR이 MCP server의 안전성을 전적으로 보장하거나 server의 선악을 자동으로 판정하는 것도 아닙니다. 등록 정보, 액세스 제어, 격리 (Containment), 사용자 동의, 관리 정책, 로그 등을 조합하여 Windows 상에서 MCP server를 다루기 쉽게 만들기 위한 기반입니다.

ODR에는 odr.exe라는 커맨드 라인 도구(CLI tool)도 마련되어 있습니다.

Microsoft Learn에서는 odr.exe가 Windows 상의 on-device agent를 발견하고 관리하기 위한 도구이며, 이미 등록된 MCP server도 관리 대상에 포함된다고 설명합니다.

기본 구문은 다음과 같은 형태입니다.

odr [command] [options]

MCP server에 관한 기본 구문은 다음과 같습니다.

odr mcp [command] [options]

커맨드 레퍼런스(Command Reference)에는 다음과 같은 서브 커맨드(Subcommand)가 게재되어 있습니다.

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

원격 MCP server를 수동으로 등록하는 예시로 다음 형식도 소개되어 있습니다.

odr.exe mcp add --uri <url-to-your-server>

이처럼 ODR은 추상적인 구상에 그치지 않고, Windows 상에서 MCP server를 등록, 목록 표시, 삭제, 설정, 실행하기 위한 구체적인 관리 수단을 갖추고 있습니다.

참고로 현재 프리뷰(Preview) 단계이기 때문에, Microsoft Learn 내에서도 목록 표시 예시로 odr mcp list와 odr.exe list가 모두 보입니다. 실제로 테스트할 경우에는 사용 중인 Windows 빌드에서 다음 도움말을 확인하는 것이 안전합니다.

odr --help
odr mcp --help

ODR의 개념은 감각적으로 브라우저 확장 프로그램(Browser Extension)의 관리와 다소 유사합니다.

브라우저 확장 프로그램에서는 확장 기능이 사용하는 기능이나 권한을 선언하고, 브라우저가 그 정보를 이용자에게 보여줍니다. 이용자는 내용을 확인하고 허용된 범위 내에서 확장 기능을 이용합니다.

ODR에 등록되는 MCP server에 대해서도, Host가 발견 및 연결에 이용할 수 있는 정보가 필요합니다.

등록 방식에 따라 형식은 다르지만, 예를 들어 다음과 같은 정보가 다뤄집니다.

• 이름
• 버전
• 설명
• 작성자
• server의 실행 방법 및 연결 정보
• 제공하는 tool
• tool의 설명
• 입출력 schema (입출력 스키마)
• server가 요구하는 capability (기능)

MCP bundle에서는 manifest에 선언한 initialize 및 tools/list 등의 정적인 정보와, 실행 시점에 server가 반환하는 정보가 일치해야 합니다.

이를 통해 ODR은 등록 시점에 상정되지 않은 tool이나 capability만이 실행 시점에 추가되지 않았는지 검증하며, Host가 server를 실행하지 않고도 tool을 발견할 수 있도록 합니다.

단, manifest나 tool의 설명이 올바르다고 해서 해당 server가 전적으로 안전하다는 것이 보장되는 것은 아닙니다.

MCP 사양에서도 tool은 임의의 코드 실행(arbitrary code execution)으로 이어질 가능성이 있으며, tool의 설명이나 annotation (주석)은 신뢰할 수 있는 server로부터 얻은 것이 아니라면 신뢰할 수 없는 것으로 취급해야 한다고 명시되어 있습니다.

즉, ODR은 편리한 카탈로그인 동시에, 등록 정보와 실제 능력 사이의 차이를 줄이고 액세스 제어(access control) 및 감사(audit)로 연결하는 접점(interface)으로 보는 것이 적절합니다.

ODR의 가치는 단순히 "AI가 편리해진다"는 것에 그치지 않습니다.

오히려 AI 에이전트가 Windows 상의 기능을 이용할 때 필요하게 되는, 눈에 띄지는 않지만 중요한 관리 작업을 공통화한다는 점에 있습니다.

AI 앱마다 파일 검색 tool을 찾는 방법, 앱 조작 tool의 설정 방법, 로컬 기능에 대한 연결 방법이 제각각이라면 사용자에게도 개발자에게도 부담이 됩니다.

Windows 상에 공통된 발견 장소(discovery location)가 있다면, Host는 OS 측의 메커니즘을 사용하여 이용 가능한 MCP server를 검색할 수 있습니다.

감각적으로는 AI 에이전트를 위한 서비스 디스커버리 (service discovery)에 가깝습니다.

AI 에이전트가 로컬 파일, 설정, 앱, 브라우저 등에 접근하는 경우, 다음과 같은 점을 확인할 수 있어야 합니다.

• 어떤 Host가 어떤 MCP server를 사용하려고 하는가
• 어떤 데이터나 기능에 대한 액세스를 요구하는가
• 읽기 전용인가, 아니면 변경을 수반하는가
• 사용자가 허용하는가
• 관리자 정책으로 허용 또는 제한하는가

Microsoft Learn에서는 사용자와 IT 관리자가 Windows Settings나 Microsoft Intune 등을 이용하여 각 agent로부터 MCP server로의 액세스를 제어할 수 있다고 설명합니다.

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

현재의 프리뷰 사양에서는 사용자 파일에 대한 액세스 허용이 개별 MCP server가 아니라, Host에 대해 부여됩니다.

특정 Host에서 이용되는 MCP server가 파일 액세스를 요구하고 사용자가 이를 허용했을 경우, 동일한 Host의 agent session에서 이용되는 다른 MCP server도 해당 파일에 액세스할 수 있을 가능성이 있습니다.

"server마다 완전히 독립된 권한"이라고 오해하지 않는 것이 중요합니다.

AI 에이전트는 prompt injection (프롬프트 인젝션)이나 tool의 악용과 같은 영향을 받을 수 있습니다.

예를 들어, 웹 페이지나 이메일에 포함된 악의적인 지시를 에이전트가 읽고, 그 지시에 따라 로컬 파일을 외부로 전송하려고 시도하는 등의 리스크를 고려할 수 있습니다.

MCP on Windows에서는 대응하는 MCP server를 agent session이라고 불리는 별도의 Windows session에서 구동하며, 별도의 agent user account를 통해 containment (격리)합니다.

containment된 server는 기본적으로 다음과 같은 사용자 환경에 직접 액세스할 수 없습니다.

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

반면, containment된 server라도 인터넷 액세스, agent 측의 파일 및 레지스트리에 대한 읽기/쓰기, agent 환경에서의 실행 파일 구동 등은 가능합니다. 사용자가 동의한 경우에는 특정 사용자 파일에 액세스할 수 있는 경우도 있습니다.

따라서 containment (격리)는 "무엇을 해도 안전해지는 상자"가 아닙니다. 사용자 동의, 데이터 공유 제어, tool (도구) 내용 확인, 로그, 감사(audit) 등과 결합되어야 합니다.

또한, 모든 등록 방식이 동일한 보호를 받는 것은 아닙니다.

Windows가 제공하는 server나, MSIX package 또는 external location (외부 위치)을 가진 package로서 등록된 server는 agent session (에이전트 세션)에서 실행됩니다. 반면, 현재 프리뷰 단계에서는 MCP bundle (.mcpb) 등의 unpackaged application (언패키지 애플리케이션)은 containment (격리) 환경에서 실행할 수 없으며, 기본적으로 ODR에서 이용할 수 없습니다.

테스트 목적이라면 Windows Settings (Windows 설정)의 "Reduce protections for agent connectors"에 해당하는 설정을 활성화하여 실행할 수 있지만, 더 넓은 액세스 권한으로 동작하기 때문에 추가적인 보안 리스크가 있다고 설명되어 있습니다.

개발자 관점에서는 ODR와 같은 공통의 발견 및 관리 기반이 있으면 Windows용 AI 연동을 구축하기가 더 쉬워집니다.

예를 들어, 어떤 앱이 MCP server를 제공하고 ODR에 등록할 수 있게 되면, 다른 AI 앱이나 에이전트 Host (호스트)는 해당 앱 전용의 연동 코드를 개별적으로 가지고 있지 않더라도, 등록 정보를 통해 이용 가능한 기능을 발견할 수 있습니다.

이는 Windows 앱이 "인간을 위한 GUI"뿐만 아니라 "에이전트를 위한 조작면"도 갖게 되는 것으로 볼 수도 있습니다.

사용자 관점에서는 다음과 같은 경험으로 이어질 가능성이 있습니다.

• 여러 앱과 데이터를 가로지르는 작업을 자연어로 요청하기 쉬워짐
• 로컬 파일이나 Windows 기능을 AI 앱에서 이용하기 쉬워짐
• 어떤 agent (에이전트)가 어떤 MCP server를 이용할지 제어하기 쉬워짐
• 로그와 감사를 통해 실행된 조작을 확인하기 쉬워짐

기업 관리자 관점에서는 Windows Settings나 Microsoft Intune 등을 통해 agent와 MCP server의 이용을 관리할 수 있다는 점이 중요합니다.

Microsoft Learn에서는 Windows의 기본 connector (커넥터)로 File Explorer MCP server가 포함될 수 있음도 설명하고 있습니다.

서두에서 예로 든 "문서 폴더에서 파일을 찾는" 것과 같은 작업은 이러한 방향성을 상상하기 쉬운 예시입니다.

ODR와 같은 메커니즘은 편리함과 위험함이 공존합니다.

에이전트가 이용 가능한 능력을 발견하기 쉬워진다는 것은, 설계나 운용을 잘못하면 의도하지 않은 tool (도구)도 호출하기 쉬워진다는 것을 의미합니다.

특히 주의해야 할 점은 다음과 같습니다.

• 정식 server와 유사한 이름이나 설명을 가진 악의적인 MCP server
• 필요 이상으로 넓은 조작을 수행할 수 있는 tool (도구)
• manifest (매니페스트)나 설명문과 실제 동작이 다른 tool (도구)
• prompt injection (프롬프트 인젝션)에 의한 의도하지 않은 tool (도구) 호출
• 사용자 데이터를 외부 서비스로 전송하는 경로
• 동일한 Host (호스트) 내의 여러 server에서 공유되는 파일 액세스 권한
• containment (격리)되지 않는 등록 방식이나 보호 수준을 낮추는 설정의 이용
• 기업 단말에서의 관리 정책 위반

이는 기존의 앱 권한이나 브라우저 확장 프로그램의 문제에 LLM (대규모 언어 모델)에 의한 판단의 불확실성이 더해지는 이미지입니다.

그렇기에 ODR은 단순한 "편리한 목록"만으로는 부족합니다.

다음 요소들을 조합하여 고려해야 합니다.

• server (서버)의 제공처와 등록 방식
• package identity (패키지 식별 정보)
• manifest (매니페스트)와 실행 시 정보의 정합성
• tool (도구)이 실제로 수행하는 처리
• 사용자 동의
• Host (호스트) 단위의 액세스 권한
• containment (격리) 여부
• 관리자 정책
• 로그와 감사

또한, AI가 생성한 판단이나 출력은 반드시 사용자의 의도대로만 이루어지는 것은 아닙니다. 중요한 조작에서는 인간이 내용을 확인할 수 있는 설계가 필요합니다.

ODR을 한마디로 정의하자면 다음과 같이 이해할 수 있습니다.

Windows 상의 AI 에이전트가 이용 가능한 로컬/원격 MCP server를 발견하고, 관리된 형태로 이용하기 위한 레지스트리

조금 더 세분화하면 다음 세 가지입니다.

• Discovery (탐색): Windows에 등록된 MCP server와 해당 tool 및 연결 정보를 발견합니다.
• Control (제어): 사용자나 IT 관리자가 agent가 MCP server에 접근하는 것을 제어합니다.
• Security and Audit (보안 및 감사): containment (격리), 승인된 리소스, 로그, 감사 등을 통해 리스크를 억제합니다.

ODR은 MCP server 자체의 안전성을 자동으로 보장하는 메커니즘은 아닙니다.

또한, 모든 MCP server가 항상 containment (격리)되는 것은 아니며, 사용자 파일 권한도 server 단위가 아닌 Host 단위로 처리됩니다.

그럼에도 불구하고, AI 에이전트가 Windows 내에서 자연스럽게 동작하기 위해서는 모델의 지능만으로는 부족합니다.

"어떤 MCP server를 이용할 수 있는가", "어디까지 접근해도 되는가", "누가 허가했는가", "나중에 무엇이 수행되었는지 확인할 수 있는가"와 같은 기반이 필요합니다.

ODR은 그 화려하지는 않지만 중요한 부분을 Windows 상에서 공통화하려는 공식 메커니즘으로 이해하면 파악하기 쉬울 것입니다.

• Model Context Protocol (MCP) on Windows overview - Microsoft Learn
• The Windows on-device agent registry command-line tool (odr.exe) - Microsoft Learn
• Quickstart: MCP host on Windows - Microsoft Learn
• Manually register remote and local MCP servers - Microsoft Learn
• Securely containing MCP servers on Windows - Microsoft Learn
• Register an MCP server with an MCP bundle - Microsoft Learn
• What is the Model Context Protocol (MCP)? - Model Context Protocol
• Specification 2025-11-25 - Model Context Protocol