MLA-C01

정답 · 해설

각 문제의 정답과 상세 해설을 정리했습니다. 핵심 용어, 정답 근거, 오답 체크, 시험 포인트까지 읽으며 복습하세요.

1 / 14 페이지

문제 1

한 회사가 Amazon SageMaker를 사용해 웹 기반 AI 애플리케이션을 구축하고 있다. 이 앱은 ML 실험, 학습, 중앙 모델 레지스트리, 모델 배포, 모델 모니터링 기능을 제공해야 한다. ML 라이프사이클 전반에서 학습 데이터의 안전하고 격리된 사용이 보장되어야 하며, 학습 데이터는 Amazon S3에 저장돼 있다. 회사는 애플리케이션의 여러 모델 버전을 관리하기 위해 중앙 모델 레지스트리를 사용해야 한다. 운영 부담(operational overhead)이 가장 적은 방법은?

A. 모델마다 별도의 Amazon Elastic Container Registry (ECR) 레포지토리를 생성한다.
B. Amazon ECR을 사용하고 모델 버전마다 고유 태그를 부여한다.
C. SageMaker Model Registry와 model group을 사용해 모델을 카탈로그화한다.✓ 정답
D. SageMaker Model Registry를 사용하고 모델 버전마다 고유 태그를 부여한다.

해설

【핵심 용어】 ▸ SageMaker Model Registry — ML 모델의 중앙 카탈로그. 버전 관리·승인·배포 워크플로 제공. ▸ Model Group — 동일한 목적을 가진 모델 버전들의 묶음. Model Group에 새 Model Package가 추가될 때마다 버전 번호가 1,2,3…로 자동 증가. 【정답 포인트】 ▸ "중앙 모델 레지스트리"·"여러 버전 관리"·"LEAST operational overhead" → Model Registry + Model Group이 네이티브 솔루션. ▸ Model Group은 자동 버전 관리를 제공하므로 태그로 수작업 관리할 필요가 없음. 【오답 체크】 (A) ECR은 컨테이너 이미지 저장소이지 모델 레지스트리가 아님. 운영 부담 큼. (B) 같은 이유로 ECR은 부적절. (D) Model Registry를 사용하더라도 Model Group 없이 태그만으로 관리하면 수작업 부담 발생 → Group이 정답. 【시험 포인트】 "central model registry" + "versioning" + "LEAST operational overhead" = SageMaker Model Registry + Model Groups.

문제 2

한 회사가 Amazon SageMaker를 사용해 웹 기반 AI 애플리케이션을 구축하고 있다. 앱은 ML 실험, 학습, 중앙 모델 레지스트리, 모델 배포, 모델 모니터링 기능을 제공해야 한다. 학습 데이터는 Amazon S3에 저장돼 있고, 회사는 연속적인 학습 작업(consecutive training jobs)을 실험하고 있다. 이 작업들의 인프라 시작 시간(startup time)을 최소화하려면?

A. Managed Spot Training을 사용한다.
B. SageMaker managed warm pools를 사용한다.✓ 정답
C. SageMaker Training Compiler를 사용한다.
D. SageMaker distributed data parallelism (SMDDP) 라이브러리를 사용한다.

해설

【핵심 용어】 ▸ SageMaker Managed Warm Pool — 학습 작업 완료 후 인스턴스를 일정 시간 유지하여 다음 학습 작업에서 재사용. 프로비저닝(인프라 준비) 시간을 크게 단축. ▸ Managed Spot Training — 비용 절감(최대 90%)용. 시작 시간과는 무관. ▸ Training Compiler — 학습 성능(GPU 활용률) 최적화용. 시작 시간과는 무관. ▸ SMDDP — 다중 인스턴스 분산 학습 속도 가속용. 【정답 포인트】 ▸ "연속 학습 작업 startup time 최소화" → Warm Pool이 정확한 네이티브 기능. ▸ 기본적으로 학습 작업은 시작 시 새 인스턴스 프로비저닝으로 수 분 소요 → Warm Pool 사용 시 이 시간을 절약. 【오답 체크】 (A) Spot은 비용 절감, 시작 시간 단축 아님. (C) Training Compiler는 학습 최적화, 인프라 시작 시간과 무관. (D) SMDDP는 분산 학습 가속, 시작 시간과 무관. 【시험 포인트】 "startup time" + "consecutive training jobs" = Warm Pool. "reduce training cost" = Spot. "optimize training compute" = Training Compiler. "speed up training across instances" = SMDDP.

문제 3

한 회사가 Amazon SageMaker를 사용해 웹 기반 AI 애플리케이션을 구축 중이다. 앱은 ML 실험, 학습, 중앙 모델 레지스트리, 모델 배포, 모델 모니터링 기능을 제공해야 한다. 학습 데이터는 S3에 저장돼 있다. 회사는 승인된 모델만 운영 엔드포인트(production endpoints)에 배포될 수 있도록 수동 승인 기반 워크플로를 구현해야 한다. 어떤 솔루션이 요구사항을 만족하는가?

A. SageMaker Experiments를 사용해 모델 등록 중 승인 프로세스를 지원한다.
B. 중앙 모델 레지스트리에서 SageMaker ML Lineage Tracking을 사용하고, 승인 프로세스용 tracking entity를 만든다.
C. SageMaker Model Monitor로 모델 성능을 평가하고 승인을 관리한다.
D. SageMaker Pipelines를 사용한다. 모델 버전이 등록되면 AWS SDK로 승인 상태를 "Approved"로 변경한다.✓ 정답

해설

【핵심 용어】 ▸ SageMaker Model Registry 승인 상태 — 각 Model Package(버전)는 "PendingManualApproval", "Approved", "Rejected" 상태를 가짐. ▸ SageMaker Pipelines — ML 워크플로 오케스트레이터. condition step 또는 외부 AWS SDK 호출로 승인 상태를 변경 가능. ▸ ML Lineage Tracking — 아티팩트·데이터셋·작업 간의 계보 추적. 승인 워크플로와 무관. ▸ Model Monitor — 배포된 모델의 드리프트 탐지. 승인 워크플로와 무관. ▸ SageMaker Experiments — 실험 비교·추적용. 승인 워크플로와 무관. 【정답 포인트】 ▸ "수동 승인 기반 워크플로" = Model Registry의 Approval Status + Pipelines 통합. ▸ Pipelines에서 학습 후 모델 버전이 등록되면, 외부 검토 후 AWS SDK로 상태를 Approved로 업데이트 → 배포 단계가 이 상태를 조건으로 트리거. 【오답 체크】 (A) Experiments는 실험 추적 도구로 승인 기능 없음. (B) Lineage Tracking은 계보 가시성용, 승인 플로 아님. (C) Model Monitor는 운영 중 드리프트 감지용이지 배포 전 승인용 아님. 【시험 포인트】 "manual approval" + "deployment" = SageMaker Pipelines + Model Registry Approval Status. 배포 전 체크포인트로서의 승인 = Pipelines의 정석 패턴.

