Claude Code / Codex의 토큰 절약: 같은 용량으로 더 많이 사용하기
요약
본 글은 Claude Code 환경에서 발생하는 높은 초기 컨텍스트(context) 비용 문제를 분석하고, 이를 절감하는 방법을 제시합니다. 특히 System prompt, Memory 등 세션 시작 시 로드되는 고정비용이 상당하여 토큰 사용량 관리가 중요함을 강조합니다. 효율적인 개발을 위해 파일 길이 제한 준수와 스킬 최적화가 필요하며, 불필요한 컨텍스트 로딩을 줄이는 것이 핵심입니다.
핵심 포인트
- 세션 시작 시 System prompt 등 고정비용이 상당하여 토큰 관리가 필수적이다.
- AGENTS.md나 CLAUDE.md 같은 파일은 공식 가이드에 따라 200줄 이내로 유지하는 것이 좋다.
- 불필요한 스킬이나 컨텍스트 로딩을 줄여 초기 비용을 절감할 수 있다.
서론
안녕하세요, Gakken LEAP의 프런트엔드 엔지니어 kou입니다.
매일 아침 coding agent를 열면 몇 번의 대화만으로 200k 토큰의 대화 창이 채워집니다. 주간 사용량도 주 중반에는 한도에 가까워지고, 남은 날은 절약 모드입니다.
상위 플랜으로 올리는 것이 빠르겠지만, 그전에 무엇에 얼마나 쓰고 있는지 확인해보고 싶었습니다. 절약 방법은 많지만, 자신의 환경에서 AGENTS.md와 memory, 모델, 긴 대화 중 어디부터 손대야 할지 알 수 없었습니다.
그래서 아무 말도 하지 않은 상태에서 토큰 사용처를 순서대로 조사했습니다. 플랜을 올리지 않고 월 20달러 구독으로 얼마나 많이 사용할 수 있는지 시험해보고자 합니다.

대화를 시작하기 전에 이미 차감된 비용
Claude Code에서 새 세션을 열고 질문하기 전에 /context를 실행합니다. Messages는 거의 비어 있어도 System prompt, System tools, Skills, Memory, Custom agents가 이미 로드되어 있습니다. 이것이 세션별 고정비용입니다.
제 자신의 머신을 정리하기 전에는 이렇습니다. System prompt 5.7k, System tools 6.4k, Skills 6.0k, Memory 7.3k, Custom agents 80 토큰. 합계 25.5k입니다.
창이 크면 25.5k는 눈에 띄지 않습니다. 하지만 세션마다 발생하기 때문에, 하루에 20개의 세션을 열면 대화 전 고정비용만으로 약 510k 토큰입니다. 이는 중규모 리포지토리의 소스를 통째로 한 번 읽는 양에 가깝습니다.

