도구 사용과 함수 호출(Tool Use and Function Calling)

Toolformer(Schick et al., 2023)는 자기 지도(self-supervised) 방식의 도구 주석(Tool Annotation)을 처음 도입했습니다. Berkeley Function Calling Leaderboard V4(Patil et al., 2025)는 2026년의 기준선을 제시합니다. 그 구성은 에이전트형(Agentic) 40%, 멀티턴(Multi-Turn) 30%, 라이브(Live) 10%, 비라이브(Non-Live) 10%, 환각(Hallucination) 10%입니다. 단일 턴(Single-Turn) 함수 호출은 거의 해결된 단계에 도달했지만, 기억(Memory), 동적 의사결정(Dynamic Decision-Making), 그리고 긴 호흡의 도구 체인(Long-Horizon Tool Chain) 문제는 여전히 풀리지 않은 과제로 남아 있습니다.

유형: Build 언어: Python (stdlib) 선수 학습: Phase 14 · 01 (에이전트 루프), Phase 13 · 01 (Function Calling Deep Dive) 소요 시간: 약 60분

학습 목표

• Toolformer의 자기 지도 학습 신호를 설명할 수 있습니다. 도구 실행 결과가 다음 토큰 손실(Next-Token Loss)을 줄일 때에만 해당 도구 주석을 유지하는 원리를 이해합니다.
• BFCL V4의 다섯 가지 평가 범주와 각 범주가 무엇을 측정하는지 설명할 수 있습니다.
• 스키마 검증(Schema Validation), 인자 강제 변환(Argument Coercion), 실행 샌드박싱(Execution Sandboxing)을 포함한 표준 라이브러리(stdlib) 기반의 도구 레지스트리(Tool Registry)를 직접 구현할 수 있습니다.
• 2026년 현재 남아 있는 세 가지 열린 문제, 즉 긴 호흡의 도구 체이닝(Long-Horizon Tool Chaining), 동적 의사결정(Dynamic Decision-Making), 기억(Memory) 문제를 진단할 수 있습니다.

문제

초기의 도구 사용 연구는 "모델이 올바른 함수 호출(Function Call)을 예측할 수 있는가?"라는 질문에서 출발했습니다. 그러나 현대의 도구 사용은 훨씬 더 어려운 질문을 던집니다. 모델이 40단계에 걸쳐 도구를 연결해 사용하고, 기억을 유지하며, 부분 관찰 가능성(Partial Observability) 속에서도 동작하고, 도구 실패에서 스스로 복구하며, 존재하지 않는 도구를 환각해 만들어내지 않을 수 있는가 하는 문제입니다.

Toolformer는 그 기준선을 세웠습니다. 모델은 자기 지도 방식으로 언제 도구를 호출해야 하는지 학습할 수 있다는 점을 보여주었습니다. BFCL V4는 2026년 기준으로 평가 목표를 정의합니다. 그리고 이 둘 사이의 간격이 바로 실제 프로덕션 에이전트가 살아남아야 하는 공간입니다.

개념

Toolformer (Schick et al., NeurIPS 2023)

핵심 아이디어는 다음과 같습니다. 모델이 자신의 사전학습 말뭉치(Pretraining Corpus)에 직접 후보 API 호출을 주석으로 달게 만들고, 각 후보를 실제로 실행해봅니다. 그리고 도구의 실행 결과를 포함했을 때 다음 토큰 손실이 줄어드는 경우에만 해당 주석을 유지합니다. 이후 이렇게 필터링된 말뭉치로 모델을 미세 조정(Fine-Tuning)합니다.

이 논문에서 다룬 도구는 계산기, 질의응답(Question Answering; QA) 시스템, 검색 엔진, 번역기, 달력입니다. 자기 지도 신호는 오직 "도구가 텍스트 예측을 돕는가"만을 기준으로 삼으며, 사람이 직접 라벨링한 데이터는 사용하지 않습니다.

규모(scale) 관점의 결과는 흥미롭습니다. 도구 사용 능력은 모델 규모가 커질수록 발현되는 성질을 보입니다. 작은 모델은 오히려 도구 주석을 주입하면 성능이 떨어지기도 하지만, 큰 모델은 분명한 이득을 봅니다. 그래서 2026년의 프런티어 모델(Frontier Model)은 강력한 도구 사용 능력을 기본적으로 내장한 채 출시되는 반면, 대부분의 7B 규모 모델은 신뢰할 수 있는 도구 사용을 위해 별도의 명시적 도구 사용 미세 조정이 필요합니다.

Berkeley Function Calling Leaderboard V4 (Patil et al., ICML 2025)

