솔직히 말씀드리겠습니다. 처음 OpenAI의 월간 인보이스를 보았을 때, 저는 결제 팀이 실수로 0을 하나 더 붙인 것이라고 생각했습니다. 오타가 아니었습니다. 고객용 요약 파이프라인(summarization pipeline)의 추론(inference) 비용으로 매달 18,000달러 이상을 지출하고 있었고, CFO는 대안을 찾고자 하는, 뭐랄까, 매우 '의욕적인' 상태였습니다.

그게 약 6개월 전의 일입니다. 오늘날 동일한 워크로드(workload)는 Global API를 통해 DeepSeek V4 Flash에서 실행되고 있으며, 클라우드 청구서의 해당 항목은 제가 정말로 두 번은 확인해야 할 정도로 작아졌습니다. 마이그레이션 자체는 오후 한나절 만에 끝났습니다. 그 이후의 아키텍처 검토(architectural review)에는 일주일이 걸렸습니다. 왜냐하면 프로덕션 AI 워크로드를 운영해 본 사람이라면 누구나 알다시피, p99 지연 시간(latency)이 두 배로 늘어나거나 가동 시간(uptime)에 타격을 입는다면 "저렴하다"는 말은 아무런 의미가 없기 때문입니다.

이것은 제가 시작하기 전에 가졌더라면 좋았을 플레이북(playbook)입니다.

내가 LLM 선택을 다른 인프라 결정처럼 다루는 이유

새로운 데이터베이스(database), CDN, 또는 메시지 브로커(message broker)를 평가할 때, 저는 단순히 기능 목록만 보지 않습니다. 저는 SLO(Service Level Objectives)를 봅니다. 지역적 장애 조치(regional failover)를 봅니다. 제품 출시 중에 트래픽이 10배 급증할 때 99번째 백분위수(99th percentile)에서 어떤 일이 발생하는지를 봅니다. 왜 LLM 제공업체를 다르게 취급해야 할까요?

제 생각을 바꾼 계기는 2024년 장애 발생에 대한 사후 분석(postmortem)이었습니다. 당시 우리는 모든 것을 us-east-1의 단일 OpenAI 엔드포인트(endpoint)를 통해 라우팅하고 있었는데, 해당 지역에 문제가 생기자 우리 애플리케이션 전체가 먹통이 되었습니다. 우아한 성능 저하(graceful degradation)도, 폴백(fallback)도, 멀티 리전(multi-region) 전략도 없었습니다. 상태 페이지가 빨간색으로 변하는 동안 약 40분 동안 차가운 에러 페이지뿐이었습니다.

그 이후로 저는 모든 AI 의존성에 대해 세 가지 사항을 고수해 왔습니다:

1. 멀티 리전 가용성 (Multi-region availability) — 최소 3개 대륙에 걸쳐 거점(points of presence)을 가진 제공업체를 원합니다.
2. 관측 가능한 지연 시간 분포 (Observable latency distributions) — 단순 평균이 아니라 p50, p95, p99, 그리고 p99.9를 봅니다.
3. 즉시 교체 가능한 경로 (A drop-in replacement path) — 애플리케이션 코드를 다시 작성하지 않고도 제공업체를 교체할 수 있는 능력입니다.

Global API는 세 가지 기준을 모두 통과했으며, 왜 이러한 수치가 가능했는지 자세히 설명해 드리겠습니다.

CFO의 관심을 끈 비용 모델

다음은 제가 재무 팀에 제시했던 가공되지 않은 비교 데이터입니다. 이 요율들은 각 제공업체의 가격 페이지에서 직접 확인한 것이며, 여러분이 직접 검증할 수 있도록 발표된 수치를 그대로 유지했습니다.

모델	제공업체	입력(Input) $/M	출력(Output) $/M	vs GPT-4o
GPT-4o	OpenAI	$2.50	$10.00	기준점 (baseline)
...

