정답 · 해설

해설

【핵심 용어】 ▸ Class Imbalance(CI) 메트릭 — 범위 [-1, 1], 0 = 완벽 균형, ±1 = 극심 불균형 ▸ SageMaker Clarify — 데이터 편향성 및 공정성 분석 도구 ▸ Balanced dataset — 클래스별 샘플 수 동등 【정답 포인트】 ▸ 균형 이미지 데이터셋 검증 → CI 메트릭 = 0 = 균형 ▸ CI 값 해석: CI → 0 = 균형, CI → ±1 = 불균형 ▸ "equal number" = CI ≈ 0 【오답 체크】 (A) CI ≈ 1: 극도로 한쪽 클래스에 치우친 상태(불균형) (C) DPL 메트릭: Data Wrangler의 메트릭이지만 편향성 감지용(불균형 감지 아님) (D) DPL ≈ -1: DPL은 그룹 간 차별 지표(여기서는 부적절) 【시험 포인트】 CI의 수학적 정의: CI = (n_major - n_minor) / (n_major + n_minor). 균형 데이터에서 n_major ≈ n_minor이므로 CI → 0. 이진 분류에서 0에 가까울수록 균형. Clarify는 공정성/편향 감지 표준 도구. 이미지 분류 데이터셋 검증에 필수.

해설

【핵심 용어】 ▸ Early stopping — 검증 오류가 증가하기 시작할 때 모델 학습을 조기에 종료하는 정규화 기법(과적합 방지) ▸ Overfitting — 학습 데이터에 과도하게 특화되어 검증/테스트 성능이 저하되는 현상 ▸ Training loss vs Validation loss — 학습 손실은 감소하지만 검증 손실은 증가하는 패턴 ▸ Epoch — 전체 학습 데이터를 한 번 순회하는 단위 【정답 포인트】 ▸ "performance peaks early then declines" = 과적합의 전형적인 신호(학습곡선 패턴) ▸ 초기 성공 후 점진적 저하 → 모델이 학습 데이터의 잡음까지 학습한 증거 ▸ Early stopping은 검증 성능 지표가 최고값에서 개선되지 않을 때 학습 중단 ▸ SageMaker에서 검증 메트릭 모니터링 → 자동 또는 수동 조기 중단 구현 가능 【오답 체크】 (A) 레이어 수 증가: 모델 용량/복잡도가 증가하면 과적합 위험이 더욱 심화(악화 방향) (C) 뉴런 수 추가: 각 레이어의 표현 능력을 높이면 복잡 패턴뿐만 아니라 잡음도 학습(과적합 심화) (D) 편향/분산 검토: 편향-분산 트레이드오프를 이해하는 것은 진단 도구지만, 문제 해결 방법 아님 【시험 포인트】 과적합 대응의 핵심: (1) 학습곡선 분석으로 과적합 조기 발견, (2) Early stopping으로 최적 학습 시점 포착. 엔터테인먼트 추천 시스템처럼 복잡한 패턴이 많은 도메인에서 정규화 필수. Patience 파라미터(개선 없이 기다리는 에포크 수)로 미세 조정 가능. 정규화(L1/L2), 드롭아웃과 함께 결합하면 더욱 효과적.

해설

