요약(TL;DR) — 대부분의 팀은 저지연(low-latency) 온라인 서빙을 위해 피처 스토어(Feature Store)를 도입하지만, 그것은 피처 스토어가 해결하도록 설계된 어려운 문제가 아니었습니다. 실제 역할은 시점 정확성(point-in-time correctness) — 즉, 미래의 데이터가 학습 레이블(training labels)로 유출되는 것을 방지하는 것 — 이며, 대부분의 구현체는 이를 조용히 건너뜁니다. LLM 유도 피처(LLM-derived features)는 아무도 추적하지 않는 버전 관리되지 않은 누수 벡터를 추가함으로써 이 문제를 더욱 악화시킵니다.

팀에게 왜 피처 스토어를 도입했는지 물어보면 다음과 같은 답변을 듣게 될 것입니다: "학습(training)과 서빙(serving) 사이의 일관된 피처가 필요했고, 온라인 모델을 위한 저지연 조회가 필요했습니다." 이는 사실이지만, 문제의 쉬운 20%에 불과합니다. 나머지 어려운 80% — 피처 스토어가 단순히 "캐시가 앞에 붙은 데이터베이스"가 아닌 별도의 아키텍처 패턴으로서 존재하는 이유 — 는 바로 시점 정확성(point-in-time correctness)입니다. 대부분의 팀은 실제로 그 부분을 구축하지 않습니다. 그들은 캐시를 구축하고 그것을 피처 스토어라고 부릅니다.

프로덕션에 가기 전까지는 아무도 알아채지 못하는 누수

시점 정확성(Point-in-time correctness)이란 다음을 의미합니다: 학습 예시(training example)를 위해 피처를 계산할 때, 해당 행(row)의 이벤트 타임스탬프(event timestamp) 시점에 사용 가능했을 데이터만을 사용해야 하며, 해당 행을 기준으로 미래의 데이터를 사용해서는 안 됩니다. 이는 당연하게 들립니다. 하지만 이는 끊임없이 위반되고 있으며, 심지어 오프라인 지표(offline metrics)를 나쁘게 만드는 것이 아니라 더 좋게 보이게 만드는 방식으로 위반되기 때문에, 바로 그 점 때문에 검토 과정에서도 살아남게 됩니다.

전형적인 사기 탐지 피처(fraud feature)인 avg_transaction_amount_30d를 예로 들어보겠습니다. 만약 이 피처를 계산할 때, 윈도우(window)를 "이 특정 트랜잭션의 타임스탬프 이전"으로 제한하지 않고, 단순히 customer_id를 기준으로 GROUP BY를 사용하여 트랜잭션 테이블과 조인한다면, 당신은 레이블이 지정된 이벤트 이후의 트랜잭션이 피처에 영향을 미치도록 허용한 것입니다. 모델은 미래의 정보가 포함된 패턴을 학습하게 됩니다. 오프라인 AUC(Area Under the Curve)는 매우 훌륭하게 나옵니다. 하지만 프로덕션(production) 환경의 추론(inference) 시점에는 해당 미래 데이터가 존재하지 않으며, 모델이 실제로 마주하는 피처 분포는 학습 시의 분포와 달라집니다. 아무도 이것을 누수 버그(leakage bug)라고 부르지 않습니다. 왜냐하면 에러를 발생시키지 않기 때문입니다. 대신 몇 달 뒤에 "설명할 수 없는 모델 성능 저하"로 나타나며, 데이터 드리프트(drift) 때문이라는 비난을 받고, 누수가 여전히 존재하는 상태에서 아무것도 해결하지 못하는 재학습(retraining) 사이클을 유발할 뿐입니다.

이것이 간과되는 이유

