솔직히 말씀드리면, 제가 어떻게 OpenAI를 떠나 단 한 번의 오후 만에 비용을 40배 절감했는지에 대한 이야기입니다.

저는 아직도 그 Slack 메시지를 기억합니다. 재무 책임자가 8월 인보이스(invoice) 스크린샷을 붙여넣었는데, 저는 진심으로 그 스크린샷이 잘못된 줄 알았습니다. 잘못된 것이 아니었습니다. 우리는 OpenAI에 매달 14,000달러를 지출하고 있었고, 그 금액에 너무 익숙해진 나머지 그 비용이 여전히 타당한지 누구도 멈춰서 질문하지 않았습니다.

그날 오후, 저는 대안들의 가격을 산출하기 시작했습니다. 오후 6시가 되었을 때, 저는 우리의 전체 추론 계층(inference layer)을 다른 제공업체로 이전했으며, 9월 예상 청구액은 약 350달러로 떨어졌습니다. CTO로서 저는 이것이 정확히 어떻게 가능했는지 공유하고 싶습니다. 왜냐하면 그 답은 "더 성능이 낮은 모델을 사용하라"가 아니기 때문입니다. 답은 "시장에서 가장 비싼 임대인으로부터 AI를 빌려 쓰는 것을 중단하라"입니다.

이것은 플레이북(playbook)입니다. 이것을 프로덕션(production) 환경에서 운영하는 사람으로서 저에게 실제로 중요했던 모든 라인, 모든 주의사항(gotcha), 모든 벤치마크(benchmark)를 담았습니다.

제가 키보드를 잡게 만든 수학적 계산

다른 무엇을 하기 전에 구체적인 숫자를 제시하겠습니다. OpenAI의 GPT-4o는 입력 토큰 100만 개당 2.50달러, 출력 토큰 100만 개당 10.00달러로 실행됩니다. 이것이 여러분이 지불해 온 가격이며, 제가 대화하는 대부분의 팀처럼 여러분도 아마 이를 비즈니스를 운영하기 위한 고정 비용으로 받아들였을 것입니다.

하지만 그렇지 않습니다.

우리의 워크로드(주로 중간 길이의 완성(completions), 일부 긴 컨텍스트(context), 매우 적은 비전(vision) 사용)에 대해 동일 선상에서 비교를 시작했을 때 제가 실제로 발견한 결과는 다음과 같습니다:

저는 두 번째 행에 대해 잠시 머물고 싶습니다. 입력 0.18달러, 출력 0.25달러인 DeepSeek V4 Flash는 단순한 마케팅용 티저 모델이 아닙니다. 이는 프로덕션급 모델로, 800개의 프롬프트로 구성된 우리의 내부 평가 세트(eval set)에서 우리의 사용 사례(주로 구조화된 추출(structured extraction), 분류(classification), 짧은 창의적 글쓰기)에 대해 GPT-4o의 3% 이내 성능을 보여주었습니다.

97%의 품질을 유지하면서 40배 더 저렴합니다. 그것이 제가 스프레드시트를 닫고 에디터를 연 순간이었습니다.

아무도 말하지 않는 진짜 비용: 벤더 종속 (Vendor Lock-In)

비용 비교 시 아무도 고려하지 않는 사실이 하나 있습니다. 벤더 종속 (Vendor Lock-In)에는 가격표가 붙어 있지만, 그것은 표면적인 가격이 아닙니다. 그것은 당신이 이동할 수 없다고 가정하고 내린 모든 아키텍처 (Architecture) 결정의 대가입니다.

만약 당신의 애플리케이션 코드 (Application code)가 OpenAI의 SDK, 응답 형식의 특이점 (Response format quirks), 그리고 가격 모델에 밀접하게 결합 (Tightly coupled)되어 있다면, 설령 내일 당장 40배 더 저렴한 옵션이 나타나더라도 재작성 없이는 그것을 채택할 수 없습니다. 그것이 진짜 비용입니다. 인보이스에 찍힌 달러 금액은 단지 증상일 뿐입니다.

저는 2022년에 다른 벤더를 통해 이 교훈을 뼈아프게 배웠습니다. 우리는 독점적인 API (Proprietary API)를 기반으로 전체 기능을 구축했는데, 해당 벤더가 가격을 세 배로 올렸고, 우리는 통합 (Integration) 코드를 재작성하는 데 6주를 소비해야 했습니다. 6주간의 엔지니어링 시간은 실제 비용입니다. 그 고통을 한 번 경험한 CTO는 다시는 그런 일이 일어나지 않도록 만드는 CTO가 됩니다.

