MCP 서버를 사용하려면 먼저 접속 정보를 설정 파일에 수동으로 작성해야 한다. 1~2개라면 괜찮다. 하지만 사내에 수십 개의 MCP 서버나 에이전트가 세워지고, 외부에도 무수한 도구가 존재하는 세상에서는 이 '사용하기 전에 전부 연결해 두는' 방식이 한계에 부딪힌다. 에이전트는 자신이 모르는 도구를 필요해진 순간에 찾아낼 수 없다.

Model Context Protocol (MCP)나 A2A가 해결한 것은 '어떻게 도구를 호출할 것인가'였다. 호출 방식의 규격은 만들어졌다. 하지만 '목적하는 도구가 어디에 있는가', '어떤 것을 사용해야 하는가', '연결해도 안전한가'와 같이 호출 전 단계의 질문은 아무도 표준화하지 않았다. 이 공백을 메우기 위해 6월 17일, Google이 주도하여 11개사가 함께 공개한 것이 바로 **Agentic Resource Discovery (ARD)**다.

ARD의 구조는 놀라울 정도로 소박하며, 등장인물은 두 종류뿐이다.

하나는 카탈로그(Catalog)다. 조직은 자신의 도메인 직하의 정해진 위치인 https://{domain}/.well-known/ai-catalog.json에 제공하는 에이전트나 MCP 서버, API 목록을 JSON 형식으로 둔다. robots.txt나 security.txt처럼 '기계가 확인하러 오는 주소가 고정되어 있다'고 생각하면 이해하기 쉽다. 주소가 자신의 도메인 하위에 있다는 사실 자체가 후술할 신원 증명의 토대가 된다.

다른 하나는 레지스트리(Registry)다. 이는 공개된 카탈로그를 크롤링하여 색인을 만들고 검색을 수용한다. 사양서에서는 이를 '에이전틱 웹(Agentic Web)을 위한 검색 엔진'이라고 표현한다. 에이전트는 개별 카탈로그를 일일이 전수 조사하는 대신, 레지스트리에 자연어로 질의하기만 하면 된다.

카탈로그 본체는 다음과 같은 형태를 띤다 (사양서 4.1절의 예시).

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

주목해야 할 점은 representativeQueries이다. 항목마다 '이 도구는 이러한 질문에 답할 수 있다'라는 예문을 2~5개씩 덧붙여 둔다. 레지스트리 측은 이 예문을 벡터화(Vectorization)하여 색인하고, 이용자의 자연어 쿼리(Query)와 의미적으로 매칭시킨다. '태그를 정확히 지정하여 검색'하는 것이 아니라 '하고 싶은 일을 쓰면 유사한 것이 반환되는' 설계로 되어 있다.

레지스트리의 API는 3개의 REST 엔드포인트(Endpoint)로 정의되어 있다. 중심은 POST /search로, 자연어인 query.text를 던지면 관련도 순으로 후보가 반환된다.

