LLM 비용을 40배 절감한 방법 — CTO의 마이그레이션 플레이북

3개월 전, 저는 월간 인프라 인보이스(invoice)를 열어보고 커피를 마시다 사레가 들릴 뻔했습니다. 우리의 성장 지표가 정당화할 수 있는 속도보다 더 빠르게 OpenAI 크레딧을 소진하고 있었기 때문입니다. 저는 시드 단계의 SaaS 기업의 CTO이며, 2026년의 대부분의 엔지니어링 리더들과 마찬가지로 — 솔직히 말해서 — 가장 저항이 적은 경로였기에 OpenAI를 기본값으로 사용해 왔습니다. 훌륭한 문서, 훌륭한 SDK, 훌륭한 모델 품질까지 갖추고 있었죠. 하지만 유닛 이코노믹스 (unit economics)가 파괴되고 있을 때, "훌륭함"은 비용을 지불해주지 않습니다.

이것은 제가 단 한 번의 스프린트(sprint) 만에 전체 LLM 스택을 OpenAI에서 마이그레이션(migration)하고, 추론(inference) 비용을 40배 절감했으며, 그 과정에서 (다소 우연하게도) 벤더 종속(vendor lock-in) 상황의 리스크를 제거한 이야기입니다. 만약 당신이 눈덩이처럼 불어나는 AI 비용을 마주하고 있는 CTO나 파운딩 엔지니어라면, 제가 이미 수행한 몇 주간의 연구 시간을 아껴드리고 싶습니다.

대안을 고려하게 만든 수학적 계산

상황을 설명해 보겠습니다. 저희 제품은 문서 파싱(parsing), 고객 피드백 요약, 원시 사양으로부터 제품 설명 생성 등 많은 양의 구조화된 추출(structured extraction) 작업을 수행합니다. 저희는 모든 것을 GPT-4o를 통해 실행하고 있었는데, 다시 말하지만 기본값이었기 때문입니다. GPT-4o의 비용은 입력 토큰 100만 개당 $2.50, 출력 토큰 100만 개당 $10.00입니다. 이 수치들은 실제 운영 볼륨(production volume)을 곱하기 전까지는 합리적으로 느껴집니다.

저희 규모에서는 한 달에 대략 2억 개의 토큰을 처리하고 있었습니다. 계산해 봅시다: $2.50 × 1억 개의 입력 토큰 + $10.00 × 1억 개의 출력 토큰 = 추론 비용만 월 $1,250입니다. 스타트업에게 아주 미친 금액은 아니지만, 가장 빠르게 증가하는 항목이었고, 조치를 취하지 않고서는 비용이 낮아질 기미가 보이지 않았습니다.

그 후 저는 대안들을 벤치마킹(benchmarking)하기 시작했습니다. 전체 평가 매트릭스(evaluation matrix)로 여러분을 지루하게 만들지는 않겠지만, 제 오후 회의를 취소하게 만든 표는 다음과 같습니다:

모델 (Model)	제공업체 (Provider)	입력 $/M	출력 $/M	GPT-4o 대비
GPT-4o	OpenAI	$2.50	$10.00	—
...

입력 $0.18, 출력 $0.25인 DeepSeek V4 Flash는 GPT-4o보다 40배 더 저렴합니다. 40% 저렴한 것이 아닙니다. 40배입니다. 우리의 사용량(volume)을 기준으로 하면, 동일한 2억(200M) 토큰의 비용은 $1,250 대신 $31이 됩니다. 소수점 위치가 믿기지 않아서 이 계산을 세 번이나 다시 했습니다.

투자 대비 효과(ROI)는 부정할 수 없었습니다. 유일한 질문은 마이그레이션(migration) 비용이었습니다.

벤더 종속(Vendor Lock-In) 문제

구현에 대해 이야기하기 전에, CTO들이 충분히 논의하지 않는 주제인 전략적 리스크로서의 벤더 종속(vendor lock-in)에 대해 이야기하고 싶습니다. 제품의 지능 계층(intelligence layer) 전체가 하나의 제공업체에서 실행될 때, 여러분은 단일 장애점(single point of failure)을 갖게 됩니다. 가격 변동, 정책 변경, 지역적 제한, API 지원 중단(deprecation) — 이 중 어떤 것이라도 하룻밤 사이에 여러분의 제품을 무력화할 수 있습니다.

