적중률 31.6%가 이득이기도 하고 손해이기도 하다

캐시가 미스하면 캐싱을 안 한 것보다 비싸다. 브레이크포인트를 걸어두면 미스한 입력이 정가가 아니라 쓰기 단가로 과금되기 때문이다. 그래서 “적중률이 몇 %를 넘으면 켜라”는 문턱을 내고 싶어진다.

그 문턱을 냈다. 그리고 조건을 하나씩 흔들어 보니 문턱이 계속 움직였다. 같은 적중률 31.6%에서 적중이 세션 앞 턴에 몰리면 캐싱을 켜는 것이 손해이고, 뒤 턴에 몰리면 이득이다. 적중률은 같다.

마지막 줄이 문턱을 흔든다. 미스 한 번의 값이 세션 어디에서 났는지에 따라 9.5배 차이가 나므로, 적중률이라는 한 숫자로 비용을 정할 수 없다.

축은 셋이다. 세션 안에서 적중이 어디에 몰리는지, 턴 수, 그리고 테넌트 구조다. 앞의 둘은 문턱을 움직이고 마지막 하나는 문턱 자체를 무의미하게 만든다. 아래에서 하나씩 크기를 재고, 마지막에 문턱을 환산하지 않고 결정하는 방법을 적는다.

전제와 용어

2편과 같은 전제를 쓴다. Claude Opus 5 기준이다.

항목	값	근거
안정 프리픽스 S	10,000 토큰	browser toolset 6,610 + bash 325 (문서) + 시스템 프롬프트 3,065 (가정)
턴당 증가분 δ	3,000 토큰	가정
턴당 출력	400 토큰	가정
턴 수 N	20 (기준 케이스)	가정

비교하는 두 구성은 이렇다. 프리픽스만은 안정 프리픽스에만 브레이크포인트를 걸어 히스토리를 정가로 흘린다. 롤링은 매 요청 히스토리 끝으로 브레이크포인트를 옮겨 직전까지를 캐시에서 읽고 새로 늘어난 부분만 쓴다. 이 글의 모든 비교는 이 둘 사이다. 뒤에 한 번 나오는 “서문과 히스토리 양쪽에 브레이크포인트”는 세 번째 구성이고 미스 비용을 보이기 위한 것이다.

턴은 API 요청 1회다 (2편과 같다). 사용자 메시지 1개가 아니다. 아래에서 보듯 턴 수가 문턱을 움직이는 축이므로, 여기에 사용자 메시지 수를 넣으면 문턱을 몇 배 잘못 잡는다.

단가는 입력 $5, 5분 쓰기 $6.25(1.25배), 1시간 쓰기 $10(2배), 읽기 $0.50(0.1배), 출력 $25다. 모두 $/1M 토큰. 쓰기·읽기 배수와 미스한 입력이 쓰기 단가로 과금된다는 사실은 모두 문서에 있다. (Anthropic 요금 문서, 프롬프트 캐싱 문서, 2026-08-23 조회)

턴당 출력 400 토큰은 20턴 세션에서 출력 비용 $0.20이 된다. 세션 단위 금액에는 그 출력 비용이 들어가 있고, 요청 단위나 사용자 단위로 낸 금액(스탬피드·프로필·테넌트 표)에는 들어가 있지 않다.

공유가 어디까지 되는지는 가정이 아니라 문서에 있다. 캐시는 워크스페이스 단위로 격리된다. Claude API·Claude Platform on AWS·Microsoft Foundry는 워크스페이스 단위이고, Amazon Bedrock과 Google Cloud는 조직 단위다. 조직이 다르면 프롬프트가 완전히 같아도 캐시를 절대 공유하지 않는다. (프롬프트 캐싱 문서, 2026-08-23 조회)

이 문장이 멀티테넌트 아키텍처에 걸린다. 테넌트마다 워크스페이스를 따로 주면 테넌트를 넘는 서문 테이프 공유가 사라진다. 테넌트 안에서는 여전히 공유되므로, 서문을 쓰는 비용이 사용자 수가 아니라 테넌트 수로 곱해진다. 같은 워크스페이스 안에서 애플리케이션 레벨로 테넌트를 가르는 구성이라면 전부 공유되고 이 글의 계산이 그대로 성립한다. 어느 쪽인지가 축 3의 크기를 정하므로 계산 전에 확인한다.