【핵심 용어】 ▸ F1 Score — Precision과 Recall의 조화평균(minority class 성능을 동시에 평가) ▸ Accuracy — 전체 정확도(다수 클래스 편향으로 불균형 데이터에 부적합) ▸ Class imbalance — 한 클래스의 샘플 수가 다른 클래스보다 훨씬 적은 상황 ▸ Image augmentation — 기존 이미지를 회전, 확대, 잡음 추가 등으로 변형하여 새로운 샘플 생성 ▸ SMOTE — 합성 소수집단 과잉샘플링(수치형 특성에만 적합, 이미지 아님) 【정답 포인트】 ▸ "extremely small fraction" + "poor on one class" = 전형적인 불균형 분류 문제 ▸ 불균형 데이터 평가 메트릭 = F1 Score(minority class 가중치 반영) ▸ Accuracy는 다수 클래스만으로도 높은 값 도출 가능(소수 클래스 무시) ▸ 이미지 데이터 증강 = 기존 이미지 변환(SMOTE는 수치형 데이터용) 【오답 체크】 (A) 정확도 최적화 + 이미지 증강: 증강은 맞으나, 정확도는 불균형 데이터에 거짓 신뢰도 제공(소수 클래스 1%일 때 정확도 99% 달성 가능) (C) 정확도 + SMOTE: 정확도 선택 오류 + SMOTE는 수치 테이블 데이터용(이미지 처리 시 부자연스러운 합성 이미지 발생) (D) F1 + SMOTE: F1은 올바른 메트릭이나, SMOTE는 이미지 처리에 표준 방법 아님(이미지 도메인에서는 증강이 표준) 【시험 포인트】 불균형 분류의 2-축 솔루션: (1) 메트릭 선택 = Recall, Precision, F1(소수 클래스 성능 강조), (2) 샘플링 전략 = 이미지는 augmentation, 수치는 SMOTE/oversampling. 소수 클래스가 전체의 1-5%일 때 F1이 모델 진정한 성능을 반영. Amazon SageMaker에서 자동 이미지 증강 지원.

해설

【핵심 용어】 ▸ k-means clustering — 비지도 학습 알고리즘으로 데이터를 k개의 동질적 클러스터로 분할 ▸ Segmentation — 유사한 특성을 가진 객체(환자)들을 그룹화하는 작업 ▸ Hyperparameter k — 클러스터 개수를 사용자가 직접 지정하는 파라미터 ▸ Centroid — 각 클러스터의 중심점(거리 계산의 기준) ▸ Unsupervised learning — 레이블 없이 데이터의 내재적 구조 발견 【정답 포인트】 ▸ "segment patients into groups" = 비지도 학습 클러스터링(명확한 타겟 라벨 없음) ▸ "determine the number of groups by using hyperparameters" = k 파라미터 설정(저위험/중위험/고위험 = k=3) ▸ "similar risk factors" = 동질적 클러스터 형성(환자들의 건강 특성 유사도 기반) ▸ k-means는 거리 기반으로 작동하므로 전처리된 수치 데이터 필요 【오답 체크】 (A) XGBoost: 지도 학습 앙상블 알고리즘(분류/회귀용, 세분화 아님) (C) DeepAR: 시계열 예측 알고리즘(미래 시점 예측용, 환자 분류와 무관) (D) RCF(Random Cut Forest): 이상 탐지 알고리즘(정상/이상 이원 분류, 다중 그룹 세분화 아님) 【시험 포인트】 의료 데이터 분석의 표준: 환자를 위험도 수준별로 그룹화하면 맞춤형 치료 계획 수립 가능. k-means는 (1) 거리 기반 응집도(cohesion) 최대화, (2) 클러스터 간 분리도(separation) 최대화. k 값 선택은 엘보우 방법(elbow method) 또는 실리엣 분석(silhouette analysis) 사용. 환자 건강 기록, 약물 복용력, 생활 방식을 수치화 후 정규화하여 입력.

해설

