🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Agentic Resource Discovery(ARD)는 에이전트가 도구·스킬·다른 에이전트를 미리 설치하지 않고도 실행 시점에 검색해 발견하도록 하는 공개 표준이며, Hugging Face는 이를 Discover Tool로 구현했습니다.

📌 핵심 요약

• 현재 에이전트 생태계의 MCP, Skills, A2A는 각각 도구 호출, 지침 소비, 다른 에이전트 호출을 표준화하지만, 어떤 도구나 지침, 에이전트가 필요한지는 여전히 사용자가 미리 알고 연결해야 한다는 한계가 있습니다.
• ARD는 이 문제를 해결하기 위해 도구와 에이전트 능력을 카탈로그화하고, 인덱싱하고, 연합된 레지스트리에서 검색할 수 있게 하는 발견 계층을 제안합니다.
• 사양은 정적 매니페스트인 ai-catalog.json과 동적 검색 API인 POST /search를 정의하며, 자연어 의도 기반 검색을 통해 에이전트가 런타임에 적절한 capability를 찾도록 합니다.
• Hugging Face Discover Tool은 ARD의 참조 구현으로, Hugging Face Hub의 Spaces, Agent Skills, MCP 서버 정보를 ARD 카탈로그 엔트리로 변환해 CLI, REST API, MCP 엔드포인트로 제공합니다.
• 글은 ARD가 실행 프로토콜을 새로 만들기보다 발견과 실행을 분리하고, 기존 artifact 형식을 media type 기반 envelope로 감싸며, 향후 federation과 well-known URI 기반 게시를 확장하려는 방향을 설명합니다.

🧩 주요 포인트

1. 현재 에이전트 생태계의 MCP, Skills, A2A는 각각 도구 호출, 지침 소비, 다른 에이전트 호출을 표준화하지만, 어떤 도구나 지침, 에이전트가 필요한지는 여전히 사용자가 미리 알고 연결해야 한다는 한계가 있습니다.
2. ARD는 이 문제를 해결하기 위해 도구와 에이전트 능력을 카탈로그화하고, 인덱싱하고, 연합된 레지스트리에서 검색할 수 있게 하는 발견 계층을 제안합니다.
3. 사양은 정적 매니페스트인 ai-catalog.json과 동적 검색 API인 POST /search를 정의하며, 자연어 의도 기반 검색을 통해 에이전트가 런타임에 적절한 capability를 찾도록 합니다.
4. Hugging Face Discover Tool은 ARD의 참조 구현으로, Hugging Face Hub의 Spaces, Agent Skills, MCP 서버 정보를 ARD 카탈로그 엔트리로 변환해 CLI, REST API, MCP 엔드포인트로 제공합니다.
5. 글은 ARD가 실행 프로토콜을 새로 만들기보다 발견과 실행을 분리하고, 기존 artifact 형식을 media type 기반 envelope로 감싸며, 향후 federation과 well-known URI 기반 게시를 확장하려는 방향을 설명합니다.

🧠 상세 정리

1. 기존 에이전트 프로토콜의 공통 한계

글은 오늘날 에이전트를 만드는 사람이 흔히 MCP, Skills, A2A라는 세 가지 프로토콜을 알고 있다는 지점에서 출발합니다. MCP는 에이전트가 도구를 호출하는 표준 방식을 제공하고, Skills는 에이전트가 지침을 소비하는 방식을 제공하며, A2A는 에이전트가 다른 에이전트를 호출하는 방식을 제공합니다. 하지만 세 프로토콜은 모두 사용자가 이미 어떤 도구, 지침, 에이전트가 필요한지 알고 있다고 가정합니다. 즉 호출과 사용 방식은 표준화되어도, 필요한 capability를 발견하고 통합하고 유지하는 책임은 여전히 사용자나 개발자에게 남아 있습니다.

2. ARD가 제안하는 발견 계층

Agentic Resource Discovery, 즉 ARD는 MCP, Skills, A2A 앞단에 놓이는 discovery layer로 소개됩니다. 이 사양은 에이전트와 도구가 연합된 레지스트리 안에서 어떻게 카탈로그화되고, 인덱싱되고, 검색될 수 있는지를 정의합니다. 핵심은 에이전트가 필요한 capability를 미리 설치된 목록에서 고르는 것이 아니라, 런타임에 검색해 찾을 수 있게 하는 것입니다. 글은 ARD가 제품이나 marketplace가 아니라, 어떤 회사든 독립적으로 구현할 수 있고 어떤 에이전트나 도구도 참여할 수 있는 공유 표준이라고 분명히 설명합니다.

