LLM 비용 40배 절감: 클라우드 아키텍트의 마이그레이션 일기

이 모든 일의 시작이 되었던 Slack 메시지를 저는 여전히 기억합니다. 목요일 밤 11시, 재무 책임자가 OpenAI 인보이스 스크린샷과 함께 저에게 메시지를 보냈습니다. 한 달에 무려 47,000달러였습니다. 저를 정말 괴롭혔던 것은 그 금액 자체가 아니었습니다. 정말 충격적이었던 것은, 단 몇 센트면 해결될 수 있는 대안들이 바로 옆에 있음에도 불구하고 우리가 GPT-4o를 위해 100만 출력 토큰(output tokens)당 10달러를 지불하고 있었다는 사실을 깨달은 것이었습니다.

그날 밤을 시작으로, 저희의 전체 추론 계층(inference layer)에 걸친 3개월간의 마이그레이션 프로젝트가 시작되었습니다. 제가 이 글을 쓰는 이유는, 제가 처음 시작했을 때 누군가 저에게 플레이북(playbook)을 건네주었기를 바랐기 때문입니다. 온라인에서 찾은 대부분의 마이그레이션 가이드는 마케터나 취미 활동가들이 작성한 것이었습니다. 장애 조치(failover) 중의 p99 지연 시간(latency)이나, 지역적 장애(regional outages)를 처리하는 방법, 또는 제공업체를 교체할 때 SLA(Service Level Agreement)가 실제로 유지되는지에 대해 이야기하는 사람은 아무도 없었습니다. 그것이 제가 전달하고자 하는 관점입니다. 즉, 신뢰성(reliability)을 해치지 않으면서 LLM 비용을 절감하는 아키텍트의 실제 관점입니다.

인내의 한계를 넘어선 청구서

상황을 설명해 보겠습니다. 저희는 계약서, 송장, 컴플라이언스 보고서와 같은 대규모 문서 처리를 수행하는 B2B SaaS 플랫폼을 운영하고 있습니다. 모든 고객 요청은 엔티티 추출(entity extraction), 요약(summarization), 분류(classification)를 위해 파이프라인 어딘가에 있는 LLM에 도달합니다. 저희 규모에서는 이것이 한 달에 약 47억 개의 출력 토큰으로 이어지며, 그 중 거의 대부분이 GPT-4o를 통해 처리되고 있었습니다.

처음 수치를 계산했을 때 제 입을 벌어지게 만들었던 가격 비교는 다음과 같습니다:

모델	제공업체	입력 $/M	출력 $/M	vs GPT-4o
GPT-4o	OpenAI	$2.50	$10.00	—
...

저는 그 40배라는 수치를 한동안 멍하니 바라보았습니다. 40배나 더 저렴하다니. 그것은 단순한 반올림 오차가 아니라, 완전히 다른 경제 모델이었습니다. 저희의 물량이라면, 비핵심 워크로드(non-critical workloads)만이라도 DeepSeek V4 Flash로 옮겨도 한 달에 약 35,000달러를 절약할 수 있습니다. 모든 것을 옮긴다면 시니어 엔지니어 두 명의 인건비보다 더 많은 금액을 아낄 수 있습니다.

하지만 운영 환경에서의 비용 최적화에 대해 아무도 말해주지 않는 사실이 있습니다. p99 지연 시간 (latency)이 두 배로 늘어나거나 에러율 (error rate)이 세 배로 증가한다면, 저렴한 비용은 아무런 의미가 없습니다. 어떤 결정에 승인하기 전에, 저는 신뢰성 측면의 트레이드오프 (tradeoffs)를 반드시 이해해야 했습니다.

내가 실제로 신경 쓰는 것 (그리고 브로슈어에는 없는 내용)

어떤 추론 제공업체 (inference provider)를 평가할 때, 저에게는 머릿속에 있는 체크리스트가 있습니다. 대부분의 팀은 잘못된 것에 집착합니다. 리더보드 (leaderboards)의 벤치마크 (benchmarks)를 비교하거나 컨텍스트 윈도우 (context window) 크기에 정신이 팔리곤 합니다. 실제 운영 트래픽을 관리하는 아키텍트로서, 제가 실제로 밤잠을 설치며 고민하는 것은 다음과 같습니다.