【핵심 용어】 ▸ Retrieval Augmented Generation(RAG) — 기존 문서 검색 후 그 결과를 바탕으로 텍스트 생성 ▸ Document embedding — 문서를 고정 크기의 수치 벡터로 변환하여 의미적 유사성 계산 가능하게 함 ▸ Vector store — 임베딩된 벡터들을 저장하고 유사도 검색을 지원하는 데이터베이스 ▸ Instruction tuning — 모델을 특정 명령이나 작업에 최적화하도록 미세조정하는 기법 ▸ Bedrock knowledge base — S3 문서를 임베딩하여 검색 가능하게 관리하는 AWS 기능 【정답 포인트】 ▸ RAG 시스템의 핵심: (1) 문서 검색(embedding 필수), (2) 유사 문서 검색, (3) LLM으로 답변 생성 ▸ "process PDF files and store in vector store" = embedding 모델 필수 ▸ Cohere Embed Multilingual = Bedrock 지식 기반의 표준/권장 임베딩 모델 ▸ 다국어 지원으로 글로벌 PDF 컬렉션 처리 가능(768차원 벡터 출력) 【오답 체크】 (A) Titan Text Premier: 텍스트 생성 모델(embedding 모델 아님, 응답 생성 단계에만 사용) (B) Mistral 7B Instruct: 지시 조정된 LLM(문서 임베딩 기능 없음) (C) Claude Sonnet: 대화형 대규모 언어 모델(임베딩 기능 없음, 최종 응답 생성 단계에만 사용) 【시험 포인트】 Bedrock RAG 구현 흐름: (1) 문서 수집(S3) → (2) Cohere Embed로 벡터화 → (3) OpenSearch/Pinecone 벡터 저장소 저장 → (4) 쿼리 벡터화 후 유사 문서 검색 → (5) Claude/Titan으로 검색 결과 기반 답변 생성. Cohere Embed는 768차원 조밀 벡터로 의미 정보 압축. Bedrock 지식 기반은 자동 청킹(chunking)과 메타데이터 추출 지원.

해설

【핵심 용어】 ▸ AWS Glue interactive sessions — 서버리스 Apache Spark 환경으로 대규모 ETL 작업 실행 ▸ PII detection transform — AWS Glue의 내장 변환 기능으로 개인식별정보(이름, 주민번호, 신용카드번호 등) 자동 감지/제거 ▸ Petabyte-scale data — 매우 큰 규모 데이터(분산 처리 필수) ▸ Unstructured data — 정형화되지 않은 텍스트, 문서, 이메일 등 ▸ Serverless processing — 인프라 관리 없이 필요한 만큼 리소스 자동 할당 【정답 포인트】 ▸ "petabytes of unstructured data" = 분산 처리 엔진(Spark) 필수 ▸ "identify and remove PII" = Glue의 Detect PII transform 기능 활용 ▸ AWS Glue interactive sessions = 서버리스(비용 효율) + 확장 자동화 ▸ "prepare data for SageMaker ML" = 전처리 후 모델 학습용 데이터셋 생성 【오답 체크】 (B) SageMaker Canvas: 노코드 ML 도구(대규모 ETL 파이프라인 설계에 부적합) (C) SageMaker Clarify: 모델 편향성/공정성/설명성 분석(PII 자동 제거 기능 없음) (D) Amazon Comprehend DetectEntities: NLP 개체 명인식(PII 감지하나, 자동 제거 기능 제한적, API 호출 비용 높음) 【시험 포인트】 GDPR, HIPAA, CCPA 같은 규제 준수 요구사항에서 Glue의 PII detection transform은 핵심. 페타바이트 규모는 단일 머신 처리 불가능(Spark 분산 병렬 처리 필수). Glue interactive sessions는 (1) 빠른 프로토타입, (2) 디버깅 용이, (3) SageMaker와 원활 통합. 의료/금융/개인정보 취급 데이터셋의 표준 전처리 솔루션.

해설

