기준: MLA-C01 시험 가이드오류 제보

MLA-C01· AssociateWeek 8 · Day 5읽기 약 12분

핵심 정리

Week 8의 뼈대는 닫힌 루프 — 감지(드리프트·성능·시스템) → 알람 → 재학습 → 안전한 재배포 → 다시 감지.
모니터 선택은 라벨 유무로 갈린다. 라벨 있음 → 모델 품질, 없음 → 데이터 품질·피처 기여도.
모델 성능 저하(정확도)와 시스템 성능 저하(지연·오류)는 다른 도구다 — Model Quality Monitor vs CloudWatch.
오류율 급증 조사는 4XX(클라이언트) / 5XX(서버) 구분이 첫 단계, 구간별 지연 특정은 X-Ray.
재배포는 위험 사다리 — 섀도(영향 0) → A/B·카나리(소수 노출) → Blue/Green(자동 롤백 필수).

Day 5 - Week 8 종합: ML 솔루션 모니터링·유지보수 복습

Week 8 한 장 요약

Week 8은 "배포 이후의 삶"을 다뤘다. 모델은 배포 순간 가치를 만들기 시작하지만, 동시에 세상과 어긋나기 시작한다. 데이터가 변하고, 편향이 생기고, 시스템이 느려지고, 성능이 떨어진다. 네 글이 하나의 루프로 이어진다.

              ┌───────────────── 운영 중인 엔드포인트 ─────────────────┐
              │                                                     │
   ┌──────────┴──────────┐                 ┌────────────────────┐   │
   │ Day 1~2  모델이 옳은가  │                 │ Day 3  시스템이 건강한가 │   │
   │  데이터 품질 (Deequ)    │                 │  ModelLatency        │   │
   │  모델 품질 (GT 필요)    │                 │  OverheadLatency     │   │
   │  편향 드리프트 (Clarify) │                 │  4XX / 5XX Errors    │   │
   │  기여도 드리프트 (SHAP)  │                 │  CPU/Mem/GPU 사용률   │   │
   └──────────┬──────────┘                 └──────────┬─────────┘   │
              │                                       │             │
              └───────────┬───────────────────────────┘             │
                          ▼                                         │
                 CloudWatch 지표 · 알람                               │
                          │                                         │
        ┌─────────────────┴──────────────────┐                      │
        ▼                                    ▼                      │
  Auto Scaling / 운영 조치           EventBridge · Lambda             │
  (지연·오류 대응)                          │                         │
                                           ▼                         │
                              Day 4  SageMaker Pipelines 재학습       │
                                     → ConditionStep → Registry      │
                                     → 섀도 / A/B / 블루·그린 재배포 ───┘

1. Model Monitor 네 모니터 (Day 1~2)

모든 모니터링은 Data Capture(요청·응답을 S3에 저장)에서 시작하고, 베이스라인(정상의 기준)을 만든 뒤 cron 스케줄로 Processing Job을 띄워 비교한다.

모니터	감시 대상	도구	라벨 필요
데이터 품질	입력 피처 분포 통계(데이터 드리프트)	Model Monitor(Deequ)	불필요
모델 품질	예측 성능 지표(정확도·F1)	Model Monitor	필요(ground truth)
편향 드리프트	그룹 간 예측 편향(공정성)	Clarify	일부 불필요
피처 기여도 드리프트	피처 중요도(SHAP) 변화	Clarify	불필요

같은 표를 "언제 울리나"로 다시 보면 선택이 더 선명해진다.

모니터	감지 속도	잡아내는 사고	못 잡는 것
데이터 품질	즉시(다음 주기)	스키마 깨짐·결측 폭증·신규 범주·분포 이동	분포는 그대로인데 관계가 변한 경우
모델 품질	라벨이 모인 뒤	실제 정확도 하락(개념 드리프트의 결과)	라벨이 없으면 아예 계산 불가
편향 드리프트	즉시~라벨 필요 지표는 지연	특정 그룹에 불리해지는 변화	전체 성능 저하 자체
피처 기여도 드리프트	즉시	모델이 의존하는 피처가 바뀜(조기 경보)	성능이 실제로 얼마나 나빠졌는지

