DeepSeek를 활용하여 Flutter 스택의 LLM 비용을 60% 절감한 방법

3개월 전, 저는 마치 몸값을 요구하는 협박 편지처럼 보이는 우리의 월간 AI 청구서를 멍하니 바라보고 있었습니다. 우리는 문서 요약(document summarization)과 의도 분류(intent classification)를 수행하는 Flutter 앱을 위해 GPT-4o를 실행하고 있었고, 비용 소모율(burn rate)은 감당하기 어려운 수준으로 치솟고 있었습니다. 우리는 시드 단계(seed-stage)의 스타트업이기에 모든 달러가 중요했습니다. 다음 투자 유치(fundraise) 전까지 무언가 변화가 필요하다는 것을 알고 있었습니다.

그날 저녁, 저는 주말 동안 우리의 LLM 레이어 전체를 다시 작성했습니다. 결과는 다음과 같습니다: 60%의 비용 절감, 측정 가능한 품질 저하 없음, 그리고 벤더 종속성(vendor lock-in) 제로. 제가 정확히 어떻게 이를 수행했는지, 이를 프로덕션(production)에 배포하며 무엇을 배웠는지, 그리고 다시 한다면 어디에서 다른 결정을 내릴지에 대해 설명하겠습니다.

아무도 경고해주지 않는 벤더 종속성(Vendor Lock-In)의 함정

앱을 처음 출시했을 때, 우리는 모든 것을 OpenAI의 SDK에 직접 연결했습니다. 전형적인 실수였습니다. 약 두 달 동안은 아주 잘 작동했습니다. 그러다 속이 울렁거릴 정도의 첫 번째 인보이스(invoice)를 받았고, 저는 우리 아키텍처에 세 가지 구조적인 문제가 내재되어 있다는 것을 깨달았습니다:

가격 비교를 할 수 없었습니다. 모든 모델이 서로 다른 인증(auth), 서로 다른 스트리밍 의미론(streaming semantics), 그리고 서로 다른 에러 핸들링(error handling)을 가진 각기 다른 SDK 뒤에 존재했습니다. 더 저렴한 모델로 전환하는 것은 설정 변경이 아니라 전체 재작성을 의미했습니다.
필요하지 않은 기능에 과도한 비용을 지불하고 있었습니다. 우리 트래픽의 대부분은 짧은 형식의 분류(classification)와 추출(extraction)입니다. 우리는 더 작은 모델이 충분히 해낼 수 있는 작업을 처리하기 위해 GPT-4o의 요율을 지불하고 있었습니다.
폴백 경로(fallback path)가 없었습니다. 제품 출시 중에 OpenAI가 우리에게 속도 제한(rate-limited)을 걸었을 때, 앱은 그냥... 죽어버렸습니다. 우아한 성능 저하(graceful degradation)도, 장애 조치(failover)도 없었습니다. 규모가 커지면 이는 5단계 비상사태(five-alarm fire)와 같습니다.

해결책은 더 저렴한 API를 찾는 것이 아니었습니다. 해결책은 애초에 우리의 코드베이스를 특정 제공업체에 결합(coupling)하는 것을 멈추는 것이었습니다.

스프레드시트 계산: 우리가 실제로 지출하고 있었던 것

기술적인 변경을 수행하기 전에, 로그에서 2주간의 실제 트래픽을 추출했습니다. 분포는 양봉형(bimodal)이었습니다. 요청의 약 70%는 짧은 분류 호출(입력 200 토큰 미만, 출력 100 토큰 미만)이었고, 30%는 더 긴 요약 작업(입력 2K 토큰, 출력 500 토큰)이었습니다. GPT-4o를 사용했을 때 우리 규모에서의 수치는 다음과 같았습니다:

백만 입력 토큰당: $2.50
백만 출력 토큰당: $10.00
128K 컨텍스트 윈도우 (Context window)
월간 비용: 약 4M 입력 + 800K 출력 토큰 기준 약 $11,400

그 다음, 후보 모델들에 동일한 워크로드(workload)를 실행해 보았습니다. 여기서 전체 표를 보여드려 지루하게 만들지는 않겠지만, 실제 운영에 적합한 최종 후보 목록은 다음과 같았습니다:

모델	입력 ($/M)	출력 ($/M)	컨텍스트 (Context)
DeepSeek V4 Flash	0.27	1.10	128K
...

