Apr 18, 2026

마지막 업데이트 Apr 14, 2026

Vector Database 가이드: 의미 기반 검색이 왜 SQL만으로는 부족한가

RAG, semantic search, 문서 검색 이야기를 조금만 보다 보면 vector database라는 표현을 정말 자주 만나게 됩니다. 처음에는 그냥 새로운 데이터베이스 종류처럼 들리지만, 실제로 그 뒤에 있는 질문은 훨씬 더 구체적입니다.

“단어가 정확히 같은 문서”가 아니라, “의미가 비슷한 문서”를 시스템이 어떻게 찾아낼 수 있을까?

vector database는 보통 바로 그 문제를 풀기 위해 등장합니다. 막연한 “AI 전용 DB”라기보다, embedding 벡터를 similarity 기준으로 빠르게 검색하기 위한 저장소이자 검색 시스템에 가깝습니다.

이 글에서는 아래 내용을 다룹니다.

vector database가 실제로 무엇을 저장하는지
embeddings와 어떻게 연결되는지
왜 일반적인 관계형 조회만으로는 semantic retrieval이 어려운지
언제는 vector database가 필요하고 언제는 과한지

짧게 말하면 이렇습니다. embeddings가 텍스트를 벡터로 바꾸고, vector database는 그 벡터를 빠르게 검색해서 의미 기반 retrieval을 제품 수준에서 가능하게 만들어 줍니다.

Vector database란 무엇인가

vector database는 벡터, 보통은 embeddings를 저장하고, query 벡터와 가까운 벡터를 빠르게 찾아내도록 최적화된 저장소입니다.

실무에서는 보통 아래 흐름으로 연결됩니다.

문서를 chunk로 나눈다
각 chunk를 embedding으로 바꾼다
그 벡터와 metadata를 저장한다
사용자 질문도 embedding으로 바꾼다
가장 가까운 chunk를 similarity 기준으로 찾는다

즉 vector database는 아래 같은 조회를 주로 하는 시스템이 아닙니다.

user_id = 42
status = active

오히려 아래 질문을 풀기 위한 시스템입니다.

이 질문과 의미가 가장 가까운 문서 chunk는 무엇인가?

이건 exact filtering과는 완전히 다른 retrieval 문제입니다.

Embeddings와는 어떤 관계인가

embeddings와 vector database는 아주 밀접하지만 같은 것은 아닙니다.

embeddings는 의미를 담은 벡터 표현이고
vector database는 그 벡터를 저장하고 검색하는 계층입니다

즉 embeddings가 표현 계층이라면, vector database는 그 표현을 실제 retrieval에 써먹게 해 주는 검색 계층이라고 보면 됩니다.

그래서 이 글은 Embeddings 가이드와 자연스럽게 이어집니다. embeddings가 의미를 숫자로 표현해 주고, vector database는 그 숫자 표현을 바탕으로 실제 검색을 수행합니다.

왜 일반 데이터베이스만으로는 부족할까

전통적인 데이터베이스는 structured filtering에 매우 강합니다.

예를 들면 아래 같은 쿼리에 탁월합니다.

오늘 생성된 주문 찾기
pro 플랜 사용자 찾기
billing 태그가 붙은 문서 찾기

하지만 semantic retrieval은 질문 자체가 다릅니다.

이 사용자 질문과 의미가 가까운 문서를 찾아라

이게 어려운 이유는, 질문과 정답 문서가 정확히 같은 단어를 쓰지 않는 경우가 많기 때문입니다.

예를 들면:

query: “계정을 복구하려면 어떻게 해?”
문서 제목: “로그인 비밀번호 재설정 방법”

사람은 둘이 연결된다는 걸 쉽게 압니다. 하지만 exact-match 기반 조회는 놓칠 수 있습니다.

이때 vector similarity search가 필요해집니다. 단어 표면이 아니라 의미의 가까움을 수치적으로 비교할 수 있게 해 주기 때문입니다.

실전 예시: RAG 문서 도우미

사내 문서 도우미를 만든다고 해 보겠습니다.

팀은 아래 자료를 가지고 있습니다.

내부 정책 문서
지원 플레이북
온보딩 문서
운영 런북

사용자가 이렇게 묻습니다.

“운영 로그 접근 권한은 어떻게 신청해?”

이때 시스템은 모든 문서를 사람이 읽듯 훑지 않습니다. 보통은:

질문을 embedding으로 바꾸고
vector space에서 가까운 문서 chunk를 찾은 뒤
가장 관련 있는 chunk를 가져오고
그것을 LLM의 context로 붙여 답하게 합니다

이게 vector database가 RAG에서 자주 나오는 이유입니다. retrieval 단계를 충분히 빠르고 충분히 관련성 있게 만들어서 grounded generation을 가능하게 해 주기 때문입니다.

왜 vector search는 보통 완벽 탐색이 아니고 근사 탐색인가

실무에서 중요한 포인트 하나는, vector search가 모든 벡터를 정확히 끝까지 비교하는 방식으로만 동작하지 않는다는 점입니다. 많은 시스템은 approximate nearest neighbor 방식으로 검색합니다.

이유는 간단합니다.

저장된 벡터 수가 많아질 수 있고
모든 벡터를 매번 완전 비교하면 느려지며
제품에서는 낮은 지연 시간이 중요하기 때문입니다

즉 목표는 수학적으로 가장 완벽한 최근접 검색이 아니라, 제품에서 쓸 수 있을 만큼 빠르고 충분히 좋은 retrieval입니다.

