6개월 전, 저는 클라우드 청구서를 보고 숨이 막힐 뻔했습니다. 우리는 본질적으로 요약 파이프라인 (summarization pipeline)을 위해 OpenAI 추론 (inference) 비용으로 매달 8,400달러를 태우고 있었습니다. 대단한 것도 아니었습니다. 미세 조정 (fine-tuned)된 괴물 모델도 아니었습니다. 그저 GPT-4o가 단순 반복 작업 (grunt work)을 수행하고 있었을 뿐입니다. 그 순간은 우리 엔지니어링 채널에서 벤더 종속 (vendor lock-in), 단위 경제성 (unit economics), 그리고 우리 단계에서 프로덕션 준비 (production-ready)가 된다는 것이 실제로 무엇을 의미하는지에 대한 냉정한 논의를 강제했습니다.

우리는 이주했습니다. 동일한 워크로드 (workload)에 대해 청구 금액이 월 약 210달러로 떨어졌습니다. 이것은 제가 14개월 차가 아닌 1개월 차에 누군가 건네주었기를 바랐던 플레이북 (playbook)입니다.

내가 OpenAI에 충성했던 이유 (그리고 그것이 왜 실수였는지)

솔직한 진실을 말씀드리자면, 저는 가장 저항이 적은 경로였기 때문에 기본적으로 OpenAI를 선택했습니다. SDK는 세련되었고, 문서 (docs)는 깔끔했습니다. 모든 블로그 포스트, 모든 튜토리얼, 모든 Stack Overflow 답변은 OpenAI를 기준점으로 가정했습니다. 그래서 저는 질문조차 던지지 않았습니다. 규모가 커졌을 때 이것이 실제로 우리에게 어떤 비용을 발생시키는가?

MVP를 출시하고 있으며 월 200달러를 쓰고 있을 때는 그 답이 중요하지 않습니다. 하지만 월 8,400달러를 쓰고 있고, 우리의 비용 소모율 (burn rate)이 브릿지 라운드 (bridge round)를 유치할지 여부를 결정하고 있다면, 그 답은 모든 것입니다. 그때가 되면 벤더 종속 (vendor lock-in)은 추상적인 아키텍처 (architecture) 문제가 아니라, CFO가 반드시 지적할 항목이 됩니다.

더 깊은 문제는 단순히 가격만이 아니었습니다. 우리가 전체 검색 증강 생성 (retrieval-augmented generation, RAG) 파이프라인, 평가 하네스 (eval harness), 그리고 비동기 워커 레이어 (async worker layer)를 OpenAI의 API 표면 (API surface)을 중심으로 구축했다는 점이었습니다. 전환하는 것은 비용이 많이 드는 것처럼 느껴졌습니다. 전환하는 것은 위험해 보였습니다. 전환하는 것은 결코 되돌릴 수 없는 엔지니어링 시간의 한 분기를 소모하는 것처럼 느껴졌습니다.

전환 비용에 대해 제가 틀렸었습니다. 엔지니어 한 명이 약 3일 정도 걸렸습니다. 왜 그런지 정확히 보여드리겠습니다.

나 자신에게 화가 나게 만든 가격 산출 방식

우리의 첫 번째 스프린트 계획 회의 (sprint planning meeting) 때 누군가 저에게 보여주었기를 바랐던 방식으로 수치를 보여드리겠습니다:

모델 (Model)	제공업체 (Provider)	입력 (Input) $/M	출력 (Output) $/M	GPT-4o보다 저렴함
GPT-4o	OpenAI	$2.50	$10.00	—
...

DeepSeek V4 Flash 행을 보십시오. 입력 $0.18, 출력 $0.25입니다. GPT-4o는 입력 $2.50, 출력 $10.00입니다. 생성 중심의 워크로드 (generation-heavy workload)에서 비중을 크게 차지하는 부분인 출력 토큰 (output tokens) 측면에서 보면, 무려 40배의 차이 (delta)가 발생합니다.

우리의 사용 사례 (use case)의 경우, OpenAI에서 $8,400이 들던 동일한 워크로드가 DeepSeek V4 Flash에서는 약 $210가 들었습니다. 우리는 대량 구매 할인 (volume discount)을 협상할 필요조차 없었습니다. 엔터프라이즈 계약 (enterprise contract)도 필요 없었습니다. 이것은 단지 표기 가격 (sticker price)일 뿐입니다.

