본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 18. 20:15

에이전틱 리소스 디스커버리(Agentic Resource Discovery)가 AI 에이전트의 누락된 계층인 이유

요약

Hugging Face가 제안한 Agentic Resource Discovery(ARD)는 에이전트가 필요한 도구와 역량을 런타임에 동적으로 검색할 수 있게 하는 새로운 계층입니다. 기존의 정적 구성 방식에서 벗어나, 에이전트가 적절한 도구를 스스로 찾아 활용할 수 있는 디스커버리 메커니즘을 제공합니다.

핵심 포인트

  • 정적 도구 연결 방식의 유지보수 한계를 극복하는 동적 검색 계층 제안
  • MCP 등 실행 프로토콜 이전에 적절한 역량을 찾는 디스커버리 역할 수행
  • 정적 매니페스트를 통한 메타데이터 인덱싱 및 동적 검색 API 지원
  • 컨텍스트 윈도우 비용 절감 및 에이전트 확장성 개선

AI 에이전트들은 많은 개별 작업에서 점점 더 나아지고 있지만, 여전히 익숙한 시스템 문제에 직면해 있습니다. 바로 적절한 시점에 적절한 역량(capability)을 선택하는 문제입니다. 모델은 추론(reasoning)에 강할 수 있고, 별도의 도구는 검색에 강할 수 있으며, 또 다른 도구는 GUI 제어에 강할 수 있지만, 에이전트가 무엇을 사용할 수 있는지, 옵션의 순위를 어떻게 매겨야 하는지, 또는 현재 작업을 위해 어떤 아티팩트(artifact)를 로드해야 하는지 모른다면 이 중 어느 것도 도움이 되지 않습니다. 이것이 Hugging Face의 Agentic Resource Discovery에 관한 기사가 해결하고자 하는 문제입니다.

진짜 병목 현상은 생성이 아닙니다

오늘날의 기본 에이전트 패턴은 여전히 '선 설치, 후 사용' 방식입니다. 개발자는 도구, 기술(skill), 또는 다른 에이전트를 미리 연결해 두고, 생태계가 변화하더라도 동일한 구성이 계속 작동하기를 바랍니다. 이러한 접근 방식은 에이전트가 많은 도메인에 걸쳐 작동해야 하는 순간 빠르게 무너집니다. 엄선된 소수의 도구를 넘어선 순간, 정적 구성(static configuration)은 유지보수의 부담이 됩니다.

ARD 제안은 선택 단계 자체를 바꿉니다. 모든 통합 사항을 에이전트에 하드코딩하는 대신, 역량(capabilities)을 레지스트리(registry)에 게시하고 런타임(runtime)에 검색합니다. 즉, 에이전트가 모든 도구를 사전에 알 필요가 없습니다. 에이전트에게는 훌륭한 디스커버리 계층(discovery layer)이 필요할 뿐입니다.

MCP만으로는 부족한 ARD의 추가 요소

ARD의 중요한 아이디어는 실행 프로토콜(execution protocols)을 대체하는 것이 아니라 그 앞에 위치한다는 점입니다. MCP는 에이전트가 도구를 호출하는 방식을 설명합니다. 기술(Skills)은 에이전트가 지침을 소비하는 방식을 설명합니다. A2A는 에이전트가 다른 에이전트에게 도달하는 방식을 설명합니다. ARD는 이러한 프로토콜 중 어느 것이 사용되기 전에 에이전트가 적절한 것을 찾을 수 있도록 돕는 계층입니다.

사양(spec)은 두 가지 핵심 요소를 정의합니다:

1. 정적 매니페스트 (Static manifests)

발행자(Publishers)는 well-known URL에 ai-catalog.json 매니페스트(manifest)를 노출할 수 있습니다. 이를 통해 레지스트리(registry)는 모든 클라이언트에 대해 개별적인 커스텀 통합(custom integration)을 요구하지 않고도 해당 기능을 인덱싱(indexing)할 수 있는 충분한 메타데이터(metadata)를 확보하게 됩니다. 매니페스트에는 신원(identity), 태그(tags), 대표 쿼리(representative queries), 그리고 컴플라이언스(compliance) 관련 신호들이 포함될 수 있습니다. 이는 검색 품질이 단순히 이름이나 짧은 설명 그 이상에 달려 있기 때문에 매우 중요합니다.

2. 동적 검색 (Dynamic search)

ARD는 또한 POST /search API를 정의합니다. 클라이언트가 자연어로 의도(intent)를 제출하면, 레지스트리는 순위가 매겨진 기능(capabilities)들을 반환합니다. 이는 선택(selection)의 문제를 모델의 컨텍스트 윈도우(context window)에서 명시적인 검색 서비스(search service)로 전환합니다. 에이전트에게 이는 실질적인 개선 사항입니다. 검색은 모든 도구 설명을 프롬프트(prompt)에 밀어 넣는 것보다 비용이 저렴하며, 하드코딩된 허용 목록(allowlist)을 업데이트하는 것보다 훨씬 쉽기 때문입니다.

Hugging Face의 Discover tool은 이 아이디어를 구체적으로 구현한 사례입니다. 이 도구는 Hub의 검색 인프라(search infrastructure)를 래핑(wrap)하여, 클라이언트의 요청에 따라 결과를 스킬(skills), MCP 서버, 또는 가공되지 않은 Space 메타데이터(raw Space metadata) 형태로 노출합니다.

이것이 컴퓨터 사용 에이전트(computer-use agents)에게 더 중요한 이유

