🦞 31. Quota 리셋 안 될 때 10분 복구 가이드

Quota reset 알림을 봤는데도 작업이 계속 막히면, 실제로 quota가 영구적으로 안 풀린 경우보다 지금 확인한 범위가 좁았거나, 기존 세션이 예전 상태를 계속 끌고 가는 경우가 더 많다. 특히 채팅 안 /status와 CLI의 openclaw status --usage는 보는 범위가 다를 수 있고, remote mode에서는 로컬이 아니라 gateway host 상태가 기준이 된다.

그래서 이 문제는 오래 추측할수록 더 꼬인다. 가장 빠른 복구 순서는 고정돼 있다. 리셋 시각 확인 → usage 범위 확인 → 살아 있는 세션 확인 → 새 짧은 요청으로 재현 분리. 이 순서만 지키면, 실제 운영에서는 10분 안에 “진짜 quota 부족”인지 “세션 착시”인지 대부분 갈린다.

기본 개념이 먼저 필요하면 07. Quota 기본 구조를 같이 보면 이해가 훨씬 빠르다.

이런 상황이면 바로 이 문서부터 보면 된다

아래 중 하나라도 맞으면, 일단 세게 재시도하지 말고 이 복구 순서부터 타는 편이 낫다.

• 리셋 알림은 왔는데 quota exceeded가 계속 뜬다.
• 일반 대화는 되는데 자동화나 특정 세션만 막힌다.
• 로컬에서는 괜찮아 보이는데 실제 운영 잡은 계속 실패한다.
• 같은 요청을 2~3번 반복했는데 실패 패턴이 그대로다.

flowchart LR
A[Quota 리셋 알림 확인] --> B{지금도 quota exceeded?}
B -- 아니오 --> G[정상 운영]
B -- 예 --> C[openclaw status --usage 확인]
C --> D[openclaw sessions --active 120 확인]
D --> E{새 짧은 요청도 막히는가?}
E -- 아니오 --> H[기존 세션 범위 문제]
E -- 예 --> I[반영 지연 또는 실제 quota 부족]
H --> J[세션 분리 후 재검증]
I --> J
J --> K[짧은 요청 2회 정상 확인]

칠판 치트시트

1. /status 한 번 보고 전체 상태라고 단정하지 않는다
2. openclaw status --usage로 provider 범위를 다시 본다
3. openclaw sessions --active 120으로 살아 있는 세션을 확인한다
4. 긴 작업 대신 새 짧은 요청 1회로 범위를 자른다
5. remote mode면 gateway host 기준으로 다시 판단한다

2분 판별표

지금 보이는 증상	가능성이 큰 원인	첫 확인 포인트
리셋 알림 직후에도 바로 quota exceeded	provider 반영 지연	openclaw status --usage
메인 채팅은 되는데 cron/자동화만 실패	기존 자동화 세션 재사용	openclaw sessions --active 120
로컬 화면은 멀쩡한데 서버 작업만 실패	gateway host 기준 확인 누락	remote mode / gateway 상태
같은 긴 작업만 계속 실패	전체 quota보다 기존 흐름 오염	새 짧은 요청 1회 재현

이 표의 목적은 원인을 완벽히 맞히는 게 아니다. 첫 번째 확인 지점을 빨리 고르는 것이다. 진단이 늦어질수록, 사람은 같은 긴 작업을 다시 던지기 쉽고 그럴수록 원인 분리가 더 어려워진다.

왜 “리셋 안 됨”처럼 보이는데 실제로는 다른 문제인가

공식 Usage tracking 문서 기준으로, 채팅의 /status는 provider usage를 현재 모델 provider 기준으로 보여줄 수 있다. 반면 CLI status의 openclaw status --usage는 provider별 usage 스냅샷을 더 넓게 보여준다.

여기서 첫 번째 착시가 생긴다. 채팅창에서는 막혀 보이는데, 실제로는 특정 provider만 꽉 찼거나 반대로 채팅창이 보고 있는 범위가 더 좁은 경우가 있다.

두 번째 착시는 세션이다. 공식 Session Management 문서에 따르면 세션 상태의 source of truth는 gateway다. 그래서 오래 살아 있던 자동화 세션이나 remote mode 환경에서는, 내 로컬 화면 감각과 실제 운영 상태가 다를 수 있다.

결국 “리셋이 안 됐다”처럼 느껴지는 장면은 보통 아래 셋 중 하나다.

1. 리셋 알림은 왔지만 provider 반영이 몇 분 늦는 상태
2. 특정 세션이 이전 상태를 계속 끌고 가는 상태
3. 로컬이 아니라 gateway host를 봐야 하는데 다른 쪽만 본 상태

10분 복구 순서

1) 먼저 usage 범위를 넓게 다시 확인

