Claude Code 토큰 낭비를 막는 6가지 방법

URL: https://www.youtube.com/watch?v=-QwaaSwQIhE
날짜: 2026-08-20
채널: Tech Bridge
원문 게시일: 2026-08-19
영상 길이: 12분 20초
관련 원문: https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions

📌 핵심 질문 / Claude Code 세션의 토큰 비용을 어떻게 줄일 것인가

==Claude Code의 비용과 성능은 모델을 무작정 오래 붙잡아 두는 데서 좋아지지 않으며, 필요한 컨텍스트만 남기고 캐시를 보존하며 시끄러운 작업을 격리하는 운영 습관에서 결정된다.==

• 서로 다른 작업 사이에는 /clear로 이전 작업의 불필요한 컨텍스트를 제거한다.
• /compact는 세션의 프롬프트 캐시가 살아 있는 첫 1시간 안에 실행해야 재독해 비용을 줄일 수 있다.
• /context와 /memory로 시작부터 로드되는 토큰과 전역 MCP 서버·스킬을 점검하고 주기적으로 가지치기한다.
• 세션 중간의 모델·추론 노력(effort level) 변경은 캐시를 무효화하므로, 다른 모델이 필요하면 서브에이전트로 분리한다.
• 파일은 “찾아봐”라고 시키기보다 @파일명으로 직접 첨부하고, 대량 출력을 만드는 명령은 필터나 저렴한 서브에이전트로 격리한다.

토큰은 단순히 사용량을 나타내는 숫자가 아니라 컨텍스트 캐시, 도구 호출, 검색 결과, 모델·추론 설정이 서로 영향을 주는 운영 자원이다. Claude Max나 Codex처럼 정액제 환경에서는 낭비가 가려지기 쉽지만, 오픈소스 모델이나 API를 직접 사용하는 환경에서는 같은 습관이 곧바로 비용으로 드러난다. 따라서 세션을 작업 단위로 나누고, 입력을 작게 만들며, 메인 모델에는 결론만 전달하는 방식이 장기적으로 중요하다.

1. 컨텍스트 관리: 작업에 필요한 정보만 남기기

첫 번째 묶음의 핵심은 컨텍스트 창을 무한한 메모장처럼 쓰지 않는 것이다. 이전 작업의 흔적과 전역 도구 설정이 매 요청에 따라오면 모델이 읽어야 할 토큰과 비용이 함께 커진다.

1.1. 방법 1 — 작업 전환 때마다 /clear 실행하기

1. 서로 무관한 작업의 컨텍스트를 분리한다

   1. 작업 전환 시점: 한 기능을 구현한 뒤 전혀 다른 기능을 디버깅하거나, 프로젝트를 바꾸는 경우에는 기존 대화의 세부 맥락이 새 작업에 필요하지 않다.
   2. 불필요한 정보 제거: /clear는 지금까지의 대화 컨텍스트를 비워 새 요청이 과거의 파일·실패·추론 기록에 끌려가지 않도록 한다.

2. 컨텍스트를 버리기 전에 산출물을 남긴다

   1. 단계별 아티팩트: 작업 단계마다 필요한 결과를 파일이나 아티팩트로 저장하면, 나중에 그 결과만 다시 불러올 수 있다.
   2. 재현 가능한 흐름: 대화 전체를 계속 들고 가는 대신 구현 결과·테스트 결과·결정 사항을 아티팩트로 남기고 /clear를 실행하면 세션이 가벼워진다.

3. 정액제의 착시를 경계한다

   1. Claude Max의 토큰 한도: 정액제에서는 사용자가 매 요청의 토큰 비용을 직접 보지 않으므로 컨텍스트를 계속 누적하기 쉽다.
   2. 사용 습관의 차이: 컨텍스트를 자주 비우면 장시간 작업에서도 토큰이 계속 소진되는 현상을 줄일 수 있다. 반대로 매번 과거 대화를 유지하면 한도에 빨리 도달한다.

