Vector Database(벡터 DB)란? | GEO 용어집

벡터 데이터베이스(Vector Database)는 임베딩 벡터를 저장하고, '의미적으로 가장 유사한' 벡터를 빠르게 검색할 수 있도록 설계된 특수 데이터베이스입니다. RAG 파이프라인, 시맨틱 검색, 추천 시스템, AI 에이전트의 장기 기억 등 LLM 기반 제품의 핵심 인프라로 자리잡았습니다.

왜 중요한가

전통적인 SQL 데이터베이스는 '정확한 키워드 일치'에만 최적화되어 있지만, LLM 시대의 검색은 '의미 유사도'로 작동합니다. 수백만 개의 임베딩 벡터(각 1,000차원 이상) 중에서 '가장 가까운 k개'를 수 밀리초 안에 찾는 능력이 필요하고, 이것이 일반 DB로는 거의 불가능합니다. 벡터 DB는 근사 최근접 이웃(ANN) 알고리즘으로 이 문제를 풀어, LLM 응답의 기반이 되는 실시간 검색을 가능하게 만듭니다.

작동 원리

임베딩 생성: OpenAI, Cohere 등의 임베딩 모델로 텍스트·이미지를 벡터로 변환합니다.
인덱싱: HNSW, IVF, PQ 같은 ANN 알고리즘으로 벡터를 검색 최적 구조로 저장합니다.
쿼리 임베딩: 사용자 질의를 같은 모델로 벡터화합니다.
유사도 검색: 코사인 유사도·내적·유클리드 거리 기준으로 상위 k개 벡터를 반환합니다.
메타데이터 결합: 각 벡터에 연결된 원본 텍스트와 메타데이터를 함께 반환해 LLM 컨텍스트로 주입합니다.

대표 솔루션

전용 벡터 DB:

Pinecone: 관리형 서비스, 단순한 API, 빠른 시작
Weaviate: 오픈소스, 하이브리드(벡터+키워드) 검색 강점
Qdrant: Rust 기반, 고성능·낮은 리소스 사용
Milvus: 대규모 분산 벡터 검색

기존 DB의 벡터 확장:

pgvector: PostgreSQL 확장, 기존 SQL 데이터와 함께 관리 가능
Elasticsearch: 키워드 검색에 벡터 검색을 결합
Redis: 인메모리 벡터 검색

일반적으로 초기 단계에서는 pgvector로 시작해 트래픽과 규모가 커지면 전용 DB로 이전하는 패턴이 많습니다.

선택 기준

데이터 규모: 100만 벡터 이하면 pgvector로 충분합니다. 1억 벡터 이상이면 전용 DB가 필수입니다.

하이브리드 검색: 벡터+키워드+필터를 모두 써야 한다면 Weaviate·Elasticsearch가 유리합니다.

지연 시간: 사용자 대면 애플리케이션은 p99 100ms 이하가 목표입니다. 이때 HNSW 인덱스가 가장 안정적입니다.

운영 부담: 관리형 서비스(Pinecone)는 비용이 높지만 인프라 운영 부담이 거의 없습니다. 오픈소스(Qdrant, Milvus)는 반대입니다.

메타데이터 필터링: 카테고리·날짜·사용자 ID로 선제 필터링이 잦다면, 이를 벡터 검색과 효율적으로 결합하는 솔루션을 골라야 합니다.

GEO 관점의 함의

블로그 운영자가 직접 벡터 DB를 구축할 일은 드물지만, 자사 콘텐츠가 LLM·AI 검색 엔진의 벡터 DB에 '잘 저장되도록' 쓰는 것은 중요합니다. 명확한 헤딩, 자기 완결적 문단, 구체적 수치와 출처는 임베딩 품질을 높여 벡터 DB 내 유사도 검색에서 상위에 올라올 확률을 키웁니다.

Sources:

inblog에서 활용하기

inblog 블로그가 AI 검색 엔진에 자주 인용되려면 콘텐츠가 벡터 DB에서 '가장 관련성 높은' 결과로 뽑혀야 합니다. inblog 에디터에서 각 섹션이 독립적으로 완결되고 구체적 키워드·수치를 포함하도록 작성하면, 해당 문단의 임베딩 품질이 상승하고 RAG 파이프라인에서 인용 대상으로 선정될 확률이 높아집니다.

벡터 데이터베이스