핵심적인 수치는 다음과 같습니다: DeepSeek V4 Flash는 GPT-4o보다 입력 비용은 약 9배, 출력 비용은 약 9배 저렴합니다. 우리의 70%에 달하는 단문 트래픽의 경우, GLM-4 Plus는 $0.20/$0.80으로 훨씬 더 공격적인 가격을 보여줍니다. DeepSeek V4 Pro의 200K 컨텍스트는 가끔 전체 계약서를 입력해야 하는 요약 경로(summarization path)에서 이를 실행 가능하게 만든 요소였습니다.

참고로, Global API는 백만 토큰당 $0.01에서 $3.50 사이의 가격대를 가진 184개의 모델을 나열하고 있습니다. 변동 폭이 매우 크며, 특정 워크로드에 대한 정답이 가격 범위의 최상단에 위치하는 경우는 거의 없습니다.

아키텍처 결정: 하나의 SDK, 다양한 모델

저의 첫 번째 원칙은 간단했습니다. 다시는 애플리케이션 계층(application layer)에 특정 제공업체 전용 코드를 작성하고 싶지 않다는 것이었습니다. 이는 모든 모델을 단일한 OpenAI 호환 인터페이스(OpenAI-compatible interface)를 통해 노출하는 통합 게이트웨이(unified gateway)를 찾고, 이를 얇은 내부 추상화(internal abstraction)로 감싸서 코드베이스의 나머지 부분이 어떤 모델이 호출되고 있는지조차 알 수 없게 만드는 것을 의미했습니다.

제가 Global API를 선택한 데에는 두 가지 이유가 있습니다. 첫째, OpenAI SDK를 그대로 대체(drop-in)할 수 있어 기존 코드가 기본적으로 계속 작동했다는 점입니다. 둘째, 설정 하나만 바꾸는 것만으로 동일한 프롬프트에 대해 모델을 A/B 테스트할 수 있는 능력을 제공했다는 점입니다. 이것이 바로 우리 단계의 스타트업 CTO에게 필요한 레버리지(leverage)입니다.

통합 과정은 다음과 같았습니다:

import os
from openai import OpenAI

...

총 설정 시간은 10분 미만이었습니다. 환경 변수(env var)와 베이스 URL(base URL)만 변경하면 되었습니다.

워크로드별 트래픽 라우팅 (진정한 승리)

여기가 실제로 비용 절감이 발생한 지점입니다. 저는 "LLM"을 하나의 단일한 대상으로 취급하는 것을 중단했습니다. 대신 요청의 형태(shape)에 따라 라우팅하기 시작했습니다:

짧은 분류 / 추출 (Short classification / extraction) → DeepSeek V4 Flash ($0.27/$1.10)
중간 크기의 Q&A 및 도구 사용 (Mid-size Q&A and tool use) → Qwen3-32B ($0.30/$1.20) (더 강력한 추론이 필요할 때)
긴 문맥 요약 (Long-context summarization) → DeepSeek V4 Pro ($0.55/$2.20) (200K 컨텍스트 작업용)
백그라운드, 저위험 작업 (Background, low-stakes tasks) → GLM-4 Plus ($0.20/$0.80)

절감액이 쌓여갔습니다. 2주간의 프로덕션 트래픽을 거친 후, 월간 실행 비용(monthly run rate)은 약 $11,400에서 약 $4,500로 떨어졌습니다. 이는 동일한 워크로드에서 60%의 감소를 의미하며, 품질 벤치마크는 내부 평가 스위트(internal eval suite)에서 84.6% 정도로 안정적으로 유지되었습니다. 지연 시간(Latency)은 초당 320 토큰의 처리량(throughput)과 함께 평균 1.2초를 기록했는데, 이는 더 작은 모델들이 더 빠르게 구동되기 때문에 짧은 형식의 경로(short-form path)에서는 GPT-4o에서 확인했던 것보다 실제로 더 빨랐습니다.

결정타가 된 스트리밍 + 캐싱 패턴

모델 교체 외에도 두 가지 변화가 청구서 금액을 추가로 30% 더 낮췄습니다. 두 가지 모두 지루한 작업이지만, 규모가 커질 때(at scale) 필수적입니다.

스트리밍 (Streaming). 100 토큰 이상을 생성하는 사용자 대면 기능에 대해서는 스트리밍 응답(streaming responses) 방식으로 전환했습니다. 첫 번째 토큰까지의 체감 지연 시간(Perceived latency)이 1.5초에서 400ms 미만으로 줄어들었습니다. 사용자들이 앱이 멈췄다고 생각하여 긴 생성 과정을 포기하는 일이 사라지면서, 실제 세션 길이(session length)는 오히려 늘어났습니다.

