최근 AI 에이전트 (Agent)의 진화가 눈부십니다. 에이전트는 스스로 생각하고, 도구를 사용하며, 다른 에이전트와 협력하면서 태스크를 수행합니다.

하지만 에이전트가 "사용할 수 있는 도구 (Tool)"나 "협력할 수 있는 동료 (다른 에이전트)"를 어떻게 찾아낼 것인가라는 점에 있어, 현재 큰 과제가 존재하고 있습니다.

현상황에서 많은 에이전트 시스템은 이용 가능한 도구나 접속처가 개발자에 의해 수동으로 하드코딩 (Hard-coding)되어 있습니다. 이는 인터넷 태동기에 웹사이트에 접속하기 위해 수동으로 디렉토리 목록을 조회하거나, IP 주소를 직접 지정하던 시대와 비슷합니다.

이 과제를 해결하기 위해 Google, Microsoft, Hugging Face 등의 멤버들이 공동으로 책정(策定)을 진행하고 있는 새로운 오픈 사양이 바로 ARD (Agentic Resource Discovery) 입니다.

본 기사에서는 이 ARD가 무엇인지, 왜 필요한지, 그리고 정밀도와 확장성이 뛰어난 시스템을 어떻게 구축할 것인지에 대해 그림과 샘플 코드를 곁들여 알기 쉽게 해설합니다.

에이전트에게 외부 시스템이나 도구 (웹 검색, 데이터베이스, 특정 API 등)를 사용하게 할 경우, 현재 일반적으로 행해지고 있는 접근 방식에는 다음과 같은 심각한 페인 포인트 (Pain Point)가 있습니다.

에이전트가 이용하는 도구의 엔드포인트 (Endpoint, URL이나 API 키 등)는 개발 시에 하드코딩되거나 정적인 설정 파일에 기술되어 있습니다. 도구가 새로 추가되거나 변경될 때마다 시스템의 재배포나 코드 수정이 필요하므로 스케일 (Scale)할 수 없습니다.

LLM에게 도구를 사용하게 하려면 시스템 프롬프트 (System Prompt)나 컨텍스트 윈도우 (Context Window)에 모든 도구의 기능 설명 (Tool Description)을 미리 넣어두어야 합니다.

하지만 사용할 수 있는 도구가 수십, 수백 개로 늘어나면 다음과 같은 문제가 발생합니다.

토큰 소비 (비용) 증대-
LLM의 추론 정밀도 저하 (Attention의 분산): 선택지가 너무 많으면 LLM이 적절한 도구를 올바르게 선택하지 못하거나 지시를 무시할 확률이 높아집니다 (말하자면 "도구가 너무 많아서 미아가 되는" 상태).

ARD (Agentic Resource Discovery) 는 에이전트가 "어떠한 리소스 (도구, 에이전트, API 등)가 존재하며, 그것들이 어디에 있고, 신뢰할 수 있는 것인가"를 동적으로 발견 (검색)하기 위한 표준 프로토콜 사양입니다.

말하자면, **"AI 에이전트를 위한 분산형 검색 엔진 겸 DNS"**라고 할 수 있습니다.

ARD 도입을 통해 에이전트는 기동 시에 모든 도구 사양을 파악해 둘 필요가 없어집니다. 태스크를 실행하는 과정에서 "〇〇를 실행할 수 있는 도구가 필요하다"라고 판단한 시점에 ARD를 통해 동적으로 도구를 검색하고, 그 자리에서 접속하여 이용하는 것이 가능해집니다.

에이전트 생태계 (Ecosystem)에는 ARD 외에도 MCP (Model Context Protocol) 나 A2A (Agent-to-Agent) 와 같은 프로토콜이 존재합니다. 이것들은 경쟁하는 것이 아니라 각각의 역할을 가진 상보적인 프로토콜입니다.

각각의 역할 분담은 다음과 같습니다.

각각의 관계를 도식화하면 다음과 같습니다.

ARD의 중심에 있는 것이 ai-catalog.json 이라는 매니페스트 (Manifest) 파일입니다. 이는 웹사이트에서 말하는

sitemap.xml

이나, 웹 서비스 제공 시의 .well-known/ 구성과 유사합니다. 도구나 에이전트를 제공하는 조직 (Publisher)은 자신이 소유한 도메인 하위에 다음과 같은 URL로 카탈로그 파일을 공개합니다.

https://example.com/.well-known/ai-catalog.json

도메인 직하에 공개함으로써, **"해당 도메인의 소유자가 공식적으로 제공하는 도구이다"라는 암호학적 신뢰성 (Identity & Trust)**이 담보됩니다.

다음은 특정 조직이 제공하는 MCP 서버나 API 도구를 선언하는 ai-catalog.json의 간단한 구현 샘플입니다.

