이런 경험 있나요? 도구 목록이 30개만 되어도 LLM이 헤맨다
개발자들이 LLM 에이전트를 만들면서 가장 흔하게 겪는 문제가 뭘까요? 바로 Tool Calling입니다. 사용자 요청을 받은 LLM이 필요한 도구를 선택해서 호출하는 것 같은데, 도구 개수가 조금 늘어나면 정확도가 확 떨어집니다. 웹 검색 도구, 데이터베이스 조회 도구, API 호출 도구, 계산기, 캘린더, 이메일 등 실무에서 쓸 만한 도구들을 다 연결하다 보니 어느새 50개가 넘습니다. 그럼 뭐가 일어날까요? LLM이 어떤 도구를 써야 할지 헷갈립니다. 잘못된 도구를 호출하고, 필요한 도구를 놓치기도 합니다.
2025년 현재, 이 문제는 단순히 프롬프트를 잘 쓴다고 해결되지 않습니다. LLM이 토큰으로 모든 도구의 정의를 다 로드해야 하기 때문에, 도구가 30개를 넘기면 “context bloat”이라는 심각한 문제가 생깁니다. 프롬프트에 도구 정의만 55,000개 토큰을 먹이는데, 사용자의 실제 질문은 아직 안 들어온 상태죠. 비용도 올라가고, 응답 속도도 느려집니다.
그런데 더 심각한 건 정확도입니다. 도구 30개가 넘으면 LLM의 도구 선택 정확도가 눈에 띄게 떨어집니다. “리포트를 생성해라”는 요청에 “보고서 생성”과 “레포트 작성” 두 도구가 있으면, 모델은 헷갈립니다. 비슷한 이름의 도구들이 많아질수록 LLM은 번갈아 가며 호출하거나 아예 틀린 도구를 집어듭니다.
Tool Calling의 기본부터 다시 생각해보자
먼저 Tool Calling이 뭔지 제대로 이해해야 합니다. 이건 LLM이 외부 도구(API, 함수, 데이터베이스)를 호출해서 실제 세상과 상호작용하는 기능입니다. 예를 들어, “서울의 오늘 날씨 뭐야?”라는 질문을 받으면 LLM은 get_weather 도구를 호출하면서 파라미터로 city=”서울”을 넘깁니다. 도구가 결과를 반환하면 LLM은 그 정보를 바탕으로 자연스러운 답변을 만듭니다.
이 과정은 ReAct(Reasoning + Acting)라는 패턴을 따릅니다. 생각하고(Reasoning), 행동하고(Acting), 관찰한 결과(Observation)를 바탕으로 다시 생각하는 루프죠. 시스템은 이 사이클을 몇 번 반복하면서 복잡한 문제를 풉니다. 이론적으로는 완벽합니다. 하지만 실전에서는 도구 개수가 늘어나면서 모든 게 꼬입니다.
왜 도구가 많으면 LLM이 혼란스러워할까
2025년 최신 연구에서 밝혀진 핵심 원인들을 정리해보겠습니다. 첫 번째는 “Context Bloat”입니다. 도구가 28개면 프롬프트에 55,000개 토큰을 먹여야 합니다. OpenAI의 GPT-5 같은 모델은 토큰이 비싸거든요. 도구 정의 하나가 평균 1,500에서 2,000개 토큰을 차지합니다. 설명, 파라미터, 타입 정보가 다 들어가니까요. 그러면 사용자의 실제 질문은 이미 컨텍스트의 아래쪽에 밀려있습니다. LLM 입장에서는 도구의 정의들이 훨씬 크게 보이고, 사용자 질문은 흐릿해집니다.
두 번째는 “Tool Confusion”입니다. 도구 30개 중에 비슷하게 이름 붙은 도구들이 있으면 LLM은 선택을 못 합니다. get_user_info와 get_user_profile, query_user_data 같은 도구들이 한데 있으면, 모델은 어떤 차이가 있는지 정확히 파악하기 어렵습니다. OpenAI와 Anthropic 같은 대형 모델도 도구가 30개 이상 있으면 정확도가 떨어진다는 벤치마크 결과가 있습니다.
세 번째는 “Token Waste”입니다. 사용자가 날씨만 물었는데 모든 도구의 정의를 로드합니다. 실제로 필요 없는 도구들도 매번 프롬프트에 들어갑니다. 이건 돈 낭비일 뿐만 아니라, 응답 시간도 느리게 만듭니다.
현실의 사례: 누가 30개 이상의 도구를 쓸까
생각해보면 실무에서는 30개 정도는 쉽게 넘습니다. 회사 내부 시스템을 연결하는 에이전트를 만든다고 하세요. Slack 통합, GitHub 통합, Jira 통합, Google Workspace 통합만 해도 수십 개의 도구가 필요합니다. Slack만 해도 메시지 보내기, 파일 업로드, 반응 추가, 스레드 조회 등 10개 이상의 도구가 필요합니다. MCP(Model Context Protocol) 서버를 여러 개 연결하면 100개가 넘을 수도 있습니다.
예를 들어, 한 금융회사가 LLM 기반의 보고서 작성 어시스턴트를 만들었습니다. 사원들이 “Q3 매출 보고서 작성해줘”라고 하면, 에이전트가 자동으로 데이터를 수집해서 보고서를 만들어주는 거죠. 이 시스템은 데이터베이스 조회(판매, 고객, 재고 등 분야별로 5개), API 호출(외부 시장 데이터 3개), 파일 작업(PDF 생성, CSV 내보내기 2개), 이메일(전송, 예약 2개), Slack 알림 2개 등 총 14개 도구가 필요했습니다. 프로토타입 단계에는 잘 작동했습니다. 하지만 회사가 시스템을 확장하면서 도구가 50개를 넘자 정확도가 60%까지 떨어졌어요. 일반적으로 단순한 작업은 95% 정확도로 작동하는데, 도구가 많으면 15%나 떨어집니다.
2025년의 해결책: Tool Search Tool 패턴
이 문제를 해결하기 위해 2025년에 나온 가장 효과적인 방법이 “Tool Search Tool” 패턴입니다. Anthropic이 처음 제안했고, Spring AI가 구현해서 공개했습니다.
핵심 아이디어는 간단합니다. 모든 도구를 미리 로드하지 말고, LLM이 필요할 때 검색해서 찾도록 하는 거죠. 처음에는 LLM에게 “tool_search”라는 특수한 도구만 줍니다. 사용자의 요청을 받으면 LLM이 먼저 “어떤 도구가 필요할까?”를 생각해서 tool_search를 호출합니다. 예를 들어, “내 GitHub 이슈들을 정리해줘”라는 요청이 들어오면, LLM은 tool_search(“GitHub 이슈”)라고 호출합니다. 그럼 시스템이 관련된 도구들만 검색해서 반환합니다. GitHub 이슈 조회, 이슈 필터링, 라벨 추가 등 5개 도구만 로드되는 거죠.
이 방식의 효과가 정말 놀랍습니다. 실제 벤치마크 결과를 보면, 같은 50개 도구를 다루는 상황에서도 Token 사용량이 34% ~ 64%까지 줄어듭니다. 도구 검색에 추가 요청이 4~5개 필요하지만, 토큰 절감 효과가 훨씬 크기 때문에 최종 비용은 더 낮아집니다. 응답 시간도 빨라지고, 정확도는 유지됩니다.
도구 설계할 때 꼭 고려해야 할 것들
우선 도구를 만들 때 명확한 이름과 설명이 필수입니다. “get_data”보다는 “get_sales_report_q3” 같이 구체적인 이름이 훨씬 낫습니다. 도구 설명도 짧고 명확해야 합니다. 복잡한 설명은 LLM을 더 헷갈리게 합니다.
도구의 파라미터도 최소화해야 합니다. 선택적 파라미터를 많이 두는 것보다, 필수 파라미터만 명확하게 정의하세요. 그래야 LLM이 쉽게 판단할 수 있습니다.
도구들을 의미론적으로 그룹화하는 것도 좋은 전략입니다. “GitHub 도구들”, “데이터 조회 도구들” 같이 카테고리를 정해놓으면, Tool Search Tool이 더 정확하게 검색할 수 있습니다.
버전 관리도 중요합니다. 도구가 변경되면 LLM에게 새로운 정의를 줘야 하는데, 이게 자동화되어 있지 않으면 문제가 생깁니다. 2025년에는 MCP(Model Context Protocol)라는 표준이 나왔는데, 이를 사용하면 도구 버전 관리와 업데이트가 훨씬 쉬워집니다.
실제 구현: Orchestrator 패턴
더 정교한 해결책도 있습니다. “Orchestrator” 패턴이라고 불리는데, 작은 LLM이 도구 선택을 전담하는 방식입니다. 예를 들어, 8B 파라미터의 작은 모델(Orchestrator-8B)을 학습해서 도구 선택만 하게 하고, 실제 작업은 GPT-5 같은 큰 모델에 위임하는 거죠.
이 방식의 장점은 정확도와 비용 효율성입니다. Orchestrator-8B는 어떤 도구 조합이 필요한지 정확하게 파악합니다. LLM이 실수로 비싼 모델을 불필요하게 호출하는 일을 줄입니다. 실제로 테스트한 결과, 같은 작업을 할 때 GPT-5를 1.6번 호출하는 반면, 프롬프트 기반의 단순한 방식은 6번 이상 호출했습니다. 비용이 4배 차이 나는 거죠.
2026년 최신 트렌드: 동적 도구 발견
최신 기술 트렌드는 “Dynamic Tool Discovery”입니다. Spring AI의 최신 버전에서 이를 구현했습니다. 벡터 데이터베이스나 Lucene을 사용해서 도구를 시맨틱하게 검색하는 방식입니다.
사용자가 “내 GitHub 저장소의 최근 pull request들을 내 팀의 Slack에 공유해줘”라고 하면, 시스템이 자동으로 GitHub 조회 도구, Slack 메시지 전송 도구를 검색해서 찾습니다. 도구들 사이의 의존성도 자동으로 파악합니다. GitHub에서 데이터를 가져온 후, 그 데이터를 Slack에 보내는 순서를 이해하는 거죠.
이 방식은 토큰 절감(34~64%), 정확도 유지, 응답 속도 개선을 동시에 달성합니다. 가장 중요한 건 확장성입니다. 도구가 100개, 1,000개가 되어도 성능이 선형적으로 떨어지지 않습니다.
결론: 도구는 많을수록 좋은 게 아니다
2026년 현재, LLM 에이전트에서 도구 호출은 가장 중요한 부분입니다. 하지만 도구가 많다고 능력이 좋아지는 건 아닙니다. 오히려 너무 많으면 정확도가 떨어지고 비용이 늘어납니다.
효과적인 에이전트를 만들려면, 첫째 필요한 도구만 준비하고, 둘째 도구의 이름과 설명을 명확하게 하고, 셋째 Tool Search Tool이나 Orchestrator 같은 동적 발견 패턴을 사용하고, 넷째 도구들을 의미론적으로 그룹화하는 것이 중요합니다.
2025년의 최신 연구와 실무 사례들은 명확히 보여줍니다. 도구를 똑똑하게 선택하는 능력이, 도구를 많이 갖는 것보다 중요합니다. LLM에게 50개의 도구를 모두 보여주는 것보다, 필요한 5개의 도구만 정확하게 찾아서 보여주는 게 훨씬 효율적입니다. 이것이 2025년 Tool Calling 설계의 핵심 원칙입니다.