정답 · 해설

해설

【핵심 용어】 ▸ Multi-model Endpoint — 동일 프레임워크의 여러 모델을 하나의 엔드포인트에서 동적 로드 ▸ Multi-container Endpoint — 다양한 프레임워크의 여러 모델을 하나의 엔드포인트 내 별도 컨테이너에서 실행 【정답 포인트】 ▸ "다양한 프레임워크" + "하나의 invoke_endpoint" → Multi-container endpoint는 각 모델이 고유 컨테이너에서 실행되므로 프레임워크 독립적입니다. Single endpoint로 관리 오버헤드 최소화, 비용 효율적입니다. 【오답 체크】 (A) Multi-model endpoint는 동일 프레임워크(예: 여러 XGBoost 모델) 제약이 있어 부적절합니다. (C) 3개 엔드포인트 필요 = 인스턴스 리소스 3배 이상 비용 증가 (D) SparkML은 모델 배포 도구가 아니며 엔드포인트 생성 불가능합니다. 【시험 포인트】 다양한 프레임워크 → Multi-container endpoint / 동일 프레임워크 → Multi-model endpoint 구분이 중요합니다.

해설

【핵심 용어】 ▸ Lifecycle Configuration — 노트북 인스턴스 생성/시작 시 실행되는 스크립트 설정 ▸ auto-stop-idle script — AWS가 제공하는 표준 유휴 종료 스크립트 【정답 포인트】 ▸ "1시간 유휴 후 자동 중지" → Start Notebook section에서 실행되는 라이프사이클 스크립트가 계속 모니터링합니다. GitHub의 auto-stop-idle은 SageMaker 공식 권장 구현입니다. 【오답 체크】 (B) Create Notebook section은 노트북 생성 시만 실행되며 지속적 모니터링 불가능합니다. (C) CloudWatch Logs는 노트북 활동 로깅용이며 Lambda 트리거로 인스턴스 종료는 비표준 구현입니다. (D) 메모리 기반 판단은 신뢰성이 낮으며 실제 유휴 상태를 정확히 반영하지 못합니다. 【시험 포인트】 Lifecycle configuration + auto-stop-idle은 SageMaker 유휴 관리의 표준 패턴입니다.

해설

【핵심 용어】 ▸ Ground Truth Internal Workforce — 조직 내부 직원을 라벨러로 등록하여 관리 ▸ Mechanical Turk — AWS의 크라우드소싱 마켓플레이스로 일반 대중에 작업 공개 【정답 포인트】 ▸ "회사의 라벨링 전문가" + "내부만" → Ground Truth Internal Workforce가 정확한 선택입니다. 회사의 전속 라벨링팀을 AWS 시스템에 통합하여 관리합니다. 【오답 체크】 (A) Data Exchange는 데이터 거래 마켓플레이스이며 라벨링 워크포스 관리 기능 없습니다. (C) Mechanical Turk human loop는 외부 크라우드 워커용이며 내부 팀 관리에 부적절합니다. (D) Mechanical Turk 웹사이트는 AWS Ground Truth 없이 별도 시스템이며 enterprise management 기능이 부족합니다. 【시험 포인트】 내부 라벨러 → Ground Truth Internal Workforce / 크라우드 아웃소싱 → Mechanical Turk

해설

【핵심 용어】 ▸ Serverless Inference — 요청 기반 자동 스케일링으로 유휴 시 0 비용, 콜드 스타트 존재 ▸ Provisioned Concurrency — 워밍 인스턴스를 사전 할당하여 콜드 스타트 제거 【정답 포인트】 ▸ "간헐적 트래픽" + "비용 효율적" → Serverless endpoint가 최적입니다. 트래픽 없을 때 비용 0, 업무 시간에 provisioned concurrency로 응답 시간 보장합니다. 【오답 체크】 (A) Real-time endpoint는 상시 인스턴스 비용이 발생하므로 간헐적 트래픽에는 비용 비효율적입니다. (C) Asynchronous endpoint는 수 분 이상 지연을 수용할 수 있는 배치 처리용이며 실시간 예측 부적절합니다. (D) Lambda 함수로 endpoint 시작/중지는 복잡하고 신뢰성 낮으며 비표준 구현입니다. 【시험 포인트】 간헐적 트래픽 + 비용 최소화 → Serverless endpoint with provisioned concurrency 는 MLA-C01 핵심입니다.

