GPT 계정이 소진될 때 손으로 갈아타지 않도록 설계한 방법-Hermes Agent Credential Pool과 fill_first로 A → B → 회복된 A 항로를 만든 사례

📝 한줄 요약

“GPT 계정 하나의 사용량이 소진되면 다른 계정으로 자동 전환하고, 그 계정도 소진되면 원래 계정으로 돌아오게 해 달라”는 요청을 ChatGPT 웹 계정 자동 로그인 문제가 아니라 Hermes Agent의 openai-codex Credential Pool 운영 문제로 재구성했다. fill_first 전략과 오류별 cooldown을 공식 문서·현재 구현·실제 CLI로 검증하고 운영가이드를 만들었지만, 검증 환경에는 Codex credential이 1개만 등록되어 있었으므로 실제 2계정 소진 전환은 NOT RUN으로 남겼다.

바쁘시면 이것만 읽어도 됩니다.

• ChatGPT 브라우저 세션을 자동 로그아웃·로그인시키는 방식은 채택하지 않았다.

• Hermes의 Credential Pool은 같은 provider에 여러 OAuth credential을 두고 정상 항목을 선택·회전한다.

• “한 계정을 소진할 때까지 쓰고 다음 계정으로 이동”하려면 round_robin보다 fill_first가 맞다.

• A가 회복되는 순간 정상 B를 강제로 끊는 구조가 아니다. B가 소진되거나 새로 credential을 선택할 때 회복된 A가 다시 우선 선택된다.

• 공식 문서, 현재 코드, CLI surface, 격리된 fill_first 설정 canary와 비밀값 없는 in-memory 선택 canary를 모두 확인했다.

• 두 번째 OAuth 계정 등록, 의도적인 사용량 소진, A → B → A 실전환, Gateway 재시작은 실행하지 않았다.

• 시간·비용 절감 효과는 측정하지 않았으므로 임의의 수치를 만들지 않았다.

🎯 이런 분들께 도움됩니다

• 여러 OpenAI Codex 계정을 합법적인 범위에서 운영하면서 수동 전환을 줄이고 싶은 Hermes 사용자

• ChatGPT 웹 계정과 API·OAuth credential을 같은 것으로 착각하지 않으려는 운영자

• “자동 전환”이라는 요구를 실제 provider·오류·상태 머신으로 바꾸고 싶은 사람

• 설정 파일을 고치기 전에 공식 문서와 현재 구현을 함께 확인하려는 AI 워크스페이스 관리자

• 실행하지 않은 부분을 성공처럼 포장하지 않는 사례 기록이 필요한 사람

😫 문제 상황 — “GPT 계정 두 개”라는 말만으로는 자동화 대상을 정할 수 없었다

출발점은 다음 요청이었다.

지금 GPT 계정 2개가 있는데,
한 계정의 사용량이 소진될 경우 다른 GPT 계정으로 자동으로 바뀌고,
그것이 다시 소진될 경우 다시 원래 계정으로 바뀌도록 스위칭을 자동화하고 싶다.

겉으로 보면 브라우저에서 계정 A를 로그아웃하고 계정 B로 로그인하는 자동화처럼 보인다. 그러나 실제 운영 단위는 세 가지로 갈라진다.

브라우저 세션 자동 전환은 CAPTCHA, 2단계 인증, 세션 보안, 계정 정책 변화에 취약하다. 무엇보다 Hermes가 모델을 호출하는 실행 경로와 브라우저 로그인 상태가 일치한다고 보장할 수 없다.

반면 Hermes의 Credential Pool은 모델 호출 직전 선택되는 credential을 관리한다. 사용량·quota·인증 오류를 감지한 뒤 같은 provider의 다른 정상 credential을 고르는 것이므로, 요청의 실행 단위와 자동화 단위가 일치한다.

그림 1. 실행 증거 카드가 아니라, 실제 소스 폐쇄 receipt에서 파생한 문제 재구성 카드다. 검증 시점의 등록 credential 수는 1개였으며 계정 라벨·토큰은 수집하지 않았다.

🌱 첫 번째 전환점 — 계정을 바꾸는 것이 아니라 “정상 credential을 선택”한다

Credential Pool의 핵심은 계정 이름이 아니라 각 credential의 상태다.

요청
→ 같은 provider의 pool 조회
→ 전략에 따라 정상 credential 선택
→ provider 호출
→ 성공 또는 오류에 따라 상태 갱신
→ 필요하면 다음 정상 credential 선택

공식 문서는 Credential Pool을 같은 provider 안의 회전이라고 설명한다. 모든 credential이 소진된 뒤에야 다른 provider의 fallback이 이어진다. 따라서 다음 두 기능을 구분해야 한다.

• Credential Pool: openai-codex 안에서 A → B

