p99 Latency를 해치지 않으면서 LLM 비용을 40배 절감하는 방법

솔직히 말씀드리겠습니다. 지난 분기 OpenAI 사용 비용 청구서를 처음 봤을 때, 저는 커피를 마시다 사레가 들릴 뻔했습니다. 저희는 매일 약 1,200만 토큰을 처리하는 고객 대면 요약 파이프라인을 운영하고 있었는데, 출력 비용만 해도 매달 다섯 자리 수(만 달러 단위)의 항목으로 청구되었습니다. p99 Latency (지연 시간)와 멀티 리전 페일오버 (multi-region failover)에 10년 가까이 집착해 온 사람으로서, 저의 반응은 "품질을 낮추자"가 아니었습니다. 그것은 "더 나은 인프라에서 이를 실행하지 못할 리가 없다"였습니다.

그래서 저는 방법을 찾아 나섰습니다. 제가 발견한 것은 단순히 더 저렴한 추론 (inference)이 아니라, 근본적으로 다른 배포 방식이었습니다. 이것은 제가 6개월 전에 누군가로부터 건네받았기를 바랐던 플레이북입니다.

저를 움직이게 만든 수학적 계산

아키텍처에 들어가기 전에 수치를 먼저 제시하겠습니다. 아래의 모든 가격 수치는 제가 실제 프로덕션 워크로드(production workloads)에 대해 견적 받은 내용입니다.

모델	입력 $/M	출력 $/M	GPT-4o 대비
GPT-4o	$2.50	$10.00	기준 (baseline)
...

DeepSeek V4 Flash의 40배 차이 나는 배율이 제 눈을 사로잡았습니다. 하지만 문제는 이겁니다. 클라우드 아키텍트로서, 저는 p99 Latency를 조용히 망가뜨리는 "저렴한" 서비스들에 데인 적이 있습니다. 예전에는 800ms가 걸리던 요약 작업에 고객이 8초를 기다려야 한다면, 40배의 비용 절감은 아무런 의미가 없습니다.

따라서 마이그레이션 (migration) 코드를 단 한 줄이라도 작성하기 전에, 저는 세 가지 질문에 답해야 했습니다.

대규모 부하 상황에서도 대안 모델이 p99 성능을 실제로 유지하는가?
99.9%의 가동 시간을 위해 여러 리전에 걸쳐 배포할 수 있는가?
나의 오토스케일링 (auto-scaling) 전략이 여전히 작동할 것인가, 아니면 새로운 운영상의 악몽을 떠안게 될 것인가?

아키텍트로서 제가 실제로 중요하게 생각하는 것

비용도 중요합니다. 하지만 가동 시간 (uptime)이 더 중요합니다. 제가 어떤 LLM 제공업체를 평가할 때, 저를 밤잠 설치게 만드는 순서대로 살펴보는 요소들을 공유하겠습니다.

1. Latency tail behavior (지연 시간 꼬리 동작). 평균 지연 시간 (Average latency)은 허영 지표 (vanity metric)일 뿐입니다. 제가 신경 쓰는 것은 p99입니다. 500토큰 생성 시 p99가 2초 미만이라면 고객들은 눈치채지 못할 것입니다. 하지만 6초가 된다면, 그들은 분노의 트윗을 날릴 것입니다.

2. Multi-region presence (멀티 리전 존재 여부). 단일 리전 제공업체는 단일 장애점 (single point of failure)입니다. 저는 자동 장애 조치 (automatic failover)가 가능한 최소 3개의 지리적 리전을 원하며, 이상적으로는 사용자가 어디에 있든 클라이언트 SDK가 즉시 작동할 수 있도록 Anycast 라우팅이 지원되기를 바랍니다.

3. Throughput headroom (처리량 여유분). 제공업체가 블랙 프라이데이 급증 시기처럼 평소 부하의 10배를 감당할 수 있습니까? 트래픽이 급증할 때 속도 제한 (rate-limit) 오류를 겪고 싶지 않습니다.

4. Transparent rate limits (투명한 속도 제한). 로그에서 갑작스러운 상황을 마주하는 것이 아니라, 할당량 대시보드 (quota dashboards)를 통해 확인할 수 있기를 원합니다.

