모든 RAG(Retrieval-Augmented Generation) 튜토리얼은 똑같은 방식을 취합니다. 임베딩(embeddings), 청킹(chunking), 검색(retrieval) 과정을 안내하다가, 막상 결정적인 순간이 되면 "이제 벡터 데이터베이스를 선택하세요"라고 말하며 그냥... 넘어가 버립니다. 마치 커피를 주문하는 결정이나 폰트를 고르는 것처럼 말이죠.

하지만 그렇지 않습니다. 당신이 선택한 데이터베이스는 쿼리(query)가 얼마나 빨리 반환될지, 인프라 비용이 얼마나 많이 발생할지, 그리고 트래픽이 3배로 늘어나는 날 당신의 삶이 얼마나 비참해질지를 결정합니다. 그리고 제가 이 주제를 조사하면서 깨닫는 데 시간이 좀 걸렸던 사실이 하나 있습니다. 처음에 시작한 데이터베이스가 실제 서비스(ship) 단계에서 사용하는 데이터베이스가 아닌 경우가 많다는 점입니다. 팀들은 마이그레이션(migration)을 하며, 때로는 한 번 이상 수행하기도 합니다. 어떤 이동은 깔끔한 승리가 되지만, 어떤 이동은 몇 주간의 고통과 사후 분석(postmortem) 문서로 남게 됩니다.

그러니 후회를 피하도록 해봅시다. 저는 벤치마크(benchmarks), 실제 운영 사례(production write-ups), 그리고 사람들이 사후에야 비로소 깨닫게 되는 트레이드오프(trade-offs)를 파헤치는 데 긴 시간을 보냈습니다. 이것은 제가 처음 시작했을 때 가졌더라면 좋았을 가이드입니다. 이 다섯 가지(pgvector, Pinecone, Qdrant, Weaviate, Milvus)가 각각 실제로 무엇을 잘하는지, 어디서 조용히 무너지는지, 그리고 기능 매트릭스(feature matrix)에 빠져 허우적거리지 않고 어떻게 선택할 수 있는지에 대한 내용입니다.

결론을 미리 말씀드리자면, 이것이 여기서 가장 유용한 정보이기 때문입니다: 방금 읽은 벤치마크가 아니라, 이미 운영 중인 인프라를 기반으로 선택하세요. 만약 이미 Postgres를 사용 중이라면, 정답은 아마도 pgvector일 것이며 거의 읽기를 멈춰도 좋습니다. 만약 다시는 인프라를 만지고 싶지 않다면, Pinecone입니다. 그 이후의 모든 것은 미세 조정(fine-tuning)의 영역입니다.

성격 급한 분들을 위한 치트 시트(cheat sheet)

첫째, 벤치마크만 쳐다보는 것을 멈추세요

그 유혹을 이해합니다. 만족스러운 작은 막대 그래프와 함께 벤치마크(benchmarks)가 눈앞에 있고, 한 데이터베이스가 다른 데이터베이스보다 3ms 더 빠르다는 수치는 마치 결정적인 근거처럼 느껴집니다. 하지만 실제로는 그렇지 않은 경우가 대부분입니다. 거의 모든 사람이 실제로 운영하는 규모에서는 이 목록에 있는 모든 데이터베이스가 충분히 빠르기 때문에, 사용자는 그 차이를 전혀 느끼지 못할 것입니다. 지연 시간(latency) 전쟁은 주로 여러분에게 아직 존재하지 않는 워크로드(workloads)를 두고 벌어지는 싸움입니다.

실제로 결정을 내리는 요소는 대략 다음과 같은 순서의 네 가지 지루한 질문들입니다.