• Fallback provider: Codex pool 전체가 막혔을 때 다른 provider·모델로 이동

이번 요청은 첫 번째 기능이 중심이었다.

🔧 왜 fill_first를 선택했나

Hermes에는 여러 선택 전략이 있다.

공식 문서의 fill_first 설명은 다음과 같다.

Use the first healthy key until it's exhausted, then move to the next.

이를 두 계정으로 바꾸면 다음과 같다.

credential_pool_strategies:
  openai-codex: fill_first

우선순위 1: 계정 A
우선순위 2: 계정 B

현재 구현은 credential을 우선순위로 정렬하고, cooldown이 끝난 항목을 다시 정상 상태로 돌린 뒤 첫 번째 사용 가능한 항목을 선택한다. 따라서 A가 cooldown에서 회복되고 새 선택이 일어나는 시점에는 A가 다시 앞에 온다.

🧭 “원래 계정으로 복귀”의 정확한 의미

여기서 가장 쉽게 과장되는 문장은 “A가 회복되면 자동으로 A로 돌아간다”이다. 이 말은 다음 두 의미로 읽힐 수 있다.

1. A의 제한이 풀리는 시각에 정상 사용 중인 B를 즉시 중단하고 A로 강제 복귀한다.

2. B가 소진되거나 새 세션·새 선택이 일어날 때, 회복된 A가 첫 번째 정상 credential로 다시 선택된다.

기본 Credential Pool이 보장하는 것은 두 번째다.

그림 2. 공식 문서와 현재 선택 로직에서 파생한 상태 머신이다. 실제 두 계정을 소진시켜 캡처한 live 화면이 아니다.

기본 흐름

A 정상
→ A 계속 사용
→ A usage limit 도달
→ A를 cooldown 상태로 표시
→ B 선택
→ B도 소진
→ A가 회복됐으면 A 선택
→ A도 미회복이면 다른 fallback 또는 요청 실패

선제 복귀가 아닌 이유

Credential Pool은 모델 호출 시점에 정상 항목을 선택한다. 별도의 타이머가 정상 B의 실행을 중단시키는 구조가 아니다. 따라서 “A의 reset 시각이 되자마자 무조건 A”가 필요하다면 기본 fill_first와 다른 운영기가 필요하다.

하지만 단지 상태를 지우기 위해 hermes auth reset을 예약 실행하는 것도 안전하지 않다. provider의 실제 제한이 풀리기 전에 로컬 상태만 지우면 같은 credential에서 다시 429가 발생할 수 있다. 수동 reset은 provider 측 회복을 확인한 뒤 사용하는 복구 수단으로 남기는 편이 낫다.

⚙️ 오류별 전환 규칙을 분리했다

“사용량 소진”은 모든 오류를 한 종류로 처리한다는 뜻이 아니다. 현재 공식 문서와 구현을 대조해 다음처럼 분리했다.

provider가 정확한 reset_at을 주면 고정 cooldown보다 그 시각이 우선한다.

🧪 실제로 확인한 것

이번 작업에서는 설명만 쓰지 않고 다섯 층을 따로 확인했다.

1. 최신 공식 문서 원문

Credential Pools 공식 페이지를 다시 읽어 다음을 확인했다.

• same-provider rotation

• fill_first의 첫 번째 정상 항목 우선

• plan·usage limit의 즉시 회전

• 일반 429·402·401의 서로 다른 복구 방식

• provider reset_at 우선

• 모든 pool 항목 소진 뒤 fallback provider 사용

호스팅된 추출 backend가 한 번 402 결제 게이트로 실패했지만, 그 오류를 원문 부재로 해석하지 않았다. 같은 요청을 반복하지 않고 로컬 Trafilatura 경로로 바꿔 공식 페이지 원문과 hash를 보존했다.

2. 현재 Hermes 구현

현재 credential_pool.py에서 다음을 확인했다.

• fill_first가 기본 전략이다.

• credential은 priority 순으로 정렬된다.

• 소진 cooldown이 끝난 항목은 다음 선택에서 정상 상태로 복원된다.

• fill_first는 첫 번째 사용 가능한 항목을 고른다.

• 401은 5분, 429와 기본 오류는 1시간 cooldown이다.

• 폐기된 OAuth는 DEAD 상태로 분리되어 자동 복귀하지 않는다.

3. 실제 CLI surface

다음 명령의 존재와 옵션을 실제 CLI로 확인했다.

hermes auth add openai-codex --type oauth --label "GPT-B"
hermes auth list openai-codex
hermes auth remove openai-codex <번호>
hermes auth reset openai-codex
hermes auth status openai-codex

계정 라벨이 출력될 수 있는 원문은 보존하지 않고 등록 개수만 파싱했다.

