LLM 비용을 65% 절감한 방법 — CTO의 실전 플레이북

솔직히 말해서, 저는 예전에 가동 시간(uptime) SLA 보장을 단순히 체크박스 하나 채우는 정도로 여겼습니다. 그러다 14시간 동안 지속된 지역적 장애로 인해 우리의 전체 추론 계층(inference layer)이 무너지는 것을 목격했고, 갑자기 벤더의 마케팅 페이지에 적힌 그 약속들이 우리 스택에서 가장 비싼 단어들이 되어버렸습니다.

2026년에 AI 제공업체를 선택할 때 아무도 말해주지 않는 사실이 있습니다. 모델 벤치마크(benchmarks)가 모든 관심을 받지만, 실제 운영 경제성(production economics)은 가동 시간 SLA 비교에서 결정된다는 점입니다. 저는

Model	Input ($/M)	Output ($/M)	Context
DeepSeek V4 Flash	0.27	1.10	128K
...

GPT-4o의 출력 가격을 보세요. 백만 토큰당 $10.00입니다. 오타가 아닙니다. 저희 실제 워크로드, 즉 긴 컨텍스트 검색(long-context retrieval)과 구조화된 생성(structured generation)이 혼합된 경우를 가정하면, 월간 약 8억 개의 출력 토큰을 사용합니다. 이 양만 GPT-4o로 처리할 경우, 생성 측면에서만 매월 $8,000가 발생합니다.

그런데 DeepSeek V4 Pro의 출력 가격은 백만 토큰당 $2.20입니다. 저희 사용 사례에 동일한 품질 등급인데도 불구하고 약 4.5배 더 저렴합니다. 계산 자체가 비교할 수 없을 정도입니다. 하지만 가장 놀라웠던 부분은 이것이었습니다. SLA 데이터를 비용 분석에 결합하기 시작했을 때, 단순히 저렴할 뿐만 아니라 종종 더 신뢰성이 높았습니다. 인프라를 유지하는 팀들은 레거시 부채(legacy debt)가 적고, 장애 조치 경로(failover paths)가 단순하며, 결정적으로 같은 온콜 로테이션(on-call rotation)을 두고 경쟁하는 백만 개의 다른 제품이 없었습니다.

저는 Global API의 통합 인터페이스를 통해 184개의 모델을 사용하기 시작했습니다. 대부분의 팀에게는 과도한 선택지일 수 있지만, 공급업체 종속성(vendor lock-in)을 피하려는 CTO에게는 정확히 원하는 옵션 가짓수(optionality)입니다. 전체 스택이 하나의 추상화 계층(abstraction)을 통해 실행되면, 공급업체를 전환하는 것이 분기 단위의 마이그레이션 작업이 아니라 설정 변경(config change)만으로 가능해집니다.

실제 프로덕션 환경에서 40-65% 비용 절감의 모습

저는 공급업체들이

그다음 우리는 구조화된 추출 파이프라인(structured extraction pipelines)을 출력 1M당 $0.80인 GLM-4 Plus로 옮겼습니다. 여기서 $2,100를 추가로 절감했습니다.

대화형 채팅 레이어(interactive chat layer)는 처음에는 GPT-4o를 유지했습니다. 우리만의 특정 유스케이스(use case)에 대해 검증되지 않은 모델로 고객 경험을 도박에 걸고 싶지 않았기 때문입니다. 하지만 3개월간의 A/B 테스트를 거친 후, 품질 차이(quality deltas)가 오차 범위 내에 있다는 것을 확인했습니다. 그래서 그 부분도 마이그레이션(migration)했습니다. 최종 청구 금액은 월 $4,960였습니다.

이는 65%의 절감입니다. 코드 변경 사항은요? 약 200줄 정도였으며, 대부분 설정(config) 변경이었습니다. 진짜 핵심 작업은 평가 하네스(evaluation harness)를 구축하는 것이었습니다. 각 워크로드(workload)를 전환할 수 있는 확신을 주는 테스트 스위트(test suite)를 만드는 작업 말입니다.

실제로 어떻게 연결했는가

대부분의 블로그 포스트가 저를 실망시키는 부분이 바로 여기입니다. 가격표는 보여주지만, 통합(integration) 과정은 절대 보여주지 않습니다. 그래서 여기 우리 프로덕션(production) 환경에서 실제로 실행되고 있는 코드를 공개합니다:

import openai
import os
from typing import Optional
...

이게 전부입니다. 이것이 추상화(abstraction)의 전부입니다. Global API가 OpenAI 호환 인터페이스를 제공하기 때문에, 우리가 이미 가지고 있던 SDK를 수정 없이 그대로 사용할 수 있습니다. 특정 워크로드에 대해 DeepSeek V4 Pro를 테스트하고 싶을 때, 저는 문자열 하나만 바꿉니다. 품질 벤치마크(quality benchmark)를 위해 GPT-4o와 비교하고 싶을 때도 문자열 하나만 바꿉니다.