문제 4

회사가 Amazon SageMaker를 사용하여 웹 기반 AI 애플리케이션을 구축하고 있습니다. 애플리케이션은 ML 실험, 학습, 중앙 모델 레지스트리, 모델 배포 및 모델 모니터링 기능을 제공합니다. ML 라이프사이클 동안 학습 데이터의 안전하고 격리된 사용을 보장해야 합니다. 학습 데이터는 Amazon S3에 저장되어 있습니다. 회사는 실시간 endpoint로 배포된 모델의 bias drift를 모니터링하기 위해 온디맨드 워크플로우를 실행해야 합니다. 어떤 조치가 이 요구사항을 충족할까요?

A. 애플리케이션을 구성하여 SageMaker Clarify job을 실행하는 AWS Lambda 함수를 호출합니다.✓ 정답
B. sagemaker-model-monitor-analyzer 기본 제공 SageMaker 이미지를 가져오는 AWS Lambda 함수를 호출합니다.
C. AWS Glue Data Quality를 사용하여 bias를 모니터링합니다.
D. SageMaker notebook을 사용하여 bias를 비교합니다.

해설

【핵심 용어】 ▸ SageMaker Clarify — 모델 예측의 bias와 feature importance를 감지·분석하는 AWS 관리형 서비스. 모델 배포 후 실시간 bias drift 모니터링에 최적화. ▸ Model Monitor — SageMaker 내 모델 품질 저하(data drift, bias drift 등)를 지속적으로 감지하는 모니터링 솔루션. ▸ AWS Lambda — 온디맨드 워크플로우 트리거를 위한 서버리스 컴퓨팅. 스케줄링된 job 실행에 이상적. 【정답 포인트】 ▸ 문제의 핵심: "on-demand workflow" + "monitor bias drift" + "real-time endpoints" ▸ SageMaker Clarify는 정확히 실시간 배포 모델의 bias를 감지하기 위해 설계됨. ▸ Lambda로 온디맨드 워크플로우를 트리거하면, 필요할 때만 Clarify job을 실행하여 비용 효율적. 【오답 체크】 (B) sagemaker-model-monitor-analyzer는 Model Monitor를 위한 내부 이미지일 뿐, bias drift 감지 기능은 Clarify에 있음. 또한 직접 이미지를 pulling하는 것은 불필요한 복잡도 증가. (C) AWS Glue Data Quality는 데이터 품질(null, duplicates 등)을 감시하는 도구이지, ML 모델의 bias drift 감지 기능은 없음. (D) SageMaker notebook을 수동으로 사용하는 것은 "on-demand workflow" 요구사항과 맞지 않으며, 자동화되지 않음. 【시험 포인트】 "bias drift" + "real-time monitoring" + "on-demand" → **SageMaker Clarify + Lambda**. Clarify는 deployment bias 감지 전담, Lambda는 트리거 자동화.

문제 10

ML 엔지니어가 AWS에서 부정거래 탐지 모델을 개발 중입니다. 학습 데이터셋에는 거래 로그, 고객 프로필 및 온프레미스 MySQL 데이터베이스의 테이블이 포함되어 있습니다. 거래 로그와 고객 프로필은 Amazon S3에 저장되어 있습니다. 데이터셋은 모델 알고리즘의 학습에 영향을 미치는 클래스 불균형을 가지고 있습니다. 또한 많은 feature들이 상호 의존성을 가지고 있습니다. 알고리즘이 데이터의 모든 원하는 기본 패턴을 포착하지 못하고 있습니다. 여러 데이터 소스의 데이터를 수집할 수 있는 AWS 서비스 또는 기능은 무엇입니까?

A. Amazon EMR Spark job
B. Amazon Kinesis Data Streams
C. Amazon DynamoDB
D. AWS Lake Formation✓ 정답

해설

【핵심 용어】 ▸ AWS Lake Formation — 다양한 소스(S3, RDS, on-premises DB 등)에서 데이터를 수집하고 정규화하여 중앙 데이터 레이크를 구축하는 AWS 관리형 서비스. 메타데이터 관리, 카탈로그화, 접근 제어 포함. ▸ Amazon EMR Spark job — 빅데이터 처리 프레임워크. 데이터 수집보다는 이미 준비된 데이터를 변환·분석하는 데 사용. ▸ Amazon Kinesis Data Streams — 실시간 스트림 수집 서비스. 배치 데이터 집계가 아닌 연속적인 이벤트 스트림에 최적화. ▸ Amazon DynamoDB — NoSQL 데이터베이스. 데이터 수집·집계 기능이 없음. 【정답 포인트】 ▸ 문제의 핵심: "aggregate data from various data sources" (S3, on-premises MySQL) ▸ Lake Formation은 여러 이종(heterogeneous) 데이터 소스를 단일 데이터 레이크로 통합·관리하기 위해 설계됨. ▸ 온프레미스 DB와 S3 양쪽을 지원하는 유일한 서비스. 【오답 체크】 (A) EMR Spark는 데이터 처리·변환 도구이지, 이종 소스에서 데이터를 "aggregate/수집"하는 것이 목적이 아님. 이미 준비된 데이터를 입력받아 ETL을 수행. (B) Kinesis는 실시간 스트림 데이터(예: IoT 센서, 로그 스트림)를 수집하는 서비스. 정적인 S3 객체와 on-premises DB를 배치로 집계하는 데는 부적절. (C) DynamoDB는 단순 데이터베이스일 뿐 데이터 소스 통합·집계 기능이 없음. 【시험 포인트】 "multiple data sources" + "aggregate" + "structured+unstructured" → **AWS Lake Formation**. on-premises DB 포함 여부가 핵심: Lake Formation만 지원.

문제 11

ML 엔지니어가 AWS에서 부정거래 탐지 모델을 개발 중입니다. 데이터가 수집된 후, ML 엔지니어는 데이터의 이상값을 자동으로 감지하고 결과를 시각화하는 솔루션을 구현해야 합니다. 어떤 솔루션이 이 요구사항을 충족할까요?

A. Amazon Athena를 사용하여 이상값을 자동으로 감지하고 결과를 시각화합니다.
B. Amazon Redshift Spectrum을 사용하여 이상값을 자동으로 감지합니다. Amazon QuickSight를 사용하여 결과를 시각화합니다.
C. Amazon SageMaker Data Wrangler를 사용하여 이상값을 자동으로 감지하고 결과를 시각화합니다.✓ 정답
D. AWS Batch를 사용하여 이상값을 자동으로 감지합니다. Amazon QuickSight를 사용하여 결과를 시각화합니다.

해설