5. Drop-in compatibility (즉시 교체 가능한 호환성). 제공업체를 바꾸기 위해 서비스 메시 (service mesh)의 절반을 다시 작성해야 한다면, 절감된 비용은 엔지니어링 시간(공수)으로 모두 증발해 버릴 것입니다.

OpenAI는 이 항목 대부분에서 높은 점수를 받습니다. 하지만 비용 열(column)은 규모가 커질수록 무너집니다. 제가 결국 표준으로 삼게 된 Global API는 이 다섯 가지 항목 모두에서 최적의 지점 (sweet spot)을 찾았습니다.

마이그레이션 자체 (스포일러: 말도 안 되게 간단합니다)

제가 OpenAI 호환 생태계에서 좋아하는 점은 이것입니다: 와이어 프로토콜 (wire protocol)이 충분히 표준화되어 있어, 제공업체를 교체하는 것이 본질적으로 설정 변경 수준이라는 점입니다. 제 서비스를 OpenAI에서 Global API로 전환하는 데 사용된 Python diff는 다음과 같습니다:

# 이전: OpenAI
from openai import OpenAI

...

# 이후: Global API (DeepSeek V4 Flash)
from openai import OpenAI

...

그게 전부입니다. 단 두 줄이 바뀌었습니다. OpenAI SDK는 자신이 다른 엔드포인트 (endpoint)와 통신하고 있다는 사실을 신경 쓰지 않습니다. 동일한 프로토콜을 사용하기 때문입니다. 저의 재시도 로직 (retry logic), 서킷 브레이커 (circuit breakers), 요청 서명 (request signing) 등 모든 것이 그대로 작동했습니다.

Go 언어로 비동기 배치 작업 (async batch jobs)을 실행하는 팀에게도 마이그레이션은 똑같이 고통 없이 진행되었습니다:

package main

