MLOps 데이터 전처리 및 피처 스토어 구축: Feast, Hopsworks 실전 가이드

MLOps 파이프라인의 핵심인 데이터 전처리와 피처 스토어 구축 전략을 알아봅니다. Feast와 Hopsworks를 활용한 실용적인 구현 가이드로 머신러닝 모델 개발을 가속화하세요.

📑 목차

• MLOps, 왜 데이터 전처리와 피처 스토어가 중요할까요?
• MLOps에서 데이터 전처리의 중요성과 도전 과제
• 온라인/오프라인 서빙 불일치 (Skew) 문제
• 다양한 데이터 소스 통합 및 관리의 어려움
• 전처리 로직의 버전 관리 및 재현성
• 피처 스토어(Feature Store)란 무엇이며 왜 필요할까요?
• 피처 스토어의 핵심 기능
• 왜 피처 스토어가 필요할까요?
• Feast를 활용한 피처 스토어 구축 실전 가이드
• Feast의 주요 개념
• Feast 구축 단계
• Hopsworks를 통한 피처 스토어 및 MLOps 플랫폼 경험
• Hopsworks 소개
• Hopsworks의 주요 장점
• Feast 단독 사용과 Hopsworks 통합 사용 비교
• 데이터 전처리 파이프라인과 피처 스토어 통합 전략
• ETL/ELT 파이프라인과 피처 스토어 연동
• 스트리밍 데이터 전처리 및 온라인 스토어 연동
• 모니터링: 피처 드리프트 감지 및 데이터 품질 관리
• MLOps 성공의 열쇠, 데이터 관리

Image by analogicus on Pixabay

MLOps, 왜 데이터 전처리와 피처 스토어가 중요할까요?

안녕하세요! 머신러닝 모델을 만들고 배포하는 과정, 정말 복잡하고 어렵다고 느끼시죠? 특히 모델을 개발할 때는 잘 되던 것이 실제 서비스에 배포하고 나면 예상치 못한 문제들이 터져 나오곤 하는데요. 학습 데이터와 실제 서비스 데이터 간의 불일치(Skew) 문제나, 수많은 모델에서 동일한 피처를 계속해서 전처리하는 비효율성 같은 것들이 대표적일 거예요.

이런 문제들을 해결하고, 머신러닝 모델을 안정적으로 운영하며 지속적으로 개선하기 위해 등장한 개념이 바로 MLOps(Machine Learning Operations)인데요. MLOps의 핵심은 단순히 모델을 잘 만드는 것을 넘어, 모델의 개발부터 배포, 모니터링, 재학습까지 전 과정을 자동화하고 관리하는 데 있답니다. 그리고 이 MLOps 파이프라인의 성공 여부를 결정하는 가장 중요한 요소 중 하나가 바로 데이터 전처리와 피처 스토어(Feature Store) 구축 전략이에요. 왜냐하면, 결국 모델은 데이터로 학습되고 데이터로 예측을 수행하니까요!

이번 글에서는 MLOps 환경에서 데이터 전처리가 왜 중요하고 어떤 도전 과제들이 있는지, 그리고 이 문제들을 해결하기 위한 핵심 솔루션인 피처 스토어가 무엇인지 알아볼 거예요. 특히 오픈소스 피처 스토어인 Feast와 엔터프라이즈 MLOps 플랫폼인 Hopsworks를 활용해서 어떻게 실질적인 데이터 파이프라인을 구축하고 피처를 관리할 수 있는지 실전 가이드 형식으로 자세히 설명해 드릴게요. 자, 그럼 함께 MLOps의 세계로 떠나볼까요?

MLOps에서 데이터 전처리의 중요성과 도전 과제

머신러닝 모델의 성능은 결국 데이터의 품질에 달려있다는 말, 많이 들어보셨을 거예요. 아무리 좋은 모델 아키텍처를 사용하고 복잡한 알고리즘을 적용해도, 입력되는 데이터가 지저분하거나 일관성이 없으면 좋은 결과를 기대하기는 어렵죠. 여기서 데이터 전처리(Data Preprocessing)의 역할이 빛을 발하는 건데요.

