자금을 낭비하지 않고 AI 벤더를 선택하는 방법

6개월 전, 저와 공동 창업자는 40만 달러에 달하는 클라우드 청구서를 마주하고 있었고, 그중 약 60%가 단일 LLM (Large Language Model) 제공업체로 인해 발생했습니다. 우리는 자금(runway)을 빠르게 소진하고 있었습니다. 그때 저는 일주일 내내 벤더 선정에 몰두하여 제가 손에 넣을 수 있는 모든 것을 벤치마킹했고, 통합 게이트웨이(unified gateway)를 중심으로 우리의 추론 계층(inference layer)을 재구축했습니다. 제가 OpenAI에 첫 수표를 쓰기 전에 누군가 저에게 말해줬더라면 좋았을 내용들을 공유합니다.

요약(TL;DR): 적절한 AI 벤더를 선택하는 것은 조달(procurement) 작업이 아니라 아키텍처 결정입니다. 잘못 선택하면 6개월 안에 스택의 절반을 다시 작성해야 할 것입니다. 제대로 선택하면 비용을 절반으로 줄이고, 더 빠르게 제품을 출시하며, 더 편안하게 잠들 수 있습니다. 제가 현재 이 문제를 어떻게 생각하는지, 2026년의 실제 수치는 어떤 모습인지, 그리고 오늘 바로 여러분의 저장소(repo)에 붙여넣을 수 있는 Python 코드 스니펫을 안내해 드리겠습니다.

벤더 종속(Vendor Lock-In)이 진짜 위험인 이유

제가 대화하는 대부분의 CTO들은 모델 품질 벤치마크에 집착합니다. 품질은 중요하지만, 그것이 여러분을 망하게 하지는 않습니다. 벤더 종속(Vendor Lock-in)이 여러분을 망하게 할 것입니다.

OpenAI의 SDK, Anthropic의 SDK, 또는 Google의 SDK를 사용하여 직접 구축할 때, 여러분은 단순히 토큰(tokens)을 사는 것이 아닙니다. 여러분은 특정 툴체인(toolchain), 특정 응답 형태(response shapes), 특정 스트리밍 동작(streaming behavior), 그리고 특정 과금 관계를 사는 것입니다. 해당 제공업체가 가격을 인상하거나, 속도 제한(rate-limited)이 걸리거나, 서비스 중단(outage)이 발생하는 날, 여러분은 꼼짝달싹 못 하게 됩니다. 저는 제가 자문을 제공했던 세 회사가 정확히 이 문제로 어려움을 겪는 것을 목격했습니다. 그중 한 회사는 지역적 서비스 중단 동안 페일오버(failover) 방식이 엔지니어링 채널에 5분 동안 Slack 메시지를 보내는 것이었기 때문에 일주일 치의 수익을 잃었습니다.

제가 최종적으로 결정한 아키텍처이자, 이 글을 읽는 모든 스타트업 CTO에게 추천하고 싶은 아키텍처는 애플리케이션 코드와 현재 사용 중인 모델 제공업체 사이에 위치하는 얇은 추상화 계층(abstraction layer)입니다. 이 추상화는 단순히 OpenAI와 호환되는 HTTP 엔드포인트(endpoint)일 뿐이며, 이는 시장에 있는 말 그대로 모든 모델이 동일한 프로토콜을 사용한다는 것을 의미합니다. 오늘 한 제공업체를 가리키고, 내일 다른 업체로 교체하더라도 여러분의 애플리케이션 코드는 변경되지 않습니다.

Global API 팀은 정확히 이런 종류의 게이트웨이를 구축했으며, 제가 실제 운영 환경 (production)에서 사용하는 것이기도 합니다. 이는 모든 주요 연구소의 184개 모델을 전면에 내세운 통합 API 표면 (unified API surface)입니다. 여러분은 코드베이스에 하나의 클라이언트와 하나의 결제 관계만 유지하면 되며, 재배포 없이도 모델들을 A/B 테스트할 수 있습니다. 이것이 바로 정석입니다.

솔직하게 말하는 2026년 가격 환경

실제 수치를 말씀드리겠습니다. 비용을 예측할 때 실제로 고려하게 될 방식인 100만 토큰당 가격으로 나열하겠습니다.