{
"query": {
"text": "find me a flight booking agent",
...

반환되는 각 후보에는 0~100 사이의 score (의미적 관련도)가 붙는다.

{
"results": [
{
...

나머지 2개는 결과를 패싯 집계(Facet aggregation)하는 POST /explore와, 결정론적으로 목록을 따라가는 GET /agents이다.

여기서 설계 사상이 가장 흥미로운 부분인데, Hugging Face는 공개 기사에서 "선택을 LLM의 외부로 뺀다"라고 단언했다. 기존에는 사용할 수 있는 도구의 설명을 전부 컨텍스트(Context)에 흘려보내 LLM이 선택하게 할 수밖에 없었으며, 이는 토큰 예산의 제약을 받는다. ARD에서는 레지스트리 검색이 후보를 좁힌 뒤, 필요한 만큼만 에이전트에게 전달한다. 컨텍스트 윈도우(Context Window)를 색인이 대신 처리하게 하는 발상이다.

그리고 ARD는 호출 그 자체에는 일절 관여하지 않는다. 찾아낸 후에는 해당 리소스 고유의 프로토콜(MCP, A2A, OpenAPI 등)로 호출한다. 사양은 명확하게 "MCP나 A2A, Skills의 대체가 아니다"라고 위치를 정하고 있다. 호출 전 단계만을 담당하는 얇은 계층(Thin layer)이라고 파악하는 것이 옳다.

검색 엔진이 까다로운 이유는 모르는 상대가 상위에 노출될 수 있기 때문이다. 에이전트가 찾아낸 도구에 인증 정보나 조작 권한을 넘겨준다면, 상대가 주장하는 존재가 맞는지 기계적으로 확인할 수 없다면 문제가 된다. Hugging Face 기사의 표현이 핵심을 찌른다.

검증 없는 발견은, 낯선 상대를 신뢰하는 작업을 산업화할 뿐이다.

ARD는 이 검증을 도메인 소유권과 연결하여 해결한다. 각 항목의 식별자는 urn:air:<publisher>:<namespace>:<name> 형식이며, 맨 앞에 도메인이 들어간다. 나아가 trustManifest에 암호학적 신원(SPIFFE ID, DID, HTTPS의 FQDN 등)을 담는다. 레지스트리나 오케스트레이터(Orchestrator)는 URN에서 도메인을 추출하고, trustManifest

의 암호학적 주장(cryptographic assertion)과 대조한다. 해당 도메인이 발행한 유효한 증명을 제시하지 못하면, 그 능력은 거부된다. 요컨대, 신원의 뿌리를 DNS와 도메인 관리라는 기존의 신뢰 기반(trust infrastructure)에 두고 있는 것이다. SOC2나 HIPAA와 같은 준수 선언(compliance attestation)을 attestations에 담을 수 있는 틀도 마련되어 있다.

단순히 사양(specification)에 그치지 않고, 공개와 동시에 구현체(implementation)가 나오고 있다.

GitHub의 Agent Finder는 "모든 것을 사전에 연결하지 않고, 인덱스(index)에서 관련 정보만 추출한다"라는 ARD의 목표를 그대로 제품화한 것으로, 컨텍스트 비대화(context bloating) 문제로 고민하는 사람들에게 가장 와닿는 입구가 될 것이다.

냉정하게 살펴봐야 할 점도 있다. 리포지토리(ards-project/ard-spec, Apache-2.0) 상의 사양은 v0.9 드래프트 단계이며, 실제 세부 사항은 아직 유동적이다. 예를 들어 MCP 서버를 가리키는 미디어 타입(media type)은 사양 본문의 예시에서는 application/mcp-server-card+json을 사용하지만, Hugging Face의 구현 예시에서는 application/mcp-server+json을 사용하고 있어 일치하지 않는다. type이 IANA 미디어 타입으로 분류를 나타내는 이상, 이 부분이 어긋나면 검색 필터의 상호 운용성(interoperability)이 무너진다. 발견 규격으로서의 가치는 결국 레지스트리의 랭킹 품질과, 누가 얼마나 성실하게 카탈로그를 공개하느냐에 달려 있다. 인덱스가 빈약하면 "검색 엔진"은 헛스윙을 하게 된다.

그럼에도 불구하고, A2A, MCP, Skill과 역할이 중복되지 않는 "호르기 직전의 계층"을 깔끔하게 분리하고, 신뢰의 뿌리를 도메인에 둔 설계 판단은 영리하다. 프로토콜의 난립이 아니라, 기존 프로토콜 위에 검색과 ID 검증을 한 층 더 얹는 방향이기 때문이다. 사내에 여러 개의 MCP 서버나 에이전트를 보유하기 시작한 조직이라면, 우선 자신들의 /.well-known/ai-catalog.json에 무엇을 담을지 정리하는 것부터 이 규격과의 거리를 가늠해 볼 수 있을 것이다.