Day 1 - 도메인 1·2 통합 복습: 데이터 준비 + 모델 개발

도메인 1·2 전체 지도

마지막 주의 첫날이다. 새 개념이 아니라 흩어진 지식을 시험장에서 꺼낼 형태로 다시 묶는다.

[도메인 1 — 데이터 준비 28%]
  수집               저장              준비·변환                특성 관리
  ─────              ─────             ──────────               ──────────
  Kinesis DS   ─┐                      Data Wrangler(비주얼)     Feature Store
  Firehose     ─┼─▶  S3 (데이터레이크) ─▶ Processing Job(코드)  ─▶  ├ 온라인 : 저지연 단건
  배치 업로드   ─┘    + Glue Catalog     Glue ETL / EMR(Spark)      └ 오프라인: S3·대량
  Ground Truth        (스키마·메타)      Athena(SQL 즉석 조회)            │
  (라벨링)                               Clarify(사전 편향 점검)          │
                                                                         ▼
[도메인 2 — 모델 개발 26%]                                          학습용 데이터
  학습  ───────────▶  튜닝  ───────────▶  평가  ───────────▶  모델 아티팩트
  Training Job        AMT                 지표 선택            model.tar.gz (S3)
  빌트인/프레임워크    Bayesian·Random     Accuracy·F1·AUC             │
  /커스텀 컨테이너     Grid·Hyperband      RMSE·MAE·R²                 ▼
  File/Pipe/FastFile   objective_metric    Clarify(사후 편향)    Model Registry
  Spot + 체크포인트    Debugger(과적합·병목 룰)                  (→ 도메인 3)

이 지도의 가로축은 "데이터가 모델이 되는 순서"이고, 세로축은 "누가 그 단계를 책임지는가"다. 시험 문항은 거의 항상 이 지도 위의 한 지점을 지목한다. 시나리오를 읽으며 "지금 어느 칸의 이야기인가"를 먼저 찍으면 보기 4개 중 절반은 다른 칸의 서비스라 즉시 소거된다.

도메인 1: 수집·저장 — 서비스 지도

데이터가 어디서 와서 어디에 쌓이는지를 먼저 정리한다.

시험은 "실시간인가 일괄인가", "코드를 짤 것인가 비주얼로 할 것인가", "어디에 저장할 것인가"로 서비스를 가른다. 실시간 이벤트면 Kinesis, 적재 후 변환이면 Glue, 비주얼 전처리·빠른 EDA면 Data Wrangler, S3를 SQL로 즉석 조회면 Athena다. 데이터 레이크의 중심은 거의 항상 S3이고, 나머지는 그 주변에서 수집·변환·조회 역할을 나눠 맡는다.

도메인 1: 준비·변환 도구 고르기

같은 "전처리"라도 도구가 갈린다. 이 구분이 문제의 단서가 된다.

⚠️ 함정: "코드를 거의 작성하지 않고 시각적으로"가 나오면 Data Wrangler, "내가 쓴 전처리 스크립트를 관리형으로 실행"이면 Processing Job이다. 둘을 뒤집어 놓는 보기가 오답으로 쓰이기 쉽다. Data Wrangler와 Processing Job은 대립 관계가 아니라 Data Wrangler의 흐름을 Processing Job으로 내보내 파이프라인에 넣는 것이 표준 조합이다.

도메인 1: 특성공학 체크리스트

⚠️ 함정: 데이터 누수(leakage) 는 조용히 성능을 부풀린다. 대표 사례 두 가지. ① 스케일러·대치값을 전체 데이터로 계산한 뒤 학습/검증을 나누면 검증 정보가 학습에 새어 든다 — 반드시 학습 세트로 fit하고 검증에는 transform만 한다. ② 시계열을 무작위로 셔플해 분할하면 미래가 과거를 학습시킨다 — 시계열은 반드시 시간 순 분할이다.

도메인 1: Feature Store — 온라인 vs 오프라인

Feature Store는 특성을 한 번 정의해 학습과 추론이 함께 쓰게 만드는 중앙 저장소다.

import boto3
 
# 온라인 스토어: 실시간 추론 직전 단건 조회
fs_runtime = boto3.client('sagemaker-featurestore-runtime')
resp = fs_runtime.get_record(
    FeatureGroupName='customer-features',
    RecordIdentifierValueAsString='C-10293',
)
# 오프라인 스토어는 S3에 쌓이므로 Athena로 SQL 조회해 학습 데이터셋을 만든다

Feature Store의 존재 이유는 training-serving skew 제거다. 학습 때 계산한 특성과 추론 때 계산한 특성이 미세하게 달라지면 성능이 조용히 떨어진다. 특성을 한 곳에 정의·버전관리하고 온라인/오프라인 양쪽이 같은 정의를 공유하면 이 불일치가 사라진다. "여러 팀·여러 모델이 같은 특성을 재사용", "학습과 실시간 추론의 특성을 일치"라는 키워드가 나오면 Feature Store다.

도메인 1: SageMaker Clarify — 편향과 설명가능성

Clarify는 두 가지를 한다. ① 편향 탐지(bias detection) — 학습 전 데이터 편향, 학습 후 모델 편향을 측정한다. ② 설명가능성(explainability) — SHAP 값으로 어떤 특성이 예측에 얼마나 기여했는지 보여준다.

편향은 두 시점에서 본다. 사전(pre-training) 편향은 데이터 자체의 불균형(예: 특정 집단 표본 부족)을, 사후(post-training) 편향은 모델 예측이 집단별로 다르게 나오는지를 측정한다. "공정성·편향·차별을 점검하라"는 Clarify, "예측 근거를 설명하라/특성 기여도"는 Clarify의 SHAP이다. 모니터링 단계에서는 Model Monitor가 Clarify와 연동해 운영 중 편향·특성 기여도 드리프트를 감시한다.

도메인 2: 빌트인 알고리즘 → 문제 유형 매핑

모델 개발은 "어떤 알고리즘을, 어떻게 학습시키는가"다. 빌트인 알고리즘의 대표 매핑은 다음과 같다.

알고리즘 매핑을 묻는다. "시계열 다변량 예측"에 회귀를 고르면 틀린다 — DeepAR이다. "실시간 스트림 이상치"는 RCF, "수천 차원 희소 추천"은 Factorization Machines다. 또 학습 데이터 입력 모드도 묻는다. 데이터가 인스턴스 디스크보다 크거나 시작 지연을 줄이고 싶으면 Pipe 모드(또는 최신 Fast File 모드)로 S3에서 스트리밍하고, 작은 데이터면 File 모드로 통째로 복사한다.

도메인 2: 학습 인프라 — 입력 모드·인스턴스·Spot

Spot은 반드시 체크포인트가 짝이다. checkpoint_s3_uri 없이 Spot만 켜면 회수될 때마다 처음부터 다시 학습해 오히려 손해다. 그리고 max_wait >= max_run이어야 한다 — Spot은 용량을 기다리는 시간이 추가로 필요하기 때문이다. "GPU로 바꿨는데 안 빨라진다"는 대개 연산이 아니라 I/O가 병목인 경우이며, 트리 계열(XGBoost)에 GPU를 붙이는 보기는 함정이다.

도메인 2: 하이퍼파라미터 튜닝(AMT)

SageMaker Automatic Model Tuning(AMT)은 하이퍼파라미터 탐색을 자동화한다.

from sagemaker.tuner import HyperparameterTuner, IntegerParameter, ContinuousParameter
 
tuner = HyperparameterTuner(
    estimator=estimator,
    objective_metric_name='validation:auc',   # 최적화 대상 지표
    objective_type='Maximize',
    hyperparameter_ranges={
        'max_depth': IntegerParameter(3, 10),
        'eta': ContinuousParameter(0.01, 0.3),
    },
    max_jobs=30,            # 총 학습 시도 수
    max_parallel_jobs=3,    # 동시 실행 수(Bayesian은 작게 두는 편이 유리)
    strategy='Bayesian',
)
tuner.fit({'train': train_input, 'validation': val_input})

튜닝 전략 선택은 "예산 효율 vs 병렬성"이다. Bayesian은 적은 시도로 좋은 값을 찾지만 앞선 결과를 참고하므로 병렬도를 너무 키우면 이점이 줄고, Random/Grid는 병렬화가 쉽지만 비효율적이며, Hyperband는 가망 없는 학습을 일찍 끊어 대규모 탐색의 비용을 줄인다. "적은 학습 횟수로 효율적 탐색"은 Bayesian, "조기 종료로 자원 절약"은 Hyperband가 키워드다.

도메인 2: 평가 — 올바른 지표 고르기

지표 선택은 거의 항상 "데이터가 불균형한가, 무엇을 더 중요하게 보는가"로 결정된다.

불균형 데이터에서 Accuracy를 고르면 틀린다. 99%가 정상인 사기탐지에서 "전부 정상"이라 찍어도 정확도 99%지만 사기는 하나도 못 잡는다. 이런 시나리오는 F1·AUC·Recall로 평가해야 한다. "사기/질병을 놓치면 안 된다"는 Recall, "오탐(거짓경보) 비용이 크다"는 Precision이 핵심어다. 과적합 징후(학습 정확도↑·검증 정확도↓)는 정규화·드롭아웃·조기종료·데이터 증강으로 대응한다.

도메인 1·2 혼동하기 쉬운 짝

증상 → 원인 → 조치

내일은 도메인 3·4 — 배포·오케스트레이션과 모니터링·보안을 같은 방식으로 묶는다.

📖 용어

• 도메인 비중 : MLA-C01이 데이터 준비 28%·모델 개발 26%·배포 22%·모니터링 보안 24%로 출제되는 비율. 1·2가 절반을 넘는다.
• training-serving skew : 학습 때 만든 특성과 추론 때 만든 특성이 미묘하게 달라 성능이 조용히 떨어지는 현상.
• Feature Store 온라인/오프라인 스토어 : 실시간 추론용 저지연 단건 조회 저장소 / 학습·배치용 S3 기반 대량 조회 저장소.
• 데이터 누수(leakage) : 학습해서는 안 될 정보(검증 데이터 통계, 미래 값, 정답을 암시하는 컬럼)가 학습에 새어 들어가 성능이 과대평가되는 것.
• Processing Job : 내 전처리·평가 스크립트를 SageMaker 관리형 인스턴스에서 돌리는 작업. 끝나면 인스턴스가 내려간다.
• SHAP : 각 특성이 개별 예측에 얼마나 기여했는지 수치로 보여주는 설명 기법. Clarify가 이걸 계산해준다.
• 사전 편향 / 사후 편향 : 데이터 자체가 특정 집단에 치우쳤는가 / 모델 예측이 집단별로 다르게 나오는가.
• AMT (Automatic Model Tuning) : 하이퍼파라미터 조합을 자동으로 여러 번 학습해 최적값을 찾아주는 SageMaker 기능. 최적화 대상인 objective_metric은 학습 로그로 방출되어야 튜너가 읽을 수 있다.
• 불균형 데이터 : 한 클래스가 압도적으로 많은 데이터. Accuracy가 무의미해지고 F1·AUC·Recall이 필요해진다.