OpenAI는 경이로운 기업이지만, 이미 여러 차례 가격을 인상하고 약관을 변경한 영리 기업이기도 합니다. 저는 클라우드 제공업체가 가격 티어(pricing tiers)를 변경할 때 스타트업들이 압박을 받는 모습을 너무 많이 봐왔습니다. 추상화 계층(abstraction layers)을 조기에 구축하는 것이 여러분이 살 수 있는 가장 저렴한 보험입니다.

이것이 제가 모든 대안을 평가할 때 사용한 관점입니다. 저는 단순히 더 저렴한 토큰만을 원한 것이 아닙니다. 제가 구축한 추상화 계층을 온전히 유지할 수 있도록 동일한 API 방언(dialect)을 사용하는 제공업체를 원했습니다. OpenAI API 형식은 사실상 업계 표준이 되었으며, 이를 지원하지 않는 제공업체는 저에게 전체 코드베이스를 다시 작성하라고 요구하는 것과 같습니다.

마이그레이션 (스포일러: 오후 한나절이면 끝났습니다)

제가 이 글을 쓰고 있다는 사실조차 믿기지 않는 부분입니다. 테스트를 포함한 실제 코드 마이그레이션은 약 4시간 정도 걸렸습니다. 그 시간의 대부분은 CI 파이프라인(CI pipeline)이 끝나기를 기다리는 시간이었습니다. 코드 변경 자체는요? 단 두 줄이었습니다.

만약 여러분이 OpenAI Python SDK를 사용하고 있다면 — 솔직히 말해서 대부분이 그러하겠지만 — 변경된 내용은 말 그대로 이것이 전부입니다:

# 이전 (Before)
from openai import OpenAI
client = OpenAI(api_key="sk-...")
...

저는 새로운 SDK를 작성하지 않았습니다. 서비스 레이어 (service layer)를 다시 작성하지도 않았습니다. 프롬프트 템플릿 (prompt templates)을 리팩터링하지도 않았습니다. 저는 API 키를 변경하고, base_url을 Global API의 엔드포인트 (endpoint)로 지정한 뒤, 모델 이름 (model name)을 교체했을 뿐입니다. 이것이 저희 모노레포 (monorepo)에서 발생한 변경 사항의 전부입니다.

저희 팀의 JavaScript 개발자들에게도 변경 사항은 마찬가지로 사소했습니다:

import OpenAI from 'openai';