이미 무엇을 운영하고 있습니까? 만약 Postgres가 이미 여러분의 스택(stack)에서 잘 돌아가고 있다면 (그리고 여러분이 풀스택 개발자라면 아마 그럴 것입니다), 두 번째 데이터베이스를 추가한다는 것은 동기화 계층(sync layer), 별도의 백업, 그리고 새벽 3시에 여러분을 깨울 수 있는 완전히 새로운 무언가를 의미합니다. 그러한 중력은 실재하며, 대개 승리합니다.

인프라를 직접 운영하고 싶습니까? 어떤 사람들은 운영(ops)에서 만족감을 느낍니다. 어떤 사람들은 또 다른 클러스터(cluster)를 설정하느니 차라리 돈을 불태우는 게 낫다고 생각합니다. 둘 다 타당합니다. 자신이 어느 쪽인지 솔직해지세요.

실제로 규모가 얼마나 커질까요? 벡터(vectors)가 1,000만 개 미만이라면 진심으로 무엇이든 작동합니다. 1,000만 개에서 10억 개 사이라면 선택지가 빠르게 줄어듭니다. 10억 개를 넘어가면 실제 선택할 수 있는 옵션은 아마 두 개 정도일 것입니다.

하이브리드 검색(hybrid search)이 필요합니까? 이 질문은 사람들에게 은근슬쩍 다가옵니다. 순수 시맨틱 검색(semantic search)은 훌륭하지만, 사용자가 정확한 제품 ID나 버전 번호를 입력했을 때 여러분의 "느낌 기반(vibes-based)" 검색이 어리둥절해하며 답을 내놓지 못하는 상황이 발생할 수 있습니다. 이에 대해서는 나중에 더 자세히 다루겠지만, 일단 기억해 두세요.

이 네 가지 질문에 솔직하게 답하면 데이터베이스는 기본적으로 스스로 결정됩니다. 각 데이터베이스를 이 관점에서 살펴보겠습니다.

pgvector: 정답에 가까울 정도로 지루한 해답

pgvector는 데이터베이스가 아닙니다. 그것은 Postgres 확장 기능(extension)입니다. 여러분이 이미 가지고 있는 데이터베이스에 벡터 검색(vector search)을 수행하는 방법을 가르치는 것, 그것이 전부입니다. 새로운 서비스도 필요 없고, 동기화 계층도 필요 없으며, 급하게 프로비저닝(provisioned)하고 제대로 이해하지도 못한 시스템으로부터 새벽 2시에 호출을 받을 일도 없습니다.

왜 이것이 종종 정답이 되는가. 당신의 벡터가 실제 데이터 바로 옆에 위치하므로, 단일 트랜잭션(transaction) 내에서 두 가지 모두를 쿼리할 수 있고, 기존 백업이 이미 벡터를 포함하고 있으며, 필터링은 단순히 SQL의 WHERE 절을 사용하는 것과 같습니다: 조인(join), 서브쿼리(subquery) 등 모든 것이 가능합니다. "Postgres는 벡터를 처리하기에 너무 느리다"라는 오래된 불만은 진정으로 시대에 뒤떨어진 것입니다. 이는 IVFFlat 방식이 주를 이루던 좋지 않았던 과거 시절의 이야기입니다. HNSW 인덱싱(indexing)이 도입된 이후, pgvector는 백만 개의 벡터 규모에서 전용 데이터베이스들과 대등한 성능을 보여주기 시작했으며, pgvectorscale 확장을 사용하면 수천만 개의 벡터에 대해 99% 재현율(recall)을 유지하면서도 경쟁력 있는 처리량(throughput)을 기록하며 그 이상의 규모에서도 충분히 제 역할을 해냅니다. 수많은 RAG 프로젝트들에게 이것은 정답이며, 유일한 단점이라면 별로 흥미롭지 않다는 점뿐입니다.

