Agentic AI 논문 읽기: Toolformer — 언어 모델이 스스로 도구를 잡은 순간

논문 정보

• 제목: Toolformer: Language Models Can Teach Themselves to Use Tools
• 저자: Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom (Meta AI Research, Universitat Pompeu Fabra)
• 출판: NeurIPS 2023
• arXiv: 2302.04761

이 시리즈의 첫 번째 글에서 CoALA는 좌표계를 펼쳤다. 기억, 행동, 판단이라는 세 축 위에 에이전트를 올려놓는 지도다. 두 번째 글에서 ReAct는 그 지도 위에 처음으로 에이전트를 세웠다. 생각한 다음 행동하고, 결과를 보고 다시 생각하는 패턴이다. 세 번째 글에서 CoT는 시간을 거슬러 올라가 원점을 찾았다. LLM이 추론할 수 있다는 것 — 에이전트가 성립하기 위한 가장 근본적인 전제를 증명한 논문이었다.

네 번째 글에서는 다른 질문을 던진다. ReAct에서 에이전트는 위키피디아 API를 호출했다. 검색하고, 페이지를 탐색하고, 답을 제출했다. 하지만 그 능력이 어디서 왔는지 되짚어보면, 인간이 몇 개의 시연 궤적을 직접 작성해서 프롬프트에 넣어준 것이었다. "이 상황에서는 이 도구를 이렇게 쓴다"는 예시를 인간이 보여주니, 모델이 그 패턴을 따라 한 것이다. CoT도 마찬가지다. 풀이 과정이 담긴 예시를 인간이 프롬프트에 넣어줬다. 두 논문 모두, 도구 사용의 "무엇을"과 "어떻게를" 인간이 가르쳤다.

2023년 2월이다. ChatGPT가 출시된 지 3개월, GPT-4가 공개되기 한 달 전이다. Meta AI Research에서 하나의 질문에 답하는 논문이 나온다. 모델이 도구 사용법을 스스로 알아낼 수 있는가? 인간의 시연 없이, 어떤 도구를 언제 쓸지, 어떤 입력을 넣을지, 그 결과를 어떻게 활용할지를 자기 지도 학습만으로 배울 수 있는가? Toolformer는 이 질문에 "예"라고 답한 논문이다.

몸이 없는 지성 — 도구가 필요한 이유

LLM은 역설적인 존재다. 변호사 시험을 통과하고 시를 쓸 수 있지만, 7 × 8을 실수하고, 어제 무슨 일이 있었는지 모르고, 지금이 몇 월인지 알지 못한다. 지성은 있지만 몸이 없다. 파라미터에 압축된 세계 모델 안에 갇혀 있어서, 세계와 접촉하는 채널이 없다.

논문은 이 한계를 네 가지로 정리했다. 첫째, 최신 정보에 접근할 수 없어 사실을 환각한다. 학습 데이터의 마감일 이후의 세계는 존재하지 않는다. 둘째, 정밀한 수학 계산이 안 된다. "1,247 × 83"을 파라미터 연산으로 풀어야 하니 틀리는 것이 당연하다. 셋째, 저자원 언어를 잘 이해하지 못한다. 영어 중심으로 학습된 모델에게 스와힐리어 문서는 안개 속이다. 넷째, 시간의 흐름을 인식하지 못한다. "다음 주 목요일"이 언제인지 계산하려면 오늘이 며칠인지 알아야 하는데, 모델에게 "오늘"은 존재하지 않는다.

이 한계들에는 공통점이 있다. 모두 외부 도구가 있으면 즉시 해결된다는 것이다. 검색 엔진이 있으면 최신 정보를 가져올 수 있고, 계산기가 있으면 산술 오류가 사라지고, 번역기가 있으면 다국어를 처리할 수 있고, 달력이 있으면 시간을 인식할 수 있다. 문제는 도구의 부재가 아니라, 도구를 연결하는 방법이었다.

