정답 · 해설

해설

【핵심 용어】 ▸ Parquet — 칼럼 기반 저장 형식, 쿼리 성능 최적화에 탁월 ▸ AWS Glue ETL — 관리형 데이터 변환 서비스 【정답 포인트】 ▸ CSV는 전체 행을 읽어야 하므로 대용량 데이터 쿼리가 비효율적입니다. Parquet는 필요한 칼럼만 읽음으로써 IO를 50-90% 감소시킵니다. AWS Glue는 완전 관리형 서비스로 인프라 관리가 불필요합니다. 【오답 체크】 (A) 파일 분할은 성능 개선이 미미하며 데이터 형식 최적화가 아닙니다. (B) 칼럼 삭제는 쿼리 성능 근본 개선이 아니며 형식 최적화가 필요합니다. (D) EMR은 클러스터 관리가 필요하므로 운영 오버헤드가 높습니다. 【시험 포인트】 최소 오버헤드 + 쿼리 성능 → Glue ETL + Parquet 조합입니다.

해설

【핵심 용어】 ▸ DPL — 클래스 라벨의 비율 차이를 측정, 클래스 불균형 감지용 ▸ 사전학습 편향 메트릭 — 모델 학습 전 데이터 편향 확인 【정답 포인트】 ▸ "클래스 불균형 확인" → 클래스 라벨의 분포 이상을 확인해야 합니다. DPL은 특정 세그먼트에서 양성 클래스 비율이 전체 데이터와 얼마나 다른지 측정하며, DPL 값이 크면 클래스 불균형이 심해서 편향 위험이 높습니다. 【오답 체크】 (A) MSE는 회귀용 손실 함수이며 클래스 라벨 불균형 감지가 불가능합니다. (C) Silhouette score는 비지도 학습(클러스터링)용이며 분류 문제와 무관합니다. (D) SSIM은 이미지 처리용이며 테이블 형식 분류 데이터에 미적용됩니다. 【시험 포인트】 사전학습 편향 측정 = DPL로 클래스 라벨 비율 불균형 확인

해설

【핵심 용어】 ▸ Multi-model endpoint — 단일 엔드포인트에서 여러 모델 호스팅, 동적 로딩 ▸ 추론 비용 최적화 — 컴퓨팅 리소스 효율성 극대화 【정답 포인트】 ▸ "여러 ML 모델" + "비용 최적화" → 공유 리소스 활용이 필수입니다. Multi-model endpoint는 같은 프레임워크의 모델들을 동일 컨테이너에서 로드/언로드하며, 사용하지 않는 모델을 메모리에서 제거해서 메모리를 절약하고 비용을 감소시킵니다. 【오답 체크】 (A) Multi-container는 모든 컨테이너가 메모리에 상주하므로 비용이 높습니다. (C) Sequential invocation은 성능 저하를 야기하며 동시 요청 처리가 불가능합니다. (D) 모델당 별도 엔드포인트는 가장 비용 비효율적입니다. 【시험 포인트】 같은 프레임워크 + 여러 모델 + 비용 최적화 → Multi-model endpoint

해설

【핵심 용어】 ▸ Amazon Rekognition — 컴퓨터 비전 서비스, 객체/동작 감지 자동화 ▸ Amazon A2I — 인간 검수 워크플로우, 머신 예측 + 사람 판단 결합 【정답 포인트】 ▸ 비디오 움직임 분류 → 컴퓨터 비전 + 자동 감지가 필요합니다. Amazon Rekognition이 자동으로 비디오의 동작을 감지하며, A2I가 Rekognition 결과에 대한 인간 검수를 제공해서 라벨 지정 시간을 4개월 대비 훨씬 빠르게 단축할 수 있습니다. 【오답 체크】 (A) Ground Truth는 수동 라벨 지정 조율로 자동화가 부족합니다. (B) JumpStart는 모델 사용/학습용이며 라벨 지정 시간 단축 기능이 없습니다. (C) Data Wrangler는 데이터 변환 도구로 라벨 지정 가속 기능이 없습니다. 【시험 포인트】 비디오 라벨 시간 단축 → Rekognition 자동 감지 + A2I 인간 검수

해설