【핵심 용어】 ▸ SageMaker Model Monitor — 프로덕션 모델의 데이터 드리프트(distribution shift) 자동 감지 ▸ Feature distribution drift — 입력 데이터의 통계적 분포가 기준값과 달라지는 현상(마케팅 캠페인으로 인한 고객 행동 변화) ▸ SageMaker Clarify — 데이터 편향, 피처 분포 변화, 모델 해석성 분석 도구 ▸ Baseline statistics — 모델 학습 시 사용한 데이터의 통계 기준값(평균, 분산, 분포) ▸ Proactive monitoring — 성능 문제 발생 전 조기 감지 【정답 포인트】 ▸ "sharp drop in performance" = 데이터 분포 변화 신호(feature distribution shift) ▸ "detect feature distribution changes" = SageMaker Clarify 분석 ▸ "near real-time input validation" = Model Monitor(거의 즉시 드리프트 감지) ▸ "before future campaigns" = 선제적 모니터링으로 조기 경보 【오답 체크】 (B) CloudWatch + feature attribution: 속성 추적은 설명성 강화용(성능 저하 예측/방지 아님) (C) Clarify bias detection + latency alarm: 편향 감지와 지연시간은 성능 저하의 일부 원인이나 근본 원인(분포 변화) 미반영 (D) Constraints monitoring + error logs: 로그 분석은 사후 대응(선제적 감지 아님) 【시험 포인트】 마케팅 캠페인의 영향: 새로운 고객 층 유입 → 과거 데이터와 다른 특성 분포(예: 연령, 지역, 구매력) → 모델이 학습하지 않은 패턴 → 추천 정확도 저하. Model Monitor는 (1) 기준 통계(mean, variance, histogram) 설정, (2) 실시간 입력 모니터링, (3) 편차 자동 감지, (4) CloudWatch 경보 트리거. Clarify는 근본 원인 분석(어느 feature가 변했나?)에 활용. 추천 시스템의 성능 저하 대응 표준 절차.

해설

【핵심 용어】 ▸ Stratified split — 각 그룹(월, 지역)의 비율을 학습/검증 데이터셋에 동일하게 유지 ▸ Seasonality — 특정 시기(계절 또는 월별)에 특이한 패턴을 보이는 현상(높은 판매 월) ▸ Distribution mismatch — 학습 데이터와 검증 데이터의 분포가 다를 때 발생(왜곡된 성능 평가) ▸ Random split — 임의로 데이터를 나누면 계절성 같은 편향이 검증셋에 과다/과소 포함될 위험 ▸ Normalization — 수치 피처의 스케일을 표준화(평균 0, 표준편차 1로 변환) 【정답 포인트】 ▸ "특정 두 달마다 높은 판매" = 월별 계절성 패턴 존재 ▸ 무작위 분할 → 검증셋이 높은 판매 월 과다/과소 포함 → 검증 성능 왜곡 ▸ 층화된 분할 = 각 월과 지역의 비율을 학습/검증에 균등 배분 ▸ 공정한 성능 평가 = 학습과 검증의 분포 일치 【오답 체크】 (A) 이상값 제거: 높은 판매는 유효한 패턴(잡음 아님), 정보 손실 초래 (C) 전체 정규화: 수치 스케일만 조정(월 간 판매량 편차와 계절성은 미반영) (D) 지역별 정규화: 지역 내 편차는 감소하나 월별 계절성 패턴 해결 안 함 【시험 포인트】 시계열 분류 + 계절성 = 층화된 분할 필수. 20년 월간 데이터(240개 샘플)에서 계절성은 강력한 신호. 임의 분할 시 검증셋이 높은 판매 월(예: 11월, 12월) 과다 포함 → 검증 정확도 거짓으로 높음, 또는 과소 포함 → 거짓으로 낮음. Stratified split은 month와 region 같은 그룹 변수의 클래스 분포를 학습/검증에 동일 비율로 배분. SageMaker에서 sklearn의 StratifiedKFold 또는 StratifiedShuffleSplit 사용.

해설

