솔직히 말씀드리겠습니다. 저의 p99 latency (p99 지연 시간) 대시보드가 빨간색으로 불이 들어온 날은, OpenAI가 우리의 프로덕션 워크로드 (production workload)에 적합한 선택이었다는 척도를 그만두기로 결심한 날이었습니다. 우리는 약 14개월 동안 고객 대상 요약 파이프라인 (summarization pipeline)을 GPT-4o를 통해 운영해 왔으며, 품질은 괜찮았지만 매달 말에 청구되는 비용은 CFO(최고재무책임자)를 밤잠 설치게 할 정도였습니다. 두 달간의 아키텍처 리뷰 (architectural review), 폴백 테스트 (fallback testing), 그리고 수많은 커피를 마신 끝에 우리는 트래픽을 마이그레이션 (migration)했습니다. 실제로 중요했던 수치들을 포함하여 제가 배운 점들을 공유합니다.

이것은 마케팅 게시물이 아닙니다. 준수해야 할 SLA (Service Level Agreement)와 고객에 대한 99.9% 가동 시간 (uptime) 약속을 지키며 대규모 트래픽을 운영하는 클라우드 아키텍트의 현장 노트입니다. 만약 여러분이 OpenAI에서 Claude로(또는 현재 Global API를 통해 사용 가능한 다른 184개 모델 중 하나로) 전환할지 고민 중이라면, 이 글이 여러분의 주말을 몇 번은 아껴줄 것입니다.

기존 설정이 작동을 멈춘 이유

화요일 아침 우리의 워크로드 (workload)는 대략 다음과 같았습니다: 하루 240만 건의 인퍼런스 호출 (inference calls), 평균 프롬프트 (prompt) 약 1,800 토큰 (tokens), 평균 컴플리션 (completion) 약 600 토큰. 계산은 복잡하지 않았습니다. 입력 토큰 100만 개당 $2.50, 출력 토큰 100만 개당 $10.00인 GPT-4o 가격 책정에 따라, 우리는 대략 $2.50 × 4.32 (월간 입력 토큰 43.2억 개)에 $10.00 × 1.44 (월간 출력 토큰 14.4억 개)를 더한 금액을 지불하고 있었습니다. 이는 피크 시간대 멀티플라이어 (peak-hour multipliers)가 적용되기 전의 월간 비용이 다섯 자릿수 달러($10,000 이상)에 달한다는 의미였습니다.

비용보다 저를 더 괴롭혔던 것은 p99 latency (p99 지연 시간)였습니다. 미국 업무 시간 동안 GPT-4o의 테일 레이턴시 (tail latencies)가 4.8초까지 치솟는 것을 목격했고, 우리의 오토스케일링 (auto-scaling) 로직은 이를 따라잡으려다 요동치고 있었습니다. 신뢰성 관점에서 이는 독과 같습니다. SLA 약속은 평균값에는 관심이 없습니다. SLA는 최악의 1% 요청에 관심을 가집니다. 왜냐하면 바로 그 요청들이 고객 지원 티켓(customer support tickets)에 나타나기 때문입니다.

저는 대안을 찾기 시작했고, 100만 토큰당 0.01달러에서 3.50달러 사이의 가격대로 184개의 AI 모델을 제공하는 Global API에 도달했습니다. 가격표 하나만 보고도 미팅 일정을 잡아야겠다고 생각했습니다.

비용의 현실, 한 줄씩 살펴보기

수치를 나란히 놓고 비교했을 때 제가 확인한 내용은 다음과 같습니다. 단순히 표를 던져주는 것보다 맥락이 더 중요하다고 생각하기에, 이 과정을 차근차근 설명하겠습니다.

모델	입력 ($/M)	출력 ($/M)	컨텍스트 윈도우 (Context Window)
DeepSeek V4 Flash	0.27	1.10	128K
...

이 수치들을 액면 그대로 보면, GPT-4o는 입력 측면에서 GLM-4 Plus보다 약 9배 더 비싸고, 출력 측면에서는 12배 이상 더 비쌉니다. 이것은 단순한 반올림 오차가 아닙니다. 이는 재정적으로 실행 가능한 워크로드(workload)와 그렇지 않은 워크로드 사이의 차이입니다.