한계가 드러나는 지점. 단일 서버에서 벡터가 수백만 개를 넘어가기 시작하면 인덱스 구축에 20분 이상이 소요되기 시작하며, Postgres의 VACUUM 프로세스가 쿼리 자원을 가로채기 시작합니다. 또한 더 미묘한 함정도 있습니다: pgvector는 검색을 수행한 후에 필터링을 합니다. 따라서 대규모 컬렉션에서 까다로운 필터 조건을 적용하면, 소수의 결과값을 돌려주기 위해 방대한 후보군을 스캔해야 함을 의미합니다. 벡터가 약 5,000만~1억 개 정도에 도달하면 읽기 복제본(read replicas), 파티셔닝(partitioning)을 고려하거나, 혹은 포기해야 할 시점이 올 것입니다.

이럴 때 사용하세요: Postgres를 사용 중이고, 벡터 수가 약 5,000만 개 미만이며, 지연 시간(latency) 경쟁에서 반드시 이겨야 하는 상황이 아닐 때. 대부분의 팀이 정확히 이 조건에 해당하며, 스스로 인지하지 못하고 있습니다.

Pinecone: 돈을 지불하고 문제를 없애버리세요

Pinecone은 기본적으로 관리형 벡터 데이터베이스(managed-vector-database) 카테고리를 발명했으며, 여전히 그 기준을 제시하고 있습니다. API 키를 받고, 인덱스를 만들고, 벡터를 던져 넣고, 다시 쿼리하면 됩니다. 크기를 산정할 필요도, 튜닝할 필요도, 유지 관리할 필요도 없습니다. 이것은 단순한 기능 목록이 아닙니다. 이것이 제품의 핵심 가치(pitch)이며, 진정으로 훌륭한 가치입니다.

사람들이 이를 좋아하는 이유. "벡터 데이터베이스가 필요하지만, 더 이상 이에 대해 고민하고 싶지 않다"는 것은 완전히 정당한 입장이며, Pinecone은 바로 그런 사람을 위해 구축되었습니다. 수십억 개의 벡터로 확장 가능하며, 하이브리드 검색 (hybrid search)을 수행하고, 엔터프라이즈 컴플라이언스 (enterprise compliance) 요건들을 갖추고 있습니다. 운영상의 모든 골칫거리를 이를 유지하는 것이 유일한 업무인 누군가에게 떠넘길 수 있습니다.

함정 (그리고 실제적인 함정이 있습니다). 이것은 폐쇄형 소스 (closed-source)이며, 셀프 호스팅 (self-hosting)이 불가능합니다. 끝입니다. 당신의 데이터는 그들의 클라우드에 존재하며, 만약 그들의 가격 정책이 바뀌거나 그들에게 문제가 생기면 당신에게는 플랜 B가 없습니다. 서버리스 (serverless) 계층은 편의성을 위해 지연 시간 (latency)을 희생하며, 조절할 수 있는 노브(knob) 없이 재현율 (recall)을 약 90% 수준으로 고정합니다. Pinecone은 HNSW 내부 구조를 건드릴 수 없게 합니다. 쓰기 작업은 최종 일관성 (eventual consistency)을 따르므로, 새로 추가된 벡터가 나타나기까지 약간의 시간이 걸립니다. 필터링은 SQL보다 약하며 (조인(join)이나 서브쿼리(subquery) 불가), 따라서 복잡한 작업은 다시 애플리케이션 코드로 넘어가게 됩니다. 그리고 비용은 당신과 함께 성장하며, 때로는 당신이 원하는 것보다 더 빠르게 증가합니다.

이런 경우에 사용하세요: 튜닝 제어권보다 인프라를 운영하지 않는 것이 더 중요하며, 다시는 이 문제를 고민하지 않는 대가로 벤더 종속 (lock-in)을 받아들이기로 했다면 사용하세요.

Qdrant: 빠르며, 스스로도 그 사실을 알고 있는 모델

Qdrant는 오픈 소스 (open-source)이며, Rust로 작성되었고, 첫날부터 벡터 검색만을 수행하기 위해 구축되었습니다. 그 집중력이 결과로 나타납니다.

