# Claude Code·Codex API 연결 방법 비교: 3가지 경로의 비용과 설정 > Canonical: https://vxi.me/ko/posts/claude-code-codex-api-gateway-comparison/ > Locale: ko-kr > Published: 2026-10-14 > Updated: 2026-10-14 > Markdown: https://vxi.me/ko/posts/claude-code-codex-api-gateway-comparison.md Claude Code나 Codex 구독을 갱신할 때마다 이런 계산을 해본 적 있을 겁니다. Plus 멤버십은 월 20달러인데, 적게 쓰면 아깝고 많이 쓰면 할당량이 부족합니다. 공식 API를 종량제로 쓰자니 청구액에 한도가 없어 부담스럽고, 게이트웨이를 직접 구축해 구독을 한데 모으려면 VPS와 OAuth 설정을 해결해야 합니다. 중계 업체를 찾으면 가격은 저렴하지만, API 키를 남에게 맡겨야 하고 원하는 모델이 실제로 응답하는지도 업체를 믿을 수밖에 없습니다. 실제로 선택할 수 있는 세 가지 경로를 비교해봤습니다. CLIProxyAPI로 보유한 CLI 구독을 호환 API로 변환해 직접 운영하는 방법, OpenRouter 같은 상용 중계 서비스를 통해 종량제로 요청을 전달하는 방법, 모델 제공업체의 공식 API를 직접 이용하는 방법입니다. 결론부터 말하면, 모두에게 가장 좋은 게이트웨이는 없습니다. 자신의 사용량에 맞는 비용 구조를 고르는 게 중요합니다. 사용량이 많고 구독 한도 안에서 안정적으로 쓸 수 있다면 구독을 모아 직접 운영하는 방식이 대체로 가장 저렴합니다. 사용량이 적다면 종량제가 가장 간편하고, 그 중간이라면 VPS를 직접 관리할 의향이 있는지 따져보면 됩니다. 먼저 범위를 분명히 하겠습니다. 이 글은 Claude Code, Codex 같은 AI 코딩 에이전트의 API 공급 경로만 다루며, 범용 LLM 게이트웨이를 전반적으로 비교하지는 않습니다. CLIProxyAPI는 여러 CLI 도구의 구독 인증 정보를 모아 사용합니다. 프로젝트 문서에 따르면 Codex, Claude Code, Gemini CLI, Grok 등을 업스트림으로 지원하고, OpenAI/Gemini/Claude/Codex 호환 인터페이스를 제공합니다. 따라서 범용 게이트웨이와 비교하는 것은 적절하지 않습니다. ## 먼저 비용 계산 기준부터 맞추기 처음에는 기능표부터 만들려고 했지만, 기능이 얼마나 많은지는 ‘돈이 어디에 드는지’에 답해주지 못했습니다. 그래서 비교 기준을 비용 구조, 설정 난이도, 데이터 흐름으로 바꿨습니다. 실제로 경로를 선택할 때 문제를 겪기 쉬운 부분이 바로 이 세 가지입니다. 버전 정보도 결론에 영향을 줍니다. CLIProxyAPI는 릴리스가 잦습니다. 처음엔 GitHub releases의 버전 번호만 확인하면 된다고 생각했지만, Docker Hub의 이미지 태그도 대조해야 했습니다. 양쪽 모두 v8.0.27(2026-10-12 릴리스)을 가리켜야 확인이 끝납니다. 한쪽만 확인하면 오래된 페이지 캐시를 볼 수도 있습니다. 아래에 언급한 버전은 2026-10-14 기준입니다. 직접 설치하기 전에 Docker Hub 태그도 확인하는 습관을 들이는 게 좋습니다. ## 자체 운영: 구독료와 VPS 비용, 비교적 고정된 지출 자체 운영 방식은 ‘무료 API’라기보다 고정 비용을 기준으로 계산하는 편이 정확합니다. 월 20달러부터 시작하는 구독료에 약 5~10달러의 VPS 비용을 더한다고 가정하면, 월 지출은 비교적 일정하고 사용량이 늘수록 비용을 분산하기 쉽습니다. 에이전트를 매일 집중적으로 사용하는 사람에게는 대체로 가장 저렴한 경로입니다. 대신 세 가지를 직접 감당해야 합니다. OAuth 디바이스 코드 인증 과정, VPS의 지속적인 관리, 그리고 업스트림 구독의 이용 제한 리스크입니다. 10월 초 VPS에 배포할 때 OAuth 단계에서 Cloudflare 403과 지역별 타임아웃을 겪었습니다. 확인 결과 게이트웨이 자체 문제가 아니라 구독 측 또는 네트워크 환경 문제였습니다. 당시 배포 과정을 기록한 글도 작성했습니다. OAuth 외 Docker 및 클라이언트 설정은 그대로 따라 할 수 있습니다. [Codex를 CLIProxyAPI로 프록시하는 방법](/posts/cliproxyapi-codex-docker-proxy/). 다만 자체 운영에서는 연결 경로 중 어느 한 곳에서 문제가 생겨도 한밤중에 일어나 해결해야 하는 사람이 바로 본인입니다. ### 대략적인 손익분기점 계산 사용량이 어느 정도여야 종량제보다 직접 운영이 유리할까요? 전제를 분명히 한 대략적인 계산입니다. 정확한 견적은 아닙니다. - **자체 운영 고정 비용**: 월 구독료 $20 + 기본형 VPS 월 $5 ≈ **월 $25로 고정**, 사용량과 상관없이 비용은 같습니다. - **공식 API 종량제 비용**: Sonnet 5.5급 모델(입력 $2 / 출력 $10, 토큰 100만 개당, 서드파티 정리 가격)을 기준으로 하면, 하루 입력 100만 토큰 + 출력 20만 토큰 사용 시 약 $4/일이며 한 달이면 **$120**에 가까워집니다. 손익분기점은 직관적입니다. 매일 토큰을 백만 단위로 사용하는 헤비 유저라면 자체 운영으로 ‘끝없이 늘어나는 비용’을 고정 월 요금으로 제한할 수 있습니다. 반대로 일주일에 몇 번만 터미널을 여는 라이트 유저라면 종량제 비용은 한 달에 몇 달러에 그칠 수도 있습니다. 이 경우 자체 운영은 사용하지 않는 VPS의 월 비용만 더 부담하게 됩니다. 자신의 사용 패턴에 맞춰 선택하면 됩니다. ### 설치 테스트: v8.0.27, 한 번에 성공 이번에는 격리된 테스트 머신(Ubuntu 26.04, 1코어 / 메모리 1.9G)에서 설치 과정을 다시 진행했습니다. 버전은 latest 대신 v8.0.27로 고정했습니다. ```bash docker pull eceasy/cli-proxy-api:v8.0.27 # 292MB，发布页显示 2026-10-12 发布 ``` 최소 설정은 세 줄이면 충분하며, 업스트림을 설정하지 않아도 실행할 수 있습니다. ```yaml # config.yaml config-version: 8 server: port: 8317 ``` ```bash docker run -d --name cpa-test --restart unless-stopped \ -p 8317:8317 \ -v ./config.yaml:/CLIProxyAPI/config.yaml \ -v ./auths:/root/.cli-proxy-api \ eceasy/cli-proxy-api:v8.0.27 ``` 시작 로그에서 버전, Commit, 빌드 시간(v8.0.27 / bf93416 / 2026-10-12)을 확인했고, GitHub main과 일치했습니다. `/`은 200을 반환하고 호환 엔드포인트 세 개를 보여줍니다. 업스트림을 설정하지 않은 상태에서 `/v1/models`이 빈 목록을 반환하는 것도 정상이며 오류가 아닙니다. 테스트 중 확인한 세부 사항 중 두 가지는 튜토리얼에서 분명히 짚어둘 만합니다. 1. **최소 설정에는 기본 인증이 없습니다.** `access.api-keys`을 설정하지 않으면 누구나 게이트웨이를 호출할 수 있습니다. 내부 네트워크에서만 사용할 때는 문제가 없지만, 포트를 인터넷에 공개한다면 가장 먼저 API 키를 설정해야 합니다. 2. **컨테이너에서 호스트에 접속할 때 127.0.0.1을 사용하면 안 됩니다.** 처음에 mock 업스트림을 `http://127.0.0.1:18888`으로 설정했더니 게이트웨이가 connection refused를 반환했습니다. 컨테이너 내부의 localhost는 컨테이너 자신을 가리킵니다. 호스트의 Docker 브리지 주소(보통 172.17.0.1)나 `--network host`을 사용하세요. 게이트웨이 오류 메시지는 꽤 명확합니다. 500 응답에 dial 실패 원인이 그대로 표시돼 문제를 찾기 어렵지 않았습니다. 또한 제 테스트 설정에는 `/health` 엔드포인트가 없어 404가 반환됐습니다. 헬스 체크 스크립트를 작성할 때 일반적인 템플릿을 그대로 복사하지 마세요. ### 게이트웨이 자체 지연은 어느 정도일까? 테스트 결과 약 4ms ‘직접 운영하면 느려지지 않을까?’는 경로를 선택할 때 자주 나오는 질문입니다. 직접 측정해봤습니다. 같은 머신에서 첫 chunk가 일정하게 50ms 지연되는 mock OpenAI 업스트림을 실행하고, mock에 직접 연결하는 경우와 게이트웨이를 거쳐 mock에 연결하는 경우를 각각 streaming 방식으로 20회씩 비교했습니다. | 경로 | 성공률 | 첫 토큰 지연 중앙값 | 첫 토큰 지연 p95 | 총 소요 시간 중앙값 | |---|---|---|---|---| | mock 업스트림에 직접 연결 | 20/20 | 52.4ms | 52.9ms | 104.2ms | | CLIProxyAPI 게이트웨이 경유 | 20/20 | 56.5ms | 57.3ms | 108.7ms | 게이트웨이 자체로 추가되는 지연은 약 4ms였고, p95와 중앙값 차이도 작아 오버헤드가 안정적이었습니다. 결론은 이번 테스트 조건으로 한정됩니다. **같은 머신에서 부하가 낮고 mock 업스트림을 사용하는 경우, 자체 운영 게이트웨이는 병목이 아닙니다.** 체감 속도 저하는 대체로 모델 추론과 업스트림 네트워크에서 발생하며, 프록시 홉이 하나 늘어난 영향은 크지 않습니다. 다만 고동시성이나 복잡한 네트워크 환경에서의 성능은 이번에 측정하지 않았습니다. ![게이트웨이 오버헤드 비교: mock 업스트림 직접 연결과 CLIProxyAPI 게이트웨이 경유의 첫 토큰 지연 중앙값/TTFT p95/총 소요 시간 중앙값(N=20, 동일 머신 테스트), 게이트웨이 자체 오버헤드 약 4ms](/images/posts/claude-code-codex-api-gateway-comparison/gateway-overhead-chart.png) 참고로 사용 중인 상용 중계 서비스(OpenAI 호환)에 직접 연결해 실제 모델 호출도 10회 측정했습니다(gpt-6-luna, 중계 업체 측 모델 식별자이며 모델 지문은 검증하지 않음). 10회 모두 성공했고, 첫 토큰 지연 중앙값은 1240ms, p95는 1996ms, 총 소요 시간 중앙값은 1745ms였습니다. 첫 토큰 지연은 주로 모델 추론 시간에 좌우됩니다. 이 결과도 앞서 설명한 결론을 뒷받침합니다. 게이트웨이의 4ms는 전체 요청에서 체감하기 어려운 수준입니다. 배포 자체는 복잡하지 않습니다. 컨테이너를 실행한 뒤 에이전트가 OpenAI 호환 주소로 서비스에 접속하면 됩니다. 구체적인 엔드포인트와 인증 방식은 사용하는 버전의 문서를 확인하세요. 아래는 호출 측에서 흔히 사용하는 설정 형태입니다. 예시 주소는 자신의 서비스 주소로 바꿔야 합니다. ```python from openai import OpenAI client = OpenAI( base_url="https://your-api.example/v1", api_key="YOUR_API_KEY", ) ``` 처음부터 구축하고 싶지 않다면, 당시 검증했던 배포 스크립트를 원클릭 배포 저장소로 정리해뒀습니다. `setup.sh` 한 번으로 설정을 마칠 수 있습니다. 키를 설정하면 서비스를 실행할 수 있어 시간을 아끼고 싶은 사람에게 적합합니다. kuangyongjie/cliproxyapi-codex-deploy ## OpenRouter: 운영 부담은 적고 종량제로 과금 OpenRouter의 비용 구조는 자체 운영과 정반대입니다. 모델 토큰은 공급업체 가격 그대로 전달하며 추가 마진은 붙이지 않습니다. 플랫폼 수수료는 충전할 때 발생합니다. 신용카드 충전 수수료는 5.5%(최소 0.80달러), 암호화폐 충전 수수료는 5%입니다. 이 수수료는 2026-10 기준 독립 출처 세 곳(betterclaw.io, leanroute.dev, calculatorai.app)을 교차 확인했으며, 모두 같은 기준을 사용했습니다. 실제 요율은 [공식 가격 페이지](https://openrouter.ai/pricing)를 확인하세요. 이 글에서는 2026-10-14에 확인했습니다. 또한 BYOK 모드도 있습니다. 자체 공식 API 키를 연결하면 월 25,000달러의 list-price 사용량까지 플랫폼 수수료가 면제되고, 초과분에는 5%가 부과됩니다(위와 같이 공식 페이지 기준). 세 가지 경로 중 설정이 가장 간단합니다. 가입하고 충전한 다음 OpenAI SDK의 `base_url`을 OpenRouter 주소로 지정하고 모델을 선택하면 됩니다. 공식 문서에서도 OpenAI 호환 엔드포인트와 drop-in 교체를 지원한다고 확인했습니다. 기존 코드는 거의 수정하지 않아도 됩니다. ```python from openai import OpenAI client = OpenAI( base_url="https://openrouter.ai/api/v1", api_key="YOUR_OPENROUTER_API_KEY", ) response = client.chat.completions.create( model="YOUR_MODEL", messages=[{"role": "user", "content": "Hello"}], ) ``` 운영 부담이 줄어드는 대신 요청은 OpenRouter를 거쳐 업스트림 공급업체로 전달됩니다. 플랫폼은 기본적으로 prompt와 completion을 저장하지 않고 메타데이터만 보관하며, 로그는 opt-in 방식으로 활성화할 수 있습니다. 이는 플랫폼 자체의 기본 로그 정책입니다. 요청은 최종적으로 업스트림 공급업체에도 도달하며, 해당 공급업체의 데이터 정책이 적용됩니다. 데이터에 민감한 팀이라면 ‘저장하느냐 마느냐’만 따지기보다 요청이 어떤 업체를 거치는지 확인해야 합니다. 이 원칙은 모든 상용 중계 서비스에 적용됩니다. 상용 중계 서비스의 위험은 구체적으로 설명하되, 확인된 근거와 판단은 구분해야 합니다. 한 연구에서는 재판매 중계 서비스에서 모델 지문이 일치하지 않는 사례를 지적했지만, 원문을 독립적으로 검증하지는 못했습니다. 따라서 여기서는 특정 중국어권 중계 업체를 지목하지 않겠습니다. 더 안전한 방법은 소액으로 먼저 사용해보고, 실제 응답의 모델 지문과 서비스 동작을 확인한 뒤 맞지 않으면 다른 서비스를 선택하는 것입니다. 가격만 강조하고 검증 방법은 언급하지 않는 추천은 경계할 필요가 있습니다. ## 공식 API: 직접 연결을 기준으로 비교 공식 API는 종량제로 과금되며 모델 제공업체에 직접 연결하므로 데이터 경로가 가장 짧습니다. 다른 두 경로를 비교하는 기준이기도 합니다. ‘몇 % 저렴하다’는 홍보 문구에서 기준이 되는 가격은 모두 여기서 출발합니다. OpenAI와 Anthropic의 구체적인 가격은 2026-10 기준 서드파티 정리 자료를 인용했습니다. 초기 비교용으로 참고할 수 있지만 가격 페이지는 자주 바뀝니다. 실제 적용 전에 [공식 가격 페이지](https://openai.com/api/pricing/)와 [Anthropic 가격 페이지](https://www.anthropic.com/pricing/)에서 다시 확인하세요. 변동 가능성이 있는 가격을 장기간 유효한 값처럼 비용 모델에 반영해서는 안 됩니다. 안정성은 실측 수치가 없어도 아키텍처를 보면 먼저 가늠할 수 있습니다. 자체 운영 서비스에는 VPS라는 단일 장애 지점이 하나 더 생기며, 문제가 나면 직접 해결해야 합니다. 상용 플랫폼은 라우팅과 fallback으로 대응할 수 있지만, 실제로 작동하는지는 모델과 장애 유형에 따라 달라집니다. 공식 API는 공급업체가 직접 서비스를 제공합니다. 선택 기준은 간단히 정리할 수 있습니다. 사용량이 많고 VPS를 관리할 수 있으며 구독 관련 이용 제한 리스크를 감수할 수 있다면 자체 운영을 고려하세요. 사용량이 적거나 운영을 원하지 않는다면 OpenRouter가 더 간편합니다. 데이터 경로와 직접 연결이 필수라면 공식 API를 선택하세요. 이 글에서는 세 경로의 실제 가용성을 비교하지 않았으므로, 아키텍처 분석을 uptime 보장으로 받아들여서는 안 됩니다. ## 범위와 제한 사항 이번 실측은 두 가지였습니다. 같은 머신에서 mock 업스트림을 사용해 게이트웨이 자체 오버헤드를 측정한 테스트(N=20, +4ms)와 상용 중계 서비스에 직접 연결해 실제 사용감을 확인한 테스트(사용 중인 중계 서비스, gpt-6-luna, N=10)입니다. **측정하지 않은 항목**은 OpenRouter 및 공식 API의 실제 지연 시간(해당 API 키가 없었음), OAuth 구독 업스트림을 사용한 종단 간 성능(브라우저에서 디바이스 로그인을 완료해야 함), 24시간 이상 연속 사용 시의 안정성입니다. 게이트웨이 오버헤드에 관한 결론은 mock 업스트림을 사용한 결과입니다. 이는 ‘게이트웨이 자체는 느리지 않다’는 점을 보여줄 뿐, ‘사용자의 업스트림도 느리지 않다’는 뜻은 아닙니다. CLIProxyAPI 버전, OpenRouter 수수료, 공식 가격은 변동될 수 있습니다. 위 내용은 2026-10-14 기준으로 확인한 결과입니다. 실제 적용 전에는 프로젝트 릴리스 페이지, Docker Hub 태그, 공식 가격 페이지를 다시 확인하세요. ## 마무리: 세 줄로 정리하는 선택 기준 - **자체 구독 통합을 선택하세요**: 매일 에이전트로 코드를 집중적으로 작성하고, CLI 구독을 이미 보유했으며, 기본적인 Linux 운영 능력이 있고 비용을 고정하고 싶다면 적합합니다. - **OpenRouter를 선택하세요**: 사용량이 적거나 중간 수준이고 변동이 크며, 서버를 관리하고 싶지 않고 여러 모델을 자주 바꿔가며 테스트한다면 적합합니다. - **공식 API를 선택하세요**: 데이터 경로에 관한 규정 준수 요구가 있고 예산이 충분하며 사용량에 따른 비용 변동을 감수할 수 있다면 적합합니다. **관련 링크:** [CLIProxyAPI 프로젝트](https://github.com/router-for-me/CLIProxyAPI) · [원클릭 배포 저장소](https://github.com/kuangyongjie/cliproxyapi-codex-deploy) · [OpenRouter 빠른 시작](https://openrouter.ai/docs/quickstart) · [OpenRouter 가격](https://openrouter.ai/pricing) ## Verification context - Level: first-party - Verified: 2026-10-14T00:00:00.000Z - Environment: Ubuntu 26.04 - Environment: Docker 29.9.0 - Environment: CLIProxyAPI v8.0.27 - Evidence mode: mixed - Evidence receipt: https://vxi.me/evidence/claude-code-codex-api-gateway-comparison.json