Claude 고급 도구 사용 기능 공개

• Claude Developer Platform에 3가지 새로운 기능이 추가되어, 모델이 수천 개의 외부 도구를 효율적으로 탐색·호출·학습할 수 있는 고급 도구 사용 구조 제공
• Tool Search Tool은 필요한 시점에만 도구 정의를 불러와 토큰 사용량을 최대 85% 절감하고, 대규모 MCP 환경에서 정확도 74~88% 수준 향상
• Programmatic Tool Calling은 코드 실행 환경에서 도구를 병렬 호출해 토큰 절감(37%) , 지연 시간 감소, 정확도 향상을 달성
• Tool Use Examples는 실제 호출 예시를 통해 JSON Schema로 표현할 수 없는 도구 사용 패턴과 매개변수 관계를 학습하게 함
• 세 기능은 대규모 AI 에이전트의 효율적 오케스트레이션 기반을 제공하며, 복잡한 워크플로우 자동화의 핵심 구성 요소

---

AI 에이전트의 도구 사용 확장

• 미래의 AI 에이전트는 수백~수천 개의 도구를 통합적으로 활용해야 함
  • 예시로 IDE 보조 도구, 운영 코디네이터, Slack·GitHub·Jira·Google Drive 등과의 연동 제시
• 기존 방식은 모든 도구 정의를 미리 로드해야 해 맥락 창(context window) 을 빠르게 소모
• 새로운 접근은 필요 시점에 도구를 탐색·로드하고, 코드 기반 호출과 예시 학습을 통해 효율성 확보

Tool Search Tool

• 기존 MCP 환경에서는 다수의 서버 연결 시 도구 정의가 10만 개 이상의 토큰을 차지
  • 예: GitHub(26K), Slack(21K), Jira(17K) 등 누적 시 134K 토큰 초과 사례
• Tool Search Tool은 도구를 on-demand 방식으로 검색·로드
  • 초기 로드 시 약 500토큰만 사용, 필요 도구만 추가 로드
  • 전체 토큰 사용량 약 8.7K로 감소, 95%의 컨텍스트 절약
• 내부 테스트 결과, MCP 평가 정확도 Opus 4: 49%→74%, Opus 4.5: 79.5%→88.1% 향상
• defer_loading: true 설정을 통해 도구를 지연 로드 가능
  • 자주 쓰는 도구만 항상 로드하고 나머지는 검색 시점에 불러옴
• 정규식(regex)·BM25 기반 검색 도구 기본 제공, 임베딩 기반 커스텀 검색도 가능
• 적용 권장 조건: 10개 이상 도구, 10K 토큰 이상 정의, 선택 오류 빈번한 환경

Programmatic Tool Calling

• 기존 자연어 기반 호출은 중간 결과 누적과 다중 추론 패스로 인해 비효율 발생
  • 예: 10MB 로그 분석 시 전체 데이터가 맥락에 포함되어 토큰 낭비
• Programmatic Tool Calling(PTC)은 코드 실행 환경에서 도구를 병렬 호출
  • Claude가 Python 코드로 루프·조건문·데이터 변환을 수행
  • 중간 결과는 모델 맥락에 포함되지 않고, 최종 결과만 반환
• 예시: 분기별 예산 초과자 탐색 작업에서 2,000개 항목 대신 결과 1KB만 맥락에 포함
• 효과
  • 토큰 사용량 43,588→27,297(37% 감소)
  • 지연 시간 단축(20회 호출 시 19회 추론 제거)
  • 정확도 향상: 내부 검색 25.6→28.5%, GIA 벤치마크 46.5→51.2%
• 적용 권장 조건
  • 대규모 데이터 요약, 3단계 이상 종속 호출, 병렬 실행 필요 작업
  • 단일 호출이나 작은 응답에는 비효율적

Tool Use Examples

• JSON Schema는 구조만 정의할 뿐, 사용 패턴·형식 규칙·매개변수 관계를 표현하지 못함
  • 예: 날짜 형식, ID 규칙, 중첩 객체 사용 시점 등 불명확
• Tool Use Examples는 도구 정의에 실제 입력 예시(input_examples) 를 추가
  • 예시를 통해 Claude가 날짜 형식(YYYY-MM-DD), ID 규칙(USR-XXXXX), 선택 매개변수 조합 등을 학습
