에이전트가 자기 도구를 못 찾는다 — 런타임 도구 탐색 계층

어떤 문제인가

지금 AI 에이전트가 도구를 얻는 방식은 ‘설치 먼저, 사용은 나중’이다. 개발자가 MCP 서버 URL을 설정 파일에 손으로 박아 넣어야, 에이전트가 그 도구를 쓸 수 있다. 이 방식은 규모가 커지면 무너진다. 에이전트가 작업 도중에 처음 보는 도구를 동적으로 발견할 길이 없기 때문이다. 흔한 우회책 — 모든 도구 설명을 LLM 컨텍스트 창에 쏟아붓기 — 도 한계가 뚜렷하다. 토큰 예산이 막고, 도구가 수십 개만 넘어가도 모델이 어느 걸 골라야 할지 혼동한다. 결국 에이전트의 능력은 개발자가 미리 상상해 박아 둔 도구의 집합에 갇힌다. 사용자가 “이 PDF를 회계 시스템에 넣어 줘”라고 해도, 그 회계 시스템 커넥터가 사전에 설치돼 있지 않으면 에이전트는 존재 자체를 모른다. 사람이라면 검색해서 찾을 일을, 에이전트는 못 한다. 도구 자체는 폭발적으로 늘어나는데 — MCP 서버, AI 스킬, ML 애플리케이션이 수천 개 — 정작 에이전트가 그중 적합한 걸 런타임에 찾아 고르는 계층이 비어 있다.

왜 지금인가

타이밍을 만든 건 표준의 등장이다. 허깅페이스가 마이크로소프트·구글·고대디 등과 함께 ARD(에이전트 자원 탐색) 초안 사양을 공개했다. 모델은 단순하다. 도메인의 잘 알려진 경로에 ai-catalog.json을 올리면, 레지스트리가 색인하고, 에이전트가 자연어 의도로 검색한 뒤, 발행자를 검증하고 MCP·A2A·일반 API로 연결한다. 에이전트를 위한 DNS와 전화번호부인 셈이다. 사양은 정적 매니페스트(ai-catalog.json)와 동적 레지스트리 API(자연어로 POST /search) 두 갈래를 정의한다. 표준이 깔렸다는 건 그 위에서 경쟁할 판이 열렸다는 뜻이다. 도메인 이름 시스템이 표준화되자 DNS 사업자·등록대행이 생긴 것과 같다. 지금은 표준이 막 초안 단계이고, 색인 품질·랭킹·발행자 검증 같은 ‘실제로 쓸 만한 레지스트리’는 아직 비어 있다. 표준 자체는 누가 검색을 잘하느냐를 정하지 않는다. 같은 의도에 어떤 도구를 1순위로 올리느냐 — 그 랭킹 품질이 곧 제품 경쟁력이고, 그 자리는 아직 임자가 없다.

어떻게 만들 수 있나

ARD 사양을 따르는 도구 탐색 레지스트리를 만든다. 핵심은 셋이다. 첫째, 크롤·색인 — 도메인마다 흩어진 ai-catalog.json을 긁어모으고, 도구의 설명·대표 쿼리·태그를 임베딩으로 색인한다. 둘째, 의도 랭킹 — 에이전트가 자연어로 “X를 하고 싶다”고 검색하면, 적합한 도구를 신뢰도순으로 돌려준다. 단순 키워드 매칭이 아니라, 발행자 신원·준수 증명·실제 사용 신호를 가중치로 넣어 정확도를 올린다. 셋째, 검증 게이트 — 아무 도구나 노출하지 말고, 발행자를 검증하고 악성·사칭 도구를 걸러 에이전트가 안전하게 연결하게 한다. 수익은 도구 발행자 쪽(노출·우선 색인의 B2B 과금)과 에이전트 개발자 쪽(검색 API 호출 과금) 양면으로 건다. 처음부터 모든 도구를 다루려 하지 말고, 한 수직 영역 — 가령 핀테크 커넥터나 데이터 파이프라인 도구 — 의 색인 품질을 압도적으로 끌어올려 거기서 표준 레지스트리로 자리 잡는 게 현실적이다. 허깅페이스의 디스커버 툴 같은 레퍼런스 구현이 이미 있으니, 차별점은 ‘얼마나 더 정확하게, 얼마나 더 안전하게’ 찾아 주느냐다.