OpenCode를 로컬 게이트웨이로 실행하여 작업 중 레이트 리밋 문제 해결하기
Running OpenCode through a local gateway so rate limits stop killing mid-task
핵심 요약
OpenCode 사용 시 발생하는 API 레이트 리밋 문제를 해결하기 위해 Bifrost 게이트웨이를 활용한 다중 공급자 라우팅 구축 경험 공유.
- 레이트 리밋 해결 — 여러 AI 공급자를 게이트웨이로 묶어 요청을 분산함
- Bifrost 활용 — Go 바이너리 기반의 가벼운 로컬 게이트웨이로 설정 관리함
- 작업 중단 방지 — 공급자 429 에러 발생 시 자동으로 다른 공급자로 전환함
- 효율적 모델 관리 — 여러 공급자를 설정하여 복잡한 작업 시 중단 없이 수행함
[블록 1/6] 저는 꽤 오랫동안 OpenCode를 사용해 왔고, 아주 만족하고 있습니다. Claude Code나 Codex의 구독 비용은 저에게는 그다지 합리적이지 않아서, OpenCode의 무료 티어를 선호합니다. OpenCode Zen 덕분이죠!
[블록 2/6] 하지만 계획을 세우고 초안을 작성할 때는 성능 좋은 모델이 필요한데, 저는 Zenmux나 비슷한 제공업체에서 모델을 가져와 사용합니다. 그런데 이런 곳들은 레이트 리밋이 매우 심합니다. 작업을 거의 다 끝낼 때쯤 리밋에 걸리면, 작업을 멈추고 설정을 열어 제공업체를 바꾸고, 재시작한 뒤 중단된 지점부터 다시 시작해야 했습니다. 복잡한 작업 하나당 세네 번씩은 이런 일이 발생했죠. 할당량을 잃는 것도 짜증 나지만, 작업 흐름이 끊기는 게 더 최악이었습니다.
[블록 3/6] 그래서 제가 내린 결론은 모든 것 앞에 게이트웨이를 두고, OpenCode가 특정 제공업체가 아닌 그 게이트웨이를 바라보게 하는 것이었습니다. OpenCode 설정에는 베이스 URL 하나만 넣고, 라우팅은 그 뒤에서 처리되도록 하는 거죠. 한 제공업체에서 429 에러가 나면, 여유가 있는 다음 제공업체로 요청이 넘어갑니다.
[블록 4/6] 처음에는 LiteLLM을 시도했습니다. 잘 작동하고, 이미 파이썬 스택을 사용 중이라면 더 명확한 선택지일 겁니다.
[블록 5/6] 하지만 최근에 Bifrost를 알게 되어 LiteLLM에서 갈아탔습니다. 제 환경에 딱 맞았던 이유는 별도의 데이터베이스 서비스 없이 로컬 SQLite 설정 저장소를 사용하는 단일 Go 바이너리였기 때문입니다. 현재 9개의 제공업체를 설정해 두고 그 사이에서 폴백(fallback)이 작동하도록 해두었는데, 이 부분이 실제로 중단 문제를 해결해 주었습니다.
[블록 6/6] 혹시 같은 문제로 고생하는 분들에게 도움이 될까 싶어 공유합니다. 여기까지 오는 데 시간이 좀 걸렸네요.
