정답 · 해설

해설

【핵심 용어】 ▸ AWS Glue DataBrew — 시각적 데이터 준비 도구. 코드 불필요, 드래그-드롭으로 레시피 작성. 원-핫 인코딩 변환 기본 지원 ▸ One-Hot Encoding — 범주형 변수를 이진 열들로 변환 (예: "색상" → "색상_빨강", "색상_파랑" 열) 【정답 포인트】 ▸ '코드 불필요한(no-code) 솔루션' → DataBrew 선택 기준 ▸ DataBrew는 원-핫 인코딩 변환을 UI 레시피로 직접 지원 ▸ 대화형 인터페이스로 미리보기 후 작업 생성 ▸ 자동으로 S3 결과 저장 구성 가능 ▸ 비기술 사용자도 사용 가능한 완전 관리형 서비스 【오답 체크】 (B) Athena + SQL: 원-핫 인코딩을 SQL로 구현하기 어려움. CASE WHEN 조합으로 가능하지만 복잡 (C) Glue ETL Notebook: 코딩 필요 (PySpark). '코드 불필요' 요구사항 미충족 (D) Redshift + Spectrum: 클러스터 관리 오버헤드. 데이터 준비보다 분석용. 비용 높음 【시험 포인트】 코드 불필요 + 데이터 변환 → DataBrew. Glue 서비스 차이(DataBrew/ETL/Catalog) 이해.

해설

【핵심 용어】 ▸ Script Mode(스크립트 모드) — SageMaker의 기존 스크립트를 최소 수정으로 실행 가능. 사용자 정의 학습 코드 지원 ▸ PyTorch Training Script — 온프레미스 Python/PyTorch 코드 그대로 사용 가능 【정답 포인트】 ▸ 'PyTorch 알고리즘' + '기존 스크립트 재사용' → Script Mode 최적 선택 ▸ Script Mode는 사용자 스크립트(train.py)를 SageMaker에서 직접 실행 ▸ PyTorch Framework 컨테이너 자동 제공 ▸ 최소한의 코드 수정만으로 마이그레이션 가능 ▸ on-premises → cloud 전환 시간 최소화 【오답 체크】 (A) 기본 제공 알고리즘: 사전 구현된 알고리즘만 제공. 커스텀 PyTorch 코드 실행 불가 (B) Canvas: 노-코드 비즈니스 인텔리전스 도구. 개발자 스크립트 지원 안 함 (C) JumpStart: 사전 학습된 모델과 예제 제공. 기존 스크립트 재사용 목적 아님 【시험 포인트】 커스텀 프레임워크 코드 마이그레이션 → Script Mode. SageMaker 기능별 사용 시나리오 차이.

해설

【핵심 용어】 ▸ QuickSight Anomaly Detection Insights — AI 기반 이상치 자동 감지. 통계 모델 활용 ▸ Calculated Field — 기존 필드의 수식 조합으로 새 필드 생성. 시각화 보강용 【정답 포인트】 ▸ '이상치를 시각적으로 표시' + '어떤 가격이 비정상적인지 결정' → 이상 탐지 인사이트 필수 ▸ QuickSight의 Anomaly Detection Insights가 ML 기반으로 이상치 자동 식별 ▸ 막대 차트와 이상 탐지 조합으로 시각화 + 분석 동시 제공 ▸ 계산 필드는 시각화 표현만 개선할 뿐 이상치 식별은 못함 【오답 체크】 (A) 제곱근 계산: 가격 시각화만 변형. 이상치 식별 로직 없음. Lambda 스캔은 과도 (B) DataBrew REMOVE_OUTLIERS: 이상치를 제거하는 것이지 시각화 목표 미충족. 식별 후 표시해야 함 (D) 하위 10개 필터: 고정된 수의 최소값만 선택. 동적 이상치 감지 불가. 통계 근거 없음 【시험 포인트】 이상치 시각화 + 감지 → QuickSight Anomaly Detection Insights. 계산 필드는 표현 도구일 뿐.

