10장. 멀티 벤더 아키텍처 설계

OpenAI를 붙여 봤고, Claude도 붙여 봤고, Gemini도 붙여 봤다. 여기까지 오면 많은 팀이 자연스럽게 이런 질문을 던진다.

"그래서 셋 중에 뭐가 제일 좋죠?"

그런데 실전 서비스에서는 이 질문이 생각보다 오래 중요하지 않다. 더 오래 남는 질문은 따로 있다.

"지금 붙인 모델을 다음 달에도 그대로 써도 될까?"

조금 더 냉정하게 말하면 이렇다.

"장애가 나면 어디로 우회하지?" "가격이 오르면 무엇으로 갈아타지?" "응답 품질이 흔들리면 어떤 규칙으로 다른 모델로 보낼까?"

이 장의 핵심은 분명하다. 실전 서비스에서는 어떤 모델이 최고인지보다, 언제든 갈아탈 수 있는 구조를 갖추는 것이 더 중요하다. 모델은 바뀐다. 가격도 바뀐다. 제한도 바뀐다. 심지어 잘 쓰던 모델이 몇 달 뒤 사라지기도 한다.¹

좋은 멀티 벤더 아키텍처는 이 변화를 드라마가 아니라 설정 변경으로 만든다. 오늘은 바로 그 설계를 이야기해 보자.

왜 멀티 벤더가 필요한가

처음에는 한 벤더만으로도 충분해 보인다. 문서도 잘 되어 있고, SDK도 편하고, 성능도 그럴듯하다. 실제로 초기 제품은 그렇게 시작하는 편이 맞다.

문제는 서비스가 "기능"이 아니라 "운영"의 단계로 넘어갈 때 생긴다. 그때부터는 모델 품질 하나만으로는 설명되지 않는 현실이 한꺼번에 들어온다. 공급자 장애, 레이트 리밋, 지역별 지연 시간, 가격 차이, 모델 단종, 팀별 예산 통제 같은 문제들이다. 실제 멀티 프로바이더 논의가 커진 배경도 비슷하다. 한 공급자에 깊게 묶이면 마이그레이션 비용이 커지고, 장애가 곧 서비스 장애로 번지며, 작업별로 더 싼 모델이나 더 빠른 모델을 쓰고 싶어도 코드가 발목을 잡게 된다.¹

예를 들어 보자. 고객지원 자동화 기능을 운영하는 팀이 있다고 하자. 평소에는 A 벤더의 고성능 모델이 매우 잘 맞는다. 그런데 월요일 오전 10시에 429가 쏟아지기 시작한다. 요청은 밀리고, 재시도는 겹치고, 고객센터 상담사는 답이 늦게 나와 짜증이 난다. 이때 "우리 모델은 평소 성능이 좋다"는 사실은 거의 위로가 되지 않는다.

서비스 입장에서 중요한 것은 하나다.

답이 조금 덜 우아해도 계속 나와야 한다.

바로 여기서 멀티 벤더 설계가 필요해진다. 멀티 벤더의 목적은 화려한 데모가 아니다. 운영의 충격을 흡수하는 것이다.

멀티 벤더의 목표를 먼저 분리하자

멀티 벤더라고 하면 종종 "모든 모델을 한 번에 다 붙이는 거대한 플랫폼"을 떠올린다. 하지만 그렇게 시작하면 대개 너무 무겁다. 먼저 목표를 나눠 보는 편이 좋다.

• 교체 가능성: 지금 쓰는 벤더를 나중에 다른 벤더로 바꿔도 비즈니스 코드가 크게 흔들리지 않는가

• 장애 대응: 주 벤더가 느려지거나 실패할 때 자동으로 다른 모델이나 다른 벤더로 우회할 수 있는가

• 정책 기반 라우팅: 요청의 종류, 비용, 속도, 품질 기준에 따라 어떤 모델로 보낼지 규칙적으로 결정할 수 있는가

이 셋은 비슷해 보여도 조금 다르다.

교체 가능성은 구조의 문제다. 장애 대응은 신뢰성의 문제다. 정책 기반 라우팅은 운영 최적화의 문제다.

처음부터 셋을 완벽하게 다 하려 하지 말자. 대부분의 팀은 먼저 교체 가능한 내부 계약을 만들고, 그다음 기본 폴백을 넣고, 마지막으로 정교한 라우팅 정책으로 확장한다. 이 순서가 자연스럽다.

내부 계약이 먼저고 벤더는 나중이다