제가 평가한 마이그레이션 후보군 전반에 걸쳐, 비용 절감 폭은 기존에 지불하던 금액 대비 40~65% 사이였습니다. 정확한 수치는 어떤 모델이 어떤 트래픽 버킷(traffic bucket)을 처리하느냐에 따라 달랐습니다. 이에 대해서는 잠시 후에 더 자세히 다루겠습니다. 타당성 검토(sanity check)를 위해 예를 들자면: 만약 현재 GPT-4o에 월 50,000달러를 지출하고 있다면, 50%의 절감은 매달 25,000달러를 예산으로 되돌려준다는 의미입니다. 이는 시니어 엔지니어 한 명의 연봉을 재배치하는 것과 같습니다.

멀티 리전(Multi-Region)이 진정한 돌파구였다

이 부분에 대해 이야기하고 싶은데, 대부분의 "LLM 제공업체를 교체하세요"라는 게시물들은 이 부분을 완전히 생략하기 때문입니다. Global API의 통합 엔드포인트(unified endpoint)가 저에게 중요했던 이유는 단지 가격 때문만이 아니라, 멀티 리전 배포(multi-region deployment) 때문이었습니다.

OpenAI의 직접 API에서 마이그레이션할 때, 저는 리전 장애 조치(regional failover)가 걱정되었습니다. 기존 아키텍처는 재시도(retries) 기능이 포함된 단일 기본 제공업체를 가정하고 있었습니다. 만약 US-East 엔드포인트에 문제가 생기면, US-West 고객들이 그 영향을 받았습니다. 하지만 global-apis.com/v1의 글로벌 엔드포인트를 사용함으로써, 애플리케이션 로직을 다시 작성하지 않고도 지리적 위치에 따라 트래픽을 라우팅할 수 있었습니다. eu-west-2에 있는 저의 오토스케일링 그룹(auto-scaling group)은 us-east-1 플릿(fleet)과 동일한 SDK를 호출합니다. 인증(auth), 응답 형태(response shapes), 스트리밍 동작(streaming behavior)이 모두 동일합니다.

저희 측에서의 통합 모습은 다음과 같았습니다. 저희는 모든 곳에서 Python을 사용하기 때문에, OpenAI 호환 클라이언트 (OpenAI-compatible client)는 별도의 수정 없이 바로 적용(drop-in)할 수 있었습니다.

import openai
import os
from typing import Optional
...

이 코드 블록은 기존에 OpenAI SDK를 중심으로 작성했던 약 600줄의 프로바이더 특정 글루 코드 (provider-specific glue code)를 대체했습니다. 애플리케이션 계층 (application tier) 관점에서의 마이그레이션은 base_url을 교체하는 것이 전부였습니다. 흥미로운 작업은 그 외의 모든 곳, 즉 관측성 스택 (observability stack), 폴백 경로 (fallback paths), 비용 귀속 대시보드 (cost attribution dashboards)에서 이루어졌습니다.

워크로드 유형별 트래픽 라우팅 (Routing Traffic By Workload Type)

여기서부터 제 아키텍처에 주관적인 견해가 반영되었습니다. 저는 모든 작업에 하나의 모델을 선택하지 않았습니다. 대신 라우터 (router)를 구축했습니다.

200K의 컨텍스트 (context)가 필요한 긴 컨텍스트 검색 (long-context retrieval) 작업의 경우, $0.55/$2.20 가격의 DeepSeek V4 Pro가 정답이었습니다. 200K 컨텍스트 윈도우 (context window)는 우리가 이미 GPT-4o로 보내던 것과 일치했으며, 비용은 출력 (output) 기준 78% 더 저렴했습니다.

p99가 1.5초 미만으로 유지되어야 하는 고용량, 저지연 (latency-sensitive) 트래픽의 경우, $0.27/$1.10 가격의 DeepSeek V4 Flash에 의존했습니다. 일주일간의 측정 결과, 평균 지연 시간 (average latency)은 1.2초, 처리량 (throughput)은 초당 약 320 토큰 (tokens/sec)을 기록했으며, 이는 동일한 기간 동안 GPT-4o에서 측정된 수치를 앞질렀습니다.

