Weaviate를 사용하여 멀티 리전 DeepSeek RAG 스택을 구축한 방법

우리의 p99 지연 시간(latency) 대시보드가 빨간색으로 변했던 첫 순간을 여전히 기억합니다. 우리는 벡터 저장소(vector stores)와 추론 제공업체(inference providers)가 뒤섞인 환경을 통해 분당 12,000개의 검색 증강 생성 (RAG) 요청을 처리하고 있었고, 그 분포의 꼬리 부분(tail) 어딘가에서 사용자들은 답변을 받기 위해 8.4초를 기다리고 있었습니다. 채팅 UX에서 그것은 영겁의 시간입니다. 그것은 고객 만족도(CSAT)의 폭락을 의미합니다. 그 주에 저는 모든 것을 허물고, 추론 측면에서는 DeepSeek을, 검색 측면에서는 Weaviate를 중심으로 하며 Global API의 통합 게이트웨이를 전면에 내세운 스택으로 재구축했습니다. 6개월 후, 동일한 워크로드가 3개 리전에서 99.97%의 가용성으로 p99 1.9초 내에 실행되고 있습니다. 이것이 바로 그 플레이북입니다.

뻔한 선택지 대신 DeepSeek + Weaviate를 선택한 이유

LLM 기반 서비스를 평가할 때, 저는 모델 리더보드부터 시작하지 않습니다. 저는 세 가지 운영 질문부터 시작합니다: 목표 처리량(throughput)에서의 p99 지연 시간은 얼마인가, 제공업체에 문제가 생겼을 때 장애 상황은 어떤 모습인가, 그리고 화요일 오후에 사용량이 두 배로 늘어날 때 단위 경제성 (unit economics)이 무너지지 않게 하려면 어떻게 해야 하는가? 제 사용 사례의 경우, 이 세 가지 질문에 대한 답은 모두 Global API를 통해 라우팅되는 DeepSeek으로 나타났습니다.

Global API는 100만 토큰당 $0.01에서 $3.50 사이의 가격대로 184개의 모델을 단일 OpenAI 호환 엔드포인트(endpoint)로 노출합니다. 이 가격 차이는 사람들이 깨닫는 것보다 더 중요합니다. 이는 동일한 SDK 호출, 동일한 인증 헤더(auth header), 동일한 베이스 URL(base URL)을 사용하여 간단한 FAQ 재작성은 $0.20 모델로, 복잡한 멀티홉 추론 (multi-hop reasoning) 쿼리는 $2.20 모델로 라우팅할 수 있음을 의미합니다. 제 빌링(billing) 팀은 하나의 인보이스를 받습니다. 제 SRE 팀은 하나의 대시보드 세트를 받습니다. 제 재무 팀은 GPT-4o와 같은 프런티어 모델 (frontier model)에 직접 연결하는 것보다 40~65%의 비용 절감을 얻습니다. 모두가 승리합니다.

벡터 측면에서는 Weaviate를 선택하는 것이 쉬운 결정이었습니다. Weaviate의 샤딩 (sharding) 모델은 진정으로 멀티 테넌트 (multi-tenant) 친화적이며, HNSW 튜닝은 대규모 환경에서도 예측 가능한 재현율 (recall)을 제공합니다. 또한, 복제 (replication) 방식 덕분에 새벽 2시에 커스텀 조정 로직 (custom coordination logic)을 직접 작성할 필요가 없습니다.

실제 수치: 가격 및 처리량 (Throughput)

다음은 제가 CFO와 공유하는 비용 표입니다. 이 수치들은 Global API 카탈로그에서 직접 가져온 100만 토큰당 권장 소비자 가격 (list prices)입니다:

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

차이를 확인해 보십시오. 200K 컨텍스트의 DeepSeek V4 Pro 호출은 GPT-4o보다 입력 비용은 4배, 출력 비용은 4.5배 더 저렴하며 컨텍스트 윈도우 (context window)는 더 큽니다. 토큰의 70%가 컨텍스트 주입 (context injection)인 RAG 워크로드에서, 이 계산이 승패를 결정짓는 핵심입니다.

운영 환경에서 측정한 결과, DeepSeek V4 Flash는 샤드 (shard)당 초당 320 토큰의 처리량 (throughput)으로 엔드 투 엔드 지연 시간 (end-to-end latency, 임베딩 조회 + 프롬프트 조립 + 생성) 평균 1.2초를 기록했으며, 내부 평가 스위트 (eval suite)에서 평균 84.6%의 점수를 받았습니다. GPT-4o로 전환하는 폴백 (fallback) 경로는 동일한 처리량에서 약 1.8초가 소요되지만 비용은 대략 4.5배 더 높습니다. 저는 이를 기본값이 아닌, 품질을 보장하기 위한 낙하산 (parachute) 용도로 유지합니다.

실제 구현

