쉬운 설명
전통적인 DB는 '값이 정확히 일치하는' 검색을 잘합니다. 'name = '김철수''는 빠르게 답하지만, '이 문장과 의미가 비슷한 글을 찾아라'는 약합니다. 벡터 데이터베이스는 임베딩 — 의미를 담은 숫자 벡터 — 을 저장하고, 새 벡터가 들어오면 그것과 거리가 가까운 벡터들을 효율적으로 찾아 줍니다.
수백만 개 벡터에서 가까운 이웃을 찾는 것은 단순 비교로는 너무 느립니다. 그래서 ANN(근사 최근접 이웃) 알고리즘 — HNSW·IVF·PQ 같은 기법 — 으로 약간 부정확하지만 매우 빠른 검색을 합니다. 정확도를 일부 양보하고 속도를 10~100배 얻는 식입니다.
대표 솔루션: Pinecone·Weaviate·Qdrant·Milvus 같은 전용 제품, PostgreSQL의 pgvector 확장(범용 DB에 벡터 검색 추가), Elasticsearch·OpenSearch의 벡터 기능. 클라우드 사업자도 자체 벡터 검색(AWS OpenSearch·Azure AI Search·GCP Vertex AI Matching Engine)을 빠르게 늘리고 있습니다.
LLM 시대에 자주 만나게 되는 이유는 RAG 때문입니다. 우리 회사 문서를 임베딩해 벡터 DB에 넣어 두고, 사용자 질문이 들어오면 그 질문도 임베딩해 가까운 문서 조각을 찾아 LLM에 함께 넣어 줍니다. 그러면 LLM이 회사 내부 지식을 참고해 답할 수 있게 됩니다.
주의할 점: 벡터 DB만 잘 골라도 RAG가 잘되는 건 아닙니다. 임베딩 모델 선택, 자료를 어떻게 자르는지(chunk), 검색된 결과의 재정렬(re-ranking), 메타데이터 필터(예: 부서·날짜)까지 함께 다뤄야 진짜 품질이 나옵니다. 작은 시작에는 pgvector로 충분한 경우가 많고, 데이터·트래픽이 커지면 전용 제품을 검토합니다.
비유로 보면
벡터 DB는 도서관 사서가 책 한 권을 받아 '이 책과 분위기·내용이 비슷한 책들을 가져오겠다'고 즉시 일을 시작하는 모습과 비슷합니다. 정확히 같은 책을 찾는 게 아니라 의미가 비슷한 책을 찾는 일이고, 사서가 어떤 기준으로 비슷함을 정의하느냐(임베딩 모델)가 결과의 절반을 결정합니다.
어디에서 만나나
RAG 기반 사내 챗봇, 시멘틱 검색(키워드가 달라도 의미가 비슷한 글 찾기), 추천 시스템(상품·콘텐츠 유사도), 이미지·영상 검색, 이상 탐지(평소 패턴 벡터와의 거리), 사용자 클러스터링·세그멘테이션. AI 응용이 늘면서 벡터 DB가 점점 표준 인프라가 되고 있습니다.
작은 예시
사내 정책 챗봇을 만들 때, 회사의 위키·정책 PDF 수천 페이지를 잘게 잘라 임베딩하고 벡터 DB에 저장합니다. 직원이 '연차 이월 규정이 어떻게 돼?' 하고 물으면 벡터 DB가 의미가 가까운 정책 조각을 찾아 주고, LLM이 그 조각을 보며 답을 만들어 줍니다.
자주 하는 오해
한 줄 정리
벡터 DB의 진짜 가치는 '의미가 가까운 것을 빠르게 찾는다'에 있습니다. LLM 응용에서는 검색의 질이 모델보다 결과를 더 크게 결정합니다.