해설

【핵심 용어】 ▸ Ground Truth Annotation Job — 레이블링 작업 정의 및 관리 플랫폼 ▸ Private Workforce — 조직 내부 직원을 레이블러로 사용하는 보안 솔루션 【정답 포인트】 ▸ "직원만 접근" + "높은 정확도" → (C) Ground Truth로 작업 정의 + (D) Private workforce로 내부 직원 관리가 최적 조합입니다. 보안과 품질을 모두 확보합니다. 【오답 체크】 (A) Rekognition은 사전학습 모델로 사용자 특화 라벨링이 불가능합니다. (B) 레이블 없이 모델 훈련은 불가능하며 unsupervised learning이 될 수 없습니다. (E) Mechanical Turk는 일반 대중 크라우드소싱이므로 "직원만 접근" 요구사항을 위반합니다. 【시험 포인트】 Ground Truth + Private workforce = 보안이 필요한 고정확도 내부 라벨링 Ground Truth + Mechanical Turk = 대규모 저비용 크라우드 라벨링

해설

【핵심 용어】 ▸ Profile Job — 데이터 품질 분석/통계 생성용으로 변환은 미지원 ▸ Recipe Job — 데이터 정규화, 정제, 변환을 위한 실제 처리 엔진 【정답 포인트】 ▸ "정리하고 정규화" → Recipe job이 필수적입니다. Profile은 분석만 하고 Recipe가 변환을 실행합니다. S3 경로 직접 연결로 충분합니다. 【오답 체크】 (A) Profile job은 데이터 분석만 지원하며 실제 정규화 변환 기능 없습니다. (C) DataBrew는 S3 경로를 직접 지원하므로 JDBC 연결은 불필요합니다. (D) JDBC는 관계형 DB용이며 S3 직접 액세스보다 복잡합니다. 【시험 포인트】 DataBrew Profile = 분석 / DataBrew Recipe = 변환 은 명확한 구분입니다.

해설

【핵심 용어】 ▸ Glue Relationalize Transform — 중첩된 JSON을 자동으로 정규화하는 빌트인 변환 ▸ 최소 운영 오버헤드 — 완전관리형 서비스, 코드 작성 불필요 【정답 포인트】 ▸ "중첩 JSON → 표 형식" + "최소 오버헤드" → AWS Glue의 Relationalize transform이 표준 솔루션입니다. 선언적 변환으로 코드 작성 불필요하며 완전관리형입니다. 【오답 체크】 (B) 사용자 정의 Scala 코드는 운영 오버헤드 증가하며 기존 기능으로 충분합니다. (C) Lambda는 15분 타임아웃으로 대규모 JSON 처리에 부적절합니다. (D) Athena flatten은 쿼리 시점의 변환이며 데이터 사전 변환 불가능합니다. 【시험 포인트】 JSON → 표 형식 변환 → Glue Relationalize transform이 표준 패턴입니다.

해설

【핵심 용어】 ▸ SageMaker Experiments — 하이퍼파라미터, 메트릭, 아티팩트를 자동 추적하는 ML 실험 플랫폼 ▸ 최소 구현 노력 — 빌트인 자동 추적, 별도 코드 최소화 【정답 포인트】 ▸ "수백 번 훈련 반복" + "특성 + 결과 기록" → SageMaker Experiments가 정확한 선택입니다. 자동 메트릭 수집, 파라미터 추적, 비교 기능이 내장되어 최소 코드로 완벽 추적됩니다. 【오답 체크】 (A) CloudWatch 메트릭은 실시간 모니터링용이며 대규모 파라미터 세트 추적 부적절합니다. (B) 수동 S3 로깅 + Glue 쿼리는 구현 복잡도 높고 관리 오버헤드 큽니다. (C) Model Registry는 검증된 모델 버전 관리용이며 모든 실험 추적 아님입니다. 【시험 포인트】 머신러닝 실험 추적 → SageMaker Experiments는 명확한 선택입니다.

