IVFFlat 인덱스에서 재현율이 서서히 떨어진 사례를 되짚어보면, 원인은 probes 값이나 메모리가 아니라 증분 삽입 구조에 있었다. 정적 코퍼스에는 IVFFlat이 빌드 비용과 메모리에서 유리하지만, 데이터가 계속 들어오는 환경에서는 HNSW가 재현율을 더 안정적으로 유지한다. 2026년 기준 pgvector에서 인덱스를 고를 때는 재현율·지연·빌드 비용·메모리를 하나의 지표로 뭉뚱그리지 말고 각각 따로 측정해야 한다.
IVFFlat 재현율 저하, 원인은 어디에 있었나?
원인은 인덱스 파라미터가 아니라 IVFFlat의 클러스터 구조가 삽입 이후 데이터 분포와 어긋난 데 있었다. 클러스터(lists)는 인덱스 생성 시점의 데이터 분포로 고정되는데, 이후 들어온 벡터가 다른 분포를 가지면 검색이 엉뚱한 클러스터만 훑게 된다.
- IVFFlat은 빌드가 빠르고 메모리를 덜 쓰지만, 쿼리 성능과 재현율은 HNSW보다 낮다는 점이 공식 문서에서도 명시돼 있다Azure Cosmos DB for PostgreSQL 문서
- AWS 실측에서는 검색 지연이 HNSW 약 1.5ms, IVFFlat 약 2.4ms, sequential scan 약 650ms로 나타났다AWS Database Blog
- 같은 자료에서 IVFFlat 빌드는 약 15초, HNSW는 약 81초였고, 이후 버전 최적화로 HNSW 빌드가 30초로 줄었다
- IVFFlat은 데이터가 계속 변하면 재구축·재튜닝 부담이 커지고, HNSW는 증분 삽입에 더 자연스럽다는 경험적 정리가 반복적으로 나온다
증상은 순차적으로 나타났다. 초기에는 정적 코퍼스에 IVFFlat을 적용해 문제가 없었다. 이후 신규 문서가 매일 대량으로 인입되기 시작하면서 검색 응답의 재현율이 눈에 띄게 떨어졌고, 같은 쿼리에도 상위 결과가 흔들리는 현상이 관찰됐다.
probes 값을 올리면 해결됐을까?
아니다. probes를 높이면 재현율은 소폭 개선됐지만 지연이 비례해서 늘었고, 근본 문제는 사라지지 않았다. IVFFlat은 lists와 probes 튜닝에 민감해서, probes를 올리는 쪽으로만 대응하면 검색 비용이 quadratic하게 늘어나는 방향으로 가게 된다. 재현율 저하의 원인이 클러스터 분포 자체에 있었기 때문에, probes 조정은 증상만 완화할 뿐 데이터 분포와 클러스터 경계의 불일치는 해결하지 못했다.
lists 재구축이 원인이었을까?
부분적으로는 맞지만 전체 원인은 아니었다. lists 값을 원래 데이터 규모에 맞춰 재계산하고 인덱스를 재구축하면 재현율이 일시적으로 복구됐다. 하지만 신규 데이터가 계속 들어오는 구조에서는 재구축을 주기적으로 반복해야 했고, 이는 운영 비용을 인덱스 생성 시점마다 반복적으로 지불하는 구조였다. 즉 lists 재구축은 원인에 대한 처방이 아니라 증상 재발을 늦추는 임시 조치였다.
메모리 부족이 지연을 만들었을까?
아니다. 메모리 사용량 자체는 IVFFlat이 HNSW보다 낮게 유지됐고, 지연 문제의 원인은 메모리가 아니라 검색 단계에서 잘못된 클러스터만 스캔하는 구조였다. 메모리·디스크 절감 관점에서는 IVFFlat이나 halfvec 같은 quantization이 여전히 유리했지만AWS Database Blog, 그것이 재현율 저하를 설명하지는 못했다.
실제 원인은 어디에 있었나?
원인은 IVFFlat의 클러스터 구조가 정적 데이터 분포를 전제로 설계돼 있다는 점이었다. 증분 삽입이 지속되는 워크로드에서는 클러스터 경계가 실제 데이터 분포와 계속 어긋나고, 이는 probes나 lists 조정으로는 근본적으로 해소되지 않는 구조적 한계였다.
무엇을 바꿔서 재발을 막았나?
증분 삽입이 있는 컬렉션은 HNSW로 전환하고, 정적 스냅샷 코퍼스에만 IVFFlat을 남겼다. HNSW는 ef_search 튜닝에 대해 재현율이 비교적 안정적으로 유지되고, 기본값 근처에서도 충분한 정확도를 보인다는 점이 전환 근거였다. 빌드 비용 증가는 병렬 워커와 quantization으로 상당 부분 상쇄됐다.
이 사례에서 다른 시스템에도 적용할 수 있는 교훈은?
인덱스 선택 기준을 "빌드가 빠른가, 검색이 빠른가" 두 축으로만 보지 말고 "데이터가 정적인가, 계속 들어오는가"를 먼저 물어야 한다는 것이다. 정적 데이터에는 빌드·메모리 우위가 있는 구조가 유리하지만, 분포가 계속 바뀌는 데이터에는 재현율을 유지하는 구조를 우선해야 한다. 이는 pgvector뿐 아니라 클러스터링 기반 인덱스 전반에 적용되는 원칙이다.
핵심 정리
- IVFFlat 재현율 저하의 원인은 파라미터가 아니라 증분 삽입과 정적 클러스터 구조의 불일치였다
- AWS 실측 기준 검색 지연은 HNSW 약 1.5ms, IVFFlat 약 2.4ms였고, 빌드는 IVFFlat이 더 빨랐다
- probes·lists 조정은 증상 완화용 임시 조치일 뿐 구조적 원인을 해결하지 못한다
- 증분 삽입이 지속되는 컬렉션은 HNSW, 정적 스냅샷 코퍼스는 IVFFlat이라는 기준이 유효하다
- 인덱스 선택은 재현율·지연·빌드 비용·메모리를 각각 별도로 측정한 뒤 결정해야 한다
더 알아보기
벡터 검색 설계의 핵심 판단축: 재현율, 지연, 비용의 균형 — 이 주제의 종합 가이드