라우팅과 모델 선택: 채널, 모델, 클라이언트의 관계

AI 게이트웨이를 사용할 때 가장 혼동하기 쉬운 세 가지 개념은 채널, 모델, 클라이언트입니다. 이들의 관계를 이해하면 라우팅을 올바르게 구성할 수 있고, "왜 요청이 내가 예상한 채널로 가지 않지?"라는 혼란도 피할 수 있습니다.

세 가지 기본 개념

이들의 관계는 하나의 단방향 링크입니다:

클라이언트 →(가상 키)→ 게이트웨이(라우팅 정책)→ 채널 → 모델

매 요청 시 클라이언트가 요청 안에 모델명을 지정하고, 게이트웨이는 이 모델명을 기준으로 해당 모델을 처리할 수 있는 채널을 찾아 요청을 전달합니다.

Claude Code, opencode 등 클라이언트의 모델 선택기에서 qwen3:8b (Ollama Qwen3) 같은 항목을 보게 됩니다. 괄호 안의 이름은 이 모델의 출처 채널을 나타내며, "또 다른 연결"이 아닙니다:

클라이언트와 게이트웨이 사이에는 항상 하나의 연결(하나의 주소 + 하나의 가상 키)만 존재합니다.
하나의 모델을 여러 채널에 구성할 수도 있습니다. 이 경우에도 선택기에는 한 줄만 표시되며(괄호 안에는 그중 하나의 출처 채널이 표시됨), 각 요청을 실제로 어떤 채널이 처리할지는 라우팅 정책이 결정합니다(아래 참조).

라우팅 정책이 다루는 질문은 바로 이것입니다: 같은 모델을 여러 채널이 처리할 수 있을 때, 어느 채널을 사용할 것인가?

모드	동작	적합한 시나리오
Fixed(고정)	항상 동일한 채널 사용	채널 품질이 안정적이며 출처를 고정하고 싶을 때
Failover(주/백업)	기본 채널이 실패하거나 크레딧이 소진되면 순서대로 백업 채널로 전환	기본·백업 채널을 갖춘 구성
Balanced(분산)	사용 가능한 채널들 사이에서 요청을 번갈아 분배	동일한 성격의 여러 채널로 부하 분산

꼭 기억해야 할 두 가지:

라우팅은 채널 사이에서만 전환하며, 모델을 바꾸지 않습니다. 어떤 모델을 요청할지는 항상 클라이언트가 결정하며, 게이트웨이가 대신 모델을 바꿔 주지 않습니다.
서로 다른 모델은 원래부터 각자 자신의 채널로 향합니다. Balanced는 "이번에는 A 채널의 모델, 다음에는 B 채널의 모델"을 사용하는 방식이 아닙니다. 오직 같은 모델이 놓인 여러 채널 사이에서만 번갈아 분배합니다.

게이트웨이는 전달만 담당합니다. 사용하는 도구가 매 요청마다 모델명을 담아 보내면, 게이트웨이는 그에 따라 라우팅합니다. 모델 전환은 클라이언트에서 수행합니다:

opencode: TUI에서 /models를 입력해 선택하거나, opencode.json에서 model(기본 모델)과 small_model(제목 생성 등 가벼운 작업용)을 구성합니다.
Claude Code: /model 명령으로 전환합니다.
Codex: -m <model> 인자 또는 구성 파일로 지정합니다.

일상 사용에 영향을 줄까 걱정되시나요? 다음 절차를 따르세요:

먼저 덜 중요한 프로젝트로 시험하기: 중요하지 않은 프로젝트 디렉터리에서 원클릭 연동을 완료하고, 워크플로가 정상 작동하는지 확인합니다.
요청 한 건으로 검증: 테스트 요청을 하나 보낸 뒤, "사용 기록" 페이지에서 어떤 모델과 채널에서 처리되었는지, 비용이 얼마 들었는지 확인합니다.
언제든 되돌리기: "연동 관리" 페이지에서 인수를 중지합니다. 중지하면 ServBay가 작성한 구성은 제거되고, 인수로 생성된 가상 키는 폐기됩니다. 기존의 사용자 지정 구성은 자동으로 복원되지 않으므로, 필요한 경우 수동으로 조정한 뒤 클라이언트를 재시작하면 적용됩니다.

채널 = 업스트림 연결; 모델 = 채널이 제공하는 능력; 모델명은 클라이언트가 매 요청마다 지정합니다.
라우팅 정책은 "같은 모델의 여러 채널" 사이에서만 선택합니다: Fixed는 고정, Failover는 주/백업, Balanced는 순환 분배입니다.
클라이언트의 모델 선택기에서 모델을 전환하고, "사용 기록" 페이지에서 각 요청이 처리된 모델·채널과 비용을 확인하세요.