정답 · 해설

해설

【핵심 용어】 ▸ One-hot encoding — 카테고리형 변수를 이진 벡터로 변환. 각 카테고리마다 하나의 1과 나머지는 0. 신경망에 최적. ▸ Label encoding — 카테고리를 정수(0, 1, 2, ...)로 변환. 순서 관계 암시 가능 → 신경망에서 부적절 (색상은 순서 없음). ▸ Categorical feature — 순서 없는 카테고리 데이터. 신경망은 수치 입력 필요 → encoding 필수. ▸ Neural network input — 신경망은 연속 수치 값을 선호. 카테고리는 one-hot 형식이 표현력 좋음. 【정답 포인트】 ▸ 문제의 핵심: "neural network model" + "categorical color data" → 인코딩 필요 ▸ One-hot encoding은 신경망의 입력층에 최적화됨. 각 색상이 독립적 특성으로 취급 → 신경망이 색상 간 관계를 학습. ▸ 색상은 순서가 없는 명목형(nominal) 카테고리 → one-hot이 정확한 표현. 【오답 체크】 (A) Label encoding (정수 할당)은 신경망에 부적절. 정수 순서(0<1<2)가 모델에 암시적 순서 관계를 주게 됨. "빨강=0, 파랑=1, 초록=2"라고 하면 모델이 "파랑 > 빨강"이라고 학습할 우려. (B) Padding은 가변 길이 시퀀스(텍스트, 시계열)를 고정 길이로 맞추는 기법. 색상 데이터는 이미 고정 길이 벡터라 padding 불필요. (C) 차원 축소는 이미 수치형인 고차원 feature를 감소시킬 때 사용 (예: PCA). 색상 카테고리 수가 적으면(예: 10가지 색) one-hot 후 벡터 길이는 10 → 차원 축소 필요 없음. 【시험 포인트】 "categorical color data" + "neural network" → **One-hot encoding**. 신경망은 카테고리를 이진 벡터로 변환 선호. label encoding은 순서 관계 암시.

해설

【핵심 용어】 ▸ Amazon Macie — 민감한 데이터(PII, 신용카드, SSN 등)를 자동으로 "탐지"하는 AWS 보안 서비스. ML 기반 패턴 인식. S3 데이터 스캔 가능. ▸ Amazon Comprehend — 자연어 처리(NLP) 서비스. 텍스트에서 엔티티(사람, 장소)나 감정을 분석. PII 탐지도 가능하지만 Macie보다 덜 초점화됨. ▸ PII (Personally Identifiable Information) — 개인 식별 정보. 민감한 데이터의 대표 예. ▸ Lambda — 서버리스 함수. 데이터 제거 작업에 이상적 (경량, 빠름). 【정답 포인트】 ▸ 문제의 핵심: "identify and remove sensitive data" + "S3 data" + "LEAST operational overhead" ▸ Amazon Macie는 "민감한 데이터 탐지" 전담 서비스. S3 버킷 자동 스캔, PII 패턴 인식. ▸ Macie가 민감 데이터 위치를 식별 → Lambda 함수로 제거 (간단함). ▸ "모델을 어디에 배포"하는지는 핵심이 아님. 민감 데이터 "식별"이 가장 중요. 【오답 체크】 (A) SageMaker 배포는 모델 제공용일 뿐, 민감 데이터 식별 기능 없음. Lambda만으로는 "자동" 민감 데이터 패턴 인식 어려움. 사용자가 식별 로직 구현 필요 → 개발 부담. (B) ECS + Fargate + Batch는 모두 모델 실행/배치 작업 관리용. 민감 데이터 "식별" 전담 기능 없음. AWS Batch job으로 식별 로직을 구현해야 함 → 개발 오버헤드. (D) Amazon Comprehend는 NLP 엔티티 추출/감정 분석 도구. 민감 데이터 탐지가 주 목적이 아님. 또한 EC2 인스턴스는 서버 관리 필요 → Fargate보다 오버헤드 높음. 【시험 포인트】 "identify sensitive data" + "S3" + "LEAST operational overhead" → **Amazon Macie + Lambda**. Macie는 민감 데이터 탐지 전담, Lambda는 제거 자동화.

해설

