현장에서 agent 프로젝트가 막히는 지점은 모델 성능보다 도구 목록이다. 처음에는 GitHub, Jira, Slack, DB, 사내 API를 붙이면 좋아 보인다. 곧 프롬프트 앞부분이 도구 설명서로 채워진다. 사용자는 한 문장을 입력했는데 agent는 이미 수십 개 schema를 읽고 있다. 이 구조에서는 좋은 모델도 느려지고, 비싼 context를 잡아먹고, 비슷한 이름의 도구 사이에서 잘못 고른다.
Anthropic은 2025년 11월 글에서 5개 서버 58개 도구가 약 55K token을 conversation 시작 전에 소비하고, 최적화 전 도구 정의가 134K token까지 올라간 사례를 공개했다. 같은 글은 Tool Search Tool, Programmatic Tool Calling, Tool Use Examples를 통해 도구를 사전에 모두 싣지 않고 필요할 때 찾는 방향을 제시했다. 이 흐름은 단순한 비용 절감이 아니다. agent 제품의 기본 구조가 바뀌고 있다는 신호다.
도구 과잉은 성능 문제가 아니라 설계 결함이다
MCP 최신 명세는 서버가 도구를 노출하고, client가 tools/list로 발견하고, tools/call로 실행하는 구조를 정의한다. 도구 정의에는 이름, 설명, inputSchema, 선택적 outputSchema, annotation, execution 정보가 포함된다. 이 자체는 문제 아니다. 문제는 발견한 모든 schema를 모델 context에 올리는 client 구현이다.
Lazy tool hydration의 원칙은 명확하다. 모델에게 모든 도구를 보여주지 말고, 도구를 찾는 방법만 먼저 준다.
도구는 지식 문서가 아니다. 도구는 실행 가능한 계약이다. 계약 전체를 회의 시작 전에 낭독할 필요가 없다. 필요한 조항만 꺼내면 된다.
| 기존 방식 | Lazy tool hydration |
|---|---|
| 연결된 MCP 도구 schema를 upfront로 주입 | 검색용 catalog와 최소 router만 주입 |
| 모델이 긴 도구 목록에서 직접 선택 | 검색·파일시스템이 후보를 좁힘 |
| 중간 결과가 context에 누적 | code execution에서 가공 후 요약만 반환 |
| 도구 추가 때마다 prompt가 무거워짐 | 도구 추가는 index 갱신 문제로 격리 |
Schema는 prompt가 아니라 filesystem에 둔다
우리가 권하는 구조는 단순하다. 첫 context에는 세 가지만 둔다. 첫째, 업무 목표와 금지 행위. 둘째, tool_catalog.search 같은 검색 도구. 셋째, schema 파일을 읽고 실행 계획을 검증하는 code execution 환경이다.
각 MCP 도구는 별도 파일로 정규화한다. 예를 들면 servers/jira/create_issue.schema.json, servers/slack/search_messages.schema.json, servers/github/list_pull_requests.schema.json처럼 둔다. index에는 전체 schema가 아니라 이름, 서버, 짧은 설명, tag, 권한 범위, 위험 등급, schema 경로, 예시 경로만 넣는다.
실행 순서는 이렇게 고정한다.
- 사용자 의도를 작게 분해한다.
- catalog 검색으로 후보 도구를 좁힌다.
- 필요한 schema 파일만 읽어 context에 hydrate한다.
- 반복·필터·조인은 code execution에서 처리한다.
- 최종 판단과 사용자 설명만 모델 context로 돌린다.
Anthropic의 2025년 11월 MCP code execution 글도 같은 방향을 짚는다. MCP 서버를 직접 tool call 목록으로 노출하는 대신 code API나 파일 트리로 표현하면 agent가 필요한 도구만 불러오고, 대용량 결과를 실행 환경에서 처리한 뒤 필요한 요약만 모델에 전달한다.
운영 기준이 없으면 lazy loading도 위험해진다
Lazy tool hydration은 context를 아끼는 기법으로만 보면 실패한다. 운영 기준이 있어야 한다. 특히 대기업 환경에서는 도구 검색, schema 주입, 실행 권한이 모두 audit 대상이다.
AX Ops에서는 네 가지를 먼저 정한다.
- Hydration budget: 한 turn에 주입 가능한 schema 수와 총량을 제한한다.
- Risk tier: 조회, 변경, 외부 전송, 결제성 실행을 분리한다.
- Approval rule: 민감 도구는 human approval 없이는 실행하지 않는다.
- Drift control: MCP의
listChangednotification이나 registry 변경을 index 재생성 트리거로 삼는다.
OpenAI도 2026년 4월 Agents SDK 업데이트에서 MCP, progressive disclosure, filesystem tool, shell execution, sandbox orchestration을 agent harness의 공통 primitive로 묶었다. 방향은 분명하다. agent 제품은 이제 모델 호출 코드가 아니라 실행 harness다.
참고: Context가 아니라 harness를 설계한다
요약하면 Lazy tool hydration은 도구를 숨기는 설계가 아니다. 도구를 늦게, 작게, 검증 가능하게 노출하는 설계다. MCP가 도구 연결의 표준이면, hydration layer는 운영 정착의 표준이 된다.
참고 자료:
- Anthropic, Introducing advanced tool use on the Claude Developer Platform, 2025-11: https://www.anthropic.com/engineering/advanced-tool-use
- Anthropic, Code execution with MCP: building more efficient AI agents, 2025-11: https://www.anthropic.com/engineering/code-execution-with-mcp
- Model Context Protocol Specification, Tools, version 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
- OpenAI, The next evolution of the Agents SDK, 2026-04: https://openai.com/index/the-next-evolution-of-the-agents-sdk/
- MCPToolBench++, arXiv, 2025-08: https://arxiv.org/abs/2508.07575
AX LABS는 agent를 데모가 아니라 운영 단위로 설계한다. 도구 catalog, hydration rule, approval, logging까지 한 번에 묶어야 한다. 다음 PoC에서는 모델보다 harness 설계를 먼저 보라. 더 구체적인 전환 설계는 AX Ops 방법론 →에서 이어진다.