DeepSeek과 ChromaDB가 우리의 기본 RAG 스택이 된 이유

저는 6개월 전, 저희 엔지니어링 팀이 검색 증강 생성 (Retrieval-Augmented Generation, RAG)을 생각하는 방식을 완전히 바꿔 놓은 결정에 대해 이야기하고 싶습니다. 당시 저희는 막대한 현금을 태우고 있었습니다. 정말 엄청난 액수였죠. 더 최악인 점은 무엇이었을까요? 결과조차 훌륭하지 않았다는 것입니다. 그래서 저는 월 4만 달러의 OpenAI 청구서를 마주한 새벽 2시의 스타트업 CTO라면 누구나 할 법한 행동을 했습니다. 바로 기존 스택을 완전히 해체하고 처음부터 다시 시작하는 것이었습니다.

그 결정은 Global API를 통해 실행되는 DeepSeek V4 Pro 및 V4 Flash와 벡터 저장소 (Vector Store)로서의 ChromaDB를 결합하는 결과로 이어졌습니다. 6개월간의 프로덕션 운영을 거쳐 데이터가 집계되었습니다. 제가 무엇을 배웠는지, 무엇이 망가졌는지, 그리고 왜 내일이라도 당장 이 과정을 다시 반복할 것인지에 대해 말씀드리겠습니다.

임계점 (The Breaking Point)

작년에 저희는 관대하게 표현하자면 "베스트 프랙티스 (Best Practice)"라고 부를 만한 RAG 설정을 운영하고 있었습니다. 임베딩 (Embeddings)에는 GPT-4o, 생성 (Generation)에는 GPT-4o, 벡터에는 Pinecone, 그리고 이 모든 것을 오케스트레이션 (Orchestrating)하는 데는 LangChain을 사용했습니다. 작동은 했습니다. 하지만 엄청난 비용이 들었습니다. 청구 금액은 사용량과 함께 계속 치솟았고, 쿼리당 경제성을 확인할 때마다 속이 울렁거릴 정도였습니다.

"기본" RAG 스택에 대해 아무도 말해주지 않는 사실이 있습니다. 그것은 데모를 위해 최적화되어 있을 뿐, 프로덕션 규모 (Production Scale)를 위해 최적화된 것이 아니라는 점입니다. 하루에 20만 개의 쿼리를 처리할 때는 밀리초 단위의 지연 시간 (Latency)과 토큰당 0.1센트의 비용 차이가 매우 중요해집니다. 저희는 평균 1.8초의 지연 시간, 초당 약 180토큰 수준에서 병목 현상이 발생하는 처리량 (Throughput), 그리고 사용자 기반보다 더 빠르게 증가하는 청구서를 마주하고 있었습니다.

저는 팀원들과 앉아 이렇게 말했습니다. "우리는 이것을 다시 구축할 것입니다." GPT-4o가 나쁘기 때문이 아닙니다. 그렇지 않습니다. 하지만 저희 규모에서 단일 제공업체에 대한 벤더 종속 (Vendor Lock-in)은 생존의 위협이며, 수익성을 달성하려는 스타트업 입장에서 쿼리당 비용 계산이 도저히 맞지 않았기 때문입니다.

벤더 종속 (The Vendor Lock-In) 문제

이 부분은 대부분의 블로그 포스트가 생략하는 내용이며, 솔직히 말해서 모든 CTO에게 가장 중요한 부분입니다. 추론 (Inference) 비용의 90%가 단일 벤더를 통해 발생한다면, 그것은 아키텍처가 아니라 인질 상황입니다. 해당 벤더가 가격을 인상하거나, 서비스 장애가 발생하거나, 사용 중인 모델을 지원 중단 (Deprecate) 하는 날, 당신의 비즈니스는 끝납니다. 저는 이전 회사에서 이런 일을 직접 겪었으며, 다시는 같은 실수를 반복하지 않겠다고 다짐했습니다.

그래서 첫 번째 설계 원칙은 간단했습니다. RAG 파이프라인의 모든 구성 요소는 한 시간 이내에 교체 가능해야 한다는 것입니다. 모델, 벡터 스토어 (Vector store), 오케스트레이션 레이어 (Orchestration layer)까지 전부 말입니다. 이것이 ChromaDB가 벡터 스토어 선정 과정 (Bake-off)에서 승리한 이유입니다. ChromaDB는 오픈 소스이며, 로컬에서 실행되고, 수평적 확장 (Scale horizontally)이 가능하며, 우리를 묶어둘 '엔터프라이즈 티어'가 없습니다. 우리는 내일이라도 최소한의 고통만으로 Qdrant나 Milvus로 옮겨갈 수 있습니다.

