본문 바로가기
study/TIP

Claude Code 오래 쓰는 법

by 휘루걸음 2026. 9. 4.
반응형

Claude Code 5시간 한도 오래 쓰는 법

짧은 프롬프트보다 중요한 토큰·컨텍스트·캐시 최적화 8가지

Claude Code를 본격적으로 사용하면 어느 순간 코딩보다 사용량 게이지를 더 자주 보게 됩니다.

특히 Claude Pro나 Max 플랜은 5시간 단위 사용량과 주간 한도가 함께 적용됩니다. 프로젝트를 분석하고, 서브에이전트를 실행하고, 테스트와 수정까지 반복하다 보면 5시간이 지나기 전에 한도가 먼저 끝날 수도 있습니다.

그래서 자연스럽게 이런 질문이 생깁니다.

프롬프트를 짧게 쓰면 사용량이 줄어들까?
새 대화를 자주 열어야 할까?
/compact는 언제 써야 할까?
서브에이전트를 쓰면 정말 토큰이 절약될까?
Fable이나 Opus 대신 Sonnet을 쓰는 게 나을까?

결론부터 말하면 Claude Code 사용량 최적화의 핵심은 짧게 질문하는 것이 아닙니다.

더 중요한 것은 다음 세 가지입니다.

불필요한 컨텍스트를 계속 끌고 다니지 않는 것

쉬운 작업에 과도한 모델과 Effort를 사용하지 않는 것

에이전트가 끝없이 탐색하고 재시도하지 않도록 범위를 정하는 것

이 글에서는 Claude Code의 공식 문서를 기준으로, 실제 개발 중 5시간 한도와 주간 사용량을 조금 더 오래 유지할 수 있는 방법을 정리해봤습니다.

※ 2026년 9월 기준입니다. 모델, 요금, Effort 옵션과 Claude Code 명령은 이후 변경될 수 있습니다.


먼저 알아둘 것: 구독 사용량과 API 비용은 같은 숫자가 아니다

Claude Code 사용량 이야기를 할 때 가장 자주 섞이는 개념이 있습니다.

Claude Pro·Max의 사용량

Claude 유료 구독자는 보통 다음 게이지를 봅니다.

  • 5시간 세션 사용량
  • 주간 전체 모델 사용량
  • 특정 모델의 주간 사용량
  • 추가 Usage Credits 사용량

이 퍼센트는 API 토큰 비용을 그대로 달러로 환산해 보여주는 화면이 아닙니다.

Anthropic은 사용한 모델, 대화 길이, 파일 크기, 기능, 작업 복잡도 등에 따라 실제 사용 가능량이 달라진다고 설명합니다. 따라서 “입력 10만 토큰이면 Max 5x 게이지가 몇 퍼센트 줄어든다”처럼 고정된 변환식을 만들 수는 없습니다.

반응형

Claude API 비용

API에서는 입력·출력 토큰 수에 따라 실제 금액이 청구됩니다.

현재 주요 Claude 모델은 기본 입력 토큰보다 출력 토큰의 단가가 약 5배 높습니다.

모델입력 100만 토큰출력 100만 토큰

Claude Fable 5.1 $10 $50
Claude Opus 5 $5 $25
Claude Sonnet 5 $2 $10
Claude Haiku 4.5 $1 $5

이 가격표는 API 기준입니다. Claude Max의 월 구독료와 별도로 이해해야 합니다.

다만 API 비용과 구독 게이지가 다른 체계라고 해서 최적화 방법까지 완전히 다른 것은 아닙니다.

긴 컨텍스트
높은 Effort
많은 출력
반복적인 도구 호출
다수의 병렬 에이전트

이런 작업은 API 비용을 늘리고, 구독 플랜에서도 사용량을 더 빠르게 소진시키는 요인이 됩니다.


입력보다 출력이 비싼 이유를 실무적으로 이해하기

Claude Code에서 말하는 입력에는 단순히 사용자가 작성한 한 문장만 들어가지 않습니다.

한 번의 요청에는 다음 내용이 함께 포함될 수 있습니다.

시스템 지침
CLAUDE.md
Auto Memory
현재까지의 대화
읽어온 소스코드
명령 실행 결과
테스트 로그
MCP 도구 정보
사용자가 새로 입력한 요청

