MLOps 08 - 피처 스토어

같은 피처인데 왜 결과가 다른가?

모델을 학습할 때 사용한 피처와 서빙할 때 사용하는 피처가 동일하다고 확신할 수 있는가? 대부분의 팀은 이 질문에 자신 있게 답하지 못한다. 학습 코드에서는 판다스로 피처를 계산하고, 서빙 코드에서는 자바로 같은 피처를 다시 구현하는 경우가 흔하다. 두 구현이 미묘하게 달라지면 학습 시 95%의 정확도를 보였던 모델이 프로덕션에서 예상치 못한 성능 저하를 겪게 된다.

이 문제를 학습-서빙 스큐(Training-Serving Skew)라고 부른다. 피처를 두 번 구현하는 것이 근본적인 원인이며, 피처 스토어는 이 문제를 해결하기 위해 등장한 인프라이다.

피처 스토어의 핵심 아이디어

피처 스토어의 핵심은 피처 정의를 한 곳에서 관리하고, 학습과 서빙 모두 같은 소스에서 피처를 가져오게 하는 것이다. 피처를 한 번 정의하면 학습 시에는 배치로, 서빙 시에는 실시간으로 제공되지만, 계산 로직 자체는 동일하게 유지되는 구조이다.

이를 위해 피처 스토어는 두 가지 저장소를 운영한다. 오프라인 스토어는 학습용 대량 데이터를 보관하며, 데이터 웨어하우스나 파일 시스템 기반으로 구성된다. 온라인 스토어는 서빙 시 낮은 지연시간으로 피처를 제공하며, Redis나 DynamoDB 같은 키-밸류 스토어를 사용한다. 피처 정의는 하나이지만, 접근 경로가 학습과 서빙에 맞게 분리되어 있는 것이다.

피처 정의 (단일 소스)
    │
    ├── 오프라인 스토어 ──→ 학습 파이프라인 (배치)
    │   (Parquet, BigQuery)
    │
    └── 온라인 스토어 ──→ 서빙 API (실시간)
        (Redis, DynamoDB)

포인트-인-타임 정확성

피처 스토어가 단순한 캐시와 다른 점은 포인트-인-타임 정확성(Point-in-Time Correctness)을 보장한다는 것이다. 과연 이것이 왜 중요한가?

예를 들어 대출 승인 모델을 학습한다고 가정해보자. 2024년 3월에 대출 신청이 들어왔을 때, 그 시점의 고객 신용 점수를 피처로 사용해야 한다. 2024년 6월에 업데이트된 신용 점수를 사용하면 미래 정보가 학습에 유입되는 데이터 누수(Data Leakage)가 발생하는 것이다. 이렇게 학습된 모델은 실험에서는 좋은 성능을 보이지만 프로덕션에서는 실패하게 된다.

피처 스토어는 각 피처의 타임스탬프를 관리하여, 학습 데이터를 생성할 때 해당 시점에 실제로 사용 가능했던 피처만 조인한다. 이 기능이 없으면 올바른 학습 데이터셋을 만드는 것 자체가 매우 복잡한 엔지니어링 작업이 된다.

팀 간 피처 재사용

피처 스토어의 또 다른 가치는 조직 내에서 피처를 재사용할 수 있게 한다는 점이다. 추천 팀에서 계산한 사용자 활동 피처를 사기 탐지 팀이 그대로 가져다 쓸 수 있다면, 중복 작업이 줄어들고 피처의 품질도 높아진다. 각 팀이 독립적으로 같은 피처를 구현하면 미묘한 차이가 생기기 마련이고, 어떤 팀의 구현이 맞는지 검증하기도 어렵다.

피처 스토어는 중앙 레지스트리 역할을 하여, 어떤 피처가 존재하고, 누가 만들었으며, 어떤 모델에서 사용되는지 추적할 수 있게 한다. 이는 단순히 코드 중복을 줄이는 것을 넘어, 피처에 대한 조직 차원의 거버넌스를 가능하게 하는 것이다.

주요 도구

현재 널리 사용되는 피처 스토어 도구들은 각각 다른 강점을 가진다.

Feast는 오픈소스로 시작하여 가장 널리 채택된 도구이다. 피처 정의를 파이썬 코드로 작성하고, 오프라인 스토어와 온라인 스토어를 추상화하여 동일한 인터페이스로 접근할 수 있게 한다. 관리형 서비스가 필요한 경우에는 Tecton이나 클라우드 네이티브 솔루션이 운영 부담을 줄여준다.

MLOps 파이프라인에서의 위치

피처 스토어는 데이터 파이프라인과 모델 학습/서빙 사이에 위치한다. 원시 데이터가 데이터 파이프라인을 통해 가공되면, 그 결과가 피처 스토어에 등록된다. 학습 파이프라인은 오프라인 스토어에서 과거 피처를 조회하고, 서빙 인프라는 온라인 스토어에서 실시간 피처를 조회하는 구조이다.

원시 데이터 → 데이터 파이프라인 → 피처 스토어 → 학습/서빙
                                    │
                              피처 레지스트리
                           (메타데이터, 버전, 소유자)

피처 스토어가 없는 초기 단계에서는 피처 계산 로직이 학습 코드와 서빙 코드에 산재하게 된다. 모델 수가 적을 때는 관리가 가능하지만, 수십 개의 모델이 수백 개의 피처를 공유하는 규모에 이르면 중앙화된 피처 관리 없이는 일관성을 유지하기 어려워진다. 피처 스토어 도입 시점은 학습-서빙 스큐로 인한 프로덕션 문제를 경험하거나, 팀 간 피처 중복이 눈에 띄기 시작할 때가 적절하다.

다음 포스트에서는 GPU 인프라와 스케일링을 살펴본다.