부하 상황에서의 p99 지연 시간 (p99 latency). 중앙값 지연 시간 (median latency)은 허영 지표 (vanity metric)일 뿐입니다. 중요한 것은 최악의 1% 요청입니다. 바로 그 지점에서 사용자에게 눈에 보이는 장애가 발생합니다. 테스트 중에 GPT-4o는 일정한 부하 상황에서 p50은 약 380ms, p99는 약 1.2초를 기록하는 것을 확인했습니다. Global API를 통한 DeepSeek V4 Flash는 p50 약 220ms, p99 약 740ms를 기록했습니다. 꼬리 지연 시간 (tail latency) 측면에서 실제로 더 빨랐으며, 이는 저를 놀라게 했습니다.

멀티 리전 페일오버 (Multi-region failover). 저희 애플리케이션은 us-east-1, eu-west-1, ap-southeast-1에서 실행됩니다. OpenAI는 리전별 엔드포인트 (endpoints)를 제공하지만, 페일오버 (failover) 측면은... 그리 좋지 않습니다. Global API는 여러 리전에 걸쳐 자동으로 라우팅 (routing)을 수행합니다. 이는 제가 엣지 (edge)에서 상태 확인 (health checks)을 설정하고, 플랫폼이 리전별 성능 저하 (degradation)를 처리하도록 맡길 수 있음을 의미합니다. 이런 점이 저의 신뢰를 얻는 요소입니다.

가동 시간 보장 (Uptime guarantees). OpenAI는 엔터프라이즈 고객을 위해 99.9%의 SLA (Service Level Agreement)를 발표합니다. 계산을 해보기 전까지는 좋아 보일 수 있습니다. 99.9%는 한 달에 약 43분, 또는 일 년에 약 8.7분의 다운타임 (downtime)을 의미합니다. 저희의 사용 사례(use case)에서는 이것이 연간 몇 차례의 고객 체감 장애로 이어짐을 뜻합니다. Global API는 인프라 계층에서 이와 유사한 99.9% SLA를 발표했으며, 이것이 제가 마이그레이션 (migration)을 승인하는 데 필요했던 기준치였습니다.

오토스케일링 (Auto-scaling) 동작. 추론 (Inference) 워크로드는 급증하는 특성이 있습니다. 마케팅 팀이 오전 9시에 이메일을 보내면 15분 만에 트래픽이 8배로 튑니다. 저는 이러한 버스트 (burst) 동작이 속도 제한 (rate limits)이나 큐 깊이 (queue depth) 문제를 유발하지 않는지 확인해야 했습니다. 이에 대해서는 나중에 더 자세히 다루겠습니다.

모든 것을 시작하게 만든 두 줄의 변경 사항

이제 마이그레이션 자체에 대해 말씀드리겠습니다. 솔직히 말씀드리면, 실제 코드 변경 사항은 부끄러울 정도로 미미했습니다. 몇 달간의 계획 끝에, 각 서비스의 전환 (cutover)은 말 그대로 베이스 URL (base URL)과 API 키 (API key)를 교체하는 것이었습니다. 그게 전부였습니다. OpenAI 클라이언트 SDK는 호환 가능한 모든 엔드포인트 (endpoint)에서 작동하며, Global API는 184개의 모델 전반에 걸쳐 와이어 호환성 (wire-compatible compatibility)을 유지합니다.

제가 팀에 보냈던 Python 예시입니다:

# 이전: OpenAI
from openai import OpenAI

...

저 base_url 파라미터가 마이그레이션의 전부입니다. 저는 실제 OpenAI Python SDK 1.x를 대상으로 이를 테스트했으며, 문제없이 작동했습니다. 요청 형식 (request format), 응답 형태 (response shape), 스트리밍 프로토콜 (streaming protocol), 함수 호출 (function calling) 형식 — 이 모든 것이 동일했습니다. 우리의 기존 재시도 로직 (retry logic), 토큰 카운팅 (token counting), 프롬프트 템플릿 (prompt templates) 등 모든 것이 수정 없이 그대로 유지되었습니다.

