AI Gateway 제어면
Vercel AI Gateway를 모델 라우팅, provider fallback, 사용량 정책, 비용 거버넌스를 중앙화하는 엔터프라이즈 제어면으로 운영합니다.
핵심 요약
- AI Gateway의 진짜 가치는 멀티 모델 지원이 아니라 모델 string, provider 우선순위, API key, ZDR을 앱 코드 밖에서 통제하는 운영 정책 중앙화입니다.
- 제어면에는 모델 라우팅·fallback·budget·ZDR/BYOK·caching을 두고, 앱에는 업무별 모델 요구사항과 예산 소유자 지정만 남깁니다.
- 신규 모델(
openai/gpt-5.5,xai/grok-4.3,openai/gpt-image-2)은 더 좋은 기본값이 아니라 새 운영 tier로 보고 preview/staging eval을 먼저 돌립니다. - 권장 기본값은 primary + secondary 1개 provider order, UI/batch 경로 timeout 분리, app별 API key 분리,
user + feature + tenantusage 태깅입니다. - 적용 순서는 전 호출 Gateway 경유 → app/workflow key 분리 → 경로별 fallback·timeout → 민감 경로 ZDR·BYOK 부착입니다.
AI Gateway를 도입하는 이유를 흔히 "멀티 모델 지원"으로 설명하지만, 엔터프라이즈에서 더 중요한 가치는 운영 정책 중앙화입니다.
모델 string, provider 우선순위, API key, usage, custom reporting, caching, ZDR를 앱 코드 밖에서 일관되게 다룰 수 있기 때문입니다.
2026-05 모델·운영 업데이트
AI Gateway 모델 카탈로그와 운영 기능은 빠르게 바뀝니다. 2026년 4월 말 기준으로는 GPT-5.5, Grok 4.3, GPT Image 2 같은 신규 모델과 Custom Reporting API를 함께 추적해야 합니다.
| 변화 | 운영 영향 |
|---|---|
openai/gpt-5.5, openai/gpt-5.5-pro | 코딩/장기 추론 tier 후보로 eval 기준선 추가 |
xai/grok-4.3 | 1M context와 tool calling 개선을 활용한 긴 분석 경로 후보 |
openai/gpt-image-2 | 이미지 생성도 Gateway usage/cost 추적 범위에 포함 |
| Custom Reporting API | 모델, provider, user, tag, credential type별 비용·토큰 집계 가능 |
실무 권장
새 모델은 "더 좋은 기본값"이 아니라 새 운영 tier입니다. 모델 문자열을 하드코딩하기 전에 Gateway 모델 카탈로그에서 지원 provider, 가격, ZDR, context, tool support를 확인하고, preview/staging eval부터 돌리세요.
제어면이 담당해야 할 것
| 책임 | Gateway에서 보는 기능 | 애플리케이션에 남길 것 |
|---|---|---|
| 모델 선택 | model id, provider routing | 업무별 모델 요구사항 정의 |
| 장애 완화 | provider order, fallback, timeouts | fallback 허용 여부 정책 |
| 비용 관리 | budgets, spend visibility, reporting metadata | 예산 소유자 지정 |
| 데이터 정책 | ZDR, BYOK | 어떤 요청에 적용할지 분류 |
| 응답 성능 | caching, provider tuning | cacheability 판단 |
권장 흐름
제어면 운영 체크포인트
| 항목 | 권장 기본값 | 이유 |
|---|---|---|
| provider order | primary + 1 secondary | 모델 장애를 request 수준에서 완화 |
| timeouts | UI path와 batch path 분리 | 동일 timeout은 비용과 UX를 모두 악화 |
| API key scope | app별 분리, 운영자용 별도 | 감사와 예산 소유권 분리 |
| usage tagging | user + feature + tenant tag | 고객/기능별 비용 분석 가능 |
| BYOK | 고객 요구가 있을 때만 | 운영 복잡도 증가 |
| ZDR | 민감 데이터 경로 기본 적용 | 정책 일관성 확보 |
BYOK와 팀 단위 자격 증명 전략
| 모델 | 적용 상황 | 장점 | trade-off |
|---|---|---|---|
| Platform-managed key | 기본 경로 | 운영 단순성 | 일부 고객 정책 충족 한계 |
| Team-scoped key | 부서/서비스 분리 | 비용 책임 명확 | secret 수 증가 |
| Customer BYOK | 규제/대기업 고객 | 고객 통제 강화 | 운영/지원 비용 상승 |
캐싱과 fallback을 보는 법
| 기능 | 흔한 오해 | 실무 기준 |
|---|---|---|
| caching | 응답을 항상 빨라지게 한다 | 읽기 비중이 높은 반복 질의에만 적극 사용 |
| fallback | 항상 품질을 유지한다 | 실제 목적은 운영 연속성 확보 |
| model discovery | 자동 최적 모델 선택기 | 운영자가 선택지를 표준화하는 도구 |
import { streamText } from 'ai'
const result = streamText({
model: 'anthropic/claude-sonnet-4.6',
prompt,
providerOptions: {
gateway: {
order: ['vertex', 'anthropic'],
only: ['vertex', 'anthropic'],
caching: 'auto',
tags: ['feature:support-chat', `tenant:${tenantId}`],
user: userId,
},
},
})실무 해석
Gateway는 벤더 추상화 레이어라기보다 팀의 모델 사용 습관을 통제하는 레이어입니다. 앱 코드가 직접 provider SDK를 부르면 비용과 보안 통제가 바로 분산됩니다.
예산과 usage 운영
| 단위 | 질문 | 예시 |
|---|---|---|
| Feature tag | 어떤 기능이 비용을 쓰는가 | support-chat, internal-research |
| User | 누가 호출하는가 | user id / operator id |
| Model | 어떤 모델이 효율적인가 | fast tier, reasoning tier |
| Tenant/plan tag | 누구를 위해 썼는가 | tenant id, plan tier |
추천 적용 순서
- 모든 모델 호출을 Gateway 경유로 전환합니다.
- app key와 workflow key를 분리합니다.
- fallback chain과 timeout을 사용자 경로/배치 경로별로 나눕니다.
- 민감 경로에 ZDR과 BYOK 정책을 붙입니다.
ADR 스타일 결론
Decision
AI Gateway는 멀티 모델 추상화 레이어가 아니라 운영 정책의 중앙 제어면으로 사용합니다. 모델 선택, 예산, 자격 증명, fallback, ZDR 정책은 앱 코드가 아니라 Gateway 중심으로 관리합니다.
실무 체크리스트
- 모든 프로덕션 모델 호출이 Gateway를 통과하는가
- UI path와 background path의 timeout이 분리돼 있는가
- API key가 app, workflow, ops bot 단위로 분리돼 있는가
- 민감 경로에 ZDR 또는 BYOK 적용 기준이 문서화돼 있는가