이번 주는 머신러닝의 기본 개념과 그것을 AWS에서 어떻게 구현하는지를 훑었다. 오늘은 흩어진 조각을 하나의 그림으로 묶는다. MLA-C01 시험은 단편 지식이 아니라 "이 상황엔 어느 단계의 어떤 도구를 쓰나"를 묻기 때문에, 수명주기 위에 개념과 서비스를 얹어 외우는 것이 가장 효율적이다.
오늘 복습할 네 축은 ① ML 수명주기, ② 문제 유형과 평가지표, ③ SageMaker 핵심 기능, ④ AWS AI 서비스다. 각 축을 "언제 무엇을 고르는가"의 판별 기준 중심으로 정리한다.
머신러닝 프로젝트는 한 번 학습하고 끝나는 게 아니라 순환한다. 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%인데 쓸모없는 모델"을 만들게 된다.
| 문제 유형 | 설명 | 대표 평가지표 |
|---|---|---|
| 이진 분류 | 둘 중 하나 (이탈/유지) | Precision, Recall, F1, AUC-ROC |
| 다중 분류 | 셋 이상 범주 | Accuracy, Macro-F1, 혼동행렬 |
| 회귀 | 연속값 예측 (가격) | RMSE, MAE, R² |
| 군집 | 비지도 그룹화 | Silhouette, Inertia |
지도학습/비지도학습/강화학습의 구분도 다시 정리하자. 지도학습은 정답(label)이 있는 데이터로 학습(분류·회귀), 비지도학습은 정답 없이 구조를 찾고(군집·차원 축소·이상 탐지), 강화학습은 보상으로 정책을 학습한다.
from sklearn.metrics import precision_score, recall_score, f1_score
# 불균형 데이터(사기 0.1%)에서 accuracy는 함정 — precision/recall을 본다
precision = precision_score(y_true, y_pred) # 양성 예측 중 진짜 비율
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
배포된 이탈 예측 모델의 정확도가 몇 달에 걸쳐 서서히 떨어지고 있다. 입력 데이터 분포가 학습 때와 달라진 것으로 보인다. ML 수명주기에서 이 문제가 해당하는 단계와 대응은?
문제 2
사기 거래 탐지 모델에서 사기는 전체의 0.1%다. 모델 평가지표로 가장 부적절한 것과 그 이유로 옳은 것은?
문제 3
콜센터 녹음 파일을 텍스트로 변환한 뒤 고객 불만의 감성을 분석하려 한다. 학습 없이 가장 빠르게 구현하는 조합은?
문제 4
회귀 모델 평가에서 큰 오차를 특별히 강하게 벌해 이상치를 민감하게 잡아내고 싶다. 적합한 지표는?
문제 5
"고유한 산업 결함 이미지 데이터로 커스텀 분류 모델을 학습해야 한다"는 요구가 있다. 추상화 계층에서 적합한 선택은?
💡 관련 이론: Precision과 Recall의 트레이드오프는 비용 비대칭에서 비롯된다. 사기 탐지처럼 "놓치면 큰일"인 문제는 Recall(놓치지 않기)을, 스팸 필터처럼 "정상 메일을 막으면 곤란"한 문제는 Precision(오탐 줄이기)을 우선한다. 클래스가 극단적으로 불균형하면 Accuracy는 의미가 없다 — 전부 다수 클래스로 찍어도 99%가 나오기 때문이다. 그래서 불균형 문제의 종합 지표로 F1이나 AUC-PR을 쓴다.
⚠️ 함정: 회귀에서 RMSE와 MAE를 혼동하지 말자. RMSE는 큰 오차를 제곱해 더 무겁게 벌하므로 이상치에 민감하고, MAE는 모든 오차를 동등하게 보아 robust하다. "이상치가 많고 큰 오차를 특별히 막아야 한다"면 RMSE, "이상치 영향을 줄이고 싶다"면 MAE다.
이번 주 후반에 본 SageMaker는 ML 수명주기 전체를 덮는 도구 모음이다. 단계별로 다시 묶으면 이렇다.
| 수명주기 단계 | SageMaker 기능 | 역할 |
|---|---|---|
| 작업 환경 | Studio (도메인·사용자 프로필) | 통합 IDE, 권한 분리 |
| 데이터 준비 | Data Wrangler, Feature Store | 시각적 변환, 특성 관리 |
| 학습 | Training Job, 빌트인 알고리즘 | 일시적 컨테이너 학습 |
| 튜닝 | Automatic Model Tuning | 하이퍼파라미터 최적화 |
| 배포 | 실시간/서버리스/배치/비동기 | 트래픽별 추론 옵션 |
| 운영 | Model Monitor, Pipelines | 드리프트 감지, 자동화 |
학습이 일시적 컨테이너(끝나면 인스턴스 자동 종료, 스팟으로 비용 절감)에서 일어난다는 점, 추론 옵션이 트래픽 패턴으로 갈린다는 점이 시험 단골이다.
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 프레임워크 컨테이너)나 커스텀 컨테이너로 간다.
모든 ML 문제를 직접 학습할 필요는 없다. AWS는 사전 학습된 관리형 AI 서비스를 API로 제공한다. "흔한 작업이고 빠르게 붙이고 싶다"면 이쪽이 정답이다.
| 영역 | 서비스 | 용도 |
|---|---|---|
| 텍스트 분석 | Comprehend | 감성·엔터티·핵심구 추출 |
| 번역 | Translate | 실시간 기계 번역 |
| 음성→텍스트 | Transcribe | 음성 인식, 자막 |
| 텍스트→음성 | Polly | TTS 음성 합성 |
| 이미지·영상 | Rekognition | 객체·얼굴·콘텐츠 감지 |
| 문서 추출 | Textract | OCR, 양식·표 추출 |
| 예측 | Forecast | 시계열 수요 예측 |
| 추천 | Personalize | 개인화 추천 엔진 |
| 생성형 AI | Bedrock | 파운데이션 모델 API |
판별 기준은 추상화 수준이다. AI 서비스(API 호출, 학습 불필요) → SageMaker(직접 학습·배포, 유연성) → EC2 직접 구축(최대 통제, 최대 부담). "흔한 문제 + 빠른 구현"이면 AI 서비스, "고유 데이터로 커스텀 모델"이면 SageMaker다.
💡 관련 이론: 이 계층 구조는 "build vs buy"의 클라우드 버전이다. AI 서비스는 AWS가 막대한 데이터로 미리 학습해둔 모델을 빌려 쓰는 것(buy)이고, SageMaker는 자체 데이터로 직접 만드는 것(build)이다. ML 엔지니어의 판단 포인트는 "내 문제가 일반적인가, 고유한가"다. 일반적 NLP·비전 작업은 AI 서비스가 더 빠르고 정확하며 운영 부담이 없지만, 도메인 특화 데이터(예: 의료 영상, 산업 결함)는 직접 학습이 필요하다.
Week 1의 큰 그림은 이렇다. ML은 수명주기(준비→개발→배포→모니터링→재학습)로 순환하고, 문제 유형(분류·회귀·군집)마다 평가지표가 다르며(불균형이면 accuracy 함정 주의), 이 수명주기 전체를 SageMaker가 덮는다. 흔한 작업은 학습 없이 AI 서비스로 빠르게 붙인다. 추상화 수준(AI 서비스 → SageMaker → EC2)을 문제의 일반성·고유성으로 고르는 감각이 시험의 핵심이다.
다음 주(Week 2)에는 수명주기의 첫 단계인 데이터 수집과 저장 — S3, Kinesis, Glue, Athena를 깊이 파고든다.