이제 "40배 더 저렴하다"는 말은 실제로 워크로드를 실행해 보기 전까지는 마케팅 용어처럼 들릴 수 있습니다. 그래서 우리는 실행해 보았습니다. 우리는 2주 동안 50,000개의 문서 코퍼스 (corpus)를 대상으로 A/B 테스트를 진행했습니다. 품질은 유지되었습니다. 지연 시간 (latency)은 허용 범위 내에 있었습니다. 우리의 평가 스위트 (eval suite)는 우리가 중요하게 생각하는 지표들(사실적 일관성 (factual consistency), 스키마 준수 (schema adherence), 범위를 벗어난 쿼리에 대한 거부율 (refusal rates on out-of-scope queries))에서 어떠한 퇴보 (regression)도 감지하지 못했습니다. ROI 계산은 근소한 차이가 아니라, 압도적인 결과였습니다.

아키텍처 결정: 왜 OpenAI 호환성이 생각보다 더 중요한가

이제 LLM 인프라에 대해 묻는 모든 창업자에게 제가 하는 말은 다음과 같습니다: 특정 제공업체(provider)에 맞춰 구축하지 말고, 인터페이스 (interface)에 맞춰 구축하십시오.

OpenAI의 Chat Completions API는 사실상 공용어 (lingua franca)가 되었습니다. Anthropic의 호환성 레이어 (compatibility layer), 오픈 소스 (OSS) 생태계, 프록시 서비스 (proxy services) 등 모든 주요 모델 제공업체가 해당 요청/응답 형태 (request/response shape)를 지원합니다. 만약 여러분의 코드를 OpenAI SDK (또는 그 위의 얇은 추상화 계층)를 중심으로 구조화한다면, 오후 한나절 만에 제공업체를 교체할 수 있습니다.

우리는 워커 (workers)를 리팩터링 (refactor)할 필요가 없었습니다. 프롬프트 템플릿 (prompt templates)을 다시 쓸 필요도 없었습니다. 토큰 계산 (token counting), 재시도 로직 (retry logic), 스트리밍 핸들러 (streaming handlers)를 변경할 필요도 없었습니다. 우리는 단 두 가지 값만 변경했습니다:

• API 키 (API key)
• 기본 URL (base URL)

그게 전부입니다. 단 두 줄입니다. 전체 마이그레이션(migration)에는 엔지니어링 시간으로 오후 한나절이 소요되었고, 아무것도 망가지지 않았는지 확인하기 위한 하루의 평가(eval) 작업이 추가되었습니다. 비용은 미미했습니다. 절감된 비용은 영구적으로 지속됩니다.

이것은 제가 고생하며 배운 벤더 종속(vendor lock-in)에 관한 교훈입니다. 종속은 단순히 계약에 관한 것이 아닙니다. 당신의 추상화(abstractions)가 제공업체(provider)와 정렬되어 있는지, 아니면 기본 인터페이스 표준(interface standard)과 정렬되어 있는지에 관한 것입니다. 만약 당신이 제공업체와 정렬되어 있다면, 당신은 종속된 것입니다. 만약 당신이 표준과 정렬되어 있다면, 당신은 자유롭습니다.

실제 코드 (Python)

from openai import OpenAI

client = OpenAI(api_key="sk-...")
...

이것이 변경된 내용의 전부입니다. 동일한 임포트(import). 동일한 클라이언트 인스턴스화(instantiation) 패턴. 동일한 호출 시그니처(call signature). 동일한 응답 객체(response object). 만약 당신이 공식 openai Python SDK v1.x 이상을 사용하고 있다면, 라이브러리가 클라이언트 생성자(constructor)에서 base_url을 재정의(override)할 수 있게 해주기 때문에 이 방식은 즉시 작동합니다.

우리는 기존의 스트리밍(streaming) 코드, 기존의 도구 호출(tool-calling) 정의, 기존의 JSON 모드 플래그(flags)를 그대로 유지했습니다. SDK 호출 이후의 모든 다운스트림(downstream) 요소들은 전혀 건드리지 않았습니다.

