연습 문제

문제 1

정유 공장 안전 시스템에서, ML engineer는 센서 스트림에서 메탄 누출을 탐지하는 binary classifier를 선택해야 한다. 실제 누출을 놓치는 경우(false negative)는 평균 사고 비용이 $120,000 발생하는 반면, false alarm은 $300의 현장 점검과 5분의 다운타임을 유발한다. 그렇다면 모델을 선택할 때 어떤 metric 결과를 가장 우선적으로 고려해야 하는가?

문제 분석

핵심 개념: 이 문제는 classification evaluation metrics와 cost-sensitive model selection을 평가한다. 안전이 중요한 탐지(메탄 누출)에서는 오류의 비즈니스 영향이 비대칭이므로, 가장 비용이 큰 오류 유형을 최소화하는 metric을 우선한다. 이는 ML model development의 일부로, 리스크에 맞춰 metrics, thresholds, decision criteria를 선택하는 것이다. 정답이 맞는 이유: false negative는 실제 누출을 놓치는 것으로, 평균 사고 비용이 $120,000이다. false positive는 $300 점검과 5분 다운타임을 유발하는데, 비용 규모가 훨씬 작다. Recall(= sensitivity 또는 true positive rate)은 실제 positive 중에서 올바르게 탐지한 비율을 측정한다: Recall = TP / (TP + FN). Recall을 최대화하면 false negatives(FN)를 직접적으로 줄인다. 따라서 모델 선택 시 high recall을 우선해야 하며(그리고 일반적으로 decision threshold를 조정해 FN을 더 줄임), 그 결과 false alarm이 증가하더라도 감수하는 것이 맞다. 주요 AWS Features / Best Practices: Amazon SageMaker에서 다음을 수행할 수 있다: - 목표를 반영하는 evaluation metrics를 선택(예: recall, 또는 precision보다 recall에 더 큰 가중치를 두는 beta > 1의 F-beta). - 모델 출력(확률)을 사용해 학습 후 classification thresholds를 조정하여 비용에 따라 precision vs recall을 트레이드오프. - SageMaker Automatic Model Tuning에서 training logs를 통해 게시되는 custom metrics(예: 고정 precision에서의 recall, 또는 custom cost function)를 사용. - confusion matrices와 Precision-Recall curves로 평가(imbalanced 또는 safety 컨텍스트에서는 ROC보다 더 유용한 경우가 많음). 이는 AWS Well-Architected 원칙(특히 reliability와 operational excellence)과도 부합한다: 높은 심각도의 실패를 줄이도록 설계한다. 흔한 오해: High precision은 그럴듯하게 들릴 수 있다(“false alarm으로 시간 낭비하지 말자”). 하지만 여기서는 false alarm 비용이 누출을 놓치는 비용에 비해 매우 작다. 또 다른 함정은 “low precision”이 목표라고 생각하는 것인데, 그렇지 않다. 목표는 high recall이며, precision이 떨어질 수는 있지만 그것이 목표는 아니다. 시험 팁: 비용이 비대칭이면 이를 FN vs FP에 매핑하라. FN이 훨씬 더 비싸면(안전, fraud escape, 질병 미탐), recall(또는 beta > 1의 F-beta)을 우선하라. FP가 더 비싸면(예: 정상 결제 차단), precision을 우선하라. base model만 보지 말고 threshold tuning도 항상 고려하라.

문제 2

