Vercel AI SDK 6와 AI Gateway로 멀티 모델 앱 만들기
2025년 12월 22일, Vercel은 AI SDK 6를 공개했다. 이 릴리스는 단순한 버전 업이 아니라, 2026년 에이전트 애플리케이션 설계 방식을 바꾸는 기준점에 가깝다. Agents, ToolLoopAgent, human-in-the-loop tool approval, DevTools, full MCP support, reranking, image editing, stable structured outputs with tool calling까지 한 번에 정리되었기 때문이다.
동시에 AI Gateway의 모델 fallback 문서는 운영 관점에서 중요한 힌트를 준다. 게이트웨이는 먼저 primary model로 요청을 보낸 뒤 provider routing 규칙을 적용하고, 특정 모델에 연결된 모든 provider가 실패하면 models 배열의 다음 모델을 시도한다. 최종 응답은 가장 먼저 성공한 모델과 provider 조합에서 반환된다.
이제 질문은 하나다. 2026년의 AI 앱은 왜 멀티 모델을 기본값으로 설계해야 할까. 그리고 AI SDK 6와 AI Gateway를 함께 쓰면 무엇이 실제로 달라질까.
왜 2026년에는 멀티 모델이 기본이 되는가
2026년의 AI 제품 운영은 단일 모델 최적화만으로 버티기 어렵다. 이유는 분명하다.
- 모델마다 강점이 다르다. 어떤 모델은 추론이 강하고, 어떤 모델은 응답 속도와 비용이 좋다.
- 동일 모델도 provider별 가용성, 지연 시간, rate limit, 지역별 품질 차이가 생긴다.
- 도구 호출, 멀티모달, structured output, 긴 컨텍스트 같은 기능 지원 범위가 완전히 같지 않다.
- 프로덕션 운영에서는 정확도보다 먼저 안정성이 무너지면 제품 경험 전체가 흔들린다.
즉, 2026년의 앱 아키텍처는 "가장 좋은 모델 하나를 찾는 일"보다 "요청 종류에 따라 가장 적절한 모델 경로를 설계하는 일"에 가깝다. 멀티 모델 전략은 선택지가 아니라 신뢰성 설계다.
AI SDK 6가 에이전트 설계를 어떻게 바꿨나
AI SDK 5 시기에는 generateText와 streamText를 조합해 직접 제어 흐름을 만드는 방식이 흔했다. 이 방식은 여전히 유효하지만, AI SDK 6는 에이전트 계층을 더 명확하게 끌어올렸다.
이번 릴리스에서 특히 중요한 변화는 다음과 같다.
- Agents와 ToolLoopAgent로 반복적인 도구 실행 루프를 더 일관되게 설계할 수 있다.
- tool execution approval과 human-in-the-loop approval을 통해 위험한 작업을 승인 기반으로 바꿀 수 있다.
- DevTools가 추가되어 도구 호출과 실행 흐름을 관찰하기 쉬워졌다.
@ai-sdk/mcp패키지의 MCP 지원이 stable이 되었고 OAuth authentication, resources, prompts, elicitation까지 지원한다.- tool calling과 함께 stable structured outputs를 사용할 수 있어, UI와 백엔드 계약을 더 강하게 만들 수 있다.
- reranking과 image editing이 포함되어 검색형 앱과 멀티모달 앱의 구성 선택지가 넓어졌다.
핵심은 "모델 호출"에서 "에이전트 시스템 설계"로 중심축이 이동했다는 점이다. 이제 프롬프트만 잘 쓰는 팀보다, 도구 승인 경계와 모델 라우팅 전략을 잘 설계하는 팀이 더 강해진다.
멀티 모델 앱의 기본 구조
가장 실용적인 시작점은 다음 3단 구조다.
- UI와 스트리밍은 Next.js Route Handler 또는 Server Action에서 관리한다.
- 모델 호출 표면은 AI SDK 6로 통일한다.
- 가용성과 라우팅은 AI Gateway에서 처리한다.
이렇게 나누면 애플리케이션 코드에는 "무슨 작업을 시키는가"를 남기고, 운영 정책은 게이트웨이로 점진적으로 이동시킬 수 있다.
import { streamText } from 'ai';
export async function POST(req: Request) {
const { prompt } = await req.json();
const result = streamText({
model: 'openai/gpt-5.4',
prompt,
providerOptions: {
gateway: {
order: ['azure', 'openai'],
models: [
'anthropic/claude-sonnet-4.6',
'google/gemini-3-flash',
],
},
},
});
return result.toUIMessageStreamResponse();
}
이 예제의 중요한 포인트는 단순하다.
- 주 모델은
model필드에 둔다. - 백업 모델은
providerOptions.gateway.models배열에 둔다. - provider 우선순위는
order로 제어한다.
실서비스에서는 이 구성이 장애 대응뿐 아니라 비용 최적화와 기능 호환성 대응에도 효과적이다.
AI Gateway fallback과 provider routing은 실제로 어떻게 동작하나
Vercel 문서 기준으로 동작 순서는 명확하다.
- 게이트웨이는 먼저 primary model로 요청을 보낸다.
- 각 모델에 대해 provider routing 규칙을 적용한다.
- 해당 모델에서 가능한 모든 provider가 실패하면 다음 fallback model로 넘어간다.
- 가장 먼저 성공한 모델과 provider 조합의 응답이 반환된다.
이 순서를 이해하면 운영 정책을 더 현실적으로 짤 수 있다.
좋은 fallback 설계 예시
- 주 모델: 높은 품질의 범용 모델
- 1차 fallback: 더 저렴하지만 tool calling이 안정적인 모델
- 2차 fallback: 빠른 응답이 강점인 모델
피해야 할 설계
- 기능이 다른 모델을 무작정 같은 체인에 넣는 것
- structured output 스키마가 깨질 수 있는데 검증 없이 응답을 신뢰하는 것
- provider 장애와 model capability mismatch를 같은 방식으로만 처리하는 것
운영에서 중요한 포인트는 "실패하면 다른 모델로 넘긴다"가 끝이 아니라는 점이다. 어떤 기능이 반드시 유지되어야 하는지 먼저 정의해야 한다. 예를 들어 tool calling, JSON schema 호환, 이미지 입력 지원 여부가 다르면 같은 fallback 체인에 넣더라도 요청 타입별로 분리하는 편이 안전하다.
언제 human approval을 반드시 넣어야 하나
AI SDK 6의 human-in-the-loop tool approval은 데모 기능이 아니라 운영 제어 장치로 봐야 한다. 특히 아래 작업은 승인 단계를 기본값으로 두는 편이 좋다.
- 결제, 환불, 주문 변경처럼 금전 영향이 있는 작업
- 데이터 삭제, 권한 변경, 배포 실행 같은 되돌리기 어려운 작업
- 외부 시스템에 쓰기를 발생시키는 CRM, ERP, 티켓 시스템 연동
- 고객에게 직접 전달되는 메일, 메시지, 공지 발송
- 보안 민감도가 높은 내부 도구 호출
반대로 승인 없이 자동화해도 되는 작업은 다음에 가깝다.
- 읽기 전용 검색
- 문서 요약과 초안 작성
- low-risk 분류 작업
- 캐시 가능한 내부 조회
팀이 실무에서 바로 적용하기 좋은 기준은 간단하다. "잘못 실행되었을 때 사람이 후처리하는 비용이 큰가"를 기준으로 나누면 된다.
승인 경계는 모델보다 도구에서 잡는 편이 낫다
많은 팀이 고성능 모델을 쓰면 승인 단계를 줄여도 된다고 생각하지만, 운영 관점에서는 반대다. 모델 품질이 좋아질수록 더 많은 권한을 맡기고 싶어지기 때문에 오히려 도구 계층의 정책이 중요해진다.
추천 패턴은 다음과 같다.
- 읽기 도구는 자동 승인
- 쓰기 도구는 사용자 승인 또는 역할 기반 승인
- 고위험 도구는 두 단계 승인
- 모든 승인 이벤트는 감사 로그에 남김
const toolPolicy = {
searchDocs: 'auto',
readTicket: 'auto',
updateTicketStatus: 'requires-approval',
refundPayment: 'requires-approval',
deployProduction: 'requires-approval',
} as const;
이런 정책 테이블은 프롬프트보다 오래 간다. 모델을 교체해도 운영 원칙이 유지되기 때문이다.
MCP가 멀티 모델 앱에서 중요한 이유
AI SDK 6에서 @ai-sdk/mcp가 stable이 되면서 MCP는 실험적인 연결 포맷을 넘어 실서비스 통합 레이어에 가까워졌다. 특히 OAuth authentication, resources, prompts, elicitation 지원은 엔터프라이즈 통합에 직접적인 의미가 있다.
이 변화가 중요한 이유는 두 가지다.
- 도구와 컨텍스트 공급 방식을 모델별 커스텀 코드에서 분리하기 쉬워진다.
- 에이전트가 단순 API 호출기가 아니라, 조직 내부 시스템과 연결되는 표준 런타임으로 발전한다.
멀티 모델 환경에서는 모델을 자주 바꾸게 된다. 이때 도구 연결 방식까지 모델별로 다르게 묶여 있으면 유지보수가 급격히 어려워진다. MCP를 활용하면 모델 레이어와 도구 레이어 사이의 결합을 줄이기 쉽다.
Next.js 팀을 위한 실전 도입 체크리스트
다음 체크리스트는 "이번 분기 안에 실제로 도입"하는 팀을 기준으로 정리했다.
1. 요청 유형부터 나눈다
하나의 범용 채팅 엔드포인트만 만들지 말고 최소한 아래 범주로 나누는 편이 좋다.
- 일반 Q and A
- 검색 기반 답변
- 도구 호출형 작업
- 백오피스 승인형 작업
요청 유형이 나뉘어야 fallback 정책과 모델 선택도 분리할 수 있다.
2. structured output을 먼저 표준화한다
UI가 렌더링할 JSON 형태, tool result 형태, 로그 필드를 먼저 정하면 모델 교체 비용이 낮아진다.
3. fallback 체인은 기능 기준으로 묶는다
속도와 비용만 보지 말고 다음 항목을 함께 체크해야 한다.
- tool calling 안정성
- JSON 출력 일관성
- 이미지 입력 여부
- 컨텍스트 길이
- provider availability
4. 승인 정책을 코드로 관리한다
프롬프트 문장만으로 승인 여부를 제어하지 말고, 서버 측 정책 객체나 데이터 테이블로 관리하는 편이 안전하다.
5. DevTools와 로그를 함께 본다
AI SDK 6 DevTools는 개발 속도를 높여주지만, 프로덕션에서는 요청별 모델, provider, fallback 발생 여부, tool approval 이벤트를 로그와 메트릭으로 함께 남겨야 한다.
6. 평가 기준을 한 번에 하나씩 올린다
처음부터 최고 정확도와 최저 비용과 최고 안정성을 동시에 맞추려 하지 않는 편이 좋다. 보통은 아래 순서가 현실적이다.
- 실패 없이 응답하는가
- tool 호출이 안전한가
- structured output이 안정적인가
- 비용이 예산 안에 들어오는가
- 평균 지연 시간이 목표를 만족하는가
추천 도입 시나리오
가장 무난한 출발점은 다음과 같다.
- 고객 응대형 읽기 작업은 자동 fallback과 자동 provider routing 사용
- 내부 운영형 쓰기 작업은 human approval 필수
- 복잡한 에이전트 플로우는 AI SDK 6 Agent 계층에서 관리
- 외부 시스템 연결은 MCP를 우선 검토
이 조합은 팀의 구현 속도와 운영 통제를 함께 챙기기 좋다.
마무리
2026년의 AI 앱 경쟁력은 "어떤 모델을 쓰는가"만으로 결정되지 않는다. 더 중요한 것은 모델을 바꿔도 서비스 품질과 운영 통제가 유지되는 구조를 먼저 만드는 일이다. AI SDK 6는 에이전트 설계와 도구 승인, MCP 통합을 더 실용적으로 만들었고, AI Gateway는 멀티 모델 운영을 제품 코드 밖으로 일부 분리할 수 있게 해준다.
정리하면 방향은 분명하다. 단일 모델에 모든 기대를 거는 대신, 모델 선택과 provider routing과 human approval을 시스템 설계의 일부로 끌어올려야 한다. 그게 2026년형 AI 제품팀의 기본기다.