데이터 전처리는 원시 데이터를 모델이 학습하고 이해하기 쉬운 형태로 가공하는 모든 과정을 의미해요. 결측치 처리, 이상치 제거, 스케일링, 인코딩, 피처 엔지니어링 등이 여기에 해당하죠. 그런데 MLOps 환경에서는 이 전처리가 단순히 모델 성능을 높이는 것을 넘어, 훨씬 더 중요한 의미를 갖는답니다.

온라인/오프라인 서빙 불일치 (Skew) 문제

가장 큰 도전 과제 중 하나는 바로 학습-추론 서빙 불일치(Training-Serving Skew) 문제예요. 학습 데이터는 보통 배치(Batch) 형태로 오프라인에서 처리되지만, 실제 서비스에서의 추론은 실시간(Online)으로 이루어지는 경우가 많죠. 이때 학습 시점의 전처리 로직과 추론 시점의 전처리 로직이 미묘하게 다르거나, 사용되는 데이터 소스가 달라지면 모델이 예측하지 못한 결과를 내놓을 수 있거든요. 예를 들어, 학습 시에는 특정 피처의 결측치를 평균값으로 채웠는데, 추론 시에는 0으로 채우게 되면 모델은 혼란스러워할 수밖에 없겠죠.

다양한 데이터 소스 통합 및 관리의 어려움

또 다른 어려움은 다양한 데이터 소스에서 오는 데이터를 통합하고 관리하는 거예요. 관계형 데이터베이스, NoSQL 데이터베이스, 데이터 레이크(S3, GCS), 스트리밍 데이터(Kafka) 등 여러 곳에 흩어져 있는 데이터를 일관된 형태로 가져와 전처리하는 것은 복잡한 작업인데요. 각 데이터 소스마다 접근 방식이나 데이터 형식이 다르고, 이를 통합하는 파이프라인을 구축하는 것 자체가 큰 공수와 전문성을 요구하거든요.

전처리 로직의 버전 관리 및 재현성

마지막으로, 전처리 로직의 버전 관리와 재현성(Reproducibility) 확보 문제도 빼놓을 수 없어요. 모델이 개선되면서 전처리 로직도 계속해서 진화할 텐데요. 어떤 모델이 어떤 버전의 전처리 로직으로 학습되었는지 명확하게 기록하고, 필요할 때 언제든 그 상태를 재현할 수 있어야 안정적인 MLOps를 구축할 수 있답니다. 그렇지 않으면 "이 모델은 왜 학습할 때랑 지금이랑 결과가 다르지?" 하는 상황에 직면하게 될 거예요.

피처 스토어(Feature Store)란 무엇이며 왜 필요할까요?

앞서 언급했던 데이터 전처리의 여러 도전 과제들을 해결하기 위한 핵심 솔루션이 바로 피처 스토어(Feature Store)예요. 피처 스토어는 말 그대로 머신러닝 모델 학습과 추론에 사용되는 피처(Feature)들을 중앙 집중적으로 관리하고 서빙하는 저장소를 의미합니다.

피처 스토어의 핵심 기능

피처 스토어는 다음과 같은 핵심 기능을 제공해요:

• 피처 정의: 원시 데이터를 가공하여 특정 피처를 생성하는 로직을 정의하고 메타데이터와 함께 저장합니다.
• 피처 저장: 온라인 서빙을 위한 저지연(low-latency) 저장소(예: Redis, Cassandra)와 오프라인 학습을 위한 고용량 저장소(예: S3, HDFS)에 피처 값을 저장합니다.
• 피처 서빙: 학습 시에는 배치 형태로 대량의 피처를, 추론 시에는 단일 또는 소량의 피처를 실시간으로 제공합니다.
• 피처 버전 관리: 피처 정의 및 값의 버전을 관리하여 재현성을 보장합니다.
• 피처 모니터링: 피처의 통계, 분포 변화(드리프트) 등을 모니터링하여 데이터 품질 문제를 조기에 감지합니다.

