벡터 데이터베이스는 임베딩 벡터를 저장하고 유사도 검색을 처리하는 데이터 시스템입니다. 전용 데이터베이스일 수도 있고 기존 데이터베이스에 벡터 기능을 더한 형태일 수도 있습니다. 데이터베이스가 의미를 스스로 이해하는 것은 아니며, 임베딩 모델이 만든 벡터와 거리 계산을 바탕으로 가까운 항목을 찾습니다.
이 글은 Pinecone, AWS, Google Cloud, IBM의 공식 기술 문서를 기준으로 작성했습니다.
정확 일치가 아니라 유사도
관계형 데이터베이스도 범위 검색과 전문 검색, 벡터 기능을 제공할 수 있습니다. 차이는 제품 이름보다 질의 방식에 있습니다. 일반적인 조건 검색이 값과 규칙에 맞는 행을 찾는다면, 벡터 검색은 질문 벡터와 가까운 벡터를 찾습니다. 코사인 유사도 같은 지표를 사용하므로 단어가 달라도 임베딩 공간에서 가까운 데이터가 결과에 들어올 수 있습니다.
데이터가 작거나 정확도가 더 중요하면 모든 후보를 비교하는 exact k-NN을 쓸 수 있습니다. 데이터가 커지면 정확도를 일부 양보하고 속도를 얻는 근사 최근접 이웃(ANN)을 자주 씁니다. HNSW와 IVF 같은 인덱스는 속도와 재현율의 균형이 다르므로 데이터 규모와 요구 정확도에 맞춰 고릅니다.
인덱스가 아니라 데이터베이스인 이유
유사도 탐색만 하는 라이브러리와 데이터를 지속해서 저장하고 조회하는 시스템은 역할이 다릅니다. 메타데이터 필터, 갱신, 백업과 접근 제어의 지원 범위는 제품마다 다르므로, 기능 목록 하나로 벡터 데이터베이스 여부를 단정하기보다 실제 저장과 검색 구조를 확인합니다.
형태도 전용 제품만이 아닙니다. Pinecone 같은 전용 서비스, 오픈소스(Weaviate, Milvus), PostgreSQL 확장(pgvector), 기존 검색엔진과 클라우드 DB의 벡터 기능까지 스펙트럼이 넓고, Google Cloud는 미래에는 모든 데이터베이스가 벡터 데이터베이스가 될 것이라고까지 말합니다. 벡터 검색이 별도 신제품이 아니라 데이터베이스의 기본 기능이 되어 가는 흐름입니다.
RAG 파이프라인 안의 자리
RAG에서는 청킹한 문서 조각을 임베딩해 벡터 데이터베이스에 저장할 수 있습니다. 질문이 오면 가까운 조각을 찾지만 응답 시간은 데이터 규모와 인덱스, 인프라에 따라 달라집니다. RAG는 키워드 검색이나 두 방식을 섞은 검색도 쓸 수 있으므로 벡터 데이터베이스가 필수 부품은 아닙니다.
이 문서군의 위계로 정리하면 이렇습니다. 임베딩이 의미를 벡터로 바꾸는 표현, 청킹이 그 단위를 만드는 전처리, 시맨틱 검색이 그 위에서 성립하는 검색 방식, RAG가 검색과 생성을 잇는 전체 구조, 벡터 데이터베이스는 그 벡터들이 물리적으로 저장되고 검색되는 인프라입니다.
검색 실무자에게 갖는 의미
자체 RAG나 사내 검색을 운영하는 마케터와 콘텐츠 담당자는 검색 결과를 점검할 때 이 개념을 씁니다. 다만 Google이나 Naver 검색이 특정 벡터 데이터베이스를 쓴다고 공식 확인된 것은 아닙니다. 벡터 검색 원리만으로 의미가 넓은 글이 AI 인용에 유리하다고 결론 내릴 수도 없습니다. 콘텐츠 조언이 아니라 검색 시스템을 설계하고 진단하는 기술 개념으로 이해해야 합니다.
질문과 문서 조각을 찾는 실제 예시
배송 정책 문서에 다음 두 조각이 있다고 해보겠습니다.
- 문서 A:
제주 지역에는 3,000원의 추가 배송비가 붙습니다. - 문서 B:
결제 후 2영업일 안에 출고합니다.
사용자가 제주도는 배송비를 더 내나요라고 물으면 정확히 같은 단어가 없어도 질문 벡터와 문서 A의 벡터가 가까워 상위 결과가 될 수 있습니다. 실제 순위는 임베딩 모델과 거리 지표, 필터와 인덱스 설정에 따라 달라집니다.
검색 결과를 확인하는 방법
자체 시스템의 관리 화면이나 로그에서 다음 항목을 봅니다.
- 질의에 사용한 임베딩 모델과 벡터 차원
- 상위 문서 조각과 유사도 또는 거리 점수
- 날짜와 카테고리 같은 메타데이터 필터
- exact k-NN과 ANN의 결과 차이
- 정답 문서가 상위 결과에 들어온 비율과 검색 시간
대표 질문과 정답 문서를 미리 정해 recall과 지연을 함께 비교합니다. 공개 검색엔진의 내부 벡터와 점수는 이 방식으로 확인할 수 없습니다.
자주 묻는 질문
RAG를 만들려면 벡터 데이터베이스가 필수인가요?
아닙니다. 키워드 검색, 벡터 검색, 두 방식을 조합한 검색 등 여러 구현이 가능합니다. 벡터 데이터베이스는 의미로 검색하는 방식을 대규모로 빠르게 처리할 때 유리한 선택지이지 전제 조건이 아닙니다.
일반 데이터베이스로는 안 되나요?
되는 경우가 많아졌습니다. PostgreSQL의 pgvector처럼 기존 DB에 벡터 검색을 얹는 확장이 성숙해서, 규모가 아주 크지 않다면 쓰던 DB에 벡터 기능을 더하는 선택이 흔합니다. 전용 제품은 대규모와 고성능 요구에서 강점이 있습니다.
벡터 검색 결과는 정확한가요?
exact k-NN은 모든 후보를 비교할 수 있고, ANN은 속도를 얻는 대신 가까운 결과 일부를 놓칠 수 있습니다. 어떤 방식을 쓰는지와 재현율, 지연을 실제 데이터로 확인해야 합니다.
마케터가 이 용어를 알아야 하나요?
사내 검색과 RAG를 도입하거나 공급사를 검토할 때 임베딩 모델, 필터, 재현율과 응답 시간을 묻는 데 필요합니다. 콘텐츠만 만드는 역할이라면 내부 구조를 이해하는 배경 지식으로 충분합니다.
함께 알아두면 좋은 용어
- 임베딩: 벡터 데이터베이스에 저장되는 표현
- 청킹: 저장 단위를 만드는 전처리
- RAG: 벡터 데이터베이스가 선택적으로 쓰이는 구조
- 시맨틱 검색: 이 인프라가 가능하게 하는 검색 방식