# Claude 고급 도구 사용 기능 공개 > Clean Markdown view of GeekNews topic #24594. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24594](https://news.hada.io/topic?id=24594) - GeekNews Markdown: [https://news.hada.io/topic/24594.md](https://news.hada.io/topic/24594.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-11-25T09:54:47+09:00 - Updated: 2025-11-25T09:54:47+09:00 - Original source: [anthropic.com](https://www.anthropic.com/engineering/advanced-tool-use) - Points: 24 - Comments: 5 ## Summary Anthropic이 **Claude Developer Platform**에 공개한 세 가지 신규 기능은 AI가 수천 개의 외부 도구를 **필요할 때만 탐색·호출·학습**하도록 설계된 고급 오케스트레이션 구조를 제시합니다. **Tool Search Tool**은 필요한 시점에만 도구 정의를 불러와 토큰 사용량을 최대 85% 줄이며, **Programmatic Tool Calling**은 코드 실행 기반 병렬 호출로 지연 시간과 비용을 동시에 절감합니다. 여기에 **Tool Use Examples**가 더해져 모델이 실제 사용 패턴을 학습함으로써 복잡한 매개변수 처리 정확도를 크게 높입니다. 거대한 에이전트 생태계를 효율적으로 제어하려는 개발자라면, 이 조합이 “AI가 도구를 다루는 방식” 자체를 어떻게 재정의하는지 주목할 만합니다. ## Topic Body - **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 예시 및 구현 가이드 제공 - 이 기능들은 단순 함수 호출을 넘어 **지능적 오케스트레이션**으로 발전하는 기반 기술로 제시됨 - 복잡한 워크플로우와 대규모 데이터 환경에서 **동적 탐색·효율적 실행·정확한 호출**을 실현하는 핵심 구성 요소로 강조됨 ## Comments ### Comment 46836 - Author: kaydash - Created: 2025-11-27T01:36:00+09:00 - Points: 1 근데 아직까지는 모델빨인것같아요 클로드가 서비스하는 모델들이여서 이렇게 잘 working하는것이지 다른모델들은 과연...싶네요 ### Comment 46807 - Author: beoks - Created: 2025-11-26T12:21:43+09:00 - Points: 1 Anthropic, Google, OpenAI 같은 기업들 중에서 Anthropic 이 가장 Agentic AI 에 가깝다는 느낌이 드네요. ### Comment 46752 - Author: neo - Created: 2025-11-25T09:54:47+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46038047) - 여러 **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 블로그 글](https://huggingface.co/blog/llchahn/ai-agents-output-schema)에 있음 - 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 에이전트에 가장 적합한 기술 중 하나라고 생각함 자세한 내용은 [이 글](https://chatbotkit.com/reflections/why-graphql-beats-mcp-for-agentic-ai)에 정리했음 - 나도 비슷한 접근을 씀 내 에이전트는 **SPARQL 쿼리** 하나만 수행하고, 상태는 그래프 DB뿐임 대부분의 온톨로지가 공개되어 있어서 schema introspection이 거의 필요 없음 구조화된 출력 덕분에 유효한 RDF만 생성하도록 제약할 수 있음 GraphQL에서도 비슷한 방식이 가능할 듯함 - 하지만 모든 사용 사례에 맞진 않음 나는 웹 검색, 로컬 API 호출, Slack 통합 등 다양한 작업을 해야 해서 GraphQL 하나로는 부족함 - GraphQL introspection은 정의가 너무 길어져 **토큰 낭비**가 생기거나, 여러 번 호출해야 하는 문제가 있음 - 그래도 이건 정말 좋은 GraphQL 활용 예시임 권한, 캐싱, mutation 문제는 있지만 **선택적 context 로딩**에는 큰 영향이 없음 - 우리도 **Exograph**에서 같은 접근을 취함 ([exograph.dev](https://exograph.dev)) LLM이 schema에 맞는 GraphQL 쿼리를 꽤 잘 작성함 실수하더라도 에러 메시지를 잘 주면 금방 수정함 관련 reasoning은 [이 블로그 글](https://exograph.dev/blog/exograph-now-supports-mcp#comparing-with-alternatives)에 있음 ### Comment 46765 - Author: kimjoin2 - Created: 2025-11-25T14:04:02+09:00 - Points: 2 sonnet 4.5 도 꽤나 좋다 생각했는대요 opus 4.5 는 더 좋은 것 같아요. 우와. ### Comment 46783 - Author: shakespeares - Created: 2025-11-25T21:52:13+09:00 - Points: 1 - Parent comment: 46765 - Depth: 1 그래요? 어떤점이 주로 그런가요?