【핵심 용어】 ▸ AWS Glue — ETL(Extract, Transform, Load) 작업을 위한 완전관리형 서비스로 S3 데이터를 처리하고 변환하는 데 특화됨 ▸ Amazon Data Firehose — 실시간 스트리밍 데이터 전송 서비스로 Kinesis Streams의 데이터를 대상으로 전달하는 용도 ▸ Amazon SageMaker Studio Classic — 통합 IDE로 노트북, 모델 배포(엔드포인트) 등을 관리할 수 있음 【정답 포인트】 문제에서 "모든 원본 데이터가 S3에 저장"이고 "데이터 수집 및 ML 모델 배포 파이프라인"이 필요합니다. AWS Glue는 S3의 정형·비정형 데이터를 ETL로 처리하고 데이터 카탈로그를 만드는 데 최적화되어 있으며, SageMaker Studio Classic은 그 처리된 데이터로 모델을 학습하고 배포하는 완전한 환경을 제공합니다. 두 서비스의 조합이 파이프라인 구축에 가장 자연스럽습니다. 【오답 체크】 (A) Data Firehose는 실시간 스트리밍 데이터를 다른 서비스(Redshift, OpenSearch 등)로 자동 전달하는 서비스입니다. 배치 형태의 S3 데이터를 처리하고 변환하는 ETL용으로는 Glue가 더 적합합니다. (C) Redshift ML은 SQL 쿼리 기반으로 Redshift 데이터웨어하우스 내에서 모델을 만드는 서비스이며, S3의 원본 데이터를 일반적인 ETL 형태로 처리하는 데는 맞지 않습니다. (D) Athena는 S3 데이터를 SQL로 분석하는 쿼리 서비스일 뿐 "데이터 수집 파이프라인"을 만드는 도구가 아니며, 배포는 SageMaker 노트북만으로는 엔드포인트 관리가 불완전합니다. 【시험 포인트】 "S3 + 데이터 처리 + 모델 배포" → "Glue + SageMaker Studio/Endpoint". Firehose는 스트리밍, Athena는 쿼리 분석, Redshift ML은 DW 내 모델이라는 각 서비스의 용도를 구분해야 합니다.

해설

【핵심 용어】 ▸ SageMaker Model Registry — 모델의 메타데이터, 버전, 상태를 일원화로 관리하는 저장소 ▸ Model Registry Collections — 여러 모델 그룹을 논리적으로 조직화하기 위한 상위 계층 구조로, 기존 모델 그룹 구조는 유지하면서 추가 카테고리화가 가능 ▸ ML Lineage Tracking — 데이터 및 모델의 출처와 변환 이력을 추적하는 기능으로 자동 태깅용이 아님 【정답 포인트】 문제의 핵심은 "기존 모델 아티팩트와 그룹화는 유지하면서" "범주별로 발견성을 개선"하는 것입니다. Model Registry Collections는 모델 그룹들 위에 추상화 계층을 추가하여 기존 구조를 건드리지 않으면서도 세 가지 도메인별 조직화를 제공합니다. 모델 그룹을 이동하기만 하면 되므로 무결성이 보장됩니다. 【오답 체크】 (A) 태그는 메타데이터 추가일 뿐이며 "그룹화"를 이루지 못합니다. 또한 문제에서 요구하는 "조직화" 수준의 계층 구조를 제공하지 않습니다. (B) 모델 그룹을 새로 만들고 기존 모델을 "이동"하면 원래 모델 그룹이 비워지거나 재구성되어 "기존 그룹화에 영향"을 줍니다. (C) ML Lineage Tracking은 데이터와 모델 간의 변환 이력을 추적하는 기능이며 자동 분류나 카테고리 태깅 기능이 아닙니다. 【시험 포인트】 "기존 구조 유지 + 상위 카테고리화" → "Collections". "태그 추가", "그룹 이동", "Lineage 추적"은 각각 목표를 달성할 수 없습니다.

해설

【핵심 용어】 ▸ Security Group — 인스턴스 레벨의 Stateful 방화벽으로 Inbound/Outbound 규칙으로 트래픽 제어 ▸ Network ACL — 서브넷 레벨의 Stateless 방화벽으로 명시적 거부 규칙이 가능하며 모든 인바운드 트래픽에 먼저 적용됨 ▸ Route Table — 트래픽의 라우팅 경로를 결정하는 역할이며 트래픽 거부에 사용되지 않음 【정답 포인트】 공용 서브넷에 있는 SageMaker 도메인으로의 특정 IP 트래픽을 "거부"해야 합니다. Security Group은 Stateful이므로 명시적 "거부" 규칙(Deny)을 지원하지 않습니다(기본 거부만 함). 그러나 Network ACL은 서브넷 레벨에서 명시적 Deny 규칙을 우선 처리할 수 있으며, 해당 IP의 모든 트래픽을 차단할 수 있습니다. 서브넷의 기본 Network ACL에 거부 규칙을 추가하면 서브넷의 모든 리소스(도메인 포함)에 적용됩니다. 【오답 체크】 (A) Security Group은 Stateful이지만 명시적 Deny 규칙을 지원하지 않습니다. SageMaker 도메인은 독립적인 보안 그룹 할당이 제한적이며, Deny를 통한 거부는 불가능합니다. (C) Shadow Variant와 Inference Recommender는 모델 배포 성능 비교 도구이지 보안 차단 메커니즘이 아닙니다. (D) Route Table은 패킷의 경로를 결정하는 것이지 거부하는 역할이 아닙니다. IP 기반 트래픽 차단에는 사용되지 않습니다. 【시험 포인트】 "특정 IP 차단" → "Network ACL Deny 규칙" (명시적 거부). Security Group은 Deny가 없고, Route Table은 라우팅용이며, Shadow Variant는 성능 비교용입니다.

해설

