청킹 크기와 벡터DB 선택, 재현율·지연은 어디서 갈리는가?

결론부터 말하면 재현율은 청킹(크기·overlap)이 결정하고, 지연과 인덱스 비용은 벡터DB·인덱스 파라미터가 결정한다. 두 축은 독립적으로 움직이지 않고 곱해져 총 응답 비용을 만든다. 2026년 기준 실측을 보면 1M 벡터 전후까지는 pgvector도 충분히 경쟁력이 있지만, 10M~50M 이상·고QPS 구간에서는 전용 벡터DB 쪽으로 경계가 뚜렷하게 기운다.

  • 청크가 커질수록 문맥은 보존되지만 임베딩 수·인덱스 크기가 늘어 지연이 커진다.
  • overlap을 늘리면 재현율은 오르지만 임베딩 비용과 인덱스 빌드 시간이 함께 증가한다.
  • 규모(벡터 수)가 커질수록 pgvector의 tail latency와 빌드 시간이 먼저 불리해진다.
  • 검색 파라미터(probes 등)를 청킹과 별개로 튜닝하지 않으면 재현율이 쉽게 깨진다.
  • 평균 지연보다 p95/p99 같은 꼬리 지연이 설계 판단에 더 중요하다.

이 글이 뜯어보는 범위는 텍스트 청킹 → 임베딩 → 인덱스(HNSW/IVFFlat) → 쿼리 파라미터로 이어지는 RAG 검색 파이프라인이다. 청킹 알고리즘 자체의 자연어처리 디테일이나 리랭킹 단계는 다루지 않는다.

청크 크기와 overlap은 임베딩 단에서 무엇을 바꾸는가?

청크 크기와 overlap은 임베딩 개수와 인덱스 총량을 직접 늘린다. 2026년 비교 자료들은 256~512 토큰, 10~20% overlap을 일반적인 기본값으로 언급하는데, 이는 벡터DB 실측이라기보다 운영 가이드 수준이다출처: anthraai.com. overlap이 커지면 같은 문서에서 만들어지는 청크 수가 늘어 임베딩 호출과 저장 벡터 수가 동시에 증가하고, 이는 인덱스 빌드 시간과 메모리 사용량으로 그대로 전이된다. 즉 재현율을 높이려는 선택이 인덱스 레이어의 비용 구조를 바꾸는 첫 지점이 여기다.

인덱스 레이어에서 HNSW 파라미터는 재현율을 어떻게 조정하는가?

HNSW의 ef_construction, m 값과 양자화 방식이 재현율·빌드 시간·메모리를 함께 좌우한다. Instaclustr 자료는 pgvector 0.7.0의 HNSW+binary quantization이 0.5.0 대비 인덱스 빌드 시간을 약 150배 줄였고, scalar quantization은 약 50배 성능 향상, IVFFlat 대비 throughput/p99가 약 30배 개선됐다고 보고한다출처: instaclustr.com. 다만 이 수치는 특정 데이터셋(dbpedia-openai-1000k-angular)과 버전 조합에 종속돼 있어, "압축·양자화·인덱스 선택이 비용 구조를 크게 바꾼다"는 수준으로만 일반화하는 것이 안전하다.

쿼리 단에서 검색 파라미터는 지연을 어떻게 흔드는가?

probes 값을 낮추면 지연은 줄지만 재현율이 함께 떨어진다. Instaclustr는 pgvector HNSW에서 probes를 10~100 사이로 조정해 정확도와 지연을 맞추라고 권한다출처: instaclustr.com. 이는 청킹 이야기가 아니라 검색 파라미터 이야기지만, 실무에서는 청킹을 잘 설계해도 이 값을 맞추지 못하면 재현율이 그대로 무너진다는 점에서 같은 축의 마지막 단계로 봐야 한다.

실측 수치는 규모별로 어떤 경계를 보여주는가?

