서브에이전트 하나 돌렸는데 한도가 순식간에 사라졌습니다 — 클로드 사용량 안 새게 지키는 법

어느 날 밤이었어요. 클로드 코드로 리팩터링 작업을 하고 있었는데, 거의 다 끝나간다 싶은 순간에 사용량 한도 경고가 떴습니다.

혹시 이런 경험, 있으신가요? 당황스러웠던 건 전날이었어요. 전날도 비슷하게 오래 붙잡고 있었는데 멀쩡했거든요. 그런데 그날따라 유독 빨리 걸렸습니다. 체감상 평소라면 그 정도 리팩터링으로는 한도가 절반도 안 줄었을 텐데, 그날은 한 시간도 안 돼서 절반 넘게 사라진 느낌이었어요.

왜 유독 출력이 많은 작업에서 한도가 먼저 오는지는 따로 정리해둔 글이 있습니다. 토큰과 컨텍스트 윈도우가 쌓이는 구조를 이해하고 나면 "왜 그날만 그랬지"라는 의문은 풀리는데, 이 글은 그 원리 설명이 아니에요.

이 글은 그날 이후로 실전에서 뭘 바꿨는지를 정리한 글입니다. 원리보다 행동이 먼저 필요한 분을 위한 체크리스트에 가까워요.

이 글은 2026년 7월 기준으로 정리했습니다. 한도나 요금제 정책은 이후 바뀔 수 있으니, 최신 내용은 공식 페이지에서 한 번 더 확인해보시길 권합니다.

이 글에서 다루는 순서는 이렇습니다. 한도 구조 확인 → 서브에이전트 가드레일 → AI에게 맡기지 말아야 할 작업 → 프롬프트 작성법 → 채팅 관리 → 모델 선택 → Extra usage와 Max 전환까지, 체감 효과가 큰 순서대로 정리했어요.

 

 

클로드 사용량 한도, 손보기 전에 30초 안에 확인할 것

습관을 바꾸기 전에 지금 내가 어떤 한도 구조 안에 있는지부터 확인하고 가는 게 순서예요.

 

5시간 한도 vs 주간(weekly) 한도, 뭐가 다른가요

클로드는 기본적으로 5시간마다 초기화되는 세션 한도로 작동합니다. 메시지를 얼마나 보냈든, 5시간이 지나면 그 한도는 새로 채워져요.

문제는 이것만 있는 게 아니라는 점입니다. Claude Code처럼 자동화 작업에 많이 쓰이는 환경에서는 별도의 주간(weekly) 한도가 함께 걸려 있어요. 5시간 한도는 살아있는데 주간 한도가 먼저 소진돼서 작업이 막히는 경우가 꽤 흔합니다.

이유는 이렇습니다. TechCrunch 보도에 따르면, Claude Code를 24/7 백그라운드로 상시 돌리는 헤비 유저의 사용 패턴을 억제하려는 목적으로 Anthropic이 이 주간 한도를 도입했다고 해요. 개인 사용자 입장에서는 억울할 수 있지만, 구조를 알고 있으면 최소한 "왜 5시간 한도는 남았는데 막히지"라는 혼란은 줄어듭니다.

 

구분	초기화 주기	특히 잘 걸리는 상황	도입/주의 포인트
5시간 한도	5시간마다 자동 초기화	한 세션 안에서 메시지를 몰아서 주고받을 때	사용량이 많아도 5시간 지나면 리셋되므로 "잠깐 쉬었다 재개"가 가장 단순한 대응
주간(weekly) 한도	주 단위로 초기화	Claude Code처럼 서브에이전트·자동화 파이프라인을 상시로 돌릴 때	헤비 유저의 리소스 과점유를 막으려고 Anthropic이 별도로 도입 — 5시간 한도가 남아 있어도 이 한도가 먼저 소진되면 작업이 막힘

 

 

지금 몇 % 남았는지 확인하는 가장 빠른 방법

Claude Code를 쓰고 계신다면 /usage 명령어로 현재 남은 한도를 바로 확인할 수 있어요. 앱이나 웹 버전에서도 설정 화면에서 사용량 표시를 볼 수 있습니다.

