프롬프트 캐시가 싸졌다고 그대로 고정해도 될까? 6칸 컨텍스트 릴리스 카드

핵심 요약

• 재사용 대상은 안정적인 묶음으로 한정하고, 요청마다 달라지는 입력은 분리합니다.
• 정책, 도구 정의, 참조 문서, 모델 동작이 바뀌면 이전 묶음의 유효성을 다시 판단합니다.
• 승격 전에는 같은 golden task를 캐시 적중과 강제 미적중 조건에서 실행해 필수 행동·금지 행동·지연·비용을 함께 기록합니다.
• 품질 불일치가 보이면 재시도 횟수를 늘리기보다 이전 검증 묶음으로 되돌리고 사람 검토를 우선합니다.

왜 캐시 적중만으로는 충분하지 않을까요?

AI 에이전트가 길고 반복되는 지시문, 도구 설명, 참조 문서를 자주 사용하면 같은 컨텍스트를 재사용하는 방식이 유용할 수 있습니다. Anthropic의 공식 문서도 프롬프트 구조에서 재사용 가능한 부분과 매 요청에 달라지는 부분을 구분해 다루는 방식을 설명합니다. 다만 재사용 자체는 답변이 최신 규칙을 따랐는지, 필요한 도구를 올바르게 골랐는지까지 보증하지는 않습니다.

문제는 보통 조용히 시작됩니다. 예를 들어 승인 규칙이 바뀌었는데 이전 정책 문서가 묶음에 남아 있으면, 에이전트는 빠르고 일관된 답을 내면서도 오래된 기준을 반복할 수 있습니다. 이런 상황에서 비용이나 응답 시간만 보고 성공으로 처리하면 권한, 신뢰성, 결과 품질의 문제가 뒤늦게 드러납니다.

무엇을 묶고 무엇을 분리할까요?

첫 단계는 “무엇이 거의 변하지 않는가”를 정하는 일입니다. 안정적인 지시문, 검증된 도구 정의, 특정 버전의 참조 문서는 하나의 묶음 후보가 될 수 있습니다. 반대로 사용자의 이번 요청, 주문 번호, 권한 상태, 최신 작업 데이터처럼 요청마다 달라지는 값은 묶음 밖에 둬야 합니다. 이 경계가 흐리면 갱신해야 할 변경과 단순 입력 변화를 같은 방식으로 다루게 됩니다.

도구 정의 자체를 안정적으로 관리하는 방법은 도구 정의를 안정적으로 관리하는 기본 원칙에서 더 자세히 다뤘습니다. 이번 글의 초점은 그 정의를 포함한 전체 묶음을 언제 재사용하고 언제 새 릴리스로 취급할지에 있습니다.

FLOWIT 6칸 컨텍스트 릴리스 카드

재사용 여부를 말로만 합의하면 담당자가 바뀔 때 기준도 사라집니다. 아래 여섯 칸을 한 장의 기록으로 남기면 비용, 권한, 신뢰성, 운영 책임을 함께 확인할 수 있습니다.

hit/miss 비교와 무효화 결정

새 묶음을 바로 운영에 넣기보다, 같은 golden task를 두 번 실행해 비교합니다. 한 번은 재사용이 가능한 조건에서, 다른 한 번은 새 컨텍스트로 처리한 조건에서 실행합니다. 두 결과가 모두 필수 행동을 만족하고 금지 행동이 없을 때에만 비용과 지연의 차이를 의사결정 자료로 사용합니다. 품질이 다르면 더 저렴한 쪽을 고르는 문제가 아니라, 변경 내용을 다시 검토하는 문제입니다.

재현 가능한 작은 예시

1. “승인이 필요한 요청은 보류하고 담당자에게 넘긴다”는 필수 행동과 “승인 없이 외부 쓰기를 실행하지 않는다”는 금지 행동을 golden task에 둡니다.
2. 정책 문서 버전을 바꾼 뒤, 같은 요청을 재사용 조건과 새 컨텍스트 조건에서 각각 실행합니다.
3. 두 결과가 같은 보류 판단과 근거 문서 버전을 가리키는지 확인합니다. 한쪽이라도 외부 쓰기를 시도하거나 이전 문서를 인용하면 승격하지 않습니다.
4. 검증된 이전 묶음으로 되돌리고, 바뀐 문서·도구·정책을 기록한 뒤 다시 비교합니다.

바로 쓰는 배포 전 점검표

• 변경된 문서, 도구, 정책을 묶음 기록에 남겼나요?
• golden task마다 필수 행동과 금지 행동을 정했나요?
• 재사용 조건과 새 컨텍스트 조건의 결과를 같은 기준으로 비교했나요?
• 강제로 재검증하게 만드는 경로를 한 번 실제로 시험했나요?
• 되돌리기 권한과 담당자, 검토 채널이 정해졌나요?

컨텍스트를 바꾼 뒤 상태가 보존되는지까지 확인해야 한다면 컨텍스트 전환 뒤 상태를 수용하는 방법도 함께 보세요. 모델을 교체하는 상황에는 모델 변경을 운영 이벤트로 다루는 런북이 다음 판단에 도움이 됩니다.

자주 묻는 질문

프롬프트 캐시를 쓰면 항상 비용이 줄어드나요?

반복되는 안정적 컨텍스트가 있을 때 비용과 지연 측면에서 이점이 생길 수 있지만, 실제 효과는 사용 패턴과 제공자의 현재 정책에 따라 달라집니다. 먼저 품질 기준을 통과한 뒤 같은 작업 조건에서 관측해야 합니다.

문서가 한 줄만 바뀌어도 항상 다시 검증해야 하나요?

모든 편집을 같은 위험도로 볼 필요는 없습니다. 다만 답변의 사실, 권한, 승인 절차, 도구 호출에 영향을 주는 변경이라면 새 검증이 필요합니다. 영향이 없는 서식 수정인지도 기록으로 설명할 수 있어야 합니다.

캐시 적중 결과와 새 컨텍스트 결과가 조금 다르면 어떻게 하나요?

먼저 필수 행동과 금지 행동 기준에 영향을 주는 차이인지 확인하세요. 판단이나 근거가 달라졌다면 승격하지 말고 이전 검증 묶음으로 되돌린 뒤 변경 원인을 검토하는 편이 안전합니다.

누가 되돌리기 결정을 해야 하나요?

운영 책임자와 권한을 가진 담당자를 미리 정해 두는 것이 좋습니다. 특히 외부 시스템에 쓰는 작업은 결과를 만든 모델보다 업무 책임자가 보류·되돌리기 기준을 승인해야 합니다.

참고 자료

• Anthropic Prompt caching 문서 — 재사용 가능한 프롬프트 부분과 요청별 내용을 구분하는 공식 안내입니다.
• Claude Platform release notes — 모델·플랫폼 변경을 확인할 때 참고할 공식 변경 기록입니다.
• FLOWIT: AI 에이전트 도구 정의를 안정적으로 운영하는 5단계 — 도구 계약을 관리하는 실무 원칙을 보완합니다.