기존 접근법은 두 갈래였다. 하나는 대량의 인간 주석에 의존하는 방식이다. 어떤 상황에서 어떤 도구를 호출해야 하는지를 사람이 일일이 레이블링하고, 그 데이터로 모델을 훈련시킨다. 효과적이지만 확장하기 어렵다. 새로운 도구가 추가될 때마다 새로운 주석이 필요하다. 다른 하나는 도구 사용을 특정 과제에만 한정하는 방식이다. "수학 문제를 풀 때는 계산기를 쓰라"고 하드코딩하는 식이다. 이러면 모델의 범용성이 사라진다.

Toolformer는 이 두 가지를 모두 피하겠다고 선언한다. 인간 주석 없이 학습하고, 특정 과제에 묶이지 않고, 모델의 핵심 언어 능력을 훼손하지 않으면서 도구를 사용하겠다는 것이다.

스스로 가르치는 법 — 3단계 파이프라인

Toolformer의 핵심 아이디어를 한 문장으로 요약하면 이렇다. 도구를 호출했을 때 미래 토큰을 더 잘 예측할 수 있다면, 그 도구 호출은 유용한 것이다.

이 직관을 알고리즘으로 구현하는 과정이 3단계 파이프라인이다.

Step 1: API 호출 샘플링

대규모 텍스트 데이터셋의 각 문장에서, 모델에게 "여기에 API를 호출하고 싶은 충동이 드느냐?"고 묻는다. 구체적으로는, 각 위치에서 특수 토큰 <API>가 생성될 확률을 계산한다. 그 확률이 임계값 이상인 위치에서, 모델이 스스로 API 호출 후보를 생성한다. 어떤 API를 호출할지, 어떤 입력을 넣을지를 모델 자신이 결정한다. 필요한 것은 각 API의 사용법을 보여주는 소수의 예시뿐이다.

예를 들어, "The population of Tokyo is approximately 14 million"이라는 문장에서 "approximately" 앞의 위치에 높은 확률이 매겨지고, 모델이 [QA("population of Tokyo")]라는 API 호출을 생성하는 식이다.

Step 2: API 호출 실행

생성된 모든 API 호출을 실제로 실행한다. QA 시스템에 질문을 보내고, 계산기에 수식을 입력하고, 위키피디아에서 검색 결과를 받아온다. 이 단계는 단순하다 — 후보 호출을 모아서 배치로 실행하면 된다.

Step 3: API 호출 필터링

여기가 Toolformer의 핵심이다. 생성된 수백만 개의 API 호출 중 실제로 유용한 것만 골라내야 한다. 필터링 기준은 가중 교차 엔트로피 손실의 차이다.

두 가지 상황을 비교한다. L⁺는 API 호출과 그 결과가 텍스트에 삽입됐을 때의 손실 — 즉, API 결과를 본 상태에서 미래 토큰을 예측하는 난이도다. L⁻는 API가 없을 때의 손실 — 아무 도움 없이 미래 토큰을 예측하는 난이도다. 그 차이 L⁻ - L⁺가 임계값 τ_f 이상이면, 이 API 호출은 미래 토큰 예측을 실질적으로 도왔다는 뜻이다. 이 호출만 남기고 나머지는 버린다.

이 기준의 우아함은 인간의 판단이 전혀 개입하지 않는다는 데 있다. "이 상황에서 계산기를 쓰는 것이 적절한가?"를 사람이 판단하는 것이 아니라, "계산기를 썼더니 모델이 다음에 올 단어를 더 잘 맞추게 됐는가?"를 자동으로 측정한다. 언어 모델링이라는 모델의 본업을 잣대로 삼아, 도구의 유용성을 자기 지도적으로 판별하는 것이다.

비유하자면, 계산기가 도움이 되는 순간을 스스로 발견하는 학생과 같다. 선생님이 "여기서 계산기를 써라"고 알려주는 것이 아니라, 학생이 여러 문제에서 계산기를 시험 삼아 써보고, 실제로 답을 더 잘 맞힌 경우만 기억에 남기는 것이다.

