벡터 데이터베이스(Vector DB) 도입을 통한 실시간 상품 추천 파이프라인 개선

이커머스 산업이 급격히 성장함에 따라 고객 맞춤형 서비스는 고객 경험의 중요한 요소로 자리 잡고 있습니다. 특히 개인화된 상품 추천 기술은 고객의 관심을 끌고 구매 전환율을 높이는 핵심 기술로 주목받고 있습니다.

블럭스(Blux)는 이러한 요구를 충족하기 위해 초개인화 AI 솔루션을 제공하며, 클라이언트로부터 전달받은 상품 데이터와 고객(End User) 행동 데이터를 바탕으로 실시간 상품 추천 서비스를 제공하고 있습니다.

그러나 기존의 실시간 상품 추천 파이프라인에서는 필요한 작업들이 서로 다른 서버에서 수행되어 비효율이 발생하는 문제가 있었고, 블럭스에서는 이를 개선하기 위해 벡터 데이터베이스(Vector DB)를 도입하기로 했습니다.

이번 글에서는 블럭스의 기존 파이프라인에서 어떤 비효율이 발생하고 있었으며, 벡터 데이터베이스, 그중에서도 ‘MongoDB Atlas Vector Search’를 도입함으로써 어떻게 문제를 개선할 수 있었는지에 대해 알아보겠습니다.

기존 실시간 상품 추천 파이프라인의 특징

블럭스의 실시간 상품 추천 파이프라인에서는 ‘추천 후보군 설정(Candidate Selection)’과 ‘벡터 유사도 검색(Vector Similarity Search)’의 두 가지 작업이 이루어집니다.

‘추천 후보군 설정’은 상품 추천 대상이 되는 추천 후보군(Candidate Pool)을 제한하는 과정입니다. 예를 들어, 고객이 특정 카테고리 페이지에서 활동 중이라면, 해당 카테고리에 속하는 상품만 추천 결과에 포함되도록 해야 합니다. ‘상의’ 카테고리 페이지에서 추천되는 상품에는 ‘바지’, ‘신발’ 등의 카테고리에 속하는 상품이 포함되지 않도록 처리하는 작업이 이에 해당합니다.

‘벡터 유사도 검색’은 추천 후보군에 포함된 상품들 간의 임베딩(Embedding)을 비교하여 고객이 선호할 만한 옵션이나 특정 제품과 유사한 항목을 찾아내는 작업입니다. 임베딩이란, AI 모델이 산출하는 값으로서 특정 데이터를 숫자의 나열인 벡터(Vector) 형태로 표현한 것입니다. 블럭스에서는 먼저 상품 데이터와 고객 행동 데이터를 학습한 AI 모델로 각 상품의 임베딩을 생성합니다. 이후 추천 요청이 들어오면 실시간 벡터 유사도 검색을 통해 거리가 가까운 임베딩을 찾고, 이를 바탕으로 고객이 선호할 만한 상품을 반환합니다.

기존 실시간 상품 추천 파이프라인의 한계

블럭스의 기존 실시간 상품 추천 파이프라인은 앞서 설명한 ‘추천 후보군 설정’과 ‘벡터 유사도 검색’이 각각 별도의 서버에서 이루어지도록 설계되어 있습니다. ‘추천 후보군 설정’은 ‘Recommender API’라는 서버에서, ‘벡터 유사도 검색’은 ‘TFS Core’라는 서버에서 각각 수행됩니다.

먼저 Recommender API에서 ‘추천 후보군 설정’ 작업을 통해 추려낸 추천 후보군을 TFS Core로 전달하면, TFS Core에서 ‘벡터 유사도 검색’을 통해 추천 요청으로부터 만들어낸 임베딩과 추천 후보군의 임베딩 간 벡터 거리를 계산하여 추천 상품을 반환합니다.

그러나 기존 파이프라인은 다음과 같은 문제점을 가지고 있습니다.

(1) 데이터 통신 비용 증가