const client = new OpenAI({
...

동일한 SDK. 동일한 메서드 시그니처 (method signatures). 동일한 스트리밍 (streaming) 동작. 동일한 함수 호출 (function calling) 형식. 팀원들은 솔직히 의심스러워했습니다. 이전에도 "즉시 교체 가능한 (drop-in replacements)"라고 했지만, 결국 "추상화 계층을 모두 다시 작성하고 기도나 하라"는 식의 경험을 한 적이 있었기 때문입니다. 하지만 이번에는 실제로 결과가 나타났습니다.

변하지 않는 것 (그리고 변하는 것)

저는 제가 발견한 바를 솔직하게 말씀드리고 싶습니다. 프로덕션 환경에 적합한 마이그레이션 (migration)에는 정직함이 필요하기 때문입니다. Global API를 8주 동안 프로덕션에서 운영한 후, 기능별로 분석한 결과는 다음과 같습니다.

동일하게 작동하는 것:

• Chat Completions (말 그대로 동일한 엔드포인트 구조)
• SSE를 통한 스트리밍 (Streaming via SSE)
• 함수 호출 (Function calling) / 도구 사용 (tool use)
• response_format을 이용한 JSON 모드 (JSON mode)
• 비전 기능 (Vision capabilities) (이미지 분류를 위해 Qwen-VL로 테스트함)
• 응답 내 토큰 사용량 보고 (Token usage reporting)

포기한 것:

• 파인튜닝 (Fine-tuning) — Global API는 호스팅된 파인튜닝을 제공하지 않으므로, 베이스 모델 (base models)이 알고 있는 지식에 의존해야 합니다. 저희에게 이것은 문제가 되지 않았습니다. 어차피 프로덕션에서 GPT-4o를 파인튜닝한 적은 없었기 때문입니다.
• Assistants API — 스레드 (thread)/파일 (file)/어시스턴트 (assistant) 추상화는 OpenAI 전용입니다. 저희는 검색 파이프라인 (retrieval pipeline)에 대해 더 많은 제어권을 원했기 때문에 이를 사용하지 않았습니다.
• TTS/STT — 음성 관련 기능은 전용 제공업체를 계속 사용합니다. 저는 이 기능들이 어차피 항상 별도의 서비스여야 한다고 주장합니다.

저희 워크플로 (workflow)에서 변경된 점:

• 모델 폴백 (fallback) 로직을 추가하여 DeepSeek V4 Flash에 지연 시간 스파이크 (latency spikes)가 발생할 경우, 자동으로 DeepSeek V4 Pro 또는 GLM-5로 재시도하도록 했습니다. 이는 세 개의 독립적인 제공업체를 확보하게 됨으로써 실제로 우리의 p99 지연 시간 (p99 latency)을 개선했습니다.
• 관측성 스택 (observability stack)에 모델별 비용 추적 기능을 설정하여, 모델별 지출 내역을 실시간으로 확인할 수 있도록 했습니다.

실제 운영 환경의 현실 (The Production Reality)

벤치마크보다 제가 더 중요하게 생각하는 것은 이것입니다: 실제 사용자들이 새벽 3시에 API를 호출할 때 실제로 잘 작동하는가?

지연 시간 (Latency): 저희 테스트 결과, DeepSeek V4 Flash는 p50 지연 시간에서 실제로 GPT-4o를 능가했습니다. 아마도 OpenAI의 API가 그 성공의 희생양이 되었기 때문일 것입니다. 전 세계 모든 사람이 이를 호출하고 있으니까요. Global API는 트래픽 경합 (traffic contention)이 적습니다. 콜드 스타트 (Cold-start) 시간 또한 더 빠릅니다.

처리량 (Throughput): 피크 시간 동안 시간당 약 8,000개의 채팅 완료 (chat completions)를 처리합니다. 속도 제한 (rate limit) 문제는 없습니다. 제품 출시 중에 OpenAI의 티어 제한 (tier limits)에 걸려 고생했다는 무시무시한 이야기들을 들었지만, Global API를 사용하면서 저희는 근처에도 가본 적이 없습니다.

신뢰성 (Reliability): 8주 동안 두 건의 장애가 있었습니다. 하나는 저희의 잘못(배포 중 잘못된 재시도 로직)이었고, 다른 하나는 12분간의 성능 저하(degradation)였는데, 그들은 실제로 고객들에게 선제적으로 이메일을 보냈습니다. 인지하기까지 몇 시간이 걸리기도 하는 OpenAI의 상태 페이지 (status page) 장애들과 비교해 보십시오.

비용 (Cost): 여기 제 CEO가 복도에서 저와 하이파이브를 하게 만든 숫자가 있습니다. 지난달 청구서: $34. OpenAI를 사용하던 전월: $1,247. 현재 규모에서 연간 14,000달러 이상을 절감하고 있으며, 저희의 사용량은 여전히 증가하고 있습니다.

다른 CTO들에게 추천하는 전략

만약 제가 3개월 전으로 돌아가 스스로에게 조언할 수 있다면, 이렇게 말할 것입니다:

첫째, 비용이 고통스러워질 때까지 기다리지 마십시오. 당장 제공업체를 바꾸지 않더라도 지금 추상화 계층 (abstraction layer)을 구축하십시오. OpenAI SDK 주변에 얇은 래퍼 (wrapper)를 작성하는 비용은 오후 한나절이면 충분합니다. 하지만 벤더가 가격 정책을 변경했을 때 종속 (lock-in)되어 발생하는 비용은 기업의 생존 문제입니다.

둘째, 장난감 수준의 벤치마크 (toy benchmarks)가 아니라 실제 운영 규모 (production volume)에서 평가하십시오. 적은 워크로드에서는 반올림 오차처럼 보이는 토큰 가격 (token pricing)의 차이가, 규모가 커지면 수억 원 단위의 의사결정 문제가 됩니다. 저는 이제 매 분기마다 모든 주요 제공업체(provider)를 대상으로 지출 모델링을 수행하는 분기별 비용 검토를 실시합니다.

셋째, 표준 프로토콜 (standard protocols)을 따르는 제공업체를 선호하십시오. OpenAI API 형식은 사라지지 않을 것입니다. 독자적인 형식 (proprietary format)으로 경쟁 API를 구축하는 곳은 여러분에게 마이그레이션 부채 (migration debt)를 떠안으라고 요구하는 것과 같습니다. Global API가 OpenAI 호환성을 유지하기로 한 결정 덕분에 저는 다시는 종속 (lock-in)되지 않습니다. 단 두 줄의 코드 변경만으로 다른 호환 가능한 제공업체로 전환할 수 있기 때문입니다.

넷째, 무조건 가장 저렴한 옵션만을 쫓지 마십시오. DeepSeek V4 Flash는 대량의 저복잡도 작업에 매우 훌륭합니다. 하지만 우리의 파이프라인(pipeline) 내에서 다단계 에이전트 워크플로우 (multi-step agentic workflows)와 같이 정말 어려운 추론 (reasoning)이 필요한 경우에는 DeepSeek V4 Pro나 Kimi K2.5를 사용합니다. 이 경우 품질 차이 (quality delta)가 가격 상승을 정당화하기 때문입니다. 여기서 표 (table)가 중요합니다. 단순히 최저가 제공업체 하나만 두는 것이 아니라, 비용-품질 스펙트럼 (cost-quality spectrum) 전반에 걸친 옵션을 확보해야 합니다.

다섯째, 모든 것을 계측 (instrument)하십시오. 저는 이제 어떤 모델이 어떤 요청을 처리했는지, 비용은 얼마였는지, 시간이 얼마나 걸렸는지, 그리고 사용자가 출력물에 만족했는지를 모두 기록합니다. 이를 통해 추측하는 대신 지능적으로 최적화할 수 있습니다.

신입 사원에게 건네줄 코드

운영 환경에 적합한 마이그레이션이 어떤 모습인지 보고 싶다면, 폴백 로직 (fallback logic)이 포함된 Python을 사용한 약간 더 정교한 예시를 확인해 보십시오:

from openai import OpenAI
import os

...

저 base_url이 통합의 핵심 지점입니다. 그 외의 모든 것은 표준 OpenAI SDK입니다. 해당 URL을 다른 OpenAI 호환 제공업체로 바꾸기만 하면 그 외의 어떤 것도 변경할 필요가 없습니다.

앞으로 나아갈 방향

솔직히 말씀드리겠습니다. 저는 이 글을 쓰기 위해 돈을 받는 것이 아닙니다. 단지 더 많은 CTO가 "OpenAI를 반드시 사용해야 한다"는 것은 선택 사항이지, 물리 법칙이 아니라는 사실을 알았으면 할 뿐입니다. 마이그레이션 비용은 대부분의 사람들이 생각하는 것보다 훨씬 낮으며, 절감되는 비용은 실질적입니다.

궁금하시다면, Global API를 통해 단일 OpenAI 호환 엔드포인트(OpenAI-compatible endpoint)로 184개 이상의 모델에 접근할 수 있습니다. global-apis.com에서 확인해 보세요. 제가 본격적으로 도입하기 전에 모든 것을 검증할 때 사용했던 것처럼, 테스트를 위한 무료 티어(free tier)가 있는 것으로 알고 있습니다. "코드 두 줄만 바꾸면 된다"는 말이 실제로 해보기 전까지는 마케팅처럼 들릴 수 있지만, 막상 해보고 나면 지나고 나서야 당연한 일처럼 느껴집니다.

저에게 있어 결론은 이렇습니다. 저는 월 1,200달러의 비용과 벤더 종속(vendor lock-in)에 대한 불안감에서 벗어나, 월 34달러와 원할 때 언제든 제공업체를 전환할 수 있는 자유를 얻었습니다. 마지막 부분이 정말 중요한 지점입니다. AI 제공업체들이 통합되고, 가격을 올리고, 인수합병되는 시장 상황에서, 선택권(optionality)은 비용을 지불할 가치가 있는 하나의 기능입니다.