다만 이게 초 단위, 토큰 단위로 정밀하게 실시간 추적되는 건 아니에요. 그래서 서드파티 대시보드 플러그인까지 찾아보는 분들이 있는데, 개인적으로는 거기까지 갈 필요는 못 느꼈습니다. 작업 시작 전에 한 번, 긴 작업 들어가기 전에 한 번 확인하는 정도만으로도 충분했어요.

 

 

가장 빨리 한도를 갉아먹는 범인 — 서브에이전트의 도구 호출

채팅으로 클로드를 쓸 때와, 에이전트에게 작업을 통째로 맡길 때의 한도 소진 속도는 완전히 다릅니다.

 

 

시키지도 않은 재시도가 반복되는 이유

이 글 자체를 쓰면서 겪은 일이에요. 이 콘텐츠는 여러 개의 서브에이전트가 순서대로 협업하는 파이프라인으로 만들어지는데, 그중 리서치를 담당하는 서브에이전트는 검색어를 바꿔가며 웹서치를 반복하는 성격을 갖고 있습니다.

처음엔 이 리서치 에이전트를 별도 제한 없이 그냥 돌렸어요. 결과는 나쁘지 않았습니다. 다만 생각보다 사용량이 훨씬 빠르게 줄어드는 걸 체감했어요.

이유를 들여다보니 단순했습니다. 에이전트는 "충분히 좋은 결과"라는 기준이 없으면 스스로 멈추지 않아요. 검색 결과가 애매하면 검색어를 바꿔서 다시 찾아보고, 도구 호출이 실패하면 다시 시도합니다.

사람이 봤을 땐 "이 정도면 됐는데" 싶은 지점을 지나서도 계속 도구를 호출하는 경우가 생겨요. 그 호출 하나하나가 전부 한도를 깎아 먹는 요청입니다.

 

가드레일이 없을 때 에이전트가 도구 호출을 무한 반복해 한도를 소진하는 흐름과, 최대 횟수·중단 조건을 설정했을 때 정해진 시도 안에서 멈추고 보고하는 흐름을 비교한 플로우차트

 

 

 

에이전트를 돌리기 전에 범위부터 정해두는 습관

그 뒤로 바뀐 습관이 있어요. 에이전트를 돌리기 전에 "검색은 몇 건까지, 실패하면 몇 번까지 재시도, 그 이상은 중단하고 결과를 보고하라"는 기준을 미리 정해두고 시작합니다.

거창한 시스템은 아니에요. 그냥 작업을 맡기기 전에 이 세 가지를 머릿속으로, 혹은 지시문에 한 줄로 정해두는 정도입니다. 그런데 이것만으로도 체감상 한도가 새는 속도가 눈에 띄게 줄었어요.

여기서 한 가지는 분명히 해두고 싶어요. 저는 아직 이걸 settings.json 같은 파일로 정식 시스템화해서 써본 적은 없습니다. 매번 지시문에 원칙을 적어 넣는 수준이에요. 더 확실하게 못 박아두고 싶으시다면 이런 방향으로 접근해볼 수 있습니다.

Claude Code의 settings.json은 어떤 도구를 얼마나 자유롭게 쓸 수 있는지 허용/차단 범위를 지정할 수 있어요.

{
  "permissions": {
    "allow": [
      "Read(./src/**)",
      "Bash(git diff:*)",
      "Bash(git status:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "WebSearch"
    ]
  }
}

 

여기에 더해서 CLAUDE.md나 서브에이전트 프롬프트 안에 "웹서치는 최대 5건까지만 시도하고, 그 이상 필요하면 작업을 멈추고 사용자에게 보고할 것"처럼 중단 조건을 문장으로 명시해두는 방법도 함께 쓰입니다. 파일 접근 범위는 설정으로, 호출 횟수 같은 행동 기준은 지시문으로 나눠서 관리하는 식이에요.

이건 어디까지나 일반적으로 권장되는 접근이고, 저는 이 정도까지는 아직 안 해봤다는 걸 다시 한번 밝혀둡니다.

이렇게 도구·규칙·검증 루프를 포함해서 에이전트가 일하는 환경 자체를 어떻게 설계할지 더 넓게 정리해둔 글도 있어요. 하네스 엔지니어링이란? AI 에이전트를 덜 망가뜨리는 실전 방법에서 CLAUDE.md, 스킬, 검증 절차를 어떻게 조합하는지 다뤘습니다.

 

 

