DeepSeek RAG를 더 빨리 알았더라면 좋았을 텐데 — 상세 분석

자, 여러분께 드릴 말씀이 있습니다. 저는 부트캠프를 마친 후 첫 번째 "진짜" 프로젝트를 위해 지난 3주 동안 RAG (Retrieval-Augmented Generation, 검색 증강 생성) 시스템을 구축하는 데 시간을 보냈습니다. 그리고 진심으로 누군가가 처음부터 이 모든 것들을 저에게 앉혀놓고 설명해 주었더라면 좋았을 것이라고 생각합니다. 그러니까, 제가 무료 크레딧을 다 써버리고 정신력의 상당 부분을 소진하기 전 말이죠. 저는 실제 모델 선택이 얼마나 중요한지 전혀 몰랐고, 제가 얼마나 많은 돈을 낭비하고 있는지도 몰랐습니다. 이 포스트는 여러분이 저와 같은 실수를 반복하지 않도록 제가 배운 모든 것을 한곳에 쏟아붓는 것입니다.

잠시 뒤로 돌아가 보겠습니다. 코딩 부트캠프를 졸업했을 때, 저는 RAG (Retrieval-Augmented Generation) 파이프라인을 구축하는 것이 쉬운 부분일 것이라고 생각했습니다. 문서 몇 개를 가져와서, 청킹 (chunking)하고, 벡터 데이터베이스 (vector database)에 밀어 넣은 다음, 챗봇에게 질문을 던지면 되는 것이죠. 그게 얼마나 어렵겠어요, 그렇죠? 유명한 마지막 말이죠. 제 정신을 완전히 빼놓았던 것은, 그 파이프라인에서의 수많은 작은 결정들이 월말 청구서를 완전히 바꿔 놓을 수 있다는 점이었습니다. 올바른 모델을 선택하는 것과 잘못된 모델을 선택하는 것의 차이는 말 그대로 수천 달러가 될 수 있습니다. 그리고 저는 막 부트캠프를 졸업했고 제 은행 잔고는, 음, "겸손"하기 때문에, 그 부분이 개인적으로 뼈아프게 다가왔습니다.

제가 어떻게 이 주제에 발을 들이게 되었나

상황은 이렇습니다. 저는 작은 비영리 단체를 위해 작은 내부 Q&A 도구를 만들고 있었습니다. 그들은 거대한 정책 문서 폴더를 가지고 있었고, 팀원 중 누구도 그 문서들을 전부 읽고 싶어 하지 않았습니다. 전형적인 시나리오죠, 그렇죠? 그들은 평이한 영어 질문을 던지고 문서에서 답변을 추출하기를 원했습니다. 저는 "좋아, 이건 그냥 RAG야. 튜토리얼이 수백만 개는 있을 거야"라고 생각했습니다. 실제로 있습니다. 하지만 문제는 제가 온라인에서 찾은 모든 튜토리얼이 OpenAI를 직접 사용하거나 (괜찮지만 비쌉니다), 혹은 여러분이 이미 Kubernetes 클러스터를 가지고 있고 예산이 충분하다고 가정하는 설정 방식을 사용하고 있었다는 점입니다.

저는 그 중 어느 것도 가지고 있지 않았습니다. 제게 있었던 것이라고는 노트북 한 대, GitHub Student 계정, 그리고 제대로 작동하는 무언가를 반드시 출시해야 한다는 절박함뿐이었습니다. 시중에 나와 있는 수많은 AI 서비스들이 저와 같은 사람들을 위해 만들어지지 않았다는 사실에 충격을 받았습니다. 그때 Global API를 발견했습니다. 거짓말 안 하고, 그것이 제 프로젝트를 거의 구했습니다. 저를 즉시 사로잡은 점은 단 하나의 API 키로 호출할 수 있는 184개의 서로 다른 모델을 보유하고 있다는 것이었습니다. 184개라니요! 저는 그렇게 많은 AI 모델이 존재하는지도 몰랐습니다. 어떤 모델들은 100만 토큰당 비용이 단돈 0.01달러에 불과했습니다 (오타라고 생각해서 그 숫자를 세 번이나 다시 읽어야 했습니다). 반면 강력한 성능을 자랑하는 모델들은 100만 토큰당 3.50달러까지 올라갑니다. 이 가격 범위는 정말 엄청나며, 이는 단순히 Twitter에서 가장 화제가 되는 것이 아니라 여러분의 지갑 사정에 맞는 것을 실제로 선택할 수 있음을 의미합니다.

커피를 뿜게 만든 숫자들

