|

클로드 요금제 한도 2개가 앱과 공유된다 — 밤새 돈 루프 하나가 13%p를 태운 이유

3줄 요약
- 클로드 요금제(Pro·Max)에는 클로드 코드가 포함되고, 한도는 5시간 세션 한도와 주간 한도 2개다. 이 2개를 채팅 앱과 클로드 코드가 함께 쓴다.
- 한도에 닿으면 /model로 모델을 바꿔도 풀리지 않는다. 기다리거나, 사용 크레딧(usage credits)을 켜거나, 리셋 뒤 자동으로 이어 가게 하는 세 갈래뿐이다.
- 이 프로젝트에서는 아무도 안 보는 밤에 종료조건 없이 돈 LLM 루프 하나가 사용량 13%p를 태웠다. 원인은 단가가 아니라 "멈출 조건이 없었다"였고, 대책은 상한 3종 중 최소 2개를 코드로 거는 것이다.

질문 답
클로드 요금제에 클로드 코드가 들어 있나 Pro·Max 모두 포함된다(공식 도움말)
한도는 몇 개인가 5시간 세션 한도와 주간 한도, 2개
채팅 앱과 따로 세나 아니다. 같은 한도를 클로드 앱과 클로드 코드가 나눠 쓴다
한도에 닿으면 모델을 바꾸면 되나 세션·주간 한도는 모든 모델 공통이라 /model로 못 피한다
어디서 확인하나 클로드 코드의 /usage — 플랜 사용량 막대와 항목별 귀속(breakdown)
밤새 돌리는 자동화는 무엇을 걸어야 하나 실패 상한·전체 호출 상한·시간 상한 중 최소 2개

이 글대로 하면 무엇이 달라지는가: "어제 채팅 좀 했는데 왜 오늘 클로드 코드가 막히지?"를 구조로 설명할 수 있게 되고, 무인으로 돌리는 루프가 한도를 통째로 먹기 전에 스스로 멈추게 만들 수 있다.

클로드 요금제 한도란 무엇인가?

클로드 요금제 한도란 구독 플랜이 일정 시간 동안 쓸 수 있게 허용하는 사용량의 상한이다. 공식 도움말(support.claude.com, "Using Claude Code with your Pro or Max plan")은 Pro·Max 구독에 클로드 코드가 포함되며, 한도가 두 층으로 걸린다고 설명한다.

한도 무엇을 세나 리셋
세션 한도 5시간 창 안의 사용량 5시간 단위로 다시 열린다
주간 한도 7일 창 안의 사용량 주 단위로 다시 열린다

여기서 가장 자주 놓치는 문장은 이것이다. 공식 도움말 원문은 "These limits are shared across Claude and Claude Code"다. 즉 브라우저나 데스크톱 앱에서 클로드와 나눈 대화와, 터미널에서 클로드 코드가 쓴 토큰이 같은 통에서 빠진다. 팀·엔터프라이즈 플랜도 같은 구조다. 클로드 코드 비용 문서(code.claude.com/docs/en/costs)는 좌석(seat)별 허용량이 "rolling five-hour window and a weekly window"로 리셋되고 채팅·Cowork와 공유된다고 적는다.

이 구조에서 나오는 결론은 하나다. 클로드 코드 쪽 사용량만 아껴서는 한도 관리가 안 된다. 앱에서 긴 대화를 한 날은 클로드 코드가 쓸 몫도 줄어 있다.

클로드 코드 요금제를 고를 때 한도 말고 무엇이 달라지나?

요금 숫자보다 먼저 볼 것은 "한도에 닿은 뒤 어디로 넘어가는가"다. 공식 도움말 기준으로 한도에 닿으면 사용 크레딧(usage credits)을 켜서 이어 가거나, Console API 크레딧으로 표준 API 요금을 내고 이어 갈 수 있다.

항목 구독 한도 안 사용 크레딧 사용 중 API 키(Console)
과금 구독료에 포함 크레딧에서 차감 토큰당 표준 API 요금
프롬프트 캐시 수명 1시간 5분으로 줄어든다 기본 5분
/usage에서 보는 것 플랜 사용량 막대 이번 달 크레딧 지출 행 Session 블록의 비용 추정