그래서 retrieval 품질 평가는 여전히 중요합니다. “벡터 공간에서 가깝다”는 것과 “사용자에게 가장 좋은 문서다”는 것은 완전히 같은 말이 아니기 때문입니다.

왜 metadata filtering도 여전히 중요한가

입문자들이 자주 하는 오해가 있습니다. vector search만 있으면 나머지 검색 제약은 다 필요 없다고 보는 것입니다. 실제로는 전혀 그렇지 않습니다.

현실적인 시스템에서는 아래 같은 metadata filter가 자주 필요합니다.

문서 타입
언어
제품 영역
최신성
고객 등급

예를 들어 semantic similarity는 높아도:

다른 언어 문서이거나
이미 폐기된 정책이거나
다른 제품군 문서라면

실제로는 틀린 결과일 수 있습니다.

그래서 실전에서는 아래를 함께 쓰는 경우가 많습니다.

vector similarity
metadata filtering
keyword search
reranking

vector database는 retrieval의 핵심 부품일 수 있지만, retrieval 전략 전체 그 자체는 아닙니다.

Vector search, keyword search, hybrid search는 어떻게 다를까

세 가지를 분리해서 생각하면 훨씬 명확해집니다.

Keyword search

정확한 단어가 중요한 경우에 강합니다.

에러 코드
상품명
ID
고정된 문구

Vector search

정확한 단어보다 의미가 중요한 경우에 강합니다.

자연어 질문
유사 문서 검색
의미 기반 도움말 검색

Hybrid search

둘 다 중요한 경우에 유리합니다.

semantic intent도 중요하고
exact identifier도 중요하며
문서 최신성이나 필터도 같이 봐야 할 때

그래서 production에서 hybrid retrieval이 자주 등장합니다. 실제 사용자는 자연어로 묻지만, 정답 문서에는 특정 코드나 정확한 용어가 포함되는 경우가 많기 때문입니다.

언제 vector database를 써야 할까

아래 상황이라면 vector database가 점점 설득력을 갖기 시작합니다.

문서 수가 충분히 많아서 단순 검색이 답답해진다
사용자가 자연어로 질문한다
exact keyword보다 semantic similarity가 중요하다
retrieval latency가 중요하다
RAG 품질이 retrieval 성능에 크게 좌우된다

이건 특히 아래 영역에서 자주 나타납니다.

사내 지식 도우미
지원 봇
문서 검색
추천 시스템
유사 문서 중복 탐지

시스템의 핵심 가치가 의미 기반 retrieval에 있다면, vector database는 충분히 검토할 만합니다.

언제는 굳이 필요 없을까

반대로 아래 상황이라면 dedicated vector retrieval이 과할 수 있습니다.

데이터셋이 아주 작다
exact keyword matching만으로도 충분하다
간단한 in-memory 검색이면 된다
문제의 핵심이 semantic retrieval이 아니라 structured lookup이다

예를 들어 아주 작은 FAQ 세트에서 질문이 몇 개의 고정 표현으로 잘 수렴한다면, 굳이 복잡한 vector retrieval 레이어를 붙이지 않아도 될 수 있습니다.

중요한 질문은 “vector database가 최신 기술인가?”가 아닙니다. “이 시스템이 정말 semantic retrieval을 이 규모로 필요로 하는가?”입니다.

자주 하는 실수

1. vector database가 일반 DB를 전부 대체한다고 생각하기

보통은 그렇지 않습니다. 많은 팀이 원문 문서, metadata, 권한 정보, 비즈니스 데이터는 별도 저장소에 두고 semantic retrieval만 vector 계층으로 처리합니다.

2. embeddings만 좋으면 RAG도 자동으로 좋아진다고 기대하기

embeddings도 중요하지만, chunking, filtering, query rewriting, reranking, 원문 품질도 같이 중요합니다.

3. exact-match retrieval을 완전히 버리기

에러 코드, ID, 고정 용어는 여전히 keyword search가 아주 강합니다.

4. retrieval 설계 없이 벡터만 저장해 두기

벡터 인덱스는 chunking, filtering, ranking, generation 흐름 안에서 어떤 역할을 하는지가 분명해야 가치가 생깁니다.

빠른 체크리스트

vector database를 넣기 전에 아래를 물어보면 좋습니다.

사용자가 exact wording보다 meaning으로 검색하는가?
문서 수가 enough large해서 retrieval 효율이 중요한가?
metadata filtering이나 reranking과 함께 써야 하는가?
현재 RAG 품질 병목이 retrieval에 있는가?

답이 대부분 yes라면 vector database를 진지하게 평가할 이유가 있습니다.

FAQ

Q. vector database를 쓰면 일반 DB는 필요 없나요?

대부분은 여전히 필요합니다. 원문 문서, metadata, 권한, 비즈니스 레코드는 따로 저장하고 semantic retrieval만 vector 계층에서 처리하는 경우가 많습니다.

Q. vector search 결과는 항상 맞나요?

아닙니다. similarity search는 retrieval을 개선하지만, 여전히 평가와 튜닝이 필요합니다. “가장 가까운 벡터”가 항상 “가장 좋은 문서”는 아닙니다.

Q. 모든 RAG 시스템이 vector database를 꼭 써야 하나요?

그렇지는 않습니다. 작은 데모나 exact-match 중심 시스템은 더 단순한 방식으로도 충분할 수 있습니다. 하지만 semantic retrieval과 규모가 중요해질수록 vector search의 가치가 커집니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.