이것이 실제 상황에서 벤더 락인(vendor lock-in)을 방지하는 모습입니다. 이론적인 이야기가 아닙니다. 이사회 보고용 슬라이드에 들어가는 내용도 아닙니다. 금요일 오후에 끝낼 수 있는 마이그레이션과 6주간의 엔지니어링 프로젝트 사이의 차이입니다.

실제로 중요했던 아키텍처 결정 사항들

업타임 SLA(uptime SLA) 비교가 일급 아키텍처 고려 사항(first-class architectural concern)임을 받아들이고 나면, 몇 가지 연쇄적인 결정이 뒤따릅니다:

워크로드 중요도에 따른 계층적 모델 선택(Tiered model selection by workload criticality). 우리의 결제 처리 추론(inference) 경로는 비용에 상관없이 가장 좋은 SLA를 제공하는 공급업체를 사용합니다. 배치 분석(batch analytics) 작업은 품질 임계값(quality thresholds)을 충족하는 가장 저렴한 모델을 사용합니다. 고객 대상 채팅은 그 중간 단계의 모델을 사용합니다. 이것이 우아한 방식은 아니지만, 대규모 환경에서 신뢰성과 비용을 모두 최적화하는 방법입니다.

모든 계층에서의 공격적인 캐싱 (Aggressive caching). 우리는 임베딩 (embeddings)을 캐싱하고, 일반적인 프롬프트 완성 (prompt completions)을 캐싱하며, 심지어 재개 가능한 연결 (resumable connections)을 위해 부분적으로 스트리밍된 응답까지 캐싱합니다. 우리의 히트 레이트 (hit rate)는 약 40% 수준이며, 이는 API 지출의 40% 감소로 직결됩니다. Redis 비용은 월 180달러입니다. 절감액은 월 4,400달러입니다. ROI (투자 대비 수익)는 압도적입니다.

적절한 곳이라면 어디든 스트리밍 (Streaming). 응답을 스트리밍 방식으로 전환했을 때 체감 지연 시간 (perceived latency)이 3.1초에서 1.2초로 줄어들었습니다. 사용자 만족도 점수가 상승했습니다. SDK가 이를 네이티브로 지원하기 때문에 엔지니어링 노력은 최소화되었습니다. 만약 당신이 2026년에 채팅 스타일의 인터페이스를 사용하면서 스트리밍을 구현하지 않고 있다면, UX 측면의 이득을 놓치고 있는 것입니다.

폴백 (fallback)이 아닌 기능으로서의 우아한 성능 저하 (Graceful degradation). 기본 제공업체의 속도 제한 (rate limiter)이 작동할 때, 우리는 사용자에게 에러를 반환하지 않습니다. 대신 중요도가 낮은 쿼리에 대해서는 더 저렴하고 빠른 모델로 성능을 낮추고(degrade), 나머지는 대기열 (queue)에 넣습니다. 고객은 응답을 받고, 엔지니어는 호출(page)을 받으며, 제품은 살아남습니다. 이 패턴 하나만으로 지난 분기에 발생한 세 번의 별도 장애 상황을 극복할 수 있었습니다.

내가 신뢰하는 벤치마크 수치들

벤더(Vendor)의 벤치마크는 식당 리뷰와 같습니다. 시작점으로서는 유용하지만, 확신하기 전에 직접 맛을 봐야 합니다. 다음은 90일 동안 우리의 특정 워크로드 (workloads)에 대해 측정한 수치입니다:

• 평균 지연 시간 (latency): 첫 번째 토큰까지 1.2초, 처리량 (throughput) 초당 320 토큰
• 상위 3개 모델 선택지의 유효 가동 시간 (effective uptime): 99.91%, 99.84%, 99.76%
• 품질 벤치마크 평균: 내부 평가 (eval) 스위트 기준 84.6%
• 100만 토큰당 비용 (워크로드 혼합 기준): $0.43

이 혼합 비용 수치가 바로 CFO (최고재무책임자)에게 중요한 지표입니다. 이 수치는 AI 인프라가 비즈니스의 마진을 깎아먹는 요소인지, 아니면 마진을 증폭시키는 요소인지를 말해줍니다. 우리는 AI가 가장 큰 비용 센터 중 하나였던 상태에서, 가장 효율적인 시스템 중 하나로 거듭났습니다.

당신은 하지 않도록 내가 저지른 실수들

