원문: What is a Feature Store? A Complete Guide to ML Feature Engineering
Feature Store란 무엇인가? ML Feature Engineering 완전 가이드
엔터프라이즈 애플리케이션에서 머신러닝의 부상은 AI 모델을 구동하는 데이터 관리에 새로운 과제를 가져왔습니다. 현대 MLOps의 핵심에는 중요한 구성 요소가 있습니다. 바로 Feature Store(피처 스토어) 입니다. Feature Store는 머신러닝 모델의 Feature(피처, 특징값)를 저장하고 관리하는 중앙화된 저장소입니다. Feature 정의에 대한 단일 진실 공급원(Single Source of Truth)을 제공하고, 여러 프로젝트 간에 피처를 재사용할 수 있게 합니다. Feature Store는 데이터 사이언티스트와 데이터 엔지니어 간의 협업 허브 역할을 하며, Feature Engineering부터 모델 배포까지 전체 머신러닝 라이프사이클을 지원합니다. 조직이 실험적인 ML을 넘어 프로덕션 규모의 배포로 나아가면서, Feature Store가 해결하는 문제들에 직면하게 됩니다. 학습에 사용된 피처를 추론 시점에도 동일하게 사용할 수 있도록 어떻게 보장할 수 있을까요? 데이터 누수(Data Leakage)는 어떻게 방지할 수 있을까요? 팀이 처음부터 피처를 다시 만드는 것이 아니라 기존 피처를 발견하고 재사용할 수 있도록 하려면 어떻게 해야 할까요?Feature Store의 핵심 개념 이해하기
Feature Store는 데이터베이스와 어떻게 다른가?
Feature Store는 내부적으로 데이터베이스 기술을 사용하지만, 근본적으로 다른 목적을 수행합니다. Feature Store는 머신러닝 모델에서 직접 사용할 수 있도록 변환된 데이터를 관리하는 것이지, 변환되고 있는 원시 데이터를 관리하는 것이 아닙니다. 고객 이탈(Churn) 예측 모델을 생각해 보겠습니다. 원시 거래 기록은 피처가 아니라 소스 데이터입니다. 하지만 그 거래로부터 파생된 값들이 피처가 됩니다.- 시간 윈도우(Time Window) 집계: 최근 7일 구매 횟수, 30일 통화 건수
- 결합(Join) 조합: 고객 인구통계와 거래 패턴의 병합
- 복잡한 계산: 예상 고객 생애 가치(CLV), 이탈 위험 점수
Feature Store가 해결하는 문제들
발견과 재사용(Discovery and Reuse)
팀은 찾을 수 없는 것을 재사용할 수 없습니다. Feature Store는 원시 데이터로부터 이미 정제된 피처들을 표면으로 드러내어, 팀 전체에서의 중복 작업을 방지합니다.일관성과 계보(Consistency and Lineage)
피처를 공유하면 의존 관계가 생깁니다. 피처 생산자(Producer)는 어떤 모델이 자신의 피처에 의존하는지 이해해야 합니다. 피처 소비자(Consumer)는 피처가 어떻게 계산되고 누가 소유하는지 알아야 합니다. Feature Store는 이 양방향 계보(Lineage)를 추적합니다.온라인-오프라인 스큐(Online-Offline Skew)
모델은 한 환경(예: 분산 컴퓨팅을 갖춘 Databricks)에서 학습하지만 다른 환경(예: Java 웹 애플리케이션)에서 배포됩니다. 이러한 환경들 간에 피처 변환 로직을 재현하는 것은 오류가 발생하기 쉽습니다. Feature Store는 변환 코드가 아닌 피처 — 즉 데이터 자체 — 를 이식 가능하게 만들어 이 문제를 해결합니다.데이터 누수 방지(Data Leakage Prevention)
예측 시점에 사용할 수 없는 미래 정보로 모델을 학습하면 프로덕션에서 실패하는 지나치게 낙관적인 결과로 이어집니다. Feature Store는 이러한 일반적인 함정을 방지하는 시점 정확성(Point-in-Time Correct) Feature 값을 제공합니다.핵심 이점
Feature Store는 측정 가능한 개선을 제공합니다.- 일관적이고 고품질의 피처로 인한 모델 성능 향상
- 시점 정확성(Point-in-Time Correctness)을 통한 데이터 누수 감소
- 피처를 한 번 계산하고 여러 번 재사용함으로써 얻는 효율성 증가
- 데이터 사이언스와 데이터 엔지니어링 팀 간의 협업 개선
- 피처 발견과 재사용을 통한 개발 속도 향상
Feature Store 아키텍처
핵심 구성 요소
완전한 Feature Store는 네 가지 필수 구성 요소를 포함합니다. 아래 표는 각 구성 요소의 역할과 특징을 보여줍니다.| 구성 요소 | 역할 | 주요 특징 |
|---|---|---|
| Feature Registry | 피처 정의와 메타데이터의 중앙 카탈로그 | 피처 발견, 데이터 거버넌스 기반 |
| Offline Store | 배치 처리 및 모델 학습용 피처 데이터 관리 | Delta Lake 기반, 시점 정확성, 전체 이력 보존 |
| Online Store | 실시간 모델 스코어링을 위한 저지연(Low-Latency) 피처 접근 | 서브 초(Sub-second) 응답, 키-값 스토어, 최신 값만 유지 |
| Pipeline | 피처 수집과 변환 자동화 | 배치/스트리밍/실시간 데이터 소스 지원 |
Feature Registry(피처 레지스트리)
피처 정의와 메타데이터의 중앙화된 카탈로그입니다. 이는 팀 전체에서 피처를 탐색하고 개발하며 게시하기 위한 주요 인터페이스 역할을 합니다. 레지스트리는 피처 발견을 가능하게 하고 데이터 거버넌스의 기반을 제공합니다.Offline Store(오프라인 스토어)
배치 처리와 모델 학습을 위한 피처 데이터를 관리합니다. Delta Lake와 같은 확장 가능한 스토리지 위에 구축된 오프라인 스토어는 시점 정확 피처 값을 가진 대용량 히스토리 데이터셋을 처리합니다. 이곳에 학습과 백테스팅(Backtesting)을 지원하는 전체 피처 이력이 저장됩니다.Online Store(온라인 스토어)
실시간 모델 스코어링을 위해 피처 값에 저지연 접근을 제공합니다. 서브 초 응답 시간에 최적화된 온라인 스토어는 각 기본 키의 최신 피처 값만 유지합니다. 일반적으로 키-값 스토어 위에 구축되며, 높은 쿼리 볼륨을 처리하도록 설계되었습니다.Pipeline(파이프라인)
피처 수집과 변환을 자동화하며, 배치, 스트리밍 파이프라인, 실시간 데이터 소스를 지원합니다. 이 파이프라인은 원시 데이터를 읽어 변환을 적용하고, 결과를 온라인 스토어와 오프라인 스토어 모두에 씁니다.온라인 피처와 오프라인 피처: 분리의 이해
온라인 피처와 오프라인 피처 간의 구분은 효과적인 아키텍처를 위해 매우 중요합니다. 오프라인 피처(Offline Feature) 는 시점 정확성을 갖춘 완전한 히스토리 데이터를 유지합니다. 2년간의 고객 데이터로 모델을 학습할 때, 각 역사적 순간에 존재했던 피처 값이 필요합니다. 현재 값이 아니라 그 시점의 값이어야 합니다. 이는 각 학습 예제가 그 시점에 사용 가능했을 정보만 사용하도록 하여 데이터 누수를 방지합니다. 온라인 피처(Online Feature) 는 매우 낮은 지연 시간으로 실시간 예측을 제공합니다. 거래를 평가하는 사기 탐지 모델은 밀리초 내에 피처를 사용할 수 있어야 합니다. 온라인 스토어는 빠른 검색에 최적화된 현재 값만 유지하면서 히스토리 깊이를 희생합니다. 온라인 스토어에 피처를 게시할 때, Feature Store는 일반적으로 각 기본 키의 최신 값만 추출하여 온라인 스토어를 컴팩트하고 성능적으로 유지하면서 오프라인 스토어는 완전한 이력을 보존합니다.Feature Engineering 워크플로우
일반적인 워크플로우는 다음 단계를 따릅니다.- 원시 데이터 변환(Raw Data Transformation): 소스 데이터(거래, 로그, 이벤트)를 의미 있는 피처로 변환합니다.
- 피처 정의(Feature Definition): Apache Spark와 같은 확장 가능한 도구를 사용해 변환 로직을 코드로 표현합니다.
- 피처 수집(Feature Ingestion): 배치, 스트리밍, 실시간 파이프라인을 통해 계산된 피처를 스토어에 로드합니다.
- 피처 제공(Feature Serving): 학습(히스토리 값)과 추론(현재 값) 시 모두 모델에 피처를 제공합니다.
피처를 효과적으로 다루기
피처의 조건은 무엇인가?
모든 것이 Feature Store에 속하는 것은 아닙니다. 좋은 피처 후보는 다음과 같습니다.- 원시 데이터로부터 계산된 파생 값 (원시 데이터 자체가 아님)
- 추론 시점이 아닌 사전 계산 가능한 값
- 여러 모델이나 사용 사례에 걸쳐 재사용 가능한 값
- 잘 정의된 계산 로직을 가진 안정적인 값
피처에서 시간 차원 다루기
피처는 본질적으로 시계열 데이터입니다. 시간이 지남에 따라 변화하는 특성을 설명합니다. 시계열 피처 테이블(Time Series Feature Table) 은 기본 키와 함께 타임스탬프 키를 포함함으로써 이 시간적 차원을 명시적으로 모델링합니다. 고객 피처 테이블에서 복합 키(customer_id, date) 는 각 시점의 각 고객의 피처 값을 고유하게 식별합니다. 이를 통해 “기준 시점(As Of)” 조인 이 가능해집니다. 타임스탬프가 있는 학습 예제가 주어지면, Feature Store는 그 시점 이전에 존재했던 최신 피처 값을 검색합니다.
이 접근법은 학습 중 데이터 누수를 방지합니다. 2년간의 히스토리 데이터로 이탈 모델을 학습할 때, 각 학습 예제는 현재 값이 아닌 그 당시 존재했던 피처 값을 사용해야 합니다. 현재 값을 사용하면 고객이 실제로 이탈했는지 여부에 관한 정보가 포함될 수 있기 때문입니다.
비정형 데이터를 위한 피처
Feature Store는 테이블 패러다임을 채택하지만, 이미지나 텍스트 같은 비정형 데이터도 임베딩(Embedding) 을 통해 자연스럽게 적용됩니다. 임베딩은 복잡한 입력을 압축된 형태로 요약하는 벡터 임베딩(Vector Embedding)입니다. 재사용 가능한 피처가 아닌 원시 이미지나 문서를 저장하는 것이 아니라, 그것들로부터 계산된 임베딩을 저장합니다. 예를 들어, 사용자 포럼 게시물이 있는 회사는 언어 모델을 사용하여 게시물 텍스트를 임베딩하고 그 임베딩을 피처로 저장할 수 있습니다. 게시물 내용을 학습해야 하는 여러 모델이 임베딩을 재계산하는 대신 재사용할 수 있습니다. 아키텍처적으로, 임베딩은 부동 소수점 값의 배열일 뿐이며 Feature Store가 쉽게 수용할 수 있는 표준 타입입니다.구현 모범 사례
피처를 테이블로 구성하기
전략적인 피처 테이블 설계는 여러 요소의 균형을 맞춥니다. 다음은 테이블 설계 시 고려해야 할 주요 기준입니다.| 기준 | 설명 | 예시 |
|---|---|---|
| 보안 경계 | 민감한 피처를 제한된 접근 권한으로 분리 | 소득, 건강 데이터를 별도 테이블로 분리 |
| 업데이트 빈도 | 빠르게 변하는 피처와 느리게 변하는 피처를 분리 | 시간별 업데이트 vs. 일별 업데이트 |
| 데이터 소스 정렬 | 특정 데이터 소스에서 파생된 피처를 함께 그룹화 | 거래 테이블 파생 피처, 로그 파생 피처 |
| 소유권 | 팀 경계에 맞춰 피처 테이블 분리 | 데이터 소스를 관리하는 팀이 파생 피처도 소유 |
피처 개발 워크플로우
1단계: 먼저 검색하기(Discovery First)
새로운 피처를 만들기 전에, 피처 레지스트리에서 기존 피처를 검색합니다. 사용 가능한 것을 살펴보면 종종 재사용하거나 응용할 수 있는 부분적으로 관련된 피처가 드러납니다.2단계: 변환 로직 정의하기(Define Transformation Logic)
확장 가능한 도구를 사용하여 피처 계산을 코드로 표현합니다.3단계: 피처 테이블 생성 및 채우기(Create and Populate Feature Tables)
Feature Store 클라이언트를 사용하여 테이블을 만들고 계산된 피처를 씁니다.4단계: 철저하게 문서화하기(Document Thoroughly)
피처가 무엇을 나타내는지, 어떻게 계산되는지, 업데이트 빈도, 사용 사례 예시를 설명하는 설명을 추가합니다. 좋은 문서화는 재사용되는 피처와 먼지만 쌓이는 피처의 차이입니다.Feature Store를 활용한 학습
Feature Store를 사용한 모델 학습은 선언적(Declarative) 접근 방식을 사용합니다. 이 접근 방식은 모델이 사용하는 피처에 대한 메타데이터를 캡처하여, MLflow 통합을 통해 추론 시 자동 피처 검색을 가능하게 합니다.Feature Store를 활용한 추론
Feature Store의 MLflow 통합을 통해 모델이 로깅되면, 모델의 피처 의존성이 자동으로 기록됩니다. 추론 시점에 모델은 무엇이 필요한지 알고 있습니다. Feature Store는 필요한 피처를 조회하고 조인하는 작업을 처리하여, 모델 서빙(Model Serving) 시 수동 피처 파이프라인 코드를 제거합니다.참고 MLOps Big Book 다운로드: Databricks의 MLOps 완전 가이드 e북을 통해 Feature Store를 포함한 프로덕션 ML 운영의 전체 그림을 이해할 수 있습니다. 지금 다운로드
실제 사용 사례
사기 탐지(Fraud Detection)
사기 탐지 시스템은 실시간으로 거래를 평가하며, 밀리초 내에 사용 가능한 피처가 필요합니다. 피처에는 히스토리 패턴 대비 거래 금액, 가맹점 위험 점수, 기기 지문, 지리적 이상 징후 등이 포함됩니다. Feature Store는 이러한 피처를 사전 계산하여 온라인 스토어와 동기화하고, 거래 평가 중 저지연 조회를 가능하게 합니다.동적 가격 책정(Dynamic Pricing)
이커머스 기업은 재고, 수요, 경쟁 위치, 고객 세그먼트를 기반으로 가격을 조정합니다. 배치 파이프라인은 히스토리 데이터로부터 대부분의 피처를 야간에 계산합니다. 스트리밍 파이프라인은 현재 재고와 같이 빠르게 변화하는 피처를 지속적으로 업데이트합니다. 모델은 이러한 피처를 소비하여 대규모로 가격 추천을 생성합니다.고객 이탈 예측(Customer Churn Prediction)
이탈 모델은 위험한 고객을 사전에 파악하여 리텐션 조치를 취할 수 있도록 합니다. 피처는 인구통계, 사용 패턴, 지원 상호작용, 청구 이력을 포함합니다. 이러한 피처들은 일반적으로 배치로 일별 또는 주별로 계산됩니다. Feature Store는 학습을 위한 시점 정확 히스토리 피처와 스코어링을 위한 최신 피처를 제공합니다.추천 시스템(Recommendation Systems)
추천 시스템은 사용자 선호도, 아이템 특성, 맥락 요소를 설명하는 피처를 사용합니다. 사용자와 아이템 피처는 주기적으로 업데이트되어 Feature Store에 저장됩니다. 요청 시점에 이러한 사전 계산된 피처들은 온라인 스토어에서 검색되고, 맥락 피처와 결합되어 추천 모델에 공급됩니다.피해야 할 일반적인 함정
다음 표는 Feature Store 운영 시 자주 발생하는 실수와 대처 방안을 정리한 것입니다.| 함정 | 발생 원인 | 해결 방법 |
|---|---|---|
| 데이터 누수(Data Leakage) | 학습에 현재 피처 값을 사용 | 항상 시점 정확 피처를 사용 |
| 과도한 복잡성(Over-Complication) | 성능 향상 없이 복잡한 계산 추가 | 성능 향상이 명확히 정당화되지 않으면 단순한 집계를 선호 |
| 불충분한 문서화(Poor Documentation) | 피처 설명 없이 배포 | 표현, 계산 방법, 업데이트 빈도, 사용 예시 문서화 |
| 거버넌스 무시(Ignoring Governance) | 접근 제어 없이 민감 피처 노출 | 접근 제어, 소유권 추적 설정 |
시작하기
Feature Store를 도입해야 할 시점
Feature Store는 실험적인 ML을 넘어 프로덕션 배포로 이동할 때 유용합니다. Feature Store가 필요하다는 신호는 다음과 같습니다.- 피처를 공유할 수 있는 모델을 구축하는 여러 팀이 있을 때
- 학습과 추론 간의 일관성 유지에 어려움이 있을 때
- 데이터 사이언티스트가 모델링보다 Feature Engineering에 더 많은 시간을 소비할 때
- 피처 계산 또는 신선도(Staleness) 와 관련된 프로덕션 이슈가 발생할 때
- 어떤 피처가 존재하고 어떻게 사용되는지에 대한 가시성이 부족할 때