DeepSeek V4 Flash는 128K 컨텍스트 윈도우 (context window)를 제공하며, 입력 $0.27, 출력 $1.10입니다. 이는 제가 트래픽의 대부분을 처리하기 위해 사용하는 주력 모델입니다. DeepSeek V4 Pro는 입력 $0.55, 출력 $2.20이며, 긴 문서 분석을 훌륭하게 처리하는 200K 컨텍스트 윈도우를 갖추고 있습니다. Qwen3-32B는 입력 $0.30, 출력 $1.20에 32K 컨텍스트를 제공합니다. GLM-4 Plus는 입력 $0.20, 출력 $0.80의 초저가형 모델로, 128K 컨텍스트를 지원합니다. 분류 (classification) 및 추출 (extraction) 작업에 매우 견고합니다.

그다음 GPT-4o는 입력 $2.50, 출력 $10.00에 128K 컨텍스트입니다. 보세요, GPT-4o는 훌륭한 모델입니다. 저도 사용해 봤습니다. 하지만 2026년에 출력 토큰 100만 개당 $10를 지불하는 것은 기본값이 아니라 하나의 선택 사항입니다. 대부분의 운영 워크로드 (production workloads)에서 오픈 웨이트 (open-weight) 대안 모델들이 품질 격차를 상당히 좁혔으며, 비용 차이는 수익성 있는 분기를 보내느냐 아니면 추가 투자 유치 (fundraising round)를 하느냐의 차이를 만듭니다.

제 회사를 위해 계산을 해보았을 때, 트래픽의 약 70%를 DeepSeek V4 Flash로, 저렴한 쿼리를 위해 20%를 GLM-4 Plus로 라우팅하고, 가장 어려운 10%의 요청을 위해 GPT-4o를 폴백 (fallback)으로 유지하도록 설정했더니 추론 (inference) 비용을 58% 절감했습니다. 이 단 하나의 아키텍처 결정이 우리의 런웨이 (runway)를 4개월 연장해 주었습니다.

여러분에게 필요한 즉시 적용 가능한 코드

여기 코드 스니펫이 있습니다. 이를 붙여넣고 환경 변수를 설정하면 게이트웨이를 통해 라우팅이 시작됩니다:

import openai
import os

...

그게 전부입니다. 통합 과정은 이것으로 끝납니다. 게이트웨이가 OpenAI 와이어 프로토콜 (wire protocol)을 지원하기 때문에, 여러분은 공식 OpenAI Python SDK를 그대로 사용하게 됩니다. 즉, 기존의 에러 핸들링 (error handling), 재시도 로직 (retry logic), 스트리밍 (streaming) 코드가 모두 그대로 작동한다는 의미입니다. 새로운 프레임워크를 채택하는 것이 아니라, 단 하나의 베이스 URL (base URL)만 변경하는 것입니다.

스트리밍 (streaming)의 경우, 플래그 (flag)만 전환하면 됩니다:

stream = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4-Flash",
    messages=[{"role": "user", "content": "Explain RAG to a senior backend engineer."}],
...

동일한 SDK, 동일한 패턴을 사용하면서 내부적으로만 다른 제공자 (provider)를 사용하는 방식입니다. 만약 특정 엔드포인트 (endpoint)에서 비용보다 품질이 더 중요하다고 판단하여 DeepSeek V4 Flash에서 GPT-4o로 전환하기로 결정한다면, 문자열 하나만 바꾸면 됩니다. 이것이 바로 추상화 (abstraction)가 제값을 하는 방식입니다.

프로덕션 환경에서 라우팅 (Routing)을 바라보는 관점

제가 계속해서 되돌아오게 되는 아키텍처 패턴은 계층형 라우팅 (tiered routing)이라고 불리는 것입니다. 들어오는 요청을 난이도에 따라 분류하고 그에 따라 라우팅하는 방식입니다. 단순한 분류, 짧은 추출, 감성 분석(sentiment analysis) 등 답변이 짧고 프롬프트 (prompt)가 구조화된 작업인가요? 그렇다면 이를 처리할 수 있는 가장 저렴한 모델로 보내십시오. 복잡한 추론 (reasoning), 다단계 계획 (multi-step planning), 혹은 잘못된 답변이 고객의 신뢰를 잃게 만드는 작업인가요? 그렇다면 비용이 더 드는 모델로 보내십시오.