【핵심 용어】 ▸ Amazon Transcribe — 음성 파일을 텍스트로 자동 변환하는 완전관리형 서비스 ▸ Amazon Translate — 텍스트를 여러 언어 간 자동으로 번역하는 관리형 서비스 ▸ Amazon Bedrock — Jurassic, Claude, Stable Diffusion 등 다양한 기반 모델에 접근할 수 있는 서비스로 추가 학습 없이 즉시 사용 가능 ▸ Amazon Rekognition — 이미지 및 비디오의 물체, 얼굴, 텍스트 감지 서비스 (음성 변환 아님) 【정답 포인트】 문제에서 "최소한의 시간"으로 해결해야 합니다. 음성·비디오·텍스트를 스페인어에서 영어로 변환 후 요약해야 합니다. Transcribe는 음성→텍스트, Translate는 스페인어→영어 변환이 가능하고, Bedrock의 Jurassic 모델은 텍스트 요약에 최적화되어 있으며 추가 학습 없이 즉시 사용할 수 있습니다. 기 구축된 서비스들을 조합하므로 새로 모델을 학습하는 시간이 없습니다. 【오답 체크】 (A) SageMaker에서 데이터 변환 및 LLM을 처음부터 학습해야 하므로 매우 오래 걸립니다. 이미 검증된 서비스 조합이 훨씬 빠릅니다. (C) Rekognition은 이미지와 비디오 내 텍스트/물체 감지 서비스이지 음성을 텍스트로 변환하지 못합니다. Transcribe의 대체 불가능한 역할을 수행할 수 없습니다. (D) Stable Diffusion은 텍스트→이미지 생성 모델로 텍스트 요약에 전혀 맞지 않습니다. 【시험 포인트】 "음성+비디오+텍스트 + 스페인어 → 요약" → "Transcribe + Translate + Bedrock(LLM)". Rekognition은 음성 변환 불가, Stable Diffusion은 이미지 생성용, 모델 학습은 시간 소모.

해설

【핵심 용어】 ▸ Amazon Kinesis Streams — 실시간 스트리밍 데이터 수집을 위한 완전관리형 서비스 ▸ Amazon Managed Service for Apache Flink — Kinesis 스트림을 실시간으로 분석하는 관리형 서비스로 SQL/Java/Python 지원 ▸ RANDOM_CUT_FOREST — Flink에 기본 제공되는 이상 감지(Anomaly Detection) 알고리즘으로 별도 모델 구축 불필요 ▸ AWS Lambda + SageMaker — 기존 모델을 호출하는 방식으로 추가 관리 필요 【정답 포인트】 "운영 부담이 가장 적으면서" 실시간 스트림의 이상을 감지해야 합니다. Kinesis Streams로 데이터를 수집하고, Flink의 기본 제공 RANDOM_CUT_FOREST 알고리즘으로 즉시 이상 감지가 가능합니다. 별도의 모델 학습·배포·유지보수가 없으므로 운영 부담이 최소화됩니다. Flink 자체가 완전관리형이므로 인프라 관리도 불필요합니다. 【오답 체크】 (B) Kinesis + Lambda + SageMaker 조합은 여러 서비스를 통합해야 하며, SageMaker 엔드포인트를 별도로 배포·관리해야 하므로 운영 부담이 큽니다. 또한 Lambda 이벤트 소스 매핑 구성도 필요합니다. (C) EC2에서 Kafka를 자체 관리하면 운영 부담이 극도로 높습니다. 패치, 확장, 모니터링 모두 수동으로 처리해야 합니다. (D) SQS FIFO + Lambda + Glue 조합은 배치 처리이므로 "실시간" 요구사항에 맞지 않으며, 지연이 발생합니다. 【시험 포인트】 "실시간 스트림 + 이상 감지 + 최소 운영 부담" → "Kinesis + Managed Flink + RANDOM_CUT_FOREST". EC2 관리, SageMaker 배포, 배치 처리는 모두 운영 부담이 큽니다.

해설

【핵심 용어】 ▸ Amazon Comprehend — 텍스트 데이터에서 감정 분석(Sentiment Analysis), 엔티티 추출, 핵심 구문 추출 등을 제공하는 완전관리형 자연어 처리 서비스 ▸ Amazon Rekognition — 이미지와 비디오 분석 서비스로 텍스트 감정 분석 기능이 없음 ▸ Naive Bayes / Random Forests — 직접 학습해야 하는 모델로 학습 데이터, 전처리, 하이퍼파라미터 튜닝에 시간 소모 【정답 포인트】 "최소한의 시간"으로 텍스트 기반 채팅의 감정 분석을 완료해야 합니다. Amazon Comprehend는 사전 학습된 자연어 처리 모델로 텍스트를 입력하면 즉시 감정(Positive/Negative/Neutral/Mixed)을 반환합니다. 별도의 모델 학습, 데이터 준비, 특성 엔지니어링이 불필요하므로 매우 빠르게 평가를 완료할 수 있습니다. 【오답 체크】 (A) Rekognition은 이미지와 비디오 분석 서비스이며 텍스트 감정 분석 기능이 없습니다. 채팅 텍스트 분석에는 적합하지 않습니다. (B) Naive Bayes 분류기를 처음부터 학습하려면 레이블이 지정된 학습 데이터, 전처리, 모델 학습, 평가 등 많은 시간이 필요합니다. (D) Random Forests 역시 학습 데이터 준비, 특성 엔지니어링, 하이퍼파라미터 튜닝, 모델 평가 등에 상당한 시간이 소모됩니다. 【시험 포인트】 "텍스트 감정 분석 + 최소 시간" → "Amazon Comprehend (기 학습된 서비스)". Rekognition은 이미지용, Naive Bayes/Random Forests는 학습 필요, SageMaker 모델은 더욱 오래 걸림.

