Cloudflare 추론 비용 68% 절감 사례: 캐시 적중률만 보면 놓치는 것

68%라는 결과를 읽기 전에 고정할 비교 단위

Cloudflare는 2026년 10월 19일 AI 코드 리뷰의 평균 비용을 2.43달러에서 0.77달러로 낮췄다고 발표했다. 비교 기준은 최적화 전 가장 비쌌던 2주 평균이며, 최종 수치는 코드 품질 리뷰를 높은 추론 강도로 실행하는 구성을 반영한다. 코드 변경과 모델·강도 변경을 함께 수행했고, 각 변경 전후의 비용 분해는 통제 실험이 아니라고 명시했다. Cloudflare의 비용 최적화 보고

따라서 제목의 숫자를 내 서비스 예산에 곧바로 곱하기는 어렵다. 대신 이 사례는 “캐시가 잘 맞는데 왜 비싸졌는가”라는 운영 질문을 제기한다. 이 글은 10월 20일 확인한 문헌과 가상 계산을 바탕으로 그 질문을 푼다. Cloudflare의 리뷰 시스템이나 유료 모델을 직접 실행하지 않았다.

비교 단위는 같은 종류의 코드 변경 한 건을 같은 범위까지 검토하는 비용으로 잡자. 문서 한 줄 변경과 인증 로직 변경이 섞인 일평균만 비교하면 구성이 달라진 영향을 최적화 효과로 오해할 수 있다. 변경 규모·검토 역할·필수 검사 범위로 묶은 뒤 각각을 비교하는 것이 이 글의 제안이다.

캐시 적중률이 90%에서 98%가 되어도 비싸질 수 있다

프롬프트 캐싱은 앞에서부터 일치하는 입력인 접두부(prefix)의 처리를 재사용한다. 답변 전체를 저장했다가 똑같이 돌려주는 응답 캐시와 구분해야 한다. 현재 Claude 문서는 정확히 일치하는 구간, 캐시 경계, 최소 입력 길이 등 조건을 설명한다. 아래에서는 조건을 충족한다고 가정하고 비용만 분리한다. 캐시 작동 방식과 제약

한 번의 요청 비용을 생각할 때 입력을 세 칸으로 나누면 혼동이 줄어든다.

요청 비용 = 일반 입력 토큰 × 일반 입력 단가
          + 새 캐시 쓰기 토큰 × 쓰기 단가
          + 캐시 읽기 토큰 × 읽기 단가
          + 출력 토큰 × 출력 단가

세 입력 칸은 서로 겹치지 않게 기록한다.
업무 한 건의 비용은 그 업무에 속한 모든 요청 비용의 합이다.

공급자가 이미 전체 입력에 캐시 토큰을 포함해 보고한다면, 전체 입력 비용에 캐시 비용을 다시 더하면 안 된다. Claude 문서의 input_tokens는 캐시 쓰기·읽기와 별개이며, cache_creation_input_tokens와 cache_read_input_tokens를 함께 해석한다. 다른 API도 같다고 가정하지 말고 해당 사용량 정의에 맞춰 장부를 만든다. 사용량 추적

다음은 실제 요금제가 아닌 가상 단가다. 입력 100만 토큰당 일반 입력 1달러, 캐시 쓰기 1.25달러, 읽기 0.10달러로 둔다. 일반 입력은 0, 출력은 두 구성에서 같아 아래 입력 비용 비교에서 제외한다.

가상 구성	캐시 쓰기	캐시 읽기	입력 중 읽기 비율	입력 비용
A	10만 토큰	90만 토큰	90%	0.215달러
B	6만 토큰	294만 토큰	98%	0.369달러

A는 0.1 × 1.25 + 0.9 × 0.10, B는 0.06 × 1.25 + 2.94 × 0.10이다. 비율은 좋아졌지만 B가 읽는 절대량이 커져 더 비싸다. 이것이 캐시 대시보드에 적중률과 함께 업무당 읽기 토큰·쓰기 토큰·호출 수를 놓아야 하는 이유다. 표의 비율은 이 글에서 정의한 토큰 비율이며 특정 제품 대시보드의 hit rate 정의를 복제한 것이 아니다.

캐시 비용이 0이 아닌 한 불필요한 문맥은 계속 비용을 만든다. 예를 들어 2만 토큰으로 시작해 매 호출 사이 2천 토큰씩 기록이 쌓이는 가상의 10회 요청은 입력 합계가 20,000 × 10 + 2,000 × (0 + 1 + … + 9) = 290,000토큰이다. 마지막 요청 길이인 38,000토큰만 보면 업무 전체 입력량을 놓친다. 실제 캐시 읽기·쓰기 구분은 각 요청의 사용량으로 확인해야 한다.

공통 규칙과 매번 바뀌는 자료를 어디서 나눌까

