벡터 데이터베이스 확장 방법: 병목별 완화 순서
벡터 데이터베이스 확장 방법은 재설계 전에 병목을 진단하고 데이터 정리, 압축·차원 축소, 검색 조정과 증설 방식을 비교합니다. 지표로 검증해 가장 작은 변경부터 고르고, 운영 부담이 크면 매니지드 벡터DB도 평가합니다.
벡터 데이터베이스를 확장하는 팀은 관측된 병목에 맞춰 가장 작은 변경부터 시험하면 됩니다. 저장 공간, 상주 메모리, 색인 갱신과 검색 지연을 나누어 측정하고 조치 전후의 품질과 복구 조건을 함께 기록합니다. 초기 용량 추정보다 현재 구조에서 병목을 완화할 순서에 집중합니다.
핵심 요약
재설계 전 벡터DB 확장 선택
- 병목부터 분리합니다: 저장 공간, 상주 메모리, 인덱스 구축·갱신, 검색 지연을 같은 조건에서 측정합니다.
- 데이터를 먼저 정리합니다: 필요한 현재·이력 문서를 보존하고, 중복·만료 후보의 검색 제외와 삭제 조건을 검증합니다.
- 메모리에는 압축을 시험합니다: 양자화와 차원 축소를 같은 질의셋의 재현율과 지연으로 비교합니다.
- 증설 방식은 증상에 맞춥니다: 노드 증설, 샤딩, 복제본은 각각 수용량과 처리량에 미치는 영향을 따져 고릅니다.
- 운영 범위까지 바꿀 때 매니지드를 평가합니다: Seahorse Database는 Seahorse Cloud의 내장 컨트롤 플레인, 테이블·스키마 관리와 실시간 모니터링을 갖춘 벡터 데이터베이스 구성요소입니다.
먼저 벡터DB 스케일링 병목을 분리합니다
벡터 수와 저장소 사용량은 같은 숫자가 아닙니다. 운영 대시보드에서는 원시 벡터·메타데이터·인덱스의 저장 공간, 노드별 메모리, CPU·디스크 사용률, 인덱스 구축·갱신 시간, 질의 지연을 각각 따로 기록합니다.
p50은 절반의 요청이 그 지연 시간 안에 끝나는 지점이고, p95와 p99는 각각 95%와 99% 요청의 지연 시간을 보여 주므로 꼬리 지연도 드러납니다.
지연 시간과 QPS는 동일한 부하와 동시성에서 측정하고 timeout·오류율도 함께 기록합니다. 비교 조건에는 워밍업 여부, 캐시 상태와 반복 횟수를 남겨 결과를 재현할 수 있게 합니다.
근사 최근접 이웃 검색(Approximate Nearest Neighbor, ANN)은 가까운 후보를 빠르게 찾는 검색 방식입니다. ANN 재현율(recall@k)은 근사 검색이 정확 검색의 상위 k개를 얼마나 충실히 찾는지 나타내며, 문서의 관련성이나 생성 답변의 정확도와는 별도입니다.
같은 벡터 집합, 거리 함수, 필터와 질의 조건에 맞는 정확 검색 결과를 기준으로 계산합니다. 필터가 다르면 각 필터 조건에 맞는 exact ground truth를 각각 구합니다. 예를 들어 정확 검색 결과 10개 가운데 ANN 결과에 9개가 있으면 recall@10은 0.9입니다.
2018년 ANN-Benchmarks 평가 프레임워크는 전처리 뒤 인덱스 크기와 구축 시간, 질의 시간과 거리 계산 수를 측정하고, 재현율과 초당 질의 수(QPS)의 관계로 성능을 비교합니다.
| 관찰한 증상 | 함께 기록할 값 | 다음에 시험할 조치 |
|---|---|---|
| 디스크 용량이 빠르게 증가합니다 | 원시 벡터, 메타데이터, 인덱스, 복제본의 크기 | 중복·만료 데이터 정리, 압축, 저장 계층 분리 |
| 메모리가 먼저 찹니다 | 인덱스 상주 메모리와 최대 사용 시점 | 양자화, 차원 축소, 메모리 증설 |
| 검색이 느립니다 | p50·p95·p99, QPS(초당 질의 수), recall@k, 동시 요청 수 | 검색 설정과 필터 범위 시험 |
| 구축·갱신이 오래 걸립니다 | 구축 시간, 입력량, 갱신 대기열, 작업 중 자원 사용량 | 인덱스 설정과 갱신 작업량 검토 |
표에서 가장 먼저 한계에 닿는 자원에 따라 뒤의 선택 분기로 이동합니다. 메모리에 여유가 있고 p95 지연이 목표보다 높으면 검색 지연 분기를 먼저 택합니다. p95 지연이 목표 안에 있고 메모리가 먼저 차면 압축, 차원 축소와 메모리 증설을 비교합니다.
검색에 불필요한 데이터부터 정리합니다
첫 조치는 중복 수집을 막고 업무·보존 기준을 확인한 레코드만 정리하는 것입니다. 같은 원본 문서가 중복 수집됐는지, 교체된 문서의 과거 임베딩이 남았는지, 보존 기간이 끝난 레코드가 검색에 계속 참여하는지 확인합니다. 문서가 비슷하다는 이유만으로 합치지 말고, 업무상 서로 다른 버전이나 테넌트에 속하는지 먼저 구분합니다.
삭제 후보 목록은 원본 문서 ID, 버전, 임베딩 ID, 테넌트, 삭제 사유와 보존 조건을 연결해 만듭니다. 일반적인 내용 갱신에서는 해당 문서에서 생성한 임베딩과 메타데이터를 추적하고, 새 버전 벡터가 준비된 뒤 구버전을 정리하는 전환 방식을 사용할 수 있습니다.
반면 권한 회수나 자료 철회는 새 색인 준비를 기다리지 말고, 먼저 해당 자료에 대한 접근과 검색 노출을 차단했는지 검증합니다. 법적·업무상 보존 기간이 적용되는 레코드는 검색에서 제외할 정책과 물리 삭제 정책을 따로 결정합니다.
삭제 전에는 후보 ID의 검색 결과, 원본 문서 링크와 문서 버전 대응을 표본 검사합니다. 그 뒤 작은 배치로 정리하고 같은 대표 질의를 다시 실행해 유효 문서가 남는지, 중복 결과가 줄었는지 확인합니다.
변경 기록에는 삭제 건수, 저장 공간 변화와 대표 질의의 검색 결과 차이를 남깁니다. 정리 후에도 디스크 사용량이 줄지 않으면 다른 병목이라고 단정하지 않습니다. 논리 삭제와 물리 공간 회수는 다를 수 있고, tombstone 정리·compaction, 스냅샷, 복제본, 보존 정책에 따라 회수가 지연될 수 있습니다. 해당 제품의 삭제 후 공간 회수 동작과 실패 여부를 먼저 확인한 뒤 다음 병목을 판단합니다.
벡터 검색 최적화: 메모리가 병목이면 표현을 줄입니다
메모리가 병목일 때는 벡터를 압축하는 양자화(quantization)를 먼저 작은 범위에서 시험할 수 있습니다. 양자화는 벡터 표현을 더 적은 정보로 저장하는 방식이며, 정확도나 재현율의 변화와 맞바꾸어 메모리를 아낄 수 있습니다. 실험에서는 운영에 사용할 데이터베이스와 인덱스 설정을 고정하고 압축 옵션 한 가지씩 비교합니다.
계층적 탐색 가능 소세계 그래프(Hierarchical Navigable Small World, HNSW) 인덱스를 다루는 Weaviate의 리소스 관리 가이드에서 벡터 압축은 일부 정확도 손실과 맞바꾸어 질의 속도를 높이고 메모리 사용을 줄이는 선택지입니다. 이 가이드에서 Product Quantization(PQ)은 각 벡터를 정수 기반 중심값 배열로 바꾸고, Scalar Quantization(SQ)은 각 차원을 정수로 표현하며, 두 방식 모두 HNSW 인덱스용으로 제시됩니다. Weaviate는 인덱스 유형이나 압축 방식을 바꿀 때 충분히 시험하도록 권고합니다.
차원 축소는 압축과 달리 임베딩 공간의 표현 자체를 바꾸므로 검색 결과와 이웃 관계에 영향을 줄 수 있습니다. 실제 임베딩 모델과 대표 질의·필터로 품질을 검증하고, 문서와 질의 벡터에는 서로 호환되는 동일한 변환을 적용합니다. 모델이 지원하지 않는 변환으로 임의 차원 절단을 해서는 안 됩니다. 영향받는 인덱스의 재구축과 전환 중 이중 운영에 필요한 시간·저장 비용도 비교합니다.
먼저 압축만 적용해 메모리 사용량과 recall@k의 변화를 측정합니다. 양자화 검색 결과를 원본 벡터로 재점수화하는 옵션을 쓴다면, 원본 벡터 보관에 필요한 저장 공간도 포함합니다. 별도 차원 축소 실험에서는 같은 평가셋으로 검색 결과와 품질 변화를 비교합니다.
벡터 인덱스 최적화: 검색 지연이 병목이면 탐색량을 조정합니다
검색 지연이 주된 병목이면 인덱스를 다시 만들기 전에 검색 시점의 설정부터 조정합니다. 탐색량을 조정할 수 있는 인덱스에서는 질의 때 살펴볼 후보 수를 설정값으로 시험합니다. 탐색량을 늘리면 높은 재현율을 얻을 수 있지만 QPS가 떨어질 수 있으므로, 처리량과 recall@k를 함께 봅니다.
앞서 연결한 2018년 ANN-Benchmarks 연구는 GLOVE 데이터셋에서 코사인 유사도를, SIFT 데이터셋에서 유클리드 거리를 사용하고 10개와 100개 최근접 이웃 질의를 각각 평가합니다. 제품 코드처럼 정확한 식별자가 중요한 질의와 주제 탐색처럼 의미상 유사한 결과가 중요한 질의를 평가셋에서 따로 표시합니다.
실험표에는 조정값과 함께 그 값이 검색 실행이나 인덱스 생성 중 어느 단계에 적용되는지 기록합니다. 인덱스 생성 설정을 바꾸는 시험에서는 새 인덱스의 구축 시간·크기, 작업 중 자원 사용량과 갱신 대기열을 비교하고, 갱신 중에도 질의 서비스가 목표를 지키는지 확인합니다.
접근 패턴에 맞춰 검색 범위와 저장 계층을 나눕니다
고객, 문서 유형이나 기간을 조건으로 거는 질의가 많다면 해당 데이터베이스가 지원하는 메타데이터 필터를 후보로 시험합니다. 같은 기본 질의를 필터 없이, 그리고 실제 필터 조건을 적용해 실행해 필요한 문서가 결과에 남는지 확인합니다. recall@k는 필터 적용 여부와 각각의 검색 대상에 맞는 exact ground truth를 기준으로 산출합니다. 두 경우의 결과 수, recall@k, p95 지연과 메모리 사용량을 비교합니다.
파티셔닝(partitioning)은 데이터를 구간이나 그룹별로 나누는 방식이며, 실제 질의 경계와 맞을 때 후보가 됩니다. 예를 들어 모든 검색 요청이 고객 ID를 포함한다면 고객별 데이터 분할을 시험할 수 있습니다. 전 기간을 가로지르는 질의가 흔하면 대표 질의에 최신 자료와 이력 자료를 함께 포함하고 두 범위에서 필요한 문서가 검색되는지 확인합니다. 먼저 필터 조건으로 검색 품질과 지연을 측정하고, 데이터베이스가 파티셔닝을 지원하며 검색 경계가 잘 맞을 때 분할 구성을 별도 후보로 비교합니다.
Weaviate의 리소스 관리 가이드는 hot 계층을 활성 상태의 메모리 기반 HNSW 인덱스로 분류하며 성능은 가장 빠르고 비용은 높다고 표시합니다. 같은 표에서 warm 계층은 활성 상태의 SSD 저장과 flat 인덱스로, hot보다 느리고 비용은 중간으로 정리됩니다.
Apache Doris의 로컬 티어드 스토리지 문서는 자주 접근하는 최근 파티션을 SSD의 hot 데이터로, 덜 읽는 과거 파티션을 대용량·저비용 HDD의 cold 데이터로 구분하고 쿨다운 시간이 지나면 SSD에서 HDD로 옮기는 절차를 설명합니다. 검색 지연을 낮춰야 하는 데이터와 접근 빈도가 낮아 저장 비용을 줄이려는 데이터를 사용 패턴에 따라 나누고, 각 그룹의 검색 요구를 먼저 정합니다.
Weaviate의 표에서 cold 계층은 클라우드 저장소의 비활성 데이터이며 자원을 사용할 수 없는 상태로 표시됩니다. 이력 데이터도 업무상 검색 대상이라면 온라인 질의 경로에 해당 자료를 포함하고 요구되는 응답 시간을 정합니다. 최신 자료와 과거 자료를 별도 인덱스나 계층에 두는 경우, 두 시기의 문서를 함께 묻는 질의로 결과의 누락과 순위를 확인합니다.
노드 수용량이나 읽기 요청량에 맞춰 확장 방식을 평가합니다
수직 증설(vertical scaling)은 한 노드에 배정하는 메모리나 저장 용량을 늘리는 선택입니다. 현재 제품이 지원하는 노드 규모와 운영 예산 안에서 기존 데이터로 시험할 수 있습니다. 데이터나 인덱스의 노드별 수용 목표를 한 노드 구성이 충족하지 못하면 분산 구성을 다음 후보로 평가합니다.
샤딩(sharding)은 데이터와 인덱스를 여러 조각으로 나누어 배치하는 방식입니다. 주요 필터가 샤드 경계와 맞는지, 데이터가 한쪽 조각에 몰리는지, 재배치와 복구를 맡을 운영 역량이 있는지 함께 확인합니다.
복제본(replica)은 같은 데이터의 사본을 유지하는 분산 구성입니다. 읽기 요청 분산이나 가용성이 목표라면 제품의 복제 설정이 해당 용도를 지원하는지 확인하고, 읽기 라우팅이 제공될 때 동시 질의 처리량과 응답 시간을 측정합니다. 복제본이 보관하는 데이터와 인덱스의 범위를 확인하고, 사본을 추가했을 때 늘어나는 저장량을 증설 예산에 포함합니다. 쓰기와 인덱스 갱신이 각 복제본에 반영되는 방식도 동일한 운영 시험에서 확인합니다.
| 필요한 변화 | 먼저 볼 선택지 | 결정에 필요한 시험 |
|---|---|---|
| 한 노드의 메모리·저장 한계 | 더 큰 노드 또는 메모리·디스크 증설 | 같은 데이터와 부하에서 지연, 구축 시간, 비용 비교 |
| 노드별 데이터·인덱스 배치 한계 | 샤딩 | 제품의 샤드 배치 지원, 단일·다중 조각 질의, 재배치 부담 확인 |
| 읽기 요청 분산 또는 가용성 목표 | 복제본 | 제품의 복제·읽기 동작, 동시 질의 처리량, 복제 저장량, 갱신 반영 확인 |
샤딩과 복제본은 대체 관계가 아닙니다. 제품이 두 기능을 함께 지원하면 샤딩과 복제를 한 구성에서 조합할 수 있습니다. 다만 두 방식을 동시에 변경하면 성능 차이의 원인을 찾기 어려우므로, 우선 병목 하나에 맞는 설정을 시험하고 결과를 저장한 뒤 다음 변경을 추가합니다.
운영 부담을 바꾸려면 매니지드 벡터DB를 평가합니다
매니지드 벡터DB는 데이터베이스 관리 기능과 운영 책임을 공급자와 사용자 조직 사이에 배분하는 선택입니다. 용량 증설이 시급하다면 먼저 현재 제품에서 메모리, 검색 설정, 저장 범위와 노드 구성을 검증합니다. 동시에 테이블·스키마 관리와 모니터링을 내부에서 직접 운영할지, 관리형 플랫폼의 기능을 사용할지 평가할 수 있습니다.
Seahorse Cloud의 벡터 데이터베이스는 내장 컨트롤 플레인을 갖춘 컨테이너 기반 매니지드 벡터 데이터베이스입니다. Seahorse Cloud 제품 페이지에는 테이블·스키마 관리와 실시간 모니터링이 기능으로 제시되어 있습니다. 이런 기능은 테이블과 스키마를 관리하고 운영 상태를 확인하는 도구를 찾는 팀의 평가 기준에 맞습니다. 플랫폼 검토에서는 필요한 테이블 구조와 모니터링 작업을 실제 운영 절차에 대입해 확인합니다.
Seahorse Cloud는 온프레미스 설치 또는 SaaS 구독으로 이용할 수 있습니다. 선택한 서비스의 전달 방식, 데이터 호스팅 위치, 운영 책임과 계약 조건을 각각 정리합니다. 개발팀은 필요한 연결 방식, 접근 통제와 인증, 테넌트 분리, 배포 위치, 데이터 이관, 장애 대응과 유지보수 책임을 플랫폼 담당자와 함께 검토합니다.
운영 추적에는 민감 정보와 비밀값을 최소화하고, 목적에 맞는 접근 권한과 보존 기간을 둡니다. RAGOps는 검색 대상과 검색 설정을 다루고, AgentOps는 에이전트 실행 흐름과 도구 호출을 운영하므로 두 역할의 성과 지표를 나누어 봅니다. 검색, 모델 응답, 도구 실행과 전체 요청 시간을 따로 기록하면 병목이 검색 단계인지 에이전트 실행 단계인지 구분할 수 있습니다.
변경 후 벡터 데이터베이스 성능 개선을 검증합니다
초기 진단에서 만든 평가셋과 운영 지표를 모든 변경 전후에 그대로 사용합니다. 테스트 질의에는 자주 묻는 질문, 정확한 문서명이나 제품 코드, 오래된 문서, 필터를 사용하는 고객 질의를 포함합니다. 평가셋의 데이터·질의 버전, 거리 함수, 상위 k값, 필터와 실행 날짜를 기록해 조건을 재현할 수 있게 합니다.
각 시험은 한 가지 변경을 다룹니다. 진단 결과가 가리키는 후보 하나를 골라 시험하고, 그 결과에 따라 다음 변경을 선택합니다. 예를 들어 검색 지연은 목표를 만족하고 인덱스가 메모리 한계에 닿았다면 메모리 압축을 먼저 시험합니다. 필터 질의가 대부분인데 범위 조건이 반영되지 않는다면 검색 범위 조정을 우선 시험합니다.
각 변경은 병목 개선과 검색 품질 기준을 함께 충족할 때 채택합니다. 메모리나 저장 공간이 줄어들면서 recall@k가 정해 둔 최저 기준을 만족하는지, 검색 처리량 목표와 인덱스 구축·갱신 시간이 운영 일정을 충족하는지 확인합니다. 실행별 인덱스 크기, 구축 시간, 질의 지연과 변동을 기록해 평균 성능과 운영 안정성을 함께 판단합니다.
적용 전에는 이전 설정, 검색 평가셋, 삭제 후보 목록과 인덱스 생성 설정을 저장합니다. 지연이나 재현율이 기준을 넘으면 마지막으로 통과한 구성으로 되돌립니다. 삭제나 차원 축소처럼 원본 정보에 영향을 주는 작업은 원본 벡터 또는 임베딩 생성 경로를 보존하고, 시험 환경에서 복구 절차와 소요 시간·운영 단계를 확인합니다. 결정 기록에는 병목, 조치, 변경 전후 지표, 품질 기준, 되돌림 조건, 운영 책임자와 복구 담당자를 남기며, 복구 시 현재 권한을 유지하는 절차도 확인합니다. 다음 용량 검토에서 이 기록을 바탕으로 기존 구조 유지와 더 큰 아키텍처 변경 중 필요한 방향을 판단합니다.
관련 배경: Estimating Retrieval Capacity from Storage and Query Demand
문서와 검색 흐름을 직접 확인하세요
우리 조직의 문서와 평가 기준으로 필요한 기능을 확인해보세요.