캐싱 (Caching). 저는 LLM 호출 앞에 Redis 기반의 간단한 시맨틱 캐시 (semantic cache)를 구축했습니다. 특히 분류 (classification) 엔드포인트의 경우, 유입되는 메시지의 롱테일 (long tail)이 놀라울 정도로 반복적입니다. "계정 관련 도움이 필요해요", "비밀번호를 재설정하고 싶어요", "상담원과 연결해 주세요"와 같은 메시지들은 임베딩 (embedding) 과정을 거친 후 동일한 캐시 키 (cache key)로 수렴합니다. 현재 분류 엔드포인트에서 40%의 히트율 (hit rate)을 기록하고 있는데, 이는 해당 호출의 40%가 모델에 아예 닿지도 않는다는 것을 의미합니다. 그야말로 공짜 돈이나 다름없습니다.

import hashlib
import json
import redis
...

이 코드 스니펫 (snippet)은 실제로 저희 백엔드 프로덕션 환경에서 실행되고 있다는 점에서 프로덕션 레디 (production-ready)라고 할 수 있습니다. 이 패턴은 일반화가 가능합니다. 입력을 해싱 (hash)하고, Redis를 확인한 뒤, 일치하는 것이 없으면 모델로 넘기고, TTL (Time To Live)과 함께 결과를 다시 기록하는 방식입니다. 의도 (intents)는 안정적이므로 분류 작업에는 1시간의 TTL을 사용하고, FAQ 답변 같은 경우에는 24시간을 사용합니다.

실전에서 배운 프로덕션 레디 체크리스트

제가 고생하며 배운 몇 가지 사항이며, 다음에 다시 시작한다면 첫날부터 정책으로 코드화할 내용들입니다:

항상 폴백 모델 (fallback model)을 준비하세요. 2주 전 DeepSeek에 20분간 장애가 발생했을 때, 저희 앱은 서킷 브레이커 (circuit breaker)를 기반으로 GLM-4 Plus로 자동 전환되었고, 사용자들은 전혀 눈치채지 못했습니다. 단일 벤더 (single-vendor) 설계였다면 서비스가 중단되었을 것입니다.
지연 시간 (latency)뿐만 아니라 토큰 (tokens)을 로깅하세요. 비용은 토큰 수의 함수이며, 측정하지 않는 것은 최적화할 수 없습니다. 모든 요청은 입력, 출력, 모델, 그리고 총 비용을 로깅합니다. 저는 그 위에 Grafana 패널을 구축했습니다.
모델을 고정하되, 교체 가능하게 유지하세요. 모델 이름을 코드 내에 두지 않고 설정 (config)에 저장합니다. 설정값 푸시 한 번으로 트래픽의 100%를 전환할 수 있습니다. 이는 A/B 테스트와 장애 대응 모두에 유용했습니다.
컨텍스트 윈도우 (context window) 불일치를 주의하세요. Qwen3-32B의 32K 제한 때문에 롱 컨텍스트 (long-context) 경로에서 두 번이나 낭패를 보았습니다. 이제는 요청이 모델에 도달하기 전 API 게이트웨이 (API gateway) 단계에서 거절합니다. 강제하는 비용은 저렴하지만, 무시했을 때의 비용은 매우 비쌉니다.
비용뿐만 아니라 품질을 추적하세요. 품질 신호 (quality signal) 없는 비용 최적화는 성능 퇴보 (regression)를 배포하는 지름길입니다.

우리는 매일 500개의 프롬프트로 구성된 골든 세트 (golden set)를 프로덕션 환경에서 실행하며, 점수가 하락할 경우 알림을 받습니다. 84.6%라는 벤치마크 (benchmark)는 계속 변하는 목표이며, 우리는 이를 변동적인 목표로 취급합니다.

규모의 경제에서의 ROI (그리고 이것이 스프레드시트보다 중요한 이유)

60%의 비용 절감이 헤드라인이지만, 진정한 ROI (투자 대비 수익)는 선택권 (optionality)에 있습니다. 통합 게이트웨이 (unified gateway)를 통해 우리 팀은 오후 시간만으로 모델을 교체할 수 있습니다. 다음 분기에 DeepSeek V5가 출시되거나 새로운 중국 모델이 리더보드 (leaderboard)에 진입하면, 트래픽의 5%를 해당 모델로 라우팅 (routing)하여 품질과 비용을 측정하고, 하루 만에 적용하거나 되돌릴 수 있습니다. 이것이 바로 AI 기능 (feature)과 AI 제품 (product)의 차이입니다.

우리는 또한 속도 제한 (rate limits)을 두려워하는 일을 멈췄습니다. 429 오류는