모니터링과 drift

이 장에서 배울 것

모델 서빙이 끝나면 운영은 시작된다. 이번 장에서는 배포된 모델이 실제 환경에서 계속 잘 동작하는지 확인하는 방법을 배운다.

이 장의 목표는 다음과 같다.

• CPU, 메모리, GPU, 디스크, 네트워크, QPS, 오류율, p95 지연 시간 같은 인프라·서비스 지표를 정의한다.

• 정답 라벨이 늦게 들어올 때 모델 품질 지표, 프록시 지표, 비즈니스 KPI를 함께 추적한다.

• 데이터 드리프트, 예측 드리프트, 개념 드리프트의 차이를 구분한다.

• 로그, 메트릭, 트레이스, 대시보드, 알림, SLO를 하나의 관측성 체계로 연결한다.

• 모니터링 결과를 재학습, 롤백, 데이터 조사, 임계값 조정으로 이어지는 피드백 루프로 설계한다.

왜 이 주제가 중요한가

모델은 배포된 뒤에도 조용히 나빠질 수 있다. 서버는 정상이다. API도 200 응답을 준다. 지연 시간도 안정적이다. 그런데 추천 품질이 낮아지고, 사기 탐지 모델이 새로운 사기 패턴을 놓치고, 챗봇은 예전 정책을 기준으로 답할 수 있다.

전통적인 소프트웨어 장애는 비교적 선명하다. 서비스가 내려가거나, 오류가 증가하거나, 응답 시간이 느려진다. ML 시스템의 문제는 더 조용하다. 모델은 계속 답을 내지만, 그 답이 점점 덜 맞을 수 있다. IBM은 모델 드리프트를 데이터나 입력 변수와 출력 변수의 관계 변화 때문에 모델 성능이 저하되는 현상으로 설명한다.¹

그래서 운영자는 "서비스가 살아 있는가?"만 보면 안 된다. "모델이 아직 유효한가?", "사용자 행동이 바뀌었는가?", "비즈니스 결과가 좋아지고 있는가?"까지 봐야 한다.

핵심 개념 설명

1. 네 가지 층위의 지표를 함께 본다

운영 모니터링은 한 장의 대시보드로 끝나지 않는다. 최소한 네 층위가 필요하다.

첫째, 인프라 지표다. CPU 사용률, 메모리 사용률, GPU 사용률, GPU 메모리, 디스크 사용량, 네트워크 송수신량을 본다. 모델 서버가 컨테이너나 쿠버네티스 위에서 동작한다면 파드 재시작 횟수, 노드 상태, 큐 길이도 중요하다.

둘째, 서비스 지표다. QPS(Query Per Second, 초당 요청 수), 오류율, 타임아웃 비율, p95 지연 시간을 본다. p95 지연 시간은 전체 요청 중 95%가 이 시간 안에 끝났다는 뜻이다. 평균 지연 시간만 보면 일부 사용자의 극단적으로 느린 경험을 놓치기 쉽다.

셋째, 모델 지표다. 분류 모델이면 정확도, 정밀도, 재현율, F1, AUROC를 볼 수 있다. 회귀 모델이면 MAE, RMSE 같은 오차 지표를 본다. 생성형 AI나 LLM 시스템에서는 정답이 하나로 고정되지 않는 경우가 많으므로 응답 관련성, 근거 충실성, 환각률, 안전성 점수, 사용자 피드백 등을 함께 본다.

넷째, 비즈니스 지표다. 클릭률, 전환율, 재구매율, 이탈률, 상담 해결률, 매출, 비용 절감액 같은 지표다. Google의 ML 프로젝트 관리 가이드도 모델 지표와 비즈니스 지표를 구분하고, 모델 지표가 좋아도 비즈니스 성과가 반드시 좋아지는 것은 아니라고 강조한다.²

좋은 모니터링은 이 네 층위를 분리하지 않는다. 예를 들어 추천 클릭률이 떨어졌을 때, 원인이 모델 성능 저하인지, 신규 사용자 유입인지, 서비스 지연 증가인지, 상품 재고 변화인지 함께 확인할 수 있어야 한다.

2. 정답 라벨은 보통 늦게 온다

운영 환경에서는 정답을 바로 알 수 없는 경우가 많다. 대출 부도 예측 모델은 실제 부도 여부를 몇 달 뒤에야 알 수 있다. 이탈 예측 모델도 사용자가 정말 이탈했는지 시간이 지나야 확인된다. 고객 지원 챗봇도 "답변이 실제로 문제를 해결했는지"는 후속 행동을 봐야 알 수 있다.

이때는 세 종류의 신호를 함께 써야 한다.

• 모델 품질 지표: 라벨이 들어온 뒤 계산하는 정확도, 재현율, 오차 등

• 프록시 지표: 정답은 아니지만 품질을 추정할 수 있는 중간 신호

