Claude Code를 조직에 도입하면 개인의 습관만으로는 답할 수 없는 질문이 남습니다. 자리를 비웠다 돌아오면 첫 응답이 왜 유난히 느리고 비싼지, Amazon Bedrock으로 사용하는 조직에서는 누가 얼마나 쓰는지를 어디서 확인할 수 있는지 같은 질문입니다. 이 글은 Claude Code 토큰 비용 최적화 시리즈의 2부입니다. 1부(비용 구조와 세션 습관)에서는 비용이 컨텍스트 크기에 비례하고 실제 지불 단가는 프롬프트 캐싱(prompt […] ||
Claude Code를 조직에 도입하면 개인의 습관만으로는 답할 수 없는 질문이 남습니다. 자리를 비웠다 돌아오면 첫 응답이 왜 유난히 느리고 비싼지, Amazon Bedrock으로 사용하는 조직에서는 누가 얼마나 쓰는지를 어디서 확인할 수 있는지 같은 질문입니다.
이 글은 Claude Code 토큰 비용 최적화 시리즈의 2부입니다. 1부(비용 구조와 세션 습관)에서는 비용이 컨텍스트 크기에 비례하고 실제 지불 단가는 프롬프트 캐싱(prompt caching) 적중률이 정한다는 구조 위에서, 측정 도구와 개인의 세션 습관을 다뤘습니다. 캐시 읽기는 표준 입력 단가의 약 10%로 과금되고, 캐시를 새로 쓰는 비용은 캐시 유지 시간인 TTL(Time To Live)에 따라 표준의 1.25~2배인 1회성 투자입니다. 이번 글은 이 캐시가 언제 유지되고 언제 깨지는지, 그리고 구독, Claude Console, Amazon Bedrock 각각에서 조직이 비용을 어디서 통제하는지를 다룹니다. 대상 독자 기준은 1부와 같고(AWS 콘텐츠 기준 Level 200~300), 1부를 읽지 않아도 이해할 수 있도록 핵심 개념은 이 글에서 다시 정의합니다. 본문의 수치와 기본값은 Claude Code 공식 문서와 Amazon Bedrock 사용자 가이드의 2026년 8월 기준입니다.
1. 캐시 경제학
캐시 수명, 무효화 조건, 적용 범위의 순서로 캐시의 동작 방식을 정리합니다.
1.1 캐시 수명(TTL)
캐시는 적중할 때마다 타이머가 리셋되므로 계속 작업하는 동안은 만료되지 않고 유지됩니다. 구독에서는 Claude Code가 1시간 TTL을 자동으로 요청해서 한 시간 안쪽의 공백은 버팁니다. 플랜 한도를 소진해 usage credits 과금으로 넘어가면 쓰기 단가가 싼 5분 TTL로 자동 전환되는데, 1시간을 유지하고 싶으면 ENABLE_PROMPT_CACHING_1H=1을 둡니다. API 키, Amazon Bedrock, Google Cloud의 Agent Platform에서는 기본 5분이고, 같은 변수로 1시간을 선택할 수 있습니다.
# 셸 환경 또는 settings.json의 env 블록
export ENABLE_PROMPT_CACHING_1H=1 # API, Bedrock 등에서 1시간 TTL opt-in
export FORCE_PROMPT_CACHING_5M=1 # 디버깅용: 인증 방식과 무관하게 5분 강제
export MAX_THINKING_TOKENS=8000 # 고정 상한 방식 모델의 thinking 토큰 제한
export CLAUDE_CODE_GOAL_CHECKIN_MINUTES=0 # 유휴 중 goal 체크인 중지
1.2 캐시를 방해하는 행동과 지키는 행동
캐시는 프리픽스(prefix, 요청의 앞부분)의 정확한 일치로 동작하므로, 프리픽스 어딘가를 바꾸는 행동은 그 뒤 전부를 재계산하게 만듭니다. 다음 행동 뒤에는 요청이 부분 또는 전체 캐시 미적중으로 처리됩니다.
행동
무효화 이유
대응
/model 전환
모델마다 캐시가 분리됨
세션 초반에 결정하고 유지
/effort 변경
effort 수준마다 캐시가 분리됨
세션 초반에 결정하고 유지
fast mode 첫 활성화
요청 헤더가 캐시 키에 포함됨
사용할 예정이면 세션 초반에. 이후 on/off 토글은 캐시 유지
MCP 서버 연결, 해제
프리픽스에 로딩된 도구 정의가 변경됨
tool search 지연 로딩이면 영향 없음
MCP 제공