매력적인 이유. 오픈 소스 패키지 중 속도 리더이며, p50 지연 시간(latency)이 가장 낮습니다. 게다가 실제로 가장 중요한 부하가 걸리는 무거운 쿼리 부하에서 그 격차가 벌어집니다. 하지만 진정한 트릭은 필터링된 검색입니다. Qdrant는 필터를 나중에 붙이는 방식이 아니라, 검색 순회 과정 내부에서 필터를 실행합니다. 따라서 pgvector를 힘들게 만드는

강점. 두 가지 이유가 있습니다. 첫째, 대부분의 분야가 뒤늦게 따라오기 훨씬 전인 2022년 말에 이미 출시된 하이브리드 검색 (Hybrid Search) 기능입니다. Weaviate의 구현 방식은 진정으로 성숙해 있으며 (벡터 결과와 제대로 융합된 키워드 점수 산정), 만약 의미론적 검색 (Semantic Retrieval)과 정확한 일치 검색 (Exact-match Retrieval)의 결합이 제품의 핵심이라면, 이것은 현재 시장에서 가장 완성도 높은 네이티브 옵션입니다. 둘째, Weaviate는 임베딩 (Embedding) 작업을 대신 수행해 줍니다. 원문 텍스트를 보내기만 하면, Weaviate가 OpenAI, Cohere, Hugging Face 등 무엇이든 사용하여 입력 과정에서 이를 벡터화합니다. 파이프라인 내의 가동 요소(moving parts)가 줄어들며, 이는 실제 개발 편의성 측면에서 큰 이점입니다.

부담스러운 점. 이러한 내장 벡터화 기능은 무료가 아닙니다. 사용자가 직접 호출하는 것과 동일한 임베딩 API를 호출하므로, 단지 눈에 덜 띌 뿐 지연 시간 (Latency)과 비용은 그대로 지불하게 됩니다. 만약 당신의 사고방식이 SQL이나 일반적인 REST 방식에 맞춰져 있다면, GraphQL API는 확실히 학습 곡선이 존재합니다. 또한, 직접 호스팅 (Self-host)할 경우 Java 런타임 (Runtime)의 자원 소모가 큽니다. 모듈과 멀티테넌시 (Multi-tenancy)를 추가할수록 운영 복잡성도 함께 증가합니다.

이럴 때 사용하세요: 네이티브 하이브리드 검색이 필수 요구 사항이거나, 파이프라인의 고장 요소를 줄이기 위해 데이터베이스가 벡터화를 직접 처리하기를 진심으로 원하는 경우.

Milvus: 규모가 엄청나게 커질 때 꺼내 드는 카드

Milvus는 GitHub에서 가장 많은 별(Star)을 받은 오픈 소스 옵션이며, Zilliz(관리형 서비스인 Zilliz Cloud는 업그레이드된 엔터프라이즈 버전임)의 지원을 받습니다. 이 도구는 단 하나의 이유, 즉 다른 모든 것들이 무너져 내릴 정도의 규모 확장을 위해 존재합니다.

강점. 진정으로 거대한 규모가 되었을 때, 이 도구의 분산 아키텍처 (Distributed Architecture)를 따라올 수 있는 것은 여기 없습니다. 10억 개 이상의 벡터를 다뤄야 합니까? GPU 가속 인덱싱 (GPU-accelerated Indexing)이 필요합니까? Milvus는 바로 그 순간을 위해 만들어진 도구입니다. 1억 개 이상의 범위에서도 Milvus는 확실히 강력한 후보입니다.

