Feast Feature Store 완벽 가이드

머신러닝 모델에 필요한 피처를 효율적으로 관리하고 서빙하는 Feast Feature Store의 모든 것을 다룹니다. 초급 개발자도 쉽게 따라할 수 있도록 설치부터 실시간 서빙까지 단계별로 설명합니다.

---

목차

1. Feature_Store_개념_이해
2. Feast_아키텍처_및_설치
3. Feature_View_정의하기
4. Online_Offline_Store_설정
5. 실시간_Feature_서빙
6. Feature_재사용_전략

---

1. Feature Store 개념 이해

김개발 씨는 머신러닝 팀에 합류한 지 한 달이 되었습니다. 오늘은 추천 모델을 학습시키는 업무를 맡았는데, 데이터를 준비하는 과정에서 이상한 점을 발견했습니다.

"어라, 학습할 때 쓴 피처랑 실제 서비스에서 쓰는 피처가 다르네요?"

Feature Store는 한마디로 머신러닝에 필요한 피처를 중앙에서 관리하고 제공하는 저장소입니다. 마치 도서관이 책을 체계적으로 정리해두고 누구든 쉽게 찾아 볼 수 있게 하는 것과 같습니다.

이것을 제대로 이해하면 학습과 서빙 간의 피처 불일치 문제를 해결하고 피처 재사용성을 높일 수 있습니다.

다음 코드를 살펴봅시다.

# Feature Store의 기본 개념을 보여주는 예시
from feast import FeatureStore

# Feature Store 초기화
store = FeatureStore(repo_path=".")

# 학습 데이터 조회 (Offline Store에서)
training_df = store.get_historical_features(
    entity_df=entity_dataframe,
    features=["user_features:age", "user_features:purchase_count"]
).to_df()

# 실시간 추론용 피처 조회 (Online Store에서)
online_features = store.get_online_features(
    features=["user_features:age", "user_features:purchase_count"],
    entity_rows=[{"user_id": 1001}]
).to_dict()

김개발 씨는 입사 후 첫 번째 머신러닝 프로젝트를 맡게 되었습니다. 사용자에게 상품을 추천하는 모델을 만드는 일이었습니다.

열심히 데이터를 수집하고 피처를 만들어서 모델을 학습시켰습니다. 성능도 꽤 좋았습니다.

그런데 모델을 실제 서비스에 배포하고 나서 문제가 생겼습니다. 모델의 성능이 학습할 때와 많이 달랐던 것입니다.

박시니어 씨가 코드를 살펴보더니 고개를 저었습니다. "학습할 때 쓴 피처 계산 로직이랑 서빙할 때 쓴 로직이 다르네요.

이걸 Training-Serving Skew라고 해요." 그렇다면 Feature Store란 정확히 무엇일까요? 쉽게 비유하자면, Feature Store는 마치 대형 마트의 식재료 창고와 같습니다.

요리사가 음식을 만들 때 필요한 재료를 매번 시장에 가서 사는 대신, 창고에서 바로 꺼내 쓸 수 있습니다. 재료는 항상 같은 품질로 관리되고, 여러 요리사가 동시에 같은 재료를 사용할 수 있습니다.

Feature Store도 마찬가지로 ML 파이프라인에 필요한 피처를 중앙에서 관리합니다. Feature Store가 없던 시절에는 어땠을까요?

데이터 과학자들은 모델을 학습시킬 때마다 피처를 직접 계산해야 했습니다. SQL 쿼리를 작성하고, 데이터를 변환하고, 정제하는 과정을 매번 반복했습니다.

더 큰 문제는 서빙 단계에서 같은 피처를 다시 구현해야 한다는 것이었습니다. 백엔드 개발자가 Python으로 작성된 피처 로직을 Java나 Go로 다시 구현하다 보면 미묘한 차이가 생기기 마련이었습니다.

바로 이런 문제를 해결하기 위해 Feature Store가 등장했습니다. Feature Store를 사용하면 피처 정의를 한 곳에서 관리할 수 있습니다.

