정답 · 해설

해설

【핵심 용어】 ▸ Image classification — 이미지를 분류하여 객체가 무엇인지만 식별 (위치 정보 없음) ▸ Object detection — 이미지에서 객체를 식별하고 경계 상자로 위치를 표시 【정답 포인트】 ▸ "항목을 식별" + "위치를 제공" → 경계 상자(bounding box) 필요 ▸ Object detection은 이미지 내 객체의 위치(좌표)를 반환하는 알고리즘 ▸ YOLO, Faster R-CNN 등이 대표적인 object detection 알고리즘 【오답 체크】 (A) Image classification은 이미지 전체를 한 카테고리로 분류하기만 하므로 위치 정보를 제공하지 않음 (B) XGBoost는 표 형식 데이터 분류/회귀용 트리 기반 알고리즘이며 이미지 처리 불가 (D) k-NN은 분류 알고리즘이지만 이미지에서 객체 위치를 찾을 수 없음 【시험 포인트】 ▸ 객체 "위치" 요구 → Object detection ▸ 위치 없이 분류만 → Image classification ▸ 구조화 데이터용 → XGBoost, k-NN

해설

【핵심 용어】 ▸ AWS Glue DataBrew — 이기종 데이터 형식을 처리하기 위한 데이터 정제 서비스 ▸ Apache Parquet — AWS Glue가 기본적으로 지원하는 표준 열 지향 형식 【정답 포인트】 ▸ CSV, JSON, XLSX, Parquet이 섞여 있음 → DataBrew는 단일 형식만 효율적으로 처리 ▸ 파일 유형별 폴더 분리 필수 → 각 형식을 개별 처리 ▸ Apache Parquet은 Glue의 표준 출력 형식이므로 AWS Glue Parquet 같은 독점 형식 불필요 【오답 체크】 (A) 다양한 파일 형식을 섞여 있는 상태로 처리하면 데이터 손상 위험 또는 처리 실패 가능 (B) AWS Glue Parquet은 실제 형식이 아니며, 표준은 Apache Parquet만 존재 (D) AWS Glue Parquet이라는 형식은 존재하지 않으므로 Glue가 인식 불가 【시험 포인트】 ▸ 이기종 형식 → 파일 유형별 분리 ▸ DataBrew 호환성 → 단일 형식 폴더 ▸ Glue 호환 출력 → Apache Parquet (표준)

해설

【핵심 용어】 ▸ Precision — 예측한 양성 중 실제 양성의 비율 (오탐(False Positive) 최소화) ▸ Recall — 실제 양성 중 예측한 양성의 비율 (미탐(False Negative) 최소화) ▸ Accuracy — 전체 예측 중 정확한 예측의 비율 ▸ F1 Score — Precision과 Recall의 조화 평균 (불균형 데이터셋에서 유용) 【정답 포인트】 ▸ 이진 분류 문제 (합격/불합격) → Precision, Recall, Accuracy, F1 Score 모두 적용 가능 ▸ 제조 품질 검증에서는 거짓 불합격(Type I error)과 거짓 합격(Type II error) 모두 중요 ▸ Accuracy + F1 Score 조합이 가장 포괄적인 평가 (클래스 균형 고려) 【오답 체크】 (B) RMSE와 MAPE는 회귀 문제의 메트릭이므로 이진 분류에 부적합 (D) BLEU score는 머신 번역의 성능 평가용 메트릭으로 이미지 분류와 무관 (E) Perplexity는 언어 모델의 성능을 측정하는 메트릭으로 이미지 분류에 부적합 【시험 포인트】 ▸ 이진 분류 → Precision, Recall, Accuracy, F1 Score ▸ 회귀 문제 → RMSE, MAE, MAPE ▸ NLP 문제 → BLEU, Perplexity ▸ A+C 모두 정확한 평가 가능

해설