1.2. 방법 2 — /compact는 캐시가 살아 있을 때 실행하기

1. 프롬프트 캐시가 비용을 줄이는 방식

   1. 반복 입력의 저장: 언어 모델 서비스는 사용자가 보낸 메시지와 컨텍스트의 일부를 캐시해 같은 내용을 매번 처음부터 처리하지 않도록 한다.
   2. 캐시의 이점: 캐시가 유효하면 다음 요청에서 전체 대화를 다시 읽고 처리하는 비용을 피할 수 있다.

2. 1시간이 기준이 되는 이유

   1. 유휴 시간의 영향: 세션에서 마지막 메시지 이후 한 시간이 지나면 기존 캐시가 사라진 것으로 간주해야 한다.
   2. 늦은 compact의 비용: 이 시점 이후 /compact를 실행하면 압축 작업 자체가 과거 컨텍스트 전체를 다시 읽어야 하므로, 캐시를 활용하지 못한 채 추가 토큰을 쓸 수 있다.

3. /compact와 /clear를 구분한다

   1. compact의 역할: 계속 유지해야 하는 작업 맥락을 압축해 대화를 이어갈 때 사용한다. 다만 효과를 보려면 한 시간의 창을 넘기기 전에 실행해야 한다.
   2. clear의 역할: 이전 작업을 이어갈 필요가 없을 때 컨텍스트를 통째로 버린다. 서로 다른 작업 사이를 오가는 경우에는 /compact보다 /clear가 더 단순하고 경제적이다.
   3. 기대 효과의 범위: /compact가 갑자기 모델 성능을 크게 높이는 명령은 아니다. 주된 이점은 캐시와 토큰 비용을 관리하기 쉬워진다는 데 있다.

1.3. 방법 3 — /context와 /memory로 시작 컨텍스트를 가지치기하기

1. /context로 첫 요청 전의 부하를 확인한다

   1. 사전 로드 토큰: 메시지를 하나도 보내기 전에 프로젝트 설정·도구·스킬·메모리 등이 얼마나 로드되는지 시각화한다.
   2. 47,000토큰 사례: 화면 예시에서는 Opus 계열 컨텍스트 창에 첫 메시지 전부터 약 47,000토큰이 로드돼 있었다. 과거의 작은 컨텍스트 창에서 코드 블록 하나를 이보다 작게 만들려고 했던 시절과 비교하면 기본 부하 자체가 매우 큰 수준이다.

2. /memory로 메모리의 출처를 나눈다

   1. 11,000토큰 메모리: 같은 예시에서 메모리만 약 11,000토큰을 차지했다.
   2. 메모리 종류 확인: 사용자 메모리인지, 프로젝트 전용 메모리인지, 현재 프로젝트와 무관한 다른 정보인지 구분해야 한다.
   3. 관련성 기준의 정리: 현재 작업과 관계없는 규칙과 기록이 매 세션에 들어오면 매 요청마다 비용을 내면서도 모델의 주의를 흐리게 한다.

3. 전역 도구가 만드는 조용한 팽창을 제거한다

   1. MCP 서버: 새로운 AI 도구를 시험하며 설치한 MCP 서버는 전역에 남아 이후의 모든 세션에 영향을 줄 수 있다.
   2. 스킬과 커스텀 에이전트: Graphify처럼 유행하는 도구는 MCP 서버·커스텀 에이전트·스킬을 함께 설치하는 경우가 많다. 자주 쓰지 않는 구성요소도 자동으로 로드되면 컨텍스트가 계속 부풀어 오른다.
   3. 100,000토큰의 위험: 정리하지 않은 전역 설정이 쌓이면 작업을 시작하기도 전에 100,000토큰이 로드되는 상황이 생길 수 있다. 이는 비용뿐 아니라 실제 작업에 쓸 수 있는 컨텍스트 공간도 줄인다.