【핵심 용어】 ▸ SageMaker Clarify — 모델 편향/공정성 모니터링, 피처 중요도 분석 ▸ Model drift 감지 — 배포 후 모델 편향 변화 모니터링 【정답 포인트】 ▸ "시간 경과에 따른 성능 저하" → drift 또는 편향 증가 가능성이 있습니다. SageMaker Clarify는 배포 후 모델의 편향 변화를 지속 모니터링하며, 피처 속성 편향을 감지해서 모델 재학습을 자동으로 트리거할 수 있습니다. 【오답 체크】 (A) Debugger는 학습 중 이상 감지이며 배포 후 자동 재학습 트리거 기능이 약합니다. (B) X-Ray는 요청 지연 시간/에러율 추적이지만 모델 편향 감지는 불가능합니다. (C) Ground Truth는 데이터셋 큐레이션용이며 자동 재학습 트리거 기능이 없습니다. 【시험 포인트】 장기 배포 + 자동 재학습 + 편향 모니터링 → SageMaker Clarify

해설

【핵심 용어】 ▸ Amazon Rekognition eye gaze detection — 눈동자 움직임/응시 방향 감지 ▸ 최소 운영 노력 — 관리형 서비스, 커스텀 개발 최소화 【정답 포인트】 ▸ 차량 카메라 → 이미지/비디오 데이터 수집이 가능합니다. Rekognition은 관리형 컴퓨터 비전 서비스로 즉시 사용 가능하며, Eye gaze detection은 운전 집중도 판단으로 산만함 감지에 직결됩니다. 별도 모델 개발/학습이 불필요해서 최소 운영 노력입니다. 【오답 체크】 (B) SageMaker는 커스텀 모델 학습이 필요해서 개발 노력이 높습니다. (C) 타사 시스템 + Rekognition 통합은 복잡도 증가로 비용이 높습니다. (D) Comprehend는 텍스트 분석이며 카메라 영상 처리가 불가능합니다. 【시험 포인트】 비디오 카메라 + 운전자 안전 + 최소 운영 → Rekognition eye gaze detection

해설

【핵심 용어】 ▸ AWS CDK — Python/TypeScript로 Infrastructure as Code, 프로그래밍 친화적 ▸ Amazon EKS — AWS 관리형 Kubernetes, 컨트롤 플레인 자동 관리 【정답 포인트】 ▸ "Python을 사용하여 프로비저닝" → CDK는 Python/TypeScript를 지원합니다. (CloudFormation은 JSON/YAML) "컨트롤 플레인 관리 불필요" → EKS는 완전 관리형 서비스입니다. "반복 가능한 방식" → Infrastructure as Code가 필수이며 CDK는 Python 코드로 EKS 생성 자동화가 가능합니다. 【오답 체크】 (A) CloudFormation은 JSON/YAML이며 Python이 아닙니다. EC2 직접 관리이므로 컨트롤 플레인 관리가 필요합니다. (B) CLI는 반복 가능한 IaC 제공이 못 됩니다. (D) CloudFormation은 Python 기반이 아닙니다. 【시험 포인트】 Kubernetes + Python IaC + 관리형 → AWS CDK + Amazon EKS

해설

【핵심 용어】 ▸ 오버피팅 — 학습 데이터에 과도 적응, 새 데이터 성능 저하 ▸ 정규화(Regularization) — L1/L2 제약으로 복잡도 제어 【정답 포인트】 ▸ 학습 정확도 높음 + 테스트 성능 저하 → 오버피팅 특징입니다. 오버피팅 해결 → 정규화 + 교차 검증이 필수입니다. Experiments로 여러 정규화 강도/모델 버전을 체계적으로 비교하면서 최적 하이퍼파라미터를 찾아 성능을 개선하고 검증할 수 있습니다. 【오답 체크】 (A) 복잡도 증가는 오버피팅을 악화시키며 근본 해결이 아닙니다. (C) 배포 전 오버피팅 해결이 필요하며 배포 후 조정은 비효율입니다. (D) 데이터 증가만으로는 부족하며 모델 복잡도 제어가 필요합니다. 【시험 포인트】 오버피팅(train high, test low) → 정규화 + 교차검증 + Experiments

해설