‘추천 후보군 설정’을 통해 추려낸 추천 후보군은 Recommender API에서 TFS Core로 전달됩니다. 이 과정에서 대량의 데이터가 이동하면서 네트워크 비용이 증가하고, 처리 부하가 높아질 수 있습니다. 특히 실시간 추천 시스템에서는 이러한 데이터 이동이 많을수록 비용 부담이 커질 가능성이 있습니다.

(2) 서버 메모리 사용량 증가

Recommender API에서 ‘추천 후보군 설정’ 작업을 수행하기 위해서는 필연적으로 카테고리, 가격, 품절 여부 등 상품 데이터를 활용할 수밖에 없습니다. 이때 매번 데이터베이스에서 상품 데이터를 불러오는 것은 비효율적일 뿐만 아니라 응답 속도를 저하시킬 가능성이 있습니다.

따라서 Recommender API 서버의 메모리에 필요한 상품 데이터를 전부 캐싱(데이터를 임시 저장 위치에 저장하여 보다 빠르게 접근할 수 있도록 하는 것)하는 방식을 선택했는데, 이는 서버 메모리 사용량을 증가시켜 결과적으로 서버 비용의 증가로 이어집니다.

TFS Core에서도 ‘벡터 유사도 검색’을 수행하기 위해 AI 모델이 생성한 모든 상품의 임베딩을 서버 메모리에 캐싱하기 때문에 서버 메모리 사용량이 증가할 수밖에 없습니다.

뿐만 아니라 블럭스에서는 추천 요청이 몰렸을 때 서버의 과부하를 막기 위해 오토스케일링(AutoScaling) 시스템을 구축해 두었는데요, 오토스케일링으로 서버 개수가 증가함에 따라 서버 메모리에 캐싱되어 있는 데이터도 동일하게 복사됩니다. 동일한 데이터임에도 불구하고 여러 개의 서버가 하나의 데이터를 공유하는 대신, 각 서버별로 데이터를 캐싱하고 있기 때문에 추가적인 비효율 및 비용이 발생했습니다.

(3) 유지 보수 비용 증가

실시간 상품 추천에 필요한 두 가지 작업이 서로 다른 서버에서 수행되기 때문에 시스템을 유지 보수하거나 확장하는 과정에서 추가적인 관리 비용이 발생합니다. 서버 간의 데이터 동기화가 어려워지고, 이는 장애 발생 가능성을 높이는 요인이 됩니다.

위와 같은 문제들을 개선하기 위해 블럭스는 벡터 데이터베이스, 그중에서도 ‘MongoDB Atlas Vector Search’를 도입하기로 했습니다. 이를 활용해 상품 데이터와 임베딩을 데이터베이스에 저장하고, ‘추천 후보군 설정’과 ‘벡터 유사도 검색’을 일원화하여 처리할 수 있도록 했습니다. 그 결과, 기존 파이프라인의 문제를 효과적으로 해결할 수 있었습니다.

벡터 데이터베이스란?

‘벡터 데이터베이스’는 데이터를 고차원 벡터 형태로 저장하고, 빠르게 검색 및 비교할 수 있도록 설계된 데이터베이스입니다. 특히 유사도 검색과 같은 작업이 필요한 서비스에서 강력한 성능을 발휘합니다.

전통적인 관계형 데이터베이스(RDBMS)나 NoSQL 데이터베이스가 키-값 또는 정형 데이터를 저장하는 것과 달리 벡터 데이터베이스는 이미지, 텍스트, 음성, 고객 행동 데이터 등을 벡터로 변환하여 저장하고, 데이터 간 유사도를 바탕으로 검색하는 유사도 검색 기능을 지원합니다.

MongoDB Atlas Vector Search란?

‘MongoDB Atlas Vector Search’는 MongoDB에서 제공하는 벡터 데이터 처리 기능으로 NoSQL 데이터베이스인 MongoDB에서 벡터 데이터의 저장 및 검색을 가능하게 하는 기능입니다.