4. 정기 점검을 습관화한다

   1. /doctor 활용: Claude Code의 /doctor 명령은 설정·환경 문제를 점검하고 정리 작업을 시작하는 데 도움을 준다.
   2. 주간 점검: 현재 컨텍스트를 일주일에 한 번 확인하는 알림을 설정하면 전역 설정의 누적을 조기에 발견할 수 있다.
   3. 20,000에서 40,000으로의 증가: 발표자는 2~3주 전 정리한 뒤 약 20,000토큰까지 낮췄지만, 다시 약 40,000토큰으로 늘어났다고 설명한다. 증가분은 모든 새 세션에 반복해서 들어가는 순수한 부하이므로 주기적인 가지치기가 필요하다.

2. 리소스 효율: 캐시와 도구 호출을 낭비하지 않기

두 번째 묶음은 같은 컨텍스트를 처리하더라도 모델 설정과 파일 전달 방식을 잘못 선택해 캐시를 깨거나 불필요한 탐색을 유발하지 않는 데 초점을 둔다.

2.1. 방법 4 — 세션 중간에 모델과 effort level을 바꾸지 않기

1. 모델 선택과 추론 노력은 캐시의 일부다

   1. 모델 picker: Claude Code에서는 사용할 모델을 선택할 수 있다. 모델이 달라지면 동일한 대화라도 처리 조건이 달라진다.
   2. effort level: 초보자가 놓치기 쉽지만, 모델이 문제를 얼마나 깊게 추론할지 정하는 effort level도 결과와 비용에 영향을 주는 주요 설정이다.

2. 세션 도중 변경하면 전체 캐시가 무효화된다

   1. 다음 요청의 재독해: 대화가 누적된 상태에서 모델이나 effort level을 바꾸면 기존 프롬프트 캐시를 사용할 수 없게 된다.
   2. 100,000토큰 사례: 세션에 100,000토큰이 쌓인 뒤 모델을 변경하면 다음 메시지에서 그 내용을 다시 읽어야 한다. 결과적으로 더 많은 토큰과 비용이 발생한다.
   3. 성능보다 비용의 문제: 설정 변경이 반드시 결과 품질을 나쁘게 만드는 것은 아니지만, 이미 처리한 정보를 다시 입력하는 비용을 만든다.

3. 다른 모델이 필요하면 서브에이전트로 분리한다

   1. 메인 세션 보존: 현재 세션의 모델·effort 설정을 유지한 채 별도 서브에이전트에 다른 모델을 배정하면 메인 세션의 캐시를 지킬 수 있다.
   2. 업무별 모델 선택: 복잡한 작업은 높은 능력의 모델에, 단순한 확인·탐색은 저렴한 모델에 맡겨 필요한 결과만 메인 모델로 돌려받는다.

2.2. 방법 5 — 파일은 “찾기”보다 @ 멘션으로 직접 전달하기

1. @파일은 요청에 파일을 붙이는 동작이다

   1. 명시적 참조: 예를 들어 프로젝트의 smoke tests 마크다운 파일을 @로 멘션하면 해당 파일이 요청에 직접 첨부된다.
   2. 즉시 사용 가능한 입력: 모델이 파일의 존재를 추측하거나 파일명만 기억하는 것이 아니라, 필요한 파일의 내용을 요청 입력에서 바로 받는다.

2. “그 파일을 찾아봐”가 만드는 비용

   1. 검색 도구 호출: 파일을 찾아 달라는 모호한 지시는 여러 디렉터리의 검색 명령으로 이어질 수 있다.
   2. 검색 결과 읽기: 모델은 검색 명령의 출력과 후보 파일을 다시 읽어야 하며, 이 과정의 도구 호출·출력 토큰이 모두 컨텍스트에 들어온다.
   3. 누적되는 비효율: 한 번의 탐색은 작아 보여도 이런 검색이 반복되면 세션이 불필요한 경로와 결과로 채워진다.