openclaw status --usage

이 단계의 목적은 단순하다. “정말 전체 quota가 막혔는지”와 “특정 provider/세션만 문제인지”를 빨리 나누는 것이다.

공식 Usage tracking과 openclaw status 문서 기준으로, /status는 현재 모델 provider 기준 usage를 보여줄 수 있고 openclaw status --usage는 provider별 breakdown을 더 넓게 보여준다. 그래서 둘이 같아 보여야 한다고 가정하면 초반부터 진단이 꼬인다.

이때는 아래 두 가지만 보면 충분하다.

• 지금 쓰는 모델 provider가 실제로 막혀 있는가
• 다른 provider는 괜찮은데 현재 흐름만 막혀 있는가

현장에서는 여기서 이미 절반이 갈린다. /status만 봤을 때는 다 막힌 것처럼 느껴졌는데, openclaw status --usage로 보면 특정 provider만 꽉 찬 경우가 의외로 자주 나온다.

실무 검증 포인트

• --usage에서 목표 provider가 X% left 기준으로 어떻게 보이는지 캡처한다.
• /status와 다르면 “리셋 불능”이 아니라 “표시 범위 차이”로 먼저 본다.

2) 살아 있는 세션을 확인해서 “전체 문제”인지 “기존 흐름 문제”인지 가른다

openclaw sessions --active 120

공식 openclaw sessions 문서 기준으로 openclaw sessions --active 120은 최근 120분 안 active 세션을 분리해서 보는 데 적합하다. 또 공식 Session Management 문서에는 상태의 source of truth가 gateway라고 정리돼 있다. 즉, 이 단계는 “세션이 있느냐”보다 어느 쪽 store가 실제 기준이냐를 확인하는 과정에 가깝다.

이 단계에서는 숫자를 많이 읽기보다, 문제가 난 흐름이 아직 살아 있는지만 확인하면 된다.

특히 아래 장면을 먼저 본다.

• 크론/자동화 세션이 계속 같은 session window를 재사용하는가
• 오래 살아 있는 작업 세션이 반복 실패를 만들고 있는가
• 메인 대화는 정상인데 특정 실행 흐름만 계속 같은 상태를 끌고 가는가

실무 검증 포인트

• 방금 실패한 흐름과 새로 띄운 테스트 흐름을 서로 구분해 설명할 수 있어야 한다.
• 설명이 안 되면 “전체 quota 문제”로 단정하지 말고 세션 범위부터 다시 자른다.

3) 긴 작업을 다시 던지지 말고, 새 짧은 요청으로 재현을 자른다

실패가 났다고 바로 긴 작업을 다시 보내면 원인이 더 흐려진다. 여기서는 진단이 먼저다.

권장 흐름은 아래처럼 짧다.

1. 새 세션 또는 새 대화에서 한 줄짜리 테스트 요청을 던진다.
2. 응답이 오면 기존 세션 범위 문제로 본다.
3. 새 요청도 막히면 provider 반영 지연 또는 실제 quota 부족 쪽으로 본다.

예를 들어 아까 실패한 작업이 “문서 3개 읽고 정리해서 배포”였다면, 다시 그 작업을 보내지 말고 먼저 “한 줄로 현재 상태만 답해줘” 수준으로 잘라본다. 여기서 바로 응답이 오면, 계정 전체 quota보다 기존 흐름이 무거워졌을 가능성이 높다.

이 단계가 중요한 이유는 “계정 전체 문제”와 “기존 세션 문제”를 가장 빨리 가르는 행동이기 때문이다.

실무 검증 포인트

• 새 짧은 요청이 1회 성공했다고 바로 본 작업을 재개하지 않는다.
• 같은 형태의 짧은 요청 2회를 연속 성공시킨 뒤에만 원래 작업으로 돌아간다.

4) remote mode면 로컬 말고 gateway host를 기준으로 판단

공식 Session Management 문서에는 세션 상태가 gateway에 저장된다고 나와 있다. 게다가 기본 daily reset도 gateway host의 로컬 시간 기준 4:00 AM으로 처리된다. 그래서 remote mode에서는 내가 보고 있는 브라우저나 로컬 기기보다 gateway host 상태가 더 중요하다.

이때는 아래 질문을 같이 붙이면 헷갈림이 줄어든다.

• 지금 보고 있는 usage가 gateway host 기준인가
• 실제 문제 세션이 gateway 쪽 store에 아직 살아 있는가
• 로컬에서는 괜찮아 보여도 운영 잡이 붙는 곳은 gateway 쪽 아닌가

이 질문을 빼먹으면 “내 화면에선 되는데 왜 실제 작업은 계속 실패하지?” 같은 착시가 반복된다.

미니 케이스