"중단 조건"을 미리 정의해야 하는 이유

에이전트는 기본적으로 "실패하면 다시 시도해서 성공시킨다"는 방향으로 설계돼 있어요. 그 자체는 나쁜 게 아닙니다.

문제는 "언제 포기하고 사람에게 물어봐야 하는가"에 대한 기준이 없을 때예요. 기준이 없으면 에이전트는 계속 시도합니다. 그 시도 하나하나가 요청이고, 요청 하나하나가 한도예요.

작업을 맡기기 전에 "몇 번 실패하면 멈춘다"를 미리 정해두는 것 — 이게 사후에 한도를 아끼는 어떤 팁보다 효과가 컸습니다. 새는 걸 나중에 막는 것보다, 애초에 새는 구멍을 안 만드는 게 낫더라고요.

 

 

AI에게 시키면 오히려 손해인 작업이 있어요

한도를 아끼는 가장 확실한 방법은 사실 "덜 쓰는 것"입니다. 그런데 이걸 "참는다"가 아니라 "애초에 AI가 아니어도 되는 작업을 가려낸다"로 접근하면 얘기가 달라져요.

 

 

"이 작업, AI 없이 5분이면 끝나는가"부터 먼저 물어보세요

한동안 파일 이름을 규칙에 맞게 정리하는 작업이나, 데이터를 같은 형식으로 바꾸는 작업을 매번 채팅으로 시켰어요. 매번 같은 규칙을 다시 설명해야 했고, 결과가 조금씩 다르게 나올 때도 있었습니다.

어느 순간 이상하다는 생각이 들었어요. 규칙은 매번 똑같은데 왜 매번 AI한테 새로 시키고 있었을까요.

그 뒤로는 간단한 스크립트로 대체했습니다. 파일 이름 규칙은 정규식 몇 줄이면 됐고, 데이터 형식 변환도 짧은 스크립트 하나로 끝났어요. 한 번 짜두면 그다음부터는 실행만 하면 되니 한도를 쓸 일 자체가 없어졌습니다.

 

 

AI가 오히려 유리한 작업과의 경계선

기준은 간단해요. 규칙이 고정돼 있고 판단이 필요 없는 작업은 스크립트나 도구로 넘깁니다. 반대로 상황마다 판단이 달라지거나, 맥락을 읽고 해석해야 하는 작업은 AI가 맡는 게 나아요.

파일 이름을 규칙대로 바꾸는 건 판단이 필요 없습니다. 코드 리뷰에서 "이 로직이 왜 이렇게 짜였는지"를 해석하는 건 판단이 필요해요. 전자는 스크립트, 후자는 AI — 이 경계선을 한 번 그어두면 그다음부터는 작업을 시작하기 전에 "이거 AI 시킬 일 맞나"를 한 번씩 되묻게 됩니다.

 

작업 성격	판단 기준	처리 방식	예시
규칙이 고정, 판단 불필요	매번 같은 규칙을 반복 적용	스크립트/도구	파일 이름 규칙대로 일괄 변경, 데이터 형식 변환
상황마다 판단이 달라짐	맥락을 읽고 해석해야 함	AI	코드 리뷰에서 로직의 의도 해석, 애매한 요구사항 정리

 

이 경계선을 어디에 그어야 하는지, 어떤 작업까지 AI에게 믿고 맡길 수 있는지를 더 넓게 정리한 글은 Vibe Coding을 믿기 전에 봐야 할 AI 코딩 실전 기준에도 담아뒀어요.

 

 

프롬프트를 대충 쓰면 한도가 더 빨리 줄어들어요

같은 작업이라도 프롬프트를 어떻게 쓰느냐에 따라 요청 횟수가 두 배, 세 배로 벌어질 수 있습니다.

 

 

목표·포맷·수용 기준을 명시하면 왜 재시도가 줄어들까요

예전엔 "이 기능 리뷰해줘" 식으로 짧게 던지곤 했어요. 결과는 자주 원하는 것과 달랐습니다. 뭘 기준으로 리뷰해달라는 건지, 어떤 형태로 답을 받고 싶은지 안 적어놨으니 당연한 일이었죠.