【핵심 용어】 ▸ Inter-node encryption — 분산 훈련 시 여러 컴퓨팅 노드 간의 통신 암호화 ▸ In-transit encryption — 데이터가 이동 중일 때의 암호화 ▸ KMS key — 저장 데이터(at-rest) 암호화용으로 사용 【정답 포인트】 ▸ "전송 중(in transit)" 암호화 → 네트워크 통신 암호화 필요 ▸ SageMaker 훈련은 멀티 노드로 분산 처리 시 노드 간 통신 발생 ▸ Enable inter-container traffic encryption 파라미터로 노드 간 통신 암호화 【오답 체크】 (A) 배치 처리는 SageMaker Batch Transform용 기능이며 훈련과 별개 (C) KMS 키는 저장 데이터 암호화(at-rest)용이지 전송 중 암호화(in-transit)와 다름 (D) SageMaker 도메인은 스튜디오 환경 설정으로 훈련 작업의 전송 암호화와 무관 【시험 포인트】 ▸ In-transit → 노드 간 통신 암호화 ▸ At-rest → KMS 키 설정 ▸ 훈련 작업 = 분산 처리 = 노드 간 통신 필수

해설

【핵심 용어】 ▸ RMSE — 예측값과 실제값의 차이(오차)의 제곱 평균을 제곱근 처리한 회귀 평가 메트릭 ▸ Recall — 이진 분류에서 실제 양성 중 예측 양성의 비율 ▸ LogLoss — 확률 기반 분류의 로그 손실 메트릭 ▸ wQL — 시계열 예측에서 분위수 손실을 가중치와 함께 계산하는 메트릭 ▸ InferenceLatency — 추론 실행 시간으로 성능 메트릭이 아님 【정답 포인트】 ▸ 시계열 예측은 연속 값을 예측하는 회귀 문제 → RMSE 적용 ▸ 확률적 예측 구간 필요 시 → wQL(가중 분위수 손실) 사용 ▸ SageMaker의 시계열 예측(DeepAR) 평가 메트릭이 wQL, RMSE 【오답 체크】 (A) Recall은 이진/다중 분류의 메트릭으로 연속값 예측과 무관 (B) LogLoss는 분류 문제의 확률 손실로 회귀 예측에 부적합 (D) InferenceLatency는 모델 성능 평가가 아닌 시스템 성능 지표 【시험 포인트】 ▸ 시계열 예측(회귀) → RMSE, MAE, wQL ▸ 이진 분류 → Precision, Recall, LogLoss ▸ 시계열 확률 예측 → wQL(분위수 손실) ▸ C+E 조합이 표준

해설

【핵심 용어】 ▸ Inference component — SageMaker 엔드포인트 내에서 개별 모델을 독립적으로 관리하는 단위 ▸ Serverless Inference — 자동 스케일링되지만 콜드 스타트 지연 발생 ▸ Asynchronous Inference — 비동기 처리로 실시간 응답 불가 ▸ Cold start — 엔드포인트가 유휴 상태에서 요청 처리 시작 시의 초기 지연 【정답 포인트】 ▸ "실시간 응답" + "콜드 스타트 금지" → 최소 인스턴스 1개 항상 실행 ▸ "다양한 스케일링 요구사항" → inference component로 모델별 독립 관리 ▸ 단일 엔드포인트로 다중 모델 호스팅 → 비용 효율적 ▸ minimum number of copies = 1 → 콜드 스타트 방지 【오답 체크】 (A) Serverless Inference는 콜드 스타트 지연 발생 (밀리초~초 수준) (B) Asynchronous Inference는 비동기 처리로 실시간 응답 불가 (D) Multi-model endpoint는 모든 모델이 하나의 스케일링 정책을 공유하므로 독립적 스케일링 불가 【시험 포인트】 ▸ 실시간 + 콜드 스타트 금지 → Min copies ≥ 1 ▸ 모델별 독립 스케일링 → Inference component ▸ 비용 최적화 → 단일 엔드포인트 활용

