Claude Code를 본격적으로 사용하기 시작하면 다음과 같은 고민이 생깁니다.

• 생각보다 토큰(=비용)을 많이 소비하는 것 같다
• 별로 큰 일을 시키지 않았는데 소비가 빠르다
• 세션이 길어지면 후반부에는 속도도 느려지고 정확도도 떨어진다
• 무엇이 소비를 늘리고 있는지 근본적으로 모르겠다

토큰 소비는 단순히 '사용한 양'만으로 결정된다고 생각하기 쉽지만, 실제로는 사용 방식의 설계에 따라 크게 달라집니다. 같은 성과를 내면서도 소비량을 절반 이하로 억제하는 것은 드문 일이 아닙니다. 게다가 소비를 줄이는 노력은 그대로 정확도와 속도의 개선으로 이어집니다.

이 기사에서는 Claude Code의 토큰 소비를 줄이기 위한 실전 테크닉 8가지를 소개합니다. 어려운 설정은 필요 없으며, 대부분은 평소의 요청 방식을 조금 바꾸는 것만으로 충분합니다.

먼저, 무엇이 토큰을 소비하고 있는지 파악해야 합니다. 소비의 정체는 크게 다음 3가지입니다.

토큰을 잡아먹는 3대 요인
├─ ① 읽어들인 파일의 내용 (Read / grep 결과)
├─ ② 도구(Tool) 실행 결과 (빌드 로그, 테스트 출력, 에러 전문)
...

중요한 것은 ③입니다. Claude Code는 한 번의 응답마다 그때까지의 대화 전체를 매번 다시 읽습니다. 즉, 대화가 길어질수록 1회당 소비량이 점점 불어납니다. 후반부에 소비가 빠르게 느껴지는 이유는 바로 이 때문입니다.

이 3가지를 '어떻게 쌓아두지 않을 것인가, 어떻게 줄일 것인가'가 비용 절감의 전부입니다. 아래의 8가지는 모두 이 사고방식의 응용입니다.

가장 효과적임에도 불구하고 잘 활용되지 않는 것이 바로 이것입니다. 대화 이력은 응답할 때마다 재전송되므로, 불필요해진 이력을 품은 채 계속 진행하는 것은 매번 돈을 내고 과거의 쓰레기를 읽게 하는 것과 같습니다.

태스크가 바뀌면 /clear로 대화를 통째로 폐기합니다.

인증 버그 수정 완료 → 다음은 문서 작성
→ 여기서 /clear 실행
→ 더 이상 필요 없는 인증 코드의 읽기 결과를 매번 재전송하지 않아도 됨

"테마가 바뀌면 /clear를 한다"를 습관화하는 것만으로도 장시간 작업의 총 소비량을 크게 낮출 수 있습니다.

같은 태스크를 계속해야 해서 /clear를 할 수는 없지만, 대화가 너무 길어진 경우라면 /compact를 사용하세요. 대화 이력을 요약본으로 압축하여, 이후에는 그 요약본만 재전송하도록 합니다.

나아가 /compact는 무엇을 남길지 지정할 수 있습니다.

/compact 지금까지의 설계 판단(DB는 Postgres, 인증은 JWT)과
미완료된 TODO만 남겨줘. 디버깅 중의 시행착오나 에러 로그는 버려줘.

이렇게 하면 요약에서 불필요한 부분이 깎여나가 이후의 재전송량이 줄어듭니다. 버려도 되는 것(해결된 에러 로그, 시행착오)을 명시하는 것이 요령입니다.

소비의 숨은 주범은 ①번인 파일 읽기입니다. 2000행짜리 파일을 통째로 읽게 하면 그것만으로도 단번에 토큰을 잡아먹습니다. 정말 필요한 것이 20행뿐이라 할지라도 말입니다.

Before (통째로 읽기):

"utils.ts를 읽고 formatDate를 수정해줘"
→ 2000행이 전부 읽힘

After (범위를 좁혀 읽게 하기):

"utils.ts의 formatDate 함수만 수정해줘.
먼저 grep으로 정의 위치를 특정하고, 그 함수의 전후 맥락만 읽어줘."

"먼저 찾은 다음, 필요한 범위만 읽어라"라고 단계를 지시하는 것만으로도 읽기량이 대폭 줄어듭니다.

②번인 도구 실행 결과도 큰 비중을 차지합니다. 실패한 테스트의 풀 로그, 긴 스택 트레이스(Stack Trace). 이것들은 한 번에 대량의 토큰을 소비합니다.

에러 전문을 그대로 가져오게 하지 말고, 요점만 보고하게 하세요.

Before: 테스트 실패 로그를 전문으로 가져옴
After: "테스트를 실행하고, 실패한 테스트 이름과 에러의 요점
(메시지 1줄 + 파일:행 번호)만 보고해."