해설

【핵심 용어】 ▸ Direction Parameter(방향) — 이상 탐지 범위 제한. 'All'=높음/낮음 모두, 'Lower'=낮은 것만, 'Upper'=높은 것만 ▸ Anomaly Frequency(식별 빈도) — 탐지된 이상치의 수 ▸ Recall(재현율) — 실제 이상치 중 올바르게 감지된 비율 【정답 포인트】 ▸ 'All' → 'Lower than expected'로 변경 = 탐지 범위 축소 ▸ 기존: 높음 + 낮음 이상치 모두 감지 ▸ 변경 후: 낮은 이상치만 감지 ▸ 탐지 대상이 절반으로 감소 → 식별 빈도 ↓ ▸ Recall도 감소: 실제 높은 이상치들을 감지하지 못하므로 TP/(TP+FN) 감소 【오답 체크】 (A) 빈도 증가: 반대. 범위 축소로 감지 수 감소 (C) 빈도 증가: 위와 동일한 오류 (D) 빈도 감소 + 재현율 증가: 모순. 빈도가 감소하면 절대 재현율도 감소 【시험 포인트】 파라미터 범위 제한 → 감지 대상 감소 → 식별 빈도 & 재현율 동시 감소. 이상 탐지 파라미터 영향 이해.

해설

【핵심 용어】 ▸ Lift and Shift(리프트 앤 시프트) — 최소 수정으로 온프레미스 시스템을 클라우드로 이전 ▸ Docker Image — 애플리케이션과 의존성을 포함한 컨테이너 이미지 ▸ ECR(Elastic Container Registry) — AWS 관리형 Docker 이미지 레지스트리 【정답 포인트】 ▸ '각 서비스가 자체 독립형 Docker 이미지' → 기존 이미지 그대로 사용 가능 ▸ '최소 운영 오버헤드' → 코드 재설계/재학습 제외 ▸ 온프레미스 K8s → EKS로 변경 필요 최소화 ▸ ECR 업로드 + EKS 배포 파이프라인 구성 = 가장 직접적인 마이그레이션 ▸ 서비스 로직은 변경 없음, 인프라만 변경 【오답 체크】 (A) Kubeflow 재설계: 기존 Docker 이미지 무시, 전체 서비스 재구현 필요. 높은 오버헤드 (C) Redshift ML 재학습: 다른 플랫폼으로 마이그레이션. Kubernetes 환경 무시. 복잡도 증가 (D) SageMaker 노트북: 재학습 필요, 배포 구조 변경. EKS 목표 달성 불가 【시험 포인트】 Docker 이미지 재사용 + 최소 오버헤드 → ECR + EKS 배포. 리프트 앤 시프트 전략 이해.

해설

【핵심 용어】 ▸ Spot Instances — 온디맨드 대비 70~90% 할인. 언제든 중단 가능하지만 가격은 저렴 ▸ Interruption — AWS가 필요시 인스턴스를 회수할 수 있음. 2분 공지 ▸ Checkpoint(체크포인트) — 학습 상태 저장. 재개 시점부터 다시 시작 가능 【정답 포인트】 ▸ '48~72시간 집약적 작업' + '중단 및 재개 가능' → Spot Instances 최적 조건 ▸ '고정 예산' → 최저 비용 필수 = Spot 가장 저렴 ▸ 자동 체크포인팅으로 Spot 중단 후 재개 가능 (지속성 보장) ▸ SageMaker Training은 자동 체크포인트 지원 ▸ 비용 = Reserved보다 70~90% 저렴 【오답 체크】 (A) Reserved Instances: 1년/3년 약정 필요. 필요 시점 불확실하면 비용 낭비 (B) On-Demand: 가장 비싼 옵션. 고정 예산 제약 위반 (C) Savings Plans: Reserved와 유사하게 장기 약정. Spot만큼 저렴하지 않음 【시험 포인트】 장시간 + 중단 가능 + 저비용 → Spot + Checkpoint. 예산 최적화 시나리오에서 Spot 활용.