8장에서 우리는 Claude를 붙이면서 내부 요청과 응답 구조를 분리해야 한다는 감각을 봤다. 10장에서는 그 생각을 더 밀어붙여야 한다.

멀티 벤더 아키텍처의 출발점은 "벤더를 많이 붙이는 것"이 아니라, 애플리케이션이 벤더를 직접 모르도록 만드는 것이다.²

쉽게 말해 서비스 코드가 이런 식으로 되어 있으면 곤란하다.

if (provider === 'openai') {
  // OpenAI SDK 호출
} else if (provider === 'anthropic') {
  // Claude SDK 호출
} else if (provider === 'google') {
  // Gemini SDK 호출
}

이 구조는 처음엔 쉬워 보이지만, 시간이 갈수록 화면마다 분기문이 자라난다. 결국 "모델 교체"가 아니라 "서비스 전체 리팩터링"이 되어 버린다.

대신 애플리케이션 안에는 벤더 중립적인 계약을 먼저 둬야 한다.

export type LlmTaskType =
  | 'chat'
  | 'summary'
  | 'classification'
  | 'doc_analysis'
  | 'title_generation';

export type AppLlmRequest = {
  taskType: LlmTaskType;
  system?: string;
  messages: Array<{ role: 'user' | 'assistant'; content: string }>;
  responseSchema?: unknown;
  requires?: {
    vision?: boolean;
    tools?: boolean;
    strictJson?: boolean;
    longContext?: boolean;
    streaming?: boolean;
  };
  policy?: {
    latency: 'low' | 'normal';
    budget: 'cheap' | 'balanced' | 'premium';
    reliability: 'best_effort' | 'high';
  };
  tenantId?: string;
};

export type AppLlmResponse = {
  text?: string;
  json?: unknown;
  toolCalls?: Array<{ name: string; arguments: unknown }>;
  usage?: {
    inputTokens?: number;
    outputTokens?: number;
    estimatedCostUsd?: number;
  };
  meta: {
    provider: string;
    model: string;
    routedBy: string;
    fallbackUsed: boolean;
  };
};

이렇게 해 두면 비즈니스 로직은 "OpenAI냐 Claude냐 Gemini냐"를 몰라도 된다. 대신 "이 요청은 긴 문맥이 필요하다", "엄격한 JSON이 필요하다", "저렴한 응답이면 된다" 같은 제품 언어로만 말하면 된다.

그리고 실제 벤더 호출은 어댑터 계층이 맡는다.

여기서 중요한 원칙이 하나 있다.

모델 이름을 코드에 직접 박지 말고, 모델 별칭(alias)을 써라.

예를 들어 gpt-4o, claude-sonnet-4-6, gemini-3-pro 같은 이름이 화면 곳곳에 흩어져 있으면 교체 비용이 커진다. 대신 chat.fast, analysis.deep, summary.cheap 같은 내부 별칭을 두는 편이 낫다. 그러면 운영자가 바꾸는 것은 코드가 아니라 매핑 테이블이다.

capability registry가 없으면 라우터는 눈을 감고 운전한다

멀티 벤더에서 자주 놓치는 것이 하나 있다. 어댑터는 만들었는데, 각 모델이 무엇을 할 수 있는지 기록한 표가 없다.

이 표가 없으면 라우터는 결국 감으로 동작한다. "아마 이 모델도 JSON 될걸?", "이 모델도 이미지 되겠지?", "이 모델도 충분히 빠르지 않을까?" 같은 위험한 추측이 코드에 들어간다.

실전에서는 최소한 다음 정보 정도는 모델별로 정리해 두는 편이 좋다.

이 표를 여기서는 capability registry라고 부르자. 이름은 거창하지만 역할은 단순하다. "이 요청을 누가 처리할 수 있는가"를 기계가 판단할 수 있게 만드는 지도다.

좋은 라우터는 모델을 사랑하지 않는다. 조건을 본다.

라우터는 if문 덩어리가 아니라 정책 엔진이다

멀티 벤더 아키텍처에서 가장 중요한 컴포넌트는 의외로 SDK가 아니다. 라우터다. 그리고 이 라우터는 단순 분기문이 아니라 정책 엔진이어야 한다.³

왜 그럴까. 같은 요청이라도 상황에 따라 최적의 선택이 달라지기 때문이다.

예를 들어 문서 분석 요청 하나를 보자.

• 무료 플랜 사용자의 짧은 문서라면 빠르고 저렴한 모델이면 충분할 수 있다.

