-
[Claude][운영] prompt caching에서 긴 정책 블록은 1시간 TTL로 두고 짧은 요약·사용자 tail은 5분 TTL로 섞을 때 batch와 interactive billing 메모를 어떻게 남기나기타개발지식/풀스택개발 2026. 8. 5. 09:17
IT 리서치 노트
[Claude][운영] prompt caching에서 긴 정책 블록은 1시간 TTL로 두고 짧은 요약·사용자 tail은 5분 TTL로 섞을 때 batch와 interactive billing 메모를 어떻게 남기나
Claude prompt caching을 운영하다 보면 '긴 정책 블록은 오래 유지하고 싶고, 짧은 요약과 사용자 tail은 자주 바꾸고 싶다'는 요구가 같이 온다. 2026년 8월 5일 기준 Anthropic 공식 문서를 다시 보면 기본 TTL은 5분이고, 서로 다른 TTL을 섞을 때는 더 긴 TTL 블록이 더 앞에 와야 하며, batch cache hit는 best-effort다. 이 글은 긴 정책 블록은 1시간 TTL로 두고 짧은 요약·사용자 tail은 5분 TTL로 섞을 때 batch와 interactive billing 메모를 어떤 칸으로 남겨야 덜 꼬이는지 정리한 것이다.
1. 개요
결론부터 말하면 mixed TTL 운영의 핵심은 '무엇을 1시간으로 올릴지'보다 '어떤 순서로 배치하고 어떤 메모를 남길지'다. 긴 정책 블록처럼 여러 요청과 여러 분 간격을 견뎌야 하는 prefix만 1시간으로 두고, 세션 요약과 사용자 tail은 5분 TTL 또는 uncached tail로 두는 편이 안전하다.
그리고 비용 설명은 평균 hit율보다 prefix hash, ttl map, workload 종류, usage 2종을 같이 남기는 편이 낫다. batch는 best-effort라 같은 설계여도 hit가 흔들릴 수 있기 때문이다.
2. 어디서 실제로 막히는가
여기서 흔한 실패는 세 가지다. 첫째, 긴 정책 블록보다 뒤에 1시간 TTL을 붙인다. 둘째, 대화 요약까지 1시간으로 묶어 stale 문맥과 비용 증가를 같이 만든다. 셋째, batch와 interactive를 한 표로 기록해 어떤 write가 비쌌는지 구분하지 못한다.
Anthropic 문서는 5분 기본 TTL과 mixed TTL 순서를 같이 설명하고, batch 문서는 cache hit가 best-effort라고 적는다. 이 둘을 합치면 mixed TTL 운영은 'hit가 잘 나오는가'보다 '긴 블록과 짧은 블록을 billing 단위로 다시 설명할 수 있는가'에 더 가깝다.
실제 운영에서 더 자주 터지는 문제는 usage 화면과 로그 표를 같이 보지 않는 것이다. operator는 cache_creation_input_tokens 필드와 cache_read_input_tokens 필드를 조회하고, batch 결과와 interactive 결과를 비교하고, summary revision 상태를 저장하고, prefix hash를 기록하고, 다음 실행에서 같은 경로를 다시 확인해야 한다. 이 과정을 빼면 어느 요청이 1시간 write였는지, 어느 요청이 5분 refresh였는지, 어떤 응답 상태에서 miss가 커졌는지 설명이 안 된다.
- 증상: read hit는 보이는데 월말 비용 설명이 계속 틀어진다.
- 실패: 정책 블록과 세션 요약을 같은 TTL로 묶는다.
- 막힘: batch miss와 interactive refresh를 같은 원인으로 적는다.
- 누락: ttl map과 prefix hash를 남기지 않는다.
3. 실무에서 적용하는 순서
적용 순서는 네 단계가 가장 짧다. 먼저 여러 워크로드에서 공통으로 쓰는 긴 정책 블록만 1시간 TTL 후보로 분리한다. 두 번째로 짧은 세션 요약과 사용자 질문 tail은 5분 TTL 또는 uncached tail로 뒤에 둔다. 세 번째로 요청 로그에 workload 종류와 prefix hash와 ttl map을 같이 적는다. 마지막으로 usage에서 cache_creation_input_tokens와 cache_read_input_tokens를 separate field로 남긴다.
- 장시간 재사용되는 정책 블록만 1시간 TTL 후보로 분리한다.
- 짧은 요약과 user-tail은 뒤에 두고 5분 TTL로 짧게 유지한다.
- batch와 interactive를 workload 필드로 분리 기록한다.
- usage와 ttl map을 같은 레코드에 남긴다.
운영자는 로그를 확인하고, 필드를 저장하고, 표로 비교하고, 실행 결과와 응답 상태를 남기고, 다음 배치에서 같은 prefix hash를 다시 조회하는 습관을 가져가야 한다. usage 화면 한 장, 내부 표 한 장, prefix map 한 장만 있어도 operator가 비용 급증 원인을 훨씬 빨리 설명할 수 있다. 이미 1시간 TTL이 필요한 이유는 batch 완료 시간이나 장시간 복귀에서 나오고, 짧은 요약은 stale 위험이 더 크므로 오래 잡지 않는 편이 낫다.
checklist: 1. 실행 전 ttl map 확인 2. 요청 후 usage 필드 저장 3. batch 결과와 interactive 결과 비교 4. prefix hash와 summary revision 기록 5. 다음 실행에서 같은 상태인지 다시 조회4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 prompt caching의 기본 수명 규칙이다. Anthropic은 기본 캐시 수명이 5분이고, 다시 읽히면 추가 비용 없이 수명이 갱신된다고 설명한다.
이 전제 때문에 모든 긴 블록을 무조건 1시간으로 올릴 필요는 없다. 세션 간격이 짧고 반복 호출이 촘촘하면 5분 TTL만으로도 충분히 read hit를 만들 수 있다.
두 번째 자료는 서로 다른 TTL을 한 요청 안에서 섞는 공식 규칙이다. Anthropic은 더 긴 TTL 블록이 더 짧은 TTL 블록보다 앞에 와야 한다고 분명히 적고 있다.
실무에서는 이 순서가 가장 많이 깨진다. 정책 문서보다 뒤에 대화 요약이나 짧은 user-tail을 두고 1시간 TTL을 붙이면 설계 의도와 달리 billing 경계가 꼬인다.
세 번째 자료는 Message Batches 문서의 cache hit 설명이다. Anthropic은 batch cache hit가 best-effort이고 동시성에 따라 크게 흔들릴 수 있다고 적고 있다.
그래서 mixed TTL 운영에서는 평균 hit 숫자만 보지 말고 어떤 블록이 1시간 write였는지, 어떤 tail이 5분 miss였는지를 별도 메모로 남겨야 한다. 같은 배치라도 concurrency 때문에 hit 비율은 들쑥날쑥할 수 있기 때문이다.
가장 실용적인 자료는 workload별로 어떤 블록을 1시간과 5분으로 나눌지 정리한 표다. batch와 interactive를 같은 규칙으로 보지 말고, 재사용 간격과 변경 속도로 자르는 편이 낫다.
이미 5분 TTL과 1시간 TTL 분기 글이 큰 기준을 설명했다면, 이번 표는 batch와 interactive를 같이 운영할 때 billing 메모를 어떤 칸으로 남길지에 더 가깝다.
다섯 번째 자료는 mixed TTL 순서 예시다. 긴 정책 블록을 먼저 두고, 그 뒤에 짧은 요약과 user-tail을 배치해야 공식 규칙과 billing 경계가 맞는다.
핵심은 '더 오래 유지하고 싶은 블록이 더 앞'이라는 한 줄이다. 이 순서가 깨지면 batch와 interactive를 같이 돌릴 때 어느 write가 비싸졌는지 설명이 어려워진다.
마지막 자료는 월말 비용 설명에 바로 쓰는 메모 형식이다. mixed TTL에서는 token 수치보다 어떤 블록이 어느 TTL로 write됐는지를 로그에서 재현할 수 있어야 한다.
같은 가지의 최근 글인 thinking config와 tool_choice cache miss 글과 batch prompt caching 분리 순서 글까지 같이 보면 TTL, prefix, usage 읽기가 한 줄로 이어진다.
5. 주의사항과 리스크
첫 번째 리스크는 모든 공통 블록을 1시간 TTL로 올려 write 비용을 키우는 것이다. 두 번째는 짧은 세션 요약까지 오래 유지해 stale 문맥을 만든 뒤 miss 원인으로 오해하는 것이다. 세 번째는 batch hit가 흔들릴 때 concurrency와 best-effort 특성을 빼고 TTL 설계만 다시 손보는 것이다.
mixed TTL은 설계보다 복기 체계가 중요하다. 긴 블록, 짧은 블록, tail, workload를 나눠 적지 않으면 비용 변화가 생겨도 다시 설명할 수 없다.
6. 결론
Claude prompt caching에서 긴 정책 블록은 1시간, 짧은 요약과 사용자 tail은 5분으로 섞고 싶다면 순서와 메모부터 고정하는 편이 가장 안전하다. 긴 TTL 블록을 앞에 두고, 짧은 블록은 뒤에 두고, batch와 interactive를 분리 기록하면 hit가 흔들려도 billing 설명은 훨씬 짧아진다.
- 1시간 TTL은 긴 정책 prefix처럼 재사용 간격이 긴 블록에만 준다.
- 세션 요약과 user-tail은 5분 또는 uncached tail로 뒤에 둔다.
- prefix hash와 ttl map과 usage 2종을 같이 남긴다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