• 내부 테스트에서 복잡한 매개변수 처리 정확도 72%→90% 로 향상
• 적용 권장 조건
  • 중첩 구조·선택 매개변수가 많은 도구
  • 도메인별 규칙이 Schema로 표현되지 않는 API
  • 유사 도구 간 구분이 필요한 경우

세 기능의 통합 활용 및 베스트 프랙티스

• 세 기능은 서로 보완적으로 작동
  • Tool Search Tool → 필요한 도구 탐색
  • Programmatic Tool Calling → 효율적 실행
  • Tool Use Examples → 정확한 호출
• 적용 우선순위
  • 컨텍스트 초과 → Tool Search Tool
  • 중간 결과 과다 → Programmatic Tool Calling
  • 매개변수 오류 → Tool Use Examples
• 설정 팁
  • 도구 이름·설명을 명확히 작성해 검색 정확도 향상
  • 자주 쓰는 3~5개 도구는 항상 로드, 나머지는 지연 로드
  • 코드 실행용 도구는 반환 형식 명시
  • 예시 데이터는 실제적이고 간결하게 작성(1~5개 예시)

시작하기

• 세 기능은 베타 버전으로 제공
  • betas=["advanced-tool-use-2025-11-20"] 헤더 추가 후 사용 가능
  • 포함 도구: tool_search_tool_regex_20251119, code_execution_20250825 등
• 공식 문서와 GitHub cookbook에서 API 예시 및 구현 가이드 제공
• 이 기능들은 단순 함수 호출을 넘어 지능적 오케스트레이션으로 발전하는 기반 기술로 제시됨
• 복잡한 워크플로우와 대규모 데이터 환경에서 동적 탐색·효율적 실행·정확한 호출을 실현하는 핵심 구성 요소로 강조됨

[kimjoin2]

sonnet 4.5 도 꽤나 좋다 생각했는대요
opus 4.5 는 더 좋은 것 같아요. 우와.

[shakespeares]

그래요? 어떤점이 주로 그런가요?

[GN⁺]

Hacker News 의견

• 여러 tool call을 스트리밍할 때 context 사용량을 줄이는 방법을 찾고 있음
  일부 처리를 툴 자체로 오프로드해 200k 토큰짜리 markdown을 요약 구조로 반환하게 하지만, 이런 방식도 메인 모델의 context를 빠르게 채워버리는 경우가 있음

• Programmatic Tool Calling은 자연스러운 다음 단계라고 생각함
  LLM이 코드를 언어처럼 다루는 방향으로 가고 있으므로, 그 언어 정의가 중요함
  하지만 tool search는 불필요한 오버헤드라고 봄. 필요한 툴을 context에 미리 넣는 게 더 효율적임
  결국 함수 정의처럼 간결한 tool definition language가 필요하며, 객체를 context에 넣고 타입과 호출 가능한 메서드를 인식하게 하고 싶음

  • 이런 복잡한 구조 대신 .d.ts 같은 선언 파일을 주면 됨
    유지보수나 테스트도 쉽고, 필요하면 export * as Foo from '@foo/foo' 식으로 가져오면 됨
    LLM이 코드 작성도 잘하니, 쓰기 권한을 주면 스스로 툴을 만들거나 가져올 수 있음
    나중에는 Jupyter/Pluto/Mathematica 같은 인터랙티브한 AI↔인간 협업 플랫폼이 더 적합할 것 같음
    음성 입력을 붙이고, 세션 간 협업도 가능하게 하면 거의 Skynet 수준의 시스템이 될 것 같음
  • 왜 굳이 새로운 언어가 필요한지 모르겠음
    내가 만든 에이전트는 Python SDK의 일부 기능과 커스텀 함수만으로 충분히 동작함
    이런 pseudo-RPC 구조는 불필요한 의식처럼 느껴짐
  • 최신 MCP 사양(2025-06-18+) 은 Structured Content와 Output Schema를 지원함
    Smolagents가 이를 활용해 툴 출력을 객체(dict)로 다룸
    이런 접근이 내가 말한 방향과 비슷한지 궁금함
    자세한 내용은 Hugging Face 블로그 글에 있음

• MCP 서버가 툴 정의에 사용 예시를 포함할지 궁금함
  만약 그렇다면 코드 예시도 넣어 코드 생성 단계를 생략할 수 있을 텐데, 아마 보안 문제 때문에 막은 것 같음
  제3자가 제공한 코드를 실행하는 건 위험하니까 이런 설계가 이해됨

