DeepSeek V4 Flash의 지연 시간(Latency)을 더 빨리 알았더라면 — CTO의 분석

솔직히 말해서, DeepSeek V4 Flash의 지연 시간(Latency)을 더 빨리 알았더라면 좋았을 것입니다 — CTO의 분석

6개월 전, 저는 유명한 로고를 가졌다는 이유만으로 선택한 모델 때문에 막대한 현금을 쏟아붓고 있었습니다. 지난달에야 마침내 자리에 앉아 실제 벤치마크(benchmarks)를 실행하고 우리의 추론 계층(inference layer)을 재구축했습니다. 월간 청구서의 차이는 당혹스러울 정도였습니다. 이 글은 제가 첫 번째 아키텍처(architectural) 결정을 내리기 전에 읽었어야 했던 바로 그 글입니다.

제가 정확히 무엇을 배웠는지, 프로덕션(production) 환경에서 수치가 어떻게 나타나는지, 그리고 우리에게 실제로 유의미한 변화를 가져다준 아키텍처 선택은 무엇이었는지 설명해 드리겠습니다. 만약 여러분이 대규모 추론(inference)을 운영하는 CTO이고, 특히 이사회의 예산 압박을 받고 있다면, 이 글이 여러분의 몇 주간의 작업 시간과 상당한 비용 소모(burn)를 줄여줄 것입니다.

우리가 여기까지 오게 된 과정 — 짧은 고백

직설적으로 말씀드리겠습니다. 우리의 첫 제품을 출시했을 때, 저는 모든 초기 단계의 CTO가 저지르는 것과 똑같은 실수를 했습니다. 모두가 이야기하는 브랜드를 선택한 것입니다. 우리는 파이프라인(pipeline)의 핵심에 GPT-4o를 연결했고, 소수의 고객에게 제품을 출시하며 축하했습니다. 그러다 성장을 시작했습니다. 그리고 인보이스(invoices)가 도착했습니다.

3개월간의 성장 후, 활성 사용자당 추론 비용(inference cost)은 유닛 이코노믹스(unit economics)가 작동하지 않는 선을 넘어섰습니다. 무언가 변해야 한다는 것은 알고 있었지만, 대안에 대한 구체적인 데이터가 없었습니다. 그래서 저는 첫날 했어야 했던 일을 했습니다. 장난스러운 프롬프트(toy prompts)가 아니라, 우리가 실제로 실행하는 워크로드(workloads)를 대상으로 실제 벤치마크(benchmarks)를 실행했습니다.

이 글은 바로 그 과정에 관한 것입니다.

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

초기에 단일 제공업체에 올인하는 것에는 문제가 있습니다. 더 깊이 들어갈수록 떠나기가 더 어려워진다는 점입니다. 커스텀 함수 호출(function-calling) 형식, 제공업체 전용 캐싱 API(caching APIs), 서비스 코드에 내장된 SDK 가정 사항들 — 이 모든 것이 해소하기에 비용이 많이 드는 기술 부채(technical debt)로 쌓이게 됩니다.

저는 이를 어렵게 배웠습니다. 대안을 평가하고 싶었을 때, 이미 수 주일이 걸리는 마이그레이션(migration) 프로젝트를 마주하게 되었습니다. 지연된 하루하루는 과다 지불을 하는 또 다른 하루였습니다.

교훈은 이렇습니다: 첫날부터 교체 가능성(swap-ability)을 고려하여 설계하십시오. 표준 인터페이스를 노출하는 통합 API 레이어(unified API layer)를 사용하고, 프롬프트 로직(prompt logic)을 특정 제공자에게 종속되지 않도록(provider-agnostic) 유지하십시오. 구체적인 구현 방법은 잠시 후에 다루겠지만, 이 설계 결정 하나만으로도 우리가 마침내 마이그레이션을 진행했을 때 큰 도움을 받았습니다.

나를 분노하게 만든 수치들

우리가 결국 표준으로 삼게 된 애그리게이터(aggregator)인 Global API에서 가격 데이터를 가져왔습니다. 이 서비스는 단일 OpenAI 호환 엔드포인트(OpenAI-compatible endpoint)를 통해 184개의 모델을 노출하며, 그 가격 차이는 엄청납니다. 호출하는 모델에 따라 100만 토큰당 가격이 $0.01에서 $3.50까지 다양합니다.

다음은 제가 마침내 마이그레이션을 결정하게 만든 표입니다:

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