학습할 때도, 서빙할 때도 같은 피처 정의를 사용하므로 일관성이 보장됩니다. 또한 피처 재사용이 가능해집니다.

한 팀이 만든 피처를 다른 팀도 쉽게 가져다 쓸 수 있습니다. 무엇보다 시점 정합성을 보장한다는 큰 장점이 있습니다.

위의 코드를 살펴보겠습니다. 먼저 FeatureStore 객체를 초기화합니다.

repo_path는 피처 정의가 담긴 저장소 경로입니다. get_historical_features 메서드는 과거 시점의 피처를 조회합니다.

이는 모델 학습에 사용됩니다. get_online_features 메서드는 실시간으로 최신 피처를 조회합니다.

이는 실시간 추론에 사용됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 이커머스 회사에서 추천 시스템을 운영한다고 가정해봅시다. 사용자의 최근 구매 내역, 클릭 패턴, 선호 카테고리 같은 피처가 필요합니다.

Feature Store를 활용하면 이런 피처를 한 번 정의해두고 추천팀, 검색팀, 마케팅팀이 모두 재사용할 수 있습니다. 하지만 주의할 점도 있습니다.

초보자들이 흔히 하는 실수 중 하나는 모든 데이터를 피처로 만들어 Feature Store에 넣으려는 것입니다. 피처는 ML 모델에 실제로 사용되는 것만 등록해야 합니다.

그렇지 않으면 관리 비용만 늘어납니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 Feature Store를 도입하자고 했던 거군요!" Feature Store를 제대로 이해하면 ML 시스템의 안정성과 효율성을 크게 높일 수 있습니다.

다음 장에서는 오픈소스 Feature Store인 Feast를 본격적으로 살펴보겠습니다.

실전 팁

💡 - Feature Store는 피처의 단일 진실 공급원(Single Source of Truth) 역할을 합니다

• 학습용 피처와 서빙용 피처를 분리하지 말고 하나의 정의로 관리하세요

---

2. Feast 아키텍처 및 설치

김개발 씨는 Feature Store의 필요성을 이해하고 나서 직접 구축해보기로 했습니다. 검색을 해보니 Uber, Google, Netflix 등에서 각자 Feature Store를 만들어 썼다고 합니다.

"우리 같은 작은 팀도 Feature Store를 쓸 수 있을까요?" 박시니어 씨가 웃으며 대답했습니다. "Feast라는 오픈소스가 있어요."

Feast는 오픈소스 Feature Store로, 피처 정의부터 저장, 서빙까지 ML 피처의 전체 생명주기를 관리합니다. 마치 레고 블록처럼 필요한 컴포넌트만 조립해서 사용할 수 있어 작은 팀부터 대규모 조직까지 유연하게 적용할 수 있습니다.

설치도 pip 한 줄이면 충분합니다.

다음 코드를 살펴봅시다.

# Feast 설치
# pip install feast

# 새 Feast 프로젝트 초기화
# feast init my_feature_repo
# cd my_feature_repo

# feature_store.yaml - Feast 설정 파일
project: my_ml_project
registry: data/registry.db
provider: local
online_store:
    type: sqlite
    path: data/online_store.db
offline_store:
    type: file
entity_key_serialization_version: 2

# 설정 적용 및 피처 등록
# feast apply

박시니어 씨의 말을 듣고 김개발 씨는 Feast에 대해 조사하기 시작했습니다. Feast는 원래 Gojek이라는 동남아시아 슈퍼앱 회사에서 만들었습니다.

지금은 Tecton이라는 회사가 주도적으로 개발하고 있고, 완전히 오픈소스로 공개되어 있습니다. 그렇다면 Feast의 구조는 어떻게 되어 있을까요?

Feast는 크게 세 가지 핵심 컴포넌트로 이루어져 있습니다. 첫 번째는 Offline Store입니다.

과거 데이터를 저장하고 학습용 데이터셋을 생성하는 역할을 합니다. 두 번째는 Online Store입니다.

최신 피처 값을 저장하고 실시간 서빙에 사용됩니다. 세 번째는 Registry입니다.