서문 테이프는 살아 있고, 그래서 S는 매 턴 읽는다

캐싱은 프리픽스 정확 일치다. 그래서 바이트가 같은 안정 프리픽스는 사용자 사이에서 공유되고, 히스토리는 사용자마다 달라 캐시가 갈린다. 서문 테이프는 한 개, 본문 테이프는 사람 수만큼이다.

서문 테이프는 5분 안에 요청 한 건만 오면 유지된다. 활성 사용자 U명이 평균 간격 T분으로 요청하면 전체 요청률은 U/T건/분이다.

활성 사용자	평균 간격 5분	18분	60분
10	2.00건/분	0.56건/분	0.17건/분
100	20.00	5.56	1.67
1,000	200.00	55.56	16.67

5분에 한 건, 즉 0.2건/분을 넘으면 살아 있다. 사용자 10명이 한 시간에 한 번씩 쓰는 조합만 그 아래로 떨어진다. 실서비스 규모에서 서문 테이프는 문제가 아니다.

그래서 아래 모든 계산은 세션이 시작될 때 서문 테이프가 이미 캐시에 있다고 본다. S는 매 턴 $0.50에 읽고, 어느 세션도 S를 새로 쓰지 않는다. 문서가 정한 회계도 그렇다. 캐시 적중이 닿는 지점까지는 읽기로, 그 뒤만 쓰기로 과금된다. 서문이 hot이면 그 지점이 S 끝이므로 히스토리만 쓰기가 된다. 이 전제가 깨지는 경우는 마지막 절 0단계에서 따로 다룬다.

문제는 언제나 본문 테이프다. 그것이 살아 있으려면 그 사용자 본인이 TTL 안에 다시 와야 한다. 남의 트래픽은 도움이 되지 않는다.

미스는 캐싱을 안 한 것보다 비싸다

브레이크포인트를 걸면 그 구간의 입력은 캐시 대상이 된다. 적중하면 0.1배로 읽지만 미스하면 정가가 아니라 쓰기 단가로 과금된다. 캐시에 넣는 작업이 붙기 때문이다.

20턴 세션	입력 단가	비용	캐싱 없음 대비
브레이크포인트 없음	$5.00 (1.00배)	$4.05	—
서문과 히스토리 양쪽에 브레이크포인트, 전부 미스 (5분)	$6.25 (1.25배)	$5.01	+23.8%
서문과 히스토리 양쪽에 브레이크포인트, 전부 미스 (1시간)	$10.00 (2.00배)	$7.90	+95.1%

아래 두 행은 서문 테이프까지 매 턴 지워지는 경우다. 앞 절의 전제(서문은 살아 있다) 아래에서는 이 값이 나오지 않는다.

조건을 고정하면 문턱이 나온다

기준 케이스를 정한다. 20턴, 서문 테이프는 살아 있고, 세션 안의 간격은 모두 같은 분포에서 나온다. 이 조건에서 적중률 p를 쓸어보면 두 직선이 된다.

적중률 p	롤링 5분 TTL	롤링 1시간 TTL
0%	$3.86	$6.00
24.2%	$3.15	$4.82
50%	$2.39	$3.56
58.5%	$2.14	$3.15
75%	$1.65	$2.34
90%	$1.21	$1.61
100%	$0.91	$1.13

프리픽스만이 $3.15이므로, 5분 TTL의 문턱은 24.2%, 1시간 TTL의 문턱은 58.5%다. 간격이 지수분포라면 적중률 = 1 − exp(−TTL ÷ 평균간격)이니 각각 세션 내 평균 간격 18.1분과 68.3분에 해당한다.

두 문턱은 같은 식에서 나온다. 정리하면 S와 δ가 약분되고 이것만 남는다.

문턱 = N(w − L) ÷ ((N − 2)(w − r))
   w = 쓰기 단가, L = 정가 입력 단가, r = 읽기 단가

5분   N=20, w=6.25 -> 25 ÷ 103.5  = 24.2%
1시간 N=20, w=10   -> 100 ÷ 171   = 58.5%