해설

【핵심 용어】 ▸ Amazon Q Business — 기업 데이터 기반 RAG 생성형 AI. 접근 제어 및 필터링 지원 ▸ Document Attribute Filter — 메타데이터(생성 날짜 등) 기반으로 문서 자동 필터링 ▸ Source Attribution — 응답의 출처 문서만 표시. 필터링 기능 없음 【정답 포인트】 ▸ '가격에 대한 응답이 1개월 미만 문서만 사용' → 질의 유형별 필터 필요 ▸ Document Attribute Filter가 문서 메타데이터(created_date)로 동적 필터링 ▸ 특정 질의 주제(가격)별로 필터 조건 설정 가능 ▸ Amazon Q Business가 이 기능을 네이티브 지원 ▸ RAG 파이프라인에서 소스 문서를 사전에 필터링 【오답 체크】 (B) Source Attribution: 인용 표시만. 문서 선택 필터링 기능 없음. 이전 문서도 응답에 포함될 수 있음 (C) Amazon Q Developer: 개발자용 AI 어시스턴트. 기업 RAG 및 속성 필터링 기능 부족 (D) 폴더 분할 + 접근 제어: 수동 관리, 확장성 떨어짐. 동적 필터링 불가 【시험 포인트】 RAG 시스템에서 질의 유형별 소스 필터링 → Document Attribute Filter. Amazon Q 기능차이(Business vs Developer) 이해.

해설

【핵심 용어】 ▸ Factorization Machines(FM) — 고차원 희소 데이터의 상호작용 학습에 최적화. 저수준 인수분해로 효율적 계산 ▸ Sparse Matrix(희소 행렬) — 대부분 0인 행렬. 원-핫 인코딩된 2,000개 범주는 매우 희소 ▸ Recommendation Problem — 사용자 피처로 카테고리(공항) 예측 【정답 포인트】 ▸ '높은 차원 희소 행렬' + '범주형 피처 + 원-핫 인코딩' → FM 전문 분야 ▸ FM은 인수분해로 2,000개 범주의 희소성 효율적 처리 ▸ 피처 간 상호작용(사용자 위치 × 검색 기록) 자동 학습 ▸ SageMaker FM은 다중 클래스 분류(어느 공항인지) 지원 ▸ 추천 시스템에 최적화된 SageMaker 기본 알고리즘 【오답 체크】 (A) CatBoost: 범주형 데이터 전문이지만, 희소 데이터 처리는 덜 효율적. 원-핫 이후 차원 폭발 (B) DeepAR: 시계열 예측 알고리즘. 시간 시리즈 데이터 필요. 상황 미맞음 (D) k-means: 비지도 클러스터링. 목표 변수(다음 공항)를 무시. 추천 모델 아님 【시험 포인트】 희소 고차원 + 추천 → Factorization Machines. SageMaker 알고리즘별 최적 사용 시나리오.

해설

【핵심 용어】 ▸ Target Tracking Scaling Policy — 메트릭(호출/분)을 목표로 자동 스케일. 반응 기반 ▸ Cold Start Problem — 초기 인스턴스 0개로 첫 요청 대응 지연 ▸ Step Scaling + CloudWatch Alarm — 특정 시간/조건에 사전 스케일링 【정답 포인트】 ▸ '분당 100 호출' 목표는 현재 요청에만 반응 → 예측 기반 사전 스케일링 불가 ▸ '업무일 시작 시 0 인스턴스' → Cold Start 발생 ▸ 해결책: CloudWatch Alarm으로 시간 기반 트리거 ▸ 업무일 시작 전에 최소값을 0→1로 증가시키는 별도 정책 필요 ▸ 이렇게 하면 트래픽 도착 시 즉시 처리 가능 ▸ 스케일 다운: 다른 타이밍에 다시 0으로 (비용 절감) 【오답 체크】 (A) 쿨다운 감소: 스케일링 반응 속도만 높임. 초기 0 문제는 해결 못함 (B) CPU 메트릭 변경: 목표 여전히 반응 기반. 사전 스케일링 불가 (C) 목표값을 1로: 항상 1개 이상 유지하면 비용 증가. 유연성 감소 【시험 포인트】 예측 불가능한 트래픽 스파이크 → 시간 기반 CloudWatch Alarm + Step Scaling. Cold Start 해결 패턴.

