Day 5 - 2주차 종합 복습: 데이터 변환부터 분산 학습 데이터 공급까지

Week 2 흐름 한눈에 보기

[원시 데이터]
   │  Day 1: 변환 (ETL)
   ▼  Glue (서버리스 Spark) / EMR (풀 컨트롤 클러스터)
[정제·가공된 데이터]
   │  Day 2: 파이프라인 자동화
   ▼  Step Functions (범용) / SageMaker Pipelines (ML 전용) + EventBridge 트리거
[재현 가능한 학습 데이터셋]
   │  Day 3: 증강·합성·불균형 처리
   ▼  증강(반전·역번역) / 합성(GAN) / SMOTE·클래스 가중치
[충분하고 균형 잡힌 데이터셋]
   │  Day 4: 저장·접근 최적화
   ▼  File/Pipe/FastFile 모드 / FSx for Lustre / ShardedByS3Key
[학습에 효율적으로 공급] → 모델 학습

핵심 메시지: 데이터 준비는 변환 한 단계로 끝나지 않는다. 가공 → 자동화 → 증강 → 효율적 공급이 모두 모델 품질과 비용에 직접 영향을 준다.

Day 1 복습 — 변환과 ETL

• ETL = Extract → Transform → Load. ML에서 산출물은 학습 데이터셋이다.
• AWS Glue: 서버리스 Spark. Data Catalog, Crawler, ETL Job, DynamicFrame. 운영 부담 최소, 산발적·표준적 ETL에 적합. 과금은 DPU-시간.
• Amazon EMR: EC2 클러스터에서 Hadoop/Spark/Hive/Presto를 직접 운영. 세밀 튜닝·다중 프레임워크·스팟 절감이 필요한 무거운 워크로드에 적합.
• 대규모 전처리: Parquet 컬럼형 포맷, 파티셔닝(partition pruning), 적절한 파일 크기, predicate pushdown.
• Spark 감각: 셔플이 가장 비싸고, 스큐가 잡 시간을 지배한다. 잡 북마크로 증분 처리를 한다.

💡 개념: Glue vs EMR 판단의 세 축 — 운영 부담(최소화→Glue), 워크로드 성격(짧고 산발적→Glue, 길고 무거운 배치→EMR), 프레임워크 다양성(Spark만→Glue, 여러 엔진→EMR).

Day 2 복습 — 파이프라인 자동화

• Step Functions: 범용 오케스트레이터. ASL(JSON)로 상태 머신 정의. ML+비ML 혼합, 승인, 외부 시스템, 복잡한 분기에 강하다.
• SageMaker Pipelines: ML 전용. Python SDK. ProcessingStep/TrainingStep/TuningStep/ConditionStep/RegisterModel. lineage와 모델 레지스트리 내장.
• 선택 기준: 순수 ML CI/CD와 추적성 → SageMaker Pipelines, ML+비ML 혼합과 승인 → Step Functions. 혼합 사용도 가능하다.
• 트리거: EventBridge(cron/이벤트), S3 이벤트 → 파이프라인 시작.

⚠️ 함정: "ML이니까 무조건 SageMaker Pipelines"는 단순화된 오답이다. 비-ML 단계·승인·복잡한 분기가 많으면 Step Functions가 더 적합하다.

Day 3 복습 — 증강·합성·불균형 처리

• 증강: 레이블을 보존하는 변형으로 기존 데이터를 다양화. 이미지(반전·회전·컬러 지터), 텍스트(동의어 치환·역번역). 도메인 의미 보존이 필수다.
• 합성: 새로운 가상 데이터를 생성. GAN, 시뮬레이션, 합성 정형 데이터(프라이버시). 분포 갭 위험 → 검증은 실데이터로.
• 불균형 처리: 데이터 층(오버/언더샘플링, SMOTE=보간 합성), 알고리즘 층(클래스 가중치, 임계값), 평가 층(accuracy 금지 → recall, F1, PR-AUC).

SMOTE는 단순 복제와 달리 소수 샘플과 최근접 이웃 사이를 보간해 새 점을 만든다. 1:999 같은 불균형에서 accuracy는 거짓 안심을 주므로 평가는 recall과 PR-AUC로 해야 한다.

Day 4 복습 — 저장·접근 최적화

• 핵심 목표: 비싼 GPU가 I/O를 기다리며 놀지 않게 하는 것.
• 샤딩 전제 조건: 데이터가 여러 S3 객체로 나뉘어 있어야 효과가 난다.
• 분산 학습은 데이터 병렬(모델 복제 + 데이터 분할)이 기본이고, 모델이 GPU에 안 들어갈 때만 모델 병렬을 쓴다.

🎯 통합 시나리오: "수 TB 데이터, 8개 GPU 노드, 시작이 너무 느리다." → 데이터를 여러 Parquet 샤드로 분할(Day 1) → 파이프라인으로 자동 생성(Day 2) → 불균형이면 SMOTE/가중치(Day 3) → ShardedByS3Key + FSx for Lustre로 공급(Day 4).

Week 2 서비스·기법 지도

헷갈리는 비교 지점 총정리

MLS-C01 데이터 엔지니어링 영역의 출제 패턴은 거의 항상 "비용/운영 부담/규모/접근 패턴"의 트레이드오프 판단이다. 정답은 단일 기술이 아니라 상황(요구사항)에 맞는 선택이다. 문제에서 "운영 최소", "매우 큰 데이터", "임의 접근 필요", "비-ML 단계 포함" 같은 단서를 찾아 매핑하는 훈련이 핵심이다.

지문 단서 → 정답 매핑

Week 2 오답 노트

• 데이터가 크다는 이유만으로 EMR 상시 클러스터 — 산발적 워크로드면 서버리스가 맞다.
• 파티션을 잘게 쪼갤수록 좋다 — 작은 파일이 폭증해 오히려 느려진다.
• ML이니까 SageMaker Pipelines — 비-ML 단계가 많으면 Step Functions.
• 재시도 횟수를 늘려 실패를 해결 — 권한·경로·데이터 문제는 재시도로 안 풀린다.
• 검증셋에도 SMOTE 적용 — 리샘플링은 학습셋에만. 검증은 실제 분포를 유지해야 한다.
• 합성 데이터로 검증 — 검증은 반드시 실데이터로.
• 단일 거대 파일 + ShardedByS3Key — 객체 단위로 못 쪼개 효과가 없다.
• 검증 채널까지 샤딩 — 노드마다 다른 검증셋을 보게 되어 지표가 어긋난다.

스스로 점검하기

머릿속으로 답해 본다.

1. 운영 인력이 적고 하루 몇 번 표준 Spark 변환을 돌린다면? → Glue 서버리스 ETL
2. Spark·Hive·Presto를 함께 쓰고 인스턴스를 세밀 튜닝해야 한다면? → Amazon EMR
3. Spark 잡에서 가장 비싼 연산은? → 셔플
4. 이미 처리한 데이터를 건너뛰고 새 데이터만 처리하려면? → Glue 잡 북마크
5. 승인 대기와 Lambda 후처리가 섞인 워크플로의 상위 오케스트레이터는? → Step Functions
6. "정확도 0.85 이상일 때만 모델 등록"을 표현하는 단계는? → ConditionStep
7. 소수 클래스를 단순 복제 대신 보간으로 늘리는 기법은? → SMOTE
8. 리샘플링은 어느 데이터셋에만 적용하나? → 학습셋만
9. 합성 데이터로 학습한 모델의 검증은 무엇으로? → 실데이터
10. 수백 GB를 즉시 학습 시작하고 싶다면? → Pipe(또는 FastFile) 모드
11. 같은 데이터셋으로 튜닝을 수백 번 반복한다면? → FSx for Lustre
12. ShardedByS3Key가 효과를 내는 전제는? → 데이터가 여러 S3 객체로 분할
13. 모델이 단일 GPU 메모리에 안 들어가면? → 모델 병렬
14. 스팟으로 장시간 학습할 때 반드시 함께 가는 것은? → 체크포인트

모든 선택의 밑바닥에는 비용·운영 부담·규모·접근 패턴의 트레이드오프가 깔려 있다. 다음 주에는 이렇게 준비한 데이터 위에서 본격적인 모델링과 알고리즘으로 들어간다.

📖 용어

• ETL : 추출·변환·적재. ML에서는 그 결과물이 곧 학습 데이터셋이다.
• DPU : Glue의 처리 용량 단위. 약 4 vCPU + 16GB 메모리.
• 셔플(shuffle) : 키 기준으로 노드 간 데이터를 재분배하는 Spark 연산. 가장 비싸다.
• 오케스트레이션 : 여러 단계의 실행 순서·조건·재시도를 선언적으로 관리하는 것.
• lineage(계보) : 모델이 어떤 데이터·코드·파라미터에서 나왔는지 추적할 수 있는 기록.
• SMOTE : 소수 클래스 샘플과 최근접 이웃 사이를 보간해 새 샘플을 만드는 오버샘플링.
• 분포 갭 : 합성·증강 데이터의 분포가 실제와 어긋나 실세계 성능이 떨어지는 위험.
• 입력 모드 : S3 데이터를 학습 컨테이너로 가져오는 방식. File·Pipe·FastFile.
• ShardedByS3Key : S3 객체를 인스턴스별로 나눠 각자 다른 조각만 받게 하는 설정.
• 데이터 병렬 / 모델 병렬 : 데이터를 쪼개 모델을 복제하는 방식 / 모델 자체를 여러 GPU에 쪼개는 방식.

📝 연습 문제

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

문제 1

운영 인력이 적은 팀이 매일 표준 Spark 변환을 돌리고, 그 결과로 모델을 재학습하는 ML CI/CD를 lineage 추적과 함께 구성하려 한다. 가장 자연스러운 조합은?

• AEMR 상시 클러스터 + 수동 학습
• BGlue 서버리스 ETL + SageMaker Pipelines
• CLambda 단일 함수로 전부 처리
• DAthena 쿼리만으로 학습까지 수행

문제 2

1:999로 극히 불균형한 데이터에서 소수 클래스를 단순 복제 대신 보간으로 합성해 늘리고, 평가는 거짓 안심을 피하려 한다. 알맞은 조합은?

• ASMOTE 오버샘플링 + PR-AUC 평가
• B언더샘플링 + 정확도 평가
• C데이터 복제 + 정확도 평가
• D합성 데이터로만 검증

문제 3

수 TB 데이터를 8개 노드로 데이터 병렬 학습할 때 각 노드의 중복 다운로드를 없애고 시작 지연을 줄이려 한다. 가장 적절한 설계는?

• A단일 거대 파일 + FullyReplicated + File mode
• BDynamoDB에서 직접 읽기
• C여러 파일로 분할 + ShardedByS3Key + (반복 읽기 시) FSx for Lustre
• D모든 노드가 전체 데이터를 다운로드

문제 4

데이터 변환 워크플로에 비-ML 단계(외부 승인 대기, Lambda 후처리)와 SageMaker 학습이 함께 섞여 있고 복잡한 분기·재시도가 필요하다. 상위 오케스트레이터로 가장 적합한 것은?

• ASageMaker Pipelines 단독
• BFSx for Lustre
• CGlue Crawler
• DAWS Step Functions

문제 5

MLS-C01 데이터 엔지니어링 영역에서 도구 선택형 문제를 풀 때 가장 핵심이 되는 판단 기준은?

• A항상 가장 최신에 출시된 서비스를 고른다
• B비용·운영 부담·규모·접근 패턴 등 요구사항 단서에 맞는 선택을 한다
• C무조건 가장 강력한(비싼) 옵션을 고른다
• D모든 문제에서 EMR을 정답으로 본다