제가 계속해서 다시 확인했던, 화이트보드에 휘갈겨 쓴 표를 보여드리겠습니다. 이것들은 제가 프로젝트를 위해 조사하면서 계속 마주쳤던 모델들이며, 모두 Global API를 통해 라우팅되었습니다:

모델 (Model)	입력 (Input, 1M 토큰당)	출력 (Output, 1M 토큰당)	컨텍스트 윈도우 (Context Window)
DeepSeek V4 Flash	$0.27	$1.10	128K
...

저는 이 표를 한참 동안 뚫어지게 쳐다보았습니다. GPT-4o를 보세요. 출력 100만 토큰당 10.00달러입니다. 이제 GLM-4 Plus를 보세요. 출력 100만 토큰당 0.80달러입니다. 이것은 작은 차이가 아닙니다. 이는 "자유롭게 실험할 수 있다"와 "API 호출 하나하나를 고민해야 한다" 사이의 차이입니다. 그리고 정말 놀라운 점은, 저의 비영리 목적의 사용 사례(use case)에서는 GLM-4 Plus로도 완전히 충분했다는 것입니다. 단순한 문서 Q&A(질의응답)에서의 품질 차이는 기본적으로 거의 없었습니다.

제가 배운 일반적인 경험칙이자, 현장에서 직접 발로 뛰는 사람들이 계속해서 반복하는 말은, DeepSeek V4 Flash와 벡터 스토어(Vector Store)로 Weaviate를 조합한 설정을 사용하는 것이 모든 것에 GPT-4o를 그냥 던져 넣는 것과 비교했을 때 약 40-65%를 절약해 준다는 것입니다. 65%라니요! 정말 충격적이었습니다. 저는 항상 저렴한 옵션은 느리고 멍청한 옵션일 것이라고 가정해 왔습니다. 이제는 더 이상 그렇지 않습니다. 제가 계속해서 보았던 벤치마크 점수들은 평균적으로 약 84.6%였는데, 솔직히 말해서 아주 적은 비용으로 제가 기대했던 것보다 더 나은 결과였습니다.

나의 첫 번째 RAG 설정 (그리고 내가 실수했던 점)

제가 최종적으로 완성한 실제 코드를 보여드리겠습니다. 코드를 직접 보는 것이 전체적인 과정을 덜 두렵게 만들어 줄 것이라고 생각하기 때문입니다. 솔직히 제 스크립트의 첫 번째 버전은 창피한 수준이었습니다. 캐싱(Caching), 스트리밍(Streaming), 폴백 로직(Fallback logic)도 없이 OpenAI를 직접 호출하고 있었습니다. 모든 질문은 API를 처음부터 새로 호출했고, 전체 비용을 다 지불했으며, 사용자에게 아무것도 보여주기 전에 전체 응답이 돌아올 때까지 기다려야 했습니다. 기술적으로는 작동했지만, 느리고 비쌌습니다.

여기에 제가 최종적으로 도달한, Global API를 통합 엔드포인트(Unified endpoint)로 사용하는 더 깔끔한 버전이 있습니다. 이 방식의 훌륭한 점은 base_url을 교체하는 것입니다. 기본적으로 https://global-apis.com/v1을 가리키기만 하면 바로 준비가 끝납니다.

import openai
import os

...

핵심 호출 부분은 기본적으로 이게 전부입니다. Global API에 가입하고, 키를 가져오고, 첫 번째 성공적인 응답을 받기까지의 전체 설정 과정은 10분도 채 걸리지 않았습니다. 과장이 아닙니다. 너무 놀라서 시간을 직접 재보았습니다. 부트캠프 졸업생으로서, 저는 오후 전체를 잡아먹고 결국 의존성 충돌(Dependency conflict)로 끝나는 설정 과정에 익숙합니다. 이것은 정반대였습니다.

"아, 그래서 이렇게 저렴한 거구나"라고 느낀 순간

기본적인 기능이 작동하기 시작하자, 저는 왜 비용이 이렇게 훨씬 더 저렴한지 파헤치기 시작했습니다. 처음에는 응답이 그냥 짧다거나 혹은 무언가 교묘한 수법이 있는 게 아닐까 생각했습니다. 하지만 그렇지 않았습니다. 그 이유는 사실 작고 영리한 결정들의 조합이었으며, 이를 이해하고 나니 왜 더 빨리 알지 못했는지 스스로가 바보처럼 느껴질 정도였습니다. 제 프로젝트를 진정으로 변화시킨 요소들은 다음과 같습니다:

1. 공격적으로 캐싱(Cache)하세요. 이것이 가장 핵심입니다. 저는 질문과 답변을 저장하는 간단한 캐시(처음에는 그냥 JSON 파일이었는데, 너무 비난하지 마세요)를 설정했습니다. 동일한 질문이 다시 들어오면 캐시된 답변을 반환합니다. 사람들이 반복해서 같은 질문을 하기 때문에, 특히 내부 Q&A 도구에서는 거의 즉시 40%의 히트율(hit rate)을 기록했습니다. 40퍼센트라니! 이는 모델 설정을 단 하나도 바꾸지 않고도 청구 금액에서 40% 할인을 받는 것과 같습니다.

2. 응답을 스트리밍(Stream)하세요. 스트리밍이 사용자 경험(UX)에 얼마나 큰 차이를 만드는지 전혀 몰랐습니다. 스트리밍을 하면 사용자는 전체 응답을 위해 1.2초를 기다리는 대신, 약 200ms 만에 첫 단어들을 보게 됩니다. 총 소요 시간이 대략 비슷하더라도 사용자는 빠르다고 느낍니다. 백엔드의 처리량(throughput)은 초당 약 320 토큰(tokens per second)으로, 거의 모든 내부 도구에 충분한 수준입니다.

3. 쉬운 작업에는 더 저렴한 모델을 사용하세요. 저는 단순하고 명확하게 정의된 쿼리(예: "휴가 정책이 무엇인가요?")는 더 작고 빠른 모델로 라우팅(routing)하고, 까다로운 다단계(multi-hop) 질문들만 더 큰 모델로 보내기 시작했습니다. Global API에는 이러한 단순 쿼리에 대해 비용을 약 50% 절감해 주는 "GA-Economy"라고 불리는 티어(tier)가 있습니다. 저는 이것이 조잡하게 느껴질 줄 알았습니다. 하지만 그렇지 않습니다. 답변은 95%의 경우 동일합니다.

4. 품질을 직접 추적하세요. 각 답변 옆에 작은 따봉(thumbs-up/thumbs-down) 버튼을 추가했습니다. 이것은 정말 금쪽같은 데이터입니다. 이것이 없으면 여러분은 그저 추측만 할 뿐입니다. 이것이 있으면 더 저렴한 모델로 교체한 것이 실제로 무언가를 해치고 있는지 확인할 수 있습니다. 저는 "저렴함"과 "나쁨"이 같은 것이 아니라는 점을 배웠지만, 반드시 검증은 해야 한다는 사실도 깨달았습니다.

대체 수단(Fallback)을 마련하세요. API도 컨디션이 안 좋은 날이 있습니다. 저는 속도 제한(Rate limit) 오류를 잡아내어 다른 모델로 재시도하는 try/except 구문을 추가했습니다. 이런 조치는 밤 11시에 "봇이 작동하지 않아요"라는 Slack 메시지를 받기 전까지는 과한 설정처럼 들릴 수 있습니다. 하지만 우아한 대체 수단(Graceful fallback)은 저를 여러 번 구해주었습니다.

Weaviate가 마법의 나머지 절반이었습니다

제목에서 언급했으니 Weaviate에 대해서도 잠시 이야기해야 할 것 같습니다. 건너뛰고 싶지 않거든요. Weaviate는 제가 선택한 벡터 데이터베이스 (Vector database)입니다. 다른 것들(Chroma, FAISS)도 몇 가지 시도해 보았고 모두 작동하지만, Weaviate는 마치 프로덕션 (Production) 환경을 위해 만들어진 것 같다는 느낌을 받았습니다. 제가 가장 좋았던 점은 그냥 바로 연결된다는 것입니다. 실행하고, 컬렉션 (Collection)을 생성하고, 임베딩 (Embeddings)과 함께 문서 청크 (Document chunks)를 밀어 넣은 다음, 쿼리 (Query)를 날리면 됩니다. 쿼리는 사용자가 질문한 내용과 의미론적으로 가장 유사한 청크들을 반환합니다. 그 청크들을 (위의 제 코드 예시처럼) 프롬프트 (Prompt)에 집어넣으면 모델이 그것을 바탕으로 답변합니다.

이 파이프라인의 단계가 바로 "R", "A", "G"가 일어나는 지점입니다. 검색 (Retrieval), 증강 (Augmentation), 생성 (Generation)입니다. LLM (Large Language Model)은 단지 마지막 단계일 뿐입니다. 검색 (Retrieval) 단계가 답변이 실제로 당신의 문서에 근거(Grounded)하고 있는지, 아니면 모델이 이야기를 지어내고 있는지를 결정합니다. 검색이 좋지 않다면, 아무리 비싼 모델을 써도 소용이 없습니다. 반대로 검색이 훌륭하다면, 저렴한 모델조차도 훌륭한 답변을 내놓습니다. 그것이 아마도 제가 프로젝트 전체를 통해 배운 가장 중요한 사실이었을 것입니다.

