에러 메시지보다 더 최악인 특정한 종류의 방해가 있습니다. 바로 디버깅 스레드, 리팩터링 (refactor), 또는 장시간 실행되는 에이전트 (agent) 작업 중간에 발생하는 방해입니다.

많은 Codex 사용자들에게 그 방해에는 이름이 있습니다. 바로 순환하는 5시간 사용량 제한 (rolling five-hour usage window)입니다.

Codex 관련 논의를 살펴보면 불만 사항이 놀라울 정도로 일관적입니다. 개발자들은 5시간의 작업 블록보다 훨씬 빨리 소진될 수 있는 제한, 집중하려고 노력하는 동안 계속 지켜봐야 하는 짧은 창의 미터기 (short-window meter), 그리고 에디터에서 보이는 작업과 연관 짓기 어려운 할당량 (quota) 계산 등을 언급합니다. 좌절감은 단순히 사용량이 유한하다는 점 때문만이 아닙니다. 실제 소프트웨어 작업은 폭발적으로 일어나는 특성 (bursty)이 있기 때문입니다. 어려운 버그 하나를 잡기 위해 집중력을 유지하며 방해받지 않는 오후 시간을 보내야 할 수도 있지만, 그다음 이틀 동안은 사용량이 거의 없을 수도 있습니다.

에이전트 기반 작업 (agentic work)에서는 그 고통이 더 심합니다. 겉보기에는 작아 보이는 작업이라도 저장소 탐색 (repository exploration), 도구 호출 (tool calls), 리뷰 (reviews), 재시도 (retries), 그리고 하위 에이전트 (subagents)를 포함할 수 있습니다. 짧은 사용 제한이 구속 조건 (binding constraint)이 되면, 실질적인 질문은 _"다음 단계로 무엇을 하는 것이 가장 좋을까?"_에서 _"에이전트를 계속 실행할 여유가 있을까?"_로 바뀌게 됩니다.

이는 결코 바람직한 작업 방식이 아닙니다.

저는 사용량 제한을 극복해야 할 대상으로 취급하고 싶지 않았습니다. 그것은 제가 비용을 지불하고 사용하는 서비스의 일부입니다. 저는 제가 정당하게 사용하는 계정 및 OpenAI 호환 제공업체 (OpenAI-compatible providers)들과 더 나은 방식으로 작업하고 싶었습니다. 즉, 그들의 상태와 남은 할당량을 확인하고, 의도적으로 선택하며, 예측 가능한 401, 429 에러 또는 제공업체 소진으로 인해 세션을 잃는 일을 피하고 싶었습니다.

그래서 저는 Codex Conduit을 만들었습니다.

이것은 Codex CLI, Codex App, 그리고 지원되는 IDE 통합을 위한 로컬 데스크톱 게이트웨이 (local desktop gateway)입니다. 이 도구는 사용자의 로컬 머신에 구성된 계정과 제공업체를 통해 요청을 라우팅(route)하고, 중요한 상태를 노출하며, 현재 경로가 요청을 처리할 수 없을 때 다른 정상적인 경로로 장애 조치 (fail over)를 수행할 수 있습니다.

로컬 게이트웨이에서 원했던 것

제 목표는 로그인 파일을 다시 쓰고 모든 것을 재시작하라고 요구하는 또 다른 계정 전환기가 아니었습니다. 제가 원한 것은 로컬 Codex 트래픽을 위한 제어 평면 (control plane) 이었습니다:

• ChatGPT 구독 계정, OpenAI API 키, 그리고 OpenAI 호환 제공업체 (OpenAI-compatible providers)를 한곳에서 관리합니다.
• 상위 서비스 (upstream)에서 정보를 제공하는 경우 5시간 및 주간 할당량 (quota)을 보여주며, 제공업체의 잔액 및 계정 상태를 표시합니다.
• 현재의 Codex 워크플로우를 의도적으로 중단하지 않고도 경로 (routes)를 전환합니다.
• 401, 429 및 할당량 소진을 라우팅 신호 (routing signals)로 취급하여, 정상적이고 허용된 경로로 이동합니다.
• 무료, 릴레이 (relay), 유료 플랜 또는 제3자 경로가 자동 선택에 참여할지 여부를 직접 제어합니다.
• 게이트웨이 사용을 중단하면 원래의 Codex 설정을 복구합니다.

이것이 Codex Conduit의 역할입니다. 즉, 무제한 사용을 보장하는 것이 아니라 로컬 라우팅 계층 (routing layer) 역할을 하는 것입니다. 모든 경로는 여전히 각자의 약관, 할당량 및 비용이 적용됩니다.

설정 방법

1. 데스크톱 앱 다운로드

Codex Conduit Releases page에서 제 플랫폼에 맞는 설치 프로그램을 다운로드했습니다. 현재 릴리스 자산에는 macOS 및 Windows 빌드가 포함되어 있습니다.

처음으로 프록시 (proxy)를 활성화하기 전에, 실행 중인 Codex CLI 및 Codex App 프로세스를 종료했습니다. 이렇게 하면 설정 인계 (configuration handoff)를 예측 가능하게 만들 수 있습니다.

2. 사용 권한이 있는 계정 추가

앱에서 + Sign In을 클릭하고 브라우저에서 공식 OpenAI OAuth 흐름을 완료했습니다. Codex Conduit은 OpenAI 비밀번호를 요구하지 않습니다. 인증은 OpenAI의 인증 페이지에서 이루어집니다.

이미 사용 중인 OpenAI 호환 제공업체(provider)의 경우, + Add Third-Party Provider를 클릭하고 제공업체 세부 정보를 선택하거나 입력한 뒤, 본인의 API 키를 제공했습니다. 이 앱은 /v1/responses 또는 /chat/completions와 호환되는 업스트림(upstream)을 노출하는 제공업체를 지원합니다.

