제4장 — 올바른 벡터 데이터베이스 선택

LLM Primer III: RAG로 강화하는 엔터프라이즈 AI를 챕터별로 소개하는 시리즈의 네 번째 글입니다. RAG 시스템에서 가장 빠르게 자라고, 규모에서 가장 비싸며, 팀을 가장 단단히 묶어 두는 부분 — 기술적 장점으로 고르고, 운영적 사정으로 정해지는 자리에 관한 이야기입니다.

이 장이 존재하는 이유

벡터 데이터베이스는 검색 시스템의 저장 층이고, 그 선택은 다축 결정입니다 — 성능, 데이터 거주성, 팀의 운영적 모양, 시스템 수명에 걸친 총 소유 비용. 잘못된 선택은 수년을 묶어 둡니다. 십억 개의 임베딩을 시스템 사이로 옮기는 일은 어느 팀도 가벼이 시작하지 않기 때문입니다. 기술적 비교가 쓸모는 있지만, 선택은 대개 그 기술적 비교가 흘려 보내는 세 축에서 결정됩니다: 데이터가 살 수 있는 자리, 팀이 운영할 수 있는 것, 그리고 시스템이 수명 동안 드는 비용.

4.1 아키텍처: 목적별 설계와 확장

흔히 이름이 붙지 않은 첫 결정은, 벡터 워크로드를 위해 새로 만들어진 시스템을 도입할 것이냐, 팀이 이미 운영하는 시스템을 확장할 것이냐입니다. 목적별 데이터베이스 — Pinecone, Qdrant, Milvus, Weaviate, Vespa — 는 인덱스에서 바깥으로 향해 설계되었습니다. 쿼리 플래너, 저장 레이아웃, 복제 모델, API 모두가 고차원 벡터에 대한 근사 최근접 이웃 쿼리를 위해 설계되어 있습니다. 더 높은 성능 천장, 특히 필터-벡터 하이브리드 쿼리에서. 그리고 운영해야 할 시스템이 하나 더 늘어납니다.

확장 접근 — pgvector, Elasticsearch dense_vector, MongoDB Atlas Vector Search, RediSearch가 얹힌 Redis — 은 팀이 이미 굴리는 데이터베이스에 벡터 검색을 더합니다. 새 인증, 백업 절차, 온콜 로테이션, 패치 케이던스가 없습니다. 성능 천장은 호스트의 아키텍처가 정하고, 이는 대개 수천만 벡터 아래 범위의 애플리케이션이 요구하는 수준을 충분히 웃돕니다. 결정은 순수한 성능 문제가 아닙니다. 더 자주, 팀이 운영 예산을 어디에 쓰고 싶은가의 문제입니다 — Postgres 하나를 굴리는 팀은 두 번째를 굴리고 싶어 하지 않고, 데이터 서비스 열 개를 굴리는 팀은 열한 번째에 눈도 깜박이지 않습니다.

4.2 매니지드의 선두: Pinecone과 Vertex

Pinecone은 매니지드 벡터 데이터베이스의 정전입니다. 운영적 단순함, 예측 가능한 지연, 성숙한 SDK, 그리고 저장과 컴퓨트를 분리해 프로비저닝 용량이 아니라 실제 사용에 과금하는 서버리스 등급. 워크로드가 예약 용량의 이점을 특정해 누리는 경우가 아니라면, 새 배포의 옳은 기본값입니다. 대가는 어떤 매니지드 독점 시스템이든 따라오는 아키텍처적 락인입니다 — 임베딩은 원리적으로 휴대 가능하지만, 내보내고 재인덱싱하는 비용은 실재합니다. Vertex AI Vector Search는 구글의 제안으로, 구글 자신의 대규모 유사도 검색을 받쳐 주는 ScaNN 라이브러리 위에 세워졌습니다. 더 높은 규모 천장, GCP의 나머지와의 긴밀한 통합 — 임베딩 모델, IAM, Cloud Monitoring — 그리고 단일 클라우드에 대한 짝맞는 전략적 약속. Azure AI Search는 Microsoft에 묶인 팀에게 같은 자리를 차지합니다. 세 플랫폼 네이티브 옵션 사이의 선택은 보통 이미 있는 클라우드 약속을 따르며, 팀이 규모와 거주성을 검증한 한 합리적입니다.

4.3 오픈소스: Qdrant, Milvus, Weaviate

오픈소스 범주는 비용, 거주성, 전략적 이유로 자기 인프라를 통제하고 싶고, 분산 시스템을 운영할 역량이 있는 팀을 위한 것입니다. Qdrant는 가장 작고 집중적입니다: Rust로 작성된 단일 바이너리 배포, 강한 필터링과 양자화 지원을 갖춘 저지연 벡터 검색을 위해 설계되어 있습니다. 몇 분 안에 돌리기 시작할 수 있을 만큼 접근 가능하며, 가능한 한 작은 운영 발자국을 원할 때 옳은 선택입니다. Milvus는 가장 크고 가장 엔터프라이즈 지향적입니다 — 컴퓨트, 스토리지, 메타데이터를 분리한 클라우드 네이티브 아키텍처와, 그 범주에서 가장 높은 규모 천장(십억 규모 코퍼스, GPU 가속 인덱스, 티어드 스토리지). 운영 복잡도가 상당하고, Zilliz Cloud가 이를 완화합니다. Weaviate는 그 사이에 자리합니다 — Qdrant보다 기능이 많고 Milvus보다 단순하며, 임베딩, 리랭킹, 멀티테넌시를 위한 내장 모듈을 갖춘 — 단순한 검색 인덱스가 아니라 검색 플랫폼. 셋 모두 코어가 Apache 라이선스이고, 매니지드 유료 제공도 있으며, 벤치마크는 서로 작은 상수 배 안에 있습니다. 결정은 원 성능이 아니라 적합성입니다.