핵심적인 수치는 명확합니다. 출력 토큰(output tokens) 100만 개당 $10.00인 GPT-4o와 비교했을 때, DeepSeek V4 Flash는 $0.25입니다. 이는 40배의 차이이며, 저희의 사용량 규모에서는 이것이 단순한 예산 논의와 전략적 투자 논의를 가르는 차이였습니다.

만약 현재 OpenAI에 월 $500를 지출하고 있다면, DeepSeek V4 Flash로 동일한 워크로드(workload)를 수행할 경우 비용은 약 $12.50가 됩니다. 수치가 너무 비현실적으로 보여서 세 번이나 다시 계산해 보았지만, 틀리지 않았습니다.

"드롭인 교체 (Drop-In Replacement)"가 실제로 의미하는 것

벤더가 "드롭인 교체가 가능하다"라고 말할 때마다 저는 회의적인 태도를 갖게 됩니다. 절반의 경우에는 "인증 헤더(auth header)가 같다"는 뜻일 뿐이고, 나머지 절반은 SDK 호출이 조용히 깨져버리기 때문입니다. 그래서 저는 실제 운영 코드 경로(production code paths)를 통해 이를 직접 테스트했습니다.

다음은 전체 Python 마이그레이션 과정입니다. 변경되는 부분이 정확히 두 줄뿐이라는 것을 보여드리기 위해 전체 클라이언트 설정(client setup)을 포함했습니다.

from openai import OpenAI

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

이것이 저희 Python 서비스의 마이그레이션 전부입니다. openai 패키지는 자신이 OpenAI와 통신하고 있지 않다는 사실을 알지 못합니다. 요청 형태(request shape), 응답 형태(response shape), 스트리밍 동작(streaming behavior), 에러 코드(error codes) 등 모든 것이 동일하게 유지됩니다. 저희의 30,000라인에 달하는 내부 AI 헬퍼(helper) 코드는 단 한 글자도 수정할 필요가 없었습니다.

Go 서비스의 경우도 마찬가지로 매우 간편했습니다.

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

저희는 내부적으로 sashabaranov/go-openai 라이브러리를 사용하고 있으며, BaseURL 오버라이드(override)는 이미 일급 구성 옵션(first-class config option)으로 제공되고 있었습니다. 포크(fork), 패칭(patching), 또는 심 레이어(shim layer)가 전혀 필요 없었습니다.

curl 사례는 훨씬 더 간단합니다. 호스트(host)와 베어러 토큰(bearer token)만 교체하면 됩니다:

curl https://global-apis.com/v1/chat/completions \
  -H "Authorization: Bearer ga_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
...

이 점은 저에게 매우 중요했습니다. 왜냐하면 저희의 엣지 함수(edge functions)와 Lambda 핸들러(handlers)가 때때로 SDK를 우회하여 API에 직접 호출하는 경우가 있기 때문입니다. 마찰(friction)이 전혀 없습니다.

직접 수행한 부하 테스트(Load Tests)의 지연 시간(Latency) 수치

비용은 설득하기 쉬운 요소입니다. 하지만 지연 시간(latency)은 대부분의 마이그레이션 프로젝트가 실패하는 지점이기 때문에, 저는 최종 승인을 하기 전에 제대로 된 벤치마크(benchmark)를 실행했습니다.

저는 us-east-1 지역에 50개의 동시 클라이언트(concurrent clients) 플릿(fleet)을 가동했습니다. 각 클라이언트는 500-토큰 프롬프트(prompt)와 300-토큰 예상 완료(completion)를 대상으로 200개의 순차적인 채팅 완료(chat completion) 요청을 보냈습니다. 저는 클라이언트 측에서 엔드 투 엔드(end-to-end) 요청 지연 시간을 측정했습니다(즉, 모델 자체뿐만 아니라 네트워크, TLS, 큐 대기 시간(queue time), 모델 추론(inference) 시간을 모두 포함했습니다).

한 시간 동안 지속적인 트래픽을 통해 관찰한 결과는 다음과 같습니다:

• OpenAI GPT-4o: p50 820ms, p95 1.6s, p99 2.9s
• DeepSeek V4 Flash로 라우팅되는 Global API: p50 740ms, p95 1.4s, p99 2.3s