【핵심 용어】 ▸ Class Imbalance — 클래스별 샘플 수 불균형(결함 200 vs 정상 1,800)으로 소수 클래스 성능 저하 ▸ Oversampling — 소수 클래스 샘플을 복제/증강해 다수 클래스와 균형 맞춤 ▸ Undersampling — 다수 클래스 샘플을 줄여 균형 맞춤(정보 손실 위험) ▸ Amazon Rekognition Custom Labels — 커스텀 이미지 분류/객체 탐지 관리형 서비스 【정답 포인트】 ▸ "소수 클래스(결함 200장) 성능 저하" + "불균형 해소" → 소수 클래스인 결함 이미지를 oversampling해 균형 확보 ▸ C: 결함 이미지를 오버샘플링하면 소수 클래스 학습 신호가 강화됨 【오답 체크】 (A) 수백 장만 사용은 데이터 축소로 불균형·데이터 부족 문제 미해결. (B) 소수 클래스(200장)를 언더샘플링하면 더 줄어 성능 악화. (D) 전량 사용으로 도구만 바꾸는 것은 불균형 자체를 해소하지 못함. 【시험 포인트】 소수 클래스 성능 저하 → 소수 클래스 oversampling(또는 SMOTE). 다수 클래스에 undersampling 적용.

해설

【핵심 용어】 ▸ SageMaker Data Wrangler — S3, Athena, Redshift, Snowflake 등 다양한 데이터 소스에 직접 연결 ▸ Multi-source integration — 여러 데이터베이스/저장소의 데이터를 단일 도구에서 수집/변환 ▸ Direct data loading — 중간 ETL 도구 거치지 않고 소스에서 직접 데이터 로드 ▸ Data profiling — 데이터 통계, 결측치, 이상값 자동 분석 ▸ Data transformation — 결측치 처리, 인코딩, 정규화 등 전처리 【정답 포인트】 ▸ "directly from S3, Athena, and Snowflake" = 다중 소스 단일 도구로 지원 ▸ SageMaker Data Wrangler = 통합 데이터 수집 + 변환 + 검증 ▸ 직접 로드(Direct load) = DataSync 같은 중간 동기화 도구 불필요 ▸ UI 기반 작업 = 코드 최소화, 시각적 워크플로우 【오답 체크】 (A) AWS Glue DataBrew: 데이터 정제 도구(다중 소스 연결 기능 제한적) (B) SageMaker Pipelines + DataSync: Pipelines은 ML 오케스트레이션 프레임워크, DataSync는 온프레미스-AWS 간 동기화(클라우드 데이터 로드에 부적합) (C) Feature Store + Spark: Feature Store는 ML 피처 저장/관리용(사후 단계), S3/Athena 직접 연결보다는 처리된 피처 저장용 【시험 포인트】 SageMaker Data Wrangler는 (1) 커넥터 UI로 S3, Athena, Snowflake 쿼리, (2) 데이터 로드, (3) 통계 및 결측치/이상값 시각화, (4) 자동 변환(인코딩, 정규화, 필터링), (5) SageMaker 학습용 내보내기를 원클릭으로 처리. 다중 데이터 소스 통합 시나리오의 표준 솔루션. 데이터 과학자가 코드 없이 빠르게 데이터 준비.

해설

【핵심 용어】 ▸ SKLearnProcessor — SageMaker에서 scikit-learn 스크립트를 실행하는 처리 작업 컨테이너 ▸ Processing job — 데이터 전처리를 별도 EC2 인스턴스에서 실행하는 SageMaker 작업 ▸ Custom preprocessing script — 사용자 정의 데이터 변환 로직(scikit-learn 패키지 활용) ▸ SageMaker Python SDK — AWS와 SageMaker를 프로그래밍으로 제어하는 도구 ▸ Docker image — 프레임워크별 사전 구성된 컨테이너(scikit-learn용 자동 관리) 【정답 포인트】 ▸ "custom scikit-learn script" = SKLearnProcessor 필수 ▸ "prepare data and train" = Processing job(전처리) + Training job(모델 학습) ▸ SageMaker Python SDK = 모든 작업 오케스트레이션(스크립트 업로드, 실행, 결과 저장) ▸ 프레임워크별 Processor = scikit-learn, PyTorch, TensorFlow 등 각각 최적화된 환경 【오답 체크】 (A) AWS Lambda: 함수 실행 시간 제한(최대 15분), 메모리 제한(최대 10GB) → 대규모 데이터 처리 부적합 (C) HuggingFaceProcessor: Hugging Face 모델 및 변환용(scikit-learn 스크립트 아님) (D) AWS Glue ETL: Glue 맞춤형 레시피는 PySpark 또는 Python 스크립트로 작성(scikit-learn 라이브러리 지원하나 SageMaker 통합 약함) 【시험 포인트】 SageMaker는 각 프레임워크별 Processor 클래스 제공: SKLearnProcessor(scikit-learn), PyTorchProcessor(PyTorch), TensorFlowProcessor(TensorFlow), XGBoostProcessor(XGBoost). SKLearnProcessor는 (1) 로컬 스크립트 → S3에 업로드, (2) EC2 인스턴스에서 컨테이너 실행, (3) 결과 S3 저장을 자동 처리. 데이터 과학자의 기존 scikit-learn 코드를 SageMaker 프로덕션 파이프라인으로 바로 적용 가능. 표 형식 데이터 변환의 표준 방법.

