Claude 개발자 플랫폼, 툴 활용이 완전히 달라진 3가지 혁신

AI 에이전트가 진짜 '업무 동료'가 되려면 한두 개가 아니라 수십, 수백 개의 툴을 자유자재로 다뤄야 합니다.

Anthropic이 Claude 개발자 플랫폼에 세 가지 새로운 베타 기능을 추가하면서, 이 그림이 현실에 훨씬 가까워졌습니다.

이 글에서는

왜 기존 툴 호출 방식으로는 한계가 있었는지,
새로 추가된 세 가지 기능이 각각 어떤 문제를 해결하는지,
실제로 어떤 상황에서 어떻게 써야 효과적인지

를 개발자 관점에서 쉽고 재밌게 풀어보겠습니다.

Claude 고급 툴 사용: 무엇이 어떻게 달라졌나

이번에 공개된 기능은 이름은 조금 딱딱하지만, 아이디어는 단순합니다.

Tool Search Tool: "툴 사전"을 하나만 넣어두고, 필요한 순간에만 그 안에서 툴을 검색해 불러오는 방식입니다.
Programmatic Tool Calling: 자연어로 툴을 한 번씩 호출하는 대신, Claude가 직접 파이썬 코드로 여러 툴을 오케스트레이션합니다.
Tool Use Examples: JSON 스키마만 던져주지 말고, "이렇게 쓰는 거야"라는 실제 예시를 함께 알려주는 기능입니다.

결국 목표는 하나입니다.

쓸데없는 토큰 낭비 줄이기,
툴 선택과 파라미터 사용 정확도 높이기,
복잡한 워크플로를 빠르고 안정적으로 돌리기.

내부 테스트 기준으로는 MCP 기반 큰 툴셋에서 정확도가 20%p 가까이 올라가고, 복잡한 리서치 작업에서는 토큰 사용량이 30% 이상 줄었습니다.

이제 각각을 따로 들여다보겠습니다.

Tool Search Tool: 툴 정의 10만 토큰 시대의 해방구

툴이 몇 개 안 될 때는 정의를 전부 맥락에 넣어도 괜찮습니다. 하지만 GitHub, Slack, Jira, Sentry, Grafana, Splunk… MCP 서버를 몇 개만 붙여도 금방 50개, 100개 툴을 넘어갑니다.

문제는 여기서 시작됩니다.

툴 정의만으로도 5만~10만 토큰이 날아가고
대화가 시작되기도 전에 컨텍스트 창의 상당 부분이 이미 꽉 찹니다.
이름이 비슷한 툴들 사이에서 선택도 자주 틀립니다.

Anthropic 내부 예시에서는 MCP 툴 정의만 13만 토큰이 들어가는 경우도 있었습니다. 이 상태에서는 긴 문서나 로그를 읽을 여유가 애초에 사라집니다.

Tool Search Tool의 아이디어는 매우 단순합니다. "툴 정의를 애초에 다 넣지 말고, 검색해서 필요한 것만 그때그때 불러오자."

API에 툴 정의를 모두 등록하되, 대부분은 defer_loading: true로 표시해 둡니다. 그러면 Claude가 처음에 보는 건:

Tool Search Tool 자체 (한 500 토큰 정도)
정말 자주 쓰는 핵심 툴 몇 개

뿐입니다.

Claude가 "GitHub에서 PR 만들기"가 필요하다고 판단하는 순간, Tool Search Tool을 통해 "github"를 검색합니다. 그리고 그 시점에 정확히 필요한 2~3개 정의만 컨텍스트에 로딩합니다.

결과는 꽤 충격적입니다.

기존 방식: 대화 시작 전에 ~7만 토큰 사용
Tool Search Tool 사용: 약 8,700 토큰만 사용

컨텍스트 창의 95%를 아낀 셈이고, 토큰 사용량은 약 85% 줄어든 셈입니다. 그럼에도 전체 툴 라이브러리에는 여전히 모두 접근할 수 있습니다.

실제 MCP 평가에서 정확도도 크게 뛰었습니다.

Opus 4: 49% → 74%
Opus 4.5: 79.5% → 88.1%

툴이 많을수록, 그리고 정의가 길수록 Tool Search Tool의 가치는 기하급수적으로 커집니다.

Tool Search Tool, 언제 쓰면 좋을까?

Tool Search Tool은 마법의 만능키는 아닙니다. '검색 한 번'이라는 추가 단계가 생기기 때문에, 이 지연보다 이득이 더 클 때 의미가 있습니다.