해설

【핵심 용어】 ▸ Temperature — LLM의 출력 무작위성을 제어하는 파라미터. 높을수록 다양한 응답, 낮을수록 일관된 응답 ▸ Top_k — 다음 토큰 선택 시 확률이 높은 상위 k개의 토큰만 고려하는 샘플링 방식. 높을수록 선택지 넓음(다양성↑), 낮을수록 좁음(일관성↑) ▸ 일관성과 무작위성 — Temperature와 Top_k를 낮추면 모델의 출력이 결정적(deterministic)으로 수렴함 【정답 포인트】 문제에서 "유사한 질문에 대해 다른 답변(무작위성)"을 받으므로 "일관성을 개선"해야 합니다. Temperature를 낮추면 모델이 높은 확률의 토큰만 선택하게 되어 일관성이 높아지고, Top_k를 낮추면 선택 범위를 축소하여 다양성을 제한합니다. 두 파라미터를 모두 낮추면 거의 동일한 조건에서는 거의 동일한 응답이 생성됩니다. 【오답 체크】 (A) Temperature와 Top_k를 모두 증가시키면 무작위성이 더 높아져 응답의 다양성만 증가하고 일관성은 악화됩니다. (B) Temperature를 증가시키면 무작위성이 높아지고(일관성 감소), Top_k를 감소시키면 선택지가 줄어듭니다(상충되는 효과). 일관성 개선 효과가 혼재됩니다. (C) Temperature를 감소시키면 일관성이 개선되지만, Top_k를 증가시키면 선택지가 넓어져 무작위성이 증가합니다(상충). 일관성 개선 효과가 약화됩니다. 【시험 포인트】 "응답 일관성 개선 + 무작위성 감소" → "Temperature↓ + Top_k↓". Temperature는 기본 무작위성 제어, Top_k는 샘플링 범위 제한. 둘 다 낮춰야 최대 일관성을 달성합니다.

해설

【핵심 용어】 ▸ SageMaker Linear Learner — 선형 회귀와 분류를 위한 확장 가능한 알고리즘 ▸ target_precision — Linear Learner의 하이퍼파라미터로 모델이 달성해야 할 정밀도(Precision) 목표값. 높을수록 거짓 양성을 줄임 ▸ False Positives — 실제로는 음성(no weed)인데 양성(weed)으로 잘못 예측한 경우 ▸ Precision — 양성으로 예측한 것 중 실제 양성의 비율. Precision이 높으면 거짓 양성이 적음 【정답 포인트】 거짓 양성을 최소화하려면 Precision을 높여야 합니다. SageMaker Linear Learner의 target_precision 하이퍼파라미터를 증가시키면 모델이 양성 예측을 더 보수적으로 하게 되어, 높은 확신이 있을 때만 잡초가 있다고 예측합니다. 이는 "이것이 정말 잡초인가?"라는 기준을 높이는 것과 같아 거짓 양성이 감소합니다. 【오답 체크】 (A) Weight decay는 L2 정규화 강도를 제어하는 것으로 과적합을 방지하는 역할입니다. 거짓 양성 감소와 직접적 연관이 없습니다. (B) 에포크를 증가시키면 모델이 더 오래 학습되지만 거짓 양성 감소에 대한 직접적 영향이 없습니다. 오히려 과적합 위험이 있습니다. (D) Linear Learner의 predictor_type을 regressor로 변경하면 분류 모델이 회귀 모델로 바뀌어 "잡초 있음/없음"을 연속값으로 예측하게 되므로 목표(분류)와 맞지 않습니다. 【시험 포인트】 "거짓 양성 최소화" → "Precision 증가" → "SageMaker Linear Learner의 target_precision 파라미터 증가". Weight decay는 정규화, 에포크는 학습 반복, regressor는 모델 유형 변경으로 모두 무관합니다.

해설

【핵심 용어】 ▸ Amazon Data Firehose — 배치 기반 실시간 데이터 전달 서비스로 버퍼 크기나 시간 중 하나가 도달하면 데이터를 대상으로 전달 ▸ Buffer Interval — Firehose가 데이터를 모아두는 시간. 길수록 지연 증가 ▸ PutRecordBatch — Firehose에 여러 레코드를 한 번에 전송하는 작업으로 배치 크기 제어 가능 ▸ Sub-second Latency — 1초 미만의 지연을 목표로 함 【정답 포인트】 현재 60초 버퍼 간격으로 인해 1초 미만의 지연 요구사항을 만족하지 못합니다. "0 버퍼링"으로 설정하면 버퍼링 지연을 완전히 제거하고, PutRecordBatch 배치 크기를 작게 조정하여 레코드가 즉시 OpenSearch로 전달됩니다. 이렇게 하면 데이터가 거의 실시간으로(sub-second) 대시보드에 나타나게 됩니다. 【오답 체크】 (B) AWS DataSync는 온프레미스와 AWS 간의 데이터 동기화 서비스로 Firehose의 대체재가 아닙니다. "향상된 팬아웃 소비자"는 Kinesis 스트림의 개념이지 DataSync의 기능이 아닙니다. (C) 버퍼 간격을 60초에서 120초로 증가시키면 지연이 2배 증가하여 1초 미만 요구사항을 더욱 만족할 수 없습니다. (D) SQS 큐는 배치 처리 및 비동기 처리용 서비스로 실시간 대시보드 업데이트에는 지연이 발생합니다. Firehose보다 지연이 더 클 가능성이 높습니다. 【시험 포인트】 "버퍼 지연 감소 + sub-second latency" → "Firehose 버퍼 간격 0 + PutRecordBatch 배치 크기 조정". 버퍼 간격 증가, 서비스 변경은 모두 틀립니다.