【핵심 용어】 ▸ Shadow testing — 신 버전에서 동일 요청 처리, 결과는 사용자에게 미제공 ▸ 프로덕션 영향 최소 — 기존 사용자 경험 변화 없음 【정답 포인트】 ▸ "기존 모델 사용자에게 영향 주지 않고" → 기존 모델은 그대로 운영되어야 합니다. "프로덕션 시나리오에서 평가" → 실제 트래픽으로 테스트해야 합니다. Shadow testing은 100% 트래픽을 신 모델에도 전달해서 정확 성능을 측정하며, 신 모델 결과는 사용자 응답에 미포함되므로 위험이 제로입니다. 【오답 체크】 (A) Linear shifting도 일부 사용자가 신 모델의 영향을 받습니다. (B) Canary도 실제 사용자 트래픽 일부를 신 모델로 라우팅하므로 영향 가능성이 있습니다. (C) Rolling은 점진적 전환으로 기존 모델 일부가 중단됩니다. 【시험 포인트】 기존 무영향 + 실제 트래픽 테스트 → Shadow testing 100%

해설

【핵심 용어】 ▸ AWS Glue — 관리형 ETL 서비스, Data Catalog로 메타데이터 자동 저장 ▸ Glue Crawler — 데이터 스키마 자동 감지, 카탈로그 자동 생성 【정답 포인트】 ▸ "스키마 발견" + "메타데이터 저장" → Glue Crawler가 자동으로 수행합니다. Glue Crawler가 S3 데이터를 스캔해서 스키마를 자동 감지하며, 감지된 스키마는 Data Catalog에 자동 저장됩니다. 분석 도구(Athena, EMR 등)가 Catalog를 활용해서 최소 설정으로 작동합니다. 【오답 체크】 (B) Data Wrangler는 시각적 변환 도구이며 메타데이터 자동 저장 기능이 약합니다. (C) Athena는 쿼리 엔진으로 스키마 감지 기능이 제한적이며 메타데이터 관리가 필요합니다. (D) EC2 직접 관리는 운영 오버헤드가 높고 메타데이터 저장이 수동입니다. 【시험 포인트】 최소 수동 작업 + 스키마 자동 감지 + 메타데이터 저장 → AWS Glue Crawler

해설

【핵심 용어】 ▸ Parquet — 칼럼 기반 저장 형식, 배치/실시간 모두 최적화 ▸ Athena — S3 파일 직접 쿼리, 형식 선택이 성능 좌우 【정답 포인트】 ▸ 배치 처리 → 대용량 데이터 스캔 효율성이 필요합니다. 실시간 쿼리 → 낮은 지연 시간이 필요합니다. Parquet는 칼럼 프루닝으로 필요 칼럼만 읽으며 스냅시 압축이 내장되어 IO를 50-90% 감소시킵니다. Athena + Parquet = 배치/실시간 모두 최상의 성능입니다. 【오답 체크】 (A) CSV는 전체 행을 읽어야 하므로 대규모 데이터 배치 처리가 느립니다. (C) 중첩 JSON은 파싱 오버헤드가 높아서 실시간 쿼리가 느립니다. (D) 역직렬화 JSON도 동일하게 성능 저하가 발생합니다. 【시험 포인트】 Athena + 배치/실시간 혼합 → Parquet이 유일한 최적 선택입니다.

해설

【핵심 용어】 ▸ Cooldown period—최근 확장 후 다음 확장을 시작하기 전 대기 시간 ▸ Scale-out—인스턴스 추가 증가 (수평 확장) ▸ Scale-in—인스턴스 감소 (축소) ▸ Warmup time—신규 인스턴스가 요청 처리 준비 완료 시간 【정답 포인트】 ▸ 문제: 새 인스턴스 시작 전 기존 인스턴스 준비 완료 안 됨 ▸ 원인: 확장 후 쿨다운 너무 짧음→신규 인스턴스 준비 전 또 다른 확장 트리거 ▸ 해결: 확장 후 쿨다운 증가→기존 인스턴스 완전히 준비될 때까지 대기 ▸ 결과: 중복 확장 방지→지연 제거 【오답 체크】 (A)Multi-model endpoint는 확장 문제 해결 아님 (B)Lambda+API Gateway는 레이턴시 추가, 문제 악화 (C)축소 쿨다운 단축은 문제와 무관, 최대 인스턴스 증가는 비용만 증가 【시험 포인트】Scale-out 후 쿨다운 증가→신규 인스턴스 준비 완료까지 대기

해설