그러면 다시 설명해야 해요. "아니 그게 아니라", "이런 관점에서 봐줘"를 두세 번 반복하고 나서야 원하는 결과가 나왔습니다. 그 두세 번이 전부 한도예요.

지금은 리뷰를 요청할 때 "성능 관점에서만 봐줘", "치명적인 이슈만 우선순위대로 정리해줘", "코드 스니펫 포함해서" 같은 걸 처음부터 못 박아둡니다. 목표, 원하는 출력 형식, 어디까지가 합격선인지를 미리 적어두는 것뿐인데 재시도가 눈에 띄게 줄었어요.

Anthropic이 공식적으로 안내하는 프롬프트 작성 원칙에서도 원하는 출력을 구체적으로 명시할수록 결과가 향상된다고 설명합니다. 재시도가 줄어드는 건 결국 한도가 덜 소진된다는 뜻과 같아요.

 

 

새 채팅은 열되, "핸드오버 요약"만 챙겨가세요

주제가 바뀌면 새 채팅을 여는 게 좋다는 팁은 다들 알고 계실 거예요. 문제는 그다음입니다.

한 채팅에 여러 주제를 섞어 쓴 적이 있어요. 코드 리뷰를 하던 중간에 갑자기 급한 일이 생겨서, 이메일 문구 다듬는 작업을 같은 채팅에 그냥 끼워 넣었습니다.

나중에 그 채팅으로 다시 돌아왔을 때 맥락이 뒤섞여 있었어요. 코드 얘기를 하다가 이메일 얘기가 튀어나오고, 다시 코드로 돌아가려니 흐름이 끊겨 있었죠.

 

 

핸드오버 요약에 반드시 넣어야 할 3가지

이후로는 주제가 바뀌는 순간 새 채팅을 엽니다. 대신 이전 채팅에서 딱 세 가지만 정리해서 새 채팅 첫 메시지에 붙여넣어요.

지금까지 결정된 사항, 다음에 할 일, 참고해야 할 파일 경로. 이 세 줄이면 웬만한 맥락은 새 채팅에서도 거의 그대로 살아납니다.

배경 설명을 처음부터 다시 하는 것보다 훨씬 짧아요. 코드베이스 전체를 다시 훑게 하거나 긴 히스토리를 복사해 붙이는 것도 아니고, 딱 이 세 줄만 챙겨가는 방식인데도 실전에서는 이 정도로 충분했습니다.

 

 

모델을 전부 Opus로 돌릴 필요는 없어요

한도는 모델별로 따로 관리됩니다. Opus 한도와 Sonnet을 비롯한 다른 모델 한도가 각각 존재한다는 뜻이고, 이걸 나눠 쓰지 않으면 제일 무거운 모델의 한도만 계속 갉아먹게 돼요.

 

 

난이도별로 모델을 나눠 쓰는 기준

한동안 단순한 포맷 변경이나 문구 다듬기처럼 가벼운 작업까지 매번 제일 성능 좋은 모델로 돌렸어요. 딱히 이유가 있었던 건 아니고, 그냥 "제일 좋은 걸 쓰면 되겠지"라는 습관이었습니다.

나중에 깨달았어요. 가벼운 작업은 가벼운 모델로도 결과가 똑같이 나왔습니다. 지금은 복잡한 설계나 까다로운 리팩터링처럼 판단이 많이 들어가는 작업에만 상위 모델을 쓰고, 포맷 정리나 짧은 문구 작업은 가벼운 모델로 넘겨요.

 

작업 난이도	예시 작업	권장 모델	이유
낮음 (판단 거의 불필요)	포맷 변경, 짧은 문구 다듬기, 단순 요약	가벼운 모델(Sonnet 등)	상위 모델과 결과 품질 차이가 거의 없는데 한도만 더 빨리 줄어듦
높음 (복잡한 판단 필요)	복잡한 설계, 까다로운 리팩터링	상위 모델(Opus)	판단력 차이가 결과 품질에 직접 영향을 줌

 

체감 차이는 명확합니다. Opus 한도가 남는 시간이 훨씬 길어졌어요.