해설

【핵심 용어】 ▸ SageMaker Real-time Inference Endpoint — 낮은 지연 시간에 소수의 요청을 처리하는 엔드포인트로 높은 가용성과 자동 스케일링 기본 지원 ▸ Auto Scaling — 요청 수에 따라 엔드포인트의 인스턴스 수를 자동으로 조정하는 기능 ▸ Elastic Load Balancer — 여러 엔드포인트 인스턴스 간 트래픽 분산으로 높은 가용성 제공 ▸ Spot Instances — 비용 효율적이지만 예측 불가능한 중단(interruption) 가능성으로 높은 가용성이 필요한 프로덕션에는 부적절 【정답 포인트】 요구사항: "높은 가용성" + "최소 지연" + "예측 불가능한 요청 급증" + "비례적 확장". SageMaker 실시간 추론 엔드포인트는 이 모든 요구사항을 기본으로 제공합니다. 자동 스케일링으로 요청 수에 따라 자동 확장되고, 여러 인스턴스 간 로드 밸런싱으로 높은 가용성이 보장되며, 실시간 추론 최적화로 최소 지연이 달성됩니다. 완전관리형이므로 운영 부담도 적습니다. 【오답 체크】 (B) ECS 클러스터에 수동 배포하면 인프라 관리 부담이 크고, "예정된 스케일링"(시간 기반)은 "예측 불가능한 급증"에 대응할 수 없습니다. 지연도 더 높을 가능성이 있습니다. (C) EKS에 Operator를 설치하는 것은 복잡하며, "메모리 메트릭"은 요청 수와의 상관관계가 약할 수 있습니다. 지연 시간 최적화가 SageMaker 엔드포인트만큼 좋지 않습니다. (D) Spot Instances는 언제든 중단될 수 있으므로 "높은 가용성" 요구사항을 만족할 수 없습니다. 프로덕션 환경에는 부적절합니다. 【시험 포인트】 "높은 가용성 + 최소 지연 + 예측 불가능한 트래픽" → "SageMaker 실시간 엔드포인트 + 자동 스케일링". ECS/EKS는 관리 부담, Spot Instances는 중단 가능성, 예정된 스케일링은 트래픽 급증 대응 불가.

해설

【핵심 용어】 ▸ EMR Primary Node — EMR 클러스터의 마스터 노드로 작업 관리, 조정, 메타데이터 저장 (중단 불가) ▸ EMR Core Nodes — HDFS 데이터스토어를 유지하는 데이터 노드 (중단 시 데이터 손실) ▸ EMR Task Nodes — 데이터 저장 없이 순수 계산만 수행 (중단 가능, 재계산 가능) ▸ Spot Instances — 온디맨드보다 90% 저렴하지만 언제든 중단될 수 있음 ▸ On-Demand Instances — 높은 비용이지만 안정적 【정답 포인트】 "데이터 손실 불허용" + "최대 비용 효율". Primary Node는 클러스터 마스터로 중단되면 전체 작업이 실패하므로 반드시 On-Demand여야 합니다. Core Nodes는 HDFS 데이터를 저장하므로 Spot으로 중단되면 데이터 손실 위험이 있어 On-Demand가 필요합니다. Task Nodes는 데이터를 저장하지 않으므로 Spot으로 중단되어도 손실이 없으며, 재계산 가능하므로 비용 절감을 위해 Spot 사용 가능합니다. 【오답 체크】 (A) 모든 노드를 On-Demand로 실행하면 데이터 손실 위험은 없지만 최대 비용이 발생합니다. Spot 활용 가능성이 없습니다. (B) Task Nodes를 Spot으로 실행하는 것은 OK이지만, Primary와 Core Nodes를 Spot으로 실행하면 "데이터 손실 불허용" 요구사항 위배입니다. Core Nodes의 HDFS 데이터가 손실될 수 있습니다. (C) Primary Node만 On-Demand이고 Core Nodes를 Spot으로 실행하면 HDFS 데이터 손실 위험이 있습니다. 【시험 포인트】 "데이터 손실 불허용 + 최대 비용 효율" → "Primary(On-Demand) + Core(On-Demand) + Task(Spot)". 데이터 저장 여부로 구분: 저장 노드는 On-Demand, 계산 노드는 Spot.

해설