4. 격리된 설정 canary

사용자의 실제 설정을 바꾸지 않는 별도 Hermes home에서 다음 명령을 실행했다.

hermes config set credential_pool_strategies.openai-codex fill_first

명령은 종료 코드 0으로 끝났고, 생성된 설정을 다시 읽어 openai-codex: fill_first를 확인했다. 이 검증은 설정 명령과 직렬화가 정상이라는 증거이지, 실제 계정 두 개가 회전했다는 증거는 아니다.

5. 비밀값 없는 in-memory 선택 canary

현재 구현의 선택 의미를 말로만 해석하지 않기 위해, 사용자 계정 대신 dummy A·B 항목을 넣은 메모리 안의 CredentialPool을 실행했다. persistence는 no-op으로 막았고 auth store·설정·네트워크·Gateway에는 접근하지 않았다.

initial_selection: A
after_A_exhaustion: B
after_A_recovery_without_reselection: B
after_B_exhaustion_and_next_selection: A

이 canary는 두 가지를 동시에 확인했다.

• A가 회복됐다는 이유만으로 현재 B가 선제 중단되지는 않는다.

• B가 소진되어 다음 선택이 일어나면 회복된 우선순위 1번 A가 다시 선택된다.

다만 이것은 현재 선택 로직의 in-memory canary다. 실제 OpenAI 계정의 provider 제한과 OAuth 동작을 재현한 end-to-end 시험은 아니다.

🧯 구체적인 실패와 수리 — 문서의 숫자가 서로 달랐다

발행 전 최신 근거를 다시 확인하는 과정에서 작은 문서 drift가 발견됐다.

로컬 문서 한 파일만 믿었다면 운영가이드의 402 대기 시간을 24시간으로 적을 수 있었다. 그러나 현재 공식 웹 문서와 실제 구현이 모두 1시간을 가리켰다. 따라서 이번 글은 다음 우선순위를 적용했다.

현재 공식 웹 문서
→ 현재 실행 구현
→ 로컬 저장소의 오래된 문서 사본

이 사례에서 중요한 것은 1시간이라는 숫자 자체보다 문서·구현·실행 시점이 어긋날 수 있으므로 최종 발행 전에 다시 닫아야 한다는 점이다.

🚧 실제로 실행하지 않은 것

검증 시점에 등록된 openai-codex credential은 1개였다. 두 번째 OAuth 계정 선택은 사용자의 직접 로그인·승인이 필요한 단계이므로 임의로 진행하지 않았다.

그림 3. 실제 검증 receipt에서 파생한 완료 경계다. 18개 근거 assertion은 통과했지만 사용자 2계정 실전환은 실행하지 않았다.

✅ 결과 — 자동화보다 먼저 운영 계약이 생겼다

Before vs After

작성된 운영가이드는 다음을 포함한다.

• 계정 A·B의 device-code OAuth 등록 절차

• 우선순위와 fill_first 설정

• Gateway·새 세션 반영 방법

• 오류별 회전과 cooldown

• 수동 reset·재인증 절차

• 보안·정책·prompt cache 주의사항

• 최종 운영 체크리스트와 명령 모음

Markdown 정본을 Word와 PDF로 변환했고, PDF 6쪽은 한글 깨짐·잘림·표 넘침·불필요한 빈 페이지를 시각 검토했다. 이 산출물은 실행 가능한 운영 절차이지만, 사용자 계정 연결 완료 증명서는 아니다.

🧾 Trace · Proof · Verdict · Repair

Trace

사용자 요구
→ GPT 웹 세션과 Codex OAuth 분리
→ 공식 Credential Pools 문서 확인
→ 현재 구현의 선택·cooldown 로직 확인
→ 비밀값 없는 in-memory A → B → A 선택 canary
→ live CLI 명령 확인
→ 격리 Hermes home에서 fill_first 설정
→ 운영가이드 3종 작성·렌더링 QA
→ 최신 문서 drift 재검증
→ 사례게시글과 증거 카드 작성

Proof

• 공식 원문과 현재 구현 hash 보존

• CLI surface 확인

• 현재 credential 수를 라벨 없이 파싱

• 격리 설정 명령 종료 코드 0

• openai-codex: fill_first read-back

• 근거 assertion 18/18 PASS

• in-memory 선택 canary A → B → 회복된 A PASS

• 데이터 파생 증거 카드 3개 생성·시각 검토

• 미실행 항목을 별도 Gate로 유지

Verdict

operating_design: PASS
guide_package: PASS
isolated_config_canary: PASS
in_memory_selection_semantics_canary: PASS
two_account_registration: NOT_RUN
live_failover: NOT_RUN
chatgpt_browser_switching: OUT_OF_SCOPE

Repair

