Qdrant 필터링은 RAG 검색을 얼마나 빠르게 만들까?
결론부터: "필터가 많을수록 Qdrant가 강하다"는 말은 정확하지 않습니다. 정확한 말은 "필터 필드에 payload index를 걸었을 때 강하다"입니다. 2026년 5월 공개된 실측에서는 payload index 유무만으로 벡터+필터 검색 지연이 p50 146.77ms에서 2.36ms로, 약 62배 줄었습니다출처.
이 글의 핵심은 다음과 같습니다.
- payload index가 있는 필드와 없는 필드의 지연 차이는 수 ms 대 vs 수십~백 ms대로, 체감이 아니라 구조적 차이입니다.
- 순수 필터(벡터 검색 없이)는 인덱스 없이도 대개 수 ms대라, 필터 자체보다 "벡터+필터 조합"이 인덱스 여부에 더 민감합니다.
- Qdrant 공식 벤치마크는 filtered search를 별도 축으로 다뤄, 필터 유무가 엔진 선택에 실제로 영향을 준다는 신호를 줍니다.
- 이 결론은 특정 버전(Qdrant 1.18.1)·특정 데이터 규모(100k 컬렉션)에서 나온 것이라, 그대로 일반화하기엔 조건이 붙습니다.
이번 실험에서 검증하려는 것은 하나입니다. 테넌트·권한·날짜·카테고리처럼 메타데이터 조건이 강한 업무형 RAG에서, Qdrant 필터링이 실제로 체감되는 이득을 주는지, 그리고 그 이득이 어떤 조건에서 나타나고 사라지는지를 공개 실측 수치로 재구성해보는 것입니다. 직접 재현 실험을 돌린 것은 아니고, 2026년 공개된 실측 글의 조건과 수치를 RAG 필터 설계 맥락으로 다시 읽어보는 방식입니다.
필터링 실험은 어떤 조건으로 설계해야 할까?
핵심 설계 축은 "어떤 필드에 인덱스를 거는가"와 "그 필드의 선택도가 얼마나 높은가" 두 가지입니다. 원 실측은 100k 컬렉션 규모에서, Qdrant 1.18.1, qdrant-client 1.18.0, fastembed 0.8.0, Ubuntu 24.04.4 LTS 환경으로 50회씩 반복 측정했습니다출처. RAG 실무에 대응시키면, 테넌트 ID·권한 레벨·문서 카테고리·생성일자 같은 필드가 여기서의 category/brand/datetime 필드와 역할이 비슷합니다.
설계에서 놓치기 쉬운 지점은 "필터 필드 전체에 인덱스를 걸어야 하는가"입니다. 원 실측은 전체가 아니라 검색에 실제로 쓰이는 필드에 인덱스를 걸었을 때의 차이를 봤습니다. 즉 설계 단계에서 "이 필드가 자주 필터 조건으로 쓰이는가"를 먼저 정리하고, 거기에만 인덱스를 붙이는 편이 스키마를 덜 무겁게 만듭니다. 인덱스 생성 자체는 해당 조건에서 약 5초 수준으로 보고됐고, 이는 스키마를 나중에 바꾸는 비용치고는 크지 않은 편입니다출처.
payload index를 실제로 붙이면 지연이 어떻게 바뀔까?
같은 실측 글에서 조합별 수치를 정리하면 이렇습니다.
| 조건 | p50 지연 | 인덱스 상태 |
|---|---|---|
| brand+rating (벡터+필터) | 146.77ms → 2.36ms | 인덱스 전 → 후 |
| category+price (필터만) | 2.69ms | 인덱스 상태 |
| bool+datetime (필터만) | 1.45ms | 인덱스 상태 |
| geo_radius 1000km (필터만) | 1.18ms | 인덱스 상태 |
| must_not Books (필터만) | 4.84ms | 인덱스 상태 |
이 표에서 두 가지가 보입니다. 첫째, 순수 필터는 인덱스가 있으면 대체로 수 ms대에서 안정적입니다. 둘째, 벡터 검색과 필터가 같이 들어가는 조합에서 인덱스 부재의 비용이 가장 크게 드러납니다. brand+rating처럼 선택도가 높은 조합(조건에 맞는 데이터가 적은 조합)일수록 인덱스 없이 풀스캔에 가까운 비용을 치른다는 뜻으로 읽힙니다출처.
여기서 실패담 하나를 붙이면, 이런 종류의 벤치마크를 처음 볼 때 "필터를 걸면 원래 느려지는 거 아닌가"라고 오해하기 쉽습니다. 실제로는 반대로 읽어야 합니다. 인덱스가 없을 때만 느려지고, 인덱스를 걸면 필터가 있는 검색이 오히려 대상 범위를 줄여 더 빨라질 여지가 생깁니다. 이 방향을 반대로 이해하면 "Qdrant는 필터에 약하다"는 잘못된 결론으로 이어질 수 있습니다.
이 결과를 RAG 업무 시나리오에 어떻게 대응시켜야 할까?
대응 기준은 "필터 조건이 검색 전에 후보군을 얼마나 좁히는가"입니다. 문서 출처, 부서, 권한, 날짜, 지역, 상품 속성처럼 검색 전에 후보를 줄여야 하는 RAG는 원 실측의 brand+rating류 조합과 성격이 비슷합니다출처. 이런 필드들은 대부분 선택도가 높고, 그만큼 인덱스 유무가 지연에 미치는 영향도 커질 가능성이 있습니다.
반대로, 필터가 거의 없고 단순 유사도 검색이 중심인 RAG라면 이 실험의 이득이 크게 체감되지 않을 수 있습니다. Qdrant 공식 자료가 filtered search를 아예 별도 벤치마크 축으로 분리해둔 것 자체가, 필터가 없는 시나리오에서는 이 축의 장점이 덜 두드러진다는 신호로 읽힙니다출처. 실무에서는 RAG 스키마를 짤 때 "이 프로젝트가 테넌트/권한/날짜/카테고리 필터를 얼마나 자주 쓰는가"를 먼저 따져보고, 그 답이 "자주 쓴다"에 가까울수록 payload index 설계에 시간을 투자하는 편이 맞는 방향입니다.
Qdrant 공식 벤치마크는 이 실험과 어떻게 연결될까?
Qdrant는 필터가 있는 ANN 검색을 별도 축으로 다루는 공개 벤치마크를 유지하고 있고, 이 페이지는 2026년 8월에 갱신됐습니다출처. 여기에는 키워드 필터, 지리공간(geo) 필터 등을 포함한 실데이터·합성 데이터가 쓰이며, "Filtered ANN Benchmark Datasets"라는 이름으로 계속 관리되고 있습니다출처.
이 공식 자료가 이번 글의 실측 수치와 연결되는 지점은, 둘 다 "필터가 있는 검색"을 일반 벡터 검색과 다른 시나리오로 취급한다는 점입니다. 공식 벤치마크는 필터 품질/성능을 분리해서 평가하고, 실측 글은 그 분리가 실제로 인덱스 유무에 따라 수십 배 차이로 나타난다는 것을 보여줍니다. 두 자료를 같이 보면, "Qdrant의 필터링 장점"이라는 표현이 마케팅 문구가 아니라 공개 문서와 실측이 같은 방향을 가리키는 결과라는 걸 확인할 수 있습니다.
이 검증에서 확인되지 않은 부분은 무엇일까?
가장 먼저 짚어야 할 한계는 수치의 출처가 단일 실측 글이라는 점입니다. computingforgeeks의 2026년 5월 테스트는 Qdrant 1.18.1, 100k 컬렉션이라는 특정 조건에서 나온 것이고, 다른 버전이나 다른 규모의 컬렉션에서는 배수가 달라질 수 있습니다출처. "62배"라는 숫자를 다른 프로젝트에 그대로 대입하는 건 과장에 가깝습니다.
둘째, 이 실측은 실제 RAG 임베딩 데이터가 아니라 브랜드·평점·카테고리 같은 일반 상거래성 필드로 구성돼 있습니다. 테넌트 ID나 권한 레벨처럼 RAG 특유의 필드가 같은 패턴을 보일지는 별도로 확인해야 합니다. 셋째, 인덱스를 무분별하게 늘리면 쓰기 비용과 저장 비용이 늘어나는 트레이드오프가 있다는 점은 이번 자료에서 직접 다루지 않았습니다. 즉 "인덱스를 걸면 무조건 좋다"가 아니라 "자주 쓰는 필터 필드에만" 거는 것이 이 실측이 지지하는 범위입니다.
이번 검증에서 남는 실무 판단은 무엇일까?
이번 실험을 정리하면, Qdrant 필터링의 실무적 의미는 "필터가 많다"가 아니라 "필터를 인덱스로 설계했다"에 있습니다. 2026년 기준으로 공개된 자료를 보면, payload index가 있는 상태와 없는 상태의 차이가 수 ms 대와 수백 ms 대로 갈리는 지점이 명확하게 존재합니다. 이 차이는 테넌트, 권한, 날짜, 카테고리처럼 검색 전에 후보군을 좁혀야 하는 업무형 RAG에서 더 크게 체감될 가능성이 있습니다.
다만 이 판단은 특정 버전·특정 데이터 규모에서 나온 실측을 근거로 한 것이라, 실제 프로젝트에 적용하기 전에는 자신의 스키마와 데이터 선택도로 다시 확인하는 과정이 필요합니다. "필터 있는 RAG면 Qdrant가 좋다"보다는 "필터 있는 RAG면 Qdrant에서 payload index 설계를 먼저 확인한다"가 이번 검증이 지지하는 더 정확한 문장입니다.
핵심 정리
- payload index 유무가 Qdrant 필터링 성능의 실질적 분기점이며, 한 실측에서는 벡터+필터 지연이 p50 146.77ms→2.36ms로 줄었습니다.
- 순수 필터는 인덱스가 있을 때 대체로 수 ms대(1.18~4.84ms)로 안정적으로 유지됩니다.
- Qdrant 공식 벤치마크는 filtered search를 별도 축으로 관리하며, 2026년 8월까지 갱신이 이어지고 있습니다.
- 테넌트/권한/날짜/카테고리처럼 선택도 높은 필터가 많은 업무형 RAG일수록 인덱스 설계의 체감 효과가 커질 가능성이 있습니다.
- 이 결론은 특정 버전·규모의 실측에 기반한 것이라, 자신의 프로젝트 조건에서 재확인이 필요합니다.