How are you? good!

임베딩으로 텍스트를 벡터로 바꾸고 나면, 다음 과제는 ‘수많은 벡터 중에서 질문과 가장 가까운 것을 빠르게 찾는 일’입니다. 문서가 수백 개일 때는 전부 하나씩 비교해도 되지만, 수십만·수백만 개로 늘어나면 이야기가 달라집니다. 이 문제를 전담하는 것이 바로 벡터 데이터베이스(Vector Database)입니다. 이번 글에서는 대표적으로 자주 언급되는 FAISS·Chroma·pgvector 세 가지의 성격이 어떻게 다르고, 어떤 상황에서 무엇을 고르면 좋은지를 정리합니다.

🧩 벡터DB는 왜 필요한가

벡터DB의 핵심 임무는 최근접 이웃 탐색(Nearest Neighbor Search)입니다. 질문 벡터가 하나 들어오면, 저장된 벡터들 가운데 가장 가까운 몇 개를 찾아 돌려주는 것입니다.

문제는 데이터가 많아질수록 ‘모든 벡터와 일일이 거리를 재는’ 방식이 느려진다는 점입니다. 그래서 벡터DB는 ANN(Approximate Nearest Neighbor, 근사 최근접 탐색) 기법을 씁니다. 약간의 정확도를 양보하는 대신, 후보를 똑똑하게 좁혀 훨씬 빠르게 가까운 벡터를 찾는 방식입니다.

벡터DB = ‘벡터를 저장하는 곳’ + ‘가까운 벡터를 빠르게 찾는 색인(index)’. 이 두 가지를 얼마나 갖췄느냐가 도구를 가르는 기준이 됩니다.

🔍 세 후보의 정체 — 성격이 다르다

흔히 셋을 나란히 놓고 비교하지만, 사실 같은 종류의 물건이 아닙니다. 이 점을 먼저 이해하면 선택이 훨씬 쉬워집니다.

정리하면 FAISS는 ‘검색 엔진 부품’, Chroma는 ‘벡터 전용 완성품’, pgvector는 ‘익숙한 DB에 벡터 기능을 얹은 것’이라고 볼 수 있습니다.

⚡ FAISS — 속도에 특화된 라이브러리

FAISS(Facebook AI Similarity Search)는 대규모 벡터에서 유사도 검색을 빠르게 수행하도록 만든 라이브러리입니다. 여러 종류의 색인(index)을 제공해, 데이터 규모와 정확도·속도의 균형에 맞게 고를 수 있습니다.

다만 FAISS는 그 자체로 ‘데이터베이스’는 아닙니다. 원문 텍스트나 메타데이터를 관리하고, 서버로 띄우고, 저장을 지속시키는 부분은 직접 구성해야 합니다. 즉 자유도가 높은 만큼 손이 더 갑니다.

# FAISS 기본 흐름 (개념 예시)
import faiss
import numpy as np

# 벡터 차원 수에 맞는 색인 생성 (L2 거리 기준)
index = faiss.IndexFlatL2(dim)

# 문서 벡터들을 색인에 추가
index.add(doc_vectors)          # shape: (문서 수, dim)

# 질문 벡터와 가까운 상위 3개 검색
distances, ids = index.search(query_vector, k=3)
print(ids)                      # 가까운 문서의 인덱스 번호

정리하면 FAISS는 많은 벡터를 최대한 빠르게 뒤져야 하고, 주변 시스템을 직접 붙일 여력이 있을 때 강력한 선택지입니다.

🧪 Chroma — 가볍게 시작하는 벡터DB

Chroma는 파이썬 환경에서 몇 줄로 바로 쓸 수 있는 오픈소스 벡터DB입니다. 벡터뿐 아니라 원문 텍스트와 메타데이터를 함께 저장하고, 필요하면 메타데이터로 걸러서 검색하는 기능까지 기본으로 제공합니다.

가장 큰 장점은 진입 장벽이 낮다는 점입니다. 별도의 서버 구축 없이 로컬에서 실험을 시작할 수 있어, RAG 프로토타입이나 학습용으로 자주 선택됩니다.

# Chroma 기본 흐름 (개념 예시)
import chromadb