3. install-first 모델의 확장성 문제

현재의 에이전트 capability 모델은 먼저 설치하고 나중에 사용하는 방식에 가깝습니다. 개발자는 MCP 서버 URL을 설정 파일에 하드코딩하고, 사용자는 AI 앱에 서비스를 플러그인으로 연결한 뒤 반복해서 사용합니다. 이런 방식은 매일 쓰는 소수의 도구에는 잘 맞지만, 수천 개의 임시적이고 상황별인 표면으로 확장되기는 어렵습니다. 대안으로 모든 도구 설명을 LLM의 컨텍스트 창에 넣고 모델이 고르게 할 수도 있지만, 이는 컨텍스트 예산에 제한을 받고 설명이 너무 얇으면 검색 기반 전략 역시 충분히 구별력을 갖기 어렵습니다.

4. LLM 내부 선택에서 외부 검색으로의 전환

ARD의 중요한 변화는 capability 선택을 LLM 내부 컨텍스트 밖으로 옮기는 데 있습니다. 레지스트리는 publisher identity, representative queries, compliance attestations, tags 같은 더 풍부한 신호를 사용해 capability를 인덱싱하고 REST endpoint를 제공합니다. 클라이언트는 자연어로 검색하고, 모델은 검색 결과로 반환된 항목을 호출합니다. 이는 수동 설치와 정적 카탈로그 중심의 방식에서 intent-based search로 이동하는 것이며, 에이전트가 사전 구성 없이도 성장하는 MCP 도구, A2A 에이전트, 기타 서비스 생태계에 접근할 수 있게 합니다.

5. ARD 사양의 두 구성 요소

글은 ARD 사양이 크게 두 가지를 정의한다고 설명합니다. 첫째는 ai-catalog.json이라는 정적 manifest format으로, publisher가 well-known URL에 자신의 capability를 게시할 수 있게 합니다. 둘째는 POST /search에 위치한 동적 registry API로, live ranked discovery를 제공합니다. 이 조합은 단순한 파일 게시와 실시간 검색을 함께 다루며, capability를 웹에서 발견 가능한 형태로 표현하고 검색 결과로 노출하는 기본 구조를 만듭니다.

6. Hugging Face Discover Tool 구현

Hugging Face Discover Tool은 ARD의 reference implementation으로 제시됩니다. 이 도구는 Hugging Face와 다른 ARD discovery service에 있는 수천 개의 Skills, ML applications, MCP Servers에 대한 검색 접근을 제공합니다. 구현은 Hub의 기존 Spaces semantic search와 Agent Skills를 결합하고, 그 결과를 ARD catalog entries로 제공합니다. Hub에는 이미 Gradio apps, MCP servers, demos를 실행하는 Spaces 카탈로그가 있으며, agents=true 플래그를 사용하면 agent-oriented metadata 기준으로 랭킹된 Spaces를 반환하고 Discover가 이를 ARD 사양으로 변환합니다.

7. 필터링과 media type별 변환

Discover adapter는 두 가지 필터와 변환 규칙을 적용합니다. 먼저 응답은 runtime stage가 RUNNING인 Spaces만 포함합니다. 다음으로 응답 media type은 요청에 따라 결정되며, 기본값인 application/ai-skill은 Space의 agents.md를 감싼 생성 SKILL.md를 제공합니다. application/mcp-server+json은 mcp-server 태그가 붙은 Spaces를 MCP server catalog entry로 반환하고, application/vnd.huggingface.space+json은 클라이언트가 직접 처리할 수 있는 raw Space metadata를 제공합니다. Skills의 경우 Discover는 agents.md를 읽어 name, description, source metadata를 포함한 frontmatter로 감싸고, MCP 태그가 붙은 Spaces는 Gradio MCP endpoint를 가리키는 catalog entry로 생성합니다.

8. 사용 방법과 API 접근

