Three months ago I sat down with my finance lead and watched her scroll through our OpenAI invoice. The number was $14,200 for the month. That was the moment I knew we had a problem. Not a "maybe we should optimize" problem — a real, existential, "this kills our margins before we hit Series B" problem.

3개월 전, 저는 재무 책임자와 함께 앉아 그녀가 우리의 OpenAI 인보이스(invoice)를 스크롤하는 것을 지켜보았습니다. 한 달 금액은 $14,200였습니다. 그 순간 저는 우리가 문제를 안고 있다는 것을 깨달았습니다. "아마 최적화(optimize)를 해야 할지도 모르겠네" 수준의 문제가 아니라, 실질적이고 실존적인, 즉 "Series B 단계에 도달하기도 전에 우리의 마진(margin)을 깎아먹는" 문제였습니다.

I run a B2B SaaS platform that does a lot of LLM-powered document processing. Summarization, extraction, classification, the boring stuff that makes real money but burns tokens like crazy. We were routing everything through GPT-4o because, honestly, it was the path of least resistance when we started. Then the bills started arriving.

저는 LLM (Large Language Model) 기반의 문서 처리 작업을 많이 수행하는 B2B SaaS 플랫폼을 운영하고 있습니다. 요약(Summarization), 추출(extraction), 분류(classification)와 같이 실제 돈을 벌어다 주지만 토큰(token)을 미친 듯이 태워버리는 지루한 작업들 말이죠. 솔직히 말씀드리면, 시작할 당시에는 GPT-4o를 사용하는 것이 가장 저항이 적은 경로였기에 모든 것을 그곳으로 라우팅(routing)하고 있었습니다. 그러다 청구서가 날아오기 시작했습니다.

This is the story of how I cut our LLM spend by 97%, the architecture decisions that made it possible, and the things I wish someone had told me before I started.

이 글은 제가 어떻게 LLM 지출을 97% 절감했는지, 이를 가능하게 했던 아키텍처(architecture) 결정들, 그리고 시작하기 전에 누군가 저에게 말해줬더라면 좋았을 것들에 대한 이야기입니다.

The Math That Made Me Sweat

나를 땀 흘리게 만든 수학적 계산

Let me put actual numbers on the table. Here's what I was paying versus what I pay now:

실제 수치를 테이블에 올려보겠습니다. 제가 이전에 지불하던 금액과 현재 지불하는 금액의 비교입니다:

Look at that DeepSeek V4 Flash row. 40× cheaper than GPT-4o. For comparable quality on the workloads I was running. I had been leaving 97.5% of my budget on the table.

DeepSeek V4 Flash 행을 보십시오. 제가 실행하던 워크로드(workload)에서 비슷한 품질을 유지하면서도 GPT-4o보다 40배나 저렴합니다. 저는 예산의 97.5%를 그냥 낭비하고 있었던 셈입니다.

Doing the mental math: a $500/month OpenAI bill becomes $12.50. My $14,200 bill? Theoretically $355. That's not optimization, that's a different business.

암산해 보자면, 월 $500의 OpenAI 청구서는 $12.50가 됩니다. 저의 $14,200 청구서는요? 이론적으로 $355가 됩니다. 이것은 단순한 최적화가 아니라, 완전히 다른 비즈니스 모델이 되는 수준입니다.

Why I Almost Didn't Do It

왜 내가 거의 실행에 옮기지 않을 뻔했는가

Here's the thing nobody tells you about cost optimization at a startup: it's not a technical problem, it's a willpower problem. The reason I was paying OpenAI 40× too much wasn't because their API is hard to use. It was because switching felt risky. I had deadlines. I had a roadmap. I had investors asking about growth metrics, not infrastructure costs.

스타트업의 비용 최적화(cost optimization)에 대해 아무도 말해주지 않는 사실이 있습니다. 그것은 기술적인 문제가 아니라 의지력의 문제입니다. 제가 OpenAI에 40배나 더 많은 비용을 지불했던 이유는 그들의 API 사용이 어려워서가 아니었습니다. 전환하는 것이 위험하게 느껴졌기 때문입니다. 저에게는 마감 기한이 있었고, 로드맵(roadmap)이 있었습니다. 투자자들은 인프라(infrastructure) 비용이 아니라 성장 지표(growth metrics)에 대해 묻고 있었습니다.