첫날 누군가 나에게 말해줬더라면 좋았을 것들

제가 직접 고생하며 배워야 했던 몇 가지 사항들이 더 있습니다. 이것들이 이런 서비스를 출시하려는 다른 부트캠프 졸업생이나 주니어 개발자들에게 도움이 될 것이라고 생각합니다:

• 청크 크기 (Chunk size)는 생각보다 중요합니다. 저는 처음에 너무 큰 청크로 시작했는데, 각 청크에 여러 아이디어가 포함되어 있어 모델이 계속 혼란을 겪었습니다. 더 작고 집중된 청크가 더 나은 답변을 만듭니다. 저는 청크당 약 500 토큰(tokens)에 약 50 토큰의 중첩(overlap)을 두었는데, 정책 문서(policy documents) 작업에 매우 효과적이었습니다.
• 임베딩 (Embeddings)에도 비용이 듭니다. 사람들은 이 점을 잊곤 합니다. 문서를 인제스트 (ingest)할 때, 임베딩 호출에 대한 비용을 지불하게 됩니다. 저는 호출을 하나씩 하는 대신 배치 (batch) 처리하여 인제스트 비용을 절반으로 줄였습니다. 아주 쉬운 승리입니다.
• 모델 이름을 모든 곳에 하드코딩 (hardcode)하지 마세요. 저는 이제 프로젝트 상단에 단일 MODEL_NAME 상수를 둡니다. 다른 모델을 테스트하고 싶을 때, 한 줄만 바꾸면 끝납니다. DeepSeek V4 Flash에서 DeepSeek V4 Pro, 그리고 Qwen3-32B로 전환하는 것은 리팩터링 (refactor)이 아니라 5초면 끝나는 실험입니다.
• 컨텍스트 윈도우 (Context window)는 당신의 친구입니다. DeepSeek V4 Pro는 200K 컨텍스트 윈도우를 가지고 있는데, 이는 엄청난 크기입니다. 즉, 공간이 부족할 걱정 없이 검색된 많은 청크를 프롬프트 (prompt)에 밀어 넣을 수 있다는 뜻입니다. 실제로 해보기 전까지는 이것이 얼마나 중요한지 몰랐습니다.
• 지연 시간 (Latency)은 평균 1.2초입니다. 제가 계속 확인한 수치입니다. 특히 스트리밍 (streaming)을 사용할 때는 실제로 매우 빠르게 느껴집니다. 이미 충분히 빠른 것을 최적화하려고 프론트엔드 (front end)를 과도하게 설계하지 마세요.

방금 이 작업을 마친 사람의 관점에서 본 큰 그림

부트캠프 졸업생으로서 이 글을 읽는 다른 분들에게 솔직한 요약을 말씀드리겠습니다. 2026년에 DeepSeek와 Weaviate를 사용한 RAG는, 제 생각에 지갑을 털리지 않으면서도 실제 프로덕션 품질 (production-quality)의 결과가 필요한 사람에게 가장 실용적인 설정입니다. 비용은 제가 시도했던 다른 대안들보다 40~65% 더 저렴합니다. 속도는 초당 320 토큰의 처리량 (throughput)과 평균 1.2초의 지연 시간으로 안정적입니다. 품질은 제가 중요하게 생각하는 벤치마크 (benchmarks)에서 약 84.6%를 기록했습니다. 그리고 Global API의 통합 SDK (unified SDK)를 사용하면 이 모든 과정을 10분 이내에 구축할 수 있습니다.

저에게 가장 큰 "전혀 몰랐던" 순간은 적절한 모델을 선택하는 것이 여러분이 직접 조절할 수 있는 레버(lever)라는 사실을 깨달았을 때였습니다. 그것은 화려한 아키텍처 다이어그램(architecture diagram)에서 내리는 어떤 영구적인 결정이 아닙니다. 모델을 교체하고, 난이도에 따라 라우팅(routing)하며, 공격적으로 캐싱(caching)하고, 실제 사용자 피드백을 기반으로 전체 시스템을 튜닝(tuning)할 수 있습니다. 이 중 그 어떤 것도 더 이상 이론에 그치지 않습니다. 제가 직접 해냈습니다. 제 비영리 고객은 만족하고 있고, 비용은 아주 적게 나오며, 봇은 지난 2주 동안 단 한 번도 다운되지 않았습니다.

만약 이 내용 중 공감되는 부분이 있거나, 첫 RAG 시스템을 구축하려는 단계에서 합리적인 시작점을 찾고 있다면, 저는 진심으로 Global API를 살펴보라고 추천하고 싶습니다. 그들은