강한 모델을 어디에 집중해서 써야 비용 대비 효율이 나는지는 Claude Mythos 비용 폭탄 피하는 법: 강한 AI 모델을 정확히 쓰는 6가지 기준에서 더 구체적인 기준으로 정리했습니다.

 

 

Opus 한도를 다 쓰면 자동으로 다른 모델로 바뀌나요

아니요, 자동으로 전환되지는 않아요. Claude Code에서는 /model 명령어로 사용자가 직접 다른 모델을 선택해야 합니다. 한도가 다 찼다고 해서 알아서 모델이 바뀌는 게 아니라, 안내를 보고 사용자가 명시적으로 전환해야 하는 구조예요.

다만 이 동작 방식은 클라이언트나 요금제에 따라 조금씩 다르게 안내될 수 있고, 정책도 바뀔 수 있으니 지금 쓰고 계신 환경에서 직접 한 번 확인해보시길 권합니다.

 

 

Extra usage 켤 때 여유분은 얼마나 잡아야 할까요

여기서부터는 직접 켜본 경험은 없어요. 대신 습관을 먼저 바꿔보고 나서, 그래도 부족할 때 고려하는 옵션이라는 관점에서 정리합니다.

 

한도를 걸어놔도 초과되는 이유

Extra usage(사용량 크레딧)는 기본 한도를 넘겼을 때 추가로 사용량을 쓸 수 있게 해주는 기능이고, 월별 지출 상한선을 직접 금액으로 설정할 수 있습니다. 그런데 이 상한선을 걸어놔도 실제 청구액이 그보다 살짝 넘는 경우가 보고돼요.

이유는 구조에 있습니다. 이미 진행 중인 세션은 한도에 닿았다고 해서 그 자리에서 뚝 끊기지 않고, 하던 요청까지는 끝까지 처리된 뒤에 멈춰요. 그 마지막 요청 하나가 상한선을 살짝 넘기는 식으로 청구되는 경우가 생기는 거죠. (이 부분은 공식 문서에 명시된 내용이라기보다 실사용자들 사이에서 반복적으로 보고되는 경험담에 가깝다는 점은 밝혀둡니다.)

그래서 개인적으로는 이 기능부터 켜기보다, 지금까지 정리한 습관들을 먼저 적용해보시길 권하고 싶어요. 그래도 계속 부족하다면 그때 Extra usage를 켜되, 상한선은 넉넉하게 잡기보다 최소한으로 시작해서 실제 초과 폭을 보면서 조정하는 편이 안전합니다.

 

 

그래도 자주 걸린다면 — Max로 넘어가기 전에 먼저 해볼 것

위 습관들을 다 적용했는데도 한도에 자주 부딪힌다면, 그때는 플랜 문제일 수 있어요.

 

Max 전환을 고려할 만한 신호 3가지

첫째, 서브에이전트나 자동화 파이프라인을 상시로 돌리는 작업 방식으로 완전히 굳어졌을 때. 둘째, 습관을 다 바꿔봤는데도 주간 단위로 한도에 막히는 일이 반복될 때. 셋째, Opus 같은 상위 모델을 판단이 많이 필요한 작업에 거의 매일 써야 하는 상황일 때예요.

이 세 가지 중 두 개 이상에 해당한다면 Max로 넘어가는 게 합리적입니다. Max 플랜은 Pro 대비 세션당 5배에서 20배 더 많은 사용량을 제공해요. 반대로 하나도 해당하지 않는데 "그냥 한도 걱정 없이 쓰고 싶어서" 넘어가는 거라면, 위에서 정리한 습관들부터 먼저 적용해보시길 권합니다. 요금 차이가 작지 않으니까요.

 

오늘부터 순서대로 적용하는 체크리스트

여기까지 정리한 걸 나열식으로 읽으면 뭐부터 손대야 할지 헷갈리실 수 있어요. 그래서 체감 효과가 큰 순서로 다시 정리합니다.

1. 에이전트를 돌리기 전에 도구 호출 범위와 중단 조건부터 정한다 — 가장 크게 새는 구멍입니다.
2. AI를 쓰기 전에 "이거 스크립트나 도구로 될 일 아닌가"부터 물어본다.
3. 프롬프트에 목표·형식·수용 기준을 미리 적어둔다.
4. 주제가 바뀌면 새 채팅을 열되, 세 줄짜리 핸드오버 요약만 챙겨간다.
5. 작업 난이도에 맞춰 모델을 나눠 쓴다.
6. 그래도 부족하면 Extra usage나 Max 전환을 검토한다.

 

