Embedding Storage Design은 “벡터를 어디에 넣을지"만의 문제가 아닙니다. 원문, chunk, metadata, embedding version, 재색인 시점까지 같이 설계해야 나중에 운영이 편합니다.
개요 #
벡터 저장 설계가 약하면 검색 품질이 갑자기 떨어지거나, 재색인할 때 전체 데이터를 다시 밀어넣어야 합니다. 이 문제는 규모가 커질수록 비용으로 바뀝니다.
Qdrant, Qdrant Cloud, pgvector를 쓸 때도 기본 아이디어는 같습니다. 벡터 자체보다 “벡터와 함께 저장하는 정보"가 나중에 운영 비용을 좌우합니다.
왜 중요한가 #
좋은 storage design은 다음을 줄여줍니다.
- 중복 embedding 생성
- 잘못된 version 혼재
- 불필요한 full reindex
- metadata 필터 폭발
- 저장소와 인덱스 비용 증가
Vector Storage Cost를 낮추고 싶다면 저장 구조부터 정리해야 합니다. 단순히 더 싼 저장소를 고르는 것보다, 어떤 데이터를 hot path에 둘지 결정하는 것이 먼저입니다.
선택 기준 #
저장 구조를 정할 때는 “지금 필요한 데이터"와 “나중에 다시 계산할 데이터"를 분리해야 합니다. source of truth를 vector DB 안에 모두 넣는 설계는 재색인과 비용에서 불리합니다.
운영/튜닝 포인트 #
설계할 때 보는 포인트는 다음입니다.
- 원문과 chunk를 분리 저장할지 여부
- embedding version을 metadata로 둘지 별도 컬럼으로 둘지
- tenant, namespace, collection 분리 방식
- 재색인 시 전체 교체 vs 증분 업데이트
- cold storage로 내릴 데이터의 기준
- filter 가능한 metadata의 최소 집합
검색 분포가 복잡하면 Hybrid Search와 같이 dense/sparse signal을 함께 저장하는 방식이 더 낫습니다. 품질 측정은 Retrieval Quality Metrics를 기준으로 확인해야 합니다.
아키텍처 도식 #
권장 구조는 다음과 같습니다.
- source document는 object storage 또는 document store에 둡니다.
- chunk와 embedding은 vector DB에 둡니다.
- metadata는 필터에 필요한 최소 값만 남깁니다.
- embedding version을 명시해 재색인을 추적합니다.
- old version은 즉시 지우지 말고 검증 후 제거합니다.
체크리스트 #
- 원문, chunk, embedding의 책임이 분리되어 있는가
- version mismatch를 탐지할 수 있는가
- 증분 재색인 흐름이 있는가
- metadata가 과하게 커지지 않는가
- storage cost와 retrieval quality를 같이 보는가
- cold data 정책이 정의되어 있는가
결론 #
Embedding Storage Design은 검색 품질과 운영 비용을 동시에 좌우합니다. 저장 구조를 먼저 잘 잡아두면 인덱스 튜닝과 운영이 훨씬 단순해집니다.