관련 포스트MLOps 모델 서빙 피처 스토어 데이터 드리프트

학습-서빙 편차(Training-Serving Skew)

•

2026년 10월 18일 발행•2026년 10월 18일 수정

요약

학습 시 입력과 서빙 시 입력의 차이로 인해 모델의 학습 성능과 서비스 성능이 달라지는 현상

중급

머신러닝 모델의 학습과 배포 과정, 피처 파이프라인의 구조를 이해하고 데이터 분포 비교 방법을 알아야 한다.

태그

MLOps 모델 서빙 피처 스토어 데이터 드리프트

#개념

학습-서빙 편차(Training-Serving Skew)는 머신러닝 모델이 학습될 때 본 입력과 실제 서비스에서 예측할 때 받는 입력이 서로 달라 성능 차이가 생기는 현상이다. Google의 머신러닝 규칙 문서는 이를 학습 시 성능과 서빙 시 성능의 차이로 정의하며, 그 원인이 데이터 처리 방식, 데이터 자체, 피드백 루프에 있다고 설명한다.

학습-서빙 편차가 위험한 이유는 대부분 오류 없이 조용히 발생하기 때문이다. 오프라인 검증에서는 정확도가 높게 나왔는데 배포 후 클릭률이나 전환율이 기대에 못 미치고, 로그에는 예외가 남지 않는다. 모델은 형식만 맞으면 어떤 값이든 받아 예측을 내므로, 입력이 미묘하게 어긋나도 시스템은 정상처럼 보인다. 편차가 나타나는 위치에 따라 흔히 다음과 같이 구분한다.

학습-서빙 편차의 유형

스키마 편차(Schema Skew): 학습 데이터와 서빙 데이터의 스키마가 다른 경우다. 학습 때는 정수였던 피처가 서빙에서 문자열로 들어오거나, 필수 피처가 누락되는 상황이 해당한다.
피처 편차(Feature Skew): 같은 예제에 대해 학습 경로와 서빙 경로가 계산한 피처 값이 다른 경우다. 전처리 로직의 차이나 조회 시점의 차이에서 주로 발생한다.
분포 편차(Distribution Skew): 개별 값은 올바르게 계산되었지만 학습 데이터 전체의 분포가 서빙 트래픽의 분포와 다른 경우다. 편향된 샘플링이나 다른 원천 데이터를 학습에 쓴 경우 나타난다.
스코어링 편차(Scoring/Serving Skew): 모델이 점수를 매긴 예제 중 일부만 실제로 사용자에게 노출되어, 노출된 예제로 만든 학습 데이터가 전체 점수 대상과 달라지는 경우다. Breck 등은 피처 편차, 분포 편차와 함께 이 유형을 구분했다.

학습-서빙 편차의 원인은 다양하지만, 대부분은 학습과 서빙이 서로 다른 코드와 데이터 경로를 따른다는 구조적 차이에서 출발한다. 학습은 대량의 과거 데이터를 배치로 처리하고 서빙은 개별 요청을 수 밀리초 안에 처리해야 하므로, 두 경로는 자연스럽게 다른 기술과 팀으로 나뉜다. 실무에서 자주 만나는 원인은 다음과 같다.

주요 원인

전처리 코드 이중 구현: 학습은 파이썬과 Spark로, 서빙은 Java나 Go로 같은 변환을 따로 구현하면 토큰화, 반올림, 정규화 상수 같은 세부 사항이 어긋난다.
데이터 소스 차이: 학습은 데이터 웨어하우스의 정제된 일 배치 테이블을 쓰고, 서빙은 운영 데이터베이스나 이벤트 스트림을 쓰면 같은 이름의 피처라도 정의와 값이 달라진다.
시점 불일치와 누수: 학습 데이터를 만들 때 예측 시점 이후에 확정된 값을 조인하면, 서빙에서는 얻을 수 없는 미래 정보를 모델이 학습하게 된다.
피처 신선도와 지연: 서빙 시점의 피처가 배치 주기나 스트림 지연 때문에 몇 시간 전 값으로 남아 있으면 학습 때 가정한 최신 값과 어긋난다.
기본값과 결측 처리 차이: 학습 파이프라인은 결측을 평균으로 대치하는데 서빙은 0이나 빈 문자열을 넣는 식으로 처리 방식이 다르면 분포가 크게 달라진다.
라이브러리 버전 차이: 학습과 서빙 환경의 전처리 라이브러리, 토크나이저, 직렬화 포맷 버전이 다르면 같은 코드도 다른 결과를 낼 수 있다.
피드백 루프: 모델이 노출한 결과가 다음 학습 데이터를 만들면, 학습 데이터는 모델이 선택한 항목에 편중되어 실제 서빙 상황을 대표하지 못한다.

