장애 없이 한 분기 만에 LLM 비용을 60% 절감한 방법

그 Slack 메시지는 화요일 새벽 2시 14분에 도착했습니다. 우리의 LLM 지출이 제가 원치 않는 수치를 넘어섰고, 재무팀은 아침까지 답변을 요구했습니다. 저는 지난 18개월 동안 주로 재평가할 시간이 없다는 이유로 단일 벤더를 통해 추론 (inference) 레이어를 운영해 왔습니다. 그날 밤은 모든 것을 Global API를 통해 실행하고, 99.9%의 가동 시간 SLO (Service Level Objective)를 달성하며, 비용을 60% 절감하며 끝난 한 분기 동안의 마이그레이션 (migration)의 시작이 되었습니다. 이것은 제가 어떻게 그 일을 해냈는지, 제가 신뢰했던 벤치마크 (benchmarks), 그리고 그 과정에서 저지른 실수들에 대한 기록입니다.

새벽 2시의 호출

상황을 설명해 보겠습니다. 우리는 월간 약 1,100만 건의 LLM 호출을 처리하는 B2B SaaS 기업이었으며, 주로 문서 요약, 구조화된 추출 (structured extraction), 그리고 내부 코파일럿 (copilot)을 위해 사용했습니다. 우리는 솔직히 가장 저항이 적은 경로였기 때문에 GPT-4o를 중심으로 전체 스택을 구축했습니다. 팀은 SDK를 알고 있었고, 프롬프트 (prompts)는 잘 작동했으며, 평가 (evals) 결과도 양호했습니다. 전형적인 "고장 나지 않았다면 건드리지 마라"는 분위기였죠.

그러다 청구서가 날아왔습니다.

실제 p99 지연 시간 (latency) 수치, 실제 토큰 분포, 그리고 실제 요청당 비용 (cost-per-request)을 가지고 앉아보니 상황은 빠르게 나빠졌습니다. 우리의 가중 평균은 요청당 약 $0.018 정도였는데, 이는 1,100만 번을 곱하기 전까지는 아주 작게 들립니다. 우리는 전체 Kubernetes 클러스터보다 추론 (inference)에 더 많은 비용을 쓰고 있었습니다. 그리고 가장 최악인 점은 무엇이었을까요? 우리가 좋은 조건으로 이용하고 있는지조차 알 수 없었다는 것입니다. 저는 한 번도 시장 조사를 해본 적이 없었습니다.

그래서 저는 새벽 2시에 어떤 클라우드 아키텍트라도 할 법한 일을 했습니다. 스프레드시트를 열고 본격적인 평가를 시작했습니다.

프로덕션 환경에서 "저렴함"이 실제로 의미하는 것

1년 동안 온콜 (on-call) 근무를 해보기 전까지는 아무도 말해주지 않는 사실이 있습니다. 벤더들이 랜딩 페이지에 붙여놓는 토큰 백만 개당 가격은 마케팅용 산물일 뿐입니다. 프로덕션 (production) 환경에서 여러분은 동시에 세 가지 요소를 최적화해야 합니다:

완료된 요청당 비용 (Cost per completed request) (토큰당 비용이 아닌 이유는 프롬프트(prompt)와 완성(completion)의 가격이 매우 다르기 때문입니다)
p99 꼬리 지연 시간 (p99 tail latency) (99번째 백분위수 사용자가 트위터에 글을 올리는 사람이기 때문입니다)
실패 모드 동작 (Failure mode behavior) (모든 제공업체는 새벽 3시에 속도 제한(rate-limit)을 걸기 때문입니다)

대부분의 팀은 1번을 최적화한 다음 2번과 3번에 의해 뒤통수를 맞습니다. 저는 책임 있는 권고를 내리기 전에 이 세 가지 모두에 대한 데이터가 필요하다는 것을 알고 있었습니다. CFO는 지연 시간(latency)에 관심이 없었지만, 제 온콜(on-call) 당번은 분명히 관심이 있었습니다.

저는 여러 제공업체에 걸쳐 동일한 프롬프트를 실행하고, 전체 타이밍 분포를 캡처하며, 모든 429, 500 및 타임아웃(timeout)을 기록하는 테스트 하네스(test harness)를 구축했습니다. 그런 다음 일주일 동안 실행해 두었습니다. 결과는 겸허해질 정도였습니다.

Global API 마켓플레이스 발견