해설

【핵심 용어】 ▸ bedrock:InvokeModel — Amazon Bedrock의 모든 기초 모델(Titan, Claude, Mistral 등) 호출 권한 ▸ sqs:ReceiveMessage — Amazon SQS 큐에서 메시지를 수신하는 권한 ▸ sqs:DeleteMessage — 처리 완료 후 SQS 큐에서 메시지를 제거하는 권한 ▸ bedrock:Get* — Bedrock 모델 정보, 메타데이터 조회(호출 아님) ▸ IAM 최소 권한 원칙(Least Privilege) — 필요한 최소 권한만 부여 【정답 포인트】 ▸ 애플리케이션 3단계 흐름: (1) SQS 메시지 읽기, (2) Bedrock 모델 호출(이미지 생성), (3) 메시지 삭제 ▸ (1) SQS 작업: sqs:ReceiveMessage 필수 ▸ (2) Bedrock 작업: bedrock:InvokeModel 필수(정답 AC에서 A에 해당) ▸ (3) SQS 정리: sqs:DeleteMessage 필수(정답 AC에서 C에 해당) 【오답 체크】 (B) bedrock:Get*: 모델 정보/메타데이터 조회만 가능(실제 모델 호출 불가) (D) sqs:GetQueueAttributes: 큐 속성(메시지 수, 가시성 타임아웃 등) 조회만(메시지 수신/삭제 권한 없음) (E) sagemaker:PutRecord*: SageMaker Feature Store 기록 추가(Bedrock/SQS와 무관) 【시험 포인트】 다중 AWS 서비스 권한 설계의 핵심: (1) 각 서비스별 필요한 작업 식별, (2) 필요한 최소 권한만 부여(불필요한 권한은 거부). SQS와 Bedrock은 독립적인 서비스이므로 각각의 권한이 필요. bedrock:InvokeModel은 특정 모델 리소스(예: arn:aws:bedrock:region::foundation-model/amazon.titan-image-generator-v1)에 대한 Action. sqs:ReceiveMessage와 sqs:DeleteMessage는 특정 SQS 큐 ARN에 대한 Action. 2-선택 문제에서 서비스별로 최소 하나씩 선택되도록 출제.

해설

【핵심 용어】 ▸ Microsoft Purview Sensitive Information Type — 규정 준수용 민감 정보 자동 분류자, 텍스트 기반 콘텐츠 대상 ▸ Documents — 텍스트가 포함된 문서 파일이 분류 대상 【정답 포인트】 ▸ "민감 정보 유형 분류자가 분류 가능한 파일" → 텍스트를 추출·패턴 매칭할 수 있는 문서(Documents) ▸ A: 분류자는 텍스트 콘텐츠를 스캔하므로 문서가 대상 【오답 체크】 (B) 비디오는 텍스트 패턴 매칭 대상 아님. (C) 오디오는 텍스트 콘텐츠가 아니라 분류 불가. (D) 이미지는 SIT 분류자의 직접 대상이 아님. 【시험 포인트】 민감 정보 분류자는 텍스트 기반 → 문서 대상. 영상/음성/이미지는 대상 아님.