BFCL은 2026년 시점에서 사실상의 표준(de facto) 평가로 자리 잡았습니다. V4의 구성은 다음과 같습니다.

• 에이전트형(Agentic, 40%) — 전체 에이전트 궤적(trajectory)을 평가합니다. 기억, 멀티턴, 동적 의사결정을 모두 포함합니다.
• 멀티턴(Multi-Turn, 30%) — 도구 체인을 포함한 상호작용형 대화를 평가합니다.
• 라이브(Live, 10%) — 사용자가 실제로 제출한 프롬프트를 사용합니다. 합성 데이터보다 더 어려운 분포를 가집니다.
• 비라이브(Non-Live, 10%) — 합성으로 만든 테스트 사례를 사용합니다.
• 환각(Hallucination, 10%) — 도구를 호출하지 말아야 할 상황을 감지하는 능력을 평가합니다.

V3는 상태 기반 평가(State-Based Evaluation)를 도입했습니다. 도구 호출의 추상 구문 트리(Abstract Syntax Tree; AST)를 비교하는 대신, 도구 시퀀스가 끝난 뒤 API의 실제 상태를 확인합니다. 예를 들어 "파일이 실제로 생성되었는가?"를 검사하는 방식입니다. V4는 여기에 웹 검색, 기억, 형식 민감도(Format Sensitivity) 범주를 새로 추가했습니다.

2026년의 핵심 발견은 단일 턴 함수 호출은 거의 해결되었다는 점입니다. 이제 실패는 주로 기억(턴 사이의 맥락 유지), 동적 의사결정(이전 결과를 바탕으로 다음 도구를 선택하기), 긴 호흡의 체인(20단계 이상이 넘어가면서 발생하는 표류), 환각 감지(맞는 도구가 없을 때 호출을 거부하기)에 집중되어 있습니다.

도구 스키마(Tool Schema)

모든 LLM 제공자(provider)는 자체적인 도구 스키마를 가지고 있습니다. 세부 사항은 조금씩 다르지만, 기본 형태는 거의 동일합니다.

name: string
description: string (what it does, when to use it)
input_schema: JSON Schema (properties, required, types, enums)

Anthropic은 input_schema를 직접 사용하고, OpenAI는 function.parameters를 사용합니다. 두 형식 모두 JSON Schema를 입력으로 받습니다. 여기서 설명(description)은 단순한 부가 정보가 아니라 핵심을 떠받치는 요소입니다. 모델은 이 설명을 읽고 어떤 도구를 사용할지 판단하기 때문입니다. 그래서 부실한 도구 설명은 "잘못된 도구를 선택하는" 실패의 가장 흔한 근본 원인이 됩니다.

인자 검증(Argument Validation)

어떤 도구 호출도 그대로 신뢰해서는 안 됩니다. 다음 항목을 반드시 검증해야 합니다.

1. 타입 강제 변환(Type Coercion). 스키마가 정수(int)를 요구하는데 모델이 문자열 "5"를 반환할 수 있습니다. 변환이 명확한 경우에는 자동으로 변환하고, 애매한 경우에는 거부합니다.
2. 열거형 검증(Enum Validation). 스키마가 status in {"open", "closed"}로 정의되어 있는데 모델이 "in_progress"를 내보내면, 설명이 담긴 오류 메시지와 함께 거부합니다.
3. 필수 필드(Required Fields). 필수 필드가 빠져 있으면 즉시 오류 관찰(Error Observation)을 모델 쪽으로 돌려줍니다. 런타임을 그대로 종료시키지 않습니다.
4. 형식 검증(Format Validation). 날짜, 이메일, URL 같은 값은 정규식이 아니라 전용 파서(parser)로 검증합니다.

모든 검증 실패는 구조화된 관찰(Structured Observation) 형태로 반환되어야 합니다. 그래야 모델이 올바른 형식으로 다시 호출을 시도할 수 있습니다.

병렬 도구 호출(Parallel Tool Calls)

요즘 LLM 제공자들은 하나의 어시스턴트 턴 안에서 여러 도구를 병렬로 호출하는 기능을 지원합니다. 그 루프는 다음과 같이 동작합니다.

1. 모델이 서로 다른 tool_use_id 값을 가진 도구 호출 3개를 한 번에 내보냅니다.
2. 런타임은 이 호출들을 실행합니다. 서로 독립적이라면 병렬로 실행할 수 있습니다.
3. 각 실행 결과는 동일한 tool_use_id로 매칭된 tool_result 블록 형태로 모델에게 돌아갑니다.

