똑똑해지는 AI, Tool 호출도 진화하나?

이상했습니다. 요즘 모델이 못 할 만한 일은 아니었습니다. 파일에서 한 구간을 읽고, 이어 붙이고, 글자 수를 세는 정도였으니까요.

그런데 작업 내용이 아니라 도구를 부르는 단계에서 막혔습니다. 9초 뒤에 에이전트는 글자 하나 다르지 않은 똑같은 명령을 다시 보냈고, 또 거절당했습니다. 표현을 바꿔 두 번 더 시도했습니다. 33초 동안 네 번이었습니다.

무엇을 해야 하는지는 처음부터 알고 있었습니다. 막힌 곳은 그 의도를 도구가 받아들이는 형태로 옮기는 단계였습니다.

그러다 궁금해졌습니다. AI는 지금 도구를 어떤 방식으로 부르고 있을까요. 그리고 그 방식은 모델이 지금보다 훨씬 덜 똑똑했던 시절과 얼마나 달라졌을까요.

찾아보니 며칠 전에 거의 같은 질문을 실험한 논문이 나와 있었습니다. 방법은 의외로 단순했습니다. 툴 호출을 하나씩 만들게 하지 않고, 모델에게 아예 짧은 코드를 쓰게 했습니다.

결과는 한쪽으로 기울지 않았습니다.

이 글은 무엇입니까 2026년 8월 6일 공개된 논문 「The Bitter Lesson of Tool Calling」(arXiv:2608.06370)을 읽고 정리했습니다. 저자 네 명은 회계·컨설팅 법인 PwC의 기술혁신 조직 소속입니다. 모델을 만드는 회사도, 대학 연구실도 아닙니다. 논문이 말한 것과 제 해석은 본문에서 구분해 표시했습니다. 수치는 전부 원문을 직접 열어 문자열 단위로 대조했습니다.

AI가 지금 도구를 부르는 방식

AI가 검색을 하거나 파일을 읽는 것처럼 스스로 할 수 없는 일을 할 때는 “도구”를 부릅니다. 부르는 방식은 대체로 정해져 있습니다. 개발자가 도구의 이름과 필요한 값을 미리 정의해 두면, 모델이 그 형식에 맞는 호출 하나를 만들어 냅니다.

사용자 요청 → 모델이 판단 → { 도구: "날씨", 값: "서울" } → 실행 → 결과 → 모델이 다시 판단 → ...

형식이 정해져 있으니 값이 제대로 들어왔는지 검사하기 쉽고, 권한을 걸기도 쉽습니다. 대신 행동 하나에 호출 하나입니다. 도구를 백 번 불러야 하면 호출 객체를 백 개 만들어야 하고, 앞의 결과를 받아 다음을 부르는 연쇄 작업이라면 고리 하나마다 모델이 처음부터 다시 생각합니다.

논문이 비교한 쪽은 도구를 파이썬 함수처럼 보여줍니다. 모델은 이렇게 생긴 것을 받습니다.

def get_weather(city: str):
    ...

그리고 호출을 하나씩 만드는 대신 짧은 프로그램을 씁니다.

results = []
for city in cities:
    results.append(get_weather(city))

도시가 백 개여도 위 세 줄이 그대로 끝입니다. 조건에 따라 갈라지거나, 중간 결과를 걸러내거나, 여러 개를 동시에 부르는 것도 프로그래밍 언어가 원래 갖고 있는 문법으로 표현됩니다. 논문은 이 방식을 PTC(programmatic tool calling)라고 부르고, 14개 모델을 BFCL v4라는 도구 호출 평가 세트에서 두 방식으로 각각 돌렸습니다.

정확도는 비슷했고, 시간이 줄었습니다 — 다만 모델을 가렸습니다

정확도만 보면 밋밋합니다. 14개 중 11개에서 PTC가 기존 방식과 같거나 나았는데, 대부분 몇 점 차이입니다.

시간은 달랐습니다. 앞 결과를 받아 다음 도구를 부르는 연쇄 작업에서 14개 중 13개 모델이 기존 방식의 절반 정도 시간에 끝냈습니다. 논문이 잰 항목당 소요 시간은 기존 방식의 0.32배에서 0.96배 사이였습니다.

기존 방식은 고리 하나마다 모델이 한 번씩 다시 생각해야 합니다. 코드로 쓰면 그 연쇄가 한 번에 적히고, 실행은 프로그램이 합니다. 붙잡고 있어야 하는 횟수가 줄어드는 셈입니다.

연쇄가 길수록 격차도 벌어졌습니다. 짧은 연쇄에서는 차이가 거의 없다가 12단계 이상에서 정확도가 18.8%포인트 갈렸습니다. 여기서 “포인트”는 두 비율의 차이라는 뜻입니다.

