ef_search를 올리면 재현율은 오르지만, 어느 구간을 넘기면 지연이 완만한 증가에서 급격한 증가로 바뀐다. 1M 벡터급 실측에서 ef_search 40일 때 recall@10 0.72·지연 11.5ms였던 것이 ef_search 640에서는 recall@10 0.95·지연 68.28ms로 이동했다. pgvector는 중소 규모와 소프트 실시간 구간에서는 충분히 경쟁적이지만, 5M~50M 이상 규모나 빡빡한 p95 SLO 구간에서는 전용 벡터DB 쪽이 유리한 사례가 나온다.
ef_search를 키우는 것만으로 재현율 절벽을 넘을 수 있나?
넘을 수는 있지만, 그만큼 지연을 지불해야 한다. 낮은 탐색폭에서는 상위 k개 중 상당수를 놓치고, 그 놓친 결과가 고탐색폭 구간으로 갈수록 서서히 채워지는 게 아니라 초반 구간에서 급격히 회복된다.
- ef_search(또는 k) 40→640 구간에서 recall@10은 0.72→0.95, 지연은 11.5ms→68.28ms로 이동했다.opensearch
- recall@1을 0.90에서 0.97까지 올리면 지연은 36.8ms→71.5ms로 거의 두 배 늘었다.
- 1M 벡터·1536차원·inner product·m=32·ef_construction=80 조건에서는 ef_search=100으로 accuracy@10 0.99에 도달한 사례가 보고됐다.
- 같은 ef_search 값이라도 벡터 수·차원·m·ef_construction 조합이 다르면 절벽이 나타나는 위치 자체가 이동한다.
빠르게 갈지, 정확하게 갈지를 먼저 정해야 하는데, 이 축은 고정된 상수가 아니라 데이터 규모가 커질수록 함께 움직인다.
ef_search를 두 배로 올리면 지연도 두 배로 늘어나나?
아니다. 초반 구간에서는 지연 증가가 완만하지만, recall 0.90대 후반을 향할수록 증가폭이 커진다. k=240에서 34.96ms·recall 0.90, k=480에서 56.67ms·recall 0.93, k=640에서 68.28ms·recall 0.95로, k가 커질수록 recall 1%p를 더 얻는 데 드는 지연 비용이 늘어난다. AWS의 pgvector HNSW 사례는 반대로 ef_search를 20으로 고정한 채 동시성만 늘렸는데, db.m7g.16xlarge에서 32클라이언트 기준 25096 TPS까지 나왔다.AWS Database Blog 다만 이 수치는 recall을 함께 보지 않은 조건이라, "빠르다"는 결과만으로 RAG용 재현율을 판단할 수는 없다.
벡터 수가 늘어나면 pgvector의 재현율-지연 곡선은 어떻게 변하나?
규모가 커질수록 같은 recall을 유지하기 위한 인프라 요구가 커지고, 어느 지점을 넘으면 처리량을 올려도 recall이 오히려 떨어진다. Supabase의 1M 벡터 HNSW 벤치마크에서 2XL은 약 180 QPS에 recall@10 0.99, 4XL은 270 QPS에 0.99, 8XL은 470 QPS에 0.99였지만, 16XL은 약 1800 QPS까지 처리량이 늘어난 대신 recall@10이 0.91로 떨어졌다. 처리량과 재현율이 항상 같은 방향으로 움직이지 않는다는 뜻이다.
같은 recall 목표라도 인덱스 파라미터가 다르면 비교가 가능한가?
의미 있는 비교가 되지 않는다. ef_search 값만 놓고 비교하는 것은 조건을 지운 비교다. 10M 행·1536차원·r7g.4xlarge 조건에서 pgvector HNSW는 top-10을 8~15ms, 약 95% recall로 반환했다는 요약이 있지만, 5M 벡터 조건에서는 ef_search 설정에 따라 p95 지연이 80~140ms까지 벌어진다는 요약도 함께 존재한다. 같은 "pgvector HNSW"라는 이름 아래에서도 m, ef_construction, 하드웨어가 다르면 결과가 전혀 다른 그림이 된다.
실측 수치를 한 표로 정리하면 어떤 그림이 나오나?
| 조건 | ef_search/k | recall@10 | 지연 |
|---|---|---|---|
| OpenSearch 실험 | 40 | 0.72 | 11.50ms |
| OpenSearch 실험 | 240 | 0.90 | 34.96ms |
| OpenSearch 실험 | 640 | 0.95 | 68.28ms |
| pgvector(1M, Supabase 8XL) | ~100 | 0.99 | QPS 470 기준 |
| pgvector(1M, Supabase 16XL) | ~100 | 0.91 | QPS 1800 기준 |
| PostgreSQL 계열(50M, 99% recall) | 미공개 | 0.99 | p95 28ms |
표에서 보이는 것은 하나다. recall 0.9대 초반까지는 대부분의 설정이 감당하지만, 0.95 이상·대규모 QPS로 가는 순간부터 조건 하나하나가 결과를 뒤집는다.
pgvector에서 전용 벡터DB로 옮기면 실제로 드는 것은 무엇인가?
인덱스를 다시 만들어야 한다는 점이 가장 크다. HNSW 인덱스는 이식이 아니라 재구축 대상이며, ef_construction과 m을 새 시스템 기준으로 다시 잡아야 recall 곡선이 재현된다. 여기에 쿼리 인터페이스(SQL vs 전용 API) 전환, 재현율 회귀 테스트, 그리고 규모가 커진 상태에서 재현율-지연 곡선을 다시 실측하는 작업이 따라붙는다. ef_search 값 하나를 그대로 옮겨서는 같은 recall이 나오지 않는다.
그래서 ef_search 튜닝과 벡터DB 교체, 언제 무엇을 택해야 하나?
정답은 벡터 수·목표 recall·SLO 세 축의 조합에 있다. 벡터 수가 수백만 이하이고 recall 0.90대 초반이면 pgvector에서 ef_search를 올리는 쪽이 인프라 비용 대비 합리적이다. 반대로 recall 0.95 이상을 요구하면서 벡터 수가 5M~50M을 넘고 p95 SLO가 수십 ms 단위로 빡빡하다면, pgvector의 지연 곡선이 먼저 무너진다. 2026년 기준으로도 이 경계는 "전용 벡터DB가 항상 빠르다"는 단순 구도가 아니라, 조건별로 뒤집히는 경계로 남아 있다.
핵심 정리
- ef_search를 올리면 recall은 오르지만, 0.90대 후반 구간부터는 지연이 급격히 늘어나며 이것이 재현율 절벽으로 체감된다.
- 1M 벡터 기준 ef_search 40→640에서 recall@10 0.72→0.95, 지연 11.5ms→68.28ms로 이동한 실측이 있다.
- pgvector는 처리량을 올려도 규모(16XL, 1800 QPS 부근)에서 recall이 0.91까지 떨어지는 역전 구간이 나타난다.
- 벤치마크 비교에는 반드시 벡터 수·차원·m·ef_construction·하드웨어를 함께 명시해야 하며, ef_search 값만 놓고 비교하면 조건이 지워진다.
- 선택 기준은 "전용 벡터DB냐 pgvector냐"가 아니라 목표 recall·벡터 규모·p95 SLO의 조합이다.
더 알아보기
벡터 검색 설계의 핵심 판단축: 재현율, 지연, 비용의 균형 — 이 주제의 종합 가이드