사용자는 Hugging Face CLI인 hf에 내장된 discover 명령으로 ARD 검색을 시작할 수 있습니다. 예시는 uv tool install huggingface_hub로 CLI를 설치한 뒤, hf discover search 명령으로 모델 fine-tuning 리소스를 찾거나, --json --kind mcp 옵션으로 이미지 생성 MCP 서버를 찾는 방식을 보여줍니다. 다른 registry를 검색할 때는 --registry-url 옵션을 사용할 수 있습니다. 또한 Hugging Face catalog는 https://huggingface.co/.well-known/ai-catalog.json 에 게시되어 있고, REST API는 https://huggingface-hf-discover.hf.space/search 로 직접 호출할 수 있으며, MCP client는 /mcp endpoint를 통해 catalog search에 연결할 수도 있습니다.

9. 사양 차원에서의 의미와 확장성

글은 ARD가 discovery와 execution을 분리한다는 점을 사양의 핵심 의미로 설명합니다. 정적 manifest format은 media type에 의해 구동되므로, 특정 artifact protocol을 새로 만들지 않아도 같은 envelope 안에서 여러 형식이 함께 사용될 수 있습니다. registry API는 평범한 HTTP REST이기 때문에 다양한 클라이언트가 federation 방식으로 연결될 수 있습니다. Discover Tool은 새 artifact format을 발명하지 않고 Hub라는 기존 검색 backend를 사양의 envelope로 감싸며, 같은 Spaces가 클라이언트 요청에 따라 skill이나 MCP server로 표면화될 수 있음을 보여주는 작동 사례입니다.

10. 검증의 중요성과 다음 단계

본문 말미와 커뮤니티 코멘트는 발견뿐 아니라 검증의 중요성도 함께 강조합니다. 커뮤니티 코멘트는 에이전트가 도구를 호출하거나 데이터를 가져오거나 결정을 내리기 전에, capability를 누가 게시했는지와 변조되지 않았는지를 확인할 수 있어야 한다고 지적합니다. 해당 코멘트는 ai-catalog.json을 well-known path에 게시하고, registry가 이를 crawl하며, 에이전트가 의도로 검색한 뒤 publisher를 검증하고 연결하는 흐름을 설명합니다. 본문에서 제시된 다음 단계는 federation modes인 auto, referrals, none과의 더 긴밀한 통합, 그리고 사용자와 조직 프로필에서 정적 ai-catalog.json manifest를 지원하는 것입니다.

🧾 핵심 주장 / 시사점

• ARD의 핵심 가치는 새로운 실행 방식을 만드는 데보다, 이미 존재하는 MCP, Skills, A2A 같은 실행 경로 앞에 검색 가능한 discovery layer를 두는 데 있습니다.
• 에이전트 생태계가 커질수록 모든 도구 설명을 컨텍스트에 넣는 방식보다, publisher identity와 tags, 대표 query, compliance attestations 같은 외부 인덱싱 신호가 더 중요해집니다.
• 발견이 자동화될수록 검증도 함께 중요해집니다. 에이전트가 런타임에 capability를 찾아 바로 행동하려면, 검색 결과의 출처와 무결성을 확인하는 메커니즘이 신뢰의 핵심이 됩니다.

✅ 액션 아이템

• ARD를 공개 표준으로 도입해 MCP·Skills·A2A에서 사용자 사전지식 의존을 줄이고 런타임 자원발견 흐름을 정비한다.
• ai-catalog.json 정적 매니페스트와 POST /search 동적 검색 API를 연동해 자연어 의도 기반으로 적합한 capability를 런타임 조회·선택하도록 운영 규격을 정한다.
• Hugging Face Discover Tool이 CLI·REST·MCP에서 Hub Spaces·Agent Skills·MCP 서버를 카탈로그 항목으로 노출하는지 확인하고 세 경로 노출 형태의 일관성을 점검한다.

❓ 열린 질문

• 의도 기반 자연어 검색이 정확히 동작하려면 POST /search에서 질의 정규화와 메타데이터 매칭 규칙을 어떻게 잡아야 하는가?
• 발견 계층에서 반환된 카탈로그 항목과 실행 레이어 요구사항이 충돌할 때 우선 적용 기준은 무엇이어야 하는가?
• 미디어 타입 기반 envelope와 federation, well-known URI 게시를 결합했을 때 어느 클라이언트에서 호환성 제약이 가장 먼저 드러나는가?