이 순서에는 이유가 있어요. 위로 갈수록 "새기 전에 막는" 사전 설계에 가깝고, 아래로 갈수록 "새고 난 뒤에 보완하는" 사후 대응에 가깝습니다.

한도를 아끼는 법을 검색하는 분들 대부분은 사후 대응 쪽 팁부터 찾으세요. 새 채팅 열기, 모델 바꾸기 같은 것들요. 그런데 실제로 체감 효과가 컸던 건 언제나 위쪽, 그러니까 작업을 시작하기 전에 범위와 기준을 정해두는 쪽이었습니다.

절약보다 먼저 와야 하는 건 설계입니다. 아끼는 습관은 그다음이에요. 지금 진행 중인 작업이 있다면, 다음 세션을 시작하기 전에 1번부터 하나씩 적용해보세요.

 

 

자주 묻는 질문

 

서브에이전트를 쓰면 왜 한도가 유난히 빨리 줄어드나요?

에이전트는 "충분히 좋은 결과"라는 기준이 없으면 스스로 멈추지 않고, 검색이나 도구 호출을 실패할 때마다 계속 재시도해요. 그 재시도 하나하나가 전부 요청으로 잡혀 한도를 깎아 먹습니다. 작업을 맡기기 전에 도구 호출 횟수와 실패 시 중단 조건을 미리 정해두면 소진 속도를 눈에 띄게 줄일 수 있어요.

 

Extra usage 상한선을 걸어놨는데 왜 그보다 더 청구되나요?

이미 진행 중인 세션은 한도에 닿았다고 그 자리에서 바로 끊기지 않고, 하던 요청까지는 끝까지 처리된 뒤에 멈추기 때문이에요. 그 마지막 요청 하나가 상한선을 살짝 넘기는 식으로 청구되는 경우가 있으니, 처음에는 여유분을 넉넉하게 잡기보다 최소한으로 시작해서 실제 초과 폭을 보며 조정하는 게 안전합니다.

 

Opus 한도를 다 쓰면 자동으로 다른 모델로 바뀌나요?

아니요, 자동으로 전환되지 않아요. Claude Code에서는 /model 명령어로 사용자가 직접 다른 모델을 선택해야 합니다. 한도 소진 안내가 뜨더라도 그 자체로 모델이 바뀌는 건 아니고, 안내를 보고 사용자가 명시적으로 전환해야 하는 구조예요. 다만 이 동작은 클라이언트나 요금제에 따라 조금씩 다르게 안내될 수 있으니, 지금 쓰고 계신 환경에서 직접 확인해보시길 권합니다.

 

 

참고 자료

1. Usage limit best practices – Anthropic Help Center — Pro/Max/Team/Enterprise의 5시간 세션 한도, Opus와 다른 모델의 주간 한도가 별도로 리셋된다는 점, 질문 묶기·Projects 캐싱 등 공식 절약 습관의 근거로 사용.
2. Anthropic unveils new rate limits to curb Claude Code power users – TechCrunch — Anthropic이 Claude Code에 주간 한도를 도입한 배경(24/7 백그라운드 상시 실행 억제, 서비스 안정성 유지)을 설명하는 업계 매체 기사로 근거 삼음.
3. 프롬프팅 모범 사례 – Claude Docs — "명확하고 직접적으로 작성하기" 등 요청을 구체적으로 구성할수록 결과가 향상된다는 공식 프롬프트 작성 원칙의 근거로 사용.
4. Models, usage, and limits in Claude Code – Anthropic Help Center — Claude Code에서 모델 한도 소진 시 /model 명령으로 사용자가 직접 전환해야 한다는 점의 근거로 사용.
5. Manage usage credits for paid Claude plans – Anthropic Help Center — Extra usage(사용량 크레딧)의 정의와 월별 지출 상한선 설정 기능의 근거로 사용.
6. What is the Max plan? – Anthropic Help Center — Max 플랜이 Pro 대비 세션당 5배/20배 더 많은 사용량을 제공한다는 수치의 근거로 사용.