• 서울에서 브라우저로 상태를 봤을 때는 이미 리셋된 것처럼 보였다.
• 그런데 실제 cron은 다른 호스트 시간/세션 store 기준으로 돌고 있었다.
• 이 경우 사람은 “리셋 안 됨”으로 느끼지만, 시스템 입장에서는 다른 기준을 보고 있었던 것에 가깝다.

현장 미니 사례 3개

사례 A) 07:00 리셋 알림 직후 바로 긴 작업을 돌렸는데 계속 실패

• 상황: 알림을 보자마자 무거운 작업을 다시 실행함
• 실제 원인: 알림 시점과 provider 반영 시점이 약간 어긋남
• 처리: openclaw status --usage로 범위를 다시 보고, 3~10분 안쪽에서 짧은 요청 1회만 재검증
• 정리: “리셋 미적용”이 아니라 “반영 지연”으로 정리됨

사례 B) 채팅은 되는데 cron 자동화만 계속 막힘

• 상황: 메인 대화는 멀쩡한데 예약/자동화 흐름만 실패
• 실제 원인: 계정 전체 문제라기보다 오래 살아 있는 자동화 세션이 같은 상태를 재사용
• 처리: openclaw sessions --active 120으로 active 세션 확인 후 새 흐름에서 재현 분리
• 정리: 전체 장애처럼 보였던 문제가 특정 세션 문제로 축소됨

사례 C) 내 맥북에서는 이상 없어 보이는데 서버 운영은 계속 실패

• 상황: 로컬 UI는 정상처럼 보이는데 실제 작업은 막힘
• 실제 원인: remote mode에서 gateway host 기준 확인이 빠짐
• 처리: gateway host 기준 usage와 session 상태를 다시 확인
• 정리: 로컬 착시와 실제 운영 상태를 분리해 원인 파악

누가, 무엇을, 어떤 순서로 하면 되나

운영자가 실제로는 아래 순서만 따르면 된다.

1. openclaw status --usage로 provider 범위를 확인한다.
2. openclaw sessions --active 120으로 살아 있는 세션을 확인한다.
3. 새 짧은 요청 1회로 기존 세션과 계정 전체 문제를 분리한다.
4. remote mode면 gateway host 기준으로 같은 판단이 맞는지 다시 본다.
5. 짧은 요청 2회가 연속 정상일 때만 본 작업을 다시 붙인다.

즉, 복구 핵심은 “많이 시도하기”가 아니라 범위를 빠르게 자르기다.

이렇게 확인되면 거의 복구다

아래 4개가 맞으면, 실무에서는 대부분 복구 완료로 봐도 된다.

• 새 짧은 요청이 2회 연속 정상 응답한다.
• openclaw status --usage에서 목표 provider가 즉시 다시 꽉 차지 않는다.
• openclaw sessions --active 120에서 문제 세션과 새 세션을 구분해서 설명할 수 있다.
• remote mode라면 gateway host 기준으로도 같은 판단이 나온다.

재발 방지 팁

리셋 시간대에는 아래 운영 습관 하나만 붙여도 재발이 크게 줄어든다.

• 리셋 알림 직후 첫 검사는 긴 작업이 아니라 한 줄 헬스체크로 한다.
• 중요한 자동화에는 “기존 세션 실패 시 새 세션으로 짧게 재검증” 규칙을 넣는다.
• /status와 openclaw status --usage가 같은 범위를 보지 않을 수 있다는 점을 팀 규칙으로 고정한다.
• remote mode 운영자는 로컬 느낌보다 gateway host를 먼저 본다.

한 줄 결론

Quota 리셋이 안 된 것처럼 보일 때는, 실제로는 quota 자체보다 보는 범위와 붙잡고 있는 세션이 어긋난 상태인 경우가 더 많다.
openclaw status --usage → openclaw sessions --active 120 → 새 짧은 요청 1회 순서로 자르면, 대부분 10분 안에 복구 방향이 잡힌다.

내부링크·다음글 연결 (10)

1. 07. Quota 기본 구조
2. 36. Quota 리셋 알림 왔는데 quota exceeded 계속 뜰 때
3. 37. Scheduled reminder 떴는데 액션이 안 이어질 때
4. 서브에이전트 분산운영
5. 32. HEARTBEAT_OK 반복응답 해결
6. 35. 예약 리마인더 중복발송 해결
7. systemd 충돌) 해결
8. 42. cron 시간 바꿨는데 예전 시각에 계속 돌 때
9. 43. cron은 돌았는데 텔레그램 전달이 안 올 때
10. 🚀 OpenClaw 인덱스

다음 추천 읽기: 36. Quota 리셋 알림 왔는데 quota exceeded 계속 뜰 때

※ 이 문서는 생성형 AI를 활용해 작성되었습니다.