안정 프리픽스가 10,000이든 30,000이든, 턴당 증가분이 500이든 10,000이든 문턱은 그대로다. 들어가는 것은 단가 세 개와 턴 수뿐이다.

여기까지가 조건을 고정했을 때의 답이다. 이제 조건을 흔든다.

축 1 — 적중 위치가 문턱을 가장 크게 흔든다

위 표는 턴마다 적중 확률이 같다고 본 것이다. 실제 워크로드는 그렇지 않다.

롤링에서는 적중이든 미스든 그 요청 시점의 누적 프리픽스, 즉 그 요청까지의 전체가 캐시에 남는다. 그래서 다음 요청은 직전 요청과의 간격이 TTL 안이면 적중한다. 그 앞에서 무슨 일이 있었는지는 상관없다. 여기까지는 간격들이 서로 상관돼 있어도 성립한다.

문제는 미스 한 번의 값이 턴마다 다르다는 것이다. 미스는 본문 테이프를 어디까지 되감아 다시 녹음하는지에 따라 값이 달라지고, 3턴째와 20턴째가 9.5배 차이다. 그래서 적중률이 같아도 적중이 앞에 몰렸는지 뒤에 몰렸는지에 따라 비용이 갈린다.

적중 6/19 (31.6%)	20턴 비용	프리픽스만 대비
적중이 앞 턴(2~7)에 몰림	$3.60	+14.4%
균일 — 문턱 표가 쓰는 가정	$2.93	−7.0%
적중이 뒤 턴(15~20)에 몰림	$2.26	−28.3%

표는 7.0% 이득이라고 말하는데 실제로는 14.4% 손해일 수 있다. 21%p 차이다.

결정이 실제로 뒤집히는 구간은 적중률 26.3%에서 47.4%다. 그 구간에서 표는 이득이라고 하고 앞쏠림 실측은 손해다. 52.6%·26.3%·15.8%는 19회 중 정수 횟수로 낸 값이라 연속 문턱 24.2%와 자릿수가 다르다. 표가 이득이라고 말하기 시작하는 실제 지점은 19회 중 5회, 26.3%다.

문턱을 환산해 쓰는 방식이 가장 위험한 자리가 여기다.

축 2 — 턴 수가 줄면 문턱이 올라간다

턴 수는 문턱 식에 직접 들어간다. 히스토리가 짧으면 캐시에 넣을 것이 적고 서문 테이프의 비중이 커지므로, 롤링이 이기기가 더 어려워진다.

턴 수 N	5분 문턱	5분 허용 간격	1시간 문턱	1시간 허용 간격	5분↔1시간 교차
5	36.2%	11.1분	87.7%	28.6분	6.00분
6	32.6%	12.7분	78.9%	38.5분	4.46분
8	29.0%	14.6분	70.2%	49.6분	3.28분
10	27.2%	15.8분	65.8%	55.9분	2.76분
20	24.2%	18.1분	58.5%	68.3분	1.91분
50	22.6%	19.5분	54.8%	75.5분	1.39분
100	22.2%	19.9분	53.7%	77.9분	1.16분

다섯 열이 모두 턴 수에 따라 움직인다. 20턴 값을 5턴 서비스에 쓰면 1시간 문턱을 58.5%로 잡는데 실제는 87.7%이므로, 그 사이 구간에서 롤링을 켜 둔 채 손해를 본다.

마지막 열은 두 TTL이 갈리는 지점이다. 20턴에서 1.91분이므로 5분 TTL이 이기는 구간은 거의 없고, 5턴에서는 6.00분까지 넓어진다. 짧은 세션일수록 5분 TTL이 살아난다.

2편은 교차 턴 수(2S ÷ δ + 1, 이 전제로 8턴) 아래면 프리픽스 캐싱으로 끝난다고 했다. 그 값은 토큰 물량이 갈리는 지점이고 가격이 갈리는 지점이 아니다. 위 표가 가격 기준의 경계를 대신하고, 5턴 세션도 간격이 11.1분 아래면 롤링이 이긴다.

축 1과 축 2의 크기를 나란히 놓으면 이렇다. 5분 문턱이 움직이는 폭은 적중 위치가 36.8%p, 턴 수가 14.0%p다. 적중 위치가 두 배 넘게 크고, 승인이 끼는 에이전트에서는 구조적으로 깨진다.