【핵심 용어】 ▸ SageMaker Debugger — 학습 작업 중 지표를 실시간 모니터링하고 문제 감지 시 작업 중지 가능 (무의미한 학습 방지) ▸ AWS Trainium — ML 학습 최적화 전용 칩으로 에너지 효율이 높고 학습 속도 향상 ▸ SageMaker Ground Truth — 데이터 레이블링 서비스로 학습 데이터 준비에 사용 (학습 자체의 에너지는 줄이지 않음) ▸ AWS Lambda — 추론(배포) 관련 기능으로 학습 에너지와 무관 ▸ Distributed Training — 학습을 여러 인스턴스에 분산하는 방식으로 개별 인스턴스 부하 감소하지만 전체 계산 리소스는 더 사용 【정답 포인트】 "에너지 사용 및 계산 리소스 감소"는 학습 단계에서 불필요한 계산을 줄이거나 더 효율적인 하드웨어를 사용해야 합니다. (A) SageMaker Debugger는 수렴하지 않는 조건(loss가 계속 증가, 메트릭이 개선 안 됨 등)을 감지하고 학습을 일찍 중지하여 낭비되는 계산 리소스를 제거합니다. (D) AWS Trainium은 학습 전용 칩으로 GPU/CPU 대비 에너지 효율이 훨씬 높아 동일한 작업에 더 적은 전력 소모합니다. 【오답 체크】 (B) SageMaker Ground Truth는 데이터 레이블링(준비 단계)에 사용되며, 학습 작업 자체의 에너지나 계산 리소스를 줄이지 않습니다. (C) AWS Lambda는 배포(추론) 환경의 기능으로 학습 단계의 에너지 사용과 직접 관련이 없습니다. (E) 분산 학습(PyTorch/TensorFlow distributed)은 여러 인스턴스를 사용하므로 전체 계산 리소스가 증가하고 통신 오버헤드도 발생합니다. 에너지 절감과 반대입니다. 【시험 포인트】 "학습 에너지/리소스 감소" → "불필요한 학습 중지(Debugger) + 효율 칩(Trainium)". Ground Truth는 레이블링, Lambda는 배포, 분산학습은 리소스 증가.

해설

【핵심 용어】 ▸ SageMaker Data Wrangler — 데이터 준비 전용으로 5TB 이상의 대용량 데이터와 복잡한 NLP 변환에는 제한적 ▸ SageMaker Pipelines — 데이터 처리, 특성 엔지니어링, 모델 학습, 배포 등 전체 ML 워크플로우를 단계별로 정의하고 자동화하는 완전 관리형 서비스 ▸ AWS Step Functions — 서버리스 워크플로우 조정 서비스로 Lambda 함수 등을 연결 (복잡한 ETL/NLP에는 부적절) ▸ Amazon EventBridge — 이벤트 기반 자동 트리거 서비스 ▸ Lambda — 계산 시간 제약(15분 제한)으로 시간이 걸리는 복잡한 처리에 부적절 【정답 포인트】 "5TB 이상 + CSV/JSON/Parquet/텍스트 + 복잡한 조작(시간 소모) + NLP 변환 + 완전 자동화". SageMaker Pipelines는 다양한 파일 형식을 처리할 수 있고, Processing Steps로 복잡한 변환(NLP 포함)을 실행하며, 파이프라인 내에서 순차 및 병렬 실행을 정의할 수 있습니다. 또한 EventBridge와 통합하여 트리거 기반 자동화가 가능합니다. 대용량 데이터의 다단계 처리에 최적화된 솔루션입니다. 【오답 체크】 (A) Data Wrangler는 대화형 데이터 준비 도구로 자동화와 확장성이 제한적이며, NLP 변환 기능도 제한적입니다. 5TB 규모의 자동 파이프라인 구축에 부적절합니다. (B) 노트북 + EventBridge 조합은 노트북 실행을 자동화할 수 있지만, 노트북 기반 파이프라인은 운영 복잡도가 높고 확장성도 떨어집니다. ML 파이프라인 자동화에 최적화되지 않았습니다. (C) Lambda는 최대 15분 실행 제한이 있으므로 "시간이 걸리는" 복잡한 처리에 부적절합니다. Step Functions로 연결해도 Lambda의 시간 제약은 해결 불가능합니다. 【시험 포인트】 "대용량(5TB) + 다양한 형식 + 복잡한 처리(NLP) + 자동화" → "SageMaker Pipelines". Data Wrangler는 대화형, Lambda는 시간 제약, 노트북은 운영 부담 높음.

해설