Go에 관한 짧은 언급

우리의 인제스션(ingestion) 워커들은 처리량(throughput) 문제로 인해 Go로 작성되었습니다. 우리는 한 달에 약 200만 개의 문서를 처리하고 있으며, I/O 바운드(I/O-bound) 청크(chunks)를 처리하는 데 Python은 충분하지 않았습니다. 동일한 트릭이 Go에서도 작동하는데, 커뮤니티에서 관리하는 sashabaranov/go-openai 라이브러리가 동일한 재정의(override) 기능을 제공하기 때문입니다:

config := openai.DefaultConfig("ga_xxxxxxxxxxxx")
config.BaseURL = "https://global-apis.com/v1"
client := openai.NewClientWithConfig(config)
...

동일한 OpenAI 호환 클라이언트. 동일한 모델 사양(spec). 다른 엔드포인트(endpoint). 우리의 Go 워커들은 비즈니스 로직(business-logic) 리팩토링을 단 한 줄도 할 필요가 없었습니다.

기능 호환성: 포기해야 하는 것과 유지되는 것

저는 트레이드오프(tradeoffs)에 대해 솔직해지고 싶습니다. 왜냐하면 "프로덕션 준비 완료(production-ready)"라는 말은 실패 모드(failure modes)가 존재하지 않는 척하는 것이 아니라, 당신의 실패 모드를 알고 있다는 것을 의미하기 때문입니다.

Global API를 통해 동일하게 작동하는 것:

• Chat completions (당연히 — 이것이 마이그레이션 경로입니다)
• Server-sent events (SSE) 스트리밍
• Function calling (함수 호출) / tool use (도구 사용), OpenAI와 동일한 스키마
• response_format을 통한 JSON mode (JSON 모드)
• 멀티모달 모델에서의 Vision (시각) 입력 (문서 이미지의 경우 Qwen-VL을 사용합니다)
• Embeddings (임베딩) (현재 대부분의 제공업체에서 사용 가능)

작동하지 않거나 사용할 수 없는 것:

• Fine-tuning (미세 조정) — 만약 당신의 해자 (moat)가 미세 조정된 모델에 의존한다면, OpenAI를 계속 사용하거나 자체 호스팅을 해야 합니다. 저희는 미세 조정을 하지 않으므로, 이 부분은 저희에게 문제가 되지 않았습니다.
• Assistants API (threads, runs, 전체 관리형 런타임) — 만약 이를 사용하고 있었다면, 직접 상태 계층 (state layer)을 구축해야 합니다. 솔직히 말해서, 직접 구축하는 것이 결국 옳은 선택이라고 생각합니다. Assistants API는 디버깅을 지옥으로 만드는 블랙박스입니다.
• TTS (텍T-to-Speech) 및 STT (Speech-to-Text) — 전용 서비스 (ElevenLabs, 자체 호스팅 Whisper 등)를 사용하세요. 멀티모달 I/O (입출력)를 LLM 제공업체를 통해 억지로 끼워 맞추지 마세요.

LLM 기능을 구축하는 스타트업의 95%에게

1. 일주일간의 Shadow traffic (섀도 트래픽). OpenAI로 향하는 요청의 10%를 Global API로 복제하여 병렬로 실행하고, 출력값을 비교하며 불일치율 (disagreement rates)을 추적했습니다. 이를 통해 사용자에게 영향을 주지 않으면서 미세한 품질 저하 (quality regressions)를 포착할 수 있었습니다.

2. 트래픽의 5%에 대한 Canary (카나리) 테스트. 섀도 트래픽 결과가 깨끗한 것을 확인한 후, 실제 운영 트래픽의 5%를 Global API를 통해 DeepSeek V4 Flash로 라우팅하고 표준 SLO (서비스 수준 목표)를 모니터링했습니다. 여기에는 latency p95 (95퍼센타일 지연 시간), 에러율 (error rate), 그리고 다운스트림 품질 지표 (저희의 경우 사용자가 보고한 "이 답변은 틀렸습니다" 피드백)가 포함되었습니다.