피처 정의와 메타데이터를 관리합니다. 쉽게 비유하자면, Feast는 마치 음식 배달 시스템과 같습니다.

Offline Store는 식재료 창고입니다. 대량의 재료를 보관하고 필요할 때 꺼내 씁니다.

Online Store는 매장 앞 진열대입니다. 자주 찾는 인기 메뉴를 미리 준비해둡니다.

Registry는 메뉴판입니다. 어떤 음식이 있는지, 재료는 무엇인지 정보를 담고 있습니다.

Feast를 설치하는 방법은 매우 간단합니다. 터미널에서 pip install feast 명령어 한 줄이면 됩니다.

설치가 완료되면 feast init 명령어로 새 프로젝트를 생성할 수 있습니다. 이 명령어는 예제 피처 정의와 설정 파일을 포함한 기본 구조를 만들어줍니다.

feature_store.yaml 파일을 살펴보겠습니다. project 항목은 프로젝트 이름입니다.

여러 프로젝트를 운영할 때 구분하는 데 사용됩니다. registry는 피처 정의를 저장할 위치입니다.

provider는 인프라 환경을 지정합니다. local, gcp, aws 등을 선택할 수 있습니다.

online_store와 offline_store는 각각 어떤 저장소를 사용할지 설정합니다. 로컬 개발 환경에서는 SQLite와 파일 기반 저장소로 충분합니다.

하지만 프로덕션 환경에서는 더 강력한 저장소가 필요합니다. Online Store로는 Redis, DynamoDB, PostgreSQL 등을 사용할 수 있습니다.

Offline Store로는 BigQuery, Redshift, Snowflake, Spark 등을 연동할 수 있습니다. feast apply 명령어는 무엇을 할까요?

이 명령어는 피처 정의 파일을 읽어서 Registry에 등록합니다. 또한 Online Store와 Offline Store에 필요한 테이블이나 스키마를 생성합니다.

피처 정의가 변경될 때마다 이 명령어를 실행해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

설치를 마친 김개발 씨는 생성된 폴더 구조를 살펴보았습니다. example_repo.py 파일에 예제 피처 정의가 있었습니다.

"생각보다 훨씬 간단하네요!" Feast의 아키텍처를 이해했다면 이제 실제로 피처를 정의할 차례입니다. 다음 장에서는 Feature View를 작성하는 방법을 알아보겠습니다.

실전 팁

💡 - 처음에는 local provider로 시작하고, 프로덕션에서는 gcp나 aws provider를 사용하세요

• feast init 대신 feast init -t gcp나 feast init -t aws로 클라우드 템플릿을 사용할 수 있습니다

---

3. Feature View 정의하기

설치를 마친 김개발 씨는 이제 실제로 피처를 정의해보려고 합니다. 그런데 처음 보는 개념들이 눈에 들어왔습니다.

Entity, Feature View, Data Source... 박시니어 씨에게 물어보니 "Feature View가 Feast의 핵심이에요.

마치 데이터베이스의 View처럼 피처를 논리적으로 묶어놓은 거죠"라고 설명해주었습니다.

Feature View는 관련된 피처들을 하나의 논리적 단위로 묶어놓은 것입니다. 마치 엑셀 시트에서 관련된 열들을 하나의 표로 정리하는 것과 같습니다.

Feature View를 정의하려면 Entity(주체), Data Source(데이터 출처), Feature(피처 컬럼)를 지정해야 합니다.

다음 코드를 살펴봅시다.

from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64, String
from datetime import timedelta

# Entity 정의 - 피처의 주체
user = Entity(
    name="user_id",
    description="사용자 고유 식별자"
)

# Data Source 정의 - 피처 데이터의 출처
user_source = FileSource(
    path="data/user_features.parquet",
    timestamp_field="event_timestamp"
)

# Feature View 정의 - 피처들의 논리적 그룹
user_features = FeatureView(
    name="user_features",
    entities=[user],
    ttl=timedelta(days=1),
    schema=[
        Field(name="age", dtype=Int64),
        Field(name="purchase_count", dtype=Int64),
        Field(name="avg_purchase_amount", dtype=Float32),
    ],
    source=user_source,
)