축 3 — 테넌트 구조는 문턱이 아니라 공유를 깬다

앞의 두 축은 문턱의 위치를 옮긴다. 여기서는 그 위치를 계산하는 전제, 즉 프리픽스가 사용자 사이에서 공유된다는 가정 자체가 깨진다.

캐시 스탬피드. 배포 직후, 프리픽스를 바꾼 직후, 또는 트래픽이 끊겼다 돌아온 직후에는 서문 테이프가 없다. 그 상태에서 100명이 동시에 오면 100명이 각자 서문을 처음부터 녹음한다. 이것이 캐시 스탬피드다. 문서가 “캐시 엔트리는 첫 응답이 시작된 뒤에야 사용할 수 있고, 병렬 요청에서 적중이 필요하면 첫 응답을 기다린 뒤 나머지를 보내라”고 적으므로, 동시에 출발한 요청들은 서로의 녹음을 읽지 못한다. (프롬프트 캐싱 문서, 2026-08-23 조회)

동시 요청	전부 쓰기	1회 쓰기 + 나머지 읽기	배수
10	$0.63	$0.11	5.8배
100	$6.25	$0.56	11.2배
1,000	$62.50	$5.06	12.4배

서문 10,000 토큰 기준이고 금액은 동시 요청 전체의 합계다(출력은 빠져 있다). 완화 방법은 문서의 처방 그대로다. 배포 직후에 요청 하나를 먼저 흘려 캐시를 채우고 나머지를 붙인다.

그러면 배포의 실패 양상이 바뀐다. 워밍 요청이 실패하거나 늦으면 배포는 성공했는데 첫 트래픽이 11.2배를 낸다. 워밍을 배포 파이프라인의 한 단계로 넣고 그 단계의 성공까지 확인해야 한다.

사용자별 프로필. 프로필이 시스템 프롬프트에 있으면 서문 테이프가 사람마다 갈린다. 서문에 사람 이름을 적는 것과 같다. 고치는 방법은 프로필을 첫 user 메시지로 옮기는 것이다. 캐시 프리픽스는 tools → system → messages 순서로 구성되므로, 프로필이 messages 안으로 들어가면 그 앞은 다시 공유된다. 프로필 1,500 토큰, 공유 프리픽스 8,500 토큰, 사용자 100명의 첫 요청 기준:

배치	비용	system 주입 대비 절감
프로필을 system에 주입	$6.25	—
첫 user 메시지로 이동, 프로필도 캐싱	$1.41	4.4배
첫 user 메시지로 이동, 프로필은 캐싱 안 함	$1.22	5.1배

프로필에 브레이크포인트를 두지 않는 편이 싸다. 프로필은 사용자마다 다르므로 어차피 공유되지 않고, 캐싱하면 1.25배로 쓰는 반면 캐싱하지 않으면 1.0배로 흘린다.

테넌트마다 툴이 다른 경우. tools가 프리픽스 맨 앞이므로, 테넌트별로 툴 목록이 다르면 테넌트를 넘는 공유가 끊긴다. 테넌트 안에서는 바이트가 같으니 여전히 공유된다. 공유 범위가 좁아질 뿐이다. 바로 앞 절에서 프로필을 첫 user 메시지로 옮긴 뒤를 기준으로 하면, 아래는 툴 정의 6,610 토큰이 테넌트별로 다르고 나머지 1,890(bash 325 + 시스템 프롬프트 1,565, 즉 전제표의 3,065에서 옮겨 낸 프로필 1,500을 뺀 값)은 공통이라고 볼 때의 값이다. 테넌트가 하나면 두 열이 같다.

테넌트 수	테넌트별 툴셋 그대로	합집합으로 통일
2	$1.27 (4.9배)	$1.59 (3.9배)
5	$1.42 (4.4배)	$2.70 (2.3배)
10	$1.66 (3.8배)	$4.54 (1.4배)
20	$2.15 (2.9배)	$8.23 (0.8배)

테넌트별 툴셋을 그대로 두는 것이 모든 행에서 싸다. 합집합으로 통일하면 모든 테넌트가 남의 툴 정의 토큰을 매 요청 실어 보내므로, 20테넌트에서는 $8.23이 되어 프로필을 system에 주입하는 $6.25보다도 비싸다.

