벡터DB 경제학 재편: 오브젝트 스토리지 검색(Turbopuffer)과 OCR 없는 ColPali
Vector DB Economics & Late-Interaction Multimodal Retrieval (2026)
2026 벡터 검색은 '비용'과 '멀티모달' 두 축에서 흔들린다. 비용 축: 대량 코퍼스에서 메모리 상주형 전용 벡터DB는 비싸다. Turbopuffer는 벡터를 S3/GCS 오브젝트 스토리지(약 $0.02/GB)에 두고 자주 쓰는 데이터만 SSD($0.1/GB)로 캐싱해, 대형 문서 아카이브에서 압도적으로 싸지만 콜드 쿼리 지연(300~800ms)을 감수한다. 반대로 이미 Postgres를 쓰고 1천만~1억 벡터 미만이면 pgvector(+pgvectorscale)가 8~25ms p95에 월 $30 수준으로 가성비 1위, Qdrant는 하이브리드 검색·필터링(15~40ms), Pinecone은 가장 쉬운 매니지드지만 같은 규모에서 월 ~$180로 비싸다. 멀티모달 축: ColBERT 계열의 late interaction(쿼리 토큰×문서 패치를 MaxSim으로 매칭)을 비전 모델로 확장한 ColPali/ColQwen이 부상했다. PDF 페이지를 이미지(시각 패치 임베딩 그리드)로 바로 인코딩해 OCR을 통째로 건너뛰고, 표·차트·다이어그램·레이아웃을 보존한다 — OCR 파이프라인이 깨먹던 정보다.
벡터DB 선택을 '무조건 전용 DB'로 시작하는 건 비용 함정이다. 규모·지연 SLA·기존 스택(Postgres 여부)에 따라 pgvector→Qdrant→오브젝트 스토리지로 갈리며, 대부분의 초기 서비스는 pgvector로 충분하다. 더 큰 신호는 ColPali다: 한국어처럼 OCR 정확도가 떨어지는 문서나 표·도표가 많은 PDF를 다룬다면, OCR+청킹 파이프라인을 통째로 late-interaction 시각 검색으로 대체하는 선택지가 생겼다는 뜻이다. 다만 멀티벡터라 인덱스 용량·지연 비용이 크니 코퍼스 규모와 함께 저울질해야 한다.
원문 출처
Turbopuffer / daily.dev / Weaviate