Claude Opus 5의 새로운 프롬프트 캐싱(prompt-caching) API는 모델이 변경되지 않은 텍스트를 다시 읽는 과정을 생략할 수 있게 하여, 채팅 방식 앱의 토큰 비용을 대폭 절감합니다. 첫 번째 요청에는 약간의 추가 비용이 발생하지만, 이후의 모든 요청은 기본 요금의 약 10분의 1 수준으로 처리되어 반복적인 비용을 일회성 비용으로 전환해 줍니다.
개발자들이 왜 동일한 단어에 대해 두 번 비용을 지불하는가
대부분의 대화형 인터페이스는 매 턴마다 전체 프롬프트를 다시 구성합니다. 사용자가 후속 질문을 할 때마다 8,000토큰의 시스템 프롬프트, 첨부된 PDF, 그리고 전체 대화 기록이 매번 함께 모델로 전달됩니다. 텍스트의 대부분이 변경되지 않음에도 불구하고 모델은 모든 토큰을 다시 처리합니다. 현재의 가격 체계에서는 이러한 중복성이 활발하게 운영되는 봇의 비용 대부분을 차지할 수 있습니다.
캐시가 비용 계산을 어떻게 바꾸는가
이 API는 정의된 중단점(breakpoint)까지의 모든 토큰 "블록"에 대해 캐시 항목을 생성합니다. 다음 요청에 동일한 블록이 앞부분에 포함되어 있으면, 서비스는 이를 다시 토큰화하는 대신 캐시에서 읽어옵니다. 가격 구성은 절감된 작업량을 반영합니다:
- 캐시 쓰기 – 5분 TTL: 기본 가격의 1.25배
- 캐시 쓰기 – 1시간 TTL: 기본 가격의 2배
- 캐시 읽기 (hit): 기본 가격의 0.1배
실제로 새로운 블록에 대한 첫 호출은 일반적인 요청보다 비용이 약간 더 많이 듭니다. 하지만 이후 캐시를 활용하는 모든 호출은 90% 더 저렴하므로, 대화가 깊어질수록 순 지출이 급격히 감소합니다.
프롬프트 구조화를 위한 "황금률"
캐시의 효율성은 정적 콘텐츠와 동적 콘텐츠를 어디에 배치하느냐에 달려 있습니다. 변하지 않는 모든 것을 앞부분에 두고, 계속해서 변하는 부분은 뒷부분으로 미루십시오. 권장되는 순서는 다음과 같습니다:
- Tools – 모델이 호출할 수 있는 외부 함수의 정의.
- System instructions – 모델이 따라야 할 상위 수준의 동작 지침.
- Documents – PDF, 지식 베이스 또는 정책 발췌본과 같은 긴 컨텍스트.
- User questions – 매 턴마다 변하는 실시간 쿼리.
중단점 이전의 토큰을 하나라도 수정하면 캐시 항목이 무효화되며, 모델은 그 이후의 모든 내용을 다시 처리해야 합니다.
반드시 준수해야 할 숨겨진 제한 사항
- 최소 블록 크기 – Opus 5는 최소 512토큰을 포함하는 블록만 캐싱합니다. 이보다 작은 블록은 캐시를 전혀 활용할 수 없습니다.
- 타임스탬프 버그 – 캐싱된 블록 내에 계속 변하는 타임스탬프를 삽입하면 블록의 텍스트가 정확히 일치하지 않으므로 반드시 캐시 미스(miss)가 발생합니다.
- 20개 블록 조회 범위 – 서비스는 일치하는 항목을 찾기 위해 마지막 20개의 블록만 스캔합니다. 대화가 빠르게 진행되는 긴 세션은 캐시 범위를 벗어날 수 있습니다.
- 병렬 요청 – 동일한 요청을 동시에 여러 개 보내면 모두 캐시 미스가 발생합니다. 캐시는 첫 번째 요청이 완료된 후에 생성되기 때문입니다. 단일 호출로 캐시를 먼저 채운(warm) 다음 나머지를 실행하십시오.
API 응답에서 절감액 확인하기
각 응답에는 세 가지 토큰 카운터가 보고됩니다:
cache_read_input_tokens– 캐시 히트(hit)를 통해 가져온 토큰.cache_creation_input_tokens– 이번 요청에서 캐시에 기록된 토큰.input_tokens– 캐싱되지 않은 새로운 토큰.
세 숫자를 모두 더하면 해당 턴에서 모델이 고려한 총 토큰 수가 됩니다. 만약 두 캐시 필드가 모두 0이라면 요청이 캐시를 활용하지 못한 것이므로, 블록 크기와 중단점 위치를 확인하십시오.
요약: 변하지 않는 컨텍스트를 앞부분에 배치하고 Claude Opus 5의 프롬프트 캐싱 API를 활용하면, 반복되는 토큰 비용을 일회성 비용으로 전환할 수 있습니다. 결과적으로 동일한 시스템 프롬프트나 문서 세트를 반복적으로 참조하는 모든 챗봇의 비용을 획기적으로 줄일 수 있습니다. 단, 토큰 하한선을 준수하고, 캐싱된 블록 내에 가변적인 마커를 피하며, 캐시 적용 대상 콘텐츠를 20개 블록 범위 내로 유지해야 합니다.
