데이터 사이언티스트가 노트북에서 0.94 정확도의 모델을 만들어 자랑한다. 그런데 그 모델이 실제 사용자 트래픽을 받기까지는 보통 몇 달이 걸리고, 운영에 올라간 뒤에도 절반은 조용히 망가진다. 이 간극을 메우는 사람이 ML 엔지니어다. MLA-C01(AWS Certified Machine Learning Engineer – Associate)은 바로 이 "노트북에서 프로덕션까지"를 AWS 위에서 어떻게 다루는지를 묻는 자격증이다.
오늘은 ML 수명주기 전체 그림을 그리고, 그 안에서 ML 엔지니어가 데이터 사이언티스트·DevOps 엔지니어와 어떻게 역할이 갈리는지, 그리고 시험이 묻는 4개 도메인이 이 수명주기의 어느 단계에 대응하는지를 본다.
전통적인 소프트웨어는 "코드를 짜면 동작이 정해진다". ML은 다르다. 동작이 데이터에서 학습된다. 그래서 수명주기에 "데이터"와 "재학습"이라는 축이 추가된다. 큰 그림은 다음 5단계다.
1. 데이터 (Data) : 수집 → 정제 → 라벨링 → 피처 엔지니어링
2. 학습 (Train) : 알고리즘 선택 → 학습 → 하이퍼파라미터 튜닝
3. 평가 (Evaluate) : 오프라인 지표 → 비즈니스 지표 → 편향 점검
4. 배포 (Deploy) : 엔드포인트/배치 → A/B → 카나리
5. 모니터링 (Monitor) : 데이터 드리프트 → 성능 저하 → 재학습 트리거
핵심은 이게 **선형이 아니라 순환(loop)**이라는 점이다. 5번 모니터링에서 드리프트가 잡히면 1번으로 돌아간다. 소프트웨어 엔지니어가 익숙한 CI/CD에 "데이터"와 "모델"이라는 두 가지가 추가되면서 MLOps라는 분야가 생겼다.
💡 관련 이론: Google이 2015년에 발표한 논문 "Hidden Technical Debt in Machine Learning Systems"의 핵심 주장이 이것이다. 실제 ML 시스템에서 ML 코드(모델 학습)는 전체 코드베이스의 5% 미만이고, 나머지 95%는 데이터 수집·검증·서빙·모니터링·인프라다. MLA-C01이 SageMaker 알고리즘 암기가 아니라 데이터 파이프라인·배포·운영을 비중 있게 묻는 이유가 여기 있다.
세 역할은 겹치지만 무게중심이 다르다. 시험은 "ML 엔지니어 관점"을 묻기 때문에 이 경계를 분명히 해두는 게 중요하다.
| 역할 | 무게중심 | 대표 산출물 |
|---|---|---|
| 데이터 사이언티스트 | 모델 성능, 실험 | 노트북, 논문, 가설 검증 |
| ML 엔지니어 | 재현성·확장성·운영화 | 학습 파이프라인, 추론 엔드포인트, 모니터링 |
| DevOps/플랫폼 | 인프라, CI/CD | IaC, 클러스터, 네트워크 |
데이터 사이언티스트가 "이 모델이 좋다"를 증명한다면, ML 엔지니어는 "이 모델을 매주 자동으로 재학습하고, 트래픽을 안전하게 받고, 망가지면 알람이 오게" 만든다. 같은 모델이라도 ML 엔지니어는 학습을 재현 가능하게 코드로 박고, 데이터 버전을 고정하고, 추론 비용을 따진다.
# 데이터 사이언티스트 스타일: 노트북에서 즉흥적으로
model.fit(X_train, y_train) # 어떤 데이터였는지 기록 없음
preds = model.predict(X_test) # 재현 불가능
# ML 엔지니어 스타일: 재현 가능한 파이프라인으로
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
Google의 "Hidden Technical Debt in ML Systems" 논문이 강조한 핵심으로, MLA-C01 시험 구성에도 반영된 사실은?
문제 2
데이터 사이언티스트가 노트북에서 만든 0.94 정확도 모델을 ML 엔지니어가 프로덕션화할 때 가장 먼저 확보해야 할 것은?
문제 3
오프라인 평가에서 정확도가 향상된 추천 모델을 배포했더니 사용자 체류 시간이 오히려 줄었다. ML 엔지니어가 이를 사전에 감지하기 위한 가장 적절한 방법은?
문제 4
코로나 초기에 많은 수요 예측 모델이 무너진 현상을 가장 정확히 설명하는 용어는?
문제 5
MLA-C01의 4개 도메인 중 합쳐서 가장 큰 비중(절반 이상)을 차지하는 두 영역은?
위 두 코드의 차이가 ML 엔지니어링의 본질이다. 입력 데이터 버전(v3)·하이퍼파라미터·인스턴스 타입이 코드에 명시돼 있어서, 6개월 뒤 누구든 같은 모델을 재현할 수 있다.
💡 관련 이론: 재현성(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 버전이다.
🔍 더 깊이: 오프라인 지표(accuracy, AUC)는 과거 데이터에 대한 모델 성능이고, 온라인 지표(클릭률, 전환율, 매출)는 실제 사용자 행동의 결과다. 둘이 어긋나는 대표 원인은 ① 학습 데이터와 운영 데이터의 분포 차이(distribution shift), ② 모델 출력이 사용자 행동을 바꿔 데이터 분포 자체를 바꾸는 피드백 루프다. ML 엔지니어는 오프라인 지표를 게이트로, 온라인 지표를 최종 판정으로 쓴다.
소프트웨어는 배포하면 그대로지만, 모델은 세상이 변하면 조용히 틀려진다. 코로나 이전 데이터로 학습한 수요 예측 모델이 2020년에 무용지물이 된 게 대표 사례다. 이걸 모델 드리프트라 부르고 두 종류가 있다.
AWS는 SageMaker Model Monitor로 운영 중인 엔드포인트의 입력/출력을 캡처해 학습 시점 baseline과 비교하고, 드리프트가 임계치를 넘으면 CloudWatch 알람을 발생시킨다. 알람은 재학습 파이프라인(EventBridge → Pipelines)을 트리거할 수 있다.
📚 사례: 2020년 코로나 초기, 많은 기업의 수요 예측·추천·이상거래 탐지 모델이 동시에 무너졌다. 사람의 행동 패턴이 급변하면서 학습 데이터의 분포와 운영 데이터의 분포가 완전히 달라진 전형적인 데이터 드리프트였다. 이 사건 이후 "모델은 배포로 끝이 아니라 모니터링과 재학습이 본체"라는 인식이 산업 전반에 자리잡았다.
시험은 이 수명주기를 4개 도메인으로 쪼개서 묻는다. 각 도메인이 수명주기의 어느 단계에 대응하는지 매핑해두면 공부 방향이 잡힌다.
| 도메인 | 비중 | 수명주기 대응 | 핵심 키워드 |
|---|---|---|---|
| 1. 데이터 준비 (Data Prep) | 28% | 데이터 | S3, Glue, Feature Store, 데이터 라벨링 |
| 2. 모델 개발 (Model Dev) | 26% | 학습·평가 | 빌트인 알고리즘, 튜닝, 평가 지표, 편향 |
| 3. 배포·오케스트레이션 (Deploy) | 22% | 배포 | 엔드포인트, 배치, Pipelines, CI/CD |
| 4. 모니터링·유지보수·보안 (Monitor) | 24% | 모니터링 | Model Monitor, CloudWatch, IAM, KMS |
SAA가 "어떻게 설계할 것인가"를, DVA가 "어떻게 코드로 배포할 것인가"를 묻는다면, MLA는 "ML 워크로드를 AWS 위에서 어떻게 준비·학습·배포·운영할 것인가"를 묻는다. 4개 도메인 중 데이터 준비와 모니터링이 절반(52%)을 차지한다는 점이 중요하다. 모델 알고리즘 암기보다 데이터 파이프라인과 운영이 합격을 가른다.
오늘 본 그림은 두 가지다. 첫째, ML 수명주기는 데이터 → 학습 → 평가 → 배포 → 모니터링의 순환 루프이고, ML 코드 자체는 전체의 5%뿐이다. 둘째, ML 엔지니어의 역할은 데이터 사이언티스트의 실험을 재현 가능하고 확장 가능하며 운영 가능한 시스템으로 만드는 것이다.
다음 글에서는 이 수명주기의 "학습" 단계로 들어가, 풀려는 문제가 지도/비지도/강화 중 무엇인지, 분류·회귀·군집을 어떻게 구분하고 무슨 지표로 평가하는지를 본다.