GPT-4o 열을 보십시오. 우리는 DeepSeek V4 Flash보다 출력 토큰당 대략 9배 더 많은 비용을 지불하고 있었으며, 컨텍스트 윈도우(context window)는 동일했습니다. 계산기를 두드려보지 않아도 답이 나오는 수치입니다.

모델에 부하를 많이 주는 긴 컨텍스트 분석 작업인 우리의 deep_dive 워크로드(workload)의 경우, 계산기를 돌려본 순간 전환에 따른 ROI(투자 대비 효율)가 명확해졌습니다. 우리의 사용 사례에 적합한 모델들을 살펴보니, 기존에 지불하던 비용 대비 40~65%의 비용 절감을 확인할 수 있었으며, 품질 또한 병렬 평가(side-by-side evaluation)에서 충분히 유지되었습니다.

실제 운영 환경에서 측정한 것들

가격은 이야기의 절반일 뿐입니다. 나머지 절반은 더 저렴한 모델이 실제 부하(load) 상황에서도 제대로 성능을 내는지 여부입니다. 저는 2주 동안 지연 시간(latency), 처리량(throughput), 품질 지표를 캡처할 수 있도록 서비스를 계측(instrumented)했습니다. Global API를 통해 DeepSeek V4 Flash를 실행하며 발견한 결과는 다음과 같습니다:

• 평균 지연 시간 (Average latency): 비스트리밍(non-streamed) 완료 시 엔드 투 엔드(end-to-end)로 1.2초
• 처리량 (Throughput): 지속적으로 초당 320 토큰
• 품질 (내부 평가 스위트): 우리의 참조 세트(reference set) 대비 평균 벤치마크 점수 84.6%
• 컨텍스트 처리 (Context handling): 전체 128K 윈도우까지 매끄럽게 작동

이 수치들은 우리에게 이 모델이 프로덕션(Production)에 적용 가능한 수준임을 보여주었습니다. 지연 시간(Latency)은 실제로 더 비싼 모델에서 관찰되었던 것보다 더 좋았는데, 이는 부분적으로 우리가 더 이상 속도 제한(Rate-limit)으로 인해 대기열(Queuing)에 갇히지 않게 되었기 때문입니다.

DeepSeek V4 Pro를 살펴보았을 때, 지연 시간 프로필은 유사했지만 더 큰 200K 컨텍스트(Context) 덕분에 이전에는 청크(Chunk)로 나누고 다시 이어 붙여야(Stitch) 했던 유스케이스(Use cases)들을 활용할 수 있게 되었습니다. 긴 컨텍스트가 필요한 워크로드(Workloads)의 경우, Flash 대비 2배의 비용은 GPT-4o와 비교하면 여전히 매우 저렴한 수준입니다.

기존 스택을 대체한 코드

다음은 전체 마이그레이션(Migration) 과정입니다. 기존의 SDK를 버리고 Global API를 가리키는 OpenAI 클라이언트(Client)로 교체했습니다. 총 코드 변경 사항은 약 20줄 정도입니다. 통합 SDK 덕분에 기존의 모든 서비스 코드, 재시도(Retries), 그리고 관측성(Observability) 훅(Hooks)을 그대로 유지할 수 있었습니다. 이것이 바로 벤더 종속(Vendor lock-in)을 피할 수 있는 정확한 아키텍처(Architecture)입니다. 애플리케이션 코드는 표준 인터페이스(Interface)와 통신하며, 아무것도 다시 작성하지 않고도 그 뒤의 모델을 교체할 수 있습니다.

import openai
import os
from typing import List, Dict
...

두 가지 모델 선택지, 하나의 클라이언트, 하나의 베이스 URL(Base URL). 만약 다음 분기에 간단한 쿼리(Queries)를 GLM-4 Plus(이것은 $0.20/$0.80로 훨씬 더 저렴합니다)로 라우팅(Route)하거나 Qwen3-32B로 실험을 진행하고 싶다면, 변경 사항은 단 한 줄입니다.

다음은 체감 지연 시간(Perceived latency)이 중요한 사용자 대상 엔드포인트(Endpoints)를 위한 스트리밍(Streaming) 예시입니다:

from inference_client import InferenceClient

client = InferenceClient()
...

저는 한 시간 만에 스테이징(Staging) 환경에서 이를 실행했고, 일주일 만에 프로덕션(Production)으로 전환했습니다. 전환 후 첫 인보이스(Invoice)가 그 결과를 말해주었습니다. 동일한 워크로드(Workload)임에도 불구하고 지출이 58% 감소했습니다.