해설

【핵심 용어】 ▸ SSE-S3 — S3가 관리하는 암호화 키 (자동 처리) ▸ SSE-KMS — 고객이 AWS KMS에서 관리하는 암호화 키 ▸ Execution role — SageMaker 훈련 작업이 AWS 리소스에 접근할 권한 ▸ AccessDenied — IAM 권한 부족으로 인한 접근 거부 【정답 포인트】 ▸ SSE-S3 → SSE-KMS 변경 후 AccessDenied 발생 ▸ KMS 기반 암호화는 KMS 권한 필요 → kms:Decrypt (복호화), kms:Encrypt (암호화) ▸ SageMaker 훈련 작업의 실행 역할에 KMS 권한 부족 【오답 체크】 (A) S3 기본 권한(ListBucket, GetObject)은 이미 있으므로 문제 해결 불가 (B) aws:SecureTransport는 HTTPS 강제로 S3 암호화 방식 변경과 무관 (D) kms:CreateGrant는 특정 보안 요구사항이 아니며, 표준 복호화에는 필요 없음 【시험 포인트】 ▸ KMS 암호화 적용 후 AccessDenied → KMS 권한 추가 ▸ 훈련 작업 = 실행 역할이 권한 보유 필수 ▸ 데이터 접근 → kms:Decrypt 필수

해설

【핵심 용어】 ▸ Compute optimized instance — CPU 성능 최적화 인스턴스 (훈련용) ▸ Savings Plan — 사용 약정으로 할인 제공 (AWS 범용 가격 정책) ▸ Reserved Instance — 특정 인스턴스 예약으로 할인 ▸ Serverless endpoint — 서버리스 추론용 (훈련용 아님) 【정답 포인트】 ▸ "55주 일정한 수요" + "주당 35시간" → 사용 패턴이 예측 가능 ▸ SageMaker Savings Plan은 훈련/추론 비용 할인 제공 ▸ 1년 약정 + All Upfront 선결제 → 최대 할인율 적용 ▸ 컴퓨팅 최적화 인스턴스의 지속적 사용에 최적 【오답 체크】 (A) Serverless endpoint는 추론용이며 훈련에 사용 불가 (B) Edge Manager는 엣지 디바이스 배포용으로 클라우드 훈련과 무관 (C) Heterogeneous cluster는 비용 절감과 무관하며 서로 다른 인스턴스 조합 활용 【시험 포인트】 ▸ 예측 가능한 장기 수요 → Savings Plan 또는 Reserved Instance ▸ 훈련 비용 절감 → SageMaker Savings Plan ▸ All Upfront 선결제 → 최대 할인

해설

【핵심 용어】 ▸ Model drift — 시간에 따라 모델의 예측 성능이 저하되는 현상 ▸ SageMaker Model Monitor — 배포된 모델의 데이터 및 예측 드리프트 감지 전용 서비스 ▸ SageMaker Debugger — 훈련 중 모델의 내부 상태 분석 및 오버피팅/언더피팅 감지 ▸ Data drift — 입력 데이터의 분포 변화 ▸ Prediction drift — 모델 출력 분포 변화 【정답 포인트】 ▸ "라이브 데이터" + "모델 정확도 저하" → 배포된 모델의 드리프트 감지 ▸ SageMaker Model Monitor는 프로덕션 모델의 데이터/예측 드리프트 전담 ▸ 기준선(baseline) 통계와 제약조건(constraints) 비교로 자동 모니터링 ▸ 스케줄 기반 모니터링 작업으로 운영 오버헤드 최소화 【오답 체크】 (A) CloudWatch는 메트릭 시각화이며 통계 기반 드리프트 감지 불가 (B) Lambda로 수동 구현하면 운영 복잡도 증가 및 자동화 불가 (D) Debugger는 훈련 중 모델 품질 분석용이며 배포 후 프로덕션 모니터링 불가 【시험 포인트】 ▸ 프로덕션 드리프트 감지 → SageMaker Model Monitor (표준) ▸ 훈련 중 품질 분석 → SageMaker Debugger ▸ 실시간 모니터링 → CloudWatch (시각화) ▸ 기준선 vs 라이브 데이터 비교 = Model Monitor 핵심