표의 둘째 줄이 실무에서 중요하다. 비용 문서는 캐시 수명이 구독에서는 1시간이고, 사용 크레딧을 쓰기 시작하면 5분으로 줄어든다고 명시한다. 캐시가 짧아지면 잠깐 쉬었다 돌아온 첫 메시지가 전체 컨텍스트를 다시 처리한다. 한도를 넘겨 크레딧으로 넘어간 순간부터는 같은 작업 습관이 더 비싸진다는 뜻이다.

하나 더 있다. 공식 도움말은 "Monthly API credits included with Max plans can't be used in Claude Code"라고 적는다. Max에 딸린 월 API 크레딧을 클로드 코드 한도 연장용으로 쓸 수는 없다.

한도에 닿았을 때 할 수 있는 것은 무엇인가?

할 수 있는 것은 기다리기, 사용 크레딧 켜기, 리셋 뒤 자동으로 이어 가기 세 갈래다. 모델 바꾸기는 여기에 없다. 비용 문서는 "You've hit your session limit" 또는 "You've hit your weekly limit" 메시지가 모든 모델 공통의 좌석 한도라서 /model로 모델을 바꿔도 풀리지 않는다고 설명한다. 반대로 "You've hit your Opus limit"처럼 모델 이름이 들어간 메시지는 다른 계열 모델로 바꾸면 이어서 일할 수 있다.

  1. 메시지에 모델 이름이 있는지 먼저 본다. 있으면 /model로 다른 계열로 바꾼다. 없으면 2번으로 간다.
  2. 메시지에 적힌 리셋 시각을 확인한다. 급하지 않으면 그때까지 기다린다.
  3. 급하면 /usage-credits를 실행한다. Pro·Max는 브라우저에서 claude.ai 설정의 사용 크레딧 항목이 열린다.
  4. 긴 작업이 중간에 끊겼다면 v2.1.234 이상에서 /rate-limit-options로 "리셋 뒤 자동 계속"을 고를 수 있다. 조직 단위로는 관리형 설정의 autoContinueAtUsageLimit로 정한다.
  5. 다음 날 같은 일이 반복되지 않도록 /usage의 항목별 귀속을 보고 무엇이 한도를 먹었는지 확인한다(다음 절).

클로드 사용량은 어디서 어떻게 확인하나?

클로드 코드 안에서 /usage를 치면 된다. 구독자는 화면 위쪽의 Session 블록이 아니라 그 아래 플랜 사용량 막대와 breakdown을 봐야 한다. 비용 문서는 Session 블록이 API 사용자용 추정치라 구독 과금과는 관계가 없다고 적어 두었다.

breakdown에는 세 가지가 나온다.

항목 보여 주는 것 판정에 쓰는 법
Attribution 스킬·서브에이전트·플러그인·MCP 서버별 사용량 비율 특정 서브에이전트나 MCP 서버가 몫을 크게 먹는지 본다
Behavior flags 긴 컨텍스트·캐시 미스 등이 최근 사용량의 10% 이상이면 표시 습관 문제인지 작업량 문제인지 가른다
Loops /loop 등 예약 작업별 실행 횟수·총 토큰·회당 토큰 사람이 없을 때 도는 것이 얼마나 먹는지 본다(v2.1.242 이상)

d와 w 키로 최근 24시간과 7일을 오간다. 한계도 분명하다. 이 수치는 이 컴퓨터의 로컬 세션 기록으로 계산한 근사치라서, 다른 기기나 claude.ai 앱에서 쓴 양은 들어가지 않는다. 한도는 앱과 공유되는데 breakdown은 앱을 못 본다. 그래서 막대는 많이 찼는데 breakdown 합계가 작게 보이면, 빠진 부분은 앱이나 다른 기기 사용분일 가능성이 크다.

밤새 돈 루프 하나가 13%p를 태운 이유는 무엇인가?

멈출 조건 없이 돌았기 때문이다. 단가가 비싸서가 아니다. 이 프로젝트의 운영 규칙 문서(rules-token-context.md §9, 사고일 2026-08-01)에 남은 기록은 이렇다: 승인 없이 돌던 야간 LLM 루프가 사용량 13%p를 태웠다. 같은 날짜의 다른 프로젝트 백로그에도 "사고: 하룻밤 13%p"라는 경고가 남아 있다.

기록이 원인을 적는 방식이 중요하다. 규칙 문서는 "원인을 '단가가 비쌌다'로 적으면 대책이 틀린다"고 못 박는다. 사람이 보고 있었다면 몇 분 안에 끊겼을 루프였다. 문제는 아무도 보지 않는 시간과 종료조건 없음이 겹친 것이다. 그래서 대책도 "싸게 돌려라"가 아니라 "스스로 멈추게 만들어라"가 됐다.