💡 관련 이론: 드리프트의 핵심 구분 — 데이터 드리프트(covariate shift)는 입력 X의 분포 변화(데이터 품질 모니터), 개념 드리프트(concept drift)는 X와 Y의 관계 변화(모델 품질 모니터가 성능 저하로 포착). 라벨을 즉시 얻을 수 없으면 모델 품질은 불가능하므로 데이터 품질이나 피처 기여도 드리프트로 우회해 조기 경보를 얻는다. 이 "라벨 유무 → 모니터 선택" 논리가 Week 8 객관식에서 답을 가르는 기준이다.

2. 운영 모니터링: CloudWatch와 X-Ray (Day 3)

모델이 옳은가와 별개로 시스템이 건강한가를 본다. 관측성의 세 기둥: 메트릭(CloudWatch Metrics)·로그(CloudWatch Logs)·트레이스(X-Ray).

핵심 지표: ModelLatency·OverheadLatency(지연), Invocations(호출량), 4XX/5XXErrors(오류), CPU/Memory/GPUUtilization(자원).
4XX = 클라이언트 오류(잘못된 입력), 5XX = 서버 오류(컨테이너 충돌·자원 부족). 오류 추적의 첫 단계.
CloudWatch Alarm: 임계치 위반 시 SNS·Auto Scaling·Lambda 발동. EvaluationPeriods로 오탐 감소.
트래픽 변동 대응은 단순 알람이 아니라 Application Auto Scaling.

지연 지표는 어느 쪽이 튀었는지로 원인이 갈린다.

관측된 조합	해석	다음 행동
전체 지연 ↑, `ModelLatency` 정상	모델 밖(앞단 Lambda·네트워크·외부 API)이 병목	X-Ray로 구간 특정
`ModelLatency` ↑	모델 연산·인스턴스 부하	인스턴스 상향·증설, 모델 경량화
`OverheadLatency` ↑	페이로드·요청 처리 부가 비용	페이로드 축소, 형식 단순화
`5XXErrors` ↑ + `MemoryUtilization` ↑	컨테이너 OOM·자원 부족	메모리 큰 타입, 배치 크기 축소
`4XXErrors` ↑	호출 측 입력·인증 문제	클라이언트 검증, 스키마 문서화

# 운영 지표 알람 + 모델 모니터 지표를 한 대시보드로 모으는 것이 운영 베스트프랙티스
# ModelLatency 급증 → 인스턴스 부하, OverheadLatency 급증 → 요청 처리/페이로드 문제
# 전체 지연만 늘고 ModelLatency 정상 → X-Ray로 앞단(Lambda/네트워크) 병목 추적

⚠️ 함정: "성능 저하"라는 말이 모호하다. 모델 성능 저하(정확도 하락)는 Model Quality Monitor, 시스템 성능 저하(지연·오류)는 CloudWatch 운영 지표다. 문제 문장에서 "정확도/예측 품질"인지 "지연/오류/자원"인지를 구분해 도구를 골라야 한다.

3. 재학습·재배포 루프 (Day 4)

감지가 끝이 아니다. 대응이 자동화돼야 성숙한 운영이다.

자동화 체인:

Model Monitor 위반 → CloudWatch Alarm
→ EventBridge/Lambda로 SageMaker Pipeline 트리거
→ 최신 데이터로 재학습 → 평가
→ ConditionStep으로 기준 통과 시에만 Model Registry 등록(회귀 방지)
→ 안전한 재배포

재배포 전략 비교:

전략	사용자 영향	용도
섀도(Shadow)	0 (응답 기록만, 사용자에겐 안 감)	운영 트래픽으로 무위험 기술 검증
A/B(배리언트 가중치)	일부 (새 모델 응답이 실제로 나감)	점진 롤아웃, 비즈니스 성과 비교
Blue/Green·카나리	점진 전환 + 자동 롤백	안전한 전면 교체

