Spring AI 2.0·Mastra — AI 에이전트 '도구 다이어트'로 토큰 줄이기

Spring AI 2.0·Mastra — AI 에이전트 '도구 다이어트'로 토큰 줄이기

Spring AI 2.0·Mastra — AI 에이전트 '도구 다이어트'로 토큰 줄이기

AI 에이전트에게 유용한 기능을 더해주려고 이것저것 도구를 쥐여주다 보면, 갑자기 에이전트가 멍청해지거나 속도가 답답할 정도로 느려지는 경험을 하게 됩니다. 수십 개의 API 명세서가 프롬프트를 가득 채우면서 정작 에이전트가 생각할 공간이 부족해지기 때문입니다. 최근 AI 프레임워크와 연구 진영이 이 문제를 해결하기 위해 집중하고 있는 '도구 다이어트', 즉 다이내믹 툴 프루닝 기술에 대해 이야기해 보려 합니다.

이름은 보는데 왜 못 쓸까: '보는 것'과 '고르는 것'의 차이

맛집에 갔는데 메뉴판만 수십 페이지에 달한다고 상상해 보세요. 첫 장부터 끝 장까지 메뉴를 꼼꼼히 다 읽었더라도, 막상 주문할 때가 되면 결정 장애가 찾아와 엉뚱한 음식을 고르거나 선택을 포기하기 쉽습니다. AI 에이전트에게 너무 많은 도구를 쥐여주었을 때 발생하는 문제도 이와 아주 비슷합니다.

그동안 우리는 에이전트가 도구를 잘 쓰지 못하면, 긴 프롬프트 중간에 있는 정보를 놓치는 '잃어버린 중간' 현상 때문이라고 지레짐작하곤 했습니다. 하지만 2026년 6월에 발표된 연구 논문 'Looking Is Not Picking'은 아주 흥미로운 반전을 보여줍니다. 실험 결과 거대언어모델은 정답 도구의 명세서를 실제로 약 80%라는 높은 확률로 똑바로 주시하고 있었습니다.

결국 진짜 문제는 정보를 읽지 못하는 것이 아니라, 최종 의사결정을 내리는 단계에서 너무 많은 후보군 때문에 무엇을 고를지 갈팡질팡하는 데 있었습니다. 입력 단계에서 프롬프트 순서를 바꾸는 임시방편보다, 애초에 지금 쓰지 않을 불필요한 도구를 메뉴판에서 치워버리는 '도구 다이어트'가 훨씬 강력한 효과를 발휘하는 이유입니다.

필요할 때만 검색해서 꺼내 쓴다: Spring AI와 RAG-MCP

수십 개의 API 명세를 처음부터 프롬프트에 무작정 구겨 넣는 대신, 최근 트렌드는 '입력 단계 필터링'으로 빠르게 넘어가고 있습니다. 에이전트에게 처음부터 무기를 다 쥐여주지 않고, 필요할 때 스스로 무기고에서 검색해서 꺼내 쓰게 만드는 것이죠.

이 방식을 가장 완성도 있게 구현한 사례가 바로 스프링 AI(Spring AI) 2.0의 '도구 검색 어드바이저(ToolSearchToolCallingAdvisor)'입니다. 에이전트에게 수십 개의 도구를 통째로 넘기는 대신, 도구를 검색할 수 있는 단 하나의 메타 도구만 쥐여줍니다. 에이전트가 작업하다가 특정 기능이 필요해지면 이 검색 도구를 호출하고, 시스템은 내부 벡터 인덱스에서 가장 알맞은 도구 명세를 동적으로 꺼내 프롬프트에 추가합니다.

효과는 정말 확실합니다. 스프링 AI 공식 벤치마크에 따르면, 이 방식을 적용했을 때 토큰 사용량을 최소 34%에서 최대 64%까지 줄일 수 있었습니다. 에이전트가 쓸데없는 도구 명세에 한눈팔지 않으니 추론 정확도와 처리 속도가 동시에 올라갑니다.