다음은 제가 사용하는 클라이언트의 운영 버전입니다. SDK 버전을 고정하고, 기본 URL을 단일 환경 변수 (env var)로 유지하며, 나중에 리팩토링할 필요가 없도록 첫날부터 모델 라우팅 (model routing)을 내장해 두었습니다:

import openai
import os
from dataclasses import dataclass
...

복잡도 라우터 (complexity router)는 현재 키워드 길이와 물음표에 대한 정규 표현식 (regex)을 사용하는 매우 단순한 방식이지만, 핵심은 연결 지점 (seam)이 존재한다는 것입니다. 분류기 (classifier)가 더 똑똑해지더라도 클라이언트를 수정할 필요가 없습니다.

Weaviate 측면: p99를 정직하게 유지하는 방법

RAG 시스템의 지연 시간 (latency)은 세 곳에서 발생합니다: 벡터 검색 (vector search), 프롬프트 조립 (prompt assembly), 그리고 LLM 호출 (LLM call)입니다. LLM 호출은 가장 느린 구간이지만 가장 예측 가능합니다. 벡터 검색은 변동성 (variance)이 숨어들기 가장 좋은 곳입니다.

저는 각 리전(region)마다 3-레플리카(3-replica) 구성으로 Weaviate를 실행하며, 가장 빈번하게 사용되는 컬렉션(collection)이 단일 레플리카 메모리의 50%를 초กว่า 넘지 않도록 샤드(shard) 크기를 조정합니다. 임베딩 생성(Embedding generation)은 쿼리 시점이 아닌 쓰기 시점(write time)에 수행됩니다. 이는 검색(retrieval) 호출이 단순히 HNSW 탐색(traversal)과 네트워크 홉(network hop)만으로 이루어짐을 의미합니다. 저의 p95 검색 지연 시간(latency)은 38ms, p99는 71ms입니다. 저는 평균값이 아니라 이 수치들을 기준으로 용량 계획(capacity planning)을 세웁니다.

임베딩 일관성(embedding consistency)을 위해, 추론(inference)에 사용하는 것과 동일한 모델 제품군(model family)으로 벡터를 생성합니다. 임베더(embedder)와 생성기(generator)를 혼용하는 것은 RAG 품질을 떨어뜨리는 소리 없는 살인자 중 하나입니다. 검색 단계에서 임베딩 공간(embedding space) 상의 "유사한" 것들을 찾아내더라도, 생성기가 이를 실제로 활용할 수 없게 만들기 때문입니다. 절대 하지 마세요.

멀티 리전(Multi-Region)과 제가 실제로 달성한 SLA

저에게 멀티 리전은 단순히 체크박스를 채우는 항목이 아니라, SLA(Service Level Agreement)입니다. 제 계약은 99.9%의 가용성(availability)을 보장하며, 이는 하나의 리전이 완전히 다운되는 상황에서도 살아남아야 함을 의미합니다. 저의 토폴로지(topology)는 명확합니다:

us-east-1, eu-west-1, ap-southeast-1 모두 활발하게 트래픽을 처리합니다.
글로벌 API 엔드포인트(endpoint)는 가장 가까운 정상 리전으로 해석(resolve)됩니다.
Weaviate 클러스터는 리전별로 독립적입니다. 리전 간 복제(cross-region replication)는 2초의 지연 시간(lag)을 목표로 하는 비동기(async) 방식입니다.
us-east-1에 도착한 요청은 us-east-1의 Weaviate에서 읽습니다. 그것으로 끝입니다. 단일 RAG 호출을 위해 동기식(synchronously)으로 리전을 넘나들지 않습니다. 지연 시간 비용이 너무 높고 실패 모드(failure modes)가 너무 많기 때문입니다.

대신 저는 엣지(edge)에서 상태 확인(health-checked) 기반의 페일오버(failover)를 수행합니다. 만약 us-east-1의 DeepSeek 트래픽이 30초 동안 0.5% 이상의 5xx 에러를 반환하기 시작하면, 트래픽 관리자(traffic manager)가 eu-west-1으로 경로를 재지정(reroute)합니다. 지난 90일 동안 측정된 저의 가용성은 99.97%였습니다. 이는 제 SLA 목표보다 4.3배 더 나은 수치이며, 덕분에 온콜(on-call) 담당자들에게 많은 신뢰를 얻었습니다.

오늘 시작하는 누구에게나 해주고 싶은 다섯 가지 조언

이것들은 실제 운영 트래픽을 견뎌내며 살아남은 관행들입니다. 이 중 일부는 제가 고생하며 배운 것들입니다. 여러분은 지름길을 택하시길 바랍니다.

1. 가능한 모든 계층에서 캐싱(Cache)을 수행하세요. 임베딩(Embedding) 수준에서의 시맨틱 캐시(Semantic cache), 쿼리(Query) 수준에서의 완전 일치 캐시(Exact-match cache), API 에지(Edge)에서의 응답 캐시(Response cache)가 있습니다. 시맨틱 캐시의 히트율(Hit rate)을 40%로 유지하는 것만으로도 현재 트래픽 기준 월 약 $11,000를 절약했습니다. 구현 방법은 결과에 TTL(Time-to-Live)을 설정한 최근 쿼리 임베딩들의 Weaviate 컬렉션(Collection)을 사용하는 것입니다.