실제로 중요한 프로덕션 관행

비용은 하나의 레버(Lever)입니다. 다른 하나의 레버는 모델을 어떻게 사용하는가입니다. 모델 교체 후 우리에게 가장 큰 승리를 안겨준 관행들은 다음과 같습니다:

1. 공격적으로 캐싱(Cache)하십시오. 우리는 의미론적 유사성 매칭(Semantic similarity matching)을 통해 프롬프트(Prompts)를 캐싱합니다. 40%의 히트율(Hit rate)을 달성함으로써, 모델 절감액에 더해 실질적인 추론(Inference) 비용을 추가로 35-40% 더 낮췄습니다. 이는 우리가 올해 수행한 변화 중 단일 항목 기준 가장 높은 ROI(투자 대비 수익)를 기록한 변화입니다.

2. 사용자 대면 서비스는 모두 스트리밍(Streaming)하세요. 전체 지연 시간(Total latency)보다 첫 번째 토큰이 생성될 때까지의 시간(Time-to-first-token)이 더 중요합니다. 사용자는 스트리밍을 더 빠르다고 인지하며, 클라이언트에 즉시 데이터를 반환하기 시작할 수 있습니다. 또한, 스트리밍이 실패했을 때 재시도하는 비용은 전체 완료(Full completions)가 실패했을 때보다 저렴합니다.

3. 단순한 쿼리는 더 저렴한 모델로 라우팅(Route)하세요. 모든 요청에 DeepSeek V4 Pro가 필요하지는 않습니다. 우리는 짧고 단순한 쿼리를 Global API를 통해 GA-Economy로 라우팅했으며, 해당 하위 집합에서 추가로 50%의 비용 절감을 확인했습니다. 통합 인터페이스(Unified interface) 덕분에 이러한 라우팅은 매우 간단합니다.

4. 품질을 지속적으로 모니터링하세요. 품질이 저하되는 저렴한 모델은 숨겨진 비용입니다. 우리는 사용자 만족도 점수, 작업 완료율(Task completion rates)을 추적하며, 별도로 분리된 테스트 세트(Held-out test set)를 대상으로 매일 평가 파이프라인(Eval pipeline)을 실행합니다. 품질이 떨어지면 즉시 알림(Paged)을 받습니다.

5. 실제 폴백(Fallback) 경로를 구축하세요. 속도 제한(Rate limits)은 발생합니다. 제공업체(Provider)의 중단도 발생합니다. 여러분의 아키텍처는 우아하게 성능을 저하시켜야(Degrade gracefully) 합니다. 보조 모델로 폴백하거나, 큐에 넣고 재시도하거나, 사용자에게 명확한 에러를 표시해야 합니다. 우리는 지난 분기 주요 제공업체 장애 당시 이를 뼈아픈 경험을 통해 배웠습니다.

이 모든 것을 하나로 묶어주는 아키텍처 결정

만약 제가 과거의 저를 위해 이 글을 쓴다면, 이 부분에 굵게 표시를 할 것입니다: 여러분이 할 수 있는 가장 중요한 일은 안정적인 인터페이스 뒤로 모델 계층을 추상화(Abstract)하는 것입니다.

저는 창업자들이 애플리케이션 로직을 특정 제공업체의 SDK에 직접 결합하는 것을 끊임없이 목격합니다. 그들은 커스텀 도구(Custom tools), 제공업체 전용 캐싱(Provider-specific caching), 제공업체 전용 스트리밍 형식과 같은 특정 제공업체 전용 기능들을 사용합니다. 3개월 후 그들이 더 저렴한 모델로 A/B 테스트를 하고 싶어 할 때, 그들은 몇 주가 걸릴 리팩터링(Refactor) 작업을 마주하게 됩니다.

제가 현재 자문하는 모든 팀에 권장하는 패턴은 다음과 같습니다:

• 서비스 코드 내의 단일 클라이언트 인터페이스
• 제공업체에 구애받지 않는(Provider-agnostic) 메시지 형식
• 코드가 아닌 설정(Configuration)으로서의 모델 선택
• 여러 제공업체에 걸쳐 작동하는 관측성(Observability)
• 요청별로 모델을 선택하는 라우팅 계층(Routing layer)