왜 피처 스토어가 필요할까요?

피처 스토어가 MLOps에서 필수적인 이유는 명확해요.

1. 재현성 확보 및 학습-추론 불일치(Skew) 해소: 피처 스토어는 학습 시 사용된 피처와 동일한 전처리 로직으로 생성된 피처를 추론 시에도 제공함으로써, 학습-추론 불일치 문제를 근본적으로 해결해 줍니다. 동일한 피처 정의를 공유하고 동일한 파이프라인을 통해 생성된 데이터를 사용하니까요.
2. 피처 재사용성 증가 및 개발 속도 향상: 한 번 정의하고 생성된 피처는 여러 모델이나 여러 팀에서 손쉽게 재사용할 수 있어요. 예를 들어, '사용자 구매 이력'이라는 피처는 추천 모델, 이상 감지 모델, 고객 이탈 예측 모델 등 다양한 곳에서 활용될 수 있죠. 덕분에 각 팀이 매번 동일한 피처를 처음부터 다시 만들 필요가 없어 개발 시간이 크게 단축됩니다.
3. 데이터 거버넌스 및 품질 관리: 피처 스토어는 조직 내 피처들을 중앙에서 관리하므로, 어떤 피처가 어디에 사용되고 있는지 쉽게 파악할 수 있어요. 또한, 피처의 통계 정보나 데이터 품질을 모니터링하여 문제가 발생했을 때 빠르게 대응할 수 있도록 돕습니다.

피처 스토어가 없을 때와 있을 때의 차이를 표로 비교해 보면 그 필요성을 더 명확히 이해하실 수 있을 거예요.

구분	피처 스토어가 없을 때	피처 스토어를 활용할 때
데이터 전처리	각 모델/팀별로 전처리 로직을 개별적으로 구현 및 관리 (중복 발생)	중앙에서 피처 정의 및 전처리 로직 관리, 일관된 피처 생성 파이프라인
학습-추론 일관성	학습/추론 환경의 전처리 로직 불일치로 Skew 발생 위험 높음	동일한 피처를 사용하여 학습-추론 불일치 문제 해결, 높은 일관성 유지
피처 재사용성	피처 재사용 어려움, 각 모델마다 피처를 처음부터 다시 생성하는 경우가 많음	한 번 생성된 피처를 여러 모델/팀에서 손쉽게 공유하고 재사용 가능
개발 속도	피처 엔지니어링 및 전처리에 많은 시간 소요, 개발 주기가 길어짐	피처 준비 시간 단축, 모델 개발 및 배포 속도 향상
데이터 거버넌스	분산된 피처 관리로 인해 데이터 품질 및 사용 현황 파악 어려움	중앙 집중식 피처 관리, 데이터 품질 모니터링 및 거버넌스 용이

결국 피처 스토어는 MLOps 파이프라인을 효율적이고 안정적으로 구축하기 위한 필수적인 인프라라고 할 수 있겠죠!

Image by Alexandra_Koch on Pixabay

Feast를 활용한 피처 스토어 구축 실전 가이드

피처 스토어의 개념과 필요성을 이해하셨다면, 이제 실제로 어떻게 구축할 수 있는지 알아봐야겠죠? 가장 널리 사용되는 오픈소스 피처 스토어 중 하나가 바로 Feast입니다. Feast는 Uber에서 시작되어 현재는 LF AI & Data Foundation 프로젝트로 활발하게 개발되고 있는데요. 오프라인 학습과 온라인 추론을 위한 피처 서빙을 일관되게 제공하는 데 중점을 두고 있답니다.

Feast의 주요 개념

Feast를 이해하기 위해 몇 가지 핵심 개념을 먼저 살펴볼게요.