여기서 중요한 규칙은 간단합니다. 본인이 소유하거나 운영할 명시적인 권한이 있는 계정 및 API 자격 증명(credentials)만 추가하십시오.

3. 상태 및 잔여 용량 확인

Accounts 페이지에서 현재 경로(route), 계정 유형, 사용 가능한 할당량(quota) 또는 잔액, 상태(health state), 그리고 마지막 갱신 시간을 확인할 수 있었습니다.

이 화면은 자동화가 도입되기도 전에 저의 행동 방식을 바꾸어 놓았습니다. 작업을 시작한 후에야 경로가 소진되었다는 사실을 깨닫는 대신, 어디서 작업을 시작할지 미리 결정할 수 있게 되었습니다.

4. 로컬 프록시(Local Proxy) 활성화

다시 대시보드(Dashboard)로 돌아가 Local Proxy를 켰습니다.

Codex Conduit은 ~/.codex/config.toml 파일을 config.toml.mybak로 백업하고, 로컬 프록시 설정을 작성한 뒤 게이트웨이를 시작합니다. UI에 Proxy ON이 표시되면, 향후 요청이 로컬 경로를 사용하도록 Codex CLI, Codex App 또는 관련 IDE 통합 도구를 재시작합니다.

나중에 프록시를 끄면 게이트웨이가 중단되고 이전 Codex 설정을 복구하려고 시도합니다. 저는 경로를 변경할 때마다 설정 파일을 수동으로 편집하는 대신, 이러한 가역적인(reversible) 설정을 선호합니다.

5. 요행을 바라는 대신 라우팅 정책 선택하기

Settings > Background Services에서 어떤 경로가 자동 전환(automatic switching)에 참여할 수 있는지 선택했습니다.

제가 선택한 보수적인 초기 정책은 다음과 같습니다:

• 제가 비용 및 데이터 처리 약관을 명시적으로 수락하지 않는 한, 제3자 경로(third-party routes)가 자동 선택되는 것을 방지합니다.
• 현재의 제3자 경로가 실패할 경우, 상태가 양호한 구독 계정으로 폴백(fallback)할 수 있도록 허용합니다.
• 제가 의도적으로 해당 할당량(quota)을 사용하고자 하는 경우가 아니라면, 무료 계정은 로테이션에서 제외합니다.

신중하게 승인된 계정 및 제공자 풀(pool)을 운영하는 사람들에게는 정책을 더 넓게 설정할 수 있습니다. 핵심은 정책이 명시적이어야 한다는 것입니다. 즉, 비용에 민감한 경로가 조용히 기본값(default)으로 설정되지 않도록 하는 것입니다.

경로가 실패할 때 발생하는 일

Codex Conduit은 Codex와 설정된 업스트림(upstreams) 사이에서 로컬로 실행됩니다:

Codex CLI / Codex App / 지원되는 IDE
                 |
                 v
...

게이트웨이가 인증 실패, 속도 제한(rate limit), 또는 할당량 소진(quota-exhaustion) 응답을 감지하면, 정책에 따라 허용된 다음의 정상적인 경로를 선택할 수 있습니다. 이것이 제공자의 제한을 없애거나 사용할 수 없는 서비스를 사용 가능하게 만들 수는 없습니다. 하지만 작업 도중에 실패 원인을 진단하고, 경로를 선택하고, 설정을 변경하고, 재시작해야 하는 수동 작업을 줄여줍니다.

로컬 대시보드를 통해 결정 과정을 시각적으로 확인할 수도 있습니다. 이는 매우 중요한데, 자동화된 라우팅(routing)은 특히 경로마다 할당량이나 가격이 다를 때 반드시 검사 가능(inspectable)해야 하기 때문입니다.

이것이 나에게 도움이 된 이유

5시간이라는 제한은 여전히 개별 구독 경로에 존재하는 제약 사항입니다. Codex Conduit은 이를 부정하지 않습니다.

변화된 것은 운영 경험(operational experience)입니다:

• 긴 작업을 시작하기 전에 발생할 가능성이 높은 제약 사항을 미리 확인할 수 있습니다.
• 승인된 나만의 경로들을 하나의 데스크톱 앱에서 체계적으로 관리할 수 있습니다.
• 예측 가능한 실패가 설정상의 비상 사태로 이어지지 않아도 됩니다.
• 안정성 우선 정책과 비용 우선 정책을 분리할 수 있습니다.
• 게이트웨이가 더 이상 필요하지 않을 때는 이를 끄고 이전의 Codex 설정을 복구할 수 있습니다.

저에게 이것은 사용량을 계속 감시하는 시간을 줄이고, 실제 엔지니어링 문제에 더 많은 시간을 할애할 수 있음을 의미합니다.

직접 사용해 보시고, 무엇이 잘못되는지 알려주세요

Codex Conduit는 오픈 소스(open source)이며 GitHub에서 확인할 수 있습니다:

https://github.com/cherrylfrei-max/codex-conduit

만약 Codex를 집중적으로 사용하신다면, 특히 다음 세 가지 사항에 대한 피드백을 부탁드리고 싶습니다. 어떤 할당량(quota) 신호가 가장 유용한지, 어떤 제공업체(provider) 장애 조치(failover) 케이스에 더 나은 처리가 필요한지, 그리고 에이전트(agent)가 실행되는 동안 라우팅(routing) 상세 정보가 어느 정도까지 보여야 하는지입니다.

여러분의 워크플로(workflow)에서 5시간 제한 중 가장 흐름을 방해하는 부분은 무엇인가요? 제한 그 자체인가요, 예측 불가능성인가요, 아니면 작업이 이미 진행 중일 때 발생하는 중단인가요?