VectorDB는 RDBMS와 무엇이 다를까: 의미 기반 검색의 장점, 제품, 쿼리 방식, ANN 알고리즘

들어가며

RDBMS는 정확한 조건 검색과 트랜잭션 처리에 강하다. WHERE user_id = 10, created_at >= '2026-01-01', ORDER BY price DESC처럼 명확한 값과 관계가 있는 데이터에는 여전히 가장 믿을 만한 기본 선택지다.

그런데 AI 서비스에서는 질문이 자주 이렇게 바뀐다.

• “환불 규정과 비슷한 문서를 찾아줘”
• “이 에러 로그와 의미가 가까운 장애 사례를 찾아줘”
• “이 상품 설명과 취향이 비슷한 콘텐츠를 추천해줘”
• “이미지 분위기가 비슷한 사진을 찾아줘”

이런 요청은 문자열이 정확히 같지 않아도 의미가 가까우면 찾아야 한다. VectorDB는 텍스트, 이미지, 음성, 로그 같은 비정형 데이터를 임베딩 벡터로 바꾸고, 벡터 공간에서 가까운 항목을 찾도록 설계된 데이터베이스다. 요즘 RAG, AI 검색, 추천 시스템에서 VectorDB가 자주 등장하는 이유가 여기에 있다.

VectorDB가 저장하는 것

VectorDB에 들어가는 핵심 데이터는 보통 세 가지다.

1. 원문 또는 원문 위치
2. 임베딩 벡터
3. 필터링용 메타데이터

예를 들어 블로그 글 조각을 저장한다면 이런 형태가 된다.

{
  "id": "post-2026-05-26-001",
  "text": "VectorDB는 의미 기반 검색에 적합하다...",
  "embedding": [0.012, -0.034, 0.881, "..."],
  "metadata": {
    "category": "it-tech-story",
    "publish": true,
    "language": "ko",
    "created_at": "2026-05-26"
  }
}

검색할 때도 질문을 같은 임베딩 모델로 벡터화한다. 그 다음 DB는 저장된 벡터 중 질문 벡터와 가장 가까운 상위 k개를 돌려준다.

RDBMS 대비 장점

VectorDB의 가장 큰 장점은 “정확히 같은 단어”가 아니라 “의미적으로 가까운 데이터”를 찾는다는 점이다. RDBMS나 전통적인 풀텍스트 검색은 토큰, 키워드, 정규화, 인덱스 조건에 강하지만, 표현이 달라진 문장까지 자연스럽게 연결하는 데는 한계가 있다.

예를 들어 사용자가 “계정 삭제하고 싶어”라고 입력했을 때 문서 제목이 “회원 탈퇴 절차”라면 키워드만으로는 놓칠 수 있다. 벡터 검색은 두 문장이 비슷한 의미 공간에 놓이도록 임베딩되기 때문에 더 쉽게 연결한다.

두 번째 장점은 멀티모달 검색이다. 텍스트뿐 아니라 이미지, 음성, 동영상 프레임도 임베딩으로 바꾸면 같은 방식으로 유사도를 계산할 수 있다. 그래서 “이 이미지와 비슷한 상품”, “이 문의와 비슷한 과거 티켓”, “이 문서와 함께 읽을 만한 글” 같은 기능을 하나의 검색 패턴으로 다룰 수 있다.

세 번째 장점은 RAG와의 궁합이다. LLM은 긴 지식 저장소를 그대로 들고 있지 못한다. 질문이 들어오면 관련 문서 조각을 VectorDB에서 찾아 LLM 컨텍스트에 넣는 방식이 일반적이다. 이때 VectorDB는 “답을 생성하는 모델”이 아니라 “답변에 필요한 근거 후보를 찾아주는 검색 계층”에 가깝다.

그래도 RDBMS를 대체하지는 않는다

VectorDB가 RDBMS를 완전히 대체하는 것은 아니다. 정확한 회계 데이터, 주문 상태, 권한, 트랜잭션, 조인 중심의 업무 데이터는 RDBMS가 더 적합하다.

VectorDB 검색 결과는 보통 “가까운 후보”다. 특히 근사 최근접 탐색을 쓰면 속도와 정확도 사이의 트레이드오프가 생긴다. 또한 임베딩 모델이 바뀌면 벡터를 다시 만들거나 인덱스를 재구성해야 할 수 있다. 데이터 품질도 중요하다. 문서를 너무 크게 쪼개면 검색이 둔해지고, 너무 작게 쪼개면 맥락이 사라진다.

그래서 실무 구조는 둘 중 하나를 고르는 방식보다 함께 쓰는 경우가 많다.

• RDBMS: 원본 업무 데이터, 권한, 상태, 정합성 관리
• 검색 엔진: 키워드 검색, 로그 검색, 분석 검색
• VectorDB: 의미 기반 검색, 추천, RAG 후보 검색
• LLM: 검색된 근거를 바탕으로 요약, 답변, 분류

쿼리 방식은 어떻게 다를까

RDBMS의 전형적인 쿼리는 조건을 만족하는 행을 찾는다.

