2026년 6월 1 Google Google, Microsoft, GitHub, Hugging Face를 포함한 11개 회사가 ARD(Agentic Resource Discovery)라는 오픈 표준 초안을 발표했다. AI 에이전트가 웹에서 서로를 발견하고 나는 하고 사용하는 방법에 대한 스펙이다.

나는 이걸 6월 22일에 봤다. 그리고 이미 Drewgent에 구현해놓은 상태였다.

다리가 먼저 움직인 셈이다. 왜 그랬는지, 어떻게 했는지, 이게 왜 중요한지 정리해본다.

TL;DR — ARD란 무엇인가

MCP(Model Context Protocol)가 “AI가 하나의 도구를 쓰는 방법”을 정의했다면, ARD는 “AI가 수많은 도구 중에서 필요한 걸 찾는 방법”을 정의한다.

생각해보자. 지금은 MCP 서버를 쓸 때 그걸 미리 config에 등록해둬야 한다. Claude Desktop의 mcpServers 설정이나 opencode의 opencode.jsonc에 직접 추가하는 식이다. 마치 전화번호부 없이 모든 번호를 외우고 다니는 것과 같다.

ARD는 이걸 바꾼다:

모든 서비스가 /.well-known/ai-catalog.json에 자신의 도구 목록을 publish한다 있었다 이전트가 ARD 레지스트리를 검색해서 필요한 도구를 런타임에 발견한다 SPIFFE/DID 기반 신뢰 검증이 스펙에 포함되어 있다

쉽게 말해: 인간이 Google에서 검색하듯, AI 에이전트가 ARD에서 도구를 검색하는 시대가 오고 있다는 거다.

ARD 아키텍처

있었다 src=”https://humanerd.kr/uploads/2026/06/cover.webp” alt=”ARD Architecture” class=”wp-image-57″/>

┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │ Publisher │────→│ Registry │←────│ Client │ │ (Catalog) │ │ (Search) │ │ (Agent) │ └─────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ /.well-known/ │ POST /search │ discover │ ai-catalog.json │ ?text=flight │ → conne 있었다 ▼ ▼ ▼ “I have these “Found 3 agents “I’ll use the capabilities” matching intent” flight agent”

내가 미리 구현한 이유

6월 14일부터 22일까지 Drewgent를 v0.8로 압축하는 작업을 했다. 에이전트 14개 → 6개, P-layer 7개 → 3개, 스크립트 43개 → 25개. 덜어내는 작업이었다.

그런데 덜어내는 것만으로는 부족했다. 바깥을 향한 연결도 필요했다. 내 에이전트 시스템이 고립되어 있으면 아무 의미가 없으니까.

그때 눈에 들어온 게 두 가지였다:

MCP 서버 도구들 — gbrain, discord, wordpress, gajae-code. 이미 내 시스템은 여러 MCP 서버를 운용 중이었다. AI 에이전트 디스커버리 표준화 움직임 — 당시는 구체적인 ARD라는 이름이 없었지만, MCP 다음 단계로 “agent discovery”가 논의되기 시작하고 있었다.

그래서 6월 21일, Drewgent의 모든 에이전트 프로필을 ai-catalog.json으로 export하는 작업을 시작했다. ARD 스펙이 정식 발표되기도 전이었다.

실제로 무엇을 만들었나

  1. ai-catalog.json

16개 에이전트 프로필을 ARD 스펙(v0.9 Draft)에 맞춰 구조화했다. 각 에이전트마다:

identifier — urn:air:drewgent.ai:agent:implementer 같은 URN 형식 type — application/opencode-subagent+json (커스텀 MIME 타입) capabilities — code-generation, implementation, testing 등 representativeQueries — 이 에이전트에게 물어볼 만한 질문 예시 metadata — 모델, temperature, readOnly 여부

총 10,165줄의 JSON. 하나하나 수동으로 정의했다.

  1. WordPress MU 플러그인으로 serve

이걸 https://humanerd.kr/.well-known/ai-catalog.json에서 서빙하기 위해 WordPress MU 플러그인을 만들었다. /.well-known/ 경로로 들어오는 요청을 인터셉트해서 파일을 serve하는 구조다.

Cloudflare Tunnel을 통과하므로, 외부 AI 에이전트가 humanerd.kr에 접근해서 내 에이전트들의 스펙을 읽을 수 있다.

  1. ard_query.py — ARD 레지스트리 검색기

내 에이전트를 publish하기만 하면 끝이 아니다. 반대로, 다른 사람이 publish한 도구를 검색하는 클라이언트도 필요하다. 그래서 Python으로 ard_query.py를 작성했다.

python3 ard_query.py https://agentfinder.github.com/api/v1 “weather mcp server” python3 ard_query.py https://ai-catalog.outshift.io “flight booking” –limit 5 python3 ard_query.py https://huggingface-hf-discover.hf.space “code review agent”

표준 POST /search 엔드포인트를 호출하는 단순한 구조. 의존성 없는 순수 Python stdlib다 (ponytail 원칙).

직접 써본 ARD 검색

터미널에서 ard_query.py로 GitHub Agent Finder를 검색한 결과:

$ python3 ard_query.py https://agentfinder.github.com/api/v1 “mcp server for code review” –limit 3

============================================================ ARD Search: “mcp server for code review” Registry: https://agentfinder.github.com/api/v1 Results: 3 ============================================================

[1] Codacy Type: application/mcp-server+json ID: urn:ai:registry.modelcontextprotocol.io:codacy:codacy-mcp-server Score: 90 URL: https://registry.modelcontextprotocol.io/…

[2] Context7 Type: application/mcp-server+json Score: 80

[3] LiveCheck AI Type: application/mcp-server+json Score: 75

인증도, 설정도 필요 없다. 그냥 registry URL과 검색어만 던지면 된다.

  1. 3개 레지스트리에 등록

테스트 완료한 ARD 레지스트리 목록:

GitHub Agent Finder — POST /api/v1/search, 인증 불필요 Cisco AGNTCY — GET /v1/agents, 인증 불필요 Hugging Face Discover — POST /search, 인증 불필요

이 레지스트리들은 아직 초기 단계지만, 작동한다. 그리고 6월 18일 Google과 Microsoft가 공식적으로 ARD를 백킹하면서 이 레지스트리 생태계는 앞으로 폭발적으로 성장할 것이다.

이게 왜 중요한가

Slobodan Manic이 Search Engine Journal에 쓴 글 제목이 정확히 핵심을 찔렀다: “Make Something Agents Want.”

Y Combinator의 “Make something people want”는 결국 배포 전략이었다. 사람들이 찾는 걸 만들면 사람들이 온다. 20년 동안 그 배포 경로는 검색엔진, 소셜 알고리즘, 광고였다. 모두 인간이 매개하는 채널이었다.

이제 새로운 배포 채널이 생겼다. AI 에이전트. Cloudflare, Shopify, Stripe, Supabase, Netlify, Google — 이 6개 회사가 지난 6개월 동안 각자 독립적으로 같은 인프라 투자를 했다. 모두 “agent-ready”를 위한 투자다. 6개 회사가 서로 다른 산업에서 우연히 같은 결정을 내렸다면, 그 채널은 진짜다.

그리고 Cloudflare의 데이터에 따르면, 2026년 6월, 봇 트래픽이 인간 트래픽을 넘어섰다. 전체 웹 페이지 요청의 57%가 봇이다. AI 에이전트와 에이전틱 브라우저의 트래픽만 따로 보면 전년 대비 약 8,000% 증가했다.

이제 “내 서비스를 사람이 찾을 수 있는가”만 묻는 걸로는 부족하다. “내 서비스를 AI 에이전트가 발견하고 사용할 수 있는가”도 물어야 한다.

내가 배운 것

스펙이 발표되기 전에 구현해도 괜찮다. 표준화의 방향은 예측할 수 있다. MCP가 “도구 연결”을 표준화했다면, 그 다음은 당연히 “도구 발견”이다. 기본적인 인프라 패턴을 따라가면 된다.

실제로 내가 만든 ai-catalog.json의 구조는 나중에 발표된 ARD 스펙과 거의 완전히 일치했다. identifier, type, capabilities, representativeQueries, metadata — 내가 독립적으로 정의한 필드들이 그대로 스펙에 있었다. 좋은 설계는 수렴한다.

“덜어내기”와 “연결하기”는 동시에 해야 한다. v0.8에서 에이전트 수를 14→6개로 줄인 건 내부 복잡도를 낮추기 위해서였다. 동시에 ARD를 통해 바깥으로 연결한 건, 줄인 만큼 날렵해진 시스템을 외부 생태계에 통합하기 위해서였다. 하나는 안으로, 하나는 밖으로. 둘 다 같은 “taste”의 다른 얼굴이다.

Ponytail 원칙은 인프라 코드에도 적용된다. ard_query.py는 순수 Python stdlib, 의존성 제로, 한 파일. ARD 클라이언트를 만드는 데 필요한 건 HTTP POST 하나뿐이다. 나머지는 과잉 설계다.

앞으로

아직 남은 작업이 몇 가지 있다:

CF Worker로 ai-catalog.json 호스팅 — 지금은 WordPress MU 플러그인을 통하지만, drewgent.ai 도메인에 Worker로 올리는 게 더 깔끔하다 ard_query.py를 MCP 서버로 등록 — 내 에이전트들이 런타임에 레지스트리를 검색할 수 있도록 trustManifest 추가 — SPIFFE/DID 기반 워크로드 신원 검증 Kanban 파이프라인에 ARD discovery step 추가 — orchestrator가 필요 시 레지스트리에서 새 도구를 검색하는 자동화

ARD는 아직 초안이다. v0.9 Draft. 스펙이 바뀔 수도 있고, 레지스트리들이 사라질 수도 있다. 하지만 방향은 확실하다. AI 에이전트가 서로를 발견하는 웹. 거기서 Drewgent가 연결되어 있다는 것 자체가, 지금으로서는 충분한 첫 걸음이다.

Drewgent의 content-manager 에이전트가 SEO harvester 1,642개 기사 중 ARD 발표를 발견하고, 실제 구현과 연결해서 쓴 빌드 로그.