WebPiki
it

벡터 데이터베이스 입문: Pinecone, Weaviate, ChromaDB 비교

벡터 DB가 뭔지, 왜 필요한지, 주요 제품 비교와 선택 기준을 정리했다.

RAG(Retrieval-Augmented Generation)가 AI 애플리케이션의 핵심 패턴이 되면서, 벡터 데이터베이스에 대한 관심도 같이 올라갔다. "LLM한테 내 데이터를 기반으로 답변하게 하고 싶다"면, 벡터 DB를 거의 반드시 만나게 된다.

근데 막상 찾아보면 제품이 너무 많다. Pinecone, Weaviate, ChromaDB, Milvus, Qdrant, pgvector... 뭐가 다르고 뭘 써야 하는지 헷갈린다.

벡터 임베딩부터 이해하자

벡터 DB를 이해하려면 먼저 "임베딩(embedding)"을 알아야 한다.

텍스트, 이미지, 오디오 같은 비정형 데이터를 수백~수천 차원의 숫자 배열(벡터)로 변환한 것이 임베딩이다. "고양이"라는 단어를 [0.12, -0.34, 0.56, ...] 같은 숫자 배열로 바꾸는 건데, 이 변환 과정에서 의미가 보존된다. 비슷한 의미의 단어는 벡터 공간에서 가까이 위치하고, 다른 의미의 단어는 멀리 위치한다.

"고양이"와 "강아지"의 벡터 거리는 가깝고, "고양이"와 "자동차"의 거리는 멀다. 이 성질을 이용하면 "유사한 문서 찾기", "비슷한 이미지 검색", "의미적으로 관련된 질문-답변 매칭" 같은 걸 할 수 있다.

임베딩은 OpenAI의 text-embedding-3, Cohere의 Embed, 오픈소스 모델(sentence-transformers) 등으로 생성한다. 벡터 DB는 이렇게 생성된 임베딩을 저장하고 검색하는 전문 저장소다.

왜 일반 DB로는 안 되나

PostgreSQL에 벡터를 ARRAY로 저장하고, 코사인 유사도를 계산하는 쿼리를 날리면 되지 않을까? 작은 데이터셋에서는 된다. 근데 규모가 커지면 문제가 생긴다.

정확한 유사도 검색(brute-force)은 모든 벡터와 비교해야 하니까 O(n)이다. 벡터가 100만 개면 매 쿼리마다 100만 번 비교해야 한다. 1000차원 벡터면 비교 한 번에 1000번의 곱셈과 덧셈. 이건 느리다.

벡터 DB는 ANN(Approximate Nearest Neighbor) 알고리즘을 써서 이 문제를 해결한다. 정확도를 약간 희생하는 대신(99%+ 정확도), 검색 속도를 수백~수천 배 빠르게 만든다.

주요 ANN 알고리즘

HNSW (Hierarchical Navigable Small World) — 가장 널리 쓰이는 알고리즘. 그래프 구조를 만들어서 유사한 벡터끼리 연결하고, 계층적으로 탐색한다. 검색 속도와 정확도의 균형이 좋다. 대부분의 벡터 DB가 기본으로 지원한다. 메모리를 좀 먹지만 그만큼 빠르다.

IVF (Inverted File Index) — 벡터를 클러스터로 나누고, 쿼리 벡터와 가까운 클러스터만 검색한다. HNSW보다 메모리 효율이 좋지만 정확도가 약간 낮을 수 있다. 대규모 데이터셋에서 메모리가 제한적일 때 유용하다.

PQ (Product Quantization) — 벡터를 압축해서 메모리 사용량을 줄이는 기법. 단독으로 쓰기보다 IVF와 결합(IVFPQ)해서 사용하는 경우가 많다. 정확도가 떨어지지만 수십억 개의 벡터를 다뤄야 할 때 현실적인 선택지다.

주요 벡터 DB 비교

Pinecone

완전 관리형(fully managed) 서비스. 서버를 직접 운영할 필요가 없다. API만 호출하면 된다.

