사기 탐지, 추천 시스템과 같은 실시간 인공지능/머신러닝(AI/ML) 활용 사례가 급증하고 있으며, 이러한 시스템을 성공적으로 프로덕션 환경에 배포하는 데 피처 스토어(feature store)가 핵심적인 역할을 합니다. 대표적인 오픈소스 피처 스토어인 Feast에 따르면, 커뮤니티 Slack에서 사용자들이 가장 많이 던지는 질문은 "Feast는 얼마나 확장 가능하고 고성능인가?"라는 것입니다. 그 이유는 실시간 AI/ML에서 피처 스토어의 가장 중요한 특성이 온라인 스토어에서 ML 모델로 피처를 제공하는 속도, 즉 온라인 예측이나 스코어링을 위한 지연 시간(latency)이기 때문입니다.
성공적인 피처 스토어는 밀리초 단위로 측정되는 엄격한 지연 시간 요구 사항을 p99 수준으로 일관되게 충족하면서, 초당 수백만 건의 쿼리와 기가바이트~테라바이트 규모의 데이터셋까지 확장할 수 있어야 하며, 동시에 낮은 총소유비용(TCO)과 높은 정확도를 유지해야 합니다.
이 글에서 살펴보겠지만, 온라인 피처 스토어의 선택과 피처 스토어 아키텍처는 성능과 비용 효율성을 결정하는 중요한 요소입니다. 그래서 많은 기업들이 온라인 피처 스토어를 선택하기 전에 철저한 벤치마킹을 통해 어떤 아키텍처나 스토어가 가장 성능이 좋고 비용 효율적인지 검증합니다. 이번 글에서는 실시간 AI/ML 활용 사례를 성공적으로 배포한 기업들이 직접 구축한 DIY 피처 스토어와 오픈소스·상용 피처 스토어의 아키텍처와 벤치마크 결과를 함께 살펴보겠습니다.
1. 오픈소스 Feast
먼저 벤치마크 데이터와 Feast 오픈소스 피처 스토어의 데이터 아키텍처를 살펴보겠습니다. Feast는 최근 서로 다른 온라인 스토어(Redis vs. Google Cloud DataStore vs. AWS DynamoDB)를 사용했을 때의 피처 제공 지연 시간을 비교하는 벤치마크를 진행했습니다. 또한 Java gRPC 서버, Python HTTP 서버, Lambda 함수 등 피처를 추출하는 다양한 메커니즘의 속도도 함께 비교했습니다. 결론부터 말하자면, Java gRPC 서버와 Redis를 온라인 스토어로 조합했을 때 압도적으로 가장 높은 성능을 보였습니다.
위 다이어그램은 온라인 모기지 회사 Better.com이 오픈소스 Feast 피처 스토어를 활용해 리드 스코어링 순위 시스템을 구현한 사례입니다. Better.com의 수석 소프트웨어 엔지니어 Vitaly Sergey의 발표에 따르면, 피처는 오프라인 스토어(S3, Snowflake, Redshift)에서 온라인 스토어(Redis)로 물리화(materialize)됩니다. 여기에 더해 Kafka 토픽 같은 스트리밍 소스에서도 피처가 온라인 스토어로 유입됩니다. Feast는 최근 배치 데이터 소스 외에 스트리밍 데이터 소스도 지원하기 시작했으며, 현재는 Redis만 지원합니다. 실시간 AI/ML 활용 사례는 신선한 실시간 데이터에 의존하기 때문에 스트리밍 데이터 소스 지원은 매우 중요합니다.
Better.com의 리드 스코어링 사례를 예로 들어 보겠습니다. 새로운 리드는 하루 종일 지속적으로 유입되며, 피처는 여러 소스에서 수집됩니다. 엔티티(리드)와 이를 스코어링하는 데 사용되는 피처는 끊임없이 갱신되므로 리드는 계속해서 재순위화됩니다. 새 리드가 유입되는 즉시 모델에 의해 스코어링되고, 온라인 스토어에 적재된 직후 곧바로 재순위화될 수 있습니다. Better.com의 리드는 48시간 후 만료되는데, 이는 Redis 온라인 스토어에서 TTL(Time To Live)을 48시간으로 설정하여 해당 엔티티(리드)와 연관된 피처 벡터를 자동으로 만료시키는 방식으로 구현됩니다. 덕분에 피처 스토어가 스스로 정리되어 오래된 엔티티나 피처가 귀중한 온라인 스토리지 공간을 차지하지 않습니다.
Feast의 또 다른 흥미로운 구현 사례는 Microsoft Azure Feature Store입니다. Azure 클라우드에서 실행되며 낮은 지연 시간이 요구되는 실시간 AI/ML 활용 사례에 최적화되어 있고, 배치·스트리밍 소스를 모두 지원하며 Azure 데이터 & AI 생태계와 통합됩니다. 피처는 배치 소스(Azure Synapse Serverless SQL, Azure Storage / ADLS)와 스트리밍 소스(Azure Event Hub) 양쪽에서 온라인 스토어로 유입됩니다. 이미 Azure에 배포되어 있거나 Azure 생태계에 익숙하다면 좋은 선택지가 될 수 있습니다. 온라인 스토어로는 Azure Cache for Redis를 사용하며, Enterprise 등급의 Azure Redis는 Active-Active 지역 복제 기능을 통해 최대 99.999% 가용성을 갖춘 글로벌 분산 캐시를 구성할 수 있습니다. 또한 Enterprise Flash 등급을 활용해 DRAM(인메모리)과 플래시 메모리(NVMe 또는 SSD)를 함께 사용하는 계층형 메모리 아키텍처로 Redis를 운영하면 추가적인 비용 절감도 가능합니다.
2. Wix의 자체 구축(DIY) 피처 스토어 – MLOps 플랫폼의 초석
다음은 실시간 AI/ML 활용 사례를 구현한 또 다른 아키텍처입니다. 웹사이트 빌딩 플랫폼으로 유명한 Wix의 피처 스토어 아키텍처로, 추천, 이탈 예측, 프리미엄 전환 예측, 랭킹, 스팸 분류기 같은 실시간 활용 사례에 사용됩니다. Wix는 2억 명이 넘는 등록 사용자를 보유하고 있지만, 특정 시점에 '활성 사용자'는 그중 극히 일부에 불과합니다. 이러한 특성이 피처 스토어 구현 방식에 큰 영향을 미쳤습니다.
아래 정보는 당시 Wix에서 ML 엔지니어링을 이끌었던 Ran Romano의 TechTalk 발표를 바탕으로 합니다. Wix 피처 스토어에 저장된 데이터의 90% 이상이 클릭스트림이며, ML 모델은 웹사이트별 또는 사용자별로 트리거됩니다. Ran은 실시간 활용 사례에서 지연 시간이 매우 중요한 문제이며, 일부 프로덕션 활용 사례에서는 피처 벡터를 밀리초 단위 내로 추출해야 한다고 설명했습니다.
원본 데이터는 AWS S3 버킷에 Parquet 파일로 저장되며, 사업부(예: '편집기', '레스토랑', '예약' 등)별로, 그다음 날짜별로 파티셔닝됩니다. 이는 Wix ML Platform보다 수년 앞서 구축된, 데이터 분석가들이 사용하는 Wix 데이터 플랫폼의 일부입니다. Spark와 SQL을 사용하는 일일 배치 빌드 프로세스(수 분~수 시간 소요)를 통해 모든 사용자의 히스토리 피처가 S3에서 추출되고, 사용자 단위로 피벗·집계되어 오프라인 스토어(Apache HBase)에 적재됩니다. 이를 통해 사용자별 히스토리 조회가 훨씬 빨라집니다. 시스템이 특정 사용자가 현재 활성 상태임을 감지하면 '워밍업(warmup)' 프로세스가 트리거되어 해당 사용자의 피처가 온라인 스토어(Redis)로 로드됩니다. 온라인 스토어는 활성 사용자의 히스토리만 담고 있으므로 오프라인 스토어보다 훨씬 작습니다. 이 워밍업 프로세스는 몇 초 정도 걸릴 수 있습니다. 마지막으로, 온라인 피처 스토어의 피처는 사용자가 발생시키는 각 이벤트마다 스트리밍 소스에서 들어오는 신선한 실시간 데이터로 지속적으로 갱신됩니다(Apache Storm 사용).
이러한 아키텍처는 Feast 아키텍처에 비해 쓰기 대비 읽기 비율이 낮습니다. 모든 사용자가 아닌 활성 사용자의 피처만 온라인 스토어에 저장하기 때문에 물리화와 온라인 스토리지 측면에서 매우 효율적입니다. Wix의 등록 사용자 중 활성 사용자는 극히 일부이므로 이는 막대한 절약으로 이어집니다. 하지만 대가가 있습니다. 온라인 스토어에서 피처를 조회하는 것은 밀리초 단위로 매우 빠르지만, 피처가 이미 온라인 스토어에 존재하는 경우에만 그렇습니다. 워밍업 프로세스가 몇 초 걸리기 때문에 경합 조건(race condition)상, 사용자가 활성화되는 시점에 필요한 피처를 제때 로드하지 못할 수 있습니다. 그러면 해당 사용자에 대한 스코어링이나 예측은 실패하게 됩니다. 활용 사례가 거래 승인이나 사기 방지 같은 미션 크리티컬 흐름에 포함되지 않는다면 괜찮은 트레이드오프입니다. 이런 아키텍처는 어느 시점에든 활성 사용자 비율이 낮다는 Wix만의 특수성에 잘 맞는 설계이기도 합니다.
3. 상용 피처 스토어 Tecton
이번에는 상용 엔터프라이즈 피처 스토어 Tecton의 아키텍처를 살펴보겠습니다. 아래 다이어그램에서 볼 수 있듯이, Tecton은 배치 데이터 소스와 스트리밍 데이터 소스 외에도 '기본 제공(out-of-the-box)' 실시간 데이터 소스를 지원합니다. 이른바 '실시간 피처(real-time features)' 또는 실시간 변환이라고 불리는 것들입니다. 실시간 피처는 추론 요청 시점에만 계산될 수 있는 피처로, 예를 들어 의심 거래 금액과 마지막 거래 금액의 차이 같은 것이 있습니다. 앞서 살펴본 오픈소스 Feast를 사용한 Better.com의 경우 실시간 피처 지원을 자체적으로 개발해야 했지만, Tecton 피처 스토어에서는 피처 스토어가 기본적으로 지원하므로 훨씬 쉽게 구현할 수 있습니다. Feast와 Wix 피처 스토어와 마찬가지로 Tecton 역시 레지스트리에 피처를 정의하여 논리적 정의를 오프라인·온라인 스토어 양쪽에서 한 번만 정의합니다. 이를 통해 학습-서빙 편차(training-serving skew)를 크게 줄여 프로덕션 환경에서도 ML 모델의 높은 정확도를 보장합니다.
오프라인 스토어, 온라인 스토어 선택 및 벤치마킹과 관련하여, Tecton은 오프라인 피처 스토어로 S3를 지원하고, 온라인 스토어는 고객에게 DynamoDB와 Redis Enterprise Cloud 중 선택권을 제공합니다. 최근 발표에서 Tecton CTO Kevin Stumpf는 회사가 수행한 벤치마크를 바탕으로 온라인 피처 스토어를 선택하는 팁을 공유했습니다. Tecton은 지연 시간과 처리량뿐 아니라 온라인 스토어의 비용까지 벤치마킹했습니다. 왜 비용이 중요할까요? 높은 처리량이나 낮은 지연 시간이 필요한 활용 사례에서는 온라인 스토어 비용이 MLOps 플랫폼 전체 총소유비용에서 큰 비중을 차지할 수 있기 때문에, 절감 효과가 상당할 수 있습니다.
Tecton 벤치마크의 결론은 명확합니다. Tecton 사용자들에게 typical한 높은 처리량 활용 사례에서 Redis Enterprise는 DynamoDB보다 3배 빠르면서 동시에 14배 저렴했습니다.
그렇다면 단점은 없을까요? 활용 사례가 하나뿐이고, 높거나 일관된 처리량이 필요 없으며, 엄격한 지연 시간 요구 사항도 없다면 DynamoDB로 충분할 수 있습니다. Tecton 벤치마크의 전체 세부 내용과 결과는 관련 자료에서 확인할 수 있습니다.
4. Lightricks의 상용 피처 스토어 Qwak 활용 사례
또 다른 피처 스토어 아키텍처 사례를 소개합니다. 셀카 보정 앱 Facetune으로 유명한 유니콘 기업 Lightricks는 영상·이미지 편집 모바일 앱을 개발하는 회사로, 상용 피처 스토어 Qwak을 기반으로 추천 시스템용 피처 스토어를 운영합니다.
위 다이어그램에서 볼 수 있듯이, Tecton과 마찬가지로 Qwak 피처 스토어도 배치, 스트리밍, 실시간 피처의 세 가지 유형의 피처 소스를 지원합니다.
주목할 점은 Qwak 피처 스토어에서는 피처의 물리화가 원본 데이터 소스에서 직접 수행된다는 것입니다. 오프라인 스토어(S3의 Parquet 파일 사용)와 온라인 스토어(Redis 사용) 모두 마찬가지입니다. 이는 Wix, Feast, Tecton 사례와 다른 부분으로, 이들에서는 배치 소스에 대해 오프라인 스토어에서 온라인 스토어로 물리화가 이루어집니다. Qwak 방식의 장점은 학습과 서빙 흐름에서 피처의 변환 로직이 통합될 뿐만 아니라(Feast, Wix, Tecton과 동일), 실제 변환·피처 연산 자체도 동일하게 수행되어 학습-서빙 편차를 더욱 줄일 수 있다는 것입니다. 원본 데이터에서 오프라인·온라인으로 이어지는 통합 데이터 파이프라인은 프로덕션 환경에서 더 높은 정확도를 보장할 잠재력을 갖습니다.
요약
이 글에서는 실시간 AI/ML을 위한 여러 피처 스토어의 벤치마크와 아키텍처의 핵심 내용을 살펴보았습니다. 첫 번째는 오픈소스 Feast, 두 번째는 Wix의 자체 구축 피처 스토어, 세 번째는 Tecton, 네 번째는 Qwak입니다. 또한 이 기업들이 수행한 벤치마크의 주요 결과를 통해 어떤 온라인 스토어가 가장 성능이 좋고 비용 효율적인지 확인했습니다. 온라인 스토어에서 피처를 추출하는 데 어떤 메커니즘이나 피처 서버를 사용해야 하는지도 살펴보았습니다. 피처 스토어의 성능과 비용은 아키텍처, 지원되는 피처 유형, 선택한 컴포넌트에 따라 크게 달라진다는 점을 알 수 있었습니다.
원문 출처: KDnuggets