【핵심 용어】 ▸ AWS::SageMaker::Model — 모델 아티팩트(가중치, 메타데이터)를 CloudFormation에서 정의하는 리소스 ▸ AWS::SageMaker::Endpoint — 모델을 호스팅하는 엔드포인트를 정의하는 리소스로, Model 리소스를 참조해야 함 ▸ AWS::SageMaker::NotebookInstance — 개발/실험용 Jupyter 노트북 인스턴스 ▸ AWS::SageMaker::Pipeline — SageMaker Pipelines 워크플로우 정의 【정답 포인트】 문제에서 "SageMaker 엔드포인트가 호스팅할 ML 모델"을 CloudFormation으로 "만들어야" 합니다. 모델 자체를 정의하려면 먼저 AWS::SageMaker::Model 리소스를 선언해야 합니다. 이 리소스는 모델 아티팩트의 위치(S3), 컨테이너 이미지, IAM 역할 등을 정의합니다. 그 다음 AWS::SageMaker::Endpoint 리소스가 이 Model을 참조하여 호스팅합니다. 【오답 체크】 (B) AWS::SageMaker::Endpoint는 모델을 호스팅하는 "엔드포인트"를 정의하는 것이지 "모델 자체"를 정의하는 것이 아닙니다. 엔드포인트는 Model 리소스를 참조해야 하므로 Model이 먼저 정의되어야 합니다. (C) NotebookInstance는 개발 환경이지 모델을 호스팅하지 않으며 엔드포인트와도 직접 관련이 없습니다. (D) Pipeline은 ML 워크플로우 정의(학습, 평가, 배포 단계)이지 개별 모델 정의가 아닙니다. 【시험 포인트】 "CloudFormation에서 SageMaker 엔드포인트가 호스팅할 모델 정의" → "AWS::SageMaker::Model". Endpoint는 Model을 참조하는 상위 리소스이므로 Model이 선행되어야 합니다.

해설

【핵심 용어】 ▸ AWS Lake Formation — 데이터 레이크의 중앙 권한 관리 및 정책 집행 서비스로 세밀한 접근 제어(Fine-Grained Access Control) 제공 ▸ Lake Formation Tags — 리소스(테이블, 열, 행)에 태그를 붙여 사용자/역할을 태그로 매핑하는 방식으로 캠페인별 액세스 제어 ▸ IAM Policies — AWS Glue Catalog 메타데이터만 제어하며 실제 S3 데이터 접근 제어는 불완전 ▸ DynamoDB Streams + Lambda — S3 버킷 정책을 동적 업데이트하는 복잡한 과정으로 운영 부담 높음 ▸ S3 Bucket Policies — IAM 기반으로 세밀한 캠페인별 제어 어려움 【정답 포인트】 "가장 운영 효율적" + "Athena 쿼리 + S3 직접 탐색 + 캠페인별 접근 제어". Lake Formation의 태그 기반 액세스 제어가 최적입니다. 각 엔지니어에게 태그를 할당하고(예: campaign-A), 각 데이터 리소스에도 태그를 붙입니다(예: campaign-A). Lake Formation이 태그 기반 자동 권한 집행을 처리하므로 IAM 정책 수동 관리가 불필요합니다. Athena 쿼리와 S3 직접 액세스 모두 Lake Formation의 통합 권한 제어를 받습니다. 【오답 체크】 (A) AWS Glue Data Catalog에 IAM 정책을 설정하면 메타데이터(테이블, 파티션)만 제어되고 실제 S3 데이터는 IAM만으로 충분히 제어되지 않습니다. 또한 세밀한 캠페인별 제어도 어렵습니다. (B) DynamoDB Streams + Lambda로 S3 버킷 정책을 동적으로 수정하는 방식은 매우 복잡하고 운영 부담이 큽니다. 또한 S3 버킷 정책만으로는 세밀한 행/열 수준 제어가 불가능합니다. (D) S3 버킷 정책 단독으로는 IAM 기반 제어만 가능하며, Athena 쿼리 시 추가 권한 검증이 필요합니다. 캠페인별 세밀한 제어가 어렵고, DynamoDB나 외부 시스템과의 동기화가 필요합니다. 【시험 포인트】 "데이터 레이크 + 캠페인별 세밀한 접근 제어 + Athena + S3 + 운영 효율" → "Lake Formation 태그 기반 권한". IAM 정책은 메타데이터 제어, 동적 S3 정책 업데이트는 복잡함.

해설

【핵심 용어】 ▸ Apache Parquet — 컬럼 기반 스토리지 형식으로 스키마, 메타데이터 내장, 압축, 선택적 컬럼 읽기 지원으로 매우 효율적 ▸ CSV — 행 기반 텍스트 형식으로 파싱 오버헤드 크고 데이터 타입 정보 없음 ▸ JSON/JSONL — 비정형이며 파싱 비용 높고 복잡한 구조 처리 오버헤드 큼 ▸ Snappy/gzip 압축 — 저장 공간은 절약하지만 읽기 시 압축 해제 오버헤드 발생 【정답 포인트】 "복잡한 구조 + 처리 시간 최소화". SageMaker Canvas는 S3의 데이터를 자동으로 로드하여 모델 학습에 사용합니다. Apache Parquet은 다음 특성으로 처리 시간을 최소화합니다: (1) 컬럼 기반으로 필요한 컬럼만 읽을 수 있어 I/O 감소, (2) 스키마와 메타데이터가 내장되어 파싱 불필요, (3) 압축 알고리즘이 최적화되어 빠른 읽기, (4) 복잡한 데이터 구조를 효율적으로 표현. 결과적으로 로드 및 처리 시간이 CSV나 JSON 대비 훨씬 짧습니다. 【오답 체크】 (A) CSV는 행 기반 텍스트 형식으로 전체 파일을 파싱해야 하며, 복잡한 중첩 구조 표현도 어렵습니다. Snappy 압축도 읽기 시 압축 해제 오버헤드가 발생합니다. (B) JSONL(한 줄에 한 객체)은 JSON의 변형이지만 여전히 비정형이며 파싱 비용이 큽니다. 복잡한 구조 처리는 느립니다. (C) JSON은 비정형이고 파싱 비용이 매우 높으며, gzip 압축은 추가 압축 해제 오버헤드를 발생시킵니다. 【시험 포인트】 "복잡한 데이터 구조 + 처리 시간 최소화" → "Apache Parquet (컬럼 기반 + 스키마 + 최적화된 압축)". CSV는 행 기반, JSON은 비정형 파싱 비용 높음, 압축은 오버헤드.

