기준: MLA-C01 시험 가이드오류 제보

MLA-C01· AssociateWeek 10 · Day 4읽기 약 15분

핵심 정리

시험이 어려운 이유는 개념을 몰라서가 아니라 시나리오를 기능으로 번역하지 못해서인 경우가 많다.
순서를 고정한다: 문항을 읽으며 키워드로 정답을 먼저 떠올린 뒤 보기에서 그 이름을 찾는다. 보기부터 읽으면 흔들린다.
혼동 짝은 미세 조건어로 갈린다 — "배포 전 vs 운영 중", "일회 vs 지속", "같은 프레임워크 vs 다른 프레임워크".
3대 함정: 불균형인데 Accuracy, 알고리즘 오매핑, 실시간을 0으로 스케일. 알고만 있으면 즉시 걸러진다.
비용 절감 보기가 다른 요구(성능·가용성·보안)를 깨면 오답이다. 싸다고 정답이 아니다.

Day 4 - 자주 틀리는 함정·키워드: "요구사항 → SageMaker 기능" 번역표

핵심 번역표 — 요구사항 → 기능

이 표가 머릿속에 박히면 종합 문제 풀이 속도가 크게 빨라진다.

데이터·특성

요구사항 키워드	정답 기능
코드 없이 비주얼 데이터 준비	Data Wrangler
내 전처리 스크립트를 관리형 실행	Processing Job
서버리스 ETL·스키마 카탈로그	Glue / Glue Data Catalog
S3를 옮기지 않고 SQL 조회	Athena
실시간 스트림 수집	Kinesis Data Streams / Firehose
사람이 라벨을 붙여야 함	Ground Truth
학습-추론 특성 일관성	Feature Store / 추론 파이프라인
실시간 추론 직전 단건 특성 조회	Feature Store 온라인 스토어
과거 시점 기준 학습 데이터셋 생성	Feature Store 오프라인 스토어
예측이 공정한지/편향 점검	SageMaker Clarify
어떤 특성이 예측에 기여했는지	Clarify (SHAP)

학습·튜닝·평가

요구사항 키워드	정답 기능
학습 비용 절감(중단 허용)	Managed Spot Training + 체크포인트
디스크보다 큰 데이터·시작 지연	Pipe / Fast File 모드
매 epoch 반복 읽기 I/O 병목	FSx for Lustre
적은 시도로 효율적 튜닝	Bayesian
가망 없는 학습 조기 종료	Hyperband
학습 디버깅·병목 분석	SageMaker Debugger
학습 시도들의 지표 비교	SageMaker Experiments
내 PyTorch 스크립트로 학습	프레임워크 Estimator + entry_point
불균형 데이터 성능 평가	F1 / AUC-ROC / Recall

배포·오케스트레이션

요구사항 키워드	정답 기능
저비용·간헐 추론(0 스케일)	서버리스 추론
큰 페이로드·긴 처리·개별 요청	비동기 추론
비용 최저 일괄 점수화	배치 변환
동종 모델 수백 개 비용 절감	멀티모델 엔드포인트(MME)
다른 프레임워크 소수 모델 한 엔드포인트	멀티컨테이너 엔드포인트(MCE)
딥러닝 추론 비용 절감	AWS Inferentia(inf1/inf2)
A/B 테스트·점진 트래픽 이전	프로덕션 변형 가중치
ML 워크플로 자동화·CI/CD	SageMaker Pipelines
기준 통과 시에만 등록	ConditionStep + Model Registry
재학습을 이벤트로 트리거	EventBridge
비-ML 서비스가 많이 섞인 워크플로	Step Functions

모니터링·보안·거버넌스

요구사항 키워드	정답 기능
입력 분포가 변했는지 감지	Model Monitor (Data Quality)
정답 대비 성능 저하 감지	Model Monitor (Model Quality) + ground truth
운영 중 편향 변화 감시	Bias Drift 모니터(Clarify 연동)
운영 중 특성 기여도 변화	Feature Attribution Drift 모니터
인터넷 없이 S3 접근	Gateway VPC 엔드포인트
인터넷 없이 ECR·SageMaker API 접근	Interface 엔드포인트(PrivateLink)
컨테이너 외부 통신 차단	EnableNetworkIsolation
저장 데이터 암호화	KMS
전송 중 암호화	TLS
누가 무슨 API를 호출했나	CloudTrail
지연·오류율 알람	CloudWatch
모델 용도·성능·한계 문서화	Model Cards
데이터→학습→모델 계보 추적	Lineage Tracking
과도한 권한을 가진 노트북·역할	IAM 최소 권한

