Claude Code를 하루 서너 시간만 써도 월 사용료 고지서가 무섭게 올라갑니다. 필자도 그랬습니다. Opus 4.7이 xhigh 추론까지 지원하면서 한 세션에 수백만 토큰이 녹아내리는 일이 잦아졌고, 리밋 걸려서 작업이 끊기는 경험을 몇 번 하고 나니 설정 자체를 근본부터 다시 짜야겠다는 결론에 도달했습니다.
이 글은 2026년 4월 현재 Opus 4.7 + xhigh 환경에서 직접 테스트한 토큰 절약 설정 9가지를 정리한 기록입니다. Anthropic 공식 Prompt Caching 문서, CLAUDE.md 메모리 최적화, hooks, Claude Code Router(CCR), .claudeignore, /clear, /compact, MCP 정리 같은 항목을 한 덩어리로 묶어 놓았습니다.
숫자 자랑을 하려는 글이 아닙니다. 같은 작업을 같은 퀄리티로 끝내되 투입 토큰만 줄이자는 이야기입니다. 결과부터 말씀드리면, 반복 작업 기준 cached input tokens 히트율이 오르면서 체감 비용이 눈에 띄게 줄었습니다.
원인을 모르고 절약부터 하려니 효과가 안 났습니다. 토큰 소진 속도가 빠른 구조적 이유는 크게 네 가지입니다.
첫째, Claude Code는 매 턴마다 system prompt + CLAUDE.md + 최근 대화 전체를 재전송합니다. 캐싱 없이 쓰면 같은 CLAUDE.md를 100번 찍어 보낸다는 뜻입니다.
둘째, 툴 호출이 많은 코드베이스일수록 Read/Grep 결과가 컨텍스트에 계속 누적됩니다. node_modules 한 번 잘못 읽으면 수십만 토큰이 단숨에 날아갑니다.
셋째, 모델 선택이 기본 Opus로 고정돼 있으면, 단순 파일 이동·포맷팅 같은 작업에도 최고가 모델이 붙습니다. Sonnet이면 충분한 일이 많습니다.
넷째, /clear, /compact를 안 쓰면 세션이 길어질수록 컨텍스트 윈도가 가득 차서 매 턴 비용이 선형으로 올라갑니다.
이 네 축을 따로따로 공략하는 것이 이 글의 뼈대입니다.
Claude Code는 프로젝트 루트의 CLAUDE.md를 system prompt 근처에 매 턴 포함시킵니다. 이 파일이 캐시 히트하는가가 절약의 절반입니다.
Anthropic Prompt Caching 문서에 따르면 cache hit 시 input token 비용이 원가의 10% 수준으로 떨어집니다(Opus 기준 cache write는 1.25배, cache read는 0.1배). 즉, 같은 system prompt를 반복 호출할 때만 의미가 있습니다.
CLAUDE.md를 다음 원칙으로 다시 짰습니다.
STATIC/DYNAMIC 경계를 분리해 놓으니 반복 세션에서 cached input tokens 비중이 눈에 띄게 올라갔습니다.
Claude가 실수로 node_modules, dist, .next, vendor, 빌드 아티팩트를 읽어 버리면 한 번에 수십만 토큰이 증발합니다. 프로젝트 루트에 .claudeignore를 두고 다음을 넣어 둡니다.
node_modules/
dist/
build/
.next/
.venv/
__pycache__/
*.min.js
*.lock
coverage/
파일만 두는 것으로는 부족하고, Grep·Glob이 자동으로 이 경로를 피해 가는지 체감 테스트를 해 봐야 합니다. 필자는 매번 새 프로젝트 들어갈 때 .claudeignore를 가장 먼저 세팅합니다. 한 번의 사고 읽기가 한 달치 절약을 날려 버리기 때문입니다.
둘은 비슷해 보이지만 역할이 다릅니다.
/clear — 세션 전체 리셋. 지금까지의 모든 대화와 파일 읽기 기록을 날립니다/compact — 요약 유지. 과거 맥락을 짧게 압축해서 토큰을 줄입니다필자의 타이밍 기준은 이렇습니다.
| 상황 | 선택 | 이유 |
|---|---|---|
| 작업 주제가 완전히 바뀔 때 | /clear | 이전 맥락이 방해가 됨 |
| 같은 작업을 이어가되 토큰이 찰 때 | /compact | 맥락은 유지 |
| 30턴 이상 주고받았을 때 | /compact 우선 | 필수는 아니지만 캐시 효율 유지 |
| 긴 파일 여러 번 읽어서 컨텍스트 무거울 때 | /compact | 과거 Read 결과 압축 |
/clear와 /compact는 언제 쓰든 공짜가 아닙니다. /compact는 요약 생성에 토큰이 들어가기 때문에, 너무 자주 때리면 오히려 손해입니다. 10~15턴 주기 정도가 체감상 균형점이었습니다.
Opus 4.7은 강력하지만 비싸고, 대부분의 반복 작업은 Sonnet 4.5로도 충분합니다. 모델 전환 기준은 간단합니다.
Claude Code에서 /model sonnet으로 바꾸면 해당 세션은 Sonnet으로 돕니다. 작업이 복잡해지면 다시 /model opus로 올리면 됩니다. 한 파이프라인 안에서 Opus와 Sonnet을 섞어 쓰는 방식이 가장 효율적이었습니다.
참고로 Sonnet 전환 시 OAuth 관련 에러가 간헐적으로 나는 환경이 있습니다(필자 경험). 사용료 절감이 목적이면 에러 회피 루틴도 같이 마련해 둬야 합니다.
settings.json의 hooks는 Claude 자체가 아니라 harness가 실행하는 장치입니다. 토큰 절약 관점에서 쓸모 있는 훅은 다음입니다.
rg 대신 Grep tool 강제) 전에 경고·차단예를 들어 RTK(Rust Token Killer) 같은 프록시를 hook으로 걸면 git status, ls, cat 같은 명령의 출력을 압축해서 토큰을 60~90% 줄이는 구조를 만들 수 있습니다. 필자 환경에서도 데일리 파이프라인에 적용 중입니다.
훅은 잘못 걸면 작업 자체가 막히니, 처음에는 읽기 전용 명령부터 적용하고 점진적으로 확대하는 편이 안전합니다.
CCR은 작업 종류에 따라 Opus / Sonnet / Haiku / 외부 모델을 자동 라우팅해 주는 프록시 도구입니다. 직접 /model을 매번 바꾸는 대신, 규칙 기반으로 스위칭이 됩니다.
라우팅 규칙을 잘 짜면 "고급 작업은 품질 유지, 잡일은 싼 모델"이라는 이상적 구조가 잡힙니다. 모든 사람에게 필수는 아니지만, 월 사용량이 꾸준히 큰 사람에게는 ROI가 좋은 편입니다.
CCR을 쓸 때 주의할 점은 라우팅 규칙 자체가 잘못되면 오히려 Opus가 엉뚱한 데 붙어서 비용이 터진다는 것입니다. 초기 1~2주는 라우팅 로그를 직접 눈으로 확인하는 편이 좋습니다.
MCP 서버를 많이 붙여 놓으면 각 서버의 tool 설명이 system prompt에 포함돼 매 턴 토큰을 먹습니다. 당장 안 쓰는 MCP는 과감히 비활성화합니다.
필자의 기준은 이렇습니다.
Serena MCP처럼 코드베이스 색인용 MCP는 특정 프로젝트에서만 유효합니다. 글로벌로 켜 두면 매 세션마다 색인 로딩 비용이 발생합니다. 필요한 프로젝트의 .mcp.json에만 붙이는 편이 토큰 효율이 좋습니다.
"90% 절약"이라는 표현은 Anthropic 공식 Prompt Caching 문서의 cache read price가 기본 input price의 10% 수준이라는 점에서 나온 숫자입니다. 전체 토큰이 아니라 cache hit된 input tokens에 한해서만 적용됩니다. 오해하면 안 됩니다.
필자가 측정해 본 기준(개인 환경, 사용 빈도에 따라 다름)은 대략 이렇습니다.
| 구분 | cached input 비중 | 체감 |
|---|---|---|
| 캐시 설계 전 | 낮음 | 세션이 길어질수록 input 비용 급증 |
| STATIC/DYNAMIC 분리 후 | 유의미하게 상승 | 같은 작업 반복 시 비용 안정화 |
| hooks + /compact 병행 | 추가 상승 | 30턴 넘어가도 비용 선형 증가 억제 |
정확한 수치는 /cost 명령으로 세션별 토큰 사용량과 비용을 직접 확인하는 것이 가장 신뢰할 만합니다. 남의 후기보다 본인 사용 패턴을 재는 게 빠릅니다.
토큰 절약과 별개로, 작업이 끊기는 것도 비용입니다. 리밋에 걸리거나 토큰이 만료되면 복구에 또 토큰이 들어갑니다.
다음 두 가지를 병행합니다.
리밋은 피할 수 없을 때가 있습니다. 중요한 건 복구 비용이 0에 가까워야 한다는 것입니다.
필자의 블로그 파이프라인(네이버 블로그 1편 기준, keyword·SERP·본문·이미지·옵시디언 저장 전 과정)을 동일한 퀄리티로 돌렸을 때의 체감 차이입니다.
| 항목 | Before | After |
|---|---|---|
| CLAUDE.md 캐시 | 구조 미분리 | STATIC/DYNAMIC 분리 |
| .claudeignore | 없음 | 표준 세트 적용 |
| 모델 | Opus 4.7 고정 | Opus + Sonnet 혼용 |
| hooks | 없음 | RTK-style 훅 적용 |
| /compact 타이밍 | 거의 안 씀 | 10~15턴 기준 |
| MCP | 전부 켬 | 코어 5개 + 필요시 활성 |
| 체감 비용 | 월 사용료 기준 높음 | 약 절반 수준으로 안정 |
"월 $200 → $20 같은 극단적 절감이 가능한가요?"라는 질문을 자주 받습니다. 특정 반복 작업(캐시 적중률이 높고 Sonnet으로 대체 가능한 작업)에 한해서는 이론상 가능하고, 실제로 그 근처까지 내려간 사례도 있습니다. 다만 모든 사람의 월 사용료가 동일 비율로 줄지는 않습니다. 작업 성격에 따라 다릅니다.
Q1. Claude Code 토큰이 왜 이렇게 빨리 소진되나요?
매 턴 system prompt + CLAUDE.md + 과거 대화가 재전송되기 때문입니다. 캐싱 없이 쓰면 반복 비용이 선형으로 쌓입니다. 여기에 node_modules 같은 대용량 폴더를 잘못 읽으면 수십만 토큰이 단번에 소진됩니다.
Q2. 프롬프트 캐싱으로 정말 90% 절약이 가능한가요?
정확히는 cache read로 처리된 input tokens의 단가가 기본 input 단가의 10% 수준이라는 의미입니다(Anthropic 공식 Prompt Caching 문서 기준). 전체 월 사용료가 무조건 90% 줄어드는 것이 아니라, 캐시 적중률이 높을수록 해당 부분의 비용이 줄어듭니다.
Q3. Claude Code 월 사용료를 절반으로 줄이려면?
다음 다섯 가지를 동시에 적용하는 것이 현실적입니다. CLAUDE.md 캐시 설계, .claudeignore 적용, Sonnet 모델 병행, /compact 주기 관리, MCP 다이어트. 한두 개만 건드려서는 체감 변화가 작습니다.
Q4. /clear와 /compact는 언제 쓰는 게 효율적인가요?
주제가 완전히 바뀌면 /clear, 같은 작업을 이어가되 토큰이 찰 때는 /compact입니다. 10~15턴 주기로 /compact가 체감상 균형점이었습니다. /compact 자체도 요약 토큰을 쓰니 매 턴 남발은 금물입니다.
Q5. Opus와 Sonnet 중 어느 모델이 토큰 효율이 좋나요?
단가는 Sonnet이 훨씬 쌉니다. 다만 복잡한 설계 판단이나 긴 리팩터링은 Opus가 한 번에 끝내기 때문에 총 비용에서 역전되는 경우도 있습니다. 작업 난이도별로 나눠 쓰는 것이 정답입니다.
Q6. node_modules 같은 파일을 Claude가 안 읽게 하려면?
프로젝트 루트에 .claudeignore 파일을 두고 node_modules, dist, build, .next 등 제외 경로를 적어 둡니다. 새 프로젝트 시작할 때 가장 먼저 하는 세팅입니다.
Q7. 리밋 걸렸을 때 끊김 없이 계속 작업하는 방법이 있나요?
세션 체크포인트 패턴이 효과적입니다. 긴 배치 작업은 중간 상태를 파일로 저장해 두고, 리밋 해제 후 그 지점부터 이어서 돌리는 구조로 설계합니다. HANDOFF.md 누적 업데이트도 같은 맥락입니다.
Q8. 토큰 사용량은 어디서 확인하나요?
Claude Code 안에서 /cost 명령으로 현재 세션의 토큰 사용량과 비용을 바로 볼 수 있습니다. 이 숫자를 보고 설정을 조정하는 게 남의 후기 보는 것보다 훨씬 정확합니다.
Claude Code 토큰 절약은 한 방에 끝나는 마법이 아니라, 작은 설정 여러 개를 겹쳐 쌓는 작업입니다. 핵심만 다시 짚자면 CLAUDE.md 캐시 설계, .claudeignore, 모델 혼용, /compact 주기, hooks, MCP 다이어트 — 이 여섯 가지만 확실히 잡아도 체감 비용은 절반 가까이 내려옵니다. 시작은 /cost로 본인 지금 숫자를 한 번 찍어 보는 것부터입니다.