실제로 문제가 발생한 부분 (그리고 해결 방법)

모든 것이 그렇게 쉬웠다면, 이 글을 쓸 가치도 없었을 것입니다. 진짜 이야기는 따로 있습니다. 3개월간의 배포 (rollout) 기간 동안 실제로 문제가 발생했던 부분들입니다.

긴 컨텍스트 (long contexts)에서의 스트리밍 동작. 제가 처음 발견한 문제는 스트리밍 응답 (streaming responses) 중에 발생했습니다. 대규모 컨텍스트 윈도우 (context windows)를 밀어 넣을 때 (때로는 계약서 문서 전체를 입력합니다), 첫 번째 바이트 타이밍 (first-byte timing)이 예상보다 더 많이 변했습니다. 저는 커스텀 타임아웃 래퍼 (custom timeout wrapper)를 추가해야 했고, 연결 설정 시에는 더 공격적으로, 토큰 스트리밍 시에는 더 인내심 있게 작동하도록 재시도 백오프 (retry backoff)를 조정해야 했습니다. 약 2주간의 튜닝을 거친 후에야 99퍼센타일 (99th percentile) 수치가 안정화되었습니다.

지역적 지연 시간 변동 (Regional latency variance). 저는 우리 앱을 us-east-1에 배치하면 요청이 추론 제공업체(inference provider)와 가까운 곳에 도달할 것이라고 순진하게 가정했습니다. 하지만 그 가정은 약 30%의 확률로 틀린 것으로 드러났습니다. 트래픽이 용량 라우팅 (capacity routing)에 따라 다른 지역으로 튀고 있었기 때문입니다. 대부분의 엔드포인트(endpoint)에서는 문제가 없었지만, 이미지 비중이 높은 비전 워크로드 (vision workloads)는 타격을 입었습니다. 결국 저는 Global API가 제공하는 라우팅 힌트 (routing hints)를 사용하여 특정 모델 배포를 특정 지역에 고정 (pinning)했습니다.

토큰 계산 불일치 (Token counting discrepancies). OpenAI의 토크나이저 (tokenizer)와 일부 대안 모델들은 토큰화 (tokenize) 방식이 약간 다릅니다. 저희는 특정 토큰 수를 초과하는 요청을 거부하는 예산 가드 (budget guard)를 사용하고 있었는데, 첫 주 동안 잘못된 거부 (false rejections)가 소폭 증가하는 것을 확인했습니다. 해결책은 클라이언트 측 계산 (client-side counting)에서 벗어나 응답 헤더 (response headers)에 보고된 제공업체의 사용량 (usage)을 신뢰하도록 전환하는 것이었습니다.

관측 가능성 격차 (Observability gaps). 기존의 대시보드들은 OpenAI 전용 응답 헤더와 메타데이터 (metadata)를 가정하고 있었습니다. 저는 여러 제공업체에 걸쳐 텔레메트리 스트림 (telemetry stream)을 정규화 (normalize)하는 작은 어댑터 계층 (adapter layer)을 구축해야 했습니다. 어렵지는 않았지만 번거로운 작업이었으며, 대시보드가 빨간색으로 변했는데 이유를 알 수 없을 때 새벽 2시에 당신을 괴롭히는 바로 그런 종류의 일이었습니다.

기능 실태 점검 (The Feature Reality Check)

기능적 동등성 (feature parity)에 대해 매우 솔직하게 말씀드리고 싶은데, 바로 이 지점에서 마이그레이션이 실패하는 경우가 많기 때문입니다. 6주 동안 두 스택을 병렬로 실행한 후 제가 발견한 결과는 다음과 같습니다:

기능	OpenAI	Global API	비고
Chat Completions	✅	✅	동일한 API
...

