Day 3 - SageMaker Feature Store: 특성을 자산으로 관리하기

Feature Store란 무엇인가

어제 만든 특성들이 노트북 안 데이터프레임에만 있다면 다음 프로젝트에서 같은 특성을 또 만들어야 한다. 더 나쁜 건 학습 때 쓴 변환과 추론 때 쓴 변환이 미묘하게 달라져 모델 성능이 조용히 무너지는 것이다.

Feature Store는 ML 특성을 중앙에서 저장·관리·제공하는 저장소다. 핵심 단위는 Feature Group으로, 관계형 테이블처럼 행과 열로 구성되며 각 열이 하나의 특성(feature)이다.

from sagemaker.feature_store.feature_group import FeatureGroup
 
feature_group = FeatureGroup(name='customer-features', ...)
 
feature_group.create(
    record_identifier_name='customer_id',   # 행 식별자
    event_time_feature_name='event_time',    # 이벤트 시각
    role_arn=role,
    enable_online_store=True                 # 온라인 스토어 활성화
)
 
# 특성 적재
feature_group.ingest(data_frame=df, max_workers=3)

같은 customer_id에 대해 event_time이 다른 여러 레코드가 쌓이면, "특정 시점의 특성 값이 무엇이었나"를 재구성할 수 있다.

customer_id = cust_123 의 이력

event_time          purchase_30d   activity_score
2026-01-15 10:00        12             0.71
2026-03-02 09:30        18             0.83
2026-06-24 14:10        25             0.66   ← 온라인 스토어가 반환하는 "최신값"

오프라인 스토어는 위 세 줄을 모두 보관한다 → 과거 시점 재구성 가능

Event Time은 시계열 데이터베이스의 bitemporal 개념과 닿아 있다. 모델을 과거 데이터로 학습할 때 "그 시점에 실제로 알 수 있었던 특성 값"만 써야 미래 정보 누수(look-ahead bias)를 막는다. 예를 들어 2024년 1월 거래를 예측하는데 2024년 3월에 갱신된 특성 값을 쓰면 미래를 본 것이다. Event Time 기반 조회는 이 시간적 정합성을 보장하는 메커니즘이다.

온라인 스토어와 오프라인 스토어

Feature Store의 핵심은 두 종류의 스토어를 동시에 제공한다는 점이다. 시험에서 이 둘의 차이를 구분해야 한다.

# 온라인 스토어: 실시간 추론 시 최신 특성 조회
record = featurestore_runtime.get_record(
    FeatureGroupName='customer-features',
    RecordIdentifierValueAsString='cust_12345'
)
 
# 오프라인 스토어: 학습용 데이터셋 생성 (Athena)
query = feature_group.athena_query()
query.run(query_string="SELECT * FROM customer_features WHERE ...",
          output_location='s3://my-bucket/query-results/')

⚠️ 함정: 온라인 스토어만 활성화하면 학습용 이력이 S3에 쌓이지 않고, 오프라인만 활성화하면 실시간 추론에서 저지연 조회를 못 한다. 대부분의 실제 ML 시스템은 둘 다 활성화해서, 같은 특성을 학습(오프라인)과 추론(온라인)에 일관되게 쓴다. 데이터를 ingest하면 SageMaker가 온라인에는 최신값을, 오프라인에는 이력을 자동으로 동기화한다.

일관성: training/serving skew 방지

Feature Store의 가장 큰 가치는 학습과 추론이 같은 특성 정의를 공유한다는 점이다. training/serving skew는 학습 때와 서빙 때 특성 계산 방식이 달라 모델 성능이 떨어지는 고전적 문제다.

전형적 시나리오: 학습 파이프라인은 pandas로 "최근 30일 평균 구매액"을 계산하고, 추론 서버는 Java로 같은 값을 다시 계산한다. 두 구현이 미묘하게 다르면(경계 처리, 반올림) 모델이 보는 값이 학습 때와 달라진다.

[특성 계산 파이프라인]  ──ingest──>  [Feature Store]
                                        |
                  ┌─────────────────────┴──────────────────┐
                  v                                          v
        [오프라인 스토어]                            [온라인 스토어]
        학습 데이터셋 생성                          실시간 추론 조회
        (Athena, 동일 정의)                        (GetRecord, 동일 정의)

training/serving skew는 ML 시스템의 기술 부채를 다룬 Google의 "Hidden Technical Debt in Machine Learning Systems" 논문에서 강조한 핵심 문제다. 모델 코드는 전체 ML 시스템의 작은 부분이고, 데이터 파이프라인과 특성 일관성이 실패의 주원인이다. Feature Store는 특성을 "코드"가 아니라 "공유 데이터 자산"으로 승격시켜, 정의를 한 곳에 모으는 것으로 이 부채를 줄인다.