Claude가 생성하는 출력에도 화면에 보이는 답변만 들어가는 것은 아닙니다.

  • 설명과 코드
  • 파일 수정 내용
  • 도구 호출과 인자
  • 내부 Thinking 토큰
  • 후속 작업 판단

특히 Effort는 텍스트 답변뿐 아니라 도구 호출과 Thinking을 포함한 전체 출력 토큰에 영향을 줍니다. Effort가 높을수록 더 깊게 검토할 수 있지만 속도와 사용량 측면에서는 불리해질 수 있습니다.

따라서 다음 두 요청은 같은 한 줄짜리 프롬프트라도 소비량이 크게 다를 수 있습니다.

이 변수명을 userId로 바꿔줘.
전체 프로젝트를 분석하고 문제를 찾아 완벽하게 개선해줘.

프롬프트 글자 수는 비슷할 수 있지만, 두 번째 요청은 저장소 탐색, 설계 판단, 파일 수정, 테스트, 오류 재분석을 연속으로 유발할 가능성이 큽니다.

짧은 프롬프트가 반드시 싼 프롬프트는 아닙니다.

오히려 범위가 모호한 짧은 명령이 더 비싼 작업으로 이어질 수 있습니다.


Claude Code 사용량을 빨리 녹이는 요인

우선순위낭비 요인발생하는 문제

1 관계없는 작업을 한 세션에서 계속 진행 과거 대화가 매 요청의 컨텍스트에 남음
2 모든 작업에 고성능 모델·Max Effort 사용 Thinking과 도구 호출이 과도하게 늘어남
3 전체 저장소·대용량 로그를 무조건 읽힘 필요 없는 입력이 컨텍스트를 차지
4 서브에이전트·에이전트 팀 과다 실행 에이전트마다 별도 컨텍스트와 추론 발생
5 비대한 CLAUDE.md와 미사용 MCP 매 세션의 기본 컨텍스트가 무거워짐
6 종료 조건 없는 자동 작업 재시도·추가 탐색·후속 구현이 계속됨

Anthropic도 예상보다 많은 비용이 발생하는 대표 원인으로 정리하지 않은 장기 세션과 필요 이상으로 비싼 모델 사용을 들고 있습니다. Claude Code는 컨텍스트가 커질수록 매 요청에서 처리해야 할 토큰이 늘어납니다.


1. 작업이 달라졌다면 /clear, 이어갈 작업이라면 /compact

Claude Code 사용량을 아끼는 가장 효과적인 습관은 세션을 적절한 시점에 정리하는 것입니다.

/clear를 써야 할 때

현재 작업과 다음 작업이 서로 관련이 없다면 새 컨텍스트에서 시작하는 것이 좋습니다.

로그인 오류 수정 완료
        ↓
블로그 SEO 페이지 구현 시작

→ /clear
Spring API 분석 완료
        ↓
React 디자인 수정 시작

→ /clear

관계없는 작업인데 기존 세션을 계속 쓰면 이전 코드와 토론, 테스트 결과가 이후 모든 요청에 따라붙습니다.

Anthropic도 작업 주제가 바뀔 때 /clear를 사용하라고 권장합니다. 다시 돌아올 가능성이 있다면 먼저 /rename으로 세션 이름을 붙이고, 나중에 /resume으로 복귀할 수 있습니다.

/rename auth-refactor
/clear

/compact를 써야 할 때

프로젝트와 목표는 같은데 대화가 너무 길어졌다면 /compact가 적합합니다.

/compact는 오래된 대화를 요약해 현재 작업에 필요한 맥락만 남깁니다.

그냥 실행할 수도 있지만, 무엇을 남길지 지정하는 편이 더 안전합니다.

/compact 다음 내용은 반드시 유지해줘:
- 현재 구현 목표
- 수정한 파일 목록
- 확정된 설계 결정
- 실패 중인 테스트와 오류 원인
- 절대 변경하면 안 되는 API 규격

이미 해결된 토론, 전체 로그, 폐기한 접근 방식은 제거해줘.

Anthropic 공식 문서도 /compact 뒤에 보존할 내용을 직접 지시할 수 있다고 안내합니다.

간단한 구분법

상황선택

전혀 다른 업무로 전환 /clear
같은 기능을 계속 개발 /compact
예전 작업으로 돌아감 /resume
현재 컨텍스트 점검 /context
사용량 점검 /usage