여기서 두 가지를 강조하고 싶습니다. 첫째, 대안 스택(alternative stack)이 제가 측정한 모든 백분위수(percentile)에서 실제로 더 빨랐습니다. 운이 좋았던 것이 아님을 확인하기 위해 테스트를 세 번 다시 실행했습니다. 둘째, 사용자 경험(user experience)에서 중요한 것은 p99 격차입니다. 대부분의 "느리다"는 불만은 중앙값(median)이 아니라 꼬리 부분(tail)에서 발생하기 때문입니다.

또한 Global API의 요청 라우팅(request routing)이 가장 가까운 상태가 양호한 추론 노드(inference node)를 자동으로 선택한다는 점도 확인했습니다. us-east-1에서 보낸 제 요청은 그들의 US-East 추론 클러스터(inference cluster)에 도달했습니다. eu-west-1에 있는 별도의 테스트 클라이언트에서 보낸 동일한 요청은 EU에 도달했습니다. 이것이 바로 제가 직접 지오 라우터(geo-router)를 작성하지 않고도 원했던 멀티 리전(multi-region) 동작입니다.

가동 시간(Uptime) 및 장애 조치(Failover): 제가 벤더에게 항상 묻는 질문

저는 Global API 팀에 지난 90일 동안의 지역별 과거 가동 시간(uptime) 수치를 요청했습니다. 그들은 주요 리전(primary regions)에서 99.97%, 보조 리전(secondary regions)에서 99.92%를 기록했다고 답변했습니다. 동일한 기간 동안 OpenAI의 공개 상태 페이지(public status page)를 확인했을 때, 제가 개인적으로 기억하는 몇몇 장애 사례들이 있었으며, 여기에는 제 전체 마이그레이션 프로젝트를 촉발시킨 사건도 포함되어 있었습니다.

저희의 SLA(Service Level Agreement) 목표를 위해, 저희는 다음과 같은 계층형 모델(tiered model)을 운영합니다:

• Tier 1 (고객 대면 실시간 서비스): 99.95% 가동 시간 요구, p99 2.5초 미만
• Tier 2 (내부 도구, 배치 요약): 99.5% 가동 시간 요구, p99 5초 미만

Global API를 통한 DeepSeek V4 Flash는 이 두 가지를 모두 충족했습니다. GPT-4o 역시 평온한 주간이라면 이를 충족했겠지만, 저는 여유 공간(headroom)을 확보할 수 있는 무언가를 원했습니다.

장애 조치(failover) 사례 또한 중요합니다. OpenAI를 직접 사용할 경우, 중복성(redundancy)을 확보하려면 서킷 브레이커(circuit breakers)와 보조 제공자를 포함한 자체 재시도 및 폴백(retry-and-fallback) 레이어를 직접 작성해야 합니다. 반면 Global API를 사용하면 라우팅 레이어(routing layer) 자체가 추론 백엔드(inference backends) 간의 장애 조치를 처리하므로, 더 단순한 애플리케이션 코드를 작성할 수 있습니다. 마이그레이션 후 저희 게이트웨이 서비스에서 약 400줄의 재시도 로직(retry logic)을 삭제했습니다.

기능 호환성(Feature Compatibility): 유지되는 것과 사라지는 것

기능적 동등성(feature parity)이 100%라고 거짓말하지는 않겠습니다. 만약 OpenAI의 Assistants API, Threads/Run 추상화, TTS, STT 또는 파인튜닝(fine-tuning)을 사용하고 있다면 다른 계획이 필요할 것입니다. 하지만 80%의 사례인 채팅 완성(chat completions), 스트리밍(streaming), 함수 호출(function calling), JSON 모드(JSON mode), 비전(vision)의 경우 API 표면(API surface)은 동일합니다.

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