• Entity (엔티티): 피처의 주체가 되는 객체를 의미해요. 예를 들어, 사용자(user), 상품(product), 주문(order) 등이 될 수 있죠. 각 엔티티는 고유한 ID를 가집니다.
• Feature (피처): 엔티티의 속성을 나타내는 값이에요. 예를 들어, 사용자 엔티티의 '최근 구매 금액', '로그인 횟수' 등이 피처가 됩니다.
• Feature View (피처 뷰): 하나 이상의 피처를 그룹화하고, 이 피처들이 어디에서 왔는지(데이터 소스), 어떻게 생성되는지(전처리 로직), 그리고 어떻게 저장되는지(온라인/오프라인 스토어)를 정의하는 논리적인 단위예요. Feast의 핵심 추상화 계층이라고 볼 수 있습니다.
• DataSource (데이터 소스): 피처가 저장되어 있는 원본 위치를 의미해요. Parquet 파일, BigQuery 테이블, Kafka 토픽 등이 될 수 있습니다.
• Online Store (온라인 스토어): 실시간 추론을 위해 저지연으로 피처를 서빙하는 저장소예요. Redis, DynamoDB 등이 주로 사용됩니다.
• Offline Store (오프라인 스토어): 모델 학습을 위해 대량의 피처를 배치 형태로 서빙하는 저장소예요. S3, GCS, HDFS, BigQuery 등이 사용됩니다.

Feast 구축 단계

간단한 예시를 통해 Feast를 어떻게 사용하는지 알아볼까요? 여기서는 로컬 파일 시스템을 오프라인 스토어로, SQLite를 온라인 스토어로 사용하는 간단한 환경을 가정해 볼게요.

# 1. Feast 설치
pip install feast[aws,gcp,snowflake,redis] # 필요한 클라우드 및 온라인 스토어 백엔드 포함

# 2. Feast 프로젝트 초기화
# 새로운 디렉토리에서 실행
mkdir my_feature_repo
cd my_feature_repo
feast init .

# 이 명령을 실행하면 다음 파일들이 생성됩니다:
# - feature_store.yaml: Feast 프로젝트 설정 파일
# - example.py: 피처 뷰 정의 예시 파일
# - data/ : 샘플 데이터가 있는 디렉토리

`feature_store.yaml` 파일은 Feast 프로젝트의 전반적인 설정을 담고 있어요. 온라인 스토어와 오프라인 스토어의 타입을 지정해 주죠. 예를 들어, SQLite와 로컬 파일을 사용하도록 설정할 수 있습니다.

# feature_store.yaml (예시)
project: my_feature_repo
registry: data/registry.db # 피처 메타데이터를 저장
provider: local
online_store:
    type: sqlite
    path: data/online_store.db # 온라인 피처 값을 저장
offline_store:
    type: file # 오프라인 피처는 로컬 파일(Parquet)로 저장

이제 `feature_definitions.py` (또는 `example.py` 파일 이름 변경)에서 피처 뷰를 정의해 볼까요?

# feature_definitions.py (예시: 사용자 활동 피처)
from datetime import timedelta
from feast import Entity, FeatureView, Field, FileSource
from feast.types import Int64, Float32, String

# 1. 엔티티 정의
# 'user_id'를 가진 사용자 엔티티를 정의합니다.
user = Entity(name="user_id", description="사용자 ID")

# 2. 데이터 소스 정의
# Parquet 파일에서 피처 데이터를 읽어올 FileSource를 정의합니다.
# 실제 환경에서는 BigQuery, S3 등 다양한 데이터 소스를 사용하겠죠.
user_activity_source = FileSource(
    path="data/user_activity_data.parquet", # 샘플 데이터 파일 경로
    timestamp_field="event_timestamp", # 타임스탬프 필드 지정
    created_timestamp_field="created_timestamp", # 생성 타임스탬프 필드 지정 (선택 사항)
)