시점 조인(Point-in-time joins)은 올바르게 구축하기에 비용이 많이 들고 테스트하기에는 지루합니다. "현재 상태"만 있는 데이터 웨어하우스(data warehouse) 테이블이 아니라, 타임스탬프가 찍힌 이벤트 로그에 대해 as-of 조인을 지원하는 오프라인 스토어(offline store)가 필요합니다. 대부분의 팀은 그런 로그를 가지고 있지 않습니다. 그들은 서서히 변하는 차원 테이블(slowly-changing dimension tables), 야간 스냅샷(nightly snapshots), 혹은 더 나쁘게는 이력 정보가 전혀 없는 프로덕션 데이터베이스 복제본(production database replica)을 가지고 있습니다. "정확히 이 순간에 이 피처는 어떤 모습이었는가"를 재구성하기 위한 인프라를 구축하는 것은 실질적인 엔지니어링 투자이며, 그 자체로는 눈에 보이는 제품 가치를 창출하지 않습니다. 그저 아직 발생하지 않은 버그를 방지할 뿐입니다. 이는 로드맵 검토 과정에서 설득하기 매우 어려운 과제이며, 따라서 데모하기 쉬운 부분, 즉 10ms 미만의 조회 속도를 가진 Redis 기반의 온라인 스토어(online store)를 위해 우선순위에서 밀려나게 됩니다.

그 결과, 업계에는 "피처 스토어 (feature store)"라는 라벨이 붙어 있지만 실제로는 스키마 레지스트리 (schema registry)가 부착된 공유 캐시 (shared cache)에 불과한 시스템들이 넘쳐나고 있습니다. 이러한 시스템들은 피처 "정의 (definitions)"에 대한 학습/서빙 왜곡 (training/serving skew) 문제, 즉 양쪽 경로에서 동일한 변환 코드가 실행되도록 하는 문제는 해결합니다. 하지만 피처 "타이밍 (timing)"에 대한 학습/서빙 왜곡 문제는 해결하지 못하며, 이는 코드 리뷰 과정에서 보이지 않기 때문에 훨씬 더 위험한 문제입니다.

LLM 시대에 재현된 동일한 버그

이 문제는 이제 새로운 생명력을 얻었습니다. 이제 팀들은 LLM에서 유도된 시그널 (signals)을 피처로 저장하고 있습니다. 예를 들어, 고객 지원 티켓의 임베딩 (embedding), 분류기 프롬프트 (classifier prompt)로부터 얻은 감성 점수 (sentiment score), 또는 비정형 텍스트에 대한 LLM 호출로 생성된 "위험 카테고리 (risk category)" 태그 등이 이에 해당합니다. 이러한 값들은 수치형 집계 (numeric aggregates) 데이터와 함께 동일한 엔티티 키 (entity key) 및 타임스탬프 (timestamp)를 가지고 피처 스토어에 기록되며, 모두가 동일한 보장 사항이 적용된다고 가정합니다.

하지만 그렇지 않습니다. 왜냐하면 이러한 피처들은 스키마가 포착하지 못하는 의존성을 가지고 있기 때문입니다. 즉, "어떤 모델 버전과 어떤 프롬프트가 이 값을 생성했는가" 하는 점입니다. 평균 거래 금액과 같은 수치형 집계는 정의 측면에서 안정적입니다. SQL이 변경되었거나 변경되지 않았거나 둘 중 하나이며, SQL의 버전을 관리할 수 있습니다. 반면 LLM 유도 피처의 의미는 기반 모델이 업데이트되거나, 프롬프트 템플릿 (prompt template)이 단어 하나만 수정되거나, 혹은 제공업체가 기본 샘플링 동작 (sampling behavior)을 변경할 때 조용히 변할 수 있습니다. 이 중 그 어떤 것도 스키마 변경으로 나타나지 않습니다. 여러분의 피처 스토어는 ticket_sentiment_score가 1년 동안 "동일한 피처"였다고 기쁘게 말하겠지만, 실제로는 세 가지 서로 다른 모델 버전이 세 가지 서로 다른 감성 개념을 바탕으로 계산한 결과물일 수 있습니다.

이것은 시점 누수(point-in-time leakage)의 사촌 격인 '시점-버전 누수(point-in-version leakage)'입니다. 모델 버전 A에 의해 계산된 ticket_sentiment_score를 바탕으로 학습된 모델은, 서빙(serving)을 위해 해당 피처가 모델 버전 B에 의해 소리 없이 재생성되었을 때 올바르게 동작하지 않을 것이며, 재학습(retraining)에 사용되는 백필(backfill)의 경우도 마찬가지입니다. 만약 당신의 피처 스토어(feature store)의 출처 메타데이터(provenance metadata)가 "타임스탬프와 엔티티 키(timestamp and entity key)" 수준에서 멈춘다면, 당신은 이를 감지할 방법이 없으며, 성능 저하가 발생했을 때 이를 설명할 방법도 없습니다.