• 비즈니스 KPI: 실제 목표와 연결되는 결과 지표

예를 들어 이탈 예측 모델에서 실제 이탈 라벨이 30일 뒤에 들어온다고 하자. 그동안은 로그인 빈도, 사용 시간, 알림 클릭률, 고객 문의 증가 같은 프록시 지표를 본다. 프록시 지표가 악화되고, 나중에 들어온 실제 이탈률도 상승한다면 모델 품질 저하 가능성이 커진다.

프록시 지표는 정답이 아니다. 그래서 단독으로 자동 재학습을 결정하면 위험하다. 대신 빠른 경보로 사용하고, 라벨 기반 품질 지표와 비즈니스 KPI로 확인한다.

3. 드리프트의 종류를 구분한다

드리프트는 "무언가 변했다"는 말이다. 하지만 무엇이 변했는지에 따라 대응이 달라진다.

데이터 드리프트는 입력 데이터의 분포가 바뀌는 현상이다. 여름 데이터로 학습한 수요 예측 모델이 겨울 상품 패턴을 만나면 입력 특성의 분포가 달라진다. 사용자 연령대, 지역, 기기 종류, 문장 길이, 이미지 밝기, 거래 금액 범위가 바뀌는 것도 데이터 드리프트다.

예측 드리프트는 모델이 내는 예측값의 분포가 바뀌는 현상이다. 예전에는 승인과 거절이 7:3이었는데 최근에는 9:1이 되었다면 예측 분포가 바뀐 것이다. 입력 분포가 변했기 때문일 수도 있고, 전처리 오류나 피처 파이프라인 문제 때문일 수도 있다.

개념 드리프트는 입력과 정답 사이의 관계가 바뀌는 현상이다. 예전에는 특정 행동이 사기 신호였지만 사기범들이 전략을 바꾸면서 더 이상 유효하지 않을 수 있다. 또는 "좋은 투자", "스팸", "위험 고객"의 의미가 시장이나 정책 변화로 바뀔 수 있다. AWS의 생성형 AI 운영 가이드도 LLM에서 데이터 드리프트는 사용자 프롬프트 분포 변화로, 개념 드리프트는 입력과 기대 출력 사이의 관계 변화로 나타난다고 설명한다.³

중요한 점은 데이터 드리프트가 항상 성능 저하를 뜻하지는 않는다는 것이다. 입력 분포가 변해도 모델이 여전히 잘 맞을 수 있다. 반대로 통계적 분포 변화는 작아 보여도 비즈니스에 중요한 구간에서 성능이 크게 나빠질 수 있다.

4. 통계 기반 탐지는 유용하지만 한계가 있다

드리프트 탐지에는 여러 통계 방법이 쓰인다.

• KS 테스트: 두 데이터 분포가 같은지 비교한다.

• PSI: 변수 분포가 기준 시점 대비 얼마나 변했는지 본다.

• KL/JS divergence: 두 확률 분포의 차이를 측정한다.

• Wasserstein 거리: 한 분포를 다른 분포로 옮기는 데 필요한 차이를 거리처럼 본다.

이 방법들은 빠르고 자동화하기 쉽다. 하지만 한계도 분명하다. 첫째, 어떤 임계값이 "위험"인지는 도메인마다 다르다. 둘째, 많은 피처를 동시에 보면 우연한 경보가 많아진다. 셋째, 분포 변화가 성능 저하와 직접 연결되지 않을 수 있다. 넷째, LLM의 프롬프트나 응답처럼 고차원·비정형 데이터에서는 단순한 1차원 통계만으로 의미 변화를 잡기 어렵다.

따라서 통계 지표는 결론이 아니라 출발점이다. "드리프트가 발생했으니 즉시 재학습"이 아니라 "어느 구간에서 어떤 변화가 생겼는지 조사하라"는 신호로 해석해야 한다.

5. 관측성은 행동으로 이어져야 한다

관측성(observability)은 시스템이 왜 그렇게 동작했는지 추적할 수 있는 능력이다. 모니터링이 "지표를 본다"에 가깝다면, 관측성은 "문제 원인을 찾아 행동한다"에 가깝다.

기본 구성요소는 다음과 같다.

• 로그: 개별 요청에 대한 상세 기록

• 메트릭: 시간에 따른 숫자 지표

• 트레이스: 하나의 요청이 여러 컴포넌트를 지나간 경로

• 대시보드: 운영자가 상태를 빠르게 보는 화면

• 알림: 조치가 필요한 상황을 담당자에게 전달하는 규칙

• SLO: 서비스가 지켜야 할 목표 수준

