ChatGPT Plus 쿼터 터져도 작업이 안 멈추게 만들었다 (맥 스튜디오 로컬 LLM fallback)
ChatGPT 쓰다가 “5시간 뒤에 다시 시도하세요” 떠본 적 있으시죠?
한참 몰입해서 작업하는 중에 흐름 끊기면 돌아오기 어려우시죠?
그렇다고 다른 구독을 한 개 더 붙이는 게 정답은 아닌 것 같죠?
ChatGPT Plus 쿼터와 맥 스튜디오 로컬 LLM을 같은 에이전트 안에서 연결했다. 쿼터가 터지는 순간 로컬 gpt-oss:120b로 자동 전환되어 대화가 끊기지 않는다. 이건 “쿼터 우회”보다 넓은 이야기. 상용 AI 서비스의 예측 불가능한 중단에 대비해 자기 기기를 안전망으로 두는 아키텍처 선택이다.
문제의 실체
Plus 쿼터는 gpt-5.4와 gpt-5.4-mini를 공유한다. 실제 로그에서도 두 모델이 같은 시점에 rate_limit로 함께 돌아오는 걸 직접 확인했다. 한 쪽이 막히면? 다른 쪽도 같이 터진다. fallback을 같은 모델 패밀리 안에서만 잡으면 의미가 없다는 뜻. 진짜 fallback이 되려면 쿼터 시스템이 다른 모델을 체인 끝에 둬야 한다.
선택지는 세 개였다.
첫째, 그냥 기다린다. 5시간씩 끊기면서.
둘째, Plus를 해지하고 다른 걸 쓴다. 비슷한 문제가 반복될 가능성.
셋째, 쿼터와 무관한 모델을 fallback 체인 끝에 꽂아둔다.
셋째를 골랐다. 그게 1편에서 벤치마크했던 gpt-oss:120b. 로컬 추론 47 tok/s. Codex보다 느리지만 reasoning 내장, 무엇보다 쿼터가 없다.
원리 먼저 — fallback 체인 설계 원칙
도구 특정 설정으로 들어가기 전에 원리를 적어둔다. 세 층의 역할을 구분해 체인을 짠다.
- Primary: 가장 먼저 시도되는 모델. 가장 빠르고 품질 좋은 옵션. 대부분의 시간 여기서 돈다.
- Mid-tier: Primary 실패 시 다음으로 시도되는 후보. 주의 — Primary와 같은 쿼터 풀이면 의미가 제한적. ChatGPT Plus는
gpt-5.4와gpt-5.4-mini가 쿼터 공유. - 최종 fallback: 모두 실패했을 때 마지막 안전망. 쿼터·네트워크·결제가 Primary와 전부 독립적이어야 한다. 로컬 모델이 이 자리에 가장 적합하다.
이 3층 구조는 fallback 체인을 지원하는 다른 에이전트 프레임워크에서도 비슷하게 쓸 수 있다. 아래는 내가 쓰는 OpenClaw 실전 예시.
실제 설정 (OpenClaw 기준)
요약: Primary에 Codex gpt-5.4, Mid-tier에 gpt-5.4-mini, 최종 fallback에 ollama/gpt-oss:120b를 꽂는다.
OpenClaw는 ~/.openclaw/openclaw.json 하나로 라우팅을 잡는다. agents.defaults.model 섹션에 primary와 fallbacks가 있다.
{
"agents": {
"defaults": {
"model": {
"primary": "openai-codex/gpt-5.4",
"fallbacks": [
"openai-codex/gpt-5.4-mini",
"ollama/gpt-oss:120b"
]
}
}
}
}
체인 흐름은 이렇다. primary(gpt-5.4) → rate_limit → mini로 fallback → 같이 rate_limit → ollama로 에스컬레이트. 맨 뒤에 로컬이 있으면 최악의 상황에서도 뭔가는 대답이 나온다.
같은 파일에 Ollama provider를 등록한다.
{
"models": {
"providers": {
"ollama": {
"baseUrl": "http://127.0.0.1:11434",
"api": "ollama",
"apiKey": "OLLAMA_API_KEY",
"models": [
{
"id": "gpt-oss:120b",
"name": "gpt-oss:120b",
"reasoning": true,
"input": ["text"],
"cost": {"input":0,"output":0,"cacheRead":0,"cacheWrite":0},
"contextWindow": 128000,
"maxTokens": 8192
}
]
}
}
}
}
그리고 에이전트별 auth-profiles.json에 ollama용 엔트리를 추가한다.
"ollama:default": {
"type": "api_key",
"provider": "ollama",
"key": "ollama-local"
}
포맷 주의 두 가지. type은 api_key(하이픈이 아니라 언더스코어), 필드명은 key(not apiKey). localhost라 실제 키 값은 의미 없지만 형식이 맞아야 한다.
작동 확인 로그
실제 쿼터 소진 상황에서 찍힌 로그.
gpt-5.4 → rate_limit (쿼터)
프로필 로테이트 재시도 → rate_limit
에스컬레이트 → gpt-5.4-mini → rate_limit
프로필 로테이트 → rate_limit
에스컬레이트 → ollama/gpt-oss:120b → OK
Plus 쿼터가 완전히 터진 상태에서 로컬이 받아줬다. 응답 정상. 체감 속도는 Codex보다 느리게 느껴진다. 중요한 건? 대화가 끊기지 않는다는 것.
디버깅 노트 — 세션 캐시가 fallback을 먹었다
설정을 제대로 박고 데몬을 재시작했는데도 같은 에러가 반복됐다. 로그를 까보니 원인은 ~/.openclaw/agents/<agent>/sessions/sessions.json. 세션이 과거에 쓴 모델명(gpt-5.4-pro)을 계속 요청하고 있었다.
문제가 복잡한 이유 두 개.
- 세션이 모델을 기억한다. 과거 어느 시점에 fallback이 pro를 거쳐갔고, 그게 세션 상태에 박혔다. 전역 설정을 고쳐도 세션은 옛 값 유지.
- “model not supported” 에러는 fallback을 발동시키지 않는다. OpenClaw는
providerRuntimeFailureKind: unknown으로 분류, rate_limit만 fallback 트리거한다. 세션이 pro를 부르고 거부당하면 그대로 실패.
수정 스크립트.
import json, pathlib
p = pathlib.Path.home() / ".openclaw/agents/ceo/sessions/sessions.json"
d = json.loads(p.read_text())
for sess in d.values():
if isinstance(sess, dict):
if sess.get("model") == "gpt-5.4-pro":
sess["model"] = "gpt-5.4"
for v in sess.values():
if isinstance(v, dict) and v.get("model") == "gpt-5.4-pro":
v["model"] = "gpt-5.4"
p.write_text(json.dumps(d, indent=2))
12개 항목 수정. 데몬 재시작. 텔레그램 세션 테스트에서 fallback 체인이 정상 작동.
일반 교훈: 에이전트 프레임워크의 설정 변경이 진짜 반영되려면 세션 상태까지 확인해야 한다. 설정은 “앞으로 시작될 세션의 기본값”. 실행 중 세션은 자기 상태를 따로 보유한다.
한계와 복귀 전략
솔직한 수치 — 47 tok/s는 Codex의 체감 절반. 짧은 대화는 괜찮고 긴 문서 작성은 답답할 수 있다. 메모리는 gpt-oss:120b가 60GB 이상 쓴다. 64GB 맥이면 다른 앱 병목이 걸릴 여지가 있다. 128GB 기준에서는 편하게 돈다.
복귀는 어떻게 되는가? 쿼터 리셋 시간(보통 5시간 뒤)이 지나면 Primary가 다시 받는다. fallback 체인은 매 요청마다 Primary부터 재시도하므로 자동 복귀. 긴 작업 중간에 로컬로 내려갔다가 Codex로 올라오는 전환도 대화 단위로 자연스럽게 섞인다. 이 부분은 에이전트 프레임워크에 따라 다를 수 있으니 자기 도구의 fallback 재시도 주기를 확인해볼 것.
이번 편의 결론
쿼터 제약은 Primary 모델 쿼터와 독립된 최종 fallback을 체인 끝에 두면 해소된다. “쿼터 우회” 기능이 아니라 의존 리스크 분산 아키텍처로 접근할 것 — 이게 이번 편에서 가져갈 한 줄.
시리즈 다음 편
쿼터 문제는 해결됐다. 에이전트를 길게 돌려보니 진짜 문제는 다른 곳에 있었다. AI가 만들어놓은 결과물을 누가 확인하냐는 것. 코드는 생성했는데 실제로 돌아가는지 아무도 안 본다. 다음 편은 AI가 스스로 결과물을 검증하게 만든 규칙 이야기다.
댓글
댓글 쓰기