한 미디어 분석 회사는 12개의 AWS 계정에 걸쳐 200개 이상의 ML 모델을 운영하고 있으며, 각 모델은 계정 로컬 Amazon ECR 리포지토리에 semantic version 태그로 저장된 Docker image로 패키징되어 있습니다. 컴플라이언스 요구사항은 별도의 governance account에 단일 cross-account 중앙 catalog를 두어 versioned entry, approval status(Approved/Pending/Rejected), lineage metadata, audit log를 지원하고, 공유 data science account에 read-only discovery를 제공하며, producer account가 CI/CD를 통해 새 버전을 등록할 수 있게 하고, 계정 간 container image를 복제하거나 마이그레이션하지 않도록 하는 것입니다. 회사는 어떤 솔루션을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 아티팩트를 이동하지 않으면서 여러 AWS account 전반에서 ML 모델 거버넌스를 중앙화하는 것을 테스트합니다. 가장 적합한 서비스는 Amazon SageMaker Model Registry(SageMaker MLOps의 일부)로, versioned catalog(Model Package Groups), approval workflow, lineage/metadata, 그리고 AWS CloudTrail을 통한 감사 가능성을 제공합니다. 정답인 이유: 옵션 C는 모든 요구사항을 충족합니다: governance account의 단일 중앙 catalog, versioned entry, approval status(Approved/Pending/Rejected), lineage metadata, audit log. SageMaker Model Registry는 모델 패키지 metadata를 중앙에 저장하면서 모델 아티팩트를 URI(예: ECR image URI 및 선택적으로 S3의 model data)로 참조할 수 있게 합니다. 결정적으로, governance account로 container image를 복제할 필요가 없습니다. producer account는 CI/CD를 통해 cross-account로 SageMaker API를 호출하여 새 model package version을 등록할 수 있고, 공유 data science account에는 model package group 및 버전을 list/describe할 수 있는 read-only discovery 권한을 부여할 수 있습니다. 주요 AWS 기능: - Model Package Groups: 하나의 모델에 대한 논리적 그룹화로, semantic versioning은 연속적인 model package version으로 처리됩니다. - Model approval workflow: ModelPackageApprovalStatus는 규제 환경에서 사용되는 PendingManualApproval/Approved/Rejected 패턴을 지원합니다. - Cross-account access: SageMaker resource-based policy(및/또는 governance account로 sts:AssumeRole 하는 IAM role)를 사용하여 producer account가 model package를 생성하고 consumer account가 이를 list/describe할 수 있도록 허용합니다. 필요 시, producer account의 ECR repository policy와 함께 사용하여 권한이 있는 deployment account가 image pull을 할 수 있게 합니다. - Audit logs: SageMaker API 호출은 governance account의 CloudTrail에 캡처되어 컴플라이언스 및 추적 가능성을 지원합니다. - Lineage/metadata: model package description, tag에 custom metadata를 저장하고, 해당되는 경우 SageMaker lineage tracking과 통합합니다. 흔한 오해: ECR replication(A/B)은 “중앙화”처럼 보이지만, image를 명시적으로 복제하므로 “container image를 복제/마이그레이션하지 않기” 제약을 위반하며, approval workflow나 lineage를 제공하지 않습니다. AWS Glue Data Catalog(D)는 데이터 metadata용이며 container/model 거버넌스용이 아니고, model approval state 및 MLOps lifecycle control을 기본적으로 표현할 수 없습니다. 시험 팁: “model catalog”, “approval status”, “versioned entry”, “audit/compliance”가 보이면 SageMaker Model Registry를 떠올리십시오. 문제가 아티팩트 이동을 금지한다면, replication 기반 접근보다 cross-account reference와 resource policy/assume-role 패턴을 사용하는 metadata catalog를 선호하십시오.

문제 3

220명의 data scientist가 있는 한 온라인 여행 플랫폼은 Amazon SageMaker Model Registry를 사용하여 이미 95개의 model group으로 구성된 1,200개가 넘는 model package version을 추적하고 있습니다. 또한 이 과학자들은 pricing optimization, search relevance, fraud detection의 세 가지 business domain에 맞춰져 있으므로, ML platform engineer는 model artifact, model package version, approval status 또는 현재 model group membership을 수정하지 않고도 기존 자산을 이러한 domain별로 구성하여 대규모에서 discoverability를 향상시키는 솔루션을 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 4