해설

【핵심 용어】 ▸ SageMaker Profiler — 학습 중 CPU, GPU, 메모리, I/O 성능을 세부 프로파일링. 병목 지점 식별 ▸ DDP(Distributed Data Parallel) — 다중 GPU 병렬 학습. 동기화 오버헤드 존재 가능 ▸ GPU Underutilization — GPU 컴퓨팅 능력을 충분히 사용하지 못함 【정답 포인트】 ▸ '스크립트의 어느 지점에서 활용 최적화 가능' → 상세한 성능 분석 필요 ▸ SageMaker Profiler가 학습 중 초 단위 성능 메트릭 수집 ▸ 주석(annotation)으로 코드 섹션별 성능 추적 ▸ 병목 지점(데이터 로딩, 동기화, 통신) 정확히 식별 ▸ 생성된 보고서로 최적화 영역 특정 가능 【오답 체크】 (A) CloudWatch: 인스턴스 수준 메트릭만 제공. 스크립트 내부 코드별 상세 분석 불가 (C) CloudTrail: API 호출 감사 로그. GPU 성능 메트릭 기록 안 함 (D) Model Monitor: 모델 성능 모니터링(데이터 드리프트). 학습 시 GPU 성능 프로파일링 아님 【시험 포인트】 학습 스크립트 성능 병목 지점 식별 → SageMaker Profiler. 학습 최적화 도구 선택.

해설

【핵심 용어】 ▸ Data Drift(데이터 드리프트) — 프로덕션 데이터의 통계적 특성이 학습 데이터와 변함 ▸ Model Drift — 모델의 예측 정확도 자체가 시간에 따라 저하 ▸ Distribution Shift — 입력 데이터 분포(X)가 변함 【정답 포인트】 ▸ '프로덕션 데이터 분포가 학습 데이터 분포와 다른지 감지' → Data Drift 정의와 일치 ▸ '고객 행동 변화' = 입력 피처 분포의 변화 ▸ Data Drift 감지 = 입력 분포 모니터링 ▸ SageMaker Model Monitor의 Data Quality Monitoring 기능 ▸ 통계 기반 드리프트 감지 (KL Divergence, Chi-Square 등) 【오답 체크】 (B) Model Quality Drift: 예측 정확도(예: RMSE) 저하 감지. 드리프트 원인 파악 아님 (C) Model Bias Drift: 그룹별 예측 공정성 변화. 데이터 분포 변화와 다름 (D) Feature Attribution Drift: 피처 중요도 순위 변화. 분포 자체 변화 아님 【시험 포인트】 입력 데이터 분포 변화 감지 → Data Quality Drift. 드리프트 유형별 모니터링 대상 이해.

해설