The voice in my head said: "It's working. Don't touch it. Focus on product-market fit. Optimize later."

제 머릿속의 목소리는 이렇게 말했습니다: "잘 돌아가고 있잖아. 건드리지 마. 제품-시장 적합성(product-market fit)에 집중해. 최적화는 나중에 하고."

That voice is wrong. Here's why.

그 목소리는 틀렸습니다. 그 이유는 다음과 같습니다.

우리 규모에서는 성장의 모든 퍼센트 포인트보다 마진의 모든 퍼센트 포인트가 더 중요합니다. 우리는 제품-시장 적합성 (Product-Market Fit, PMF)을 찾으려 노력하던 PMF 이전 단계가 아니라, 수익성을 향한 경로를 찾으려 노력하던 PMF 이후 단계였습니다. 매출의 3%를 추론 (Inference)에 사용하는 것과 매출의 30%를 추론에 사용하는 것의 차이는, 우리가 원하는 조건으로 시리즈 A (Series A) 투자를 유치하느냐, 아니면 우리의 런웨이 (Runway)가 우리가 내리는 모든 결정을 좌우하게 되느냐의 차이입니다.

내 머릿속의 또 다른 목소리는 이렇게 말했습니다: "벤더 종속 (Vendor lock-in). 만약 모든 것을 OpenAI 기반으로 구축했는데 그들이 가격을 올리면, 당신은 끝장이다."

그 목소리는 100% 옳았습니다.

효과적이었던 의사결정 프레임워크 (Decision Framework)

나는 단순히 제공업체를 바꾸고 싶었던 것이 아닙니다. 전환이 코드 재작성이 아닌 설정 변경만으로 가능한 시스템을 구축하고 싶었습니다. 이는 세 가지 아키텍처 원칙을 의미했습니다:

1. OpenAI SDK를 표준으로 삼으세요. OpenAI를 사용하지 않더라도 OpenAI 클라이언트 라이브러리를 사용하세요. 모든 주요 모델 제공업체가 이를 지원합니다. SDK는 범용 제품 (Commodity)입니다. 모델도 범용 제품입니다. 어느 쪽에도 자신을 결합(Couple)시키지 마세요.

2. 모델 이름을 추상화하세요. 코드베이스에 gpt-4o를 하드코딩하는 것이 바로 종속되는 방식입니다. 이를 설정 값 (Config value)으로 만드세요. 더 나아가, 런타임 (Runtime) 결정 사항으로 만드세요.

3. 라우터 (Router)를 구축하세요. 처음에는 if/else 문으로 시작하더라도, 작업에 따라 서로 다른 모델로 요청을 보낼 수 있는 라우터를 구축하세요. 작업마다 서로 다른 모델을 사용하세요. 모든 것을 가장 비싼 모델로 보내지 마세요.

이러한 원칙을 세우고 나니, 실제 마이그레이션 (Migration)은 사소한 일이 되었습니다. 결과적으로 코드 두 줄이면 충분했습니다.

마이그레이션: 실제로 일어난 일

시중에 있는 문서들은 대충 얼버무리는 경우가 많기 때문에, 제가 실제로 거쳤던 실제 마이그레이션 경로를 실제 코드와 함께 설명해 드리고 싶습니다. 저는 이 글이 제가 읽었으면 좋았을 법한 그런 글이 되기를 바랍니다.

다음은 저희 프로덕션 백엔드에서 실행되는 Python 예시입니다:

from openai import OpenAI

client = OpenAI(api_key="sk-proj-...")
...

그것이 우리 통합의 전부였습니다. 분당 수백 건의 호출이 모두 정확히 그 패턴을 통해 이루어졌습니다. 이제 변경 후의 모습을 보겠습니다:

# 변경 후: DeepSeek V4 Flash를 사용하는 Global API
from openai import OpenAI

...

