ARD: AI 에이전트가 스스로 도구를 찾는 시대
핵심 요약
2026년 6월 17일, Google과 Microsoft가 공동 기획한 Agentic Resource Discovery(ARD) 스펙이 공개됐다. GitHub, Hugging Face, NVIDIA, Salesforce, Snowflake, Cisco, Databricks, GoDaddy, ServiceNow까지 총 11개사가 서명했다. 핵심은 간단하다. AI 에이전트가 어떤 도구가 세상에 존재하는지 스스로 검색하고, 신뢰할 수 있는지 확인하고, 바로 연결할 수 있도록 하는 공개 표준이다.
GitHub는 같은 날 ARD를 구현한 첫 제품 Agent Finder를 GitHub Copilot에 탑재했다. Anthropic과 OpenAI는 서명 명단에 없다.
에이전트가 도구를 찾는 문제
지금까지 AI 에이전트에 도구를 연결하는 방식은 손으로 하드코딩하는 것이었다. 어떤 MCP 서버를 쓸지, 어떤 API를 호출할지 개발자가 직접 명시해야 했다. 에이전트 수가 늘고 도구 생태계가 커질수록 이 방식은 한계를 드러낸다.
ARD는 이 문제를 웹의 방식으로 푼다. 도메인 소유자가 /.well-known/ai-catalog.json에 카탈로그를 게시하면, 크롤러가 수집하고, 에이전트가 자연어 쿼리로 검색한다. 구글이 웹페이지를 인덱싱하는 것과 같은 원리를 에이전트 도구 생태계에 적용한 셈이다.
두 가지 핵심 프리미티브
ARD v0.9 스펙은 두 개의 기본 구성요소를 정의한다.
첫 번째, ai-catalog.json 정적 매니페스트. 조직이 /.well-known/ai-catalog.json 경로에 머신 리더블 카탈로그를 호스팅한다. 여기에는 어떤 MCP 서버, A2A 에이전트, API 도구, 스킬이 있는지 명시된다. robots.txt나 sitemap.xml처럼 잘 알려진 경로에 놓아두기만 하면 된다.
두 번째, 레지스트리 API. 공개 또는 사설 레지스트리가 카탈로그를 크롤링해 인덱스를 구축한다. 에이전트는 이 레지스트리에 자연어로 의도를 전달하면 랭킹된 도구 목록을 받는다. GitHub Agent Finder는 GitHub의 공개 카탈로그와 기업 내부 사설 레지스트리 모두를 지원한다.
| 구성요소 | 역할 | 예시 |
|---|---|---|
ai-catalog.json | 도구 카탈로그 게시 | /.well-known/ai-catalog.json |
| 레지스트리 API | 크롤링 + 자연어 검색 | GitHub Agent Finder 인덱스 |
| 발행자 검증 | 도메인 기반 신뢰 확인 | DNS + 서명 |
| 연결 프로토콜 | 실제 실행 채널 | MCP, A2A, REST API |
스펙은 **도구 탐색(pre-invocation discovery)**에 집중한다. 실제 도구 실행은 MCP나 A2A 같은 기존 프로토콜이 담당한다. ARD는 MCP를 대체하지 않는다. 어디서 MCP 서버를 찾을지 알려주는 레이어다.
GitHub Agent Finder: 첫 구현체
ARD 발표와 동시에 GitHub은 Agent Finder를 GitHub Copilot에 출시했다. 동작 방식은 직관적이다.
에이전트가 복잡한 작업을 수행하다가 특정 능력이 필요해지면, 자연어로 "데이터베이스 스키마를 분석하는 도구가 필요해"라고 검색한다. Agent Finder는 ARD 인덱스를 뒤져 관련 MCP 서버나 도구를 반환하고, Copilot이 그것을 즉시 가져다 쓴다. 작업 시작 전 모든 도구를 미리 선언하지 않아도 된다.
엔터프라이즈 거버넌스도 같은 인터페이스에서 처리된다. 어떤 카탈로그를 허용할지 정책으로 설정하면, Agent Finder는 허용 범위 안의 리소스만 돌려준다.
Anthropic과 OpenAI가 빠진 이유
11개 서명사 목록에서 눈에 띄게 빠진 이름이 있다. Anthropic과 OpenAI다.
이 구도는 우연이 아니다. MCP는 Anthropic이 설계하고 관리하는 도구 실행 프로토콜이다. OpenAI는 자체 Agents SDK를 밀고 있다. ARD를 주도한 측은 Microsoft, Google, Salesforce, Snowflake 같은 엔터프라이즈 플랫폼 기업들이다.
분석가들은 이 구도를 AI 시대의 플랫폼 전쟁으로 읽는다. AI 모델을 공급하는 회사(OpenAI, Anthropic)와 AI 기능을 통합해 플랫폼을 구축하는 회사(Google, Microsoft, Salesforce) 사이의 표준 패권 싸움이다. 도구 탐색 표준을 누가 쥐느냐는 장기적으로 AI 에이전트 생태계의 중심이 어디에 쏠리느냐와 직결된다.
ARD 스펙 자체는 Apache 2.0 라이선스로 공개됐고, 기반 AI Catalog 데이터 모델은 Linux Foundation 워킹 그룹에서 관리한다. Anthropic이나 OpenAI가 나중에 합류하는 것을 막는 조항은 없다.
개발자 입장에서의 실질적 의미
ARD가 채택된다면 AI 에이전트 개발 방식이 바뀐다. 지금은 "이 에이전트에 어떤 도구를 연결할지" 코드로 명시하는 게 기본이다. ARD 이후에는 "이 에이전트가 필요한 도구를 스스로 찾을 수 있도록 카탈로그를 게시했는가"가 더 중요해진다.
도구 공급자 입장에서도 변화가 생긴다. 자기 MCP 서버나 API를 ARD 카탈로그에 등록하면, 별도 마케팅 없이도 에이전트들이 런타임에 발견할 수 있다. 앱스토어가 모바일 앱 발견 문제를 해결한 것처럼, ARD가 에이전트 도구 발견 문제를 해결하려는 시도다.
현 시점에서 공개 카탈로그에 등록된 리소스 수는 적다. v0.9라는 버전 번호가 말해주듯 스펙 자체도 아직 초안 단계다. 실질적 영향은 엔터프라이즈 채택 속도와 주요 카탈로그 크기에 달렸다.
전망
ARD가 풀려는 문제는 진짜다. 에이전트 수가 기하급수적으로 늘어나는 환경에서 도구 탐색을 사람이 수동으로 관리하는 방식은 한계가 있다.
그러나 성패의 관건은 스펙 자체보다 생태계다. ai-catalog.json을 실제로 게시하는 조직이 얼마나 빨리 늘어나느냐, Anthropic의 MCP 레지스트리와 어떻게 공존하거나 경쟁하느냐가 ARD의 미래를 결정할 것이다. Anthropic이 합류하지 않은 상태에서도 충분한 도구 생태계를 구축할 수 있는지가 단기 검증 포인트다.
개인적으로는 표준이 하나로 수렴하지 않을 가능성도 충분하다고 본다. MCP 레지스트리와 ARD가 각자의 생태계를 구축하고 브리지 레이어로 상호 운용되는 형태가 현실적인 중간 경착지일 수 있다.
참고