이 표의 가치는 "보기를 보기 전에 정답을 먼저 떠올리는 것"이다. 시험 보기는 그럴듯한 함정으로 채워져 있어서, 정답을 먼저 정하지 않고 보기를 읽으면 흔들린다. 문제를 읽으며 키워드를 잡아 기능 이름을 머릿속에 적은 뒤, 그 이름이 보기에 있는지 확인하는 순서가 가장 안전하다.

혼동하기 쉬운 짝 — 무엇이 다른가

헷갈리기 쉬운 쌍을 명확히 구분하면 다음과 같다.

혼동 쌍	구분 기준
Model Monitor vs Clarify	운영 중 드리프트 감시=Monitor / 배포 전 일회 편향·설명 분석=Clarify
Data Quality vs Model Quality	입력 분포·스키마 변화 / 정답 대비 성능 저하(라벨 필요)
MME vs MCE	같은 컨테이너·다수 모델 / 다른 프레임워크·소수 모델
비동기 vs 배치 변환	개별 요청을 큐로 받아 S3에 결과 / 전체 데이터셋을 작업 단위로
서버리스 vs 비동기	작은 페이로드·짧은 처리·간헐 / 큰 페이로드·긴 처리·큐
Data Wrangler vs Processing Job	비주얼·코드 없이 / 내 스크립트를 관리형 실행
Feature Store 온라인 vs 오프라인	저지연 단건 조회(실시간) / S3 대량 조회(학습·배치)
Gateway vs Interface 엔드포인트	라우팅 테이블·S3/DynamoDB / ENI·대부분의 서비스
CloudTrail vs CloudWatch	누가 무슨 행위(API 감사) / 시스템 지표·로그·알람
Pipelines vs Step Functions	SageMaker 특화 ML CI/CD / 범용 서비스 오케스트레이션
Bayesian vs Hyperband	적은 시도로 효율 탐색 / 가망 없는 학습 조기 종료
File vs Pipe vs Fast File	전체 복사 / 스트리밍 / 즉시 접근 + 필요분 스트리밍
데이터 병렬 vs 모델 병렬	데이터를 쪼갬(데이터가 많음) / 모델을 쪼갬(GPU에 안 들어감)
Precision vs Recall	오탐 비용이 큼 / 놓침 비용이 큼
추론 파이프라인 vs 프로덕션 변형	순차 체인(전처리→모델) / 트래픽 분배(A/B)
Glue vs EMR	서버리스 ETL·카탈로그 / 클러스터 직접 운영·대규모 Spark

⚠️ 함정: 시험은 이 혼동 쌍을 일부러 같은 문항의 보기로 나란히 놓는다. "편향을 감시하라"에서 Model Monitor의 Bias Drift와 Clarify를 둘 다 보기로 주고, "일회성 사전 점검"이면 Clarify, "운영 중 지속 감시"면 Model Monitor(+Clarify 연동)로 갈린다. 미세한 조건어("배포 전" vs "운영 중", "일회" vs "지속")가 정답을 가른다.

함정 유형 1 — 불균형인데 Accuracy를 고르게 유도

불균형 데이터(사기·질병·이탈)에서 Accuracy를 보기에 매력적으로 배치한다. 99% 정상 데이터에서 "전부 정상" 모델도 정확도 99%다. 정답은 거의 항상 F1·AUC·Recall이다. "놓치면 안 됨"=Recall, "오탐 비용 큼"=Precision.

지표 문제는 "비용 비대칭"을 읽어야 한다. 거짓음성(놓침)의 비용이 크면 Recall, 거짓양성(오경보)의 비용이 크면 Precision, 둘의 균형이 중요하면 F1이다. 임계값(threshold)을 조정하면 Precision-Recall이 트레이드오프된다는 점도 함께 묻는다. 의료 진단처럼 놓침이 치명적이면 임계값을 낮춰 Recall을 올리는 식이다.