구체적으로, 저의 라우터 (router)는 세 가지 신호(signal)를 확인합니다: 프롬프트 길이, 작업 유형 (경량 분류기 또는 키워드 휴리스틱 (heuristic)을 통해 감지), 그리고 프리미엄 응답에 비용을 지불하는 엔터프라이즈 고객을 위한 테넌트별 (per-tenant) 품질 요구 사항 플래그입니다. 각 신호는 특정 모델로 매핑됩니다. 라우팅 로직 자체는 파이썬 (Python) 코드로 약 80줄 정도입니다.

이 방식의 ROI (투자 대비 효율)는 엄청납니다. 모든 것을 GPT-4o로 보내던 이전의 기준점 (baseline)과 비교했을 때 비용을 62% 절감했으며, 고객 만족도 차이는 2% 미만이었습니다. 이는 고민할 필요도 없는 이득이 큰 거래입니다.

캐싱 (Caching)은 선택이 아닌 필수입니다

이 점은 아무리 강조해도 지나치지 않습니다. 만약 애플리케이션 계층 (Application Layer)에서 LLM 응답을 캐싱 (Caching)하고 있지 않다면, 당신은 돈을 길바닥에 버리고 있는 것과 다름없습니다. 대부분의 프로덕션 트래픽 (Production Traffic)에는 상당한 반복성이 존재합니다. 사용자들은 동일한 질문을 던집니다. 에이전트 (Agents)는 동일한 도구 (Tools)를 호출합니다. RAG 파이프라인 (RAG Pipelines)은 동일한 문서에 접근합니다.

저는 2단계 캐시 (Two-tier cache)를 사용합니다. 밀리초 미만의 히트 (Hit) 속도를 가진 핫 키 (Hot keys)를 위한 인메모리 (In-memory) LRU와, 그 외의 모든 것을 위한 24시간 TTL (Time-to-Live) 설정의 Redis를 사용합니다. 제 워크로드 (Workloads)에서 히트율 (Hit rate)은 약 40%를 유지합니다. 이는 요청이 제 서버를 떠나지 않기 때문에, 추론 (Inference) 비용의 40%가 그냥 사라진다는 것을 의미합니다.

구현은 매우 간단합니다:

import hashlib
import json
from functools import lru_cache
...

정규화된 요청 (Normalized request)을 해싱 (Hash)하고, 조회한 뒤, 히트되면 반환합니다. 미스 (Miss)가 발생하면 게이트웨이 (Gateway)로 전달하고 결과를 다시 기록합니다. 재무 책임자가 AI 항목에 대해 불편한 질문을 던지는 것을 멈추게 될 때, 저에게 감사하게 될 것입니다.

사용자 경험과 비용을 위한 스트리밍 (Streaming)

이 부분은 조금 더 미묘합니다. 응답 스트리밍 (Streaming responses)은 체감 지연 시간 (Perceived latency)을 극적으로 개선하며, 실제로 비용 절감에도 도움이 됩니다. 사용자가 원하는 답이 아니라는 것을 깨달았을 때 생성을 중단할 수 있기 때문입니다. 제 분석 결과에 따르면, 스트리밍된 응답의 약 15%는 처음 몇 개의 토큰 (Tokens)만으로 사용자에게 필요한 모든 정보를 전달했기 때문에 생성 중간에 취소됩니다.

이러한 취소 동작은 실제로 비용을 절약해 줍니다. 스트리밍을 사용하지 않았다면 전체 응답을 생성하고 그 비용을 모두 지불했을 것입니다. 스트리밍을 사용하면 사용자가 실제로 소비한 부분에 대해서만 비용을 지불합니다. 공격적인 취소 타임아웃 (Cancellation timeouts, 대부분의 엔드포인트에 대해 8초로 제한)과 결합하면, 이는 비용 절감에 12%를 추가로 더해줍니다.

또 다른 이점은 UX (User Experience)입니다. 400ms 미만의 첫 번째 토큰 지연 시간 (First-token latency)은 인간에게 즉각적인 것처럼 느껴집니다. 반면 1.2초의 전체 응답 생성은 그에 비해 느리게 느껴집니다. 스트리밍은 그 체감 격차를 좁혀주며, 사용자는 경험에 대해 더 높은 점수를 줍니다. 이것이 바로 NPS (Net Promoter Score) 점수에 나타나는 요소입니다.