왜 함부로 선택해서는 안 되는가. 이것은 매우 거대한 기계입니다. 일반적인 사용 사례(use cases)에서는 운영 복잡성(operational complexity)이 Qdrant보다 훨씬 높습니다. Kubernetes를 다루는 데 필요한 실제 엔지니어링 시간을 예산에 반영해야 하며, 팀이 학습 곡선(learning curve)을 넘어야 한다는 점을 예상해야 합니다. 또한 RAG 파이프라인에서 문제를 일으킬 수 있는 출력 필드(output fields)와 관련된 알려진 성능 함정(performance gotcha)도 있습니다. 만약 벡터 수가 수천만 개 미만이라면, Milvus는 거의 확실히 귀하의 문제 규모에 비해 과도한 데이터베이스입니다.

이럴 때 사용하세요: 진정으로 1억~10억 개 이상의 영역으로 진입하거나 분산 GPU 인덱싱(distributed GPU indexing)이 필요하며, 이를 운영할 수 있는 운영 역량(ops capacity)을 갖춘 경우.

제가 생략한 것들에 대한 짧은 언급

ChromaDB는 가치 있는 언급을 할 만합니다. 설정 없이 Python 프로세스 내부에서 바로 실행되며 프로토타이핑(prototyping)에 매우 즐거운 도구입니다. 다만 'Big 5'가 제공하는 프로덕션 도구(고가용성(high availability), 스냅샷(snapshots), 실제 모니터링)를 제공하지 않으므로, 머무르는 곳이 아닌 시작하는 곳으로 생각하십시오. Faiss (데이터베이스가 아닌 라이브러리), LanceDB (멀티모달 우선), Vespa, 그리고 Vertex Vector와 같은 클라우드 네이티브 관리형 옵션들이 더 넓은 분야를 구성하지만, 실제로 프로덕션 Slack 채널에서 사람들이 논쟁하는 것은 위의 다섯 가지입니다.

제가 계속 설명하겠다고 약속했던 하이브리드 검색(hybrid-search)에 대하여

여기 그 내용이 있습니다. 왜냐하면 이것이 사람들이 예상하는 것보다 더 많은 선택을 조용히 결정하기 때문입니다. 순수 벡터 검색(pure vector search)은 누군가가 정확한 SKU, 사람의 이름, 또는 "v2.3.1"을 검색하기 전까지는 아주 훌륭합니다. 하지만 갑자기 귀하의 아름다운 의미론적 임베딩(semantic embeddings)이 주제적으로는 인접하지만 쓸모없는 결과를 반환하게 됩니다. 실제 시스템에는 동일한 쿼리 내에서 퍼지한 의미론적 일치(fuzzy semantic match)와 정확한 키워드 히트(exact keyword hit)가 모두 필요합니다.

Weaviate와 Qdrant는 이를 네이티브(natively)로 제공합니다. Pinecone은 이를 나중에 덧붙였습니다(bolted it on). pgvector는 직접 수동으로 조립하게 만듭니다. 만약 진정으로 다양한 콘텐츠를 대상으로 에이전트 메모리(agent memory)나 RAG를 구축하고 있다면, 하이브리드 검색을 타협할 수 없는 요소로 취급하고 이것이 귀하의 결정에 영향을 미치도록 하십시오. 이것은 더 이상 있으면 좋은 기능(nice-to-have)이 아닙니다. 차별화 요소인 척 트렌치코트를 입고 있는, 기본 요건(table stakes)입니다.

그래서, 실제로 무엇을 선택해야 할까요?

이 모든 내용에서 한 가지만 기억한다면:

Postgres를 사용 중이고 벡터 수가 약 5,000만 개 미만인가요? pgvector를 사용하고 바로 무언가를 만드세요. 조사는 그만하세요.

설정 파일(config file)을 절대 보고 싶지 않으신가요? Pinecone을 선택하고 벤더 종속(lock-in)을 받아들이세요.

자체 호스팅(Self-hosting)을 하며 속도나 필터링(filtering)이 중요한가요? Qdrant입니다.

하이브리드 검색(Hybrid search)이 제품의 핵심인가요? Weaviate입니다.

수억 개의 벡터를 마주하고 계신가요? Milvus입니다.