Feature Store란 무엇인가요?

이 블로그는 원래 Tecton.ai에서 게시되었으며, 2025년 8월 Databricks에 인수되었습니다. 인수 이후 Databricks Feature Store는 배치 및 스트리밍 데이터 모두에 대한 관리형 피처 파이프라인 생성을 자동화하는 강력한 피처 실험 추상화 기능인 Declarative Feature APIs를 출시했습니다.

업데이트: 2025년 5월 15일

저자 소개:
Mike Del Balso, Tecton CEO & 공동 창립자
Willem Pienaar, Feast 제작자

데이터 팀은 운영 머신러닝이 데이터 파이프라인 생성 훨씬 너머의 데이터 문제를 해결해야 한다는 것을 깨닫기 시작했습니다.

이전 게시물 Why We Need DevOps for ML Data에서는 프로덕션 ML 시스템 구축 시 팀이 직면하는 주요 데이터 문제 중 일부를 강조했습니다.

• 올바른 원시 데이터에 액세스
• 원시 데이터에서 피처 빌드
• 피처를 학습 데이터로 결합
• 프로덕션에서 피처 계산 및 제공
• 프로덕션에서 피처 모니터링

대규모 분석 또는 실시간 스트리밍을 위한 프로덕션 데이터 시스템은 새로운 것이 아닙니다. 그러나 고객 대면 애플리케이션에 내장된 ML 기반 인텔리전스인 운영 머신러닝은 대부분의 팀에게는 새로운 것입니다. 운영 목적(예: 추천 시스템, 사기 탐지, 개인화 등)을 위해 머신러닝을 프로덕션에 배포하는 과제는 데이터 도구에 대한 새로운 요구 사항을 도입합니다.

이를 가능하게 하기 위해 새로운 종류의 ML 특화 데이터 인프라가 등장하고 있습니다.

점점 더 많은 데이터 과학 및 데이터 엔지니어링 팀이 ML 애플리케이션을 프로덕션화하는 데 필요한 데이터 세트와 데이터 파이프라인을 관리하기 위해 피처 스토어로 눈을 돌리고 있습니다. 이 게시물은 최신 피처 스토어의 주요 구성 요소를 설명하고 이러한 구성 요소의 합이 데이터 엔지니어링 노력의 중복을 줄이고 머신러닝 수명 주기를 가속화하며 데이터 과학 팀 간의 새로운 종류의 협업을 가능하게 함으로써 조직에 강력한 배율기 역할을 하는 방법을 설명합니다.

빠른 복습: ML에서 피처는 예측 모델의 입력 신호로 사용되는 데이터입니다.

