Day 1 - ML 수명주기와 ML 엔지니어의 역할

📌 핵심 정리

• ML 수명주기는 데이터 → 학습 → 평가 → 배포 → 모니터링의 순환 루프다. 선형이 아니다.
• 실제 ML 시스템에서 모델 학습 코드는 5% 미만, 나머지 95%는 데이터·서빙·모니터링·인프라다.
• ML 엔지니어의 일 = 데이터 사이언티스트의 실험을 재현 가능·확장 가능·운영 가능하게 만드는 것.
• 오프라인 지표(정확도)와 온라인 지표(체류시간·매출)는 어긋날 수 있다 → A/B·카나리로 검증한다.
• MLA-C01 4개 도메인 중 데이터 준비(28%) + 모니터링(24%) = 52%. 알고리즘 암기가 아니라 운영이 합격을 가른다.

ML 수명주기: 노트북에서 프로덕션까지

데이터 사이언티스트가 노트북에서 만든 0.94 정확도 모델이 실제 트래픽을 받기까지는 보통 몇 달이 걸리고, 운영에 올라간 뒤에도 절반은 조용히 망가진다. 이 간극을 메우는 사람이 ML 엔지니어다.

전통적 소프트웨어는 코드를 짜면 동작이 정해진다. ML은 동작이 데이터에서 학습된다. 그래서 수명주기에 "데이터"와 "재학습"이라는 축이 추가된다.

        ┌──────────────────────────────────────────────────────┐
        │                                                      │
        v                                                      │
  ┌───────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   │
  │ 1. 데이터  │──>│ 2. 학습   │──>│ 3. 평가   │──>│ 4. 배포   │   │
  └───────────┘   └──────────┘   └──────────┘   └──────────┘   │
   수집·정제        알고리즘 선택    오프라인 지표    엔드포인트    │
   라벨링           하이퍼파라미터   비즈니스 지표    배치/카나리   │
   피처 엔지니어링   튜닝            편향 점검            │        │
                                                        v        │
                                                ┌──────────────┐ │
                                                │ 5. 모니터링   │─┘
                                                └──────────────┘
                                                 드리프트 감지
                                                 성능 저하 알람
                                                 재학습 트리거

핵심은 이게 **선형이 아니라 순환(loop)**이라는 점이다. 5번 모니터링에서 드리프트가 잡히면 1번으로 돌아간다. 소프트웨어 엔지니어가 익숙한 CI/CD에 "데이터"와 "모델"이 추가되면서 MLOps라는 분야가 생겼다.

각 단계가 어떤 AWS 서비스에 대응하는지 미리 매핑해두면 이후 주차가 훨씬 빠르다.

💡 관련 이론: Google이 2015년에 발표한 논문 "Hidden Technical Debt in Machine Learning Systems"의 핵심 주장이 이것이다. 실제 ML 시스템에서 ML 코드(모델 학습)는 전체 코드베이스의 5% 미만이고, 나머지 95%는 데이터 수집·검증·서빙·모니터링·인프라다. MLA-C01이 SageMaker 알고리즘 암기가 아니라 데이터 파이프라인·배포·운영을 비중 있게 묻는 이유가 여기 있다.

ML 엔지니어 vs 데이터 사이언티스트 vs DevOps

세 역할은 겹치지만 무게중심이 다르다. 시험은 "ML 엔지니어 관점"을 묻기 때문에 이 경계를 분명히 해두는 게 중요하다.

데이터 사이언티스트가 "이 모델이 좋다"를 증명한다면, ML 엔지니어는 "이 모델을 매주 자동으로 재학습하고, 트래픽을 안전하게 받고, 망가지면 알람이 오게" 만든다.

# 데이터 사이언티스트 스타일: 노트북에서 즉흥적으로
model.fit(X_train, y_train)        # 어떤 데이터였는지 기록 없음
preds = model.predict(X_test)      # 재현 불가능
 
# ML 엔지니어 스타일: 재현 가능한 파이프라인으로
import sagemaker
from sagemaker.estimator import Estimator
 
estimator = Estimator(
    image_uri=training_image,
    role=role,
    instance_count=1,
    instance_type="ml.m5.xlarge",
    hyperparameters={"num_round": 100, "max_depth": 5},
    output_path="s3://my-bucket/models/",   # 산출물 위치 고정
)
estimator.fit({"train": "s3://my-bucket/data/v3/train/"})  # 데이터 버전 고정

위 두 코드의 차이가 ML 엔지니어링의 본질이다. 입력 데이터 버전(v3)·하이퍼파라미터·인스턴스 타입이 코드에 명시돼 있어 6개월 뒤 누구든 같은 모델을 재현할 수 있다.

재현에 필요한 4요소 — 하나라도 빠지면 같은 모델이 안 나온다.

💡 관련 이론: 재현성(reproducibility)은 ML 엔지니어링의 1순위 원칙이다. 머신러닝 실험을 재현하려면 코드 버전만으로는 부족하고 ① 코드, ② 데이터 버전, ③ 하이퍼파라미터, ④ 환경(라이브러리 버전·랜덤 시드)까지 모두 고정해야 한다. SageMaker가 Experiments, Model Registry, lineage tracking 같은 기능을 제공하는 이유다.

오프라인 지표와 비즈니스 지표는 다르다

ML 엔지니어가 자주 부딪히는 함정 하나. 오프라인 평가에서 좋아진 모델이 실제 비즈니스 지표는 떨어뜨릴 수 있다. 추천 모델의 정확도가 올라갔는데 사용자 체류 시간은 줄어드는 식이다.