예외도 있었습니다. GPT-5는 오히려 2.8배 느려졌습니다. 생각을 길게 하는 모델이라, 왕복을 줄여 번 시간을 생성 시간이 도로 까먹었습니다.

그리고 세 모델은 아예 무너졌습니다. GPT-4o는 81.9에서 55.0으로, GPT-4.1은 81.9에서 62.1로, GPT-5.4-mini는 79.3에서 55.0으로 떨어졌습니다.

이유가 좀 허탈합니다. 이 모델들은 여러 줄짜리 파이썬 코드를 만들 때 실제 줄바꿈 대신 \n이라는 두 글자를 그대로 출력했습니다. 실행하는 쪽에서는 문법 오류가 났습니다. 프롬프트 문제도 아니었습니다. 같은 지시문으로 더 작고 더 오래된 GPT-5-nano는 멀쩡한 코드를 만들었으니까요. 왜 그런지는 논문 범위 밖이라고 밝히고 있습니다.

여기서 논문이 뽑아낸 문장이 이 글에서 제일 중요합니다.

PTC가 잘 되는지 아닌지는 모델 회사가 아니라 모델 세대를 따라갑니다.

Anthropic 모델 다섯 개는 전부, OpenAI에서도 최신 GPT-5.6 계열 셋은 전부 기존 방식 이상이었습니다. 무너진 셋은 모두 GPT-5.6 이전입니다. 다만 깔끔하게 순서대로는 아닙니다. 무너진 셋 중 GPT-5.4-mini는 멀쩡했던 GPT-5.4보다 늦게 나온 모델입니다.

한 번에 여러 개를 동시에 부르는 상황에서도 눈에 띄는 결과가 나왔습니다. Claude Sonnet 5에게 부를 도구 수를 늘려가며 시켜봤더니 70개까지는 전부 제대로 부르다가, 72개에서 75%로 떨어지고, 100개에서는 하나도 제대로 못 불렀습니다. 코드 방식은 100개에서도 전부 불렀습니다.

그렇다고 “정해진 형식이 100개를 못 버틴다”는 이야기는 아닙니다. 논문이 그 해석을 직접 부정합니다. 같은 조건에서 GPT-5.6-Sol은 100개까지 멀쩡했고, 논문은 이 한계가 형식 자체의 성질이 아니라 Anthropic 모델이 병렬 호출을 늘어놓는 방식에 특유한 것이라고 못 박았습니다. 같은 형식인데 만든 회사에 따라 무너지는 지점이 다르다는 쪽이 오히려 흥미롭습니다.

토큰은 특정 조건에서만 절약됩니다

Anthropic은 이 방식을 실제 API 기능으로 제공합니다. 공식 문서에는 특정 검색 벤치마크에서 성능이 평균 11% 오르면서 입력 토큰을 24% 덜 썼다고 적혀 있고, 엔지니어링 블로그에는 복잡한 조사 작업에서 평균 43,588 토큰이 27,297 토큰으로 줄었다는 수치가 있습니다. 37% 감소입니다.

논문 쪽 숫자는 방향이 반대인 구간을 보여줍니다.

• 동시에 부르는 도구가 26개 근처에서 비용이 역전됩니다. 그 아래에서는 코드 방식이 더 비쌉니다. 지시문 전체를 시스템 프롬프트에 넣어야 해서 고정 비용이 붙습니다
• 연쇄 작업에서는 코드 방식이 입력 토큰을 1.5배 씁니다
• 출력 토큰은 두 방식이 같습니다

재는 작업이 다르니 서로 틀린 수치는 아닙니다. 다만 절약은 작업이 충분히 클 때 생깁니다.

논문 부록에는 14개 모델을 평균 낸 표가 있는데, 거기서는 기존 방식 78.6점, 코드 방식 77.0점으로 순위가 뒤집힙니다. 무너진 세 모델이 평균을 끌어내린 것이고, 논문도 캡션에 그렇게 적어 뒀습니다. 초록은 “14개 중 11개”라고 쓰고 부록은 반대로 보이는 표를 싣는 셈인데, 이 대비가 오히려 “평균 말고 세대를 보라”는 주장의 예시가 됩니다.

제 로그를 세어봤더니 첫인상이 틀렸습니다

글 첫머리의 그 일이 얼마나 자주 일어나는지 궁금했습니다. 체감으로는 꽤 자주 겪는 것 같았습니다. 그래서 제 PC에 남아 있는 Claude Code 세션 기록을 열어 직접 세어봤습니다. 2026년 5월 22일부터 8월 9일까지 80일치, 대화 기록 44개입니다.