client = chromadb.Client()
col = client.create_collection("docs")

# 문서·벡터·메타데이터를 함께 저장
col.add(
    ids=["d1", "d2"],
    embeddings=[vec1, vec2],
    documents=["문서 내용 1", "문서 내용 2"],
)

# 질문 벡터로 가까운 문서 검색
res = col.query(query_embeddings=[query_vec], n_results=3)
print(res["documents"])

즉 Chroma는 빠르게 시작하고 문서 관리까지 한 번에 해결하고 싶은 소~중규모 프로젝트에 잘 맞습니다.

🐘 pgvector — 익숙한 SQL 안으로

pgvector는 널리 쓰이는 관계형 데이터베이스 PostgreSQL에 벡터 타입과 유사도 검색 기능을 더해 주는 확장입니다. 기존 테이블에 벡터 컬럼을 추가하는 방식이라, 이미 PostgreSQL을 쓰고 있다면 새 인프라를 도입하지 않고 벡터 검색을 붙일 수 있습니다.

가장 큰 매력은 익숙한 SQL과 기존 데이터의 결합입니다. 사용자 정보·주문 내역 같은 일반 데이터와 벡터를 같은 DB에서 조인·필터링할 수 있어, 운영 부담이 적습니다.

-- pgvector 기본 흐름 (개념 예시)
-- 벡터 컬럼을 가진 테이블
CREATE TABLE docs (
  id      bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)   -- 임베딩 차원 수
);

-- 질문 벡터와 가까운 순으로 정렬해 상위 3개 조회
SELECT content
FROM docs
ORDER BY embedding <-> :query_vector   -- <-> : 거리 연산자
LIMIT 3;

정리하면 pgvector는 PostgreSQL 기반 서비스를 이미 운영 중이거나, 벡터와 일반 데이터를 함께 다뤄야 할 때 자연스러운 선택입니다.

📊 한눈에 비교

표에서 보듯 ‘무엇이 무조건 낫다’는 답은 없습니다. 프로젝트의 규모와 이미 갖춘 환경에 따라 유리한 도구가 달라질 뿐입니다.

💡 어떻게 고를까 — 실무 팁

❓ 자주 묻는 질문 (FAQ)

Q. FAISS와 Chroma는 결국 같은 것 아닌가요?
A. 다릅니다. FAISS는 검색 기능을 제공하는 라이브러리이고, Chroma는 문서·메타데이터 저장까지 포함한 완성형 벡터DB입니다. 실제로 벡터DB가 내부에서 FAISS 같은 색인 기술을 활용하기도 합니다.

Q. pgvector는 전용 벡터DB보다 느리지 않나요?
A. 극단적으로 큰 규모나 초고속이 필요한 경우엔 전용 도구가 유리할 수 있습니다. 하지만 많은 서비스에서는 운영 단순함과 SQL 결합의 이점이 더 크게 작용합니다. 규모와 요구 성능을 먼저 가늠해 보는 것이 좋습니다.

Q. 나중에 다른 벡터DB로 갈아탈 수 있나요?
A. 벡터 자체는 숫자 배열이므로 옮기는 것이 원칙적으로 가능합니다. 다만 도구마다 색인·API가 달라 재적재와 코드 수정이 필요합니다. 처음부터 저장 형식을 단순하게 유지해 두면 전환이 수월합니다.

마무리

벡터DB는 임베딩으로 만든 벡터를 저장하고, 질문과 가까운 벡터를 빠르게 찾아 주는 도구입니다. FAISS·Chroma·pgvector는 이름이 나란히 붙어 다니지만 성격이 서로 다릅니다. FAISS는 속도에 특화된 라이브러리, Chroma는 가볍게 시작하는 전용 벡터DB, pgvector는 익숙한 SQL 안으로 벡터를 끌어들이는 확장입니다. 정답은 하나로 정해져 있지 않으며, 프로젝트의 규모·운영 여건·기존 인프라를 기준으로 고르는 것이 핵심입니다. 작게 시작해 검증한 뒤, 필요가 커지면 그때 더 강한 도구로 옮겨 가는 접근이 가장 현실적입니다.