AWS, 에이전트 레지스트리를 위한 연합 레이어로 Agentic Resource Discovery 지원

Amazon Web Services는 Agentic Resource Discovery 사양을 적극 지원하며, 2026년 8월 24일에 이 오픈 표준이 AWS Agent Registry와 어떻게 함께 작동하도록 설계되었는지에 대한 자세한 내용을 발표했습니다. AWS Agent Registry는 올해 초에 프리뷰를 시작한 AI 에이전트, 도구 및 스킬을 위한 관리형 카탈로그입니다.

AWS 게시물은 ARD를 AWS 자체 제품이 남겨둔 문제에 대한 해결책으로 제시합니다. AWS Agent Registry는 조직에 에이전트, MCP 서버, 도구, 에이전트 스킬 및 맞춤형 리소스를 위한 중앙 집중식 검색 가능한 카탈로그를 제공하지만, 이는 오직 자체 AWS 환경 내에서만 가능합니다. 대부분의 기업은 여러 클라우드, 온프레미스 인프라, SaaS 플랫폼에 걸쳐 에이전트를 운영하고 있으며, 각각 고유한 레지스트리와 메타데이터 형식을 가지고 있습니다. 이러한 환경을 연결하려면 현재 모든 레지스트리 쌍 사이에 맞춤형 커넥터를 구축해야 합니다.

ARD는 공유 형식 대안을 제안합니다. 모든 레지스트리가 리소스를 동일한 방식으로 설명하고 공통 프로토콜을 통해 검색을 제공한다면, 게시자는 리소스를 한 번만 기술하고 소비자는 어디서든 이를 발견할 수 있습니다.

Inside the AWS Agent Registry Model

현재 Amazon Bedrock AgentCore를 통해 프리뷰 중인 이 레지스트리는 두 가지 개념을 중심으로 구축됩니다. 레지스트리는 관리자가 자체 권한 및 승인 설정으로 생성하는 카탈로그이며, 레코드는 각 리소스를 설명하는 메타데이터 항목입니다. 게시 워크플로는 관리자를 시작으로 게시자, 큐레이터, 소비자 순으로 진행되며, 레코드가 검색 가능해지기 전에 승인 게이트가 존재합니다. 접근 권한은 AWS Identity and Access Management 자격 증명이나 기업 아이덴티티 제공자의 JSON Web Token을 통해 제어되며, 레지스트리는 원격 MCP 엔드포인트로 노출되어 MCP 호환 클라이언트가 직접 검색할 수 있습니다.

AWS가 특히 유지하려는 부분은 바로 이 거버넌스 레이어입니다. 해당 게시물에서 AWS는 ARD를 집행 지점 외부에 위치한 상호 운용성 레이어로 설명합니다. 카탈로그를 게시하는 조직이 내용, 열람 권한, 접근 취소 시점을 제어하고, 정책이 실제로 적용되는 곳에서 Agent Registry의 기존 승인 및 접근 제어가 그대로 유지됩니다. 이러한 표현은 의도적이며, ARD는 사물을 찾는 역할을 담당하고, 이를 프로덕션에 신뢰하도록 하는 역할은 하지 않음을 강조합니다.

What the ARD Specification Actually Standardizes

ARD는 AWS 프로젝트가 아닙니다. 이 사양은 2026년 6월 17일에 Google, Microsoft, Hugging Face, GoDaddy 등이 참여한 작업 그룹에 의해 발표되었으며, Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow, Snowflake 등이 협력사로 참여했습니다. Apache 2.0 라이선스로 제공되며, agenticresourcediscovery.org에 공개되고 GitHub에 참고 구현이 있습니다. AWS는 사양을 직접 작성하기보다 개발 과정에서 피드백을 제공했습니다.

Google 발표에 따르면, 아키텍처는 두 가지 기본 요소에 기반합니다. 카탈로그는 조직이 자체 도메인 아래에 게시하는 파일(ai-catalog.json과 같은 잘 알려진 경로)로, 사용 가능한 에이전트, MCP 서버, A2A 에이전트, OpenAPI 도구 또는 중첩 카탈로그를 설명하며, 도메인 소유권이 게시자 신원의 암호학적 근거가 됩니다. 레지스트리는 이러한 카탈로그에 대한 검색 엔진 역할을 수행합니다. 레지스트리는 카탈로그를 크롤링하고 인덱싱하며, 자연어 검색 요청에 응답해 일치 항목을 반환하고, 클라이언트가 연결 전에 게시자의 신원을 확인하는 데 필요한 검증 가능한 신뢰 메타데이터를 함께 제공합니다.

ARD가 설정하는 경계는 실행이 아니라 검색입니다. ARD를 통해 리소스를 찾은 클라이언트는 해당 리소스가 기본적으로 지원하는 메커니즘(MCP, API, 에이전트 프레임워크 등)을 통해 호출합니다. 사양 사이트에서는 ARD가 런타임이 아니며, MCP나 A2A 프로토콜을 대체하는 것이 아니며, 중앙 카탈로그도 아니라는 점을 명확히 하고 있습니다. 설계는 각각 자체 신뢰 및 순위 정책을 적용하는 다수의 검색 서비스를 전제로 합니다. AWS는 이를 DNS에 비유합니다. 로컬 레지스트리는 양자 간 계약이나 독점 커넥터 없이 공유 프로토콜을 통해 연합하며, 이는 네트워크 전반에서 이름 해석이 이루어지는 방식과 같습니다.

How the Pieces Fit Together

Agent Registry 고객에게는 마이그레이션 없이 연합을 제공한다는 것이 핵심 메시지입니다. 클라우드, 온프레미스 시스템, SaaS 도구에 걸쳐 에이전트 인프라를 보유한 조직은 이를 ARD 형식으로 노출해 환경 간에 검색 가능하도록 하면서도 로컬 제어를 유지할 수 있습니다. 또한 자체 도메인에 카탈로그를 게시하면 ARD 호환 클라이언트가 이를 검색할 수 있어, 단일 벤더 레지스트리로는 도달할 수 없는 조직 간 경로를 열 수 있습니다.

AWS는 다른 기업이 아직 구축 중인 단계에서 이미 제품을 제공하고 있습니다. Google의 Gemini Enterprise Agent Platform의 일부인 자체 Agent Registry는 향후 몇 달 안에 기본 ARD 지원을 추가할 예정이며, GitHub와 Hugging Face도 사양 작업 그룹에 참여하고 있습니다. 세 클라우드 모두에서 나타나는 패턴은 동일합니다. 내부에는 관리되고 거버넌스가 적용된 레지스트리가, 외부에는 오픈 연합 프로토콜이 존재합니다.

다만 주의할 점은 AWS 게시물에서 설명한 통합이 방향성은 있지만 아직 제공되지 않았다는 것입니다. AWS는 전달 일자를 발표하기보다는 ARD가 Agent Registry 고객에게 어떤 기능을 제공할 것으로 기대하는지를 밝히고 있으며, 레지스트리 자체는 여전히 프리뷰 단계에 머물러 있습니다. 2026년 8월 24일에 확립된 것은 정렬입니다. 가장 큰 클라우드 제공자가 연합하려는 오픈 사양을 명시했으며, 이는 Google과 Microsoft가 구축하고 있는 사양과 동일합니다.