Agentic Resource Discovery (ARD): An open specification for agent discovery

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS Agent Registry는 에이전트 자원의 중앙 검색을 제공하며, 개방형 명세 ARD는 로컬 통제를 유지하면서 여러 환경의 레지스트리를 연결하는 상호운용 계층을 지향한다.

📌 핵심 요약

• 에이전트, MCP 서버, 도구, 스킬, API가 여러 환경에 분산되면서 개발자가 자원을 직접 찾고 검토하며 연결을 유지하는 방식의 확장성이 한계에 부딪힌다.
• AWS Agent Registry는 에이전트 자원을 레지스트리와 개별 자원의 메타데이터 레코드로 관리하며, 조직 전체 또는 자원 유형·단계·팀별 카탈로그와 계정 간 공유를 지원한다.
• AWS Agent Registry는 게시·검토·승인 절차, 의미 기반 검색과 키워드 검색을 결합한 하이브리드 검색, 원격 MCP 엔드포인트, IAM 또는 JWT 기반 접근 제어를 제공한다.
• ARD는 제품이나 단일 레지스트리가 아니라 Apache License 2.0으로 공개된 개방형 표준이며, 공통 자원 형식과 검색 프로토콜을 통해 서로 다른 환경의 레지스트리 연합을 지원하도록 설계됐다.
• AWS는 ARD가 자원 이전 없이 환경 간 검색과 조직 간 공개 검색을 가능하게 하고, 기존 AWS Agent Registry 접근 제어는 집행 지점에 유지되는 보완 관계를 기대한다고 설명한다.

🧩 주요 포인트

1. 자원 분산과 수동 연결의 확장성 한계 → 자원 메타데이터를 모으고 승인된 항목을 검색하는 중앙 카탈로그의 필요성.
2. 환경마다 다른 레지스트리 형식 → ARD의 공통 형식과 검색 프로토콜로 개별 맞춤 커넥터 의존을 줄이는 상호운용 방향.
3. 검색 범위 확대와 로컬 접근 제어 유지 → ARD와 AWS Agent Registry의 보완 가능성이 제시됐으며, 실제 연계 효과는 기대 수준으로 구분할 필요.

🧠 상세 정리

1. 자원 증가에 따른 발견과 연결의 한계

조직이 AI 에이전트와 도구의 활용을 확대하면서 필요한 자원을 찾는 일이 주요 과제로 떠오른다. 팀마다 MCP 서버를 만들고 에이전트와 전문 도구를 배포하지만, 중앙 카탈로그가 없으면 자원이 분리된 상태로 남는다. 개발자는 자원을 직접 찾아 검토하고 연결한 뒤 그 연결까지 유지해야 하며, 한 AI 클라이언트에 설정한 에이전트가 다른 클라이언트에서도 곧바로 사용 가능한 것은 아니다. 소수의 도구를 연결할 때 가능했던 방식은 공개 레지스트리와 기업 내부에 에이전트, MCP 서버, 스킬, API가 늘어나면서 확장성의 한계를 드러낸다.

2. AWS Agent Registry의 카탈로그와 레코드

AWS Agent Registry는 에이전트, MCP 서버, 도구, 에이전트 스킬, 사용자 정의 자원을 위한 중앙 검색 카탈로그를 제공한다. 핵심 구성은 카탈로그 자체인 레지스트리와 개별 자원을 나타내는 레지스트리 레코드로 나뉜다. 레지스트리는 AWS 계정 안에 생성하며, 각각 별도의 권한 구성과 승인 설정을 갖는다. 조직 전체에 하나를 운영하거나 자원 유형, 단계, 팀별로 분리할 수 있고, 계정 간 공유를 통해 전체 AWS Organization에 제공할 수도 있다. 레코드는 자원이 무엇이고 어떤 기능을 하며 어떻게 접근하는지를 설명하는 메타데이터를 담는다.

3. 승인 절차와 기업용 검색·접근 제어

관리자는 레지스트리를 만들고 승인 설정을 구성한 뒤 IAM 또는 기업 신원 제공자의 JWT를 사용해 접근 권한을 설정한다. 게시자는 MCP 서버, 에이전트, 도구를 레코드로 등록해 승인을 요청하고, 큐레이터는 이를 검토해 승인하거나 거절하며 더 이상 사용하지 않는 레코드를 사용 중단 처리한다. 사람과 AI 에이전트는 승인된 자원을 검색하며, 관리자는 필요할 때 레코드를 검색 대상에서 제거할 수 있다. 검색은 의미 이해와 키워드 일치를 결합해 자연어 질의와 정확한 이름 검색을 모두 지원한다. 원격 MCP 엔드포인트를 제공하므로 MCP 호환 클라이언트가 레지스트리에 직접 접근할 수 있으며, 승인 절차는 보안·규정 준수·품질 기준에 맞는 레코드가 검색되도록 한다.