# 3. 피처 뷰 정의
# 'user_activity_features'라는 피처 뷰를 정의합니다.
# 이 뷰는 'user' 엔티티에 속하며, user_activity_source에서 데이터를 가져와 피처로 만듭니다.
user_activity_features = FeatureView(
    name="user_activity_features",
    entities=[user],
    ttl=timedelta(days=30), # 피처의 유효 기간을 30일로 설정
    batch_source=user_activity_source, # 오프라인 학습을 위한 데이터 소스
    # stream_source=None, # 스트리밍 데이터 소스도 정의할 수 있습니다.
    features=[
        Field(name="login_count", dtype=Int64),
        Field(name="last_purchase_amount", dtype=Float32),
        Field(name="favorite_category", dtype=String),
    ],
)

위 코드에서 보듯이, Entity와 DataSource를 정의한 다음, 이를 묶어서 FeatureView를 정의하는 방식이에요. `ttl` (Time-To-Live)을 설정해서 피처의 유효 기간을 관리할 수 있다는 점도 흥미롭죠.

이제 이 피처 뷰를 Feast 레지스트리에 등록하고, 온라인 스토어에 피처를 로드해 볼까요?

# 4. 피처 등록 및 온라인 스토어에 피처 로드
# 터미널에서 실행
# 정의된 피처 뷰를 Feast 레지스트리에 등록합니다.
feast apply

# 오프라인 스토어(data/user_activity_data.parquet)의 최신 피처를
# 온라인 스토어(data/online_store.db)로 로드합니다.
feast materialize-incremental $(date +%Y-%m-%d)
# 또는 특정 기간의 데이터를 로드할 수도 있습니다.
# feast materialize 2023-01-01T00:00:00 2023-01-31T23:59:59

이제 Python 코드에서 Feast 클라이언트를 사용해서 피처를 가져올 수 있어요.

# 5. 피처 가져오기 (학습 및 추론)
from feast import FeatureStore
import pandas as pd
from datetime import datetime, timedelta

# Feast FeatureStore 클라이언트를 초기화합니다.
fs = FeatureStore(repo_path=".")

# 학습을 위한 피처 가져오기 (오프라인 서빙)
# 'entity_df'는 피처를 가져올 엔티티 ID와 타임스탬프를 포함하는 데이터프레임입니다.
entity_df = pd.DataFrame.from_dict(
    {
        "user_id": [1001, 1002, 1003],
        "event_timestamp": [
            datetime(2023, 1, 1, 10, 0, 0),
            datetime(2023, 1, 1, 10, 15, 0),
            datetime(2023, 1, 1, 10, 30, 0),
        ],
    }
)

training_data = fs.get_historical_features(
    entity_df=entity_df,
    feature_views=[
        "user_activity_features:login_count",
        "user_activity_features:last_purchase_amount",
        "user_activity_features:favorite_category",
    ],
).to_df()

print("--- 학습용 피처 데이터 ---")
print(training_data)

# 실시간 추론을 위한 피처 가져오기 (온라인 서빙)
# 특정 user_id에 대한 최신 피처를 요청합니다.
online_features = fs.get_online_features(
    features=[
        "user_activity_features:login_count",
        "user_activity_features:last_purchase_amount",
        "user_activity_features:favorite_category",
    ],
    entity_rows=[{"user_id": 1001}],
).to_dict()

print("\n--- 온라인 추론용 피처 데이터 ---")
print(online_features)

이렇게 Feast를 활용하면 학습을 위한 과거 피처 데이터와 실시간 추론을 위한 최신 피처 데이터를 일관된 방식으로 가져올 수 있게 된답니다. 데이터 전처리 로직은 `user_activity_source`가 가리키는 데이터 파일에 미리 적용되어 있거나, Spark/Flink 같은 ETL 파이프라인을 통해 피처 스토어에 주기적으로 적재되는 형태로 운영될 거예요.

Hopsworks를 통한 피처 스토어 및 MLOps 플랫폼 경험