예를 들어 "p95 지연 시간 500ms 이하를 99% 시간 동안 유지한다"는 SLO를 정할 수 있다. 모델 품질에 대해서는 "최근 7일 라벨 기준 재현율이 0.90 이상이어야 한다"처럼 정의할 수 있다. LLM 시스템이라면 "근거 없는 답변 비율이 2% 이하", "검색된 문서와 응답의 관련성 점수 0.8 이상" 같은 목표도 가능하다.

쉬운 비유 또는 사례

모델 모니터링은 냉장고 온도계와 비슷하다. 냉장고 문은 닫혀 있고 전원도 켜져 있다. 겉으로는 정상이다. 하지만 내부 온도가 조금씩 올라가면 음식은 천천히 상한다.

모델도 그렇다. API는 살아 있고 로그도 찍힌다. 하지만 입력 데이터가 변하고, 예측 분포가 흔들리고, 사용자의 기대가 바뀌면 모델의 품질은 천천히 상한다. 모니터링은 이 변화를 일찍 발견하는 온도계다. 좋은 운영은 온도계만 설치하지 않는다. 온도가 올라갔을 때 냉장고를 점검할지, 음식을 폐기할지, 전원을 교체할지, 문이 잘 닫히는지 확인하는 절차까지 만든다.

사례를 하나 보자. 쇼핑몰의 추천 모델이 있다. 배포 직후에는 클릭률이 높았다. 한 달 뒤 클릭률이 하락했다. 인프라 대시보드는 정상이었다. 그런데 모니터링을 보니 신규 유입 사용자의 비율이 급증했고, 모바일 앱에서 들어오는 요청의 비중도 크게 늘었다. 입력 데이터 분포가 바뀐 것이다. 예측 분포를 보니 특정 카테고리 상품만 과도하게 추천되고 있었다. 운영팀은 모바일 신규 사용자 구간을 따로 분석했고, 최근 행동 데이터를 더 반영한 모델을 재학습했다. 동시에 기존 모델로 일부 트래픽을 롤백할 수 있게 카나리아 배포 비율을 조정했다.

이 사례에서 핵심은 "클릭률 하락"만 본 것이 아니다. 서비스 지표, 입력 분포, 예측 분포, 사용자 세그먼트, 배포 버전을 함께 본 것이다.

직접 해보는 실습

이번 실습에서는 실제 도구를 깊게 설치하기보다, 운영 모니터링 설계 문서를 만들어 본다. 작은 모델 하나를 운영한다고 가정하고 다음 표를 채운다.

1단계: 지표 정의하기

이 표에서 중요한 것은 "경고 기준"보다 "담당 행동"이다. 알림을 받았는데 무엇을 해야 할지 모르면 그 알림은 소음이 된다.

2단계: 기준선 정하기

기준선(baseline)은 비교 기준이다. 다음 데이터를 저장한다.

• 학습 데이터의 피처별 평균, 표준편차, 분위수

• 검증 데이터의 모델 성능

• 배포 직후 안정 기간의 입력 분포

• 배포 직후 안정 기간의 예측 분포

• 주요 비즈니스 KPI의 평상시 범위

기준선은 모델 버전과 연결해야 한다. 모델이 바뀌면 기준선도 바뀔 수 있다. 따라서 모델 레지스트리에 모델 버전, 데이터 버전, 기준선 통계를 함께 기록하는 것이 좋다.

3단계: 간단한 드리프트 점검 코드 작성하기

아래 코드는 학습 데이터와 최근 운영 데이터의 한 피처를 KS 테스트로 비교하는 예시다.

import pandas as pd
from scipy.stats import ks_2samp

train = pd.read_csv("data/train_baseline.csv")
current = pd.read_csv("data/current_window.csv")

feature = "amount"
stat, p_value = ks_2samp(train[feature].dropna(), current[feature].dropna())

print({
    "feature": feature,
    "ks_stat": round(stat, 4),
    "p_value": round(p_value, 4),
})

if p_value < 0.05:
    print("분포 변화 신호가 있습니다. 모델 성능과 비즈니스 지표를 함께 확인하세요.")

주의할 점이 있다. p-value가 작다고 무조건 장애는 아니다. 운영 데이터가 아주 많으면 작은 차이도 통계적으로 유의하게 나올 수 있다. 반대로 표본이 너무 작으면 중요한 변화를 놓칠 수 있다. 그래서 통계 지표, 시각화, 모델 성능, 비즈니스 결과를 함께 봐야 한다.

4단계: 피드백 루프 설계하기

다음과 같은 규칙을 문서화한다.

• 오류율 또는 p95 지연 시간이 SLO를 위반하면 먼저 서빙 인프라와 최근 배포를 확인한다.

• 입력 데이터 스키마가 깨지면 재학습보다 데이터 파이프라인 조사를 우선한다.

• 예측 분포가 급변했지만 성능 라벨이 없으면 샘플링하여 수동 라벨링을 요청한다.

• 라벨 기반 성능이 기준 이하로 떨어지면 재학습 파이프라인을 실행한다.

