Amazon Bedrock 프롬프트 캐싱은 캐시된 프리픽스를 읽을 때 약 90% 할인된 가격을 제공하지만, 캐시 쓰기는 일반 입력 토큰보다 비싸기 때문에 캐시 히트가 한 번도 일어나지 않으면 청구서는 오히려 더 나빠진다. 이 기능은 2025년 4월부터 정식 출시되었고, 2026년 1월에 도입된 1시간 캐시 지속 시간 덕분에 전체 세션과 배치 작업에도 유용해졌다. 그런데도 대부분의 팀은 여전히 이를 꺼둔 채로 두거나, 엉뚱한 위치에 켜서 조용히 프리미엄을 더 내고 있다. 할인 자체는 실재한다. 그것을 실제로 챙길 수 있는지는 전적으로 캐시 브레이크포인트를 어디에 두느냐에 달려 있다.

사람들이 흔히 빠지는 함정은 캐시를 그냥 뿌려 놓으면 되는 공짜 가속 장치처럼 취급하는 것이다. 공짜가 아니다. 모든 캐시 체크포인트는 그 앞의 토큰들이 만료되기 전에 변경 없이 다시 전송될 것이라는 내기다. 내기에서 이기면 읽기 가격의 10분의 1만 낸다. 지면 아무것도 얻지 못한 채 쓰기 프리미엄만 낸 셈이다.

가격이 실제로 작동하는 방식

중요한 토큰 클래스는 세 가지이며, 가격이 각각 다르게 매겨진다.

  • 캐시 쓰기: Bedrock이 프리픽스를 처음 저장할 때, 그 토큰들은 일반 입력 요율보다 높게 청구된다. Anthropic 모델에서는 짧은 캐시 지속 시간의 경우 기본 입력의 약 1.25배, 1시간 지속 시간의 경우 약 2배가 쓰기 요율이다.
  • 캐시 읽기: 저장된 프리픽스와 일치하는 이후의 모든 요청은 해당 토큰을 약 0.1배 가격으로 읽는다. 이것이 흔히 말하는 90% 절감이다.
  • 비캐시 입력: 마지막 캐시 체크포인트 이후의 모든 것은 매번 일반 요율로 청구된다.

쓰기 프리미엄이 핵심이다. 이후의 읽기를 저렴하게 만들기 위해 미리 값을 치르는 셈이다. 손익분기점 계산은 단순하다. 쓰기에 추가로 지불한 비용을 상쇄할 만큼 캐시된 프리픽스가 충분히 여러 번 히트해야 한다. 한 번의 쓰기와 한 번의 읽기는 일반 호출 두 번보다 비쌀 수 있다. 절감 효과는 동일한 프리픽스가 여러 번 반복해서 읽힐 때에만 누적된다.

브레이크포인트를 어디에 둘 것인가

캐시 체크포인트는 "이 지점 이전의 모든 것은 안정적이니 저장하라"는 의미다. 그러므로 호출 간에 변하지 않는 프롬프트 부분 뒤에, 그리고 변하는 부분 앞에 배치해야 한다. 일반적인 어시스턴트에서 이 순서는 다음과 같다.

[ system prompt        ]  stable
[ tool / function defs ]  stable
[ retrieved context    ]  semi-stable, per session
---- cache checkpoint here ----
[ conversation history ]  grows every turn
[ user's new message   ]  changes every turn

시스템 프롬프트와 도구 정의는 모든 호출에서 동일하므로 캐시된 프리픽스 안에 들어가야 한다. 새로운 사용자 턴은 절대 반복되지 않으므로 바깥에 있어야 한다. 검색된 컨텍스트는 그 중간에 위치한다. 같은 세션에서 동일한 문서가 재사용된다면 캐시하고, 매 호출마다 새로운 것을 검색한다면 캐시하지 않는다. 이 순서를 잘못 잡아 체크포인트를 도구 정의 앞에 두면, 거의 아무것도 캐시하지 못하면서 쓰기 비용만 계속 내게 된다.

캐시 미스가 캐시 없음보다 더 비쌀 때

캐시 히트는 프리픽스가 바이트 단위로 정확히 일치해야 하고, 해당 항목이 아직 살아 있어야 한다. 다음 세 가지 흔한 방식으로 이 내기에서 진다.

  • 프리픽스를 변형시킨다. 시스템 프롬프트 상단 근처에 타임스탬프, 요청 ID, 사용자별 인사말을 삽입하면 바이트가 달라져서 모든 호출이 새로운 쓰기가 되고 절대 읽기가 되지 못한다. 가장 흔한 자책골이다.
  • 트래픽이 TTL에 비해 너무 뜸하다. 요청이 캐시 수명보다 더 뜸하게 도착하면, 각 요청은 다음 요청이 오기 전에 쓰기와 만료를 반복한다. 1시간 지속 시간이 이 창을 크게 넓혀 주었지만, 트래픽이 적은 엔드포인트는 여전히 매번 미스를 낼 수 있다.
  • 프리픽스가 최소 기준에 미달한다. Bedrock은 모델별 토큰 하한선을 넘는 프리픽스만 캐시한다. 짧은 시스템 프롬프트는 아예 캐시 대상이 아닐 수 있어서, 체크포인트가 무시되고 아무것도 얻지 못한다.

각 경우마다 상쇄할 읽기가 없는 채로 쓰기 프리미엄만 내거나, 추가 비용은 없지만 절감도 없으면서 최적화했다고 착각하게 된다. 둘 다 그 경로에서 캐싱을 명확히 끄기로 결정하는 것보다 나쁘다.

작동 여부를 빠르게 확인하는 법

캐시가 뜨거운 상태라고 가정하지 마라. Converse와 InvokeModel 응답은 usage 필드에 캐시 읽기와 캐시 쓰기 토큰 수를 보고한다. 이를 로깅하고 비율을 지켜봐라. 건강한 캐시 경로는 소량이고 꾸준한 쓰기와 대량의 읽기를 보여준다. 쓰기와 읽기가 일대일로 따라간다면 프리픽스가 안정적이지 않고, 아무도 히트하지 않는 캐시에 프리미엄을 내고 있는 것이다. 프리픽스를 고치거나 체크포인트를 끄자.

# usage block to watch on every response
cacheWriteInputTokens  -> should be rare after warmup
cacheReadInputTokens   -> should dominate on a hot path
inputTokens            -> only the tail after your checkpoint

결론

Bedrock의 프롬프트 캐싱은 켜기만 하면 공짜로 90% 할인을 받는 스위치가 아니다. 선불 할인이다. 미리 쓰기 프리미엄을 지불하고, 변하지 않는 프리픽스를 반복적으로 읽음으로써 그것을 회수한다. 안정적인 시스템 프롬프트와 도구 정의 뒤에 체크포인트를 두고, 변동성이 있는 것은 캐시 영역 밖에 두고, 읽기 대 쓰기 비율을 로깅해서 그 내기가 실제로 수익을 내고 있는지 증명하라. 제대로 하면 Bedrock에서 가장 저렴하게 얻을 수 있는 큰 절감 효과다. 부주의하게 하면 최적화처럼 보이면서 청구서를 더 나쁘게 만드는 항목이 된다.

다음으로 읽을 글

AWS 전반의 더 폭넓은 비용 최적화 플레이북은 ercan.cloud의 클라우드 필드 노트에서, 허브는 ercanermis.com에서 확인할 수 있다.