모델 레이어에서는 Global API가 역할을 했습니다. 이들은 단일 OpenAI 호환 엔드포인트를 통해 184개의 AI 모델을 제공하며, 바로 이 점이 저를 설득했습니다. DeepSeek V4 Flash를 Qwen3-32B나 GLM-4 Plus와 비교 테스트하고 싶을 때, 우리는 설정 파일의 문자열 하나만 바꾸면 됩니다. 새로운 SDK도, 새로운 인증 흐름 (Auth flow)도, 새로운 결제 관계도 필요 없습니다. 이것이 바로 향후 18개월을 버텨낼 수 있는 아키텍처입니다.

결정을 내리게 만든 비용 계산

이제 돈 이야기를 해봅시다. 결국 이것은 비용에 관한 이야기이기 때문입니다. 이전에 토큰 100만 개당 지불했던 비용은 다음과 같습니다:

• GPT-4o: 입력 $2.50, 출력 $10.00, 128K 컨텍스트 (Context)
• Pinecone: 우리 규모 기준으로 포드 (Pod)당 월 약 $70, 여기에 스토리지 비용 별도

현재 제가 지불하고 있는 비용은 다음과 같습니다:

표를 다시 한번 보십시오. 우리의 주력 생성 모델인 DeepSeek V4 Pro의 비용은 입력 $0.55, 출력 $2.20입니다. GPT-4o는 입력 $2.50, 출력 $10.00입니다. 이는 입력 비용은 약 4.5배, 출력 비용도 약 4.5배 절감된 수치입니다. 컨텍스트 윈도우 (Context window) 또한 200K로 더 커졌기 때문에, 내용을 잘라내지 않고도 각 프롬프트에 더 많은 검색된 컨텍스트를 집어넣을 수 있습니다.

우리는 계층형 모델 전략 (tiered model strategy)을 실행합니다. 추론이 필요한 복잡한 다단계 쿼리에는 DeepSeek V4 Pro를 사용합니다. 단순한 검색 및 요약 (retrieval-and-summarize) 작업인 트래픽의 80%에는 DeepSeek V4 Flash를 사용합니다. 예외적인 케이스를 위한 폴백 (fallback)으로는 GLM-4 Plus를 사용합니다. 쿼리당 비용이 매우 낮기 때문에, 필요할 때 여러 번의 패스 (multiple passes)를 수행할 여유가 있어 품질에 대해 공격적인 태도를 취할 수 있는 경제성을 갖추고 있습니다.

최종 결과: 월간 추론 비용이 62% 감소했습니다. 지연 시간 (latency)은 평균 1.2초로 떨어졌습니다. 처리량 (throughput)은 초당 320 토큰으로 상승했습니다. 사용자 만족도 점수와 내부 평가 스위트 (eval suite)로 측정한 품질은 실제로 향상되었습니다. 당사의 벤치마크 스위트에서 84.6%를 기록하고 있으며, 이는 GPT-4o 베이스라인보다 3포인트 향상된 수치입니다. 왜일까요? 200K 컨텍스트 윈도우 (context window)를 사용할 여유가 있어 더 많은 검색된 청크 (retrieved chunks)를 포함할 수 있고, 이는 환각 (hallucinations)이 줄어든다는 것을 의미하기 때문입니다.

실제 구현 (The Implementation, For Real)

다음은 우리가 실제로 실행하는 코드입니다. 이것은 튜토리얼이 아니라 프로덕션 (production) 코드입니다. 베이스 URL (base URL)에 주목하세요. 이것이 여러분에게 필요한 유일한 통합 지점입니다:

import os
from openai import OpenAI
import chromadb
...

이것이 RAG 루프의 전부입니다. 임베딩 (Embed), 검색 (retrieve), 생성 (generate). LangChain도, LlamaIndex도, 오케스트레이션 프레임워크 (orchestration framework)도 없습니다. 오직 OpenAI 호환 호출과 로컬 벡터 스토어 (vector store)뿐입니다. 움직이는 부품이 적을수록, 새벽 3시에 고장 나는 일도 적어집니다.

실제로 비용을 절감하는 프로덕션 패턴

위의 코드를 단순하게 구현한 버전도 작동은 하지만, 비용이 낭비됩니다. 캐싱 (caching), 폴백 (fallback), 그리고 계층형 모델 전략을 적용하여 우리가 실제로 실행하는 버전은 다음과 같습니다:

import hashlib
import json
from functools import lru_cache
...

세 가지 주목할 점이 있습니다. 첫째, 캐시 (cache)입니다. 일반적인 쿼리에 대해 40%의 캐시 적중률을 보이며, 이는 해당 쿼리들에 대해 직접적으로 40%의 비용 절감으로 이어집니다. 둘째, 계층형 모델 선택 (tiered model selection)입니다. 대부분의 쿼리는 200K 컨텍스트를 가진 Pro 모델이 필요하지 않습니다. Flash 모델로도 충분히 처리 가능합니다. 셋째, 폴백 (fallback)입니다. DeepSeek의 속도 제한 (rate-limit)에 걸릴 때 (드물지만 발생합니다), 우리는 GLM-4 Plus로 페일오버 (fail over)합니다. 프로덕션 준비가 되었다는 것은 500 에러가 아니라 우아한 성능 저하 (graceful degradation)를 의미합니다.

