2026년에 RAG (Retrieval-Augmented Generation) 시스템을 구축하는 모든 팀은 동일한 결정 트리(decision tree)에 직면합니다. 벡터 저장소(vector store)가 필요합니다. 비교 가이드들을 열어봅니다. Pinecone은 자신이 가장 빠르다고 말합니다. Milvus는 수십억 건까지 확장 가능하다고 말합니다. pgvector는 이미 PostgreSQL을 가지고 있다고 말합니다. Neo4j는 관계(relationships)가 중요하다고 말합니다. FAISS는 아무 말도 하지 않는데, 이는 스스로를 어떤 주장도 하지 않는 라이브러리(library)로 정의하기 때문입니다.

그들 중 틀린 것은 없습니다. 하지만 모두 불완전한 답변입니다.

올바른 벡터 저장소는 단 한 가지, 오직 한 가지에 의해 결정됩니다. 바로 사용자가 실제로 던지는 쿼리(query)의 형태입니다. 현재의 쿼리 분포가 아니라, 아직 좋은 답변을 작성하지 못한 어려운 쿼리들을 포함한 전체 쿼리 분포가 기준이 되어야 합니다.

이 글은 각 옵션이 실제로 무엇을 하는지, 각 옵션이 진정으로 승리하는 지점은 어디인지, 그리고 결정적으로 왜 Neo4j가 이 목록에 있는 다른 모든 옵션과 근본적으로 다른 아키텍처적 위치를 차지하는지에 대한 완전한 가이드입니다.

목차

1. 모든 벡터 데이터베이스가 실제로 수행하는 작업
2. FAISS: 모든 것의 시작이 된 라이브러리
3. pgvector: PostgreSQL 확장 기능
4. MongoDB Atlas Vector Search: 문서 데이터베이스(Document Database) 접근 방식
5. Milvus: 수십억 규모를 위해 특화 설계됨
6. Pinecone: 완전 관리형 표준
7. Neo4j: 근본적으로 다른 옵션
8. 신뢰할 수 있는 벤치마크 수치
9. 쿼리 형태 결정 프레임워크
10. 프로덕션에서 사용하는 하이브리드 패턴
11. 결정 매트릭스

1. 모든 벡터 데이터베이스가 실제로 수행하는 작업

옵션들을 비교하기 전에 메커니즘을 명확히 해야 합니다. 왜냐하면 많은 비교가 서로 다른 시스템이 무엇에 최적화되어 있는지를 혼동하기 때문입니다.

모든 벡터 데이터베이스는 핵심적으로 한 가지 일을 합니다. 쿼리 벡터(query vector)가 주어지면, 코사인 유사도(cosine similarity), 내적(dot product), 또는 유클리드 거리(Euclidean distance)와 같은 거리 측정 지표(distance metric)를 통해 그와 가장 가까운 저장된 벡터들을 찾는 것입니다. 벡터는 의미를 나타냅니다. 벡터 공간에서의 근접성은 의미론적 유사성(semantic similarity)을 의미합니다. 이것이 시맨틱 검색(semantic search)을 가능하게 합니다. 즉, 사용자의 질문을 임베딩(embed)하고, 해당 임베딩과 가장 가까운 저장된 청크(chunks)를 검색하여 모델에 전달하는 것입니다.

시스템 간의 차이점은 무엇을 계산하느냐가 아니라, 대규모 환경에서 얼마나 효율적으로 계산하는지, 벡터와 함께 어떤 추가 데이터를 저장하는지, 순수 유사도(similarity) 외에 어떤 쿼리 패턴을 지원하는지, 그리고 어떤 운영 모델(operational model)을 요구하는지에 있습니다.