재학습 트리거도 세 가지를 비교해 고른다.

트리거	비용	반응 속도	대표 시나리오 문구
드리프트 기반	낮음(변화 시에만)	빠름	"불필요한 재학습 비용을 줄이면서"
성능 기반	중간	라벨 대기만큼 지연	"정확도가 기준 아래로 떨어지면"
일정 기반	높음(항상 실행)	주기만큼 지연	"매주 정기적으로"

위험 사다리로 외우면 쉽다. 가장 안전 = 섀도(사용자 0 영향) → 중간 = A/B/카나리(소수 사용자에 점진 노출) → 전면 = Blue/Green(가드레일·자동 롤백 필수). 재학습 트리거도 비용 관점에서 일정 기반보다 드리프트 기반 이벤트 트리거가 선호된다.

4. 시험 결정 포인트

Week 8 문제를 빠르게 푸는 분기들이다.

라벨이 즉시 있나? 있음 → 모델 품질. 없음 → 데이터 품질/피처 기여도.
공정성/그룹 편향? → Clarify Bias Drift. 피처 중요도? → Clarify Feature Attribution.
정확도 문제 vs 지연·오류 문제? → 전자 Model Quality Monitor, 후자 CloudWatch 운영 지표.
오류율 급증 원인? → 4XX(클라이언트) vs 5XX(서버) 먼저 구분.
사용자 영향 없이 새 모델 검증? → 섀도. 점진 전환·성과 비교? → A/B.
재학습 비용 절감? → 일정 기반 대신 드리프트 이벤트 트리거.
전체 지연은 느린데 모델은 정상? → X-Ray로 앞단 구간 추적.
트래픽 변동에 자동 대응? → 알람 알림이 아니라 Application Auto Scaling.
재학습한 모델이 나쁠 위험 차단? → ConditionStep + Model Registry 조건부 등록.

문제 문장의 키워드만 보고 바로 서비스로 넘어가는 매핑도 정리해 두면 빠르다.

문제에 나오는 표현	곧바로 떠올릴 답
"입력 분포가 학습 때와 달라졌는지"	데이터 품질 모니터
"정답 레이블을 얻을 수 없다"	데이터 품질 / 피처 기여도 드리프트
"정확도·F1이 떨어지는지"	모델 품질 모니터(+ ground truth 수집)
"특정 그룹에 불리해지는지"	Clarify 편향 드리프트
"어떤 피처에 의존하는지 변했는지"	Clarify 피처 기여도 드리프트(SHAP)
"요청·응답을 저장해야 한다"	Data Capture
"정상의 기준을 만든다"	베이스라인(statistics·constraints, Deequ)
"구간별 지연을 추적"	X-Ray
"오탐을 줄이고 싶다"	`EvaluationPeriods` 상향
"사용자 영향 없이 검증"	섀도 테스트
"가중치로 트래픽 분배"	프로덕션 배리언트 A/B
"자동 롤백"	배포 가드레일(블루·그린 + CloudWatch 알람)

5. 헷갈리는 쌍 정리

오답이 몰리는 지점은 대체로 다음 네 쌍이다.

헷갈리는 쌍	가르는 한마디
데이터 품질 vs 피처 기여도	"값이 변했다" vs "그 값이 예측에 미치는 영향이 변했다"
모델 품질 vs CloudWatch 지표	"예측이 틀린다" vs "응답이 느리다·실패한다"
A/B vs 섀도	새 모델 응답이 사용자에게 "간다" vs "안 간다"
알람 vs Auto Scaling	"사람에게 알린다" vs "인스턴스를 자동으로 늘린다"

6. 종합 진단표: 증상 → 원인 → 조치

