Agentic Resource Discovery(ARD): Google과 Microsoft 등이 함께 제안하는, 에이전트를 위한 개방형 자원 탐색 표준

9bow · 6월 23, 2026, 3:30오전

Agentic Resource Discovery(ARD) 소개

오늘날 AI 에이전트는 더 이상 혼자 동작하지 않습니다. 하나의 작업을 끝내기 위해 외부 도구를 호출하고, 다른 팀이 만든 스킬을 빌려 오고, 때로는 또 다른 전문 에이전트에게 일을 넘깁니다. 이렇게 도구(Tool), 스킬(Skill), 에이전트(Agent) 가 조직과 플랫폼의 경계를 넘어 하나의 거대한 생태계를 이루기 시작하면서, 에이전트는 세 가지 질문에 답할 수 있어야 합니다. "필요한 능력은 어디에 있는가, 그중 무엇을 써야 하는가, 그리고 그것에 안전하게 연결해도 되는가?" 문제는 지금까지 조직의 경계를 가로질러 이 질문에 답하는 표준이 없었다는 점입니다.

Agentic Resource Discovery(ARD)는 바로 이 빈자리를 메우기 위해 제안된 개방형 명세입니다. AI 능력(capability)을 웹에 게시(publish)하고, 색인(index)하고, 발견(discover)하고, 검증(verify)하는 공통 계층을 정의합니다. 핵심 아이디어는 단순합니다. "각 도구가 어떤 프레임워크나 프로토콜, 제공자 위에서 동작하든 상관없이, 어떤 에이전트라도 그것을 동적으로 찾아서 신뢰를 확인한 뒤 연결할 수 있게 하자" 는 것입니다. ARD는 Google, Microsoft, Hugging Face를 비롯해 Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, ServiceNow, Snowflake 등 업계 전반의 파트너들이 함께 만들었습니다.

이 글에서는 ARD가 풀려는 문제가 무엇인지, 카탈로그와 레지스트리라는 두 축이 어떻게 동작하는지, 데이터 모델(ai-catalog.json)과 신뢰 모델(trustManifest), 검색 API(POST /search)는 어떤 모습인지, 그리고 Hugging Face와 GitHub, Google Cloud의 레퍼런스 구현이 이를 어떻게 실체화했는지를 차례로 살펴봅니다. 이미 MCP, A2A 같은 프로토콜을 알고 계신 분이라면, ARD는 그 앞단(in front of) 에 놓이는 "발견 계층"이라고 이해하시면 가장 빠릅니다.

왜 '발견'이 별도의 계층이어야 하는가

지금까지 에이전트가 능력을 얻는 방식은 "먼저 설치하고 나중에 쓴다(install-first, use-later)" 였습니다. 개발자가 MCP 서버 URL을 설정 파일에 하드코딩하거나, 사용자가 플러그인으로 서비스를 연결해 두는 식입니다. 이 방식은 매일 쓰는 몇 개의 도구에는 잘 맞지만, 수천, 수만 개의 즉석(ad-hoc) 능력으로는 확장되지 않습니다. Microsoft의 설명을 빌리면, 갓 설치한 GitHub Copilot은 소수의 내장 도구만 노출하고, 숙련된 개발자가 커넥터를 몇 개 더 연결해도 수십 개가 한계입니다. 그런데 실제로 존재하는 도구는 이미 수십만 개에 달하고 매일 늘어납니다. 에이전트가 볼 수 있는 것과 실제로 존재하는 것 사이에는 몇 자릿수의 격차가 있고, "AI는 명시적으로 연결된 것만 쓸 수 있으며, 나머지는 존재하지 않는 것이나 마찬가지" 인 상황입니다.

또 다른 한계는 컨텍스트 윈도우(context window)입니다. LLM이 도구를 고르는 가장 흔한 방식은 모든 도구 설명을 컨텍스트에 통째로 집어넣고 모델이 직접 고르게 하는 것인데, 이 방식은 능력의 수가 늘어날수록 토큰 예산을 빠르게 소진합니다. ARD는 이 선택(selection) 문제를 LLM 바깥으로 꺼내, 전용 검색 서비스에 맡깁니다. 검색 서비스는 발행자 정체성, 대표 질의(representative queries), 컴플라이언스 메타데이터, 사용 패턴 같은 더 풍부한 신호를 활용해 능력을 정렬할 수 있으며, 이 과정에서 컨텍스트 토큰을 소비하지 않습니다.