해설

【핵심 용어】 ▸ Azure Network Security Group (NSG) — 서브넷/NIC 트래픽 필터링 규칙 집합 ▸ Priority(우선순위) — 규칙 평가 순서를 정하는 값, 기본 규칙은 높은(65000+) 우선순위 번호에 위치 ▸ 기본 규칙 vs 사용자 지정 규칙 — 기본 규칙은 특정 우선순위 범위에 예약되어 있음 【정답 포인트】 ▸ "기본 규칙과 사용자 지정 규칙 구분" → Priority 값으로 판별(기본 규칙은 65000 이상 예약 범위) ▸ C: 우선순위 번호 범위로 기본/커스텀 여부 식별 【오답 체크】 (A) Source는 트래픽 출처일 뿐 규칙 유형 구분 기준 아님. (B) Protocol은 TCP/UDP 등 프로토콜 지정일 뿐 유형 구분 불가. (D) Port는 포트 지정일 뿐 기본/커스텀 판별 불가. 【시험 포인트】 NSG 기본 규칙은 예약된 Priority 번호(65000+)로 식별.

해설

【핵심 용어】 ▸ git pull — 원격 저장소의 최신 커밋을 로컬로 가져와 병합(fetch + merge) ▸ git push — 로컬 커밋을 원격에 업로드 ▸ git commit — 로컬 변경 사항 스냅샷 기록 【정답 포인트】 ▸ "다른 팀원이 병합한 최신 노트북을 못 봄" + "최신 업데이트 반영" → 원격의 최신 내용을 당겨오는 git pull ▸ A: !git pull origin master로 원격 병합본을 로컬 SageMaker 노트북에 반영 【오답 체크】 (B) commit은 로컬 변경 기록일 뿐 원격 내용을 가져오지 않음. (C) push는 로컬을 원격에 올리는 것으로 방향이 반대. (D) branch는 브랜치 목록/생성일 뿐 업데이트 반영과 무관. 【시험 포인트】 원격 최신 내용 반영 → git pull. push는 업로드, commit은 로컬 기록.

해설

【핵심 용어】 ▸ SageMaker Clarify — 편향(bias)·설명가능성 분석, DPL 등 편향 지표 산출 ▸ DPL (Difference in Proportions of Labels) — 클래스 간 라벨 비율 차이, 0에 가까울수록 균형 ▸ SageMaker Data Wrangler — 데이터 전처리/균형 조정(oversampling·undersampling) 【정답 포인트】 ▸ "DPL 0.4" + "라벨 발생을 균등하게" → DPL을 0에 가깝게 줄여야 함, 소수 클래스 oversampling으로 비율 격차 축소 ▸ C: random oversampling으로 소수 클래스를 늘려 DPL(비율 차이)을 감소 【오답 체크】 (A) oversampling은 맞으나 DPL을 '증가'시킨다는 목표가 반대(균형은 DPL 감소). (B) undersampling으로 DPL을 증가시킨다는 것도 목표와 반대. (D) undersampling으로 DPL 감소는 가능하나 데이터 손실이 크고, '대부분 데이터 활용' 취지에 부적합. 【시험 포인트】 균형(라벨 균등) 목표 = DPL을 0으로 축소. 데이터 보존하며 균형 → oversampling.

해설