Anthropic의 기사에서는 세션 비용을 세 가지로 분류합니다. context에 들어가는 토큰의 양, 그것이 몇 턴 지속되는지, 동시에 몇 개의 context를 구동하는지입니다. 모델 가격은 이 모든 것에 곱해집니다. context에 가장 먼저 들어가는 것이 바로 이 25.5k이므로, 우선 여기서 줄일 수 있는 것들을 로드되는 타이밍별로 조사했습니다.
무엇이 언제 context에 들어가는가
고정비를 정리할 때는 내용물과 로드되는 시점을 살펴봅니다.
| 계층 | 로드되는 타이밍 | 포함하는 내용 |
|---|---|---|
| CLAUDE.md / AGENTS.md | 세션마다 매번 | 움직이기 전에 반드시 알아야 할 제약 사항 |
| ... |
CLAUDE.md / AGENTS.md
Claude Code는 두 가지를 모두 읽기 때문에, 리포지토리에 AGENTS.md만 있어도 추가 설정은 필요 없습니다. 공식 가이드에서는 파일당 200줄 이내를 권장합니다. 내용이 길수록 context를 많이 사용하고 지시 사항을 따르기 어려워지기 때문입니다. 남길 기준은 하나,
토큰 수순으로 정렬하고, 스킬을 선택하여 Space에서 상태를 전환할 수 있습니다. name-only
은 이름만 남기고 description을 제거하며, user-only는 모델에게 숨긴 채 /이름을 통한 수동 호출만 남깁니다. Esc 키로 저장하면 현재 리포지토리의 .claude/settings.local.json에 skillOverrides로 작성됩니다.
큰 스킬 묶음은 실행 시에도 무거워집니다. Superpowers에는 86개의 스킬이 있으며, 구상, 사양서, 엄격한 검토(review), subagent 파견까지 진행합니다. 호출할 때마다 비용이 들기 때문에, 시작 시의 description만으로는 비용을 측정하기 어렵습니다. issue #750에는 토큰 소모를 이유로 사용을 중단했다는 의견도 있습니다.
MCP와 CLI
MCP와 CLI의 차이는 tool schema를 언제 읽느냐에 있습니다. 필요할 때 읽는 클라이언트도 늘었지만, 시작 시 모든 것을 포함하는 것도 있습니다. 후자의 경우 GitHub를 gh로, Sentry를 sentry-cli로 바꾸면 초기 context를 줄일 수 있습니다.

Mario Zechner의 120회 비교에서는 성숙한 CLI가 있는 영역이라면 MCP로 감쌀 필요는 없다는 결론이었습니다. 다만 결과는 작업에 따라 다릅니다.
gh 같은 CLI라면, 출력을 모델에게 전달하기 전에 걸러낼 수 있습니다. gh pr view --json title,body의 경우 제목과 본문만으로 다른 필드는 context에 들어가지 않습니다. MCP가 반환하는 필드는 서버 측에서 결정합니다.
context에 넣지 않아도 되는 작업
정형적인 작업은 스크립트에 맡깁니다. 변경 파일을 규칙으로 조사하거나, 데이터를 정해진 형식으로 배열하는 것입니다. 모델에게 시키면 재료가 모두 context에 들어가고, 이후 턴에서도 계속 보내집니다. 스크립트라면 결과를 한 줄만 반환하면 됩니다.
전체를 자동화할 필요도 없습니다. 모델이 필요한 것은 판단 부분만이며, 의심스러운 부분을 찾아내는 것은 스크립트 쪽이 누락될 염려가 적습니다. 제가 관리하는 콘텐츠 파일에서는 sh 스크립트를 lint로 전체 리포지토리에 적용하여 해당 라인만 모델에게 전달합니다. 해당하더라도 오류는 아닐 수 있으며, 수정할지 여부는 모델이 판단합니다.
캐시를 낭비하지 않기
고정 비용 다음은 캐시입니다. 노력이 적게 들면서 절약 효과도 컸던 부분입니다.
prompt cache는 같은 prefix에 히트(hit)합니다. Claude의 캐시 읽기는 일반 입력 단가의 1/10~1/40이며, 높은 모델일수록 할인율이 더 커집니다. 1시간 동안 캐시를 작성하는 비용은 일반 비용의 2배이고, 구독 서비스의 메인 대화는 기본적으로 이 1시간 캐시입니다. 도중에 prefix를 변경하면 그전까지의 작성이 무효가 됩니다.
1시간은 세션 시작부터가 아니라 마지막 히트 시점부터 계산됩니다. 히트할 때마다 기한이 연장되며, 1시간을 사용하지 않으면 만료됩니다. 다음 날로 돌아가거나 61분 후에 돌아와도 캐시 입장에서는 같습니다.