【핵심 용어】 ▸ Gateway VPC endpoint—S3/DynamoDB용 특화, 라우트 테이블 통합 ▸ Interface VPC endpoint—대부분의 AWS 서비스용, ENI 생성 ▸ NAT gateway—아웃바운드 인터넷 접근용, 인터넷 게이트웨이 필요 ▸ 인터넷 무경유—프라이빗 네트워크 내 통신만 사용 【정답 포인트】 ▸ "S3 버킷으로 트래픽, 인터넷 무경유"→VPC 엔드포인트 필수 ▸ S3 전용 엔드포인트→Gateway VPC endpoint 최적화 ▸ 엔드포인트 정책으로 S3 버킷 접근 제어 ▸ 라우트 테이블이 S3 트래픽을 엔드포인트로 자동 라우팅 【오답 체크】 (A)NAT gateway는 인터넷 게이트웨이 필요→인터넷 경유 (C)Interface endpoint는 S3에 불필요한 복잡성 추가, ENI 비용 (D)Gateway Load Balancer endpoint는 S3 지원 안 함, NLB 용도 【시험 포인트】S3+프라이빗 네트워크+인터넷 무경유→Gateway VPC endpoint

해설

【핵심 용어】 ▸ XGBoost—랭킹/회귀/분류 모두 가능한 부스팅 앙상블 ▸ K-means clustering—비지도 클러스터링, 순위 매기기 불가 ▸ PCA—차원 감소 기법, 예측 모델 아님 ▸ NTM—토픽 모델링, 텍스트 분석용 【정답 포인트】 ▸ "고객을 순위 매기기"→Ranking 또는 Scoring 필요 ▸ "대출금 상환 가능성"→연속값 스코어 필요→회귀 가능 ▸ XGBoost는 LambdaMART 알고리즘→랭킹 최적화 ▸ SageMaker 내장 XGBoost 제공→직접 사용 가능 【오답 체크】 (B)K-means는 비지도 학습, 고객 순위 매기기 불가 (C)PCA는 피처 축소 기법, 예측/순위 기능 없음 (D)NTM은 토픽 모델링, 수치 타겟 예측 불가 【시험 포인트】고객 랭킹/점수화→XGBoost (회귀/분류/랭킹 통합)

해설

【핵심 용어】 ▸ SageMaker Model Monitor—배포 모델의 drift 감지 전문 ▸ Data drift—입력 데이터 분포 변화 ▸ Concept drift—타겟 변수/피처 관계 변화 ▸ CloudWatch Events—Model Monitor 경보 트리거 ▸ Lambda—경보 기반 자동 재학습 실행 【정답 포인트】 ▸ "배포된 모델의 드리프트 감지"→SageMaker Model Monitor 전문 도구 ▸ Model Monitor가 프로덕션 데이터 모니터링→드리프트 자동 감지 ▸ CloudWatch Events 통합→Lambda 트리거 ▸ Lambda 함수가 재학습 작업(SageMaker Training) 시작 ▸ 완전 자동화 파이프라인 구성 【오답 체크】 (A)Glue는 데이터 파이프라인용, 배포 후 모델 모니터링 기능 약함 (B)Apache Flink는 스트림 처리, 모델 드리프트 감지 전문 아님 (D)QuickSight는 시각화 도구, 자동화된 drift 감지 부족 【시험 포인트】배포 모델+자동 재학습+드리프트 감지→SageMaker Model Monitor+Lambda

해설

【핵심 용어】 ▸ SageMaker Model Registry—모델 버전 관리, 메타데이터 추적, 프로덕션 배포를 위한 중앙화된 저장소 ▸ SageMaker Inference Recommender—실제 트래픽 패턴 분석을 통해 최적의 EC2 인스턴스 유형 추천 【정답 포인트】 ▸ 버전 추적+인스턴스 권장→SageMaker Model Registry+SageMaker Inference Recommender 조합 ▸ Model Registry는 AWS 기본 모델 관리 도구로 버전 관리, 메타데이터, 승인 워크플로우 지원 ▸ Inference Recommender는 모델 성능과 비용을 기반으로 최적 인스턴스 타입 추천 【오답 체크】 (A)ECR은 컨테이너 이미지 저장소일 뿐 모델 버전 관리 기능 부족+Compute Optimizer는 일반 워크로드용이지 SageMaker 추론 최적화 미지원 (B)Autopilot은 자동 모델 학습 서비스로 인스턴스 권장 기능 없음 (D)ECR은 버전 관리 미흡+SageMaker Experiments는 실험 추적 도구로 인스턴스 권장 미지원 【시험 포인트】모델 관리 서비스별 용도 구분→Model Registry(저장소/버전), Inference Recommender(최적화)

해설