2. 사용자에게 노출되는 모든 것은 스트리밍(Stream)하세요. 측정되는 것은 p99이지만, 사용자가 불만을 느끼는 것은 체감 지연 시간(Perceived latency)입니다. 스트리밍은 첫 번째 토큰 생성 시간(Time-to-first-token)을 1.2초에서 180ms로 단축하며, 전체 생성 시간은 동일하더라도 사용자는 그 차이를 느낍니다. OpenAI SDK는 추가적인 작업 없이 stream=True를 통해 이를 지원합니다.

3. 저렴한 티어(Tier)를 공격적으로 사용하세요. $0.20/$0.80 가격의 GLM-4 Plus는 짧은 형식의 Q&A, 요약, 구조화된 추출(Structured extraction) 등 놀라울 정도로 많은 트래픽을 처리합니다. 전체 볼륨의 50%를 저가형 모델로 라우팅(Routing)함으로써 추론(Inference) 비용을 절반으로 줄였습니다. 쉬운 작업에서의 품질 차이는 제가 측정할 수 있는 오차 범위(Noise floor) 미만입니다.

4. 지연 시간뿐만 아니라 품질을 모니터링하세요. 지연 시간 대시보드는 사용자가 좋은 답변을 받고 있는지에 대해 아무것도 알려주지 않습니다. 저는 추천(Thumbs-up) 비율, 재생성(Regenerate) 비율, 그리고 골드 셋(Gold set)을 기준으로 채점한 무작위 응답 200개에 대한 주간 스팟 체크(Spot-check)를 추적합니다. 앞서 언급한 84.6%라는 벤치마크 수치는 공개 리더보드가 아니라 이 루프(Loop)에서 나온 것입니다.

5. 필요하기 전에 폴백(Fallback) 경로를 구축하세요. 속도 제한(Rate limits)은 발생합니다. 제공업체 장애(Provider outages)도 발생합니다. 기본 모델에 대해 지터(Jitter)를 포함한 3회 재시도 전략을 사용하고, 지속적인 실패 시 보조 모델로 폴백하는 방식은 셀 수 없이 많은 횟수 동안 저의 SLA를 지켜주었습니다. 폴백 비용은 평소 지출의 1%에 불과하지만, 4시간 동안 서비스가 중단되었을 때의 비용은 측정할 수 없을 만큼 큽니다.

처음부터 다시 시작한다면 바꾸고 싶은 것들

솔직히 말해서, 바꿀 것은 별로 없습니다. 생성(Generation)을 위한 DeepSeek, 검색(Retrieval)을 위한 Weaviate, 그리고 게이트웨이로서의 Global API의 조합은 이전의 스택이었다면 녹아내렸을 부하 속에서도 잘 버텨주었습니다. 굳이 꼬투리를 잡자면, 시맨틱 캐시 (Semantic Cache)를 3개월 차가 아닌 첫 주부터 구축했을 것입니다. 그 공백기 동안 실제로 낭비된 비용이 꽤 컸습니다. 또한 섀도 트래픽 (Shadow-traffic) 배포 파이프라인에도 더 일찍 투자했을 것입니다. 184개의 모델 카탈로그를 대상으로 하는 카나리 배포 (Canary releases)는 생산성을 비약적으로 높여주는 힘이 됩니다.

가장 감사하게 생각하는 점은 이 모든 것을 혼자 할 필요가 없었다는 것입니다. Global API는 184개의 모델에 대해 단일 통합 지점을 제공해주었습니다. 덕분에 저희 팀은 184개의 개별 SDK 호출 경로를 유지 관리하는 대신, 검색 품질 (Retrieval quality), 프롬프트 평가 (Prompt evaluation), 용량 계획 (Capacity planning)과 같은 어려운 부분에 집중할 수 있었습니다. 새로운 모델을 A/B 테스트하고 싶을 때, 저는 라우팅 설정 (Routing config)에서 문자열 하나만 변경하고 메트릭 (Metrics)을 관찰하면 됩니다. 이것이 저희 규모의 팀에게 적합한 추상화 (Abstraction)입니다.

만약 여러분도 비슷한 문제 — 너무 많은 모델, 너무 많은 청구서, 밤잠을 설치게 만드는 p99 — 에 직면해 있다면, Global API를 살펴보십시오. 가격 페이지는 명확하며, SDK는 이미 익숙한 OpenAI의 것과 동일합니다. 가입 시 제공되는 무료 크레딧은 실제 데이터를 사용하여 제대로 된 벤치마크 (Benchmark)를 실행하기에 충분합니다. 스택이 여러분에게 제대로 작동할지 알 수 있는 유일한 방법은 그것뿐입니다.