Day 5 - Week 1 종합 — ML 기초·AWS 스택 복습

ML 수명주기: 전 과정 한눈에

MLA-C01은 단편 지식이 아니라 "이 상황엔 어느 단계의 어떤 도구를 쓰나"를 묻는다. 수명주기 위에 개념과 서비스를 얹어 외우는 것이 가장 효율적이다.

[1. 데이터 준비] → [2. 모델 개발] → [3. 배포·서빙] → [4. 모니터링·유지보수]
  수집/저장/변환     학습/튜닝/평가     엔드포인트 선택    드리프트/재학습
  (도메인 1, 28%)   (도메인 2, 26%)   (도메인 3, 22%)   (도메인 4, 24%)
        ↑                                                      |
        └──────────────── 재학습 트리거 ──────────────────────┘

핵심은 마지막 화살표다. 배포된 모델은 시간이 지나면 데이터 분포가 변해(drift) 성능이 떨어지고, 그러면 다시 데이터 준비 단계로 돌아간다. ML 엔지니어의 일은 이 순환을 자동화·안정화하는 것이다.

단계별로 이번 주에 배운 것을 한 표에 모으면 이렇다.

이 순환을 표준화한 것이 CRISP-DM(Cross-Industry Standard Process for Data Mining)이다. 1990년대 정립된 이 방법론은 비즈니스 이해 → 데이터 이해 → 데이터 준비 → 모델링 → 평가 → 배포의 6단계 반복 사이클을 정의한다. 현대 MLOps는 여기에 "배포 후 모니터링과 자동 재학습"을 강하게 결합한 형태다. 시험에서 "모델 성능이 시간이 지나며 저하된다"는 시나리오는 항상 이 순환의 모니터링·재학습 단계를 가리킨다.

문제 유형과 평가지표

모델이 푸는 문제가 무엇이냐에 따라 평가지표가 갈린다. 잘못된 지표를 고르면 "정확도 99%인데 쓸모없는 모델"을 만들게 된다.

학습 방식 구분도 다시 정리하면 다음과 같다.

• 지도학습: 정답(label)이 있는 데이터로 학습 → 분류·회귀
• 비지도학습: 정답 없이 구조를 찾음 → 군집·차원 축소·이상 탐지
• 강화학습: 보상으로 정책을 학습 → 순차적 의사결정

from sklearn.metrics import precision_score, recall_score, f1_score
 
# 불균형 데이터(사기 0.1%)에서 accuracy는 함정 — precision/recall을 본다
precision = precision_score(y_true, y_pred)   # 양성 예측 중 진짜 비율
recall = recall_score(y_true, y_pred)         # 실제 양성 중 잡아낸 비율
f1 = f1_score(y_true, y_pred)                 # 둘의 조화평균

지표를 고르는 판별표 — 상황을 보고 바로 지표를 짚는 연습이다.

Precision과 Recall의 트레이드오프는 비용 비대칭에서 비롯된다. 사기 탐지처럼 "놓치면 큰일"인 문제는 Recall(놓치지 않기)을, 스팸 필터처럼 "정상 메일을 막으면 곤란"한 문제는 Precision(오탐 줄이기)을 우선한다. 클래스가 극단적으로 불균형하면 Accuracy는 의미가 없다 — 전부 다수 클래스로 찍어도 99%가 나오기 때문이다. 그래서 불균형 문제의 종합 지표로 F1이나 AUC-PR을 쓴다.

⚠️ 함정: 회귀에서 RMSE와 MAE를 혼동하기 쉽다. RMSE는 큰 오차를 제곱해 더 무겁게 벌하므로 이상치에 민감하고, MAE는 모든 오차를 동등하게 보아 robust하다. "이상치가 많고 큰 오차를 특별히 막아야 한다"면 RMSE, "이상치 영향을 줄이고 싶다"면 MAE다.

SageMaker 핵심 기능 정리

이번 주 후반에 본 SageMaker는 ML 수명주기 전체를 덮는 도구 모음이다. 단계별로 다시 묶으면 이렇다.

학습이 일시적 컨테이너(끝나면 인스턴스 자동 종료, 스팟으로 비용 절감)에서 일어난다는 점, 추론 옵션이 트래픽 패턴으로 갈린다는 점이 시험 범위에 든다.

import sagemaker
from sagemaker.estimator import Estimator
 
session = sagemaker.Session()
role = sagemaker.get_execution_role()
 