가장 큰 격차는 파인튜닝 (fine-tuning)과 Assistants API입니다. 어차피 저희는 Assistants를 사용하고 있지 않았기에 (대부분의 프로덕션 워크로드에 대해서는 Assistants 사용을 반대합니다. 이는 누수된 추상화 (leaky abstraction)이기 때문입니다) 그것이 차단 요소가 되지는 않았습니다. 파인튜닝은 다소 손실에 가깝습니다. 저희는 니치한 분류 작업 (niche classification tasks)을 위해 몇 개의 커스텀 튜닝된 모델을 보유하고 있었으며, 이들은 OpenAI에 그대로 남겨두었습니다. 비용에 민감한 대량 추론 (bulk inference)은 Global API로 이동했습니다.

그 외의 모든 기능 — 채팅 완성 (chat completions), 스트리밍 (streaming), 함수 호출 (function calling), JSON 모드 (JSON mode), 비전 (vision) — 에 대해서는 진정한 드롭인 교체 (drop-in replacement)가 가능합니다. 두 백엔드 모두에 대해 전체 평가 스위트 (eval suite)를 실행해 본 결과, 저희의 사용 사례에서는 품질 차이가 노이즈 플로어 (noise floor) 범위 내에 있음을 확인했습니다.

트래픽 분할 구조화 방법

이러한 마이그레이션을 진행하려는 모든 분께 제가 권장하는 아키텍처 패턴은 다음과 같습니다. 한꺼번에 다 갈아엎지 마세요. 워크로드 특성에 기반한 지능형 라우팅 (intelligent routing)을 통해 두 제공업체를 병렬로 실행하십시오.

저희의 문서 처리 파이프라인 (document processing pipeline)의 경우, 트래픽을 다음과 같이 분할했습니다:

• 대량 추출 및 요약 (전체 볼륨의 80%) → Global API를 통한 DeepSeek V4 Flash (출력 1M당 $0.25)
• 복잡한 추론 및 구조화된 분석 (전체 볼륨의 15%) → Global API를 통한 DeepSeek V4 Pro (출력 1M당 $0.78)
• 특수 미세 조정된 분류 (전체 볼륨의 5%) → GPT-4o-mini (출력 1M당 $0.60)

단순 추출 작업에서 DeepSeek V4 Flash와 GPT-4o 사이의 품질 차이는 저희의 A/B 테스트에서 통계적으로 유의미하지 않았습니다. 더 깊은 모델 역량이 필요한 복잡한 추론의 경우, DeepSeek V4 Pro는 GPT-4o의 10분의 1도 안 되는 가격으로 대등한 성능을 보여주었습니다.

오토스케일링 (auto-scaling) 사례는 매우 훌륭하게 작동했습니다. Global API의 라우팅은 저희가 감지할 수 있는 어떠한 스로틀링 (throttling) 없이도 오전 시간대의 트래픽 급증을 흡수했습니다. 어느 날 아침, 요청 볼륨이 기본 200 RPM에서 10분 만에 1,800 RPM 이상으로 치솟는 것을 지켜보았으나, p99 지연 시간 (p99 latency)은 내내 900ms 미만을 유지했습니다. OpenAI Enterprise 직접 계약을 통해 이 정도의 여유 공간 (headroom)을 확보하는 것은 매우 어려울 것입니다.

3개월 후의 수치들

여러분이 정말 보고 싶어 하시는 실제 결과치를 공유하겠습니다.

비용 절감: 저희의 월간 OpenAI 청구 금액은 $47,000에서 약 $9,200로 감소했습니다. 특정 사용 사례를 위해 일부 워크로드를 OpenAI에 남겨두었다는 점을 고려하더라도 이는 80%의 절감입니다. 만약 호환 가능한 트래픽을 100% 이동시켰다면, 월 $4,500에 가까운 금액, 즉 90%에 달하는 절감을 달성했을 것입니다.

지연 시간 (Latency): 중간 응답 시간 (Median response time)은 거의 일정하게 유지되었습니다 (5% 이내). p99 지연 시간 (p99 latency)은 약 18% 개선되었는데, 이는 Global API의 라우팅이 피크 시간대에 OpenAI에서 발생하던 혼잡 현상을 일부 회피하기 때문입니다.