Cloudflare는 공통 지침 뒤에 작업 디렉터리·날짜가 붙은 하나의 블록 끝에만 캐시 경계를 두어 저장소 사이 재사용을 놓쳤다고 설명한다. 공통 부분을 별도로 나눈 조치가 개선에 포함됐다. 공통 접두부를 분리한 사례

다음은 이를 응용한 요청 설계안이다. 실제 제품 화면이나 실행된 API 입력이 아니다. 한 조직의 코드 리뷰에서 규칙은 같고 저장소·변경 내역만 달라지는 상황을 가정한다.

공통 영역: 같은 도구 정의 → 검토 규칙 v3 → 공통 영역의 캐시 경계
개별 영역: 저장소 A의 환경 → 대상 커밋과 변경분 → 역할별 추가 지시

다음 작업에서도 공통 영역의 내용과 순서는 유지한다.
저장소 B의 환경과 새 변경분은 개별 영역에 넣는다.

이때 “모든 것을 앞에 몰아넣는다”가 목표가 되어서는 안 된다. 거의 쓰지 않는 규칙을 수십 장 추가하면 첫 입력과 후속 읽기 비용이 늘어난다. 공통으로 필요한 최소 자료를 고르고, 역할에 따라 다른 부분은 분리해 비교한다. 필요한 정보가 빠져 추가 파일 조회가 늘어난다면 짧게 만든 입력이 오히려 비쌀 수도 있다.

바뀐 정책을 캐시 때문에 옛 버전으로 유지해서도 안 된다. 규칙 v4가 필요하면 실제 입력을 바꾸고, 새 쓰기 비용을 정상적인 변경 비용으로 받아들인다. 공통 접두부의 버전이나 해시를 내부 기록에 남기면 내용이 달라진 시점을 찾기 쉽다. 원문 코드·비밀값을 비용 대시보드에 복사할 필요는 없다.

현재 Claude API의 캐시는 workspace 단위로 격리된다. 따라서 서로 다른 workspace의 동일 입력까지 공유한다고 계산하면 안 된다. 병렬 요청에서 새 캐시는 첫 응답이 시작된 뒤 이용 가능하므로 동시에 출발한 요청 모두가 처음부터 재사용한다고 가정할 수도 없다. 저장 범위와 동시 요청 조건

첫 쓰기와 만료까지 포함한 손익 계산

앞의 가상 입력 단가를 유지하고 출력은 100만 토큰당 5달러로 두자. 같은 공통 입력 20,000토큰, 매번 다른 일반 입력 2,000토큰, 출력 1,000토큰인 요청 10회를 생각한다. 모든 요청은 동일 모델이며 공통 입력의 캐시 조건을 충족한다. 도구 요금·인프라·재시도는 제외한다.

가상 처리 방식	공통 입력 비용	개별 입력·출력 비용	10회 합계
캐시 없이 매번 처리	0.200달러	0.070달러	0.270달러
한 번 쓰고 나머지 9회 읽기	0.025 + 0.018달러	0.070달러	0.113달러
매번 만료되어 10회 모두 새로 쓰기	0.250달러	0.070달러	0.320달러

같은 캐시 설정도 재사용이 없으면 이 가정에서는 더 비싸다. 요청이 한 번뿐일 때도 캐시 쓰기 포함 0.032달러가 일반 처리 0.027달러보다 크다. 공통 부분을 한 번 쓰고 n−1회 읽는다면 손익 조건은 다음과 같다.

쓰기 배율 w + (n − 1) × 읽기 배율 r < n
n > (w − r) ÷ (1 − r)    [r < 1, 동일 접두부를 계속 재사용할 때]

w = 1.25, r = 0.10이면 n > 1.277…
이 단순 가정에서는 총 2회부터 공통 입력 비용이 줄어든다.

이 식은 재사용이 성립한 경우의 산술이다. 요청 간격이 만료 시간을 넘거나 입력이 바뀌면 각 구간을 따로 세어야 한다. 긴 보관 기간을 택할 때는 그에 맞는 쓰기 단가도 바꾼다. 동시 요청을 기다리게 만들어 적중률을 높일 경우, 절약한 금액과 늘어난 대기 시간도 함께 비교한다.

또한 사례 당시 배율과 현재 모델 요금을 구분해야 한다. 10월 20일 확인한 Claude 문서에서 5분 쓰기는 기본 입력의 1.25배지만, 읽기는 Opus 5.5·Sonnet 5.5가 0.05배이고 모델별 예외가 있다. 위 0.10배 가정은 그 두 모델의 현재 가격 견적이 아니다. 적용할 모델·플랫폼·기간의 실제 요금을 대입하자. 현재 캐시 가격표

위 표와 누적 입력 산술은 가상 계산 스크립트로 다시 확인할 수 있다. 표준 라이브러리만 사용하며 네트워크나 모델을 호출하지 않는다. API에서 캐시가 실제 생성되는지, 지연이 줄어드는지는 검증하지 않는다.

모델과 추론 강도는 검토 역할별로 선택한다

Cloudflare의 보고에는 중요한 반대 사례도 있다. 낮아진 지적 수가 전부 잡음 제거는 아니었으며, 성능 리뷰에서는 중요한 지적이 줄었다. 코드 품질 리뷰는 높은 강도로 조정했다. 평가에는 수정된 코드 줄과 모델 심판을 사용했지만, 수정 자체가 정답을 뜻하지 않고 표본·관측 기간에도 한계가 있다고 밝혔다. 리뷰 품질과 남은 과제

추론 강도는 답변 길이만 바꾸는 설정도 아니다. Claude 공식 문서는 effort가 답변·도구 호출과 인자·활성화된 thinking에 영향을 준다고 설명한다. Sonnet 5.5의 강도는 Sonnet 5와 재조정되어 같은 이름이 같은 생각 토큰량을 뜻하지 않는다고 명시한다. 모델 교체 전후 비교에서는 설정 이름을 기록하는 데 그치지 말고 실제 호출과 토큰량을 다시 보아야 한다. 추론 강도와 모델별 차이

여기서 가져올 판단은 역할마다 요구하는 검토 깊이가 다르다는 것이다. 문서 표기를 살피는 역할과 보안 경계를 살피는 역할을 같은 단가 목표에 맞추면 비용 숫자는 단순해져도 중요한 차이를 감춘다. 다음 표는 자체 평가를 설계할 때 사용할 질문이다. 특정 모델의 우열을 측정한 결과가 아니다.

바꿀 대상	먼저 고정할 것	비용과 함께 볼 결과
공통 입력의 배치	모델·강도·검토 자료	실제 쓰기/읽기 토큰, 결과 누락
도구 목록·조회 순서	필요한 권한·검토 범위	불가능한 호출, 중복 조회, 추가 턴
모델	같은 변경분·규칙·역할	중요한 문제를 놓친 사례, 오탐
추론 강도	같은 모델·역할	추가로 찾은 유효 문제와 지연
재검토 생략	이전 검토 이후 바뀐 범위	변경이 다른 파일·규칙에 미친 영향

예를 들어 문서 파일만 바뀌었다고 재검토 전체를 생략하는 규칙은 그 문서가 생성 코드나 정책의 입력인 저장소에서 실패할 수 있다. 반대로 실행 경로와 무관한 오탈자 변경까지 모든 전문 리뷰어가 처음부터 읽으면 낭비가 생긴다. 생략 기준은 파일 확장자 하나보다 실제 의존 관계와 검토 목적에 연결하는 편이 낫다.

품질 비교에는 모델이 내놓은 지적만 모으지 말고 지적이 없었던 변경분도 일부 포함하자. 이미 발견한 문제만 평가하면 놓친 문제를 찾을 기회가 없다. 기준 문제를 심은 변경분, 사람이 확인한 실제 수정 사례, 오탐을 구분하고 평가자의 불확실성도 남긴다. 지적 개수가 같아도 중요한 문제와 사소한 제안의 구성이 다르면 같은 품질이라고 할 수 없다.

내 서비스에서 첫 번째로 바꿀 한 가지

우선 대표 작업 몇 개의 비용 장부를 다음 형태로 만들어 보자. 아래는 기록 양식이며 실측값은 비워 둔다. 실제 자료가 쌓이기 전에는 절감률을 쓰지 않는다.

작업 분류 / 대상 변경 버전:
역할 / 모델 버전 / 추론 강도:
공통 입력 버전 / 캐시 보관 조건:
일반 입력 / 캐시 쓰기 / 읽기 / 출력 토큰:
호출 수 / 오류 복구 호출 / 취소 뒤 계속된 호출:
실제 요금표 기준 총비용 / 완료 시간:
놓친 중요 문제 / 유효 지적 / 오탐 / 평가 불확실성:
이번에 바꾼 한 조건 / 되돌릴 조건:

읽기 토큰이 대부분이라면 공통 입력을 더 캐시하는 것보다 매번 보내는 자료와 호출 수를 먼저 살펴볼 이유가 있다. 첫 쓰기가 반복된다면 공통 영역의 위치·변경·만료부터 조사한다. 출력 비용이 지배적이라면 캐시 배치만으로 얻을 절감에는 한계가 있다. 어떤 변화든 중요한 검토 누락이 새로 확인되면 비용 개선과 별도로 원인을 평가하고 해당 설정을 되돌린다.

추론 내부의 저장 공간이 궁금하면 LLM 메모리와 KV 캐시, 기다리는 구간을 찾으려면 AI 지연의 임계 경로를 이어 읽을 수 있다. 모델 비용 밖의 사람 검토·복구까지 포함한 선택은 에이전트 완료 비용 분석에서 다룬다. 이 글의 표를 다시 사용할 때는 저장 기능으로 남기고, 후속 분석은 RSS에서 받아볼 수 있다.