비용뿐만 아니라 품질을 모니터링하기

대부분의 팀이 실수를 저지르는 지점이 바로 여기입니다. 비용을 최적화하고 6주가 지나면, 더 저렴한 모델이 자신들의 특정 워크로드(workload)에서 20%의 확률로 환각 (hallucination) 현상을 일으키고 있다는 사실을 깨닫게 됩니다. 그러면 그들은 평판 손상을 수습하는 데 급급하게 됩니다.

해결책은 지연 시간 (latency)을 측정하는 것과 동일한 방식으로 품질을 계측 (instrument) 하는 것입니다. 제 제품의 경우, 모든 응답의 1%를 샘플링하여 보조 LLM 판사 (LLM judge)를 통해 정확성 (accuracy), 관련성 (relevance), 그리고 어조 (tone)를 점수화합니다. 저는 모델별로 세분화하여 시간에 따른 점수를 추적합니다. 모델의 품질이 설정한 임계값 (threshold) 아래로 떨어지면 저에게 페이지 (paged) 알림이 옵니다.

또한 사용자 대면 신호 (user-facing signals)도 추적합니다: 추천/비추천 (thumbs up/down) 비율, AI 응답 이후의 세션 길이, 그리고 환불 요청 등이 있습니다. 이것들은 LLM 판사보다 노이즈가 더 많지만, 실질적인 정답 (ground truth)입니다. 만약 품질 지표는 모든 것이 괜찮다고 말하는데 비추천 비율이 상승하고 있다면, 인간을 믿으세요.

게이트웨이 (gateway)에서 확인되는 처리량 (throughput) 수치는 지속적으로 초당 320 토큰이며, 평균 엔드 투 엔드 지연 시간 (end-to-end latency)은 1.2초입니다. 이는 대화형 워크로드 (interactive workloads)에 충분히 빠른 속도이며, 게이트웨이가 커넥션 풀링 (connection pooling)과 요청 배치 (request batching)를 대신 처리해주기 때문에 모델 티어 (model tiers) 전반에 걸쳐 지연 시간이 일정하게 유지됩니다.

벤치마크 점수와 그것이 실제로 의미하는 것

제 테스트의 핵심 수치는 다음과 같습니다: 게이트웨이에서 평가한 모델들의 평균 벤치마크 점수는 84.6%였습니다. 여기에는 MMLU 하위 집합, HumanEval, 그리고 제가 제 도메인을 위해 구축한 일부 맞춤형 평가 세트가 포함되어 있습니다.

하지만 벤치마크에 대해 알아두어야 할 점이 있습니다: 벤치마크는 방향성을 제시할 뿐, 절대적인 수치가 아닙니다. MMLU에서 87%를 기록한 모델이 귀하의 특정 프롬프트 분포 (prompt distribution)에서는 72%를 기록할 수도 있습니다. 귀하의 프롬프트를 대상으로 직접 평가 스위트 (eval suite)를 실행해야 합니다. 저는 리더보드 (leaderboard) 점수만을 보고 모델을 선택했다가 프로덕션 (production) 환경에서 실망하는 팀을 얼마나 많이 보았는지 셀 수 없을 정도입니다.

저의 조언은 이렇습니다. 실제 프로덕션 (production) 트래픽에서 추출한 200~500개의 대표적인 프롬프트로 골든 세트 (golden set)를 구축하십시오. 모든 후보 모델을 대상으로 이를 실행하십시오. 비용, 지연 시간 (latency), 그리고 품질을 측정하십시오. 그런 다음 선택하십시오. 이 모든 과정은 주말이면 충분하며, 수억 원대의 실수를 방지해 줄 것입니다.

문제가 발생했을 때를 위한 폴백 (Fallback) 전략

속도 제한 (rate limits)은 발생합니다. 서비스 중단 (outages)도 발생합니다. 저는 토요일 새벽 2시에 제공업체가 다운되어 정오가 되어서야 복구된 경험이 있습니다. 만약 당신의 제품 전체가 단일 모델 제공업체에 의존하고 있다면, 그것은 당신의 문제입니다.