• Python을 래퍼로 쓴 게 아쉬움
  Bash를 썼다면 언어 간 호환성이 더 높고, Python을 쓰지 않는 워크플로에도 맞았을 것임

  • 나는 오히려 Python이 더 낫다고 생각함
    외부 툴 실행 능력도 Bash 못지않음
  • 그들은 사람들이 실제로 쓰는 언어가 Python이라는 걸 알고 그 방향으로 간 것 같음

• “수백~수천 개의 툴을 모델이 매끄럽게 다룰 미래”라는 방향은 잘못된 것 같음
  오히려 적은 툴 + 더 나은 활용 능력이 맞는 방향이라고 봄
  극단적으로는 ShellTool 하나로도 충분할 수 있음

  • 물론 모델이 모든 걸 처음부터 할 수도 있지만, 이미 검증된 툴이 있다면 그걸 쓰는 게 낫다고 생각함
    모델이 스스로 툴을 만들고 테스트해 신뢰할 수 있게 학습하는 방식이 이상적임
  • 나도 비슷하게 생각함
    커넥터 생태계는 이해하기 쉽고 마케팅하기 좋지만, 근본적으로는 잘못된 패러다임 같음

• 작은 로컬 오케스트레이터 모델이 있으면 좋겠다고 생각함
  전체 워크플로를 프로그램적으로 조율하기엔 비효율적인 경우가 많음
  context 오염을 줄이고 속도를 높이려면 programmatic > tiny local LLM > frontier LLM 구조가 이상적임
  작은 모델은 context를 자주 초기화하고, 필요한 결과만 큰 모델에 전달하면 됨

• AI 어시스턴트를 쓰다 보면 반복되는 패턴이 있음
  비효율적인 방법을 직접 개선하면, 몇 달 뒤 새 툴이 나와서 내 작업이 무의미해짐
  최신 기술을 쫓는 대가라고 생각함

• 언젠가 웹 전체가 수십억 개의 툴로 구성될 것 같음
  Google이 이를 인덱싱하고, Gemini가 동적으로 선택해 세상에서 행동을 수행하게 될 것임
  사실 이런 걸 Gemini 3에서 기대했음

• 여기서 말한 기능 #2는 최근 화제가 된 “툴을 직접 호출하지 않고 코드를 작성해 호출”하는 개념의 구현임
  Python sandbox에서 동작하며, API로도 접근 가능하고, 툴 호출을 일반 API 호출처럼 노출함
  Batch tool calling은 이미 우리 제품의 AI 어시스턴트 속도를 크게 높였고, 이번 기능은 그 진화형처럼 보임

• 우리 agentic builder는 단 하나의 툴만 씀 — 바로 GraphQL임
  에이전트가 쿼리를 작성해 실행하고, introspection으로 필요한 정보를 얻음
  최소한의 데이터만 받아 토큰 절약이 가능함
  50개 이상의 툴을 로드할 필요도 없고, REST API의 N+1 문제도 해결됨
  GraphQL typed schema 덕분에 에이전트가 더 나은 코드를 작성함
  예전엔 GraphQL을 좋아하지 않았지만, MCP의 현 상태를 보면 AI 에이전트에 가장 적합한 기술 중 하나라고 생각함
  자세한 내용은 이 글에 정리했음

  • 나도 비슷한 접근을 씀
    내 에이전트는 SPARQL 쿼리 하나만 수행하고, 상태는 그래프 DB뿐임
    대부분의 온톨로지가 공개되어 있어서 schema introspection이 거의 필요 없음
    구조화된 출력 덕분에 유효한 RDF만 생성하도록 제약할 수 있음
    GraphQL에서도 비슷한 방식이 가능할 듯함
  • 하지만 모든 사용 사례에 맞진 않음
    나는 웹 검색, 로컬 API 호출, Slack 통합 등 다양한 작업을 해야 해서 GraphQL 하나로는 부족함
  • GraphQL introspection은 정의가 너무 길어져 토큰 낭비가 생기거나, 여러 번 호출해야 하는 문제가 있음
  • 그래도 이건 정말 좋은 GraphQL 활용 예시임
    권한, 캐싱, mutation 문제는 있지만 선택적 context 로딩에는 큰 영향이 없음
  • 우리도 Exograph에서 같은 접근을 취함 (exograph.dev)
    LLM이 schema에 맞는 GraphQL 쿼리를 꽤 잘 작성함
    실수하더라도 에러 메시지를 잘 주면 금방 수정함
    관련 reasoning은 이 블로그 글에 있음