그게 전부입니다. 두 가지 변경 사항: api_key와 base_url입니다. 모델 이름도 변경되었지만, 이는 설정(configuration)의 결정일 뿐, 추상적인 의미에서의 코드 변경은 아닙니다.

OpenAI 클라이언트 라이브러리는 친숙한 인터페이스를 가진 HTTP 클라이언트일 뿐입니다. 엔드포인트(endpoint)가 어디를 가리키는지 상관하지 않습니다. 어떤 모델이 응답하는지도 상관하지 않습니다. 기본값으로 OpenAI 서버를 사용하도록 되어 있을 뿐, 어디로든 라우팅(routing)할 수 있는 추상화 계층 (abstraction layer)입니다.

이 순간, 저는 제 코드의 실제 결합도(coupling)는 최소한임에도 불구하고, 특정 벤더(vendor)에 심리적으로 닻을 내리고(anchoring) 있었다는 사실을 깨달았습니다.

더 현실적인 프로덕션 설정

두 줄의 코드는 빠른 테스트에는 유효합니다. 하지만 프로덕션(production) 환경에서는 라우터(router)가 필요합니다. 제가 실제로 배포한 내용은 다음과 같습니다:

# model_router.py
import os
from openai import OpenAI
...

이것이 실제 라우터입니다. 이 라우터는 작업을 처리할 수 있는 가장 저렴한 모델을 선택합니다. 분류(Classification) 작업에는 GPT-4o가 필요하지 않습니다. 출력 100만 토큰당 0.25달러인 DeepSeek V4 Flash가 필요합니다. 복잡한 추론(reasoning)은 여전히 GPT-4o를 사용할 가치가 있을 수 있지만, 실제로 그것이 필요한 5%의 요청에 대해서만 사용합니다.

결과적으로, 요청당 평균 비용이 약 0.012달러에서 약 0.0008달러 수준으로 떨어졌습니다. 계산이 맞아떨어집니다.

내가 처음에 실수했던 것들

여러분의 고통을 덜어드리고자 합니다. 제가 시도했지만 실패했던 것들과, 성공했던 것들을 알려드리겠습니다.

실패했던 것: 모든 것을 한꺼번에 마이그레이션(migrate)하려고 했던 것. 저는 금요일 오후를 골라 전환을 완료하고 프로덕션에 푸시(push)했다가, 에러율이 급증하는 것을 지켜봐야 했습니다. 왜 그랬을까요? 모든 OpenAI 기능이 아직 모든 곳에서 지원되는 것은 아니기 때문입니다. 저는 특정 워크플로우(workflow)를 위해 Assistants API를 사용하고 있었습니다. 그 기능은 Global API에서 (아직) 사용할 수 없습니다. 저는 채팅 완료(chat completions) 엔드포인트를 사용하여 우회 방법(workaround)을 구축해야 했습니다.

효과가 없었던 것: 모든 "저렴한" 모델이 동일하다고 가정하는 것. 저는 분류 (classification) 작업에 DeepSeek V4 Flash를 테스트했습니다. 성능이 압도적이었습니다. 하지만 미묘한 차이가 중요한 요약 (summarization) 작업에 테스트했을 때는 GPT-4o보다 눈에 띄게 성능이 떨어졌습니다. 제가 위에서 보여드린 라우터 (router)가 존재하는 이유가 바로 이것 때문입니다. 작업에 맞는 적절한 도구를 사용하세요.

효과가 있었던 것: 마이그레이션 (migration) 전에 기능 동등성 매트릭스 (feature parity matrix) 구축하기. 저는 자리에 앉아 제가 사용 중인 모든 OpenAI 기능을 나열했습니다. 채팅 완료 (Chat completions)? 쉬웠습니다. 스트리밍 (Streaming)? 쉬웠습니다. 함수 호출 (Function calling)? 쉬웠습니다. 비전 (Vision)? 쉬웠습니다. 임베딩 (Embeddings)? 곧 지원 예정. 파인튜닝 (Fine-tuning)? 사용 불가. 어시스턴트 API (Assistants API)? 사용 불가. TTS/STT? 사용 불가.

