Redis 벡터 검색, RAG에 바로 써도 될까?

결론부터 말하면 "조건부로 가능"이다. Redis 8은 768차원 FLOAT16 벡터 10억 개, 동시 검색 50건, top-100 조건에서 정밀도 90%일 때 중앙 지연시간 약 200ms를 기록했지만, 이 수치는 Redis가 LAION-5B 파생 데이터로 자체 수행한 벤치마크다. 출처 실제 서비스의 임베딩 모델, 메타데이터 필터, top-k, 동시 요청 수가 다르면 지연시간과 정밀도는 그대로 옮겨지지 않는다.

이 글의 핵심

  • Redis 8은 정밀도 90%/지연 200ms, 정밀도 95%/지연 1.3초로 품질을 높일수록 지연이 커진다. 출처
  • 색인 속도는 M=16·EF_CONSTRUCTION=32에서 초당 약 6.6만 벡터, 품질을 낮추면 초당 16만 벡터까지 올라간다.
  • FLAT은 10만 벡터 미만의 소규모·정확도 검증용, HNSW는 대규모·저지연 운영용으로 역할이 다르다.
  • 메모리 비용은 "벡터 크기 × 개수"만으로 산정하면 부족하다. HNSW 그래프와 메타데이터 오버헤드가 추가된다.
  • SKU·오류코드처럼 정확한 문자열이 중요한 문서는 dense 검색만으로 부족할 수 있다(RRF 하이브리드 Recall@5 0.695 vs dense 단독 0.587).

가장 흔한 함정은 이 벤치마크 수치를 그대로 자기 서비스의 SLA처럼 받아들이는 것이다. Redis 벤치마크는 특정 동시성·top-k·데이터 분포에서 나온 결과이고, 임베딩 모델이 바뀌거나 메타데이터 필터 선택도가 낮아지면 같은 설정에서도 지연시간이 쉽게 늘어난다. 2026년 기준으로 Redis 8에는 FLAT·HNSW 외에 SVS-VAMANA 계열 압축 기능도 추가돼 있어, 어떤 버전·엔진으로 측정한 수치인지부터 확인해야 한다. 출처

FLAT과 HNSW, 어디서 갈라야 할까?

데이터 규모와 "정확한 최근접"이 필요한지가 기준이다. FLAT은 저장된 모든 벡터와 비교하는 정확 검색이라 결과는 보장되지만 데이터 수에 따라 검색 시간이 선형으로 늘어난다. Redis의 비교표는 10만 벡터 미만을 FLAT의 대표 사용 구간으로 제시하지만, 실제 기준은 차원 수·하드웨어·필터 선택도에 따라 달라진다. 출처

HNSW는 대규모 운영 검색의 기본 후보로, 일반적인 조건에서 약 90~95% 수준의 검색 정확도와 낮은 지연시간을 목표로 설계됐다. 다만 M을 높이면 그래프 연결과 메모리 사용량이 함께 늘고, EF_RUNTIME을 높이면 recall과 지연시간이 동시에 증가한다. 테스트는 M을 4·8·16·32, EF_CONSTRUCTION을 4·8·16·32, EF_RUNTIME을 4부터 8192까지 바꿔가며 수행됐으므로, 같은 "HNSW"라도 파라미터 조합에 따라 결과가 크게 갈린다. 실무에서는 작은 사내 문서 코퍼스나 정답셋 검증용으로 FLAT을 먼저 써보고, 운영 규모로 넘어갈 때 HNSW로 전환하며 같은 골든셋으로 recall 변화를 비교하는 순서가 안전하다.

메모리 비용은 어디서 숨어있나?

가장 많이 빠뜨리는 부분은 "벡터 원본 크기"만 계산하는 것이다. 압축하지 않은 FLOAT32 벡터는 차원당 4바이트이므로 768차원 벡터 하나가 약 3KB에 불과하다. 출처 하지만 여기에 HNSW 그래프 연결 정보, 키·필드·JSON 구조, 메타데이터, Redis 자체 오버헤드가 추가되면서 실제 메모리 사용량은 이 숫자보다 눈에 띄게 커진다.

운영 견적을 낼 때는 저장 데이터 크기가 아니라 피크 메모리, 복제본 수, 샤드 수, 백업, 네트워크, 질의 동시성을 함께 계산해야 한다. 출처 반대로 Redis를 캐시·세션 상태·대화 메모리·키-값 데이터와 검색을 한 플랫폼에 통합하면 운영해야 할 시스템 수 자체가 줄어드는 효과도 있다. 즉 Redis 벡터 검색의 비용은 "벡터DB 단독 비용"이 아니라 "기존에 쓰던 Redis 인프라 대비 추가 비용"으로 계산해야 실제 체감과 가까워진다.

