Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 2026년 5월, "피처 스토어 정말 필요한가?"라는 진지한 질문

2020~2022년의 피처 스토어 황금기는 끝났다. 2026년 5월 현재, 시장은 두 갈래로 갈라졌다. 한쪽은 **Tecton·Hopsworks·Chalk·Fennel 같은 전용 피처 플랫폼**이 엔터프라이즈를 잡고, 다른 한쪽은 **Databricks Unity Catalog + Feature Engineering, Snowflake Cortex, Vertex AI Feature Store 같은 레이크하우스·웨어하우스 네이티브 통합**이 "그냥 데이터 플랫폼 안에 들어 있으면 되지 않나"로 시장을 잠식했다.

그 결과 가장 흔한 질문이 바뀌었다. "어떤 피처 스토어를 도입할까?"가 아니라 **"우리에게 피처 스토어가 정말 필요한가? dbt로 피처 테이블 만들고 Redis에 캐시하면 끝 아닌가?"**다. 이 글은 마케팅 매트릭스를 늘어놓지 않는다. 피처 스토어가 풀려는 진짜 문제, 그 문제가 정말 별도 시스템을 요구하는지, 2026년 현재 선택지가 어디까지 왔는지를 코드와 함께 정리한다.

피처 스토어가 뭐고, 뭐가 아닌가 — 레지스트리·오케스트레이션·서빙의 분리

먼저 단어부터 정확히 한다. **피처 스토어(feature store)**라고 묶어 부르지만, 실제로는 세 개의 독립 책임이 한 박스에 들어 있다.

1. **피처 레지스트리(registry)**: "이 피처는 누가 만들었고, 어떤 소스에서, 어떤 변환으로, 어떤 타입으로 나오는가"의 메타데이터.

2. **오프라인 학습 데이터 생성(offline materialization)**: 과거 시점의 피처 값을 정확한 시간으로 조인해 학습 데이터셋을 만드는 일.

3. **온라인 서빙(online serving)**: 추론 시점에 가장 최신 피처를 ms 단위로 꺼내 주는 키-밸류 룩업.

세 책임은 분리될 수 있다. dbt + Snowflake로 1·2번을, Redis로 3번을 따로 해도 그 자체로 "가벼운 피처 스토어"다. Feast·Tecton·Hopsworks가 하는 일은 **세 책임을 한 API로 묶고, 그 사이의 정합성(특히 학습-서빙 스큐)을 시스템이 보장**해 주는 것이다.

핵심 문제 — 학습-서빙 스큐(training-serving skew)는 왜 생기는가

피처 스토어가 풀려는 단 하나의 본질적 문제는 **학습-서빙 스큐**다. 학습 때 본 피처 값과 추론 때 본 피처 값이 미묘하게 달라서 모델 성능이 무너지는 현상이다. 원인은 단순하다.

- 학습 때는 **과거의 어떤 시점**까지의 데이터로 피처를 계산했다.

- 추론 때는 **현재 시점**의 데이터로 피처를 계산한다.

- 두 코드 경로가 다른 SQL/파이썬으로 짜여 있고, 시간 처리가 미묘하게 다르다.

이걸 막으려면 (a) 피처 정의가 한 곳에 있어야 하고 (b) 과거 시점 조회(point-in-time join)가 정확해야 한다. 피처 스토어가 존재하는 단 하나의 이유라고 봐도 좋다.

온라인 vs 오프라인 스토어 — 왜 두 개의 백엔드를 갖는가

피처 스토어는 거의 항상 두 개의 백엔드를 갖는다.

- **오프라인 스토어(offline store)**: 학습 데이터 생성용. Snowflake, BigQuery, Redshift, Iceberg/Delta on S3. 페타바이트급 과거 데이터, 시간 범위 스캔에 최적.

- **온라인 스토어(online store)**: 추론 서빙용. Redis, DynamoDB, Cassandra, ScyllaDB, Aerospike. 키 룩업 p99 ≤ 10ms.