"시계열 예측"에 Linear Learner, "이상 탐지"에 K-Means처럼 비슷해 보이는 오답을 준다. 매핑을 확실히: 시계열=DeepAR, 이상치=RCF, 클러스터링=K-Means, 차원축소=PCA, 표 형식 분류/회귀=XGBoost, 추천(희소)=Factorization Machines, 텍스트=BlazingText.

오답 유인	왜 끌리나	정답
시계열 → Linear Learner	"예측=회귀"라는 연상	DeepAR
이상 탐지 → K-Means	"이상치는 군집 밖"이라는 연상	Random Cut Forest
세그먼트 나누기 → XGBoost	"분류=XGBoost"라는 연상	라벨이 없으면 K-Means
추천 → K-Means	"비슷한 사용자 묶기"라는 연상	희소 상호작용이면 Factorization Machines
특성이 너무 많음 → 특성 삭제	단순 직관	PCA로 차원 축소

함정 유형 3 — 실시간을 0으로 스케일하려는 시도

"트래픽이 0까지 떨어지니 실시간 엔드포인트를 0대로 스케일하라"는 보기는 틀린다. 실시간은 최소 1대 유지가 강제다. 0 스케일이 필요하면 서버리스/비동기/배치로 가야 한다. 또 XGBoost에 GPU(p4d)를 붙이는 보기도 함정 — 트리 모델은 CPU가 정답이다.

⚠️ 함정: "비용을 줄여라"는 키워드가 나오면 보기마다 비용 절감 기법이 그럴듯하게 섞인다. 동종 다수 모델→MME, 딥러닝 추론→Inferentia, 간헐 트래픽→서버리스/비동기, 학습 비용·중단 허용→Spot은 맞지만, "XGBoost를 GPU로", "실시간을 0으로", "정확도가 중요한데 데이터를 버려서"는 비용은 줄어도 요구를 깨는 함정이다. 비용 절감이 다른 요구(성능·가용성)를 희생하면 오답이다.

함정 유형 4 — 도구를 원래 용도 밖으로 밀어 넣기

보기가 "존재하는 서비스"를 쓰되 역할을 살짝 비튼다. 서비스 이름이 익숙해서 그냥 넘어가기 쉽다.

함정 보기	왜 틀렸나
Model Monitor가 재학습을 수행한다	Monitor는 감지·알림까지. 재학습은 EventBridge → Pipeline
KMS로 인터넷 접근을 차단한다	KMS는 저장 암호화. 네트워크는 VPC 엔드포인트·격리
CloudTrail로 지연 시간을 모니터링한다	CloudTrail은 API 감사. 지표는 CloudWatch
Clarify로 운영 중 드리프트를 지속 감시한다	지속 감시는 Model Monitor(Clarify 연동)
Debugger로 편향을 측정한다	Debugger는 학습 과정 진단. 편향은 Clarify
Feature Store에 학습 스크립트를 저장한다	Feature Store는 특성 저장소이지 코드 저장소가 아니다
서버리스 추론으로 학습 비용을 줄인다	추론 옵션이라 학습 비용과 무관

함정 유형 5 — 조건을 하나 빠뜨린 "거의 정답"

가장 아픈 함정이다. 조건이 세 개인데 두 개만 만족하는 보기를 정답 옆에 둔다.

[조건 체크 방식]
  문항에서 조건을 뽑는다        조건①  조건②  조건③
        ▼
  보기 A : VPC 엔드포인트만       ✓      ✗      ✗   → 탈락
  보기 B : VPC + 격리             ✓      ✓      ✗   → "거의 정답" 함정
  보기 C : VPC + 격리 + KMS       ✓      ✓      ✓   → 정답
  보기 D : IAM 정책 강화만        ✗      ✗      ✗   → 탈락

조건 개수를 먼저 세고, 보기마다 몇 개를 만족하는지 표시한다.
조건 하나가 "인터넷 비경유", 또 하나가 "외부 유출 차단"처럼 비슷해 보이지만 다른 요구일 때 특히 위험하다.
반대로 조건이 하나뿐인데 구성 요소가 잔뜩 붙은 보기는 "LEAST operational overhead" 기준에서 밀린다.