FAISS는 라이브러리(library)입니다. 영속성(persistence), 메타데이터(metadata), 서빙 인프라(serving infrastructure) 없이 메모리 내에서 계산을 수행합니다. 이 목록에 있는 다른 모든 옵션은 데이터베이스(database)입니다. 즉, 영속성, API 서빙, 메타데이터 필터링 및 운영 관리 기능을 추가합니다. pgvector, MongoDB, Neo4j는 기존 데이터베이스에 추가된 벡터 기능(vector capabilities)입니다. Milvus와 Pinecone은 벡터 워크로드(vector workloads)를 위해 특별히 구축된 데이터베이스입니다.

Neo4j는 벡터 검색을 네이티브 속성 그래프(native property graph)와 결합하는 유일한 옵션으로, 특정 쿼리 유형에 있어 매우 중요한 방식으로 다른 모든 것과 아키텍처적으로 구별됩니다.

2. FAISS: 모든 것의 시작이 된 라이브러리

Facebook AI Research Similarity Search는 2017년에 출시되었으며, 근사 최근접 이웃(ANN, approximate nearest neighbor) 검색의 참조 구현(reference implementation)으로 남아 있습니다. 위에서 언급한 많은 데이터베이스가 핵심적인 ANN 계산을 위해 내부적으로 사용하는 것이 바로 이것입니다.

FAISS는 데이터베이스가 아닙니다. 영속성, API 서버, 메타데이터 저장소, 액세스 제어(access control), 멀티 테넌시(multi-tenancy) 기능이 없습니다. 이는 Python 바인딩(bindings)을 갖춘 고도로 최적화된 C++ 라이브러리로, 매우 빠른 인메모리(in-memory) 유사도 검색을 수행합니다.

GPU 가속을 통한 순수 벡터 검색 속도 측면에서, FAISS는 순수 유사도 검색 벤치마크에서 Milvus를 포함한 전체 벡터 데이터베이스보다 성능이 뛰어납니다. 데이터베이스의 모든 오버헤드(overhead)를 제거하면 계산 속도가 더 빨라지기 때문입니다.

FAISS가 유리한 경우: 연구 환경, 오프라인 배치 처리(offline batch processing), 주변 인프라를 모두 직접 제어하는 커스텀 애플리케이션에 이 기능을 임베딩(embedding)하는 경우, 그리고 데이터베이스 오버헤드를 추가하기 전에 ANN 계산의 한계치가 어느 정도인지 파악하기 위한 벤치마킹 시 유용합니다.

FAISS가 실패하는 지점: 재시작 시에도 지속되는 영속성(persistence), 메타데이터 필터링(metadata filtering), 동시 액세스(concurrent access), 벡터 인덱스 업데이트, 또는 모니터링이 필요한 모든 프로덕션 애플리케이션입니다. 프로덕션 환경에서 FAISS를 사용한다는 것은 이 모든 기능을 직접 구축해야 함을 의미합니다. 한 번 이런 일을 겪은 팀은 두 번 다시 반복하지 않습니다.

솔직한 결론: 당신이 연구자이거나 FAISS를 감싸는 인프라를 구축하고 있다면 FAISS는 올바른 선택입니다. 하지만 애플리케이션을 구축 중이며 몇 달이 아닌 몇 주 안에 운영을 시작하고 싶다면 잘못된 선택입니다.

3. pgvector: PostgreSQL 확장 기능

pgvector는 PostgreSQL에 벡터 저장 및 ANN 검색 기능을 추가합니다. 일반적인 관계형 데이터와 함께 벡터를 하나의 컬럼 타입으로 저장합니다. SQL을 사용하여 쿼리할 수 있으며, 관계형 조인(join)과 동일한 트랜잭션 내에서 벡터 검색 결과를 얻을 수 있습니다.

이것이 pgvector의 진정하고 중대한 장점입니다. 별도의 인프라 구성 요소를 제거할 수 있다는 점입니다. 제품 데이터, 사용자 데이터, 문서 메타데이터, 그리고 임베딩(embeddings)이 모두 하나의 데이터베이스에 존재합니다. 사용자 권한, 문서 날짜, 그리고 의미론적 유사성(semantic similarity)에 따라 필터링해야 하는 쿼리는 벡터 데이터베이스와 관계형 데이터베이스 사이의 왕복(round trip) 없이 단 하나의 SQL 문으로 실행됩니다.

