발표에서 확인된 핵심 사실

7개 커머스 회귀 사례에서 목표 도구만 검색했을 때 14.3%였던 필수 선행 도구 포함률이 그래프 확장 후 100%로 상승했다. Plateer Labs(플래티어 랩스)가 개발한 graph-tool-call(그래프 툴 콜, 요청마다 관련 도구만 검색해 LLM에 전달하는 Python 오픈소스 라이브러리)을 적용한 결과다.

이 라이브러리는 전체 도구 카탈로그를 모델 외부에 분리해 관리한다. 요청마다 관계 그래프를 통해 필요한 최소한의 스키마(Schema, 데이터 구조 정의)만 LLM에 전달한다. 에이전트에 연결된 도구가 많아질수록 정확도가 떨어지는 문제를 해결하기 위한 구조다.

기존에는 도구 수가 늘어나면 스키마가 컨텍스트를 과도하게 차지해 엉뚱한 도구를 선택하는 문제가 발생했다. 이름과 설명이 비슷한 도구 사이에서 선택이 어려워지거나, 실행에 필요한 선행 도구 호출 순서를 놓치는 경우가 생긴다. 도구의 양적 확장이 오히려 에이전트의 성능 저하를 유발하는 제약이 있었다.

해당 수치는 소규모 고정 데이터셋의 회귀 검사 결과이며 일반적인 모델 성능을 보장하는 벤치마크는 아니다. 관계 그래프를 통한 도구 검색이 필수 선행 도구의 탐색률을 높이는 기제로 작동함을 확인했다.

기술이 실제로 작동하는 방식

LLM에 전달되는 정보는 전체 도구 목록이 아니라 검색을 통해 선별된 필수 스키마로 제한된다. graph-tool-call(도구 간 관계를 그래프로 정의해 탐색하는 체계)은 OpenAI(REST API 표준 규격), MCP(Model Context Protocol, 모델 컨텍스트 프로토콜), Python 함수를 수집해 도구 카탈로그와 관계 그래프를 생성한다. BM25(단어 빈도 기반 검색 알고리즘)나 임베딩을 활용해 사용자 요청에 부합하는 목표 도구를 검색하고, 해당 도구의 필수 입력값을 생성하기 위한 선행 도구를 추적해 탐색한다. 최종적으로는 탐색 결과에서 도출된 필요한 스키마만 LLM에 전달하여 입력 토큰 낭비를 줄인다.

연결 환경에 따라 MCP 서버 프록시나 OpenAI/Swagger(API 설계 및 문서화 도구) 카탈로그, LangChain(LLM 애플리케이션 프레임워크) 및 LangGraph(상태 기반 멀티 에이전트 워크플로우 도구) 게이트웨이를 선택해 시스템에 연결한다. 여러 MCP 서버를 하나의 검색 가능한 프록시로 묶어 관리하거나, OpenAI/Swagger에서 도구 카탈로그를 직접 생성하는 방식이 가능하다. OpenAI나 Anthropic 요청 직전에 도구 목록을 필터링하거나 Python 함수 목록에서 요청별로 필요한 도구만 선택하는 용도로 배치한다. 이러한 연결 구조를 통해 LLM이 처리해야 할 도구의 범위를 요청 단위로 정밀하게 제한한다.

v0.36.0의 커머스 회귀 사례 테스트 결과, 필수 선행

필수 선행 도구 포함률이 14.3%에서 100%로 상승했다. v0.36.0의 모델 없는 7개 커머스 회귀 사례 테스트 결과다. 실행 가능한 후보 구성 비율 역시 47.6%에서 100%로 증가했다. 예상 스키마 크기는 1,476토큰에서 160토큰으로 감소했다.

단순 임베딩 검색은 의미적으로 유사한 도구를 찾는 방식이다. refundOrder처럼 설명이 비슷한 도구는 찾지만, 실행에 필요한 값을 생성하는 findOrdersByEmail 같은 선행 도구까지 찾기에는 한계가 있다. graph-tool-call(그래프 기반 도구 호출)은 의미적 유사성과 실행 관계 추론을 동시에 수행한다.

도구 수가 수십 개 이상인 환경에서 토큰 비용 절감과 호출 정확도 향상을 위해서는 관계 추론 기반의 탐색 체계 도입 여부를 판단해야 한다. `uvx --from graph-tool-call==0.36.0 graph-tool-call demo dependency-chain` 명령어로 동작 검증이 가능하다.