같은 문서를 매번 새로 읽히고 있다면: 프롬프트 캐싱으로 입력 요금 줄이는 순서
사내 규정집이나 제품 설명서를 AI에게 읽히고 직원 질문에 답하게 하는 도구를 API로 직접 만들어 쓰는 팀이 있습니다. 이런 도구는 질문이 들어올 때마다 지시문과 긴 문서를 맨 앞에 붙여 처음부터 다시 보내는 경우가 많습니다. 질문은 한 줄인데 문서가 훨씬 길다면, 입력 요금은 같은 글을 반복해서 읽히는 데 쓰이고 있는 셈입니다.
이때 쓰는 기능이 프롬프트 캐싱입니다. 한 번 읽힌 앞부분을 저장해 두었다가 다시 쓸 때 낮은 단가로 계산해 주는 기능입니다. 앤트로픽 프롬프트 캐싱 공식 문서 기준으로 캐시 읽기 단가는 대부분 모델에서 기본 입력의 0.1배입니다. 그런데 Opus 5.5와 Sonnet 5.5는 0.05배, Fable 5.1과 Mythos 5.1은 0.025배로 더 낮습니다. 캐시에 처음 저장하는 쓰기에는 기본 입력의 1.25배가 붙고, 기본 수명은 5분입니다.
그렇다면 캐싱을 켜기만 하면 어떤 모델에서든 입력 요금이 일률적으로 90% 줄어들까요? 그렇지 않습니다. 할인은 요청 맨 앞부분이 이전 요청과 완전히 같고, 수명 안에 다시 읽힐 때만 생깁니다. 읽기 배율과 최소 길이도 모델마다 다릅니다. 그래서 지시문과 문서를 프롬프트 맨 앞에 고정하고 바뀌는 질문을 맨 뒤에 두는 일, 쓰는 모델의 읽기 배율과 최소 길이를 공식 문서에서 확인하는 일이 함께 가야 합니다.
이 글은 노션 AI처럼 완성된 도구의 Q&A 기능이 아니라, API로 직접 호출 구조를 짜는 팀의 프롬프트 배치만 다룹니다.
캐시 읽기 단가는 모델마다 다릅니다
읽기 단가를 기본 입력 단가에 곱하는 배율로 보면 모델별 차이가 한눈에 들어옵니다. 앤트로픽 공식 문서에 적힌 배율은 다음과 같습니다.
- 대부분 모델: 기본 입력의 0.1배
- Opus 5.5, Sonnet 5.5: 0.05배
- Fable 5.1, Mythos 5.1: 0.025배
- 5분 캐시 쓰기: 모든 모델 1.25배, 1시간 캐시 쓰기: 2배
같은 문서를 같은 횟수로 읽혀도 모델에 따라 읽기 비용이 최대 네 배까지 벌어집니다. 0.1배와 0.025배의 차이입니다. 따라서 “캐싱하면 90% 싸진다”는 숫자는 읽기 배율이 0.1배인 대부분 모델의, 다시 읽힌 부분에만 맞습니다. 모델을 바꾸거나 새로 고를 때는 그 모델의 읽기 배율을 표에서 다시 찾아야 합니다.
쓰기에 1.25배가 붙는데 언제부터 이득일까요?
캐시는 처음 저장할 때 기본 입력보다 비싸게 계산하고, 다시 읽을 때 싸게 계산하는 구조입니다. 고정 앞부분의 기본 입력 단가를 1로 놓고 배율만 곱합니다. 읽기 0.1배 모델에서 5분 캐시를 쓰는 경우입니다.
- 캐시 없이 두 번 보내면: 1 + 1 = 2
- 캐시를 쓰면: 1.25(쓰기) + 0.1(읽기) = 1.35
- 한 번만 보내고 끝나면: 캐시 없이 1, 캐시를 쓰면 1.25
한 번만 보내면 오히려 25% 더 냅니다. 두 번째 호출부터 이득이 시작됩니다. 열 번을 5분 안에 이어서 보내면 첫 번째가 쓰기, 나머지 아홉 번이 읽기이므로 1.25 + 0.9 = 2.15이고, 캐시 없이는 10입니다. 읽기 0.05배 모델이라면 같은 두 번 호출(5분 캐시)이 1.25 + 0.05 = 1.30이 됩니다.
이 계산은 고정 앞부분에만 적용됩니다. 매번 바뀌는 질문 부분은 기본 단가 그대로입니다. 또 이 글의 계산은 공식 문서의 배율을 곱한 것이며, 실제 청구 금액을 측정한 결과가 아닙니다.
수명 5분 안에 다시 읽혀야 합니다
기본 수명은 5분이고, 캐시된 내용이 사용될 때마다 추가 비용 없이 수명이 갱신됩니다. 질문이 5분 안에 계속 이어지는 업무 시간대라면 캐시가 살아 있고 읽기 단가가 계속 적용됩니다. 반대로 질문 사이 간격이 5분보다 길어 캐시가 사라지면 다음 질문에서 다시 쓰기 비용을 냅니다.
호출 간격이 더 길다면 1시간 수명 옵션이 있습니다. 대신 1시간 캐시 쓰기는 기본 입력의 2배입니다. 읽기 0.1배 모델을 기준으로 같은 앞부분을 두 번 보내면 2 + 0.1 = 2.1이어서 캐시 없이 보낸 2와 비슷하고, 세 번 보내면 2.2로 캐시 없이 보낸 3보다 낮아집니다. 간격이 길수록 몇 번 다시 읽힐지를 먼저 따져 보아야 하는 이유입니다.
고정 앞부분이 너무 짧으면 캐시가 만들어지지 않습니다
캐시가 가능한 최소 프롬프트 길이는 모델마다 512, 1,024, 2,048, 4,096 토큰으로 다릅니다. 토큰은 AI가 글을 나눠 읽는 단위입니다. 앤트로픽 공식 문서는 이보다 짧으면 캐시 표시를 해도 캐시 없이 처리되고 오류도 나지 않는다고 안내합니다.
그래서 요금표만 보고 캐싱을 켠 뒤 효과가 없는 채로 지나갈 수 있습니다. 확인 방법도 문서에 있습니다. 응답에 담기는 사용량 항목 중 캐시 생성 토큰과 캐시 읽기 토큰이 둘 다 0이면 캐시가 되지 않은 것입니다. 지시문이 짧고 문서를 붙이지 않는 도구라면 최소 길이에 못 미칠 수 있습니다.
OpenAI도 모델마다 할인율이 다릅니다
OpenAI 프롬프트 캐싱 공식 문서에 따르면 프롬프트 캐싱은 기본으로 자동 적용됩니다. 캐시된 입력의 할인율은 모델별로 달라 최대 95%입니다. GPT-5.6 이후 모델은 최소 1,024 토큰에 읽기 0.1배, 쓰기 1.25배로 안내돼 있습니다.
여기서도 같은 결론입니다. 자동으로 적용된다고 해서 모든 모델이 같은 할인을 받는 것은 아닙니다. 쓰는 모델의 캐시 입력 단가를 공식 가격표에서 직접 확인해야 합니다.
잘못된 배치와 올바른 배치
앤트로픽 공식 문서는 도구 정의, 시스템 지침, 맥락, 예시 같은 정적 내용을 프롬프트 맨 앞에 두라고 안내합니다. 앞부분이 이전 요청과 완전히 같아야 하므로 바뀌는 값은 뒤로 보내야 합니다.
- 잘못된 배치: 요청 시각과 질문자 이름, 지시문, 규정 문서, 질문. 맨 앞부터 매번 달라지니 뒤의 긴 문서가 같아도 앞부분이 일치하지 않습니다.
- 올바른 배치: 지시문, 규정 문서, 그다음에 요청 시각과 질문. 앞의 두 덩어리가 매번 같으므로 재사용 대상이 됩니다.
규정 문서를 개정하면 그 지점부터 앞부분이 달라지므로 한 번은 다시 쓰기 비용이 생깁니다. 원리상 그렇다는 추론이며, 개정 주기가 잦은 문서는 이 비용을 감안해야 합니다.
효과가 없거나 줄어드는 경우
캐싱이 맞지 않는 구조가 있고, 이 글의 근거에도 한계가 있습니다. 먼저 효과가 거의 없는 구조입니다.
- 호출 간격이 캐시 수명(기본 5분)보다 길어 다시 읽히지 않는 호출은 쓰기 비용만 남습니다.
- 고정 앞부분이 모델별 최소 길이(512~4,096 토큰)보다 짧으면 캐시가 만들어지지 않습니다.
- 요청마다 맨 앞부분이 달라지는 구조에서는 효과가 거의 없습니다.
다음은 이 글이 다루지 못한 부분입니다. 모든 단가는 공식 문서를 2026년 10월에 확인한 값이어서 모델과 요금이 바뀌면 달라집니다. 절감되는 금액은 호출 횟수와 문서 길이에 따라 달라지므로 이 글은 배율만 다룹니다.
오늘 바꿀 순서
- 지금 호출에서 매번 같은 부분(지시문, 문서)과 매번 바뀌는 부분(질문, 시각, 사용자 정보)을 나눠 적습니다.
- 같은 부분을 맨 앞에, 바뀌는 부분을 맨 뒤에 놓도록 호출을 고칩니다.
- 쓰는 모델의 읽기 배율과 최소 캐시 길이를 공식 문서에서 확인합니다.
- 같은 부분이 최소 길이를 넘는지, 질문 간격이 수명 안인지 따져 보고, 간격이 길면 1시간 옵션의 쓰기 2배를 감안해 비교합니다.
- 며칠 운영한 뒤 응답의 캐시 사용량 항목과 청구 내역으로 실제로 읽기가 일어나는지 확인합니다.
가장 먼저 할 일은 1번입니다. 호출 한 건의 내용을 펼쳐 놓고 맨 앞에서 처음 바뀌는 글자가 어디인지 찾아보시기 바랍니다. 그 글자 앞까지가 지금 재사용될 수 있는 앞부분입니다.
저희 연구소가 쓴 책 『긴 답변은 친절이 아니라 요금이다』 9장 ‘같은 문서를 매번 새로 읽히지 마라’에서 이 내용을 더 자세히 다룹니다.