여기서 한 가지 핵심 엔지니어링 규칙이 있습니다. 상관 식별자(Correlation ID)를 시스템의 핵심 요소로 다루어야 한다는 점입니다. 이 ID가 뒤섞이면 잘못된 도구와 엉뚱한 결과가 짝지어지는 라우팅 오류가 발생합니다.

샌드박싱(Sandboxing)

도구 실행 지점은 그대로 샌드박스의 경계가 됩니다. 자세한 내용은 09강에서 다룹니다. 핵심만 말하면, 모든 도구는 자신의 읽기/쓰기 표면(Read/Write Surface), 네트워크 접근 권한, 제한 시간(Timeout), 메모리 한도(Memory Cap)를 명시적으로 정의해야 합니다. 범용적인 run_shell(cmd) 같은 도구는 위험 신호이며, 구체적이고 좁은 책임을 가진 git_status() 같은 도구가 훨씬 안전합니다.

만들어보기

code/main.py는 프로덕션 수준의 형태를 갖춘 도구 레지스트리를 구현합니다.

• 표준 라이브러리(stdlib)만 사용하는 JSON Schema 부분집합 검증기
• 설명, 입력 스키마, 제한 시간, 실행기(executor)를 포함한 도구 등록 기능
• 인자 강제 변환과 열거형 검증
• 상관 식별자를 사용하는 병렬 도구 디스패치(dispatch)
• 구조화된 문자열 형태의 오류 관찰

다음 명령으로 실행합니다.

python3 code/main.py

실행 트레이스(trace)는 미니 에이전트가 한 번의 턴에서 세 개의 도구를 호출하는 모습을 보여줍니다. 그중 일부러 잘못 만든 호출 하나는, 모델이 그 정보를 받아 즉시 행동을 교정할 수 있도록 설명이 담긴 오류와 함께 거부됩니다.

사용해보기

LLM 제공자들은 Anthropic, OpenAI, Gemini, Bedrock처럼 각자 고유한 도구 스키마를 가지고 있습니다. 여러 제공자를 함께 사용해야 한다면 OpenAI Agents SDK, Vercel AI SDK, LangChain tool adapter 같은 변환 계층(Translation Layer)을 활용하는 것이 좋습니다. 그리고 도구 사용이 제품의 중심 기능이라면, 배포 전에 BFCL을 기준 벤치마크로 삼아 에이전트를 한 번 돌려보는 과정을 권장합니다.

산출물 만들기

outputs/skill-tool-registry.md는 특정 작업 도메인을 위한 도구 카탈로그, 스키마, 레지스트리를 생성하는 산출물입니다. 여기에는 설명 품질 검사도 포함되어 있어, 각 도구의 설명이 "모델에게 언제 그 도구를 골라야 하는지"를 충분히 전달하고 있는지 확인할 수 있습니다.

연습문제

1. (쉬움) 모델이 어떤 도구도 사용하지 않겠다고 명시적으로 거부할 수 있는 "no-op" 도구를 추가해 보세요. 그리고 이를 BFCL과 유사한 환각 테스트에서 측정해 보세요.
2. (쉬움) 문자열로 들어온 정수와 실수를 각각 정수/실수로 강제 변환하는 기능을 구현해 보세요. 그리고 강제 변환이 어느 지점부터 실제 버그를 가리기 시작하는지 분석해 보세요.
3. (중간) 도구별 제한 시간과 회로 차단기(Circuit Breaker)를 추가해 보세요. 예를 들어 연속 3회 실패한 도구는 60초 동안 호출 자체를 거부하도록 만듭니다. 이 변경은 모델의 복구 방식에 어떤 영향을 주나요?
4. (중간) BFCL V4 문서를 읽어 보세요. "멀티턴" 같은 범주 하나를 골라 예시 프롬프트 10개를 직접 만든 에이전트에 통과시키고, 통과율을 측정해 보고서로 정리해 보세요.
5. (어려움) 표준 라이브러리 기반의 검증기를 Pydantic 또는 Zod로 이식해 보세요. 장난감 수준의 검증기가 놓쳤지만 Pydantic/Zod는 잡아낸 케이스에는 어떤 것들이 있었나요?

핵심 용어

더 읽을거리

• Schick et al., Toolformer (arXiv:2302.04761) — 자기 지도 방식의 도구 주석을 처음 제안한 논문입니다.
• Berkeley Function Calling Leaderboard (V4) — 2026년 시점의 도구 사용 평가 벤치마크입니다.
• Anthropic, Tool use documentation — Claude Agent SDK에서 사용하는 프로덕션 수준의 도구 스키마 문서입니다.
• OpenAI Agents SDK docs — 함수 도구(Function Tool) 유형과 가드레일(Guardrails)에 대한 공식 문서입니다.