김개발 씨는 사용자 추천 모델에 필요한 피처를 정리해보았습니다. 사용자의 나이, 구매 횟수, 평균 구매 금액 등이 필요했습니다.

이 피처들을 어떻게 Feast에 등록할 수 있을까요? 먼저 Entity를 이해해야 합니다.

Entity는 피처의 주체입니다. 쉽게 말해 "누구의 피처인가"를 나타냅니다.

사용자 피처라면 user_id가 Entity가 됩니다. 상품 피처라면 product_id가 Entity가 됩니다.

마치 데이터베이스 테이블의 Primary Key와 비슷한 역할을 합니다. 다음으로 Data Source를 정의합니다.

Data Source는 피처 데이터가 어디에서 오는지를 지정합니다. Feast는 다양한 데이터 소스를 지원합니다.

로컬 파일(Parquet, CSV), 데이터 웨어하우스(BigQuery, Redshift, Snowflake), 메시지 큐(Kafka) 등을 연결할 수 있습니다. timestamp_field는 매우 중요합니다.

Feast가 시점 정합성을 보장하는 데 사용됩니다. 이제 핵심인 Feature View를 정의해봅시다.

Feature View는 마치 식당의 세트 메뉴와 같습니다. 관련된 음식들을 하나의 세트로 묶어두면 주문하기도 편하고 관리하기도 쉽습니다.

사용자 관련 피처들을 user_features라는 Feature View로 묶고, 상품 관련 피처들은 product_features라는 별도의 Feature View로 관리합니다. 위의 코드를 자세히 살펴보겠습니다.

name은 Feature View의 이름입니다. 나중에 피처를 조회할 때 이 이름을 사용합니다.

entities는 이 피처가 어떤 Entity에 속하는지 지정합니다. ttl은 Time To Live의 약자로, 피처의 유효 기간입니다.

1일이 지난 피처는 오래된 것으로 간주됩니다. schema 부분이 실제 피처 정의입니다.

Field 클래스로 각 피처의 이름과 데이터 타입을 지정합니다. Feast는 Int64, Float32, String, Bool 등 다양한 타입을 지원합니다.

배열 타입도 사용할 수 있어서 임베딩 벡터 같은 복잡한 피처도 저장할 수 있습니다. 실무에서 Feature View를 설계할 때는 몇 가지 원칙이 있습니다.

첫째, 관련된 피처끼리 묶습니다. 사용자의 인구통계 정보는 user_demographics, 행동 데이터는 user_behaviors로 분리하면 관리가 편합니다.

둘째, 갱신 주기가 비슷한 피처끼리 묶습니다. 실시간으로 변하는 피처와 하루에 한 번 업데이트되는 피처는 분리하는 것이 좋습니다.

주의할 점도 있습니다. Feature View에 너무 많은 피처를 넣지 마세요.

하나의 Feature View에 수백 개의 피처가 있으면 조회 성능이 떨어질 수 있습니다. 또한 피처 이름은 명확하게 짓는 것이 중요합니다.

cnt 대신 purchase_count처럼 의미를 알 수 있는 이름을 사용하세요. 김개발 씨는 드디어 첫 번째 Feature View를 작성했습니다.

feast apply 명령어를 실행하니 Registry에 피처 정의가 등록되었습니다. "이제 이 피처들을 실제로 저장하고 조회하려면 어떻게 해야 하죠?" 다음 장에서 Online Store와 Offline Store 설정을 알아보겠습니다.

실전 팁

💡 - Feature View 이름은 팀 내에서 일관된 네이밍 컨벤션을 정해두세요

• ttl은 비즈니스 요구사항에 맞게 설정하되, 너무 짧으면 피처가 없다고 나올 수 있습니다

---

4. Online Offline Store 설정

Feature View를 정의한 김개발 씨는 이제 피처를 실제로 저장해야 합니다. 그런데 Feast에는 Offline Store와 Online Store 두 가지가 있다고 합니다.