3. 적용 범위를 판단한다

   1. 알고 있는 파일: 경로 또는 파일명이 확실하고 직접 참조할 수 있다면 @ 멘션이 가장 경제적이다.
   2. 불확실한 파일: 파일 위치를 모르는 상황에서 무조건 멘션할 수는 없으므로 검색이 필요하다. 다만 검색 범위를 먼저 좁히고 결과를 필터링하는 방식이 낫다.

3. 노이즈 감소: 큰 출력을 메인 컨텍스트에서 격리하기

세 번째 묶음은 명령 자체보다 명령이 쏟아내는 출력이 문제라는 관점에서 출발한다. 메인 모델에 필요한 결론만 남기면 컨텍스트 오염과 비용을 동시에 줄일 수 있다.

3.1. 방법 6 — 플래그와 서브에이전트로 시끄러운 명령을 정리하기

1. 플래그로 출력량을 먼저 제한한다

   1. Git 상태 확인의 문제: 추적되지 않은 변경 파일이 많은 저장소에서 모델이 아무 옵션 없이 git status를 실행하면 긴 목록 전체가 출력된다.
   2. 컨텍스트 오염: 모델은 그 목록을 읽고 해석해야 하며, 읽은 파일명과 상태가 이후 대화의 캐시에도 들어간다.
   3. 필요한 정보만 선택: 명령의 플래그나 별도의 필터링 도구로 현재 작업에 필요한 상태만 뽑으면 메인 모델에 들어오는 토큰을 줄일 수 있다.

2. 대량 출력은 저렴한 서브에이전트에 맡긴다

   1. 격리 실행: 출력이 클 것이라고 예상되는 명령을 Sonnet 또는 Haiku 서브에이전트에서 실행한다.
   2. 결과 압축: 서브에이전트가 전체 출력을 읽고 필요한 사실만 추려 메인 모델에 전달한다.
   3. 모델 선택: 단순한 상태 조회·요약은 Haiku로 충분할 수 있고, 조금 더 복잡한 해석에는 Sonnet을 사용할 수 있다.

3. Git 상태 예시

   1. 과할 수 있는 작은 작업: Git 상태 하나만 확인하는 데 서브에이전트를 쓰는 것은 경우에 따라 과도한 설계일 수 있다.
   2. 큰 출력에서의 효과: 변경 파일이 많거나 여러 명령을 연달아 실행해야 할 때는 서브에이전트가 출력을 고립시키는 가치가 커진다.
   3. 메인 모델에 남는 결과: 예시에서는 추적되지 않은 변경 사항, 최근 커밋 5개, 스테이징·수정 여부가 없다는 요지만 메인 세션에 전달된다. 전체 로그와 파일 목록은 메인 컨텍스트에 들어오지 않는다.

4. 토큰 절약이 중요한 이유와 설계 원칙

토큰 관리는 단순한 사용량 절약을 넘어 에이전트 시스템을 설계하는 기본 역량으로 이어진다.

4.1. 정액제 환경이 가리는 실제 비용

1. 보조금이 들어간 정액제

   1. 고정 요금의 편리함: Claude Code Max나 Codex 플랜은 사용자가 일정 금액을 내고 많은 작업을 수행하는 구조라, 명령 하나가 몇 토큰을 쓰는지 체감하기 어렵다.
   2. 낭비의 은폐: 모델 제공자가 비용을 보조하는 동안에는 불필요한 검색·재독해·대량 출력을 방치해도 개인 청구서에 즉시 나타나지 않는다.

2. 오픈소스·사용량 기반 모델의 현실

   1. 직접 비용 부담: 오픈소스 모델을 직접 호스팅하거나 API 사용량에 따라 지불하는 환경에서는 모든 재독해와 도구 출력이 비용으로 계산된다.
   2. 나쁜 운영 습관의 대가: 모델이 원하는 대로 탐색하도록 방치하고 결과를 관리하지 않으면 정액제에서 숨겨졌던 비용이 크게 증가한다.