【핵심 용어】 ▸ SageMaker Data Wrangler — 데이터 준비 및 시각화 전용 도구. 이상값 감지(anomaly detection), 통계 분석, 자동 변환, 인터랙티브 시각화를 단일 UI에서 제공. 코드 작성 불필요. ▸ Amazon Athena — SQL 쿼리 엔진. 데이터 쿼리는 가능하지만 이상값 "자동 감지" 기능이 없음. ▸ Amazon Redshift Spectrum — 데이터 웨어하우스 쿼리 서비스. Athena와 유사하게 분석은 하지만 자동 이상값 감지 기능 없음. ▸ AWS Batch — 배치 컴퓨팅. 사용자가 직접 이상값 감지 로직을 작성해야 함 → 개발 오버헤드 증가. 【정답 포인트】 ▸ 문제의 핵심: "automatically detect anomalies" + "visualize the result" ▸ Data Wrangler는 정확히 데이터 품질 문제(이상값, 아웃라이어)를 자동으로 식별하고 시각화하도록 설계됨. ▸ 내장 통계 변환(IQR, z-score 등)으로 코드 작성 없이 이상값 감지 가능. ▸ 동일 도구 내에서 감지와 시각화를 함께 수행 → "all-in-one" 솔루션. 【오답 체크】 (A) Athena는 SQL 쿼리만 실행 → 이상값을 "자동 감지"하려면 별도 쿼리 로직 작성 필요. 시각화도 지원하지 않음. (B) Redshift Spectrum + QuickSight 조합은 데이터 탐색에는 좋지만, Spectrum은 이상값 자동 감지 기능이 없어 사용자 정의 SQL 필요. (D) AWS Batch는 컨테이너 기반 배치 작업 관리일 뿐, 이상값 감지 로직은 사용자가 직접 구현해야 함 → 개발 부담 높음. 【시험 포인트】 "automatically detect anomalies" + "visualize" + "LEAST code" → **SageMaker Data Wrangler**. 내장 통계 변환 + 인터랙티브 UI.

문제 12

ML 엔지니어가 AWS에서 부정거래 탐지 모델을 개발 중입니다. 학습 데이터셋에는 카테고리형 데이터와 수치형 데이터가 포함되어 있습니다. ML 엔지니어는 모델의 정확도를 최대화하기 위해 학습 데이터셋을 준비해야 합니다. 어떤 조치가 운영 부담이 가장 적으면서 이 요구사항을 충족할까요?

A. AWS Glue를 사용하여 카테고리형 데이터를 수치형 데이터로 변환합니다.
B. AWS Glue를 사용하여 수치형 데이터를 카테고리형 데이터로 변환합니다.
C. Amazon SageMaker Data Wrangler를 사용하여 카테고리형 데이터를 수치형 데이터로 변환합니다.✓ 정답
D. Amazon SageMaker Data Wrangler를 사용하여 수치형 데이터를 카테고리형 데이터로 변환합니다.

해설

【핵심 용어】 ▸ SageMaker Data Wrangler — 데이터 준비 UI 도구. 카테고리형 데이터를 수치형으로 변환(encoding: one-hot, label encoding 등)하는 내장 변환 제공. 코드 없이 클릭만으로 수행. ▸ AWS Glue — ETL 서비스. 데이터 변환을 위해 Apache Spark job을 작성·관리해야 함. 개발 시간 필요. ▸ Feature encoding — 머신러닝 모델이 처리할 수 있도록 범주형 변수를 수치형으로 변환하는 필수 전처리. 【정답 포인트】 ▸ 문제의 핵심: "categorical data" + "numerical data" → 인코딩 필요 ▸ "LEAST operational overhead" = 코드 작성 최소화 ▸ Data Wrangler는 내장 인코딩 변환(one-hot, ordinal, target encoding 등)으로 몇 클릭만에 완료. ▸ Glue는 job 작성, 배포, 모니터링이 필요 → 운영 부담 증가. 【오답 체크】 (A) Glue를 사용하면 PySpark/Scala 코드를 작성·테스트해야 하므로 개발 오버헤드 발생. Data Wrangler보다 느림. (B) 수치형을 카테고리형으로 변환하는 것은 정확도 향상에 직접 기여하지 않음. 오히려 정보 손실 가능 (binning은 특수 경우만). (D) (B) 와 동일 이유. 또한 이미 수치 데이터가 있다면 굳이 변환할 이유 없음. 【시험 포인트】 "categorical → numerical" + "LEAST operational overhead" → **SageMaker Data Wrangler**. 내장 encoding UI, 코드 불필요.

문제 13

ML 엔지니어가 AWS에서 부정거래 탐지 모델을 개발 중입니다. ML 엔지니어는 모델을 학습하기 전에 불균형 데이터 문제를 해결해야 합니다. 어떤 솔루션이 운영 노력이 가장 적으면서 이 요구사항을 충족할까요?

A. Amazon Athena를 사용하여 불균형에 기여하는 패턴을 식별합니다. 그에 따라 데이터셋을 조정합니다.
B. Amazon SageMaker Studio Classic 기본 제공 알고리즘을 사용하여 불균형 데이터셋을 처리합니다.
C. AWS Glue DataBrew 기본 제공 기능을 사용하여 소수 클래스를 오버샘플링합니다.
D. Amazon SageMaker Data Wrangler balance data 연산을 사용하여 소수 클래스를 오버샘플링합니다.✓ 정답

해설

【핵심 용어】 ▸ SageMaker Data Wrangler balance data operation — 클래스 불균형을 해결하기 위한 내장 기능. oversampling/undersampling을 한 번의 클릭으로 자동 수행. 코드 작성 불필요. ▸ Class imbalance — 한 클래스의 샘플이 다른 클래스보다 훨씬 많은 데이터 문제. 모델이 다수 클래스에 편향됨. ▸ Oversampling — 소수 클래스 샘플을 복제하거나 synthetic하게 생성(SMOTE)하여 클래스 비율을 균형있게 만드는 기법. 【정답 포인트】 ▸ 문제의 핵심: "imbalanced data" + "LEAST operational effort" ▸ Data Wrangler의 "balance data" 연산은 정확히 이 목적으로 설계됨. 클릭 하나로 oversampling 수행. ▸ 다른 옵션들은 모두 수동 작업이나 추가 개발이 필요. 【오답 체크】 (A) Athena는 데이터 분석 쿼리 도구. 불균형을 "식별"할 수 있지만 자동으로 "해결"하지 못함. 사용자가 수동으로 sampling 로직을 구현해야 함. (B) SageMaker Studio Classic의 기본 알고리즘은 불균형을 "처리"할 수 있지만(예: class weights), 이는 학습 중의 대응일 뿐 데이터 준비 단계의 해결이 아님. 또한 모든 알고리즘이 class weights를 지원하는 것은 아님. (C) AWS Glue DataBrew는 데이터 품질(missing values, duplicates 등)에 초점. 클래스 불균형 "오버샘플링" 기능이 없음. 사용자가 custom recipe를 작성해야 함. 【시험 포인트】 "class imbalance" + "LEAST operational effort" → **SageMaker Data Wrangler balance data**. SMOTE/oversampling 자동화.