3. 일주일간의 50/50 분할. 게이트웨이 계층 (gateway layer)에서 가중치 기반 라우팅 (weighted routing)을 사용하여 대규모 환경에서 진정한 병렬 비교 (side-by-side comparison)를 수행했습니다. 이 단계에서 비용 추정치가 전체 볼륨에서도 유효함을 검증했습니다.

4. 전체 전환 (Full cutover). 2주간의 깨끗한 50/50 데이터를 확보한 후, 기본 설정을 전환했습니다. 만약의 롤백 (roll back) 상황에 대비하여 OpenAI를 폴백 (fallback) 상태로 유지했습니다 (클라이언트가 다른 base_url로 연결되도록 유지함).

결정부터 전체 전환까지 걸린 총 시간은 약 3주였으며, 그중 대부분은 통계적 신뢰도 (statistical confidence)를 확보하기 위해 데이터를 축적하는 시간이었습니다. 실제 엔지니어링 작업은 이틀 안에 끝났습니다.

벤더 종속 (Vendor Lock-In) 문제 (이번에는 진지하게)

가장 핵심적인 문제 (the elephant in the room)를 짚고 넘어가고 싶습니다. 어떤 분들은 이 글을 읽고 "결국 OpenAI 종속을 Global API 종속으로 바꾸는 것뿐이 아닌가"라고 말할 것입니다. 일리 있는 지적입니다. 하지만 저는 프레임워크가 잘못되었다고 생각합니다.

당신을 실제로 종속시키는 것은 **독점적 API (proprietary APIs)**입니다. 만약 assistants.create()를 호출하거나, OpenAI의 배치 엔드포인트 (batch endpoint)를 사용하거나, 그들의 파인튜닝 (fine-tuning) API에 의존하고 있다면, 당신은 진짜 종속된 상태입니다. 이러한 워크로드 (workloads)를 마이그레이션하는 것은 비용이 많이 듭니다.

반면, OpenAI 호환 엔드포인트에 표준 메시지 형식을 사용하여 Chat Completions를 호출하고 있다면, 당신은 종속되지 않은 것입니다. 해당 프로토콜을 지원하는 어떤 제공업체로든 설정 변경 한 번이면 전환할 수 있습니다. 그것은 종속이 아니라 선택권 (optionality)입니다.

현재 저희는 게이트웨이 계층(gateway layer)에서 세 가지 제공업체를 운영하고 있습니다: 비용 최적화된 워크로드(workloads)를 위한 Global API, 정말로 GPT-4o 수준의 품질이 필요한 소수의 케이스를 위한 OpenAI, 그리고 진정으로 보안을 극도로 경계하는(paranoid) 시나리오를 위한 자체 호스팅 폴백(self-hosted fallback)입니다. 이들 사이의 라우팅(routing)은 단 20줄짜리 미들웨어 함수로 처리됩니다. 이것이 바로 "벤더 종속(vendor lock-in) 방지"가 실제로 구현되는 모습입니다.

스프레드시트를 위한 ROI 계산법

현재 OpenAI에 매달 500달러를 지출하고 있다고 가정해 봅시다. 실제 사용자가 있는 소규모 스타트업에게는 합리적인 금액입니다. 만약 기본 워크로드를 DeepSeek V4 Flash로 이전한다면, 이에 상응하는 비용은 월 약 12.50달러입니다. 품질 수준, 인터페이스, SDK가 모두 동일합니다.

연간 절감액: 약 5,850달러.

만약 여러분이 많은 시리즈 A(Series A) 스타트업들이 위치한 지점인 월 5,000달러를 지출하고 있다면, 연간 약 58,500달러의 절감액을 기대할 수 있습니다. 이는 시니어 엔지니어 한 명의 연봉입니다. 이는 런웨이(runway)입니다. 이는 다운 라운드(down round)와 플랫 라운드(flat round)를 가르는 차이입니다. 이것이 바로 여러분의 이사회가 물어볼 법한 숫자입니다.

위에서 보여드린 것처럼, 이전 비용은 대략 엔지니어 이틀 치의 작업량입니다. 보수적으로 잡아서 전체 스프린트(sprint) 기간을 할당하더라도, 회수 기간(payback period)은 몇 주 단위로 측정됩니다. 그 이후부터는 순수 이익(margin)입니다.