하이브리드 검색이 필요한 문서는 따로 있을까?

제품번호, SKU, 오류코드, 고유명사가 중요한 업무 문서에서는 dense 벡터 검색만으로 충분하지 않을 수 있다. 이런 문서는 의미는 비슷해도 정확한 문자열 일치가 답변 품질을 좌우하는 경우가 많기 때문이다. Redis는 벡터 검색과 전문검색, TAG·NUMERIC·GEO 계열 메타데이터 필터를 결합하는 하이브리드 검색을 지원한다.

Redis가 인용한 23,088개 질의 벤치마크에서는 RRF 기반 하이브리드 검색의 Recall@5가 0.695였고, dense 검색만 썼을 때는 0.587이었다. 출처 수치 차이가 크지는 않지만, 고유명사·코드값이 자주 등장하는 도메인에서는 이 차이가 실제 답변 누락 여부로 이어질 수 있다. 다만 이 수치도 특정 벤치마크 질의셋에서 나온 결과이므로, 자신의 문서 유형에 SKU·코드값이 얼마나 섞여 있는지를 먼저 확인한 뒤 하이브리드 전환 여부를 판단하는 편이 합리적이다.

"정밀도 90%"는 답변 품질을 보장한다는 뜻일까?

아니다. Redis 벤치마크의 precision·QPS 수치는 벡터 검색 단계의 성능일 뿐, 최종 RAG 답변의 정확도와는 다른 지표다. 벡터 검색 평가는 Recall@k, Precision@k, MRR·nDCG로 측정하고, 최종 RAG 품질은 근거 문서 포함률, 답변 정확도, 환각률, 질의당 비용, p50/p95 지연시간을 별도로 기록해야 한다.

다른 벡터DB와의 비교도 같은 맥락에서 조심해야 한다. Redis가 공개한 비교 벤치마크에서는 recall 0.98 이상 조건에서 Qdrant보다 최대 3.4배, Milvus보다 3.3배, Weaviate보다 1.7배 높은 QPS를 기록했다고 보고됐다. 출처 이 테스트는 100만 개·960차원 gist-960과 dbpedia-openai-1M-angular 데이터셋, AWS c6i.8xlarge 32 vCPU 환경에서 수행됐다. 수치 자체는 참고할 만하지만 Redis가 설계한 조건에서 나온 결과이므로, 선택의 단독 근거로 쓰기보다 자신의 데이터·하드웨어·recall 목표로 재현해보는 과정이 필요하다.

도입 전에 어떤 조건을 기록해야 할까?

운영 전에 설정값을 기록해두지 않으면 나중에 지연시간이 변해도 원인을 추적하기 어렵다. 최소한 Redis 버전과 배포 형태(Redis 8 Community Edition, Redis Cloud 등), 벡터 차원·자료형, 임베딩 모델과 청크 크기·overlap, 인덱스 종류(FLAT 또는 HNSW), HNSW 파라미터(M, EF_CONSTRUCTION, EF_RUNTIME), top-k와 메타데이터 필터 선택도, 동시 요청 수는 적어둬야 한다.

지연시간을 잴 때는 벡터 검색만의 시간인지, 네트워크 RTT·임베딩 생성·LLM 응답까지 포함하는지도 구분해야 한다. Redis가 보고한 200ms는 RTT를 포함한 수치이지만 임베딩 생성이나 LLM 호출 시간은 별도다. 출처 마지막으로 recall@k나 precision@k를 계산할 exact-neighbor 골든셋을 미리 만들어두면, 파라미터를 바꿀 때마다 품질 변화를 실제 숫자로 비교할 수 있다. 비용 쪽에서는 피크 메모리, 복제본 수, 샤드 수, 백업, 동시성까지 포함한 견적을 운영 전에 한 번은 뽑아보는 편이 나중의 재설계보다 싸다.

핵심 정리

  • Redis 8의 10억 벡터 벤치마크(정밀도 90%/200ms, 95%/1.3초)는 자체 조건의 결과이며 실제 서비스로 그대로 가져올 수 없다.
  • FLAT은 소규모·정확도 검증용, HNSW는 대규모 저지연 운영용으로 역할이 다르며 M·EF 파라미터가 recall과 지연을 동시에 움직인다.
  • 메모리 비용은 벡터 원본 크기가 아니라 HNSW 오버헤드, 복제본·샤드·백업·동시성까지 포함해 계산해야 한다.
  • SKU·오류코드가 중요한 문서는 하이브리드 검색(RRF) 적용 여부를 별도로 검토할 가치가 있다(Recall@5 0.695 vs 0.587).
  • 벡터 검색 precision 수치와 RAG 최종 답변 품질은 다른 지표이며, 둘 다 별도로 측정하고 기록해야 한다.