파인튜닝: 필터링을 통과한 API 호출을 원본 텍스트에 삽입하여 증강 데이터셋을 만들고, 이 데이터로 모델을 파인튜닝한다. 결정적으로, 증강 데이터셋은 API 호출을 제외하면 원본과 정확히 같은 텍스트를 포함한다. 원래 학습할 내용에 API 호출이 자연스럽게 끼워진 형태이므로, 핵심 언어 모델링 능력이 보존된다.

추론: 파인튜닝이 끝나면, 모델은 텍스트를 생성하다가 스스로 <API> 토큰을 출력한다. 이 시점에서 디코딩을 잠시 멈추고, 해당 API를 실제로 호출하여 결과를 받아온 뒤, 그 결과를 텍스트에 삽입하고 다시 생성을 이어간다. 모델이 "여기서 도구를 써야겠다"고 스스로 판단하고, 실행하고, 결과를 통합하는 전체 흐름이 자동으로 작동한다.

다섯 개의 손가락 — Toolformer의 도구들

Toolformer가 도구에 부과하는 제약은 두 가지뿐이다. 입력과 출력이 텍스트 시퀀스로 표현 가능해야 하고, 사용 시연을 소수 확보할 수 있어야 한다. 이 조건을 충족하는 다섯 가지 도구를 탐구한다.

다섯 개의 도구가 다섯 개의 손가락과 같다. 각각은 특화되어 있지만, 함께 작동하면 모델의 손이 닿는 범위를 극적으로 넓힌다. QA 시스템은 모델이 "모르는 것"을 보완하고, 계산기는 "못 하는 것"을 보완하고, 위키피디아 검색은 "오래된 것"을 보완하고, 번역기는 "읽지 못하는 것"을 보완하고, 캘린더는 "인식하지 못하는 것"을 보완한다.

흥미로운 점은 QA 시스템과 위키피디아 검색의 역할 분화다. 둘 다 사실 정보를 가져오지만, QA 시스템은 정확한 답을 반환하고, 위키피디아 검색은 더 넓은 맥락을 반환한다. "도쿄의 인구가 몇 명인가?"에는 QA가, "도쿄에 대해 더 알고 싶다"에는 위키피디아가 적합하다. 모델은 이 미묘한 차이를 스스로 학습한다.

작은 모델이 거인을 넘다 — 벤치마크 결과

Toolformer는 GPT-J(6.7B 파라미터)를 기반으로 한다. 당시 기준으로도 대형 모델이 아니었다. GPT-3는 175B, OPT는 66B — Toolformer보다 10배에서 26배 큰 모델들이 비교 대상이다. 결과는 충격적이었다.

사실 완성 (LAMA)

6.7B 모델이 자신보다 26배 큰 GPT-3를 모든 항목에서 능가했다. 98.1%의 예시에서 QA 도구를 자율적으로 호출했다. 모델이 "이 문장의 사실적 정확성을 확인해야 한다"고 스스로 판단한 것이다.

수학 벤치마크

여기서의 격차는 더 극적이다. Toolformer는 GPT-3보다 수학 문제에서 2~3배 높은 정확도를 보인다. 97.9%의 예시에서 계산기를 호출했다. 산술 능력이 본질적으로 부족한 언어 모델에게, 외부 계산기라는 의수를 달아준 효과다.

이 결과가 의미하는 바는 명확하다. 규모만이 능력의 경로가 아니다. 175B 파라미터를 쌓아서 산술을 조금 더 잘하게 만드는 대신, 6.7B 모델에 계산기를 쥐어주면 문제가 해결된다. 크기의 게임이 아니라 증강의 게임이다.

스케일링 법칙: 도구를 잡을 수 있는 최소 크기

논문은 GPT-2 패밀리(124M~1.6B)와 GPT-J(6.7B)에 Toolformer를 적용하여, 도구 사용 능력이 어느 규모에서 출현하는지를 측정했다. 결과는 약 775M 파라미터에서 도구 사용 능력이 나타나기 시작한다는 것이다. 그 아래에서는 도구를 사용해도 성능이 나아지지 않는다.

