RDBMS 네이티브 벡터 인덱싱과 전용 벡터 DB의 선택 기준

2026년 들어 PostgreSQL 18, Oracle 26ai, SQL Server 2025가 모두 네이티브 벡터 인덱싱을 지원하기 시작했다. HNSW·IVF Flat·DiskANN이 범용 RDBMS 안으로 들어오면서, 벡터 검색은 독립 데이터베이스 카테고리보다 데이터 타입과 인덱스 기능에 가까운 형태로 수렴하고 있다.

이 변화는 RAG 파이프라인을 만들 때 별도 벡터 DB와 인프라를 추가하지 않고도 기존 SQL 환경을 활용할 수 있게 한다. 동시에 AI-on-Postgres 전략을 내세운 PostgresML·Hydra 같은 생태계는 기존 DB 벤더의 빠른 기능 흡수와 경쟁해야 하는 위치가 됐다.

벡터 기능을 품은 PostgreSQL·Oracle·SQL Server

PostgreSQL 자체에 벡터 타입이 내장된 것은 아니지만, pgvector 확장이 사실상 표준적인 선택지로 자리 잡았다. VECTOR 컬럼 타입과 HNSW 인덱스(CREATE INDEX ... USING hnsw), IVFFlat 인덱스를 제공하며 L2 거리·코사인 유사도·내적(Inner Product) 거리 함수를 지원한다. PostgreSQL 18의 병렬 쿼리 개선과 pgvector 0.8+의 scalar quantization 지원은 대규모 벡터 집합에서 인덱스 성능 개선과 맞물린다.

Oracle은 데이터베이스를 26ai로 리브랜딩하며 AI Vector Search를 추가 비용 없이 번들로 제공하기 시작했다. 인메모리 그래프 기반의 HNSW와 대용량 데이터에 적합한 디스크 기반 IVF를 지원한다. 이전 버전인 23ai에서 지원하지 않던 HNSW 인덱스 DML(INSERT/UPDATE/DELETE)이 26ai에 추가돼, OLTP 환경에서도 벡터 인덱스를 운용할 수 있게 됐다. VECTOR_EMBEDDING()으로 내부 임베딩 생성이 가능하고 SQL 안에서 LLM 호출과 RAG 파이프라인을 완결할 수 있다.

SQL Server 2025는 VECTOR 데이터 타입 및 DiskANN 기반 벡터 인덱스를 도입했다. Microsoft Research에서 개발한 디스크 최적화 ANN(Approximate Nearest Neighbor) 알고리즘을 적용해, 인메모리 HNSW보다 메모리 사용량을 크게 줄이면서 검색 속도를 제공한다. VECTOR_DISTANCE()와 T-SQL 통합으로 기존 쿼리 패턴에 벡터 검색을 넣을 수 있다.

인덱스 알고리즘이 만드는 운영상의 차이

⤢✕

HNSW(Hierarchical Navigable Small World)는 그래프 기반 알고리즘으로, 데이터셋 크기와 무관하게 O(log N) 검색 복잡도를 제공한다. 검색 품질(Recall)과 속도의 균형이 좋지만 인덱스를 메모리에 유지하므로 대규모 벡터 집합에서는 메모리 비용이 커진다. m(최대 연결 수)과 ef_construction(인덱스 빌드 탐색 폭)으로 recall과 빌드 속도를 조정한다.

IVF Flat(Inverted File Index)은 벡터 공간을 클러스터로 나눈 뒤, 질의와 관계있는 클러스터만 찾는다. HNSW보다 메모리 효율은 좋지만 nlist(클러스터 수)와 nprobe(검색 클러스터 수)를 조율해야 한다. nprobe를 낮추면 검색은 빨라지고 recall은 낮아진다.

DiskANN은 Microsoft Research의 Vamana 알고리즘을 토대로 디스크 I/O를 최적화한 ANN 구현이다. 수십억 규모 벡터를 인메모리 없이 처리할 수 있어 비용 효율이 높지만, HNSW보다 쿼리 지연시간은 다소 높다.

PQ(Product Quantization)는 벡터를 서브벡터로 나누고 각각을 코드북으로 압축한다. 저장 공간을 수십 분의 일로 줄이며, Pinecone은 이를 HNSW와 결합해 고속 검색과 압축 저장을 함께 구현한다.

검색 성능보다 먼저 봐야 할 선택 조건

항목	RDBMS 네이티브	전용 벡터 DB
검색 지연시간 p99	수십~수백 ms	7ms(Pinecone)
운영 복잡도	낮음(기존 RDBMS 활용)	높음(별도 인프라)
하이브리드 검색	제한적(별도 FTS 결합 필요)	네이티브(Weaviate BM25F 등)
ACID 트랜잭션	완전 지원	제한적
SQL 통합	완전 지원	API 기반
운영 비용	기존 라이선스 활용	추가 비용 발생
수평 확장성	수직 확장 중심	수평 확장 최적화

Pinecone의 p99 지연시간 7ms와 Milvus의 싱글 디짓 밀리초에 비하면 Elasticsearch·RDBMS 기반 벡터 검색은 수백 ms 수준으로 차이가 난다. 다만 대부분의 RAG 파이프라인에서는 수백 ms~수 초가 걸리는 LLM 추론이 병목이므로, 벡터 검색의 수십 ms 차이가 사용자 경험에 미치는 영향은 제한적이다.

