Day 1 - ML 수명주기 (Specialty 관점)

MLS-C01(AWS Certified Machine Learning – Specialty)은 SageMaker 버튼 위치를 묻지 않는다. "이 비즈니스 문제를 풀려면 어떤 데이터를, 어떻게 가공해서, 어떤 알고리즘으로, 어떤 지표로 평가하고, 어떻게 배포·모니터링할 것인가"를 시나리오로 묻는다. 그래서 첫날은 전체 수명주기를 Specialty 깊이로 다시 그린다. Associate가 "각 단계가 뭔지"를 묻는다면, Specialty는 "단계 사이의 트레이드오프"를 묻는다.

오늘 목표는 ① 문제를 ML 문제로 번역하는 법, ② 데이터→특성→모델→배포→모니터링의 순환 구조, ③ 오프라인 모델 지표를 비즈니스 지표에 연결하는 사고를 잡는 것이다.

문제 정의: 비즈니스 질문을 ML 문제로 번역하기

가장 흔한 실패는 모델링이 아니라 문제 정의에서 일어난다. "이탈을 줄이고 싶다"는 비즈니스 목표지 ML 문제가 아니다. ML 문제로 번역하려면 세 가지를 고정해야 한다.

1. 예측 대상(target): 무엇을 예측하는가 — 다음 30일 내 이탈 여부(이진 분류)
2. 입력(features): 어떤 신호로 예측하는가 — 최근 로그인 빈도, 결제 이력, 지원 티켓 수
3. 성공 기준(metric): 무엇이 "좋은" 모델인가 — recall 0.8 이상에서 precision 최대화

문제 유형을 잘못 잡으면 그 뒤 모든 게 어긋난다. Specialty 시험은 다음 매핑을 시나리오로 끊임없이 묻는다.

💡 관련 이론: 지도학습(supervised)은 레이블이 있는 데이터로 입력→출력 매핑을 배우고, 비지도학습(unsupervised)은 레이블 없이 구조를 발견한다. "사기 탐지"는 보통 지도학습 이진 분류로 풀지만, 레이블(과거 사기 사례)이 극히 적으면 이상 탐지(Random Cut Forest 같은 비지도 기법)로 접근한다. 같은 비즈니스 문제도 레이블 가용성에 따라 문제 유형이 바뀐다는 점이 Specialty의 단골 함정이다.

수명주기는 선형이 아니라 순환이다

ML 시스템은 한 번 만들고 끝나지 않는다. 운영 중 데이터가 변하면(드리프트) 다시 처음으로 돌아간다.

1. 데이터 (Data)        : 수집 → 정제 → 레이블링 → 저장(데이터레이크)
2. 특성 (Feature)       : 피처 엔지니어링 → 변환 → Feature Store
3. 모델 (Model)         : 알고리즘 선택 → 학습 → HPO 튜닝 → 평가
4. 배포 (Deploy)        : 실시간 엔드포인트 / 배치 변환 / 서버리스
5. 모니터링 (Monitor)   : 데이터·모델 품질 드리프트 → 재학습 트리거
                         └──────────────(loop back to 1)──────────────┘

이번 주(Week 1)는 1단계 데이터와 그 직전 단계인 수집·저장·레이블링에 집중한다. Specialty 시험에서 데이터 엔지니어링 도메인의 비중이 크기 때문이다(전체의 약 20%).

# SageMaker SDK로 본 수명주기 — 단계별 책임 분리
import sagemaker