과거의 나에게 해주고 싶은 말

첫날에 알았더라면 좋았을 몇 가지 사항들입니다. ChromaDB의 HNSW 인덱스는 빠르지만, 기본 설정은 우리의 규모에 맞춰 튜닝되어 있지 않습니다. 우리는 200만 개의 벡터 컬렉션(2M-vector collection)에 대해 ef_construction을 8로, M을 16으로 설정했고, 그 결과 재현율(recall)이 91%에서 96%로 향상되었습니다. 임베딩(Embedding) 비용은 은밀하게 다가옵니다. 인덱스를 재구성(reindex)할 때마다 50,000개의 문서를 임베딩하고 있다는 사실을 깨닫기 전까지는 비용이 작아 보입니다. 우리는 공격적으로 배치(batch) 처리를 수행하며, 모든 문서 변경 시마다 재구성하는 것이 아니라 정해진 일정에 따라 재구성합니다.

스트리밍(Streaming)은 선택 사항이 아닙니다. 제가 언급한 평균 1.2초의 지연 시간(latency)에는 스트리밍을 통한 첫 번째 토큰까지의 시간(time to first token)이 포함되어 있습니다. 스트리밍이 없다면 체감 지연 시간은 2.5초에 가까워지며, 사용자는 이를 알아차립니다. 스트리밍을 사용하면 첫 번째 토큰이 180ms 안에 도착하여 사용자는 시스템이 작동하고 있음을 보게 됩니다. UX(사용자 경험)는 API 수준에서도 중요합니다.

품질 모니터링은 아무도 구축하고 싶어 하지 않는 부분입니다. 우리는 따봉(thumbs up/down)을 통해 사용자 만족도를 추적하며, 수동 검토를 위해 응답의 5%를 샘플링합니다. 제가 언급한 84.6%의 벤치마크 점수는 매주 실행되는 내부 평가(eval) 스위트에서 나온 것입니다. 이러한 루프(loop)가 없다면, 당신은 눈을 감고 비행하는 것과 같습니다.

벤더 종속(Vendor Lock-In) 방지 보험 정책

이 부분으로 다시 돌아가고 싶은데, 이것이 바로 제가 밤에 편히 잠들 수 있는 이유이기 때문입니다. 우리의 전체 추론(inference) 레이어는 하나의 설정 문자열(config string)입니다. 만약 Global API가 내일 사라진다면, 저는 기본 URL을 OpenAI, Together, 또는 Groq로 바꾸고 모델 이름만 업데이트하면 됩니다. 총 마이그레이션 시간은 아마 90분 정도일 것입니다. 만약 다음 분기에 Qwen3-32B와 DeepSeek V4 Pro를 A/B 테스트하고 싶다면, 이는 10줄의 설정 변경과 24시간의 섀도 트래픽(shadow traffic) 실행만으로 가능합니다.

그것이 바로 '프로덕션 준비 완료(production-ready)'가 실제로 의미하는 바입니다.

우리는 GPT-4o 스택을 사용할 때보다 40-65% 적은 비용을 지불하고 있습니다. 품질은 향상되었고, 지연 시간 (Latency)은 줄었으며, 처리량 (Throughput)은 늘어났습니다. 그리고 특정 벤더 종속성 (vendor lock-in)이 전혀 없습니다. 84.6%의 벤치마크 점수와 초당 320 토큰의 처리량도 훌륭하지만, 진짜 승리는 선택권 (optionality)에 있습니다. 더 나은 모델이 출시되는 당일에 바로 이동할 수 있으며, 6주간의 마이그레이션 프로젝트 없이도 이를 수행할 수 있습니다.

만약 당신이 프로덕션 환경에서 RAG를 운영하는 CTO이고, OpenAI 청구서를 볼 때마다 움찔한다면, DeepSeek + ChromaDB + Global API 스택을 진지하게 고려해 보시기 바랍니다. 우리 팀은 초기 통합에 10분도 채 걸리지 않았으며, 그 이후로 계속해서 프롬프트 엔지니어링 (prompt engineering)과 검색 전략 (retrieval strategy)을 반복 개선해 오고 있습니다. 절감된 비용 덕분에 1분기에는 엔지니어 두 명을 추가로 채용할 수 있었습니다. 이것이야말로 이사회에 보고할 수 있는 실질적인 투자 대비 효과 (ROI)입니다.

184개의 서로 다른 벤더 계정에 가입하지 않고도 184개의 모든 모델을 테스트하고 싶다면 Global API를 확인해 볼 가치가 있습니다. 통합 엔드포인트 (unified endpoint)가 핵심입니다. 하나의 SDK, 하나의 인증 (auth), 하나의 청구서로 해결됩니다. 이것이 바로 RAG 인프라가 처음부터 작동했어야 하는 방식입니다.