만약 에이전트가 API만 호출한다면, 디스커버리(discovery)는 유용하긴 하겠지만 그 영향은 미미할 것입니다. 하지만 에이전트가 그래픽 소프트웨어(graphical software)를 조작해야 하는 상황이 되면 문제는 더욱 심각해집니다. GUI 에이전트는 도구뿐만 아니라, 적절한 스킬 팩(skill pack), 적절한 스크린샷(screenshot), 또는 특정 작업에 특화된 플레이북(playbook)까지 선택해야 하는 경우가 많기 때문입니다.

이것이 바로 arXiv 논문인 VISUALSKILL: Multimodal Skills for Computer-Use Agents가 ARD의 유용한 동반자가 되는 이유입니다. 이 논문은 GUI 작업이 시각적임에도 불구하고 기존의 스킬 라이브러리(skill libraries)가 텍스트 전용(text-only)인 경우가 많다고 주장합니다. 논문의 결과는 주목할 만합니다. Claude Opus 4.6을 기반으로 하는 Claude Code CLI 에이전트는 VISUALSKILL을 사용할 때 평균 0.456점을 기록했는데, 이는 스킬이 없는 베이스라인(baseline)보다 15.3점 높고, 동일한 조건의 텍스트 전용 스킬보다 8.3점 높은 수치입니다.

여기서 얻을 수 있는 교훈은 단순히 멀티모달 (multimodal) 스킬이 도움이 된다는 것만이 아닙니다. 에이전트 생태계가 이질적 (heterogeneous)으로 변하고 있다는 점입니다. 어떤 기능은 API이고, 어떤 기능은 UI 워크플로우 (UI workflows)이며, 어떤 기능은 로봇 정책 (robot policies)이고, 또 어떤 기능은 재사용 가능한 태스크 번들 (task bundles)입니다. 이러한 기능들이 존재하게 되면, 다음 질문은 에이전트가 어떻게 적절한 기능을 빠르고 신뢰성 있게 발견(discovery)하느냐 하는 것입니다.

생태계는 이미 그 방향으로 움직이고 있습니다

최근의 프로젝트들은 서로 다른 각도에서 동일한 점을 시사합니다. From the Hugging Face Hub to Robot Hardware with Strands Agents and LeRobot에 관한 Hugging Face의 포스트는 시뮬레이션, Hub 데이터셋, 정책 추론 (policy inference), 그리고 물리적 로봇 배포 (physical robot deployment)를 아우르는 에이전트 루프 (agent loop)를 보여줍니다. 중요한 세부 사항은 단순히 이 스택이 작동한다는 것뿐만 아니라, 서로 다른 라이프사이클 (lifecycle)과 형식을 가진 여러 리소스를 결합하고 있다는 점입니다.

더 실무적인 측면에서, Launch HN: Adam (YC W25) – Open-Source AI CAD에 대한 Hacker News 스레드와 Running local models is good now를 둘러싼 논의 모두 동일한 트렌드를 가리킵니다. 바로 사용 가능한 로컬 및 오픈 소스 (open-source) 기능의 수가 증가하고 있다는 것입니다. 생태계가 이토록 빠르게 성장할 때, 각 도구에 대한 수동 설정은 더 이상 지속 가능하지 않습니다.

ARD는 이러한 성장에 대한 대응입니다. ARD는 발견 (discovery)을 부가 기능이 아닌 인프라 (infrastructure)로 취급합니다.

빌더들이 여기서 얻어야 할 점

만약 당신이 에이전트 제품을 만들고 있다면, 교훈은 명확합니다.

첫째, 정적인 도구 목록이 오래 유지될 것이라고 가정하지 마십시오. 새로운 도구가 나타날 것이고, 기존 도구는 형태가 변할 것이며, 사용자는 에이전트가 이에 적응하기를 기대할 것입니다.

둘째, 짧은 도구 이름보다 더 풍부한 메타데이터 (metadata)를 게시하십시오. 대표적인 쿼리 (queries), 태스크 유형 (task types), 그리고 기능 태그 (capability tags)는 랭킹 (ranking)을 개선합니다. 멀티모달 (multimodal) 또는 GUI 중심 시스템의 경우, 클라이언트가 로드하려는 아티팩트 (artifact)가 어떤 종류인지 이해할 수 있도록 충분한 구조를 포함해야 합니다.

셋째, 디스커버리 (discovery)와 실행 (execution)을 분리해야 합니다. 검색 (Search)은 에이전트에게 무엇이 존재하는지를 알려주어야 합니다. 실행 프로토콜 (execution protocol)은 그것을 어떻게 사용할지를 처리해야 합니다. 이러한 분리는 시스템을 연합 (federate)하기 더 쉽게 만들고, 유지보수를 더 안전하게 하며, 여러 벤더 (vendors)에 걸쳐 확장하기 더 용이하게 만듭니다.

ARD는 아직 초안 단계이지만, 실제적인 아키텍처의 변화를 가리키고 있습니다. 에이전트가 API, GUI, 로컬 모델 (local models), 로봇 스택 (robot stacks), 그리고 공유된 기술 (shared skills) 전반에 걸쳐 작업할 수 있게 됨에 따라, 주요 과제는 더 이상 모델의 품질만이 아닙니다. 그것은 바로 역량 라우팅 (capability routing)입니다. 최고의 성능을 내는 에이전트는 단순히 추론 (reasoning)을 더 잘하는 것이 아니라, 적절한 리소스를 더 빠르게 찾아낼 것입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0