대부분의 에이전트는 사용하지 않는 도구에 대해서도 비용을 청구받습니다. 한 번이 아니라, 매 턴(turn)마다 말이죠.

그 메커니즘은 놓치기 쉬울 정도로 매우 단순합니다. 모델에 도구 세트를 제공할 때, 모든 도구에 대한 전체 JSON 스키마(JSON schema)가 요청에 포함됩니다. 이름, 설명, 파라미터 타입(parameter types), 열거형 값(enum values), 중첩된 객체(nested objects) 등 모든 것이 포함됩니다. 모델은 이 모든 것을 읽고, 하나를 선택하여 호출합니다. 다음 턴이 되면 전체 카탈로그가 다시 전송됩니다. API는 상태가 없는(stateless) 방식이며, 도구 목록이 요청의 일부이기 때문입니다.

도구가 8개라면 이는 눈에 띄지 않습니다. 하지만 도구가 200개라면 입력 토큰(input token) 비용을 압도하고, 실제로 중요한 컨텍스트(context)를 밀어내며, — 더 고통스러운 부분은 — 도구 선택 정확도를 측정 가능한 수준으로 저하시킵니다.

Microsoft Foundry는 바로 이 문제를 해결하기 위해 Build 2026에서 Tool Search를 출시했습니다. 이는 이해할 가치가 있으며, Foundry를 넘어 이해할 가치가 있습니다. 동일한 실패 모드(failure mode)가 MCP(Model Context Protocol)를 많이 사용하는 모든 에이전트에서 나타나며, 그 완화 방법 또한 일반화될 수 있기 때문입니다.

문제의 형태

모델이 올바르게 사용할 수 있을 만큼 충분히 상세한 도구 스키마는 파라미터 설명(parameter descriptions)을 고려할 때 한 번에 150~400 토큰을 소모합니다. 저렴한 스키마는 잘못된 도구 호출(tool calls)을 생성하므로, 팀들은 관대한 스키마를 작성합니다. 이는 옳은 결정이지만 동시에 비용이 많이 드는 결정이기도 합니다.

이를 카탈로그 전체와 여러 턴에 걸쳐 곱해 보면 다음과 같습니다:

tokens_per_turn  = base_prompt + conversation_history + (n_tools × avg_schema_tokens)
tokens_per_task  = tokens_per_turn × turns

스키마당 250 토큰인 200개 도구 카탈로그를 대상으로 12턴의 작업을 수행하면, 도구 정의에만 약 600,000개의 입력 토큰을 소비합니다. 대화 자체는 20,000 토큰일 수 있습니다. 당신은 모델이 이미 11번이나 선택하지 않기로 결정한 카탈로그를 다시 읽는 데 압도적인 비용을 지불하고 있는 것입니다.

토큰 비용은 눈에 보이는 절반에 불과합니다. 보이지 않는 나머지 절반은 더 심각합니다. 카탈로그가 커짐에 따라, 서로 다른 팀, 서로 다른 MCP (Model Context Protocol) 서버, 서로 다른 코드베이스 시대에서 유래한 get_customer, get_customer_profile, fetch_customer_record, lookup_account_by_customer와 같은 유사한 중복 항목들이 축적됩니다. 선택 정확도가 떨어지는 이유는 모델이 멍청해져서가 아니라, 모델에게 진정으로 모호한 메뉴를 건네주었기 때문입니다.

도구 검색 (Tool Search)이 변화시키는 것

Foundry는 평면적인 리스트(flat list) 대신, tool_search와 call_tool이라는 두 가지 메타 도구(meta-tools)를 노출합니다. 에이전트는 자신이 무엇을 하려고 하는지 설명하고, 순위가 매겨진 소수의 후보군을 돌려받은 뒤, 그중 하나를 호출합니다.

이 방식의 트레이드오프(trade-off)는 카탈로그 전체를 전송하지 않는 대신 검색을 위한 왕복(round-trip) 과정을 거치는 것입니다. 도구가 약 30개를 넘어가면 이 트레이드오프는 매우 유리해집니다. 그 미만일 경우에는 대개 유리하지 않으며, 이는 이 방식을 도입하기 전에 솔직하게 고려해야 할 첫 번째 사항입니다.

전략 비교

도구 검색 (Tool Search)이 유일한 정답은 아니며, 항상 옳은 것도 아닙니다.

핀 고정 (Pinning)은 사람들이 건너뛰곤 하지만 결코 건너뛰어서는 안 되는 부분입니다. Foundry는 중요한 도구를 핀으로 고정하여 검색 왕복 과정을 완전히 건너뛰게 할 수 있으며, 팀이 실제로 해당 도구를 어떻게 생각하는지에 대한 컨텍스트 (context)를 추가하고, 자주 사용되는 도구를 자동으로 고정할 수 있게 해줍니다. 실제로 소수의 도구가 대부분의 호출을 차지합니다. 그러한 도구들을 고정하고 나머지는 검색(retrieve)하도록 설정하면, 일반적인 경로에서 검색 지연 시간(retrieval latency)을 지불하지 않으면서도 평면적인 토큰 비용을 유지할 수 있습니다.

