Claude · Gemini · OpenAI를 한 코드베이스에서 — 멀티 LLM 아키텍처

결론 한 단락

Songstark은 사내 4개 프로덕트(automation · band-ai · history-book · veltis-ai-studio)에서 Claude · Gemini · OpenAI를 한 코드베이스에서 동시에 사용한다. 라우팅은 도메인별 강점 매핑(텍스트 reasoning → Claude, 이미지/영상 → Gemini, 임베딩/정형 → OpenAI)으로 결정되며, SDK 추상화 레이어 한 장만 있으면 단일 호출 인터페이스 뒤에서 모델을 자유롭게 바꿀 수 있다. 이 글은 그 라우팅 패턴과 운영 시 마주친 함정을 정리한다.

왜 한 모델에 고정하지 않는가

"AI 외주" 의뢰의 절반은 "Claude로 짜 주세요" 또는 "OpenAI로 짜 주세요"로 시작한다. 우리는 그 요청을 받으면 거의 항상 한 단계 되묻는다 — "이 워크플로우 안에서 모든 단계가 같은 모델일 필요가 있습니까?"

대답은 거의 "아니오"다. 같은 워크플로우 안에서도 다음 작업은 서로 다른 모델이 정답이다.

• 긴 한국어 reasoning + tool use: Claude Sonnet/Opus
• 이미지·영상 분석, 멀티모달: Gemini 2.5 Pro / Flash
• 임베딩 (cost per 1M tokens): OpenAI text-embedding-3-large
• 싸고 빠른 구조화 응답 (JSON 출력): Gemini Flash 또는 Claude Haiku
• 음성·비디오 transcription: Whisper (OpenAI) 또는 Google STT

한 모델에 고정하면 반드시 어느 한 단계가 손해를 본다. 멀티 LLM이 "복잡함"이 아니라 "기본값"이라는 게 우리의 운영 결론이다.

라우팅 코드가 SDK 추상화 한 장이면 된다는 것

복잡해 보이지만 실제로 필요한 코드는 한 함수다. Vercel AI SDK 또는 자체 thin wrapper로 모델을 인자로 받는 단일 호출을 만들고, 호출처에서 작업 종류에 따라 모델 ID만 바꾼다.

// lib/ai/route.ts
import { generateText } from 'ai';
import { anthropic } from '@ai-sdk/anthropic';
import { google } from '@ai-sdk/google';
import { openai } from '@ai-sdk/openai';

const MODELS = {
  'long-reasoning': anthropic('claude-sonnet-4-6'),
  'cheap-structured': google('gemini-2.5-flash'),
  'multimodal': google('gemini-2.5-pro'),
  'embedding': openai.embedding('text-embedding-3-large'),
} as const;

export async function route(
  task: keyof typeof MODELS,
  prompt: string,
) {
  const model = MODELS[task];
  return generateText({ model, prompt });
}

호출처는 모델을 모른다. 이게 멀티 LLM 운영의 핵심이다 — 모델 교체를 1줄 변경으로 만들면, 가격·성능 변화에 따라 라우팅 표만 갱신하면 된다. Anthropic이 Sonnet 4.7을 내면 라우팅 표만 업데이트한다.

자사 사례

1. marea/automation — Computer Use + Gemini 이미지

마레아홀딩스 사내 운영 자동화 플랫폼은 KAIST 교수 대상 대량 아웃리치를 다음 흐름으로 돈다.

1. xlsx 업로드 → 파싱 (Node.js, AI 없음)
2. 교수 정보 → 개인화 이메일 초안 (Claude Sonnet, batch API)
3. 첨부 이미지 분석 (Gemini 2.5 Pro)
4. Resend 일괄 발송 (외부 API)

같은 워크플로우의 4단계가 4가지 다른 도구를 쓴다. 한 모델에 고정했다면 Claude는 이미지를 못 보고, Gemini는 batch 처리가 비효율적이라 비용이 두 배가 됐을 것이다.

2. history-book — Anthropic + Google 듀얼 SDK

