Claude Code 'No credential slots' 오류, 한도인 줄 알았는데 아니었다
Claude 호출이 실패하면 요금제부터 올리고 싶어진다. 그 전에 실패가 정말 모델 사용량 문제인지, 내 컴퓨터의 하네스가 쥐고 있는 인증 슬롯이 모두 막힌 것인지 먼저 확인해야 한다. 2026년 9월 15일과 16일, Claude를 쓰는 에이전트 하네스 omo에서 겪은 실패는 로컬 인증 슬롯 단계에서 먼저 드러났다. 15일에는 두 슬롯이 모두 rate-limit로 차단돼 있었고, 16일에는 한 슬롯이 응답하는데도 여러 세션이 슬롯을 나눠 잡아 추가 요청이 막혔다.
이 글은 여러 세션에서 Claude를 돌리다 호출이 막힌 개발자를 위한 확인 순서다. 목표는 결제 여부를 판단하기 전에 오류 문자열, 로컬 슬롯 상태, 실패·성공 시각, 동시 호출 수를 차례로 보고 다음 행동을 고르는 것이다.
먼저 범위를 밝힌다. 아래 오류는 omo 런타임의 인증 슬롯 장애 조치에서 나온 것이다. Claude Code 공식 /usage 화면이나 공식 한도 안내와 같은 오류가 아니고, 9월 기록의 일회성 사례다. 지금 모든 계정에서 같은 일이 생긴다는 뜻도 아니다.
무슨 일이 있었나
2026년 9월 15일, 텔레그램으로 보낸 요청 세 건이 작업 세션에 정상적으로 들어갔다. 그런데 회신은 세 건 모두 요청 처리가 끝났지만 최종 답변을 확인하지 못했습니다였다.
처음에는 텔레그램 연결 문제처럼 보였다. 같은 시각의 인증 상태를 보니 원인은 다른 곳에 있었다. omo의 credential pool에서 Claude용 claude-sdk-oauth 슬롯 두 개가 모두 rate-limit 상태였다. default 슬롯은 15:42:46 KST까지 차단돼 있었고 failureCount는 5였다. account-2 슬롯은 15:31:28까지 차단, failureCount 3이었다.
런타임(Senpi)의 장애 조치 함수 runCredentialFailover는 사용할 수 있는 후보 슬롯이 0개면 No credential slots available을 던진다. 결국 그 폴백 문구는 전송 오류가 아니었다. 모델 호출이 인증 슬롯을 얻지 못해 최종 답변 자체가 만들어지지 않은 결과였다.
1단계: 오류 문자열을 그대로 읽는다
화면에 보이는 마지막 문구만 보면 원인을 잘못 짚기 쉽다. 위 사례에서 사용자에게 보인 것은 "최종 답변을 확인하지 못했다"는 안내뿐이었다. 한도나 결제에 관한 말은 없었다.
같은 문구가 다른 원인을 숨긴 사례도 있다. 2026년 9월 29~30일에 텔레그램 요청 다섯 건이 모두 같은 폴백 안내로 끝났다. 후속 수정 작업에서 세션 기록을 대조하니 다섯 건 모두 세션에는 도착해 있었다. Claude 인증 차단은 그중 한 건뿐이었고, 나머지 네 건은 로드된 런타임에서 OpenAI 쪽 모듈을 찾지 못한 오류(Cannot find module .../openai-codex-responses-*.js)였다.
그래서 첫 단계는 안내 문구가 아니라 세션 기록과 런타임 로그에 남은 원래 오류 문자열을 찾는 것이다. 이번 기록에서 인증 슬롯 문제를 가리킨 문자열은 두 가지였다.
No credential slots available: 쓸 수 있는 슬롯 후보가 0개.All Claude accounts ... blocked: 등록된 Claude 계정 슬롯이 모두 막힘.
둘 다 Claude 쪽에서 보낸 요금제 안내가 아니라 로컬 하네스가 슬롯을 고르지 못했다는 신호다.
2단계: 로컬 슬롯 상태를 본다
omo는 Claude 인증 슬롯 상태를 ~/.omo/agent/credential-pool-state.json에 둔다. 당시 claude-sdk-oauth 슬롯은 default, account-2 두 개뿐이었다. 파일 원문은 자격증명 정보가 섞일 수 있으니 공유하지 말고, 슬롯별로 아래 항목만 옮겨 적는다.
- 차단 사유(blockReason): 예를 들어
rate_limit. - 차단 해제 예정 시각.
- failureCount.
- 마지막 성공 시각(lastSuccess).
- 리스 보유 여부: 지금 어떤 세션이 그 슬롯을 쥐고 있는지.
9월 16일 14:32 기준으로 기록된 값은 이랬다. default는 failureCount 8, 차단 사유 rate_limit, 기록된 해제 시각 9/15 23:36이었고 리스를 쥐고 있었다. account-2는 lastSuccess가 14:30으로, 실제로 응답하고 있었다.
여기서 볼 점은 "Claude가 막혔다"가 한 문장으로 정리되지 않는다는 것이다. 한 슬롯은 실패가 쌓인 채 리스를 쥐고 있었고, 다른 슬롯은 2분 전에도 성공했다. 계정 전체의 사용량이 바닥났다는 판정을 내릴 상태가 아니었다.
3단계: 실패 시각과 성공 시각을 맞춘다
슬롯 값을 읽었으면 내 요청이 실패한 시각과 나란히 놓는다.
- 실패 시각이 모든 슬롯의 차단 구간 안에 있으면 당시 쓸 수 있는 슬롯이 없었던 것이다. 9월 15일 사례가 그랬다. 두 슬롯 모두 15시대에 차단 중이었다.
- 실패 시각 근처에 다른 슬롯의 성공 기록이 있으면 슬롯 하나가 아직 살아 있다. 9월 16일 14:32의
account-2처럼, 계정을 늘리거나 요금제를 바꾸기 전에 왜 그 요청이 살아 있는 슬롯을 받지 못했는지부터 봐야 한다.
차단 해제 시각이 지났다고 바로 정상이라고 보지도 않는다. 위 default 슬롯은 기록상 해제 시각이 지난 뒤에도 failureCount가 8까지 쌓인 채 리스를 쥐고 있었다. 해제 시각 하나만 보지 말고 failureCount, lastSuccess, 리스를 함께 읽는다.
4단계: 동시에 몇 세션이 Claude를 잡고 있는지 센다
9월 16일 기록의 결론은 이렇다. 슬롯은 두 개뿐인데 여러 세션이 동시에 Claude 슬롯을 잡으면, 추가 요청은 All Claude accounts ... blocked로 실패한다. 같은 시각 슬롯 제약이 없는 openai-codex 레인에서 돌던 작업은 영향을 받지 않았다.
그러니 마지막 확인은 지금 Claude를 호출하는 세션이 몇 개인지 세는 것이다. 슬롯 수보다 동시 세션이 많으면 요금제를 올려도 같은 하네스 안의 자리 다툼은 그대로 남을 수 있다.
판정과 다음 행동
| 확인 결과 | 다음 행동 |
|---|---|
원래 오류가 No credential slots available 또는 All Claude accounts ... blocked이고 모든 슬롯이 차단 구간 | 차단 해제 시각이 지난 뒤 새 요청을 보낸다. |
| 슬롯이 막혔지만 기다릴 수 없는 작업 | 다른 제공자 모델로 전환해 처리한다. 당시 기록에 남긴 복구 방법 중 하나다. |
| 슬롯 수보다 동시 Claude 세션이 많음 | 동시에 Claude를 쓰는 세션 수를 줄인다. |
| 한 슬롯은 막혔지만 다른 슬롯이 최근 성공 | 결제 판단을 미루고 요청이 살아 있는 슬롯을 받지 못한 이유를 먼저 본다. |
| 원래 오류가 인증과 무관(예: 모듈을 찾지 못함) | 슬롯이나 요금제가 아니라 그 오류부터 고친다. |
한 가지 더 있다. 이미 실패한 요청은 슬롯이 풀려도 같은 작업 흐름에서 자동으로 다시 실행되지 않았다. 당시에는 새 메시지를 보내야 했다. 9월 30일에는 답변이 늦게 오는 요청에 폴백을 서둘러 보내지 않도록 브리지를 고쳤다. 답변 없이 작업이 끝나면 4~7초 만에 폴백을 보내던 흐름을 90초 답변 마감 뒤에만 폴백하도록 바꿨고, 전체 테스트 44개가 통과했다.
이 기록으로 답하지 않는 것
이 절차는 로컬 하네스의 슬롯 상태를 판별할 뿐이다. 다음 질문에는 이 기록으로 답하지 않는다.
- Claude Code 공식
/usage화면의 수치나 공식 한도 오류의 의미. - 공식 주간 리셋 시점.
- 요금제를 바꿨을 때 할인이나 비용 절감률.
동시 세션을 줄여도 모든 슬롯이 rate-limit로 반복해서 막히거나, 슬롯 상태가 정상인데도 공식 한도 안내가 보인다면, 그때가 요금제와 실제 비용을 비교할 시점이다. 그 비교는 Claude Code 요금제와 실제 비용: Pro·Max·Team, API 종량제는 언제 더 쌀까?에 정리했다. 비용이 어디서 새는지부터 보려면 AI 코딩 도구 비용은 어디서 새는가를, 한 제공자가 막혀도 작업이 이어지게 하려면 3층 LLM fallback 체인을 이어서 보면 된다.
결론: 돈을 내기 전에 자리부터 센다
9월 기록에서 Claude 호출 실패는 로컬 인증 슬롯 두 개가 모두 rate-limit로 차단되거나 여러 세션에 점유돼 쓸 슬롯이 없던 결과였다. 같은 폴백 안내가 전혀 다른 오류를 가리킨 날도 있었다. 그래서 결제 화면을 열기 전에 원래 오류 문자열, 슬롯 상태, 실패·성공 시각, 동시 세션 수를 이 순서로 확인한다. 슬롯 다툼이나 다른 오류가 아닌데도 rate-limit 차단이 반복될 때 비로소 요금제 비교가 의미 있다.
댓글
댓글 쓰기