AI 에이전트 도구 과부하 문제와 시맨틱 라우팅 해결법

핵심 메시지

• AI 에이전트에 필요할 법한 모든 도구 명세를 매 요청마다 통째로 넣는 '뚱뚱한 에이전트(fat agent)' 방식은 도구가 늘어날수록 느려지고 비싸지며 부정확해진다.
• 벤치마크에서 도구 정확도는 도구 10개일 때 약 78%였지만 100개에서 약 40%, 741개에서는 13.6%까지 추락한 반면, 시맨틱 라우터는 같은 조건에서 83% 이상을 유지했다.
• 해법은 '도구를 위한 RAG'다. 도구 설명을 임베딩해 벡터 DB에 저장하고, 사용자 질문과 가장 관련 있는 상위 3~5개(K=5 권장)만 골라 모델에 주입한다.
• 이는 새로운 인프라가 아니라 지연 로딩·적시(JIT) 컴파일과 같은 오래된 원리를 LLM 컨텍스트에 적용한 것으로, 앤트로픽은 MCP 온디맨드 도구 로딩으로 토큰을 15만→2천(98.7% 감소)으로 줄였다고 보고했다.

쉽게 이해하기

프로소디카(Prosodica)의 소하이브 셰이크와 안쿠시 라스토기는 데모에서는 멀쩡해 보이지만 운영에서 무너지는 흔한 실수를 지적한다. 바로 에이전트에 쓸 수 있는 모든 도구를 한꺼번에 쥐여주는 설계다. 도구가 10개일 때는 잘 동작하지만, 카탈로그가 커지면 모델이 엉뚱한 함수를 부르고 비슷한 도구를 혼동하며 응답도 느려진다.

문제의 핵심은 특정 도구가 잘못 작성돼서가 아니라, 매 요청이 전체 카탈로그를 떠안도록 강제된다는 데 있다. 도구가 741개면 사용자의 질문을 보기도 전에 도구 설명과 스키마만으로 약 12만 7천 토큰이 소모된다. 게다가 긴 컨텍스트의 중간에 묻힌 정보는 모델이 잘 활용하지 못하는 '중간 소실(lost in the middle)' 현상까지 겹친다.

성능 저하는 정확도뿐 아니라 지연과 비용에서도 나타난다. 도구가 500개면 첫 토큰까지 걸리는 시간이 5초를 넘길 수 있어 실시간 서비스에 치명적이고, 하루 10만 건 요청이면 도구를 설명하는 데만 수십억 토큰이 새어 나간다.

대안인 시맨틱 라우팅은 RAG와 똑같은 구조다. 오프라인에서 각 도구의 설명을 임베딩해 벡터 DB(크로마·파인콘·콰드런트 등)에 저장해 두고, 런타임에 사용자 질문을 같은 임베딩 모델로 변환해 가장 가까운 상위 K개 도구만 검색한다. 그 3~5개의 스키마만 모델에 주입하므로 컨텍스트가 작게 유지되고 정확도가 보존된다.

발표자들은 도구가 20개 미만이면 라우터가 불필요하고 그냥 직접 로딩해도 되지만, 50개를 넘으면 라우터 기반 방식이 정당화된다고 선을 긋는다. 또한 라우터 미스(폴백·K 확대로 대응), 빈약한 도구 설명(임베딩 품질 저하), 희귀 도구(설명 재작성 필요) 같은 트레이드오프를 함께 관리해야 한다고 강조한다.

주요 인사이트

• 카탈로그는 커져도 모델의 '작업 집합(working set)'은 작게 유지해야 한다 — 이것이 벤치마크가 주는 핵심 교훈이다.
• 도구 과부하 문제는 프롬프트가 나빠서가 아니라 아키텍처가 모델에게 '엉뚱한 문제'를 풀라고 시키기 때문에 생긴다. 도구 몇 개만으로도 혼동이 시작될 수 있다.
• 시맨틱 라우팅은 새 기술 스택이 아니다. 이미 임베딩 모델과 벡터 DB가 있다면 RAG 검색 패턴을 도구 선택에 그대로 재사용하는 것이다.
• 라우터는 올바른 도구를 '추가'할 뿐 아니라 무관한 도구를 모델의 선택지에서 '제거'한다 — 이 제거 효과가 정확도 유지의 숨은 비결이다.
• K=5를 기본값으로 시작하고 모든 선택을 로깅한 뒤 실제 테스트셋으로 평가해, 목표 정확도를 만족하는 가장 작은 K를 고르는 것이 실용적 출발점이다.

자주 묻는 질문

관련 AI 소식