프롬프트 캐시 적중률만 올렸더니 Claude 토큰비용이 줄었어요

자동화 워크플로우를 며칠 돌리다 보면 토큰 사용량이 슬금슬금 올라가요. 코드는 그대로인데 요청 횟수만 늘어서 비용이 붙는 거죠. 혼자 운영하면서 이걸 들여다봤더니, 범인은 모델이 아니라 프롬프트 캐시 적중률이었어요.

캐시 읽기는 원래 싸요

Claude의 프롬프트 캐시는 반복되는 앞부분(프리픽스)을 저장해 두고 재사용하는 구조예요. 직접 확인해 보면 숫자가 꽤 정직합니다.

• ✓캐시 읽기 = 기본 입력의 약 10% 비용
• ✓캐시 쓰기 = 약 25% 추가
• ✓기본 유지시간 5분

캐시에서 읽어 오면 기본 입력의 약 10%(1/10) 비용이고, 캐시에 쓸 때만 약 25%가 더 붙어요. 그러니까 같은 앞부분을 계속 재사용할수록 이득이 커지는 구조예요. 문제는 이 앞부분을 내가 자꾸 흔들고 있었다는 거였어요.

적중률을 깎아먹던 습관들

테스트해 보니 캐시가 깨지는 순간이 정해져 있었어요.

• 세션 중간에 시스템 프롬프트를 손대면 그 뒤 캐시가 통째로 무효가 돼요.
• 요청 앞쪽에 현재 시각이나 랜덤 값을 넣으면 매번 프리픽스가 달라져서 적중이 안 돼요.
• 모델을 중간에 바꾸면 그것만으로 캐시가 리셋돼요.

세 개 다 제가 하고 있던 일이었어요. 특히 "요청마다 타임스탬프를 맨 앞에 붙이는" 습관이 조용히 적중률을 갉아먹고 있었죠.

바꾼 건 세 가지뿐이에요

고정 프리픽스 유지→가변값은 뒤로→적중률 비율 감시

첫째, 자주 안 바뀌는 지시문·규칙은 앞쪽에 고정하고 세션 중간엔 건드리지 않았어요. 둘째, 시각·요청 ID 같은 가변값은 프리픽스 뒤로 몰았어요. 셋째, 로그에 cache_read / 전체 입력 비율을 찍어 두고 0.85 이상을 목표로 감시했어요.

적용해 봤더니 적중률이 90%대로 올라오면서, 워크플로우당 실제 청구되는 입력 토큰이 눈에 띄게 줄었어요. 코드 로직은 한 줄도 안 고쳤는데 말이죠. 캐시 기본 유지시간이 5분이라, 요청 간격이 뜨는 배치는 흐름을 몰아서 5분 안에 붙이는 것도 도움이 됐어요.

정리하면

토큰비용은 더 싼 모델을 찾는 문제가 아니라, 같은 앞부분을 얼마나 자주 재사용하느냐의 문제일 때가 많아요. 저처럼 여러 도구를 자동화로 붙여 쓰는 1인 개발이라면 더 그렇고요. 플랜씨(plan-c)나 플랜엘(plan-l) 같은 서비스의 자동화 파이프라인을 돌릴 때도 같은 원리로 비용을 눌러 봤어요.

거창한 최적화 말고, 오늘은 프롬프트 프리픽스부터 고정해 보세요. 비율 하나만 찍어 봐도 어디서 새는지 금방 보일 거예요.