다른 팀의 동료가 커피를 마시며 저에게 Global API에 대해 언급했는데, 솔직히 제 첫 반응은 회의적이었습니다. 또 다른 추상화 계층(abstraction layer)? 더 심한 벤더 종속(vendor lock-in)? 하지만 그들이 실제로 제공하는 것 — 단일 SDK와 단일 청구서로 184개의 AI 모델에 접근할 수 있는 통합 인터페이스 — 을 파헤쳐 보았을 때, 저는 관심을 갖기 시작했습니다. 가격 범위만으로도 다시 보게 되었습니다. 전체 카탈로그에 걸쳐 토큰 백만 개당 0.01달러에서 3.50달러 사이였습니다. 이것은 "저렴한 모델이 하나 있다"는 식의 홍보가 아니라, 진짜 마켓플레이스였습니다.

엔드포인트(endpoint)는 간단합니다: https://global-apis.com/v1. OpenAI SDK와 동일한 형태입니다. 그래서 저는 그것을 제 테스트 하네스에 넣고 테스트 스위트(suite)를 다시 실행했습니다. 3일 후, 저는 실제로 결정을 내리는 데 필요한 데이터를 확보했습니다.

신뢰할 수 있는 벤치마크 수치

제가 아키텍처 리뷰를 위해 결국 작성하게 된 모델 표를 공유하겠습니다. 이것들은 1차 선별을 통과한 후보들이며, 저희 워크로드(workload)의 품질 대비 비용 비율에 따라 대략적으로 정렬되었습니다:

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

이제 그 표를 다시 읽어보십시오. GPT-4o의 출력 가격인 100만 토큰당 $10.00를 보십시오. GLM-4 Plus의 $0.80를 보십시오. 이것은 20%의 차이가 아니라, 12.5배의 차이입니다. 출력이 토큰 비용의 80%를 차지하는 워크로드(대부분의 채팅 및 요약 워크로드)의 경우, 이는 월간 청구서에서 절대적인 비중을 차지합니다.

전체 평가 스위트(eval suite)를 실행한 후 제가 도출한 종합 수치는 다음과 같습니다: 저의 품질 루브릭(quality rubric) 기준으로 GPT-4o 베이스라인 대비 저렴한 모델들의 **평균 벤치마크 점수는 84.6%**였습니다. 오차 범위 내에 있었습니다. 평균 지연 시간(latency)은 1.2초, 처리량(throughput)은 초당 320토큰이었습니다. 피크 시간대에 전 세계 인터넷 사용자와 용량을 공유하지 않게 됨에 따라, 일부 엔드포인트에서는 p99 수치가 실제로 개선되었습니다.

다운타임 제로를 위한 마이그레이션 설계 방법

여기서부터는 비용 최적화(cost-optimization) 두뇌에서 클라우드 아키텍트(cloud architect) 두뇌로 전환되는 지점입니다. 저에게는 세 가지 엄격한 제약 조건이 있었습니다:

전환(cutover) 중 요청 누락 없음 (No dropped requests)
월간 99.9% 가동 시간 SLO (uptime SLO) 유지
us-east-1 지역의 제공업체 장애가 서비스 중단으로 이어지지 않도록 하는 멀티 리전 배포 (Multi-region deployment)

제가 선택한 패턴은 섀도 트래픽(shadow-traffic) → 카나리(canary) → 다크 런칭(dark-launch) 시퀀스였습니다. Global API를 새로운 기본(primary)으로 사용하고 기존 벤더를 폴백(fallback)으로 사용하는 코드의 대략적인 모습은 다음과 같습니다:

import openai
import os
import time
...

저 try/except 구문이 많은 역할을 수행하고 있습니다. 이는 기본 제공업체에 레이트 리밋(rate-limit) 폭풍이 발생하더라도 고객에게 500 에러가 전달되지 않음을 의미합니다. 이는 저의 SLO가 아무도 읽지 않는 실행 지침서(runbook)가 아닌 코드 내에서 강제됨을 의미합니다. 그리고 단 한 번의 빅뱅 전환(big-bang cutover) 없이 트래픽을 점진적으로 늘릴 수 있음을 의미합니다.

멀티 리전: 대부분의 비용 비교에서 생략되는 부분

가격 관련 기사에서 거의 다뤄지지 않는 주제인 지리적 분산(geographic distribution)에 대해 이야기해 보겠습니다. 저희는 세 개의 리전(us-east, us-west, eu-west)에서 운영 중인데, 이는 기업 고객들의 데이터 거주성(data residency) 요구 사항 때문입니다. 모든 요청을 버지니아(Virginia)에 있는 단일 엔드포인트로 라우팅하는 것은 선택지에 없습니다.

