지난 글에서 프롬프트 캐싱을 처음 도입할 때 알아둘 7가지를 정리했다.
그 글 마지막에 이렇게 약속했다.
“같은 시스템 프롬프트를 캐싱 없이 / 5분 TTL / 1시간 TTL로 각각 N번 호출하면서
누적 비용이 어떻게 갈라지는지 직접 측정한다.”
약속한 실험을 돌렸다.
같은 prefix를 세 가지 모드로 각 20번, 총 60번 호출했다.
먼저 결론부터 던지면 이렇다.
같은 작업을 캐싱 OFF로 돌리면 $1.56, 5분 TTL로 돌리면 $0.33이다.
79% 절감. 20번 만에.
이론으로 봤던 “3회부터 이득”이 실측에서는 어디로 갔는지,
측정 중에 만난 두 가지 예상 못 한 발견을 정리한다.
실험 설계
캐싱 효과는 prefix가 길수록, 호출이 많을수록 커진다.
그래서 비교 가능한 조건을 잡았다.
- 모델: Claude Opus 4.7
- prefix: 지난 글 본문(
blog_post_prompt_caching.md)을 그대로 시스템 프롬프트로 투입. 약 4,860 토큰. - 사용자 메시지: 그 글에 대한 짧은 질문 20개를 돌아가며 사용 (“이 글에서 가장 중요한 한 문장을 골라줘” 같은 식). 매번 다른 질문이지만 짧다(~30 토큰).
- 모드: 캐싱 OFF / 5분 TTL / 1시간 TTL
- 호출 수: 모드당 20회, 총 60회
- 출력 제한: max_tokens=60
캐시 키가 깨끗하게 시작하도록 매 벤치 실행마다 prefix 맨 앞에 실험 ID 한 줄을 prepend했다.
이게 안 되면 직전 실험이 만든 캐시가 재사용되면서 그림이 더러워진다.
(이걸로 한 번 데이고 나서 추가한 안전장치다. 자세한 건 뒤에 따로 쓴다.)
가격은 Opus 4.7 기준 입력 $15/M, 출력 $75/M, 캐시 쓰기는 5분 TTL이 1.25배, 1시간 TTL이 2배, 캐시 읽기는 0.1배다.
이 단가를 그대로 코드에 박고 호출별 토큰 수와 곱해 누적 비용을 계산했다.
결과 1 – 누적 비용 곡선
20번 호출까지의 누적 비용을 그리면 이렇게 나온다.
빨간 선은 캐싱 OFF다.
한 호출에 약 $0.078씩 정직하게 쌓인다.
20회면 $1.56.
파란 선은 5분 TTL이다.
첫 호출에 $0.098로 OFF보다 잠깐 비싸다. 캐시 쓰기 비용(1.25배) 때문이다.
두 번째 호출부터 한 번에 $0.012씩만 늘어난다.(OFF의 약 1/7 기울기)
20회 누적이 $0.33.
녹색 선은 1시간 TTL이다.
첫 호출에 $0.151로 가장 비싸다. 캐시 쓰기 단가가 2배니까 당연하다.
두 번째부터는 5분 TTL과 거의 같은 기울기로 간다.
20회 누적이 $0.38.
세 곡선의 거리가 호출이 늘수록 벌어진다.
이 그림 한 장이 “왜 캐싱을 켜는가”에 대한 답이다.
결과 2 – 손익분기는 2회와 3회
초반 10회만 확대해서 보면 손익분기가 어디인지 명확해진다.
5분 TTL은 두 번째 호출부터 OFF 누적보다 싸진다.
1시간 TTL은 세 번째 호출부터다.
지난 글에서 이론으로 풀었던 손익분기 공식은 5분 TTL 기준 N ≥ 2였다.
“1.25 + 0.1 × N < 1 × (N + 1) → N ≥ 2”
실측이 정확히 이걸 맞춘다.
캐시를 쓴 첫 호출은 약간 손해, 두 번째부터 본전, 세 번째부터 이미 OFF보다 한참 싸다.
여기서 한마디 더 보태야 할 게 있다.
“세 번 이상 재사용할 거 같으면 켜라”는 휴리스틱은 보수적으로는 옳다.
실측에서 두 번째 호출이 OFF를 넘기는 폭은 사실 미미하다(차트에서 파란 선이 빨간 선 바로 아래 붙어 있다).
세 번째 호출쯤 가야 비로소 “체감되는 이득”이 생긴다.
그러니 머릿속 디폴트는 여전히 “3회”로 두는 게 맞고,
손익분기는 2회라는 건 운영 중 분석할 때 알면 좋은 정밀한 수치 정도로 받아들이자.
호출당 비용 – 첫 호출과 그 이후
평균이 아니라 호출별로 쪼개 보면 캐싱의 본체가 보인다.
| 항목 | 비용 (USD) | OFF 대비 |
|---|---|---|
| 캐싱 OFF (호출당 평균) | $0.0778 | 1.00x |
| 5분 TTL — 첫 호출 | $0.0980 | 1.26x |
| 5분 TTL — 2회차 이후 평균 | $0.0122 | 0.16x |
| 1시간 TTL — 첫 호출 | $0.1510 | 1.94x |
| 1시간 TTL — 2회차 이후 평균 | $0.0122 | 0.16x |
여기서 가장 인상적인 숫자는 마지막 두 줄이다.
캐시가 한 번 자리잡고 나면 호출당 비용이 OFF의 16%까지 떨어진다.
5분 TTL이든 1시간 TTL이든 이 부분은 거의 같다.
캐시 읽기 단가가 0.1배라서, write의 1.25 vs 2 차이는 첫 호출 한 번에서만 갈리고 그 다음부터는 의미가 없다.
이게 함의하는 바가 있다.
TTL 선택은 비용이 아니라 “호출 간격”으로 결정해야 한다.
호출 간격이 5분 안쪽이면 5분 TTL이 무조건 맞다(쓰기 단가가 싸니까).
호출 간격이 5분을 자주 넘긴다면 1시간 TTL을 켜라(2배 쓰기 비용을 한 번 더 무는 게, 캐시 미스가 나서 처음부터 다시 캐싱하는 것보다 훨씬 싸니까).
가격표만 보면 1시간 TTL이 “두 배 비싼 옵션”으로 보이지만
실제 운영에서는 캐시가 살아 있느냐 죽었느냐가 모든 걸 결정한다.
발견 1 – 5분 TTL은 매 호출마다 “확장 비용”이 붙는다
실측을 돌리다가 처음 본 현상이 하나 있다.
5분 TTL 모드에서 두 번째 호출부터의 usage 응답을 보면 이렇다.
[5m] 2/20 in=6 cwrite=43 cread=4854
[5m] 3/20 in=6 cwrite=28 cread=4854
[5m] 4/20 in=6 cwrite=28 cread=4854
[5m] 5/20 in=6 cwrite=32 cread=4854
cread는 캐시에서 읽어온 prefix 토큰이다. 매번 4,854. 이건 예상된 값이다.
이상한 건 cwrite다.
매 호출마다 20~40 토큰의 작은 cache_creation이 추가로 잡힌다.
사용자 메시지가 매번 다르니까 prefix는 안 바뀌었는데 뭔가가 캐시에 새로 쓰이고 있다는 뜻이다.
토큰 수가 사용자 질문의 길이와 비슷한 걸 보면
매 호출의 user message가 cache에 함께 누적되는 동작으로 보인다.
다음 호출의 user message는 또 다르니까 이게 다시 읽힐 일은 없는데 어쨌든 cache write 비용은 발생한다.
20회 누적으로 약 600 토큰. 비용으로는 $0.011 정도다.
크지는 않지만 이론 모델에는 없는 “세금”이다.
그리고 더 흥미로운 비교는 그 다음에 있다.
같은 실험을 1시간 TTL 모드로 깨끗하게 다시 돌려봤다.
[1h] 2/20 in=49 cwrite=0 cread=4860
[1h] 3/20 in=34 cwrite=0 cread=4860
[1h] 4/20 in=34 cwrite=0 cread=4860
[1h] 5/20 in=38 cwrite=0 cread=4860
1시간 TTL에서는 cwrite=0이다.
매 호출의 user message가 그냥 input_tokens로 일반 입력 단가로 계산되고
캐시에는 추가로 쓰이지 않는다.
같은 일을 하는데 5분 TTL은 user message를 캐시에 잠깐 묻고 1시간 TTL은 안 묻는다.
왜 다른지 공식 문서에 명시된 설명을 찾지 못했다.
추측해보자면 5분 TTL은 “잠깐만 살아 있어도 되는 캐시”라서
후속 호출을 위해 prefix를 적극적으로 확장해놓는 쪽으로 동작하고
1시간 TTL은 비싸게 쓴 캐시라서 그런 투기적 확장을 안 하는 쪽으로 보인다.
어쨌든 실측에서 관찰된 사실은 이거다.
5분 TTL은 호출당 작은 cwrite 세금이 붙는다. 1시간 TTL은 없다.
비용에 미치는 영향은 미미하지만 토큰 계측을 운영에 붙일 때 이 패턴을 모르면
“왜 cache_creation이 0이 아니지?”에서 한 번 헤매게 된다.
발견 2 – TTL은 write-side 파라미터다
처음 실험을 돌렸을 때 1시간 TTL 모드가 이상하게 동작했다.
호출 1번부터 cwrite=28, cread=4854로 잡혔다.
분명히 1시간 TTL 모드의 첫 호출인데 캐시 읽기가 일어났다.
원인은 단순했다.
직전에 돌린 5분 TTL 모드가 같은 prefix로 캐시를 만들어 두었고
1시간 TTL 모드의 호출이 그 캐시를 그냥 가져다 썼다.
가져다 쓰는 것까지는 문제가 아닌데 결과적으로 1시간 캐시는 단 한 번도 새로 만들어지지 않았다.
20회 호출 내내 5분 캐시를 읽기만 했다.
여기서 깨달은 건 이거다.
cache_control의 TTL 옵션은 “이 호출이 캐시를 새로 쓸 때 어떤 TTL로 쓸 것이냐”를 정한다.
캐시 조회는 TTL과 무관하다.
prefix가 일치하는 캐시 항목이 있으면 그게 5분으로 적힌 거든 1시간으로 적힌 거든 그냥 읽는다.
그래서 깨끗한 1시간 TTL 실측을 받으려고 같은 실험을 다른 실험 ID(=다른 prefix)로 한 번 더 돌려야 했다.
이 함정이 운영에서 의미하는 바는 명확하다.
TTL을 갈아끼웠다고 캐시가 새 모양으로 작동하는 게 아니다.
같은 prefix로 호출하던 코드 경로가 두 군데 있고 한 쪽이 5분 TTL로 캐시를 만들면,
다른 쪽이 1시간 TTL로 호출해도 그 5분 캐시에 free-ride한다.
기존 캐시가 만료되어 사라진 뒤에야 1시간 TTL로 새 캐시가 만들어진다.
특히 실측·벤치를 할 때 이 함정에 빠지기 쉽다.
깨끗한 측정을 원한다면 prefix를 명시적으로 바꿔서 캐시 키를 새로 따자.
토큰이 어디로 흘렀나
같은 작업, 같은 결과인데 모드만 바꿨더니 토큰이 다른 길로 흐른다.
OFF 모드는 거의 전부가 일반 input 토큰이다($15/M 단가).
캐싱 모드는 거의 전부가 cache_read 토큰으로 옮겨갔다($1.50/M 단가).
cache_creation 부분은 작게 보인다.
이 그림이 핵심을 압축한다.
캐싱은 단가를 안 바꾸고 토큰의 흐름을 바꾼다.
같은 prefix를 60번 읽어야 한다면, 60번 비싼 단가로 처리하느냐
한 번만 비싸게 캐시에 적어두고 59번 싸게 꺼내 쓰느냐의 선택이다.
핀테크 분류기로 환산하면
실측 결과를 운영 워크로드에 반영해보자.
핀테크에서 자주 나오는 패턴이 있다.
거래 메시지 분류기다.
- 시스템 프롬프트: 분류 라벨 정의 + few-shot 20개 + 회사 약관 발췌. 약 4,860 토큰.
- 입력: 한 건의 거래 메시지. 약 50 토큰.
- 출력: 분류 결과. 약 30 토큰.
이 분류기를 하루 1만 건 처리한다고 가정한다.
호출 간격이 1분 안쪽이라 5분 TTL이 잘 먹는 워크로드라고 하자.
캐싱 OFF로 한 달(30일) 돌리면:
- 입력 토큰: 4,910 × 1만 × 30일 = 약 14.7억 토큰
- 비용: 14.7억 × $15/M = 약 $22,100
캐싱 ON(5분 TTL)으로 같은 작업을 돌리면 호출당 평균 $0.0122이고
첫 호출의 캐시 쓰기는 거의 무시할 정도다.
- 30일 × 1만 호출 × $0.0122 = 약 $3,660
월 약 $18,400 절감이다.
이게 분류기 한 종류만 가정했을 때다.
KYC 룰 점검, 거래 메모 요약, 알림 분류, FAQ 응답 같은 LLM 워크플로우가 두세 종류 있다면
절감액은 더 늘어난다.
물론 이건 어디까지나 가정이고 실제 운영에서는
캐시 미스율, 호출 간격 분포, prefix 변경 빈도가 다르게 작동한다.
다음 글에서 실제 워크플로우에 붙여서 검증할 예정이다.
프롬프트 캐싱 실측에서 건진 5가지
정리하면 이렇다.
- 5분 TTL은 두 번째 호출, 1시간 TTL은 세 번째 호출부터 OFF보다 싸진다. 이론 공식과 일치.
- 호출당 비용은 모드 무관하게 OFF의 16%까지 떨어진다. TTL 차이는 첫 호출에서만 의미 있다.
- TTL 선택은 비용이 아니라 호출 간격으로 결정해야 한다. 5분 안쪽이면 5분 TTL, 자주 넘기면 1시간 TTL.
- 5분 TTL은 매 호출마다 작은 cwrite 세금이 붙는다. 1시간 TTL은 없다. 토큰 계측 시 패턴을 알아둬야 헤매지 않는다.
cache_control의 TTL은 write-side 파라미터다. 캐시 조회는 TTL과 무관해서, 다른 TTL로 쓴 캐시에 free-ride가 일어날 수 있다. 깨끗한 측정·벤치를 원한다면 prefix를 분리하자.
다음 글에서 무엇을 할 것인가
이번 글에서는 인공적으로 짠 prefix로 비용 곡선을 그렸다.
다음 글에서는 같은 프롬프트 캐싱 설계를 실제 워크로드에 옮겨본다.
핀테크 거래 분류기를 가상 시나리오로 잡고,
시스템 프롬프트·도구 정의·reference document를 어떻게 배치할지,
cache_control 마커를 어디에 박을지,
5분과 1시간 TTL을 어떤 코드 경로에서 갈라 쓸지,
캐시 미스를 어떻게 로깅할지를 설계 일지처럼 쓴다.
이번 글이 “캐싱은 왜 켜는가”였다면, 다음 글은 “캐싱을 어떻게 붙이는가”다.
p.s. 이번 실험에 든 비용은 60회 호출 합쳐 약 $2.3였다. 이 글이 그 값을 한다고 믿고 발행한다.
