Toolformer 이후 논문 흐름을 한 번에 이해하려면, 먼저 질문을 바꿔야 합니다. 중요한 것은 AI가 도구를 쓸 수 있느냐가 아니라, 언제 어떤 도구를 어떤 구조로 써야 덜 틀리고 더 믿을 만해지는가입니다.
Toolformer는 이 문제를 꽤 일찍 정확하게 찔렀습니다. 언어 모델 옆에 계산기나 검색기를 붙이는 데서 끝내지 않고, 도구 호출 시점 자체를 학습 대상으로 올렸기 때문입니다.
하지만 그 다음 흐름은 Toolformer의 복제본이 아니었습니다. 후속 논문들은 도구 사용 문제를 더 넓게 쪼갰습니다. 어떤 논문은 reasoning과 action의 루프를 다뤘고, 어떤 논문은 여러 모델을 고르는 controller 구조를 밀었고, 또 어떤 논문은 자주 바뀌는 API 문서를 어떻게 따라갈지를 더 중요하게 봤습니다.
- Toolformer가 처음 정확히 무엇을 바꿨는가
- 그 다음 논문들은 무엇을 새로 해결하려 했는가
- 지금 agent를 만들 때 여전히 어려운 지점은 무엇인가
Toolformer 이후 논문 흐름의 출발점
Toolformer의 핵심은 단순합니다. 논문 초록과 OpenReview 설명 기준으로, 모델이 어떤 API를 호출할지, 언제 호출할지, 어떤 인자를 넣을지, 그리고 결과를 이후 토큰 예측에 어떻게 반영할지를 self-supervised 방식으로 학습하게 만들겠다는 구상입니다.
여기서 중요한 변화는 도구 연결에서 도구 사용 판단으로 관심이 이동했다는 점입니다. 이전에도 외부 도구를 붙일 수는 있었지만, Toolformer는 텍스트를 이어 가는 도중 어느 위치에서 도구 호출이 실제로 도움이 되는지를 스스로 찾게 만들려 했습니다.
- 계산이 필요하면 계산기를 부른다
- 최신 사실이 필요하면 검색을 부른다
- 날짜 계산이 필요하면 캘린더를 부른다
- 그렇지 않으면 괜히 도구를 열지 않는다
이 감각은 지금 봐도 낡지 않았습니다. 오히려 오늘의 agent 시스템이 느려지거나 불안정해지는 가장 흔한 이유를 미리 건드린 셈입니다. 도구를 많이 연결했다고 좋은 시스템이 되지 않는다는 점입니다.
질문이 커졌다
Toolformer 이후 흐름에서 가장 눈에 띄는 변화는, 문제의 단위가 API 호출 한 번에서 실행 루프 전체로 커졌다는 점입니다. Toolformer가 묻던 질문은 지금 여기서 도구를 부를까, 어떤 인자를 넣을까, 그 결과가 다음 예측에 도움이 될까에 가까웠습니다.
후속 논문들은 여기에 더 큰 질문을 붙였습니다. 먼저 생각을 적고 행동해야 하는가, 여러 도구나 여러 모델 중 무엇을 고를 것인가, 설명 문서가 바뀌면 어떻게 따라갈 것인가, 여러 단계 실행 중 실수를 어떻게 줄일 것인가입니다. 즉 초점이 호출 시점에서 실행 구조로 넓어졌습니다.
ReAct가 더한 것
ReAct는 Toolformer와 같은 문제를 그대로 잇기보다, reasoning과 acting을 교차시키는 형식을 전면에 세웠습니다. 논문 초록 기준으로 ReAct는 reasoning traces와 task-specific actions를 interleaved manner로 생성해, 외부 환경과 상호작용하면서 더 해석 가능하고 신뢰할 수 있는 trajectory를 만들 수 있다고 설명합니다.
여기서 달라진 점은 모델의 내부 판단보다 루프의 가시성이 훨씬 중요해졌다는 점입니다. Toolformer가 지금 도구를 부를까에 가깝다면, ReAct는 생각하고, 행동하고, 관찰한 뒤, 다시 다음 행동을 고를까에 가깝습니다.
- Toolformer: 호출 시점과 인자 선택을 학습한다
- ReAct: 생각-행동-관찰 루프를 설계한다
검색 한 번으로 끝나는 질문이라면 Toolformer식 관점이 잘 맞습니다. 반대로 버그 조사, 문서 탐색, 웹 상호작용처럼 여러 단계가 필요한 일은 ReAct식 루프가 훨씬 직접적입니다. 그래서 Toolformer 이후 흐름은 단순히 더 똑똑한 tool calling으로 간 것이 아니라, 도구 사용을 장면별 호출이 아니라 상태를 가진 실행 과정으로 보기 시작했다고 보는 편이 더 정확합니다.
HuggingGPT가 넓힌 것
HuggingGPT는 도구 사용 문제를 한 단계 더 넓혔습니다. 논문 초록에 따르면 이 시스템은 LLM을 controller로 두고, 사용자 요청을 받으면 task planning을 하고, 공개된 모델 설명을 바탕으로 적절한 모델을 고르고, 각 subtask를 실행한 뒤 결과를 요약합니다.
여기서 핵심은 도구가 이제 계산기나 검색기 한두 개가 아니라는 점입니다. 도구 집합이 커지고, 모달리티도 텍스트 밖으로 넓어집니다. 즉 문제는 언제 호출할까에서 끝나지 않고, 무엇을 위임할까로 이동합니다.
- planner가 해야 할 일
- executor가 해야 할 일
- 각 도구 설명을 어떤 형식으로 읽힐지
- 결과를 다시 모아 최종 응답으로 합칠지
Toolformer가 한 번의 적절한 호출을 배우는 쪽이었다면, HuggingGPT는 여러 작업을 분해하고 재조합하는 orchestration 쪽으로 무게를 옮깁니다.
Gorilla가 바꾼 초점
Gorilla는 또 다른 현실 문제를 더 분명하게 드러냈습니다. OpenReview 초록 기준으로 Gorilla는 자주 바뀌는 도구 집합과 API 문서에 적응하기 위해 retriever-aware training과 문서 검색 결합을 강조합니다. 즉 모델이 API를 안다고 가정하지 않고, 그때그때 문서를 읽고 더 정확히 호출하게 만들자는 쪽입니다.
이 지점에서 Toolformer와의 차이가 선명해집니다. Toolformer는 소수의 API 예시를 발판으로 self-supervised 학습을 진행합니다. 반면 Gorilla는 대규모 API와 문서 변경을 더 현실적인 문제로 둡니다.
- Toolformer: 호출이 유용한 순간을 배운다
- ReAct: 여러 단계 루프를 다룬다
- HuggingGPT: 여러 도구와 모델을 조율한다
- Gorilla: 바뀌는 문서와 큰 도구 집합에 grounding한다
이 네 축을 같이 보면, 도구 사용 연구가 점점 더 실제 시스템 문제로 내려왔다는 흐름이 보입니다.
바뀐 것, 안 바뀐 것
바뀐 것
- 도구 사용의 범위가 넓어졌다. 계산기와 검색을 넘어 웹 탐색, 다단계 QA, 멀티모달 모델 선택, 대규모 API 호출까지 커졌다.
- 성공 기준이 바뀌었다. 호출이 도움이 되느냐뿐 아니라 trajectory 해석 가능성, planner 안정성, 문서 변경 대응력, hallucination 완화가 중요해졌다.
- 시스템 경계가 넓어졌다. 이제는 모델 하나보다 planner, retriever, executor, verifier가 함께 얼마나 안정적으로 움직이는지가 더 중요하다.
안 바뀐 것
- 도구를 많이 쓴다고 좋은 것이 아니다. 쓸데없는 호출은 느리고 비싸며 잘못된 결과를 더 자신 있게 포장할 수도 있다.
- 도구 출력도 틀릴 수 있다. 검색 결과, API 문서, 외부 응답 자체가 부정확할 수 있다.
- 긴 루프는 쉽게 무너진다. 작은 오류가 여러 단계에서 누적되면 전체 실패로 커진다.
- 권한과 승인 문제는 별도 층이다. 파일 삭제, 결제, 배포 같은 행동은 별도의 정책과 보호 장치가 필요하다.
설계 함의
1. tool calling만으로는 부족하다
도구 스키마를 예쁘게 정의하는 것만으로는 부족합니다. 어떤 요청은 한 번의 함수 호출이면 되지만, 어떤 요청은 검색과 검증, 요약과 재시도가 필요합니다. 그래서 시스템은 최소한 호출 판단, 계획, 실행, 검증을 나눠 생각하는 편이 안전합니다.
2. 문서 grounding은 기본에 가깝다
Gorilla가 강조한 지점은 지금 더 중요해졌습니다. 도구가 자주 바뀌는 환경에서는 모델의 파라미터 기억보다, 최신 문서를 끌어와 현재 스키마에 맞게 호출하는 편이 안전합니다. 실무에서 자주 터지는 문제도 존재하지 않는 인자 이름을 만들어 내거나, 예전 버전 옵션을 자신 있게 쓰는 일입니다.
3. 루프는 짧고 보여야 한다
ReAct 계열의 장점은 실행 과정을 사람이 추적하기 쉽다는 점입니다. 어느 단계에서 잘못됐는지 보여야 수정할 수 있기 때문입니다. 가능하면 긴 블랙박스 실행보다, 짧은 단계와 명확한 관찰 지점을 두는 편이 좋습니다.
4. 승인과 복구는 따로 설계해야 한다
도구 사용 논문을 읽다 보면 모델이 점점 자율적으로 보이지만, 제품에서는 자율성보다 통제가 먼저입니다. 특히 외부 상태를 바꾸는 행동은 read와 write를 구분하고, 위험한 write 앞에는 승인 규칙을 두고, 실패 시 중단 정책과 실행 로그를 따로 설계해야 합니다. 이 층은 Toolformer 이후 흐름과 연결되지만 그대로 얻어지는 것은 아닙니다.
한 장 요약
- Toolformer는 도구 호출 판단을 학습 문제로 만들었다.
- ReAct는 도구 사용을 reasoning-action loop로 넓혔다.
- HuggingGPT는 여러 모델을 고르는 controller 구조를 밀었다.
- Gorilla는 최신 문서와 대규모 API grounding 문제를 전면에 세웠다.
그리고 끝까지 남은 질문도 분명합니다. 언제 도구를 써야 하는가, 어떤 도구를 믿을 수 있는가, 여러 단계 실행을 어떻게 안정화할 것인가, 승인과 실패 복구를 어디에 둘 것인가입니다. 결국 Toolformer 다음에 달라진 것은 도구 사용이 더 큰 시스템 문제가 되었다는 점입니다. 반대로 아직도 안 달라진 것은, 좋은 agent는 도구를 많이 쓰는 agent가 아니라, 필요한 순간에만 올바른 구조로 도구를 쓰는 agent라는 사실입니다.
관련해서 먼저 읽어 두면 좋은 글은 Toolformer 논문 쉽게 이해하기, ReAct 논문 쉽게 이해하기, MCP란 무엇인가입니다.
주요 원문 출처는 Toolformer arXiv, Toolformer OpenReview, ReAct arXiv, ReAct 프로젝트 사이트, HuggingGPT arXiv, Gorilla OpenReview입니다.
