지금까지 에이전트가 새 도구를 쓰려면, 사람이 먼저 그 도구를 손으로 찾아내 연결해야 했습니다. ARD는 그 순서를 뒤집습니다. 에이전트가 작업 중에 스스로 필요한 도구를 검색해 찾아내죠.
6월 17일, Google·Microsoft·Hugging Face·GitHub를 비롯한 업계 파트너들이 ARD(Agentic Resource Discovery) 라는 공개 명세를 함께 발표했습니다. AI 클라이언트가 자기 도메인에 게시된 도구·스킬·에이전트를 표준화된 방식으로 색인하고 검색할 수 있게 하는 발견(discovery) 계층입니다. MCP가 도구를 ‘어떻게 호출하느냐’를 풀었다면, ARD는 그 앞 단계인 ‘무엇이 존재하는지 어떻게 아느냐’를 노립니다.
출처: Announcing the Agentic Resource Discovery specification – Google Developers Blog
진짜 병목은 호출이 아니라 발견이었다
MCP, Skills, A2A. 요즘 에이전트를 만든다면 이 세 가지는 익숙할 겁니다. 각각 도구 호출, 명령 전달, 에이전트 간 통신을 표준화했죠. 그런데 셋 모두 한 가지를 전제합니다. 사용자가 어떤 도구를 쓸지 이미 알고 있다는 것.
오늘날 에이전트가 도구를 얻는 방식은 ‘먼저 설치, 나중에 사용’입니다. 개발자가 MCP 서버 주소를 설정 파일에 박아넣고, 사용자가 플러그인으로 서비스를 연결하죠. 매일 쓰는 몇 개 도구에는 잘 맞습니다. 문제는 그 바깥입니다. 공개된 에이전트 리소스는 이미 수십만 개 규모인데, 에이전트 하나가 실제로 볼 수 있는 건 명시적으로 연결된 소수뿐입니다. 나머지는 존재하지 않는 것이나 마찬가지죠.
대안으로 가용한 도구 설명을 전부 컨텍스트 창에 쏟아붓고 모델이 고르게 하는 방법도 있습니다. 하지만 컨텍스트 예산에 막히고, 설명이 너무 빈약해 제대로 구분되지도 않습니다. Microsoft는 이 상황을 초기 인터넷에 빗댑니다. 수백만 페이지가 존재했지만 대부분의 사람은 브라우저 북마크에 담긴 사이트만 방문했습니다. 웹은 거기 있었지만 ‘어두웠다’는 거죠. 검색엔진이 모든 것에 닿는 발견 계층을 만들고 나서야 웹이 환하게 켜졌습니다.
카탈로그와 레지스트리, 두 개의 부품
ARD의 구조는 두 가지 요소로 이뤄집니다.
- 카탈로그(Catalog): 도구를 가진 조직이 자기 도메인의 잘 알려진 경로에
ai-catalog.json파일을 올립니다. 어떤 능력을 제공하는지 기술한 문서로, MCP 서버·A2A 에이전트·OpenAPI 도구 등을 담을 수 있습니다. 도메인 소유권 자체가 신원과 신뢰의 암호학적 기반이 됩니다. - 레지스트리(Registry): 에이전트 웹의 검색엔진 역할입니다. 게시된 카탈로그를 크롤링하고 색인해 검색 가능하게 만듭니다.
실제 흐름은 이렇습니다. 클라이언트가 새 능력이 필요하면, 자연어로 작업을 설명해 레지스트리에 검색을 요청합니다. 레지스트리는 조건에 맞는 능력과 함께, 게시자를 검증하고 신뢰를 확인할 메타데이터를 돌려줍니다. 클라이언트는 그 정보로 게시자의 암호학적 신원을 확인한 뒤, 도구의 원래 프로토콜로 직접 연결합니다. ARD는 여기서 빠집니다. 무엇을 쓸지 결정하도록 돕고, 호출 자체는 도구에 맡기죠.
핵심은 선택의 위치를 모델 바깥으로 옮긴다는 점입니다. 지금은 모델이 컨텍스트에 담긴 도구 목록에서 직접 골라야 합니다. ARD에서는 레지스트리가 게시자 신원, 대표 질의, 태그 같은 풍부한 신호로 먼저 추려줍니다. 미리 설치된 정적 목록에서, 런타임 의도 기반 검색으로의 전환입니다.
단일 카탈로그가 아니라 DNS에 가깝다
ARD가 목표로 하는 건 모든 도구를 담은 하나의 거대한 카탈로그가 아닙니다. 여러 발견 서비스가 공존하고, 각자 무엇을 색인하고 누구를 위해 어떻게 순위를 매기는지가 다릅니다. 공개 서비스는 웹 전반의 리소스를 담고, 벤더 서비스는 자사 생태계만 노출하며, 기업용 서비스는 내부 리소스와 검증된 외부 도구만 보여줄 수 있습니다.
Microsoft는 이 통제 모델이 일반 웹 검색보다 DNS에 가깝다고 설명합니다. DNS는 조직이 사설 이름과 공개 이름을 같은 해석기로 처리하게 해줍니다. 로컬 통제를 유지하면서도 더 큰 공유 시스템에 참여하는 구조죠. ARD도 같은 방식을 능력에 적용합니다. 어떤 발견 서비스에 묻느냐에 따라 에이전트가 받는 답이 달라지는데, 이건 결함이 아니라 의도된 설계입니다. 발견 서비스를 운영하는 쪽이 답의 범위를 통제하기 때문입니다.
발표와 함께 실제 구현도 나왔습니다. GitHub의 agent finder는 Copilot이 작업에 맞는 MCP 서버·스킬·도구를 런타임에 찾아 컨텍스트에 주입하고, Hugging Face의 Discover Tool은 허브의 수천 개 스킬과 MCP 서버를 ARD 형식으로 검색하게 해줍니다.
에이전트가 쓸 수 있는 도구가 ‘미리 연결해둔 것’에 갇혀 있던 시대에서, 작업하는 순간 필요한 것을 찾아내는 시대로 넘어가는 신호입니다. 명세는 아직 초안 단계이고, 인증·권한·거버넌스 같은 문제는 ARD가 대신 풀어주지 않습니다. 신뢰 메타데이터의 구체적 스키마와 페더레이션 모델은 공식 명세에서 확인할 수 있습니다.
참고자료:
- Agentic Resource Discovery Specification – ARD 공식 사이트
- Introducing the Agentic Resource Discovery specification – Microsoft Command Line
- Agentic Resource Discovery: Let agents search – Hugging Face Blog
답글 남기기