함정 유형 6 — 최상급 한정어를 흘려 읽기

한정어	무엇을 비교하나	흔한 오답
MOST cost-effective	비용	성능은 좋지만 비싼 구성
LEAST operational overhead	운영 부담	EC2에 직접 구축·자체 스크립트
MOST secure	보안	작동은 하지만 노출 경로가 남는 구성
LEAST latency	지연	배치·비동기처럼 즉시성이 없는 옵션
FASTEST to implement	구현 속도	커스텀 컨테이너·직접 구현

오답 패턴: 증상 → 원인 → 조치

증상	원인	조치
보기를 읽다 마음이 바뀌어 틀린다	정답을 먼저 정하지 않고 보기부터 읽음	키워드→기능 번역을 머릿속에 적은 뒤 보기 확인
혼동 짝에서 매번 반대를 고른다	미세 조건어를 안 읽음	"배포 전/운영 중", "일회/지속"에 밑줄
조건 세 개 중 두 개짜리 보기를 고른다	조건 개수를 세지 않음	조건에 번호를 매기고 보기마다 체크
비용 문항에서 성능을 깨는 보기를 고른다	한정어만 보고 다른 요구를 무시	요구를 깨는 보기는 한정어와 무관하게 탈락
아는 서비스 이름이 보이면 반사적으로 고른다	서비스의 "역할"이 아니라 "이름"으로 판단	그 서비스가 정확히 무엇을 하는지 되뇌기
시간이 모자라 뒤쪽을 못 푼다	한 문항에 과도하게 체류	2분 초과 시 임시 답 + 표시 후 이동

내일은 D-Day 전략으로 마무리한다.

📖 용어

번역표 : 시나리오의 요구사항 키워드를 SageMaker 기능 이름으로 바로 바꿔주는 대응표. 풀이 속도를 좌우한다.
혼동 짝 : 시험이 일부러 같은 문항의 보기로 나란히 놓는 비슷한 두 기능. 미세 조건어로 갈린다.
미세 조건어 : "배포 전 vs 운영 중", "일회 vs 지속", "개별 요청 vs 전체 데이터셋"처럼 정답을 가르는 짧은 수식어.
최상급 한정어 : MOST cost-effective, LEAST operational overhead 등 비교 기준을 지정하는 표현. 여러 보기가 다 작동할 때 정답을 하나로 좁힌다.
거의 정답 함정 : 요구 조건 중 하나를 빠뜨린 보기. 정답 바로 옆에 배치되어 가장 많이 걸린다.
역할 비틀기 함정 : 실제 존재하는 서비스를 원래 용도가 아닌 일에 쓰게 하는 보기(예: Model Monitor가 재학습을 수행).
비용 비대칭 : 거짓양성과 거짓음성의 손실 크기가 다른 상황. 이 비대칭이 Precision·Recall 중 무엇을 볼지 결정한다.
임계값(threshold) : 분류 확률을 양성/음성으로 가르는 기준값. 낮추면 Recall이 오르고 Precision이 내려간다.
소거법 : 요구를 하나라도 위반하는 보기를 지워 후보를 줄이는 풀이 방식.

📝 연습 문제

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

문제 1

배포 전에 모델 예측이 특정 집단에 불공정한지 한 번 점검하고, 동시에 각 특성의 예측 기여도를 SHAP로 보고하려 한다. 가장 적절한 기능은?

문제 2

학습 작업이 중단되어도 재시작할 수 있고 비용을 최대한 절감하려 한다. 단, 마감이 빠듯하지는 않다. 가장 적절한 선택은?

문제 3

다음 중 요구사항과 기능 매핑이 잘못된 것은?

문제 4

트래픽이 업무 시간에만 있고 야간·주말엔 거의 0으로 떨어지는 사내 도구의 추론 비용을 줄이려 한다. 첫 호출의 약간의 지연(콜드 스타트)은 허용된다. 가장 적절한 옵션은?

문제 5

Model Monitor의 Data Quality와 Model Quality 모니터 차이로 가장 정확한 것은?

참고 공식 자료