본문 바로가기

인공지능

Smart Tool Selection: Spring AI의 Dynamic Tool Discovery로 34~64% 토큰 절감하기

728x90
반응형
728x170

AI 에이전트를 운영하다 보면 Tool 개수가 기하급수적으로 늘어나는 순간이 찾아온다. Slack, GitHub, Jira, MCP 서버까지 연결하면 Tool 수가 50개를 훌쩍 넘어가고, 그때부터 문제는 조용히 시작된다. 모델은 비슷한 이름의 Tool 사이에서 헤매기 시작하고 토큰 비용은 대화가 시작되기도 전에 치솟는다. 이 글에서는 이러한 문제를 해결하기 위해 도입된 Tool Search Tool 패턴과, Spring AI가 이를 어떻게 구현해 토큰을 34~64% 절감했는지 구체적인 구조와 코드 기반으로 정리한다.

반응형

기존 Tool Calling의 구조와 한계

Spring AI의 ToolCallAdvisor는 편리하지만 본질적 한계를 갖는다.
첫 번째 요청에서 등록된 모든 Tool 정의를 모델에게 전달한다는 점이다. Tool이 20개를 넘고, 정의 전체가 5만 토큰 이상을 차지하는 경우라면 대화가 시작되기 전에 이미 비용이 발생한다.

이 방식이 가지는 문제는 크게 세 가지로 나뉜다.

  1. Context Bloat
    모든 Tool 정의가 요청마다 포함되면서 불필요한 토큰이 과하게 사용된다.
  2. Tool Confusion
    비슷한 이름과 목적을 가진 Tool이 많아질수록 모델의 선택 정확도가 떨어진다.
  3. 높은 운영 비용
    매 요청마다 사용하지 않는 Tool 정의에 대해 비용을 지불하게 된다.

여러 MCP 서버를 한 번에 연결하는 환경에서는 이 한계가 더욱 뚜렷하게 나타난다.


Tool Search Tool 패턴이란 무엇인가

Anthropic이 제안한 Tool Search Tool 패턴의 핵심 아이디어는 단순하다.
“모든 Tool 정의를 미리 로딩하지 않는다. 필요할 때만 검색해서 불러온다.”

즉, 처음에는 Tool Search Tool이라는 단 하나의 Tool만 모델에게 제공한다.
모델이 특정 기능이 필요할 때 Tool Search Tool을 호출하여 관련 Tool 목록을 요청하고, 그때 해당 Tool 정의만 LLM 컨텍스트에 확장하는 방식이다.

Spring AI는 이 패턴을 ToolSearchToolCallAdvisor로 구현하여 Anthropic뿐 아니라 OpenAI, Gemini, Azure OpenAI, Ollama 등 Spring AI가 지원하는 모든 모델에서 동일한 방식으로 활용할 수 있게 만들었다.


Spring AI ToolSearchToolCallAdvisor의 동작 방식

동작 흐름은 다음과 같은 7단계로 요약된다.

  1. 모든 Tool 등록
    시스템 시작 시 전체 Tool을 ToolSearcher에 색인한다. 이 시점에는 LLM에게 전달되지 않는다.
  2. 첫 번째 요청
    모델은 Tool Search Tool만 보고 응답한다.
  3. Tool 발견 요청
    모델이 필요한 기능을 추론하면 Tool Search Tool을 호출한다.
    예: “current time”, “get weather”, “clothing shop” 등.
  4. ToolSearcher가 검색
    검색 전략(Lucene, VectorStore 등)을 기반으로 가장 관련성 높은 Tool을 찾아낸다.
  5. 선택된 Tool 정의 확장
    모델의 다음 요청부터는 Tool Search Tool + 검색된 Tool 정의만 컨텍스트에 주입된다.
  6. 모델이 실제 Tool 호출
    모델이 이제 발견된 Tool을 호출하여 결과를 받는다.
  7. 최종 응답 생성
    필요한 Tool 호출이 끝나면 일반 응답으로 이어진다.

이 방식은 전체 Tool 라이브러리가 얼마나 크든, 실제로 필요한 Tool 정의만 전달하기 때문에 토큰 절감 효과가 매우 크다.


검색 전략: Lucene, VectorStore, Regex

Spring AI는 ToolSearcher 인터페이스만 구현하면 다양한 검색 방식을 활용할 수 있다.

  • Keyword 기반 Lucene 검색
    정확한 키워드 기반 검색에 강함
    Tool 이름이 명확할 때 적합
  • VectorStore 기반 Semantic 검색
    자연어 질의에 대한 의미 기반 검색
    모델이 툴 이름을 직접 모르더라도 높은 적중률 제공
  • Regex 기반 검색
    패턴 기반 자동 매칭
    get_* 형태의 규칙적 Tool 명명에 적합

검색 전략은 Tool 수가 많을수록 더욱 중요해지며, Spring AI는 상황에 맞는 선택지를 제공한다.


실제 코드 예제로 이해하는 동작