"왜 저장소가 두 개나 필요한 거죠?" 박시니어 씨가 화이트보드에 그림을 그리며 설명을 시작했습니다.

Offline Store는 대량의 과거 데이터를 저장하고 모델 학습용 데이터셋을 생성하는 데 사용됩니다. Online Store는 최신 피처 값만 저장하고 실시간 추론에 사용됩니다.

마치 도서관의 서고(Offline)와 대출 데스크(Online)의 관계와 같습니다. 두 저장소를 적절히 설정하면 학습과 서빙 모두 효율적으로 처리할 수 있습니다.

다음 코드를 살펴봅시다.

# feature_store.yaml - 프로덕션 환경 설정 예시
project: recommendation_system
registry: s3://my-bucket/feast/registry.db
provider: aws

offline_store:
    type: redshift
    cluster_id: my-redshift-cluster
    region: ap-northeast-2
    database: feast
    user: feast_user
    s3_staging_location: s3://my-bucket/feast/staging/

online_store:
    type: redis
    connection_string: redis://my-redis.cache.amazonaws.com:6379

# 피처를 Online Store에 적재 (materialization)
# feast materialize 2023-01-01T00:00:00 2024-01-01T00:00:00
# feast materialize-incremental $(date +%Y-%m-%dT%H:%M:%S)

박시니어 씨는 화이트보드에 두 개의 상자를 그렸습니다. 왼쪽에는 거대한 창고, 오른쪽에는 작은 진열대를 그렸습니다.

"머신러닝 시스템에서 데이터 저장소가 두 개 필요한 이유를 설명해드릴게요." Offline Store는 마치 거대한 물류 창고와 같습니다. 모델을 학습시키려면 수개월, 수년치의 과거 데이터가 필요합니다.

이 데이터는 수백 GB, 수 TB에 달할 수 있습니다. Offline Store는 이런 대용량 데이터를 저장하고 분석하는 데 최적화되어 있습니다.

BigQuery, Redshift, Snowflake 같은 데이터 웨어하우스가 Offline Store로 적합합니다. Online Store는 매장 앞 진열대와 같습니다.

실제 서비스에서 추천을 해주려면 사용자의 현재 피처가 필요합니다. 이때 수 TB의 창고에서 데이터를 찾아오면 너무 느립니다.

그래서 자주 사용하는 최신 피처만 빠른 저장소에 미리 꺼내둡니다. Redis, DynamoDB 같은 Key-Value 저장소가 Online Store로 적합합니다.

응답 시간이 수 밀리초 이내여야 하기 때문입니다. 두 저장소의 사용 시나리오를 비교해봅시다.

모델 학습 시에는 Offline Store를 사용합니다. "지난 6개월간 이 사용자가 어떤 상품을 봤는지" 같은 과거 시점의 데이터를 조회합니다.

실시간 추론 시에는 Online Store를 사용합니다. "이 사용자의 현재 선호도 점수"처럼 최신 값만 필요합니다.

설정 파일을 살펴보겠습니다. offline_store 섹션에서 Redshift를 사용하도록 설정했습니다.

cluster_id, region, database 등 연결 정보를 지정합니다. s3_staging_location은 데이터를 임시로 저장하는 경로입니다.

online_store 섹션에서는 Redis를 사용합니다. connection_string만 지정하면 됩니다.

가장 중요한 것은 Materialization입니다. Offline Store에만 데이터가 있으면 Online Store에서 조회할 수 없습니다.

feast materialize 명령어를 실행하면 Offline Store의 데이터를 Online Store로 복사합니다. 지정한 기간의 데이터 중 각 Entity별로 가장 최신 값만 Online Store에 저장됩니다.

실무에서는 어떻게 운영할까요? 보통 배치 파이프라인을 구성합니다.

매일 새벽에 feast materialize-incremental 명령어를 실행해서 전날 업데이트된 피처를 Online Store에 반영합니다. Airflow나 Prefect 같은 워크플로우 도구와 연동하면 자동화할 수 있습니다.

