# 클라이언트에는 모델 하나: 게이트웨이가 자동으로 계층화

> 클라이언트에서 모델 선택을 없앱니다: 모델 이름 하나만 노출하면 게이트웨이가 대화 상태(계획 vs 실행)에 따라 자동으로 계층화해 강한 모델이 계획하고 비용 효율 모델이 실행합니다. 머신별 구성 드리프트 없음.

표준 링크: https://www.gatellm.io/ko/use-cases/automatic-model-tiering/

UI에서 모델 선택을 없애세요 — 클라이언트는 모델 이름 하나만 노출하고, 계획은 강한 모델에서 실행되고 실행은 비용 효율 모델로 떨어지며, 요청이 이미 지나던 홉에서 계층화됩니다.

## 커뮤니티가 실제로 불평하는 것
"모두가 설정에 다른 모델을 넣어 같은 프롬프트가 사람마다 다르게 나온다", "누군가의 첫 주에 가장 흔한 질문이 어떤 모델을 골라야 하냐는 것이다", "모델을 은퇴시키려면 모든 개발자 머신의 환경 변수를 고쳐야 한다". 모델 선택이 결정할 정보가 가장 적은 사람에게 넘어갔습니다: 자기 지출을 볼 수 없고, 이 특정 요청이 강한 모델을 받을 자격이 있는지 알 방법이 없습니다.
대신 모두를 저렴한 모델로 내리면 작업 품질이 떨어집니다 — 계획과 아키텍처 판단을 작은 모델에 맡기면 재작업 비용이 절감보다 커집니다. 정말 중요한 구분은 이 요청이 무엇을 하는가, 계획인가 실행인가이며, 클라이언트는 게이트웨이에 그걸 알려 준 적이 없습니다.

## GateLLM은 이렇게 합니다
클라이언트는 모델 이름 하나를 유지하고, 게이트웨이의 포괄 매핑(from "*")이 클라이언트가 요청한 이름을 정규화하므로 개인 설정을 바꿔도 요청의 도착지가 바뀌지 않습니다. 어떤 모델을 고를지 설명할 것도 남지 않습니다.
계층화 신호는 이미 대화 안에 있습니다: Claude Code의 계획 모드가 진입 시 Plan mode is active, 종료 시 Exited Plan Mode를 주입합니다. before 슬롯 스크립트가 마지막 메시지부터 거꾸로 스캔해 마지막으로 본 마커로 현재 상태를 판단한 뒤 context.useModel()을 호출해 라우팅을 전환합니다. 결정은 문자열 위치 비교입니다 — 별도 분류 호출도, 추가 네트워크 홉도 없습니다.
계층화는 before 슬롯에 있어야 합니다: after 슬롯은 번역된 업스트림 본문을 보므로 클라이언트가 주입한 마커를 읽을 수 없고, after-slot useModel은 같은 프로토콜 안에서만 전환하는 반면 계획에서 실행으로의 전환은 모델 간 경로 변경입니다. request_payload 규칙(prompt_cache_key 등)은 두 모델에 모두 구성해야 합니다: 진입 모델은 계획 중 자기 것을 유지하고, 대상 모델의 것은 전환 후에 적용됩니다.

## 실제로 효과가 있는 5가지 레버
- 단일 인그레스 이름: 클라이언트는 모델 이름 하나를 노출하고 from "*" 포괄 매핑이 모든 요청 이름을 하나의 도착 모델로 정규화
- 자동 계층화: before 슬롯 스크립트가 거꾸로 스캔해 마지막 마커를 취함 — 진입 마커는 기록에 영원히 남으므로 "포함" 검사는 상태를 영구히 계획 모드로 읽습니다
- 프로토콜 가드: 스크립트가 context.sourceProtocol을 먼저 확인하고 비-Anthropic 트래픽에는 조기 반환하므로, 여러 클라이언트를 서비스하는 진입 모델이 잘못 라우팅되지 않음
- 관찰 가능: 로그 모델 열의 SW 태그는 스크립트 전환, MM은 아이덴티티 매핑을 표시하며, 통계와 과금이 최종 모델 이름으로 귀속되어 모든 계층화 결정을 감사 가능
- 클라이언트 배포 제로: 구성 변경에 머신별 편집이 필요 없고 매핑은 핫 리로드(유일한 예외는 재시작이 필요한 스크립트 힙 상한 SCRIPT_MEMORY_LIMIT_MB)

## FAQ
### 클라이언트가 여전히 자기 모델을 고를 수 있나요?
고를 수는 있지만 그 선택이 요청의 도착지를 결정하지 않습니다: 포괄 매핑이 요청된 이름을 정규화하고, 스크립트 useModel은 클라이언트 권한에 구속되지 않는 관리자 강제 경로 변경입니다. 클라이언트에 이름 하나만 노출하는 것이 그 질문 자체를 없앱니다.

### 전용 모델 라우터나 분류기를 쓰면 안 되나요?
지연 시간과 형태 문제입니다. 별도 라우터는 홉을 더하고 보통 분류 호출도 추가합니다. 여기서는 계층화 신호가 이미 대화에 있는 마커 텍스트이고, 결정은 요청이 어차피 지나던 경로에서 마지막 마커 위치를 비교하는 것입니다. 프로토콜 번역, 인증, 계량은 이미 게이트웨이에 있으므로 계층화가 이를 복제할 두 번째 구성 요소를 필요로 하지 않습니다.

