AI 에이전트를 개발할 때 가장 많이 받는 질문 중 하나가 바로 “도구 호출(Tool Calling)을 위해 어떤 로컬 LLM을 사용해야 할까요?”입니다. 간단해 보이는 질문이지만, 실제로는 매우 복잡하고 미묘한 답변이 필요합니다.
출처: Apideck Blog
Docker 팀이 이 질문에 답하기 위해 진행한 체계적인 연구 결과를 소개합니다. 이들은 21개의 LLM 모델을 대상으로 3,570개의 테스트 케이스를 실행하여 도구 호출 성능을 실증적으로 평가했습니다.
도구 호출이란 무엇인가?
도구 호출(Tool Calling 또는 Function Calling)은 대형 언어 모델이 단순히 텍스트를 생성하는 것을 넘어서 외부 도구, API, 함수와 상호작용할 수 있게 하는 기능입니다. 사용자의 자연어 입력을 분석하여 특정 작업이 필요하다고 판단하면, 해당 작업을 수행하는 외부 함수를 호출하는 것입니다.
예를 들어, 사용자가 “오늘 날씨가 어때?”라고 묻면, 모델은 일반적인 답변을 생성하는 대신 날씨 API를 호출하여 실시간 날씨 정보를 가져올 수 있습니다. 이는 AI 에이전트가 실제 업무에 활용되기 위해 필수적인 기능입니다.
Docker의 실험 과정: 수동 테스트에서 자동화까지
Docker 팀은 처음에는 수동 테스트로 시작했습니다. chat2cart라는 AI 기반 쇼핑 어시스턴트를 만들어 다양한 로컬 LLM들을 테스트해봤습니다. 사용자가 자연어로 대화하며 쇼핑 카트를 구성하고, 제품을 추가하거나 삭제하고, 결제를 완료할 수 있는 시스템이었습니다.
OpenAI의 GPT-4나 GPT-3.5는 예상대로 잘 작동했습니다. 필요할 때 도구를 호출하고, 불필요한 도구 사용을 피하며, 도구의 응답을 자연스럽게 처리했습니다. 하지만 로컬 모델들은 여러 문제를 보였습니다.
로컬 모델들의 문제점
Berkeley Function-Calling Leaderboard에 등재된 모델들(xLAM-2-8b-fc-r, watt-tool-8B 등)을 테스트하면서 다음과 같은 문제들이 반복적으로 발생했습니다:
- 성급한 호출: “안녕하세요!”와 같은 인사말에도 도구를 호출하는 현상
- 잘못된 도구 선택: 검색해야 할 때 추가를 하거나, 빈 카트에서 삭제를 시도하는 등의 오류
- 잘못된 매개변수: 제품명이나 수량 같은 필수 매개변수가 누락되거나 잘못된 형태로 전달
- 응답 무시: 도구의 출력을 무시하여 어색하거나 불완전한 대화가 이어지는 문제
이 시점에서 수동 테스트의 한계가 명확해졌습니다. 모델마다 다른 방식으로 실패했고, 비결정적 특성 때문에 신뢰할 만한 평가를 위해서는 각 시나리오를 여러 번 실행해야 했습니다.
확장 가능한 테스트 프레임워크: model-test
Docker 팀의 목표는 학술적 엄밀함이 아니라 “2-3일 안에 충분히 좋은 답을 얻는 것”이었습니다. 이를 위해 model-test라는 유연한 테스트 프레임워크를 개발했습니다.
작동 원리
핵심 아이디어는 간단합니다. 현실적인 도구 사용 대화를 시뮬레이션하고, 모델에게 추론하고 행동할 여지를 주며, 그 행동이 합리적인지 확인하는 것입니다.
각 테스트 케이스는 다음을 포함합니다:
- 프롬프트 (예: “iPhone을 카트에 추가해줘”)
- 초기 카트 상태 (선택사항)
- 여러 개의 유효한 도구 호출 변형 (정답이 하나가 아닐 수 있기 때문)
예를 들어, “iPhone을 카트에 추가해줘”라는 요청에 대해서는 다음 두 가지 접근을 모두 허용합니다:
- 직접 “iPhone”을 추가하기
- 먼저 “iPhone”을 검색한 후 검색 결과(예: “iPhone 15”)를 추가하기
이러한 유연성은 모델의 완벽한 예측보다는 의도에 맞는 합리적인 도구 시퀀스에 집중할 수 있게 해줍니다.
에이전트 루프 시뮬레이션
실제 에이전트의 동작과 비슷하게 만들기 위해 최대 5라운드의 에이전트 루프를 시뮬레이션합니다:
- 사용자: “iPhone 5를 카트에 추가해줘”
- 모델: “iPhone 5를 검색해드리겠습니다…”
- 도구: (제품 목록 반환)
- 모델: “제품 X를 카트에 추가하겠습니다…”
- 도구: (카트 업데이트)
- 모델: “완료되었습니다” → 테스트 통과!
만약 5라운드 후에도 모델이 계속 도구를 호출하려 한다면 테스트 실패로 간주합니다.
평가 기준과 측정 방법
최종 F1 점수는 세 가지 핵심 차원을 종합합니다:
| 측정 항목 | 의미 |
|---|---|
| 도구 호출 | 모델이 도구가 필요하다는 것을 인식했는가? |
| 도구 선택 | 올바른 도구를 선택하고 정확히 사용했는가? |
| 매개변수 정확성 | 도구 호출 인수가 올바른가? |
F1 점수는 정밀도(모델이 유효한 도구 호출을 얼마나 자주 했는가)와 재현율(해야 할 도구 호출을 얼마나 자주 했는가)의 조화 평균입니다.
지연 시간(평균 실행 시간)도 추적했지만 F1 계산에는 포함되지 않았으며, 속도와 사용자 경험 평가에만 활용되었습니다.
21개 모델 테스트 결과
테스트 환경: MacBook Pro M4 Max, 128GB RAM에서 3,570개 테스트 케이스, 210개 배치 실행
전체 순위 (도구 선택 F1 점수 기준)
| 순위 | 모델 | F1 점수 |
|---|---|---|
| 1 | gpt-4 | 0.974 |
| 2 | qwen3:14B-Q4_K_M | 0.971 |
| 3 | qwen3:14B-Q6_K | 0.943 |
| 4 | claude-3-haiku-20240307 | 0.933 |
| 5 | qwen3:8B-F16 | 0.933 |
| 6 | qwen3:8B-Q4_K_M | 0.919 |
| 7 | gpt-3.5-turbo | 0.899 |
| 8 | gpt-4o | 0.857 |
| 9 | gpt-4o-mini | 0.852 |
| 10 | claude-3-5-sonnet-20241022 | 0.851 |
최고 성능 모델들
전체 모델 중에서는 OpenAI의 GPT-4가 0.974의 도구 선택 F1 점수로 1위를 차지했으며, 평균 응답 시간도 5초 미만으로 우수했습니다. 호스팅 모델이므로 로컬 모델 탐색의 직접적인 대상은 아니지만, 신뢰할 만한 벤치마크 역할을 했습니다.
로컬 모델 중에서는 Qwen 3 (14B)가 0.971의 F1 점수로 GPT-4에 거의 근접한 성능을 보였습니다. 다만 지연 시간은 약 142초로 상당히 높았습니다.
속도와 성능의 균형을 원한다면 Qwen 3 (8B)를 추천합니다. F1 점수 0.933을 달성하면서도 지연 시간을 거의 절반(약 84초)으로 줄였습니다.
Claude 3 Haiku 같은 호스팅 모델도 0.933의 F1 점수와 3.56초의 탁월한 속도로 클라우드 기반 서비스의 높은 기준을 보여주었습니다.
저조한 성능의 모델들
모든 모델이 도구 호출을 잘 처리한 것은 아닙니다. 양자화된 Watt 8B 모델은 매개변수 정확성에서 어려움을 겪어 0.484의 낮은 F1 점수를 기록했습니다. 마찬가지로 LLaMA 기반 XLam 8B 변형도 올바른 도구 경로를 자주 놓쳐 0.570의 F1 점수를 얻었습니다. 이러한 모델들은 다른 작업에는 적합할 수 있지만, 구조화된 도구 사용 테스트에서는 기대에 미치지 못했습니다.
양자화의 영향
흥미롭게도 일부 모델에 대해 양자화된 버전과 비양자화된 버전을 모두 실험한 결과, 도구 호출 동작이나 성능에서 유의미한 차이를 발견하지 못했습니다. 이는 양자화가 추론 품질에 부정적인 영향을 주지 않으면서 리소스 사용량을 줄이는 데 유익하다는 것을 시사합니다.
실무 관점에서의 모델 선택 가이드
최대 정확도가 목표라면
Qwen 3 (14B) 또는 Qwen 3 (8B)가 최선의 선택입니다. 둘 다 로컬에서 실행 가능하고 정확하며, 8B 버전이 상당히 빠릅니다.
속도와 성능의 균형을 원한다면
Qwen 2.5가 좋은 옵션으로 부각되었습니다. 실시간 경험을 지원할 만큼 빠르면서도 적절한 도구 선택 정확도를 유지합니다.
경량화가 필요하다면
리소스가 제한된 환경에서는 LLaMA 3 Groq 7B 변형이 훨씬 낮은 컴퓨팅 요구사항으로 적당한 성능을 제공합니다.
개발자들에게 주는 시사점
이번 테스트를 통해 확인된 것은 Qwen 계열 모델이 오픈소스 옵션 중에서 도구 호출에 탁월하다는 점입니다. 하지만 언제나 그렇듯 애플리케이션을 설계할 때는 정확도와 지연 시간 사이의 균형을 고려해야 합니다.
핵심 발견사항들:
Qwen 모델의 압도적 우위: Qwen3의 8B 버전조차 다른 어떤 로컬 모델보다 뛰어난 성능을 보였습니다.
추론 능력 = 지연 시간: 더 높은 정확도를 가진 모델일수록 상당히 오래 걸립니다.
도구 호출은 거의 모든 실제 GenAI 애플리케이션의 핵심입니다. 에이전트를 구축하든 에이전틱 워크플로우를 만들든, LLM이 언제 행동할지 어떻게 행동할지 알아야 합니다. 이 간단한 프레임워크 덕분에 “어떤 모델을 선택해야 할지 모르겠다”는 고민이 “명확한 장단점을 가진 세 가지 훌륭한 옵션으로 좁혔다”는 결과로 바뀌었습니다.
실제 활용을 위한 권장사항
에이전틱 애플리케이션을 위한 모델을 평가하고 있다면, 추측에 의존하지 마세요. Docker의 model-test 프레임워크를 활용해 자신만의 테스트를 만들어보시기 바랍니다.
도구 호출은 단순히 기술적 기능을 넘어서 AI가 실제 세계와 상호작용하는 핵심 메커니즘입니다. 올바른 모델 선택은 사용자 경험과 애플리케이션 성공에 직접적인 영향을 미칩니다. Docker 팀의 체계적인 연구 결과를 참고하여 여러분의 프로젝트에 가장 적합한 모델을 선택하시기 바랍니다.
참고자료:
Comments