SELECT *
FROM documents
WHERE category = 'it-tech-story'
ORDER BY created_at DESC
LIMIT 10;

VectorDB의 쿼리는 보통 “이 벡터와 가까운 벡터 top-k”를 찾는다.

query_vector = embed("VectorDB와 RDBMS의 차이")

search(
  vector = query_vector,
  top_k = 10,
  filter = {
    category: "it-tech-story",
    publish: true
  }
)

pgvector처럼 PostgreSQL 안에서 쓰는 경우에는 SQL 형태로도 표현할 수 있다. 거리 연산자를 기준으로 가까운 순서로 정렬하는 식이다.

SELECT title, body
FROM posts
WHERE category = 'it-tech-story'
ORDER BY embedding <=> '[0.012, -0.034, ...]'
LIMIT 10;

여기서 핵심은 거리 함수다.

• Cosine similarity: 방향이 얼마나 비슷한가
• Inner product: 내적이 얼마나 큰가
• L2 distance: 유클리드 거리로 얼마나 가까운가

같은 임베딩 모델로 만든 벡터끼리 같은 거리 기준을 적용해야 검색 품질이 안정적이다.

필터링은 생각보다 어렵다

실무 검색에서는 “가장 비슷한 문서”만으로는 부족하다. 보통 카테고리, 언어, 권한, 날짜, 테넌트, 공개 여부 같은 조건을 같이 건다.

문제는 벡터 인덱스가 빠르게 찾은 후보가 필터 조건을 만족하지 않을 수 있다는 점이다.

• Pre-filtering: 먼저 조건으로 좁힌 뒤 벡터 검색
• Post-filtering: 먼저 벡터 검색 후 조건에 맞지 않는 결과 제거
• Single-stage 또는 filter-aware search: 필터 조건을 검색 과정에 함께 반영

데이터가 작으면 단순해도 되지만, 테넌트가 많거나 권한 조건이 복잡하면 필터링 전략이 검색 품질과 지연시간을 크게 좌우한다. Qdrant는 필터와 잘 결합되는 HNSW 구조를 강조하고, Pinecone도 메타데이터 필터링을 벡터 검색의 핵심 기능으로 다룬다.

근사 최근접 탐색이 필요한 이유

벡터가 100만 개 있고 각 벡터가 1,536차원이라고 하자. 질문 하나가 들어올 때 모든 벡터와 거리를 계산하면 정확하긴 하지만 비용이 크다. 이 방식은 보통 flat 또는 exact search라고 부른다.

실무에서는 대부분 “정답과 거의 비슷한 후보를 훨씬 빠르게 찾는” ANN, 즉 Approximate Nearest Neighbor 알고리즘을 쓴다. ANN은 정확도 일부를 양보하고 속도, 메모리, 확장성을 얻는다.

중요한 튜닝 기준은 보통 세 가지다.

• Recall: 진짜 가까운 결과를 얼마나 잘 찾는가
• Latency: 검색 응답 시간이 얼마나 짧은가
• Cost: 메모리, CPU, 디스크 비용이 얼마나 드는가

대표 ANN 알고리즘

HNSW

HNSW는 현재 상용 VectorDB에서 가장 널리 쓰이는 그래프 기반 알고리즘 중 하나다. 벡터들을 가까운 이웃끼리 연결한 그래프로 만들고, 검색할 때는 높은 계층에서 대략적인 방향을 잡은 뒤 낮은 계층에서 세밀하게 탐색한다.

직관적으로는 “동네 지도”와 비슷하다. 처음부터 모든 집을 뒤지는 대신, 고속도로 같은 큰 연결을 타고 근처까지 간 다음 골목길을 따라 가까운 후보를 찾는다.

장점은 검색 속도와 recall 균형이 좋다는 점이다. 단점은 그래프를 유지해야 하므로 메모리를 꽤 쓰고, 인덱스 생성 비용도 있다. Qdrant는 dense vector index로 HNSW를 사용한다고 설명하고, Weaviate와 MongoDB Atlas Vector Search, Azure AI Search도 HNSW 기반 ANN을 문서화하고 있다.

IVF

IVF, 즉 Inverted File Index는 벡터 공간을 여러 클러스터로 나누고, 쿼리 벡터가 가까운 클러스터 몇 개만 탐색한다. 모든 벡터를 보지 않고 후보 영역을 줄이는 방식이다.

장점은 대규모 데이터에서 효율적이고 구조가 비교적 이해하기 쉽다는 점이다. 단점은 클러스터를 어떻게 나누는지, 몇 개의 클러스터를 탐색할지에 따라 품질이 크게 달라진다. pgvector의 IVFFlat, Faiss 계열 인덱스에서 자주 볼 수 있다.

PQ와 SQ

Product Quantization(PQ)과 Scalar Quantization(SQ)은 벡터를 압축하는 방법이다. float32 벡터를 그대로 저장하면 메모리 비용이 커지므로, 벡터를 더 작은 표현으로 바꿔 저장하고 거리 계산도 근사한다.

장점은 메모리와 디스크 비용을 크게 줄일 수 있다는 점이다. 단점은 압축 때문에 정확도가 떨어질 수 있다. 대규모 검색에서는 HNSW나 IVF와 quantization을 조합해 비용과 성능을 맞추는 경우가 많다.