증상	흔한 원인	조치
모니터링 결과가 계속 비어 있다	Data Capture 미설정 / 해당 주기 트래픽 0	캡처 S3 경로 확인, `sampling_percentage` 상향
모델 품질 모니터가 지표를 못 낸다	ground truth 미수집·`inference_id` 불일치	정답 업로드·ID 매칭 점검, 없으면 데이터 품질·기여도로 대체
드리프트 경보인데 모델 품질은 정상	성능에 영향 없는 피처의 분포 변화	즉시 재학습 대신 관찰, 중요 피처 위주 임계치 차등
재학습 후 성능이 더 나빠졌다	조건 없는 자동 등록·배포	ConditionStep으로 기준 통과 시에만 등록
5XX 급증 + 메모리 사용률 급증	컨테이너 OOM·자원 부족	메모리 큰 타입 교체, 인스턴스 증설, 배치 축소
트래픽 급증 때마다 지연 초과	Auto Scaling 미설정	Application Auto Scaling 타겟 추적 정책 등록
전면 교체 후 장애인데 롤백이 안 됐다	가드레일에 CloudWatch 알람 미연결	배포 정책에 롤백 알람 연결·사전 검증
모니터링·재학습 비용이 과도하다	매시간 스케줄 + 100% 캡처 + 일정 기반 재학습	주기 완화, 샘플링 하향, 이벤트 기반 트리거 전환

다음 주에는 ML 솔루션 모니터링·유지보수의 심화 — 보안·거버넌스, 비용 최적화, MLOps 파이프라인 고도화로 이어진다.

📖 용어

닫힌 루프(MLOps loop) : 감지 → 알람 → 재학습 → 재배포 → 다시 감지로 스스로 순환하는 운영 구조.
Data Capture : 엔드포인트 요청·응답을 S3에 저장하는 기능. 모든 모니터링의 원재료다.
베이스라인 : "정상"의 기준 스냅샷. 데이터 품질은 statistics.json·constraints.json으로 나온다.
데이터 드리프트 / 개념 드리프트 : 입력 X의 분포가 변함 / X와 Y의 관계 자체가 변함.
ground truth : 예측이 맞았는지 판정할 실제 정답. 모델 품질 모니터의 필수 재료이며 보통 뒤늦게 확정된다.
SHAP 기여도 드리프트 : 피처 중요도의 순위·크기가 베이스라인에서 벗어났는지 라벨 없이 보는 조기 경보 지표.
관측성의 세 기둥 : 메트릭·로그·트레이스. CloudWatch Metrics·CloudWatch Logs·X-Ray가 각각 대응한다.
Application Auto Scaling : 엔드포인트 인스턴스 수를 지표 기준으로 자동 증감하는 서비스. 트래픽 변동 대응의 정석.
ConditionStep : 평가 지표가 기준을 넘을 때만 모델을 등록·배포하도록 막는 파이프라인 조건 단계.
섀도 / A/B / 배포 가드레일 : 응답을 기록만 하는 무위험 검증 / 가중치로 일부 사용자에게 노출해 성과를 비교하는 검증 / 블루·그린·카나리 전환에 알람 기반 자동 롤백을 붙인 안전 배포 장치.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

운영 중 모델의 실제 정답 레이블을 수집할 방법이 전혀 없는 상황에서 모델 성능 저하를 조기에 감지하려 한다. 가장 적절한 조합은?

문제 2

어떤 엔드포인트에서 Invocation5XXErrors가 급증하고 ModelLatency도 함께 치솟았다. 가장 먼저 의심할 영역은?

문제 3

새 모델 버전을 운영 트래픽으로 검증하되 사용자에게는 절대 영향을 주지 않으면서, 충분히 검증되면 일부 사용자에게 점진적으로 노출하고 싶다. 단계적 전략으로 옳은 것은?

문제 4

Model Monitor가 드리프트를 감지한 뒤 자동으로 재학습을 시작하게 하려면, 빈칸의 서비스 조합으로 가장 적절한 것은? "Model Monitor 위반 → CloudWatch Alarm → ___ → SageMaker Pipeline 실행"

문제 5

재학습 파이프라인에서 새로 학습한 모델이 평가 기준에 미달했을 때 성능 회귀를 막는 표준 메커니즘은?

참고 공식 자료