세션 중간에 룰 파일 고치면 토큰 비용이 뛰는 이유

어제와 똑같은 작업을 시켰는데 토큰 사용량이 두 배 가까이 나온 적 없나요? 저도 로그를 열어 보니 범인은 모델이 아니라 제 손이었어요. 세션 중간에 룰 파일을 한 줄 고친 게 문제였거든요.

프롬프트 캐시는 앞부분만 기억해요

프롬프트 캐싱은 시스템 프롬프트나 룰 파일처럼 매번 똑같이 들어가는 앞부분을 저장해 두고 재사용하는 기능이에요. Anthropic 공식 문서 기준으로 캐시를 읽을 때는 기본 입력 요금의 10%만 내고, 새로 쓸 때는 25%를 더 내요. 캐시가 계속 맞으면 입력 비용이 10분의 1 수준까지 내려가는 구조예요.

중요한 건 캐시가 앞에서부터 정확히 일치하는 구간만 재사용한다는 점이에요. 중간에 한 글자만 달라져도 그 뒤는 전부 새로 계산해요.

캐시를 조용히 날리는 5가지 실수

1. 세션 중간에 룰 파일 수정

룰 파일은 프롬프트 맨 앞에 붙어요. 한 줄만 고쳐도 뒤가 전부 무효화돼요. 직접 돌려 보니 같은 작업인데 캐시 적중이 사라지면서 입력 비용이 눈에 띄게 뛰더라고요. 룰 수정은 세션을 닫은 뒤로 미루는 편이 싸요.

2. 세션 중간에 모델 변경

캐시는 모델별로 따로 잡혀요. 중간에 다른 모델로 바꾸면 쌓아 둔 캐시를 버리고 처음부터 다시 쓰기 시작해요.

3. 가변값을 앞쪽에 두기

현재 시각이나 랜덤 ID를 시스템 프롬프트 상단에 넣으면 호출마다 앞부분이 달라져서 캐시가 한 번도 안 맞아요. 적용해 봤더니 가변값을 프롬프트 끝으로 옮기는 것만으로 적중률이 돌아왔어요.

4. 직렬화 순서 방치

내용이 같아도 JSON 키 순서나 툴 정의 순서가 호출마다 바뀌면 다른 프롬프트로 취급돼요. 키 정렬과 툴 순서를 코드에서 고정해 두세요.

5. 같은 프롬프트 병렬 동시 발사

첫 요청이 캐시를 만들기 전에 나머지를 같이 쏘면 전부 캐시 없이 계산돼요. 테스트해 보면 첫 요청 하나를 끝낸 뒤에 병렬로 도는 쪽이 훨씬 저렴해요.

• ✓룰 파일 고정
• ✓모델 유지
• ✓가변값은 뒤로
• ✓직렬화 순서 고정
• ✓첫 요청 후 병렬

세션 운영 습관으로 굳히기

기본 캐시는 5분이 지나면 사라져요. 자리를 오래 비웠다 돌아오면 다시 쓰기 비용부터 낸다는 뜻이에요. 저는 캐시 읽기 비율을 로그로 확인하는데, 전체의 85% 아래로 떨어지면 위 다섯 가지부터 점검해요.

혼자서 플랜씨(plan-c) 같은 서비스를 만들다 보면 에이전트 세션이 하루 종일 이어져요. 라이프케어로그처럼 1인 개발로 여러 제품을 돌리는 상황일수록 이 습관 하나가 월 비용을 꽤 갈라놓더라고요.

룰 정리→세션 시작→작업 유지→세션 종료→룰 수정

캐시는 성실한 반복을 좋아해요. 룰을 고치고 싶어지면, 세션부터 닫아 보세요.