아래는 Spring Boot 애플리케이션에서 ToolSearchToolCallAdvisor를 적용한 예시다.

@SpringBootApplication
public class Application {

    @Bean
    CommandLineRunner demo(ChatClient.Builder builder, ToolSearcher toolSearcher) {
        return args -> {
            var advisor = ToolSearchToolCallAdvisor.builder()
                .toolSearcher(toolSearcher)
                .build();

            ChatClient chatClient = builder
                .defaultTools(new MyTools())
                .defaultAdvisors(advisor)
                .build();

            var answer = chatClient.prompt("""
                Help me plan what to wear today in Amsterdam.
                Please suggest clothing shops that are open right now.
                """).call().content();

            System.out.println(answer);
        };
    }

    static class MyTools {

        @Tool(description = "Get the weather for a given location at a given time")
        public String weather(String location, 
            @ToolParam(description = "YYYY-MM-DDTHH:mm") String atTime) {...}

        @Tool(description = "Get clothing shop names for a given location at a given time")
        public List<String> clothing(String location,
                @ToolParam(description = "YYYY-MM-DDTHH:mm") String openAtTime) {...}

        @Tool(description = "Current date and time for a given location")
        public String currentTime(String location) {...}

        // 수십, 수백 개의 Tool이 추가될 수 있음
    }
}

이 예제에서 모델은 다음 흐름을 따른다.

  1. Tool Search Tool만 주어진 상태에서 질문 분석
  2. currentTime Tool이 필요하다고 판단 → 검색 요청
  3. weather Tool 필요 → 검색 요청
  4. clothing Tool 필요 → 검색 요청
  5. 각 Tool 실행 후 결과 기반 응답 생성

Tool이 100개 이상이어도 모델은 실제 필요한 3개만 선택적으로 받아본다.


벤치마크 결과: 34~64% 토큰 절감

28개 Tool(그중 실제 필요한 Tool은 3개) 환경에서 테스트한 결과는 다음과 같다.

Lucene 기반 검색 결과

모델 TST 사용 총 토큰
Gemini 2,165 60% 절감
OpenAI 4,706 34% 절감
Anthropic 6,273 64% 절감

VectorStore 기반 검색 결과

모델 TST 사용 총 토큰 
Gemini 2,214 57% 절감
OpenAI 3,697 47% 절감
Anthropic 6,319 63% 절감

공통적으로, 절감 효과는 대부분 프롬프트 토큰 감소에서 발생했다.
요청 횟수는 소폭 증가했지만 토큰 비용은 오히려 크게 감소했다.


언제 Tool Search Tool 패턴을 사용해야 할까

다음 상황 중 하나라도 해당된다면 도입을 고려해볼 필요가 있다.

  • Tool 개수가 20개 이상
  • Tool 정의 전체가 5,000 토큰 이상
  • MCP 기반 여러 서버 연결로 Tool 수가 계속 증가
  • 모델의 Tool 선택 정확도가 떨어지는 문제 발생
  • 불필요한 초기 토큰 소비로 비용이 올라가는 환경

반면 Tool 수가 5~10개 수준으로 매우 적다면 전통적인 방식도 충분히 효율적이다.


728x90

Tool Search Tool 패턴은 대규모 Tool 기반 LLM 애플리케이션에서 겪는 핵심 문제를 해결하기 위한 실질적인 접근법이다. Spring AI는 이 패턴을 모든 주요 모델에서 동일하게 활용할 수 있는 구조로 구현했고, 실제로 34~64%의 토큰 절감 효과가 검증됐다. Tool 개수가 증가하는 환경에서 비용 최적화와 정확도 향상을 동시에 달성할 수 있다는 점에서 앞으로의 AI 에이전트 아키텍처에서 핵심적인 기술로 자리 잡을 가능성이 높다.

이 패턴을 도입하면 더 많은 Tool과 더 복잡한 에이전트를 연결하더라도 비용 증가 없이 유지할 수 있고, 모델의 선택 정확도도 향상된다. 다양한 서비스와 MCP 서버가 통합되는 시대에 필수적인 선택지가 될 것이다.

300x250

https://spring.io/blog/2025/12/11/spring-ai-tool-search-tools-tzolov?fbclid=IwY2xjawOnqHpleHRuA2FlbQIxMQBzcnRjBmFwcF9pZBAyMjIwMzkxNzg4MjAwODkyAAEeav9be5vjJLnj0ZL9jWcCAXYenm8LuMgBEzr5BNFUrJZscLgmAIU3gXMvTMs_aem_UbS9oPBUo4xniqOFol-MAA

 

Smart Tool Selection: Achieving 34-64% Token Savings with Spring AI's Dynamic Tool Discovery

As AI agents connect to more services—Slack, GitHub, Jira, MCP servers—tool libraries grow rapidly. A typical multi-server setup can easily have 50+ tools consuming 55,000+ tokens before any conversation starts. Worse, tool selection accuracy degrades

spring.io

728x90
반응형
그리드형