4. 여러 환경의 레지스트리가 만드는 상호운용 문제

AWS Agent Registry는 AWS 환경 안에서의 자원 검색을 해결하지만, 기업의 에이전트와 도구는 여러 클라우드, 온프레미스, SaaS 플랫폼, 기업 애플리케이션에 걸쳐 배포된다. 각 환경은 자체 레지스트리와 명명 규칙, 메타데이터 스키마를 사용할 수 있어 통합 검색이 복잡해진다. 서로 다른 형식을 사용하는 레지스트리를 연결하려면 상호운용이 필요한 레지스트리 쌍마다 맞춤형 커넥터를 만들어야 한다. 원문은 공통 명세를 통해 자원 설명 형식과 검색 프로토콜을 통일하면 이러한 연결 방식을 바꿀 수 있다고 설명한다. 게시자는 자원을 한 번 설명하고 소비자는 여러 환경에서 이를 발견한다는 것이 이 접근의 목표다.

5. ARD의 개방형 명세와 레지스트리 연합

ARD는 제품이나 하나의 레지스트리가 아니라 개방형 표준이며, Apache License 2.0에 따라 공식 사이트와 GitHub에 공개돼 있다. AWS는 명세 개발 과정에서 피드백을 제공했다. 원문은 네트워크 전반의 이름 해석을 가능하게 하는 DNS에 비유해 ARD의 레지스트리 연합 역할을 설명한다. 각 환경의 카탈로그가 공통 프로토콜을 사용하는 엔드포인트로 자원을 노출하면, 다른 레지스트리는 같은 프로토콜을 이해해 여러 카탈로그를 색인하고 통합 검색에 활용할 수 있다. 이 설계는 로컬 레지스트리들이 개별 양자 합의나 독점 커넥터 없이 연합할 수 있도록 하는 데 초점을 맞춘다.

6. 로컬 통제를 유지하는 검색 확장과 기대

AWS는 ARD가 AWS Agent Registry를 보완하는 방향으로 자원 이전 없는 연합, 로컬 통제 유지, 공개 검색 확대를 제시한다. 여러 클라우드와 온프레미스, SaaS에 있는 자원을 일관된 형식으로 노출하면서 각 환경의 통제권을 유지하는 방식이다. 카탈로그를 게시하는 조직은 포함할 자원과 열람 대상, 접근 철회 시점을 결정하며, AWS는 기존 Agent Registry 접근 제어가 집행 지점에 남고 ARD가 상호운용 계층을 맡을 것으로 기대한다. 조직이 자체 도메인에 카탈로그를 공개하면 ARD 호환 클라이언트가 이를 발견하는 조직 간 검색 경로도 제시된다. 이러한 보완 효과는 기대와 방향으로 설명되며, 글은 ARD 명세·참조 구현·AWS Agent Registry 문서와 프리뷰 출시 안내를 소개하고 피드백을 요청한다.

🧾 핵심 주장 / 시사점

• 중앙 카탈로그와 개방형 검색 명세는 서로 다른 범위를 다룬다. AWS Agent Registry는 조직의 자원 관리와 검색을, ARD는 환경 간 상호운용을 담당하는 보완 관계로 제시된다.
• 공통 자원 형식과 검색 프로토콜은 레지스트리마다 별도 연결을 만드는 부담을 줄이는 기반이며, 기존 자원을 다른 환경으로 옮기지 않는 연합 방식과 연결된다.
• 검색 범위가 넓어져도 카탈로그 게시 조직의 접근 통제가 유지되는 설계가 핵심이며, AWS Agent Registry와의 연계 효과는 이미 구현된 기능과 구분해 읽어야 한다.

✅ 액션 아이템

• 에이전트, MCP 서버, 도구, 스킬, API의 자원 분산과 수동 연결 부담을 기준으로 중앙 카탈로그 필요성 검토.
• AWS Agent Registry의 조직 전체·팀별 카탈로그, 승인 절차, IAM 또는 JWT 기반 접근 제어 적용 방식 검토.
• ARD의 공통 형식과 검색 프로토콜을 통한 환경 간 검색 가능성을 검토하되, AWS Agent Registry와의 실제 연계 효과는 기대 수준과 구분.

❓ 열린 질문

• 에이전트, MCP 서버, 도구, 스킬, API 가운데 자원 분산과 수동 연결 부담이 가장 큰 대상은 무엇인가?
• AWS Agent Registry를 조직 전체 카탈로그로 운영할지 팀별로 나눌지 결정하는 기준은 무엇인가?
• ARD와 AWS Agent Registry의 보완 관계에서 환경 간 검색과 로컬 접근 제어 유지가 실제로 구현됐는지 확인하려면 어떤 근거가 필요한가?