대부분의 AI/ML 튜토리얼은 모델을 학습시키는 단계에서 끝납니다.

실제 시스템은 그 이후부터 시작됩니다.

프로덕션 (Production) 환경에서 가장 어려운 문제는 모델링이 아닙니다. 바로 다음과 같은 것들입니다:

• 데이터 품질 드리프트 (Data quality drift)
• 평가 신뢰성 (Evaluation reliability)
• 배포 안전성 (Deployment safety)
• 모니터링 실패 모드 (Monitoring failure modes)
• 지속적 개선 루프 (Continuous improvement loops)

이 글에서는 실제 프로덕션 엔지니어링 관행을 기반으로 한 **AI/ML 시스템을 위한 실용적인 골든 파이프라인 (Golden Pipeline)**을 분석합니다.

1. 골든 파이프라인 (엔드 투 엔드 뷰)

실제 프로덕션 ML/AI 시스템은 다음과 같은 모습입니다:

데이터 수집 (Data Ingestion) → 검증 (Validation) → 피처 엔지니어링 (Feature Engineering) → 학습 (Training) →
평가 (Evaluation) → 모델 레지스트리 (Model Registry) → 배포 (Deployment) →
섀도 테스트 (Shadow Testing) → A/B 테스트 (A/B Testing) → 모니터링 (Monitoring) → 피드백 루프 (Feedback Loop)

각 단계는 독립적으로 버전이 관리되며 테스트가 가능해야 합니다.

2. 데이터 수집 계층 (Data Ingestion Layer)

핵심 원칙:

원시 데이터 (Raw data)를 절대 신뢰하지 마세요.

베스트 프랙티스 (Best Practices):

• 스트리밍 수집 (Streaming ingestion) 사용 (Kafka / Kinesis / PubSub)
• 원시 데이터와 처리된 데이터를 분리하여 저장
• 수집 시점에 스키마 검증 (Schema validation) 강제
• 전체 데이터 리니지 (Data lineage) 추적

흔한 실패 원인:

대부분의 ML 실패는 모델의 실패가 아니라, 데이터 파이프라인의 실패입니다.

3. 데이터 검증 계층 (Data Validation Layer)

학습 전 단계:

• 스키마 검증
• 결측치 (Missing values) 확인
• 이상치 (Anomalies) 탐지
• 타입 일관성 (Type consistency) 보장

권장 도구:

• Great Expectations
• Pandera
• Pydantic (Python 시스템에서 매우 효과적)

예시:

from pydantic import BaseModel

class Transaction(BaseModel):
...

4. 피처 엔지니어링 계층 (Feature Engineering Layer)

=============================

규칙:

피처 (Feature)를 재현할 수 없다면 → 그것은 존재하지 않는 것입니다.

베스트 프랙티스 (Best Practices):

• 피처 파이프라인을 결정론적 (Deterministic)으로 만드세요
• 학습 중 인라인 피처 계산 (Inline feature computation)을 피하세요
• 가능한 경우 피처 스토어 (Feature stores)를 사용하세요:
  • Feast
  • Tecton

5. 학습 파이프라인 (Training Pipeline)

=====================

원칙:

• 학습은 상태가 없어야 합니다 (Stateless)
• 모든 실행은 재현 가능해야 합니다 (Reproducible)
• 모든 하이퍼파라미터 (Hyperparameters)를 기록하세요
• 데이터셋의 버전을 관리하세요

도구:

• MLflow

• Weights & Biases

• DVC

• Hydra

6. Evaluation Layer (평가 레이어) (Critical (중요))

===============================

이곳은 대부분의 시스템이 실패하는 지점입니다.

단일 지표(Single metric)에 의존하지 마세요.

계층적 평가(Layered evaluation)를 사용하세요:

1. Exact Metrics (정확도 지표)

• Accuracy (정확도)

• Precision / Recall (정밀도 / 재현율)

• F1

2. Task-Specific Metrics (작업 특화 지표)

• Exact match (정확한 일치)

• Numeric tolerance (수치 허용 오차) (금융 시스템에서 중요)

• Structured output validation (구조화된 출력 검증)

3. LLM-Based Evaluation (LLM 기반 평가) (해당하는 경우)

• Pairwise comparison (쌍별 비교)

• Rubric scoring (루브릭 점수 산정)

• LLM-as-judge (LLM을 판사로 활용) (신중하게 보정됨)

Key Insight (핵심 통찰):

실제 환경의 시스템에서 Exact match는 종종 틀린(WRONG) 판단이 될 수 있습니다.