해설

【핵심 용어】 ▸ SageMaker Clarify — 모델의 편향(bias), 공정성(fairness), 설명 가능성(explainability) 분석 ▸ Feature importance — 모델 결정에 영향을 미치는 입력 특성의 중요도 ▸ Bias detection — 인구통계(성, 나이, 인종 등)에 따른 불공정한 예측 ▸ SHAP values — 예측에 대한 특성의 기여도 분석 【정답 포인트】 ▸ "입력 데이터와 예측 검토" → 모델 분석 필요 ▸ "다양한 인구통계에 걸쳐" → 편향(bias) 감지 ▸ "추세를 식별" → 설명 가능성 분석 ▸ SageMaker Clarify는 모델 공정성과 편향 분석의 표준 도구 【오답 체크】 (A) CloudWatch는 시스템 성능(네트워크, CPU) 모니터링용이며 모델 편향 분석 불가 (B) DataBrew는 데이터 정제용이지만 모델 편향이나 인구통계별 성능 분석 불가 (D) Lambda는 데이터 품질 일관성 보장이지만 모델의 내재된 패턴(편향) 분석 불가 【시험 포인트】 ▸ 모델 편향 + 공정성 분석 → SageMaker Clarify (표준) ▸ 인구통계별 성능 격차 → Clarify로 감지 ▸ 예측 설명 가능성 → SHAP, LIME 분석 (Clarify 내 포함)

해설

【핵심 용어】 ▸ Blue/green deployment — 이전 버전(blue) 삭제 후 새 버전(green) 시작 ▸ Rolling deployment — 인스턴스를 순차적으로 업데이트 ▸ Canary deployment — 소량의 트래픽으로 새 버전 검증 ▸ Shadow testing — 새 버전으로 트래픽 복제 (트래픽 영향 없음) ▸ Reserved Instance — 예약된 컴퓨팅 용량 【정답 포인트】 ▸ 원래 10개 인스턴스 사용 + 추가 1개 인스턴스로 배포 ▸ "다운타임 없이" + "서비스 중단 없이" → 0 downtime 배포 필수 ▸ Rolling deployment with batch size 1: - 1개 인스턴스를 새 버전으로 업데이트 - 기존 9개 + 새 1개 = 10개 용량 유지 - 순차 업데이트로 10개 → 10개 유지 - 추가 1개로 안전한 업데이트 가능 【오답 체크】 (A) All-at-once는 모든 인스턴스 동시 업데이트로 다운타임 발생 (B) Canary는 트래픽 분배일 뿐 배포 메커니즘이 아니며, 10개 이상의 리소스 필요 (C) Shadow testing은 배포가 아닌 테스트 방식 【시험 포인트】 ▸ "다운타임 없이" → Rolling deployment 선택 ▸ "배포 프로세스용 추가 인스턴스" → Rolling batch size 1로 순차 업데이트 ▸ 기존 용량 유지 → 10개 구성 변경 없음

해설

【핵심 용어】 ▸ CloudWatch — AWS 리소스의 메트릭, 로그, 이벤트 모니터링 ▸ CloudTrail — AWS API 호출 감사 및 추적 (규정 준수용) ▸ SNS — 푸시 알림, 이메일, SMS 메시지 발송 서비스 ▸ SQS — 메시지 큐 서비스 (비동기 처리용) 【정답 포인트】 ▸ "하이퍼파라미터 변형 모니터링" → CloudWatch 메트릭 ▸ "SMS 문자 메시지 전송" → SNS가 SMS 발송 지원 ▸ CloudWatch는 SageMaker 훈련 메트릭(loss, accuracy 등) 수집 ▸ SNS는 SMTP, SMS, SQS, Lambda 등 다양한 메시지 배달 지원 【오답 체크】 (A) SQS는 메시지 큐로 SMS 발송 불가 (메시지 저장만 가능) (C) CloudTrail은 API 감사용이며 성능 메트릭 수집 불가 (D) CloudTrail + SNS 조합은 메트릭 모니터링 불가 【시험 포인트】 ▸ SageMaker 훈련 메트릭 → CloudWatch (표준) ▸ SMS 발송 → SNS (전용) ▸ 메시지 큐 → SQS (비동기 처리) ▸ API 감사 → CloudTrail (규정 준수)

