Amazon Aurora PostgreSQL에서 pgvector 0.8.0 기반 프로덕션 RAG 운영 전략

인덱스 전략 및 유사도 함수

프로덕션 RAG 워크로드에서는 HNSW 인덱스가 기본 선택지로 권장된다. HNSW는 다층 근접 그래프를 활용해 빠른 쿼리 성능과 점진적 삽입을 지원하지만, IVFFlat 대비 빌드 시간과 메모리 소모가 크다. IVFFlat은 빌드 비용이 적으나 데이터 변경 시 재현율 저하로 재훈련이 필요해 대규모 정적 코퍼스에 적합하다.

유사도 연산자는 텍스트 임베딩의 경우 **코사인 유사도(<=>)**가 기본값이다. 단위 정규화 벡터라면 **음의 내적(<#>)**이 더 빠르며, 시맨틱 검색에는 **L2 거리(<->)**가 부적합하다. 소규모 데이터(1만~5만 벡터)나 Ring 엔지니어링 사례처럼 1,000억~2,000억 규모의 임베딩을 사용자별 파티션으로 분산할 때는 병렬 순차 스캔이 대안이 될 수 있다.

pgvector 0.8.0 주요 기능 및 설정

pgvector 0.8.0의 Iterative Index Scan은 과도한 필터링(overfiltering) 문제를 해결한다. 프로덕션 환경에서는 정확도와 속도 균형을 고려해 relaxed_order 모드를 권장한다. 기본 구성 시 HNSW 인덱스 파라미터는 AWS 권장치인 m=16, ef_construction=128을 적용하며, 쿼리 시 hnsw.ef_search는 기본값 40보다 높은 100 이상으로 튜닝해야 재현율을 확보할 수 있다.

확장성 및 메모리 관리

메모리 효율을 위해 halfvec(16-bit) 양자화를 적용하면 메모리 사용량을 50% 절감하면서 재현율 손실을 최소화할 수 있다. RAM 초과 시 Aurora Optimized Reads를 활용해 NVMe 계층형 캐시로 유효 캐시 용량을 최대 5배까지 늘리고 읽기 지연을 최대 8배 감소시킬 수 있다. 다만, 이는 r6gd/r8gd/r6id 인스턴스 또는 Aurora I/O-Optimized 클러스터에서만 지원된다.

데이터 삭제나 업데이트로 인한 Churn 관리는 중요하다. HNSW는 제자리 압축을 지원하지 않으므로, 저트래픽 시간에 REINDEX CONCURRENTLY를 실행하거나 파티션 기반 재구축 전략을 사전에 계획해야 한다. HNSW 인덱스는 RAM 상주가 필수이며, 디스크 스필 시 지연이 급증하므로 메모리 최적화 r-시리즈 인스턴스 선택이 필요하다.

관측성 및 리소스 정리

운영 안정성을 위해 쿼리 통계, 인스턴스 지표, 대기 이벤트, 커스텀 지표 등 4계층 관측성을 확보해야 한다. BufferCacheHitRatio가 99% 이상 유지되는지 확인하고, SwapUsage가 0인지 모니터링한다. ReadIOPS가 지속적으로 높으면 인덱스 스필을 시사하므로 주의해야 한다. 또한, 고정 평가 쿼리를 통해 재현율 하락을 추적하고, p99 지연시간을 모니터링해 테일 지연을 관리한다.

과도한 연결 풀은 work_mem 소진을 유발하므로 Amazon RDS Proxy를 활용한다. 테스트 종료 후에는 documents 테이블, 인덱스, vector 확장 및 수동 스냅샷을 명시적으로 삭제해 불필요한 스토리지 비용을 방지해야 한다.