AX LABS
← 블로그 AX Ops 방법론

툴 카탈로그가 캐시를 깬다

MCP 운영의 첫 계약은 순서와 버전이다

AX LABS 5분 읽기

현장에서 에이전트 런타임을 붙여 보면 같은 일이 반복된다. PoC에서는 잘 보이던 응답 속도와 비용 구조가 운영 트래픽 앞에서 흔들린다. 원인은 모델이 아니다. 매 요청마다 조금씩 달라지는 MCP tool catalog다.

툴 하나를 추가했고, 설명 문구를 다듬었고, 권한별로 노출 목록을 바꿨다. 개발 입장에서는 작은 변경이다. 모델 입장에서는 prefix가 바뀐 새 프롬프트다. 캐시는 맞지 않는다.

캐시는 의미가 아니라 prefix를 본다

Prompt caching은 “비슷한 내용”을 재사용하지 않는다. 공급자별 구현은 다르지만 운영자가 기억할 원리는 하나다. 캐시는 반복되는 앞부분이 같을 때만 경제성이 생긴다.

Anthropic 문서는 prompt caching이 tools, system, messages 순서로 prefix를 참조한다고 설명한다. tool definition 변경은 tools cache뿐 아니라 system, messages cache까지 함께 무너뜨린다. OpenAI 문서도 static content를 앞에 두고 variable content를 뒤에 두라고 권고하며, tools 역시 동일해야 캐시 대상이 된다고 설명한다.

에이전트 런타임에서 tool catalog는 설정 파일이 아니라 비용 구조를 결정하는 prefix 계약이다.

MCP를 붙인 뒤 캐시 hit rate가 낮다면 먼저 모델을 바꾸지 않는다. tool catalog가 요청마다 동일한지 본다.

Tool catalog는 동적으로 만들수록 비싸진다

MCP는 서버가 tool을 제공하고 클라이언트가 이를 발견해 호출하는 구조다. 2025-11-25 MCP schema의 Tool에는 name, title, description, inputSchema, outputSchema, annotations 같은 필드가 있다. 이 필드들은 모델이 도구를 이해하는 재료이자 캐시 prefix의 일부가 된다.

운영에서 자주 깨지는 지점은 명확하다.

흔한 설계 운영 결과 AX Ops 설계
권한마다 tool 배열을 새로 생성 순서와 길이가 흔들림 전체 catalog 고정, 실행 단계에서 권한 검사
배포 때마다 description 자동 생성 문구 변화가 cache miss 유발 문구 변경은 버전 변경으로 관리
서버 응답 순서를 그대로 사용 런타임마다 배열 순서 변동 canonical sort 고정
실험 tool을 중간에 삽입 뒤쪽 prefix까지 변경 prefix namespace와 append-only 정책

권한 관리는 tool definition에서 하지 않는다. 실행 전 policy gate와 tool handler 내부에서 한다. 모델에게 보이는 catalog는 안정적으로 유지하고, 호출 가능 여부는 런타임에서 판단한다.

버전과 prefix를 분리해야 배포가 산다

Cache-stable catalog의 핵심은 세 가지다.

  1. 순서 고정: vendor.domain.toolName 같은 prefix를 붙이고 사전순으로 정렬한다. 사람이 보기 좋은 묶음보다 byte-level 안정성이 먼저다.
  2. 버전 고정: description, inputSchema, outputSchema가 바뀌면 catalog_version을 올린다. 몰래 고치지 않는다.
  3. prefix 고정: 공통 tool catalog, system instruction, 정적 policy를 앞에 둔다. 사용자 질문, 시간, 계정 상태, 조회 결과는 뒤에 둔다.

운영 런타임에는 catalog manifest가 필요하다. manifest에는 tool name, schema hash, description hash, owner, rollout state를 둔다. 요청 조립기는 manifest만 읽는다. MCP 서버가 응답한 순서를 그대로 프롬프트에 넣지 않는다.

이 방식은 유연성을 줄이는 일이 아니다. 변경을 배포 가능한 단위로 만드는 일이다. 카탈로그가 안정되면 캐시 hit rate, TTFT, 입력 토큰 비용을 같은 대시보드에서 관리할 수 있다.

참고와 다음 행동은 하나로 묶어라

이 주제의 결론은 단순하다. 에이전트 운영에서 prompt cache는 모델 기능이 아니라 런타임 설계의 산출물이다. MCP tool catalog를 cache-stable하게 만들지 않으면 tool이 늘어날수록 운영비와 지연이 같이 커진다.

참고 자료:

AX Ops에서는 이 작업을 prompt engineering으로 두지 않는다. catalog manifest, cache boundary, policy gate, telemetry를 한 설계로 묶는다. 다음 스프린트에서 할 일은 tool을 더 붙이는 것이 아니라 tool catalog를 계약으로 고정하는 것이다. AX Ops 방법론 →