따라서 제가 내린 아키텍처 결정은 단순히 "추론 제공자 (Inference provider)를 교체하는 것"보다 더 큰 것이었습니다. 그것은 다음과 같았습니다: 어떤 요청이든 어떤 제공자에게도 라우팅 (Route)할 수 있고, 원할 때 언제든 모델을 교체할 수 있으며, LLM 제공자를 전략적 의존 대상이 아닌 범용적인 입력값 (Commodity input)으로 취급할 수 있도록 추상화 계층 (Abstraction layer)을 구축하는 것이었습니다. 이것만이 184개의 모델과 수십 개의 제공자를 영원히 협상 카드로 유지할 수 있는 유일한 방법입니다.

좋은 소식은, 그렇게 하는 것이 실제로 코드 두 줄만 바꾸면 된다는 점입니다. 제가 보여드리겠습니다.

실제 마이그레이션: 프로젝트가 아닌 단 두 줄의 코드

대부분의 "마이그레이션 가이드 (Migration guides)"는 마이그레이션을 직접 해보지 않은 사람들이 작성합니다. 실제 마이그레이션은 지루합니다. 그것은 분기 내내 지속되는 이니셔티브 (Initiative)가 아니라, 차이점 (Diff)이 포함된 PR (Pull Request)일 뿐입니다.

제 Python 마이그레이션이 처음부터 끝까지 어떻게 진행되었는지 보여드리겠습니다:

# 이전 (Before)
from openai import OpenAI

...

그게 전부입니다. OpenAI Python SDK는 OpenAI REST API와 통신하는 얇은 HTTP 클라이언트 (HTTP client)일 뿐입니다. Global API 역시 동일한 REST API를 노출하므로, SDK는 그 차이를 알지 못합니다. JavaScript/TypeScript SDK, Go 라이브러리, Java 클라이언트, 그리고 raw curl도 마찬가지입니다. 제 비용을 40배나 높였던 벤더(vendor)는 제가 이미 사용하고 있던 와이어 포맷 (wire format)을 사용하는 바로 그 벤더입니다.

제 정신 건강을 위해, 그 위에 작은 라우터 (router) 계층도 작성했습니다:

# routers/llm.py
from openai import OpenAI
import os
...

이 라우터는 제가 올해 작성한 코드 중 가장 가치 있는 20줄입니다. 이는 제 애플리케이션의 나머지 코드들이 특정 제공자(provider) 전용 모듈을 절대 임포트 (import)하지 않는다는 것을 의미합니다. 그저 complete("fast", ...) 또는 complete("premium", ...)를 호출하기만 하면 라우터가 적절한 엔드포인트 (endpoint)를 선택합니다. 만약 Global API가 비싸지거나 새로운 모델이 출시되면, 저는 상수 (constant) 하나만 변경하면 됩니다. 세 번째 제공자를 추가해야 한다면, 딕셔너리 (dict)에 항목 하나만 추가하면 됩니다.

이것은 처음 필요할 때 그 가치를 스스로 증명해내는 종류의 작업입니다.

프로덕션 체크리스트: 전환 시 실제로 문제가 발생하는 것들

"두 줄의 변경"은 실제로 가능하지만, 프로덕션 (production) 환경은 교과서가 아닙니다. 제가 직접 겪었던 문제들을 공유하여 여러분이 같은 실수를 반복하지 않도록 돕고자 합니다.

1. 스트리밍 (Streaming) 동작은 동일하지만, 토큰 수 (token counts)는 반드시 기록하세요. 저는 모든 요청에 대해 입/출력 토큰 사용량을 기록하고 이를 우리의 메트릭스 파이프라인 (metrics pipeline)으로 전송하는 작은 미들웨어 (middleware)를 추가했습니다. 이것은 여러분의 비용 절감이 단순한 희망 사항이 아니라 실제인지 확인할 수 있는 유일한 방법입니다. 2주간의 프로덕션 트래픽을 거친 결과, GPT-4o의 요청당 실제 비용은 $0.078였던 반면, DeepSeek V4 Flash는 $0.0019였습니다. 40배라는 수치는 프로덕션에서도 그대로 유지되었습니다. 거의 항상 유지되지만, 반드시 검증해야 합니다.

2. 지연 시간 (Latency) 프로필이 다릅니다. 우리의 워크로드 (workload)에서 DeepSeek V4 Flash는 실제로 더 빨랐습니다 — GPT-4o의 p50이 620ms인 것에 비해 380ms였습니다. 하지만 이것이 보편적인 것은 아닙니다. $0.28의 출력 비용을 가진 Qwen3-32B는 긴 컨텍스트 (context)에서 약간 더 느렸습니다. 트래픽을 전환하기 전에 실제 프롬프트 (prompt)를 대상으로 작은 부하 테스트 (load test)를 실행해 보세요.