그래서 환산하지 말고 직접 비교한다

적중률을 재서 문턱과 대조하려면 자기 턴 수의 행을 찾고, 세션 안에서 적중이 균일하게 흩어졌다고 가정해야 한다. 두 번째 가정이 축 1만큼 크게 틀린다.

가정이 필요 없는 경로가 있다. 로그에서 세션 비용을 직접 만들어 프리픽스만 캐싱했을 때의 비용과 비교하는 것이다. 필요한 입력은 다섯 개다.

1. 세션 ID — 요청을 세션으로 묶는다
2. 요청 시각 — 직전 요청과의 간격을 낸다
3. 사용량 필드 넷 — cache_read_input_tokens, cache_creation_input_tokens, input_tokens, output_tokens
4. S — tools와 system 블록의 토큰 수. 사용량 필드에서는 복원되지 않으므로 직접 센다
5. TTL — 지금 쓰고 있는 값

지금 구성의 세션 비용
  = cache_read_input_tokens      × $0.50
  + cache_creation_input_tokens  × 그 요청의 쓰기 단가
  + input_tokens                 × $5.00
  + output_tokens                × $25.00     (모두 /1M)

프리픽스만 캐싱했을 때의 같은 세션
  = N×S × $0.50 + 히스토리 × $5.00 + 출력 × $25.00
    (히스토리 = 각 요청의 입력에서 S를 뺀 합)

아직 롤링을 켜지 않았다면 왼쪽을 로그에서 재구성한다. 요청 시각으로 직전 요청과의 간격을 내고 TTL 미만이면 적중으로 놓으면, 각 요청의 읽기·쓰기 토큰이 정해진다. 이 경로는 실측 간격을 쓰므로 지수분포 가정도 필요 없다.

적중이 어디에 몰렸든, 간격 분포가 무엇이든, 턴 수가 얼마든 이 비교는 성립한다. 적중을 무작위로 흩뿌린 패턴에 넣어 보면 이 식으로 낸 값과 모델값이 소수점까지 일치한다.

두 조직으로 계산해 본다

두 예시를 가른 것은 사용자 수도 트래픽 총량도 아니다. 간격과 턴 수, 그리고 간격이 세션 내내 고른지 여부다.

이 셋은 독립이 아니다. 간격이 벌어지면 사람이 한 세션에 넣을 수 있는 턴 수가 줄고, 턴 수가 줄면 문턱이 올라가고, 승인 대기가 끼면 적중이 앞 턴에 몰린다. 세 축이 같은 방향으로 나빠진다.

그래서 어떻게 하는가

0. 서문 테이프가 살아 있는지 먼저 본다. 조건은 사용자 수가 아니라 요청률이다. 공유 범위(전체 또는 테넌트) 안에서 0.2건/분을 넘으면 살아 있다. 넘지 않으면 서문에 걸어 둔 브레이크포인트도 매 턴 미스해서 비용이 $4.30이 되고, 브레이크포인트를 아예 걸지 않은 $4.05보다 6.2% 비싸다. 그 경우에만 답이 캐싱을 전부 끄는 것이다. 워크스페이스로 테넌트를 갈랐어도 테넌트별 요청률이 0.2건/분을 넘으면 서문은 살아 있으므로 여기에 해당하지 않는다.

1. 세션당 실비용을 두 구성으로 계산해 직접 비교한다. 위의 다섯 입력과 두 식이다. 문턱과 대조하지 않는다.

2. 사용자군을 간격으로 가른다. 답이 구간별로 갈리기 때문이다. 아래는 기준 케이스(20턴)에 적중이 세션 내내 고르게 흩어졌다는 가정을 쓴 값이다. 프리픽스만은 간격과 무관하게 $3.15다.

세션 내 평균 간격	5분 적중률	1시간 적중률	롤링 5분	롤링 1시간	가장 싼 것
2분	91.8%	100.0%	$1.15	$1.13	롤링 1시간
5분	63.2%	100.0%	$2.00	$1.13	롤링 1시간
20분	22.1%	95.0%	$3.21	$1.37	롤링 1시간
60분	8.0%	63.2%	$3.63	$2.92	롤링 1시간
90분	5.4%	48.7%	$3.70	$3.63	프리픽스만
180분	2.7%	28.3%	$3.78	$4.62	프리픽스만

