기준: MLS-C01 시험 가이드오류 제보
오늘은 새 지식을 넣지 않는다. 시험장에서 그대로 쓸 수 있는 운영 매뉴얼만 만든다.
| 항목 | 내용 |
|---|---|
| 시험명 | AWS Certified Machine Learning – Specialty (MLS-C01) |
| 문항 수 | 65문항 (채점 50 + 비채점 15, 구분 표시 없음) |
| 시간 | 180분 |
| 합격 점수 | 750 / 1000 (스케일 점수) |
| 문항 유형 | 객관식(택1) + 복수 정답(택2~3) |
| 합격 판정 | 전체 스케일 점수 기준(도메인별 과락 없음) |
| 도메인 | 비중 |
|---|---|
| 1. 데이터 엔지니어링 | 20% |
| 2. 탐색적 데이터 분석 | 24% |
| 3. 모델링 | 36% |
| 4. ML 구현 및 운영 | 20% |
💡 관련 이론: 합격은 도메인별 과락 없이 전체 스케일 점수 750 이상이면 된다. 비채점 15문항은 표시되지 않으므로 모든 문항을 동일하게 성실히 푼다. 스케일 점수는 단순 정답률이 아니라 문항 난이도를 보정한 값이라 "정확히 몇 개 맞히면 합격"이 고정돼 있지 않다. 따라서 특정 도메인을 버리기보다 비중이 가장 큰 도메인 3(36%)에서의 정확도를 끌어올리는 것이 점수 기대값을 가장 크게 높인다.
| 구간 | 권장 |
|---|---|
| 1패스(전체) | 65문항 × 약 2분 = 130분, 확실한 문제부터 |
| 표시(플래그) | 헷갈리면 즉답 후 플래그, 붙잡지 말 것 |
| 2패스(플래그) | 남은 시간으로 재검토 (약 40분) |
| 최종 검토 | 마지막 10분, 마킹 누락 확인 |
💡 관련 이론: 180분/65문항이면 한 문항당 약 2.8분이지만, 쉬운 문항을 1분대에 끝내 어려운 시나리오에 시간을 몰아주는 것이 핵심이다. 한 문항에 4분 이상 매달리는 순간 기대 손실이 커진다. "확신 70% 이상이면 답하고 플래그, 미련 두지 않기"가 페이스를 지키는 규칙이다. 빈칸은 0점이므로 시간이 부족하면 반드시 추정 답이라도 채운다.
| 도메인 | 비중 | 환산 문항 수(비중×65) | 대표 문항 형태 | 권장 페이스 |
|---|---|---|---|---|
| 1. 데이터 엔지니어링 | 20% | 약 13문항 | 수집·저장·ETL 서비스 선택 | 단서가 명확 → 1~1.5분 |
| 2. 탐색적 데이터 분석 | 24% | 약 16문항 | 인코딩·스케일링·불균형·누수 판단 | 1.5~2분 |
| 3. 모델링 | 36% | 약 23문항 | 알고리즘 선택·튜닝·지표·과적합 진단 | 2~3분, 여기에 시간을 몰아준다 |
| 4. ML 구현 및 운영 | 20% | 약 13문항 | 배포 형태·안전 출시·모니터링·비용 | 1.5~2분 |
| 요구사항 문장의 단서 | 정답 방향 |
|---|---|
| "밀리초 지연, 다중 소비자, 재처리" | Kinesis Data Streams |
| "운영 최소화하며 S3로 적재" | Kinesis Data Firehose |
| "스트림에 실시간 SQL 집계" | Kinesis Data Analytics |
| "카메라·영상 스트림 수집" | Kinesis Video Streams |
| "온프레미스 DB를 AWS로 이관" | DMS |
| "대용량 파일 동기화 전송" | DataSync |
| "데이터 레이크 중앙 저장소" | S3 |
| "서버리스로 S3를 SQL 조회" | Athena |
| "대규모 정형 분석 웨어하우스" | Redshift |
| "서버리스 ETL + 스키마 카탈로그" | Glue (스키마 자동 추론=크롤러) |
| "세밀한 하둡/스파크 클러스터 제어" | EMR |
| "결과를 BI 대시보드로" | QuickSight |
| "결측이 소수·무작위" | 평균/중앙값 대치 |
| "결측 자체에 의미가 있음" | 결측 지시 변수 추가 |
| "순서 없는 범주형 인코딩" | One-Hot |
| "순서 있는 등급형 범주" | Ordinal/Label 인코딩 |
| "범주값 종류가 수만 개" | 임베딩·빈도 축소(One-Hot은 차원 폭발) |
| "거리·경사 기반 모델, 스케일 차이" | 표준화/정규화 |
| "트리 모델(XGBoost)인데 스케일링 필수" | 함정(불필요) |
| "분포가 크게 치우침(왜도)" | 로그 변환 |
| "연속값을 구간으로 묶기" | 비닝(binning) |
| "상관 0.9+ 다중공선성" | 피처 제거 또는 PCA |
| "특성이 매우 많고 확장성 우선" | 내장 PCA(algorithm_mode=randomized) |
| "어떤 변수가 쓰였는지 설명" | 특성 선택(원본 컬럼 유지) |
| "군집이 있는지 눈으로 확인" | t-SNE 2D(시각화 전용) |
| "소수 클래스 과소" | SMOTE/오버샘플링/클래스 가중치 |
| "다수 클래스 과다, 데이터 충분" | 언더샘플링 |
| "텍스트를 수치 피처로" | BoW / TF-IDF / 임베딩 |
| "시계열 데이터 분할" | 시점 기준 분할(랜덤 셔플 금지) |
| "전체 데이터로 fit 후 분할" | 데이터 누수(함정) |
| 요구사항 문장의 단서 | 정답 방향 |
|---|---|
| "정형 표 데이터 분류·회귀" | XGBoost, Linear Learner |
| "이미지 분류/탐지" | Image Classification / Object Detection (CNN) |
| "시계열 수요 예측(다중 계열)" | DeepAR |
| "텍스트 분류·임베딩" | BlazingText |
| "문서에서 토픽 추출" | LDA / NTM |
| "라벨 없이 그룹 나누기" | K-Means |
| "이상 탐지" | Random Cut Forest |
| "추천·희소 상호작용" | Factorization Machines |
| "은닉층 활성화 기본" | ReLU |
| "이진 분류 출력 활성화" | Sigmoid |
| "다중 클래스 출력 활성화" | Softmax |
| "회귀 출력 활성화" | 없음(선형) |
| "학습·검증 모두 낮음" | 과소적합 → 복잡도↑·학습 더 |
| "검증만 낮음" | 과적합 → 정규화·증강·조기종료 |
| "학습 데이터가 적은 이미지" | 전이학습 + 데이터 증강 |
| "적은 예산 효율 튜닝" | 베이지안(AMT) |
| "탐색 공간 작고 병렬 자원 충분" | Grid / Random Search |
| "오차 지표 / 성능 지표 방향" | Minimize / Maximize |
| "극단 불균형에서 변별력 비교" | PR-AUC |
| "FP가 비쌈 / FN이 비쌈" | 정밀도 / 재현율 (균형=F1) |
| "회귀 성능 평가" | RMSE / MAE / R² |
| "학습 중 기울기 폭주·소실 진단" | Debugger |
| "대량 오프라인 채점, 엔드포인트 불필요" | Batch Transform |
| "간헐 트래픽, 콜드 스타트 OK" | Serverless Inference |
| "큰 페이로드·긴 처리 큐잉" | Asynchronous Inference |
| "상시 낮은 지연" | Real-time Endpoint |
| "트래픽 변동 대응" | 엔드포인트 Auto Scaling |
| "여러 모델을 한 엔드포인트에" | Multi-Model Endpoint |
| "사용자 영향 없이 트래픽으로 검증" | Shadow 테스트 |
| "위험을 줄이며 점진 전환" | Canary / Linear |
| "배포 후 성능 저하/입력 분포 변화" | Model Monitor (+CloudWatch 알람→재학습) |
| "엔드포인트 지연·에러율·로그" | CloudWatch |
| "누가 어떤 API를 호출했는지 감사" | CloudTrail |
| "집단 공정성·SHAP 설명" | Clarify |
| "학습 비용↓·중단 허용" | Managed Spot Training |
| "워크플로 자동화·재현·CI/CD" | Pipelines + Model Registry |
| "저장·전송 암호화, 접근 통제" | KMS + IAM |
이 번역표를 관통하는 메타 원칙은 세 가지다. (1) "관리 부담을 누가 지는가"로 서버리스/관리형(Firehose·Glue·Athena·Serverless) vs 직접 제어(Streams·EMR·Real-time)가 갈린다. (2) "데이터 형태"가 알고리즘을 정한다(표=XGBoost, 이미지=CNN, 시퀀스=DeepAR/RNN, 텍스트=BlazingText). (3) "지표는 비즈니스 비용의 번역"이라 FP/FN 중 무엇이 비싼지가 정밀도/재현율/F1을 정한다. 모르는 문제도 이 세 축으로 환원하면 정답 영역이 좁혀진다.
| 짝 | 갈리는 기준 | 왼쪽을 고를 때 | 오른쪽을 고를 때 |
|---|---|---|---|
| Sigmoid ↔ Softmax | 출력 클래스 수 | 이진 분류 출력 | 다중 클래스 출력(합=1) |
| Maximize ↔ Minimize | 목적 지표의 방향 | 성능 지표(F1·AUC·정확도) | 오차 지표(RMSE·MAE·loss) |
| Streams ↔ Firehose | 관리 부담과 소비 방식 | 밀리초·다중 소비자·재처리 | 완전관리 적재, 버퍼 후 S3 |
| Canary ↔ Shadow | 사용자에게 결과가 가는가 | 일부 사용자에게 실제 응답, 점진 전환 | 트래픽 복제, 응답 미반환(무위험) |
| 정밀도 ↔ 재현율 | 어떤 오류가 비싼가 | FP(오탐)가 비쌈 — 스팸 분류 | FN(미탐)이 비쌈 — 질병 선별 |
| 오버샘플링 ↔ 언더샘플링 | 데이터 총량이 충분한가 | 소수 클래스가 절대적으로 부족 | 다수 클래스가 과하고 데이터 충분 |
| Model Monitor ↔ CloudWatch ↔ CloudTrail | 무엇을 보는가 | 드리프트(입력 분포·모델 품질) | 인프라 지표·로그 / API 호출 감사 |
| Debugger ↔ Clarify | 학습 과정인가 결과 설명인가 | 학습 중 텐서·기울기 이상 | 편향(Disparate Impact)·SHAP 설명 |
| Batch Transform ↔ Async Inference | 일괄인가 요청 단위인가 | 정해진 데이터셋 전량, 엔드포인트 불필요 | 큰 페이로드·긴 처리, 요청별 큐잉 |
| Glue ↔ EMR | 서버리스인가 클러스터 제어인가 | 빠른 ETL·데이터 카탈로그 | Spark/하둡 세밀 튜닝 |
| Athena ↔ Redshift | 애드혹 조회인가 웨어하우스인가 | S3 위 서버리스 SQL, 간헐 탐색 | 대규모 정형 분석, 상시 BI |
| 함정 | 올바른 판단 |
|---|---|
| 불균형 데이터에 정확도(Accuracy) | F1 / PR-AUC로 (정확도 금지) |
| 트리/XGBoost에 표준화 "필수" | 트리는 스케일 불변, 사실상 불필요 |
| 다중 클래스 출력에 Sigmoid | Softmax가 맞음 |
| 회귀 출력에 Softmax | 선형(활성화 없음)이 맞음 |
| Streams vs Firehose 혼동 | 커스텀/저지연=Streams, 완전관리=Firehose |
| Canary vs Shadow 혼동 | 점진 전환=Canary, 무위험 복제 검증=Shadow |
| Model Monitor vs CloudWatch | 드리프트=Monitor, 인프라 지표=CloudWatch |
| Debugger vs Clarify | 학습 과정=Debugger, 편향·설명=Clarify |
| 대량 오프라인에 Real-time | Batch Transform이 비용 우위 |
| RMSE를 분류에, F1을 회귀에 | 회귀=RMSE/MAE/R², 분류=정밀도/재현율/F1/AUC |
| AMT 목적 지표 방향 | 오차=Minimize, 성능=Maximize |
| 데이터 누수(전처리를 분할 전 전체에) | 학습셋으로 fit, 검증/테스트엔 transform만 |
| 시계열을 랜덤 셔플로 분할 | 시점 기준 분할(과거→미래) |
| 과소적합인데 정규화를 더 강하게 | 반대 — 복잡도를 올리고 더 학습 |
| PCA 전 표준화 생략 | 분산 기반이라 표준화가 선행돼야 함 |
| t-SNE 좌표를 모델 입력으로 | 시각화 전용, 신규 데이터 변환 불가 |
| 배포 후 문제인데 Debugger | 배포 후는 Model Monitor |
| 드리프트 대응으로 CloudTrail | CloudTrail은 API 감사 도구일 뿐 |
| "실시간"만 보고 Real-time Endpoint | 수집의 실시간(Kinesis)과 추론의 실시간은 다른 층위 |
| 장시간 학습 잡을 Lambda로 실행 | SageMaker 학습 잡 / Pipelines |
| 복수 정답 문항에서 개수 무시 | "두 개를 고르시오" 지시를 정확히 셀 것 |
함정의 절반은 "방향 반대"이고 절반은 "도메인 혼동"이다. 방향 함정(Sigmoid↔Softmax, Maximize↔Minimize, Streams↔Firehose)은 짝을 외워두면 즉시 걸러진다. 데이터 누수는 특히 교묘한데, 스케일러·인코더를 학습/검증을 합친 전체에 fit하면 검증 정보가 새어 평가가 낙관 편향된다. 반드시 학습셋으로만 fit하고 검증·테스트에는 transform만 적용한다 — 이 한 줄이 자주 보기로 위장해 출제된다.
지표 : 불균형=F1/PR-AUC · FP비쌈=정밀도 · FN비쌈=재현율 · 회귀=RMSE/MAE/R²
활성화 : 은닉=ReLU · 이진=Sigmoid · 다중=Softmax · 회귀=없음(선형)
튜닝 : 예산 적음=베이지안(AMT) · 오차=Minimize · 성능=Maximize
진단 : 검증만 낮음=과적합 · 둘 다 낮음=과소적합
수집 : 다중소비자·재처리=Streams · 완전관리 적재=Firehose · 실시간SQL=Analytics
저장 : 레이크=S3 · 서버리스SQL=Athena · 웨어하우스=Redshift
ETL : 서버리스=Glue · 클러스터 제어=EMR · DB 이관=DMS
추론 : 상시저지연=Real-time · 간헐=Serverless · 일괄=Batch · 대용량큐=Async
출시 : 점진=Canary · 무위험 복제=Shadow · 병행 전환=Blue/Green
운영 : 드리프트=Model Monitor · 인프라=CloudWatch · 감사=CloudTrail
설명 : 학습 과정=Debugger · 편향·SHAP=Clarify
비용 : 학습=Spot · 추론=Batch/Serverless/Multi-Model
누수 : 학습셋으로만 fit · 시계열은 시점 기준 분할MOST / BEST / LEAST 같은 최상급 어휘에 표시하며 읽기.선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
MLS-C01 시험 구성에 대한 설명으로 옳은 것은?
문제 2
시험 시간 배분 전략으로 가장 권장되는 것은?
문제 3
다음 중 "요구사항 → 서비스" 번역이 잘못된 것은?
문제 4
다음 중 시험에서 자주 등장하는 함정에 대한 올바른 판단은?
문제 5
점수 기대값을 가장 효과적으로 높이는 학습 우선순위로 옳은 것은?