Vector DB는 RAG를 공부하다 보면 거의 반드시 만나는 말입니다. 그런데 처음부터 Vector DB를 붙이면 RAG가 좋아진다고 생각하면 판단이 흐려집니다.
이 글의 기준은 단순합니다. Vector DB는 RAG 자체가 아니라 의미 검색을 저장하고 빠르게 찾기 위한 선택지입니다. 검색해야 할 문서의 성격과 규모를 먼저 봐야 합니다.
Vector DB 도입 전 먼저 볼 기준
일반 DB 검색과 Vector DB 검색은 질문이 다르다
일반적인 DB 검색은 정해진 필드와 조건을 기준으로 데이터를 찾는 데 강합니다. 예를 들어 사용자 ID, 주문 번호, 날짜 범위, 상태값처럼 정확한 조건이 있으면 일반 DB가 자연스럽습니다.
반면 Vector DB는 문장이나 문서를 embedding으로 바꾼 뒤, 질문과 의미가 가까운 항목을 찾는 데 초점이 있습니다. OpenAI의 embedding 문서도 텍스트를 숫자 벡터로 바꾸어 검색과 분류 같은 작업에 활용할 수 있다고 설명합니다.
RAG에서 Vector DB가 맡는 위치
RAG 흐름은 보통 문서를 나누고, embedding을 만들고, 검색한 뒤, LLM 입력에 근거를 넣는 순서로 움직입니다. Vector DB는 이 중에서 주로 ’embedding 저장’과 ‘가까운 벡터 검색’을 맡습니다.
문서 조각 -> embedding -> 저장소에 저장
사용자 질문 -> embedding -> 가까운 문서 후보 검색
후보 문서 + 질문 -> LLM 답변 생성중요한 점은 Vector DB가 답변 품질 전체를 보장하지 않는다는 것입니다. 문서 조각이 잘못 나뉘었거나, 검색 후보가 너무 많거나, 권한 필터가 빠져 있으면 Vector DB를 써도 답변은 흔들립니다.
키워드 검색이 더 나은 순간
에러 코드, 정확한 API 이름, 상품 번호, 법률 문구처럼 단어 일치가 중요한 검색은 키워드 검색이 더 안정적일 수 있습니다. 사용자가 NullPointerException을 검색하는데 비슷한 의미의 다른 문서를 보여주면 오히려 방해가 됩니다.
그래서 실무 RAG에서는 벡터 검색만 고집하지 않습니다. 키워드 검색으로 정확한 후보를 잡고, 벡터 검색으로 표현이 다른 문서를 보완하는 식으로 섞을 수 있습니다.
metadata filter가 필요한 순간
RAG 검색은 의미만 가까우면 끝나는 문제가 아닙니다. 문서의 날짜, 조직, 권한, 제품 버전, 언어 같은 조건을 함께 걸어야 할 때가 많습니다. 이때 metadata filter가 중요해집니다.
예를 들어 같은 질문이라도 Android 문서와 iOS 문서를 섞으면 답이 틀어질 수 있습니다. 내부 업무 문서라면 사용자 권한에 따라 검색 가능한 문서가 달라져야 합니다.
hybrid search는 왜 자주 등장할까
Hybrid search는 키워드 검색과 벡터 검색을 함께 쓰는 접근입니다. 정확한 용어 일치와 의미 유사도를 동시에 보려는 목적입니다. LangChain도 검색과 retrieval 구성을 다룰 때 여러 저장소와 검색 방식을 조합하는 흐름을 설명합니다.
다만 hybrid search도 만능은 아닙니다. 두 검색 결과를 어떻게 합치고, reranking을 어디서 할지 정해야 합니다. 검색 결과를 다시 정렬하는 문제는 RAG reranking 글에서 따로 다뤘습니다.
작은 프로젝트는 꼭 Vector DB부터 시작하지 않아도 된다
문서가 적고 업데이트가 드물다면 파일, 일반 DB, 간단한 in-memory index로도 실험할 수 있습니다. 처음부터 운영형 Vector DB를 붙이면 인프라 관리와 비용, 권한 설계가 먼저 커질 수 있습니다.
- 문서 수가 적으면 단순 검색으로 시작해도 된다.
- 정확한 단어 검색이 핵심이면 키워드 검색을 먼저 본다.
- 의미가 비슷한 문서 검색이 핵심이면 embedding 검색을 검토한다.
- 권한, 버전, 날짜 필터가 중요하면 metadata 설계를 먼저 한다.
도입 체크리스트
- 검색하려는 데이터가 문장과 문서 중심인지 확인한다.
- 키워드 검색으로 해결되지 않는 표현 차이가 실제로 있는지 본다.
- 문서 수, 업데이트 빈도, 응답 속도 요구를 적는다.
- 권한과 metadata filter가 필요한지 먼저 설계한다.
- 검색 결과를 그대로 넣을지 reranking과 context packing을 둘지 결정한다.
정리
Vector DB는 RAG를 위한 마법 같은 필수 부품이 아닙니다. 의미 검색을 대규모로 저장하고 빠르게 찾기 위한 선택지입니다. 정확한 조건 검색은 일반 DB와 키워드 검색이 더 자연스럽고, 표현이 달라도 의미가 가까운 문서를 찾아야 할 때 Vector DB의 가치가 커집니다.
