캐시값이 내려가면, 우리 AI 원가는?
캐시 읽기 가격 인하는 작은 팀의 프롬프트 설계와 AI 원가 구조를 바꿉니다.
이번 9월 첫 주 모델 발표에서 작은 팀이 가장 먼저 봐야 할 줄은 벤치마크 점수가 아니라 가격표의 한 줄이었습니다.
Anthropic은 9월 1일 Claude Fable 5.1과 신뢰 접근용 쌍둥이 모델 Mythos 5.1을 내놓으면서 캐시 읽기 가격을 75% 인하했습니다.
본체 토큰 가격은 기존 Fable 5와 같은 수준을 유지한 채, 캐시로 다시 읽는 토큰만 싸진 것입니다.
며칠 사이 Google DeepMind가 Gemini 3.8 Flash를, OpenAI가 GPT-6 Astra를 내놓으며 관심은 성능에 쏠렸지만, 매달 API 청구서를 직접 결제하는 1인 빌더에게 더 큰 사건은 조용히 바뀐 이 캐시 가격입니다.
캐시 가격이 내려가면 우리 원가 구조는 어떻게 바뀔까?
결론부터 말하면, "매번 새로 쓰는 프롬프트"보다 "매번 똑같이 반복되는 프롬프트"가 훨씬 유리해집니다. 새로 들어오는 토큰 값은 그대로인데 반복 재사용되는 앞부분만 싸졌으니, 같은 기능이라도 프롬프트를 어떻게 조립했는지에 따라 원가가 갈립니다.
지금까지는 "프롬프트를 짧게"가 정답에 가까웠지만, 이제는 "긴 부분을 고정해서 재사용"이 더 정확한 정답입니다.
예를 들어 반품 정책·배송 규정·톤앤매너를 담은 3,000토큰짜리 지침을 매 문의마다 붙여 쓰는 상담봇이 있다면, 지금까지 이 3,000토큰은 하루 500건이면 500번 온전한 가격으로 계산됐습니다.
같은 지침을 캐시 블록으로 묶어 첫 호출에서만 새로 읽게 만들면, 이후 호출에서는 그 부분이 캐시 읽기 단가로 처리됩니다.
기능은 그대로인데 청구서만 얇아지는, 흔치 않은 종류의 개선입니다.
그럼 프롬프트를 어떻게 다시 짜야 할까?
핵심은 프롬프트를 고정 블록과 변동 블록으로 분리하고, 고정 블록을 무조건 앞에 두는 것입니다.
캐시는 앞에서부터 일치하는 구간을 재사용하기 때문에, 앞부분에 고객 이름이나 타임스탬프가 하나 끼어 있으면 뒤의 거대한 지침 전체가 캐시를 놓칩니다.
오늘 한 시간만 들여도 정리할 수 있는 작업입니다.
- 맨 앞: 시스템 규칙 — 역할, 금칙어, 출력 스키마, 브랜드 톤. 거의 바뀌지 않는 것들만.
- 그다음: 상시 참조 자료 — 제품 카탈로그 요약, 요금표, FAQ, 정책 문서처럼 모든 문의에 공통으로 필요한 문서.
- 맨 뒤: 변동 입력 — 고객 질문, 세션 이력, 오늘 날짜, 주문번호. 여기만 매번 바뀌게 합니다.
- 고정 블록은 자주 손대지 않기 — 쉼표 하나만 고쳐도 그 시점부터 캐시가 새로 쌓입니다.
프롬프트 수정은 모아서 배포하세요. - 트래픽 패턴 확인 — 문의가 몰리는 시간대에 첫 호출을 미리 한 번 흘려두면 이후 요청이 캐시를 타고 갑니다.
반대로 하루 두세 번만 쓰는 배치 작업은 캐시 효과가 거의 없습니다.
RAG를 쓰는 팀이라면 한 가지가 더 있습니다.
검색 결과를 프롬프트 앞쪽에 붙이는 구조는 매 호출마다 앞부분이 달라져 캐시가 통째로 깨집니다.
고정 지침을 앞, 검색된 문서 조각은 뒤로 옮기는 순서 조정만으로도 히트율이 달라집니다.
캐시를 켜기 전에 확인할 것은 무엇일까?
캐시는 원가 최적화 장치이지 품질 보증 장치가 아닙니다.
프롬프트 구조를 바꾸는 일은 곧 모델이 보는 입력 순서를 바꾸는 일이므로, 답변 품질이 미묘하게 달라질 수 있습니다.
그래서 순서 조정 전후를 같은 질문 20~30개로 비교해 보는 최소 평가 세트가 필요합니다.
조달 계획도 함께 봐야 합니다.
이번 GPT-6 Astra는 방어자 대상 프로그램과 ChatGPT Business·Pro에 먼저 열리고 API 경로는 순차 개방되는 방식이었습니다.
즉 새 모델이 나왔다는 뉴스와 우리 서비스가 그 모델을 API로 쓸 수 있는 시점은 다릅니다.
캐시 최적화를 특정 모델 하나에만 끼워 맞추지 말고, 고정·변동 블록 분리라는 구조 자체를 코드에 남겨 두면 모델을 갈아 끼울 때 그대로 재사용할 수 있습니다.
모델 선택과 묶어서 생각하면 효과가 더 커집니다.
분류·요약·태깅처럼 판단이 단순한 호출은 9월 2일 공개된 Gemini 3.8 Flash 같은 경량·저가 계열로 내리고, 고정 지침이 긴 상담·작성 기능은 캐시가 잘 먹는 상위 모델에 남기는 식의 이원화가 현실적입니다.
한 서비스 안에서 모든 호출을 같은 모델로 처리하는 구조가 사실 가장 비싼 선택입니다.
마지막으로 고정 블록에 무엇을 넣는지 한 번 더 보세요.
자주 재사용되는 블록에 고객 개인정보나 내부 계약 조건이 섞여 들어가면, 절감액보다 큰 리스크를 캐시에 저장하는 셈입니다.
이번 주에 할 일 세 가지
거창한 리팩터링은 필요 없습니다.
아래 세 가지만 하면 다음 달 청구서에서 차이를 확인할 수 있습니다.
- 가장 호출량이 많은 기능 하나를 골라 프롬프트를 고정·변동 블록으로 갈라 적고, 고정 블록을 앞으로 옮깁니다.
- 캐시 읽기 토큰과 신규 입력 토큰을 따로 로그에 남겨 히트율을 매일 확인합니다.
숫자가 없으면 최적화도 없습니다. - 질문 20~30개로 된 평가 세트를 만들어 순서 변경 전후 답변을 비교하고, 품질이 유지될 때만 전면 적용합니다.
모델 발표를 따라다니는 대신 가격표의 각주를 읽는 팀이 이깁니다.
성능 경쟁은 계속 뒤집히지만, 원가 구조를 정리해 둔 팀은 어떤 모델이 이겨도 마진을 지킵니다.