목차
이 글은 Anthropic 엔지니어링 블로그에 2025년 11월 24일 게재된 “Introducing advanced tool use on the Claude Developer Platform” 을 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/advanced-tool-use
한 줄로 말하면 #
도구가 수백 개 있을 때 다 외우지 말고, 필요할 때 찾고 코드로 묶고 예시로 배우게 하자.
어떤 문제를 해결하려 했나 #
Claude에 GitHub, Slack, Sentry, Grafana, Splunk MCP 서버를 다 붙였다고 상상해봅시다.
“음, 그러면 대화 시작 전부터 도구 정의만으로 컨텍스트가 55,000 토큰 정도 차네요. 어떤 셋업은 134,000 토큰까지도…”
대화도 시작 안 했는데 컨텍스트 절반이 도구 설명문으로 채워집니다. 게다가 도구를 호출할 때마다 중간 결과(50KB짜리 데이터 등)가 컨텍스트에 누적됩니다.
이 글은 그 세 가지 골칫거리를 각각 해결하는 신기능 세 개를 소개합니다.
해결책: 세 가지 신기능 #
1. Tool Search — “도구를 미리 다 외우지 말고, 찾아 써라” #
도구 정의에 defer_loading: true 표시를 하면, 검색 도구만(~500 토큰) 처음에 로드됩니다. Claude는 필요할 때 검색해서 해당 도구만 가져옵니다.
{
"tools": [
{"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},
{"name": "github.createPullRequest", "defer_loading": true}
]
}효과:
- 토큰 사용 85% 감소 (도구 라이브러리는 그대로 유지)
- Opus 4 정확도 49% → 74%
- Opus 4.5 정확도 79.5% → 88.1%
- 컨텍스트 창의 95% 보존
2. Programmatic Tool Calling — “도구 호출을 코드로 묶어라” #
#13에서 본 코드 실행 발상과 같은 정신입니다. Claude가 파이썬 코드를 짜서 여러 도구를 샌드박스 안에서 한 번에 묶어 호출하고, 결과만 컨텍스트로 가져옵니다.
# Claude가 작성한 오케스트레이션 코드
team = await get_team_members("engineering")
expenses = await asyncio.gather(*[
get_expenses(m["id"], "Q3") for m in team
])
# 2,000명치 비용 명세서는 샌드박스에만, 결과만 반환효과:
- 복잡한 리서치 작업에서 토큰 37% 감소 (43,588 → 27,297)
- 수십 번의 중복 추론 패스 제거
- GIA 벤치마크 46.5% → 51.2%
3. Tool Use Examples — “스키마 말고 예시로 가르쳐라” #
JSON Schema는 구조를 정의하지만 사용 패턴을 못 담습니다. 어떤 옵션 파라미터를 언제 넣어야 하는지, API 관행은 어떤지 같은 것들이요. 그래서 도구 정의에 실제 호출 예시를 함께 넣습니다.
{
"name": "create_ticket",
"input_examples": [
{
"title": "Login page returns 500 error",
"priority": "critical",
"due_date": "2024-11-06"
}
]
}효과:
- 복잡한 파라미터 처리 정확도 72% → 90%
- 날짜 형식·ID 관행·중첩 구조 같은 모호함 해소
결과 / 효과 #
| 기능 | 핵심 수치 |
|---|---|
| Tool Search | 토큰 85% ↓, 정확도 +18~25%p |
| Programmatic Tool Calling | 토큰 37% ↓, GIA +4.7%p |
| Tool Use Examples | 정확도 72% → 90% |
원문 권장: “세 기능을 다 쓸 필요 없다. 본인의 가장 큰 병목부터 시작하라.”
핵심 결론 #
도구 많이 붙이면 더 강해진다고 생각하기 쉽지만, 사실 도구가 많아질수록 컨텍스트가 빠르게 가난해집니다. 이 글의 답은 다릅니다.
“성능 문제가 모델인 줄 알았는데, 사실은 도구 정의·중간 결과·사용법 모호함이 컨텍스트를 갉아먹는 게 문제였다.”
해법은 세 갈래입니다. 다 외우지 말고(Tool Search), 결과 다 들고 다니지 말고(Programmatic), 추측하지 말게 하라(Examples).
내 작업에 적용한다면 #
시나리오 1 — 일반적인 데이터 분석 과정 #
분석 환경에 도구·헬퍼 함수가 쌓이면 LLM이 길을 잃습니다.
[Before — 모든 헬퍼 정의를 로드]
함수 50개 시그니처를 컨텍스트에 다 붙임
→ 시작부터 토큰 절반 사용
[advanced tool use 적용]
[Tool Search 패턴]
- 함수 카탈로그를 외부 인덱스에 두고 검색
- "분포 확인 함수 찾아줘" → 관련 함수만 로드
[Programmatic 패턴]
- 데이터 정제·집계·검증을 코드로 묶기
- 큰 중간 결과는 샌드박스 머무름
[Examples 패턴]
- 각 헬퍼에 "이렇게 호출했을 때 잘 됨" 예시 첨부
- 파라미터 헷갈림 방지핵심: 분석 도구가 많아질수록 “필요할 때 찾고, 결과는 코드에 묶고, 예시로 가르치는” 셋업이 분석 품질을 좌우합니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화에서도 도구·API 종류는 빠르게 늘어납니다. CMS, 분석, 모니터링, 결제, 알림…
[Before — 모든 API 클라이언트 컨텍스트에]
운영 작업 시작 전부터 도구 정의 100KB
→ 작업 시작 시점에 토큰 거의 소진
[advanced tool use 적용]
[Tool Search]
- API 카탈로그를 인덱싱해 두고 필요할 때만 로드
[Programmatic]
- 운영 시퀀스(빌드→테스트→배포→스모크)를 코드로 묶기
- 단계별 로그는 샌드박스에 누적, 요약만 반환
[Examples]
- 각 운영 API에 "이런 상황에 이렇게 호출" 예시 동봉
- 잘못된 옵션 조합 사고 예방핵심: 운영 도구가 많을수록 “세 가지 신기능 중 가장 큰 병목 하나부터” 적용하세요. 다 도입할 필요 없습니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