MongoDB Atlas Vector Search의 주요 특징은 다음과 같습니다.

(1) 벡터 데이터 저장 및 활용

벡터 데이터 전용 인덱스(Index) 등 MongoDB에서 기본적으로 사용되는 도큐먼트(Document) 기반 데이터 모델 외에도 벡터 데이터를 저장 및 활용할 수 있는 기능을 제공합니다. 이를 통해 벡터 형태의 상품 임베딩 데이터를 기존 MongoDB 인프라와 통합적으로 관리할 수 있습니다.

(2) 벡터 유사도 검색

벡터 유사도 검색이 가능하며 유사도 측정 시 벡터의 끝점 간 거리를 측정하는 ‘유클리드 거리(Euclidean Distance)’, 벡터 간의 각도를 기반으로 유사성을 측정하는 ‘코사인 유사도(Cosine Similarity)’, 그리고 벡터 간의 각도뿐만 아니라 벡터의 크기도 함께 고려하여 유사성을 측정하는 ‘내적(Dot Product)’까지 총 세 가지 함수를 사용할 수 있습니다.

(3) 사전 필터(Pre-Filter)

단순한 벡터 검색을 넘어 특정 조건을 만족하는 데이터를 미리 선별하여 해당 데이터에 대해서만 검색을 수행할 수 있는 ‘사전 필터(Pre-Filter)’ 기능을 제공합니다. Pre-Filter를 사용하면 상품 ID, 카테고리 등 특정 상품 정보에 기반하여 추천 후보군을 제한하는 ‘추천 후보군 설정’ 작업을 ‘벡터 유사도 검색’과 동시에 수행할 수 있습니다.

블럭스가 벡터 데이터베이스로 MongoDB를 선택한 이유

블럭스에서는 원래 상품 데이터 및 고객 행동 데이터를 포함하여 대부분의 데이터를 저장하는 데이터베이스로 MongoDB를 사용하고 있었습니다. 즉, 이미 일원화된 데이터베이스로 MongoDB를 사용 중이었기 때문에 기존 데이터베이스와 통합적으로 사용할 수 있다는 점에서 MongoDB Atlas Vector Search 도입 시 이점이 컸습니다.

또한, MongoDB Atlas Vector Search에서 제공하는 Pre-Filter 기능을 사용하면 특정 조건을 만족하는 데이터만 검색 대상으로 제한하여 벡터 유사도 검색을 수행할 수 있습니다. 이는 블럭스의 실시간 상품 추천 파이프라인에서 필요한 ‘추천 후보군 설정’ 및 ‘벡터 유사도 검색’을 MongoDB에서 통합적으로 수행함으로써 기존 파이프라인의 문제를 해결할 수 있음을 의미했습니다.

따라서 블럭스는 MongoDB Atlas Vector Search를 통해 MongoDB를 벡터 데이터베이스로 활용함으로써 도입 비용을 최소화하면서 실시간 상품 추천 파이프라인의 비효율성을 개선하고자 했습니다.

벡터 데이터베이스 도입 후 어떻게 달라졌을까?

MongoDB Atlas Vector Search를 통해 MongoDB를 벡터 데이터베이스로 활용하여 ‘추천 후보군 설정’ 및 ‘벡터 유사도 검색’이 모두 MongoDB에서 이루어지도록 실시간 상품 추천 파이프라인을 개선하였습니다. 아울러 MongoDB Atlas Vector Search에서 지원하는 Pre-Filter와 함께 벡터 유사도 검색 기능을 사용함으로써 ‘추천 후보군 설정’ 및 ‘벡터 유사도 검색’을 MongoDB에서 동시에 수행할 수 있게 되었습니다.

그럼 벡터 데이터베이스 도입 후 무엇이 달라졌을까요?

