솔직히 말해서, 대규모 LLM 비용 절감: 나의 OpenAI 탈출 플레이북

6개월 전, 나는 월간 인프라 청구서를 열어보고 너무 오랫동안 무시해 왔던 한 항목을 빤히 쳐다보았습니다. OpenAI에 지불하는 4,200달러. 오직 OpenAI에만 말이죠. 나는 노트북을 닫고, 커피를 한 잔 더 따른 뒤, 첫날부터 했어야 했던 수학적 계산을 스케치하기 시작했습니다. 3주 후, 우리는 추론 (Inference)의 80%를 다른 제공업체를 통해 라우팅하고 있었고, 청구 금액은 312달러로 줄었으며, 운영 환경(Production)에서 깨진 것은 아무것도 없었습니다.

이것은 누군가가 나에게 건네주었더라면 좋았을 플레이북입니다. 특정 업체의 홍보나 벤치마크 성능 과시용 대결이 아닙니다. 그저 아키텍처 결정 사항, 주의해야 할 점(Gotchas), 그리고 내가 실제로 배포한 코드에 관한 것입니다.

나를 깨운 청구서

2024년이나 2025년에 OpenAI로 구축을 시작할 때 아무도 말해주지 않는 사실이 있습니다. 단위 가격은 합리적으로 보이지만, 제품이 트랙션을 얻기 시작하면 상황이 달라진다는 것입니다. 갑자기 그 "합리적인" 금액이 연봉 수준이 되어버립니다. 나는 솔직히 GPT-4o가 기본이었기 때문에 우리의 고객 지원 코파일럿 (Co-pilot)을 그 모델로 구축했습니다. 모두가 그것을 사용하니까요. 그것이 가장 저항이 적은 경로였습니다. 나는 총소유비용 (TCO) 계산조차 해본 적이 없었습니다.

어느 일요일 아침에 그 계산을 해보았는데, 숫자가 끔찍했습니다. GPT-4o의 출력 토큰 (Output tokens)당 10.00달러/M 기준으로, 모든 긴 문맥 요약 (Long-context summarization) 작업에서 돈이 새어나가고 있었습니다. 우리의 평균 고객 지원 스레드는 왕복 3,200 토큰이었고, 우리는 하루에 14,000개를 처리하고 있었습니다. 곱셈을 해보세요. 그리고 거기에 30을 곱하세요.

그때 벤더 종속 (Vendor lock-in)은 추상적인 우려 사항이 아니라 손익 계산서 (P&L)의 문제가 되었습니다. 나는 전체 추론 레이어 (Inference layer)를 단 하나의 제공업체 SDK, 하나의 인증 (Auth) 체계, 하나의 기본 URL에 맞춰 구축해 놓았습니다. 탈출하는 것이 비용이 많이 들 것 같았습니다. 하지만 내 생각이 틀렸습니다. 비용은 화요일 오후 한나절이면 충분했습니다.

결정을 명확하게 만든 단위 경제성 (Unit Economics)

내가 예산 승인이 필요할 때 공동 창업자 앞에 내놓았던 것과 똑같은 표를 당신 앞에 놓아보겠습니다. 이 숫자들은 논쟁을 종결시켰습니다:

모델 (Model)	제공업체 (Provider)	Input $/M	Output $/M	vs GPT-4o
GPT-4o	OpenAI	$2.50	$10.00	—
...

DeepSeek V4 Flash 라인을 다시 한번 읽어보세요. Output 비용이 $0.25/M입니다. 이는 GPT-4o 대비 40배의 가격 차이이며, 저희의 내부 평가 세트(내 엔지니어 두 명이 블라인드 테스트로 채점한 800개의 실제 프로덕션 프롬프트)에서도 품질은 통계적 오차 범위(statistical noise) 내에 있었습니다. 40배나 저렴하다면, "통계적 오차 범위 내"라는 답변이 정답입니다.

저희 내부 문서의 헤드라인 사례는 이렇습니다: 만약 당신이 OpenAI에 월 500달러를 쓰고 있다면, 12.50달러만 써도 될 수 있습니다. 오타가 아닙니다. 동일한 워크로드에 대해 $10.00/M과 $0.25/M 사이의 차이입니다. 저희 규모에서 이 차이는 머신러닝(ML) 엔지니어 한 명 전체와 몇 개의 Datadog 대시보드 사이의 차이였습니다.

벤더 종속(Vendor Lock-In)이 생각보다 더 위험한 이유

코드를 보여드리기 전에, 전략적인 근거를 말씀드리겠습니다. 이 부분이 당신의 마이그레이션(migration)이 분기별 검토를 통과할 수 있을지를 결정하기 때문입니다.