{
"specVersion": "1.0",
"host": {
...

• specVersion: ARD의 사양 버전을 나타냅니다.
• host: 리소스 제공자의 정보. identifier에는 Web 도메인을 기반으로 한 분산형 ID (DID) 등이 사용됩니다.
• entries: 제공하는 리소스의 배열.
• type: application/mcp+json이나 application/openapi+json 등을 지정하여, 어떤 프로토콜로 호출해야 하는지를 나타냅니다.
• url: 접속 대상이나 API 스키마의 URL.
• description: 검색 엔진 (Registry)이나 에이전트가 도구가 필요한지 여부를 판단하기 위한 상세 설명문.

ARD Registry가 웹상의 ai-catalog.json을 순회하며 정보를 수집 (크롤링, Crawl)해 두면, 에이전트는 언제든지 자연어로 필요한 리소스를 찾아낼 수 있게 됩니다.

이 "자연어에 의한 검색"의 이면에는 다음과 같은 시맨틱 검색 (Semantic Search, 의미 검색) 메커니즘이 작동하고 있습니다.

• 사전 인덱싱 (Pre-indexing): Registry는 각 도메인의 ai-catalog.json을 순회하며, 도구의 설명문 (description)을 "의미를 나타내는 수치 벡터"로 변환하여 데이터베이스에 저장해 둡니다.
• 검색 쿼리의 의미 해석: 에이전트가 전송한 "날씨를 조사하고 이미지를 생성하고 싶어"와 같은 모호한 요청도 마찬가지로 벡터 데이터로 변환됩니다.
• 의미 기반 매칭 (Semantic Matching): 쿼리와 등록된 도구 설명문의 유사도를 계산하여, 단어가 완전히 일치하지 않더라도 의도에 가장 가까운 도구의 접속 정보 (메타데이터)를 자동으로 찾아 에이전트에게 반환합니다.

나아가, 에이전트 시스템 측에서 이 검색을 실행하는 (트리거를 당기는) 프로세스에는 주로 다음과 같은 두 가지 설계 접근 방식이 있습니다.

• 에이전트 스스로 판단하여 검색하는 방식 (Agent-Driven 방식):
  에이전트 (LLM)에게 미리 "Registry를 검색하기 위한 검색 도구 (API)"를 인식시켜 둡니다. LLM이 태스크를 처리하는 과정에서 "현재 가지고 있는 도구로는 해결할 수 없다"라고 판단하는 시점에 자발적으로 검색 도구를 호출하여 필요한 리소스를 찾아냅니다.
• 시스템이 백그라운드에서 사전에 검색하는 방식 (System-Driven 방식 / 라우터 방식):
  메인 LLM을 구동하기 전에, 에이전트 실행 엔진 (LangChain이나 LlamaIndex 등의 프레임워크)이 사용자 입력을 Registry에 던져 자동으로 검색합니다. 검색 결과에 해당하는 도구의 메타데이터만을 시스템 프롬프트 (System Prompt)에 동적으로 주입하여 LLM을 구동하기 때문에, LLM이 너무 많은 도구 설명으로 인해 혼란을 겪는 것을 방지할 수 있습니다 (Search-First 접근 방식).

다음은 이 검색으로부터 실제 도구 실행 (MCP/OpenAPI 등에 의한 접속)까지의 처리 흐름입니다.

기존처럼 LLM의 시스템 프롬프트에 모든 도구 정의를 미리 작성해 둘 필요가 없습니다.

"필요할 때, 필요한 것만 검색하여 에이전트의 컨텍스트 (Context)에 추가한다"라는 접근 방식을 취하기 때문에, 컨텍스트 윈도우 (Context Window)가 불필요하게 비대해지지 않으며, API 비용 절감과 LLM의 답변 정확도 향상을 동시에 달성할 수 있습니다.

에이전트의 코드베이스 측을 변경하지 않고도 새로운 도구 (MCP 서버)나 특정 작업에 특화된 전문 에이전트를 동적으로 추가할 수 있습니다.

자사 도메인의 ai-catalog.json에 한 줄을 추가하는 것만으로, 기존의 에이전트들이 자동으로 해당 도구를 인지하고 사용하기 시작합니다.

ARD는 오픈 웹 표준을 목표로 책정되고 있습니다.

자사 내부의 도구뿐만 아니라 인터넷상에 공개되어 있는 안전한 서드파티 (Third-party) 도구나 다른 기업의 에이전트를 안전하게 검색하고 통합하는 것이 가능해집니다. 도메인에 연결된 인증이 있기 때문에 "사칭"이나 "부정 도구 실행"을 방지할 수 있습니다.

현재의 AI 에이전트 개발은 말하자면 「닫힌 로컬 환경」에 의존하고 있습니다. 하지만 ARD (Agentic Resource Discovery)의 등장으로 인해, 에이전트는 자율적으로 Web을 탐색하고, 필요한 기능을 찾아내며, 이를 조립하는 수단을 손에 넣고 있습니다.

MCP가 「도구의 연결 방식」을 결정했다면, ARD는 「도구의 탐색 방식」을 결정하는 것입니다. 이들이 결합됨으로써, 진정한 의미의 「자율형 AI 에이전트 네트워크 (Internet of Agents)」가 현실이 되어갈 것입니다.

부디 여러분의 프로젝트에서도 .well-known/ai-catalog.json 의 설계와, ARD를 활용한 동적인 에이전트 구축을 검토해 보시는 것은 어떨까요?

본 기사는 최신 ARD (Agentic Resource Discovery) 초안 사양 (v0.9)을 기반으로 해설하고 있습니다. 사양은 향후 업데이트에 따라 변경될 가능성이 있습니다.