고백할 것이 있습니다. 저는 2025년 상반기 동안 OpenAI 요금을 마치 종교처럼 당연하게 지불해 왔고, 단 한 번도 의문을 품지 않았습니다. 그러던 어느 화요일, 결제 대시보드를 열고 간단하게 계산을 해보았는데, 커피를 마시다 사레가 들릴 뻔했습니다. 솔직히 말해 평범한 트래픽 수준이었음에도 불구하고 저는 매달 약 500달러를 OpenAI에 쏟아붓고 있었습니다. 그 순간 저는 대안을 찾기 시작했고, 제가 발견한 것은 직장에서 LLM 기능을 설계하는 방식을 근본적으로 바꾸어 놓았습니다.

이 글은 "새로운 모델로 바꿨더니 모든 것이 환상적입니다!"와 같은 그런 종류의 글이 아닙니다. 저는 실제 수치, 실제 코드 변경 사항, 실제 트레이드오프(tradeoffs), 그리고 아무도 미리 말해주지 않는 것들을 여러분께 보여드리고자 합니다. 참고로(fwiw), 저는 백엔드 엔지니어입니다. 저는 분위기나 재현 불가능한 벤치마크에는 관심이 없습니다. 제가 신경 쓰는 것은 다음과 같습니다: 요청이 반환되는가, 출력이 사용 가능한가, 그리고 비용이 얼마인가?

내가 바가지를 쓰고 있다는 것을 깨달은 순간

상황을 설명해 보겠습니다. 제 스택은 구조화된 추출(structured extraction), 요약(summarization), 그리고 일부 에이전트 워크플로우(agentic workflows)가 혼합된 꽤 전형적인 LLM 기반 SaaS입니다. 제 볼륨의 약 60%는 GPT-4o로 가고, 나머지는 저렴한 분류를 위한 gpt-4o-mini와 검색(retrieval)을 위한 가끔의 text-embedding-3-large로 나뉩니다.

GPT-4o의 출력 가격을 Hacker News에서 언급된 몇몇 모델과 비교하여 처음 숫자를 확인했을 때, 저는 정말로 표를 잘못 읽고 있다고 생각했습니다. GPT-4o는 출력 토큰 100만 개당 10.00달러입니다. DeepSeek V4 Flash는 출력 토큰 100만 개당 0.25달러입니다. 오타가 아닙니다. 배수는 정확히 40배입니다.

저는 돌아가서 사용 로그를 세 번 확인했습니다. 저는 GPT-4o에서 충분히 많은 출력 토큰을 소모하고 있었기에, 월 500달러와 약 12.50달러 사이의 차이는 어떤 가설적인 절감액이 아니었습니다. 그것은 매 결제 주기마다 제가 그냥 버리고 있었던 실제 돈이었습니다. 제 생각에(imo), 이것은 모든 엔지니어링 매니저가 분기별로 감사해야 하는 종류의 일이지만, 대부분은 그렇지 않습니다.

그래서 저는 합리적인 엔지니어라면 누구나 할 법한 일을 했습니다. 주말을 반납하여 트래픽의 대부분을 더 저렴한 제공업체(provider)로 마이그레이션(migration)했고, OpenAI에 아주 작은 카나리(canary) 테스트용 트래픽만 남겨둔 채 2주 동안 품질과 지연 시간(latency)을 관찰했습니다. 결국 카나리는 제거되었습니다. 이 모든 일의 시작이 된 표를 보여드리겠습니다.

내 생각을 바꾼 가격표

6개월만 더 일찍 알았더라면 좋았을 비교표입니다. 모든 수치는 100만 토큰(per million tokens)당 기준입니다. 모든 모델은 잠시 후에 설명할 통합 엔드포인트(unified endpoint)를 통해 접근할 수 있습니다.

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

내부적인 세부 사항 중 짚고 넘어갈 몇 가지가 있습니다:

• DeepSeek V4 Flash가 가장 눈에 띄는 수치를 보여주지만, Qwen3-32B도 비용 면에서 아주 약간 더 비쌀 뿐($0.28 vs $0.25 출력 비용) 코드 집약적인 워크로드(workload)에서는 강력한 경쟁자입니다. 두 모델에 동일한 프롬프트(prompt)를 실행해 본 결과, Qwen3-32B가 Python 리팩토링(refactoring) 작업에서 근소하게 앞섰습니다.
• DeepSeek V4 Pro는 추론 깊이(reasoning depth)가 필요할 때 제가 선택하는 모델입니다. 출력 비용이 $0.78/M으로, GPT-4o보다 여전히 12.8배 저렴하며, 제 에이전트 워크플로(agentic workflows) 대부분에서 출력 품질이 GPT-4o와 대등하거나 오히려 더 뛰어납니다.
• GLM-5와 Kimi K2.5는 제 기준에서는 틈새 시장용(niche picks)입니다. GLM-5는 중국어 콘텐츠에 훌륭하며, Kimi K2.5는 문서 분석에 유용한 매우 긴 컨텍스트 윈도우(context window)를 가지고 있습니다.
• "vs GPT-4o" 열은 출력 가격을 기준으로 계산되었습니다. 만약 워크로드가 입력 중심적이라면(긴 프롬프트, 큰 컨텍스트 윈도우), 그 격차는 상당히 줄어듭니다.

부끄러울 정도로 간단한 마이그레이션

이 부분이 제가 왜 진작 이렇게 하지 않았는지 스스로 바보 같다고 느끼게 만든 대목입니다. OpenAI Python SDK는 기본적으로 얇은 HTTP 클라이언트(client)에 불과하며, Global API를 포함한 거의 모든 대안 제공업체는 OpenAI Chat Completions API와 와이어 호환(wire-compatible)되도록 설계되었습니다. 즉, 여러분은 단 두 가지만 바꾸면 됩니다. API 키와 베이스 URL(base URL)입니다. 그게 전부입니다. 당연히 모델 이름도 바뀌겠지만, 요청/응답(request/response) 형태는 동일합니다.

제가 코드베이스에서 정확히 무엇을 변경했는지 보여드리겠습니다. 이것은 식별 가능한 정보들을 제거한 제 실제 운영 리포지토리(production repo)의 실제 diff입니다.

Python: 변경 전과 후

from openai import OpenAI

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

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

...

다시 한번 읽어보세요. 변경된 것은 오직 api_key, base_url, 그리고 model 문자열뿐입니다. 그 외의 모든 파라미터 — temperature, max_tokens, messages, stream, tools, response_format — 는 동일하게 작동합니다. 반환 타입(return type)도 동일한 Pydantic 모델입니다. 기존의 에러 핸들링(error handling)이 그대로 작동합니다. 재시도 로직(retry logic)도 그대로 작동합니다. 로깅(logging)도 그대로 작동합니다.

저는 클라이언트를 래핑(wrap)하는 서비스 추상화(service abstraction)를 가지고 있으며, 환경 변수(environment variable) 하나를 바꾸는 것으로 이를 배포했습니다. 카나리(canary) 설정 시간을 포함하여 약 20분 정도 걸렸으며, 그 시간의 대부분은 제가 무언가를 망가뜨리지 않았는지 세 번씩 확인하는 데 사용되었습니다.

Go: 백엔드 충성파들을 위해

이 글을 읽는 분들 중 많은 분이 운영 환경에서 Go를 사용하고 계신다는 것을 알기에, sashabaranov/go-openai 클라이언트를 사용하는 Go에서의 동일한 변경 사항을 소개합니다:

// 변경 전
client := openai.NewClient("sk-...")

...

내용은 같습니다. 두 줄이 바뀝니다. openai.ChatCompletionRequest 구조체(struct), 응답 형태(response shape), 스트리밍 API(streaming API) — 이 모든 것이 그냥 작동합니다.

제가 처음 이 작업을 했을 때는 함정이 있을 것이라며 계속 기다렸습니다. 하지만 함정은 없습니다. 적어도 표준 채팅 완성(chat completions) 경로에 대해서는 말이죠. OpenAI API는 사실상 사실상의 표준(de facto standard)이 되었으며, 저는 우리가 오늘날 RFC 793을 바라보는 것처럼 이 시대를 바라보게 될 것이라고 생각합니다. 즉, 모두가 구현하는 기초적인 프로토콜(foundational protocol) 말입니다.

작동하는 것과 작동하지 않는 것 (솔직한 목록)

온라인상의 많은 "마이그레이션 가이드(migration guides)"가 마케팅 문구처럼 읽히기 때문에 저는 여기서 신중하고 싶습니다. 제가 실제로 시도하며 작성한 진짜 호환성 표를 보여드리겠습니다:

기능 (Feature)	OpenAI	Global API	내 메모 (My Notes)
Chat Completions	✅	✅	호환 가능 (Wire-compatible), 예상치 못한 문제 없음
...