한 ML 엔지니어가 Amazon SageMaker XGBoost 알고리즘을 사용하여 뉴스 추천 시스템을 위한 클릭률 예측 모델을 구축하고 있습니다. 이때 이진 분류기는 노출(impression)을 클릭 또는 비클릭으로 라벨링하며, 500만 행과 180개 feature(원-핫 인코딩된 publisher_id 및 time bucket feature 포함)로 학습됩니다. 현재 hyperparameter가 max_depth=10, eta=0.1, subsample=1.0일 때 모델은 학습 세트에서 0.99 AUC와 95% precision을 달성하지만, 홀드아웃된 1주 트래픽과 새로 유입되는 노출에서는 0.68 AUC와 35% precision만 보여 심각한 overfitting을 시사합니다. 알고리즘이나 feature space를 변경하지 않고 새로운 노출에 대한 일반화를 개선하려면 엔지니어는 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 gradient-boosted decision tree(Amazon SageMaker XGBoost)에서의 ML 모델 개발과 regularization을 평가합니다. 증상(학습 지표는 매우 우수하지만 홀드아웃/신규 트래픽 지표는 저조함)은 높은 분산(high variance)/overfitting을 의미합니다. tree boosting에서는 모델 용량(model capacity)이 tree depth 및 관련 복잡도 파라미터에 의해 크게 제어됩니다. 정답이 맞는 이유: max_depth=10이면 tree가 상당히 깊어, 모델이 학습 주(week)의 특이한 패턴을 외우기 쉽습니다. 특히 sparse한 one-hot publisher_id 및 time-bucket feature는 거의 고유한 분할을 많이 만들 수 있습니다. 그 결과 학습 AUC/precision은 거의 완벽하지만, 다른 주(week)와 신규 노출에 대한 일반화는 약해집니다. max_depth를 낮추면 가설 공간(hypothesis space)이 줄어들어(더 얕은 tree), 노이즈나 특정 주(week)에만 해당하는 상관관계를 맞추기보다 더 넓고 안정적인 패턴을 학습하도록 강제합니다. 이는 알고리즘이나 feature space를 바꾸지 않고 overfitting을 줄이는 가장 직접적인 레버입니다. 주요 AWS 기능 / Best Practice: SageMaker XGBoost에서 max_depth는 각 boosted tree의 최대 깊이를 제어하며, 일반적으로 더 작은 값이 일반화에 도움이 됩니다. 이는 ML에서 성능 효율성과 신뢰성을 위해 더 잘 일반화되는 단순한 모델을 선호한다는 AWS Well-Architected 원칙과도 부합합니다. 실무에서는 SageMaker Automatic Model Tuning을 사용해 max_depth(그리고 종종 min_child_weight, gamma, reg_alpha/reg_lambda, subsample/colsample_bytree, early stopping도 함께)를 튜닝하고, 프로덕션 drift에 맞추기 위해 시간 기반 validation split으로 평가합니다. 흔한 오해: eta를 올려 “더 빠르게 학습”하거나 max_depth를 올려 “복잡도를 추가”하고 싶을 수 있지만, 모델이 이미 학습 데이터를 매우 잘 맞추는 상황에서는 둘 다 보통 overfitting을 악화시킵니다. 또 다른 흔한 생각은 feature를 제거하는 것이지만, 문제에서 feature space를 변경하지 말라고 명시하고 있으며, feature 제거는 순수한 hyperparameter 기반 일반화 개선이 아니라 데이터/feature-engineering 변경입니다. 시험 팁: 학습 성능과 validation/test 성능 간 격차가 크면 overfitting/high variance를 의심하십시오. tree-based boosting의 1차 대응은 max_depth를 줄이고, subsampling/column sampling을 추가하며, regularization을 늘리고, early stopping을 사용하는 것입니다. 문제에서 알고리즘과 feature를 제한한다면 모델 복잡도를 줄이는 hyperparameter 변경을 선택해야 하며, 여기서는 max_depth 감소가 해당됩니다.

문제 5

미디어 모니터링 팀이 주당 다국어 팟캐스트 오디오(MP3) 900시간, 주당 컨퍼런스 녹화(MP4 비디오) 300시간, 블로그 게시물 35,000개를 수집하며, 이 중 이탈리아어 항목에 대해서만 24시간 이내에 독일어 요약을 제공해야 합니다. 또한 엔지니어링 노력을 최소화하고 어떤 모델 학습도 피해야 합니다. 어떤 솔루션이 가장 짧은 시간 내에 요구 사항을 충족하나요?

문제 분석