문제 14

ML 엔지니어가 AWS에서 부정거래 탐지 모델을 개발 중입니다. ML 엔지니어는 모델을 학습하기 위해 Amazon SageMaker 기본 제공 알고리즘을 사용해야 합니다. ML 엔지니어는 어떤 알고리즘을 사용해야 할까요?

A. LightGBM✓ 정답
B. Linear learner
C. K-means clustering
D. Neural Topic Model (NTM)

해설

【핵심 용어】 ▸ LightGBM — 부정거래 탐지, 이탈 예측 등 binary classification 문제에 최적화된 gradient boosting 트리 모델. SageMaker 기본 제공 알고리즘. ▸ Linear learner — 선형 회귀/분류 알고리즘. feature 간 비선형 상호작용(interdependencies)을 포착하지 못함. ▸ K-means clustering — 비지도학습 알고리즘. 레이블이 있는 부정거래 탐지(지도학습)에는 부적절. ▸ NTM (Neural Topic Model) — 텍스트 토픽 추출용 비지도학습. 거래 로그 및 고객 프로필 수치 데이터에 부적합. 【정답 포인트】 ▸ 문제의 핵심: "fraud detection" (binary classification) + "feature interdependencies" (비선형 관계) + "SageMaker built-in algorithm" ▸ LightGBM은 정확히 이 요구사항 충족: gradient boosting으로 비선형 패턴 포착, feature interaction 자동 학습, 부정거래 탐지에 산업 표준. ▸ SageMaker에서 공식 지원되는 LightGBM 용기 이미지 제공. 【오답 체크】 (B) Linear learner는 선형 결정 경계만 학습. 거래 데이터의 "많은 feature 상호의존성"을 포착할 수 없음. 부정거래는 복잡한 비선형 패턴. (C) K-means는 비지도학습 clustering 알고리즘. 부정/정상 레이블이 있는 classification 문제에 사용되지 않음. 또한 "이상값 탐지"와 "분류" 목표가 다름. (D) NTM은 텍스트 문서의 토픽 분포를 학습하는 알고리즘. 거래 로그와 고객 프로필의 구조화된 수치/카테고리 데이터에는 전혀 맞지 않음. 【시험 포인트】 "fraud detection" + "feature interdependencies" + "SageMaker built-in" → **LightGBM** (또는 XGBoost). gradient boosting은 비선형 상호작용 자동 학습.

문제 15

회사가 XGBoost 예측 모델을 프로덕션에 배포하여 고객이 구독을 취소할 가능성을 예측합니다. 회사는 Amazon SageMaker Model Monitor를 사용하여 F1 score의 편차를 감지합니다. 모델 품질의 기준선 분석 동안 회사가 F1 score에 대한 임계값을 기록했습니다. 몇 개월 동안 변화가 없었으나 모델의 F1 score가 크게 감소했습니다. F1 score 저하의 원인은 무엇일까요?

A. 예측에 사용되는 기본 고객 데이터에서 concept drift가 발생했습니다.✓ 정답
B. 모델이 원래 기준선 데이터의 모든 패턴을 포착할 만큼 충분히 복잡하지 않았습니다.
C. 원래 기준선 데이터에 누락된 값의 데이터 품질 문제가 있었습니다.
D. Model Monitor의 기준선 계산 중 잘못된 ground truth 레이블이 제공되었습니다.

해설

【핵심 용어】 ▸ Concept drift — 시간 경과에 따라 입력 데이터(feature) 또는 타겟 변수의 분포가 변하는 현상. 기준선과 프로덕션 데이터의 특성이 달라짐. 모델 성능 저하의 주요 원인. ▸ Data drift — feature 분포만 변함 (개인의 소비 행동 패턴 변화 등). ▸ SageMaker Model Monitor — 배포된 모델의 performance metric(F1, precision 등) 저하를 지속적으로 감시. ▸ Baseline — 초기 학습 데이터의 모델 성능 기준점. 【정답 포인트】 ▸ 문제의 시간 흐름: 기준선 분석 시 F1 OK → 몇 개월 후 F1 급락 ▸ "몇 개월" = 실제 운영 환경에서 데이터 분포가 변했다는 신호. 고객 이탈 패턴 자체가 변함 (경제 상황, 경쟁사, 요금 변경 등). ▸ 모델은 과거 데이터로 학습했으나, 현재 고객의 이탈 결정 요인이 달라짐 → concept drift. 【오답 체크】 (B) 모델 복잡도 부족이면 "처음부터" (기준선 분석 시점에서도) F1이 낮아야 함. "몇 개월 후에 갑자기 감소"한다면 모델 능력이 아니라 데이터 변화 때문. (C) 기준선 데이터의 품질 문제(missing values)라면 기준선 분석 당시에 이미 F1이 낮았을 것. "이후 갑자기 저하"와는 관계 없음. (D) Ground truth 레이블 오류는 기준선 계산 시점의 문제. 이후 몇 개월간의 성능 저하를 설명하지 못함. 또한 Model Monitor는 실시간 prediction drift를 감시하지, 과거 기준선 레이블을 재검증하지 않음. 【시험 포인트】 "months later" + "F1 score suddenly decreases" → **Concept drift**. 데이터 분포 변화(고객 이탈 패턴 변화)가 모델 성능 저하의 주된 원인. 모델 재학습 필요.

문제 16

데이터 과학 팀이 Amazon SageMaker notebook 인스턴스를 사용하여 ML 모델을 테스트합니다. 데이터 과학자가 새로운 권한이 필요할 때마다, 회사는 SageMaker notebook 인스턴스 생성 중에 생성된 각 개별 역할에 권한을 추가합니다. 회사는 팀의 권한 관리를 중앙화해야 합니다. 어떤 솔루션이 이 요구사항을 충족할까요?

A. 필요한 권한이 있는 단일 IAM 역할을 생성합니다. 팀이 사용하는 각 notebook 인스턴스에 역할을 추가합니다.✓ 정답
B. 단일 IAM 그룹을 생성합니다. 데이터 과학자를 그룹에 추가합니다. 팀이 사용하는 각 notebook 인스턴스에 그룹을 연결합니다.
C. 단일 IAM 사용자를 생성합니다. AdministratorAccess AWS 관리형 IAM 정책을 사용자에게 추가합니다. 각 notebook 인스턴스를 IAM 사용자를 사용하도록 구성합니다.
D. 단일 IAM 그룹을 생성합니다. 데이터 과학자를 그룹에 추가합니다. IAM 역할을 생성합니다. AdministratorAccess AWS 관리형 IAM 정책을 역할에 추가합니다. 역할을 그룹과 연결합니다. 그룹을 각 notebook 인스턴스와 연결합니다.

해설

