전용 벡터 데이터베이스는 언제 필요한가

한 줄 요약

전용 벡터 데이터베이스는 벡터를 위해 설계된 저장소·필터·운영 도구를 준다. 그 대가로 데이터가 두 곳에 놓이고, 트랜잭션·조인·백업을 따로 챙겨야 한다. 어느 쪽이 싼지는 규모와 팀이 정한다.

왜 따로 두나

pgvector 로 충분한 자리가 많다. 수십만 건, 조건이 단순하고, 이미 PostgreSQL 을 운영하고 있으면 새 시스템을 들이는 비용이 더 크다. 그런데 세 가지가 겹치기 시작하면 달라진다 — 수천만 벡터, 까다로운 payload 필터, 그리고 벡터 검색이 서비스의 중심인 경우.

앞 모듈에서 본 필터 함정이 결정적이다. pgvector 의 HNSW 는 조건을 모르고 후보를 내놓는다. Qdrant 는 필터를 그래프 탐색 안에 넣는다. payload 인덱스로 조건에 맞는 점만 따라가고, 조건이 너무 좁으면 스스로 전수 검사로 바꾼다. 결과가 줄어드는 일이 없고, 부분 인덱스를 조건마다 만들 필요도 없다.

어떻게 생겼나

| 개념 | PostgreSQL 에서의 대응 | 다른 점 |
| --- | --- | --- |
| 컬렉션 | 표 | 벡터 크기와 거리 함수를 만들 때 정한다 |
| 점(point) | 행 | id + 벡터 + payload(JSON) |
| payload 인덱스 | 열 인덱스 | keyword·integer·geo 등 형이 있다 |
| scroll | 커서 | 정렬 없이 next_page_offset 으로 넘긴다 |
| 스냅샷 | pg_dump | 컬렉션 단위 파일 하나 |

전부 REST(6333)와 gRPC(6334)로 다룬다. curl 로 되는 일이 파이썬 클라이언트로도 되고, 반대로도 그렇다. 응답의 score 는 거리가 아니라 유사도라 클수록 가깝다 — pgvector 의 <=> 와 순위는 같고 숫자의 방향만 반대다.

검색은 상위 k 건만 돌려준다. "billing 범주의 점을 전부" 처럼 조건에 맞는 것을 다 훑어야 할 때는 scroll 이다. 정렬하지 않고 next_page_offset 을 따라 100건씩 넘기며, 마지막 페이지에서 그 값이 null 이 된다.

실무에서 진짜 중요한 것

첫째, 진실의 원본은 하나다. 벡터 DB 는 원본 데이터의 파생물이다. 문서가 바뀌면 벡터도 다시 만들어 넣어야 하고, 그 동기화 파이프라인이 사실상 운영의 전부다. Qdrant 에 문서 본문을 통째로 넣어 두면 두 원본이 생긴다 — payload 에는 필터와 표시에 필요한 것만 둔다.

둘째, 스냅샷은 만들었다고 끝이 아니다. 스냅샷 파일을 다른 곳에 옮기고, 새 컬렉션으로 복원해 점 수와 검색 결과가 같은지 확인하기 전까지는 백업이 아니다. 이 코스 환경은 볼륨이 없어서 세션이 끝나면 스냅샷도 사라진다 — 그게 "만들었다" 와 "보관했다" 의 차이다.

셋째, 같은 질의를 두 엔진에 던져 본다. 이전을 검토할 때 가장 정직한 근거는 벤치마크 문서가 아니라, 우리 데이터와 우리 질의로 두 엔진의 상위 10건이 얼마나 겹치는지다. 이 코스의 마지막 단계가 그것이다.

다음 실습에서 할 것

Qdrant 를 켜고 컬렉션을 만들어 2,000건을 payload 와 함께 넣은 뒤, 필터 검색·scroll·payload 인덱스·스냅샷을 거쳐 같은 질의를 pgvector 와 나란히 놓고 비교한다.