3. 함수 호출 (Function calling) 형식은 동일하지만, 방어적으로 접근하세요. 스키마 (schema)는 동일하지만, 저는 여전히 도구 호출 (tool calls)을 try/except 문으로 감쌉니다. 간혹 특정 제공업체가 약간 다른 형태의 에러를 반환하기 때문입니다. 이를 다른 모든 외부 의존성 (external dependency)처럼 취급하세요.

4. 임베딩 (Embeddings)과 미세 조정 (fine-tuning)은 별개의 문제입니다. Global API는 (아직) 미세 조정 (fine-tuning)이나 Assistants API를 제공하지 않습니다. 임베딩의 경우, 우리는 다른 전문 제공업체를 사용했습니다. 미세 조정의 경우, 우리는 아예 하지 않습니다. 추론 (inference) 전환을 통해 절감한 비용으로 대신 영리한 프롬프트 파이프라인 (prompt pipeline)을 구축하는 엔지니어링 비용을 충당합니다. 만약 미세 조정이 당신의 해자 (moat)의 핵심 부분이라면, 그 점을 고려하여 계산하세요.

5. 롤백 계획 (rollback plan)을 세우고 한 번은 실행해 보세요. 저는 첫 일주일 동안 섀도우 비교 (shadow comparison)를 위해 트래픽의 10%를 OpenAI에 남겨두었습니다. 7일 후, 이를 0%로 줄였고 다시는 돌아보지 않았습니다. 중복 결제로 발생한 일주일간의 비용은 약 400달러였지만, 고객에게 영향을 미치는 사고를 방지할 수 있었습니다. 그만한 가치가 충분했습니다.

벤더 종속 (Vendor Lock-In) 위의 벤더 종속 계층

한 가지 구체적으로 말씀드리고 싶습니다. "특정 벤더에 종속되지 마세요"라는 조언은 하기는 쉽습니다. 하지만 실제로 실행하기는 더 어렵습니다. 왜냐하면 벤더를 추상화 (abstract)할 때마다 성능이나 편의성이 조금씩 누수되기 때문입니다.

빠르게 움직여야 하면서도 밤에 잠을 편히 잘 수 있어야 하는 스타트업에게 적절한 절충안이라고 생각하는, 제가 최종적으로 도달한 아키텍처 (architecture)는 다음과 같습니다:

• Tier 1 — "빠른" 계층 (fast tier): 요청의 90%를 처리하는 기본 계층입니다. Global API를 통한 DeepSeek V4 Flash를 사용합니다. 비용이 가장 중요한 고려 사항이며, 지연 시간 (latency)은 괜찮고, 품질은 구조화된 작업 (structured tasks)을 수행하기에 충분합니다.
• Tier 2 — "프리미엄" 계층 (premium tier): 정말로 최고의 모델이 필요한 10%의 요청을 위한 GPT-4o입니다. 추가적인 3%의 품질 향상이 사용자에게 실제로 중요한 긴 문장, 창의적인 작업, 다단계 추론 (multi-step reasoning) 프롬프트가 이에 해당합니다.
• Tier 3 — 탈출구 (escape hatch): 배포 (deploy) 없이도 운영 환경에서 Global API가 제공하는 184개의 모델 중 어떤 것이든 단일 엔드포인트 (endpoint)를 전환할 수 있게 해주는 설정 플래그 (config flag)입니다. 우리는 새로운 모델이 출시되는 당일에 A/B 테스트를 수행하기 위해 이 기능을 사용합니다.

이것은 과잉 설계 (over-engineering)가 아닙니다. 이것이 바로 비용과 품질을 모두 고려할 때 나타나는 프로덕션 준비성 (production-readiness)의 모습입니다. 핵심은 "어떤 모델을 사용해야 하는가?"라는 질문이 일 년에 한 번 하는 아키텍처 검토 (architecture review)가 아니라, 매주 내리는 데이터 기반의 결정이 되어야 한다는 점입니다.

CFO와 나누었던 ROI 대화

저는 이 과정을 내부적으로 어떻게 프레임화(framing)했는지 공유하고 싶습니다. 기술적인 세부 사항보다 프레임화가 더 중요하다고 생각하기 때문입니다.

대화의 주제는 "LLM 제공업체를 바꾸고 싶습니다"가 아니었습니다. 대신 "우리는 단일 벤더에 월 14,000달러의 공급업체 집중 리스크 (supplier concentration risk)를 안고 있으며, 출력 품질을 유지하면서 이 지출을 97% 줄일 방법을 찾아냈습니다. 전환 과정 동안 이틀의 엔지니어링 시간과 중복 결제 비용 400달러가 필요합니다"였습니다.