이것을 세 번째 글에서 다룬 CoT의 스케일링 법칙과 비교하면 흥미롭다. CoT는 약 100B(1000억) 파라미터 이상에서야 추론 능력이 출현했다. Toolformer의 도구 사용 능력은 그 문턱의 130분의 1 지점에서 나타난다. 같은 문제 — 예를 들어 산술 — 를 해결하는 데 두 가지 경로가 있는 셈이다. 하나는 모델을 충분히 크게 키워서 내부적으로 추론하게 하는 것(CoT의 경로), 다른 하나는 작은 모델에게 도구를 쥐어주는 것(Toolformer의 경로)이다.

언어 모델링 성능 보존

마지막으로 결정적인 검증이 있다. 도구 사용 학습이 모델의 핵심 능력을 훼손하지 않았는가? WikiText와 CCNet에서 퍼플렉시티를 측정한 결과, API 호출이 증강된 데이터로 파인튜닝한 후에도 퍼플렉시티가 증가하지 않았다. 이것이 가능한 이유는, 증강 데이터셋이 API 호출을 제외하면 원본 데이터셋과 정확히 같은 텍스트를 포함하기 때문이다. 모델은 원래 배울 것을 그대로 배우면서, 추가로 도구를 사용하는 법을 익힌 것이다.

아직 열리지 않은 문 — Toolformer의 한계

논문은 효과를 보고하는 데 그치지 않고, 다섯 가지 한계를 정직하게 밝힌다.

첫째, 도구 체이닝이 불가능하다. 한 도구의 출력을 다른 도구의 입력으로 넘길 수 없다. "도쿄의 인구를 검색한 뒤, 그 숫자를 계산기에 넣어 서울 인구와 비교하라"는 흐름이 불가능하다. 각 API 호출이 텍스트 내 독립된 위치에서 독립적으로 샘플링되기 때문이다.

둘째, 상호작용이 불가능하다. 검색 결과가 부적절할 때 쿼리를 수정하거나, 여러 결과를 탐색하는 루프가 없다. 한 번 호출하고, 그 결과를 받아들이는 것이 전부다.

셋째, 입력의 문구에 민감하다. 같은 내용이라도 표현이 바뀌면 API 호출 여부가 달라질 수 있다.

넷째, 비용을 고려하지 않는다. 모든 API 호출을 동등하게 취급한다. 현실에서 검색 API는 비싸고 캘린더 API는 싸다. 이 차이를 호출 결정에 반영하는 메커니즘이 없다.

다섯째, 샘플 효율이 낮다. 100만 개 이상의 문서를 처리하여 수천 개의 유용한 API 호출만을 건져내는 과정은 계산 비용이 크다.

이 한계들을 두 번째 글에서 다룬 ReAct와 나란히 놓으면, 두 논문의 강점과 약점이 정확히 상보적임이 드러난다. ReAct는 사고-행동-관찰 사이클을 반복하므로 도구 체이닝과 상호작용이 자연스럽다. 검색 결과가 부적절하면 "이건 내가 원한 게 아니다, 다른 검색어를 시도해보자"라고 생각하고 다시 행동한다. 하지만 ReAct의 도구 사용 능력은 인간이 작성한 몇 개의 시연 궤적에 의존한다.

반대로 Toolformer는 도구 사용법을 자기 지도적으로 학습하지만, 한 번의 호출로 끝난다. 추론 트레이스도 없고, 결과를 보고 전략을 수정하는 루프도 없다. ReAct가 "행동 사이에 생각할 시간을 주는" 에이전트라면, Toolformer는 "생각 없이 도구를 쓰는, 그러나 언제 쓸지를 스스로 아는" 모델이다. 둘 다 도구를 사용하지만, 도구를 사용하는 방식이 근본적으로 다르다.

CoALA의 좌표계 위에 놓은 Toolformer

이 시리즈의 매 글에서 해온 것처럼, CoALA의 좌표계 위에 Toolformer를 올려놓는다.

