벡터 저장 비용은 디스크 가격만 보지 않으면 잘못 판단하기 쉽습니다. 인덱스 구조, 복제, 메타데이터, 백업, 재색인, 그리고 검색 성능을 유지하기 위한 메모리 사용량까지 함께 봐야 합니다.
개요 #
벡터 저장 비용은 크게 네 가지로 나눌 수 있습니다.
- 원본 데이터 저장 비용
- 벡터와 인덱스 저장 비용
- 운영과 복구를 위한 복제 및 백업 비용
- 검색 지연을 줄이기 위한 메모리 비용
Qdrant, Qdrant Cloud, pgvector는 같은 벡터 검색 문제를 다루지만 비용 구조는 다릅니다. managed service는 운영 부담이 적고, self-host는 세밀한 제어가 가능하지만 운영 비용이 붙습니다.
왜 중요한가 #
벡터 DB는 데이터가 쌓일수록 단순 저장소가 아니라 운영 시스템이 됩니다.
- 문서 수가 늘수록 인덱스와 메타데이터가 같이 커집니다
- 임베딩 차원이 높을수록 저장량이 늘어납니다
- 고성능 검색을 위해 메모리를 더 쓰게 됩니다
- 복제와 백업은 안전하지만 고정 비용을 만듭니다
RAG 서비스가 커질수록 “어떤 벡터를 얼마 동안 저장할지"가 곧 비용 전략이 됩니다.
비용 구조 #
| 항목 | 비용에 미치는 영향 |
|---|---|
| Vector count | 문서 수와 chunk 수에 비례 |
| Dimension | 차원이 높을수록 저장량 증가 |
| Index overhead | HNSW 같은 인덱스 구조 비용 |
| Metadata | 필터링용 필드가 많을수록 증가 |
| Replication | 가용성 때문에 비용 상승 |
| Backups | 장기 보관 정책에 따라 증가 |
| Memory | 성능 유지를 위한 상주 비용 |
Hybrid Search나 reranking을 같이 쓰면 벡터만 저장할 때보다 저장해야 할 메타데이터가 더 중요해집니다.
아키텍처 도식 #
저장 비용을 줄이려면 저장 계층을 분리해서 봐야 합니다.
- 원문과 chunk를 분리합니다
- 오래 안 쓰는 데이터는 cold storage로 보냅니다
- 필터링에 필요한 최소 메타데이터만 유지합니다
- 재색인 비용을 감안해서 chunk 정책을 고정합니다
- managed service와 self-host 비용을 비교합니다
Qdrant Cloud는 운영을 단순화하고, pgvector는 기존 PostgreSQL 스택과 묶을 수 있습니다. 어떤 쪽이 싸냐보다, 현재 트래픽과 팀 운영 능력에 맞는지가 더 중요합니다.
체크리스트 #
- 벡터 차원을 줄일 수 있는지 검토합니다
- 중복 chunk를 저장하지 않습니다
- 복제와 백업 정책을 숫자로 확인합니다
- 오래된 임베딩을 재사용할 수 있는지 봅니다
- 필터 메타데이터를 과하게 늘리지 않습니다
- 재색인 주기를 운영 계획에 넣습니다
- managed vs self-host 총비용을 비교합니다
결론 #
벡터 저장 비용은 스토리지 가격보다 운영 패턴에서 더 크게 갈립니다. 데이터 수명, 인덱스 크기, 복제 정책, 메모리 사용량을 함께 봐야 실제 비용을 줄일 수 있습니다.