Claude API 도구 변경 베타: 프롬프트 캐시를 깨지 않고 에이전트 권한을 줄이는 방법

Anthropic의 2026년 7월 24일 Claude Platform release notes에는 실무 개발자가 놓치기 쉬운 변경이 들어 있다. Mid-conversation tool changes가 beta로 들어갔고, 대화 중 턴 사이에 도구를 추가하거나 제거하면서 prompt cache를 유지할 수 있게 됐다. 대상은 Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, Claude Opus 5이며, 요청에는 mid-conversation-tool-changes-2026-07-01 beta header가 필요하다.

이 기능은 겉으로 보기엔 API 편의 기능이다. 하지만 에이전트 운영 관점에서는 권한 관리 방식이 바뀐다. 지금까지 많은 팀은 대화 시작 시점에 가능한 모든 도구를 모델에 넘겼다. 그래야 나중에 필요할 때 도구를 쓸 수 있기 때문이다. 문제는 필요 없는 도구까지 열어두면 공격면과 비용이 커진다는 점이다.

왜 대화 중 도구 변경이 중요한가

에이전트는 작업 단계마다 필요한 권한이 다르다. 고객지원 AI를 예로 들면 초기 단계에서는 고객 문의 읽기와 정책 검색이면 충분하다. 환불 가능성이 확인된 뒤에야 주문 조회가 필요하고, 실제 환불 실행은 사람 승인 이후에만 열려야 한다.

기존 구조에서는 세 가지 문제가 있었다.

• 모든 도구를 처음부터 제공해 tool 목록이 커진다.
• 도구 목록이 바뀌면 prompt cache가 깨져 비용과 latency가 늘 수 있다.
• 권한을 줄이려면 새 대화를 시작하거나 복잡한 세션 재구성이 필요하다.

Mid-conversation tool changes는 이 문제를 줄인다. 대화 흐름은 유지하면서 다음 턴에 필요한 도구만 조정할 수 있다. 특히 prompt cache를 유지할 수 있다는 점이 중요하다. 긴 시스템 프롬프트, 정책 문서, 도구 설명이 들어간 에이전트에서는 cache hit 여부가 비용에 직접 영향을 준다.

권한은 역할이 아니라 작업 단계 기준으로 열어야 한다

많은 서비스가 “관리자”, “상담원”, “사용자”처럼 역할 기반으로 도구를 나눈다. 이것도 필요하지만 충분하지 않다. 같은 상담원이라도 현재 작업이 단순 문의인지, 개인정보 변경인지, 환불 승인인지에 따라 도구가 달라져야 한다.

권장 모델은 stage-based permissions다.

이렇게 하면 모델이 실수하거나 외부 문서에 악성 지시가 섞여도 실행 가능한 행동 범위가 좁아진다. 프롬프트로 “환불하지 마”라고 말하는 것보다 환불 도구를 아예 제공하지 않는 것이 더 강한 통제다.

Prompt cache를 유지하려면 도구 설명도 관리해야 한다

도구 변경 기능이 있어도 tool schema를 매 턴 무질서하게 바꾸면 캐시 이점이 줄어든다. 따라서 도구를 설계할 때 stable한 부분과 dynamic한 부분을 분리해야 한다.

실무 팁은 다음과 같다.

• 자주 쓰는 read-only 도구 설명은 안정적으로 유지한다.
• 위험한 write 도구는 단계가 열릴 때만 추가한다.
• 도구 이름과 파라미터 schema를 자주 바꾸지 않는다.
• 사용자별 권한은 도구 설명에 긴 문장으로 넣지 말고 서버에서 검증한다.
• cache hit율, 입력 토큰, 첫 토큰 latency를 같이 측정한다.

모델에게 “이 사용자는 환불 권한이 있습니다”라고 말하는 것은 보조 정보일 뿐이다. 실제 권한 검사는 서버가 해야 한다. 모델이 잘못 판단해도 서버가 막아야 운영 사고가 나지 않는다.

Server-side fallback default 모드도 같이 봐야 한다

같은 release notes에는 fallbacks parameter의 default mode도 beta로 추가됐다. Anthropic 권장 fallback 모델을 refusal category 기준으로 적용하는 방식이며 server-side-fallback-2026-07-01 beta header가 필요하다. 이것 역시 운영 기능이다.

모델이 거절하거나 실패했을 때 클라이언트가 직접 다른 모델을 호출하면 구현은 유연하지만 로깅과 정책 일관성이 깨질 수 있다. 서버 측 fallback은 실패 처리 경로를 더 표준화할 수 있다. 다만 무조건 켜면 안 된다. fallback 모델이 원래 모델보다 약하거나 동작이 다르면, 같은 요청에서 다른 정책 판단이 나올 수 있기 때문이다.

따라서 fallback은 다음 케이스부터 제한적으로 쓰는 편이 좋다.

• 형식 오류 재시도
• 낮은 위험도의 요약·분류 작업
• 일시적 refusal를 사람이 검토하기 전 보조 답변 생성
• SLA가 중요한 내부 도구

반대로 법률, 의료, 보안, 결제처럼 실패 비용이 큰 작업은 fallback 결과를 바로 사용자에게 내보내지 말고 검토 상태로 보내야 한다.

구현 시나리오: 고객지원 에이전트

예를 들어 SaaS 고객지원 에이전트를 만든다고 하자. 첫 턴에는 search_policy, summarize_ticket만 제공한다. 모델이 주문 확인이 필요하다고 판단하면 다음 턴에 lookup_order를 추가한다. 환불 조건이 맞으면 사용자에게 환불 제안을 작성하지만, execute_refund는 아직 제공하지 않는다. 상담원이 승인 버튼을 누른 다음 턴에서만 execute_refund를 추가한다. 실행 후에는 다시 쓰기 도구를 제거한다.

이 구조의 장점은 명확하다. 모델이 초기 단계에서 환불을 실행하려고 해도 도구가 없다. 외부 문서가 악성 지시를 넣어도 사용 가능한 행동이 제한된다. 동시에 대화와 캐시는 유지되므로 사용자는 흐름이 끊겼다고 느끼지 않는다.

바로 적용할 체크리스트

Claude API를 운영 중인 팀은 다음을 점검하면 된다.

1. 현재 에이전트에 처음부터 모든 도구를 넘기고 있는지 확인한다.
2. 도구를 read-only, write, destructive, external send로 분류한다.
3. 작업 단계를 정의하고 단계별 허용 도구 목록을 만든다.
4. 위험 도구는 승인 이벤트 이후 턴에서만 추가한다.
5. 도구 제거 후에도 모델이 해당 액션을 시도하는지 eval로 확인한다.
6. prompt cache hit율과 latency를 도구 변경 전후로 측정한다.
7. server-side fallback은 낮은 위험도 작업부터 켜고 로그를 분리한다.
8. 모든 실제 권한 검사는 모델이 아니라 서버에서 최종 수행한다.

Mid-conversation tool changes는 화려한 기능은 아니다. 하지만 운영 AI에서는 이런 기능이 더 중요하다. 에이전트가 필요한 순간에 필요한 도구만 갖게 만들 수 있다면, 비용과 위험을 동시에 줄일 수 있다. 장기 실행 AI 에이전트를 운영한다면 프롬프트 개선보다 먼저 도구 권한 수명주기를 설계해야 한다.