Claude Code 사용 한도: 5시간 창, 주간 상한, 429, 그리고 벽에 부딪힌 뒤의 모든 갈림길
구독 한도는 동시에 도는 시계 두 개: 5시간 롤링 창과 주간 상한. 어떻게 도는지, 왜 Opus가 주간 풀을 먼저 태우는지, 429가 실제로 무엇을 말하는지, 벽 이후의 다섯 갈림길을 비용 순으로 정리한다.
한도라는 것은 평소엔 존재하지 않다가, 당신이 바쁜 바로 그 순간 나타난다. 월말 청구서와 함께 오는 게 아니라, 리팩터링 절반쯤 온 금요일 밤을 골라 에이전트를 '나중에 다시 시도하세요'만 말하는 입력창으로 바꾼다. 이 글은 한도를 우회하는 법이 아니다—그건 정당한 목표가 아니다. 분해하는 것이다: 어떤 시계가 도는지, 벽에 부딪힌 순간 기계가 무엇을 말하는지, 실제로 존재하는 출구는 몇 개이고 각각의 값표는 얼마인지.
먼저 밝힙니다: 나는 Claude Code용 종량 과금 게이트웨이 Teapot Router를 운영한다. 그래서 아래 출구 중 하나에 명백한 이해관계가 있다—그래서 출구는 저렴한 순으로, 무료인 것을 맨 앞에 두었다. 순서가 공정한지는 직접 판단하라.
한도는 동시에 도는 시계 두 개
Claude Code 구독 한도는 숫자 하나가 아니라 둘이다: 5시간 롤링 창과 주간 상한. 창은 시작한 시점부터 5시간 뒤 리셋되고, 주간 상한은 일주일 전체에 걸쳐 창이 용서해주지 않은 만큼을 쌓는다. 화요일 오후에 몰아친 작업은 화요일 창만 쓰는 게 아니라 이번 주 풀에서도 깎인다.
그래서 '방금 리셋됐는데 왜 또 막히지'는 대개 버그가 아니다. 5시간 창이 찬 것과 주간 상한이 바닥난 것은 다른 감각이고, 후자는 창이 새로 비어도 주가 넘어가길 기다려야 한다. /usage로 지금 자신이 어느 시계 앞에 서 있는지 볼 수 있다.
- 5시간 창: 롤링 리셋. '지금 계속할 수 있는가'를 결정한다.
- 주간 상한: 누적. '이번 주가 얼마나 남았는가'를 결정한다.
- 둘은 독립적으로 계량되고, 먼저 차는 쪽이 당신을 멈춘다.
왜 Opus가 항상 주간 상한을 먼저 태우는가
주간 상한은 '사용량'으로 재고, 플래그십 모델은 턴당 경량 모델의 몇 배를 먹는다—더 긴 컨텍스트 입력, 더 긴 출력. 같은 8시간의 무거운 하루가 Opus에서는 Sonnet의 몇 배 속도로 주간 풀을 줄인다. 여기서 그 유명한 비대칭이 나온다: 주 초반에 며칠 Opus를 돌리면 Sonnet 전용 할당량이 남아 있어도 주간 상한이 먼저 바닥난다—풀은 공유고 전용 몫은 전체 탱크를 채우지 못한다.
이건 헤비 유저에 대한 벌이 아니라 요금 구조가 쓴 대로 움직이는 것이다. 구독은 정액 보험이고 보험료는 어떤 모델을 쓰는지에 둔감하지만, 풀에는 바닥이 있다. 그게 보이면 '모델을 바꾼다'와 '과금 방식을 바꾼다'는 미신이 아니라 같은 산술의 두 변수가 된다.
벽에 부딪힌 그 순간 안에서 무슨 일이 일어나는가
표면 증상은 429다. 이것은 오류라기보다 프로토콜이 '할당량을 다 썼고 재개 시각은 응답 헤더에 있다'고 정직하게 알려주는 것이다. 대부분의 클라이언트는 재개 시각을 전달해 준다—그러니 벽에서 첫 수는 도구를 갈아타는 게 아니라 시계를 읽고 다음 한 시간을 어떻게 쓸지 정하는 것이다.
분명히 해둘 가치가 있다: 이 벽은 구독 경로에 존재한다. 종량 과금 API 경로에는 5시간 창도 주간 풀도 없고, 제한은 별종(분당 처리량과 등급별 월 지출 상한)이라 혼자 코딩하는 개발자는 사실상 만나지 못한다. 종량이 더 낫다는 뜻이 아니라—벽을 계량기로 바꿀 뿐이다—그러나 아래 모든 출구는 이 갈림길에서 갈라진다.
다섯 갈림길, 저렴한 순으로
벽 이후의 선택지는 원래 어딘가에 적혀 있었다. 다른 문서들에 흩어져 있을 뿐. 모아서 '싼 것부터' 순으로 놓았다:
- 리셋을 기다린다. 5시간 창은 금방 돌아오고 비용은 0. '마지막 한 끗' 상황이라면: 작업을 멈춰 두고 창이 돌아오면 마무리한다.
- 컨텍스트를 압축한다. /compact 또는 새 세션. 매 턴은 지금까지의 대화를 다시 보내므로 죽은 무게를 덜면 남은 각 턴이 싸진다. 할당량은 돌아오지 않지만 남은 것이 오래간다.
- 모델을 한 단계 내린다. 틀에 박힌 편집과 검색에 플래그십은 필요 없다. 정말 어려운 요청만 Opus에 남기면 주간 소진 속도가 즉시 내려간다. 가장 과소평가된 출구: 대부분 사람의 기본 모델은 그들의 대부분 작업에 과잉이다.
- 플랜을 올린다. 하루 몇 시간을 플래그십에 집중하는 형태라면 더 큰 풀이 정말로 단위당 싸다—그게 등급의 존재 이유다. 써야 할 곳에서 써라.
- 종량 과금으로 전환한다. 벽은 사라지고 계량기가 돈다. 사용이 다양하거나 불규칙하거나 여러 도구에 흩어진 사람, 그리고 한 달에 한 번 이상 벽에 부딪히는 사람에게 맞다—막힌 시간도 비용이다.
어떤 형태의 사람이 어디서 멈춰야 하는가
앞 네 출구에 이 글은 필요 없다. 벽에 한 번 부딪힌 사람은 저절로 익힌다. 산술을 멈춰 세울 가치가 있는 곳은 넷과 다섯 사이다: 플랜을 올릴 것인가, 종량으로 바꿀 것인가.
그 판단의 원료는 자기 사용 형태다: 하루 집중 시간, 작업 강도, 캐시 동작. 이것을 비용 계산기에 넣으면 손익분기—종량 지출이 플랜 가격을 따라잡는 하루 시간—이 나온다. 그 선 아래면 종량이 싸고, 위면 플랜이 이기고 벽은 내가 선택한 보험료다. 만능 답은 없고 자기 곱셈만 있다.
알아둘 비대칭 하나: 플랜 가격은 고정이지만 종량 단가는 요금표를 따른다. 계량기를 선택하는 사람은 기계 판독 가능한 가격표와 요청 단위 명세를 요구해야 한다—안 그러면 '계량기가 돈다'가 조용히 '잠긴 상자 안에서 계량기가 돈다'가 된다.
한도는 적이 아니라 구독이 맺은 계약 조항이다: 월 지출 상한과 맞바꾼 사용량 상한. 벽의 아픔은 계약이 조건을 상기시키는 소리다. 외울 것은 다섯 출구가 아니라 자기 형태다. 형태가 분명해지면 어디서 멈출지는 한 자릿수 곱셈이 된다.
자주 묻는 질문
Claude Code 한도는 얼마나 자주 리셋되나?
5시간 롤링 창은 시작 후 5시간마다, 주간 상한은 주 단위로 회복된다. 둘은 독립적이라 창이 새로 돼도 주간 풀은 차지 않는다. 제한되면 /usage로 어느 시계인지 확인하라.
종량 과금 API에도 한도가 있나?
있지만 별종이다: 분당 요청 수와 토큰 처리량(RPM/ITPM/OTPM), 등급별 월 지출 상한이지 5시간 창이나 주간 풀이 아니다. 개발자 혼자 쓰는 양에서는 사실상 보이지 않고, 순간 집중과 월 총액을 잰다.
429가 떴다. 고장인가?
아니다—429는 서버가 '할당량 소진, 재개 시각은 응답 헤더에'라고 보고하는 것뿐이다. 시계를 읽고 정해라: 기다릴지, 압축할지, 아니면 위의 다섯 출구 중 하나로 갈지.