이 가운데 가장 흔하고 찾기 어려운 원인은 시점 불일치다. 예를 들어 사용자의 최근 7일 구매 횟수를 학습 데이터에 붙일 때 예측 시점이 아니라 테이블을 만든 날 기준으로 계산하면, 레이블 이후의 구매가 피처에 섞여 들어간다. 이는 데이터 누수(Data Leakage)의 한 형태로, 오프라인 지표는 비정상적으로 좋아지고 서빙 성능은 크게 떨어진다.

학습-서빙 편차는 데이터 드리프트(Data Drift)와 구분해야 한다. 드리프트는 시간이 흐르면서 실제 세계의 데이터 분포가 바뀌는 현상으로, 학습과 서빙의 파이프라인이 완벽히 같아도 발생한다. 반면 편차는 같은 시점의 같은 입력이 학습과 서빙에서 다르게 표현되는 문제로, 재학습만으로는 해결되지 않고 파이프라인 자체를 고쳐야 한다.

두 현상은 대응 방법도 다르다. 드리프트는 주기적인 재학습과 모니터링으로 대응하지만, 편차는 코드와 데이터 경로를 일치시키는 엔지니어링으로 대응한다. 원인을 구분하지 못하면 편차 문제를 재학습 주기 단축으로 덮으려다 비용만 늘고 성능은 회복되지 않는 일이 생긴다. 따라서 성능 저하가 관찰되면 먼저 원인이 어느 쪽인지 진단해야 한다.

편차를 탐지하는 가장 확실한 방법은 서빙 시점에 모델이 실제로 받은 피처를 로깅하고, 이를 학습 데이터와 비교하는 것이다. 같은 요청 식별자로 학습 경로가 다시 계산한 피처와 서빙 로그의 피처를 조인하면 피처 편차를 예제 단위로 확인할 수 있다. 전체 분포는 피처별 통계를 비교해 분포 편차를 확인한다. 분포 비교에는 다음과 같은 지표가 자주 쓰인다. 각 지표에 임계값을 정해 두고 배포 전후와 운영 중에 지속적으로 확인한다.

편차 탐지 지표

피처 값 일치율: 같은 예제에서 학습 경로와 서빙 경로의 피처 값이 일치하는 비율이다. 피처 편차를 가장 직접적으로 드러낸다.
L-무한대 거리(L-infinity Distance): 범주형 피처의 범주별 비율 차이 중 최댓값인 $\max_i |p_i - q_i|$로 계산하며, 특정 범주의 급격한 변화를 잡아낸다.
젠슨-섀넌 발산(Jensen-Shannon Divergence): 두 분포의 대칭적 차이를 측정하며, 수치형과 범주형 피처 모두에 적용할 수 있다.
모집단 안정성 지수(Population Stability Index, PSI): 구간별 비율로 $\sum_i (p_i - q_i)\ln(p_i / q_i)$를 계산하며, 금융권 신용 평가 모델 모니터링에서 오래 쓰여 왔다.

텐서플로 데이터 검증(TensorFlow Data Validation, TFDV)은 이러한 비교를 자동화하는 대표 도구다. 학습 데이터와 서빙 데이터의 통계를 생성하고, 스키마에 피처별 skew_comparator를 지정하면 L-무한대 거리나 젠슨-섀넌 발산이 임계값을 넘는 피처를 이상으로 보고한다. Breck 등은 2019년 논문에서 Google의 실제 운영 경험을 바탕으로 이러한 데이터 검증 체계를 정리했다.

탐지보다 중요한 것은 편차가 구조적으로 생기지 않도록 설계하는 것이다. 탐지는 이미 발생한 문제를 사후에 알려 줄 뿐이며, 원인을 찾아 고치는 동안 서비스 성능 손실은 계속된다. 따라서 학습과 서빙이 같은 정의와 같은 데이터를 공유하도록 파이프라인을 설계하는 것이 근본적인 해법이며, 대표적인 예방 방법은 다음과 같다.

주요 예방 방법

공유 변환 코드: 학습과 서빙이 같은 변환 코드를 사용하도록 만든다. TFX의 TensorFlow Transform은 전처리를 그래프로 내보내 모델과 함께 배포하므로 서빙에서 같은 변환이 그대로 적용된다.
피처 스토어: 피처 스토어(Feature Store)에서 피처 정의를 한 번만 작성하고 오프라인 저장소와 온라인 저장소에 같은 값을 제공한다. Feast 같은 도구가 이 구조를 지원한다.
시점 기준 조인(Point-in-Time Join): 각 학습 예제의 예측 시점 이전에 존재했던 피처 값만 조인하여 미래 정보 누수를 막는다.
서빙 로그 기반 학습 데이터: 서빙 시점에 계산한 피처를 로그로 남기고 이를 그대로 다음 학습 데이터로 사용한다. 학습과 서빙의 입력이 정의상 일치하게 된다.
섀도 배포(Shadow Deployment): 새 모델과 파이프라인을 실제 트래픽에 병렬로 붙여 예측만 기록하고, 오프라인 예측과 비교해 차이가 없을 때 노출을 시작한다.