13%p라는 숫자를 읽을 때의 주의점도 같이 적는다. 이 프로젝트는 %p를 가중 토큰으로 바꾸는 환산 계수를 쓰고 있지만, 그 계수는 추정값이다. 관련 스크립트 주석에는 "이 값으로 낸 %p를 승인·보고 수치로 쓰지 않는다"고 적혀 있다. 13%p는 계량기 화면에서 읽은 변화량이고, 이를 토큰 수로 바꾼 값은 이 글에 싣지 않는다.

오진 사슬 — 왜 처음엔 단가를 의심하게 되나

  1. 아침에 사용량 막대가 크게 올라 있다.
  2. 가장 눈에 띄는 변수는 모델 단가라서 "비싼 모델을 썼다"로 결론 내리기 쉽다.
  3. 모델을 싼 쪽으로 바꾼다. 하지만 루프에는 여전히 종료조건이 없다.
  4. 다음 밤에도 루프가 돈다. 단가가 내려간 만큼 더 오래, 더 많이 돈다.

단가를 고치면 사고의 크기만 줄고 사고는 그대로 남는다. 고쳐야 할 것은 4번의 "여전히"다.

무인 루프에는 무엇을 걸어야 스스로 멈추나?

상한 3종 중 최소 2개를 코드로 건다. 이 프로젝트 규칙이 정한 3종은 실패 상한(연속 3회), 전체 호출 상한, 시간(wall-clock) 상한이다. 아래는 그 셋을 한 클래스로 묶은 최소 형태다.

import time

class LoopGuard:
    """무인 루프의 종료조건. 셋 중 하나라도 넘으면 멈춘다."""
    def __init__(self, max_fail=3, max_calls=200, max_seconds=3 * 3600):
        self.max_fail, self.max_calls, self.max_seconds = max_fail, max_calls, max_seconds
        self.fail = 0
        self.calls = 0
        self.t0 = time.monotonic()

    def check(self):
        if self.fail >= self.max_fail:
            return f"연속 실패 {self.fail}회"
        if self.calls >= self.max_calls:
            return f"호출 상한 {self.calls}회"
        if time.monotonic() - self.t0 >= self.max_seconds:
            return "시간 상한 도달"
        return None

    def record(self, ok):
        self.calls += 1
        self.fail = 0 if ok else self.fail + 1

쓰는 쪽은 매 반복 맨 앞에서 check()를 부르고, 멈출 사유가 나오면 그 사유와 누적 호출 수를 로그 한 줄로 남긴 뒤 끝낸다. 이 프로젝트는 그 로그를 llm_usage.jsonl 같은 원장 파일에 쌓는다.

가드를 만들었으면 가드가 실제로 멈추는지를 먼저 시험한다. 규칙 문서가 "종료조건 자체 테스트"를 따로 요구하는 이유다.

def test_guard_stops():
    g = LoopGuard(max_fail=3, max_calls=10, max_seconds=60)
    for _ in range(3):
        g.record(ok=False)
    assert g.check() == "연속 실패 3회"

    g = LoopGuard(max_fail=3, max_calls=5, max_seconds=60)
    for _ in range(5):
        g.record(ok=True)
    assert g.check() == "호출 상한 5회"

429 쿨다운은 왜 상한이 아닌가

흔한 착각이 "429가 나면 쉬었다가 다시 도는 서킷브레이커를 넣었으니 안전하다"이다. 규칙 문서는 이것을 명시적으로 부정한다 — 서킷브레이커는 재개 장치라서 오히려 루프의 수명을 늘린다. 한도에 닿아 429를 받고, 쉬고, 리셋 뒤 다시 돌면 그 루프는 다음 한도 창까지 먹는다. 쿨다운은 상한 옆에 붙일 수는 있어도 상한을 대신하지 못한다.

무인 자동화를 띄우기 전에 무엇을 확인하나?

