Claude Code 비용을 이해할 때 핵심은 “토큰을 얼마나 썼나”만이 아닙니다. 같은 입력 토큰이라도 캐시에서 읽었는지, 새로 계산해 캐시에 썼는지에 따라 비용과 지연 시간이 크게 달라집니다.
Claude Code 같은 장시간 에이전트는 이전 요청에서 처리한 프롬프트 앞부분을 재사용하는 프롬프트 캐싱으로 비용과 응답 지연을 줄입니다.1 따라서 캐시 히트율은 단순한 성능 지표가 아니라, 실제 운영 비용을 좌우하는 핵심 변수입니다.
캐시 미스가 왜 비싼가
프롬프트 캐싱에서 캐시 히트는 이미 계산한 입력을 다시 사용하는 상태입니다. 반대로 캐시 미스는 같은 입력이라도 다시 읽고 계산해야 하는 상태입니다.
가격 차이는 작지 않습니다. 예시 기준으로 일반 입력 토큰은 1배, 캐시 쓰기는 1.25배, 캐시 읽기는 0.1배로 설명됩니다.2 즉 캐시에 새로 쓰는 토큰은 캐시에서 읽는 토큰보다 12.5배 비쌉니다.
이 차이는 짧은 요청에서는 잘 보이지 않을 수 있습니다. 하지만 긴 코드베이스, 대형 CLAUDE.md, 누적된 세션 컨텍스트처럼 10만 토큰 규모의 입력을 다루는 세션에서는 매 턴 체감됩니다. 캐시가 유지되면 긴 컨텍스트를 싸고 빠르게 재사용할 수 있지만, 캐시가 깨지면 같은 대화라도 매번 비싼 입력 처리를 반복하게 됩니다.
캐시는 “앞부분이 같아야” 유지된다
Claude의 프롬프트 캐싱은 prefix matching 방식으로 동작합니다. 요청 시작 부분부터 cache_control 중단점까지의 내용이 이전 요청과 일치해야 캐시를 재사용할 수 있습니다.1
중요한 점은 prefix 중간 어디에서든 내용이 바뀌면 그 이후 캐시가 무효화된다는 것입니다.1 그래서 Claude Code는 캐시 재사용을 극대화하기 위해 잘 변하지 않는 정적 시스템 프롬프트와 도구 정의를 앞에 두고, CLAUDE.md, 세션 컨텍스트, 대화 메시지처럼 바뀔 가능성이 큰 내용은 뒤에 배치합니다.1
실무적으로는 “프롬프트 앞부분을 얼마나 안정적으로 유지하느냐”가 비용 최적화의 출발점입니다.
캐시를 깨는 흔한 패턴
캐시 미스는 큰 변경에서만 생기지 않습니다. 작고 사소해 보이는 차이도 prefix를 바꾸면 캐시를 깨뜨릴 수 있습니다.
예를 들어 정적 시스템 프롬프트에 매번 달라지는 상세 타임스탬프를 넣으면 요청 앞부분이 계속 바뀝니다. 도구 정의의 내용은 같더라도 순서가 비결정적으로 섞이면 이전 prefix와 달라져 캐시가 깨질 수 있습니다.1
Claude Code는 이런 문제를 피하기 위해 시간 변경이나 파일 변경 같은 업데이트를 시스템 프롬프트 자체에 반영하지 않고, 다음 사용자 메시지나 도구 결과의 system-reminder 태그로 전달합니다.1 핵심은 변해야 하는 정보와 변하지 않아야 하는 정보를 분리하는 것입니다.
모델 전환도 캐시 비용을 만든다
캐시는 모델별로 분리됩니다. 따라서 대화 중 모델을 바꾸면 기존 모델에서 쌓아 둔 캐시를 그대로 쓰기 어렵습니다.1
예를 들어 Opus로 10만 토큰 규모의 대화를 이어가다가 쉬운 질문이라는 이유로 Haiku로 전환하면, Haiku용 프롬프트 캐시를 다시 만들어야 할 수 있습니다. 이 경우 더 저렴한 모델을 선택했더라도 캐시 재생성 비용 때문에 오히려 비싸질 수 있습니다.1
즉 모델 전환은 단순한 “단가 절약”이 아니라 “캐시를 새로 만드는 비용 이벤트”로 봐야 합니다.
Claude Code 비용 최적화의 기준
Claude Code에서 비용을 줄이는 방법은 단순히 짧게 묻는 것이 아닙니다. 더 중요한 것은 캐시가 유지되도록 안정적인 prefix를 설계하는 것입니다.
실무적으로는 다음 기준을 기억하면 됩니다.
정적 시스템 프롬프트와 도구 정의를 안정적으로 유지한다.
도구 목록과 순서가 매번 달라지지 않게 한다.
상세 타임스탬프처럼 자주 변하는 값은 프롬프트 앞부분에 넣지 않는다.
시간 변경, 파일 변경 같은 업데이트는 후속 메시지나 도구 결과로 전달한다.
CLAUDE.md와 세션 컨텍스트 변경이 캐시에 미치는 영향을 의식한다.
모델 전환은 캐시 재생성 비용까지 포함해 판단한다.
Anthropic이 Claude Code의 프롬프트 캐시 적중률을 알림 대상으로 모니터링하고, 적중률이 너무 낮으면 장애 사건으로 다루는 이유도 여기에 있습니다.1 캐시 미스는 단순한 비효율이 아니라, 장시간 에이전트 제품의 비용 구조와 사용자 경험을 동시에 흔드는 운영 리스크입니다.
결론은 분명합니다. Claude Code에서 캐시 히트율은 부가적인 최적화가 아니라 핵심 설계 요소입니다. 긴 컨텍스트를 자주 다루는 팀일수록 “무엇을 프롬프트 앞부분에 둘 것인가”와 “무엇을 뒤로 미룰 것인가”를 비용 전략의 일부로 다뤄야 합니다.
1Lessons from building Claude Code: Prompt caching is everything
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.