그리고, 문제가 해결되었다면 그 로그는 책상에서 치워야 합니다. 테크 2의 /compact를 사용하여 "디버깅 과정은 버려줘"라고 지정하여 정리하세요.

"src/ 하위 폴더를 전부 읽어서 구성을 파악해줘"와 같은 횡단 조사(Cross-sectional investigation)는 방치하면 수십 개 파일의 내용이 부모 대화에 쌓이게 되고, 이후 계속해서 재전송됩니다.

이런 조사는 서브 에이전트(Sub-agent)에게 위임하여 결과의 요약만 받는 것이 효율적입니다.

"src/ 하위의 아키텍처 조사는 서브 에이전트에게 맡기고,
주요 모듈의 책임과 데이터 흐름의 요약만 받아와줘."

서브 에이전트(Sub-agent)가 읽어들인 파일의 내용은 부모 대화에 쌓이지 않습니다. **"조사가 무거운 부분은 별도의 작업장에서 수행하게 하고, 결과의 요약본만 가져오게 한다"**으로써 부모 대화의 컨텍스트를 가볍게 유지할 수 있습니다.

한 번 조사했던 내용을 세션(Session)을 넘나들며 몇 번이고 다시 조사하고 있지는 않나요? 그것은 매번 토큰을 지불하며 동일한 조사를 반복하는 것과 같습니다.

조사 및 설계의 결과물은 .md 파일로 작성합니다.

"조사 결과를 docs/architecture-notes.md에 정리해줘.
다음부터는 이 파일만 읽으면 파악할 수 있는 상태로 만들어줘."

다음부터는 "docs/architecture-notes.md를 읽어줘"라는 한마디만으로, 수십 개의 파일을 다시 로드하지 않고도 파악된 상태로 복귀할 수 있습니다. 휘발되는 대화가 아니라, 남는 파일로 성과를 옮겨두는 것이 포인트입니다.

매 세션마다 "이 프로젝트는 Postgres를 사용해", "테스트는 vitest를 사용해"라고 설명하고 있지는 않나요? 대화로 매번 전달하면 그만큼 토큰을 소비하게 되며, /clear를 할 때마다 내용이 사라져 다시 설명해야 하는 반복이 발생합니다.

변하지 않는 전제 조건은 CLAUDE.md에 적어둡니다. 자동으로 읽히며, /clear를 해도 사라지지 않습니다.

# CLAUDE.md
## 기술 스택 (고정)
- DB: PostgreSQL / 인증: JWT
...

이렇게 하면 매번 반복하던 설명이 사라지고, /clear도 부담 없이 사용할 수 있게 됩니다. 테크 1의 /clear 습관과 함께 사용하면 효과적입니다.

모든 작업에 최고 성능의 모델이 필요한 것은 아닙니다. 간단한 정형 작업이나 가벼운 수정에는 경량화된 저비용 모델로도 충분한 경우가 많습니다.

Claude Code는 사용 중인 모델을 전환할 수 있습니다 (/model로 확인 및 변경).

무거운 모델이 적합한 작업: 복잡한 설계, 어려운 버그 원인 규명, 대규모 리팩터링 (Refactoring)
가벼운 모델로 충분한 작업: 정형적인 수정, 포맷 정리, 단순 치환

"지금 어려운 일을 하고 있는가?"를 의식하여, 난도가 높은 부분만 무거운 모델에 맡기고 가벼운 작업은 가벼운 모델로 돌리면 전체적인 비용을 억제할 수 있습니다.

주의: 모델의 선택지나 명칭은 시기에 따라 달라질 수 있습니다. 현재 사용 가능한 모델은 직접 /model을 입력하여 확인하시기 바랍니다.

토큰 소비를 줄이는 노력은 곧 정확도 향상과 속도 개선으로 이어집니다. 대화를 가볍게 유지하면 Claude Code는 장시간 사용해도 명료함을 유지하며, 결과적으로 불필요한 재작업도 줄어듭니다.

우선은 **테크 1(태스크 구분 시 /clear)**과 테크 3(범위를 좁혀 읽기) 두 가지부터 시작해 보세요. 이 두 가지만으로도 소비량의 차이를 체감할 수 있을 것입니다.

테크 6, 7에서 언급한 "파일로 성과를 옮기는 운용", "CLAUDE.md에 전제를 두는 운용"은 설계 패턴을 알고 있으면 시작하기가 더 쉽습니다. 제가 사용 중인 스킬을 무료로 공개하고 있습니다.

무료 스타터 (GitHub · CC BY 4.0):

CLAUDE.md 설계 및 계획 우선 개발 (PIV) 등 4가지 스킬이 일본어와 영어로 포함되어 있습니다. 컨텍스트를 가볍게 유지하는 운용의 토대를 만드는 데 사용할 수 있습니다. 우선 무료 리포지토리(Repository)부터 시도해 보세요.

최신 팁은 X에서도 발신하고 있습니다: @k___n___t_1125