2. 모델보다 먼저 Effort를 조절하라

단순 작업에도 항상 가장 강한 모델과 max Effort를 사용하면 사용량이 빠르게 줄어듭니다.

Effort는 Claude가 응답에 얼마나 많은 토큰을 사용할지를 조절하는 옵션입니다.

Effort적합한 작업

low 파일 탐색, 단순 요약, 반복 작업
medium CRUD, 일반적인 수정, 테스트 추가
high 복잡한 구현과 기본 에이전트 작업
xhigh 장시간 코딩, 고난도 문제 해결
max 비용보다 최고 성능이 중요한 작업

Anthropic은 Fable 5.1을 포함한 최신 모델에서 기본값인 high부터 시작하고, 일반 작업은 medium이나 low, 정말 어려운 코딩과 에이전트 작업만 xhigh나 max로 올리는 방식을 권장합니다.

예를 들어 다음 작업에 Max Effort는 대체로 과합니다.

README 오타 수정
변수명 변경
JSON 정렬
단순 테스트 데이터 생성
파일 경로 수정
CSS 여백 변경

반면 다음 작업은 높은 Effort를 고려할 만합니다.

복잡한 동시성 오류 분석
대규모 레거시 구조 파악
인증 아키텍처 재설계
재현하기 어려운 성능 문제
여러 서비스에 걸친 장애 분석

실무 기준

일단 medium 또는 high로 시작
        ↓
결과가 부족하면 한 단계 올림
        ↓
하위 모델이 반복 실패한 경우에만 max

처음부터 모든 작업을 Max로 시작하는 것보다, 필요한 순간에만 올리는 편이 효율적입니다.

그리고 새 세션을 시작할 때는 모델과 Effort를 한 번 확인하는 습관이 좋습니다.

현재 모델은 무엇인가?
현재 Effort는 어느 수준인가?
이 작업에 정말 이 설정이 필요한가?

3. CLAUDE.md는 프로젝트 백과사전이 아니다

CLAUDE.md는 Claude Code를 잘 활용하기 위한 핵심 파일입니다.

하지만 편리하다고 모든 내용을 넣기 시작하면 매 세션의 기본 컨텍스트가 무거워집니다.

728x90
아키텍처 전체 설명
배포 절차
DB 테이블 정의
코딩 규칙
장애 이력
모든 API 문서
테스트 데이터
과거 결정 과정

이 내용이 전부 CLAUDE.md에 들어 있으면, 현재 작업에 필요하지 않아도 세션 시작 시 로드될 수 있습니다.

Anthropic은 CLAUDE.md에는 모든 세션에서 반드시 알아야 할 핵심 정보만 두고, 특정 작업에서만 필요한 절차는 Skill이나 별도 문서로 옮기라고 권장합니다. 공식 비용 최적화 문서에서는 CLAUDE.md를 가급적 200줄 이내로 유지할 것을 제안합니다.

CLAUDE.md에 남길 내용

  • 빌드·테스트 명령
  • 주요 디렉터리 구조
  • 절대 변경하면 안 되는 규칙
  • 팀의 기본 코딩 컨벤션
  • 패키지 매니저와 런타임 버전
  • 반복해서 Claude가 틀리는 핵심 정보

Skill이나 별도 문서로 뺄 내용

  • 배포 체크리스트
  • DB 마이그레이션 절차
  • 코드 리뷰 기준
  • 특정 기능의 상세 API 명세
  • 드물게 사용하는 장애 대응법
  • 블로그 작성 형식과 SEO 템플릿

Claude Code는 CLAUDE.md와 Auto Memory를 세션 시작 시 컨텍스트로 읽습니다. 실제로 어떤 파일이 로드됐는지는 /context에서 확인할 수 있습니다.


4. 파일과 로그는 필요한 부분만 보여줘라

Claude가 알아서 찾아준다는 이유로 전체 저장소를 무조건 읽게 할 필요는 없습니다.

프롬프트에서 대상 범위를 명시하는 것만으로도 불필요한 탐색을 줄일 수 있습니다.

범위가 너무 넓은 요청

전체 프로젝트를 모두 분석해서
로그인 오류를 찾아줘.

범위를 좁힌 요청