저렴하고 가벼운 분류 (classification) 버킷 (의도 탐지 (intent detection), 스팸 플래깅 (spam flagging) 등)의 경우, $0.20/$0.80 가격의 GLM-4 Plus는 DeepSeek V4 Flash 대비 50%의 비용 절감을 가져왔으며, 품질 측면에서는 어떠한 변화도 없었습니다.

Qwen3-32B는 짧은 형식의 생성 (short-form generation)을 위해 저희 라우터의 한 자리를 차지했습니다. 32K 컨텍스트 윈도우가 제한적이긴 하지만, 깊은 히스토리가 필요하지 않은 저희의 채팅 위젯 (chat widgets)에는 $0.30/$1.20의 가격이 그 제약을 감수할 만한 가치가 있었습니다.

실제로 구현된 라우터의 모습은 다음과 같습니다:

import openai
import os
import hashlib
...

이것은 정교한 머신러닝 (ML) 라우팅이 아닙니다. 결정론적 규칙 엔진 (deterministic rule engine)이며, 이것이 바로 SLA (Service Level Agreement)가 보장되어야 하는 시스템에서 제가 원하는 바입니다. 의외의 변수는 가동 시간 (uptime)의 적입니다.

실제로 중요했던 수치들

이 스택으로 약 6주 동안 운영한 후, 수치를 뽑아보았습니다. 너무 많은 마이그레이션 관련 포스트들이 실제 결과를 생략한다고 생각하기에, 이 수치들을 공유하고자 합니다.

평균 지연 시간 (latency)은 1.2초로 나타났으며, 이는 우리의 내부 목표치와 일치했습니다. 처리량 (throughput)은 부하 상황에서도 초당 약 320 토큰 (tokens/sec) 수준을 안정적으로 유지했습니다. 추론 (reasoning), 요약 (summarization), 지시 이행 (instruction-following)이 혼합된 우리의 평가 스위트 (evaluation suite) 전반에 걸친 벤치마크 점수는 평균 84.6%를 기록했습니다. 이는 Global API가 보고하는 수치와 일치하며, 우리의 내부 품질 검사 결과와도 약 2포인트 내외의 차이로 부합했습니다.

비용은 이전 GPT-4o 베이스라인과 동일한 워크로드 (workload)를 비교했을 때 52% 감소했습니다. 일부 범주 (buckets)에서는 더 나은 결과가 나왔고 (우리의 분류 (classification) 트래픽은 65%에 가까운 절감 효과를 보였습니다), 일부는 더 낮았습니다 (긴 문맥 (long-context)을 사용하는 DeepSeek V4 Pro 범주는 약 38% 수준이었습니다). 하지만 전체 수치는 제가 사전에 모델링했던 40~65% 범위 안에 확실히 들어왔습니다.

내가 채택한 신뢰성 패턴 (Reliability Patterns)

이러한 마이그레이션을 진행하는 모든 분께 제가 구현할 순서대로 몇 가지 권장 사항을 말씀드리겠습니다.

공격적으로 캐싱하세요 (Cache aggressively). 우리의 시맨틱 캐시 (semantic cache) 적중률은 첫 달 이내에 약 40%로 안정화되었습니다. 적중률이 40%라면, 캐시된 쿼리에 대해 추론 (inference) 비용을 40% 적게 지불하게 됩니다. 우리는 코사인 유사도 (cosine similarity) 임계값을 0.92로 설정한 Redis 기반 임베딩 캐시 (embedding cache)를 사용했습니다. 중요한 지표는 적중률입니다. 만약 적중률이 20% 미만이라면, 캐시 키 (cache key) 전략을 개선해야 합니다.