4.2. 프롬프트 캐싱과 GPU 처리의 이해

1. 토큰이 처리되는 경로를 알아야 한다

   1. 서버 GPU: 입력 토큰이 서버의 GPU에서 처리되는 방식이 지연 시간·비용·캐시 효과에 영향을 준다.
   2. 프롬프트 캐싱: 이미 처리한 앞부분을 캐시하면 매번 같은 컨텍스트를 새로 계산하지 않아도 되지만, 모델·effort level 변경이나 긴 유휴 시간은 그 이점을 없앨 수 있다.

2. 에이전트 SDK로 확장할 때의 의미

   1. 제어 기능의 제품화: 에이전트 SDK는 모델 선택, 컨텍스트 전달, 도구 호출, 캐시와 같은 제어 장치를 애플리케이션 안에 노출한다.
   2. 설계자의 책임: 어떤 컨텍스트를 메인 모델에 보낼지, 어떤 작업을 서브에이전트에 맡길지, 언제 캐시를 유지하거나 버릴지 이해해야 사용자 비용과 응답 품질을 함께 관리할 수 있다.

주요 발언 모음

"작업 사이에 /clear를 사용하는 사람이 충분히 많지 않다."

"한 시간이 지난 뒤 /compact를 실행하면, 그 compact를 실행하기 위해 기존에 있던 모든 것을 다시 읽도록 만들게 된다."

"메시지를 하나도 보내기 전에 47,000토큰이 로드되고 있다."

"2~3주 전에 약 20,000토큰까지 정리했는데, 벌써 40,000토큰으로 돌아왔다."

"모델이나 effort level을 세션 중간에 바꾸면 캐시가 완전히 무효화된다."

"파일을 찾아보라고 말하는 것보다 실제 @ 멘션을 사용하는 편이 리소스를 크게 절약한다."

"필요한 특정 조각만 알고 싶다면, 노이즈를 만드는 작업을 서브에이전트에서 실행하는 것이 가치 있다."

핵심 데이터 & 수치

• 47,000토큰: 첫 메시지를 보내기 전 Opus 계열 컨텍스트에 로드된 전체 토큰의 예시다.
• 11,000토큰: 같은 예시에서 메모리가 차지한 토큰 규모다.
• 100,000토큰: 전역 MCP 서버·스킬·에이전트가 누적되면 작업 시작 전에도 로드될 수 있는 위험한 규모다.
• 1시간: 기존 프롬프트 캐시가 사라질 수 있으므로 /compact를 실행하기 전에 고려해야 할 세션 유휴 시간 기준이다.
• 2~3주: 정리 후 약 20,000토큰이던 컨텍스트가 약 40,000토큰으로 다시 늘어난 사례가 관찰된 기간이다.
• 최근 5개 커밋: Git 전체 출력 대신 메인 모델에 전달할 수 있는 요약 정보의 예시다.

결론 및 시사점

1. 작업 경계를 먼저 만든다: 작업이 바뀌면 /clear하고, 이어야 하는 작업만 캐시가 살아 있는 첫 한 시간 안에 /compact한다.
2. 시작 비용을 측정한다: /context로 사전 로드 토큰을 확인하고 /memory·/doctor로 관련 없는 메모리·MCP·스킬·에이전트를 제거한다.
3. 캐시를 깨는 변경을 피한다: 한 세션에서 모델과 effort level을 고정하고, 다른 모델이 필요할 때는 서브에이전트를 생성한다.
4. 입력은 직접 전달한다: 확실히 알고 있는 파일은 @로 첨부해 검색·읽기 도구 호출을 줄인다.
5. 출력은 선별한다: Git 상태처럼 긴 결과를 만드는 명령은 플래그로 필터링하고, 전체 결과가 필요하지 않으면 Sonnet·Haiku 서브에이전트에서 요약한다.
6. 비용 구조를 미리 설계한다: 정액제의 편리함에 기대지 말고 프롬프트 캐싱, GPU 처리, 도구 출력과 서브에이전트 비용을 사용량 기반 환경의 기준으로 관리한다.
7. 에이전트 개발의 기본기로 삼는다: 컨텍스트·모델·도구 호출·캐시를 통제하는 능력은 개인의 Claude Code 사용을 넘어 Agent SDK로 제품을 만들 때도 필수적인 설계 역량이다.