이러한 프레임워크의 진화는 학계의 연구 흐름과도 일치합니다. 실제로 'RAG-MCP' 연구진이 모델 컨텍스트 프로토콜(MCP) 환경에서 필요한 도구만 검색해 주입해 보았더니, 프롬프트 토큰이 50% 이상 절감되었습니다. 놀랍게도 올바른 도구를 정확히 골라내는 확률은 기존 약 13%에서 43%로 3배 이상 뛰어올랐습니다.

실행 로그 다이어트: 마스트라와 랭그래프의 콘텍스트 정리법

앞서 살펴본 스프링 AI의 방식이 애초에 에이전트에게 보여줄 메뉴판 자체를 줄이는 '입력 단계 필터링'이라면, 도구를 실행한 이후에 발생하는 토큰 낭비를 막는 '실행 단계 필터링'도 매우 중요합니다.

에이전트가 데이터베이스를 조회하거나 외부 API를 호출하면 수백, 수천 줄에 달하는 원본 데이터가 대화 기록에 고스란히 쌓이게 됩니다. 이 무겁고 지저분한 로그들이 콘텍스트에 계속 남아있으면 에이전트는 금방 멍청해지거나 속도가 느려집니다.

오픈소스 프레임워크인 마스트라(Mastra)는 이 문제를 '도구 호출 필터(ToolCallFilter)'라는 기능으로 깔끔하게 해결합니다. 도구 실행이 끝난 뒤, 다음 대화를 이어갈 때 불필요하게 길고 복잡한 원본 인자나 가비지 데이터를 대화 기록에서 즉시 정리하는 기술입니다.

다음 예시처럼 아주 간단한 설정만으로 에이전트의 콘텍스트를 항상 깨끗하게 유지할 수 있습니다.

typescript
import { Agent } from '@mastra/core/agent';
import { ToolCallFilter } from '@mastra/core/processors';

const agent = new Agent({
  id: 'lightweight-agent',
  name: 'Slim Agent',
  model: 'openai/gpt-4o',
  inputProcessors: [
    new ToolCallFilter({
      filterAfterToolSteps: 2, // 최근 2단계의 도구 실행 내역만 유지합니다.
      preserveModelOutput: true, // 원본 로우 데이터 대신 핵심 요약 정보만 남깁니다.
    })
  ]
});

이렇게 하면 에이전트는 직전에 자신이 무엇을 했는지 기억하면서도, 머릿속을 가볍게 비운 덕분에 다음 행동을 훨씬 빠르고 정확하게 결정할 수 있습니다.

한편, 랭그래프(LangGraph)는 워크플로의 각 단계(노드)마다 필요한 도구만 동적으로 연결하는 방식을 제안합니다. 에이전트가 전체 대화 흐름 중 지금 딱 처리해야 하는 일에만 집중할 수 있도록, 특정 순간에만 최소한의 도구 세트를 쥐여주는 구조입니다. 입력을 가볍게 하고 실행 기록을 청소하는 이러한 실전 패턴들은 이제 대규모 AI 서비스를 안정적으로 운영하기 위한 필수 공식이 되고 있습니다.

똑똑한 에이전트는 무기를 가볍게 쥔다

강력한 AI 에이전트를 만든다는 것은 이제 단순히 수백 개의 도구를 빽빽하게 연결하는 작업이 아닙니다. 에이전트가 복잡한 추론을 이어갈 수 있도록 머리 공간인 콘텍스트를 얼마나 가볍고 쾌적하게 유지해 주느냐가 실제 에이전트의 성능을 결정합니다.

앞으로 대규모 에이전트 시스템을 설계할 계획이 있다면, 실행 시점에 도구를 동적으로 골라내고 대화 기록을 정리하는 다이어트 패턴을 설계도에 꼭 추가해 보세요. 무기를 가볍게 쥔 에이전트가 결국 더 예리하고 똑똑하게 움직이는 법이니까요.