### 스크립트가 아무것도 전환하지 않고 로그에도 오류가 없나요?
대개 스크립트 OOM입니다: 각 스크립트는 자체 QuickJS 샌드박스(힙 상한 SCRIPT_MEMORY_LIMIT_MB, 기본 64MB)에서 실행되고, 오버플로 시 기본 log-and-continue 모드가 useModel을 포함한 모든 부수 효과를 조용히 버립니다. Claude Code의 수십 개 도구 정의가 메모리를 먼저 소비하며 이 하한은 스크립트 계층에서 제거할 수 없으니 한도를 높이세요(재시작 필요). 로그 모델 열의 SW 태그로 전환을 확인하세요.

- [전체 방법: 계획 모드로 모델 전환(문서)](https://docs.gatellm.io/en/howto/script-switch-model-by-plan-mode)

## 관련 활용 사례
- [에이전트가 실제로 실행하는 모델 강제: 모델을 고정하고 계획과 실행을 분리](https://www.gatellm.io/ko/use-cases/enforce-model-policy.md)

## 관련 페이지
- [홈](https://www.gatellm.io/ko/index.md)
- [요금](https://www.gatellm.io/ko/pricing.md)
- [비용 계산기](https://www.gatellm.io/ko/calculator.md)
- [소개](https://www.gatellm.io/ko/about.md)
- [데모 예약](https://www.gatellm.io/ko/demo.md)
- [FAQ](https://www.gatellm.io/ko/faq.md)
- [AI 게이트웨이 비교](https://www.gatellm.io/ko/compare.md)
- [LiteLLM 비교](https://www.gatellm.io/ko/compare/litellm.md)
- [OpenRouter 비교](https://www.gatellm.io/ko/compare/openrouter.md)
- [Alibaba Cloud AI Gateway 비교](https://www.gatellm.io/ko/compare/alibaba-cloud.md)
- [Azure API Management 비교](https://www.gatellm.io/ko/compare/azure-apim.md)
- [Apigee 비교](https://www.gatellm.io/ko/compare/apigee.md)
- [Cloudflare AI Gateway 비교](https://www.gatellm.io/ko/compare/cloudflare.md)
- [Kong AI Gateway 비교](https://www.gatellm.io/ko/compare/kong.md)
- [Portkey 비교](https://www.gatellm.io/ko/compare/portkey.md)
- [LiteLLM vs Kong AI Gateway](https://www.gatellm.io/ko/compare/litellm-vs-kong.md)
- [LiteLLM vs OpenRouter](https://www.gatellm.io/ko/compare/litellm-vs-openrouter.md)
- [LiteLLM vs Portkey](https://www.gatellm.io/ko/compare/litellm-vs-portkey.md)
- [사용 사례](https://www.gatellm.io/ko/use-cases.md)
- [LLM 비용 절감](https://www.gatellm.io/ko/use-cases/reduce-cost.md)
- [고가용성](https://www.gatellm.io/ko/use-cases/high-availability.md)
- [멀티테넌트 격리](https://www.gatellm.io/ko/use-cases/multi-tenant.md)
- [컴플라이언스 및 감사](https://www.gatellm.io/ko/use-cases/compliance-audit.md)
- [증상별 트러블슈팅](https://www.gatellm.io/ko/use-cases/troubleshooting.md)
- [다중 벤더 혼합 모델 스택](https://www.gatellm.io/ko/use-cases/mixed-model-stack.md)
- [Office 내 AI 셀프 호스팅](https://www.gatellm.io/ko/use-cases/self-hosted-office-ai.md)
- [Token 사용량 가시성 및 귀속](https://www.gatellm.io/ko/use-cases/token-ops.md)
- [Token FinOps: AI 비용 배분 및 통제](https://www.gatellm.io/ko/use-cases/token-finops.md)
- [MCP 도구 거버넌스](https://www.gatellm.io/ko/use-cases/mcp-tool-governance.md)
- [모든 모델에 웹 검색 추가](https://www.gatellm.io/ko/use-cases/web-search-grounding.md)
- [다중 키 로테이션 및 대기](https://www.gatellm.io/ko/use-cases/multi-key-pooling.md)
- [연결 클라이언트 접근 제어](https://www.gatellm.io/ko/use-cases/client-admission-control.md)
- [모델 사용 정책 강제](https://www.gatellm.io/ko/use-cases/enforce-model-policy.md)
- [하나의 프로토콜, 어떤 모델이든](https://www.gatellm.io/ko/use-cases/one-protocol-any-model.md)
- [Office / Microsoft 365 추가 기능](https://www.gatellm.io/ko/office-addin.md)
- [용어집](https://www.gatellm.io/ko/glossary.md)
- [모델 카탈로그](https://www.gatellm.io/ko/models.md)
- [SDK 및 프레임워크 통합](https://www.gatellm.io/ko/integrations.md)
- [AI 코딩 에이전트 및 하네스](https://www.gatellm.io/ko/coding-agents.md)
- [보안 및 컴플라이언스](https://www.gatellm.io/ko/security.md)