【핵심 용어】 ▸ Asynchronous Inference — 장시간 실행 추론에 최적. 요청 즉시 완료 후 결과 콜백 ▸ Batch Transform — 대량 오프라인 추론. 실시간 사용자 피드백 불가 ▸ SNS(Simple Notification Service) — 푸시 기반 메시지 전송. 사용자 즉시 알림 가능 【정답 포인트】 ▸ '고해상도 이미지 처리' → 장시간 추론 (수 초~수 분) ▸ '처리 완료 후 알림' → 비동기 콜백 필요 ▸ Asynchronous Inference: 요청 받으면 OutputLocation 반환 → 결과 준비 후 SNS 알림 ▸ S3: 고해상도 이미지 저장소로 표준 (EFS는 오버스펙) ▸ SNS: 푸시 기반으로 사용자에게 즉시 알림 가능 【오답 체크】 (A) Batch Transform + SQS: 배치는 정시 처리(scheduled) 또는 수동 실행. 실시간 처리 안 됨. SQS는 풀 기반으로 지연 가능 (C) EFS + Batch: EFS는 고성능 파일 시스템이지만 여기선 불필요. 배치 방식 부적절 (D) EFS 사용: 고해상도 이미지는 S3 더 적합. 스토리지 선택 오류 【시험 포인트】 장시간 추론 + 즉시 알림 → Asynchronous + SNS. 비동기 패턴 이해. 스토리지 선택(S3 vs EFS).

해설

【핵심 용어】 ▸ Recall(재현율) — 실제 양성 중 올바르게 예측된 양성. TP/(TP+FN) ▸ Precision(정밀도) — 양성 예측 중 실제 양성. TP/(TP+FP) ▸ 재입원 위험 — 의료 도메인 → 놓친 고위험 환자(FN) 비용 > 불필요한 개입(FP) 비용 【정답 포인트】 ▸ '위양성을 용인할 의향' = FP 증가 허용 = Recall 중시 전략 ▸ '높은 재현율 + 낮은 정밀도' = FN 감소 + FP 증가 ▸ 의료 도메인에서는 위음성(놓친 고위험 환자)이 훨씬 비쌈 ▸ 섀도우 변형이 기존 모델보다 더 많은 재입원 위험자 감지 ▸ 목표(높은 정확도 + FP 용인) 달성 → 승격 진행 【오답 체크】 (B) 테스트 연장: 정밀도 개선이 목표가 아님. 이미 충분한 데이터로 재현율 높음 확인 (C) Blue/Green 부분 배포: 점진적 롤아웃은 좋지만 이미 테스트 완료. 즉시 승격 가능 (D) 롤백: 새 모델이 목표(높은 재현율) 달성했으므로 불필요 【시험 포인트】 도메인별 메트릭 우선순위: 의료(Recall > Precision) vs 사기탐지(Recall) vs 스팸필터(Precision). Shadow testing 완료 후 승격 결정.

해설

【핵심 용어】 ▸ High-resolution metric — 1초 단위 세밀한 모니터링으로 변화를 빠르게 감지 ▸ Scale-in cooldown — 축소 후 재확장 전 대기 시간(짧을수록 반응성 높음) ▸ InvocationsPerInstance — 인스턴스당 호출 수 기반 메트릭 【정답 포인트】 ▸ 갑작스러운 트래픽 변화 대응 → 고해상도(high-resolution) 메트릭 필수 ▸ 빠른 응답성 → 300초 축소 대기(기본값)가 600초보다 우수 ▸ 키워드 "MOST responsive" → 고해상도 + 짧은 대기 시간 = D 【오답 체크】 (A) 표준 해상도 + 300초: 표준 메트릭은 세밀도 부족으로 변화 감지 지연 (B) 고해상도 + 600초: 고해상도는 맞으나, 600초 대기로 축소 후 재확장 지연 (C) 표준 해상도 + 600초: 표준 메트릭 + 긴 대기로 가장 느린 응답성 【시험 포인트】 트래픽 급증 시나리오 → 고해상도 메트릭(1초 단위 감시) + 짧은 cooldown(빠른 재확장). SageMaker 자동 확장에서 "high-resolution"은 정밀한 추적의 핵심. 실시간 가격 조정처럼 지연이 중요한 경우 이 조합 필수.

해설