해설

【핵심 용어】 ▸ Bedrock — 서버리스 기초 모델 API로 완전관리형 ▸ Lambda + API Gateway — 서버리스 애플리케이션 계층 ▸ S3 — 벡터 저장용 비용 효율적 스토리지 【정답 포인트】 ▸ "서버리스" + "내부 문서 RAG" → (A) Bedrock Claude + (D) Lambda+API Gateway + (E) S3 조합이 최적입니다. 모두 완전관리형 서버리스이며 RAG 구현에 필수 요소들입니다. 【오답 체크】 (B) SageMaker JumpStart는 관리형이지만 Bedrock보다 운영 오버헤드 높습니다. (C) EC2는 서버리스가 아니며 프로비저닝 및 관리 필요합니다. (F) RDS는 관계형 DB이며 벡터 검색 최적화 부족합니다. 【시험 포인트】 서버리스 + 내부 문서 → Bedrock + Lambda + S3 기반 RAG 패턴입니다.

해설

【핵심 용어】 ▸ Asynchronous Inference — 장시간 처리용으로 S3 입출력 기본 지원 ▸ 최소 운영 오버헤드 — 완전관리형, 자동 스케일링 【정답 포인트】 ▸ "수 분 처리" + "100MB 데이터" + "최소 오버헤드" → Asynchronous endpoint가 정확한 선택입니다. S3에서 대용량 입력 수신, S3로 결과 저장하는 완벽한 구조입니다. 【오답 체크】 (A) EC2 Auto Scaling은 관리 오버헤드 높고 운영 복잡도 증가합니다. (B) Real-time endpoint는 동기식이므로 수 분 대기는 타임아웃 위험 높습니다. (D) ECS는 컨테이너 오케스트레이션 관리 필요하므로 오버헤드 높습니다. 【시험 포인트】 장시간 처리 + 대용량 데이터 → Asynchronous endpoint는 명확한 선택입니다.

해설

【핵심 용어】 ▸ Binary Encoding — 카테고리를 이진 비트로 표현 (2진수로 표현) ▸ Label Encoding — 카테고리를 정수로 매핑 ▸ 차원성 유지 필수 — 특성 개수 증가 금지 【정답 포인트】 ▸ "차원성 증가 금지" → (A) Binary, (B) Label encoding만 가능합니다. 둘 다 2개 카테고리를 1개 차원으로 표현합니다. 【오답 체크】 (C) One-hot은 2개 값당 2개 열로 차원성이 2배 증가합니다. (D) Statistical imputation은 결측값 처리용이며 인코딩이 아닙니다. (E) Tokenization은 텍스트 처리용이며 예/아니오 이진 값 인코딩 부적절합니다. 【시험 포인트】 차원성 유지 필수 → Binary/Label encoding / 차원성 확대 가능 → One-hot

해설

【핵심 용어】 ▸ Factorization Machines — 희소 데이터에서 특성 간 상호작용을 학습하는 추천 알고리즘 ▸ 고차원 희소 데이터 — 많은 특성, 많은 0 값 【정답 포인트】 ▸ "고차원 희소 데이터" + "추천 모델" → Factorization Machines가 정확한 선택입니다. 협업 필터링과 콘텐츠 기반 필터링 모두 지원하며 희소성 극복에 특화되어 있습니다. 【오답 체크】 (A) k-NN은 희소 고차원 데이터에서 거리 메트릭 신뢰성 낮습니다. (C) PCA는 차원 축소용이며 예측 모델이 아닙니다. (D) seq2seq는 시계열/기계번역용이며 추천 알고리즘이 아닙니다. 【시험 포인트】 희소 데이터 추천 → Factorization Machines는 SageMaker 알고리즘 선택의 중요 문제입니다.