pgvector 위에 구축된 Timescale의 확장 기능인 pgvectorscale은 5,000만 개의 벡터에 대해 99% 재현율(recall)에서 초당 471개의 쿼리를 달성합니다. 이는 진지한 프로덕션 수치입니다. 5,000만에서 1억 개 미만의 벡터를 사용하는 대부분의 애플리케이션에서 pgvectorscale을 결합한 pgvector는 충분히 실행 가능한 프로덕션 선택지입니다.

한계점은 운영상의 문제가 아니라 아키텍처의 문제입니다. PostgreSQL의 쿼리 플래너(query planner)는 ANN 검색을 위해 설계되지 않았습니다. 벡터 수가 수억 개를 넘어가면, 전용 벡터 데이터베이스에 구축된 목적 특화형 ANN 인덱스가 재현율(recall)과 처리량(throughput) 측면에서 pgvector보다 뛰어난 성능을 보입니다. 작은 규모에서 pgvector를 매력적으로 만드는 운영상의 단순함이 규모가 커지면 병목 현상이 됩니다.

pgvector가 승리하는 경우: 이미 PostgreSQL을 사용 중인 애플리케이션, 5,000만 개 미만의 벡터를 사용하는 RAG (Retrieval-Augmented Generation) 시스템, 단일 쿼리 내에서 벡터 결과와 관계형 데이터(relational data)를 JOIN할 수 있는 능력이 아키텍처 측면에서 중요한 모든 유스케이스, 그리고 최대 이론적 처리량(throughput)보다 운영상의 단순함을 올바르게 우선시하는 팀.

pgvector가 실패하는 경우: 1억 개 이상의 벡터 수, 관계형 데이터베이스와 독립적으로 벡터 인덱스의 수평적 확장(horizontal scaling)이 필요한 애플리케이션, 그리고 벡터 검색이 광범위한 관계형 애플리케이션 내의 하나의 기능이 아니라 주요 쿼리 패턴인 워크로드.

솔직한 결론: 수백만 개 미만의 벡터를 사용하는 대부분의 RAG 워크로드의 경우, 본인의 Postgres 내에 있는 pgvector가 가장 강력한 선택입니다. 임베딩(embeddings), 문서, 메타데이터가 SQL JOIN으로 쿼리할 수 있는 하나의 데이터베이스에 함께 존재하기 때문입니다. 규모의 한계는 실재하지만, 대부분의 애플리케이션은 그 수준에 도달하지 않습니다.

4. MongoDB Atlas Vector Search: 문서 데이터베이스 접근 방식

MongoDB Atlas Vector Search는 MongoDB의 문서 모델(document model)에 벡터 인덱싱과 ANN (Approximate Nearest Neighbor) 검색을 추가합니다. pgvector와 마찬가지로, 핵심 가치는 공동 배치(co-location)에 있습니다. 즉, 문서 데이터와 임베딩이 동일한 데이터베이스에 거주하며 함께 쿼리할 수 있습니다.

MongoDB의 문서 모델은 특정 데이터 형태에 있어 pgvector의 관계형 모델보다 진정한 이점을 가집니다. 중첩된 구조(nested structure), 배열(arrays), 가변 스키마(variable schema)를 가진 JSON 문서는 MongoDB에서 자연스럽게 처리되지만, PostgreSQL에서는 스키마 조작(schema gymnastics)이 필요합니다. 콘텐츠 관리 시스템(CMS), 제품 카탈로그, 고객 프로필과 같이 문서 데이터로 구축된 애플리케이션의 경우, MongoDB에서 문서와 함께 임베딩을 저장하는 것이 PostgreSQL보다 아키텍처적으로 더 깔끔합니다.