해설

【핵심 용어】 ▸ IAM condition keys — IAM 정책에 조건을 추가하여 특정 작업 제약 ▸ RootAccess parameter — SageMaker 노트북 인스턴스의 루트 권한 설정 ▸ CloudFormation — IaC(Infrastructure as Code) 서비스 ▸ EventBridge — AWS 이벤트 기반 자동화 【정답 포인트】 ▸ "배포를 방지" → 사전 예방(preventive) 방식 ▸ IAM 조건 키로 CreateNotebookInstance API 호출 시 RootAccess=False 강제 ▸ "배포 금지" + "최소 운영 오버헤드" → IAM 정책 기반 차단이 최적 ▸ 예: sagemaker:RootAccess condition key = "Disabled" 강제 【오답 체크】 (B) KMS 키는 암호화 키 관리용이며 접근 제어와 무관 (C) EventBridge + Lambda는 이미 배포된 후 삭제(reactive)하는 방식 (D) CloudFormation 이벤트 모니터링은 불가능하며, Lambda로 삭제 후처리는 사전 예방 아님 【시험 포인트】 ▸ "배포 방지" = "사전 제어" → IAM 정책 ▸ "이미 배포된 후 삭제" → EventBridge + Lambda (사후 대응) ▸ SageMaker 보안 정책 → IAM 조건 키 (표준)

해설

【핵심 용어】 ▸ Network isolation — 인터넷으로부터 완전히 격리된 네트워크 환경 ▸ NAT gateway — 프라이빗 리소스의 아웃바운드 인터넷 액세스 제공 ▸ VPC endpoint — AWS 서비스에 대한 프라이빗 연결 (인터넷 게이트웨이 불필요) ▸ Gateway VPC endpoint — S3, DynamoDB 등 AWS 서비스에 대한 프라이빗 라우트 【정답 포인트】 ▸ "인터넷으로부터 네트워크 격리" → 아웃바운드 인터넷 액세스 차단 ▸ S3 게이트웨이 VPC 엔드포인트 → S3에 대한 프라이빗 연결 ▸ 프라이빗 서브넷 + VPC endpoint → NAT gateway 불필요 ▸ S3에 대한 모든 트래픽이 AWS 네트워크 내부에서 이동 【오답 체크】 (A) NAT 게이트웨이는 인터넷 게이트웨이를 통해 인터넷 액세스 제공 → 격리 위반 (C) 퍼블릭 서브넷은 인터넷 게이트웨이 존재 → 네트워크 격리 불가 (D) 암호화는 네트워크 격리와 다른 개념이며, 아웃바운드 인터넷 연결 차단 불가 【시험 포인트】 ▸ 네트워크 격리(No internet) → Private subnet + VPC endpoint ▸ 데이터 암호화(In transit/At rest) → KMS, SSE-KMS ▸ S3 접근 → Gateway VPC endpoint (최적)

해설

