Claude Code에서 백그라운드의 부작업자(Sub-agent)를 여러 개 실행하는 사람들에게 이런 일이 발생한다. 부작업자가 “You've hit your session limit - resets at 7pm”과 같은 메시지와 함께 차례차례 멈춘다. 그런데 같은 세션의 본체 작업은 몇 시간 동안이나 평소처럼 계속 움직이고 있다. /status를 확인해 봐도 계약 중인 구독(Subscription) 할당량에는 아직 여유가 있다. 표시된 시간까지 기다려도 아무것도 변하지 않는다. 어쩔 수 없이 추가 이용 크레딧을 구매하면 잠시 동안은 작동한다. 하지만 다시 같은 지점에서 멈추고, 게다가——멈춰서 버려진 부작업자가 사용한 만큼의 토큰은 제대로 과금된다.

이 사고는 GitHub의 이슈 #74006에서 당사자의 상세한 관측과 함께 보고되었다. 동작 자체는 보고자의 것이므로 전언으로 기술하고, 확인 방법은 직접 구축하여 확인한 범위 내에서 작성한다.

보고자의 관측을 정리하면 다음과 같다.

• 본체 세션의 반복은 몇 시간 동안 한 번도 멈추지 않고 작동했다 (새벽 3시경부터 정오 전까지 20회의 커밋, 14시 이후에도 멈추지 않음).
• 그 이면에서 부작업자만이 “세션 상한, X시에 리셋”이라며 종단적으로 종료되었다. 시간은 8am → 2:10pm → 7pm으로 돌아가는데, 기다려도 풀리지 않는다.
• /status는 그동안 계속 구독 할당량에 여유가 있음을 표시했다.
• 추가 크레딧을 $100 구매하자 다음 부작업자가 작동했다. 하지만 16.4분(61회의 도구 호출) 동안 실행된 후, 다시 똑같은 “세션 상한”으로 종료되었고, 그 374,904 토큰은 방금 구매한 크레딧에서 차감되었으며 결과물은 제로였다. 여기에 $50를 더해 총 $150를 “회피”하기 위해 지불했다. 그동안에도 /status는 구독 할당량을 “여유 있음”으로 계속 표시했다.

즉, 기다려도 풀리지 않고 사도 풀리지 않는데, 종료된 작업만큼은 과금된다. 표시된 상한과 실제로 적용되고 있는 상한이 일치하지 않을 가능성이 높다.

이 부분이 가장 중요하다. 보고자는 동일한 세션에서 발생한 여러 번의 종료를 나중에 사용량 기록을 통해 구분해 냈다. 모든 것이 같은 원인은 아니다. 이 부분을 혼동하면 교정할 필요가 없는 할당량을 의심하거나, 효과가 없는 크레딧을 구매하게 된다.

대량의 병렬 실행 이후의 종료는 순수하게 할당량 고갈일 수 있다. 처음 두 번의 종료 직전에는 차원이 다른 병렬 실행이 있었다. 첫 번째는 12개의 검증 부작업자가 약 7분 동안 약 240만 토큰을 소모한 직후에 13번째가 종료되었다. 두 번째는 약 35분 동안 15개·약 330만 토큰이 실행을 마친 직후였다. 이 정도의 병렬 실행이 짧은 시간에 이루어진다면, 공유 할당량이 정말로 바닥났을 가능성이 높다. 이 경우의 “상한”은 실재하는 것이며, 혼란스러운 점은 부작업자마다 리셋 시간이 다르게 투영되기 때문에(8시→14시 10분→19시), 하나의 할당량임에도 불구하고 여러 개의 별개 상한이 적용되는 것처럼 보인다는 것이다.

설명되지 않는 것은 고립된 종료 쪽이다. 세 번째 종료는 성격이 다르다. 병렬 실행은 제로였으며, 단 하나의 부작업자가 방금 구매한 추가 크레딧 위에서 16.4분·374,904 토큰을 실행한 후 똑같은 “세션 상한”으로 종료되었다. 게다가 /status는 구독 할당량에 여유가 있음을 표시한 상태였다. 직전에 대량의 병렬 실행이 있었던 것도 아니다. 할당량 고갈로는 설명할 수 없다.

이 고립된 종료 주변에 있었던 유일한 이상 신호는 보조 모델의 부재였다. 동일한 세션 내에서 다음과 같은 문구가 그대로 나타났다 (첫 번째는 본체의 승인 판정 시, 두 번째는 완료된 부작업자의 점검 시).