【핵심 용어】 ▸ SageMaker Clarify — 모델 편향성 및 데이터 불균형 감지 도구 ▸ Class Imbalance(CI) — CI > 0이면 불균형 존재, CI = 0이면 완벽한 균형 ▸ SMOTE — 소수 클래스 샘플을 합성 생성하여 전체 데이터 보존(언더샘플링 아님) 【정답 포인트】 ▸ "기존 데이터 손실 없음" → SMOTE(합성) 필수, 언더샘플링 제외 ▸ 불균형 감지 → Clarify 사용(JumpStart 아님) ▸ CI > 0 = 불균형 존재 → SMOTE 적용 시점 【오답 체크】 (A) Clarify는 맞으나 CI=0일 때 언더샘플링: 균형 상태에서 제거는 불필요 (C) JumpStart로 보고서 생성: Clarify보다 덜 정확한 불균형 감지 (D) JumpStart + CI=0 판단: 불균형 감지 도구로 Clarify가 표준 【시험 포인트】 데이터 손실 금지 요구사항 = SMOTE 필수. SageMaker에서 불균형 감지는 Clarify(专用도구) 사용. CI > 0이 불균형의 표지(선택지의 수를 결정하는 핵심). 언더샘플링은 다수 클래스 삭제로 정보 손실 발생.

해설

【핵심 용어】 ▸ One-hot encoding — 카테고리별 이진 컬럼 생성(3개 값 = 3개 컬럼, 차원 증가 최소) ▸ Ordinal encoding — 순서 있는 카테고리를 정수로 변환(대소 관계 존재) ▸ Tokenization — 텍스트를 토큰 단위로 분해(NLP용, 로지스틱 회귀 부적합) 【정답 포인트】 ▸ location: 3개 값(소수) → 원-핫 인코딩(3개 바이너리 피처) ▸ job_seniority_level: 10+개 순서형 데이터 → 서수형 인코딩(1,2,3...순서 매핑) ▸ 로지스틱 회귀: 수치형 입력 필수 → 인코딩 필수 【오답 체크】 (A) Tokenization: 텍스트 분해는 로지스틱 회귀에 부적절 (C) Binning: location의 범주형 값을 구간화할 이유 없음, 표준화는 범주형에 불가 (D) 원-핫은 맞으나 job_seniority_level을 표준화: 순서형 데이터는 서수형 인코딩이 낫음 【시험 포인트】 카테고리 개수 → 3개(작음)=원-핫, 10개+(크거나 순서형)=서수형 선택. 로지스틱 회귀는 선형 모델이므로 범주 간 거리 관계 유지하는 인코딩 필요. 직급(seniority)처럼 순위 의미가 있으면 서수형이 의미론적으로 우월.

해설

【핵심 용어】 ▸ Real-time endpoint — 즉시 예측 응답(밀리초 단위 지연) ▸ Auto scaling — 요청량 변화에 따른 자동 인스턴스 조정 ▸ Batch transform — 배치 처리(지연 허용 시나리오용, 실시간 부적합) 【정답 포인트】 ▸ "near real-time predictions with low latency" → SageMaker endpoint 필수 ▸ "variable request volumes" → auto scaling으로 비용 효율화 ▸ 실시간 예측 요구 = 배치 변환 제외 【오답 체크】 (A) Batch transform: 배치 처리로 지연 발생, 실시간 예측 부적합 (B) API Gateway + S3: S3는 모델 저장소(추론 서버 아님), 지연 높음 (D) EC2 + ALB: 관리 오버헤드 높고, 자동 확장 복잡도 증가 【시험 포인트】 요구사항 분석: (1) near real-time = endpoint, (2) low latency = managed service, (3) variable volume = auto scaling. SageMaker endpoint는 완전 관리형이므로 배포 및 확장 자동화. EC2는 운영 복잡도 높음. 배치 변환은 데이터 레이크 처리용.

해설