핵심 요약 (20줄)

1. Anthropic의 Claude Code 세션 운영 원칙은 컨텍스트를 줄이고 캐시를 보존하며 노이즈를 격리하는 데서 출발한다.

2. 서로 다른 작업으로 넘어갈 때 /clear를 실행하면 이전 작업의 파일과 추론 기록이 새 세션의 토큰을 차지하지 않는다.

3. 작업 결과를 아티팩트나 파일로 저장하면 컨텍스트를 비워도 필요한 산출물을 다시 불러올 수 있다.

4. Claude Max 같은 정액제에서는 토큰 낭비가 청구서에 바로 보이지 않으므로 컨텍스트를 계속 누적하기 쉽다.

5. /compact는 유지할 작업 맥락을 압축하지만, 세션이 한 시간 이상 멈춘 뒤 실행하면 캐시를 잃어 전체 내용을 다시 읽을 수 있다.

6. /compact는 성능을 극적으로 높이는 명령이 아니라 프롬프트 캐시와 토큰 비용을 관리하는 장치다.

7. /context는 첫 메시지 전부터 프로젝트에 로드되는 설정과 도구의 토큰 규모를 보여준다.

8. 예시 환경에서는 아무 메시지도 보내기 전에 약 47,000토큰이 로드됐고 메모리만 약 11,000토큰을 차지했다.

9. /memory로 사용자 메모리와 프로젝트 메모리를 구분하고 현재 작업과 무관한 기록을 제거해야 한다.

10. 전역 MCP 서버와 커스텀 스킬·에이전트는 새 도구를 시험할수록 누적되어 시작 컨텍스트를 100,000토큰까지 키울 수 있다.

11. /doctor와 주간 점검을 활용하면 정리 뒤 다시 부풀어 오르는 전역 설정을 조기에 발견할 수 있다.

12. 모델 picker와 effort level은 세션의 프롬프트 캐시와 연결되므로 작업 도중 변경하면 기존 캐시가 무효화된다.

13. 100,000토큰이 쌓인 세션에서 모델을 바꾸면 다음 요청이 전체 내용을 다시 읽어 토큰과 비용을 늘린다.

14. 다른 모델이 필요한 작업은 메인 세션의 모델을 바꾸는 대신 적절한 모델의 서브에이전트로 분리한다.

15. 알고 있는 파일은 “찾아봐”라고 지시하지 말고 @파일명으로 직접 요청에 첨부한다.

16. 직접 파일을 멘션하면 검색·디렉터리 탐색·후보 파일 읽기에 쓰이는 도구 호출과 출력 토큰이 줄어든다.

17. 긴 git status 같은 명령은 전체 출력이 메인 컨텍스트를 오염시키고 캐시에 불필요한 파일 목록을 남긴다.

18. 플래그로 출력을 필터링하거나 Sonnet·Haiku 서브에이전트가 필요한 상태만 요약하게 하면 노이즈를 격리할 수 있다.

19. 정액제의 보조금이 사라지고 오픈소스·사용량 기반 모델이 늘어날수록 이런 운영 습관은 실제 비용 차이로 나타난다.

20. 프롬프트 캐싱·GPU 처리·도구 호출을 이해하는 능력은 Claude Code 사용뿐 아니라 Agent SDK 기반 제품 설계에도 필요한 기본기다.