다음 상황이라면 적극적으로 고려할 만합니다.

MCP 서버가 여러 개 붙어 있고
툴 정의가 1만 토큰을 가볍게 넘고
헷갈리는 이름의 툴이 많아 선택 오류가 자주 나며
세션마다 실제로 사용하는 툴은 그중 극히 일부인 경우

반대로, 툴이 5~6개밖에 없고, 매번 거의 다 쓰는 구조라면 굳이 검색 단계를 넣을 이유는 없습니다.

실무적으로는 이런 식 구성이 가장 현실적입니다.

정말 자주 쓰는 3~5개 툴은 항상 로딩
나머지 수십, 수백 개는 모두 defer_loading: true
이름과 description을 검색 친화적으로 잘 작성
시스템 프롬프트에 "툴 검색이 가능하다"는 안내 문구 추가

이렇게만 해도 "툴 지옥에서 토큰 파산"이라는 상황을 상당 부분 피할 수 있습니다.

Programmatic Tool Calling: 툴 오케스트레이션을 코드로 맡기기

이제 두 번째 문제입니다.

기존의 자연어 기반 툴 호출 방식에는 두 가지 큰 한계가 있습니다.

첫째, 중간 결과가 모두 컨텍스트 창을 더럽힙니다.

10MB짜리 로그 파일을 툴로 읽어오면
Claude 컨텍스트에 로그 전체가 들어가 버립니다.
사실 Claude가 필요한 건 "에러 유형과 빈도" 같은 요약뿐인데도 말이죠.

둘째, 툴 호출마다 모델 추론을 한 번씩 해야 합니다.

5개 툴을 순차적으로 호출하는 워크플로는
결국 5번의 인퍼런스 + 중간 결과를 눈으로 훑고 판단하는 작업의 반복입니다.
느리고, 비싸고, 실수하기 쉽습니다.

Programmatic Tool Calling(이하 PTC)은 여기서 접근 방식을 바꿉니다.

"툴을 자연어로 하나씩 호출하지 말고, Claude가 파이썬 코드로 여러 툴을 한 번에 orchestration하게 만들자."

Claude는 코드 작성에 강합니다. 그래서 다음과 같은 일을 코드에서 처리하도록 넘깁니다.

루프, 조건문, 분기, 에러 처리
대량 데이터에서 합계/평균/필터링 같은 변환 작업
여러 툴의 결과를 합쳐 최종 결과만 Claude에게 돌려주기

중간 데이터는 코드 실행 환경 안에서만 소비되고, 모델의 컨텍스트에는 들어오지 않습니다.

예시로 보는 Programmatic Tool Calling의 파괴력

상황을 하나 그려보겠습니다.

질문: "우리 엔지니어링 팀에서 Q3 출장 예산을 초과한 사람은 누구야?"

가지고 있는 툴은 세 개입니다.

get_team_members(department)
get_expenses(user_id, quarter)
get_budget_by_level(level)

전통적인 방식이라면:

팀원 20명 조회 → 1번 툴 호출
각자 Q3 비용 조회 → 20번 툴 호출, 사람당 50~100개 라인 아이템
레벨별 예산 조회 → 여러 번 호출
이 모든 결과가 Claude 컨텍스트에 그대로 쌓입니다.
이후 Claude가 자연어로 총합을 계산하고, 예산과 비교하고, 초과 여부를 판단합니다.

이렇게 되면 수천 개의 비용 라인이 컨텍스트를 가득 채우고, 토큰도 잔뜩 쓰이면서, 계산 실수 가능성도 높습니다.

PTC를 쓰면 구조가 완전히 달라집니다.

Claude가 파이썬 코드 한 덩어리를 작성합니다.
코드 안에서 세 툴을 호출해 필요한 데이터를 모두 가져옵니다.
가져온 데이터를 코드에서 합계내고, 예산과 비교하고, 초과한 사람만 리스트로 만듭니다.
Claude가 최종적으로 보는 건 "예산을 초과한 사람 2~3명의 결과 JSON"뿐입니다.

중간의 2,000+ 라인 아이템, 합계 계산 중간값, 예산 룩업 정보는 전부 코드 실행 환경에서만 소비되고, 모델 컨텍스트에는 들어가지 않습니다.

내부 실험에서는 이런 방식으로:

평균 토큰 사용량이 약 37% 감소
여러 툴이 얽힌 복잡한 리서치·질의 작업에서 정확도가 눈에 띄게 향상
인퍼런스 횟수가 줄어들면서 지연 시간도 체감될 정도로 줄었습니다.