【핵심 용어】 ▸ Distributed Data Parallelism(DDP) — 데이터를 여러 인스턴스에 분산, 병렬 처리 ▸ Epochs — 전체 데이터셋 반복 학습(컴퓨팅 시간에 영향, 처리량 아님) ▸ Model complexity — 뉴런/레이어 수 증가는 학습 시간 증가(시간 단축 반대) 【정답 포인트】 ▸ DDP 활성화 상황 → 인스턴스 추가로 병렬도 확대 가능 ▸ "decrease required time" → 처리량 증가만 효과(변수 추가 아님) ▸ 인스턴스 수 ↑ = 병렬 처리량 ↑ = 전체 학습 시간 ↓ 【오답 체크】 (A) Epochs 증가: 반복 횟수 증가 = 학습 시간 증가(역효과) (B) 뉴런 수 증가: 모델 복잡도 ↑ = 계산량 ↑ = 시간 증가 (C) 레이어 수 증가: 모델 깊이 ↑ = 학습 비용 ↑ = 시간 증가 【시험 포인트】 DDP는 수평 확장 기법 → 인스턴스 증가만이 학습 시간 단축. 모델 구조 변경(뉴런, 레이어, epoch)은 학습 횟수나 복잡도 증가로 역효과. "decrease time" 문맥에서 인프라 확장 선택이 정답.

해설

【핵심 용어】 ▸ Bayesian optimization — 이전 결과 학습으로 최적점 추정, 순차 탐색(샘플 효율 높음) ▸ Grid search — 모든 조합 시도(샘플 효율 낮음, 큰 범위 부적합) ▸ Random search — 무작위 샘플링(순서 없음, 학습 없음) ▸ Hyperband — 조기 중단으로 빠른 탐색(소수 상위 조합) 【정답 포인트】 ▸ "slowly and sequentially" → 순차 탐색 방식 필수 ▸ "regression-based" → 이전 데이터로 예측 모델 구성 ▸ "small hyperparameter ranges" → 세밀한 탐색(Bayesian 최적) ▸ 샘플 효율성 = Bayesian > Grid/Random 【오답 체크】 (A) Grid search: 모든 조합 탐색으로 순차성 없음, 작은 범위에도 비효율 (B) Random search: 이전 결과 반영 없음, "regression" 요구사항 미충족 (D) Hyperband: 조기 중단으로 "slowly sequential" 특성 부족, 신속 탐색 지향 【시험 포인트】 "regression-based sequential selection" = Bayesian optimization의 정의. 베이지안은 가우시안 프로세스로 모델링하여 다음 시도할 지점을 확률적으로 선택. 작은 범위에서 소수 시도로 최적값 찾기(Grid보다 효율). SageMaker HPO 기본 알고리즘.

해설

【핵심 용어】 ▸ Random Cut Forest(RCF) — 비지도 이상 탐지(anomaly detection), 레이블 불필요 ▸ Unsupervised learning — 레이블 없는 데이터에서 패턴 발견 ▸ Anomaly detection — 정상에서 벗어난 이상 지점 식별 【정답 포인트】 ▸ "unlabeled dataset" → 비지도 학습 알고리즘 필수 ▸ "detect irregularities" = 이상 탐지 시나리오 ▸ 생체 신호 모니터링 → RCF(시계열 이상 탐지 적합) ▸ num_trees ↑ = 앙상블 성능 향상 【오답 체크】 (A) XGBoost: 지도 학습(분류/회귀), 레이블 필요, max_depth 과다 = 과적합 (B) k-means: 클러스터링(분할만 함), 이상 탐지 아님, 생체 신호 이상 감지 부적합 (C) DeepAR: 시계열 예측(시점 이후 값 예측), 이상 탐지 아님 【시험 포인트】 비지도 + 이상 탐지 = RCF 필수. RCF는 고차원 데이터의 이상을 효율적으로 감지. 의료/IoT 시나리오에서 표준 선택. num_trees는 앙상블 크기(더 많을수록 정확도 상승하지만 비용 증가).