규모가 커질수록 pgvector의 지연·빌드 비용이 먼저 불리해진다. 50M 벡터, 768차원, 99% recall 조건에서 Postgres+pgvectorscale은 471 QPS, Qdrant는 41.47 QPS로 보고되는데, 이 수치만 보면 pgvector가 앞서 보이지만 지연 프로파일은 다르다. 같은 조건에서 pgvectorscale은 p50 31.07ms·p95 60.42ms·p99 74.60ms, Qdrant 1.13.4는 p50 30.75ms·p95 36.73ms·p99 38.71ms로, 평균은 비슷해도 꼬리 지연은 Qdrant가 안정적이다. 인덱스 빌드 시간은 Postgres 쪽이 약 11.1시간, Qdrant 쪽이 약 3.3시간이었다출처: ecorpit.com.

반대로 MS MARCO 1M passages, 384차원, 단일 머신(c7g.4xlarge, 16 vCPU, 32GB RAM) 조건에서는 pgvector(HNSW)가 빌드 48분·p50 8ms·p95 22ms·QPS 480, Qdrant는 빌드 19분·p50 3ms·p95 9ms·QPS 1,200으로 나타나 중간 규모에서도 격차가 존재한다출처: anthraai.com. 같은 조건에서 Weaviate는 빌드 26분·p95 14ms·QPS 850, Vespa는 빌드 41분·p95 11ms·QPS 1,050으로, 전용 벡터DB 사이에서도 빌드/지연/처리량 트레이드오프가 갈린다.

재현율을 올리면 무엇을 내줘야 하는가?

재현율을 올리는 선택(청크를 잘게 쪼개고 overlap을 늘리는 것, probes를 높이는 것)은 예외 없이 지연과 인덱스 비용을 늘린다. 500K~1M 벡터 구간에서 adaptive 파라미터 방식이 fixed 방식보다 p95를 낮춘다는 보고가 있는데, 1M 벡터·64차원에서 adaptive p95 125~161ms, fixed p95 141~219ms, 500K에서는 adaptive median 60~65ms, fixed 66~70ms였다출처: mastra.ai. 이는 파라미터를 고정하면 규모가 커질수록 꼬리 지연이 더 크게 흔들린다는 뜻이고, 반대로 파라미터를 데이터 규모에 맞춰 조정하면 재현율 손실 없이 지연을 낮출 여지가 있다는 뜻이다. 결국 재현율과 지연은 한쪽을 고정하면 다른 쪽이 흔들리는 관계이며, 인덱스 빌드 시간까지 포함하면 세 변수가 동시에 움직인다.

어떤 규모에서 pgvector를, 어떤 규모에서 전용 벡터DB를 쓰는가?

1M 벡터 전후, 단일 Postgres 운영으로 복잡도를 최소화해야 하는 상황이면 pgvector가 여전히 합리적인 기본값이다. 2026년 실무 글들은 pgvector+HNSW를 노드당 1천만 벡터까지의 기본 선택지로 보기도 한다출처: jacar.es. 반면 10M~50M 이상의 코퍼스, 높은 QPS, 낮은 tail latency가 SLO에 들어가는 환경이라면 전용 벡터DB 쪽으로 기울어진다. 이 경계는 2026년 기준 반복적으로 인용되는 패턴이며, 청킹 전략을 아무리 정교하게 짜도 벡터DB 선택이 이 경계를 넘지 못하면 재현율·지연 목표를 동시에 맞추기 어렵다.

핵심 정리

  • 재현율은 청킹(크기·overlap)이, 지연·인덱스 비용은 벡터DB·인덱스 파라미터가 각각 결정하며 둘은 곱해져 총 비용이 된다.
  • 50M 벡터·99% recall 조건에서 pgvectorscale은 평균 QPS가 높지만 p95/p99 tail latency는 Qdrant가 더 안정적이다출처: ecorpit.com.
  • 1M 벡터 규모에서도 pgvector 대비 전용 벡터DB(Qdrant·Weaviate·Vespa)가 빌드 시간과 지연 모두 더 가벼운 경향이 반복 관찰된다출처: anthraai.com.
  • 검색 파라미터를 데이터 규모에 맞춰 적응적으로 조정하면 고정값 대비 tail latency를 낮출 수 있다.
  • 1M 전후·단일 Postgres 운영은 pgvector, 10M~50M 이상·고QPS·낮은 tail latency 요구는 전용 벡터DB 쪽이 실측상 유리하다.

더 알아보기

벡터 검색 설계의 핵심 판단축: 재현율, 지연, 비용의 균형 — 이 주제의 종합 가이드