엔드 투 엔드 (End-to-end) 구축하기

두 개의 명령어를 통해 도구 상자(toolbox)가 부착된 호스팅 에이전트를 구성할 수 있습니다.

mkdir my-toolbox-agent && cd my-toolbox-agent

azd ai agent init \
...

그 다음 샘플의 디스크립터 (descriptor)를 사용하여 툴박스 (toolbox)를 생성합니다:

azd ai toolbox create my-toolbox --from-file ./src/toolbox-agent/toolbox.yaml

그러면 에이전트가 바인딩 (bind)하게 될 버전 관리된 MCP 엔드포인트 (endpoint)가 출력됩니다:

제가 20분을 허비하며 발견한 주의 사항 하나를 말씀드리자면, --project-endpoint를 명시적으로 전달하더라도 azd ai toolbox create를 실행하려면 로컬 azd 프로젝트와 환경 (environment)이 필요합니다. 만약 azd ai agent init부터 시작하지 않는다면, 먼저 azd init --minimal을 실행하고 환경에 엔드포인트를 설정하십시오:

azd init --minimal
azd env set FOUNDRY_PROJECT_ENDPOINT https://<account>.services.ai.azure.com/api/projects/<project>

toolbox.yaml은 카탈로그 (catalog)와 그 검색 동작 (search behaviour)이 선언되는 곳입니다. 아래 구조는 예시일 뿐입니다. 프리뷰 스키마 (preview schemas)는 변경될 수 있으므로, 복사하기 전에 현재 샘플을 확인하십시오:

# toolbox.yaml — 예시 구조, 현재 샘플과 대조하여 확인하십시오
name: my-toolbox
description: Order operations, customer lookup, and fulfilment tools
...

마지막의 searchContext가 실제로 중요한 역할을 수행합니다. 도구 검색 (Tool Search)에서는 검색 품질 (retrieval quality)이 승패를 결정짓는 핵심이며, 검색은 여러분이 작성한 설명 (descriptions)을 바탕으로 실행됩니다. "이것을 사용하지 말고 저것을 사용하라"와 같은 명시적인 부정적 지침 (explicit negative)은 그곳에 작성할 수 있는 가장 가치 있는 내용입니다. 왜냐하면 유사한 항목들이 거의 중복될 때 바로 선택 오류가 발생하기 때문입니다.

순차적인 턴 (A turn, in sequence)

측정하기, 제 말만 믿지 마십시오

이 주제를 단순히 활성화하는 것을 넘어 글로 쓸 가치가 있는 이유는, 그 성과가 측정 가능하며 성과의 크기가 전적으로 여러분의 카탈로그에 달려 있기 때문입니다. 무엇인가를 변경하기 전에 트레이싱 (tracing)을 연결하여 기준점 (baseline)을 확보하십시오.

pip install azure-ai-projects azure-identity opentelemetry-sdk azure-core-tracing-opentelemetry

from azure.core.settings import settings
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
...

실행하기 전에 AZURE_EXPERIMENTAL_ENABLE_GENAI_TRACING=true를 설정하면, 프롬프트(prompts), 도구 호출(tool calls), 모델 응답(model responses) 등 모든 턴(turn)이 토큰 사용량(token usage)이 첨부된 스팬(span)으로 나타납니다. ConsoleSpanExporter를 Azure Monitor exporter로 교체하면 동일한 스팬들이 Foundry 포털의 관측성(Observability) 탭에 기록됩니다.

이제 비교를 실행해 보세요. 아래의 하네스(harness)는 의도적으로 단순하게 설계되었습니다. 고정된 작업 세트와 두 가지 설정을 사용하여 스팬을 집계합니다.

import os
import json
from dataclasses import dataclass, field
...

평탄한 카탈로그(flat catalog)를 대상으로 실행한 다음, 도구 검색(Tool Search)을 켠 동일한 카탈로그를 대상으로, 그리고 상위 5개 도구를 고정(pinned)한 상태로 다시 실행해 보세요. 세 가지 숫자와 하나의 표를 통해, 이것이 블로그 포스트의 카탈로그가 아닌 당신의 카탈로그를 위해 수행할 가치가 있는 일인지 알 수 있을 것입니다.

도움이 되지 않는 경우

실패 모드(failure modes)는 실제로 존재하므로, 한계점에 대해 솔직하게 말씀드리겠습니다.

