Category
모델이 정의된 함수·API를 호출해 검색·계산·DB 조회 같은 실제 동작을 수행하게 하는 기능이다. function calling이 에이전트의 실행 능력을 만드는 토대다. 핵심은 모델이 도구를 고르고 인자를 채우는 정확도이며, 도구 스키마 설계와 결과 검증이 신뢰성을 좌우한다.
MCP 생태계가 커지면서 한 에이전트에 수십 개의 도구 서버를 한꺼번에 물리는 구성이 흔해졌지만, 도구 수가 늘수록 선택 정확도가 꺾인다는 분석이 잇따른다. 원인은 두 갈래다. 첫째, 모든 도구의 description이 컨텍스트에 상주하면서 입력 토큰을 잠식하고 비슷한 이름의 도구끼리 혼동을 유발한다. search_user와 find_user, get_account가 한 네임스페이스에 같이 있으면 모델은 미묘하게 틀린 도구를 고른다. 둘째, 선택 폭이 넓을수록 모델이 불필요한 도구를 호출하는 '도구 환각'이 늘어난다. 대응으로 떠오른 패턴이 도구 라우팅 계층이다. 작업 단계마다 관련 도구 5~10개만 노출하고, 검색형 메타 도구로 필요할 때만 나머지를 끌어오는 방식이다. Anthropic의 도구 검색 도구 패턴이나 단계별 도구 게이팅이 같은 문제의식에서 나왔다. 도구는 많을수록 좋은 게 아니라, 한 결정 시점에 보이는 도구가 적을수록 정확해진다.
Anthropic이 Claude Opus 4.5와 Sonnet 4.5 계열에서 병렬 도구 호출 신뢰도를 끌어올린 가이드를 갱신했다. 핵심은 독립적인 도구 호출을 한 턴에 배열로 묶어 내보내는 능력이 모델 자체로 안정화됐다는 점이다. 이전에는 read 3건을 순차로 돌려 왕복 지연이 쌓였는데, 의존성 없는 호출을 한 번에 펼치면 검색·조회 위주 에이전트에서 체감 지연이 절반 가까이 줄어든다. 다만 공짜는 아니다. 모델이 의존 관계를 오판하면 아직 안 나온 ID를 인자로 끼워 넣은 채 병렬로 쏴버려, 두 번째 호출이 통째로 헛돈다. 그래서 도구 description에 '이 도구의 출력이 저 도구의 입력'이라는 선후 관계를 명시하라는 권고가 함께 붙었다. 병렬화는 토큰을 아끼는 게 아니라 라운드트립을 아끼는 최적화라는 점을 분명히 한 것이다.