4.4 임베디드와 Postgres: Chroma와 pgvector

대부분의 실제 RAG 배포는 수십만 벡터에 대해 초당 수십 쿼리를 서비스하지, 수십억에 대해 초당 수백만을 서비스하지 않습니다. 이러한 워크로드에 옳은 도구는 애플리케이션 프로세스 안에서, 혹은 그 옆에서 돕니다. Chroma는 임베디드 옵션입니다 — 기본은 인프로세스, 로컬 디스크에 영속화하며, 가장 단순한 경우 설정이 필요 없습니다. 프로토타입, 자기 데이터와 함께 출하되는 도구, 한 머신에 들어가는 프로덕션 배포에 적합합니다. pgvector는 Postgres에 벡터 형, 거리 연산자, HNSW/IVFFlat 인덱싱을 더합니다. 잘 프로비저닝된 호스트에서 대략 천만 벡터까지의 코퍼스에 대해 pgvector는 신뢰할 수 있는 프로덕션 선택이며, 이미 Postgres를 굴리는 팀에게는 운영적으로 가장 단순한 선택입니다. 벡터 검색은 기존 ORM이 이해하는 테이블에 대한 SQL 쿼리가 되고, 구조화 메타데이터와의 조인은 일등 시민입니다. 이 옵션들의 숨은 미덕은, 마음을 바꾸는 비용을 낮춰 둔다는 점입니다 — 분산 시스템으로의 이주가 일어난다면, 그 범위가 한정되어 있습니다.

4.5 거주성, 운영, 비용 — 실제로 결정하는 축

이 세 운영 축은 프로덕션 결정이 실제로 내려지는 자리이기에 이름을 붙여 둘 만합니다. 데이터 거주성은 어떤 기술적 비교가 의미를 갖기 전에 후보 목록을 좁힙니다. EU 데이터 보호, 금융권 규제, 주권 클라우드 약속 — 이 제약은 협상할 여지가 없으며, 어떤 벤더에게든 첫 질문은 어떤 리전을 지원하고 계약상 데이터 처리 약속이 무엇인가입니다. 특별히 함정 하나: 임베딩은 파생 데이터이지만, 역변환되거나 유사도 검색으로 원본을 회수하는 데 쓰일 수 있기에 대부분의 규제 프레임에서 여전히 개인 데이터입니다. 원문서는 다루되 임베딩에 대해서는 모호한 계약은 불완전합니다.

운영적 모양은 팀 자신의 역량입니다. 한 애플리케이션 서비스를 운영하는 세 명의 엔지니어로 된 팀은 운영 표면을 가장 적게 더하는 옵션을 골라야 합니다 — pgvector, 매니지드 Pinecone이나 Qdrant Cloud, 임베디드 Chroma. 서른 명의 팀은 비용과 역량 이점을 위해 오픈소스 분산 시스템의 복잡도를 흡수할 수 있습니다. 실수는, 팀이 실제로 운영할 역량과 맞지 않는 시스템을 고르는 것입니다. 시스템 수명에 걸친 총 비용은 프로비저닝, 모니터링, 백업, 복구 훈련, 용량 계획, 업그레이드 작업, 그리고 그에 따른 온콜 시간 비용까지 포함합니다. 정직한 틀짓기는 세 시나리오에서 비용을 묻습니다 — 현재 워크로드, 10배, 100배 — 곡선의 기울기가 출발점만큼 중요하기 때문입니다.

제4장이 준비하는 것

벡터 데이터베이스는 저장 층이 무엇을 담을 수 있는지, 얼마나 빠르게 질의될 수 있는지, 어떤 필터와 메타데이터 패턴을 지원하는지를 정합니다. 이 속성들 중 어느 것도 그 자체로 검색 품질을 결정하지는 않습니다 — 그 위에 무엇을 만들 수 있는지를 결정합니다. 그 위에 만들어지는 것이 검색 파이프라인이고, 이득은 그곳에서 복리로 쌓입니다: 밀집 벡터와 BM25를 결합한 하이브리드 검색, 이질적 리트리버 사이의 RRF, 크로스 인코더 리랭킹, 그리고 사용자가 묻는 방식과 문서가 답하는 방식을 잇는 쿼리 이해 층.

다음 → 제5장: 검색 파이프라인 설계. 밀집 벡터 검색과 키워드 검색이 RRF로 결합되는 방식, 남은 품질 간격의 대부분을 닫는 크로스 인코더 리랭킹 단계, 그리고 나머지를 마무리하는 쿼리 이해 층.