그 목록을 작성하고 나니, OpenAI에 어떤 기능을 남겨두어야 할지 (결국 하나도 남기지 않았지만), 그리고 어떤 기능을 중심으로 아키텍처 (architecture)를 설계해야 할지 정확히 알 수 있었습니다.

효과가 있었던 것: 실제 운영 트래픽 (production traffic)을 이용한 부하 테스트 (load testing). 저는 일주일 동안 운영 트래픽의 일정 비율을 새로운 제공업체로 복제했습니다. 출력값 (outputs)을 비교했습니다. 지연 시간 (latency)을 비교했습니다. 비용 (cost)을 비교했습니다. 데이터를 확보한 후에야 비로소 완전한 전환을 결정했습니다.

기능 호환성: 실제 목록

결정을 내리기 쉽게 만든 제가 실제로 사용했던 매트릭스는 다음과 같습니다:

세 가지 "사용 불가" 기능이 있었습니다. 저희에게는 그중 어떤 것도 결정적인 결격 사유 (dealbreakers)가 아니었습니다. 하지만 여러분에게는 그럴 수도 있습니다. 마이그레이션하기 전에 반드시 감사를 실시하세요.

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

사람들은 계속 제게 묻습니다: "하지만 결국 OpenAI 종속을 Global API 종속으로 바꾸는 것 아닌가요?"

타당한 질문입니다. 대답은 "아니오"이며, 그 이유는 다음과 같습니다.

OpenAI 클라이언트 SDK는 업계 표준입니다. 모든 진지한 제공업체가 이를 지원합니다. 만약 내일 Global API가 사라진다면, 저는 base_url을 변경하여 다른 곳을 가리키게 하면 됩니다. 코드는 바뀌지 않습니다. 모델 이름만 바뀔 뿐입니다. 그것은 배포 (deployment)이지, 재작성 (rewrite)이 아닙니다.

만약 내일 OpenAI가 사라진다면 — 혹은 더 현실적으로, 가격을 3배 올린다면 — 상황은 마찬가지입니다. 저는 base_url을 변경하기만 하면 끝납니다.

이전에 겪었던 종속 (lock-in)은 실질적인 문제였습니다. 하지만 지금 제가 겪는 "종속"은 설정 (configuration)의 문제입니다. 이 둘 사이에는 천지 차이가 있습니다.

품질은 어떤가요?

여러분이 무슨 생각을 하는지 알고 있습니다. "물론 더 저렴하겠지만, 품질이 충분히 좋을까요?"

저희의 사용 사례 (use cases) 기준으로는 그렇습니다. 때로는 더 낫기도 합니다. 분류 (classification) 작업에서 DeepSeek V4 Flash는 제 테스트 결과 GPT-4o와 대등한 수준이었습니다. 일부 추출 (extraction) 작업에서는 오히려 더 일관적이었는데, 이는 아마도 GPT-4o가 너무 똑똑하게 굴려고 하다가 지시 사항을 스스로 의심하기 때문일 것입니다.

복잡한 추론 (complex reasoning) — 다단계 분석 (multi-step analysis), 에이전트 워크플로우 (agentic workflows), 모델이 많은 상태 (state)를 유지하며 추론해야 하는 모든 작업 — 에 있어서는 여전히 GPT-4o가 승리합니다. 그렇기 때문에 라우터 (router)가 해당 작업들을 프리미엄 티어 (premium tier)로 보내는 것입니다. 하나의 모델만 선택해야 하는 것이 아닙니다. 각 작업에 적합한 모델을 선택해야 하는 것입니다.

제가 배운 또 다른 점은 품질이 단일 차원이 아니라는 것입니다. 지연 시간 (latency)이 중요합니다. 일관성 (consistency)이 중요합니다. 예측 가능성 (predictability)이 중요합니다. 저는 DeepSeek V4 Flash가 제 워크로드 (workloads)에서 GPT-4o보다 실제로 더 빠르다는 것을 발견했으며, 이는 동일한 인프라 (infrastructure)로 더 많은 요청을 처리할 수 있음을 의미했습니다. 이는 비용 절감 효과를 배가시킵니다.