【핵심 용어】 ▸ IAM Role (역할) — AWS 서비스(EC2, SageMaker 등)가 맡을 수 있는 권한 모음. 사용자가 아닌 "서비스"에 할당됨. ▸ IAM User (사용자) — 사람에게 할당되는 자격증명(AccessKey 등). 서비스에 직접 할당되지 않음. ▸ IAM Group (그룹) — 여러 사용자를 묶어 한 번에 권한 할당. 하지만 SageMaker notebook 인스턴스에 직접 "attach"할 수 없음. ▸ Notebook execution role — SageMaker notebook이 AWS 리소스(S3, ECR 등)에 접근할 때 맡는 IAM 역할. 【정답 포인트】 ▸ 문제의 핵심: "centralize management of permissions" + "multiple notebook instances" ▸ SageMaker notebook 인스턴스는 "IAM 역할"을 인수하고 실행함. 사용자나 그룹을 직접 지정할 수 없음. ▸ 단일 IAM 역할을 생성하고 모든 notebook에 "attach"하면, 권한 수정 시 역할 정책만 업데이트하면 모든 노트북에 즉시 반영. ▸ 여러 notebook에서 각각의 역할을 관리하는 것보다 중앙화됨. 【오답 체크】 (B) IAM 그룹은 "사용자" 관리용. SageMaker notebook 인스턴스는 그룹을 "assume"할 수 없음. Notebook은 역할만 인수. (C) IAM 사용자(개인 자격증명)를 notebook에 할당하는 것은 AWS 모범 사례 위배. 또한 AdministratorAccess는 과도한 권한(최소 권한 원칙 위반). 그리고 notebook은 사용자를 "assume"할 수 없음. (D) 그룹과 역할을 "연결"하려고 하지만, AWS IAM에서는 "role을 group에 attach"할 수 없음. 역할은 서비스나 사용자에게만 할당됨. 또한 AdministratorAccess는 불필요한 과도한 권한. 【시험 포인트】 "Notebook instance" + "centralize permissions" → **Single IAM Role**. Notebook은 역할을 인수(assume)하며, 단일 역할로 중앙화 관리 가능. 권한 변경 시 역할만 수정.

문제 17

ML 엔지니어가 특정 위치의 아파트 가격을 예측하기 위해 ML 모델을 사용해야 합니다. ML 엔지니어는 모델의 성능을 평가하기 위해 어떤 메트릭을 사용해야 할까요?

A. Accuracy (정확도)
B. Area Under the ROC Curve (AUC)
C. F1 score
D. Mean absolute error (MAE)✓ 정답

해설

【핵심 용어】 ▸ Mean Absolute Error (MAE) — 연속형(회귀) 문제의 평가 메트릭. 예측값과 실제값의 평균 절대 오차. 해석이 직관적(예: "평균적으로 $10,000 오차"). ▸ Accuracy — 분류(classification) 문제 메트릭. 맞은 샘플 비율. 회귀에는 적용 불가. ▸ AUC (ROC curve 아래 영역) — binary classification의 분류 성능 메트릭. 회귀에는 적용 불가. ▸ F1 score — binary/multiclass 분류의 정밀도와 재현율의 조화평균. 회귀에는 적용 불가. ▸ Regression vs Classification — 가격 예측 = 연속형 수치 출력 = 회귀(regression). 【정답 포인트】 ▸ 문제의 핵심: "predict the price of apartments" = 회귀 문제(숫자 예측) ▸ Accuracy, AUC, F1은 모두 "분류" 문제용 메트릭. ▸ MAE는 회귀 문제의 표준 메트릭. MSE(Mean Squared Error)와 함께 가장 일반적. ▸ MAE는 이상값(outlier)에 덜 민감하고 해석이 직관적 (실제 금액 단위의 오차). 【오답 체크】 (A) Accuracy는 "맞은 것의 비율" (%)로 표현됨. 연속형 숫자 예측(가격)에는 의미 없음. 예: "예측이 70% 정확"은 회귀에서 의미 없음. (B) AUC는 binary classification의 순위 매김(ranking) 성능을 평가. 가격 예측의 연속형 출력에는 적용 불가. (C) F1 score는 분류 문제의 precision과 recall을 조합. 회귀에는 정의되지 않음. 【시험 포인트】 "predict the price" (회귀) → **MAE, RMSE, R²** 등의 회귀 메트릭. Accuracy/AUC/F1은 분류(classification) 전용.

문제 18

ML 엔지니어가 stochastic gradient descent (SGD)를 사용하여 신경망을 학습했습니다. 신경망은 테스트 셋에서 성능이 좋지 않습니다. 학습 손실(training loss)과 검증 손실(validation loss)의 값은 높게 유지되며 진동 패턴을 보입니다. 값이 몇 epoch 동안 감소했다가 몇 epoch 동안 증가한 후 같은 사이클을 반복합니다. ML 엔지니어는 학습 프로세스를 개선하기 위해 무엇을 해야 할까요?

A. Early stopping을 도입합니다.
B. 테스트 셋의 크기를 늘립니다.
C. Learning rate를 증가시킵니다.
D. Learning rate를 감소시킵니다.✓ 정답

해설

【핵심 용어】 ▸ Stochastic Gradient Descent (SGD) — 경사 하강법. 각 배치마다 가중치를 업데이트하는 최적화 알고리즘. ▸ Learning rate — SGD에서 가중치 업데이트 크기를 조절하는 하이퍼파라미터. 크면 수렴이 불안정, 작으면 수렴이 느림. ▸ Oscillating loss — 손실이 진동하며 수렴하지 않는 현상. 보통 learning rate가 너무 높을 때 발생. ▸ Underfitting vs Overfitting — 현재 상황은 둘 다 아님 (training loss도 높음) = convergence 문제. 【정답 포인트】 ▸ 문제의 핵심: "training loss AND validation loss both high" + "oscillating pattern" (진동) ▸ 진동 패턴은 학습이 최적점 주변을 "왕복"하는 현상 = learning rate가 너무 높음. ▸ Learning rate를 낮추면 가중치 업데이트 크기가 작아져, 안정적으로 수렴. 【오답 체크】 (A) Early stopping은 "validation loss가 증가"할 때 학습을 중단하는 기법 (overfitting 방지). 하지만 현재 문제는 "둘 다 높고 진동" = 수렴 실패. 중단해도 좋은 성능 달성 불가. (B) 테스트 셋 크기 증가는 평가 데이터만 늘림. 학습 과정 개선과 무관. 또한 "training loss도 높음" = 데이터 부족이 아니라 수렴 실패. (C) Learning rate 증가는 현재 문제를 악화시킴. 진동이 더 심해질 것. SGD 진동의 원인 자체가 높은 learning rate. 【시험 포인트】 "oscillating loss" + "high training & validation loss" → **Decrease learning rate**. Learning rate가 너무 높으면 최적점 주변에서 진동. 감소시켜 안정적 수렴 달성.

문제 19