체크리스트는 다섯 줄이다. 앞의 둘은 예방이고 뒤의 셋은 봉쇄다. 이 프로젝트 규칙은 둘을 "한 세트로 쓴다"고 적는다. 예방만 하면 예상이 빗나간 날 막을 장치가 없고, 봉쇄만 하면 애초에 안 띄워야 할 루프가 뜬다.

  • [ ] 예상 사용량을 착수 전에 적었다(몇 %p를 쓸 것으로 보는가)
  • [ ] 그 예상을 사람이 보고 승인했다
  • [ ] 실패·호출·시간 상한 중 2개 이상을 코드로 걸었고, 멈추는지 테스트했다
  • [ ] 끝날 때 멈춘 사유와 사용량을 로그 한 줄로 남긴다
  • [ ] 월 1회, 돌고 있는 cron·스케줄러·백그라운드 러너를 전부 나열해 아직 필요한지 본다

마지막 줄이 사고의 형태와 직접 맞닿아 있다. 규칙 문서는 사고를 "목록에 없는 채로 돌고 있었다"로 요약한다. 상한을 아무리 잘 걸어도, 상한이 없는 옛 루프가 목록 밖에서 돌고 있으면 소용이 없다.

한계 — 이 대책으로 안 통하는 경우

이 가드는 내가 짠 루프에만 걸린다. 클로드 코드 자체의 예약 작업(/loop)은 Loops 행으로 확인하고 직접 끄거나 주기를 늘려야 한다. 또 한도는 앱과 공유되므로, 가드가 루프를 잘 멈춰도 같은 시간대에 앱에서 긴 대화를 하면 아침 막대는 여전히 높을 수 있다. 이 경우는 breakdown이 앱 사용분을 못 보기 때문에 화면만으로는 원인을 가를 수 없다.

서브에이전트의 실제 토큰 비용과 압축이 한 턴에서 비롯된다는 실측도 같은 질문, 즉 "무엇이 한도를 먹는가"를 다른 각도에서 잰 글이다. 이미지 생성 쪽에서 같은 유형의 사고가 난 기록은 AI 이미지 생성 비용 사고에 있다.

자주 묻는 질문

Q. 클로드 요금제를 쓰면 클로드 코드 한도는 따로 주어지나?
A. 따로가 아니다. 공식 도움말 원문이 "These limits are shared across Claude and Claude Code"다. 5시간 세션 한도와 주간 한도 2개를 채팅 앱과 클로드 코드가 함께 쓴다.

Q. 주간 한도에 걸렸는데 모델을 바꾸면 계속 쓸 수 있나?
A. 세션 한도·주간 한도 메시지는 모든 모델 공통이라 /model로 풀리지 않는다. 모델 이름이 들어간 메시지("Opus limit" 등)일 때만 다른 계열 모델로 바꿔 이어 갈 수 있다.

Q. 클로드 사용량 확인은 어디서 하나?
A. 클로드 코드에서 /usage를 친다. 구독자는 플랜 사용량 막대와 breakdown(귀속·행동 플래그·Loops)을 보면 된다. 다만 이 수치는 이 컴퓨터의 로컬 기록 기준이라 다른 기기와 claude.ai 앱 사용분은 빠진다.

Q. Max 요금제의 월 API 크레딧으로 클로드 코드 한도를 늘릴 수 있나?
A. 없다. 공식 도움말이 "Monthly API credits included with Max plans can't be used in Claude Code"라고 적는다. 한도를 넘겨 이어 가려면 사용 크레딧을 켜거나 Console API 크레딧으로 표준 요금을 낸다.

Q. 밤새 돌리는 자동화는 무엇을 걸어야 안전한가?
A. 실패 상한(연속 3회)·전체 호출 상한·시간 상한 중 최소 2개를 코드로 걸고, 그 상한이 실제로 멈추는지 테스트한다. 429 쿨다운은 재개 장치라 상한을 대신하지 못한다.

이 글이 도움이 됐다면

링크 하나면 필요한 사람에게 닿습니다.

네이버 블로그

설치 없이 바로 쓰는 무료 도구

입력값은 서버로 전송되지 않고 브라우저에서만 계산합니다.

글자수 세기 공백 포함·제외 글자수, 바이트, 원고지 매수를 한 번에 3.3% 계산기 프리랜서 원천징수 실수령액과 세전 금액 역산 실업급여 계산기 구직급여일액·소정급여일수·총 수령액을 한 번에 날짜 계산기 두 날짜 사이 일수, 며칠 뒤·며칠 전 날짜와 요일 주휴수당 계산기 주휴시간·주급 합계와 주휴 포함 시급

도구 모음 전체 보기 ›

Comments

Comments (0)

Leave a Comment

← Back to List