대신 RDBMS는 운영 인프라를 단순하게 유지하고 SQL로 메타데이터 필터와 권한 제어를 결합할 수 있다. 벡터 검색이 기존 트랜잭션 데이터와 긴밀히 연결돼 있다면 이 장점이 단순 지연시간 차이보다 크게 작용할 수 있다.

SQL 안에서 구성하는 RAG 검색

-- PostgreSQL + pgvector RAG 구현 예시

-- (1) 문서 청크 저장 테이블
CREATE TABLE document_chunks (
    id          SERIAL PRIMARY KEY,
    doc_id      INTEGER REFERENCES documents(id),
    chunk_text  TEXT,
    embedding   VECTOR(1536),  -- text-embedding-3-small 기준
    created_at  TIMESTAMPTZ DEFAULT NOW()
);

-- (2) HNSW 인덱스 생성 (코사인 유사도 기준)
CREATE INDEX ON document_chunks
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- (3) 유사도 검색 + 메타데이터 필터 조합
SELECT c.chunk_text,
       1 - (c.embedding <=> $1::vector) AS similarity
FROM   document_chunks c
JOIN   documents d ON d.id = c.doc_id
WHERE  d.owner_id = $2          -- 권한 기반 필터
  AND  d.category = 'security'  -- 카테고리 필터
ORDER  BY c.embedding <=> $1::vector
LIMIT  5;

RDBMS를 RAG 벡터 저장소로 사용하면 기존 RDB의 메타데이터, 권한 관리, 트랜잭션 보장에 벡터 검색을 얹을 수 있다. WHERE 절에서 검색 결과를 메타데이터 기준으로 곧바로 걸러낼 수 있다는 점은 전용 벡터 DB와 구분되는 강점이다.

키워드와 의미 검색을 함께 다루는 방법

하이브리드 검색은 BM25 키워드 검색과 벡터 유사도 검색을 결합해 단일 검색으로는 얻기 어려운 높은 Recall을 목표로 한다. 키워드 일치가 중요한 사실적 질의와 개념 유사도가 중요한 의미론적 질의를 함께 처리하는 RAG 파이프라인에 적합하다.

PostgreSQL에서는 to_tsvector/to_tsquery 기반 FTS(Full Text Search)에 pgvector를 결합하고 RRF(Reciprocal Rank Fusion)로 결과를 합치는 방식이 일반적이다. Weaviate는 BM25F(필드 가중 BM25)를 네이티브로 지원하고 BlockMax WAND로 키워드 사이드를 10배 가속한다. Milvus 2.5+는 BM25 점수를 희소 벡터(sparse vector)로 저장해 단일 인덱스 구조에서 하이브리드 검색을 처리하며, Elasticsearch 대비 30배 지연시간 우위를 내부 테스트에서 측정했다. Qdrant v1.9+는 명명된 벡터(named vector)로 HNSW 조밀 벡터와 희소 역인덱스를 함께 보유하고, v1.15.2부터 서버사이드 IDF 계산을 지원한다.

RDBMS 기반 하이브리드 검색은 전용 벡터 DB보다 구현이 복잡할 수 있다. 그 대신 별도 인프라를 줄이고 기존 SQL 생태계와의 통합을 유지할 수 있다.

기존 데이터베이스에 벡터 기능을 넣는 흐름

먼저 PostgreSQL에서는 CREATE EXTENSION vector를 설치하고, Oracle 26ai·SQL Server 2025에서는 내장 타입을 활성화한다. 기존 테이블에 VECTOR 컬럼을 추가한 뒤 임베딩 생성 배치 작업을 실행한다. 초기 임베딩 생성에는 OpenAI text-embedding-3-small(1536차원) 또는 오픈소스 all-MiniLM-L6-v2(384차원) 모델을 활용한다.

인덱스가 만들어진 뒤에는 HNSW의 m, ef_construction, 검색 시 ef_search(탐색 폭), IVF의 nlist·nprobe를 워크로드에 맞춰 조정한다. Recall@10으로 파라미터를 최적화하면서 인덱스 빌드 시간과 검색 품질의 트레이드오프를 측정한다.

신규 문서가 INSERT될 때는 트리거나 애플리케이션 레이어에서 임베딩 API를 호출하고, 결과를 VECTOR 컬럼에 저장하는 파이프라인을 구성한다. 임베딩 모델을 바꾸면 전체 재임베딩 배치가 필요하므로 모델 버전 관리도 함께 설계해야 한다. 모델 버전과 차원 정보를 별도 메타데이터 컬럼에 저장하면 점진적 재임베딩이 가능하다.

RDBMS 네이티브 벡터 인덱싱은 SQL 통합, ACID 보장, 운영 단순성, 비용 효율을 우선하는 시스템에서 실용적인 선택지다. 단순 검색 지연시간과 수평 확장성이 가장 중요한 경우에는 전용 벡터 DB의 강점이 여전히 남는다. 기존 RDBMS 기반 시스템이라면 별도 벡터 DB를 도입하기 전에 pgvector·Oracle AI Vector Search·SQL Server DiskANN으로 RAG 파이프라인을 구성하고 성능 요구사항을 검증할 수 있다.