그래서 배포 단계에서 A/B 테스트가 필수다. SageMaker는 한 엔드포인트에 여러 모델 variant를 두고 트래픽을 분배할 수 있다.

from sagemaker.session import production_variant
 
variant_a = production_variant(
    model_name="model-v1", instance_type="ml.m5.large",
    initial_instance_count=1, variant_name="A", initial_weight=90,
)
variant_b = production_variant(
    model_name="model-v2", instance_type="ml.m5.large",
    initial_instance_count=1, variant_name="B", initial_weight=10,  # 10%만 신모델로
)

신모델에 트래픽 10%만 보내 실제 비즈니스 지표를 관찰하고, 안전하면 점진적으로 weight를 올린다. 이게 카나리 배포의 ML 버전이다.

🔍 더 깊이: 오프라인 지표와 온라인 지표가 어긋나는 대표 원인은 ① 학습 데이터와 운영 데이터의 분포 차이(distribution shift), ② 모델 출력이 사용자 행동을 바꿔 데이터 분포 자체를 바꾸는 피드백 루프다. ML 엔지니어는 오프라인 지표를 게이트로, 온라인 지표를 최종 판정으로 쓴다.

⚠️ 함정: "오프라인 지표가 올랐으니 전량 배포"는 전형적인 오답 유형이다. 지표가 올라도 소량 트래픽으로 먼저 검증하는 단계를 건너뛰면, 문제가 생겼을 때 전체 사용자가 영향을 받는다. 시험에서 "신모델의 위험을 최소화하며 실제 성능을 확인"이라는 조건이 보이면 트래픽 분할(variant weight)이 정답 방향이다.

모니터링: 모델은 출시 순간부터 늙는다

소프트웨어는 배포하면 그대로지만, 모델은 세상이 변하면 조용히 틀려진다. 이걸 모델 드리프트라 부르고 두 종류가 있다.

AWS는 SageMaker Model Monitor로 운영 중인 엔드포인트의 입력/출력을 캡처해 학습 시점 baseline과 비교하고, 드리프트가 임계치를 넘으면 CloudWatch 알람을 발생시킨다. 알람은 재학습 파이프라인(EventBridge → Pipelines)을 트리거할 수 있다.

[엔드포인트] ──데이터 캡처──> [S3]
                               │
                               v
                    [Model Monitor 스케줄]
                     baseline 통계와 비교
                               │
                    임계치 초과 │
                               v
                       [CloudWatch 알람]
                               │
                               v
                  [EventBridge] ──> [SageMaker Pipelines 재학습]

📚 사례: 2020년 코로나 초기, 많은 기업의 수요 예측·추천·이상거래 탐지 모델이 동시에 무너졌다. 사람의 행동 패턴이 급변하면서 학습 데이터의 분포와 운영 데이터의 분포가 완전히 달라진 전형적인 데이터 드리프트였다. 이 사건 이후 "모델은 배포로 끝이 아니라 모니터링과 재학습이 본체"라는 인식이 산업 전반에 자리잡았다.

MLA-C01의 4개 도메인

시험은 이 수명주기를 4개 도메인으로 쪼개서 묻는다. 각 도메인이 수명주기의 어느 단계에 대응하는지 매핑해두면 공부 방향이 잡힌다.

• SAA는 "어떻게 설계할 것인가", DVA는 "어떻게 코드로 배포할 것인가"를 묻는다.
• MLA는 "ML 워크로드를 AWS 위에서 어떻게 준비·학습·배포·운영할 것인가"를 묻는다.
• 데이터 준비 + 모니터링이 절반(52%)이다. 모델 알고리즘 암기보다 데이터 파이프라인과 운영이 합격을 가른다.

다음 글에서는 이 수명주기의 "학습" 단계로 들어가, 풀려는 문제가 지도/비지도/강화 중 무엇인지, 분류·회귀·군집을 어떻게 구분하고 무슨 지표로 평가하는지를 본다.

📖 용어

• ML 수명주기 : 데이터 준비부터 학습·평가·배포·모니터링까지 돌고 도는 ML 작업의 전체 흐름.
• MLOps : 소프트웨어의 CI/CD에 "데이터"와 "모델"을 얹어 ML 시스템을 자동·안정적으로 운영하는 분야.
• 재현성(reproducibility) : 같은 코드·데이터·설정·환경으로 다시 돌리면 같은 모델이 나오는 성질.
• 데이터 버전 고정 : 학습에 쓴 데이터가 무엇이었는지 경로·태그로 못박아 두는 것. s3://.../data/v3/ 같은 형태.
• 오프라인 지표 : 과거 데이터로 계산한 모델 성능. 정확도·AUC 등. 배포 전 통과 기준으로 쓴다.
• 온라인 지표 : 실제 서비스에서 사용자가 만든 결과. 클릭률·체류시간·매출 등.
• A/B 테스트 : 트래픽을 나눠 두 모델을 동시에 돌려 어느 쪽이 나은지 실제로 확인하는 방법.
• 카나리 배포 : 신버전에 트래픽을 아주 조금만 먼저 보내 이상이 없는지 살핀 뒤 비중을 올리는 배포 방식.
• 모델 드리프트 : 시간이 지나며 모델이 조용히 틀려지는 현상. 데이터 드리프트와 컨셉 드리프트로 나뉜다.
• Model Monitor : 운영 엔드포인트의 입출력을 캡처해 학습 시점 기준과 비교하고 이상 시 알람을 내는 SageMaker 기능.