특징:

  • 인프라 관리 불필요 — 스케일링, 백업, 모니터링을 Pinecone이 알아서 한다
  • Serverless 옵션 — 사용한 만큼만 과금. 소규모 프로젝트에 적합
  • 메타데이터 필터링 — 벡터 검색과 동시에 조건 필터링 가능
  • 네임스페이스로 데이터 분리

가격: 무료 티어가 있지만 제한적이다(인덱스 5개, 차원 제한). 프로덕션 용도면 월 $70부터 시작하고, 규모에 따라 올라간다.

적합한 경우: 인프라 관리를 하고 싶지 않은 팀, 빠르게 프로토타입을 만들고 싶을 때, 서버리스 아키텍처에 맞출 때.

Weaviate

오픈소스지만 클라우드 서비스도 있다. 벡터 검색과 키워드 검색을 결합한 하이브리드 검색이 강점이다.

특징:

  • 하이브리드 검색 — BM25(키워드) + 벡터 검색을 함께 쓸 수 있다. 정확도가 올라간다
  • 모듈 시스템 — OpenAI, Cohere, Hugging Face 등의 임베딩 모듈을 플러그인으로 연결. 별도의 임베딩 파이프라인 없이 텍스트를 넣으면 자동으로 벡터화
  • GraphQL API
  • 멀티모달 — 텍스트뿐 아니라 이미지 벡터도 저장·검색 가능

가격: 셀프호스팅하면 무료(오픈소스). 클라우드는 Sandbox(무료)부터 시작, 프로덕션은 사용량 기반 과금.

적합한 경우: 키워드 + 벡터 하이브리드 검색이 필요할 때, 멀티모달 데이터를 다룰 때, 셀프호스팅을 원할 때.

ChromaDB

가볍고 심플한 오픈소스 벡터 DB. 로컬 개발과 프로토타이핑에 최적화되어 있다.

특징:

  • 설치가 정말 간단하다. pip install chromadb 한 줄이면 끝
  • Python 네이티브 — LangChain, LlamaIndex와의 통합이 매끄럽다
  • 인메모리 또는 영구 저장소 선택 가능
  • 임베딩 함수를 내장하고 있어서 별도의 임베딩 서비스 없이 사용 가능
import chromadb

client = chromadb.Client()
collection = client.create_collection("my_docs")

collection.add(
    documents=["고양이는 귀엽다", "강아지는 충성스럽다", "자동차가 고장났다"],
    ids=["doc1", "doc2", "doc3"]
)

results = collection.query(
    query_texts=["반려동물"],
    n_results=2
)
# → "고양이는 귀엽다", "강아지는 충성스럽다"

가격: 오픈소스, 무료. 클라우드 서비스는 아직 초기 단계.

적합한 경우: 로컬 개발, 프로토타입, 소규모 프로젝트, 학습 목적. 대규모 프로덕션에는 아직 부족한 면이 있다.

Milvus

CNCF 졸업 프로젝트(인큐베이팅 완료). 대규모 환경에 강한 오픈소스 벡터 DB다.

특징:

  • 수십억 개의 벡터를 다룰 수 있는 확장성
  • GPU 가속 검색 지원
  • 분산 아키텍처 — 스토리지와 컴퓨팅 분리
  • 다양한 인덱스 타입 지원 (HNSW, IVF, DiskANN 등)
  • Zilliz Cloud라는 관리형 서비스도 있다

적합한 경우: 대규모 데이터셋(수억~수십억 벡터), 높은 처리량이 필요한 프로덕션 환경. 소규모에서는 오버스펙.

Qdrant

Rust로 작성된 오픈소스 벡터 DB. 성능과 기능의 균형이 좋다.

특징:

  • Rust 기반이라 메모리 효율과 성능이 우수
  • 풍부한 필터링 — 중첩 조건, 지리적 필터링 등
  • 페이로드(메타데이터) 인덱싱이 잘 되어 있어서 필터링 성능이 좋다
  • gRPC와 REST API 모두 지원
  • 클라우드 서비스도 있음