3개월 차, 실제 수치

지난 3개월간의 실제 수치를 말씀드리겠습니다. "40배 더 저렴하다"는 마케팅 문구는 증거 없이는 무의미하기 때문입니다.

1개월 차 (기준점, 모두 OpenAI 사용): $14,200
2개월 차 (이전, 60/40 분할): $5,840
3개월 차 (운영, 전체 라우터 적용): $1,180

사용량은 늘어났고, 비용은 줄어들었습니다. 이것이 핵심입니다.

또 다른 변화도 있었습니다. LLM 기능을 추가하는 것에 대한 두려움이 사라졌습니다. 이전 단계에서는 모든 새로운 기능 요청이 "이것이 추론 비용 (inference cost)을 들일 가치가 있는가"라는 필터를 거쳐야 했습니다. 이전 작업 이후, 그 필터는 기본적으로 사라졌습니다. 저는 3개월 차에 세 가지 새로운 제품 기능을 추가했는데, 1개월 차였다면 비용 문제만으로도 폐기했을 기능들이었습니다. 인프라 절감이 제품 개발 속도 (product velocity)를 해방시킨 것입니다.

이것이 진정한 ROI (투자 대비 수익)입니다. 단순히 92%의 비용 절감이 아니라, 비용이 로드맵 (roadmap)의 제약 사항이 되지 않게 되었다는 사실 말입니다.

주의해야 할 사항들

문서에는 나와 있지 않지만 제가 직접 겪었던 몇 가지 주의 사항(gotchas)이 있습니다:

1. 속도 제한 (Rate limits)이 다릅니다. Global API는 OpenAI와 다른 속도 제한을 가집니다. 마이그레이션(migration)을 마친 후가 아니라, 그 전에 반드시 확인하세요. 저는 화요일 오후에 429 에러를 마주하며 뼈아픈 교훈을 얻었습니다.

2. 스트리밍 (Streaming) 동작이 약간 다릅니다. 청크 (chunk) 형식은 동일하지만, 타이밍은 다를 수 있습니다. 토큰 단위의 타이밍에 의존하는 UI를 가지고 있다면 철저하게 테스트하십시오.

3. 에러 코드 (Error codes)가 다릅니다. 특정 OpenAI 에러 코드(예: rate_limit_error와 RateLimitError의 차이)에 의존하는 재시도 로직 (retry logic)이 있다면 업데이트하십시오. 코드들이 유사한 패턴을 따르기는 하지만 완전히 동일하지는 않습니다.

4. 모델 명명 규칙 (Model naming)이 더 유연합니다. Global API는 184개의 모델을 노출하며 이는 매우 좋지만, 무엇을 요청하고 있는지 정확히 알아야 합니다. 모델 이름을 그냥 추측하지 말고 API 레퍼런스 (API reference)를 사용하십시오.

권장 사항

OpenAI에 상당한 비용을 지출하고 있는 스타트업의 CTO라면, 저는 다음과 같은 순서로 행동할 것입니다:

1. 실제 지출을 감사 (Audit)하십시오. 예상 지출이 아니라, 항목별로 상세히 기록된 실제 지출을 확인하십시오. 기능/사용 사례 (feature/use case)별로 세분화하십시오.

2. 볼륨은 높고 복잡도는 낮은 워크로드 (workloads)를 식별하십시오. 이것들이 바로 마이그레이션 대상입니다. 분류 (Classification), 추출 (extraction), 간단한 요약 (summarization) 등, 볼륨은 많지만 GPT-4o의 완전한 추론 능력이 필요하지 않은 모든 것이 해당됩니다.

3. 라우터 (router)를 구축하십시오. 현재 제공업체가 두 곳뿐이라 하더라도 추상화 (abstraction) 계층을 만드십시오. 미래의 당신이 현재의 당신에게 감사할 것입니다.

4. 병렬 테스트 (parallel test)를 실행하십시오. 일주일 동안 트래픽의 일정 비율을 새로운 제공업체로 보냅니다. 출력값(outputs)을 비교하십시오. 지연 시간 (latency)을 비교하십시오. 비교하십시오.