특히 "데이터는 크지만, Claude가 알아야 할 건 요약 결과뿐인 작업"에서 효과가 극적입니다.

Programmatic Tool Calling, 언제 도입해야 할까?

PTC는 코드 실행이라는 계층이 하나 더 생기는 만큼, 아주 단순한 작업에는 과할 수 있습니다. 하지만 다음 조건이 하나라도 맞으면 고려할 가치가 큽니다.

툴 결과가 "대량 데이터"인데 Claude는 집계/요약만 필요할 때
3단계 이상의 멀티 스텝 워크플로에서 여러 툴이 엮일 때
결과를 필터링·정렬·변환해서 일부만 Claude에 보여주고 싶을 때
10개, 20개 이상의 항목에서 동일한 작업을 병렬로 돌려야 할 때

반면, 이런 경우라면 굳이 PTC까지는 필요 없습니다.

단일 툴 한 번 호출해서 정보만 가져오면 되는 간단한 작업
데이터가 작고, 중간 데이터까지 Claude가 직접 보고 판단해야 하는 경우

구현 팁을 몇 가지 정리하면:

code_execution 툴을 추가하고, 특정 툴에 allowed_callers로 "코드 실행에서 호출 가능"을 명시합니다.
툴 반환 형식을 description에 매우 구체적으로 적어두면, Claude가 올바른 파싱 코드를 훨씬 잘 작성합니다.
병렬 호출이 가능한 툴, 재시도해도 안전한(idempotent) 툴부터 PTC 대상에 올리는 것이 좋습니다.

Tool Use Examples: 스키마만으론 부족한 '사용법'을 가르치기

세 번째 문제는 "형식은 맞는데, 쓰는 방법이 틀리는" 상황입니다.

JSON 스키마는 이런 걸 잘 정의합니다.

필드 타입
필수/옵션 여부
enum 값 범위

하지만 이런 건 말해주지 못합니다.

날짜는 "2024-11-06"인지, "Nov 6, 2024"인지
id는 "USR-12345" 형식인지, 그냥 "12345"인지
중첩 객체는 언제, 어느 수준까지 채워야 하는지
priority가 critical일 때 escalation 필드는 어떻게 채우는지

예를 들어 지원 티켓 API create_ticket 스키마만 던져주면, Claude는 구조를 맞출 수는 있지만 "회사 내부 룰대로 제대로" 쓰기는 어렵습니다.

Tool Use Examples는 여기에 "샘플 호출"을 추가할 수 있게 합니다.

동일한 schema에 input_examples 배열을 달고
실제로 쓸 법한 예시 1~5개를 넣어줍니다.

예를 들면,

심각한 장애: priority=critical, reporter 정보 + 연락처, escalation 설정, 짧은 SLA
기능 요청: priority 없이 labels 위주, escalation 없음
내부 잡무: title만 있는 간단한 티켓

이 정도 예시만 있어도 Claude는 금방 패턴을 학습합니다.

날짜는 YYYY-MM-DD 포맷을 쓰는구나
reporter.id는 "USR-XXXXX" 형식이구나
critical 이슈엔 escalation 객체를 같이 채우는구나
간단한 작업에는 최소 필드만 보내는구나

Anthropic 내부 테스트에서는 복잡한 파라미터 처리 정확도가 72% → 90%로 크게 향상됐습니다. "스키마만 보고 추측하던" 부분을 예제로 확실히 잡아준 덕입니다.

Tool Use Examples, 어디까지 넣는 게 좋을까?

예시는 많을수록 좋은 걸까요? 꼭 그렇진 않습니다. 예시도 토큰을 먹기 때문에, "정확도 향상"과 "토큰 비용" 사이 균형이 필요합니다.

도입 효과가 큰 경우는 다음과 같습니다.

중첩 구조가 복잡하고, 유효한 JSON이라고 해서 의미적으로 맞는 건 아닌 경우
옵션 필드가 많고, "언제 어떤 조합으로 쓰는지"가 중요할 때
ID, 코드, 포맷에 조직 고유의 규칙이 있는 API
이름이 비슷한 여러 툴 중 어느 걸 언제 써야 하는지 헷갈릴 때

반대로, 이런 경우는 예시 없이도 충분합니다.

파라미터가 1~2개뿐인 아주 단순한 툴
URL, 이메일 같이 Claude가 이미 잘 아는 표준 포맷
검증 문제를 JSON 스키마 제약으로 해결할 수 있는 경우