【핵심 용어】 ▸ High Variance(고분산) — 과적합 경향, 학습 데이터에 과도 적합해 일반화 저하 ▸ L2 Regularization — 가중치 크기에 페널티를 부과해 과적합 억제, 일반화 향상 ▸ Learning Rate — 최적화 스텝 크기(수렴 속도 관련, 과적합 직접 억제 아님) 【정답 포인트】 ▸ "high variance(과적합)" + "학습 시간 크게 늘리지 않고 일반화 개선" → 정규화 강도(L2) 증가가 표준 처방 ▸ C: L2 정규화 파라미터를 키우면 가중치가 억제되어 과적합 완화·일반화 향상 【오답 체크】 (A) 레이어 증가는 모델 복잡도를 키워 분산(과적합)을 오히려 악화. (B) 학습률 감소는 수렴 속도에 영향, 과적합 억제 수단이 아니며 학습 시간 증가. (D) 배치 크기 대폭 증가는 일반화를 오히려 해칠 수 있고 목적과 무관. 【시험 포인트】 고분산=과적합 → 정규화(L2/L1·dropout) 강화가 정석 처방.

해설

【핵심 용어】 ▸ Microsoft Purview Insider Risk Management — 내부 사용자의 잠재적 위험 활동 탐지 및 위험 점수 부여 ▸ Communication Compliance — 통신 정책 위반 탐지(별도 기능) ▸ eDiscovery — 법적/규제 대응 콘텐츠 검색·보존·내보내기(별도 기능) 【정답 포인트】 ▸ "내부자 위험 관리 역할" → 잠재적으로 유해한 사용자 활동을 탐지하고 활동에 위험 점수를 부여 ▸ C: 사용자 활동 탐지 + 위험 점수화가 Insider Risk Management의 핵심 기능 【오답 체크】 (A) 통신 정책 위반 탐지는 Communication Compliance의 역할. (B) 리소스 감사/규정 준수 평가는 Compliance Manager 등 다른 기능. (D) 콘텐츠 검색·보존·내보내기는 eDiscovery의 역할. 【시험 포인트】 Insider Risk Management = 내부 사용자 위험 활동 탐지 + 위험 점수 부여.

해설

【핵심 용어】 ▸ SIEM (Security Information and Event Management) — 로그·이벤트 수집·상관 분석으로 악성 활동 탐지 및 리포트 제공 ▸ SOAR — 자동 사고 대응/복구(SIEM과 구분) 【정답 포인트】 ▸ "SIEM의 기능" → 로그를 검토해 악성 활동에 대한 리포트를 제공 ▸ C: SIEM은 로그 분석·상관관계로 위협/악성 활동을 탐지하고 보고 【오답 체크】 (A) 애플리케이션 통신 리뷰/리포트는 네트워크 트래픽 분석 도구의 기능. (B) 지출 한도 알림은 비용 관리(예: 예산 경보) 기능, 보안과 무관. (D) 자동 사고 복구는 SOAR의 영역. 【시험 포인트】 SIEM = 로그·이벤트 수집·분석으로 악성 활동 탐지·보고. 자동 대응은 SOAR.

해설

【핵심 용어】 ▸ Amazon EMR 노드 유형 — Primary(클러스터 관리), Core(데이터 저장 HDFS + 연산), Task(연산 전용, HDFS 없음) ▸ Task Node — 스토리지 없이 처리량만 추가, Spot Instance에 최적(중단돼도 데이터 손실 없음) ▸ Spot Instance — 저렴하지만 중단 가능, 상태 비저장 워크로드에 적합 【정답 포인트】 ▸ "처리 시간 단축" + "가장 비용 효율적" → Spot으로 Task 노드 증설(연산 능력 추가, 중단돼도 HDFS 데이터 안전) ▸ C: Spot Task 노드는 저비용으로 처리량을 늘리기에 가장 적합 【오답 체크】 (A) Primary 노드는 보통 단일/소수 관리 노드, Spot·확장 대상이 아님. (B) Core 노드는 HDFS 데이터 보유, Spot 중단 시 데이터 손실 위험. (D) On-Demand Core 증설은 안정적이나 비용이 더 비쌈(비용 효율 저하). 【시험 포인트】 EMR 비용 효율 스케일링 → Spot으로 Task 노드 추가. Core는 데이터 보유라 Spot 부적합.