• 엔터프라이즈 고객의 계약서 검토라면 긴 문맥과 높은 안정성이 필요하다.

• 현재 주 벤더의 지연 시간이 급증했다면 같은 요청도 다른 벤더로 보내는 편이 낫다.

• 응답을 JSON으로 파싱해야 하는 기능이라면 구조화 출력 안정성이 더 중요한 기준이 된다.

즉 라우터는 단지 "어느 벤더를 호출할까"를 정하는 컴포넌트가 아니다. 제품 정책, 운영 상태, 비용 한도, 기능 요구사항을 함께 반영하는 결정기다.

좋은 라우터는 보통 다음 입력을 본다.

• 요청 종류: 채팅, 요약, 분류, 문서 분석, 에이전트 실행

• 기능 요구: 긴 문맥, 이미지 처리, 툴 호출, 엄격한 JSON

• 서비스 정책: 무료/유료 플랜, 테넌트별 예산, 응답 SLA

• 실시간 상태: 현재 지연 시간, 오류율, 레이트 리밋 근접도, 폴백 활성화 여부

• 규제 조건: 특정 리전 사용, 데이터 보관 정책, 사내망 전용 여부

예를 들어 라우팅 규칙은 이런 식으로 읽히면 좋다.

function selectModel(req: AppLlmRequest, health: HealthState): ModelAlias {
  if (req.requires?.vision) return 'vision.primary';

  if (req.taskType === 'title_generation') return 'title.cheap';

  if (req.policy?.budget === 'cheap' && req.taskType === 'classification') {
    return 'classify.bulk';
  }

  if (req.requires?.longContext || req.taskType === 'doc_analysis') {
    if (health['analysis.deep'].healthy) return 'analysis.deep';
    return 'analysis.backup';
  }

  if (req.policy?.latency === 'low') return 'chat.fast';

  return 'chat.default';
}

이 예시는 단순하지만 중요한 사실을 보여 준다. 라우터의 기준은 벤더 이름이 아니라 업무 의미와 운영 상태여야 한다는 점이다.

장애는 예외가 아니라 전제다

LLM 서비스에서 "장애가 날 수도 있다"는 표현은 너무 순진하다. 더 현실적인 말은 이렇다.

언젠가는 반드시 장애가 난다.

그래서 멀티 벤더 설계에서 폴백은 옵션이 아니라 핵심 기능이다. 중요한 것은 모든 실패를 같은 방식으로 다루지 않는 것이다. 일시적인 실패와 구조적인 실패는 다르게 처리해야 한다.¹⁶

가장 실전적인 폴백 구조는 계층형이다.

1. 같은 모델 재시도 429, 503, 일시적 타임아웃처럼 순간적인 오류라면 짧은 재시도가 효과적이다. 이때는 exponential backoff와 jitter를 써서 한꺼번에 다시 몰리지 않게 해야 한다.⁶

2. 같은 벤더의 대체 모델 주력 모델이 과부하이거나 일시적으로 불안정할 때, 같은 벤더의 더 가벼운 모델로 품질을 조금 낮추고 서비스 연속성을 지킬 수 있다.

3. 다른 벤더로 폴백 벤더 자체가 흔들릴 때는 공급자를 바꾸는 것이 가장 강한 대응이다. 이 단계부터는 응답 형식 차이와 프롬프트 호환성을 흡수하는 어댑터가 꼭 필요하다.

4. 축소 응답 또는 캐시 응답 두 벤더 모두 흔들릴 수도 있다. 그때는 "AI가 잠시 불안정합니다"라는 무성의한 문구보다, 최근 캐시 결과나 제한된 템플릿 응답이라도 주는 편이 낫다.⁶

여기서 중요한 건 실패 분류다. 429, 500, 503, 네트워크 타임아웃은 재시도나 폴백 후보가 된다. 반면 400, 401, 403 같은 오류는 대개 우리 요청이나 자격 증명 문제라서 재시도해도 해결되지 않는다.¹⁶

한 가지 더. 폴백이 있다고 해서 모든 기능이 똑같이 폴백되어야 하는 것은 아니다.

요약, 분류, 제목 생성 같은 기능은 모델이 바뀌어도 사용자 경험이 크게 깨지지 않을 수 있다. 하지만 결제 안내, 법적 문서 검토, 정책 답변처럼 오답 비용이 큰 기능은 무조건 다른 모델로 보내기보다 아예 안전한 축소 모드로 내려가는 편이 더 낫다.