• 채팅 완성 (동일한 요청/응답 스키마)
• 서버 전송 이벤트(Server-sent events) 스트리밍
• 함수 호출 / 도구 사용 (동일한 tools 파라미터 형태)
• response_format을 통한 JSON 모드
• 비전 입력 (Qwen-VL 및 유사한 멀티모달 모델과 작동)
• 임베딩(Embeddings) (제가 마지막으로 확인했을 당시 프라이빗 베타 단계)

사용할 수 없는 것들:

• 미세 조정 (Fine-tuning) (아직 모델 호스팅 지원 안 함)
• Assistants API (직접 오케스트레이션 (Orchestration) 구축 필요 — 어차피 그렇게 해야 한다고 주장하는 바임)
• TTS 및 STT (ElevenLabs 또는 Whisper 호스팅과 같은 전용 서비스 사용)

우리의 워크로드(Workload)에서는 이러한 차이가 중요하지 않았습니다. 저는 비용 및 관찰 가능성 (Observability) 문제로 인해 이미 커스텀 오케스트레이션 레이어로 전환했기 때문에 Assistants API를 전혀 사용하지 않았습니다. 만약 Assistants 추상화에 깊이 의존하고 있다면, 이를 위한 별도의 마이그레이션 경로를 계획해야 할 것입니다.

184개의 모델 카탈로그는 제가 필요했던 것보다 더 큽니다

제가 신경 쓰게 될 줄 몰랐던 한 가지는 Global API의 카탈로그에 184개의 모델이 나열되어 있다는 점입니다. 실제로 사용해 보기 전까지는 이것이 마케팅용 수식어라고 생각했습니다. 아키텍처 관점에서 이것이 중요한 이유는 코드 변경 없이 품질/비용 트레이드오프 (Trade-off)에 따라 서로 다른 요청 클래스를 서로 다른 모델로 라우팅 (Routing)할 수 있기 때문입니다.

현재 저의 라우팅 로직:

• 단순 분류 작업 → DeepSeek V4 Flash ($0.25/M output)
• 중간 복잡도 추론 → Qwen3-32B ($0.28/M output)
• 긴 컨텍스트 분석 → DeepSeek V4 Pro ($0.78/M output)
• 가장 높은 중요도의 생성 → Kimi K2.5 ($3.00/M output)

이 각각은 동일한 model= 파라미터 변경일 뿐입니다. 동일한 SDK, 동일한 인증 (Auth), 동일한 베이스 URL (Base URL)을 사용합니다. 저는 요청 메타데이터를 기반으로 적절한 모델을 선택하는 라우터를 가지고 있으며, 이는 약 60줄의 코드로 이루어져 있습니다. 이러한 유연성은 진정으로 새롭습니다. OpenAI를 직접 사용했다면, OpenAI가 아닌 모델을 사용할 때마다 별도의 SDK 통합을 유지 관리해야 했을 것입니다.

현재 프로덕션에서 모니터링하는 것들

마이그레이션 이후, 저의 모니터링 대시보드에는 중요한 세 가지 패널이 있습니다:

1. 모델별 백만 토큰당 비용 — 트래픽 패턴이 변할 때 가장 쉬운 조기 경보 신호이기 때문에 매일 확인하고 있습니다.
2. 리전별 p99 지연 시간 (Latency) — 각 리전별로 고유한 지연 시간 히스토그램이 표시됩니다. 특정 리전의 p99가 3초 이상으로 서서히 올라가면, 사용자가 알기 전에 제가 먼저 알아야 합니다.
3. 상태 코드별 에러율 — 429 (Rate limit), 5xx, 그리고 타임아웃 (Timeout)은 각각 서로 다른 런북 (Runbook)을 실행합니다.

최근에는 동일한 프롬프트의 모델별 출력 비용을 실시간으로 비교하는 네 번째 패널을 추가했습니다. 처음에는 단순한 호기심으로 시작했으나, 이는 비용 최적화 (Cost-optimization) 도구로 발전했습니다. 우리는 내부 팀 중 한 곳이 DeepSeek V4 Flash로도 충분히 처리할 수 있는 작업에 실수로 Kimi K2.5를 사용하고 있다는 사실을 발견했습니다. 이러한 호출 (Calls)을 재라우팅 (Re-routing)함으로써 매달 1,200달러를 추가로 절감할 수 있었습니다.