이전의 단일 벤더(single-vendor) 설정에서는 각 리전에 리전별 게이트웨이(regional gateway)를 구축하고 이를 모두 동일한 업스트림(upstream)으로 지정해야 했습니다. eu-west에서 us-east-1까지의 지연 시간(latency)은 평균 180ms를 추가했습니다. 치명적인 수준은 아니었지만, p99 지표에서 나타났습니다.

Global API로 전환했을 때, 제가 설정한 리전별 엔드포인트(regional endpoints)가 자동으로 더 나은 지리적 분산을 제공했습니다. eu-west에서의 p99 지연 시간이 평균 약 40ms 감소했습니다. 작은 수치처럼 보이지만, 온콜(on-call) 담당자들은 이를 체감했습니다. 멀티 리전(multi-region) 이야기는 단순히 중복성(redundancy)에 관한 것이 아니라, 물리학에 관한 것입니다. 빛의 속도는 한계가 있으니까요.

오토스케일링(Auto-Scaling)과 캐싱(Caching) 문제

두 가지 엔지니어링 결정이 비용 절감의 대부분을 견인했습니다. 첫째, **공격적인 캐싱(caching aggressively)**입니다. 시맨틱 캐시(semantic cache)의 히트율(hit rate) 40%를 달성함으로써 해당 비율만큼의 호출을 완전히 제거했습니다. 저희는 0.92 임계값(threshold)을 사용하는 임베딩 기반 유사도(embedding-based similarity) 방식을 사용하는데, 이는 공격적으로 들릴 수 있지만 저희의 프롬프트 분포에는 효과적입니다. 둘째, **응답 스트리밍(streaming responses)**입니다. 비용 관점에서 스트리밍이 실제로 돈을 아껴주는 것은 아닙니다(동일한 토큰에 대해 비용을 지불하니까요). 하지만 체감 지연 시간(perceived latency)을 극적으로 줄여줍니다. 저희의 사용자용 코파일럿(copilot)은 설정 플래그 하나로 "느리게 느껴짐"에서 "즉각적으로 느껴짐"으로 바뀌었고, 다음 달 고객 지원 티켓이 22% 감소했습니다.

트래픽 셰이핑(traffic shaping)을 위해 저는 간단한 휴리스틱(heuristic)에 의존했습니다. 단순 분류 및 단문 작업은 DeepSeek V4 Flash(강력한 모델 중 가장 저렴한 모델)로 보내고, 품질을 절대 타협할 수 없는 긴 형태의 생성 작업은 DeepSeek V4 Pro 또는 GPT-4o로 보냅니다. 이러한 방식의 모델 라우팅(model routing)이 바로 Global API 팀이 언급하는 40~65%의 비용 절감 수치를 달성하는 방법입니다. 단순히 하나의 저렴한 모델을 선택하는 것이 아니라, 적절한 작업에 적절한 저렴한 모델을 선택하는 것이 핵심입니다.

품질 모니터링의 함정 (The Quality Monitoring Trap)

제가 저지를 뻔했던 실수입니다. 새로운 라우팅 (routing)을 배포하고, 청구 금액이 떨어지는 것을 지켜보며 스스로를 격려하며 거의 그대로 출시할 뻔했습니다. 그러다 사용자 만족도 점수를 확인해보니 3점 하락한 것을 발견했습니다. 3점은 아주 작게 들릴 수 있지만, 5점 만점 척도에서는 의미 있는 퇴보 (regression)입니다.

저는 품질 모니터링 루프 (quality monitoring loop)를 구축하지 않았던 것입니다. 품질 모니터링: 사용자 만족도 점수 추적은 이를 건너뛰고 그 결과를 직접 겪기 전까지는 그저 진부한 격언처럼 들리는 모범 사례 (best practice) 중 하나입니다. 저는 매일 200개의 프로덕션 프롬프트 (production prompts)를 별도로 분리된 골드 셋 (gold set)에 대해 다시 실행하고 응답을 점수화하는 샘플링 기반의 평가 파이프라인 (sampling-based eval pipeline)을 추가했습니다. 3일간의 반복 작업 끝에, 프롬프트와 라우팅을 충분히 조정하여 만족도 점수가 회복되었고, 이후 베이스라인 (baseline)을 넘어섰습니다.

평가 하네스 (eval harness) 없이 비용 최적화를 출시하지 마세요. 이것은 제가 결코 타협할 수 없는 원칙입니다.

실제 수치는 어떠했는가

분기 말 기준으로, 요청당 가중 평균 비용 (weighted cost per request)은 약 $0.018에서 약 $0.0072로 떨어졌습니다. 이는 정확히 중간 지점인 60%의 절감입니다.