Feast는 강력한 오픈소스 피처 스토어이지만, 실제 프로덕션 환경에서 운영하려면 데이터 파이프라인 구축, 보안, 모니터링, 버전 관리 등 추가적인 인프라와 관리 작업이 필요해요. 이런 복잡성을 해결하고 엔드-투-엔드 MLOps 플랫폼을 제공하는 솔루션 중 하나가 바로 Hopsworks입니다.

Hopsworks 소개

Hopsworks는 피처 스토어를 핵심으로 하는 엔터프라이즈 MLOps 플랫폼이에요. 오픈소스 Feast를 기반으로 하면서도, 사용자가 더 쉽게 피처를 정의하고 관리하며, 머신러닝 모델 개발 및 배포 전반을 아우르는 다양한 기능을 제공하죠. 데이터 과학자와 ML 엔지니어들이 협업하여 모델을 개발하고 운영하기 위한 통합 환경을 제공한다고 이해하시면 됩니다.

Hopsworks의 주요 장점

Hopsworks를 사용하면 다음과 같은 이점들을 얻을 수 있어요.

• Feast 기반의 관리형 피처 스토어: Feast API를 완벽하게 지원하면서도, 웹 UI를 통해 피처를 시각적으로 정의하고 관리할 수 있어요. 데이터 소스 연결, 피처 엔지니어링 파이프라인 스케줄링, 피처 모니터링 등을 GUI에서 손쉽게 처리할 수 있습니다.
• 통합된 MLOps 워크플로우: 피처 스토어뿐만 아니라 데이터 버전 관리, 모델 레지스트리, 잡(Job) 스케줄링, 서빙 인프라(KServe 등) 등 MLOps의 모든 단계를 위한 도구들을 통합적으로 제공해요.
• 강력한 데이터 거버넌스 및 보안: 데이터 접근 제어, 감사 로그, 데이터 카탈로그 등 엔터프라이즈 환경에 필요한 보안 및 거버넌스 기능을 내장하고 있습니다.
• 분산 처리 엔진 통합: Apache Spark, Flink와 같은 분산 처리 엔진과 긴밀하게 통합되어 대규모 데이터 전처리 및 피처 엔지니어링을 효율적으로 수행할 수 있어요.

Feast 단독 사용과 Hopsworks 통합 사용 비교

Feast를 단독으로 사용하는 것과 Hopsworks와 함께 사용하는 것을 비교해 보면, 각자의 장단점을 명확히 알 수 있을 거예요.

구분	Feast 단독 사용	Hopsworks 통합 사용
구축 및 관리	직접 인프라 구축 및 관리 (데이터 소스, 온라인/오프라인 스토어, ETL 파이프라인 등)	관리형 서비스 형태로 제공, 웹 UI를 통한 손쉬운 설정 및 관리
기능 범위	피처 스토어 기능에 집중 (피처 정의, 저장, 서빙)	피처 스토어 외에 데이터 관리, 모델 레지스트리, 실험 관리, 잡 스케줄링 등 통합 MLOps 기능 제공
복잡성	여러 오픈소스 도구들을 조합하여 MLOps 파이프라인 구축 시 복잡성 증가	통합된 플랫폼으로 MLOps 구축 및 운영의 복잡성 크게 감소
확장성/안정성	사용자가 직접 분산 시스템 구축 및 확장성/안정성 확보 필요	엔터프라이즈급 확장성 및 안정성 제공, 클라우드 환경에 최적화
비용	오픈소스 사용으로 직접적인 라이선스 비용은 없으나, 인프라 및 운영 비용 발생	클라우드 서비스 또는 엔터프라이즈 솔루션 비용 발생, 운영 효율로 상쇄 가능

소규모 프로젝트나 학습용으로는 Feast 단독 사용이 충분하지만, 대규모의 복잡한 프로덕션 MLOps 환경에서는 Hopsworks와 같은 통합 플랫폼이 훨씬 효율적이고 안정적인 선택이 될 수 있답니다. Hopsworks 환경에서는 Feast의 피처 정의 파일을 그대로 가져와 사용하거나, 웹 UI에서 직접 피처 뷰를 생성하고 데이터 파이프라인을 연결할 수 있어 개발 생산성을 극대화할 수 있어요.

