Redis 추천 엔진

Redis 추천 엔진 (Recommendation Engine)

한 번의 Redis 호출로 벡터 유사도와 구조화 필터를 결합해, 빡빡한 지연 예산 안에서 개인화된 추천을 제공하는 패턴입니다.

출처: 공식문서 — Redis recommendation engine

언제 Redis를 추천 엔진으로 쓰는가

임베딩 유사도에 구조화 속성 필터를 결합해야 하면서 지연 예산이 빡빡할 때 — 전형적으로 수십 밀리초 안에 반환해야 하는 후보 검색·스코어링·재순위화의 다단계 파이프라인이면서, 배치 주기를 기다릴 수 없는 실시간 세션 신호를 접목해야 할 때 — Redis를 추천 엔진의 서빙 레이어로 사용합니다.

왜 이 문제가 어려운가

추천 파이프라인은 종단 간 약 200ms 안에 순위 목록을 만들어야 하고, 서빙 단계에서 아이템 임베딩·아이템 메타데이터·사용자 피처·최근 상호작용 이력을 동시에 필요로 합니다. 흔한 우회 방법들은 실질적인 단점이 있습니다.

  • 관계형 데이터베이스는 임베딩·메타데이터·사용자 피처를 저장할 수 있지만, 서빙 시점 동시성에서 서브 밀리초 근사 최근접 이웃(KNN) 검색을 수행할 수 없습니다. 수백만 벡터에 대한 KNN은 행 저장소(row store)가 만들어진 용도가 아닙니다.
  • 전용 벡터 데이터베이스는 메타데이터 필터링이 있는 KNN을 처리하지만, 별도의 확장·모니터링 표면, 추가 네트워크 홉, 기본 저장소의 아이템 메타데이터와 벡터 저장소의 임베딩 사이의 동기화 계층을 추가합니다. 대부분 배치 로드에 최적화된 읽기 중심 워크로드를 위해 설계됐지, 세션 신호가 요청 중에 사용자 피처를 갱신해야 하는 읽기 사이에 끼어드는 서브 밀리초 쓰기에는 최적화되어 있지 않습니다.
  • 오프라인으로 추천을 미리 계산하면 서빙 시점 비용은 없어지지만 세션 내 행동에 반응할 수 없습니다 — 사용자가 뭔가 클릭해도 다음 요청은 여전히 어제의 오프라인 배치를 기준으로 순위를 매깁니다.

작동하는 서빙 레이어는 벡터 KNN, 구조화 사전 필터, 그리고 요청 경로 안에서 즉시 반영되는 사용자별 피처 업데이트가 필요합니다 — 별도의 벡터 저장소를 세우고 기본 저장소와 동기화하지 않고도 말이죠.

Redis 솔루션에서 기대할 수 있는 것

다음을 할 수 있습니다.

  • 피크 동시성에서 검색 단계의 P99 지연 10ms 미만으로 개인화된 추천을 반환합니다.
  • 단일 FT.SEARCH 호출에서 임베딩 유사도와 TAG·NUMERIC·TEXT 사전 필터를 결합하며, 저장소 간 조인(cross-store join)이 없습니다.
  • 배치 파이프라인을 기다리지 않고 실시간 세션 신호(클릭, 체류 시간, 장바구니 추가)를 다음 추천에 반영합니다 — HSET으로 쓴 세션 벡터는 애플리케이션이 쿼리 벡터로 FT.SEARCH에 전달하는 사용자 피처 해시의 바로 다음 읽기에 보입니다.
  • HSET으로 벡터 필드를 덮어써 서빙 중단 없이 오프라인 학습 파이프라인에서 아이템 임베딩을 갱신합니다. HNSW 인덱스는 다음 쿼리에 새 벡터를 반영합니다. 스키마 변경(다른 차원 수·모델)에는 같은 방식이 이중 필드 쓰기 + FT.ALTER 또는 인덱싱된 키 프리픽스 교체로 확장됩니다.
  • 아이템 임베딩·아이템 메타데이터·사용자 피처·단기 상호작용 상태를 한 서빙 레이어에 함께 두어 요청 경로에서 저장소 간 홉을 제거합니다.
  • 캐시·세션·레이트 리미팅을 이미 처리하는 스택의 같은 Redis 인스턴스에서 추천 인덱스를 운영합니다 — 추가 인프라가 필요 없습니다.