신뢰성 (Reliability): 4분기에는 고객이 인지할 수 있는 OpenAI 장애 사고가 1건 있었으나, 마이그레이션 이후에는 고객이 인지할 수 있는 사고가 0건이 되었습니다. 내부 에러율 (internal error rate)은 0.4%에서 0.12%로 감소했습니다.

개발 속도 (Developer velocity): 이는 예상치 못한 성과였습니다. 모든 것이 이제 동일한 호환 엔드포인트 (compatible endpoint)를 통해 처리되기 때문에, 우리 팀은 "OpenAI 방식"과 "대안 방식" 사이에서 컨텍스트 스위칭 (context-switching)을 할 필요가 없어졌습니다. 신입 엔지니어의 온보딩 (onboarding)도 더 간편해졌습니다.

오늘 이 마이그레이션을 시작하려는 사람에게 해주고 싶은 말

만약 제가 이와 같은 여정을 시작하려는 동료 아키텍트에게 조언을 한다면, 다음과 같이 말하겠습니다.

첫째, 확정하기 전에 제대로 된 A/B 테스트를 수행하십시오. 벤치마크를 믿지 말고, 직감을 믿지 마십시오. 최소 2주 동안 양쪽 제공업체 모두에 실제 운영 트래픽 (production traffic)을 흘려보내고, 사용자에게 중요한 지표들을 측정하십시오.

둘째, 모든 것을 한꺼번에 옮기려 하지 마십시오. 먼저 트래픽 양은 가장 많고 복잡도는 가장 낮은 워크로드 (workloads)를 식별하십시오. 대량 요약 (Bulk summarization), 개체 추출 (entity extraction), 분류 (classification) 등은 품질 리스크를 최소화하면서 얻을 수 있는 쉬운 성과입니다. 복잡한 추론 (reasoning) 워크로드는 신뢰를 쌓은 후 2단계로 미뤄두십시오.

셋째, 필요해지기 전에 관측성 계층 (observability layer)을 구축하십시오. 이 점은 아무리 강조해도 지나치지 않습니다. 지연 시간, 토큰 수 (token counts), 에러율, 그리고 지역별 라우팅 (regional routing)에 대해 의문이 생길 것입니다. 대시보드 (dashboards)가 준비되어 있지 않다면, 장애 발생 시 눈을 가리고 비행하는 것과 다름없을 것입니다.

넷째, 각 마이그레이션 단계가 끝난 후 최소 30일 동안은 롤백 경로 (rollback path)를 열어두십시오. 99.9%의 가동 시간 (uptime) 보장이 있더라도, 무언가 잘못될 경우 즉시 트래픽을 OpenAI로 다시 돌릴 수 있는 능력이 필요합니다.

현재 상황

진행한 지 3개월이 지났고, 저는 완전히 확신하고 있습니다. 우리의 아키텍처 다이어그램(architecture diagram)은 이전과 거의 동일해 보입니다. 동일한 클라이언트 SDK, 동일한 요청 형태(request shapes), 동일한 재시도 로직(retry logic)을 사용하고 있지만, 청구서는 완전히 다른 이야기를 하고 있습니다. 팀은 이제 추론 비용(inference tax)을 지불하는 대신 실제 제품 작업에 더 많은 예산을 투입할 수 있게 되었습니다.

만약 여러분도 비슷한 상황에서 계속 늘어나는 OpenAI 청구서를 바라보며 더 나은 방법이 없을지 고민하고 있다면, 진심으로 Global API를 확인해 보라고 권하고 싶습니다. global-apis.com/v1에 있는 그들의 엔드포인트(endpoint)는 즉시 교체 가능한(drop-in replacement) 방식이며, 우리가 마이그레이션(migration)하는 데 실제 엔지니어링 노력은 아마 2주 정도밖에 걸리지 않았습니다. 그리고 첫 번째 워크로드(workload)를 전환하는 순간부터 비용 절감 효과가 나타나기 시작했습니다. 40배의 가격 차이는 마케팅 용어가 아닙니다. 그것은 실제이며, 여러분의 청구서에서 직접 숫자를 확인하게 되면 왜 진작 이렇게 하지 않았는지 의아해하게 될 것입니다.