개선된 실시간 상품 추천 파이프라인의 성능을 검증하기 위해 오픈소스 모니터링 시스템인 ‘Prometheus’를 활용하였습니다. 파이프라인 개선 전후 5일 동안 Recommender API 및 TFS Core의 메모리 사용량(5분 Interval 평균)과 Recommender API의 응답 시간(5분 Interval 평균)을 측정하여 개선 여부를 평가하였고 그 결과는 다음과 같습니다.

• 메모리 사용량

기존 파이프라인에서의 평균 메모리 사용량은 1.8GiB인 반면 개선된 파이프라인에서의 평균 메모리 사용량은 400MiB로 메모리 사용량이 약 77% 감소하였습니다.

• 응답 시간

기존 파이프라인에서의 평균 응답 시간은 330ms인 반면 개선된 파이프라인에서의 평균 응답 속도는 110ms로 응답 시간이 3분의 1 수준으로 단축되었습니다. 특히 트래픽이 높은 상황에서도 안정적인 응답 속도를 유지하였습니다.

결과적으로 벡터 데이터베이스를 도입하여 파이프라인을 개선함으로써 기존 파이프라인에 존재하던 세 가지 문제인 (1) 데이터 통신 비용 증가, (2) 서버 메모리 사용량 증가, (3) 유지 보수 비용 증가를 모두 개선할 수 있었습니다.

기존에는 Recommender API에서 ‘추천 후보군 설정’을 통해 추천 후보군을 추려낸 뒤 TFS Core로 전달했습니다. 개선된 파이프라인에서는 이러한 데이터 전달 과정을 완전히 제거하여 불필요한 네트워크 트래픽과 데이터 이동 비용을 절감하였습니다.

또한, ‘추천 후보군 설정’ 작업을 위해 필요한 상품 데이터와 ‘벡터 유사도 검색’을 위해 필요한 임베딩이 더 이상 Recommender API와 TFS Core의 메모리에 캐싱되지 않습니다. 실시간 상품 추천 파이프라인에서 필요한 작업이 모두 MongoDB에서 이루어지기 때문에 작업에 필요한 상품 데이터와 임베딩도 모두 MongoDB에 저장됩니다. 덕분에 서버의 메모리 사용량이 크게 감소하였고, 서버의 안정성과 확장성이 동시에 향상되었습니다.

이와 함께 실시간 상품 추천 파이프라인에서 필요한 작업과 데이터가 모두 MongoDB에 통합되었기 때문에 별도의 서버 간 데이터 동기화 문제도 해소되었고, 유지 보수 비용도 감소하였습니다.

더 빠르고 효율적으로, 블럭스 추천 시스템의 진화

지금까지 MongoDB Atlas Vector Search를 통해 MongoDB를 벡터 데이터베이스로 활용함으로써 블럭스의 실시간 상품 추천 파이프라인을 어떻게 개선할 수 있었는지에 대해 알아보았습니다.

블럭스의 기존 실시간 상품 추천 파이프라인에서는 ‘추천 후보군 설정’과 ‘벡터 유사도 검색’ 작업이 각각 별도의 서버에서 수행되었고, 그로 인해 불필요한 데이터 이동으로 인한 비효율성이 발생했습니다. 이에 따라 서버 메모리 사용량 및 유지 보수 비용이 증가하는 문제가 있었습니다.

이를 개선하기 위해 MongoDB를 벡터 데이터베이스로 활용 및 도입하여 두 작업이 모두 MongoDB에서 수행될 수 있도록 통합하였고, 결과적으로 데이터 통신 비용(응답 시간), 서버 메모리 사용량, 유지 보수 비용을 모두 줄일 수 있었습니다.

이번 개선 작업을 통해 기존 파이프라인에 기능적으로 문제가 없더라도 새로운 기술을 도입함으로써 서비스의 비용을 절감하거나 성능을 향상시킬 수 있다는 사실을 다시 한번 느낄 수 있었습니다.

앞으로도 블럭스는 끊임없이 새로운 기술을 연구하고 도입하기 위한 노력을 멈추지 않고 열심히 나아가겠습니다.