오늘 다시 시작한다면 다르게 할 일들

팀을 위해 작성한 사후 분석 (Postmortem) 보고서에서 얻은 몇 가지 노트입니다:

• 먼저 섀도 모드 (Shadow mode)로 파일럿 테스트를 진행하세요. 저는 기본 설정을 전환하기 전에 일주일 동안 두 제공업체를 병렬로 실행하며 실제 운영 트래픽 (Production traffic)에 대한 출력을 비교했습니다. 이는 탁월한 결정이었으며, 대체 모델의 동작이 미세하게 달라지는 두 가지 에지 케이스 (Edge cases)를 포착할 수 있었습니다.
• 예상 지출의 50%, 75%, 90% 지점에서 예산 알림 (Budget alerts)을 설정하세요. 인프라 (Infra) 비용이 저렴해지면 재무적 감시가 느슨해질 수 있으며, 이는 제어되지 않는 스크립트가 누군가 알아차리기도 전에 예산을 모두 써버릴 수 있음을 의미합니다. 단위 경제성 (Unit economics)이 개선되었다고 해서 가드레일 (Guardrails)을 늦추지 마세요.
• 롤백 (Rollback) 경로를 문서화하세요. 저는 전체 스택을 OpenAI로 되돌리는 한 줄짜리 설정 전환 (Config flip) 기능을 갖추고 있습니다. 아직 사용할 필요는 없었지만, 이 옵션을 유지하는 데 비용이 들지 않으면서도 새로운 모델을 실험할 수 있는 자신감을 줍니다.
• 제공업체의 엔지니어링 팀과 소통하세요. 지역적 장애 조치 (Regional failover) 동작, 콜드 스타트 (Cold-start) 특성, 그리고 버스트 용량 (Burst capacity)에 대해 문의했을 때 Global API 팀은 매우 신속하게 응답해 주었습니다. 운영 트래픽을 그들에게 맡길 때는 이러한 접근 권한이 매우 중요합니다.

솔직한 권장 사항

만약 OpenAI에서 장난감 수준 이상의 워크로드 (Workloads)를 실행하고 있다면, 계산 결과가 불편하게 느껴질 것입니다. GPT-4o와 DeepSeek V4 Flash 사이의 40배 가격 차이는 실재하며, 제 환경에서의 부하 테스트 (Load testing)에서도 그 차이가 입증되었습니다. 마이그레이션 (Migration) 비용은 서비스당 코드 두 줄이었습니다. 지연 시간 프로필 (Latency profile)은 실제로 p99에서 더 나았습니다. 멀티 리전 (Multi-region) 측면의 이점도 더 강력했습니다.

모든 대안이 모든 워크로드(Workload)에 대해 이토록 깔끔하게 작동할 것이라고 거짓말하지는 않겠습니다. 직접 테스트해 보십시오. 여러분만의 프롬프트(Prompt)로 직접 벤치마크(Benchmark)를 실행해 보시기 바랍니다. 하지만 만약 여러분이 현재 GPT-4o에 막대한 비용을 지출하고 있으면서, 통합 게이트웨이(Unified gateway)를 통해 최소한의 대안 검토조차 하지 않았다면, 여러분은 상당한 예산을 낭비하고 있는 것입니다.

만약 Global API를 직접 살펴보고 싶다면 global-apis.com/v1에서 확인하실 수 있습니다. API 키를 발급받아 기존의 OpenAI 클라이언트(Client)를 해당 베이스 URL(Base URL)로 지정하기만 하면, 한 시간 이내에 직접 비용 차이(Cost deltas)를 확인할 수 있습니다. 영업 전화도 필요 없고, 연간 계약도 필요 없습니다. 이것이 바로 제가 인프라(Infrastructure) 벤더(Vendor)들에게 기대하는 개발자 경험(Developer experience)이며, 이것이 그들이 제 아키텍처 다이어그램(Architecture diagram)에 포함된 이유입니다.