같은 피처가 두 곳에 **다른 신선도로** 존재한다. 오프라인에는 어제까지의 모든 값이 있고, 온라인에는 "현재 가장 최신" 한 행만 있다. 이 둘을 동기화하는 작업(materialization)이 피처 스토어의 일상 운영이다.

포인트인타임 정합성 — 시간 누수 없는 학습 데이터 만들기

학습 데이터 생성의 핵심은 **이 사용자가 이 라벨을 받은 시점 t에서, 그 시점까지만 알 수 있었던 피처 값을 가져온다**는 규칙이다. 그렇지 않으면 미래 정보가 학습에 새어 들어가 오프라인 성능이 부풀려진다.

피처 스토어의 point-in-time join은 대략 이런 SQL을 안전하게 짜 준다.

-- 라벨 이벤트와 피처 테이블의 시간 정합 조인

SELECT

l.user_id,

l.event_ts,

l.label,

f.feature_value

FROM labels l

LEFT JOIN LATERAL (

SELECT feature_value

FROM user_features f

WHERE f.user_id = l.user_id

AND f.event_ts <= l.event_ts

ORDER BY f.event_ts DESC

LIMIT 1

) f ON TRUE;

이걸 사람이 매번 짜다 보면 어딘가에서 `<` 대신 `<=`를 쓰거나, 조인 순서가 틀어져서 미세한 누수가 생긴다. 피처 스토어의 `get_historical_features`는 이 안전성을 시스템이 책임진다.

Feast — CNCF 샌드박스, 오픈소스 표준의 자리