주의할 점이 있습니다. Materialization은 시간이 걸리는 작업입니다.

피처 수가 많고 Entity 수가 많으면 수십 분에서 수 시간이 걸릴 수 있습니다. 따라서 실시간으로 변하는 피처는 별도의 방법으로 처리해야 합니다.

이 부분은 다음 장에서 다루겠습니다. 김개발 씨는 고개를 끄덕였습니다.

"아, 그래서 저장소가 두 개 필요한 거군요. 학습할 때는 과거 데이터 전체가 필요하고, 서빙할 때는 최신 데이터만 빠르게 조회하면 되니까요!"

실전 팁

💡 - 로컬 개발에서는 SQLite와 File Store로 충분하지만, 프로덕션에서는 반드시 확장 가능한 저장소를 사용하세요

• Materialization 주기는 피처 갱신 빈도와 비즈니스 요구사항을 고려해서 결정하세요

---

5. 실시간 Feature 서빙

김개발 씨는 드디어 추천 모델을 서비스에 배포할 준비가 되었습니다. 그런데 문제가 생겼습니다.

"사용자가 방금 클릭한 상품 정보를 피처로 쓰고 싶은데, Materialization은 하루에 한 번밖에 안 돌잖아요. 어떻게 해야 하죠?" 박시니어 씨가 미소를 지었습니다.

"실시간 피처 서빙 방법을 알려드릴게요."

실시간 Feature 서빙은 밀리초 단위의 낮은 지연시간으로 피처를 제공하는 것을 말합니다. Feast는 REST API 서버를 내장하고 있어 HTTP 요청으로 피처를 조회할 수 있습니다.

또한 스트리밍 데이터 소스와 연동하면 실시간으로 변하는 피처도 처리할 수 있습니다. 마치 증권사 HTS에서 실시간 시세를 보여주는 것처럼 최신 피처를 즉시 제공합니다.

다음 코드를 살펴봅시다.

# Feast Feature Server 실행
# feast serve --host 0.0.0.0 --port 6566

# Python SDK를 사용한 실시간 피처 조회
from feast import FeatureStore
import time

store = FeatureStore(repo_path=".")

# 단일 사용자 피처 조회
start = time.time()
features = store.get_online_features(
    features=[
        "user_features:age",
        "user_features:purchase_count",
        "user_features:avg_purchase_amount"
    ],
    entity_rows=[{"user_id": 1001}]
).to_dict()
print(f"조회 시간: {(time.time() - start) * 1000:.2f}ms")

# REST API 호출 예시 (curl)
# curl -X POST http://localhost:6566/get-online-features \
#   -H "Content-Type: application/json" \
#   -d '{"features": ["user_features:age"], "entities": {"user_id": [1001]}}'

김개발 씨가 걱정하는 것은 당연한 문제였습니다. 추천 시스템에서 사용자의 최근 행동은 매우 중요한 피처입니다.

방금 운동화를 클릭한 사용자에게 드레스 구두를 추천하면 안 되겠죠. 먼저 Feature Server에 대해 알아봅시다.

Feast는 내장 Feature Server를 제공합니다. feast serve 명령어를 실행하면 REST API 서버가 시작됩니다.

이 서버는 Online Store에 저장된 피처를 HTTP 요청으로 조회할 수 있게 해줍니다. 별도의 백엔드 서버를 구축할 필요가 없습니다.

왜 REST API가 중요할까요? 추천 서비스는 보통 다양한 언어로 작성됩니다.

Python으로 모델을 만들었지만, 실제 서비스는 Java나 Go로 운영될 수 있습니다. REST API를 사용하면 어떤 언어에서든 피처를 조회할 수 있습니다.

HTTP 요청만 보낼 수 있으면 됩니다. Python SDK를 직접 사용할 수도 있습니다.

모델 서빙 서버가 Python이라면 SDK를 직접 사용하는 것이 더 빠릅니다. get_online_features 메서드로 피처를 조회합니다.