# 빌트인 XGBoost로 테이블 데이터 분류 학습
estimator = Estimator(
    image_uri=sagemaker.image_uris.retrieve("xgboost", session.boto_region_name, "1.7-1"),
    role=role,
    instance_count=1,
    instance_type="ml.m5.xlarge",
    use_spot_instances=True,   # 학습 비용 절감
)
estimator.fit({"train": "s3://my-bucket/train/"})

추론 옵션 판별 한 줄 요약

빌트인 알고리즘이 안 맞으면 두 단계로 넓어진다. 스크립트 모드(AWS 관리 프레임워크 컨테이너 + 자체 학습 스크립트)로 TensorFlow·PyTorch 모델을 돌리거나, 특수 런타임이 필요하면 커스텀 컨테이너(직접 만든 Docker 이미지)로 간다. "빌트인 → 스크립트 모드 → 커스텀 컨테이너" 순으로 통제권이 커지고 부담도 커진다.

AWS AI 서비스: 학습 없이 쓰는 사전 학습 모델

모든 ML 문제를 직접 학습할 필요는 없다. AWS는 사전 학습된 관리형 AI 서비스를 API로 제공한다. "흔한 작업이고 빠르게 붙이고 싶다"면 이쪽이 정답이다.

시험에는 여러 AI 서비스를 조합하는 시나리오도 나온다.

판별 기준은 추상화 수준이다. AI 서비스(API 호출, 학습 불필요) → SageMaker(직접 학습·배포, 유연성) → EC2 직접 구축(최대 통제, 최대 부담). "흔한 문제 + 빠른 구현"이면 AI 서비스, "고유 데이터로 커스텀 모델"이면 SageMaker다.

이 계층 구조는 "build vs buy"의 클라우드 버전이다. AI 서비스는 AWS가 막대한 데이터로 미리 학습해둔 모델을 빌려 쓰는 것(buy)이고, SageMaker는 자체 데이터로 직접 만드는 것(build)이다. ML 엔지니어의 판단 포인트는 "내 문제가 일반적인가, 고유한가"다. 일반적 NLP·비전 작업은 AI 서비스가 더 빠르고 정확하며 운영 부담이 없지만, 도메인 특화 데이터(예: 의료 영상, 산업 결함)는 직접 학습이 필요하다.

Week 1 한 줄 체크리스트

시나리오로 Week 1 점검하기

시험은 개념을 따로 묻지 않고 상황에 얹어 묻는다. 이번 주 내용을 상황 → 판단 형태로 적용해 본다.

자주 헷갈리는 짝

⚠️ 함정: Week 1에서 틀리기 쉬운 지점은 "더 좋은 기술"을 고르는 습관이다. 시험은 요구사항을 만족하는 가장 단순하고 저렴한 선택을 정답으로 본다. 딥러닝이 필요 없는 문제에 딥러닝을, API 한 번이면 되는 작업에 커스텀 학습을 고르면 오답이다.

다음 주(Week 2)에는 수명주기의 첫 단계인 데이터 수집과 저장 — S3, Kinesis, Glue, Athena를 깊이 파고든다.

📖 용어

• CRISP-DM : 비즈니스 이해부터 배포까지 6단계를 반복하는 고전적 데이터마이닝 방법론. MLOps의 조상.
• 드리프트(drift) : 시간이 지나며 입력 분포나 정답 관계가 변해 모델 성능이 떨어지는 현상.
• 재학습 트리거 : 드리프트나 성능 저하가 감지됐을 때 자동으로 학습을 다시 돌리게 하는 장치.
• Macro-F1 : 다중 분류에서 클래스별 F1을 단순 평균한 값. 소수 클래스도 동등하게 반영한다.
• Silhouette 점수 : 군집이 얼마나 잘 뭉치고 서로 떨어졌는지 재는 지표. 정답이 없을 때 쓴다.
• R²(결정계수) : 모델이 데이터의 변동을 얼마나 설명하는지 0~1로 나타낸 회귀 지표.
• Automatic Model Tuning : 하이퍼파라미터 조합을 자동으로 탐색해 최적값을 찾아주는 SageMaker 기능.
• 파운데이션 모델 : 방대한 데이터로 미리 학습해 여러 작업에 두루 쓰는 대형 모델. Bedrock이 API로 제공한다.
• build vs buy : 직접 만들 것인가, 이미 있는 것을 사서 쓸 것인가의 판단. AI 서비스 vs SageMaker의 선택 축.
• 관리형 서비스 : 인프라 운영을 AWS가 대신 맡아주는 서비스. 통제권 일부를 내주는 대신 부담이 줄어든다.