종속(Lock-in)은 단순히 가격에 관한 문제만이 아닙니다. 세 가지 측면이 있습니다:

1. 가격 협상력 (Price leverage) — 떠날 수 없을 때, 제공업체는 그 사실을 압니다. 가격 결정권은 선택지를 가진 쪽으로 흐릅니다. 저는 선택지를 원합니다.
2. 로드맵 리스크 (Roadmap risk) — 만약 제공업체가 당신이 의존하고 있는 모델을 지원 중단(deprecate)한다면, 당신의 마이그레이션은 계획된 스프린트(sprint)가 아니라 비상 상황이 됩니다. 저도 이 문제로 호출(paged)을 받아본 적이 있습니다. 전혀 즐겁지 않습니다.
3. 협상 태도 (Negotiation posture) — OpenAI 계약을 두 번째로 갱신할 때, 저는 경쟁사의 견적서를 손에 쥐고 있었습니다. 그러자 할인이 나타났습니다. 참 신기한 일이죠.

해결책은 추상화 계층(abstraction layer)입니다. 14개의 의존성(dependencies)을 가진 무거운 래퍼 프레워크(wrapper framework)가 아니라, 단 하나의 base_url 파라미터와 모델 문자열(model string)이면 충분합니다. 그것이 아키텍처의 전부입니다. OpenAI 클라이언트 라이브러리는 잘 설계되어 있습니다. 규약(contract)만 준수된다면 바이트(bytes)가 어디서 오는지 상관하지 않습니다. 규약만 준수한다면, 오후 한나절 만에 제공업체를 교체할 수 있습니다.

실제 마이그레이션 (아키텍처 결정 사항)

저는 세 가지 접근 방식을 고려했습니다:

옵션 A: 직접 게이트웨이 구축. 여러 제공업체 앞에 위치하여 인증(auth), 재시도(retries), 폴백(fallbacks)을 처리하는 FastAPI 서비스를 띄웁니다. 제어권은 극대화되지만, 엔지니어링 비용도 극대화됩니다. 저는 4명 규모의 팀입니다. 그럴 시간이 없습니다.

옵션 B: LiteLLM 또는 유사한 프록시 라이브러리 사용. 괜찮은 방법이지만, 또 다른 의존성(dependency)이자 또 다른 장애 발생 지점(failure mode)이며, 또 다른 업그레이드 대상이 됩니다. 또한 제가 직접 제어하고 싶은 핵심 요소, 즉 '언제 어떤 모델이 호출될지'를 추상화하여 가려버립니다.

옵션 C: OpenAI 호환 애그리게이터 (Aggregator) 사용. 동일한 /v1/chat/completions 형태, 동일한 인증 헤더(auth header), 동일한 스트리밍 프로토콜(streaming protocol)을 노출하면서도, 여러 벤더의 184개 모델로 라우팅해주는 제공업체를 사용하는 것입니다. 이것이 제가 선택한 방식입니다. 새로운 의존성이 전혀 없습니다. 설정 변경은 단 두 줄이면 됩니다. 리스크 프로필은 OpenAI를 직접 사용하는 것과 동일하면서도, 가격 경쟁력과 모델 다양성이라는 이점을 얻을 수 있습니다.

제가 선택한 애그리게이터는 Global API이며, 이를 선택한 이유는 간단합니다. 계약(contract)이 동일하기 때문입니다. 그들의 /v1/chat/completions를 OpenAI의 것과 diff 해보았을 때 유일한 차이점은 호스트(host)뿐이었습니다. 이는 저의 추상화 계층(abstraction layer)이 공짜라는 것을 의미합니다. 왜냐하면 OpenAI 자체의 클라이언트 라이브러리(client library)가 곧 추상화 계층이기 때문입니다. 저는 단지 다른 URL을 가리키도록 설정했을 뿐입니다.

이 글을 읽고 있는 스타트업 CTO라면 교훈은 이것입니다: 구축할 필요가 없는 인프라를 구축하지 마십시오. 가장 저렴한 추상화는 이미 존재하는 것입니다.

코드 (Python, 저의 기본 언어)

이것이 제가 실제로 배포한 차이점(diff)입니다. 과장이 아닙니다. 이것이 저희 Python 서비스의 마이그레이션 전부입니다.

# 이전: OpenAI 직접 연결
from openai import OpenAI

...

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

...

그게 끝입니다. 두 줄이 바뀌었습니다. base_url 파라미터는 대부분의 엔지니어가 거의 건드리지 않는 OpenAI Python SDK의 표준 필드입니다. 이것이 존재한다는 것을 한 번 알고 나면, 이전으로 돌아갈 수 없습니다. 모든 언어의 모든 SDK에는 이와 동일한 기능이 있습니다.