응답을 스트리밍하세요 (Stream responses). 사용자 경험 개선 외에도, 스트리밍은 체감 지연 시간 (perceived latency)을 극적으로 줄여줍니다. p99가 1.2초일 때, 고객이 토큰이 나타나는 것을 200ms에서 보느냐 1,200ms에서 보느냐의 차이는 만족도 점수에 있어 엄청난 차이를 만듭니다. 이 부분이야말로 Global API의 OpenAI 호환 인터페이스가 빛을 발하는 지점입니다. 스트리밍 API가 그냥 제대로 작동하기 때문입니다.

폴백 경로(fallback path)를 확보하세요. 저는 특정 모델에서 세 번 연속 실패가 발생하면 60초 동안 트래픽을 보조 모델로 전환하는 서킷 브레이커(circuit breaker)를 라우터에 구축했습니다. 덕분에 서비스가 중단될 뻔했던 한 공급업체 측 장애 상황을 무사히 넘길 수 있었습니다. 99.9%의 SLA(Service Level Agreement)를 유지해야 한다면, 우아한 성능 저하(graceful degradation)는 타협할 수 없는 필수 사항입니다.

품질을 지속적으로 모니터링하세요. 단순히 지연 시간(latency)과 에러만 모니터링해서는 안 됩니다. 사용자의 만족도 신호 — 좋아요/싫어요(thumbs up/down), 재생성률(regeneration rates), AI 출력물을 언급하는 고객 지원 티켓 등을 추적하세요. 저는 모델 교체 후 지연 시간은 개선되었지만 요약 품질이 약간 저하되었음에도 이를 2주 동안 인지하지 못했던 뼈아픈 경험을 통해 이를 배웠습니다.

단순한 쿼리에는 GA-Economy를 사용하세요. GA-Economy는 기본적인 의도 분류(intent classification)나 단순 변환과 같이 중요도가 낮은 트래픽을 라우팅하는 티어(tier)입니다. 표준 티어 대비 50%의 비용 절감 효과는 실질적이며, 이러한 워크로드의 경우 품질 저하가 최종 사용자에게는 거의 느껴지지 않습니다.

문제가 되었던 부분들

모든 과정이 매끄러웠던 것은 아닙니다. 몇 가지 솔직한 피드백을 공유하자면 다음과 같습니다.

첫 주에는 모든 모델이 동일한 응답 메타데이터(response metadata)를 생성할 것이라고 가정했기 때문에 관측성(observability)이 엉망이었습니다. 실제로는 그렇지 않았습니다. API 응답과 로컬 토크나이저(tokenizer)가 계산한 토큰 수가 1~2개 정도 차이가 나는 경우가 있었고, 이로 인해 비용 대시보드가 몇 퍼센트 정도 어긋났습니다. 저희는 API가 보고하는 토큰을 절대적인 기준(ground truth)으로 신뢰함으로써 이 문제를 해결했습니다.

스트리밍 동작 또한 모델마다 미묘하게 달랐습니다. DeepSeek V4 Flash는 가끔 GPT-4o보다 더 큰 청크(chunk) 단위로 토큰을 배치(batch)하는 경향이 있었는데, 이로 인해 저희 채팅 위젯에서 사용자 경험이 약간 끊기는 현상이 발생했습니다. 클라이언트 측에서 스트리밍 버퍼(streaming buffer)를 조정하여 문제를 해결했지만, 이를 처리하는 데 주말을 통째로 써야 했습니다.

마지막으로, 한 제품 팀이 긴 문서를 보내면서 모델이 자연스럽게 잘라낼(truncate) 것이라고 가정했을 때, Qwen3-32B의 32K 컨텍스트 윈도우(context window)로 인해 한 차례 문제가 발생했습니다. 모델은 에러를 발생시켰습니다. 이제 우리는 요청이 우리 플릿(fleet)을 떠나기 전에 애플리케이션 계층(application layer)에서 컨텍스트 길이 체크를 강제합니다. 교훈을 얻었습니다: 35K 문서에 32K 윈도우를 절대 신뢰하지 마세요.

솔직한 견해

만약 현재 OpenAI에서 프로덕션 워크로드(production workload)를 실행 중이고 청구 비용이 부담스러워지기 시작했다면, Claude(또는 Global API에 있는 다른 183개 모델 중 하나)로 전환하는 것은 진정으로 그럴만한...