‘5시간 후 초기화’ 배너를 무심코 넘긴 결과 주간 한도에 걸려 작업이 중단된 경험과 원인 분석

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

이 글은 작성자가 Claude 사용 중 갑작스럽게 서비스 접근이 차단된 원인을 파악한 경험을 바탕으로 세션 한도와 개인별 고정 주간 한도가 별개로 존재하며 둘 다 100% 미만이어야 하는 구조임을 밝힌 사례이다. 세션 한도는 최초 메시지 발신 시점부터 롤링 방식으로 5시간 동안 유효하고 주간 한도는 계정별 앵커 시점에 따라 7일 단위로 초기화되며 작성자는 자신의 경우 세션은 거의 남아 있었지만 주간이 이미 84%여서 차단이 발생했다고 스크린샷과 수치로 확인했다. 사용량 패널의 '＞150k context' 플래그는 대화 히스토리·파일·툴 출력물 등 합산된 컨텍스트가 일정 임계를 넘으면 각 턴의 처리 비용이 급증함을 가리키고 작성자는 /compact와 /clear 명령으로 컨텍스트를 줄이는 방안을 권장할 만한 실무적 조치로 제시했다. 조직 계약 유형에 따라 개인별 풀이 독립적인 경우와 사용량 기반 공유 풀이 있는 경우가 있어 팀 차원의 모니터링과 정책 수립이 필요하다.

실용적 조언

긴 작업을 이어갈 때는 동일 스레드에 모든 산출물을 누적하는 대신 주요 전환 시점에 /compact 명령을 사용하여 컨텍스트 길이를 줄이면 각 턴의 처리 비용을 낮출 수 있다. 이 방법은 대화 히스토리와 업로드 파일을 요약해 이전 내용을 압축된 형태로 유지하므로 토큰 수를 줄이는 실질적 수단으로 작동한다. 작성자는 이 명령을 중간 과업에서 활용하는 것을 우선 테스트하려 한다고 명시했다.
작업을 완전히 전환할 때는 /clear 명령으로 세션 상태를 초기화하여 불필요한 과거 컨텍스트가 다음 과제에 끌려가지 않도록 하는 것이 권장된다. 세션을 계속 이어가면 매 요청이 누적된 전체 기록을 다시 처리하는 비용을 유발하므로 작업 구분을 명확히 하면 주간 한도 소모를 억제할 수 있다. 작성자는 자신이 세션을 전혀 지우지 않고 이어간 사례에서 주간 소모가 빠르게 증가했다고 관찰했다.
계정의 사용량 페이지에서 세부 항목을 정기적으로 확인하여 세션 한도, 주간 한도, 그리고 '＞150k context'와 같은 진단 플래그를 주시해야 한다. 개인 플랜과 사용량 기반 엔터프라이즈 플랜은 동작과 책임 범위가 달라서 조직에서는 중앙 모니터링과 경고 설정이 필요하다. 특히 공유 풀을 쓰는 계약에서는 특정 기능이 과다 소모를 유발할 수 있으므로 팀 차원의 소비 정책 마련이 필요하다.

섹션별 상세

작성자는 처음에는 '5시간 후 초기화' 배너를 무심코 넘겨왔으나 급한 작업 중 주간 한도 경고를 보고 처음으로 사용량 페이지를 확인하여 두 개의 별도 한도가 존재함을 확인했다. 세션 한도는 메시지 전송 시점부터 롤링 방식으로 5시간 동안 유효하며 그 기간 내에 과도한 요청을 하면 해당 세션이 차단되는 구조이고 주간 한도는 계정별로 고정된 앵커 시점을 기준으로 7일 단위로 초기화되어 둘 다 100% 미만이어야 정상 사용이 가능하다. 작성자는 자신의 사례에서 세션 사용률은 6%에 불과했지만 주간 사용률이 84%라서 세션 리셋을 기다려도 문제가 해결되지 않았음을 스크린샷과 수치로 근거로 제시했다.

사용자가 화면에서 본 '주간 사용량' 배너 스크린샷으로, 5시간 세션 안내와 별도로 주간 한도 퍼센티지가 표시되어 있다. — Screenshot해당 스크린샷은 사용자 인터페이스 단계에서 세션 한도 안내와 주간 한도 상태를 동시에 노출하는 방식을 보여주며, 배너만 보고는 둘의 차이를 인지하기 어렵다는 점을 시각적으로 증명한다. 이미지에는 개인별 주간 리셋까지 남은 시간과 현재 주간 사용률 수치가 포함되어 있어 사용자가 어떤 한도가 문제인지 빠르게 파악할 수 있다는 진단 단서를 제공한다. 이 화면은 초기 알림만으로는 해결되지 않는 경우가 있어 사용자가 별도 'View Usage'로 들어가 상세 항목을 확인해야 함을 시사한다.