즉 멀티 벤더는 "무조건 다른 모델로 보낸다"가 아니라, 기능별로 허용 가능한 품질 저하를 설계한다는 뜻이다.

비용 최적화는 모델 가격표가 아니라 라우팅 규칙에서 나온다

멀티 벤더를 이야기하면 흔히 "어느 모델이 더 싸냐"로 곧장 가지만, 실전에서 비용은 모델 가격표보다 어떤 요청을 어떤 모델로 보내는지에서 더 크게 갈린다.¹

간단히 말해, 모든 요청이 최고급 모델을 탈 이유는 없다.

제목 생성, 짧은 분류, 중복 문장 정리, 간단한 요약 같은 작업은 작고 빠른 모델로도 충분한 경우가 많다. 반대로 긴 문서 해석, 복잡한 추론, 중요한 의사결정 초안은 더 비싼 모델을 써도 된다. 멀티 벤더 구조의 힘은 여기서 나온다. 고급 모델을 없애는 것이 아니라, 꼭 필요한 순간에만 쓰게 만드는 것이다.¹⁴

예를 들어 고객지원 SaaS라면 이런 규칙을 둘 수 있다.

• 티켓 제목 생성과 1차 카테고리 분류는 저비용 모델

• 본문 요약은 중간 티어 모델

• 환불 분쟁, 보안 사고, 법적 표현 검토는 고품질 모델로 승급

이 구조가 좋은 이유는 두 가지다. 첫째, 평균 비용이 내려간다. 둘째, 비싼 모델을 써야 할 순간에 예산을 집중할 수 있다.

이때는 비용 통제도 중앙에서 해야 한다. 멀티 벤더 게이트웨이나 공통 계층을 두면 팀별, 테넌트별, API 키별로 사용량과 예산을 관리하기 쉬워진다. 일부 게이트웨이 계열 도구들은 가상 키, 예산 상한, 모델 allow-list, 레이트 리밋, 비용 추적을 중앙에서 적용하도록 설계되어 있다.⁴

또 하나 실무에서 놓치기 쉬운 것이 캐싱이다. 대화형 서비스나 반복되는 시스템 프롬프트는 같은 입력이 자주 다시 들어온다. 이때 프롬프트 캐싱이나 응답 캐싱을 활용하면 지연 시간과 비용을 동시에 줄일 수 있다.⁵

비용 최적화는 결국 이런 질문으로 바뀐다.

"제일 싼 모델이 뭐지?"가 아니라 "어떤 요청은 싸게 보내도 되는가?"다.

이 질문을 제대로 하면 비용이 훨씬 건강해진다.

게이트웨이를 둘 것인가, 애플리케이션 안에서 처리할 것인가

멀티 벤더 설계에서 자주 나오는 갈림길이 있다.

벤더 어댑터와 라우팅을 우리 애플리케이션 안에 넣을까, 아니면 별도의 AI 게이트웨이로 뺄까?

정답은 상황에 따라 다르다.

초기 제품이라면 애플리케이션 내부에 얇은 추상화 계층을 두는 것으로 충분하다. 직접 HTTP 요청을 보내고, 인증과 응답 정규화, 예외 처리를 공통 함수로 묶는 것만으로도 상당한 효과가 있다.²

하지만 팀이 커지고, 여러 서비스가 같은 LLM 인프라를 함께 쓰기 시작하면 이야기가 달라진다. 그때는 게이트웨이 계층이 강해진다. 중앙에서 라우팅, 인증 관리, 비용 통제, 로그 수집, 레이트 리밋, 폴백 규칙을 맡길 수 있기 때문이다.³

구조를 단순하게 그리면 이렇다.

Client / Frontend
        |
Application API
        |
   LLM Service Layer
        |
  Model Router / Policy Engine
   |        |         |
Adapter   Adapter   Adapter
(OpenAI) (Claude)  (Gemini)
   |        |         |
Provider APIs / Managed Platforms

조금 더 커지면 가운데를 별도 게이트웨이로 뺄 수 있다.

여러 애플리케이션
        |
     AI Gateway
  - auth / budgets
  - routing / fallback
  - logging / tracing
  - caching / rate limits
        |
OpenAI / Anthropic / Google / Bedrock ...

작게 시작하고 싶다면 애플리케이션 내부 추상화가 낫다. 여러 팀이 공유하고, 정책을 중앙에서 통제해야 하고, 공급자가 계속 늘어난다면 게이트웨이가 낫다.

핵심은 "처음부터 거대한 플랫폼을 만들자"가 아니다. 복잡도가 생길 지점을 미리 알고, 그때 꺼내 쓸 구조를 준비하자는 것이다.

