Claude Code를 몇 시간 쓰지도 않았는데 5시간 한도에 도달했다면, 먼저 5시간을 “보장된 연속 사용 시간”으로 이해하지 않았는지 확인해야 한다. 5시간은 사용량이 리셋되는 세션 창이고, 실제로 처리할 수 있는 작업량은 대화와 파일의 길이, 누적 컨텍스트, 선택한 모델과 기능에 따라 달라진다. Pro와 Max에는 이 세션 한도와 별도로 주간 한도도 있다.
따라서 “왜 이렇게 빨리 닳았지?”에 대한 가장 정확한 첫 답은 하나의 원인을 찍는 것이 아니다. 지금 Settings > Usage와 /usage를 열어 5시간 세션과 주간 한도 중 어떤 카운터가 움직였는지 확인하고, /context·/model·인증 경로와 현재 시각을 기록하자. 이 정보가 있어야 구독 사용량과 API 과금을 나누고 다음 비교 조건을 정할 수 있다. 빠른 소진만으로 버그, 피크타임 가중 또는 최근의 일괄적인 한도 축소를 입증할 수는 없다.
이 글은 2026년 8월 21일 확인한 Anthropic 공식 도움말과 Claude Code 명령 문서를 기준으로 한다. 이날 확인한 공개 자료는 모든 계정에 적용되는 한도 축소, 피크타임 가중 규칙 또는 특정 계정의 소진 원인을 확정하지 않는다. 계정과 버전에 따라 화면의 라벨이나 명령 출력은 달라질 수 있으므로, 최종 판단에서는 자신의 실제 화면을 우선한다.
먼저 3분 안에 현재 상태를 보존한다
진단 전에 /clear부터 실행하면 비교에 필요한 현재 컨텍스트를 잃는다. 플랜을 바꾸거나 추가 사용량을 결제하기 전에도 같은 문제가 생긴다. 먼저 아래 정보를 한 번에 기록해 두자.
- 현재 시각과 한도에 도달했거나 급격히 줄었다고 느낀 시각
- Claude의 Settings > Usage에 보이는 5시간 세션과 주간 사용량, 남은 시간 또는 리셋 정보
- Claude Code에서
/usage를 실행했을 때 보이는 세션 비용, 플랜 한도 또는 활동 정보 /context에 보이는 현재 컨텍스트 사용량과 불러온 자료/model에 보이는 실제 사용 모델- 직전에 수행한 작업, 읽힌 파일, 사용한 도구, 병렬로 진행한 Claude 작업
- Claude 구독으로 인증했는지,
ANTHROPIC_API_KEY를 사용하는 API 과금 경로인지
API 키 값 자체를 메모하거나 공유할 필요는 없다. 키의 존재와 어떤 인증 경로를 사용했는지만 확인한다. Anthropic은 Pro·Max 활동이 Claude와 Claude Code 사이에서 공유될 수 있다고 설명하며, ANTHROPIC_API_KEY가 설정된 경우 포함된 구독 사용량과 별개인 API 과금 경로가 선택될 수 있다고 안내한다. 자세한 경계는 Claude Code를 Pro 또는 Max 플랜과 함께 사용하는 방법에서 확인할 수 있다.
“5시간 한도”라는 말에는 서로 다른 문제가 섞여 있다
Settings > Usage와 Claude Code의 출력이 무엇을 가리키는지 구분하면 서로 다른 현상을 한데 묶는 오류를 줄일 수 있다.
| 보이는 신호 | 먼저 해석할 것 | 아직 결론 내릴 수 없는 것 |
|---|---|---|
| 5시간 세션 사용량이 빠르게 증가 | 현재 세션에서 대화·파일·모델·기능의 부담이 컸을 가능성 | 버그, 고정 토큰 수, 계정의 정확한 원인 |
| 주간 한도에 먼저 접근 | 최근 여러 세션과 모델 사용을 함께 확인 | 오늘 한 작업 하나가 전부 원인이라는 결론 |
/context가 크게 차 있음 | 매 turn에 포함되는 이전 대화와 프로젝트 자료가 누적됨 | 컨텍스트만이 소진의 유일한 원인이라는 결론 |
| Claude와 Claude Code 양쪽에서 활동 | 구독 사용량이 제품 간 공유되는지 확인 | Claude Code 작업량만으로 전체 사용량을 설명하는 것 |
| API 과금 또는 비용 신호 | 인증 경로와 ANTHROPIC_API_KEY 사용 여부 확인 | 구독 한도가 줄었다고 단정하는 것 |
| 화면과 예상이 계속 맞지 않음 | 동일 조건 비교와 시각별 기록을 확보 | 공개 문서만으로 계정 오류를 확정하는 것 |
Anthropic의 사용량 제한 설명에 따르면 실제 사용 가능한 메시지 수는 고정값이 아니다. 메시지와 첨부 파일의 길이, 현재 대화의 길이, 모델과 기능 등이 영향을 준다. Settings > Usage는 세션과 주간 한도의 진행 상황을 보는 출발점이지만, 막대 하나가 원인까지 알려 주지는 않는다.
컨텍스트가 커지면 같은 한 번의 요청도 같지 않다
Claude Code의 각 요청에는 새 프롬프트만 들어가는 것이 아니다. 이전 대화, CLAUDE.md 같은 프로젝트 컨텍스트, 읽힌 파일과 새 요청이 함께 포함될 수 있다. 세션이 길어질수록 새 질문이 짧아도 처리해야 할 전체 컨텍스트는 커질 수 있다.
이때 필요한 것은 “긴 대화는 무조건 나쁘다”는 규칙이 아니라 현재 상태를 확인하고 목적에 맞게 정리하는 것이다.
/context: 현재 어떤 자료가 컨텍스트를 차지하는지 먼저 본다./compact: 이어서 작업해야 할 맥락을 요약해 세션을 정리한다./clear: 완전히 새 컨텍스트로 시작한다. 되돌릴 수 없으므로 필요한 결과와 진단 기록을 저장한 뒤 사용한다./model: 현재 선택된 모델을 확인한다. 공식 도움말은 대부분의 코딩 작업에 Sonnet을 기본 선택으로 설명하고 Opus가 더 많은 할당량을 사용할 수 있다고 안내하지만, 모든 계정에 적용되는 고정 배수나 절감률은 제공하지 않는다.
이 명령들의 현재 기능은 Claude Code 대화형 모드 명령 문서에서 확인할 수 있다. 명령 이름과 표시 항목은 버전이나 플랜에 따라 바뀔 수 있으므로 실제 로컬 출력을 기록하는 편이 안전하다.
원인을 좁히는 가장 안전한 방법: 한 번에 변수 하나만 바꾼다
여러 설정을 동시에 바꾸면 사용량이 줄어도 무엇이 영향을 줬는지 알 수 없다. 아래 비교는 “절약을 보장하는 비법”이 아니라, 자신의 계정에서 관찰 가능한 근거를 만드는 절차다.
1. 비교할 짧고 반복 가능한 작업을 정한다
예를 들어 작은 함수 하나를 설명하거나, 동일한 테스트 실패를 분석하는 작업처럼 입력과 기대 결과를 명확히 고른다. 대형 리팩터링, 광범위한 저장소 탐색, 병렬 에이전트 작업은 실행마다 범위가 달라져 첫 비교 대상으로 적합하지 않다.
2. 기준 상태를 기록한다
작업 직전의 시각, Settings > Usage, /usage, /context, /model, 사용 도구와 읽힌 파일을 남긴다. 작업 직후 같은 항목을 다시 기록한다. 표시가 퍼센트인지 비용인지, 리셋 시간인지도 원래 보인 형태 그대로 적는다.
3. 변수 하나만 바꿔 다시 실행한다
가능한 비교는 다음 중 하나다.
- 같은 모델과 작업을 유지하고, 저장할 맥락을 확보한 뒤 새 세션에서 비교한다.
- 같은 작업과 컨텍스트를 유지하고, 계정에서 실제 사용할 수 있는 다른 모델로 비교한다.
- 같은 모델과 세션을 유지하고, 불필요한 파일 읽기나 도구 호출 범위만 줄인다.
- 같은 Claude Code 조건을 유지하고, Claude 웹의 병렬 활동이 없을 때 비교한다.
서로 다른 두세 가지를 한 번에 바꾸지 않는다. 또한 두 번째 실행의 결과 품질이나 작업 범위가 달라졌다면 단순 사용량 비교로 승패를 정하지 않는다.
4. 결과를 네 가지로 분류한다
- 컨텍스트를 정리했을 때만 차이가 반복된다: 누적 컨텍스트가 중요한 후보라는 계정별 근거가 생긴다. 이미 소진한 사용량이 복원된다는 뜻은 아니다.
- 모델을 바꿨을 때만 차이가 반복된다: 현재 작업과 모델 조합을 다시 선택할 근거가 된다. 모든 작업에서 같은 절감률이 보장되지는 않는다.
- 인증 경로가 달랐다: 구독 사용량과 API 과금을 분리해 다시 확인한다. 비용과 가용성은 계정·지역에 따라 다를 수 있으므로 자신의 결제 화면을 기준으로 한다.
- 같은 조건인데 설명되지 않은 차이가 반복된다: “버그 확정”이 아니라 공식 지원에 전달할 가치가 있는 미해결 관찰이다. 기록을 보존하고 상태 페이지와 공식 지원으로 넘긴다.
바로 /clear하거나 플랜부터 올리면 안 되는 이유
빠른 소진을 경험하면 새 세션을 열거나 더 높은 플랜을 사는 행동이 가장 쉬워 보인다. 그러나 원인 분류 전에 움직이면 다음 문제가 남는다.
/clear는 현재 대화 맥락을 되돌릴 수 없게 제거하므로 어떤 자료가 누적됐는지 확인하기 어려워진다.- 플랜 변경은 현재 사용 중인 카운터나 인증 경로가 잘못 이해된 경우 문제를 해결하지 못할 수 있다.
- API 과금 경로를 구독 사용량으로 오인하면 “한도가 빨리 줄었다”는 질문 자체가 맞지 않을 수 있다.
- 보편적인 정책 변경이나 장애를 가정하면, 자신의 작업 범위·모델·컨텍스트에서 재현되는 신호를 놓친다.
먼저 기록하고, 한 변수만 비교하고, 그 뒤에 작업 방식을 바꾸는 순서가 컨텍스트 손실과 불필요한 결제를 줄인다.
설명되지 않으면 지원에 보낼 증거를 만든다
동일 조건 비교 후에도 사용량 변화가 설명되지 않는다면 아래 항목을 정리한다.
- 플랜 종류와 사용한 제품: Claude, Claude Code 또는 둘 다
- 문제가 나타난 시각과 시간대
- Settings > Usage의 세션·주간 표시와 리셋 정보
/usage,/context,/model출력에서 비밀정보를 제거한 기록- 사용한 인증 경로: 구독 로그인 또는 API 과금
- 작업의 범위, 읽힌 파일, 도구 사용, 병렬 작업 여부
- 비교에서 바꾼 변수 하나와 전후 결과
- 재현 여부와 기대했던 동작
민감한 코드, 파일 내용, API 키 또는 인증 토큰은 첨부하지 않는다. 서비스 전체 이상이 의심되면 Claude 상태 페이지의 현재 공지를 함께 확인하되, 공개 공지가 없다는 사실만으로 계정별 문제를 부정해서도 안 된다.
자주 묻는 질문
5시간 동안 Claude Code를 계속 쓸 수 있다는 뜻인가?
아니다. 5시간은 세션 기반 사용량이 리셋되는 창이다. 실제로 완료할 수 있는 작업량은 입력과 파일 길이, 대화 길이, 모델과 기능에 따라 달라질 수 있다. 고정된 메시지 수나 토큰 수처럼 계산하면 오차가 커진다.
컨텍스트가 크면 빠른 소진의 원인이라고 확정할 수 있나?
확정할 수 없다. 긴 세션에서는 각 turn에 포함되는 자료가 늘어날 수 있으므로 유력한 점검 대상이지만, 특정 계정의 소진 원인은 작업 기록과 전후 비교가 있어야 좁힐 수 있다.
Opus 대신 Sonnet을 쓰면 정확히 얼마나 절약되나?
공식 자료는 Opus가 더 많은 할당량을 사용할 수 있다고 설명하지만, 모든 작업과 계정에 적용되는 고정 배수나 보장 절감률을 제공하지 않는다. 자신의 계정에서 동일한 작업 범위와 컨텍스트로 비교해야 한다.
빨리 소진됐으면 사용량 버그인가?
그 사실만으로는 알 수 없다. 현재 확인된 카운터, 인증 경로, 컨텍스트, 모델, 도구와 병렬 활동을 기록한 뒤 동일 조건에서 재현되는지 확인해야 한다. 2026년 8월 21일 확인한 공개 자료만으로는 보편적인 사용량 한도 축소, 피크타임 가중 또는 계정별 오류를 확정할 수 없으며, 그런 결론에는 별도의 최신 공식 근거나 계정별 재현 기록이 필요하다.
결론: 원인을 추측하지 말고 다음 비교를 선택한다
Claude Code 5시간 한도가 너무 빨리 소진됐을 때의 첫 조치는 플랜 변경이나 /clear가 아니다. Settings > Usage와 /usage로 어떤 한도가 움직였는지 확인하고, /context와 /model로 작업 조건을 기록하며, 구독과 API 과금 경로를 분리한다. 그다음 같은 짧은 작업에서 변수 하나만 바꿔 전후를 비교한다.
차이가 반복되면 작업 방식을 조정할 근거가 생긴다. 차이가 설명되지 않으면 그것도 중요한 결과다. 기록을 보존해 지원으로 넘기면 “빨리 닳았다”는 인상 대신, 확인 가능한 계정·세션 증거로 문제를 설명할 수 있다.