Atlas Vector Search 구현체는 HNSW (Hierarchical Navigable Small World) 인덱싱, 근사 최근접 이웃 (ANN) 검색, 그리고 벡터 유사성과 MongoDB의 기존 쿼리 연산자를 결합한 하이브리드 검색(hybrid search)을 지원합니다. 벡터 검색과 동시에 문서의 어떤 필드로도 필터링할 수 있습니다.

MongoDB가 승리하는 지점: 이미 MongoDB를 사용 중인 애플리케이션, 유연한 스키마 (flexible schema)가 진정으로 가치 있는 문서 중심 (document-heavy) 유스케이스, 그리고 벡터 검색을 별도의 서비스가 아닌 기존 문서 데이터베이스의 통합 기능으로 사용하고자 하는 팀.

MongoDB가 실패하는 지점: 문서 모델 (document model)의 이점을 얻지 못하는 순수 벡터 워크로드 (pure vector workloads), 수십억 규모 (billion-scale)에서 최대의 ANN 성능을 요구하는 애플리케이션, 그리고 문서 모델의 이점으로 Atlas의 운영 오버헤드 (operational overhead)를 정당화할 수 없는 유스케이스.

솔직한 결론: MongoDB Atlas Vector Search는 이미 MongoDB를 운영 중이며 새로운 인프라 구축 없이 시맨틱 검색 (semantic search)을 추가하고 싶은 경우에 적합한 선택입니다. 하지만 MongoDB를 사용하고 있지 않거나, 문서 모델의 컨텍스트 없이 순수 벡터 유사도 (vector similarity)가 주요 워크로드라면 적절한 선택이 아닙니다.

5. Milvus: 수십억 규모를 위해 특화 설계됨

Milvus는 확장성 (scale)을 위해 처음부터 구축된 오픈 소스 (open-source) 벡터 데이터베이스입니다. pgvector가 관계형 데이터베이스 (relational database)에 벡터 기능을 추가하는 방식이라면, Milvus는 방대한 양의 임베딩 (embeddings)을 낮은 지연 시간 (low latency)으로 저장, 인덱싱 및 쿼리하기 위해 특별히 구축되었습니다.

Milvus는 다양한 인덱스 (index) 유형을 지원합니다. 지연 시간에 최적화된 워크로드를 위한 HNSW, 메모리가 제한된 환경을 위한 IVF, RAM이 부족할 때 SSD 친화적인 스토리지를 위한 DiskANN, 그리고 GPU 가속 워크로드를 위한 SCANN이 있습니다. 이러한 인덱스 유형의 유연성은 HNSW만을 지원하는 시스템들에 비해 Milvus가 가진 주요 기술적 강점입니다.

수십억 규모의 벡터 개수에서 Milvus는 가장 강력한 오픈 소스 옵션으로 남아 있습니다. Milvus는 수평적 확장 (horizontal scaling)을 위해 설계되어, 노드를 추가하면 처리량 (throughput)이 비례하여 확장됩니다. 다만 운영 복잡성 (operational complexity)은 실재합니다. Milvus는 조율을 위한 etcd, 스토리지를 위한 MinIO, 그리고 Milvus 서버 자체를 포함한 여러 구성 요소를 필요로 합니다. 이는 pgvector나 Pinecone보다 더 많은 인프라를 요구합니다.

Zilliz Cloud는 운영 오버헤드 없이 수십억 규모의 성능을 원하는 팀을 위한 Milvus의 관리형 (managed) 버전입니다.

Milvus가 우세한 경우: 대규모 규모의 이미지 및 비디오 임베딩 (embedding) 검색, 멀티모달 (multi-modal) 벡터 워크로드, 실제로 수억 개에서 수십억 개 이상의 벡터 수를 처리하는 애플리케이션, 그리고 분산 벡터 데이터베이스 (distributed vector database)를 운영할 수 있는 인프라 엔지니어링 역량을 갖춘 팀.