관측 가능성이 없으면 멀티 벤더는 오히려 독이 된다

벤더가 하나일 때도 로그는 중요하다. 벤더가 여러 개가 되면 더 이상 중요가 아니라 생존 조건이 된다.

왜냐하면 실패 원인이 훨씬 다양해지기 때문이다. 느린 건 모델 때문인지, 우리 네트워크 때문인지, 특정 리전 문제인지, JSON 검증 실패 때문인지, 폴백 체인이 너무 길어서인지, 예산 정책에 막힌 것인지 구분해야 한다.

좋은 멀티 벤더 시스템은 최소한 아래 정보는 중앙에서 본다.³⁵

• 어떤 요청이 어느 벤더, 어느 모델로 라우팅되었는가

• 입력/출력 토큰과 추정 비용은 얼마인가

• 첫 토큰까지의 시간과 전체 응답 시간은 얼마인가

• 오류 코드는 무엇이며, 재시도와 폴백이 몇 번 발생했는가

• 구조화 출력 검증은 통과했는가

• 어떤 프롬프트 버전이 사용되었는가

• 어떤 테넌트와 어떤 사용자 키가 호출했는가

AWS 쪽의 멀티 프로바이더 게이트웨이 가이드도 로그, 캐시, 시크릿 관리, 클러스터 모니터링, 다중 가용 영역 운영을 함께 강조한다. 이유는 단순하다. 멀티 벤더는 모델 호출 문제가 아니라 결국 운영 시스템 문제이기 때문이다.⁵

운영 지표 중 특히 중요한 것은 세 가지다.

첫째, fallback ratio다. 전체 요청 중 몇 퍼센트가 원래 모델이 아니라 백업 경로를 탔는지 보는 지표다. 이 비율이 갑자기 오르면 장애의 전조일 수 있다.¹

둘째, schema validation failure rate다. 응답은 왔는데 JSON 파싱이나 필드 검증에 실패하는 비율이다. 멀티 벤더에서는 이 값이 생각보다 중요하다. 서비스는 "응답이 왔다"가 아니라 "쓸 수 있는 응답이 왔다"를 봐야 한다.

셋째, cost per successful task다. 요청당 비용이 아니라, 실제로 유효한 결과 하나를 만드는 데 얼마가 들었는지 보는 지표다. 재시도와 폴백이 많아질수록 이 숫자가 크게 달라진다.

교체 가능성을 진짜로 만들려면 운영 절차도 바꿔야 한다

아키텍처만 잘 짜 두면 벤더 교체가 자동으로 쉬워질 것 같지만, 현실은 절반만 맞다. 나머지 절반은 운영 습관에 달려 있다.

예를 들어 모델을 바꿀 때 그냥 설정 파일의 문자열만 바꾸는 것은 위험하다. 응답 길이, 말투, 툴 선택 성향, 구조화 출력 안정성, 지연 시간이 미묘하게 달라질 수 있기 때문이다.

그래서 교체 가능성을 실제 능력으로 만들려면 다음 절차가 필요하다.

먼저 대표 평가 세트를 운영해야 한다. 요약, 분류, 문서 분석, 멀티모달 해석, 툴 호출처럼 서비스 핵심 기능별로 샘플 요청을 모아 두고, 모델 교체 전후를 항상 비교해야 한다.

그다음 모델 alias를 써야 한다. summary.standard가 현재는 OpenAI 계열을 가리키다가 다음 달에는 Claude 계열을 가리켜도, 애플리케이션 코드가 모르게 해야 한다.

그리고 가능하면 canary나 shadow traffic를 쓴다. 전체를 한 번에 바꾸지 말고 일부 트래픽만 새 모델에 보내 보자. 또는 사용자는 기존 응답을 받되, 백그라운드에서 새 모델도 함께 호출해 품질과 비용을 비교해 볼 수 있다.

교체 가능성은 선언으로 생기지 않는다. 비교하고, 검증하고, 천천히 바꾸는 절차에서 생긴다.

어디까지 추상화하고, 어디서 벤더 차이를 드러낼까

멀티 벤더를 하다 보면 또 하나의 함정이 생긴다. 모든 것을 완벽하게 공통 API로 감싸려는 욕심이다.

물론 공통 계층은 중요하다. 하지만 모든 벤더의 고유 기능까지 완전히 평평하게 만들려고 하면, 오히려 가장 약한 공통분모만 남는다.