해설

【핵심 용어】 ▸ SageMaker Model Registry — 모델 생명주기 관리 및 버전 추적 ▸ 다중 프레임워크 통합 — scikit-learn, TensorFlow 통일 관리 【정답 포인트】 ▸ "여러 팀" + "다양한 노트북 코드" + "통합 인프라" → 모델을 SageMaker 네이티브 형식으로 재구축하고 Model Registry에 등록이 최적입니다. 일관된 관리, 버전 추적, 배포 파이프라인 통합이 용이합니다. 【오답 체크】 (A) API Gateway + Lambda는 복잡하고 Registry 통합이 느슨합니다. (B) 단순 가져오기만으로는 SageMaker 운영 기능 미활용입니다. (C) BYOC는 프레임워크별 커스텀 이미지 유지 오버헤드 높습니다. 【시험 포인트】 다양한 프레임워크 모델 통합 → SageMaker 네이티브 재구축 + Model Registry가 표준입니다.

해설

【핵심 용어】 ▸ SageMaker Training Compiler — 대규모 모델 훈련 최적화 ▸ 실시간 대화형 배포 — 낮은 지연시간 필수 【정답 포인트】 ▸ "LLM 훈련" + "실시간 대화형 배포" → Training Compiler로 최적화된 훈련 + Real-time endpoint로 즉시 응답 구조가 최적입니다. 대규모 모델의 훈련 성능 극대화 및 실시간 사용자 상호작용을 지원합니다. 【오답 체크】 (B) DLC는 훈련 최적화가 Compiler보다 약하며 배포 공식입니다. (C) Notebook Jobs는 대규모 LLM 훈련에 부적절합니다. Async inference는 실시간 대화 부적합합니다. (D) Studio는 개발 환경이며 훈련용 아님입니다. Batch transform은 비대화형입니다. 【시험 포인트】 LLM 훈련 + 실시간 배포 → Training Compiler + Real-time endpoint 조합입니다.

해설

【핵심 용어】 ▸ Shadow Variant — 프로덕션 트래픽 100%를 샘플링하며 실제 사용자 영향 없음 ▸ 무중단 프로덕션 검증 — 기존 모델 영향 제로 【정답 포인트】 ▸ "위험 최소화" + "트래픽 중단 금지" + "프로덕션 검증" → Shadow variant가 유일한 완벽한 솔루션입니다. 실제 사용자 영향 없이 v2를 100% 실시간 데이터로 검증하는 최안전 방법입니다. 【오답 체크】 (A) (B) Canary 배포는 최소 1% 실제 사용자에게 v2 배포하므로 위험 존재합니다. (C) 별도 엔드포인트 + 데이터 캡처는 복잡하고 신뢰성 낮습니다. 【시험 포인트】 무중단 프로덕션 검증 → Shadow variant는 SageMaker 배포 전략의 핵심입니다.

해설

【핵심 용어】 ▸ DisableProfiling — SageMaker training job 메타데이터 수집 비활성화 파라미터 ▸ Training job 수준 제어 — 작업별 세밀한 설정 【정답 포인트】 ▸ "훈련 중 메타데이터 수집 금지" → training job 단위 파라미터 설정이 가장 정확합니다. AWS CLI, Boto3, SageMaker Python SDK의 DisableProfiling=true 파라미터로 각 작업별 제어합니다. 【오답 체크】 (A) CloudWatch 로그 거부는 메트릭/로깅 차단이지만 프로파일링 데이터 메타데이터 차단 불완전합니다. (B) CloudWatch 권한 거부는 IAM 정책 수준이며 세분화 불가능합니다. (C) 콘솔 설정과 SDK 설정 분리로 일관성 부족하며 모든 경로 커버 불가능합니다. 【시험 포인트】 훈련 작업별 메타데이터 opt-out → DisableProfiling 파라미터가 핵심입니다.

해설