핵심 개념: 이 문제는 audio, video, text 전반에 걸친 multilingual content processing에 대해, 어떤 model training도 피하면서 가장 빠른 fully managed AWS AI solution을 선택하는지를 평가합니다. 필요한 pipeline은 podcasts, conference recordings, blog posts를 처리하고, Italian-language 항목만 식별한 뒤, managed services를 사용하여 24시간 이내에 German summaries를 생성해야 합니다. 정답인 이유: 어떤 선택지도 완벽하게 설계되지는 않았지만, option B가 가장 요구 사항에 가깝습니다. 왜냐하면 MP3 및 MP4 입력에 대해 speech-to-text를 위해 Amazon Transcribe를 올바르게 사용하고, training 없이 summarization을 위해 Anthropic Claude가 포함된 Amazon Bedrock을 사용하기 때문입니다. 하지만 German summaries를 생성하는 데 Amazon Translate로 English로 번역하는 단계는 불필요하며, 더 중요한 점은 이 선택지가 35,000개의 blog posts를 명시적으로 다루지 않는다는 것입니다. 그럼에도 불구하고 다른 선택지들은 AWS services를 잘못 사용하거나 custom model training을 요구하므로 분명히 덜 적합합니다. 따라서 B는 선택지들 중에서 여전히 가장 적절한 정답입니다. 주요 AWS 기능: - Amazon Transcribe batch는 대규모 audio 및 video speech content에 대해 asynchronous transcription을 지원합니다. - Amazon Bedrock은 infrastructure management나 training 없이 multilingual summarization을 위한 Claude와 같은 managed foundation models를 제공합니다. - Amazon Translate는 text를 언어 간에 번역할 수 있지만, model이 직접 summarize할 수 있다면 German summaries를 생성하기 전에 Italian을 English로 번역할 필요는 없습니다. - text blog posts의 경우, 실제 설계에서는 language filtering 이후 원본 text를 직접 Bedrock으로 보내는 방식이 실용적이지만, 그 단계는 어떤 선택지에도 명시적으로 포함되어 있지 않습니다. 흔한 오해: A는 custom model training이 필요하므로 적절하지 않습니다. 문제에서 이를 명시적으로 금지하고 있기 때문입니다. C는 Rekognition이 podcasts와 conference recordings에 대한 speech transcription을 수행하지 않으므로 틀렸습니다. D는 Comprehend가 audio/video를 text로 변환하지 않으며, Stable Diffusion은 text summarization model이 아니므로 틀렸습니다. 시험 팁: AWS AI 시험에서는 먼저 각 modality를 올바른 managed service에 매핑하세요: speech에는 Transcribe, language conversion에는 Translate, text analytics에는 Comprehend, generative text tasks에는 Bedrock입니다. 완벽한 선택지가 없다면, 핵심 요구 사항을 가장 잘 충족하면서 technical mismatches가 가장 적은 것을 고르세요. services를 잘못 사용하거나 불필요한 translation/training 단계를 추가하는 distractors를 주의하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