Image by analogicus on Pixabay

데이터 전처리 파이프라인과 피처 스토어 통합 전략

이제 데이터 전처리 파이프라인과 피처 스토어를 어떻게 효과적으로 통합할지 전략을 세워볼 시간이에요. 피처 스토어는 전처리된 피처를 저장하고 서빙하는 역할을 하지만, 그 피처를 만들어내는 과정, 즉 전처리 파이프라인은 별도로 구축되어야 하거든요.

ETL/ELT 파이프라인과 피처 스토어 연동

대부분의 데이터 전처리는 ETL(Extract, Transform, Load) 또는 ELT(Extract, Load, Transform) 파이프라인을 통해 이루어져요. Apache Spark, Flink, Apache Airflow, Prefect, Luigi 같은 도구들이 이런 파이프라인을 구축하는 데 활용되죠.

통합 전략의 핵심은 이 전처리 파이프라인의 최종 단계에서, 모델 학습과 추론에 필요한 형태로 가공된 피처들을 피처 스토어에 적재하는 거예요.

1. 데이터 추출(Extract): 다양한 원본 데이터 소스(관계형 DB, 데이터 레이크, 스트리밍 데이터 등)에서 필요한 데이터를 추출합니다.
2. 데이터 변환(Transform): 추출된 원시 데이터를 피처 스토어에 정의된 피처 뷰의 스키마와 전처리 로직에 맞춰 가공합니다. 예를 들어, 사용자 로그 데이터에서 '지난 7일간 로그인 횟수'나 '최근 30분간 구매 금액 합계'와 같은 피처를 계산하는 거죠. 이때, 학습과 추론 모두에서 동일한 로직이 사용되도록 전처리 함수를 모듈화하고 버전 관리하는 것이 중요합니다.
3. 데이터 적재(Load): 최종적으로 변환된 피처 데이터를 피처 스토어의 온라인 및 오프라인 저장소에 적재합니다. 배치 처리 파이프라인은 주기적으로 오프라인 스토어에 대량의 데이터를 업데이트하고, 실시간 스트리밍 파이프라인은 온라인 스토어에 최신 피처를 즉시 업데이트하는 방식이 일반적이에요.

예를 들어, Spark를 사용하여 일별 사용자 행동 데이터를 집계하고 Feast에 적재하는 과정을 생각해 볼 수 있겠죠.

# Spark를 이용한 피처 생성 및 Feast 적재 (개념 코드)
from pyspark.sql import SparkSession
from feast import FeatureStore
from datetime import datetime, timedelta

# Spark 세션 초기화
spark = SparkSession.builder.appName("FeatureEngineering").getOrCreate()

# Feast FeatureStore 클라이언트 초기화
fs = FeatureStore(repo_path=".")

# 1. 원시 데이터 로드 (예: CSV 파일)
raw_data_df = spark.read.csv("s3://your-data-lake/raw_user_logs.csv", header=True, inferSchema=True)

# 2. 피처 엔지니어링 수행
# 'user_id'별로 'login_count'와 'last_purchase_amount'를 계산하는 예시
# 실제로는 더 복잡한 집계 및 변환 로직이 들어갈 수 있습니다.
processed_df = raw_data_df \
    .groupBy("user_id") \
    .agg(
        {"login_event": "count", "purchase_amount": "sum"}
    ) \
    .withColumnRenamed("count(login_event)", "login_count") \
    .withColumnRenamed("sum(purchase_amount)", "last_purchase_amount") \
    .withColumn("event_timestamp", current_timestamp()) # 현재 시간을 타임스탬프로 추가

# 3. 피처 스토어에 적재
# Feast의 'ingest' 메서드를 사용하여 DataFrame을 피처 스토어에 적재
# 'user_activity_features'는 Feast에 미리 정의된 FeatureView 이름
fs.ingest(
    feature_view="user_activity_features",
    dataframe=processed_df,
    # online=True # 온라인 스토어에도 바로 적재할 경우
)