이것은 리스크 완화 (risk mitigation)에 관한 대화입니다. 이것은 마진 확대 (margin expansion)에 관한 대화입니다. 이것은 CFO와 이사회가 이해할 수 있는 언어입니다. CTO의 역할 중 일부는 인프라 결정을 예산을 통제하는 사람들의 언어로 번역하는 것입니다.

60일 후의 실제 결과는 다음과 같습니다:

• 월간 추론 (inference) 비용: $14,000 → $412
• 내부 평가 (internal eval) 품질 점수: -3% (수용 가능하며 모니터링 중)
• p50 지연 시간 (latency): 620ms → 380ms
• 벤더 수: 1 → 3
• 프로덕션에서 모델을 교체하는 데 걸리는 시간: 약 1개의 PR (Pull Request)

마지막 줄이 제가 가장 중요하게 생각하는 부분입니다. 이제 오후 한때 만에 트래픽의 10%에 새로운 모델을 배포할 수 있다는 사실은 달러 절감액보다 더 큰 가치가 있습니다. 이는 우리가 실험할 수 있다는 것을 의미합니다. 품질 향상을 추구할 수 있다는 뜻입니다. 그리고 그 누구의 로드맵 (roadmap)에도 인질로 잡히지 않을 수 있다는 것을 의미합니다.

다음에 한다면 다르게 할 몇 가지 사항들

처음부터 완벽하게 해내는 사람은 아무도 없습니다. 과거의 저에게 해주고 싶은 말은 다음과 같습니다:

• 마이그레이션 (Migration)이 아니라 추상화 (Abstraction)부터 시작하세요. 2년 전 OpenAI를 처음 통합했을 때, 첫날부터 라우터 레이어 (Router layer)를 구축했어야 했습니다. 그랬다면 단 한 번의 오후면 충분했을 비용이, 지금은 코드베이스 전체에 소급 적용하기 위해 한 번의 스프린트 (Sprint) 비용이 들었습니다.
• 리더보드 (Leaderboards)가 아니라 당신의 데이터로 벤치마크 (Benchmark)하세요. 공개된 벤치마크는 방향을 잡는 데는 유용하지만, 의사결정에는 쓸모가 없습니다. 제가 하루 만에 구축한 800개의 프롬프트 평가 세트 (Eval set)가 제가 신뢰하는 것입니다. 당신만의 평가 세트를 구축하는 데 시간을 투자하세요.
• 가장 저렴한 모델을 위해 최적화하지 마세요. 당신의 품질 기준을 충족하는 가장 저렴한 모델을 위해 최적화하세요. 저희의 경우 그것은 DeepSeek V4 Flash였습니다. 여러분의 경우에는 $0.28인 Qwen3-32B일 수도 있고, $0.78인 DeepSeek V4 Pro일 수도 있습니다. 핵심은 제가 무엇을 선택했느냐가 아닙니다. 핵심은 제가 기본 설정 (Default)이 아니라 데이터를 기반으로 선택했다는 점입니다.
• 모델 선택을 지속적인 프로세스로 취급하세요. 이번 달에 40배의 비용 절감을 안겨준 제공업체가 6개월 후에도 정답이 아닐 수 있습니다. 추상화 레이어 (Abstraction layer)를 만드는 목적 자체가 "어떤 모델을 쓸 것인가?"라는 질문을 항상 열어두기 위함입니다.

동료 CTO들을 위한 결론

만약 OpenAI에 막대한 비용을 지출하고 있다면, 과다 지불하고 있다고 가정해야 합니다. 이는 도덕적 판단이 아니라 시장의 관찰 결과입니다. 오픈 웨이트 (Open-weight) 모델 생태계는 따라잡았고, 추론 레이어 (Inference layer)는 범용화(Commoditized)되었으며, 이제 여러분이 이미 사용 중인 것과 호환되는 단일 API 뒤에 184개의 모델이 준비되어 있습니다.

마이그레이션은 코드 두 줄을 바꾸는 작업입니다. 아키텍처 측면에서의 결정은, 경제적 상황이 변할 때 코드 두 줄만 바꾸면 되는 팀이 될 것인지, 아니면 분기 내내 재작성 (Rewrite) 일정을 잡아야 하는 팀이 될 것인지의 문제입니다.

전자의 팀이 되십시오.

실제 API 인터페이스가 어떻게 생겼는지 보고 싶다면, 저는 모든 코드를 https://global-apis.com/v1을 대상으로 작성했고, 그것은 그냥 작동했습니다 (Just Worked). 지금 OpenAI 청구서를 보고 있다면 살펴볼 가치가 있습니다.