응답 시간은 보통 수 밀리초에서 수십 밀리초입니다. Online Store가 Redis라면 더 빠른 응답을 기대할 수 있습니다.

코드를 자세히 살펴보겠습니다. features 파라미터에는 조회할 피처 목록을 지정합니다.

"feature_view_name:feature_name" 형식입니다. entity_rows에는 어떤 Entity의 피처를 조회할지 지정합니다.

여러 Entity를 한 번에 조회하는 것도 가능합니다. 실시간으로 변하는 피처는 어떻게 처리할까요?

두 가지 방법이 있습니다. 첫 번째는 On-demand Feature View입니다.

요청 시점에 실시간으로 피처를 계산합니다. 예를 들어 현재 시간과 마지막 로그인 시간의 차이를 구하는 피처는 On-demand로 처리하면 됩니다.

두 번째는 Stream Feature View입니다. Kafka 같은 메시지 큐에서 이벤트를 받아 실시간으로 Online Store를 업데이트합니다.

사용자가 상품을 클릭하면 이벤트가 발생하고, 이 이벤트가 Kafka를 통해 Feast로 전달되어 피처가 즉시 갱신됩니다. 실무에서는 보통 이 세 가지를 조합해서 사용합니다.

변하지 않는 피처(나이, 성별)는 Batch Materialization으로 처리합니다. 실시간 행동 피처(최근 클릭 상품)는 Stream Feature View로 처리합니다.

요청 시점에 계산해야 하는 피처(세션 길이)는 On-demand Feature View로 처리합니다. 주의할 점이 있습니다.

실시간 피처 서빙은 인프라 비용이 더 듭니다. 모든 피처를 실시간으로 처리하려고 하지 마세요.

정말 실시간성이 필요한 피처만 선별해서 처리하는 것이 현명합니다. 또한 Feature Server는 프로덕션에서 고가용성을 위해 여러 인스턴스로 운영해야 합니다.

김개발 씨는 테스트를 해보고 놀랐습니다. "와, 진짜 10밀리초 안에 응답이 오네요!" 이제 추천 모델에 필요한 피처를 실시간으로 조회할 수 있게 되었습니다.

실전 팁

💡 - Feature Server는 Kubernetes에 배포해서 오토스케일링을 설정하세요

• 응답 시간이 중요하다면 Redis Online Store와 가까운 리전에 Feature Server를 배치하세요

---

6. Feature 재사용 전략

프로젝트를 성공적으로 마친 김개발 씨에게 새로운 업무가 주어졌습니다. 이번에는 이탈 예측 모델을 만들어야 합니다.

"어, 그런데 이 피처들... 추천 모델에서도 썼던 것 같은데?" 김개발 씨는 문득 깨달았습니다.

같은 피처를 또 만들 필요가 없다는 것을요.

Feature 재사용은 한 번 정의한 피처를 여러 모델과 팀에서 공유해서 사용하는 것입니다. Feature Store의 가장 큰 장점 중 하나입니다.

마치 레고 블록을 다양한 작품에 재사용하는 것처럼, 잘 만든 피처는 여러 ML 프로젝트의 기반이 됩니다. 피처 재사용을 잘 하면 개발 시간을 크게 단축하고 피처 품질도 높일 수 있습니다.

다음 코드를 살펴봅시다.

# 재사용 가능한 피처 정의 (shared_features.py)
from feast import FeatureView, Field, Entity
from feast.types import Float32, Int64

# 기본 사용자 피처 - 여러 모델에서 재사용
user_base_features = FeatureView(
    name="user_base_features",
    entities=[user],
    schema=[
        Field(name="account_age_days", dtype=Int64),
        Field(name="total_orders", dtype=Int64),
        Field(name="lifetime_value", dtype=Float32),
    ],
    source=user_source,
    tags={"team": "platform", "domain": "user"},
)

# 다른 모델에서 피처 조합하여 사용
def get_features_for_model(model_type: str) -> list:
    base_features = [
        "user_base_features:account_age_days",
        "user_base_features:total_orders",
    ]
    if model_type == "recommendation":
        return base_features + ["user_behavior:click_count"]
    elif model_type == "churn":
        return base_features + ["user_activity:days_since_login"]
    return base_features