로그인 오류만 분석해줘.

우선 확인할 범위:
- src/auth/**
- src/middleware/auth.ts
- tests/auth/**

결제와 관리자 기능은 이번 작업 범위에서 제외한다.
원인을 찾기 전에는 파일을 수정하지 않는다.

특정 파일을 알고 있다면 @로 직접 지정하는 것도 좋습니다.

@src/auth/login.ts
@src/auth/token.ts

두 파일 사이에서 Refresh Token 갱신이 중복 실행되는지 확인해줘.

대용량 로그를 그대로 넣지 않는다

수천 줄의 로그 전체를 읽히는 대신 먼저 오류 후보만 줄이는 편이 효율적입니다.

rg -n -C 3 "ERROR|Exception|Caused by|FATAL" ./logs/app.log

테스트 결과도 성공한 수천 줄보다 실패 항목과 스택 트레이스만 전달하는 편이 낫습니다.

Anthropic은 Hook이나 CLI 도구로 1만 줄 로그를 수백 줄 수준으로 필터링한 뒤 Claude에게 전달하는 방식을 공식 비용 절감 예시로 소개합니다.

핵심은 이것입니다.

Claude에게 로그를 읽히지 말라는 뜻이 아니라, 판단에 필요한 로그만 읽히라는 뜻입니다.


5. 서브에이전트는 무료 병렬 작업자가 아니다

서브에이전트를 사용하면 메인 대화가 깔끔해집니다.

각 서브에이전트는 별도의 컨텍스트에서 조사한 뒤 결과만 메인 세션으로 반환하기 때문입니다. 검색 결과, 대용량 로그, 다시 볼 필요가 없는 파일 내용을 메인 대화에서 격리하는 데 유용합니다.

하지만 서브에이전트를 쓴다고 전체 사용량이 자동으로 줄어드는 것은 아닙니다.

메인 에이전트 컨텍스트
+
서브에이전트 A 컨텍스트
+
서브에이전트 B 컨텍스트
+
각 에이전트의 Thinking과 도구 호출

병렬 에이전트가 늘어나면 처리 속도는 빨라질 수 있지만, 총토큰 사용량도 함께 증가할 수 있습니다. 에이전트 팀에서는 활성 인원 수에 비례해 토큰 소비가 늘어난다고 Anthropic이 명시하고 있습니다.

서브에이전트가 유리한 작업

입력은 매우 크지만
메인 대화에 필요한 결과는 짧은 작업

예를 들면 다음과 같습니다.

  • 수천 줄 로그에서 원인 후보 찾기
  • 대형 저장소의 특정 패턴 조사
  • 의존성 취약점 결과 분류
  • 여러 구현 방안 조사 후 비교표 반환
  • 반복적인 파일 목록 검사

메인 에이전트가 직접 하는 게 나은 작업

  • 변수명 하나 수정
  • 파일 한두 개의 작은 변경
  • 직전 코드에 대한 짧은 후속 수정
  • 메인 작업과 강하게 연결된 의사결정
  • 같은 파일을 여러 번 주고받아야 하는 작업

비용을 통제하는 서브에이전트 예시

---
name: log-triage
description: 대용량 로그에서 오류 원인 후보만 추출하고 짧게 보고한다
model: haiku
effort: low
maxTurns: 8
---

전체 로그를 메인 대화로 복사하지 않는다.

반환 형식:
1. 가장 유력한 원인 3개
2. 근거가 되는 로그 위치
3. 추가 확인 명령
4. 15줄 이내 요약

Claude Code의 서브에이전트에는 모델, Effort, 최대 작업 Turn 수를 각각 지정할 수 있습니다. 단순 조사 에이전트를 낮은 Effort와 경량 모델로 고정하면 불필요한 소비를 줄일 수 있습니다.


6. 프롬프트 캐시는 ‘반복 입력’을 싸게 만든다

Claude Code는 시스템 프롬프트처럼 반복되는 내용을 매번 정상 가격으로 다시 처리하지 않도록 프롬프트 캐싱을 사용합니다.

현재 일반 Claude 모델의 캐시 읽기 가격은 기본 입력 가격의 10분의 1 수준입니다.

다만 Fable 5.1과 Mythos 5.1은 예외입니다. 이 두 모델의 캐시 읽기는 기본 입력 가격의 0.025배, 즉 40분의 1 수준으로 책정돼 있습니다.

항목기본 입력 대비 비용

5분 캐시 쓰기 1.25배
1시간 캐시 쓰기 2배
일반 모델 캐시 읽기 0.1배
Fable 5.1 캐시 읽기 0.025배

처음 캐시에 저장할 때는 일반 입력보다 조금 더 비싸지만, 같은 내용을 여러 번 재사용하면 전체 비용을 줄일 수 있습니다.

캐시를 잘 활용하는 작업

  • 같은 저장소에서 연속해서 작업
  • 동일한 CLAUDE.md와 프로젝트 규칙 재사용
  • 같은 API 문서를 참고하며 여러 기능 구현
  • 긴 코드베이스를 기반으로 반복적인 수정
  • 동일한 시스템 지침을 사용하는 에이전트 작업

무조건 한 세션을 오래 유지하라는 뜻은 아니다

캐시가 아깝다고 관계없는 작업까지 한 세션에 계속 넣으면 컨텍스트 자체가 비대해집니다.

캐시 재사용 이득
<
쓸모없는 과거 컨텍스트 처리 비용

이 상태가 되면 오히려 손해입니다.

따라서 기준은 다음과 같습니다.

같은 목표와 같은 코드 범위
→ 세션 유지 또는 /compact

목표와 코드 범위가 완전히 달라짐
→ /clear

또 하나 주의할 점이 있습니다.

Effort를 바꾸면 언제나 캐시가 깨진다고 단정하면 현재 기준으로는 정확하지 않습니다. Anthropic은 Fable 5.1의 대화 중 Effort 변경이 프롬프트 캐시를 유지하도록 지원한다고 명시하고 있습니다.

AI 도구의 비용 팁은 모델 버전이 바뀌면 달라질 수 있으므로, 오래된 경험담보다 현재 공식 문서를 함께 확인하는 편이 안전합니다.


7. MCP와 도구도 컨텍스트 예산을 사용한다

MCP 서버를 여러 개 연결해두면 Claude Code의 기능은 강해집니다.

  • GitHub
  • Jira
  • Slack
  • 데이터베이스
  • 브라우저
  • 각종 사내 도구

다만 사용하지 않는 도구까지 모두 켜둘 필요는 없습니다.

현재 Claude Code는 MCP의 상세 도구 정의를 기본적으로 지연 로딩합니다. 예전처럼 모든 도구 설명 전체가 처음부터 들어오는 구조는 아니지만, 서버 이름과 기본 지침 등 일부 정보는 컨텍스트에 포함될 수 있습니다.

Anthropic도 /context로 무엇이 공간을 차지하는지 확인하고, /mcp에서 사용하지 않는 서버를 비활성화하라고 권장합니다. 가능한 경우 gh, aws, gcloud 같은 CLI가 MCP보다 컨텍스트 효율적일 수 있다고 설명합니다.

점검 방법

/context

현재 세션에 로드된 다음 항목을 확인합니다.

  • CLAUDE.md
  • Auto Memory
  • Skills
  • MCP 서버
  • 기타 기본 지침

사용하지 않는 MCP가 많다면 다음으로 정리합니다.

/mcp

프로젝트별로 필요한 MCP만 활성화하는 편이 좋습니다.

프론트엔드 작업
→ GitHub만 활성화

DB 점검 작업
→ GitHub + DB MCP

문서 정리
→ 외부 MCP 대부분 비활성화

모든 도구를 항상 연결해두는 것이 능력이 아니라, 현재 작업에 필요한 도구만 연결하는 것이 최적화입니다.


8. 작업 범위와 종료 조건을 프롬프트에 넣어라

Claude Code는 목표가 모호하면 더 많은 파일을 탐색하고, 더 많은 개선점을 제안하고, 후속 작업까지 이어갈 수 있습니다.

다음과 같은 프롬프트는 사용량을 예측하기 어렵습니다.

전체 프로젝트를 완벽하게 개선해줘.

어디까지가 완벽한지, 언제 종료해야 하는지 알 수 없기 때문입니다.

범위를 정한 프롬프트

src/auth 범위의 로그인 오류만 수정해줘.

완료 조건:
- 중복 Refresh Token 요청 원인 확인
- 최소 변경으로 수정
- 기존 API 응답 형식 유지
- 관련 테스트 추가
- 테스트와 빌드 통과

제한:
- 새 패키지 설치 금지
- DB 스키마 변경 금지
- 다른 기능 리팩터링 금지
- 동일 오류가 3회 반복되면 작업을 멈추고 보고
- 완료 후 새로운 개선 작업을 자동으로 시작하지 말 것

이 프롬프트는 단순히 비용을 아끼기 위한 것이 아닙니다.

AI가 범위를 넓혀 불필요한 코드를 바꾸는 사고도 줄여줍니다.

장시간 작업에는 중단 조건을 넣는다

테스트가 통과하면 즉시 종료한다.

같은 오류가 세 번 반복되면 더 이상 재시도하지 않는다.

추가로 발견한 개선사항은 구현하지 말고
TODO 목록에만 기록한다.

서브에이전트는 최대 2개만 사용한다.

에이전트가 알아서 일하는 것은 장점입니다.

하지만 알아서 멈추는 조건도 함께 줘야 진짜 자동화가 됩니다.


사용량을 아끼려다 오히려 더 쓰는 실수

실수 1. 프롬프트를 지나치게 잘게 나누기

파일 읽어줘.
문제 찾아줘.
수정해줘.
테스트해줘.
오류 고쳐줘.
다시 테스트해줘.

각 요청마다 현재 컨텍스트를 다시 처리할 수 있습니다.

서로 강하게 연결된 작업이라면 한 번에 완료 조건까지 전달하는 편이 효율적일 수 있습니다.

원인 분석부터 수정·테스트까지 진행하되,
원인을 확인하기 전에는 코드를 수정하지 말고
테스트 통과 후 종료해줘.

실수 2. 무조건 새 세션 열기

세션을 자주 새로 열면 깨끗해지지만, 같은 프로젝트 구조와 요구사항을 다시 설명해야 합니다.

같은 기능을 계속 작업한다면 /compact가 더 나을 수 있습니다.

실수 3. 모든 조사를 서브에이전트에게 넘기기

작은 작업까지 에이전트를 분리하면 별도 컨텍스트 생성 비용이 더 커질 수 있습니다.

실수 4. 사용량을 아끼겠다고 설명을 생략하기

요구사항이 불명확하면 Claude가 질문을 반복하거나 잘못 구현한 뒤 다시 고쳐야 합니다.

명확한 프롬프트는 길어도 낭비가 아닙니다.


작업 시작 전 20초 점검표

1. 지금 작업은 이전 작업과 관련 있는가?
   - 아니오: /clear
   - 예: 현재 세션 유지

2. 컨텍스트가 너무 커졌는가?
   - /context 확인
   - 필요하면 /compact

3. 현재 모델과 Effort가 작업 난도에 맞는가?
   - 단순 작업: low 또는 medium
   - 일반 코딩: high
   - 고난도 작업: xhigh 또는 max

4. 전체 저장소가 정말 필요한가?
   - 대상 경로와 파일을 먼저 지정

5. 로그가 너무 큰가?
   - ERROR·Exception만 먼저 필터링

6. 서브에이전트가 꼭 필요한가?
   - 입력이 크고 결과가 짧을 때만 사용

7. 사용하지 않는 MCP가 연결돼 있는가?
   - /mcp에서 비활성화

8. 종료 조건이 있는가?
   - 테스트 통과, 재시도 횟수, 작업 범위 명시

바로 복사해 쓸 수 있는 Claude Code 최적화 프롬프트

일반 기능 구현용

다음 작업을 하나의 완결된 단위로 진행해줘.

목표:
[구현할 기능]

작업 범위:
[대상 디렉터리와 파일]

완료 조건:
- 기존 구조를 먼저 분석
- 최소 변경으로 구현
- 예외 처리와 입력 검증 포함
- 관련 테스트 추가
- 린트, 테스트, 빌드 통과
- 변경 파일과 이유 요약

제한:
- 새 패키지 설치 전 승인 요청
- 범위 밖 리팩터링 금지
- DB와 공개 API 규격 임의 변경 금지
- 같은 오류 재시도는 최대 3회
- 후속 아이디어는 구현하지 말고 TODO로만 정리
- 서브에이전트는 최대 2개 사용

긴 세션 압축용

/compact 다음 정보만 우선 보존해줘:

1. 현재 목표와 완료 조건
2. 확정된 설계 결정
3. 수정한 파일과 핵심 변경점
4. 현재 실패 중인 테스트
5. 시도했지만 폐기한 접근 방식
6. 다음에 수행할 정확한 작업
7. 변경하면 안 되는 제약조건

해결된 토론, 전체 명령 출력, 중복 설명은 제거해줘.

대용량 로그 분석용

로그 전체를 메인 컨텍스트에 다시 출력하지 마.

다음 항목만 분석해줘:
- 최초 오류 시점
- Root cause 후보 최대 3개
- 직접적인 Caused by 체인
- 반복 오류 횟수
- 추가 확인 명령

최종 결과는 20줄 이내로 요약하고,
근거가 되는 로그 줄 번호만 함께 남겨줘.

가장 효과가 큰 순서만 다시 정리하면

Claude Code 사용량이 너무 빨리 줄어든다면 사소한 프롬프트 문구부터 고치기보다 다음 순서로 확인하는 편이 좋습니다.

1. 관계없는 장기 세션을 정리한다.
2. 모델과 Effort를 작업 난도에 맞춘다.
3. CLAUDE.md와 기본 컨텍스트를 줄인다.
4. 로그와 파일 범위를 좁힌다.
5. 서브에이전트 수와 최대 Turn을 제한한다.
6. 사용하지 않는 MCP를 끈다.
7. 완료·중단 조건을 명확히 한다.
8. /usage와 /context를 수시로 확인한다.

이 중에서 가장 체감이 큰 것은 대체로 세션 관리와 Effort 조절입니다.

오래된 세션에 관계없는 작업을 계속 추가하면서 Max Effort를 유지하고 있다면, 프롬프트 단어 몇 개를 줄이는 정도로는 큰 차이가 나지 않습니다.


Claude Code 한도 최적화의 핵심

Claude Code를 아끼는 가장 나쁜 방법은 필요한 일을 시키지 않는 것입니다.

한도를 남겨두는 것이 목적이 아니라, 같은 사용량으로 더 많은 유효한 작업을 끝내는 것이 목적이어야 합니다.

사용량 100% 소진
+
불필요한 프로젝트 3개
= 효율적이지 않음
사용량 40% 소진
+
실제 기능 구현
+
테스트 완료
+
문서화
= 충분히 효율적

그리고 사용량 최적화는 모델을 무조건 약하게 쓰는 것도 아닙니다.

어려운 문제에는 강한 모델과 높은 Effort가 오히려 경제적일 수 있습니다. 낮은 설정으로 여러 번 실패한 뒤 결국 다시 고성능 모델을 호출한다면 총사용량이 더 커질 수 있기 때문입니다.

결국 가장 좋은 전략은 다음 한 문장으로 정리됩니다.

쉬운 일에는 가볍게, 어려운 일에는 충분히, 관계없는 과거 맥락은 과감하게 버린다.

Claude Code는 비싸지만 잘하는 도구입니다.

그래서 더더욱 모든 작업에 최대 출력을 쓰기보다, 정말 필요한 순간에 성능을 집중해서 사용하는 편이 낫습니다.

5시간 제한 자체를 없앨 수는 없습니다.

하지만 세션, 컨텍스트, Effort와 에이전트 수를 관리하면 같은 5시간 창에서도 체감 작업량은 꽤 달라질 수 있습니다.


공식 참고자료

  • Claude Code의 세션·모델·MCP·로그 비용 최적화 방법은 공식 비용 관리 문서에서 확인할 수 있습니다.
  • Claude 모델별 입력·출력·캐시 가격은 공식 가격표에 정리돼 있습니다.
  • 프롬프트 캐시의 쓰기·읽기 배수와 만료 구조는 공식 캐싱 문서에서 확인할 수 있습니다.
  • Effort가 텍스트, 도구 호출과 Thinking에 미치는 영향은 공식 Effort 문서에 설명돼 있습니다.
  • 서브에이전트별 모델·Effort·최대 Turn 설정은 공식 서브에이전트 문서에서 확인할 수 있습니다.
  • CLAUDE.md, Auto Memory와 /context의 관계는 공식 메모리 문서에 정리돼 있습니다.

 

728x90
반응형