저희는 다른 언어들도 몇 가지 사용하고 있으므로, 저희 프론트엔드 팀의 코파일럿 (co-pilot) 위젯이 구축된 TypeScript 버전도 보여드리겠습니다.

import OpenAI from 'openai';

const client = new OpenAI({
...

형태가 동일합니다. chat.completions.create 호출 방식도 동일합니다. 프론트엔드 팀은 마이그레이션 (migration) 회의에 참석할 필요조차 없었습니다.

실제로 문제가 된 부분 (그리고 문제가 되지 않은 부분)

솔직하게 주의사항 (gotchas)에 대해 말씀드리겠습니다. 마이그레이션 과정에서 마찰이 전혀 없는 경우는 없으며, 자신의 마이그레이션이 매끄러웠다고 말하는 사람은 의심스럽기 때문입니다.

스트리밍 (Streaming)은 동일하게 작동합니다. 서버 전송 이벤트 (Server-sent events)는 동일한 형식, 청크 (chunk) 형태, 그리고 data: [DONE] 종료 표식으로 돌아옵니다. 기존의 스트리밍 파서 (streaming parser)는 코드 변경 없이 그대로 작동했습니다. 이것은 저에게 가장 위험한 부분이었습니다. 코파일럿 (co-pilot) UX 전체가 스트리밍 기반이며, 이를 재구현하는 데 드는 비용이 절감액을 모두 잡아먹을 수 있었기 때문입니다. 하지만 그렇지 않았습니다.

함수 호출 (Function calling)은 동일하게 작동합니다. 도구 사용 (Tool-use) 스키마 (schema), tools 배열, tool_calls 응답 — 모두 동일한 JSON 형태입니다. 저는 한 시간도 채 되지 않아 세 개의 도구 사용 에이전트 (agent)를 마이그레이션했습니다.

JSON 모드 (JSON mode)는 동일하게 작동합니다. response_format: { type: "json_object" } 파라미터가 그대로 적용됩니다. 저의 구조화된 추출 (structured extraction) 파이프라인은 회귀 테스트 (regression test)조차 필요하지 않았습니다.

제가 마이그레이션하지 않은 것: 파인튜닝 (fine-tuning) 작업입니다. 저는 특정 분류 (classification) 작업을 위해 의존하고 있는 두 개의 OpenAI 파인튜닝 모델을 보유하고 있습니다. Global API는 (아직) 파인튜닝된 가중치 (weights)를 호스팅하지 않으며, 설령 호스팅한다 하더라도 첫날부터 그것들을 옮기지는 않았을 것입니다. 이는 모든 프로덕션 (production) 시스템을 위한 올바른 결정입니다. 범용적인 워크로드 (workloads)를 먼저 마이그레이션하고, 교체가 안전하다는 것을 보여주는 데이터가 확보될 때까지 맞춤형 작업들은 기존 위치에 두는 것입니다.

또한 가장 중요도가 높고 볼륨이 낮은 사용 사례를 위해 GPT-4o-mini를 혼합하여 유지했습니다. 전체 GPT-4o 대비 16.7배의 비용 절감은 실질적이며, 짧은 분류 프롬프트 (classification prompts)의 경우 품질 차이는 무시할 수 있는 수준입니다. 계층별로 다른 모델을 사용하는 것, 그것이 핵심입니다.

제가 사용하는 프로덕션 준비 체크리스트 (Production-Readiness Checklist)

만약 여러분이 이 마이그레이션 (migration)을 진행하려 한다면, 제가 현재 런북 (runbook)에 유지하고 있는 체크리스트는 다음과 같습니다. 이는 트래픽의 일정 비율을 전환하기 전에 제가 스스로에게 부여하는 기준입니다.

1. 동일한 API 규약 (API contract) 검증 완료 — 실제 프롬프트로 새로운 엔드포인트 (endpoint)에 curl을 날려보고, 응답을 직접 확인합니다. JSON 형태가 OpenAI와 일치한다면 90%는 완료된 것입니다.
2. 인증 (Auth) 및 속도 제한 (rate limits) 문서화 — 429 에러의 동작 방식은 어떠한가? 재시도 예산 (retry budget)은 얼마인가? OpenAI와 동일한가, 아니면 더 나쁜가? 배포하기 전에 답을 알고 있어야 합니다.
3. 스트리밍 (Streaming) 동일성 테스트 — 스트림을 시작하고, 중간에 취소해 보며, 클라이언트가 멈추지 않는지 확인합니다. LLM 마이그레이션의 80%가 여기서 실패합니다.
4. 비용 관측성 (Cost observability) 구축 — 모든 요청에 제공자(provider) + 모델(model) 태그를 붙이십시오. 지난 화요일에 DeepSeek V4 Flash에 얼마를 썼는지 말할 수 없다면, 그것을 관리할 수 없는 것입니다.
5. 폴백 경로 (Fallback route) 정의 — 새로운 제공자가 다운되었을 때, 1분 이내에 OpenAI로 폴백 (fail back) 할 수 있습니까? 그 탈출구 (escape hatch)를 연결해 두십시오. 저렴한 보험입니다.
6. 평가 스위트 (Eval suite) 실행 — 200개 이상의 실제 프로덕션 프롬프트를 재현하고, 블라인드 테스트로 점수를 매기며, 분포를 비교합니다. 새 모델의 품질이 기존 모델의 ±5% 이내라면 배포하십시오.
7. 킬 스위치 (Kill switch) 테스트 — 환경 변수 (env var)를 전환하여 트래픽이 다시 OpenAI로 돌아가는지 확인합니다. 이는 타협할 수 없는 사항입니다. 몇 초 안에 되돌릴 수 있어야 합니다.

저는 마이그레이션 시 한 번, 그리고 로테이션에 새로운 모델을 추가할 때마다 이 체크리스트를 실행합니다.

실제 수치로 보는 ROI

마이그레이션 이후 저희의 스택 (stack)은 다음과 같습니다:

• 고객 지원 코파일럿 (Customer support co-pilot) (가장 높은 볼륨, 가장 긴 컨텍스트): DeepSeek V4 Flash. 입력 $0.18, 출력 $0.25. 기존에는 GPT-4o를 사용했습니다. 현재 볼륨 기준으로 월 약 $3,100를 절감합니다.
• 내부 문서 요약 (Internal document summarization): Qwen3-32B. 입력 $0.18, 출력 $0.28. GPT-4o보다 35.7배 저렴하며, 특히 요약 작업에서 대등한 품질을 보여줍니다. 월 약 $340를 절감합니다.
• 복잡한 추론 작업 (Complex reasoning tasks) (낮은 볼륨, 높은 중요도): DeepSeek V4 Pro. 입력 $0.57, 출력 $0.78. 12.8배 저렴하며, Flash 버전보다 눈에 띄게 나은 추론 능력을 갖추고 있습니다. 월 약 $180를 절감합니다.
• 짧은 분류 및 라우팅 (Short classification and routing): GPT-4o-mini. 여전히 OpenAI를 사용 중입니다. 마이그레이션을 검토했으나, 현재 상태를 유지하는 운영상의 단순함이 미미한 비용 절감보다 더 가치 있다고 판단했습니다. 모든 워크로드(workload)를 옮길 필요는 없습니다.
• 맞춤형 미세 조정 분류기 (Bespoke fine-tuned classifier): GPT-4o (fine-tuned). OpenAI에 유지합니다. 타당한 이유가 생기기 전까지는 옮기지 않을 것입니다.

마이그레이션 후 LLM 추론(inference)에 대한 총 월간 실행 비용(run-rate): $312. 마이그레이션 전: $4,200. 이는 연간 $46,656의 절감액이며, 이는 시니어 엔지니어 한 명의 총 비용(loaded cost)의 약 60%에 해당합니다. 저는 그 돈을 토큰이 아닌 사람에게 쓰고 싶습니다. ROI(투자 대비 수익)라는 말조차 적절하지 않습니다. 이것은 그저 더 나은 자본 배분(capital allocation)입니다.

그리고 핵심은 이것입니다. 이제 저는 184개의 모델을 보유한 OpenAI 호환 애그리게이터(aggregator)를 사용하고 있기 때문에, 다음 마이그레이션은 프로젝트가 아닌 설정 변경(config change)에 불과합니다. 다음 가격 전쟁이 일어나거나 새로운 모델이 출시되면, 저는 오후 한나절 만에 평가하고 전환할 수 있습니다. 이것이 진정한 승리입니다. 선택권(Optionality)은 복리로 작용합니다.

솔직한 주의사항

이 과정이 공짜라고 거짓말하지는 않겠습니다. 주의 깊게 살펴봐야 할 몇 가지 사항이 있습니다:

• 지연 시간 프로필(Latency profiles)이 다릅니다. DeepSeek V4 Flash는 빠르지만, 모든 지역에서 OpenAI만큼 빠른 것은 아닙니다. 실제 사용자로부터 발생하는 실제 워크로드에서 측정하십시오. 저희는 약