Toolformer는 AI가 도구를 쓴다는 말을 조금 더 현실적인 문제로 끌어온 논문입니다. 핵심은 단순합니다. 모델이 계산기나 검색기를 쓸 수 있게 만드는 데서 멈추지 않고, 언제 써야 하는지도 배우게 하자는 것입니다.
좋은 도구가 옆에 있어도 필요 없는 순간마다 꺼내 들면 느리고 산만해집니다. 반대로 꼭 확인해야 할 값을 기억으로 때우면 문장은 그럴듯해도 답은 틀릴 수 있습니다. Toolformer는 바로 이 판단을 학습 문제로 다룹니다.
왜 Toolformer가 나왔을까
큰 언어 모델은 문장을 자연스럽게 이어 가는 데 강하지만, 계산·최신 정보 확인·날짜 계산·정확한 번역·문서 조회처럼 바깥 도구가 더 잘하는 일도 분명합니다. Toolformer는 여기서 한 가지 실용적인 질문을 던집니다. 모델이 기억으로 답해야 할 때와, 도구를 먼저 써야 할 때를 스스로 구분하게 만들 수 없을까?
- 37 × 48 같은 계산
- 오늘 기준 최신 정보 확인
- 특정 단어의 정확한 번역
- 며칠 뒤 날짜 계산
- 문서나 데이터베이스에서 값 찾기
사람도 비슷합니다. 재귀 함수 개념은 바로 설명할 수 있지만, 다음 달 둘째 화요일 날짜나 현재 환율은 확인부터 하는 편이 안전합니다.
Toolformer를 한 문장으로 보면
Toolformer는 언어 모델이 텍스트를 생성하는 과정에서 도구 호출이 필요한 위치를 스스로 찾고, 실제로 도움이 되는 호출만 학습하는 방식입니다. 사람이 모든 위치를 손으로 라벨링하는 대신, 소수의 예시를 발판 삼아 모델이 도구가 유용한 순간을 찾아가게 합니다.
- 도구를 부를 수 있다
- 호출 시점을 스스로 찾는다
- 도움이 되는 호출만 남긴다
이 점 때문에 Toolformer는 단순한 tool calling 인터페이스보다 한 걸음 더 들어갑니다. 도구 사용 판단 자체를 학습 대상으로 본다는 점이 핵심입니다.
작동 방식
- 각 도구를 어떻게 부르는지 예시를 조금 준다
- 모델이 텍스트 안에서 도구를 넣어 볼 만한 위치를 찾는다
- 실제로 그 도구를 실행해 본다
- 그 결과가 다음 문장을 더 잘 예측하게 만들면 남긴다
- 그렇게 남은 호출이 들어간 데이터로 다시 학습한다
중요한 것은 후보를 많이 만드는 일이 아니라, 실제로 도움이 되는 호출만 고르는 과정입니다. 계산이나 검색을 했더니 뒤 문장이 더 정확해지면 남기고, 별 이득이 없으면 버립니다.
사람 식으로 바꾸면 결국 이런 질문에 가깝습니다. 지금 이 순간의 도구 호출이, 다음 말을 더 정확하게 이어 가는 데 실제로 도움이 되는가?
도구를 써야 하는 순간
Toolformer를 이해할 때 가장 중요한 부분입니다. 도구를 많이 쓰는 모델이 좋은 모델이라는 뜻이 아닙니다. 도구를 안 써도 되는 질문과, 도구를 써야 하는 질문을 가르는 감각이 핵심입니다.
바로 답해도 되는 질문
- 배열과 연결 리스트 차이를 설명해줘
- HTTP와 HTTPS 차이를 쉽게 설명해줘
- 재귀 함수 예제를 보여줘
- 이 문장을 더 자연스럽게 고쳐줘
- 정렬 알고리즘을 왜 배우는지 설명해줘
이런 질문은 개념 설명, 요약, 표현 개선에 가깝습니다. 최신 사실 확인이나 외부 값 조회가 꼭 필요하지 않다면 모델이 직접 답할 수 있습니다. 예를 들어 배열과 연결 리스트 차이를 묻는 질문에 검색부터 하는 시스템은 오히려 답이 느려집니다.
도구를 먼저 써야 하는 질문
- 1400명 중 400명이면 합격률이 몇 퍼센트야? → 계산기
- 다음 주 수요일에서 90일 뒤 날짜는? → 캘린더
- 오늘 발표된 iOS 정책을 확인해줘 → 검색
- 이 저장소 최신 README 기준 설치 명령을 확인해줘 → 문서 조회
- 이 API 응답 JSON에서 user_id만 추려줘 → 파싱 도구
- 스페인어 tortuga가 무슨 뜻이야? → 번역 도구
- 현재 환율 기준으로 120달러가 대략 얼마야? → 환율 조회 + 계산
여기서 중요한 포인트는 하나입니다. 문장을 잘 만드는 능력과, 확인이 필요한 값을 정확히 다루는 능력은 다른 문제라는 점입니다. 숫자 문제는 모델이 감으로 답할 수도 있지만, 계산기 한 번이면 끝나는 일을 굳이 감으로 처리할 이유는 없습니다.
논문 속 도구를 지금 기준으로 보면
논문 초록 기준으로 Toolformer는 calculator, question answering system, search engine, translation system, calendar 같은 도구를 함께 다룹니다. 오늘 기준으로 보면 AI 도구 사용의 기본 축이 거의 다 들어 있는 셈입니다.
계산기
합격률 계산, 부가세 포함 가격 계산, API 사용량 합산, CSV 평균값 계산처럼 숫자가 들어가는 순간에는 감보다 계산기가 낫습니다. 예를 들어 이번 달 요청 수가 82,341건이고 지난달이 71,908건이라면, 증가율 계산은 설명력이 아니라 계산 정확도가 핵심입니다.
검색
특정 라이브러리의 최신 설치 방법, 공식 문서의 deprecated 여부, 정책 변경 내용, 릴리스 노트 확인처럼 최신성과 출처가 중요한 경우에는 검색이 안전합니다. 기억으로 답하는 순간 오래된 정보가 섞일 수 있기 때문입니다.
캘린더
이번 달 마지막 영업일, 오늘부터 14일 뒤, 다음 분기 시작일처럼 날짜 계산은 설명보다 정확한 값이 중요합니다. 예를 들어 마지막 금요일에 점검 공지를 올려야 한다면, 문장 작성보다 날짜 계산이 먼저입니다.
번역
일반 단어 뜻 찾기, UI 문구 번역, 개발 문서 문장 옮기기, 영어 에러 메시지 해설처럼 문맥이 중요할 때 번역 도구의 도움이 커집니다. 예를 들어 deprecated는 문맥에 따라 단순히 폐기됨보다 더 이상 권장되지 않음이 자연스러울 수 있습니다.
질문응답 시스템
사내 위키에서 휴가 규정 찾기, 제품 문서에서 rate limit 규칙 찾기, 논문 본문에서 특정 실험 설정 찾기처럼 긴 문서에서 값을 꺼내는 작업을 떠올리면 이해가 쉽습니다. 즉, 모델이 전부 기억하고 답한다기보다 필요한 문서를 먼저 읽고 그 안에서 답을 꺼내 오는 구조입니다.
Toolformer의 핵심 포인트
중요한 것은 문장 전체를 도구에 맡기지 않고, 필요한 순간에 필요한 부분만 도구를 부른다는 점입니다. 도구를 남발하면 느리고 비싸지며, 너무 아끼면 그럴듯한 오답이 늘어납니다.
- 개념 설명까지 매번 검색하는 시스템 → 불필요하게 느림
- 최신 버전 정보를 기억으로 답하는 시스템 → 자신감 있는 오답 위험
- 간단한 문자열 정리에도 외부 API를 매번 호출하는 시스템 → 비용 낭비
- 숫자 계산을 말로 때우는 시스템 → 작은 오차가 누적됨
실제로 코딩 에이전트를 쓸 때도 비슷합니다. 함수 이름 하나 설명하는 데 파일 전체를 매번 뒤지면 느려지고, 반대로 실패 로그도 안 보고 원인을 단정하면 헛다리를 짚게 됩니다.
후보를 고르는 방식
모델은 텍스트를 읽으면서 여기쯤 계산기나 검색을 넣으면 뒤 문장을 더 잘 이어 갈 수 있을지 후보를 만듭니다. 그리고 실제로 도구를 실행해 보고, 그 결과를 넣은 문장이 다음 토큰 예측에 도움이 되는지 비교합니다.
- 1400명 중 400명이 통과했으므로 합격률은 … → 계산기 후보
- tortuga는 스페인어로 … → 번역 후보
- 특정 기관은 어느 단체가 발행하는가 … → 질문응답 시스템 후보
여기서 좋은 점은 사람이 모든 위치를 손으로 표시하지 않아도 된다는 것, 그리고 쓸모 있는 호출만 남기는 방향이라는 점입니다.
ReAct와의 차이
Toolformer와 ReAct는 둘 다 도구 사용을 다루지만 초점은 다릅니다. Toolformer는 도구 호출이 필요한 순간을 어떻게 학습할 것인가에 더 가깝고, ReAct는 생각-행동-관찰 루프를 어떻게 이어 갈 것인가에 더 가깝습니다.
- Toolformer: 지금 검색할까, 계산할까, 그냥 답할까를 배우는 쪽
- ReAct: 검색 결과를 보고 다음 행동을 어떻게 정할까를 운영하는 쪽
예를 들어 사용자가 버그 원인을 찾아 달라고 했을 때, Toolformer식 관점은 먼저 로그 읽기나 코드 조회가 필요한 순간을 잘 고르는 문제에 가깝습니다. ReAct식 관점은 로그를 읽고, 가설을 세우고, 다시 명령을 실행하고, 그 결과를 보고 다음 행동을 정하는 루프에 가깝습니다. 관련 글인 ReAct 논문 쉽게 이해하기를 같이 보면 차이가 더 또렷해집니다.
오늘의 에이전트와 연결되는 부분
지금 시스템에는 function calling 스키마, MCP 같은 연결 규약, 승인 단계, 권한 정책, 메모리, planner와 executor 분리, 실패 복구 같은 층이 더 붙습니다. 그래도 밑바닥 질문은 비슷합니다. 지금은 그냥 답해도 되는가, 검색이 필요한가, 파일을 읽어야 하는가, 계산을 도구로 넘겨야 하는가 같은 판단입니다.
- 도구를 너무 안 써서 근거 없는 답을 한다
- 도구를 너무 많이 써서 느리고 비싸고 산만해진다
그래서 Toolformer는 지금의 coding agent나 search agent를 볼 때도 여전히 참고할 만합니다. 관련해서 MCP란 무엇인가, Claude Code, Codex, Gemini CLI 비교를 함께 보면 오늘의 구조와 더 잘 연결됩니다.
실무 예시
테스트 실패 원인 찾기
코딩 에이전트가 ‘테스트가 깨졌는데 원인을 찾아줘’라는 요청을 받았다고 해보겠습니다. 더 나은 시스템은 바로 단정하지 않고, 먼저 테스트 로그를 읽어야 하나, 실패한 테스트 파일을 열어야 하나, 최근 변경 파일을 확인해야 하나, 재현 실행이 필요한가를 판단합니다.
이런 판단이 바로 도구 사용 판단입니다. 로그 읽기, 파일 열기, 검색, 실행, diff 확인이 필요하다면 도구를 써야 하고, 반대로 이미 단서가 충분하면 불필요한 연쇄 호출은 줄이는 편이 낫습니다.
API 문서 요약 요청
‘이 결제 API 문서를 읽고 핵심만 정리해줘’ 같은 요청에서는 문서 조회 도구가 거의 필수입니다. 문서를 읽는 일은 도구가 맡고, 차이점과 핵심을 정리하는 일은 모델이 맡는 식으로 역할이 나뉩니다. 예를 들어 인증 방식, 필수 헤더, rate limit, 오류 코드만 추려 온 뒤 개발자가 처음 붙일 때 주의할 점을 자연어로 정리하는 흐름을 떠올리면 됩니다.
일정 계산과 등록 요청
‘다음 달 둘째 화요일 오전 10시에 알림을 잡아줘’라면 날짜 계산에는 캘린더 도구가 필요하고, 실제 등록은 권한과 승인 조건을 따져야 합니다. 이 예시는 Toolformer 위에 승인과 권한 층이 왜 필요한지도 잘 보여줍니다.
번역 요청
짧은 에러 메시지는 모델이 바로 풀어 설명할 수도 있습니다. 예를 들어 Connection reset by peer를 한국어로 자연스럽게 풀어 주는 일은 어렵지 않습니다. 하지만 법률이나 의료 문서처럼 오역 비용이 큰 문맥에서는 전문 번역 도구나 원문 조회가 더 안전합니다.
강점
- 사람이 모든 호출 위치를 손으로 라벨링하지 않아도 된다
- 실제로 도움이 되는 호출만 남기려는 방향이 분명하다
- 계산기 하나가 아니라 검색, 번역, 질문응답, 캘린더처럼 여러 도구를 함께 다룬다
- 모델 크기만 키우는 길 말고 필요한 순간에 외부 도구를 잘 빌리는 길도 보여준다
이 마지막 메시지는 지금도 중요합니다. 확인이 필요한 순간에는 바깥 능력을 정확히 호출하는 편이 더 실용적일 수 있기 때문입니다.
한계
Toolformer가 오늘의 모든 에이전트 문제를 해결해 주는 것은 아닙니다. 승인 흐름, 권한 분리, 장기 메모리, 실패 복구, 감사 로그 같은 요소는 별도 문제입니다. 또 도구 호출이 항상 좋은 것도 아닙니다. 부정확한 검색 결과나 품질 낮은 응답은 오히려 문맥을 흐릴 수 있습니다.
그리고 논문의 필터링 기준은 기본적으로 다음 토큰 예측을 더 잘하게 만드는지에 맞춰져 있습니다. 이것이 언제나 사람 기준의 가장 바람직한 도구 사용과 완전히 같다고 보기는 어렵습니다.
지금 읽어둘 이유
Toolformer는 도구 사용을 단순 기능 연결이 아니라 학습 문제로 본다는 점에서 지금도 유효합니다. ReAct, function calling, search agent, coding agent를 볼 때도 좋은 기준점을 줍니다.
- 이 시스템은 검색이 꼭 필요할 때만 검색하나
- 계산해야 할 숫자를 말로 얼버무리지 않나
- 문서를 읽고 답하는가, 아니면 기억으로 때우는가
- 일정 등록이나 파일 수정처럼 위험한 작업은 승인과 분리돼 있나
도구를 쓸 줄 아는 것과 도구를 적절한 순간에 쓸 줄 아는 것은 전혀 다른 문제입니다. 이 차이를 이해하면 요즘 제품을 보는 눈도 달라집니다.
정리
Toolformer를 한 문장으로 정리하면 이렇습니다. AI가 도구를 쓸 수 있게 하자는 데서 끝나지 않고, 언제 도구를 써야 하는지까지 배우게 하자. 이 아이디어는 지금도 낡지 않았습니다. 오히려 AI가 검색, 계산, 문서 조회, 코드 실행, 일정 처리까지 맡으려는 시대에는 더 중요해졌습니다.
도구를 많이 붙이는 것보다, 언제 직접 답하고 언제 확인해야 하는지를 잘 가르는 쪽이 훨씬 중요하기 때문입니다.
관련해서 함께 보면 좋은 글은 ReAct 논문 쉽게 이해하기, MCP란 무엇인가, Claude Code, Codex, Gemini CLI 비교입니다.
주요 원문 출처는 arXiv Toolformer 논문, OpenReview, NeurIPS abstract, 논문 미러 텍스트, ReAct 프로젝트 사이트입니다.