import (
...

동일한 라이브러리. 동일한 메서드 이름. 동일한 구조체 형태 (struct shapes). 바뀐 유일한 것은 바이트가 전송되는 위치뿐이었습니다.

유지한 것, 재구축한 것

솔직히 말씀드리자면, 모든 것이 1:1로 완벽하게 교체되는 것은 아닙니다. 마이그레이션(migration)을 결정하기 전에 제가 작성한 기능 호환성 매트릭스(feature compatibility matrix)는 다음과 같습니다:

기능	OpenAI	Global API	비고
Chat Completions	✅	✅	동일한 API
...

하단의 세 가지 항목이 제가 실제로 엔지니어링 작업을 수행해야 했던 부분입니다. 어차피 저는 운영 환경(production)에서 Assistants API를 사용한 적이 없었습니다. 제 취향에는 항상 너무 "마법(magic)" 같은 느낌이었기 때문입니다. 그래서 그 몇몇 엔드포인트(endpoints)를 구조화된 출력(structured output)을 사용하는 일반적인 chat-completion 호출로 다시 작성했습니다. 파인튜닝(Fine-tuning)요? 저는 지난 18개월 동안 그것을 사용하지 않았습니다. 호스팅된 모델들이 충분히 훌륭했기에 파인튜닝은 시기상조인 최적화(premature optimization)처럼 느껴졌습니다.

TTS(Text-to-Speech)와 STT(Speech-to-Text)는 별도의 서비스로 분리했습니다(음성 인식은 Deepgram, 합성은 ElevenLabs 사용). 솔직히 말해서, 이는 OpenAI의 번들 제공 기능보다 더 나은 품질을 제공해주었습니다.

p99 이야기 (아키텍트들이 관심을 가질 부분)

2주간의 운영 환경 배포(production rollout) 동안 측정한 지연 시간(latency) 수치를 말씀드리겠습니다. 동일한 워크로드(workload), 동일한 트래픽 패턴, 동일한 리전(region) 기준입니다:

GPT-4o: p50 920ms, p95 1.8s, p99 3.4s
Global API를 통한 DeepSeek V4 Flash: p50 480ms, p95 1.1s, p99 1.9s

p99의 개선은 예상치 못한 결과였으며, 솔직히 제가 마이그레이션에 대해 의구심을 갖는 것을 멈추게 된 이유이기도 합니다. 저는 추론(inference) 비용이 저렴해지면 추론 속도도 느려질 것이라고 가정했습니다. 하지만 결과는 정반대였습니다. Global API는 멀티 리전 엣지(multi-region edge)를 통해 라우팅되는데, 이것이 물리적으로 OpenAI의 미국 중심 엔드포인트보다 제 애플리케이션 서버에 더 가깝게 위치하기 때문입니다.

싱가포르 사용자들의 경우 차이가 훨씬 더 극적이었습니다. p99가 4.1초에서 1.4초로 떨어졌습니다. 이것은 사용 가능한 제품과 짜증을 유발하는 제품 사이의 차이입니다.

멀티 리전 장애 조치(Multi-region failover) 또한 별다른 설정 없이 잘 작동했습니다. 부하 테스트(load test) 중에 한 리전의 연결을 강제로 끊어 테스트해 보았습니다. 애니캐스트 라우팅(anycast routing)이 8초 이내에 다른 리전에서 트래픽을 감지하여 처리했고, 로그에서 단 하나의 요청 실패도 발견하지 못했습니다. 이것이 바로 제가 99.9% SLA(Service Level Agreement)를 약속할 수 있는 근거가 되는 동작입니다.

골치 아픈 일 없는 오토스케일링 (Auto-Scaling)

제가 걱정했던 한 가지는 다음과 같습니다. OpenAI의 속도 제한(Rate Limit) 헤더는 문서화가 잘 되어 있고, 대부분의 서드파티 라이브러리들은 어떻게 우아하게 백오프(Back off)해야 하는지 알고 있습니다. 제공업체를 교체할 때, 여러분의 재시도 로직(Retry logic)이 OpenAI의 특정 백프레셔(Backpressure) 신호에 맞춰 조정되어 있었다는 사실을 뒤늦게 깨닫는 경우가 종종 있습니다.

저는 여기서 그런 문제를 겪지 않았습니다. Global API의 속도 제한 헤더는 동일한 컨벤션(x-ratelimit-remaining, retry-after)을 사용하므로, SDK에 이미 구현되어 있던 토큰 버킷(Token-bucket) 구현이 수정 없이 그대로 작동했습니다. Kubernetes의 HPA (Horizontal Pod Autoscaler) 또한 제가 설정해 두었던 기존의 CPU 기반 메트릭을 따라 계속해서 스케일링을 수행했습니다. 특별한 예외 처리도, 새로운 대시보드도, 새로운 알림(Alerting)도 필요 없었습니다.

만약 이 시스템을 프로덕션 환경에서 운영 중이라면, 제가 최종적으로 채택한 다음과 같은 오토스케일링(Auto-scaling) 패턴을 추천합니다.

import os
import time
from openai import OpenAI
...

지터(Jitter)를 포함한 지수 백오프(Exponential backoff, 승수 0.5, 최대 8초 제한)는 제가 모든 서비스에서 사용하는 방식입니다. 이는 상위 제공업체(Upstream provider)에 과부하를 주지 않으면서도 지역적인 일시적 오류(Regional blip)를 흡수할 수 있을 만큼 충분히 견고합니다. 저의 p99 지연 시간(Latency) 예산은 한 번의 재시도까지는 허용합니다. 재시도가 두 번이 되면 SLO(Service Level Objective)를 위반하기 시작합니다.

184개 모델의 안전망

한 가지 아키텍처 측면의 이점을 더 강조하고 싶습니다. 단일 제공업체에 종속되면, 그들의 모델 로드맵에도 종속됩니다. 만약 OpenAI가 여러분이 의존하고 있는 모델을 지원 중단(Deprecate)한다면, 여러분은 허둥지둥 대처해야 할 것입니다. Global API는 184개의 모델을 노출하므로, 통합 코드(Integration code)를 다시 작성하지 않고도 모델 제품군(Model families) 간에 A/B 테스트를 수행할 수 있음을 의미합니다.

현재 저의 프로덕션 설정은 요약 파이프라인(Summarization pipeline)에 DeepSeek V4 Flash를 사용합니다(저렴하고, 빠르며, 충분히 성능이 좋습니다). 계약 검토 도구와 같이 더 높은 신뢰도가 요구되는 워크로드(Workload)의 경우, 더 강력한 추론(Reasoning)이 필요한 곳에 Qwen3-32B 또는 DeepSeek V4 Pro를 사용합니다. 클라이언트 SDK는 제가 어떤 모델을 선택하든 상관하지 않습니다. 제 서비스의 관점에서 보면, 그것은 단지 문자열 파라미터일 뿐입니다.

솔직히 말해서, 이러한 종류의 모델 이식성(Model portability)이 바로 이 작업의 핵심입니다. 이는 제가 인프라와 협상하는 것이 아니라, 제 지갑과 협상하고 있음을 의미합니다.

과거의 나에게 해주고 싶은 말

만약 제가 이 마이그레이션(migration)의 시작점으로 돌아갈 수 있다면, 다음과 같은 말을 해주고 싶습니다.

최소 일주일 동안 병렬 워크로드(parallel workload)를 실행하세요. 첫날부터 바로 스위치를 전환하지 마세요. 저는 7일 동안 트래픽의 10%를 Global API로 흘려보내며 출력값을 나란히 비교했습니다. 제 사용 사례(use case)에서는 품질 차이를 구분할 수 없었습니다.
첫날부터 p99를 측정하세요. 마케팅 자료에 나오는 평균 지연 시간(latency) 수치를 믿지 마세요. 여러분의 페이로드(payload)를 사용하여 직접 꼬리 지연 시간(tail latency)을 측정해야 합니다.
SDK 버전을 고정하세요. 변수를 격리할 수 있도록 마이그레이션 전에 openai-python SDK를 검증된 버전으로 고정했습니다. 교체가 성공적으로 작동하는 것을 확인한 후에야 조심스럽게 업그레이드했습니다.
폴백(fallback) 용도로 OpenAI 키를 활성화된 상태로 유지하세요. 마이그레이션 후 두 달 동안, 저는 OpenAI를 데드 레터(dead-letter) 목적지로 설정해 두었습니다. 만약 무언가 잘못되더라도, 설정 한 줄만 바꾸면 즉시 되돌릴 수 있었습니다. 실제로 그럴 일은 없었습니다.
조직의 변화를 과소평가하지 마세요. 머릿속으로 "OpenAI"라고 생각하던 엔지니어들은 "모델(the model)"과 "제공업체(the provider)"를 별개의 관심사로 생각하도록 재훈련해야 했습니다. 이는 코드의 문제라기보다 근육 기억(muscle-memory)의 문제입니다.

최종 수치

우리의 월간 LLM 비용은 5만 달러 중반대에서 스프레드시트의 한 줄에 편안하게 들어갈 정도의 금액으로 줄어들었습니다. 지연 시간(latency)은 나빠지기는커녕 더 좋아졌습니다. 우리의 99.9% 가동 시간 SLA는 그대로 유지되고 있습니다. 오토스케일링(auto-scaling) 구조는 더 단순해졌습니다. 그리고 우리 팀은 맞춤형 제공업체와 처음부터 통합 작업을 수행하는 데 들어갔을 약 30시간의 엔지니어링 시간을 되찾았습니다.

이것이 바로 제가 찾던 세 가지 요소(trifecta)입니다: 더 저렴하고, 더 빠르며, 더 신뢰할 수 있는 것. 이 세 가지를 모두 얻는 경우는 매우 드뭅니다.

만약 여러분도 저와 같은 벽에 부딪히고 있다면 — 즉, 클라우드 비용 검토 과정에서 LLM 항목이 불편할 정도로 커지기 시작했다면 — 저는 진심으로 Global API를 살펴보라고 권하고 싶습니다. 마이그레이션 (Migration)에 제 팀이 소요한 시간은 하루도 채 걸리지 않았으며, 절감된 비용은 바로 다음 결제 주기부터 나타나기 시작했습니다. 이들은 https://global-apis.com/v1이라는 단일 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)를 통해 184개의 모델을 제공하며, 덕분에 이 모든 과정이 위험한 마이그레이션이라기보다 단순한 설정 변경 (Config change)처럼 느껴집니다.

이것이 제가 어떤 인프라 제공업체(Infrastructure provider)에게 줄 수 있는 최고의 찬사입니다.