작은 카탈로그는 개선되지 않고 오히려 악화됩니다. 도구가 약 30개 미만인 경우, 사용하지도 않을 토큰을 아끼기 위해 왕복 시간(round-trip)과 검색 실패 모드(retrieval failure mode)를 추가하는 셈이 됩니다. 그러지 마세요.

검색 누락(Retrieval misses)은 조용하고 혼란스럽습니다. 평탄한 리스트(flat-list) 방식의 에이전트가 잘못된 도구를 선택하면, 트레이스(trace)에는 에이전트가 올바른 도구를 고려한 것으로 나타납니다. 도구 검색(Tool Search)이 올바른 도구를 전혀 제시하지 못할 때, 트레이스에는 에이전트가 주어진 정보 내에서 합리적으로 행동한 것으로 나타납니다. 디버깅의 초점이 "왜 잘못 선택했는가"에서 "왜 이것이 후보군(candidate set)에 없었는가"로 옮겨지는데, 이는 다른 차원의 기술이며 파악하기가 더 어렵습니다.

지연 시간(Latency)이 잘못된 곳으로 이동합니다. 추가적인 왕복 시간(round-trip)이 유용한 작업이 시작되기 전인 턴의 시작 부분에 발생합니다. 비용이 들지 않는 백그라운드 에이전트라면 상관없지만, 사람이 지켜보고 있는 작업이라면 공격적으로 도구를 고정(pin)하세요.

이제 당신의 설명(descriptions)은 하중을 견디는 인프라(load-bearing infrastructure)입니다. 모호한 searchContext는 예전에 가끔 잘못된 도구 호출(tool calls)을 유발하는 정도의 비용만 발생했습니다. 하지만 이제는 기능적으로 보이지 않는 도구들을 소모하는 비용을 발생시킵니다. API 계약(API contract)을 위해 예산을 책정하듯, 이 도구들을 위해서도 예산을 책정하세요.

일반적인 교훈

Foundry를 제외하더라도 이 원칙은 유효합니다: 매 턴(turn)마다 전송하는 모든 것은 매 턴마다 그 자리에 있을 가치를 증명해야 합니다. 도구 스키마(Tool schemas)는 통합(integration) 수가 늘어남에 따라 함께 커지기 때문에 이 벽에 가장 먼저 부딪혔습니다. 하지만 동일한 감사(audit) 원칙이 다음 항목들에도 적용됩니다: 6개월 동안 아무도 읽지 않은 지침들이 쌓여 있는 시스템 프롬프트(system prompts), 더 이상 실행하지 않는 모델 버전을 위해 유지되고 있는 퓨샷 예시(few-shot examples), 그리고 내용을 다듬는 것이 누군가의 3분기 과제라는 이유로 통째로 붙여넣기 된 검색된 컨텍스트(retrieved context).

도구 검색(Tool Search)은 '방송(broadcast) 대신 검색(retrieve)하라'는 지루한 아이디어를 잘 구현한 사례입니다. 이를 채택해야 하는 이유는 이것이 새로운 기술이기 때문이 아닙니다. 단 한나절 만에 그 차이를 측정할 수 있으며, 그 수치가 보통 예상보다 크기 때문입니다.

이 분야의 프리뷰 API(Preview APIs)는 빠르게 변화하고 있습니다. 위에서 언급된 azd 명령어와 트레이싱(tracing) 설정은 2026년 6월 Foundry 릴리스 기준이며, 배포 전 현재 샘플을 통해 스키마 수준의 세부 사항을 반드시 확인하십시오.

참고 문헌

참고 문헌

1. Brady, N. "Microsoft Foundry에서 새로운 기능 (What's New in Microsoft Foundry) | 2026년 6월." Microsoft Foundry Blog — https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/
2. "Microsoft Foundry의 툴박스와 루틴 (Toolboxes and Routines in Microsoft Foundry)." Microsoft Foundry Blog — https://devblogs.microsoft.com/foundry/toolbox-build-26/
3. "Microsoft Foundry에서 새로운 기능 (What's new in Microsoft Foundry) | 빌드 에디션." Microsoft Foundry Blog — https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-build-2026/
4. "빌드 2026: 모든 프레임워크에서 AI 에이전트의 관찰 가능성(Observability)부터 ROI까지." Microsoft Foundry Blog — https://devblogs.microsoft.com/foundry/build-2026-from-observability-to-roi-for-ai-agents-on-any-framework/
5. "Microsoft Foundry, 프로덕션 에이전트를 위한 런타임, 툴링 및 거버넌스 추가." InfoQ, 2026년 6월 — https://www.infoq.com/news/2026/06/microsoft-foundry-agents/
6. "Microsoft Foundry 문서: 새로운 기능 (What's new)." Microsoft Learn — https://learn.microsoft.com/en-us/azure/foundry/whats-new-foundry