Redis가 이 솔루션을 어떻게 지원하는가

실제로 각 아이템은 임베딩 벡터와 구조화 메타데이터 — 카테고리, 브랜드, 가격, 재고 플래그, 인기도 점수 — 를 모두 담은 단일 Hash 또는 JSON 문서입니다. 단일 Redis Search 인덱스가 벡터 필드와 모든 필터 필드를 커버하므로, 하나의 FT.SEARCH 호출이 같은 패스에서 TAG·NUMERIC·TEXT 사전 필터를 적용하며 수백만 아이템에 대한 KNN 검색을 할 수 있습니다. 사용자별 피처는 별도 해시에 있으며, 애플리케이션이 HSET과 HINCRBYFLOAT으로 원자적으로 갱신합니다. 다음에 애플리케이션이 쿼리를 만들기 위해 그 해시를 읽을 때 클릭이 보이므로, 배치 주기 없이 세션 신호가 스코어링에 반영됩니다.

Redis가 추천 서빙 레이어에 잘 맞는 이유가 되는 기능들은 다음과 같습니다.

  • Hashes와 JSON이 각 아이템의 임베딩과 구조화 메타데이터를 단일 레코드에 저장하므로, 검색이 스코어러에 필요한 모든 것을 한 왕복(round trip)에 읽습니다.
  • HNSW 벡터 인덱스를 가진 Redis Search가 임베딩 필드에 대해 HNSW 속도의 근사 KNN을 수행하고, 같은 FT.SEARCH 호출이 TAG / NUMERIC / TEXT 필터를 적용해 한 패스에 후보 집합을 좁힙니다.
  • FT.HYBRID (Redis 8.4+)가 Reciprocal Rank Fusion 또는 선형 결합으로 텍스트·벡터 유사도를 단일 순위 결과로 결합합니다 — 어휘 일치가 후보 집합을 게이트하는 것만이 아니라 점수에 기여해야 하는 쿼리용으로요.
  • HSET과 HINCRBYFLOAT으로 사용자 피처 해시를 갱신하는 것은 원자적이라, 다음에 애플리케이션이 쿼리를 만드는 해시를 읽을 때 클릭이 보입니다 — 배치 주기나 캐시 무효화 없이 세션 신호가 스코어링에 반영됩니다.
  • HSET으로 벡터 필드를 덮어쓰면 HNSW 항목이 제자리에서 재학습되고, 임베딩 모델 변경 시 FT.ALTER와 이중 필드 쓰기 패턴으로 서빙 인덱스를 오프라인으로 두지 않고 새 모델로 전환할 수 있습니다.
  • 메모리에서의 서브 밀리초 읽기·쓰기 덕분에 추천 인덱스가 이미 캐시·세션·레이트 리미팅을 처리하는 같은 Redis 인스턴스에서 한계 비용 없이 운영됩니다.

생태계 (Ecosystem)

다음 라이브러리·프레임워크가 추천 워크로드에 Redis Search를 기반으로 합니다.

  • Python: 고수준 벡터 검색 클라이언트 RedisVL과 임베딩 기반 검색 체인용 LangChain Redis 통합.
  • Node.js: 객체 매핑 Hash/JSON 문서와 Redis Search 쿼리를 위한 redis-om-node.
  • Go: FT.SEARCH KNN과 구조화 필터를 일급 지원하는 go-redis.
  • ML 플랫폼: Redis를 서빙 기반으로 사용하는 온라인 피처 스토어·검색 레이어용 NVIDIA Merlin.

나만의 Redis 추천 엔진을 만드는 코드 예시

다음 가이드들은 작은 Redis 기반 상품 추천 서비스를 만드는 법을 보여줍니다. 각 가이드는 실행 가능한 대화형 데모를 포함해, 쿼리를 임베딩하고 KNN으로 후보를 검색하고 카테고리·가격으로 필터링하고 클릭을 세션 신호로 피드백하며 다음 추천이 즉시 이를 반영하는 것을 볼 수 있습니다.

더 알아보기 (Learn more)