작성자는 '세션'과 '주간' 두 게이트가 모두 통과되어야 하는 동작 원리를 상세히 기술하여 사용자가 단일 한도만 확인하면 오판할 수 있음을 보여주었다. 구체적으로 세션은 짧은 시간 안에 집중적으로 토큰을 소비하면 즉시 영향을 주는 반면 주간 한도는 긴 누적 사용량을 반영하여 일정 시점에 갑작스럽게 접근을 차단할 수 있다는 차이를 명확히 했다. 이 관찰은 작성자가 당일 여러 산출물을 하나의 스레드에 쌓아두면서 발생한 누적 컨텍스트가 실제로 주간 소모를 빠르게 끌어올렸다는 경험적 근거와 맞물려 의미 있는 운영상의 시사점을 제공한다.

사용량 상세 페이지 스크린샷으로 세션·주간 한도 수치와 '＞150k context' 진단 플래그가 표시되어 있다. — Screenshot이 스크린샷은 View Usage 화면에서 각 한도의 실측치와 더불어 최근 사용의 컨텍스트 크기 분포를 보여주며, 특히 모든 사용이 150k 토큰을 넘는 컨텍스트에서 발생했다는 진단 플래그가 강조되어 있다. 화면의 구성은 무엇이 소모를 촉발했는지를 구체적으로 가리키고 있어 사용자가 구체적인 조치(예: 컨텍스트 축소, 세션 초기화)를 취할 근거가 된다. 이 이미지는 글 전체의 핵심 주장인 '긴 컨텍스트가 주간 소모를 빠르게 끌어올렸다'는 점을 시각적 증거로 뒷받침한다.

작성자는 사용량 패널의 진단 문구 가운데 '100% of your usage was at >150k context'라는 항목을 지목하며 컨텍스트 크기가 비용 가중의 핵심 원인이라고 기술했다. 컨텍스트는 대화 히스토리·업로드 파일·툴 출력물 등 모든 입력을 합한 길이이며, 일정 임계값(본문에서 언급된 150k 토큰)을 초과하면 캐싱이 있어도 매 턴 처리 비용이 크게 증가한다고 설명되어 있다. 이 점은 긴 대화 히스토리를 계속 이어가는 워크플로에서 매번 전체 기록을 끌고 가는 방식이 비용과 사용량 관리에 불리함을 증명하는 근거로 작용한다.

작성자는 조직별 플랜 차이에 따른 사용 영향도 명확히 구분했다. 개인용 Individual Pro나 일반 Team/Enterprise의 좌석형 플랜에서는 각 사용자의 사용량 풀이 독립적으로 관리되므로 동료가 내 한도를 소모하지 않는 반면, 사용량 기반 베이스의 Enterprise 계약에서는 조직 전체가 하나의 공유 풀을 쓰기 때문에 다른 구성원의 활동이 내 사용 가능량에 직접 영향을 줄 수 있다고 밝혔다. 작성자는 또한 Claude Code나 Cowork 같은 기능이 공유 풀에서 일반 채팅보다 소모가 크다는 실무적 관찰을 덧붙여서 조직 차원의 모니터링과 정책이 필요함을 시사했다.

용어 해설

롤링 윈도우(Rolling window): — 지정한 기간을 고정된 창으로 계속 이동시키며 사용량을 계산하는 방식으로, 본문에서는 세션 한도가 최초 메시지 전송 시점부터 5시간 동안 유지되는 형태로 구현되어 있어 같은 시간대에 집중 요청을 하면 창이 재설정되기 전까지 추가 요청이 차단될 수 있음을 의미한다.
개인별 고정 주간 리셋 시점(Weekly anchor reset): — 계정별로 고정된 시작점을 기준으로 7일 단위 사용량이 초기화되는 방식으로, 본문에서는 가입 또는 계정 기준의 고정된 앵커 시점이 있어 모든 사용자가 같은 요일·시간에 초기화되지 않는다는 점을 설명한다.
컨텍스트 크기(Context size): — 대화 기록, 업로드한 파일, 툴 출력물 등 모델 호출 시 전달되는 전체 입력 길이를 토큰 기준으로 합산한 값으로, 본문에서는 150k 토큰을 초과하는 세션이 비용과 주간 소모를 급증시키는 주요 원인으로 지목된다.
사용량 기반 엔터프라이즈 플랜(Usage-based Enterprise): — 조직 전체가 하나의 사용량 풀을 공유하고 소비량에 따라 비용이 청구되는 계약 형태로, 본문에서는 이 플랜에서 팀원의 활동이 전체 풀을 소모할 수 있어 개인별 한도와 달리 주의가 필요하다고 언급된다.

언급된 도구

Claude Code중립

코드 관련 작업 및 자동화 기능으로서 Claude 플랫폼 내에서 코드 생성·수정에 사용되는 기능

Cowork중립

협업·작업 공유 관련 기능으로서 조직 단위 사용량에 영향을 줄 수 있는 요소