커뮤니티에서 듣는
| 자주 하던 작업 | 실제로 발생하는 일 | 이제 이렇게 한다 |
|---|---|
| 버그를 수정한 후 /clear 하지 않고 다음 이야기로 넘어간다 | 이전 태스크에서 읽은 파일과 명령어 출력이 이후 턴마다 계속 전송된다 | 태스크가 끝나면 /clear
|
| 이야기 도중에 모델이나 추론 레벨을 바꿔서 시도한다 | 대부분 캐시가 무효화되어, 이력을 전부 다시 계산하게 된다 | 처음에 모델과 추론 레벨을 정하고 중간에 바꾸지 않는다 |
| 1시간 이상 간격을 두고 돌아와 계속한다 | TTL이 만료되어, 이력을 전부 다시 읽게 된다 | 다음 날까지 이어갈 작업은 인계(引き継ぎ)를 작성하고 새로운 세션으로 시작한다 |
| 자리를 뜨기 전에 compact 하지 않고, 돌아와서 압축한다 | 압축 자체가 보통 단가가 된다. 캐시가 유효할 때라면 캐시 단가로 끝낼 수 있다 | 그날 다시 계속할 거라면, 자리 뜨기 전에 /compact
|
| 파일 이름만 알려주고 agent에게 찾게 한다 | grep을 해서 여러 파일을 여는 동작이 전부 이력에 들어간다 | @를 붙여서 파일을 지정한다 |
| 테스트를 돌려서 수백 줄을 흘린다 | 명령어 출력은 대화 끝까지 남아있다 | 조용히 하는 옵션을 AGENTS.md에 적는다 |
캐시가 줄이는 것은 비용과 대기 시간이며, context의 길이는 변하지 않습니다. 앞서 말한 고정비 25.5k도 히트하면 저렴한 단가로 계산됩니다. 매 턴 늘어나는 대화 이력이 더 무거울 때가 있습니다.
긴 대화 자체가 비용
캐시가 유효하더라도, 대화를 계속 길게 이어가면 비용이 오르고 답변의 질도 불안정해집니다.
Chroma가 18개의 최신 모델을 측정했을 때, 입력이 길어질수록 정확도는 떨어졌고, 그 하락세는 일정하지 않아 상한에 도달하기 전에 30~50% 떨어지는 경우도 있었습니다.
제가 창(window)을 1M으로 설정했을 때는 체감상 350k 토큰 정도부터 이전 이야기를 잊거나, 확정된 것을 재확인하거나, 다시 하는 경우가 늘어나는 변화가 눈에 띄었습니다. 350k는 개인의 체감이며, 경계는 태스크에 따라 다릅니다.
질적인 문제만은 아닙니다. 같은
추론 레벨을 높일수록 output 단가로 계산되는 thinking token이 늘어납니다. thinking에 4,000 토큰, 답변에 500 토큰을 사용하면, 답변만 사용하는 경우의 약 9배입니다.
간단하고 검증하기 쉬운 작업에는 low, 일반적인 개발에는 medium, 난제에는 high나 xhigh를 사용하며, 게다가 max도 있습니다. Claude Code 문서에서도 max는 너무 많이 생각해서 효과가 정체되기 쉽다고 주의하고 있습니다.
레벨 변경 시 캐시가 유지되는지는 모델에 따라 다릅니다. Opus 5.5, Sonnet 5.5, Fable 5.1은 API key 또는 Claude 구독을 사용하면 유지되지만, 많은 모델에서는 히스토리를 다시 읽습니다.
저도 한 번 해봤습니다. 간단한 질문을 max로 설정했더니, 여러 subagent가 이미 확인된 결론을 계속 의심하기 시작했고, 토큰은 평소의 몇 배, 속도도 느려졌습니다. 이것저것 돌려봐도 나오는 것은 같은 결론이었습니다.
모델 분업도 가능합니다. 메인 모델이 태스크 분할, 중요한 판단, 최종 확인을 담당하고, 검색, 정리, 테스트 실행 등 범위가 명확한 작업은 Luna처럼 저렴한 모델의 subagent에게 넘깁니다. OpenAI는 Luna를 고처리량(high-throughput)으로 비용에 중점을 둔 용도에 배치했습니다.
다만, 긴 context를 양쪽에 전달하면 절약 효과는 떨어집니다. 높은 모델에 전달할 prompt를 짧게 하고, 호출 횟수도 줄입니다.
codegraph는 어디까지 유효한가
코드 검색 도구에서도 모델에 보내는 내용을 줄일 수 있습니다. codegraph는 코드베이스 전체를 읽어 검색용 인덱스를 만들고, agent가 필요한 조각을 한 번에 가져올 수 있게 합니다. 1,277개 파일의 리포지토리에서는 생성에 1.5초가 걸렸습니다. 이후 세 가지 태스크에서 호출 횟수와 context에 들어간 바이트 수를 비교했습니다.
| 태스크 | codegraph | grep + 파일 읽기 | 결과 |
|---|---|---|---|
| 특정 composable을 변경할 때 누가 영향을 받는지, 어떤 테스트를 실행할지 | 2회, 17.4KB | 23회, 67.9KB | 호출 91% 감소, 바이트 74% 감소 |
| ... |
두 번째 항목에서 바이트 수가 grep의 3.5배가 된 것은, codegraph가 로그인 경로의 호출원과 관련 테스트까지 반환했기 때문입니다. grep은 파일 목록만 제공했습니다. 한편, 세 번째 항목에서는 이름이 비슷한 함수가 반환되어 목적한 문구에는 도달하지 못했습니다. 관계를 조사할 때는 codegraph를, 문구를 찾을 때는 grep을 사용합니다.
다만, codegraph는 한 번에 대량의 원문을 반환하며, 답변 후에도 히스토리에 남습니다. 문서에 따르면, 몇 턴 후에 context에 남는 검색 내용은 grep보다 약 80% 더 많아집니다.
사용 슬롯은 일찍 여는 것이 좋다
Claude처럼 일정 시간으로 나뉜 사용 슬롯이라면, 사용하는 방식의 요령이 있습니다. 첫 메시지를 보낸 시점이 기점이 되므로, 아침에 정기적으로 가벼운 메시지를 보내 미리 슬롯을 열어둡니다. 출근 시간에는 슬롯이 중반까지 진행되어 점심 전후에 리셋되므로, 하루에 사용할 수 있는 슬롯이 늘어납니다. 늘어나는 것은 슬롯의 사용 편의성이지, 토큰 총량이 아닙니다.
열린 슬롯과 주간 상한선을 얼마나 사용했는지는 statusline에 표시해 두면 항상 볼 수 있습니다. Claude Code라면 context 점유율, 캐시 히트율, 5시간 슬롯 및 주간 상한선 소진율을 한 줄에 나열할 수 있습니다. Codex CLI의 /statusline
하지만 context 비율과 두 가지 슬롯의 잔량을 보여줄 수 있습니다. 설정 방법은 다른 글에 작성했습니다.
요약
token이 사용되는 순서대로 정리하면 다음과 같습니다.
- 대화 시작 전 고정 비용:
/context를 한 번 보는 것 (Codex CLI는/status, 총량만).
상주 파일은 가급적, 없으면 업무가 끝나지 않는 부분으로 제한합니다. - 정형 작업: 스크립트로 만들어 해당 결과만 모델에 전달합니다. - 캐시: 처음에 모델과 추론 레벨을 결정하고 도중에 바꾸지 않습니다. 그날 또 계속할 거라면, 자리를 뜨기 전에
/compact를 합니다. - 대화 길이: 태스크가 끝나면/clear를 합니다. 다음 날까지 이어갈 작업은 인수인계를 작성하여 새로운 세션으로 시작합니다. - 추론 레벨과 모델: 간단한 작업에 높은 레벨을 사용하지 않습니다. 범위가 명확한 작업은 저렴한 모델에게 넘깁니다.
오늘 퇴근 전에 한 번 /context
실행하면, 대화 전부터 무엇이 포함되어 있는지 알 수 있습니다.
엔지니어 모집 중
Gakken LEAP은 매일 교육 업데이트에 힘쓰고 있습니다.
관심 있으신 분들은 채용 사이트를 확인해 보세요!
참고
토론

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기