# 4. 온라인 스토어 동기화 (배치 파이프라인의 경우)
# 주기적으로 오프라인 스토어의 최신 데이터를 온라인 스토어로 동기화
# (Feast CLI의 materialize 명령과 유사한 동작을 Python에서 수행)
# fs.materialize_incremental(...)

spark.stop()

스트리밍 데이터 전처리 및 온라인 스토어 연동

실시간 추천, 이상 감지 등 저지연 예측이 필요한 시나리오에서는 스트리밍 데이터 전처리가 중요해요. Kafka와 같은 메시지 큐에서 데이터를 받아 Flink나 Spark Streaming 같은 스트리밍 처리 엔진으로 실시간 피처를 계산하고, 이를 즉시 Feast의 온라인 스토어에 적재하는 파이프라인을 구축할 수 있습니다. 이렇게 하면 모델이 항상 최신 피처를 사용하여 예측할 수 있게 되죠.

모니터링: 피처 드리프트 감지 및 데이터 품질 관리

피처 스토어를 구축했다고 해서 모든 문제가 해결되는 건 아니에요. 시간이 지남에 따라 피처의 분포가 변하는 피처 드리프트(Feature Drift)가 발생할 수 있고, 원본 데이터 소스에 문제가 생겨 데이터 품질이 저하될 수도 있거든요. 따라서 피처 스토어에 저장된 피처들을 지속적으로 모니터링하는 것이 중요합니다.

Hopsworks와 같은 플랫폼은 이런 모니터링 기능을 내장하고 있어 피처의 통계적 특성 변화를 감지하고 알림을 보내줄 수 있어요. 이를 통해 데이터 문제를 조기에 발견하고 모델 성능 저하를 방지할 수 있답니다.

MLOps 성공의 열쇠, 데이터 관리

오늘 우리는 MLOps 파이프라인의 핵심 요소인 데이터 전처리와 피처 스토어에 대해 깊이 있게 다뤄봤어요. 모델 학습과 추론의 일관성을 보장하고, 피처 재사용성을 높여 개발 속도를 가속화하며, 데이터 거버넌스를 강화하는 데 피처 스토어가 얼마나 중요한 역할을 하는지 이해하셨을 거예요.

오픈소스 Feast는 피처 스토어의 기본 기능을 충실히 제공하여 피처를 정의하고 관리하는 데 탁월한 도구인데요. 반면 Hopsworks는 Feast의 강력한 피처 스토어 기능을 기반으로, 데이터 관리, 모델 레지스트리, 잡 스케줄링 등 MLOps의 전반적인 과정을 통합적으로 지원하는 엔터프라이즈 플랫폼으로서의 가치를 보여줬습니다.

어떤 도구를 선택하든, 중요한 것은 MLOps를 위한 체계적인 데이터 관리 전략을 수립하는 것이라는 점을 잊지 마세요. 안정적이고 효율적인 MLOps 파이프라인 구축은 결국 고품질의 피처를 일관된 방식으로 생성하고 관리하는 데서 시작되니까요.

이 글이 여러분의 MLOps 여정에 실질적인 도움이 되었기를 바랍니다. 혹시 Feast나 Hopsworks를 사용해본 경험이 있으시다면 댓글로 자유롭게 공유해 주세요. 여러분의 경험과 질문은 다른 독자들에게도 큰 도움이 될 거예요!

📌 함께 읽으면 좋은 글

• [AI 머신러닝] 2024년 한국 기업을 위한 LLM 비용 절감 완벽 가이드: SLM 경량화 및 온프레미스 배포 실무 활용법
• [AI 머신러닝] 경량 머신러닝 모델 배포 및 추론 최적화: ONNX, TensorRT 활용 실전 가이드
• [클라우드 인프라] GitOps 기반 쿠버네티스 애플리케이션 배포 및 관리 전략: Argo CD와 Flux CD 심층 비교 분석

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.