특성 재사용과 거버넌스

Feature Store의 두 번째 가치는 재사용이다. A팀이 만든 "고객 생애 가치", "최근 활동 점수" 같은 특성을 B팀이 새 모델에 그대로 가져다 쓸 수 있다.

Feature Store에는 여러 Feature Group을 시점 정합성에 맞게 조인하는 기능이 있다. 학습 데이터를 만들 때 customer 특성과 product 특성을 각자의 event time 기준으로 조인하면, "그 시점에 알 수 있었던 값들"만 정확히 결합된다. 이를 point-in-time correct join이라 하며, 수작업으로 하면 매우 까다로운 미래 누수 방지를 자동화해준다.

잘못된 조인 (미래 누수)              올바른 point-in-time 조인
예측 시점: 2026-01-15                예측 시점: 2026-01-15
customer 특성: 2026-03-02 값 ✗       customer 특성: 2026-01-15 이전 최신값 ✓
  → 두 달 뒤의 정보를 미리 봄            → 그 시점에 알 수 있던 값만 사용

한 핀테크 회사가 사기 탐지와 신용 평가 두 모델을 운영하는데, 둘 다 "최근 거래 빈도"라는 특성이 필요했다. 처음엔 각 팀이 따로 계산해 정의가 미묘하게 달랐고, 한 팀이 버그를 고쳐도 다른 팀에 반영이 안 됐다. Feature Store로 이 특성을 한 번 정의해 공유하자 정의 불일치가 사라지고, 한 곳을 고치면 양쪽 모델이 함께 개선됐다.

데이터 흐름 정리

전형적 파이프라인은 이렇게 이어진다.

이 흐름 전체가 동일한 특성 정의를 공유하므로 일관성이 유지된다.

시험 판별 요약

스토어 활성화 조합과 결과

Feature Group을 만들 때 온라인·오프라인 중 무엇을 켜느냐가 이후에 할 수 있는 일을 결정한다.

• 둘 다 켜면 ingest 한 번으로 온라인엔 최신값이, 오프라인엔 이력이 각각 반영된다.
• 나중에 학습 이력이 필요해졌는데 오프라인을 꺼둔 상태였다면, 그 기간의 이력은 되살릴 수 없다.

어떤 특성을 Feature Store에 넣나

모든 컬럼을 넣는 것이 답은 아니다. 관리 비용과 가치의 균형이 있다.

시점 정합성이 무너지는 순간

예측하려는 시점: 2026-01-15
   │
   ├─ 올바름: event_time <= 2026-01-15 중 가장 최신 레코드 사용
   │
   └─ 잘못됨: 최신 레코드(2026-06-24)를 그대로 사용
                → 5개월 뒤의 정보를 학습에 넣은 셈

⚠️ 함정: 백테스트 성능이 유난히 좋을 때는 성능을 기뻐하기 전에 시점 정합성을 먼저 의심해야 한다. point-in-time correct join을 쓰지 않은 학습셋은 거의 항상 낙관적인 숫자를 낸다.

다음 글에서는 이렇게 준비한 데이터가 공정하고 균형 잡혀 있는지 점검하는 데이터 편향·품질과 SageMaker Clarify를 본다.

📖 용어

• Feature Store : ML 특성을 중앙에 모아 저장하고 학습·추론에 일관되게 제공하는 저장소.
• Feature Group : Feature Store의 기본 단위. 행과 열로 이뤄진 테이블 형태이며 특성들이 열이 된다.
• Record Identifier : 각 행을 구분하는 키. 온라인 조회 시 이 값으로 최신 레코드를 찾는다.
• Event Time : 그 특성 값이 언제 기록됐는지의 시각. 과거 시점 재구성과 누수 방지의 기준.
• 온라인 스토어 : 최신 특성 1건을 밀리초 안에 돌려주는 key-value 저장소. 실시간 추론용.
• 오프라인 스토어 : 모든 이력을 S3에 Parquet으로 쌓아두는 저장소. 학습 데이터셋 생성용.
• GetRecord : 온라인 스토어에서 식별자로 최신 레코드 하나를 가져오는 API.
• training/serving skew : 학습 때와 추론 때 특성 계산이 달라 모델이 조용히 나빠지는 현상.
• point-in-time correct join : 예측 시점 기준으로 "그때 알 수 있던 값"만 결합하는 조인 방식.
• look-ahead bias(미래 누수) : 예측 시점 이후의 정보를 학습에 써서 성능이 부풀려지는 오류.