솔직한 주의사항

이 내용을 과장하고 싶지는 않습니다. 염두에 두어야 할 몇 가지 사항이 있습니다:

지연 시간(Latency) 프로필이 다릅니다. DeepSeek V4 Flash는 지연 시간 측면에서 GPT-4o와 동일하지 않습니다. 저희의 워크로드에서는 괜찮았지만, 여러분의 특정 트래픽에 맞춰 벤치마크(benchmark)를 수행해야 합니다. 엣지(edge)에서 실시간 채팅을 구현하고 있다면 철저히 테스트하십시오.

에지 케이스(edge cases)에서 모델 동작이 갈라집니다. 저희는 DeepSeek V4 Flash의 출력 형식이 GPT-4o와 미묘하게 달랐던 두 가지 사례를 발견했습니다 (하나는 하필이면 중첩된 리스트의 마크다운(markdown) 포맷팅과 관련된 것이었습니다). 여러분의 평가(evals) 프로세스가 이를 잡아내야 합니다. 만약 평가 프로세스가 없다면, 이전하기 전에 구축하십시오. 마이그레이션(migration)은 그러한 작업을 수행하게 만드는 아주 좋은 강제 동력(forcing function)이 됩니다.

가격 변동 (Pricing changes). 위에서 인용한 수치들은 우리가 이 분석을 수행했을 당시를 기준으로 정확하지만, LLM 가격은 계속해서 변하는 목표물(moving target)입니다. 모델을 재배포하지 않고도 교체할 수 있도록 라우팅 계층(routing layer)을 설정 기반(config-driven)으로 구축하십시오.

제공업체 신뢰성 (Provider reliability)이 중요합니다. 우리가 Global API를 선택한 이유는 이들이 여러 업스트림 제공업체(upstream providers)를 하나의 OpenAI 호환 인터페이스(OpenAI-compatible interface) 아래로 통합하여, 우리가 직접 설계할 필요 없는 장애 조치(failover) 시나리오를 제공하기 때문입니다. 만약 단일 모델 제공업체에 직접 연결한다면, 해당 업체의 가동 시간 보장(uptime guarantees)을 그대로 물려받게 됩니다.

Global API를 확인해보라고 말씀드리는 부분

이 글이 부분적으로 우리가 어떻게 Global API를 사용하게 되었는지에 관한 내용이 아니라고 거짓말하지는 않겠습니다. 하지만 저는 벤더 홍보(vendor pitch)보다는 아키텍처 측면의 논거를 우선적으로 제시하려고 노력했습니다. 왜냐하면 진짜 교훈은 "제공업체 X로 전환하라"가 아니기 때문입니다. 진짜 교훈은 "제공업체에 맞춰 구축하는 것을 멈추고, 인터페이스(interfaces)에 맞춰 구축하기 시작하라"는 것입니다.

이 교훈을 진지하게 받아들인다면, 누구를 통해서든 라우팅할 수 있습니다. 우리가 Global API를 선택한 이유는 하나의 OpenAI 호환 엔드포인트(endpoint) 아래 184개의 모델을 제공했기 때문이며, DeepSeek V4 Flash의 가격(백만 토큰당 $0.18/$0.25)이 우리의 품질 기준에서 찾은 것 중 가장 좋았고, 장애 조치(failover) 시나리오 덕분에 첫날부터 직접 멀티 제공업체 추상화(multi-provider abstraction)를 설계할 필요가 없었기 때문입니다. 이는 합리적인 이유들의 집합입니다. 여러분의 제약 조건은 다를 수 있습니다.

만약 현재 OpenAI에 상당한 비용을 지출하고 있으면서 아직 이것을 살펴보지 않았다면, 진심으로 Global API를 확인해 보라고 권하고 싶습니다. 마이그레이션(migration)은 코드 두 줄이면 충분합니다. 비용 절감은 지속적입니다. 종속(lock-in) 위험은 거의 제로로 떨어집니다. 최악의 경우, 오후 시간을 투자하여 여러분의 추상화 계층(abstraction layer)에 대해 무언가를 배우게 될 것입니다. 최선의 경우, 동일한 제품 동작을 유지하면서 연간 수만 달러를 확보할 수 있습니다.