이 구도는 초기 웹의 역사와 닮았습니다. 수백만 개의 페이지가 존재했지만 대부분의 사람은 브라우저 북마크에 미리 채워진 사이트만 방문했습니다. 웹은 거기 있었지만 "어두웠습니다(dark)". 손으로 큐레이션한 디렉터리는 속도를 따라가지 못했고, 결국 모든 것에 자동으로 도달해 그 순간 필요한 것과 연결해 주는 검색 엔진(Search Engine) 이 웹을 밝혔습니다. ARD는 에이전트 자원 생태계에 같은 일을 하려 합니다.

다만 여기서 한 가지 중요한 구분이 있습니다. "평범한 검색이면 충분하지 않은가?" 라는 물음입니다. 웹 검색이 가능했던 이유는 웹에 이미 발견 가능한 표면이 있었기 때문입니다. 페이지는 다른 페이지로 링크되었고, HTML이 내용을 렌더링 가능한 형태로 기술했으며, HTTP가 크롤러와 브라우저에 공통의 조회 방법을 주었습니다. 반면 에이전트 자원에는 그런 표면이 없었습니다. 이름과 URL만으로는 부족합니다. 에이전트가 어떤 자원을 안전하고 유용하게 발견하려면 그 자원이 무엇을 하는지, 언제 써야 하는지, 어떤 입력을 받는지, 어떤 권한이 필요한지, 누가 운영하는지, 어떻게 호출하는지, 특정 사용자나 조직, 정책 환경에 적합한지 같은 구조화된 정보가 필요합니다. ARD는 에이전트 자원에 그동안 없었던 이 발견 표면(discovery surface) 을 부여합니다.

ARD의 두 가지 기본 구성요소: 카탈로그와 레지스트리

ARD의 아키텍처는 두 개의 기본 요소(primitive) 위에 서 있습니다. 바로 카탈로그(Catalog) 와 레지스트리(Registry) 입니다. 아래 도식이 이 두 축을 한눈에 보여줍니다. 둘은 서로를 보완하며, 에이전트는 둘 중 어느 경로든 독립적으로 사용할 수 있습니다.

카탈로그(Catalog): 도메인에 직접 게시하는 능력 명함

조직은 자신이 제공하는 능력을 기술한 카탈로그를 게시합니다. 핵심은 이 카탈로그가 조직 자신의 도메인 아래에 호스팅된다는 점입니다. 표준 위치는 https://{도메인}/.well-known/ai-catalog.json 으로, 도메인에 대한 소유권 자체가 정체성과 신뢰의 암호학적 토대가 됩니다. 즉 별도의 중앙 등록 기관 없이도, 도메인을 가진 누구나 자신의 능력을 공개할 수 있습니다. 발행자는 다음과 같은 추가 메커니즘으로 카탈로그의 존재를 알릴 수도 있습니다.

Well-Known URI: /.well-known/ai-catalog.json 경로에 매니페스트를 호스팅합니다.
Agentmap 지시문: robots.txt에 Agentmap: https://example.com/catalog.json 형태의 항목을 추가합니다.
HTML Link 태그: 문서의 <head> 안에 카탈로그를 가리키는 <link> 태그를 넣습니다.
DNS: DNS의 서비스 바인딩(Service Binding) 레코드로 정적 카탈로그나 동적 레지스트리 검색 엔드포인트를 직접 가리킵니다.

레지스트리(Registry): 에이전트 웹의 검색 엔진

레지스트리는 에이전트 웹의 검색 엔진 역할을 합니다. 게시된 카탈로그들을 크롤링해 내용을 색인하고, 검색 가능한 형태로 만듭니다. 에이전트가 발견 요청을 보내면, 레지스트리는 조건에 맞는 능력 목록과 함께 발행자를 검증하고 신뢰를 확립하는 데 필요한 메타데이터를 돌려줍니다. 모든 ARD 구현은 웹 인제스천(Web Ingestion), 즉 발견된 URI에서 ai-catalog.json 파일을 크롤링하는 기능을 반드시 지원해야 하며, 선택적으로 git 저장소나 npm, OCI 레지스트리를 스캔하는 파이프라인을 추가할 수 있습니다.

여기서 ARD가 강조하는 한 가지 철학이 있습니다. "목표는 모든 자원을 담은 단 하나의 전역 카탈로그가 아니다" 라는 점입니다. 레지스트리는 여러 개일 수 있고, 각자 무엇을 색인하는지, 누구를 위해 봉사하는지, 어떻게 순위를 매기는지가 다릅니다. 공개 서비스는 웹 전반의 자원을 포함하고, 벤더 서비스는 자사 생태계만 노출하며, 기업 서비스는 내부 자원과 검증된 외부 능력만 노출할 수 있습니다. 에이전트가 어느 레지스트리에 묻느냐에 따라 답이 달라지는 것은 결함이 아니라 의도된 설계 입니다.

Microsoft는 이 점에서 ARD가 평범한 웹 검색보다 DNS에 가깝다고 설명합니다. DNS는 조직이 사설 이름과 공개 이름을 같은 리졸버로 해석하듯, 지역적 통제(local control) 를 유지하면서도 더 큰 공유 시스템에 참여할 수 있게 해 줍니다. ARD도 마찬가지로 능력에 대해 지역적 통제, 상위 소스, 그리고 조직이 통제권을 잃지 않고도 참여할 수 있는 더 큰 생태계라는 모델을 적용합니다.

ARD가 동작하는 방식: 게시에서 호출까지 네 단계

Google 블로그는 ARD 클라이언트가 런타임에 새 능력을 발견하고 실행하는 과정을 데모 영상으로 공개했습니다. 아래 영상에서 터미널의 네 단계 흐름을 확인할 수 있습니다.

전체 흐름은 다음 네 단계로 정리됩니다.

카탈로그 게시(Publishing the catalog): 제공자는 자신의 도메인의 잘 알려진 경로에 ai-catalog.json 파일을 호스팅합니다. 이 카탈로그에는 MCP 서버, A2A 에이전트, OpenAPI 도구, 심지어 중첩된 다른 카탈로그까지 포함될 수 있습니다.
발견과 해석(Discovery and resolution): 클라이언트 에이전트는 두 가지 길을 선택할 수 있습니다. 자연어 의도(intent)로 ARD 레지스트리에 질의하거나, 검색을 건너뛰고 알려진 파트너의 도메인에서 카탈로그를 직접 가져오는(fetch) 것입니다.
암호학적 검증(Cryptographic verification): 운영 환경에서는 발행자가 검증 가능한 신뢰 메타데이터를 첨부할 수 있습니다. 검색으로 찾았든 직접 가져왔든, 클라이언트나 레지스트리는 엔드포인트에 연결하기 전에 발행자의 진짜 암호학적 정체성을 능동적으로 확인합니다.
런타임 직접 연결(Direct runtime connection): 클라이언트 에이전트는 선택한 능력을 동적으로 로드하고, 그 능력의 네이티브 프로토콜이나 API로 상호작용한 뒤 결과를 사용자에게 돌려줍니다.

여기서 주목할 점은, 검증이 끝나면 "ARD는 길을 비켜선다(steps out of the way)" 는 것입니다. ARD는 호출 자체를 대신하지 않습니다. 신뢰 메타데이터를 넘겨주어 에이전트가 도구의 네이티브 프로토콜로 직접, 안전하게 연결하도록 도울 뿐입니다. 즉 ARD는 호출 이전(before invocation) 에 위치하는 계층입니다.

데이터 모델 들여다보기: ai-catalog.json

ARD의 중심 데이터 모델은 발행자가 호스팅하는 능력 매니페스트, 즉 ai-catalog.json 입니다. 이 구조는 Linux Foundation 산하 워킹 그룹이 관리하는 ai-catalog 표준을 기반으로 하며, 여기에 도메인 기반 URN 식별자, 루트 레벨 능력, 대표 질의 같은 발견 전용 속성을 더했습니다. 아래는 명세에 실린 매니페스트 예시를 간추린 것입니다.

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Acme Enterprise AI",
    "identifier": "did:web:acme.com"
  },
  "entries": [
    {
      "identifier": "urn:air:acme.com:agent:assistant",
      "displayName": "Corporate Assistant (A2A)",
      "type": "application/a2a-agent-card+json",
      "url": "https://api.acme.com/agents/assistant.json",
      "description": "General-purpose corporate A2A assistant.",
      "representativeQueries": [
        "help me draft an email to the security working group",
        "summarize my unread messages from Todd"
      ]
    },
    {
      "identifier": "urn:air:acme.com:server:weather",
      "displayName": "Weather Data Node",
      "type": "application/mcp-server-card+json",
      "url": "https://api.acme.com/mcp/weather.json",
      "capabilities": ["WeatherTool", "ForecastTool"],
      "description": "Enterprise weather MCP server for live telemetry.",
      "representativeQueries": [
        "what is the current wind speed in Chicago",
        "get the 5-day forecast for Seattle"
      ]
    }
  ]
}

각 항목(entry)에서 눈여겨볼 필드는 다음과 같습니다.

type (아티팩트 무관 봉투): ARD는 MCP, A2A 같은 개별 아티팩트의 내부 스키마를 정의하거나 제약하지 않습니다. 대신 IANA 미디어 타입 형식의 type 필드로 "이것이 무엇인지" 만 식별하고, 구체적 정의는 각 프로토콜 명세에 위임합니다. 이를 아티팩트 무관 봉투(Artifact Agnostic Envelope) 라고 부릅니다. 덕분에 새로운 아티팩트 프로토콜이 등장해도 ARD 명세를 고치지 않고 같은 봉투에 실어 나를 수 있습니다.
url 또는 data (둘 중 정확히 하나): 안전한 파싱과 예측 가능한 동작을 위해, 항목은 원격 참조인 url과 인라인 문서인 data 중 정확히 하나만 가져야 합니다. 이를 엄격한 값-또는-참조(Strict Value-or-Reference) 규칙이라 합니다.
representativeQueries: "항공편 예약 에이전트를 찾아 줘" 같은 자연어 예시 질의로, 레지스트리가 의미 기반 벡터 임베딩을 만들어 검색 순위에 활용합니다. 2~5개를 권장합니다.
capabilities: ["WeatherTool"] 처럼 특정 스킬이나 도구를 나타내는 문자열로, 전체 아티팩트를 조회하지 않고도 빠른 필터링을 가능하게 합니다.

도메인에 닻을 내린 식별자: urn:air

ARD에서 가장 독특한 설계 결정 중 하나는 식별자(identifier) 형식을 임의의 URI가 아니라 다음과 같은 도메인 기반 URN(domain-anchored URN) 으로 강제한다는 점입니다. 이는 IETF RFC 8141을 따릅니다.

urn:air:<authority-domain>:<path-segments>:<short-name>

여기서 <authority-domain> 은 반드시 발행 조직을 대표하는 정규화된 도메인 이름(FQDN, 예: acme.com, github.com)이어야 합니다. 명세는 HTTP URL 같은 임의의 URI를 식별자로 쓰지 않는 이유를 분명히 합니다.

"임의의 URI, 특히 HTTP URL은 능력의 논리적 정체성 과 물리적 네트워크 위치 를 뒤섞습니다. 기업이 클라우드 제공자를 옮기거나 API 게이트웨이를 재구성하면 HTTP URL은 깨집니다. urn:air: 식별자는 추상적이고 영속적인 계약(noun) 역할을 하며, 물리적 분산과 전송 바인딩은 url 또는 data 필드로 분리됩니다."

"Arbitrary URIs, particularly HTTP URLs, conflate the logical identity of a capability with its physical network location. The urn:air: identifier acts as an abstract, permanent contract (the noun)."

이 도메인 기반 설계는 탈중앙 신뢰(decentralized trust) 의 핵심이기도 합니다. 글로벌 페더레이션 환경에서 악의적 행위자가 자신이 소유하지 않은 네임스페이스(예: urn:air:google.com:tax-agent)를 사칭하는 것을 막아야 하는데, 도메인을 권위 앵커로 삼으면 레지스트리와 오케스트레이터가 URN에서 도메인을 추출해 trustManifest의 암호학적 주장과 교차 검증할 수 있습니다. 발행자가 해당 도메인이 발급한 유효한 증명(예: mTLS 인증서나 SPIFFE SVID)을 제시하지 못하면 그 능력은 거부됩니다. 중앙 명명 위원회 없이도 제로 트러스트 검증이 가능해지는 것입니다.

신뢰와 정체성: trustManifest로 발행자를 검증하다

정체성 바인딩, 컴플라이언스 증명, 출처(provenance), 암호학적 서명은 모두 선택적 객체인 trustManifest 하나로 통합됩니다. 단순한 용도에서는 항목을 가볍게 유지하면서도, 기업 컴플라이언스를 위한 견고한 후크를 제공하기 위한 설계입니다. 아래는 컴플라이언스 증명을 담은 기업용 예시입니다.

{
  "identifier": "urn:air:acme.com:travel:concierge",
  "displayName": "Travel Concierge",
  "type": "application/a2a-agent-card+json",
  "url": "https://api.acme.com/travel/concierge.json",
  "trustManifest": {
    "identity": "spiffe://acme.com/travel/concierge",
    "identityType": "spiffe",
    "attestations": [
      { "type": "SPIFFE-X509", "uri": "https://acme.com/.well-known/spiffe/jwks" },
      { "type": "SOC2-Type2", "uri": "https://trust.acme.com/reports/soc2.pdf" },
      { "type": "GDPR", "uri": "https://trust.acme.com/compliance/gdpr" }
    ]
  }
}

trustManifest의 주요 멤버는 다음과 같습니다.

identity (필수): SPIFFE ID, DID, HTTPS FQDN URI 같은 전역 고유 암호학적 워크로드 식별자입니다. 발견용 식별자(identifier)와는 분리되지만, 이 정체성 안의 암호학적 신뢰 도메인은 발견 식별자의 권위 도메인과 일치해야 합니다.
attestations: SOC2-Type2, HIPAA-Audit 같은 검증 가능한 주장 목록으로, 각 증명은 타입과 문서 URI, 선택적 무결성 해시(digest)를 가집니다.
provenance: derivedFrom, publishedFrom 같은 관계로 아티팩트의 계보와 출처를 기록합니다.
signature: 신뢰 매니페스트 내용에 대해 계산된 분리형 JWS 서명입니다.

Google Cloud는 이 신뢰 계층을 Gemini Enterprise Agent Platform의 Agent Registry로 구현하면서, Agent Identity로 신뢰 매니페스트를 검증하고 HIPAA 같은 기업 컴플라이언스 기준을 충족하도록 했습니다. 전역 고유 URN 부여, 에이전트 이그레스(egress) 정책 강제, 도구와 명세 고정(pinning) 같은 거버넌스 기능도 여기서 담당합니다.

검색 API: POST /search와 페더레이션

상호운용성을 보장하기 위해, ARD를 준수하는 모든 에이전트 레지스트리는 표준 HTTP REST 검색 인터페이스를 반드시 노출해야 합니다. 특화된 프로토콜은 실행에 쓰일 수 있지만, 발견만큼은 어떤 HTTP 클라이언트라도 접근할 수 있는 보편적 기준선이 필요하다는 원칙입니다. 핵심은 POST /search 엔드포인트이며, 자연어 text와 구조화된 filter로 구성된 query 객체를 받습니다.

{
  "query": {
    "text": "find me a flight booking agent",
    "filter": {
      "type": ["application/a2a-agent-card+json"],
      "tags": ["finance"],
      "trustManifest.attestations.type": ["SOC2-Type2"]
    }
  },
  "federation": "referrals",
  "pageSize": 5
}

text는 의미 기반 관련성으로 결과를 좁히고, filter는 점(.)으로 구분된 필드 경로로 중첩 필드까지 제약합니다. 한 키 안의 값들은 OR로, 서로 다른 키 사이는 AND로 결합됩니다. 응답은 관련성 점수(score, 0~100)가 붙은 카탈로그 항목 목록을 돌려주는데, 명세는 "이 점수는 의미적 관련성일 뿐, 암호학적 신뢰나 컴플라이언스, 안전 등급으로 해석되어서는 안 된다" 고 못 박습니다. 신뢰 평가는 trustManifest 계층에서 완전히 분리되어 처리됩니다.

REST가 의무이기 때문에 레지스트리 간 라우팅, 즉 페더레이션(Federation) 도 단순한 HTTP 연산이 됩니다. 클라이언트는 federation 파라미터로 토폴로지를 직접 통제합니다.

모드	동작
`auto`	레지스트리가 상위 레지스트리들에 자동 질의하고, 결과를 자신의 것과 병합해 단일 응답으로 반환
`referrals`	자신의 결과에 더해, 클라이언트가 추가로 질의할 수 있는 다른 레지스트리들의 항목을 함께 반환
`none`	자신의 색인만 검색

이 밖에도 패싯(facet) 집계를 돌려주는 선택적 POST /explore, 개발자 포털용 결정적 브라우징을 위한 GET /agents가 정의되어 있고, REST를 기준선으로 두되 레지스트리가 추가로 자신의 검색 능력을 MCP 도구나 A2A 스킬로도 노출할 수 있습니다.

통합 예시: 항공권 예약과 경비 보고

명세에 실린 통합 시나리오는 ARD의 흐름을 잘 보여줍니다. 사용자가 오케스트레이터에게 "도쿄행 항공편을 예약하고 출장 경비 보고서를 제출해 줘" 라고 요청하면, (1) 오케스트레이터는 기업 레지스트리에 federation: "referrals" 로 질의하고, (2) 레지스트리는 내부 경비 에이전트와 함께 다른 레지스트리로의 추천을 반환하며, (3) 오케스트레이터는 추천을 따라 공개 레지스트리에서 항공권 예약 에이전트를 찾고, (4) 두 능력을 각자의 프로토콜(예약은 A2A, 경비는 MCP)로 호출합니다.

레퍼런스 구현과 생태계

ARD는 명세에 그치지 않고 여러 레퍼런스 구현과 함께 공개되었습니다. 발견과 실행을 분리한다(separates discovery from execution) 는 설계 덕분에, 한 서비스를 통한 검색이 다른 서비스가 호스팅하는 능력까지 드러낼 수 있는 페더레이션이 프로토콜에 내장되어 있습니다.

Hugging Face Discover Tool

Hugging Face의 Discover Tool은 ARD의 레퍼런스 구현으로, Hugging Face Hub 위의 수천 개 스킬과 ML 애플리케이션, MCP 서버에 대한 검색 접근을 제공합니다. 동작 원리는 새 아티팩트 형식을 발명하는 대신, Hub의 기존 Spaces 의미 검색을 ARD 봉투로 감싸는 것입니다. 같은 Space가 클라이언트의 요청에 따라 스킬로도, MCP 서버로도 표면화됩니다. discover는 Hugging Face CLI(hf)에 내장되어 있습니다.

# Install the Hugging Face CLI tool:
uv tool install huggingface_hub

# Search for resources to train a model
hf discover search "Fine tune a language model"

# Find MCP Servers to generate an image
hf discover search "Generate an image" --json --kind mcp

# Search other registries
hf discover search "Purchase aeroplane tickets" --registry-url <catalog-url>

Hugging Face 카탈로그는 잘 알려진 URL인 https://huggingface.co/.well-known/ai-catalog.json 에 게시되며, REST로 직접 검색할 수도 있습니다.

curl -s https://huggingface-hf-discover.hf.space/search \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "text": "fine tune a sentence transformer",
      "filter": {
        "type": ["application/ai-skill"]
      }
    },
    "pageSize": 5
  }'

Hugging Face는 응답이 미디어 타입으로 구동되어, 기본값인 application/ai-skill(Space의 agents.md를 감싼 SKILL.md), application/mcp-server+json(MCP 태그가 붙은 Space), 원시 Space 메타데이터 등 세 가지 타입을 지원한다고 설명합니다. 다음 단계로는 명세의 페더레이션 모드(auto, referrals, none)와 더 긴밀한 통합, 그리고 사용자와 조직 프로필에 정적 ai-catalog.json 매니페스트를 다는 Hub 차원의 지원을 예고했습니다.

Hugging Face Discover 더 알아보기

Agentic Resource Discovery: Let agents search - Hugging Face 공식 블로그

Hugging Face Discover Tool - GitHub 저장소

Agent Skills on the Hub - 공식 문서

GitHub agent finder

Microsoft에 따르면, GitHub은 ARD 위에 agent finder를 함께 출시했습니다. GitHub Copilot이 주어진 작업에 맞는 MCP 서버, 스킬, 도구, 에이전트를 런타임에 동적으로 찾아 호출하게 해 주는 기능입니다. 모든 도구를 미리 적재해 컨텍스트 윈도우를 부풀리는 대신, GitHub의 공개 AI 자원 큐레이션 카탈로그나 사설 레지스트리를 검색해, 프롬프트가 요구하는 자원만 필요한 순간에 컨텍스트에 주입합니다.

Google Cloud Agent Registry