누락된 두 가지 요소인 파인튜닝 (fine-tuning)과 Assistants API는 일부 팀이 망설이게 만들 수 있는 부분입니다. 왜 이것들이 저에게는 중요하지 않았는지 설명하겠습니다.

**파인튜닝 (fine-tuning)**에 대하여: 저는 2023년에 한 번 시도해 보았으나 투자 대비 효과 (ROI)가 매우 좋지 않았습니다. 베이스 모델 (base models)이 훨씬 더 좋아졌기 때문에, 프롬프트 엔지니어링 (prompt engineering)과 검색 증강 생성 (RAG, retrieval-augmented generation)이 과거에 파인튜닝이 수행하던 역할의 95%를 처리합니다. 만약 정당한 파인튜닝 사용 사례가 있다면 그 차이를 느끼겠지만, 그렇지 않다면 (대부분의 사람들은 그렇지 않습니다) 그것이 없어도 불편함을 느끼지 못할 것입니다.

Assistants API에 대하여: 이것은 OpenAI가 화려한 추상화 (abstraction)를 구축한 사례 중 하나이며, 저를 포함한 많은 백엔드 엔지니어들은 이를 보고 "Postgres 테이블과 상태 머신 (state machine)만 있으면 오후 한나절 만에 직접 만들 수 있겠다"라고 생각했습니다. Assistants API는 파일 처리, 스레드 (threads), 그리고 내장된 코드 해석 (code interpretation) 기능을 갖추고 있지만, 저의 에이전트 런타임 (agent runtime)은 단순히 Chat Completions API 상의 상태 머신일 뿐입니다. OpenAI가 아닌 다른 제공업체로 마이그레이션하면서 저는 해당 아키텍처를 고수할 수밖에 없었고, 솔직히 그것은 옳은 결정이었습니다. 저와 모델 사이의 추상화 단계가 줄어들었기 때문입니다.

만약 TTS(Text-to-Speech)나 STT(Speech-to-Text)가 필요하다면, 전용 서비스를 사용하는 것을 권장합니다. TTS를 위해서는 ElevenLabs, STT를 위해서는 Whisper 배포판 등을 사용하는 식입니다. 이러한 기능들을 LLM 제공업체에 묶어서 사용하는 것은 편리하지만, 비용 측면에서 최적인 경우는 드뭅니다.

확정하기 전 품질을 검증하는 방법

이번 마이그레이션 과정에서 제가 수행한 가장 중요한 일은 적절한 평가 하네스 (evaluation harness)를 구축한 것입니다. 출력 품질이 급격히 떨어진다면 "더 저렴하다"는 것은 아무런 의미가 없습니다. 여러분의 시간을 아껴드릴 수 있도록 제가 사용한 접근 방식을 소개합니다:

1. 지난 한 달간의 실제 운영 요청(production requests) 200개를 샘플링하여, 개인정보(PII)를 제거한 후 골든 세트(golden set)로 저장합니다.
2. 동일한 파라미터로 GPT-4o와 DeepSeek V4 Flash에 동일한 프롬프트를 실행합니다. 출력값에 블라인드 라벨링(blind-label)을 하고, 팀 동료(또는 며칠의 간격을 둔 본인)가 1~5점 척도의 루브릭(rubric)을 기준으로 점수를 매기게 합니다.
3. 실패 모드(failure modes)를 분석합니다. 제 사용 사례의 경우, 저렴한 모델이 가끔 긴 출력을 잘라버리거나(truncated) 니치한 도메인 엔티티(niche domain entities)에 대해 환각(hallucination)을 일으켰습니다. 두 문제 모두 프롬프트 조정과 약간의 온도(temperature) 상승으로 해결 가능했습니다.
4. 플래그(flag) 뒤에서 배포합니다. 일주일 동안 트래픽의 5%를 할당하고, 그다음 50%, 그다음 100%로 늘려갑니다. 대시보드를 모니터링하세요.

제 경우, 요약 및 추출 작업에서 DeepSeek V4 Flash는 제 루브릭 기준으로 GPT-4o와 0.3점 이내의 점수 차이를 보였습니다. 성능이 정말로 떨어졌던 5%의 케이스에 대해서는 $0.78/M 가격의 DeepSeek V4 Pro로 라우팅했습니다. 최종 결과: 요청당 실질 비용이 약 38배 감소했으며, 품질 지표는 오차 범위 내에서 일정하게 유지되었습니다.