온라인 마켓플레이스의 한 ML engineer가 200,000건의 과거 거래 데이터를 사용하여 중고 스마트폰의 재판매 가격(USD)을 예측하는 모델을 구축하고 있습니다. 여기서 타깃은 $50에서 $1,500까지 범위의 연속값이며, 이해관계자들은 동일한 단위(USD)로 평균 절대 예측 오차를 보고하는 평가 지표를 요구합니다. 모델의 성능을 평가하기 위해 어떤 지표를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 지도 학습 문제에 적절한 평가 지표를 선택하는지를 테스트합니다. 타깃 변수가 USD로 표현되는 연속적인 재판매 가격이므로, 이는 (분류가 아닌) 회귀(regression) 작업입니다. 또한 지표는 타깃과 동일한 단위로 평균 절대 예측 오차를 표현해야 합니다. 정답이 맞는 이유: Mean Absolute Error (MAE)는 예측값과 실제값 간 오차의 평균 크기를 직접 측정합니다: MAE = average(|y - ŷ|). 절대 차이를 사용하므로 결과는 타깃과 동일한 단위(USD)로 표현됩니다. 이해관계자들이 “USD로 평균 절대 예측 오차”를 원한다면 MAE가 가장 직접적으로 부합합니다. 또한 해석이 쉽습니다. 예를 들어 MAE가 75라면 모델이 평균적으로 $75만큼 빗나간다는 의미로, 가격 책정에 대한 비즈니스 기대와 잘 맞습니다. 주요 AWS 기능 / 모범 사례: AWS ML 워크플로(예: Amazon SageMaker training jobs 및 모델 평가)에서 회귀 지표로는 일반적으로 MAE, MSE/RMSE, R2 등이 사용됩니다. 비즈니스 단위로의 해석 가능성이 중요할 때는 MAE가 자주 선호됩니다. 또한 MSE/RMSE처럼 오차를 제곱하지 않기 때문에 이상치(outliers)에 더 강건합니다(다만 이상치의 영향이 선형적으로는 반영됩니다). SageMaker에서는 학습 중에 MAE를 계산(사용 가능한 경우 custom metric definitions, built-in algorithm metrics)하거나, 학습 후 평가 단계(SageMaker Processing, Pipelines)에서 계산하여 Amazon CloudWatch 또는 SageMaker Experiments에서 추적할 수 있습니다. 흔한 오해: 응시자들은 인기 있는 지표라는 이유로 “Accuracy” 또는 “F1”을 고르는 경우가 많지만, 이는 출력이 이산 레이블인 분류 문제에 적용됩니다. AUC 역시 분류 전용이며 임계값 전반에서의 순위 품질을 측정하는 것으로, USD 단위의 오차를 제공하지 않습니다. 또 다른 흔한 혼동은 MAE와 RMSE 사이에서 발생합니다. RMSE도 USD 단위이지만 큰 오차를 더 크게 강조합니다. 문제는 명시적으로 “average absolute” 오차를 요구하므로 MAE가 정답입니다. 시험 팁: 먼저 ML 문제 유형을 식별하세요: 연속 타깃은 회귀를 의미합니다. 그다음 이해관계자 요구사항을 지표 특성과 매칭하세요: “absolute”와 “same units”는 MAE를 강하게 시사합니다. Accuracy/F1/AUC는 분류 지표이고, MAE/RMSE/R2는 회귀 지표라는 점을 기억하세요. 비즈니스 사용자가 해석 가능한 “평균적으로 몇 달러 차이”를 원할 때는 보통 MAE가 최선의 답입니다.

문제 7

2.5백만 건의 과거 신청 데이터와 18개 feature( age_group 및 income_bracket 포함)를 보유한 온라인 대출 플랫폼이 Amazon SageMaker에서 이진 default-risk 모델을 학습하고 있으며, 보호 대상 그룹 전반에서 성능을 왜곡할 수 있는 패턴(예: 18–25세 신청자 vs 60+ 신청자 간 demographic parity difference > 0.1)을 탐지하고 정량화하기 위해 학습 데이터와 batch prediction 출력 모두를 검토해야 합니다. 어떤 솔루션이 이러한 수준의 분석을 제공합니까?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker에서 학습 데이터와 모델 prediction 모두에 대해 bias를 탐지하고 정량화하는 것을 테스트합니다. 이를 위해 목적에 맞게 설계된 AWS 서비스는 Amazon SageMaker Clarify이며, Clarify는 bias metric(학습 전 및 학습 후)과 explainability(feature attribution)를 제공합니다. 정답이 맞는 이유: 플랫폼은 (1) 학습 dataset과 (2) batch prediction 출력 모두를 검토하여 보호 대상 그룹 간 demographic parity difference가 임계값을 초과하는 것과 같은 패턴을 탐지하고 정량화해야 합니다(예: 18–25세 vs 60+). SageMaker Clarify는 지정된 sensitive attribute(예: age_group)와 label/outcome(예: default vs no default)을 사용하여 입력 dataset에 대한 bias metric(학습 전 bias)과 inference 결과에 대한 bias metric(학습 후 bias)을 계산함으로써 이 워크플로를 직접 지원합니다. Clarify는 processing job으로 실행될 수 있고 SageMaker batch transform 출력과 통합되며, demographic parity, disparate impact 및 기타 group fairness measure 같은 metric을 포함하는 bias report를 생성합니다. 주요 AWS 기능: Clarify는 다음을 지원합니다: - 학습 전 bias 분석: 그룹 간 label 및 feature의 불균형을 탐지. - 학습 후 bias 분석: 그룹 간 prediction outcome을 평가( batch inference 포함). - 구성 가능한 facet( age_group/income_bracket 같은 sensitive feature) 및 그룹(예: 18–25 vs 60+). - 보고서 및 시각화( SageMaker Studio를 통해)와 auditability를 위해 Amazon S3에 저장되는 artifact. - SHAP 기반 feature attribution을 통한 explainability로 prediction의 driver를 이해하며, 이는 bias metric을 보완. 흔한 오해: bias는 데이터를 변환하여 완화할 수 있으므로 data-prep 도구(Glue DataBrew)나 자동화(Lambda)를 선택하고 싶을 수 있습니다. 그러나 요구사항은 단순히 데이터를 정리하거나 변환하는 것이 아니라, 데이터와 prediction 모두에 대해 공식적인 fairness metric으로 bias 패턴을 탐지하고 정량화하는 것입니다. CloudWatch는 운영 모니터링이며 fairness 분석이 아닙니다. 시험 팁: “bias”, “protected groups”, “demographic parity”, “disparate impact”, “explainability”, “training data + predictions” 같은 키워드를 보면 시험은 SageMaker Clarify를 가리키고 있습니다. Clarify( fairness/explainability)를 Model Monitor( data/model drift 및 품질) 및 기본적으로 fairness metric을 계산하지 않는 일반 ETL 도구(DataBrew/Glue)와 구분하십시오.

