근거는 있나요? — 프로덕션 ML 실패의 세 가지 균열
주피터 노트북에서 model.fit(X, y) 한 줄이면 끝나는 것처럼 보이는 머신러닝이, 배포 후 몇 주 만에 조용히 틀리기 시작합니다. 크래시가 아니라 '서서히 나빠지는' 예측—이것이 프로덕션 ML 시스템의 가장 위험한 실패 모드입니다. 최근 공유된 세 편의 엔지니어링 사례를 교차 분석하면, 모델 드리프트(drift), 재현성(reproducibility) 붕괴, 파이프라인 설계 결함이라는 세 갈래 균열이 하나의 구조적 문제로 수렴합니다.
균열 1: 드리프트 — PSI 0.15에서 12.08로, 분포는 말없이 이동한다
한 무료 드리프트 감지 API 프로젝트(tiamat.live/drift)가 흥미로운 숫자를 내놓았습니다. 평균 50, 표준편차 10인 정규분포(N(50,10)) 베이스라인에 동일 분포 샘플을 넣으면 PSI(Population Stability Index) 0.15로 '안전', 그러나 N(80,15)로 이동한 샘플에는 12.08로 즉시 경보가 뜹니다. 분리가 명확해 보이죠.
그런데 여기서 데이터 분석가로서 질문을 던져야 합니다. 베이스라인 샘플 사이즈가 20개 이상이면 충분한가요? PSI는 히스토그램 빈(bin) 기반 비교이므로 빈 수 대비 샘플이 적으면 분산이 커지고 false positive가 올라갑니다. 또한 이 API는 numeric, embedding, probability, text 네 가지 모델 타입에 각각 PSI·코사인 거리·KL 발산·어휘 z-score를 자동 매핑하는데, threshold 기본값이 공개되지 않았습니다. 임계치(threshold) 선정 근거 없이 alert: true/false만 받는 것은, 운영팀에 '왜 경보가 울렸는지' 설명할 수 없다는 뜻입니다. Precision-Recall 트레이드오프를 사용자가 조절할 수 없는 모니터링은, 결국 경보 피로(alert fatigue)로 귀결될 가능성이 높습니다.
균열 2: 노트북 환상 — 실행 순서가 만드는 '유령 상태'
'The Notebook Illusion'이라는 dev.to 글은 주피터 노트북의 네 가지 균열을 정리합니다: 실행 순서 비결정성, 숨겨진 상태(hidden state), 성능 드리프트, 재현성 붕괴. 이 중 가장 과소평가되는 것은 첫 번째입니다. 셀을 순서 없이, 여러 번 실행하면 변수가 예기치 않게 유지되고, 두 사람이 '같은 노트북'을 돌려도 다른 결과를 얻습니다. 이건 correlation 수준의 문제가 아니라 causation입니다 — 실행 순서 자체가 결과를 결정하니까요.
여기에 LSTM 구현 사례(velog)를 겹쳐 보면 문제가 더 선명해집니다. MyLSTMCell을 직접 nn.Linear로 쌓고 California Housing 데이터를 8 time-step 시퀀스로 변환해 학습하는 과정에서, random seed 미고정·GPU 메모리 누적·DataFrame 복사 같은 노트북 특유의 '상태 누수'가 발생하면 MAE와 R² 스코어가 실행마다 달라집니다. nn.LSTM 한 줄이면 되는 것을 직접 구현한 교육적 가치는 높지만, 그 결과를 '베이스라인 성능'으로 신뢰하는 순간 함정에 빠집니다. 실제 운영 환경에서도 이 성능이 나올까요?
균열 3: 파이프라인 — 프라이버시와 설명 가능성이 '정확도보다 먼저'
헬스케어 감정 분석 파이프라인 EADSS 사례는 '모델 정확도 최적화'가 프로덕션 설계의 1순위가 아닌 환경을 보여줍니다. PII(개인식별정보) 삭제를 저장 이전에 강제하고, 단일 감성 점수 대신 멀티라벨 감정 탐지로 전환하며, 순수 ML 대신 규칙+ML 하이브리드 결정 로직을 채택합니다. 규제 환경에서 '순수 end-to-end ML'이 실패하는 이유는 명확합니다: 재현 가능하고 감사 가능해야(auditable) 하기 때문입니다. 이 파이프라인은 7일·30일 롤링 윈도우로 감정 신호를 집계해 단일 데이터 포인트의 노이즈를 걸러내는데, 이는 앞서 본 드리프트 감지의 베이스라인 설정 문제와 정확히 같은 구조입니다 — 개별 샘플이 아니라 분포 수준에서 비교해야 의미 있는 신호가 나온다는 것.
Ablation study 관점에서 보면, EADSS가 설명 가능성(explainability)을 후순위가 아닌 엔지니어링 요구사항으로 격상시킨 결정이 핵심입니다. 경보 발생 시 지배적 감정 드라이버, 관련 토픽, 대표 익명화 텍스트를 함께 제시하고, 모델 버전과 추론 메타데이터를 로깅합니다. 이건 '좋은 관행'이 아니라 모니터링 파이프라인의 필수 컴포넌트입니다.
시사점: '노트북 → 프로덕션' 간극의 진짜 지표
세 사례를 종합하면 프로덕션 ML 실패를 예방하기 위해 추적해야 할 지표 계층이 드러납니다.
| 계층 | 추적 지표 | 노트북에서 보이는가? |
|---|---|---|
| 데이터 분포 | PSI, KL divergence, 코사인 거리 | ❌ 베이스라인 자체가 없음 |
| 실행 재현성 | 커널 재시작 후 동일 결과 여부, seed 고정 | ❌ 셀 순서 의존 |
| 파이프라인 거버넌스 | PII 삭제 시점, 모델 버전 로그, 결정 감사 추적 | ❌ 노트북 범위 밖 |
결국 문제는 모델 아키텍처(LSTM이든 Transformer든)가 아닙니다. 노트북이 압축한 복잡성을 프로덕션이 다시 풀어헤칠 때, 그 간극을 메울 지표와 파이프라인이 있느냐가 핵심입니다. 드리프트 감지 API가 curl 세 번으로 작동한다는 것은 진입 장벽을 낮춘 의미 있는 시도이지만, 샘플 사이즈·임계치·false positive rate에 대한 통계적 근거 없이 '경보 여부'만 반환한다면, 그것은 모니터링이 아니라 또 다른 형태의 환상일 수 있습니다.
프로덕션 ML의 성숙도는 모델의 F1-score가 아니라, 그 F1-score가 3개월 후에도 유지되는지 증명할 수 있는 인프라로 측정되어야 합니다. 노트북을 닫고 파이프라인을 열 때, 가장 먼저 물어야 할 질문은 여전히 같습니다: 근거는 있나요?