Claude Sonnet 4.5 / Haiku 4.5 / Opus 4.5
Amazon Bedrock 프롬프트 캐싱, 1시간 TTL이 오히려 비용을 늘리는 조건 있습니다
Amazon Bedrock 프롬프트 캐싱이 2026년 1월 26일 1시간 TTL 기능을 정식 출시했습니다. 공식 문서는 “비용 최대 90% 절감, 지연 시간 최대 85% 개선”을 약속합니다. 그런데 직접 공식 문서와 요금 페이지를 같이 놓고 보니 이게 항상 이득이 아닌 상황이 나왔습니다. 교차 리전 추론(CRIS) 환경에서는 캐시 쓰기 비용이 오히려 늘어날 수 있고, 모델 선택에 따라 1시간 TTL 자체를 쓸 수 없는 경우도 있습니다.
프롬프트 캐싱이 실제로 어떻게 작동하나요
LLM 추론 비용은 크게 두 부분으로 나뉩니다. 입력 토큰 처리 비용과 출력 토큰 생성 비용입니다. 프롬프트 캐싱은 이 중 입력 토큰 처리 단계를 최적화합니다. 쉽게 말하면 “이 문장, 저번에도 처리했으니 다시 계산하지 말고 저장해둔 결과 가져와”라는 방식입니다.
구체적으로는 캐시 체크포인트라는 마커를 프롬프트 안에 삽입해서 “여기까지는 캐시해라”고 표시합니다. 이후 동일한 접두사를 포함한 요청이 들어오면 모델은 캐시에서 읽어와서 그 이후 부분만 새로 처리합니다. 이 덕분에 첫 번째 토큰까지 걸리는 시간(TTFT)이 줄어들고 입력 비용이 절감됩니다.
중요한 점은, 캐시 적중은 “정확히 같은 접두사”가 있어야만 발생한다는 겁니다. 프롬프트 앞부분이 단 한 글자라도 바뀌면 캐시 미스(Cache Miss)가 납니다. 그래서 정적인 내용(시스템 프롬프트, 고정 문서, 도구 정의)은 앞에 두고, 바뀌는 내용(사용자 질문, 대화 내용)은 뒤에 배치하는 구조가 기본 원칙입니다.
💡 AWS 공식 기술 블로그에서 실제 테스트 결과를 공개했습니다. 동일 문서에 첫 질문 시 37,209 토큰이 캐시 쓰기로 처리됐고, 두 번째 질문에서는 37,209 토큰이 캐시 읽기로 처리되며 10 토큰만 새로 처리됐습니다. 수치상 절감률이 99% 이상입니다. 단, 이건 같은 문서를 반복 참조하는 챗봇류에서의 최선의 경우입니다. (출처: AWS 기술 블로그 “Effectively use prompt caching on Amazon Bedrock”, 2025.06.09)
1시간 TTL, 정식 출시 내용 직접 확인했습니다
기존 프롬프트 캐싱의 캐시 수명은 5분이었습니다. 그러다 2026년 1월 26일, Amazon Bedrock이 일부 Anthropic Claude 모델을 대상으로 1시간 TTL 옵션을 정식 출시했습니다. (출처: AWS What’s New, 2026.01.26) 에이전트 워크플로나 긴 대화 세션처럼 요청 간격이 5분을 넘길 수 있는 상황을 위한 업데이트입니다.
Converse API를 쓴다면 cachePoint 객체에 "ttl": "1h"를 추가하면 됩니다. InvokeModel API라면 cache_control 객체에 "ttl": "1h"를 추가합니다. TTL 값을 따로 지정하지 않으면 기본 5분이 적용됩니다.
같은 요청 안에서 1시간 TTL과 5분 TTL을 동시에 쓸 수도 있습니다. 단, TTL이 긴 캐시 항목이 짧은 것보다 앞에 배치되어야 한다는 제약이 있습니다. 시스템 프롬프트(1시간)를 앞에, 자주 바뀌는 도구 정의(5분)를 뒤에 두는 식입니다.
💡 속도 제한(Rate Limit) 관점에서 추가 이점이 있습니다. AWS 공식 문서에서 직접 확인한 내용입니다. “캐시 적중은 속도 제한에서 차감되지 않으므로 속도 제한 사용률을 높이려는 경우에도 1시간 TTL이 유용합니다.” 높은 트래픽 상황에서 스로틀링을 피하는 용도로도 활용할 수 있습니다. (출처: AWS Bedrock 공식 문서, prompt-caching.html)
비용 계산 직접 해봤습니다 — 손익분기점이 생각보다 높습니다
“90% 절감”이라는 숫자만 보면 무조건 켜야 할 것처럼 느껴집니다. 그런데 캐시 쓰기(Write)가 표준 입력 가격보다 비싸다는 점이 변수입니다. Anthropic 직접 API 기준으로 보면, 5분 TTL 캐시 쓰기는 표준 대비 25% 비쌉니다. 1시간 TTL 캐시 쓰기는 100% 더 비쌉니다. Claude Sonnet 4.5를 예로 들면 이렇습니다.
| 항목 | 표준 입력 | 5분 캐시 쓰기 | 1시간 캐시 쓰기 |
|---|---|---|---|
| Claude Sonnet 4.5 | $3.00 / MTok | $3.75 / MTok | $6.00 / MTok |
| 캐시 적중(읽기) | — | $0.30 / MTok | |
| Claude Haiku 4.5 | $1.00 / MTok | $1.25 / MTok | $2.00 / MTok |
(출처: Anthropic 공식 요금 페이지 및 Clien 커뮤니티 실사용자 공개 자료, 2025.12 기준)
손익분기점 계산을 해보면, 5분 TTL은 캐시 쓰기 비용이 표준의 1.25배이므로 캐시 히트가 최소 2회 이상이어야 손익분기를 넘깁니다. 1시간 TTL은 캐시 쓰기가 2배이므로 최소 약 3회 이상 히트가 나야 순수 절감이 시작됩니다. 이건 이론적 최솟값이고, 실제로 의미 있는 절감을 보려면 10회 이상 재사용이 되는 장기 세션이나 반복 쿼리 패턴에서만 빛을 발합니다.
💡 Clien 실사용자가 직접 공개한 수치입니다. “10회 재호출 해야 78%, 20회 재호출 시 84% 전후의 할인율에 도달”합니다. 90% 절감이 되려면 훨씬 더 많은 재호출이 필요합니다. 한 번 쓰고 끝나는 쿼리에는 캐싱이 오히려 손해입니다.
교차 리전 추론 쓰면 캐시 쓰기가 오히려 늘어납니다
이게 기존 블로그에서 거의 다루지 않는 부분입니다. AWS 공식 문서를 직접 읽어보니 이런 경고문이 있습니다. “교차 리전 추론(Cross-Region Inference, CRIS)과 함께 프롬프트 캐싱을 사용할 수 있지만, 수요가 많은 경우 이러한 최적화로 인해 캐시 쓰기가 증가할 수 있습니다.” (출처: AWS Bedrock 공식 문서 “더 빠른 모델 추론을 위한 프롬프트 캐싱”)
무슨 말이냐 하면, CRIS 환경에서는 수요가 몰릴 때 AWS가 자동으로 다른 리전으로 요청을 분산시킵니다. 리전이 달라지면 기존 캐시가 그쪽에 없어서 캐시 미스가 나고, 다시 캐시 쓰기 비용이 발생합니다. 덤으로 1시간 TTL 캐시 쓰기 비용(표준의 2배)을 또 내야 하는 상황이 생깁니다. AWS는 “당황하지 마라”고 쓰고는 있지만, 이건 비용 계획에 반드시 반영해야 할 변수입니다.
⚠️ 실사용 주의 사항: 한국 시간 기준으로 피크 트래픽이 몰리는 시간대(주로 오전 9시~오후 6시)에 CRIS 환경에서 1시간 TTL을 쓰면, 리전 분산으로 캐시 히트율이 급감하고 캐시 쓰기 비용이 동시에 올라가는 상황이 발생할 수 있습니다. 이 경우 프롬프트 캐싱이 절감이 아니라 추가 비용으로 역전되는 구간이 생깁니다.
이런 이유로 AWS는 캐시 성능을 Amazon CloudWatch로 모니터링하도록 권장합니다. CacheWriteInputTokenCount와 CacheReadInputTokenCount를 지표로 잡아두면 캐시 히트율이 실시간으로 보입니다. 히트율이 낮아지면 CRIS 문제나 프롬프트 구조 문제를 의심해야 합니다.
5분 TTL이 더 나은 경우가 따로 있습니다
막연히 “1시간 TTL이 더 좋다”고 생각하기 쉽습니다. 그런데 AWS 공식 문서에는 이런 문장이 나옵니다. “정기적으로 사용되는 프롬프트(예: 5분마다보다 더 자주 사용되는 시스템 프롬프트)가 있는 경우 추가 비용 없이 계속 새로 고쳐지므로 5분 캐시를 계속 사용하는 것이 낫습니다.” (출처: AWS Bedrock 공식 문서)
이걸 구체적으로 풀면, 5분 안에 같은 프롬프트 접두사로 요청이 계속 들어오는 고빈도 챗봇이라면 5분 TTL이 쓰기 비용도 낮고(1.25배 vs 2배) 캐시도 계속 갱신됩니다. 1시간 TTL은 요청 간격이 5분에서 1시간 사이인 상황, 즉 에이전트 워크플로나 분석 파이프라인처럼 단계 사이에 시간이 걸리는 케이스에 맞습니다.
- 5분 안에 같은 컨텍스트 재사용
- 실시간 고빈도 챗봇
- 동시다발 API 호출이 많은 경우
- CRIS를 많이 쓰는 환경
- 에이전트 워크플로 (5분 이상 실행)
- 긴 멀티턴 대화 세션
- 배치 처리 파이프라인
- 속도 제한 사용률을 높이려는 경우
지원 모델 조건 — 1시간 TTL은 전부 다 안 됩니다
1시간 TTL은 현재 3개 모델에서만 지원됩니다. Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5입니다. Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4, Claude 3.7 Sonnet 등은 5분 TTL만 됩니다. 이걸 모르고 코드에 "ttl": "1h"를 넣어도, 지원하지 않는 모델이면 기본 5분이 그냥 적용됩니다. (출처: AWS Bedrock 공식 문서 지원 모델 표, 2026.03 기준)
| 모델 | 최소 토큰 | 5분 TTL | 1시간 TTL |
|---|---|---|---|
| Claude Opus 4.5 | 4,096 | ✅ | ✅ |
| Claude Sonnet 4.5 | 1,024 | ✅ | ✅ |
| Claude Haiku 4.5 | 4,096 | ✅ | ✅ |
| Claude Opus 4.1 | 1,024 | ✅ | ❌ |
| Claude Sonnet 4 | 1,024 | ✅ | ❌ |
| Claude 3.7 Sonnet | 1,024 | ✅ | ❌ |
(출처: AWS Bedrock 공식 문서 지원 모델 및 제한 표, 2026.03 기준)
추가로 Opus 4.5와 Haiku 4.5는 최소 토큰이 4,096개입니다. 다른 모델들이 1,024 토큰이면 되는 것과 달리, 이 두 모델은 캐시 체크포인트당 토큰이 4,096개를 넘어야 캐싱이 작동합니다. 시스템 프롬프트가 짧으면 Opus 4.5에서 캐싱 자체가 안 됩니다. 캐시하려는 내용이 4,096 토큰 미만이면 추론은 계속되지만 접두사는 캐싱되지 않습니다.
자주 묻는 질문
마치며
Amazon Bedrock 프롬프트 캐싱 1시간 TTL은 분명 유용한 기능입니다. 에이전트 워크플로나 긴 세션에서 비용과 속도를 동시에 잡을 수 있고, Rate Limit 대응에도 쓸 수 있습니다. 그런데 “항상 이득”은 아닙니다.
캐시 쓰기 비용이 표준의 2배라는 점, 교차 리전 추론 환경에서 캐시 미스가 늘 수 있다는 점, 1시간 TTL이 3개 모델에서만 된다는 점은 공식 문서를 직접 읽기 전까지는 알기 어려운 내용입니다. 프롬프트 캐싱을 프로덕션에 적용하기 전에 CloudWatch 지표 설정을 먼저 해두고, 캐시 히트율을 측정한 뒤 판단하는 게 안전합니다.
써봤더니 장점은 분명하고 조건도 명확합니다. 조건만 맞으면 충분히 강력한 기능입니다.
※ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Amazon Bedrock 프롬프트 캐싱 지원 모델, 요금, TTL 옵션은 AWS 업데이트에 따라 달라질 수 있으므로 적용 전 공식 문서를 반드시 확인하세요. 본 포스팅의 요금 수치는 2026.01 기준이며, Anthropic 직접 API와 Amazon Bedrock의 단가 구조는 다를 수 있습니다.
댓글 남기기