AI 에이전트가 늘어날수록 핵심 문제는 “무엇을 할 수 있나”에서 “필요한 리소스를 어떻게 찾고 신뢰할 수 있나”로 이동합니다. 지금은 개발자가 도구, API, 에이전트를 미리 연결하는 방식이 많습니다. 하지만 MCP 서버, A2A 에이전트, API가 계속 늘어나면 사전 연결 방식만으로는 확장하기 어렵습니다.
Agentic Resource Discovery, 즉 ARD는 이 문제를 다루는 초안 사양입니다. 에이전트가 사용할 수 있는 리소스를 표준 형식으로 공개하고, 검색 가능한 방식으로 연결하자는 제안입니다.
ARD는 에이전트용 리소스 발견 규칙이다
ARD v0.9는 MCP 도구, A2A 에이전트 카드, 스킬, API 같은 호출 가능한 서비스를 “agentic resources”로 보고, 이를 연합된 방식으로 찾게 합니다.1 Microsoft, Google, GoDaddy, Hugging Face 등의 기여자가 개발한 공개 초안 사양으로, 핵심 구성은 두 가지입니다.
첫째는 정적 매니페스트인 ai-catalog.json입니다. 표준 위치는 다음과 같습니다.2
https://<publisher-domain>/.well-known/ai-catalog.json조직은 이 위치에 자신이 제공하는 에이전틱 리소스 목록을 게시할 수 있습니다. 정적 JSON 매니페스트는 크롤러와 디스커버리 서비스가 분산 방식으로 캐시 가능한 수집을 하도록 설계됐습니다.2
둘째는 동적 레지스트리 검색 API입니다. ARD는 POST /search를 정의해, 레지스트리가 여러 카탈로그를 수집·색인하고 에이전트가 의도 기반으로 검색할 수 있게 합니다.3 즉, 개별 조직은 카탈로그를 공개하고, 검색 서비스는 이 카탈로그들을 모아 탐색 가능한 인덱스로 만드는 구조입니다.
변화의 핵심: 설치보다 발견
기존 방식은 앱스토어 또는 플러그인 설정에 가깝습니다. 필요한 도구를 사람이 미리 고르고, 연결하고, 유지해야 합니다. ARD가 제안하는 방향은 다릅니다. 에이전트가 작업 중 필요한 기능을 검색하고, 후보를 비교한 뒤, 적절한 리소스로 연결되는 흐름입니다.
이를 위해 ai-catalog 표준은 특정 아티팩트 종류에 묶이지 않는 기본 데이터 모델을 제공합니다.2 하나의 형식 안에 API, 에이전트 카드, 도구, 스킬처럼 서로 다른 리소스를 표현할 수 있게 하려는 의도입니다.
ai-catalog.json의 루트 요소에는 다음 항목이 포함됩니다.2
specVersion: 카탈로그 형식의 버전host: 카탈로그 운영 주체의 표시 이름과 DID 또는 도메인 식별자entries: 개별 에이전틱 리소스 카드 정의의 배열collections: 하위 카탈로그나 관련 부서별 피드 링크
이 구조의 장점은 단순합니다. 조직은 자신이 가진 리소스를 기계가 읽을 수 있는 목록으로 공개하고, 에이전트와 검색 서비스는 그 목록을 일관된 방식으로 해석할 수 있습니다.
발견만큼 중요한 것은 신뢰다
에이전트가 어떤 도구를 찾았다고 해서 바로 사용할 수는 없습니다. 누가 제공했는지, 어떤 근거로 신뢰할 수 있는지, 준수나 감사 정보가 있는지 확인해야 합니다.
그래서 ai-catalog 표준은 점진적 신뢰 계층과 검증 규칙도 포함합니다.2 각 항목은 trustManifest를 통해 신원, 감사·준수 증명, 출처, 서명 같은 정보를 연결할 수 있습니다.2 ARD의 실질적 가치는 단순 검색이 아니라, “찾은 리소스를 검토 가능한 형태로 제시한다”는 데 있습니다.
이 지점이 에이전트 생태계에서 중요합니다. 사람이 앱을 고를 때는 브랜드, 리뷰, 문서, 가격을 함께 봅니다. 에이전트도 비슷한 판단 재료가 필요합니다. ARD는 그 판단 재료를 기계가 읽을 수 있는 메타데이터로 제공하려는 시도입니다.
조직이 지금 준비할 일
ARD를 적용하기 위해 처음부터 거대한 플랫폼을 만들 필요는 없습니다. 먼저 공개 가능한 도구, API, 에이전트, 스킬 목록을 정리하고, 이를 ai-catalog.json으로 표현하는 것이 출발점입니다.
실무적으로는 다음 질문부터 점검할 수 있습니다.
우리 서비스 중 에이전트가 호출할 수 있는 리소스는 무엇인가?
각 리소스의 설명, 엔드포인트, 사용 조건은 명확한가?
운영 주체와 식별자는 일관되게 표현되는가?
하위 카탈로그나 부서별 피드를 분리해야 하는가?
신뢰와 검증에 필요한 정보는 무엇인가?
이미 실험해볼 수 있는 구현도 있습니다. Hugging Face Discover Tool은 ARD의 참조 구현입니다.4 Hugging Face 카탈로그는 아래 위치에 게시되어 있습니다.
https://huggingface.co/.well-known/ai-catalog.json검색 엔드포인트도 공개되어 있습니다.
POST https://huggingface-hf-discover.hf.space/search결론: 에이전트 시대의 배포는 검색 가능성까지 포함한다
ARD의 의미는 단순히 새 표준이 하나 더 생겼다는 데 있지 않습니다. 에이전트가 서비스를 찾고, 비교하고, 신뢰 여부를 판단하려면 사람이 읽는 문서만으로는 부족합니다. 기계가 읽고 검증할 수 있는 메타데이터가 필요합니다.
앞으로 “우리 서비스가 에이전트에게 발견될 수 있는가”는 제품 배포의 기본 질문이 될 가능성이 큽니다. ARD는 그 질문에 답하기 위한 초기 규칙을 제시합니다. 지금 조직이 할 수 있는 가장 현실적인 첫걸음은, 에이전트가 이해할 수 있는 카탈로그를 준비하는 것입니다.
1ARD Specification - AgenticResourceDiscovery.org
2docs/docs/ai_catalog_spec.md at main · ards-project/docs · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.