예시:

• 정답(Gold): -32%

• 예측(Prediction): -32.82%

이는 허용 오차(Tolerance) 규칙 하에 정답으로 간주되어야 합니다.

7. Model Registry (모델 레지스트리)

==================

모델을 직접 배포하지 마세요.

모델 레지스트리(Model registry)를 사용하세요:

• MLflow Model Registry

• SageMaker Registry

• Custom versioned storage (S3/GCS) (사용자 정의 버전 관리 저장소)

저장 항목:

• Model version (모델 버전)

• Dataset version (데이터셋 버전)

• Metrics (지표)

• Git commit hash (Git 커밋 해시)

• Config snapshot (설정 스냅샷)

8. Deployment Strategies (배포 전략)

=========================

Option 1: Direct deployment (직접 배포)

• Risky (위험함)

• No rollback (롤백 불가)

Option 2: Blue-Green Deployment (블루-그린 배포)

• Two environments (두 개의 환경)

• Instant rollback possible (즉각적인 롤백 가능)

Option 3: Canary Deployment (카나리 배포) (Best Practice (권장 사항))

• Deploy to small % of traffic (트래픽의 적은 비율에 배포)

• Gradually scale (점진적으로 확장)

• Monitor closely (면밀히 모니터링)

9. Shadow Mode (섀도 모드) (Highly Underrated (매우 과소평가됨))

===================================

새 모델을 프로덕션 환경과 병렬로 실행하세요:

• No user impact (사용자 영향 없음)

• Compare outputs silently (조용히 출력값 비교)

• Detect silent failures (잠재적 실패 감지)

Why it matters (중요한 이유):

• Prevents production incidents (프로덕션 장애 방지)

• Detects drift early (드리프트 조기 감지)

• Validates behavior safely (안전하게 동작 검증)

10. A/B Testing (A/B 테스트)

================

섀도 검증(Shadow validation) 이후:

• Split traffic between models (모델 간 트래픽 분할)

• Measure real impact (실제 영향 측정)

Metrics (지표):

• 정확도 프록시 (Accuracy proxies)

• 지연 시간 (Latency)

• 사용자 참여도 (User engagement)

• 비즈니스 KPI (Business KPIs)

11. 모니터링 (Monitoring)

===============

모니터링을 하지 않는다면, 당신의 모델은 이미 고장 난 상태입니다.

모니터링 대상:

• 데이터 드리프트 (Data drift)

• 예측 드리프트 (Prediction drift)

• 지연 시간 (Latency)

• 에러율 (Error rates)

• 신뢰도 분포 (Confidence distributions)

도구 (Tools):

• Prometheus

• Grafana

• Evidently AI

• Arize

12. 피드백 루프 (Feedback Loop)

==================

이곳이 바로 프로덕션 ML 시스템이 개선되는 지점입니다.

출처:

• 사용자 수정 (User corrections)

• 휴먼 라벨링 (Human labeling)

• 암시적 피드백 (Implicit feedback) (클릭, 편집)

이것은 향후의 학습 데이터 (Training data)가 됩니다.

13. 대부분의 엔지니어가 놓치는 것들

=============================

• 모든 것은 버전 관리 (Versioned) 되어야 합니다

• 모델은 실패할 것이라고 가정하십시오

• 항상 롤백 전략 (Rollback strategy)을 갖추십시오

• 데이터가 모델보다 더 중요합니다

• 평가는 일급 시민 (First-class) 시스템이어야 합니다

14. 최종 요약 (Final Takeaway)

===================

프로덕션 AI 시스템은 다음과 같은 것이 '아닙니다':

모델 학습 (Model training) + 배포 (Deployment)

프로덕션 AI 시스템은 다음과 같습니다:

데이터 (Data) → 학습 (Training) → 평가 (Evaluation) → 배포 (Deployment) → 모니터링 (Monitoring) → 피드백 (Feedback)의 연속적인 루프

모델은 시스템의 단지 한 부분일 뿐입니다.

파이프라인 (Pipeline)이 곧 제품입니다.

만약 당신이 이것을 구축하고 있다면

단순하게 시작하십시오:

• 엄격한 데이터 검증 (Data validation)을 가장 먼저 추가하십시오
• 모델을 개선하기 전에 평가 (Evaluation) 체계를 구축하십시오
• 섀도 모드 (Shadow mode)를 조기에 도입하십시오
• 첫날부터 모든 것을 로그 (Log)로 남기십시오
• 항상 실패를 고려하여 설계하십시오