적합한 경우: 복잡한 필터링이 필요할 때, 성능을 중시하는 프로덕션 환경, 셀프호스팅을 원할 때.

비교 요약

항목PineconeWeaviateChromaDBMilvusQdrant
타입관리형오픈소스+클라우드오픈소스오픈소스+클라우드오픈소스+클라우드
셀프호스팅불가가능가능가능가능
학습 곡선낮음중간매우 낮음높음중간
확장성높음중~높음낮음매우 높음높음
하이브리드 검색제한적강점기본지원지원
프로덕션 준비도높음높음중간높음높음

pgvector — 이미 PostgreSQL을 쓰고 있다면

별도의 벡터 DB를 운영하고 싶지 않으면 pgvector를 고려할 만하다. PostgreSQL 확장으로, 기존 PostgreSQL에 벡터 검색 기능을 추가한다.

-- pgvector 확장 설치
CREATE EXTENSION vector;

-- 벡터 컬럼이 있는 테이블 생성
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding VECTOR(1536)
);

-- HNSW 인덱스 생성
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops);

-- 유사도 검색
SELECT content, embedding <=> '[0.1, 0.2, ...]' AS distance
FROM documents
ORDER BY distance
LIMIT 5;

장점:

  • 이미 PostgreSQL을 쓰고 있으면 인프라 추가 없이 사용 가능
  • SQL로 벡터 검색 + 관계형 쿼리를 조합할 수 있다
  • 트랜잭션, 백업, 복제 등 PostgreSQL의 기능을 그대로 활용
  • Supabase, Neon 같은 서버리스 PostgreSQL에서도 지원

단점:

  • 전용 벡터 DB 대비 검색 성능이 떨어진다 (특히 대규모에서)
  • 벡터 관련 기능(필터링, 하이브리드 검색)이 상대적으로 제한적
  • 수백만 개 이상의 벡터에서는 성능 저하가 체감될 수 있다

벡터가 100만 개 이하이고, 이미 PostgreSQL을 메인 DB로 쓰고 있다면 pgvector가 가장 현실적인 선택일 수 있다. 아키텍처를 단순하게 유지할 수 있다는 게 큰 장점이다.

선택 기준 정리

프로토타입 / 학습 → ChromaDB. 설치 간편하고, Python에서 바로 쓸 수 있고, 무료. LangChain 튜토리얼 대부분이 ChromaDB를 기본으로 쓴다.

소규모 프로덕션 (벡터 100만 이하) → 이미 PostgreSQL을 쓰고 있으면 pgvector, 아니면 Qdrant나 Weaviate 셀프호스팅, 또는 Pinecone Serverless.

중~대규모 프로덕션 → 인프라 관리를 원하지 않으면 Pinecone이나 Weaviate Cloud. 셀프호스팅에 자신 있으면 Qdrant나 Milvus. 하이브리드 검색이 중요하면 Weaviate.

수십억 규모 → Milvus. 이 규모에서 검증된 오픈소스 선택지가 별로 없다.

한 가지 주의할 점은, 벡터 DB의 성능은 데이터셋과 쿼리 패턴에 따라 크게 달라진다는 것이다. 벤치마크 결과만 보고 결정하기보다, 실제 데이터로 테스트해보는 게 중요하다. 대부분의 벡터 DB가 무료 티어나 오픈소스를 제공하니까, 후보를 2~3개로 줄이고 직접 비교해보는 걸 권한다.

벡터 DB는 아직 빠르게 진화하는 분야라서, 6개월 전의 비교가 지금은 맞지 않을 수도 있다. 각 제품의 최신 릴리즈 노트를 확인하면서 선택하는 게 좋다.

#벡터DB#Pinecone#ChromaDB#RAG#AI

관련 글

itFine-tuning vs RAG: 언제 어떤 방식을 선택해야 할까it멀티모달 AI란? 텍스트·이미지·음성을 동시에 이해하는 AIitAI로 업무 자동화하기: n8n + AI 실전 워크플로우