이러한 패턴을 구축해 두면, 단 하루 만에 새로운 모델을 A/B 테스트할 수 있습니다. 비용, 지연 시간 (Latency), 품질 점수, 사용자 등급 등 합리적인 기준에 따라 라우팅할 수 있습니다. 그리고 다음 혁신적인 모델이 출시되면, 당일 즉시 트래픽의 10%에 바로 적용할 수 있습니다.

Global API는 이를 우리에게 실질적으로 가능하게 만든 요소입니다. 이들은 단일 OpenAI 호환 엔드포인트를 통해 184개의 모델을 노출하기 때문에, 제가 184개의 어댑터 (Adapter)를 직접 작성할 필요가 없었습니다. 기본 URL(Base URL)이 동일하고, 인증(Auth) 방식이 동일하며, 요청 형식(Request format)도 동일합니다. 이러한 표준화는 몇 주가 걸리는 마이그레이션(Migration)과 단순한 설정 변경 사이의 차이를 만들어냅니다.

주의해야 할 사항

모든 과정이 순탄했던 것만은 아닙니다. 좀 더 일찍 고려했더라면 좋았을 몇 가지 사항들이 있습니다:

• 실제 워크로드 (Workload)를 평가하세요. 일반적인 벤치마크 (Benchmark)는 귀하의 사용 사례 (Use case)를 포착하지 못합니다. 실제 운영 트래픽의 샘플(익명화 처리됨)을 후보 모델에 실행해 보고 출력값을 점수화하세요.
• 평균값뿐만 아니라 지연 시간의 변동성 (Latency variance)을 주시하세요. 사용자 경험을 망치는 것은 P99 지연 시간입니다. 일부 저렴한 모델들은 평균값은 괜찮지만 꼬리 부분(Tail)의 지연 시간이 매우 불규칙할 수 있습니다.
• 모델별 속도 제한 (Rate limits)을 확인하세요. 애그리게이터 (Aggregator)는 직접 연결했을 때 얻을 수 있는 여유 공간을 항상 동일하게 제공하지는 않습니다. 마케팅 스파이크(Marketing spike) 기간 동안 몇 차례 스로틀링 (Throttling) 문제를 겪었으며, 더 높은 제한치를 협상해야 했습니다.
• 컨텍스트 윈도우 (Context window)의 차이에 유의하세요. Qwen3-32B의 32K 제한은 긴 문서 작업을 시도했을 때 우리에게 큰 어려움을 주었습니다. 실제 컨텍스트 사용량의 경계 지점에서 테스트를 진행하세요.

결론

Global API를 통해 접속하는 DeepSeek V4 Flash는 테스트 한 달 만에 우리의 기본 추론 (Inference) 모델이 되었습니다. 수치가 모든 것을 증명했습니다. 이전 설정과 비교하여 동등하거나 더 나은 품질, 극적으로 낮은 지연 시간 변동성, 그리고 첫 달 운영 트래픽 기준 약 58% 낮은 비용을 기록했습니다.

더 큰 컨텍스트가 필요한 워크로드의 경우, DeepSeek V4 Pro가 200K 윈도우를 무리 없이 처리합니다. 사소한 쿼리(Query)의 경우, GLM-4 Plus 또는 GA-Economy로 라우팅하여 예산을 더욱 효율적으로 활용하고 있습니다.

이 글을 읽고 있는 CTO로서 여전히 단일한 고가의 제공업체(Provider)만을 이용하고 있다면, 제 솔직한 조언은 하루 정도 시간을 내어 직접 수치를 계산해 보라는 것입니다. 마이그레이션(Migration)은 생각보다 저렴하며, 특히 애그리게이터(Aggregator)를 통하면 더욱 그렇습니다. 그리고 기다리는 매달 ROI(투자 대비 수익)는 복리로 쌓입니다.

살펴볼 가치가 있는 곳

수십 개의 제공업체 계정을 가입하지 않고 직접 벤치마크(Benchmark)를 실행하고 싶다면, Global API를 확인해 볼 가치가 있습니다. 시작 시 100의 무료 크레딧을 제공하는데, 이는 대부분의 184개 모델을 실제 워크로드(Workload)에 대해 테스트하기에 충분한 양입니다. OpenAI 호환 인터페이스(OpenAI-compatible interface)를 지원하므로, 몇 분 안에 기존 클라이언트를 해당 서비스로 연결하여 바로 측정을 시작할 수 있습니다.

이 서비스를 6개월만 더 일찍 알았더라면 좋았을 것입니다. 그랬다면 몇 번의 불편한 이사회(Board meeting)를 피할 수 있었을 텐데 말입니다.