예를 들어 어떤 벤더는 멀티모달이 특히 강하고, 어떤 벤더는 긴 문맥과 문서 처리에 강하며, 어떤 벤더는 특정 툴 호출 방식이 더 편할 수 있다. 이런 차이를 모두 지워 버리면 서비스가 얻을 수 있는 장점도 같이 사라진다.

그래서 실전에서는 보통 두 층으로 나눈다.

공통층에서는 채팅, 요약, 분류, 구조화 출력, 기본 툴 호출처럼 대부분 서비스가 공통으로 쓰는 기능만 추상화한다. 그리고 고급층에서는 벤더 고유 기능을 "escape hatch"처럼 열어 둔다.

쉽게 말해 이런 느낌이다.

• 공통 계층: 교체 가능성, 폴백, 비용 통제, 기본 라우팅 보장

• 확장 계층: 특정 벤더만의 고유 기능을 선택적으로 사용

이렇게 해야 서비스의 뼈대는 벤더 중립적으로 유지하면서도, 필요할 때는 특정 벤더의 장점을 적극적으로 쓸 수 있다.

좋은 추상화는 모든 차이를 없애는 것이 아니라, 바뀌면 위험한 차이만 숨기고, 전략적으로 쓰고 싶은 차이는 드러내는 것이다.

언제 멀티 벤더가 과한가

여기까지 읽으면 "그럼 무조건 멀티 벤더로 가야겠네"라고 생각하기 쉽다. 하지만 꼭 그렇지는 않다.

아직 기능이 하나뿐이고, 트래픽도 작고, 장애가 나도 치명적이지 않고, 팀도 아주 작다면 처음부터 복잡한 게이트웨이를 만드는 것은 과할 수 있다. 그런 경우에는 싱글 벤더 + 교체 준비가 된 인터페이스 정도면 충분하다.

즉 이렇게 시작하면 된다.

• 처음엔 주 벤더 하나만 붙인다.

• 하지만 비즈니스 코드는 벤더 SDK를 직접 모르게 한다.

• 모델 이름 대신 alias를 쓴다.

• 응답 정규화와 오류 분류는 처음부터 공통 계층에 둔다.

• 최소한의 백업 경로는 설계 문서에라도 정의해 둔다.

이렇게 하면 오늘은 단순하게 가되, 내일 멀티 벤더로 커질 여지는 남길 수 있다.

실전에서 가장 좋은 구조는 "처음부터 가장 거대한 구조"가 아니라, 지금 필요한 복잡도만 쓰면서 다음 단계로 자랄 수 있는 구조다.

정리

이 장의 핵심은 하나다. 실전 LLM 서비스에서 중요한 것은 최고의 모델을 고르는 능력보다, 모델을 갈아탈 수 있게 설계하는 능력이다.

멀티 벤더 아키텍처의 출발점은 벤더 수가 아니다. 내부 계약이다. 애플리케이션은 작업 종류, 기능 요구사항, 비용 정책, 신뢰성 요구만 말하고, 실제 벤더 차이는 어댑터와 라우터가 흡수해야 한다.

그 위에 capability registry가 올라가고, 라우터는 정책 엔진이 되며, 장애 시에는 재시도, 같은 벤더 대체 모델, 다른 벤더 폴백, 축소 응답까지 계층적으로 움직여야 한다. 비용 최적화 역시 "싼 모델 찾기"가 아니라 "어떤 요청을 어떤 티어로 보낼지"를 정하는 문제다. 그리고 이 모든 것은 결국 중앙 로그, 비용 추적, 오류 분석, 폴백 비율 같은 관측 가능성이 받쳐 줄 때만 운영 가능해진다.

좋은 멀티 벤더 설계는 화려한 기술 쇼가 아니다. 장애가 나도 답이 나오고, 가격이 바뀌어도 규칙만 고치면 되고, 모델이 바뀌어도 서비스 코드가 흔들리지 않는 구조다.

한마디로 말하면 이렇다.

모델을 붙이는 팀은 기능을 만든다. 모델을 갈아끼울 수 있게 만드는 팀은 서비스를 운영한다.

참고

¹Multi-Provider LLM: How to Stop Depending on a Single API

²Build a Multi-Provider LLM Gateway

³How to Build a Multi-Provider LLM Infrastructure with an AI Gateway

⁴Your LLM stack is fragmented. Here's how to fix it with LiteLLM

⁵Guidance for Multi-Provider Generative AI Gateway on AWS

⁶How to Build an LLM Fallback Strategy for Production AI Applications