【핵심 용어】 ▸ Model Registry — SageMaker의 모델 버전 관리 및 메타데이터 저장소 ▸ Model versioning — 모델의 변형 추적 및 버전 관리 ▸ ML Lineage Tracking — 훈련 데이터, 코드, 모델의 계보 추적 ▸ ECR — 도커 이미지 저장소 (모델 아티팩트 아님) 【정답 포인트】 ▸ "모델 버전을 자동으로 생성" → 모델 버전 관리 기능 필수 ▸ SageMaker Model Registry는 모델 메타데이터, 버전, 상태 관리 ▸ "생성되면서" = "훈련 작업 완료 후" → 자동 등록 가능 ▸ 모델의 approval 상태 관리 가능 (Draft → Approved → Production) 【오답 체크】 (A) ECR은 도커 컨테이너 이미지 저장소로 모델 버전 관리 불가 (B) SageMaker Marketplace는 타사 모델 구매/판매 플랫폼 (C) ML Lineage Tracking은 훈련 과정의 계보 추적이지 모델 버전 관리 아님 【시험 포인트】 ▸ 모델 버전 관리 → SageMaker Model Registry (표준) ▸ 훈련 과정 추적 → ML Lineage Tracking ▸ 도커 이미지 저장 → ECR (모델 아님) ▸ 제3자 모델 마켓 → SageMaker Marketplace

해설

【핵심 용어】 ▸ Retrieval Augmented Generation (RAG) — 외부 문서 기반 정보로 LLM의 응답 강화 ▸ Amazon Bedrock Knowledge Base — Bedrock의 RAG 전담 서비스 ▸ Vector embedding — 문서를 벡터 형식으로 변환 ▸ Data source — RAG의 외부 문서 저장소 【정답 포인트】 ▸ "Amazon Bedrock LLM" + "RAG" → Bedrock Knowledge Base 통합 기능 사용 ▸ S3 CSV, DOCX 문서 → 자동으로 embedding 생성 및 벡터 저장 ▸ "최소 운영 오버헤드" → 완전 관리형 서비스 선택 ▸ Knowledge Base는 S3 데이터 소스를 자동으로 인덱싱 및 검색 【오답 체크】 (A) SageMaker Pipelines로 새 모델 생성은 기존 LLM 활용이 아닌 재학습 (B) Neptune + 수동 벡터 변환은 운영 오버헤드 높음 (관리형 아님) (C) AutoML로 미세 조정 후 SageMaker 엔드포인트 배포는 복잡성 증가 【시험 포인트】 ▸ Bedrock LLM + RAG → Bedrock Knowledge Base (표준) ▸ 자동 벡터화 + 검색 → Knowledge Base 내장 ▸ 다양한 문서 형식 지원 → 자동 처리 ▸ 최소 코딩 → 완전 관리형

해설

【핵심 용어】 ▸ Serverless Inference — 자동 스케일링 추론 (대용량 페이로드 미지원) ▸ Asynchronous Inference — 비동기 처리로 응답 지연 허용 (대용량 페이로드 지원) ▸ Real-time Inference — 동기식 실시간 추론 (응답 지연 최소화) ▸ Batch Transform — 배치 데이터 처리 (예약 작업용) 【정답 포인트】 ▸ "100~300MB 페이로드" → 대용량 (Serverless는 최대 6MB) ▸ "60분 이내 처리" → 비동기 처리 가능 (실시간 불필요) ▸ Asynchronous Inference: - S3 입력 → 결과는 S3에 저장 - 최대 15분 처리 시간 (60분 SLA 충분) - 대용량 페이로드 지원 【오답 체크】 (A) Serverless는 최대 페이로드 6MB, 최대 응답 900초(15분) (C) Real-time은 대용량 페이로드에 높은 비용 + 지연 시간 증가 (D) Batch Transform은 배치 작업용 (온디맨드 추론 아님) 【시험 포인트】 ▸ 100~300MB + 지연 허용 → Asynchronous Inference ▸ 소용량 + 즉시 응답 → Real-time Inference ▸ 소용량 + 변동 트래픽 → Serverless Inference ▸ 배치 데이터 + 예약 처리 → Batch Transform

해설