CoT, ReAct와 비교하면 Toolformer가 채운 빈칸이 선명하게 드러난다.

CoT는 모든 칸이 거의 비어 있었다. 추론만 있었고, 외부 행동도, 장기 기억도, 평가도 없었다. ReAct는 바깥 행동(위키피디아 API)과 명시적 추론 트레이스를 추가했지만, 장기 기억은 여전히 없었고, 도구 사용 능력은 인간이 작성한 프롬프트 예시에서 왔다 — 명시적 절차 기억이되, 인간이 직접 쓴 것이다.

Toolformer가 새롭게 채운 셀은 학습된 절차 기억이다. CoALA가 정의한 절차 기억의 두 층 — 암묵적(LLM 가중치)과 명시적(에이전트 코드) — 에서, Toolformer는 파인튜닝을 통해 암묵적 절차 기억에 도구 사용 패턴을 새겨 넣었다. 인간이 코드로 "이때 계산기를 호출하라"고 명시하지 않아도, 모델의 가중치가 "여기서 계산기를 호출하면 도움이 된다"를 내재화한 것이다. 이것은 CoT(절차 기억 변화 없음)에도, ReAct(인간이 명시적으로 주입한 절차 기억)에도 없던 속성이다.

하지만 대가도 있다. ReAct에는 있던 명시적 추론 트레이스가 Toolformer에는 없다. ReAct의 에이전트는 "이 결과가 부적절하니 다시 검색해야겠다"고 사고를 드러내며, 인간이 이 추론을 읽고 두 줄을 고치면 실패가 성공으로 전환됐다. Toolformer는 조용히 도구를 쓴다. 왜 여기서 도구를 썼는지, 결과가 맞는지를 설명하지 않는다. 디버깅과 인간 정렬(alignment)의 측면에서, Toolformer는 ReAct보다 후퇴한 셈이다.

마무리 — 도구를 잡는다는 것의 의미

Toolformer의 전부를 한 문장으로 줄이면 이렇다: "어떤 도구를 언제 쓸지, 모델 스스로 알아내게 하라."

생물학에서 도구 사용은 종종 진화적 전환점으로 거론된다. 침팬지도 나뭇가지로 개미를 낚지만, 상황에 따라 다른 도구를 선택하고, 새로운 도구의 용도를 발견하는 것은 인간 고유의 능력으로 여겨져 왔다. Toolformer는 LLM에서 이 전환의 초기 형태를 보여준다. 모델이 "여기서 계산기를 쓰면 된다"를 가르침 없이 발견하는 것 — 도구를 받아 쓰는 것과 도구를 선택하는 것 사이의 차이다.

3년이 지난 지금, Toolformer가 제안한 기법 자체는 대체되었다. 오늘날의 Claude, GPT-4, Gemini는 네이티브 함수 호출(function calling)을 지원한다. 별도의 파인튜닝 없이, 모델이 수백 개의 도구 중에서 적절한 것을 골라 호출한다. 이 능력은 훈련 과정 자체에 내장되어 있다. 하지만 그 훈련의 근저에 흐르는 원리 — 모델이 스스로 도구의 유용성을 판단하고, 언제 어떤 도구를 써야 하는지를 자율적으로 결정한다는 것 — 는 Toolformer가 처음 입증한 것이다.

시리즈의 흐름을 되짚어보자. CoT가 추론을 증명했고, ReAct가 추론에 행동을 엮었고, Toolformer는 모델이 행동을 스스로 학습할 수 있음을 보였다. 세 편의 논문이 그린 궤적은 이렇다 — 생각할 수 있다, 생각하면서 행동할 수 있다, 행동을 스스로 배울 수 있다. 다음 질문은 자연스럽게 이어진다. 이 모든 것을 하나의 시스템 안에서 어떻게 조율하는가?

기법은 대체되지만, 좋은 원리는 표준이 된다. Toolformer는 기법에서 출발해, 표준이 되었다.

이 글은 "Agentic AI 논문 읽기" 시리즈의 네 번째 글입니다.