제가 운영하는 아키텍처에는 세 가지 계층의 폴백 (fallback)이 있습니다. 첫째, 동일한 게이트웨이 (gateway) 내의 모델 간 폴백으로, 이는 자동적이고 빠릅니다. 둘째, 기본 제공업체에 지역적 이슈가 발생할 경우 게이트웨이 간의 폴백입니다. 셋째, 가장 흔한 쿼리에 대해 캐싱된 "최선 노력 (best effort)" 응답을 제공하여, 다른 모든 것이 실패하더라도 사용자가 유용한 무언가를 받을 수 있도록 합니다.

이를 코드로 구현하는 것은 간단합니다:

def call_with_fallback(messages, primary_model, fallback_model):
    try:
        return client.chat.completions.create(
...

이것이 최소 기능 제품 (MVP) 수준의 회복 탄력성 (resilience) 계층입니다. 프로덕션 환경에서는 서킷 브레이커 (circuit breakers), 큐잉 (queueing), 그리고 아마도 실패한 요청을 위한 데드 레터 패턴 (dead-letter pattern)이 필요하겠지만, 기본적인 형태는 동일합니다. 좋은 옵션을 시도하고, 괜찮은 옵션으로 폴백하며, 절대 완전히 실패하지 않도록 하는 것입니다.

반복 속도는 숨겨진 지표입니다

제가 통합 게이트웨이 (unified gateway) 접근 방식을 계속 고집하는 이유는 반복 (iteration) 속도 때문입니다. 새로운 모델을 테스트하고 싶을 때, 저는 설정 파일의 문자열 하나만 바꾸고 다시 배포합니다. 제공업체가 새 버전을 출시하면, 확정하기 전에 트래픽의 5%를 대상으로 현재 프로덕션 모델과 A/B 테스트를 할 수 있습니다. 가격이 변하면 오후 한때에 경로를 재설정할 수 있습니다.

만약 제가 개별 제공업체의 SDK를 직접 사용하여 구축했다면, 이러한 변화 하나하나가 며칠이 걸리는 엔지니어링 프로젝트가 되었을 것입니다. SDK를 업데이트하고, 새 모델을 테스트하고, API 차이를 처리하고, 에러 핸들링을 업데이트하고, 전체 QA 스위트 (QA suite)를 실행해야 했을 것입니다. 그것은 반복 (iteration)이 아니라 고고학입니다.

모델 선택을 더 빠르게 반복 (iterate)할 수 있을수록, 비용과 품질을 더 빠르게 최적화할 수 있습니다. 이는 복리 (compounding) 효과를 가진 이점입니다. 최적의 모델 조합 (model mix)을 운영하는 매달은 돈을 절약하는 것이지만, 전환 과정이 고통스럽다는 이유로 최적화되지 않은 모델에 머물러 있는 매달은 돈을 낭비하는 것입니다.

나의 현재 프로덕션 설정 (Production Setup)

제가 실제로 무엇을 운영하고 있는지 궁금한 분들을 위해 말씀드리자면: DeepSeek V4 Flash가 제 트래픽의 약 60%를 처리하며, 이는 일반적인 목적의 생성 (generation) 작업의 대부분을 차지합니다. GLM-4 Plus가 나머지 25%를 처리하며, 주로 비용이 가장 중요한 분류 (classification), 추출 (extraction), 그리고 단문 생성 (short-form generation)을 담당합니다. DeepSeek V4 Pro는 10%를 처리하며, 긴 컨텍스트 작업 (long-context jobs)과 복잡한 추론 (reasoning) 작업을 수행합니다. GPT-4o는 나머지 5%를 위한 폴백 (fallback)으로, 제가 진정으로 가용한 최고의 모델이 필요한 쿼리들에 사용됩니다.

이 설정을 완료하는 데 10분도 걸리지 않았습니다. 이것은 마케팅 문구가 아니라 실제 측정값입니다. 제가 궁금해서 직접 시간을 재보았습니다. 계정을 생성하고, API 키를 가져오고, 베이스 URL (base URL)을 교체하고, 테스트 요청을 실행하는 데 실제 작업 시간은 약 8분이 소요되었습니다.

오늘 시작하는 CTO에게 해주고 싶은 말

만약 당신이 지금 AI 벤더 (vendor)를 선정하고 있다면, 저의 의사결정 프레임워크 (decision framework)는 다음과 같습니다: