기준: MLS-C01 시험 가이드오류 제보
[원천 데이터]
│
├─ 1) 수집/적재 (도메인 1)
│ 실시간 스트림 → Kinesis (Data Streams / Firehose)
│ 배치 적재 → S3 + Glue 카탈로그
│ 관계형/이관 → DMS, DataSync
│
├─ 2) 저장 (도메인 1)
│ 데이터 레이크 = S3 (사실상 표준)
│ 쿼리 = Athena(서버리스), Redshift(웨어하우스)
│
├─ 3) 변환/ETL (도메인 1)
│ Glue(서버리스 Spark) / EMR(대규모 클러스터)
│
├─ 4) 정제 (도메인 2)
│ 결측치 처리, 이상치, 중복 제거, 타입 보정
│
├─ 5) 피처 엔지니어링 (도메인 2)
│ 인코딩, 스케일링, 비닝, 차원 축소(PCA)
│
└─ 6) 시각화/EDA (도메인 2)
분포·상관·이상치 탐색 → QuickSight, 산점도/히스토그램| 도메인 | 대표 문항 유형 | 전형적 물음 |
|---|---|---|
| 1 데이터 엔지니어링 (20%) | 서비스 선택형 | "운영 부담 최소로 스트림을 S3에 적재하려면?" |
| 1 데이터 엔지니어링 (20%) | 아키텍처 조합형 | "수집→저장→쿼리를 어떻게 잇는가" |
| 1 데이터 엔지니어링 (20%) | 이관·전송형 | "온프레미스 DB/파일을 AWS로 옮기려면?" |
| 2 탐색적 데이터 분석 (24%) | 전처리 기법 선택형 | "고카디널리티 범주형의 인코딩은?" |
| 2 탐색적 데이터 분석 (24%) | 전처리 순서형 | "분할·대치·스케일링의 순서는?" |
| 2 탐색적 데이터 분석 (24%) | 누수 판별형 | "오프라인 점수만 높은 이유는?" |
| 2 탐색적 데이터 분석 (24%) | 차트 해석형 | "이 히스토그램 다음에 할 일은?" |
| 2 탐색적 데이터 분석 (24%) | 불균형 대응형 | "양성 0.5%인데 정확도 99%다" |
스트리밍 문제는 거의 항상 Kinesis 4형제의 역할 구분으로 갈린다.
| 서비스 | 핵심 역할 | 단서 단어 |
|---|---|---|
| Kinesis Data Streams | 실시간 수집, 커스텀 소비자, 샤드 관리 | 밀리초 지연, 다중 소비자, 재처리 |
| Kinesis Data Firehose | 완전관리 적재(S3/Redshift/OpenSearch) | 서버리스, 버퍼링 후 적재, 변환 |
| Kinesis Data Analytics | 스트림에 SQL/Flink로 실시간 분석 | 실시간 집계, 윈도우 쿼리 |
| Kinesis Video Streams | 비디오 스트림 수집 | 카메라, 영상 |
💡 관련 이론: Streams vs Firehose는 "관리 부담을 누가 지는가"로 갈린다. Streams는 샤드 용량·소비자·보존기간을 직접 관리해 가장 유연하지만 운영 부담이 크다. Firehose는 샤드 개념 없이 버퍼 크기·시간만 정하면 S3/Redshift로 자동 적재되어 "완전관리/서버리스/최소 운영" 단어와 함께 나오면 정답이다. "커스텀 처리·밀리초·재처리"는 Streams, "그냥 S3로 떨궈줘"는 Firehose로 즉답한다.
| 요구사항 | 서비스 |
|---|---|
| 데이터 레이크 중앙 저장소 | S3 |
| S3 위 서버리스 SQL 쿼리 | Athena |
| 대규모 정형 분석 웨어하우스 | Redshift |
| 서버리스 Spark ETL + 카탈로그 | Glue |
| 대규모 Hadoop/Spark 클러스터 제어 | EMR |
| 온프레미스 DB → AWS 이관 | DMS |
| 대용량 파일 동기화 전송 | DataSync |
Glue vs EMR은 "운영 통제 vs 편의"의 또 다른 사례다. Glue는 서버리스라 클러스터를 띄우지 않고 ETL 잡과 데이터 카탈로그(메타데이터)를 제공해 "서버리스 ETL, 스키마 자동 추론"에 강하다. EMR은 클러스터를 직접 띄워 스파크 버전·라이브러리·하둡 생태계를 세밀히 제어할 때 쓴다. "관리형/서버리스/빠른 시작"=Glue, "세밀한 클러스터 튜닝/기존 하둡 잡"=EMR이다.
| 문제 | 처리 기법 |
|---|---|
| 결측치(소량, MCAR) | 행 삭제 또는 평균/중앙값 대치 |
| 결측치(다수, 패턴 있음) | KNN/모델 기반 대치, 결측 플래그 피처 추가 |
| 수치 이상치 | IQR/Z-score 탐지 후 윈저화 또는 제거 |
| 클래스 불균형 | SMOTE(오버샘플링), 언더샘플링, 가중치 |
| 중복/형식 오류 | 중복 제거, 타입·단위 표준화 |
⚠️ 함정: 스케일러·인코더·대치기·SMOTE는 분할 후 학습셋에서만 fit하고, 검증·테스트셋에는
transform만 적용한다. 전체 데이터로 fit하면 테스트 정보가 학습에 새어 들어가(데이터 누수, leakage) 오프라인 점수만 부풀려지고 운영에서 무너진다. "교차검증 점수는 훌륭한데 프로덕션 성능이 형편없다"는 지문은 대부분 누수를 묻는 문제다.
| 데이터/목표 | 기법 |
|---|---|
| 순서 없는 범주형 | One-Hot Encoding |
| 순서 있는 범주형 | Ordinal/Label Encoding |
| 고카디널리티 범주 | 임베딩, 타깃/빈도 인코딩 |
| 거리/경사기반 모델의 스케일 차이 | 표준화(StandardScaler), 정규화(MinMax) |
| 연속값을 구간화 | 비닝(Binning) |
| 차원 과다, 다중공선성 | PCA(주성분 분석) |
| 텍스트 | TF-IDF, BoW, 임베딩 |
스케일링이 "필요한 모델"과 "불필요한 모델"의 구분이 출제 범위에 든다. 거리 기반(KNN, K-Means, SVM)과 경사하강 기반(선형/로지스틱 회귀, 신경망)은 피처 스케일에 민감해 표준화가 거의 필수다. 반면 트리 기반(결정트리, 랜덤포레스트, XGBoost)은 분할 기준이 스케일에 불변이라 스케일링이 사실상 무의미하다. "XGBoost인데 스케일링이 필수다"류 보기는 함정이다.
| 차트 | 보는 것 |
|---|---|
| 히스토그램/밀도 | 단일 변수 분포, 왜도 |
| 박스플롯 | 이상치, 사분위 분산 |
| 산점도 | 두 변수 관계, 군집·이상치 |
| 상관 히트맵 | 다중공선성, 피처 간 상관 |
| 라인 차트 | 시계열 추세·계절성 |
EDA의 목적은 "보기 좋은 그림"이 아니라 "전처리·모델링 의사결정의 근거 확보"다. 히스토그램에서 강한 왜도가 보이면 로그 변환을, 박스플롯에서 이상치가 보이면 윈저화를, 상관 히트맵에서 두 피처가 0.95 이상이면 다중공선성 제거(하나 드롭 또는 PCA)를 결정한다. 시각화 문제는 "이 그림에서 무엇을 보고 다음에 무엇을 하느냐"로 환원된다.
| 지문 단서 | 정답 | 이유 |
|---|---|---|
| "밀리초 지연, 여러 소비자가 각자 읽고 재처리" | Kinesis Data Streams | 샤드·보존기간을 직접 제어, 다중 소비자 지원 |
| "운영 부담 최소, 버퍼링 후 S3/Redshift 적재" | Kinesis Data Firehose | 완전관리 적재, 버퍼 크기·시간만 설정 |
| "스트림 위에서 실시간 집계·윈도우 쿼리" | Kinesis Data Analytics | 스트림에 SQL/Flink 적용 |
| "카메라 영상을 수집·재생" | Kinesis Video Streams | 비디오 전용 수집 |
| "클러스터 프로비저닝 없이 S3를 표준 SQL로 애드혹 조회" | Athena | 서버리스 쿼리, 스캔한 데이터만 과금 |
| "대규모 정형 데이터에 복잡한 조인·BI 리포트" | Redshift | 열 지향 웨어하우스 |
| "웨어하우스에서 S3의 원본을 로드 없이 함께 조회" | Redshift Spectrum | Redshift에서 S3 외부 테이블 직접 쿼리 |
| "서버리스 Spark ETL, 스키마 자동 추론과 메타데이터" | Glue (크롤러 + 데이터 카탈로그) | 클러스터 없이 ETL·카탈로그 제공 |
| "Spark 버전·하둡 생태계를 세밀히 제어, 기존 하둡 잡 이관" | EMR | 클러스터 직접 운영 |
| "온프레미스 관계형 DB를 최소 다운타임으로 이관" | DMS | DB 마이그레이션 전용, 지속 복제 지원 |
| "온프레미스 파일 서버의 대용량 파일을 S3로 동기화" | DataSync | 파일 전송·동기화 전용 |
| "코드 없이 시각적으로 데이터를 정제·프로파일링" | Glue DataBrew | 노코드 데이터 준비 |
| "학습과 추론이 같은 피처 정의를 공유·재사용" | SageMaker Feature Store | 피처 저장·조회 일원화 |
| "비기술 사용자에게 대시보드로 공유" | QuickSight | BI 시각화 서비스 |
| 지문 단서 | 정답 | 이유 |
|---|---|---|
| "색상·도시처럼 순서가 없는 범주" | One-Hot Encoding | 임의의 크기 관계를 만들지 않는다 |
| "S/A/B 등급처럼 순서가 있는 범주" | Ordinal / Label Encoding | 순서 정보를 정수로 보존 |
| "사용자 ID처럼 값이 수천 종" | 임베딩 또는 타깃·빈도 인코딩 | One-Hot이면 차원이 폭발 |
| "KNN·SVM·신경망을 학습하기 전" | 표준화(StandardScaler) | 거리·경사가 스케일에 민감 |
| "XGBoost인데 표준화가 필수다" | 오답 보기 | 트리는 분할 기준이 스케일에 불변 |
| "오른쪽 꼬리가 긴 강한 우왜도" | 로그 변환 | 분포를 대칭에 가깝게 |
| "두 피처의 상관이 0.96이다" | 다중공선성 제거(드롭 또는 PCA) | 중복 정보가 계수를 불안정하게 |
| "양성 클래스가 0.5%인데 정확도가 99%다" | 리샘플링·클래스 가중치 + F1/AUPRC로 지표 교체 | 정확도는 불균형에서 무의미 |
| "소수 클래스 샘플이 절대적으로 적다" | SMOTE(오버샘플링) | 데이터를 버리지 않고 소수를 합성 |
| "다수 클래스가 지나치게 많고 학습이 느리다" | 언더샘플링 | 다수를 줄여 균형·속도 확보 |
| "데이터를 건드리지 않고 불균형을 보정" | 클래스 가중치(예: scale_pos_weight) | 손실 함수에서 페널티 조정 |
| "분포가 치우쳐 있는데 이상치를 잡아야 한다" | IQR(박스플롯) 기준 | 분포 가정이 필요 없다 |
| "정규분포에 가까운 변수의 극단값" | Z-score 기준(예: |z| > 3) | 정규성 가정이 성립 |
| "결측이 소량이고 무작위로 흩어져 있다" | 행 삭제 또는 평균·중앙값 대치 | 비용 대비 효과가 좋다 |
| "결측 여부 자체가 정보로 보인다" | 결측 플래그 피처 + 모델 기반/KNN 대치 | 결측 패턴을 버리지 않는다 |
| "자유 텍스트를 수치 피처로" | BoW / TF-IDF / 임베딩 | 텍스트 벡터화 |
| 항목 | Data Streams | Firehose | Data Analytics |
|---|---|---|---|
| 역할 | 실시간 수집·보관 | 목적지로 적재(delivery) | 스트림에 대한 실시간 분석 |
| 관리 대상 | 샤드·소비자·보존기간 | 버퍼 크기·시간만 | 쿼리·애플리케이션 |
| 다중 소비자·재처리 | 가능 | 부적합 | 소스로 Streams/Firehose 사용 |
| 대표 단서 | 밀리초, 커스텀 소비자 | 완전관리, S3로 떨궈줘 | 윈도우 집계, SQL/Flink |
| 항목 | Glue | EMR |
|---|---|---|
| 형태 | 서버리스 Spark | 직접 띄우는 클러스터 |
| 강점 | 빠른 시작, 데이터 카탈로그·크롤러 | 버전·라이브러리·하둡 생태계 통제 |
| 대표 단서 | 서버리스 ETL, 스키마 자동 추론 | 세밀한 튜닝, 기존 하둡 잡 |
| 항목 | Athena | Redshift | Redshift Spectrum |
|---|---|---|---|
| 데이터 위치 | S3 | 클러스터에 적재된 데이터 | S3(외부 테이블) |
| 프로비저닝 | 없음(서버리스) | 클러스터 필요 | Redshift 클러스터 필요 |
| 적합한 일 | 애드혹 조회, 간헐적 분석 | 반복적 대규모 BI·복잡 조인 | 적재 없이 S3 원본을 함께 조인 |
| 항목 | DMS | DataSync |
|---|---|---|
| 대상 | 데이터베이스 | 파일·오브젝트 스토리지 |
| 대표 용도 | 온프레미스 DB → RDS/Redshift/S3 이관 | 온프레미스 NFS/SMB → S3/EFS/FSx 전송 |
| 대표 단서 | 최소 다운타임 DB 마이그레이션 | 대용량 파일 동기화 |
| 항목 | One-Hot | Label / Ordinal | 타깃(Target) |
|---|---|---|---|
| 전제 | 순서 없음 | 순서 있음 | 카디널리티가 매우 큼 |
| 차원 | 범주 수만큼 증가 | 1열 유지 | 1열 유지 |
| 위험 | 고카디널리티에서 차원 폭발 | 없는 순서를 만들어 냄 | 타깃 정보 누수 — 학습셋 기준으로만 계산 |
| 항목 | 표준화(Standardization, Z-score) | 정규화(Normalization, Min-Max) |
|---|---|---|
| 결과 | 평균 0, 표준편차 1 | 대체로 0~1 범위 |
| 범위 | 고정되지 않음 | 고정됨 |
| 이상치 | 상대적으로 덜 민감 | 최소·최대에 끌려 크게 왜곡 |
| 자주 쓰는 곳 | 선형/로지스틱 회귀, SVM, PCA | 이미지 픽셀, 신경망 입력 |
| 항목 | 오버샘플링(SMOTE) | 언더샘플링 | 클래스 가중치 |
|---|---|---|---|
| 하는 일 | 소수 클래스를 합성해 늘림 | 다수 클래스를 줄임 | 손실에서 소수 클래스 오류에 큰 페널티 |
| 데이터 손실 | 없음 | 있음 | 없음 |
| 부작용 | 과적합 위험, 학습 시간 증가 | 정보 손실 | 없음(하이퍼파라미터 조정 필요) |
| 주의 | 분할 후 학습셋에만 적용 | 다수 클래스의 다양성 훼손 주의 | 임계값 조정과 함께 보는 것이 좋다 |
| 항목 | IQR | Z-score |
|---|---|---|
| 판정 기준 | Q1 − 1.5×IQR 미만, Q3 + 1.5×IQR 초과 | 평균에서 표준편차 몇 배 이상(예: |z| > 3) |
| 분포 가정 | 없음 | 정규분포에 가깝다고 가정 |
| 치우친 분포 | 견고함 | 왜곡되기 쉬움 |
| 이상치의 영향 | 사분위는 이상치에 둔감 | 평균·표준편차 자체가 오염됨 |
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
IoT 센서 수천 대가 초당 수만 건의 이벤트를 보내고, 여러 독립 애플리케이션이 같은 스트림을 각자 다른 속도로 읽으며 과거 데이터도 재처리해야 한다. 가장 적합한 수집 서비스는?
문제 2
운영 부담을 최소화하면서 스트리밍 데이터를 1분 버퍼링 후 S3에 적재하고, 적재 전 간단한 형식 변환만 하면 된다. 가장 적합한 것은?
문제 3
결정트리 기반 XGBoost 모델을 학습하기 전 전처리를 검토 중이다. 다음 중 효과가 가장 미미하여 우선순위가 낮은 작업은?
문제 4
EDA에서 두 피처의 피어슨 상관계수가 0.96으로 나타났다. 다중공선성을 줄이기 위한 적절한 대응이 아닌 것은?
문제 5
S3 데이터 레이크에 저장된 로그를 데이터 분석가가 클러스터 프로비저닝 없이 표준 SQL로 애드혹 조회하려 한다. 가장 적합한 서비스는?