
Toolformer 해부: AI가 스스로 도구 사용법을 깨우친 날
1750억 GPT-3도 못하는 산수를 67억 모델이 해냈다. 비결은 '스스로 도구 쓰는 법을 배운 것.' 2023년 Meta AI의 Toolformer 논문이 열어젖힌 도구 사용 AI의 세계를, 2026년 MCP 시대의 시점에서 되짚는다.

1750억 GPT-3도 못하는 산수를 67억 모델이 해냈다. 비결은 '스스로 도구 쓰는 법을 배운 것.' 2023년 Meta AI의 Toolformer 논문이 열어젖힌 도구 사용 AI의 세계를, 2026년 MCP 시대의 시점에서 되짚는다.
2022년, ChatGPT가 세상을 놀라게 했다. 시를 쓰고, 코드를 짜고, 역사를 논하고, 전략을 세웠다. 그런데 이상한 점이 있었다.
"371 × 54는?"
ChatGPT는 자신 있게 대답했다. "20,034." 정답은 20,034다. 하지만 조금만 숫자가 커지면 금세 무너졌다. 7자리 곱셈? 확률적으로 찍는 수준이었다. 간단한 계산기 앱이 0.001초에 정확히 풀 수 있는 문제를, 1,750억 개의 파라미터를 가진 거대 모델이 틀리고 있었다.
산수만이 아니었다. "오늘 무슨 요일이야?"라고 물으면 학습 데이터가 끊긴 시점의 날짜를 자신 있게 말했다. 최신 뉴스를 물으면 그럴듯하게 지어냈다(hallucination). 스와힐리어 번역을 부탁하면 품질이 급락했다.
천재인데 산수를 못하고, 달력을 모르고, 사전 없이 저자원 언어를 번역하려 한다. 모델을 아무리 키워도 이 문제들은 근본적으로 해결되지 않았다. 더 큰 파라미터로 사칙연산의 정확도를 99%에서 99.9%로 올리는 것은 기하급수적 비용이 드는 반면, 계산기를 쓰면 100%가 즉시 보장된다.
2023년 2월, Meta AI Research의 Timo Schick 등 8명이 이 문제에 정면으로 답하는 논문을 발표했다.
"Toolformer: Language Models Can Teach Themselves to Use Tools."
제목이 핵심을 말한다 — "언어 모델은 스스로 도구 사용법을 배울 수 있다." 인간이 일일이 가르쳐주지 않아도, 모델이 알아서 계산기를 집고, 검색엔진을 열고, 번역기를 돌리고, 달력을 확인하는 법을 익힌다.
결과는 충격적이었다. 67억 파라미터의 GPT-J가 1,750억 파라미터의 GPT-3를 여러 벤치마크에서 능가했다. 크기가 아니라 도구가 차이를 만들었다.
이 글에서는 Toolformer가 왜 필요했고, 어떻게 작동하며, 2026년 현재의 AI 생태계에 어떤 유산을 남겼는지를 처음부터 끝까지 추적한다.
잠깐 인류 역사를 떠올려보자. 호모 사피엔스가 다른 영장류와 결정적으로 갈라진 계기는 무엇인가? 도구 사용이다. 250만 년 전 올도완 석기부터 오늘의 스마트폰까지, 인간은 자신의 생물학적 한계를 도구로 극복해왔다.
AI도 마찬가지다. 아무리 거대한 언어 모델도 근본적으로 "확률적 다음 토큰 예측기"다. 이 구조에는 본질적 한계가 있다.
논문은 크기를 키워도 해결되지 않는 네 가지 구조적 한계를 지적한다:
최신 정보에 접근 불가. 학습 데이터가 끊긴 시점 이후의 세계를 모른다. 그래서 존재하지 않는 사실을 자신 있게 지어낸다 (hallucination).
저자원 언어 이해 부족. 영어와 주요 유럽어 위주로 학습된 모델은 스와힐리어, 힌디어 같은 언어에서 성능이 급락한다.
수학 능력 부재. 다음 토큰을 "예측"하는 것과 수학적으로 "계산"하는 것은 근본적으로 다른 연산이다.
시간 인식 불가. "오늘이 무슨 요일인지", "크리스마스까지 며칠 남았는지" 알 수 없다.
이 한계들의 공통점이 있다. 전부 외부 도구를 쓰면 즉시 해결된다는 것이다. 검색엔진은 최신 정보를 제공하고, 번역기는 200개 언어를 지원하고, 계산기는 사칙연산을 완벽히 수행하며, 달력은 오늘 날짜를 알려준다.
문제는 "어떻게 도구를 쓰게 할 것인가"였다.
Toolformer 이전에도 AI에게 도구를 쥐어주려는 시도는 있었다. 하지만 각각 심각한 한계가 있었다.
WebGPT (OpenAI, 2021), LaMDA (Google, 2022), BlenderBot 3 (Meta, 2022) — 이 모델들은 인간 주석자(annotator)가 "이 맥락에서는 검색을 해야 해", "이 결과를 이렇게 활용해야 해"라고 직접 시범을 보여주고, 그 데이터로 학습했다.
문제: 비용이 엄청나다. 도구 하나당 수만 건의 인간 주석이 필요하다. 새로운 도구를 추가하려면? 또 수만 건. 10개의 도구를 쓰게 하려면? 10배의 비용. 확장이 불가능하다.
ReAct (Yao et al., 2022), PAL (Gao et al., 2022) — 이 방법들은 프롬프트에 "이런 상황에서는 검색을 하세요"라고 지시하고, 몇 가지 예시(few-shot)를 보여주는 방식이다.
문제: 특정 태스크에만 작동한다. "이 태스크에서는 계산기를 써야 한다"를 미리 알아야 한다. 범용적으로 "알아서 적절한 도구를 골라 쓰라"는 것은 불가능하다. 그리고 모델의 범용 언어 능력이 훼손될 수 있다.
이 한계들을 보고, Toolformer 팀은 두 가지 핵심 원칙을 세웠다:
- 도구 사용은 자기지도(self-supervised) 방식으로 학습되어야 한다. 대량의 인간 주석 없이.
- 모델의 범용성을 잃어서는 안 된다. 언제, 어떤 도구를, 어떻게 쓸지를 모델 스스로 결정해야 한다.
이 두 원칙이 Toolformer를 이전의 모든 시도와 근본적으로 구분짓는다.
Toolformer의 아이디어는 놀랍도록 단순하고 우아하다. 한 문장으로 요약하면:
"API 호출을 삽입했을 때 모델이 다음 토큰을 더 잘 예측하면, 그 API 호출은 유용하다."
이것이 전부다. 인간이 "이 상황에서 검색하라"고 가르칠 필요가 없다. 모델이 스스로 시도해보고, 퍼플렉시티(perplexity)가 줄어드는지 확인한다. 줄어들면 유용한 도구 사용, 줄어들지 않으면 불필요한 도구 사용.
비유하자면 이렇다:
시험을 치는 학생이 있다. 옆에 계산기, 사전, 백과사전이 놓여 있다. 학생은 각 문제마다 "계산기를 쓰면 더 잘 풀 수 있나?", "사전을 찾으면 도움이 되나?"를 스스로 판단한다. 실제로 도움이 된 경우만 기억해서, 다음 시험에서는 더 정확하게 도구를 사용한다. 선생님이 "3번 문제에서 계산기를 쓰세요"라고 알려줄 필요가 없다.
Toolformer는 도구 사용을 텍스트 시퀀스 안에 자연스럽게 삽입한다. 특수 토큰을 사용한 형식:
[QA("조 바이든은 어디서 태어났는가?")][QA("조 바이든은 어디서 태어났는가?") → 스크랜턴, 펜실베이니아]
텍스트 생성 중에 모델이 [ 토큰을 생성하면 "도구를 쓰겠다"는 의미이고, → 토큰을 생성하면 "결과를 기다리겠다"는 의미다. 시스템은 이 시점에서 실제로 API를 호출하고, 결과를 삽입한 뒤 생성을 이어간다.
Toolformer의 학습은 정확히 세 단계로 이루어진다.
대규모 텍스트 데이터셋(CCNet)의 각 문서에 대해, 모델에게 "이 텍스트에 API 호출을 추가해봐"라고 요청한다. 핵심은 프롬프트 설계다. 각 도구마다 2~5개의 예시만 제공한다.
예를 들어 계산기 도구의 프롬프트:
[Calculator(723 / 252)] 2.87골).
이 프롬프트를 보고, 모델은 새로운 텍스트의 어느 위치에 어떤 API 호출을 삽입할 수 있을지 후보를 대량 생성한다. 각 위치마다 최대 5개의 후보를 만든다.
생성된 모든 API 호출 후보를 실제로 실행한다. 계산기 호출은 Python으로 계산하고, 검색 호출은 위키피디아 인덱스에서 검색하고, QA 호출은 Atlas 모델에 질문한다.
여기가 Toolformer의 진짜 마법이 일어나는 곳이다. 각 API 호출에 대해 두 가지 손실(loss)을 비교한다:
만약 (기본값 1.0)이면 — 즉, 도구를 쓰면 다음 토큰 예측이 의미있게 좋아지면 — 이 API 호출은 유지된다. 아니면 버린다.
구체적으로 어떤 일이 벌어지는지 예시로 보자:
텍스트: "파리에서 런던까지의 거리는 약 344km이다."
후보 1: "파리에서 런던까지의 거리는 약
[Calculator(344)]344km이다." → 계산기가 344를 반환한다. 하지만 이미 텍스트에 답이 있다. 가 작다. 버림.후보 2: "파리에서 런던까지의 거리는 약
[QA("파리에서 런던까지 거리는?") → 344km]344km이다." → QA 결과가 다음 토큰 "344"를 예측하는 데 크게 도움된다. 가 크다. 유지.
이 필터링 과정에서, 100만 건 이상의 문서를 처리해도 유용한 예시는 수천~수만 건에 불과하다:
계산기 학습 데이터가 994건에 불과하다는 점에 주목하라. 100만 건의 문서에서 계산기가 정말로 도움이 되는 순간은 그만큼 드물다는 뜻이다. 하지만 이 소량의 고품질 데이터가 놀라운 효과를 발휘한다.
필터링된 API 호출들을 원본 텍스트에 삽입하고, 이 증강된 데이터셋으로 모델을 파인튜닝한다. 핵심: API 호출을 제외하면 원본 데이터와 동일한 텍스트다. 따라서 모델의 범용 언어 능력은 보존된다.
NVIDIA A100 GPU 8장에서 최대 2,000 스텝, 약 수 시간의 학습이면 충분하다.
Toolformer는 5가지 도구를 사용한다. 유일한 조건은 (1) 입출력이 텍스트로 표현 가능하고, (2) 몇 개의 예시를 보여줄 수 있다는 것이다.
각 도구의 역할을 구체적 예시로 보자:
QA 시스템: "코카콜라, 또는 [QA("코카콜라의 다른 이름은?") → 코크] 코크는 코카콜라 컴퍼니가 제조하는 탄산음료다."
계산기: "1994년에 파리에 가서 2011년까지 있었으니, 총 [Calculator(2011 - 1994) → 17] 17년이다."
Wikipedia 검색: "가나 국기의 색상 의미: 빨강은 [WikiSearch("가나 국기 빨강 의미") → 순교자의 피] 순교자의 피를..."
번역기: "그의 저서 O homem suprimido [MT(O homem suprimido) → The Suppressed Man] (억압당한 남자)는..."
캘린더: "오늘은 올해 첫 번째 [Calendar() → 2023년 2월 9일, 목요일] 금요일이다." (모델이 캘린더를 참조해 사실관계를 확인)
"___은 ___에서 태어났다" 같은 빈칸 채우기 형식의 사실 검증 태스크다.
Toolformer가 GPT-3를 13.7%p 차이로 압도했다. 크기는 25분의 1인데, 사실 지식 과제에서 훨씬 정확하다. 비결? 모델이 98.1%의 사례에서 자발적으로 QA 도구를 사용했다. "모르면 물어본다"는 전략을 스스로 학습한 것이다.
수학 문제 풀이 벤치마크. 여기서 결과는 더 극적이다.
GPT-3 대비 거의 3배. Toolformer는 97.9%의 수학 문제에서 계산기를 사용했다. 모델이 수학적 "추론" (문제를 읽고 수식으로 변환하는 것)은 자체 능력으로 수행하고, 실제 "계산"은 계산기에 위임하는 역할 분담을 스스로 학습한 것이다.
흥미로운 점: 도구를 비활성화해도 Toolformer는 기본 GPT-J보다 수학 성능이 높았다 (14.8% vs 7.5%). API 호출 데이터로 파인튜닝하는 과정에서 모델 자체의 수리적 추론 능력도 향상된 것이다.
영어 맥락을 읽고, 아랍어·독일어·스페인어·힌디어·베트남어·중국어로 된 질문에 영어로 답하는 태스크. 놀라운 결과:
| 언어 | GPT-J | GPT-3 (175B) | Toolformer |
|---|---|---|---|
| 스페인어 | 15.2 | 3.4 | 20.6 |
| 독일어 | 16.5 | 1.1 | 13.5 |
| 힌디어 | 1.3 | 0.1 | 1.4 |
| 베트남어 | 8.2 | 1.7 | 10.6 |
| 중국어 | 18.2 | 17.7 | 16.8 |
| 아랍어 | 8.2 | 0.1 | 3.7 |
GPT-3 (175B)가 거의 모든 언어에서 처참하다. 왜? 영어로 답하라고 지시했는데, GPT-3는 질문의 언어로 답하는 경우가 많았기 때문이다. Toolformer는 번역기를 사용해 질문을 영어로 변환한 뒤 답했다. 언어별로 63.8%~94.9%의 사례에서 번역 도구를 자발적으로 사용했다.
"오늘로부터 크리스마스까지 며칠 남았는가?" 같은 질문. GPT-3의 정확도는 0.8%, Toolformer는 27.3%. 34배 차이다. 54.8%의 사례에서 캘린더 도구를 사용했다.
| 모델 | WikiText PPL | CCNet PPL |
|---|---|---|
| GPT-J (원본) | 9.9 | 10.6 |
| Toolformer (도구 비활성) | 10.3 | 10.5 |
퍼플렉시티 차이가 미미하다. 도구 사용법을 배우면서도 원래의 언어 능력을 잃지 않았다. 이것이 Toolformer 설계의 두 번째 원칙 — "범용성 보존" — 이 달성된 증거다.
논문은 GPT-2 시리즈(124M, 355M, 775M, 1.6B)와 GPT-J(6.7B)에 걸쳐 모델 크기와 도구 사용 능력의 관계를 조사했다. 결과는 흥미롭다:
도구 사용 능력은 약 7.75억(775M) 파라미터에서 "발현(emerge)"한다.
124M, 355M 모델은 도구를 사용해도 성능이 거의 향상되지 않는다. 도구의 출력을 받아도 그것을 유의미하게 활용하는 능력이 없기 때문이다. 775M에서부터 도구 사용/미사용 간의 격차가 뚜렷해지고, 모델이 커질수록 그 격차는 더 벌어진다.
이것은 중요한 함의가 있다. 도구 사용은 "도구를 호출하는 능력"과 "도구 결과를 이해하는 능력" 두 가지를 동시에 요구한다. 충분히 크지 않은 모델은 결과를 받아도 그것이 왜 유용한지, 어떻게 맥락에 통합해야 하는지를 이해하지 못한다.
예외적으로 Wikipedia 검색은 더 작은 모델에서도 효과가 있었다 — 검색 결과가 이미 자연어 형태이므로, 활용 난이도가 상대적으로 낮기 때문으로 추측된다.
논문은 다섯 가지 한계를 명시적으로 인정한다. 이 정직함이 오히려 논문의 신뢰성을 높인다.
1. 도구 연쇄(chaining) 불가. 계산기 결과를 검색 쿼리에 넣는 것처럼, 한 도구의 출력을 다른 도구의 입력으로 사용할 수 없다. 각 도구의 API 호출이 독립적으로 생성되기 때문이다.
2. 상호작용 불가. 검색 결과가 마음에 들지 않아도 쿼리를 수정해서 다시 검색할 수 없다. "한 번 호출, 한 번 결과"가 끝이다.
3. 입력 표현에 민감. 같은 질문이라도 표현이 조금 달라지면 도구를 사용할지 말지의 결정이 바뀔 수 있다.
4. 데이터 비효율. 100만 건 이상의 문서를 처리해도 유용한 예시는 수천 건에 불과하다. (하지만 논문은 "반복 적용"을 해결책으로 제안한다.)
5. 비용 인식 부재. API 호출의 계산 비용을 고려하지 않는다. 간단한 질문에도 무거운 검색을 실행할 수 있다.
2023년 6월, OpenAI가 GPT-3.5/4에 Function Calling 기능을 추가했다. 모델이 자연어 대화 중에 JSON 형식으로 함수 호출을 생성하고, 결과를 받아 활용하는 것 — 이것은 Toolformer의 [API(input) → result] 형식의 산업적 표준화다.
2024년, Anthropic이 Claude에 Tool Use를, Google이 Gemini에 Function Declarations를 도입했다. 모든 주요 모델이 도구 사용을 핵심 기능으로 탑재한 것이다.
2024년 11월, Anthropic이 MCP(Model Context Protocol)를 발표했다. 2025년 3월에는 OpenAI, Google, Microsoft도 지원을 선언했다. MCP는 AI 모델과 외부 도구 사이의 연결을 표준화하는 프로토콜이다.
Toolformer는 5개의 하드코딩된 도구를 사용했다. MCP는 수천 개의 도구를 플러그앤플레이로 연결할 수 있게 한다. Toolformer의 비전이 프로토콜 수준에서 실현된 것이다.
Toolformer가 2023년에 인정한 다섯 가지 한계를, 2026년의 기술이 어떻게 극복했는지 정리하면:
| Toolformer의 한계 (2023) | 2026년의 해결 |
|---|---|
| 도구 연쇄 불가 | 에이전트 프레임워크 (LangChain, CrewAI)가 다단계 도구 사용 지원 |
| 상호작용 불가 | ReAct + 반복 루프로 검색 결과 불만족 시 재시도 가능 |
| 입력 표현에 민감 | 더 큰 모델과 강화학습 기반 파인튜닝으로 로버스트성 향상 |
| 데이터 비효율 | 합성 데이터 생성 기법 발전으로 대폭 개선 |
| 비용 인식 부재 | 라우팅 시스템이 쿼리 복잡도에 따라 적절한 도구/모델 선택 |
Toolformer의 가장 근본적인 기여는 기술적 세부사항이 아니라 패러다임의 전환이다:
"AI의 능력 = 모델 크기"라는 공식이 "AI의 능력 = 모델 크기 × 도구 접근성"으로 바뀌었다.
67억 파라미터 모델이 1,750억 모델을 이긴 것은, 도구가 파라미터를 대체할 수 있음을 증명했다. 모든 지식을 파라미터 안에 우겨넣을 필요가 없다. 필요할 때 적절한 도구를 쓰면 된다. 이것은 인간이 250만 년 전에 깨달은 것과 정확히 같은 통찰이다.
2026년 현재, Claude Code가 터미널 명령어를 실행하고, GPT-4가 코드 인터프리터를 돌리고, Gemini가 Google 검색을 하고, AI 에이전트가 수십 개의 API를 오케스트레이션하는 세상 — 이 모든 것의 학술적 출발점에 Toolformer가 있다.
Toolformer는 1,900회 이상 인용된, AI 도구 사용 분야의 사실상 기원 논문이다. 그 핵심 기여를 세 가지로 요약하면:
첫째, 자기지도 학습의 우아함. 도구 사용법을 가르치기 위해 수만 건의 인간 주석이 필요하다는 통념을 깼다. "퍼플렉시티가 줄어드는가?"라는 단일 기준으로 유용한 도구 사용을 자동으로 식별해냈다.
둘째, "작지만 도구를 쓰는 모델 > 거대하지만 맨손인 모델"의 증명. 6.7B가 175B를 이기는 결과는, AI 산업이 "파라미터 경쟁"에서 "도구 생태계 경쟁"으로 전환하는 데 결정적 근거가 되었다.
셋째, 실용적 아키텍처의 제시. 특수 토큰을 이용한 API 호출 삽입, 필터링 기반 데이터 증강, 추론 시 API 인터럽트 방식 — 이 설계 패턴은 이후 Function Calling, Tool Use, MCP의 기술적 토대가 되었다.
인간이 돌도끼를 쥔 순간 세계가 바뀌었듯, AI가 도구를 쥔 순간 AI의 세계가 바뀌었다. Toolformer는 그 순간을 기록한 논문이다.
참고 문헌