【핵심 용어】 ▸ 과적합(Overfitting)—훈련 데이터에는 우수하지만 검증/테스트에서 성능 저하 (99%vs82%) ▸ 정규화(Regularization)—모델 복잡도 제한하여 일반화 능력 향상 ▸ 드롭아웃(Dropout)—훈련 중 무작위로 뉴런 비활성화하여 과적합 방지 【정답 포인트】 ▸ 증상: 훈련/검증 정확도 격차 큼→과적합 진단 ▸ 드롭아웃+정규화(L1/L2)→모델 복잡도 제한으로 검증 성능 개선 ▸ k-폴드 교차검증→검증 안정성 확보, 일반화 능력 검증 【오답 체크】 (A)레이어 추가+배치정규화→오히려 복잡도 증가로 과적합 악화 (조기종료만 유용) (C)PCA 차원축소는 정보손실 야기+레이어 감소는 구조 변경일 뿐 정규화 미흡 (D)데이터 증강/중복제거는 훈련데이터 품질 개선이지 과적합 직접 해결 미흡 【시험 포인트】과적합 증상 인식→정규화 기법(드롭아웃, L1/L2) 적용이 해결책

해설

【핵심 용어】 ▸ AWS Glue Crawler—데이터 소스 자동 스캔하여 AWS Glue Data Catalog 메타데이터 생성/업데이트 ▸ AWS Glue Data Quality—데이터 품질 규칙 정의/실행하여 DQ 메트릭 자동 평가 ▸ 운영 오버헤드 최소화—기존 AWS 서비스로 자동화 【정답 포인트】 ▸ 월간 자동 확인→크롤러+DQ 규칙 조합 ▸ Glue Data Quality는 정상/이상 데이터 패턴 자동 감지 기능 ▸ 추가 코딩/관리 최소화→기본 제공 서비스만 사용 【오답 체크】 (B)Glue 작업으로 구현 가능하나 커스텀 함수 개발/관리 필요→오버헤드 증가 (C)Lambda 수동 실행 또는 S3 이벤트 트리거→일관된 월간 스케줄 관리 복잡+코드 관리 필요 (D)CloudWatch Insights는 로그 분석 도구지 DQ 평가 기능 없음+SQS는 메시징만 담당 【시험 포인트】기본 제공 DQ 기능(Glue Data Quality) 우선→커스텀 코드는 최후의 수단

해설

【핵심 용어】 ▸ SageMaker Model Monitor—프로덕션 모델의 데이터/모델 품질, 편향 모니터링 자동화 도구 ▸ Data Quality 기준선—훈련 데이터 특성 정의하여 추론 시 입력 분포 변화 감지 ▸ emit_metrics—기준선 제약 조건을 CloudWatch 메트릭으로 내보내는 옵션 【정답 포인트】 ▸ 입력 데이터 분포 변화 감지→데이터 품질(Data Quality) 모니터링 ▸ 자동 감지→Model Monitor+기준선 설정으로 실현 ▸ CloudWatch 연동→emit_metrics+알람으로 알림 자동화 【오답 체크】 (B)모델 품질 기준선은 예측/실제값 비교용→입력 분포 변화 감지 미흡 (C)SageMaker Debugger는 훈련 중 모델 디버깅 도구→프로덕션 추론 모니터링 미설계 (D)CloudWatch 직접 관찰+수동 분석→자동화 불가능, 운영 오버헤드 최대 【시험 포인트】Data Drift 감지=SageMaker Model Monitor+Data Quality 기준선

해설

【핵심 용어】 ▸ Serverless 추론—트래픽에 따라 자동 스케일링, 사용 시간만 요금 청구 ▸ 변동 트래픽—일일 트래픽 패턴이 일정하지 않음 ▸ 비용 효율성—유휴 리소스 최소화 【정답 포인트】 ▸ 변동 트래픽+비용 효율→Serverless 추론 ▸ Serverless는 자동 스케일링으로 피크/오프피크 대응 ▸ 시간당 비용 아님→호출 기반 청구로 저비용 【오답 체크】 (A)Batch Transform—예정된 배치 작업용, 실시간 요청 미지원 (B)Asynchronous—실시간이 아닌 지연 가능 작업용 (추천은 즉시 필요) (C)Real-time—상시 실행으로 변동 트래픽 시 비용 낭비 【시험 포인트】변동 트래픽+즉각적 응답=Serverless 추론 엔드포인트