• “회복 즉시 원래 계정으로 선제 복귀”라는 과도한 해석을 “다음 선택 시 첫 번째 정상 credential로 복귀”로 고쳤다.

• 로컬 문서의 402 cooldown 24시간 표기를 최신 공식 문서·현재 구현의 1시간과 대조했다.

• 실제 2계정 회전을 실행하지 않았으므로 성공 사례가 아니라 검증된 운영 설계 사례로 범위를 낮췄다.

🔐 보안과 정책 경계

1. 두 계정 모두 사용자가 정당하게 사용할 권한이 있어야 한다.

2. 계정 공유, 접근 통제 우회, 약관상 금지된 사용량 회피 수단으로 사용하지 않는다.

3. OAuth 토큰, 이메일, account ID, credential label 원문을 게시글·Slack·Git에 넣지 않는다.

4. auth.json을 직접 편집하지 않고 Hermes의 인증 명령을 사용한다.

5. 사용량 소진을 재현하려고 불필요한 요청을 반복하지 않는다.

6. credential이 바뀌면 provider의 prompt cache가 달라져 긴 대화 문맥을 다시 읽는 비용이 생길 수 있다.

7. 영구 인증 오류는 cooldown이 아니라 재인증 문제로 취급한다.

📋 재사용 가능한 설정 체크리스트

[ ] Hermes 버전과 현재 provider를 확인한다.
[ ] openai-codex credential 목록의 개수만 안전하게 확인한다.
[ ] 계정 A와 B를 서로 다른 OAuth 로그인으로 등록한다.
[ ] A가 우선순위 1, B가 우선순위 2인지 확인한다.
[ ] credential_pool_strategies.openai-codex를 fill_first로 설정한다.
[ ] Gateway 또는 새 세션에서 설정을 다시 읽게 한다.
[ ] usage limit·429·402·401·DEAD 상태를 구분한다.
[ ] provider reset을 확인하기 전 auth reset을 예약하지 않는다.
[ ] 실제 첫 자연 발생 failover의 상태와 로그를 비밀값 없이 기록한다.
[ ] live failover가 확인되기 전에는 “자동 전환 검증 완료”라고 쓰지 않는다.

💬 재사용 가능한 프롬프트

Hermes Agent에서 같은 provider의 OAuth credential 두 개를 안전하게 운영하려고 합니다.

1. 브라우저 웹 계정 전환과 Hermes provider credential 전환을 구분합니다.

2. 현재 provider와 credential 개수를 비밀값 없이 확인합니다.

3. 사용량 소진 시에만 다음 항목으로 이동하도록 fill_first를 검토합니다.

4. 429·402·401·영구 OAuth 오류의 처리와 cooldown을 공식 문서와 현재 구현에서 확인합니다.

5. 실제 설정 변경 전에는 격리된 Hermes home에서 config 직렬화를 canary로 실행합니다.

6. 사용자 인증이 필요한 OAuth 로그인은 임의로 수행하지 않습니다.

7. 설계·CLI·설정 검증과 실제 두 계정 failover 검증을 서로 다른 완료 상태로 보고합니다.

8. 토큰·이메일·credential label·내부 경로는 결과물에 노출하지 않습니다.

🌍 다른 업무에 적용한다면

이 구조는 OpenAI Codex에만 한정된 사고법이 아니다.

• 같은 SaaS의 여러 API key를 운영할 때 우선순위와 cooldown을 분리한다.

• 한 provider 안의 회전과 provider 간 fallback을 따로 설계한다.

• “자동 복귀”가 타이머인지 다음 선택 시점인지 정확히 정의한다.

• 현재 문서와 실제 구현이 다르면 실행 중인 버전을 기준으로 다시 검증한다.

• 사용자의 인증 행위와 에이전트가 자동화할 수 있는 범위를 분리한다.

• 정상 경로보다 모든 항목 소진·영구 인증 실패 같은 경계 상태를 먼저 문서화한다.

🚀 다음 항로

실제 적용은 다음 순서로만 진행하면 된다.

두 번째 OAuth 계정 사용자 로그인
→ credential 2개와 우선순위 read-back
→ fill_first live 설정
→ Gateway 또는 새 세션 반영
→ 자연 발생 usage limit에서 A → B 확인
→ 다음 자연 발생 선택에서 회복된 A 또는 fallback 확인
→ 비밀값 없는 운영 receipt 작성

고의 사용량 소진은 필요하지 않다. 첫 자연 발생 전환을 관찰한 뒤에야 이 사례를 “운영 설계 검증”에서 “실사용 failover 검증”으로 승격할 수 있다.

📚 참고자료

• Hermes Agent 공식 문서 — Credential Pools
  https://hermes-agent.nousresearch.com/docs/user-guide/features/credential-pools