• 새 모델이 기존 모델보다 주요 지표에서 좋지 않으면 배포하지 않는다.

• 신규 모델 배포 후 비즈니스 KPI가 악화되면 카나리아 비율을 줄이거나 롤백한다.

이 규칙이 다음 장에서 다룰 장애 대응과 비용 관리의 출발점이 된다.

흔한 실수와 오류 분석

첫 번째 실수는 인프라 지표만 보는 것이다. CPU와 오류율이 정상이어도 모델 품질은 나빠질 수 있다.

두 번째 실수는 정확도만 보는 것이다. 정답 라벨이 늦게 들어오는 서비스에서는 정확도 대시보드가 항상 과거를 보여준다. 프록시 지표와 입력·예측 분포를 함께 봐야 한다.

세 번째 실수는 모든 드리프트를 재학습으로 해결하려는 것이다. 스키마 변경, 단위 변경, 결측치 증가, 피처 계산 오류는 재학습 문제가 아니라 데이터 파이프라인 문제다. 먼저 원인을 찾아야 한다.

네 번째 실수는 알림을 너무 많이 만드는 것이다. 중요하지 않은 알림이 많으면 운영자는 결국 알림을 무시한다. 알림은 "사람이 행동해야 하는 경우"에만 보낸다. 나머지는 대시보드나 주간 리포트로 충분하다.

다섯 번째 실수는 비즈니스 KPI를 늦게 붙이는 것이다. 모델 개발이 끝난 뒤에야 전환율이나 매출 지표를 연결하면 모델이 실제로 도움이 되는지 판단하기 어렵다. 성공 기준은 프로젝트 초기에 정의해야 한다.

요약

• 모델은 배포 후에도 데이터, 사용자 행동, 시장 변화 때문에 조용히 나빠질 수 있다.

• 모니터링은 인프라, 서비스, 모델, 비즈니스 지표를 함께 봐야 한다.

• 정답 라벨이 늦게 들어오면 프록시 지표와 비즈니스 KPI를 함께 추적한다.

• 데이터 드리프트는 입력 분포 변화, 예측 드리프트는 출력 분포 변화, 개념 드리프트는 입력과 정답 관계 변화다.

• 통계 기반 드리프트 탐지는 유용하지만 성능 저하를 자동으로 증명하지는 않는다.

• 관측성 체계는 로그, 메트릭, 트레이스, 대시보드, 알림, SLO를 연결해 운영자가 행동할 수 있게 만들어야 한다.

• 모니터링 결과는 재학습, 롤백, 데이터 조사, 임계값 조정으로 이어지는 피드백 루프가 되어야 한다.

퀴즈

1. p95 지연 시간은 무엇을 의미하는가?

2. 데이터 드리프트와 개념 드리프트의 차이를 예시로 설명하라.

3. 정답 라벨이 30일 뒤에 들어오는 서비스에서 바로 정확도를 모니터링하기 어려운 이유는 무엇인가?

4. 입력 분포가 변했다는 신호가 나왔을 때 곧바로 재학습하면 위험한 이유는 무엇인가?

5. 모델 지표가 좋아도 비즈니스 지표가 나빠질 수 있는 이유를 설명하라.

체크리스트

• 인프라 지표와 서비스 지표를 분리해 정의했다.

• QPS, 오류율, p95 지연 시간의 기준선을 정했다.

• 모델 입력 분포와 예측 분포를 저장하고 비교할 수 있다.

• 라벨 지연 상황에서 사용할 프록시 지표를 정했다.

• 모델 지표와 비즈니스 KPI의 연결 관계를 문서화했다.

• 드리프트 알림 발생 시 조사 절차가 있다.

• 재학습, 롤백, 데이터 조사, 임계값 조정 기준이 있다.

• 알림마다 담당자와 기대 행동이 명확하다.

• 모델 버전, 데이터 버전, 기준선 통계를 함께 보관한다.

다음 장 연결

이번 장에서는 모델이 운영 중에 나빠지는 신호를 어떻게 볼지 배웠다. 하지만 신호를 보는 것만으로는 충분하지 않다. 알림이 울렸을 때 누가 대응할지, 어떤 순서로 원인을 좁힐지, 롤백할지 재학습할지, 비용 폭증은 어떻게 막을지 결정해야 한다.

다음 장에서는 장애 대응과 비용 관리를 다룬다. 모니터링이 "눈"이라면, 장애 대응과 비용 관리는 "손과 발"이다. 운영자는 문제를 발견하는 데서 멈추지 않고, 안정성과 비용 사이에서 현실적인 결정을 내려야 한다.

참고

¹IBM, 모델 드리프트란 무엇인가요?

²Google Developers, ML 프로젝트의 성공 측정항목

³AWS Prescriptive Guidance, Detecting drift in production applications