[Feast](https://feast.dev)는 2020년 Gojek/Google 출신이 만든 오픈소스 피처 스토어로, 2024년 CNCF 샌드박스에 합류했다. 2026년 5월 현재 가장 널리 깔린 OSS다. "BYO 백엔드" 철학으로, Feast 자체는 메타데이터 레지스트리와 SDK만 제공하고 오프라인은 BigQuery/Snowflake/Redshift/Spark, 온라인은 Redis/DynamoDB/Postgres/Bigtable을 꽂아 쓰는 식이다.

전형적인 Feature View 정의는 다음과 같다.

from datetime import timedelta

from feast import Entity, FeatureView, Field, FileSource

from feast.types import Float32, Int64

driver = Entity(name="driver", join_keys=["driver_id"])

driver_stats_source = FileSource(

name="driver_stats_source",

path="data/driver_stats.parquet",

timestamp_field="event_timestamp",

)

driver_stats_fv = FeatureView(

name="driver_hourly_stats",

entities=[driver],

ttl=timedelta(days=1),

schema=[

Field(name="conv_rate", dtype=Float32),

Field(name="acc_rate", dtype=Float32),

Field(name="avg_daily_trips", dtype=Int64),

source=driver_stats_source,

)

`feast apply`로 레지스트리에 등록하고, `feast materialize`로 오프라인→온라인 동기화를 돌린다. 백엔드 선택은 `feature_store.yaml`에서 결정한다.

project: prod_recsys

registry:

registry_type: sql

path: postgresql://feast:***@registry-db:5432/feast

provider: aws

online_store:

type: redis

connection_string: "redis-prod.cluster.local:6379"

offline_store:

type: snowflake.offline

account: xy12345

warehouse: COMPUTE_WH

database: ML

schema: FEATURES

entity_key_serialization_version: 2

학습 시점에는 `store.get_historical_features(entity_df, ...)`, 추론 시점에는 `store.get_online_features(...)`로 조회한다. 단순함이 강점이지만 스트리밍 피처에는 약하다(별도 Push API 또는 외부 스트림 엔진 필요).

Tecton — 상용 SaaS, 스트리밍·배치 통합의 야망

[Tecton](https://www.tecton.ai)은 Uber Michelangelo 출신이 2019년 창업한 상용 피처 플랫폼이다. 2024년 실험 분석 도구 Eppo의 일부 자산을 흡수하면서 "피처 + 실험 + 모델 모니터링"으로 영역을 넓혔다. 가장 큰 강점은 **배치·스트리밍·on-demand 피처를 같은 데코레이터 모델로 정의**한다는 점이다.

from tecton import stream_feature_view, FilteredSource, Aggregation

from datetime import timedelta

@stream_feature_view(

source=FilteredSource(transactions_stream),

entities=[user],

mode="pyspark",

aggregations=[

Aggregation(column="amount", function="sum", time_window=timedelta(minutes=10)),

Aggregation(column="amount", function="count", time_window=timedelta(hours=1)),

online=True,

offline=True,

feature_start_time=datetime(2024, 1, 1),

)

def user_txn_aggregates(transactions):

return transactions.select("user_id", "amount", "timestamp")

Spark Streaming/Flink 위에서 윈도우 집계를 자동으로 돌리고, 같은 정의로 과거 학습 데이터셋도 만들어 준다. 다만 상용 SaaS라 비용이 만만치 않고, Tecton 클러스터가 고객 VPC/AWS 계정에 박히는 구조라 운영 부담이 작지 않다.

Hopsworks — 엔터프라이즈 + 오픈소스, 유럽발 강자

[Hopsworks](https://www.hopsworks.ai)는 스웨덴 Logical Clocks(2023년 Hopsworks AB로 리브랜딩 후 자체 운영)가 만든 풀스택 ML 플랫폼이다. 피처 스토어가 핵심이지만, 그 위에 모델 레지스트리·서빙·벡터 인덱스까지 한 박스에 들어 있다. Apache 2.0 OSS 버전과 SaaS 버전(Serverless 포함)을 동시에 제공한다.

오프라인 스토어는 자체 Hudi 기반 또는 외부 Snowflake/BigQuery, 온라인 스토어는 RonDB(MySQL Cluster 기반 인메모리 KV) 또는 외부 시스템을 쓴다. RonDB의 강점은 트랜잭션 보장과 ms 단위 p99 둘 다를 잡는다는 것이다.

project = hopsworks.login()

fs = project.get_feature_store()

fg = fs.get_or_create_feature_group(

name="user_txn_aggregates",

version=1,

primary_key=["user_id"],

event_time="event_ts",

online_enabled=True,

)

fg.insert(txn_df, write_options={"wait_for_job": True})

fv = fs.create_feature_view(

name="user_fraud_features",

version=1,

query=fg.select_all(),

labels=["is_fraud"],

)

train_df, test_df = fv.train_test_split(test_size=0.2)

EU GDPR/AI Act 대응에 강점이 있어 유럽 금융권에서 채택률이 높다.

Databricks Feature Engineering in Unity Catalog — 레이크하우스 네이티브의 답

Databricks는 2023년까지 별도의 Workspace Feature Store를 가졌지만, 2024년부터 **Unity Catalog 안의 일반 Delta 테이블이 곧 피처 테이블**이라는 단순화로 갈아탔다. 별도 메타데이터 시스템이 사라지고, 피처는 그냥 UC 테이블이고, 권한·계보·검색은 UC가 통합 제공한다.

from databricks.feature_engineering import FeatureEngineeringClient

from databricks.feature_engineering import FeatureLookup

fe = FeatureEngineeringClient()

fe.create_table(

name="ml.user_features.transaction_summary",

primary_keys=["user_id"],

timestamp_keys=["event_ts"],

df=summary_df,

)

training_set = fe.create_training_set(

df=labels_df,

feature_lookups=[

FeatureLookup(

table_name="ml.user_features.transaction_summary",

feature_names=["amount_7d_sum", "amount_30d_avg"],

lookup_key="user_id",

timestamp_lookup_key="event_ts",

)

label="fraud",

)

온라인 서빙은 Databricks Online Tables(Lakebase 기반)로 같은 UC 테이블을 자동 미러링한다. Databricks 안에 사는 회사라면 별도 도구를 검토할 필요가 사실상 없는 수준까지 왔다.

Vertex AI Feature Store — GCP 진영의 통합형

[Vertex AI Feature Store](https://cloud.google.com/vertex-ai/docs/featurestore)는 2023년 대대적인 재설계(Feature Store 2.0)를 거쳐 BigQuery를 오프라인 백엔드로, BigQuery + Bigtable 또는 Optimized Online Store를 온라인 백엔드로 쓰는 구조가 됐다. 즉 사용자가 직접 BigQuery 테이블을 등록(feature view as BQ view)하면, Vertex가 자동으로 온라인 미러를 만들어 ms 단위 서빙을 한다.

별도 ETL이 거의 필요 없다는 게 강점이다. 단점은 GCP 록인과, Tecton·Hopsworks급 스트리밍 자유도가 부족하다는 것이다. Dataflow/Pub/Sub와 결합해 스트리밍 신선도를 끌어올리는 경우가 많다.

SageMaker Feature Store — AWS 정공법

[SageMaker Feature Store](https://aws.amazon.com/sagemaker/feature-store)는 AWS가 2020년 출시한 매니지드 피처 스토어다. 오프라인은 S3 + Athena/Glue, 온라인은 자체 DynamoDB 기반 인메모리 KV. **Feature Group**이라는 단위로 피처를 묶고, 같은 데이터가 두 스토어에 동기적으로 또는 비동기적으로 흐른다.

2024년에 추가된 **In-Memory Online Store** 옵션은 p99 < 5ms로, 광고 입찰 같은 초저지연 경로에 쓸 만한 수준이다. SageMaker Studio·Pipelines·Model Registry와의 통합이 강점이고, EMR/Glue로 배치 변환을, Kinesis Data Analytics/Flink로 스트리밍 변환을 붙인다.

Featureform과 가벼운 대안들 — "가상 피처 스토어"라는 다른 접근

[Featureform](https://www.featureform.com)은 "물리적 데이터를 옮기지 않고, 기존 인프라(Snowflake, BigQuery, Spark, Redis, DynamoDB) 위에 가상 레이어만 얹는다"는 컨셉으로 시작했다. 즉 Featureform은 정의·계보·접근 제어를 관리하지만, 실제 데이터는 사용자의 기존 시스템에 그대로 둔다. 이 접근의 강점은 도입 비용이 낮다는 것이고, 단점은 "정의만 있고 실행은 외부"라는 점이 사용자에게 새 운영 부담을 떠넘긴다는 것이다.

같은 결의 다른 길로 **TensorFlow TFX FeatureColumn**(레거시), **PyTorch TorchRec**(추천 모델 임베딩 테이블), **Apache Airflow + Redis**의 수제 조합도 여전히 흔하다. Splice Machine(2022년 폐쇄)·Logical Clocks(Hopsworks로 리브랜딩)처럼 사라진 벤더의 자취도 남아 있어, 신규 도입 시 활성도 점검은 필수다.

Bytewax — 파이썬 네이티브 스트리밍 피처 엔진

[Bytewax](https://www.bytewax.io)는 Rust 코어 위에 파이썬 데이터플로 API를 제공하는 스트리밍 처리 엔진이다. Kafka·Kinesis·Pulsar 같은 스트림 소스에서 받아 윈도우 집계·조인·세션화 같은 변환을 파이썬으로 짠다. Flink/Spark Streaming의 강력함은 약간 양보하지만, **데이터 사이언티스트가 직접 운영 가능한 파이썬 코드**라는 점이 장점이다.

from bytewax.connectors.kafka import KafkaSource, KafkaSink

from bytewax.dataflow import Dataflow

flow = Dataflow("user-amount-1min")

stream = op.input("kafka-in", flow, KafkaSource(brokers=["kafka:9092"], topics=["txns"]))

keyed = op.key_on("key-by-user", stream, lambda r: r["user_id"])

windowed = op.windowed_reduce(

"amount-1min-sum",

keyed,

clock=...,

windower=...,

builder=lambda: 0.0,

folder=lambda acc, r: acc + r["amount"],

)

op.output("kafka-out", windowed, KafkaSink(brokers=["kafka:9092"], topic="features"))

Bytewax는 자체 피처 스토어가 아니다. 출력을 Feast·Tecton의 온라인 스토어(Redis)에 직접 쓰거나, Kafka 토픽을 통해 Feast Push API로 흘려보내는 식으로 결합한다.

Materialize · RisingWave · Feldera · ksqlDB — 스트리밍 SQL로 피처 만들기

스트리밍 피처를 만드는 또 다른 길은 **스트리밍 SQL 엔진**이다. 한 번 작성한 `CREATE MATERIALIZED VIEW`가 들어오는 이벤트에 따라 점진적으로 결과를 갱신하고, 그 결과를 그대로 온라인 스토어에 쓴다.

- **Materialize**: 차등 데이터플로(differential dataflow) 기반. ANSI SQL 호환, 강한 정합성. 2024년 BYOC 모드 추가.

- **RisingWave**: 스트림 처리 + 영속 상태 결합. PostgreSQL 와이어 호환.

- **Feldera**: DBSP(Database Stream Processor) 논문 기반의 점진 계산 엔진. 2024년 OSS 공개.

- **ksqlDB**: Confluent의 Kafka 네이티브 스트리밍 SQL.

스트리밍 SQL의 강점은 동일 SQL이 배치(과거 학습 데이터)와 스트리밍(현재 피처)에 모두 통한다는 것이다. 학습-서빙 스큐의 코드 경로 분기를 근본부터 줄인다.

-- Materialize/RisingWave: 사용자별 최근 10분 거래 합계 (스트리밍)

CREATE MATERIALIZED VIEW user_amount_10m AS

SELECT

user_id,

SUM(amount) AS amount_10m_sum,

COUNT(*) AS txn_10m_count

FROM transactions

WHERE event_ts >= mz_now() - INTERVAL '10 minutes'

GROUP BY user_id;

이 뷰가 Redis로 흘러가면 그게 곧 온라인 피처다.

Fennel · Chalk — 트랜잭셔널·외부 API 통합형 피처 스토어

핀테크·결제·보험에서 가장 빠르게 자리를 잡은 두 신규 진영이다.

[Fennel.ai](https://fennel.ai)는 "**SQL이 아니라 파이썬 데이터프레임 API**로 스트리밍·배치 피처를 한 정의로 짠다"는 컨셉으로 2022년 등장했다. 핵심 차별점은 **트랜잭셔널 일관성**으로, 같은 사용자에 대한 피처 갱신이 결제·이벤트 시퀀스와 동일 순서로 적용된다. 2025년 Stripe가 Fennel을 인수하면서 외부 SaaS 활동은 줄었지만, 트랜잭셔널 피처 스토어 개념 자체가 결제 도메인의 표준이 될 것이라는 신호로 받아들여진다.

[Chalk.ai](https://chalk.ai)는 2022년 등장한 상용 피처 플랫폼으로, 파이썬 클래스로 피처를 정의하고 자동으로 배치·스트리밍 두 경로를 생성한다. 강점은 (a) 외부 API 호출을 피처로 1급 시민화한 점(예: 신용평가 API 응답을 캐시 가능한 피처로), (b) 추론 시점에 필요한 피처 그래프를 자동 토폴로지 정렬해 호출하는 점이다. 2026년 5월 현재 핀테크·보험 영역에서 빠르게 점유율을 늘리고 있고, 단점은 클로즈드 소스 SaaS라는 점과 가격이다.

임베딩이 피처가 될 때 — 벡터 DB와의 수렴

2024년까지 임베딩(벡터)은 별도 트랙이었다. 2026년에는 **임베딩도 피처의 한 종류**로 다뤄진다. Tecton/Hopsworks/Feast 모두 벡터 타입을 1급 지원하고, 온라인 스토어로 Pinecone/Weaviate/Milvus/PostgreSQL pgvector를 등록할 수 있다.

이 수렴의 결과는 두 가지다. 하나는 벡터 DB가 "임베딩 전용 피처 스토어"로 포지셔닝되는 흐름(Pinecone Serverless, Weaviate Cloud). 다른 하나는 피처 스토어가 벡터 인덱스를 흡수해 통합 SDK로 가는 흐름(Hopsworks의 Vector Index). 2027년쯤이면 둘의 경계가 거의 사라질 가능성이 높다.

피처 모니터링 — 드리프트 감지가 1급 시민이 되다

피처 스토어의 두 번째 큰 책임은 **피처 자체의 품질 모니터링**이다. 분포 변화(drift), 결측 비율, 카디널리티 폭증, 시간 단위 신선도 SLO 같은 지표를 자동으로 본다. Evidently AI, Arize, WhyLabs, Fiddler 같은 모니터링 도구들이 피처 스토어와 직접 통합되고, 일부(Tecton·Hopsworks)는 자체 모니터링을 내장한다.

핵심은 **모델 성능이 떨어졌을 때 그게 모델 문제인지 데이터/피처 문제인지를 빠르게 분리**하는 것이다. 피처 드리프트를 못 보면 모델만 계속 재학습하면서 근본 원인을 놓친다.

비교 표 — 한눈에 보는 2026년 피처 스토어 지형

| 도구 | OSS | 스트리밍 | 배치 | 온라인 | 오프라인 | 계보/거버넌스 | 운영 모델 |

| --- | --- | --- | --- | --- | --- | --- | --- |

| Chalk.ai | 클로즈드 | 강함 | 강함 | 자체 | 자체/외부 | 강함 | SaaS |

| Fennel(Stripe) | 클로즈드 | 매우 강함 | 강함 | 자체 | 자체 | 강함 | 내부화 |

데이터 컨트랙트와 모델-피처 그래프 — 거버넌스의 근육

피처 스토어를 운영하다 보면 결국 **데이터 컨트랙트**의 문제로 수렴한다. 누군가 업스트림 테이블 스키마를 바꾸면 피처 계산이 깨지고, 모델 추론도 깨진다. 2026년의 좋은 피처 스토어는 (a) 업스트림 소스의 스키마 변경을 자동 감지하고, (b) 영향받는 피처 뷰와 모델을 계보 그래프로 보여 주며, (c) 호환되지 않는 변경을 사전에 차단한다. Databricks Unity Catalog의 컬럼 마스킹/계보, Tecton의 source tracking, Hopsworks의 schema evolution policy가 이 영역의 사례다.

그 위에 **모델-피처 양방향 그래프**가 필요하다. Feature X가 사라지면 영향받는 모델 목록이, Model Y의 입력으로는 어떤 Feature가 들어가는지가 즉시 보여야 한다. MLflow Model Registry, Databricks UC의 model lineage, Tecton의 Feature Service-Model 연결, 그리고 외부 카탈로그(DataHub, OpenMetadata)와의 연동이 이 영역을 담당한다. 이게 안 되는 피처 스토어는 결국 깨진다.

레이크하우스 통합 가설 — "피처 스토어는 별도가 아니라 레이어다"

2025년 이후 가장 강한 흐름은 **피처 스토어가 별도 제품이 아니라 레이크하우스의 한 레이어로 흡수된다**는 것이다. Databricks가 Workspace Feature Store를 UC FE로 합친 게 결정적 신호였고, Snowflake도 Snowpark + Snowflake Feature Store(2024년 GA)로 같은 길을 갔다. Iceberg + Polaris/Tabular 진영도 같은 방향이다.

이 가설이 옳다면, 2027~2028년에는 "전용 피처 스토어"라는 카테고리는 핀테크/광고 같은 초저지연·트랜잭셔널 영역에서만 살아남고, 일반 ML은 레이크하우스 안에서 끝난다. 다만 그 전제는 **온라인 스토어 통합이 충분히 빨라야 한다**는 것인데, 2026년 5월 시점 Online Tables/Bigtable 통합은 아직 핀테크 수준에는 못 미친다.

"그냥 dbt + Redis면 안 되는가?"라는 진지한 답

이 글의 가장 솔직한 답이다. 다음 조건을 다 만족하면 **별도 피처 스토어 없이도 충분하다**.

- 모델 수가 5개 이하다.

- 피처가 대부분 배치(시간당/일별)다. 1분 미만 신선도는 필요 없다.

- 같은 피처를 여러 모델이 공유하지 않는다(재사용이 적다).

- 학습-서빙 스큐를 막을 책임자가 명확하고, point-in-time join을 직접 짤 수 있다.

- 거버넌스/감사 요구가 약하다.

반대로 다음이 하나라도 있으면 별도 피처 스토어가 답일 가능성이 높다.

- 모델 수가 수십~수백 개로 늘고 있다.

- 스트리밍 피처가 1초~1분 단위 신선도를 요구한다.

- 동일 피처를 5개 이상 모델이 공유한다.

- 규제(GDPR, AI Act, 한국 개인정보보호법) 대응에 계보가 필요하다.

- 사기 탐지·추천·광고처럼 ms 단위 온라인 룩업이 핵심 경로다.

한국 도입 사례 — Coupang · Toss · Naver

- **Coupang**은 추천·랭킹·물류 ETA 모델을 위한 자체 피처 플랫폼을 2021년경부터 운영한다. 사외 발표(Coupang Engineering Blog 등)에서 Spark + Redis + 자체 메타데이터 레이어 구조가 공개된 바 있고, 2025~2026년에는 Iceberg 기반 오프라인 + Aerospike/Redis 온라인 조합으로 진화한 것으로 알려져 있다.

- **Toss**는 사기 탐지·추천·신용평가에서 Kafka + Flink + Redis 조합의 스트리밍 피처 파이프라인을 SLASH 컨퍼런스 등에서 공유했다. 별도 풀스택 피처 스토어보다 "각 도메인이 자기 피처 파이프라인을 짧게 운영한다"는 분산 전략이 특징이다.

- **Naver**는 Hyperion 같은 내부 ML 플랫폼에 피처 관리 컴포넌트를 두고, HBase/Redis/MySQL을 백엔드로 쓰는 구조를 공개해 왔다. 검색·쇼핑·클로바 라인업이 각자 변형해 사용한다.

세 회사 모두 **순수 OSS(Feast)나 SaaS(Tecton)을 단독 도입하기보다, 자체 빌드 또는 부분 차용**의 길을 택했다. 트래픽 규모와 도메인 특수성이 OSS를 그대로 쓰기 어려운 영역에 있다.

일본 도입 사례 — Mercari · ZOZO · CyberAgent

- **Mercari**는 2022~2023년 Feast 기반 자체 피처 플랫폼 구축 사례를 Mercari Engineering Blog에 공개했다. BigQuery 오프라인 + Redis 온라인 + Vertex AI 학습 파이프라인을 결합한 구조다.

- **ZOZO**는 추천·검색 피처를 BigQuery + Memorystore Redis로 운영하는 패턴을 ZOZO TECH BLOG에서 여러 차례 공개했다. 일부 모델에서 Vertex AI Feature Store 검토 사례도 보고됐다.

- **CyberAgent AI Lab**은 광고·게임 추천에서 스트리밍 피처 파이프라인(Kafka + Flink/Beam + Bigtable) 구축 사례를 ai-tech-publish 등에서 공유했다. 광고 입찰 같은 ms 영역은 별도 인메모리 KV로 분리하는 전형적 패턴을 보여 준다.

세 회사 모두 일본 특유의 "BigQuery 중심 + GCP 매니지드 활용" 전략을 따라가는 경향이 있다.

2026~2027 전망 — 통합·축소·전문화

세 가지 흐름이 동시에 진행된다.

1. **레이크하우스 통합**: 범용 ML은 Databricks UC FE, Snowflake Feature Store로 흡수된다.

2. **OSS 중간 진영의 축소**: Feast가 표준 위치를 굳히되, 다른 OSS 후발주자들은 활성도가 줄어들 것이다.

3. **전문화된 SaaS의 생존**: 핀테크·광고·사기 탐지처럼 ms 단위 트랜잭셔널 피처가 필요한 영역은 Tecton·Hopsworks·Chalk가 여전히 답이다.

스트리밍 SQL(Materialize, RisingWave, Feldera) 진영이 "피처 스토어"로 직접 포지셔닝하는 것도 흥미로운 변수다. 2027년에는 "피처 스토어 vs 스트리밍 DB"의 경계 자체가 흐려질 가능성이 높다.

마치며 — 도구가 아니라 책임을 고른다

피처 스토어를 고르는 결정은 결국 **세 가지 책임(레지스트리·정합성·서빙)을 누구에게 맡길 것인가**의 결정이다. 이미 Databricks/Snowflake/GCP/AWS 한 곳을 깊게 쓴다면, 그 플랫폼의 네이티브 피처 기능부터 검증한다. 멀티 클라우드이거나 스트리밍 신선도가 핵심이면 Tecton/Hopsworks/Chalk를 본다. 가벼운 OSS 표준이 필요하면 Feast다.

마지막으로 자주 무너지는 운영 안티패턴을 짧게 짚는다. (1) 재사용되지 않는 일회성 SQL까지 피처로 등록해 카탈로그를 망친다. (2) 온라인 신선도 SLO(p99 ≤ X분)를 명시하지 않는다. (3) 피처 드리프트 모니터링이 없어 모델만 의심한다. (4) 피처마다 owner 필드가 비어 있어 6개월 뒤 누구도 손대지 못한다. (5) 피처 정의에 대한 단위·회귀 테스트가 없어 미세한 변경이 학습-서빙 스큐를 만든다.

"피처 스토어가 정말 필요한가?"라는 질문에 정직하게 답하자. 모델 수가 10개 미만이고 배치 위주라면, 잘 짜인 dbt + Redis 캐시도 훌륭한 피처 스토어다. 그 위에 도구를 얹는 건 그다음이다.

References

- Feast 공식 문서: https://docs.feast.dev/

- Tecton 공식 문서: https://docs.tecton.ai/

- Hopsworks 공식 문서: https://docs.hopsworks.ai/

- Databricks Feature Engineering: https://docs.databricks.com/aws/en/machine-learning/feature-store/

- Vertex AI Feature Store: https://cloud.google.com/vertex-ai/docs/featurestore

- SageMaker Feature Store: https://aws.amazon.com/sagemaker/feature-store/

- Bytewax 공식 문서: https://docs.bytewax.io/

- Materialize 공식 문서: https://materialize.com/docs/

- RisingWave 공식 문서: https://docs.risingwave.com/

- Feldera GitHub: https://github.com/feldera/feldera

- Featureform 공식 문서: https://docs.featureform.com/

- Chalk.ai 공식 문서: https://docs.chalk.ai/

- Fennel.ai 블로그(Stripe 인수 이전): https://fennel.ai/blog

- ksqlDB 공식 문서: https://docs.ksqldb.io/

- Feast GitHub: https://github.com/feast-dev/feast

- Apache Flink 공식 문서: https://flink.apache.org/docs/

- Snowflake Feature Store: https://docs.snowflake.com/en/developer-guide/snowflake-ml/feature-store/overview

- Evidently AI 공식 문서: https://docs.evidentlyai.com/

- Arize AI 공식 문서: https://docs.arize.com/arize

- Coupang Engineering Blog: https://medium.com/coupang-engineering

- Toss Engineering(SLASH): https://toss.tech/

- Mercari Engineering Blog: https://engineering.mercari.com/en/blog/

- ZOZO TECH BLOG: https://techblog.zozo.com/

- CyberAgent AI Tech Publish: https://ai-tech.cyberagent.co.jp/

- classmethod.jp Feature Store: https://dev.classmethod.jp/articles/?s=feature+store