예를 들어, 신용카드 회사가 거래가 사기인지 예측하려고 할 때 유용한 피처는 거래가 해외에서 발생하는지 여부 또는 이 거래의 크기가 고객의 일반적인 거래와 비교했을 때 어떤지일 수 있습니다. 피처를 언급할 때, 우리는 일반적으로 해당 신호의 개념(예: “transaction_in_foreign_country”)을 의미하며, 피처의 특정 값(예: “transaction #1364가 해외에서 발생했다”는 아님)을 의미하는 것은 아닙니다.

피처 스토어의 주요 목적은 무엇인가요?

“모델과 데이터 간의 인터페이스”

우리는 Uber의 Michelangelo 플랫폼을 설명하는 블로그 게시물에서 처음으로 피처 스토어를 소개했습니다. 그 이후로 피처 스토어는 운영 머신러닝 스택의 필수 구성 요소로 부상했습니다.

피처 스토어의 이점은 다음과 같습니다:

1. 광범위한 엔지니어링 지원 없이 새로운 피처를 프로덕션화
2. 피처 계산, 백필 및 로깅 자동화
3. 팀 간 피처 파이프라인 공유 및 재사용
4. 피처 버전, 계보 및 메타데이터 추적
5. 학습 및 제공 데이터 간의 일관성 달성
6. 프로덕션에서 피처 파이프라인의 상태 모니터링

피처 스토어는 운영 ML 애플리케이션 구축 및 운영 시 발생하는 전체 데이터 관리 문제 세트를 해결하는 것을 목표로 합니다.

피처 스토어는 다음과 같은 ML 특화 데이터 시스템입니다:

• 원시 데이터를 피처 값으로 변환하는 데이터 파이프라인 실행
• 피처 데이터 자체를 저장 및 관리하고,
• 학습 및 추론 목적을 위해 피처 데이터를 일관되게 제공

간단한 피처 관리를 지원하기 위해 피처 스토어는 환경 전반에 걸쳐 피처 파이프라인을 쉽게 빌드, 배포 및 이해할 수 있도록 하는 데이터 추상화를 제공합니다. 예를 들어, 피처 변환을 한 번 정의한 다음 개발 환경(학습용 과거 값)과 프로덕션 환경(추론용 최신 피처 값) 모두에서 일관되게 해당 값을 계산하고 제공하는 것을 쉽게 할 수 있습니다.

피처 스토어는 ML 프로젝트 수명 주기 전반에 걸쳐 피처 데이터 및 메타데이터의 중앙 허브 역할을 합니다. 피처 스토어의 데이터는 다음 용도로 사용됩니다:

• 피처 탐색 및 엔지니어링
• 모델 반복, 학습 및 디버깅
• 피처 검색 및 공유
• 추론을 위해 모델에 프로덕션 제공
• 운영 상태 모니터링

피처 스토어는 협업을 가능하게 하여 ML 조직에 규모의 경제를 제공합니다. 피처가 피처 스토어에 등록되면 조직 전체의 다른 모델에서 즉시 재사용할 수 있습니다. 이는 데이터 엔지니어링 노력의 중복을 줄이고 새로운 ML 프로젝트가 프로덕션 준비된 큐레이션된 피처 라이브러리로 부트스트랩할 수 있도록 합니다.

효과적인 피처 스토어는 배포되는 환경에 맞게 조정할 수 있는 모듈식 시스템으로 설계되었습니다. 피처 스토어를 구성하는 5가지 주요 구성 요소가 있습니다. 이 게시물의 나머지 부분에서는 해당 구성 요소를 살펴보고 운영 ML 애플리케이션을 지원하는 역할을 설명합니다.

피처 스토어의 구성 요소는 무엇인가요?

최신 피처 스토어에는 변환, 저장, 제공, 모니터링 및 피처 레지스트리의 5가지 주요 구성 요소가 있습니다.

다음 섹션에서는 이러한 각 섹션의 목적과 일반적인 기능에 대한 개요를 제공합니다.

피처 데이터 제공

Feature stores serve feature data to models. Those models require a consistent view of features across training and serving. The definitions of features used to train a model must exactly match the features provided in online serving. When they don’t match, training-serving skew is introduced, which can cause catastrophic and hard-to-debug model performance problems.

Feature stores abstract away the logic and processing used to generate a feature, providing users an easy and canonical way to access all features in a company consistently across all environments in which they’re needed.

When retrieving data offline (e.g., for training), feature values are commonly accessed through notebook-friendly feature store SDKs. They provide point-in-time correct views of the state of the world for each example used to train a model (a.k.a. “time-travel”).

For online serving, a feature store delivers a single vector of features at a time made up of the freshest feature values. Responses are served through a high-performance API backed by a low-latency database.

Data Storage for Machine Learning

Feature stores persist feature data to support retrieval through feature serving layers. They typically contain both an online and offline storage layer to support the requirements of different feature serving systems.

Offline storage layers are typically used to store months’ or years’ worth of feature data for training purposes. Offline feature store data is often stored in data warehouses or data lakes like S3, BigQuery, Snowflake, Redshift. Extending an existing data lake or data warehouse for offline feature storage is typically preferred to prevent data silos.

Online storage layers are used to persist feature values for low-latency lookup during inference. They typically only store the latest feature values for each entity, essentially modeling the current state of the world. Online stores are usually eventually consistent, and do not have strict consistency requirements for most ML use cases. They are usually implemented with key-value stores like DynamoDB, Redis, or Cassandra.

Feature stores use an entity-based data model where each feature value is associated with an entity (e.g., a user) and a timestamp. An entity-based data model provides minimal structure to support standardized feature management, fits naturally with common feature engineering workflows, and allows for simple retrieval queries in production.

Data Transformation in Machine Learning

Operational ML applications require regular processing of new data into feature values so models can make predictions using an up-to-date view of the world. Feature stores both manage and orchestrate data transformations that produce these values, as well as ingest values produced by external systems. Transformations managed by feature stores are configured by definitions in a common feature registry (described below).

Feature stores commonly interact with three main types of data transformations:

A key benefit is to make it easy to use different types of features together in the same models.

Models need access to fresh feature values for inference. Feature stores accomplish this by regularly recomputing features on an ongoing basis. Transformation jobs are orchestrated to ensure new data is processed and turned into fresh new feature values. These jobs are executed on data processing engines (e.g., Spark or Pandas) to which the feature store is connected.

Model development introduces different transformation requirements. When iterating on a model, new features are often engineered to be used in training datasets that correspond to historical events (e.g., all purchases in the past 6 months). To support these use cases, feature stores make it easy to run “backfill jobs” that generate and persist historical values of a feature for training. Some feature stores automatically backfill newly registered features for preconfigured time ranges for registered training datasets.

Transformation code is reused across environments preventing training-serving skew and frees teams from having to rewrite code from one environment to the next.

Machine Learning Monitoring

When something goes wrong in an ML system, it’s usually a data problem. Feature stores are uniquely positioned to detect and surface such issues. They can calculate metrics on the features they store and serve that describe correctness and quality. Feature stores monitor these metrics to provide a signal of the overall health of an ML application.

Feature data can be validated based on user defined schemas or other structural criteria. Data quality is tracked by monitoring for drift and training-serving skew. E.g. feature data served to models are compared to data on which the model was trained to detect inconsistencies that could degrade model performance.

When running production systems, it’s also important to monitor operational metrics. Feature stores track operational metrics relating to core functionality—for example, metrics relating to feature storage (availability, capacity, utilization, staleness) or feature serving (throughput, latency, error rates). Other metrics describe the operations of important adjacent system components, such as operational metrics for external data processing engines (e.g., job success rate, throughput, processing lag and rate).

Feature stores make these metrics available to existing monitoring infrastructure. This allows ML application health to be monitored and managed with existing observability tools in the production stack.

Having visibility into which features are used by which models, feature stores can automatically aggregate alerts and health metrics into views relevant to specific users, models, or consumers.

머신러닝 모델 레지스트리

모든 피처 스토어의 중요한 구성 요소는 표준화된 피처 정의 및 메타데이터의 중앙 집중식 레지스트리입니다. 레지스트리는 조직 내 피처에 대한 정보의 단일 진실 공급원 역할을 합니다.

레지스트리는 피처 스토어와 사용자 상호 작용을 위한 중앙 인터페이스입니다. 팀은 레지스트리를 공통 카탈로그로 사용하여 팀 내 및 팀 간의 새로운 정의를 탐색, 개발, 협업 및 게시합니다.

레지스트리의 정의는 피처 스토어 시스템 동작을 구성합니다. 자동화된 작업은 레지스트리를 사용하여 데이터 수집, 변환 및 저장을 예약하고 구성합니다. 이는 피처 스토어에 저장되는 데이터와 구성 방식의 기초를 형성합니다. 서빙 API는 어떤 피처 값을 사용할 수 있어야 하는지, 누가 액세스할 수 있어야 하는지, 어떻게 서빙되어야 하는지에 대한 일관된 이해를 위해 레지스트리를 사용합니다.

레지스트리를 사용하면 피처 정의에 중요한 메타데이터를 첨부할 수 있습니다. 이는 소유권, 프로젝트 또는 도메인별 정보를 추적하는 경로를 제공하고 인접 시스템과 쉽게 통합할 수 있는 경로를 제공합니다. 여기에는 계보 추적에 사용되는 종속성 및 버전에 대한 정보가 포함됩니다.

일반적인 디버깅, 규정 준수 및 감사 워크플로를 지원하기 위해 레지스트리는 분석적으로 사용 가능한 것과 프로덕션에서 실제로 실행되는 것에 대한 불변 기록 역할을 합니다.

지금까지 피처 스토어의 핵심 최소 구성 요소를 살펴보았습니다. 실제로는 기업이 규정 준수, 거버넌스 및 보안과 같이 추가적인 엔터프라이즈 중심 기능을 필요로 하는 경우가 많습니다. 이는 향후 블로그 게시물의 주제가 될 것입니다.

피처 스토어로 시작하기

피처 스토어를 최신 ML 애플리케이션의 데이터 흐름의 중심으로 보고 있습니다. 데이터 과학 팀이 ML을 프로덕션 환경에 적용하는 데 있어 중요한 인프라임이 빠르게 입증되고 있습니다. 2028년까지 피처 스토어를 사용하는 조직의 수가 4배로 증가할 것으로 예상합니다.

피처 스토어로 시작하는 데는 몇 가지 옵션이 있습니다.

• Feast는 이미 피처를 계산하는 변환 파이프라인이 있지만 프로덕션에서 사용하기 위한 훌륭한 스토리지 및 서빙 계층이 필요한 경우 훌륭한 옵션입니다. Feast는 현재 GCP 전용이지만 모든 환경에서 경량 피처 스토어로 Feast를 사용할 수 있도록 열심히 노력하고 있습니다. 계속 지켜봐 주세요.
• Tecton은 피처 플랫폼 서비스입니다. Feast와 Tecton의 큰 차이점은 Tecton이 변환을 지원하므로 피처 파이프라인을 Tecton 내에서 엔드투엔드로 관리할 수 있다는 것입니다. Tecton은 관리형 서비스이며 프로덕션 SLA, 호스팅, 고급 협업, 관리형 변환(배치/스트리밍/실시간) 및/또는 엔터프라이즈 기능이 필요한 경우 훌륭한 피처 스토어 선택입니다.

운영 ML 스택의 주요 구성 요소로 부상하는 피처 스토어에 대한 일반적인 정의를 제공하기 위해 이 블로그 게시물을 작성했습니다. 업계에서 이 분야에 대한 활동이 폭발적으로 증가할 것으로 예상합니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)