Milvus가 부적합한 경우: 분산 인프라를 운영할 운영 역량이 없는 팀, pgvector의 단순함이 더 유리한 5,000만 개 미만의 벡터를 사용하는 애플리케이션, 그리고 벡터와 함께 풍부한 관계형 (relational) 또는 그래프 구조 (graph-structured) 메타데이터가 필요한 유스케이스.

솔직한 결론: Milvus는 규모 (scale)가 주요 제약 사항이며 이를 운영할 엔지니어링 리소스가 있을 때 올바른 선택입니다. 수십억 규모에 도달하지 않을 것이며 운영 오버헤드 (operational overhead)를 과소평가하는 대부분의 팀에게는 잘못된 시작점입니다.

6. Pinecone: 완전 관리형 표준

Pinecone은 운영할 인프라 없이도 프로덕션급 (production-grade) 벡터 검색을 원하는 팀을 위해 설계된 완전 관리형 (fully managed), 폐쇄형 소스 (closed-source) 벡터 데이터베이스입니다. 인덱스 (index)를 생성하고, API를 통해 벡터를 삽입하며, API를 통해 쿼리합니다. Pinecone은 스케일링 (scaling), 복제 (replication), 장애 조치 (failover) 및 성능 최적화를 처리합니다.

Pinecone은 밀집 벡터 유사도 (dense vector similarity)와 희소 키워드 점수 (sparse keyword scores)를 결합하는 하이브리드 검색 (hybrid search) 및 메타데이터 필터링 (metadata filtering)을 지원합니다. 관리형 인프라에서 수십억 규모의 데이터를 처리하며 100ms 미만의 지연 시간 (latency)을 제공하는 것이 핵심 가치 제안입니다. Pinecone은 성능 극대화나 인프라 제어보다는 작동하는 제품을 출시하는 것이 주된 관심사인 팀에게 프로덕션 투입 시간 (time-to-production)을 최소화해 주는 선택지입니다.

한계점은 관리형 서비스의 이면에 존재하는 단점과 같습니다. Pinecone을 셀프 호스팅 (self-host)할 수 없으며, 기반 인프라를 조사하거나 제어할 수 없고, 사용량에 따른 가격 책정이 대량 사용 시 상당한 수준으로 늘어날 수 있습니다. 클라우드 스토리지를 허용하지 않는 데이터 레지던시 (data residency) 요구 사항이 있는 경우에도 Pinecone을 사용할 수 없습니다.

Pinecone이 승리하는 경우: 최대한의 관리형 단순성 (managed simplicity)을 원하는 팀, 벡터 검색이 주요 워크로드이고 관계형(relational) 또는 그래프(graph) 데이터가 부차적인 애플리케이션, 그리고 Pinecone의 사용 가능한 리전(region)과 호환되는 데이터 레지던시 (data residency) 요구 사항을 가진 조직.

Pinecone이 실패하는 경우: 데이터 레지던시, 에어갭 (air-gap), 또는 온프레미스 (on-premises) 요구 사항이 있는 조직. 높은 쿼리 볼륨에서 비용 민감도가 높은 팀. 벡터 검색이 관계형 또는 그래프 데이터와 긴밀하게 결합되어야 하는 애플리케이션.

솔직한 판결: Pinecone은 순수 벡터 검색 유스케이스를 위한 가장 빠른 프로덕션(production) 경로입니다. 트레이드오프(trade-off)는 규모 확장 시의 비용과 인프라 제어권의 상실입니다. 몇 주 안에 RAG 제품을 출시해야 하는 스타트업에게 Pinecone은 종종 올바른 선택입니다. 데이터 레지던시 요구 사항이 있거나 대규모 운영 시 비용 민감도가 높은 엔터프라이즈의 경우, 관리형의 단순함이 이러한 제약 사항을 감수할 만큼의 가치는 없습니다.

7. Neo4j: 근본적으로 다른 옵션