김개발 씨는 추천 모델을 만들 때 사용자의 총 주문 횟수, 평균 구매 금액, 마지막 구매일 등의 피처를 정의했습니다. 이탈 예측 모델에도 이 피처들이 그대로 필요했습니다.

Feature Store가 없었다면 어떻게 됐을까요? Feature Store 없이 피처를 재사용하면 문제가 생깁니다.

추천팀이 만든 피처 계산 로직을 이탈 예측팀이 복사해서 가져갑니다. 시간이 지나면서 두 팀의 코드는 조금씩 달라집니다.

버그가 발견되어 한쪽을 고쳐도 다른 쪽은 그대로입니다. 결국 같은 이름의 피처가 다른 값을 반환하는 상황이 발생합니다.

이것을 Feature Drift라고 합니다. Feature Store는 이 문제를 해결합니다.

피처 정의가 한 곳에 있으므로 모든 팀이 같은 피처를 사용합니다. 버그를 수정하면 모든 곳에 즉시 반영됩니다.

피처 품질 테스트도 한 번만 하면 됩니다. 이것이 Single Source of Truth의 힘입니다.

피처 재사용을 잘 하려면 설계가 중요합니다. 첫째, 피처를 도메인별로 분류하세요.

user_base_features, user_behavior_features, product_features처럼 논리적으로 묶습니다. 둘째, 범용적인 피처와 특수 목적 피처를 분리하세요.

총 주문 횟수는 범용적이지만, 최근 30일 스포츠 카테고리 구매 횟수는 특수 목적입니다. 코드의 tags 부분을 주목하세요.

tags에 team, domain 등의 메타데이터를 추가하면 피처 검색이 쉬워집니다. "마케팅팀에서 만든 피처 중 사용자 도메인 피처"를 찾는 것이 가능해집니다.

Feast의 Web UI나 API를 통해 피처 카탈로그를 탐색할 수 있습니다. get_features_for_model 함수를 살펴봅시다.

이 함수는 모델 유형에 따라 필요한 피처 목록을 반환합니다. 기본 피처는 모든 모델에 공통으로 사용되고, 모델별로 추가 피처를 더합니다.

이런 패턴을 사용하면 피처 조합을 코드로 관리할 수 있습니다. 팀 간 협업을 위한 거버넌스도 필요합니다.

누가 피처를 만들 수 있는지, 피처 변경 시 어떤 리뷰 프로세스를 거치는지 정해야 합니다. 피처 정의 파일을 Git으로 관리하고 PR 리뷰를 받는 것이 좋은 방법입니다.

피처 변경이 기존 모델에 영향을 주지 않는지 확인하는 테스트도 필요합니다. 주의할 점이 있습니다.

모든 피처를 무조건 재사용하려고 하지 마세요. 특정 모델에만 의미 있는 피처도 있습니다.

또한 피처 정의를 변경할 때는 하위 호환성을 고려해야 합니다. 피처 이름을 바꾸면 그 피처를 사용하던 모든 모델이 영향을 받습니다.

다시 김개발 씨의 이야기로 돌아갑시다. 기존에 정의된 user_base_features를 그대로 가져다 쓰니 이탈 예측 모델 개발이 훨씬 빨라졌습니다.

"피처 만드는 시간을 절반으로 줄였어요!" 김개발 씨는 Feature Store의 진정한 가치를 깨달았습니다. 이것으로 Feast Feature Store의 기본을 모두 살펴보았습니다.

피처 정의부터 저장, 서빙, 재사용까지 전체 흐름을 이해했다면 여러분도 이제 ML 시스템을 한 단계 업그레이드할 준비가 된 것입니다.

실전 팁

💡 - 피처 네이밍 컨벤션을 팀 전체가 공유하고 문서화하세요

• 피처 카탈로그를 만들어서 어떤 피처가 있는지 쉽게 검색할 수 있게 하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!