실제 청구서에서 확인한 수치

결국 실제로 중요한 것은 인보이스(invoice)에 찍히는 금액이라는 것을 알고 있습니다. 제 12월의 기록은 다음과 같습니다:

• 마이그레이션 전 (OpenAI만 사용): 월 약 $487
• 마이그레이션 후 (Global API, 주로 DeepSeek V4 Flash 사용): 월 약 $14
• 요청당 실질 비용: $0.0031에서 $0.00009로 하락

이는 수만 건의 요청을 처리하는 운영 워크로드(production workload)에서 실제로 약 35배의 감소를 의미합니다. 마이그레이션에는 단 한 번의 오후 시간만 소요되었습니다. 잘못 설정된 크론 잡(cron job) 하나를 디버깅하는 데 더 많은 시간을 썼을 정도입니다.

이 방법이 모든 상황에 보편적으로 적용될 수 있다고 주장하지는 않겠습니다. 만약 워크로드가 주로 입력 중심(예: 거대한 RAG 컨텍스트 윈도우, 긴 문서 인입)이라면, 입력 가격이 더 중요해지며 OpenAI와의 격차도 좁아집니다. 하지만 80%의 사례인 중간 정도의 컨텍스트, 출력 중심, 지연 시간(latency) 허용 가능 케이스의 경우, 계산 결과는 잔혹할 정도로 차이가 납니다. 아주 긍정적인 의미로 말이죠.

시작하기 전에 알았더라면 좋았을 것들

마케팅 문서에는 나와 있지 않지만, 제가 마이그레이션 중에 겪었던 몇 가지 주의사항(gotchas)은 다음과 같습니다:

Rate limits (속도 제한)은 다릅니다. OpenAI의 티어(tier) 시스템은 독자적인 체계를 가지고 있으며, 대부분의 대체 제공업체들도 각자만의 시스템을 가지고 있습니다. 저는 속도 제한이 동일할 것이라고 가정했다가 첫 번째 대규모 배치 작업(batch job) 중에 429 에러를 겪었습니다. 약간의 지수 백오프 (exponential backoff)를 구현해 두면 괜찮겠지만, 동일한 한계치(ceiling)를 기대하지는 마세요.

스트리밍 (Streaming)은 비슷하게 느껴지지만 타임아웃 (timeout)을 주의하세요. 저는 OpenAI 스트리밍 응답에 대해 30초의 타임아웃을 설정해 두었습니다. 더 저렴한 모델들이 평균적으로는 실제로 더 빨랐지만, 몇몇 콜드 스타트 (cold-start) 케이스는 더 오래 걸렸습니다. 안전을 위해 타임아웃을 60초로 늘렸습니다. Python에서 httpx나 requests를 사용한다면, 클라이언트 타임아웃을 충분히 넉넉하게 설정하세요.

토큰 카운팅 (Token counting)은 제공업체마다 다릅니다. 사전 비용 추정 (pre-flight cost estimation)을 수행한다면 (반드시 해야 합니다), DeepSeek 모델의 토크나이저 (tokenizer)는 OpenAI의 토크나이저와 동일하지 않습니다. 제 테스트 결과 출력 카운트는 약 3% 이내의 차이를 보였지만, 바이트 단위까지 완벽히 일치할 것이라고 기대하지는 마세요. 정확한 사전 추정을 위해서는 제공업체 자체의 토크나이저를 사용하거나, 실제 사용량을 측정하여 하루 일과가 끝날 때 정산하는 방식을 사용하세요.

프롬프트 캐싱 (Prompt caching)은 보편적이지 않습니다. OpenAI의 자동 프롬프트 캐싱은 긴 컨텍스트의 RAG (Retrieval-Augmented Generation)를 수행할 때 진정으로 유용합니다. 모든 제공업체가 아직 이 기능을 갖추고 있지는 않습니다. 만약 워크로드(workload)가 이 기능에 크게 의존한다면, 마이그레이션 전에 확인하세요. 참고로(fwiw), 저는 이 기능을 사용하고 있지 않았기에 이것이 저에게 걸림돌이 되지는 않았습니다.

최종 아키텍처 (The Final Architecture)

모든 실험을 거친 후, 제가 결정한 라우팅 전략은 다음과 같습니다. 이는 단순하고, 관찰 가능하며(observable), 추론하기 쉽습니다:

def get_client(task_type: str) -> OpenAI:
...