ML 엔지니어는 수천 개의 기존 CSV 객체와 업로드되는 새로운 CSV 객체를 처리해야 합니다. CSV 객체는 중앙 Amazon S3 버킷에 저장되며 같은 수의 열을 가지고 있습니다. 열 중 하나는 거래 날짜입니다. ML 엔지니어는 거래 날짜를 기반으로 데이터를 쿼리할 수 있어야 합니다. 어떤 솔루션이 운영 부담이 가장 적으면서 이 요구사항을 충족할까요?

A. Amazon Athena CREATE TABLE AS SELECT (CTAS) 문을 사용하여 중앙 S3 버킷의 데이터에서 거래 날짜를 기반으로 테이블을 생성합니다. 테이블에서 객체를 쿼리합니다.✓ 정답
B. 처리된 데이터용 새로운 S3 버킷을 생성합니다. 중앙 S3 버킷에서 새 S3 버킷으로 S3 복제를 설정합니다. S3 Object Lambda를 사용하여 거래 날짜를 기반으로 객체를 쿼리합니다.
C. 처리된 데이터용 새로운 S3 버킷을 생성합니다. AWS Glue for Apache Spark를 사용하여 job을 만들어 거래 날짜를 기반으로 CSV 객체를 쿼리합니다. 결과를 새 S3 버킷에 저장하도록 job을 구성합니다. 새 S3 버킷에서 객체를 쿼리합니다.
D. 처리된 데이터용 새로운 S3 버킷을 생성합니다. Amazon Data Firehose를 사용하여 중앙 S3 버킷에서 새 S3 버킷으로 데이터를 전송합니다. Firehose가 AWS Lambda 함수를 실행하여 거래 날짜를 기반으로 데이터를 쿼리하도록 구성합니다.

해설

【핵심 용어】 ▸ Amazon Athena — S3에 저장된 데이터를 SQL로 직접 쿼리하는 서버리스 분석 서비스. "in-place" 쿼리 (별도 복제 불필요). ▸ CTAS (CREATE TABLE AS SELECT) — SQL 쿼리 결과를 새 테이블로 생성하는 DDL 문. Athena에서 S3 데이터의 메타데이터 기반 관리. ▸ S3 partition — 거래 날짜 같은 열을 기준으로 S3 경로를 구조화. 쿼리 성능과 비용 최적화. ▸ Glue Data Catalog — Athena와 통합되어 테이블 스키마 관리. 【정답 포인트】 ▸ 문제의 핵심: "query CSV objects based on transaction date" + "LEAST operational overhead" ▸ Athena + CTAS는 S3 데이터를 별도 변환/복제 없이 즉시 쿼리 가능. ▸ CTAS로 transaction date를 partition key로 하는 메타데이터를 생성하면, 이후 쿼리는 자동으로 필요한 파일만 스캔 (partition pruning). ▸ "새 버킷"이나 "별도 job" 없이 기존 S3 데이터를 그대로 활용 → 운영 부담 최소. 【오답 체크】 (B) S3 Object Lambda는 S3 쿼리 응답을 실시간으로 변환하는 고급 기능. 거래 날짜 필터링 같은 단순 쿼리에는 과도한 복잡도. 또한 S3 복제는 추가 스토리지 비용. (C) AWS Glue for Spark job은 강력하지만, job 작성·배포·모니터링이 필요 (개발 오버헤드). 또한 결과를 새 버킷에 저장하면 데이터 중복 + 유지보수 부담 증가. (D) Amazon Data Firehose는 실시간 스트림 데이터 수집용 (예: Kinesis → S3). "거래 날짜 쿼리" 같은 배치 분석에는 부적합. Lambda 함수로 쿼리 로직 구현도 불필요한 개발. 【시험 포인트】 "query CSV in S3" + "LEAST operational overhead" → **Amazon Athena + CTAS**. 별도 복제/변환 없이 S3 데이터를 즉시 SQL로 쿼리.

문제 20

회사가 대규모의 비정형 데이터셋을 가지고 있습니다. 데이터셋에는 여러 핵심 속성 전체에 많은 중복 레코드가 포함되어 있습니다. AWS에서 어떤 솔루션이 최소한의 코드 개발으로 데이터셋의 중복을 감지할까요?

A. Amazon Mechanical Turk job을 사용하여 중복을 감지합니다.
B. Amazon QuickSight ML Insights를 사용하여 맞춤형 중복 제거 모델을 구축합니다.
C. Amazon SageMaker Data Wrangler를 사용하여 전처리 및 중복 감지를 수행합니다.
D. AWS Glue FindMatches transform을 사용하여 중복을 감지합니다.✓ 정답

해설

【핵심 용어】 ▸ AWS Glue FindMatches — 중복 또는 유사한 레코드를 식별하기 위한 ML 기반 Glue ETL transform. 코드 작성 최소화. 유사성 임계값 자동 학습. ▸ Deduplication — 데이터셋에서 중복 레코드를 제거하거나 표시하는 프로세스. 데이터 품질 개선의 필수 단계. ▸ Unstructured data — 정형화되지 않은 텍스트, 이미지, 센서 데이터 등. 정규식이나 SQL로 처리 어려움 → ML 필요. 【정답 포인트】 ▸ 문제의 핵심: "detect duplicates" + "unstructured dataset" + "LEAST code development" ▸ FindMatches는 정확히 대규모 중복 감지를 위해 AWS에서 제공하는 ML 변환. 여러 속성을 자동으로 비교. ▸ 사용자는 변환만 Glue job에 추가하면 됨. 중복 감지 로직 작성 불필요. 【오답 체크】 (A) Amazon Mechanical Turk는 사람(크라우드워킹)을 사용한 수동 레이블링 서비스. "자동" 감지가 아니며, 비용과 시간 소요 증가. 대규모 데이터셋에는 비현실적. (B) Amazon QuickSight ML Insights는 BI/시각화 분석 도구. "맞춤형 중복 제거 모델" 구축이 목적이 아님. 그리고 모델을 구축하려면 정의와 학습 필요 → 코드 개발 증가. (C) SageMaker Data Wrangler는 데이터 준비(전처리, 인코딩, 이상값 감지 등) 도구. FindMatches 같은 "중복 감지" 특화 기능은 없음. 사용자가 logic을 정의해야 함. 【시험 포인트】 "duplicate detection" + "unstructured data" + "LEAST code" → **AWS Glue FindMatches**. ML 기반 자동 중복 식별, Glue ETL transform으로 통합.

문제 21

회사는 Amazon EC2 인스턴스에서 배치 데이터 처리 작업을 실행해야 합니다. 작업은 주말에 실행되며 완료하는 데 90분이 소요됩니다. 처리는 중단을 처리할 수 있습니다. 회사는 앞으로 6개월 동안 매주 작업을 실행할 것입니다. 어떤 EC2 인스턴스 구매 옵션이 가장 비용 효율적이면서 이 요구사항을 충족할까요?