한국사 기반 인터랙티브 픽션은 다음을 한 코드베이스에서 운영한다.

• 선택지 생성 / 본문 스트리밍: Claude Sonnet (긴 한국어 reasoning)
• AI 일러스트 생성: Gemini 2.5 Flash + Nano Banana 2 (이미지)
• 운영자 리포트: Gemini 2.5 Flash-Lite (싸고 빠른 요약)

/play 라우트의 단일 사용자 turn 안에서 두 SDK가 동시에 호출된다. 각자가 자기 일을 하고, 우리는 라우팅만 관리한다.

3. lms-ct — Gemini RAG + Function Calling 10개

기업 교육 LMS의 AI 챗봇은 Gemini 3 Flash + pgvector(3072d) RAG로 운영된다. Function Calling 도구가 10개(코스 진도, 과제, 성적, 비디오 시청률 등) — 단일 모델에서 도구 호출 안정성을 확보하는 게 멀티 LLM 사용보다 중요한 사례다.

여기서는 멀티 LLM을 안 썼다. 도구 호출 안정성은 한 모델 안에서 fine-tuning되어 있어, 모델을 섞으면 호출 패턴이 깨진다. **"멀티 LLM이 항상 정답은 아니다"**는 것도 같은 결론.

함정 6가지

1. 토큰 카운팅이 SDK마다 다르다

Anthropic의 tokenizer.counts와 OpenAI의 tiktoken은 토큰화 알고리즘이 다르다. 같은 한국어 문자열의 토큰 수가 두 배 차이 날 수 있다. 비용 추정은 모델별로 따로 측정해야 한다.

2. Streaming 형식이 다르다

Anthropic은 text_delta와 tool_use_delta가 별도 이벤트, OpenAI는 delta.content와 delta.tool_calls가 한 chunk 안. Vercel AI SDK가 통일하지만, raw SDK 직접 사용 시 두 가지 케이스를 따로 처리해야 한다.

3. Function Calling JSON 스키마가 다르다

Anthropic은 input_schema, OpenAI는 parameters, Gemini는 parameters. 도구 정의를 한 번 적고 SDK별로 변환하는 어댑터 함수를 만드는 게 표준이다.

4. 한국어 토큰 효율 차이

Claude의 토크나이저는 한국어를 어절 단위로 비교적 잘 처리하지만, OpenAI는 자모 단위로 자른다. 같은 의미의 한국어가 OpenAI에서 1.5~2배 더 비싸다. 한국어 텍스트 워크로드는 토큰 효율을 미리 측정해 두는 게 안전하다.

5. Rate limit 정책이 다르다

Anthropic은 분당 토큰(input_tokens_per_minute) 기준, OpenAI는 분당 요청(RPM) + 토큰(TPM) 둘 다, Gemini는 모델별로 다르다. 멀티 LLM 운영 시 라우팅 표 옆에 rate limit 표도 같이 관리한다.

6. 프롬프트 캐싱이 SDK마다 다르다

Anthropic은 cache_control: { type: 'ephemeral' }, OpenAI는 자동(50% 이상 일치 시), Gemini는 cachedContent 별도 객체. 캐싱 효과가 큰 워크플로우는 모델 선택에 영향을 준다.

정리 — 멀티 LLM은 "복잡함"이 아니라 "기본값"

한 모델에 고정하면 반드시 어느 한 단계가 손해를 본다. SDK 추상화 한 장만 있으면 모델 교체는 1줄 변경이고, 라우팅 표만 갱신하면 가격·성능 변화에 즉시 대응된다. 우리가 사내에서 Claude · Gemini · OpenAI를 동시에 운영하는 이유는 그게 더 빠르고 더 싸기 때문이다.

여러분 제품에 AI를 붙일 때 "Claude로 짜 주세요"가 아니라 "이 워크플로우의 각 단계에 맞는 모델을 골라 주세요"가 더 좋은 첫 질문이다. 문의 보내기 · AI/LLM 솔루션