새로운 설정 없이 Qwen과 OpenRouter를 Claude Code 및 Codex에 연결하기

모든 새로운 모델 제공자(model provider)는 실제 코딩 도구에 도달하기 전까지는 단순해 보입니다.

Qwen은 DashScope의 OpenAI 호환 모드(OpenAI-compatible mode)를 가지고 있습니다. OpenRouter는 방대한 모델 목록에 대해 하나의 API를 제공합니다. 둘 다 AI 코딩 워크플로우(AI coding workflow)에 쉽게 연결될 것처럼 들립니다.

하지만 도구들은 "OpenAI 호환"이 "내가 사용하는 모든 것과 호환됨"을 의미하지는 않는다는 사실을 상기시켜 줍니다.

Claude Code는 Anthropic Messages를 기대합니다. Codex는 Responses 형태(shape)를 기대합니다. 다른 클라이언트들은 Chat Completions를 사용합니다. 제공자가 완벽하게 좋은 API를 가지고 있더라도, 여전히 베이스 URL(base URLs), API 키(API keys), 모델 별칭(model aliases), 그리고 작은 래퍼 스크립트(wrapper scripts)를 다시 설정해야 하는 상황에 직면하게 됩니다.

그것이 바로 제가 피하고 싶었던 부분이었습니다.

짜증 나는 부분은 API 키가 아니었습니다

키를 하나 더 추가하는 것은 쉽습니다.

혼란은 모든 도구가 제공자 결정권을 가지려고 할 때 시작됩니다.

저렴한 코딩 작업을 위해 Qwen을 시도해보고 싶다면, Claude Code의 환경 변수를 수정하고, 그다음 Codex의 설정을 수정하고, 다시 채팅 클라이언트의 모델 목록을 수정하고 싶지 않습니다. 만약 anthropic/claude-3.7-sonnet과 같은 OpenRouter 모델 슬러그(model slug)를 테스트하고 싶다면, 라우팅 계층(routing layer)이 생소해 보인다는 이유로 실수로 이를 다시 매핑(remap)하는 것을 원치 않습니다.

제가 원했던 형태는 더 단순했습니다:

도구들은 계속 localhost를 가리킵니다.
제공자(providers)는 한 번만 추가됩니다.
모델 이름은 한 곳에서 매핑되거나 그대로 전달됩니다.
프로토콜 변환(protocol conversion)은 게이트웨이(gateway) 뒤에서 일어납니다.

따라서 최신 CliGate 변경 사항은 Qwen과 OpenRouter를 일회성 설정 뭉치로 만드는 대신, 제공자 프리셋(provider presets)으로 추가합니다.

해결책은 맞춤형 제공자가 아닌 프리셋이었습니다

CliGate는 이미 AI 코딩 도구들을 위한 로컬 컨트롤 플레인(local control plane)으로 작동하고 있습니다. Claude Code, Codex CLI, Gemini CLI, OpenClaw, 그리고 OpenAI 호환 클라이언트들이 하나의 로컬 서버를 가리킬 수 있으며, CliGate가 자격 증명(credentials), 라우팅(routing), 로그(logs), 그리고 모델 매핑(model mapping)을 관리합니다.

Qwen과 OpenRouter의 흥미로운 점은 둘 다 OpenAI Chat 스타일의 제공자라는 것입니다. 이는 새로운 제공자 정의가 대부분 데이터로 이루어질 수 있음을 의미합니다:

{
  id: 'qwen',
  apiFormat: 'openai_chat',
...

OpenRouter도 동일한 처리를 받지만, 한 가지 중요한 규칙이 있습니다: /를 포함하는 모델 ID는 네이티브 모델 슬러그 (model slugs)로 그대로 통과됩니다. 만약 제가 openai/gpt-4o-mini 또는 qwen/qwen-2.5-72b-instruct를 요청한다면, CliGate는 더 잘 안다고 자처하며 이를 일반적인 티어 (tier)로 재매핑해서는 안 됩니다.

이 작은 규칙이 중요한 이유는 OpenRouter가 단일 모델 제품군이 아니라 하나의 카탈로그 (catalog)이기 때문입니다.

프로토콜 브리지 (protocol bridge)가 진정한 기능입니다

제공자 프리셋 (provider preset)은 이야기의 절반에 불과합니다.

Qwen과 OpenRouter는 채팅 완성 (Chat Completions) API를 노출합니다. 하지만 Claude Code는 채팅 완성 방식을 사용하지 않습니다. Codex는 응답 (Responses) 호환 경로를 통해 진입할 수도 있습니다. 따라서 게이트웨이는 이제 이러한 제공자들을 채팅 네이티브 업스트림 (chat-native upstreams)으로 취급하고, 이를 중심으로 도구 지향적 프로토콜들을 브리지 (bridge)합니다.

Claude Code의 경우, CliGate는 Anthropic Messages를 OpenAI Chat으로 변환하여 Qwen 또는 OpenRouter로 요청을 보낸 다음, 답변을 다시 Anthropic 스타일의 메시지로 변환합니다. 도구 호출 (tool calls)과 도구 결과 (tool results)는 이 변환 과정에서 보존됩니다.

Codex의 경우, CliGate는 이러한 제공자들이 네이티브 /responses 엔드포인트를 가지고 있는 척하지 않도록 의도적으로 설계되었습니다. 네이티브 응답 (Responses) 지원을 비활성화 상태로 두어, 기존의 응답-채팅 폴백 (Responses-to-Chat fallback)이 대신 채팅 완성 (Chat Completions)을 통해 요청을 처리하도록 합니다.

이러한 디테일은 가장 좋은 의미에서 지루합니다. 도구들은 각자의 프로토콜을 계속 사용합니다. 제공자는 자신이 실제로 지원하는 API만 지원하면 됩니다.

현재 설정 방식

사용자 대상 설정은 의도적으로 매우 간단합니다:

npx cligate@latest start
# API Keys에 Qwen 또는 OpenRouter 키를 추가하세요
# Claude Code와 Codex가 localhost:8081을 가리키도록 유지하세요

그 이후의 라우팅 (routing)은 CliGate 내부에서 일어날 수 있습니다. Qwen은 저렴한 fast 또는 standard 티어를 채울 수 있습니다. 특정 업스트림 모델 슬러그를 시도하고 싶을 때는 OpenRouter를 사용할 수 있습니다. 기존의 OpenAI, Anthropic, Gemini, Azure OpenAI, DeepSeek, Vertex 및 로컬 경로들은 동일한 대시보드에 그대로 유지될 수 있습니다.

어떠한 CLI도 어떤 제공자가 라우팅에서 승리했는지 알 필요가 없습니다.

이것이 왜 또 다른 설정 파일보다 더 좋게 느껴지는가

주요한 이점은 CliGate가 두 개의 제공자(provider)를 더 지원한다는 점이 아닙니다.

진정한 이점은 제공자를 추가하는 것이 더 이상 모든 도구(tool)에게 해당 제공자에 대해 가르치는 과정을 의미하지 않는다는 것입니다.

Qwen과 OpenRouter는 이제 로컬 제어 평면(control plane) 내부의 자격 증명(credentials) 및 라우팅 선택 사항일 뿐입니다. Claude Code는 여전히 Anthropic 형태의 API와 통신하고 있다고 생각할 수 있습니다. Codex는 여전히 예상된 경로를 통해 진입할 수 있습니다. OpenAI 호환 클라이언트(OpenAI-compatible clients)는 여전히 Chat Completions를 직접 사용할 수 있습니다.

제공자 결정 단계가 도구(tool)에서 벗어나, 실제로 요청을 검사, 라우팅, 가격 책정 및 로깅할 수 있는 계층(layer)으로 이동합니다.

출처: github.com/codeking-ai/cligate

여러분의 AI 코딩 설정에서는 OpenRouter 스타일의 모델 카탈로그(model catalogs)를 어떻게 처리하고 계신가요? 모델 슬러그(model slugs)를 직접 전달하시나요, 모든 것을 티어(tiers)로 매핑하시나요, 아니면 도구별로 별도의 설정(configs)을 유지하시나요?