A. Spot Instances✓ 정답
B. Reserved Instances
C. On-Demand Instances
D. Dedicated Instances

해설

【핵심 용어】 ▸ Spot Instances — AWS의 유휴 용량을 저가로 제공하는 인스턴스. 2분 예고로 중단 가능. On-Demand 대비 최대 90% 할인. "처리는 중단을 처리할 수 있음" 조건에 최적. ▸ Reserved Instances (RI) — 1년 또는 3년 약정 계약. On-Demand 대비 약 30~40% 할인. 비용 절감하지만, 사용 안 할 때도 비용 발생. ▸ On-Demand Instances — 시간 기반 종량 요금. 가장 비쌈. ▸ Dedicated Instances — 단일 고객 전용 하드웨어. 가장 비쌈. 규정 준수 목적 (일반 배치 작업에는 불필요). ▸ Interruption tolerance — 작업이 중단되어도 재개 가능 (fault-tolerant)한 특성. 【정답 포인트】 ▸ 문제의 핵심: "weekend batch job" + "90 minutes" + "interruptible" + "MOST cost-effective" ▸ Spot Instances는 "처리는 중단을 처리할 수 있다"는 조건을 만족하는 유일한 초저가 옵션. ▸ 주말에만 실행되고 6개월 동안 26회 실행 (총 39시간) → RI(약정) 불필요. Spot이 최저가. ▸ Spot 중단 가능성도 낮음 (주말, 배치 작업, 예측 가능한 시간). 【오답 체크】 (B) Reserved Instances는 1년/3년 약정 필요. 6개월 + 26회(39시간) 사용량에는 비효율적. RI는 지속적인 사용에 최적화. (C) On-Demand는 시간당 최고 요금. Spot의 10배 이상 비쌈. (D) Dedicated Instances는 규정/보안 요구사항이 없는 일반 배치 작업에는 불필요한 낭비. 가장 비쌈. 【시험 포인트】 "batch job" + "interruptible/fault-tolerant" + "weekend" + "short duration" + "MOST cost-effective" → **Spot Instances**. 중단 가능성이 조건이면 Spot 할인(up to 90%) 활용.

문제 22

ML 엔지니어가 Account A의 us-east-1 Region에 Amazon Comprehend 맞춤형 모델을 가지고 있습니다. ML 엔지니어는 같은 Region의 Account B로 모델을 복사해야 합니다. 어떤 솔루션이 개발 노력이 가장 적으면서 이 요구사항을 충족할까요?

A. Amazon S3를 사용하여 모델 사본을 만듭니다. 사본을 Account B로 전송합니다.
B. 리소스 기반 IAM 정책을 생성합니다. Amazon Comprehend ImportModel API 연산을 사용하여 모델을 Account B로 복사합니다.✓ 정답
C. AWS DataSync를 사용하여 Account A에서 Account B로 모델을 복제합니다.
D. Account A와 Account B 사이의 AWS Site-to-Site VPN 연결을 생성하여 모델을 전송합니다.

해설

【핵심 용어】 ▸ Amazon Comprehend ImportModel API — Account 간 또는 Region 간 Comprehend 모델을 import하기 위한 네이티브 API. 모델 소유권 변경 가능 (cross-account). ▸ Resource-based IAM policy — 리소스(모델)에 대해 다른 AWS 계정의 사용자/역할이 특정 작업을 수행하도록 허용하는 정책. ▸ Comprehend custom model — NLP 모델. 학습 데이터와 모델 아티팩트는 Comprehend 내부 저장소에서 관리됨. 【정답 포인트】 ▸ 문제의 핵심: "copy model from Account A to Account B" + "same Region" + "LEAST development effort" ▸ ImportModel API는 정확히 cross-account 모델 이동을 위해 설계된 네이티브 솔루션. ▸ 리소스 기반 IAM 정책으로 권한 설정 후 API 호출만으로 완료 → 개발 노력 최소. ▸ S3 전송이나 DataSync 같은 workaround 불필요. 【오답 체크】 (A) Amazon S3로 수동 복사하는 것은 Comprehend 모델의 메타데이터·버전·권한 정보를 손실할 가능성. 또한 모델 포맷 불일치 위험. "copy" 작업이 AWS 네이티브 API로 지원되지 않음. (C) AWS DataSync는 데이터 동기화 도구 (예: on-premises ↔ S3). Comprehend 모델(학습된 ML 아티팩트) 이동에는 부적합. 모델 메타데이터 손실. (D) Site-to-Site VPN은 네트워크 연결 도구. 모델 "복사" 메커니즘이 아님. 추가로 VPN 설정·관리의 오버헤드 증가. 【시험 포인트】 "Comprehend custom model" + "cross-account" + "same region" + "LEAST effort" → **ImportModel API + resource-based IAM policy**. AWS 네이티브 cross-account 전송.

문제 23

ML 엔지니어가 간단한 신경망 모델을 학습하고 있습니다. ML 엔지니어는 검증 데이터셋에서 시간 경과에 따른 모델 성능을 추적합니다. 모델의 성능은 처음에는 크게 개선되다가 특정 epoch 수 이후에 저하됩니다. 어떤 솔루션이 이 문제를 완화할까요? (2개를 선택)

A. 모델에서 early stopping을 활성화합니다.✓ 정답
B. 레이어에서 dropout을 증가시킵니다.✓ 정답
C. 레이어 수를 증가시킵니다.
D. 뉴런 수를 증가시킵니다.
E. 모델 bias의 원인을 조사하여 감소시킵니다.

해설

【핵심 용어】 ▸ Early stopping — 검증 성능이 개선되지 않을 때 학습을 중단하는 정규화 기법. overfitting 방지. "처음 개선 후 저하"의 직접 해결책. ▸ Dropout — 학습 중 일부 뉴런을 무작위로 비활성화하는 정규화 기법. overfitting 감소. ▸ Overfitting — 모델이 학습 데이터에 과도하게 적응하여 검증/테스트 데이터에서 성능 저하. ▸ Model bias — 모델의 체계적 오류 (예측 편향). "성능 저하" 문제와 별개. 문제 진단 후 처리할 사항. 【정답 포인트】 ▸ 문제 상황: "improves at first" → "degrades after specific epochs" = 전형적인 overfitting 신호. ▸ Early stopping (A) : 검증 성능 저하 시점에서 학습 중단 → 최적 시점 포착 가능. ▸ Dropout (B) : 레이어 내 뉴런 비활성화로 co-adaptation 방지 → overfitting 근본 완화. ▸ 둘 다 overfitting 완화 전략 → 정답. 【오답 체크】 (C) 레이어 수 증가는 모델 용량 증가 → overfitting 악화 가능. 문제 해결 X. (D) 뉴런 수 증가도 모델 복잡도 증가 → overfitting 악화. 문제 해결 X. (E) "Model bias" (체계적 오류)는 "성능 저하" 현상과 다른 개념. 현재 상황(early improvement then degradation)은 bias가 아니라 overfitting. 조사·감소해도 현재 문제 해결 X. 【시험 포인트】 "improves then degrades" → **Early stopping + Dropout** = overfitting 완화. 모델 용량 증가(C, D)는 악화. **2개 선택 문제**: overfitting 방지 기법 2가지 조합 = A + B.

