Feast(Feature Store)는 머신러닝을 위한 오픈소스 피처 스토어입니다. 피처 스토어란 ML 모델 학습과 추론에 사용되는 피처(특성)를 중앙에서 관리하고 서빙하는 시스템입니다. Feast는 오프라인(배치) 학습과 온라인(실시간) 추론에서 동일한 피처를 일관되게 사용할 수 있도록 보장합니다.
Feast는 2019년 Gojek에서 처음 개발되어 이후 Google Cloud와 협력하여 오픈소스로 공개되었습니다. 현재 Tecton이 주도적으로 개발하고 있으며, Linux Foundation AI & Data의 프로젝트입니다. Uber의 Michelangelo, Airbnb의 Zipline 등 대기업들이 내부적으로 구축한 피처 스토어의 개념을 오픈소스화한 것입니다.
Feast의 핵심 개념은 Feature View, Entity, Feature Service입니다. Entity는 피처가 연결되는 대상(사용자 ID, 상품 ID 등)이고, Feature View는 피처 그룹과 데이터 소스의 매핑입니다. Feature Service는 특정 모델이 필요로 하는 피처들을 묶은 것입니다. 오프라인 스토어(BigQuery, Snowflake 등)에서 학습용 데이터를 가져오고, 온라인 스토어(Redis, DynamoDB 등)에서 실시간 서빙합니다.
실무에서 Feast는 피처 재사용, 학습-서빙 불일치(Training-Serving Skew) 방지, 피처 버저닝 등의 문제를 해결합니다. 데이터 팀이 만든 피처를 여러 ML 팀이 공유하고, 동일한 피처 정의로 학습과 추론을 수행합니다. 특히 Point-in-time Join으로 데이터 누수(Data Leakage) 없이 시계열 피처를 정확하게 조인할 수 있습니다.
💻 코드 예제
# feature_store.yaml (프로젝트 설정)
"""
project: my_feature_store
registry: data/registry.db
provider: local
online_store:
type: redis
connection_string: localhost:6379
offline_store:
type: file
"""
# features.py (피처 정의)
from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64, String
# Entity 정의 - 피처가 연결되는 대상
user = Entity(
name="user_id",
description="고객 고유 ID"
)
# 데이터 소스 정의
user_features_source = FileSource(
path="data/user_features.parquet",
timestamp_field="event_timestamp"
)
# Feature View 정의
user_features_view = FeatureView(
name="user_features",
entities=[user],
ttl=timedelta(days=1), # 온라인 스토어 TTL
schema=[
Field(name="age", dtype=Int64),
Field(name="total_purchases", dtype=Int64),
Field(name="avg_purchase_amount", dtype=Float32),
Field(name="membership_level", dtype=String),
],
online=True,
source=user_features_source,
)
# main.py (피처 스토어 사용)
from feast import FeatureStore
import pandas as pd
from datetime import datetime
# 피처 스토어 초기화
store = FeatureStore(repo_path=".")
# 1. 오프라인: 학습 데이터셋 생성 (Point-in-time Join)
entity_df = pd.DataFrame({
"user_id": [1001, 1002, 1003],
"event_timestamp": [
datetime(2024, 1, 15, 10, 0, 0),
datetime(2024, 1, 15, 11, 0, 0),
datetime(2024, 1, 15, 12, 0, 0),
]
})
training_df = store.get_historical_features(
entity_df=entity_df,
features=[
"user_features:age",
"user_features:total_purchases",
"user_features:avg_purchase_amount",
]
).to_df()
print("학습 데이터:")
print(training_df)
# 2. 피처를 온라인 스토어에 Materialize
store.materialize_incremental(end_date=datetime.now())
# 3. 온라인: 실시간 추론을 위한 피처 조회
feature_vector = store.get_online_features(
features=[
"user_features:age",
"user_features:total_purchases",
"user_features:avg_purchase_amount",
],
entity_rows=[{"user_id": 1001}]
).to_dict()
print("실시간 피처:", feature_vector)
# CLI 명령어
# feast apply # 피처 정의 적용
# feast materialize # 오프라인 -> 온라인 스토어 동기화
# feast serve # REST API 서버 실행
🗣️ 실무에서 이렇게 말하세요
MLOps 아키텍처 설계 회의에서
"추천 모델이 3개인데 각각 피처 파이프라인을 따로 만들어서 운영 부담이 큽니다. Feast로 피처 스토어 구축하면 피처 정의를 한 번 하고 여러 모델이 공유할 수 있어요. 온라인 스토어는 Redis로 10ms 이내 응답 가능하고, 오프라인은 BigQuery 연동하면 됩니다."
데이터 사이언티스트와 논의 중
"Training-Serving Skew 문제가 계속 발생하는데, Feast의 Point-in-time Join이 해결책입니다. 학습 시점에 알 수 없었던 미래 데이터가 섞이는 걸 자동으로 방지해주거든요. 학습과 서빙에서 정확히 같은 피처 값을 보장받을 수 있습니다."
기술 면접에서
"피처 스토어가 필요한 이유는 ML 시스템의 확장성 때문입니다. 모델마다 피처 파이프라인을 따로 만들면 중복 개발, 일관성 문제, 운영 비용이 급증합니다. Feast는 피처 정의를 코드로 관리하고 버전 관리할 수 있어서 피처 거버넌스 측면에서도 좋습니다."
⚠️ 흔한 실수 & 주의사항
1
Materialize 주기 설정
온라인 스토어로 피처를 동기화하는 materialize 작업의 주기를 적절히 설정하세요. 너무 자주 하면 비용이 증가하고, 너무 드물면 피처가 오래된 값을 반환합니다. 실시간 피처가 필요하면 Streaming Feature View를 고려하세요.
2
TTL(Time-to-Live) 적절히 설정
온라인 스토어의 TTL이 너무 짧으면 피처가 만료되어 null이 반환됩니다. 반대로 너무 길면 오래된 데이터가 서빙됩니다. 피처의 특성(얼마나 자주 변하는지)에 따라 TTL을 다르게 설정하세요.
3
Entity Key 설계 신중히
Entity Key는 변경하기 어려우므로 초기에 신중히 설계하세요. 복합 키가 필요한 경우 별도 Entity로 정의해야 합니다. 또한 Entity Key 값에 특수문자나 긴 문자열이 들어가면 온라인 스토어 성능에 영향을 줄 수 있습니다.