Google의 머신러닝 규칙은 이 문제에 여러 규칙을 할애한다. 서빙 시 사용한 피처를 로깅해 학습에 재사용하라는 규칙 29, 학습과 서빙 사이에 값이 바뀌는 테이블 조인을 경계하라는 규칙 31, 학습과 서빙 파이프라인의 코드를 재사용하라는 규칙 32가 대표적이다. 같은 예제의 점수가 학습과 서빙에서 다르면 공학적 오류일 가능성이 높다는 규칙 37도 탐지의 기준이 된다.

Sculley 등은 2015년 논문 「Hidden Technical Debt in Machine Learning Systems」에서 머신러닝 시스템이 데이터 의존성, 파이프라인 정글, 숨겨진 피드백 루프 같은 기술 부채를 쌓기 쉽다고 지적했다. 학습-서빙 편차는 이 기술 부채가 실제 성능 저하로 드러나는 대표적인 증상으로, 모델 코드보다 주변 데이터 인프라가 더 큰 위험이 될 수 있음을 보여 준다.

추천 시스템은 학습-서빙 편차가 특히 자주 발생하는 영역이다. 학습은 하루 단위로 집계한 사용자 행동 피처를 쓰는데 서빙은 실시간 세션 피처를 쓰거나, 노출 로그가 이전 모델이 고른 상품에만 쏠려 피드백 루프가 생기기 쉽다. 이런 환경에서는 피처 스토어와 서빙 로그 기반 학습 데이터 생성을 함께 적용하는 경우가 많다.

정리하면 학습-서빙 편차는 모델이 아니라 데이터 경로의 불일치에서 생기는 문제다. 하나의 피처 정의, 시점이 정확한 학습 데이터, 서빙 피처 로깅, 지속적인 분포 비교를 갖추면 대부분의 편차를 예방하거나 조기에 발견할 수 있다. 이는 MLOps 체계에서 모델 품질을 지키는 가장 기본적인 안전장치다.

#관련 용어

데이터 드리프트

시간이 지나면서 실제 데이터의 분포가 학습 당시와 달라지는 현상

데이터 누수

예측 시점에는 알 수 없는 정보가 학습 데이터에 포함되어 성능이 과대평가되는 문제

피처 스토어

피처를 정의·저장하고 학습과 서빙에 같은 값을 제공하는 데이터 시스템

시점 기준 조인

각 예제의 예측 시점 이전에 존재했던 값만 결합하여 학습 데이터를 만드는 조인 방식

섀도 배포

새 모델에 실제 트래픽을 복제해 보내되 결과는 사용자에게 노출하지 않고 기록만 하는 배포 방식

모델 서빙

학습된 모델을 운영 환경에 배포하여 실시간 또는 배치로 예측을 제공하는 과정

#직무 연관도

Data Analyst낮음

모델 성과가 기대와 다를 때 데이터 정의와 집계 기준의 차이를 점검하는 데 활용

Data Scientist높음

오프라인 지표와 온라인 성과의 차이를 진단하고, 시점이 정확한 학습 데이터를 설계하는 데 필요

Data Engineer밀접

피처 파이프라인, 피처 스토어, 서빙 로깅과 모니터링을 구축하여 편차를 예방하고 탐지하는 핵심 과제

#사용 사례

전자상거래금융인터넷 서비스미디어통신

개요

학습-서빙 편차는 실시간 예측 시스템을 운영하는 거의 모든 산업에서 문제가 된다. 전자상거래와 미디어의 추천 시스템에서는 배치 피처와 실시간 피처의 불일치를 관리하는 데, 금융에서는 신용 평가와 이상 거래 탐지 모델의 입력 분포를 PSI 등으로 감시하는 데 활용된다. 인터넷 서비스와 통신 분야에서는 대규모 피처 파이프라인의 정합성을 유지하는 MLOps 관행의 일부로 다루어진다.

사례

전자상거래 추천 모델에서 서빙 시 사용한 피처를 로깅해 학습 데이터로 재사용하고, 피처별 젠슨-섀넌 발산을 매일 비교하여 오프라인 지표는 높지만 클릭률이 떨어지던 원인인 결측 처리 차이를 발견한다.