문제 8

(2개 선택)

한 데이터 과학자가 Amazon SageMaker 외부에서 scikit-learn 이탈(churn) 모델을 내보내고, SSE-S3로 암호화된 버킷(s3://retail-ml-artifacts-prod/models/churn/2025-07-01/)에 7.8-GB model.tar.gz 아티팩트를 저장했습니다. 그리고 동일한 SageMaker domain에서 SageMaker Canvas를 사용하는 비즈니스 분석가가 노코드 평가 및 반복 튜닝을 할 수 있도록 이 모델을 검색 가능(discoverable)하게 만들어야 합니다. Canvas 사용자와 모델을 공유하려면 어떤 요구 사항 조합을 충족해야 합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 SageMaker Canvas가 Canvas 외부에서 생성된 모델을 어떻게 검색하고 사용하는지, 그리고 SageMaker Studio domain 내에서 페르소나 간 모델을 공유하기 위한 거버넌스/권한 경로를 테스트합니다. 핵심 서비스는 Amazon S3(모델 아티팩트), SageMaker Model Registry(model packages/versions), IAM/SageMaker domain execution role입니다. 정답이 맞는 이유: 외부에서 빌드된 scikit-learn 모델을 Canvas에서 “검색 가능(discoverable)”하게 만들려면, 모델이 SageMaker의 모델 거버넌스 계층을 통해 노출되어야 합니다. 동일한 domain/account/region 컨텍스트에서 SageMaker Model Registry에 모델을 model package/version으로 등록하는 것이, Studio/Canvas가 임의의 S3 객체가 아니라 승인/등록된 모델을 나열하고 소비할 수 있게 하는 표준 메커니즘입니다. 또한 모델이 등록되어 있더라도, Canvas(정확히는 Canvas 사용자의 execution role)는 S3에 있는 기본 model.tar.gz를 읽을 수 있어야 합니다. SSE-S3 암호화의 경우 관리해야 할 KMS key policy는 없지만, S3 권한 부여는 여전히 적용됩니다. 따라서 role에는 bucket/key에 대한 s3:GetObject(그리고 일반적으로 해당 prefix에 대한 s3:ListBucket)가 필요합니다. 주요 AWS 기능: - SageMaker Model Registry: model packages, versions, 승인 상태, lineage, 그리고 다운스트림 도구로의 통제된 공유. - IAM 및 S3 access control: 아티팩트 prefix에 대한 s3:GetObject를 위한 bucket policy 및 role 권한. - SSE-S3: SSE-KMS 대비 암호화 관리가 단순하지만, S3 권한 필요성을 제거하지는 않음. 흔한 오해: Canvas에 real-time endpoint 배포가 필요하다고 생각하기 쉽지만, 검색 가능성/공유는 호스팅이 아니라 거버넌스와 액세스에 관한 것입니다. 또한 AWS Marketplace는 내부 모델 공유와 무관합니다. domain 분리도 틀렸습니다. Canvas와 데이터 과학자는 해당 domain 컨텍스트에서 리소스를 공유하려면 동일한 SageMaker domain에 있어야 합니다. 시험 팁: “Canvas/Studio에서 검색 가능(discoverable)”이라는 표현을 보면 “Model Registry + permissions”를 떠올리세요. “S3에 있는 모델 아티팩트”가 보이면, 소비자 페르소나의 IAM role이 정확한 S3 prefix/object를 읽을 수 있는지 항상 검증하세요(암호화 유형에 따라 KMS 권한도 필요할 수 있음).

문제 9

한 공공 의료 네트워크가 Amazon Q Business에 대한 API 호출을 통해 하루 약 2,000건의 질의를 처리하는 내부 법률 보조 챗봇을 배포하고 있습니다. 컴플라이언스 정책에 따라 모델의 응답에는 기밀 코드명 "Project Raven"(정확한 문구 일치)이 절대로 포함되면 안 되며, 해당 문자열이 인덱싱된 소스 문서에 존재하더라도 마찬가지입니다. 또한 기존 인덱스를 수정하지 않고 응답 시점에 제어가 강제되어야 합니다. 이 요구 사항을 충족하기 위해 팀은 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 기존 인덱싱된 콘텐츠에 무엇이 저장되어 있든 관계없이 민감한 용어가 노출되지 않도록 응답 시점(출력 가드레일)에서 동작하는 Amazon Q Business 보안 및 거버넌스 제어를 테스트합니다. 이는 AWS Well-Architected Framework의 “Security” 및 “Data protection” 원칙과 정렬됩니다. 정답이 맞는 이유: 요구 사항은 명확합니다. 인덱싱된 문서에 존재하더라도 챗봇의 응답에는 정확한 문구 “Project Raven”이 절대로 포함되면 안 되며, 기존 인덱스를 수정하지 않고 응답 시점에 제어가 강제되어야 합니다. Amazon Q Business는 생성된 응답에 특정 단어/문구가 나타나지 않도록 차단하는 관리 제어를 제공합니다. “Project Raven”을 차단 문구로 구성하면 검색 결과와 무관하게 API가 반환하는 최종 응답에서 해당 용어가 필터링/마스킹/차단되도록 출력 시점 정책이 적용됩니다. 주요 AWS 기능: Amazon Q Business의 차단 문구(때로는 차단 단어/문구로 설명됨)는 특정 문자열이 응답으로 출력되는 것을 방지하여 컴플라이언스와 안전을 지원하도록 설계되었습니다. 이는 출력 제어(응답 시점 강제)로서 정책이 요구하는 바와 정확히 일치합니다. 액세스 제어 통합 및 콘텐츠 필터링 같은 다른 제어를 보완하지만, 재인덱싱 없이 “이 정확한 문구는 절대 포함되면 안 됨” 제약을 유일하게 충족합니다. 흔한 오해: 흔한 함정은 검색 시점 필터링(문서 또는 결과 제외)에 집중하는 것입니다. 검색에서 일부 항목을 제외하더라도, 모델은 다른 검색된 콘텐츠, 사용자 프롬프트 인젝션, 또는 모델 동작으로 인해 해당 문구를 여전히 생성할 수 있습니다. 또 다른 오해는 콘텐츠를 “우선순위 낮춤”(부스팅)하면 위험이 줄어든다는 것인데, 이는 비노출을 보장하지 않습니다. 시험 팁: “응답에 절대 나타나면 안 됨”과 “응답 시점에 강제”라는 문구가 보이면, 검색 튜닝/랭킹/재인덱싱이 아니라 차단 문구/용어 같은 출력 가드레일을 찾으십시오. 또한 “기존 인덱스를 수정하지 않고” 같은 제약은 재구축/재수집 솔루션을 배제합니다. 의료/컴플라이언스 시나리오에서는 확률적 관련성 튜닝보다 결정론적 제어(명시적 차단)를 선호하십시오.

문제 10

핀테크 스타트업의 데이터 사이언스 팀이 프라이빗 서브넷 내에서 6개의 ml.p3.8xlarge 인스턴스를 사용해 분산 Amazon SageMaker training job을 실행하려고 합니다. 또한 학습 실행 중 SageMaker 프로세스가 사용하는 전송 중 데이터(노드 간 트래픽 및 프레임워크 조정 메시지 포함)가 저장 시(at-rest) 암호화 설정을 변경하지 않고도 엔드 투 엔드로 암호화되도록 보장해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 Amazon SageMaker 분산 학습의 네트워크 보안—특히 저장 시(at-rest) 암호화를 수정하지 않고도 training cluster 내부에서 발생하는 트래픽(노드 간 통신, 조정/제어 메시지, 컨테이너 간 트래픽)의 전송 중(in transit) 암호화—를 테스트합니다. 정답이 맞는 이유: 여러 인스턴스(6개의 ml.p3.8xlarge)에서 분산 학습을 수행할 때 SageMaker는 그래디언트/파라미터 및 조정 메시지(예: MPI/NCCL/Horovod 또는 프레임워크별 collective)를 교환하는 training container cluster를 사용합니다. SageMaker의 inter-container traffic encryption을 활성화하면 cluster 내 training 인스턴스/컨테이너 간 모든 트래픽이 전송 중에 엔드 투 엔드로 암호화됩니다. 이는 학습 실행 중 노드 간 트래픽과 프레임워크 조정 메시지를 암호화해야 한다는 요구 사항을 직접 충족하며, 저장 시(at-rest) 암호화 설정을 변경하지 않고도 이를 달성합니다. 주요 AWS 기능: SageMaker training job은 “inter-container traffic encryption”(때로는 분산 training job에서 노드 간 통신을 암호화하는 것으로 설명됨)을 지원합니다. 이를 활성화하면 SageMaker가 job에 참여하는 인스턴스들 간 네트워크 트래픽이 암호화되도록 training cluster를 구성합니다. 이는 S3/EBS의 저장 시 암호화 또는 model artifact 암호화와는 별개로, 분산 학습 패브릭 내부의 전송 중 암호화에 관한 기능입니다. 프라이빗 서브넷에서 실행하는 것은 호환되며 종종 VPC-only 액세스와 함께 사용되지만, 프라이빗 서브넷만으로는 east-west 트래픽의 암호화를 보장하지 않습니다. 흔한 오해: 자주 빠지는 함정은 KMS key( training job 또는 Studio domain용)를 지정하면 “모든 것”이 암호화된다고 가정하는 것입니다. SageMaker에서 KMS key는 주로 저장 시(at-rest) 암호화(예: training 인스턴스에 연결된 EBS 볼륨, S3의 model artifact, 또는 Studio 스토리지)를 제어합니다. 이는 분산 학습 노드 간 런타임 네트워크 트래픽을 자동으로 암호화하지 않습니다. 또 다른 오해는 Batch Transform 설정을 training job과 혼동하는 것입니다. Batch Transform은 inference/배치 스코어링 기능이지 분산 학습이 아닙니다. 시험 팁: “inter-node traffic”, “framework coordination messages”, 또는 “cluster 내부 east-west traffic” 같은 요구 사항이 보이면, 분산 학습을 위한 전송 중 암호화( inter-container/inter-node traffic encryption)에 명시적으로 해당하는 기능을 찾으세요. 요구 사항에 “at-rest encryption을 변경하지 않고”가 포함되어 있다면, 문제가 스토리지 암호화에 관한 것이 아닌 한 KMS-only 답변은 제외하세요. 또한 training, Batch Transform, Studio domain 구성은 각각 보안 제어가 다르므로 구분해야 합니다.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(3)

지금 학습 시작하기