【핵심 용어】 ▸ DPL(차이 비율) — 특정 세그먼트에서 양성 클래스의 비율 차이 측정 ▸ 언더샘플링 — 과도하게 대표되는 클래스 샘플 감소 【정답 포인트】 ▸ DPL 값이 +0.9로 매우 높음 → 40~45세 구간에서 양성 클래스가 과도하게 대표됨입니다. 과도하게 대표되는 세그먼트를 줄이려면 언더샘플링 적용이 필요합니다. 【오답 체크】 (A) 오버샘플링하면 이미 과도한 양성 클래스를 더 증가시켜 불균형 악화합니다. (C) 다른 연령대의 양성 클래스를 줄이면 40~45세의 편향은 더 심해집니다. (D) 음성 클래스를 다루는 것은 문제가 되는 양성 클래스의 과도한 표현을 해결하지 못합니다. 【시험 포인트】 DPL 값 해석 → 높은 DPL은 세그먼트에서 양성이 과도 → 언더샘플링으로 correction

해설

【핵심 용어】 ▸ Inter-container traffic encryption — SageMaker 분산 학습에서 컨테이너 간 통신 암호화 ▸ TLS 암호화 — 전송 중 데이터 보호 【정답 포인트】 ▸ 분산 학습에서 여러 인스턴스 간 통신이 발생 → 컨테이너 간 데이터 전송 암호화 필요입니다. SageMaker는 inter-container traffic encryption 옵션을 제공하며 TLS 암호화를 적용합니다. 【오답 체크】 (A) 네트워크 격리는 네트워크 경계를 정의하지만 암호화를 제공하지 않습니다. (B) 보안 그룹은 방화벽 규칙 관리이며 자체적으로 데이터 암호화하지 않습니다. (D) VPC 플로우 로그는 트래픽 로깅만 하며 암호화 기능 없습니다. 【시험 포인트】 분산 학습 + 암호화 필요 → inter-container traffic encryption 옵션입니다.

해설

【핵심 용어】 ▸ Data drift — 시간 경과에 따라 프로덕션 데이터의 분포가 학습 데이터와 달라지는 현상 ▸ 모델 성능 저하 원인 — 데이터 변화로 인한 부적응 【정답 포인트】 ▸ 모델이 장기간 성능 유지 → 학습 데이터 부족은 원인 아닙니다. 갑작스러운 성능 저하 → 실시간 데이터 변화로 인한 drift 발생입니다. 프로덕션 데이터의 특성이 학습 시점의 데이터와 다르면 모델 성능 급감합니다. 【오답 체크】 (A) 이미 학습 완료되어 있으며 긴 시간 성공 → 초기 데이터 부족은 아닙니다. (C) 리소스 제약은 점진적 성능 저하 발생, 급격한 저하 아닙니다. (D) 오버피팅은 학습/테스트 성능 불일치로 초기에 나타남, 배포 후 갑작스럽지 않습니다. 【시험 포인트】 장기 배포 후 갑작스러운 성능 저하 → Data drift 의심 → SageMaker Model Monitor로 감지

해설

【핵심 용어】 ▸ DeepAR — SageMaker 내장 알고리즘, Parquet 형식 권장 ▸ Gzip — 범용 압축 포맷, Parquet과 호환성 우수 【정답 포인트】 ▸ DeepAR 알고리즘은 시계열 데이터 처리 → Parquet 형식이 권장입니다. Parquet는 구조화된 데이터에 최적화된 칼럼 기반 형식이며, gzip은 Parquet과 표준 호환성을 제공하면서 좋은 압축률을 달성합니다. 【오답 체크】 (A) Snappy는 빠른 압축이지만 최적 압축률을 제공하지 않습니다. (B) RecordIO-Protobuf는 시계열 데이터에 부적합하며 DeepAR용이 아닙니다. (C) XZ는 높은 압축률이나 Parquet 처리 시 호환성 문제, 느린 처리가 발생합니다. 【시험 포인트】 DeepAR 시계열 → Parquet 형식 + gzip 압축 조합입니다.