문제 24

회사가 vector database를 사용하여 문서의 embedding을 저장하는 Retrieval Augmented Generation (RAG) 애플리케이션을 보유하고 있습니다. 회사는 애플리케이션을 AWS로 마이그레이션해야 하며, 텍스트 파일의 의미론적 검색을 제공하는 솔루션을 구현해야 합니다. 회사는 이미 텍스트 저장소를 Amazon S3 버킷으로 마이그레이션했습니다. 어떤 솔루션이 이 요구사항을 충족할까요?

A. AWS Batch job을 사용하여 파일을 처리하고 embedding을 생성합니다. AWS Glue를 사용하여 embedding을 저장합니다. SQL 쿼리를 사용하여 의미론적 검색을 수행합니다.
B. 맞춤형 Amazon SageMaker notebook을 사용하여 embedding을 생성하는 맞춤형 script를 실행합니다. SageMaker Feature Store를 사용하여 embedding을 저장합니다. SQL 쿼리를 사용하여 의미론적 검색을 수행합니다.
C. Amazon Kendra S3 connector를 사용하여 S3 버킷의 문서를 Amazon Kendra로 수집합니다. Amazon Kendra를 쿼리하여 의미론적 검색을 수행합니다.✓ 정답
D. Amazon Textract 비동기 job을 사용하여 S3 버킷의 문서를 수집합니다. Amazon Textract를 쿼리하여 의미론적 검색을 수행합니다.

해설

【핵심 용어】 ▸ Amazon Kendra — 의미론적 검색 엔진. 문서의 내용을 이해하고 사용자 쿼리와의 의미적 유사성을 기반으로 검색. embedding 생성·저장·검색을 완전 관리. ▸ S3 connector — Kendra가 S3에서 문서를 자동으로 수집, 인덱싱하는 통합 기능. ▸ RAG (Retrieval Augmented Generation) — 검색 기반 LLM 응답. 외부 문서에서 관련 정보를 검색 후 LLM 입력으로 사용. ▸ Semantic search — 단어 일치가 아닌 의미(의도) 기반 검색. 【정답 포인트】 ▸ 문제의 핵심: "semantic search of text files" + "migrate RAG application to AWS" + "S3 text repository" ▸ Amazon Kendra는 정확히 S3 기반 문서의 의미론적 검색을 위해 설계됨. ▸ S3 connector로 자동 수집·인덱싱 → 사용자는 관리할 vector DB 없음 (완전 관리형). ▸ "embedding 생성·저장·쿼리"가 모두 Kendra 내에 통합 → embedding 외부 관리 불필요. 【오답 체크】 (A) AWS Batch (계산) + AWS Glue (저장소)로 embedding을 생성·저장하는 것은 복잡함. 또한 "SQL 쿼리"로 embedding 검색(cosine similarity 등)을 수행하기 어려움. vector index 구축 필요 → 개발 부담. (B) SageMaker notebook + Feature Store도 유사한 문제. 사용자가 embedding 생성 script 작성 필요 (개발 오버헤드). "SQL로 의미론적 검색"은 vector similarity 계산이 필요해서 SQL만으로 불가능. (D) Amazon Textract는 문서의 "텍스트 추출" 도구 (OCR/테이블 분석). 의미론적 검색 기능 없음. 검색을 구현하려면 별도 embedding + vector DB 구축 필요 → 개발 부담 심함. 【시험 포인트】 "RAG" + "semantic search" + "S3 documents" + "fully managed" → **Amazon Kendra + S3 connector**. 의미론적 검색 전담, embedding 관리 자동화.

문제 25

회사가 Amazon Athena를 사용하여 Amazon S3의 데이터셋을 쿼리합니다. 데이터셋에는 회사가 예측하고 싶어 하는 타겟 변수가 있습니다. 회사는 모델이 타겟 변수를 예측할 수 있는지 확인하기 위해 데이터셋을 사용하는 솔루션을 필요로 합니다. 어떤 솔루션이 개발 노력이 가장 적으면서 이 정보를 제공할까요?

A. Amazon SageMaker Autopilot을 사용하여 새로운 모델을 생성합니다. 모델이 달성한 성능을 보고합니다.✓ 정답
B. 데이터 전처리, 다중선형회귀 및 성능 평가를 수행하는 맞춤형 script를 구현합니다. Amazon EC2 인스턴스에서 script를 실행합니다.
C. 데이터셋을 분석하고 모델을 생성하도록 Amazon Macie를 구성합니다. 모델이 달성한 성능을 보고합니다.
D. Amazon Bedrock에서 모델을 선택합니다. 데이터로 모델을 튜닝합니다. 모델이 달성한 성능을 보고합니다.

해설

【핵심 용어】 ▸ SageMaker Autopilot — 자동 머신러닝(AutoML) 서비스. 데이터셋을 입력받으면 데이터 준비, 특성 공학, 알고리즘 선택, 하이퍼파라미터 튜닝을 자동으로 수행 후 최적 모델 반환. 코드 불필요. ▸ Predictability assessment — 데이터에서 "이 타겟 변수를 예측할 수 있는가"를 평가하는 작업. 모델 구축 전 사전 분석. ▸ AutoML — 자동으로 최적 모델과 성능을 도출하는 기술. 개발 오버헤드 최소화. 【정답 포인트】 ▸ 문제의 핵심: "determine if a model can predict the target variable" + "LEAST development effort" ▸ Autopilot은 자동 데이터 준비 + 자동 모델 선택 + 성능 리포트를 한 번에 제공. ▸ "target variable을 예측할 수 있는가"를 가장 빠르게 검증 → Autopilot의 예측 성능 보고. ▸ 코드 작성 전혀 불필요 → 개발 노력 최소. 【오답 체크】 (B) 맞춤형 script 구현은 데이터 탐색, 전처리, 모델링, 평가를 모두 수동으로 작성 필요 → 상당한 개발 시간. "LEAST development effort"와 거리 멈. (C) Amazon Macie는 "데이터 보안 및 프라이버시" 도구 (민감한 정보 감지). ML 모델 구축 기능이 없음. 문제와 무관. (D) Amazon Bedrock은 기학습 LLM(Claude, Llama 등)을 제공하는 서비스. "구조화된 정형 데이터의 타겟 예측"(회귀/분류) 목적이 아님. LLM을 사용자 데이터로 "tuning"하는 것은 비효율적 + 비용 높음. 【시험 포인트】 "predict target variable" + "LEAST development" + "assess predictability" → **SageMaker Autopilot**. AutoML로 자동 모델 생성·성능 평가.