해설

【핵심 용어】 ▸ Recall (재현율) — 실제 양성(Positive) 중에서 모델이 올바르게 예측한 비율 = TP / (TP + FN). "실제 양성을 놓친 비율(FN)"을 반영 ▸ Precision (정밀도) — 양성으로 예측한 것 중 실제 양성의 비율 = TP / (TP + FP). "잘못된 양성 예측(FP)"을 반영 ▸ False Negative (FN) — 실제 양성인데 음성으로 예측 (놓친 양성) ▸ False Positive (FP) — 실제 음성인데 양성으로 예측 (잘못된 양성) 【정답 포인트】 "거짓 음성 비용 >> 거짓 양성 비용". 거짓 음성은 실제 양성(긍정적 경우)을 음성(부정적)으로 잘못 예측하는 것입니다. 문제에서 이 비용이 매우 높다는 것은 실제 양성을 놓치는 것이 심각하다는 의미입니다. 따라서 실제 양성을 최대한 많이 포착해야 하며, 이를 최대화하는 메트릭은 Recall(재현율)입니다. Recall을 높이려면 "양성 예측 기준"을 낮춰 더 많은 케이스를 양성으로 예측하게 되므로, 필연적으로 거짓 음성이 감소합니다. 【오답 체크】 (A) 낮은 정밀도는 잘못된 양성 예측(FP)이 많다는 의미이므로 거짓 양성 비용이 높을 때 원하는 조건입니다. 하지만 문제에서는 거짓 음성 비용이 높으므로 정밀도는 덜 중요합니다. (B) 높은 정밀도는 양성 예측이 매우 정확하다는 의미이지만, 이를 위해 거짓 음성이 증가합니다(실제 양성을 놓칠 가능성 높음). 거짓 음성 비용이 높은 상황에 맞지 않습니다. (C) 낮은 재현율은 실제 양성을 더 많이 놓친다는 의미로 거짓 음성이 많다는 뜻입니다. 문제의 요구사항과 정반대입니다. 【시험 포인트】 "거짓 음성 비용 높음" → "재현율(Recall) 최대화". 재현율은 "실제 양성을 올바르게 포착한 비율"이므로 높을수록 거짓 음성이 적습니다.

해설

【핵심 용어】 ▸ AWS CloudTrail — AWS API 호출(누가, 언제, 무엇을 했는지)을 기록하는 감시 및 감사 서비스 ▸ SageMaker Debugger — 모델 학습 중 텐서 값, 그래디언트, 가중치 변화를 추적하는 도구로 추론 모니터링은 아님 ▸ Amazon CloudWatch — 메트릭 모니터링 및 알람 설정을 위한 관리형 서비스 ▸ Invocations Metric — SageMaker 엔드포인트의 호출 횟수를 나타내는 내장 메트릭이지만 API 호출 "이벤트" 기록은 아님 【정답 포인트】 "모든 API 호출 이벤트를 기록 + 모니터링 + 임계값 초과 시 알림". CloudTrail은 모든 AWS API 호출(SageMaker 엔드포인트 호출 포함)을 자세히 기록하므로 "API 호출 이벤트 기록" 요구사항을 충족합니다. CloudWatch 대시보드에서 CloudTrail 로그를 분석하고, CloudWatch 알람으로 호출 수 임계값 초과 시 알림을 설정합니다. 이 조합이 "기록 + 모니터링 + 알림" 전체를 가장 포괄적으로 제공합니다. 【오답 체크】 (A) SageMaker Debugger는 학습 중 모델의 내부 상태(텐서, 그래디언트)를 추적하는 것이지, 배포된 엔드포인트의 "API 호출 이벤트"를 기록하지 않습니다. 추론 모니터링에는 부적절합니다. (B) tensor_variance 규칙은 텐서 분산을 감지하는 학습 모니터링 규칙이며, 엔드포인트 API 호출 기록과는 무관합니다. (D) Invocations 메트릭은 호출 "횟수"를 나타내는 메트릭이지, "API 호출 이벤트"를 기록하지 않습니다. 또한 CloudWatch 메트릭만으로는 "누가, 언제, 무엇을" 등의 상세 감사 정보를 제공하지 않습니다. 【시험 포인트】 "API 호출 이벤트 기록 + 모니터링 + 알림" → "CloudTrail(기록) + CloudWatch(모니터링 + 알람)". SageMaker Debugger는 학습용, Invocations는 메트릭일 뿐 이벤트 기록 아님.