5분 TTL이 이기는 구간은 20턴에서 1.91분 미만뿐이다. 초 단위로 연달아 도는 자동 루프가 아니면 1시간 TTL이 앞선다.

갈라서 얼마를 버는지가 나와야 공수를 승인할 수 있다. 상시(2분)와 야간(180분)이 반씩인 서비스를 가정하고 균일 선택 세 개와 분리를 모두 계산한다.

선택	상시(2분)	야간(180분)	50:50 혼합
균일 · 롤링 5분	+2.5%	+20.1%	$2.47
균일 · 롤링 1시간	최적	+46.6%	$2.87
균일 · 프리픽스만	+179.6%	최적	$3.15
사용자군 분리	최적	최적	$2.14

혼합 열의 최솟값이 분리다. 비교 대상은 최악의 균일이 아니라 최선의 균일(롤링 5분, $2.47)이고, 분리는 그보다 13.4% 싸다. 구현에 $2,000을 쓰면 6,060세션에서 회수된다. 월 세션 수가 그보다 적으면 최선의 균일 하나로 두고 나중에 다시 본다.

3. 배포 직후 프리워밍 요청을 하나 넣는다. 100명 기준으로 $6.25를 $0.56으로 만든다. 워밍 단계의 성공을 확인해야 한다.

4. 공유가 깨졌는지는 세션의 첫 요청으로 본다. 총 쓰기 토큰은 공유가 되든 안 되든 사용자 수에 선형이라 총량만 보면 어느 쪽인지 정하기 어렵다. 세션의 첫 요청만 골라 cache_creation을 보면, 공유되는 서비스에서는 S 전체를 쓰는 요청이 드물게 나오고 깨진 서비스에서는 거의 모든 세션의 첫 요청이 S를 쓴다. 그 비율을 본다.

5. 비용만으로 롤링을 끄기 전에 첫 토큰 지연을 잰다. 롤링을 끄면 매 턴 히스토리 전체를 다시 프리필한다. 20턴 시점이면 57,000 토큰이다(서문 10,000은 캐시에서 읽으므로 프리필을 건너뛴다). 켜 두는 대가는 (롤링 − 프리픽스만) × 월 세션 수이고, 예시 B라면 월 $294다. 지연 편익이 그보다 크면 문턱 아래에서도 켜 두는 것이 맞다. 다만 그 편익은 적중한 요청에만 생기므로 적중률에 비례한다.

6. 세 값을 대시보드에 올린다. 세션 내 간격 분포(평균만이 아니라 세션 안에서 앞뒤로 치우치는지까지), 턴 수, 그리고 단가다. 앞의 둘은 제품이 바뀌면 움직이고 셋 다 문턱을 움직인다. 어느 하나가 표의 다음 행으로 넘어가면 1번의 직접 비교를 다시 돌린다.

2편은 사람 개입이 5분을 넘을 수 있으면 위 어느 구간이든 1시간 TTL로 가라고 했다. 그 권고는 롤링을 켠다는 전제 위에서 5분 TTL과 1시간 TTL만 비교한 것이고, 프리픽스만 캐싱과는 비교하지 않았다. 간격이 그 행의 1시간 허용 간격을 넘으면 그 전제가 깨지고, 비교 대상은 5분 TTL이 아니라 롤링을 끄는 것이 된다. 2편은 5턴 세션에서 프리픽스만으로 37%, 롤링을 더해도 52%라 구현 공수를 들일 구간이 아니라고 봤는데, 그 결론도 간격을 넣으면 뒤집힌다. 5턴 세션도 간격이 11.1분 아래면 롤링이 이긴다.

이 글의 숫자는 2편과 같은 예시값 위에 있다. 문턱이 단가와 턴 수만의 함수라는 것만 값과 무관하게 성립하고 나머지는 전부 조건에 붙어 있다. 그래서 이 글의 결론은 문턱 하나가 아니라 문턱을 쓰지 말라는 것이다. 캐시 쓰기가 정가보다 비싼 한 적중하지 않는 캐싱은 손해이고, 그 손해가 얼마인지는 세어 봐야 안다.