도구 호출은 모두 3,542번 있었습니다. 오류로 끝난 것이 104번인데 대부분은 화면 캡처 시간 초과나 없는 경로처럼 주제와 상관없는 것들이었고, 오류 메시지가 호출 형식이나 값 자체를 지적한 것만 세면 10번이었습니다. 전체 호출의 0.28%입니다.

제 짐작이 틀렸습니다.

대신 다른 게 보였습니다. 실패가 고르게 흩어져 있지 않았습니다.

적어도 이 기록에서는 실패가 PowerShell·Edit·Write에만 몰렸습니다. Read와 Bash에서는 한 번도 없었습니다.

공교롭게도 값을 조립해서 넘기는 일이 많은 도구들입니다.

그러고 나서 논문의 한계 항목 하나가 다르게 읽혔습니다. 논문은 자기 실험이 잰 것은 값을 제대로 만들어 넣었는가이지 도구를 불러 일을 끝까지 해냈는가가 아니라고 한정합니다. 실제 API를 부르지 않고 받은 값을 되돌려주는 껍데기 함수를 썼기 때문입니다.

논문이 한계라고 적은 그 지점이, 제 로그에서 실제로 깨진 자리와 같았습니다. 이건 제 해석이고 논문의 주장이 아닙니다. 기록 하나짜리라 일반화할 수도 없습니다.

이 실험이 보여주지 못한 것

실제 도구를 부른 실험이 아닙니다. 껍데기 함수를 썼으니 API 실패, 재시도, 도중에 상황이 바뀌는 경우는 검증 범위 밖입니다.

표본도 작습니다. 세부 실험은 조건당 31~52건이라, 논문 스스로 개별 모델 결과는 방향으로만 읽으라고 적었습니다. 사용한 평가 세트에 20%의 판정 불일치가 발견됐다는 감사 결과도 있습니다. 저자들은 다른 채점 방식을 써서 그 경로를 피했지만, 정답 자체에 남은 오차는 그대로 물려받는다고 밝혔습니다. 논문은 GPT-5.6 계열의 향상폭을 초록에서 10.6%, 결론에서 10.7%로 다르게 적기도 했습니다. 표를 직접 계산하면 10.6이 맞습니다.

제가 확인한 것도 하나 적어둡니다. Anthropic은 이 방식을 Claude API 기능으로 제공하지만, Claude Code에는 같은 이름의 기능이 없습니다. 저장소 변경 기록 전체를 찾아봤지만 나오지 않고, 기능 요청 하나가 2026년 4월에 방치 상태로 닫혔습니다. 제가 매일 쓰는 도구와 위 문서는 서로 다른 물건입니다.

같은 방법인데 모델에 따라 결과가 달랐습니다

GPT-4o에서 이 방식은 기존 방식보다 26.9%포인트 낮았습니다. 쓰면 손해였다는 뜻입니다. 최신 모델들에서는 오히려 경쟁력이 생겼습니다. 방법은 그대로였고 모델만 바뀌었습니다.

이 논문만으로 PTC가 앞으로 툴 호출의 표준이 될 거라고 말할 수는 없습니다.

제가 더 흥미롭게 본 건 다른 쪽입니다. 예전에는 모델이 제대로 다루지 못해서 별로였던 방법이, 모델이 좋아지면서 현실적인 선택지가 됐다는 점입니다.

여기서부터는 논문이 한 말이 아니라 제 생각입니다. AI가 더 똑똑해지면 같은 일을 더 잘하는 데서 끝나지 않을 수도 있습니다. 예전 모델을 기준으로 만들어 둔 사용법이나 인터페이스 중에는 다시 볼 이유가 생기는 것도 있을 겁니다. 실수하지 말라고 행동 하나하나의 형식을 정해주는 쪽과, 목적을 주고 알아서 풀게 하는 쪽 중에 무엇이 나은지가 모델 능력에 따라 달라질 수 있으니까요. 툴 호출도 그중 하나일지 모릅니다.

PTC가 그 답인지는 아직 모르겠습니다. 다만 한때 쓰면 손해였던 방식이 지금은 쓸 만해졌다는 것. 저는 이 논문에서 그 변화가 가장 재미있었습니다.

확인 조건과 출처

• 논문: Patel, Sen, Lumer, Subbiah, 「The Bitter Lesson of Tool Calling」, arXiv:2608.06370v1 (2026-08-06 공개). 본문 수치는 2026년 8월 9일에 원문 HTML을 직접 받아 대조했습니다. v1 프리프린트라 이후 판에서 수치가 바뀔 수 있습니다
• Anthropic 공식 문서: Programmatic tool calling / Advanced tool use (2026-08-09 확인)
• 제 로그 실측: 2026년 5월 22일 ~ 8월 9일, Claude Code 세션 기록 44개. Windows 11