캐싱 레이어 (caching layer)를 수정하기 전에 요청 수준 (request level)에서 모델 선택을 최적화하려고 시도하며 3개월을 허비했습니다. 잘못된 곳에 에너지를 쏟은 것이었습니다. 만약 이 여정을 시작한다면, 먼저 트래픽 패턴 (traffic patterns)을 감사(audit)하십시오. API 호출의 60%가 캐시에서 처리될 수 있는 중복 또는 유사 중복 호출이라는 사실을 발견하게 될 수도 있습니다.

또한 초기에는 지연 시간 (latency)에 과도하게 집중했습니다. 본질적으로 비동기 (async) 방식인 워크플로 (workflow)에 대해 500ms 미만의 응답 시간을 추구했습니다. 사용자는 신경 쓰지 않았고, 비즈니스도 신경 쓰지 않았습니다. 저는 비용과 신뢰성을 최우선으로 고려하고, 지연 시간은 그다음으로 고려했어야 했습니다.

그리고 가장 큰 실수는 이것입니다. 가장 비싼 모델이 가장 높은 품질일 것이라고 가정했습니다. 어떤 워크로드 (workloads)에서는 그것이 사실입니다. 하지만 저희의 대부분의 경우에는 그렇지 않았습니다. 제가 신뢰하는 벤치마크 (benchmark)는 저만의 데이터로, 저만의 평가 프롬프트 (evaluation prompts)를 사용하여, 저만의 품질 지표 (quality metrics)를 측정한 것입니다. 그 외의 모든 것은 진실이 아닌 신호 (signal)일 뿐입니다.

이를 바로잡은 후 변화된 것들

엔지니어링 팀은 추론 (inference) 장애를 해결하기 위한 급한 불 끄기를 멈췄습니다. AI 관련 사고에 대한 온콜 (on-call) 순번이 주 단위에서 분기 단위로 줄어들었습니다. 비용 예측이 충분히 예측 가능해짐에 따라, 재무 부서에서도 AI 지출을 가변 비용으로 분류하는 것을 중단했습니다. 이제 AI 비용은 엄격한 범위 내에 있는 항목 (line item)이 되었습니다.

더 중요한 것은, 우리가 더 빠르게 제품을 출시하게 되었다는 점입니다. 모델 레이어 (model layer)가 깔끔하게 추상화되면, 새로운 제공업체 (providers)로 실험하는 것이 한 스프린트 (sprint) 단위의 작업이 아니라 반나절짜리 프로젝트가 됩니다. 이제 우리는 모든 새로운 기능에 대해 두세 개의 모델 티어 (model tiers)를 A/B 테스트합니다. 반복 루프 (iteration loop)는 긴밀해졌고, 실패 비용은 낮아졌으며, 우리가 구축할 수 있는 한계치는 1년 전보다 훨씬 높아졌습니다.

이에 대한 나의 결론

만약 당신이 2026년에 인프라 결정을 내리는 CTO라면, SLA 티어 (SLA tier)는 각주가 아닙니다. 그것은 기반입니다. 이를 기준으로 제공업체를 선택하고, 이를 중심으로 설계하며, 환경이 빠르게 변하기 때문에 분기별로 재검토하십시오. 2년 전의 가격 모델은 오늘날의 가격 모델과 전혀 다르며, 신뢰성 프로필 (reliability profiles)은 훨씬 더 가변적입니다.

좋은 소식은, 통합 API 인터페이스 (unified API surface)를 통해 184개의 모델을 사용할 수 있게 되면서, 더 이상 불확실성 속에서 이러한 결정을 내릴 필요가 없다는 것입니다. 추상화 계층 (abstraction layer)을 한 번 구축해 두면, 그 이후에는 지속적으로 최적화할 수 있습니다. 이것이 바로 제가 18개월 전에 처해 있었기를 바랐던 상황입니다.

만약 여러분도 비슷한 결정 문제로 고민하고 있고, 가격 데이터와 SLA 티어 (SLA tiers)를 한곳에서 확인하고 싶다면, Global API를 살펴보는 것이 가치가 있습니다. 그들의 통합 SDK (unified SDK) 덕분에 우리의 멀티 프로바이더 (multi-provider) 설정은 거의 지루할 정도로 간단해졌는데, 이는 제가 인프라 소프트웨어에 줄 수 있는 최고의 찬사입니다.

여러분만의 AI 인프라 구축 과정을 진행 중이라면 기꺼이 질문에 답변해 드리겠습니다. 제가 설명한 패턴들이 보편적인 것은 아니지만, '먼저 측정하고, 그다음에 추상화하며, 지속적으로 최적화한다'는 접근 방식은 현재까지 세 곳의 서로 다른 스타트업에서 저에게 큰 도움이 되었습니다.