실무 팁을 정리하면:

"string", "value" 같은 값 대신, 진짜처럼 보이는 데이터(도시 이름, 가격, 실제처럼 보이는 ID)를 넣습니다.
최소 필드만 채운 예시 1개, 옵션을 적당히 쓴 예시 1개, 거의 풀 세팅 예시 1개 정도면 충분한 경우가 많습니다.
애매한 툴에만 예시를 집중적으로 넣고, 자명한 툴은 스키마만 두는 식으로 토큰을 절약합니다.

세 기능을 함께 쓸 때의 전략: 어디서부터 도입할까?

이 세 기능은 서로 경쟁 관계가 아니라, 서로 다른 병목을 풀어주는 도구입니다.

Tool Search Tool → "툴 정의 때문에 컨텍스트가 터지는 문제" 해결
Programmatic Tool Calling → "중간 결과 때문에 컨텍스트와 속도가 터지는 문제" 해결
Tool Use Examples → "파라미터 오류와 잘못된 사용 패턴" 해결

그래서 한 번에 다 쓰려고 하기보다, 가장 아픈 곳부터 하나씩 도입하는 게 좋습니다.

툴이 많아서 정의만 수만 토큰이라면 → Tool Search Tool부터 적용
로그, 레코드, 행(row)이 수천·수만 개인데 결과 요약만 필요하다면 → Programmatic Tool Calling으로 중간 데이터는 코드에서만 처리
호출은 되는데 자꾸 필드 누락·형식 오류·관행 위반이 난다면 → Tool Use Examples로 예시를 추가

그다음에, 필요에 따라 나머지 기능을 겹쳐 쓰면 됩니다.

추천되는 구조는 대략 이런 느낌입니다.

Tool Search Tool로 "어떤 툴을 쓸지"를 정확히 찾고
Programmatic Tool Calling으로 "어떻게 순서를 짜고 데이터를 다룰지"를 코드로 처리하고
Tool Use Examples로 "각 툴은 어떻게 정확히 호출해야 하는지"를 예시로 가르치는 것.

Claude 고급 툴 사용, 지금 어떻게 시작할까?

이 기능들은 현재 베타이지만, 이미 개발자 플랫폼에서 바로 써볼 수 있습니다.

필요한 것은 크게 세 가지입니다.

API 호출 시 고급 툴 사용 베타 헤더 추가
tools 목록에
- tool_search_tool (regex 또는 BM25)
- code_execution
- 나머지 커스텀 툴들 + defer_loading / allowed_callers / input_examples 를 적절히 설정

그리고 문서 및 샘플을 참고하면서, 본인 서비스에 맞는 설계를 조금씩 다듬으면 됩니다.

처음부터 모든 워크플로를 갈아엎을 필요는 없습니다.

MCP를 쓰는 대형 에이전트라면 Tool Search Tool부터
데이터가 큰 리포트/대시보드 자동화라면 Programmatic Tool Calling부터
내부 API 호출 오류가 잦은 서비스라면 Tool Use Examples부터

이렇게 "가장 골치 아픈 지점 하나"만 골라서 테스트해보는 것을 추천합니다.

마무리하며

이번에 Anthropic이 공개한 세 가지 기능은, 단순한 "툴 호출 기능 업그레이드"가 아니라 에이전트 아키텍처 자체를 한 단계 끌어올리는 변화에 가깝습니다.

필요한 툴만 그때그때 검색해서 쓰고
복잡한 오케스트레이션은 코드에 맡기고
툴 사용법은 예시로 명확히 가르치는 구조

이 조합이 갖춰지면, 이제 AI 에이전트는 "몇 개의 API를 번갈아 부르는 챗봇"에서 "수십 개의 시스템을 안정적으로 다루는 자동화 코디네이터"에 가까워집니다.

지금 운영 중인 서비스에

툴이 많아서 관리가 힘들다,
데이터가 많아서 토큰이 모자라다,
API 호출 오류가 잦다

이 셋 중 하나라도 해당된다면, Claude 개발자 플랫폼의 고급 툴 사용 기능을 직접 실험해보세요.

조금의 설정과 몇 개의 예시만으로, "이건 이제 인간이 직접 할 필요가 없겠다" 싶은 순간이 생각보다 빨리 찾아올 수 있습니다.

출처 및 참고 : Introducing advanced tool use on the Claude Developer Platform \ Anthropic