DiskANN과 Vamana 계열

HNSW는 메모리 사용량이 커질 수 있다. 데이터가 매우 커지면 디스크나 SSD 친화적인 그래프 인덱스가 중요해진다. DiskANN, Vamana 계열은 이런 방향의 대표적인 접근이다. Redis는 최신 문서에서 FLAT, HNSW 외에 SVS-VAMANA 인덱스 타입도 언급한다.

LSH

Locality Sensitive Hashing은 가까운 벡터가 같은 버킷에 들어갈 가능성이 높도록 해시를 설계하는 방식이다. 개념은 오래됐고 특정 조건에서는 유용하지만, 최근 범용 VectorDB 제품에서는 HNSW나 IVF 계열이 더 자주 보인다.

상용화 제품과 선택지

VectorDB 시장은 전용 DB, 기존 DB 확장, 검색 엔진 통합으로 나뉜다.

선택 기준은 “어떤 제품이 제일 좋은가”보다 “어디에 붙일 것인가”에 가깝다.

• 이미 Postgres 중심이면 pgvector가 운영 부담이 작다.
• 검색/로그/문서 검색이 Elastic/OpenSearch에 많으면 기존 검색 엔진의 벡터 기능을 검토할 만하다.
• RAG 전용 서비스로 빠르게 시작하려면 Pinecone, Weaviate, Qdrant, Milvus 계열이 편하다.
• MongoDB 문서 데이터와 함께 검색하려면 Atlas Vector Search가 자연스럽다.
• 초저지연 캐시형 검색이나 Redis 중심 아키텍처라면 Redis Vector Search가 맞을 수 있다.

하이브리드 검색이 중요한 이유

벡터 검색은 의미를 잘 잡지만, 고유명사와 정확한 키워드에는 약할 수 있다. 예를 들어 “GPT-5.5”, “CVE-2026-12345”, “TurboQuant” 같은 단어는 의미보다 정확한 문자열 매칭이 중요하다.

그래서 실무에서는 하이브리드 검색을 많이 쓴다.

1. BM25 같은 키워드 검색 결과
2. dense vector 기반 의미 검색 결과
3. sparse vector 또는 learned sparse 검색 결과
4. reranker로 최종 재정렬

Weaviate는 keyword, vector, hybrid search를 주요 검색 방식으로 설명하고, Pinecone도 dense/sparse/hybrid 검색 패턴을 문서화한다. 결국 좋은 검색은 하나의 알고리즘보다 “후보 생성 + 필터링 + 재랭킹 + 평가”의 파이프라인에 가깝다.

운영 관점에서 봐야 할 것

VectorDB를 도입할 때는 데모 검색 품질만 보면 안 된다. 운영에서는 다음 질문이 더 중요하다.

• 임베딩 모델을 바꾸면 재색인 비용은 얼마인가?
• 문서 chunk 크기와 overlap은 어떻게 정할 것인가?
• 권한 필터가 검색 과정에서 정확히 적용되는가?
• top-k 결과를 그대로 쓸 것인가, reranker를 붙일 것인가?
• 삭제된 문서나 비공개 문서가 검색 결과에 남지 않는가?
• 검색 품질을 어떤 테스트셋으로 측정할 것인가?
• 장애 시 원본 데이터에서 재구축할 수 있는가?

특히 RAG에서는 VectorDB가 틀린 후보를 가져오면 LLM 답변도 흔들린다. “LLM이 이상한 답을 했다”는 문제의 원인이 사실은 chunking, embedding, filtering, reranking, 권한 처리에 있는 경우가 많다.

정리

VectorDB는 RDBMS보다 더 좋은 데이터베이스라기보다, 전혀 다른 검색 문제를 푸는 도구다. RDBMS가 정확한 값과 관계를 다룬다면, VectorDB는 의미적으로 가까운 후보를 빠르게 찾는다.

핵심은 다음과 같다.

• RDBMS는 정합성, 트랜잭션, 조건 검색에 강하다.
• VectorDB는 의미 검색, 추천, RAG 후보 검색에 강하다.
• 실무에서는 보통 RDBMS와 VectorDB를 함께 쓴다.
• HNSW가 현재 널리 쓰이는 대표 ANN 알고리즘이다.
• IVF, PQ, SQ, DiskANN/Vamana 계열은 규모와 비용 문제를 풀기 위한 선택지다.
• 벡터 검색만으로 충분하지 않은 경우가 많아 하이브리드 검색과 reranking이 중요하다.

AI 서비스에서 검색 품질은 모델만의 문제가 아니다. 좋은 VectorDB 설계는 원본 데이터 관리, 임베딩 모델, chunking, 인덱스, 필터링, reranking, 평가셋까지 함께 보는 일이다.

참고 링크

• Pinecone Search overview
• Weaviate vector index concepts
• Milvus overview
• Qdrant indexing documentation
• pgvector README
• MongoDB Atlas Vector Search overview
• Redis vector search concepts
• Azure AI Search vector ranking