Google Cloud는 Gemini Enterprise Agent Platform의 Agent Registry로 이 비전을 기업용 제품으로 구현했습니다. 에이전트, 스킬, MCP 서버 등 에이전트 자원을 검색, 발견, 호스팅하는 완전 관리형 지원을 제공하며, 전역 페더레이션 네트워크의 일부를 이룹니다. ARD에 대한 네이티브 지원은 향후 수개월 내 제공될 예정입니다.

기존 프로토콜(MCP, A2A, Skills)과의 관계

ARD를 이해할 때 가장 흔한 오해는 "이게 MCP나 A2A를 대체하는가?" 입니다. 답은 아니오입니다. Hugging Face의 정리가 명료합니다. MCP는 에이전트가 도구를 호출하는 표준 방법을, 스킬(Skill)은 지침을 소비하는 방법을, A2A는 다른 에이전트를 호출하는 방법을 줍니다. 그런데 세 프로토콜 모두 사용자가 이미 어떤 도구, 지침, 에이전트가 필요한지 안다고 가정 합니다. 발견, 통합, 유지보수의 책임은 여전히 사용자에게 있습니다.

ARD는 바로 그 앞단에 놓이는 발견 계층입니다. 능력을 어떻게 카탈로그화하고 색인하고 검색하는지를 정의해, 에이전트가 능력을 미리 설치하는 대신 런타임에 찾을 수 있게 합니다. ARD는 제품도, 마켓플레이스도 아닙니다. 어떤 회사든 독립적으로 구현할 수 있고 어떤 에이전트나 도구든 참여할 수 있는 공유 표준입니다.

구분	MCP / A2A / Skills	ARD
역할	능력의 실행(invocation)	능력의 발견(discovery)
전제	어떤 능력을 쓸지 이미 안다	어떤 능력이 있는지 찾아낸다
시점	호출 시	호출 이전
관계	ARD가 찾아 준 능력을 네이티브로 호출	MCP, A2A, Skills를 봉투로 감싸 색인

이러한 맥락에서 ARD는 지난 한 해 쏟아진 에이전트 프로토콜들의 상위 계층 으로 자리매김합니다. MCP, A2A, UCP, AP2 같은 프로토콜 전반을 조망하고 싶다면 PyTorchKR의 AI 에이전트 프로토콜 개발자 가이드가 좋은 출발점이며, Agent Network Protocol(ANP) 같은 P2P 연결 표준과 비교해 보아도 ARD의 위치가 또렷해집니다.

마치며: 공개 생태계를 위한 한 표를

ARD는 현재 v0.9 (Draft) 단계의 제안으로, Junjie Bu (Google), R.V.Guha (Microsoft), Shaun Smith (Hugging Face)가 저자로 이름을 올렸습니다. 명세를 바꾸려면 먼저 이슈로 논의를 시작하도록 설계되어 있고, CDDL(RFC 8610), JSON Schema, OpenAPI 세 가지 형식의 정식 스키마와 Python 기반 무의존성 적합성 테스트 도구(conformance test)까지 함께 제공됩니다.

Microsoft의 표현을 빌리면, 이들이 명세를 개방형으로 먼저 내놓은 이유는 분명합니다.

"우리는 닫힌 카탈로그가 아니라 개방형 생태계를 장려하고자 합니다."

"We want to encourage open ecosystems. Not walled catalogs."

에이전트, MCP 서버, API, 그리고 또 다른 에이전트 자원의 생태계가 커질수록, 발견 은 이 모든 것이 규모 있게 동작하기 위한 근본 과제가 됩니다. ARD가 그 공통 발견 계층의 사실상 표준으로 자리 잡을지는 앞으로의 구현과 커뮤니티 참여에 달려 있습니다. 직접 카탈로그를 게시해 보고 피드백을 남기는 것이 그 첫걸음입니다.

Agentic Resource Discovery 홈페이지

Agentic Resource Discovery 소개 블로그 (by Google)

Agentic Resource Discovery 소개 블로그 (by Microsoft)

Agentic Resource Discovery 소개 블로그 (by Hugging Face)

Agentic Resource Discovery 프로젝트 홈페이지에 게시된 명세

ARD 명세 GitHub 저장소

라이선스

Agentic Resource Discovery 명세는 Apache License 2.0으로 배포되며, 기반이 되는 ai-catalog 데이터 모델 위에 구축되었습니다. 연구 목적은 물론 상업적 용도로도 자유롭게 사용 및 수정이 가능합니다.

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~