claude-opus-4-8[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash right now.

Note: claude-opus-4-8[1m] (the safety classifier) was unavailable when reviewing this subagent's work.

이것이 가리키는 바는, 부작업자의 경로가 당신의 세션 모델(예: claude-fable-5)과는 다른 보조 모델(승인의 안전을 판정하는 분류기 등)에 의존하고 있다는 것이다. 여기서부터는 아직 제공 측에 확인되지 않은, 개연성 있는 가설로서 읽어주길 바란다. 이 보조 모델의 용량이나 재고가 바닥나서 부작업자가 종료되고 있음에도, 표시되는 “세션 상한” 에러와 /status

둘 다 세션의 모델 프레임(枠)을 가리키고 있다는 논리라면, 고립된 '죽음(사망)'의 불일치가 연결된다. 세션의 모델 프레임은 한 번도 다 소진되지 않았기에, 기다려도 해결되지 않는다. 그리고 이 보조 모델의 용량은 구독 프레임이나 추가 이용 크레딧(Credit)에 직접적으로 대응하지 않는다. 따라서 크레딧을 구매해도 적용 중인 상한에는 영향을 미치지 않으며, 종료된 부작업자(Sub-worker)가 그때까지 사용한 토큰(Token)만이 해당 크레딧에서 차감된다. 표시의 괴리가 그대로 이중 지출로 변하는 것이다.

진정으로 수정해야 할 쪽은 제공자 측이다. 에러 문구와 /status가 거부된 상한의 정체(구독 프레임인지, 추가 크레딧인지, 아니면 보조 모델의 용량인지)를 명시해야 한다. 그리고 상한으로 인해 폐기된 작업분에 대해서는 과금하지 않거나, 중간에 저장하여 재개할 수 있도록 해야 한다. 보고자 역시 그것을 요구하고 있다.

그것이 도입되기 전까지, 사용자가 직접 할 수 있는 것은 '구매하기 전에 확인하는 것'이다. 다음 세 가지가 동일한 세션에서 일치하는지 확인한다.

• 보조 모델이 부재하다는 문구(위의 직설적 표현)가 나오고 있는가.
• 부작업자가 '세션 상한'으로 인해 종료되었는가.
• /status는 구독 프레임에 여유가 있다고 표시하는가.

이 세 가지가 모두 충족된다면, 거부되고 있는 것은 보조 모델의 용량일 가능성이 높다. 이 경우 추가 크레딧을 구매해도 해결되지 않는다. 그러므로 먼저 확인해야 한다. 세션 로그(도구의 결과나 작업 사용량 요약 행)를 입력했을 때, 이 공기(共起, Co-occurrence)를 판정하는 최소한의 형태는 다음과 같다. 직접 보조 모델의 부재, 부작업자의 종료, 고아(Orphan)가 된 토큰이라는 세 가지 상황을 포함하는 장면을 만들어 실행해 보았으며, 판정이 제대로 나오는지와, 부작업자의 종료만 있고 보조 모델의 부재가 없는 경우에는 정확히 구별되는지를 확인했다.

#!/bin/bash
# 세션 로그를 표준 입력으로 흘려넣으면, '세션 상한'에 의한 부작업자의 종료가
# 보조 모델의 용량에 기인했을 가능성이 높은지 판정한다. 구매 전 확인용으로 사용한다.
...

이것은 상한을 멈추게 하지는 않는다. 보조 모델이 부재한다면 부작업자는 계속해서 종료될 것이다. 멈출 수 있는 것은 '제시된 상한에 속아, 효과가 없는 크레딧을 계속 구매하는 부분'이다. 적용 중인 상한이 무엇인지 알 수 있다면, $150를 지불하기 전에 그것이 구독 프레임도 크레딧도 아니라는 사실을 알 수 있다.

• 부작업자의 '세션 상한' 종료는 적어도 두 종류가 있다. 직전에 압도적인 병렬 작업(수백만 토큰)이 있었다면 공유 프레임이 정말로 고갈되었을 가능성이 높다(혼란스러운 점은 리셋 시점의 투영이 제각각이라는 것뿐이다). 하지만 병렬 작업이 없었고, 단일 작업임에도 크레딧 상태에서 종료되었으며, /status는 여유가 있다면—이 고립된 종료는 프레임의 고갈로는 설명되지 않는다.
• 고립된 종료 주변에 있었던 유일한 이상 징후는 보조 모델(안전 분류기 등)의 부재였다. 아직 제공자 측에 확인되지 않았지만 논리적인 가설은, 부작업자를 종료시키는 것이 이 보조 모델의 용량이며, 에러와 /status는 세션의 모델 프레임을 가리키고 있다는 것이다. 그 용량은 구독이나 크레딧에 직접 대응하지 않으므로, 구매해도 해결되지 않으며, 종료된 부작업자의 토큰만이 과금된다 = 표시의 괴리가 이중 지출이 된다.
• 사용자가 할 수 있는 것은 구매 전에 '보조 모델의 부재 · 부작업자의 종료 · /status의 여유'라는 공기(Co-occurrence)를 확인하는 것이다. 공기가 있다면 효과 없는 크레딧을 급하게 사지 않는다. 공기가 없고 종료만 발생했다면 우선 /status의 프레임을 확인한다. 진정한 수정은 제공자 측에서 이루어져야 한다(에러와 /status가 상한의 정체, 즉 어떤 모델의 어떤 풀(Pool)인지를 명시할 것, 폐기된 작업을 과금하지 말 것, 용량이 회복되면 부작업자를 재개할 것).

이러한 '표시와 실태가 어긋나 자신도 모르는 사이에 돈이 녹아내리는' 유형의 사고와 그에 대한 대비책을 무료 hook 모음인 cc-safe-setup에 정리하여 공개하고 있다. 도입은 다음 한 줄이면 충분하다.

npx cc-safe-setup

나아가, 이러한 비용 괴리 사고를 포함하여 Claude Code에서 실제로 발생한 사고들을 '증상 → 탐지 → 복구 → 예방' 순으로 정리한 유료 도서(Anthropic 공식 가이드에는 없는 사고 방지법, ¥800)도 출간했다. 백그라운드 작업자가 실행된 것만으로 이용 프레임이 타버리는 사고나, 구독 중임에도 몰래 종량제로 과금되는 함정 등, 비용 폭주의 계통을 여러 장에 걸쳐 다루고 있다. 제3장까지는 무료로 미리 읽을 수 있으며, 이후에도 매달 새로운 사고 사례를 추가하여 구매자에게 무상 업데이트로 제공한다.