【핵심 용어】 ▸ Class imbalance — 일부 클래스의 샘플이 다른 클래스보다 훨씬 적은 상태 ▸ Oversampling — 소수 클래스의 샘플을 복제하여 증가 ▸ Undersampling — 다수 클래스의 샘플을 감소 ▸ Data augmentation — 이미지 변환으로 합성 샘플 생성 【정답 포인트】 ▸ "클래스 불균형" → 훈련 데이터의 클래스 분포 비정상 ▸ Random oversampling → 소수 클래스를 무작위로 복제 ▸ 이미지 분류에서 표준 해결 방식 ▸ 클래스 가중치 조정보다 간단하고 효과적 【오답 체크】 (A) 데이터셋 크기 감소는 클래스 불균형 해결이 아니라 악화 (B) 이미지 변환(data augmentation)은 샘플 개수 증가이지 클래스 균형 맞춤은 아님 (D) Random data splitting은 훈련/테스트 분할이며 클래스 불균형 해결 불가 【시험 포인트】 ▸ 클래스 불균형 → Oversampling (소수 증가) 또는 Undersampling (다수 감소) ▸ 이미지 분류 → Oversampling + Data Augmentation 조합 ▸ SMOTE, Random oversampling 등 기법 존재 ▸ 클래스 가중치 조정도 보조 기법으로 활용 가능

해설

【핵심 용어】 ▸ AWS Glue — 완전관리형 ETL 서비스로 자동으로 민감한 데이터 감지 기능 제공 ▸ Amazon Macie — PII 검색에 특화되나 마스킹 자동화 미지원 ▸ Regex (정규식) — 신용카드 패턴을 수동으로 일일이 작성해야 함 【정답 포인트】 "Sensitive Data Detection functionality" → AWS Glue는 기본 제공 라이브러리로 신용카드, SSN 등 패턴을 자동 인식하므로, 개발자가 정규식을 직접 작성할 필요가 없음. Apache Spark 환경에서 즉시 사용 가능하여 개발 시간 최소화. 【오답 체크】 (A) Amazon Macie — PII 발견에는 탁월하나 마스킹 자동화 기능이 없어 추가 개발 필요 (C) 정규식 코드 — 신용카드 번호 패턴을 개발자가 정규식으로 직접 작성/검증해야 하므로 개발 시간 증가 (D) EC2 + Spark — Glue의 관리형 환경을 포기하고 인스턴스 관리 오버헤드 발생 【시험 포인트】 "LEAST development effort" 키워드 → 기본 제공 기능(Sensitive Data Detection)이 있는 서비스 선택. AWS Glue의 내장 민감 데이터 라이브러리는 정규식 작성을 대체하는 효율적 솔루션.

해설

【핵심 용어】 ▸ Amazon Comprehend Medical — 의료용 텍스트에서 엔티티, 관계, 속성을 자동 추출하는 사전학습 모델 ▸ SageMaker RNN/seq2seq — 처음부터 학습해야 하므로 개발 시간 소요 ▸ Amazon Kendra — 검색 엔진으로 요약이 아닌 검색에 최적화 【정답 포인트】 의료 텍스트 기반 "insight 도출" → Comprehend Medical은 의료 도메인에 특화된 사전학습 모델로, 약물, 질환, 증상, 용량 등을 자동으로 인식. 모델 학습 없이 즉시 API 호출로 결과 획득 가능. 【오답 체크】 (A) SageMaker RNN — 충분한 학습 데이터 확보, 모델 구축 및 튜닝에 시간과 비용 소요 (C) Amazon Kendra — 검색/정보 검색 목적으로 설계되었으며 NLP 요약 기능 미지원 (D) seq2seq 알고리즘 — 커스텀 모델 학습이 필요하여 개발 시간 최대 【시험 포인트】 의료(Medical) + 텍스트 분석 + "LEAST development effort" → Comprehend Medical 같은 도메인 특화 관리형 서비스 선택. 도메인 특화 모델이 가장 빠르고 신뢰도 높음.