정답 · 해설

해설

【핵심 용어】 ▸ SageMaker Pipelines Callback Steps — 외부 비동기 작업(AWS Glue 워크플로우 등)을 시작하고, 완료될 때까지 파이프라인을 "일시 중지"했다가 재개하는 메커니즘 ▸ SageMaker Processing Steps — SageMaker 처리 작업을 실행하는 단계로 다른 서비스 작업을 "시작"할 수는 없음 ▸ AWS Step Functions — 복잡한 워크플로우 조정을 위한 일반 목적 서비스로 SageMaker Pipelines보다 많은 관리 코드 필요 ▸ Amazon EventBridge — 이벤트 기반 트리거 서비스로 순차적 대기(동기식 완료 대기) 메커니즘이 없음 【정답 포인트】 "AWS Glue 작업의 출력을 SageMaker Pipelines 데이터 처리 단계에서 사용" + "최소 운영 부담". SageMaker Pipelines의 Callback Step은 정확히 이런 시나리오를 위해 설계되었습니다: (1) Callback Step이 AWS Glue 워크플로우를 시작 (2) Glue 작업이 완료될 때까지 대기 (3) 완료 신호 수신 후 다음 단계 진행. 이렇게 하면 SageMaker Pipelines 내에서 모든 단계를 선언적으로 정의하고, 자동 조정 및 에러 처리를 위임할 수 있으므로 운영 부담이 최소입니다. 【오답 체크】 (A) Step Functions를 사용하면 SageMaker Pipelines 외부에 추가 워크플로우 정의가 필요하고, 두 서비스 간 통합도 복잡합니다. 관리할 조정 로직이 증가하여 운영 부담이 커집니다. (B) Processing Steps는 SageMaker Processing 작업(컨테이너 기반)을 실행하는 것이지, 외부 Glue 워크플로우를 "시작"할 수 없습니다. ARN을 지정해도 작업이 실행되지 않으며 Glue 워크플로우 결과를 파이프라인이 기다릴 수 없습니다. (D) EventBridge는 이벤트 기반 트리거이므로 "Glue 작업이 완료될 때까지 대기"하는 동기식 메커니즘이 없습니다. Glue 작업 시작과 Pipelines 다음 단계 진행 간에 순서 보장이 어렵습니다. 【시험 포인트】 "Glue 작업 완료 대기 + SageMaker Pipelines 통합 + 최소 운영 부담" → "Callback Step". Step Functions는 외부 조정 로직, Processing Steps는 Glue 작업 실행 불가, EventBridge는 동기식 대기 불가.

해설

【핵심 용어】 ▸ 동적 데이터 마스킹(Dynamic Data Masking) — 쿼리 시점에 사용자별로 민감 데이터를 자동으로 마스킹하는 Redshift 기능 ▸ 구체화된 뷰(Materialized View) — 정적으로 저장되는 뷰로 데이터 변환이 필요함 ▸ 원본 데이터 보존(Source Data Integrity) — 원본 데이터는 변경 없이 액세스 계층에서만 제어 【정답 포인트】 동적 데이터 마스킹은 Redshift에서 기본 제공되는 기능으로, 쿼리 실행 시점에 민감한 열(column)을 대상 사용자에게만 마스킹합니다. 원본 데이터는 전혀 변경되지 않으며, 마스킹 정책만 설정하면 되어 구현 복잡도가 최소입니다. B 옵션의 구체화된 뷰는 물리적 저장소가 필요하고, C와 D는 데이터를 S3로 언로드하는 추가 단계가 필요합니다. 【오답 체크】 (B) 구체화된 뷰 — Redshift에서 뷰를 생성하려면 별도의 테이블 공간을 할당하고 마스킹 로직을 SQL로 작성해야 하므로 개발 오버헤드가 큽니다. 또한 데이터 동기화 문제도 발생합니다. (C) Athena 기반 스키마온리드 — 데이터를 Redshift에서 S3로 언로드하는 ETL 과정이 필요하고, Athena에서 추가로 마스킹 로직을 구현해야 하므로 구현 복잡도가 매우 높습니다. (D) Glue 익명화 작업 — 매번 전체 데이터를 S3로 복사하고 Glue 작업으로 변환하는 방식이므로 운영 오버헤드가 가장 큽니다. 실시간 업데이트도 어렵습니다. 【시험 포인트】 '원본 데이터 변환 없이', '저장 없이', '구현 노력 최소' 키워드 → Redshift 동적 마스킹이 최적. 데이터 보안 제어 계층의 효율성 판단이 핵심.

해설

【핵심 용어】 ▸ SageMaker Debugger — 학습 과정의 기울기, 활성화값, 가중치 등을 자동으로 추적하는 SageMaker 기본 기능 ▸ 기본 제공 규칙(Built-in Rules) — Vanishing Gradient, Overtraining, LowGPUUtilization 등 사전 정의된 이상 탐지 규칙 ▸ 실시간 메트릭(Real-time Metrics) — 학습 중 즉시 계산되고 표시되는 성능 지표 【정답 포인트】 문제에서 '기울기 소실, GPU 활용도 저하, 과적합'을 명시적으로 언급하고 있습니다. SageMaker Debugger는 정확히 이 세 가지 문제를 감지하는 기본 제공 규칙(VanishingGradient, LowGPUUtilization, Overtraining)을 제공합니다. 규칙을 설정하면 조건 충족 시 자동으로 Lambda 함수를 호출할 수 있어 운영 부담이 최소입니다. 다른 옵션들은 수동 모니터링, 커스텀 스크립트 작성, 메트릭 확대 등의 추가 작업이 필요합니다. 【오답 체크】 (A) TensorBoard + SNS — TensorBoard는 시각화 도구일 뿐 자동 이상 감지 기능이 없으며, SNS 구독자가 수동으로 결과를 처리해야 하므로 실시간 자동 반응이 어렵습니다. (B) CloudWatch 기본 메트릭 — EC2 인스턴스의 CPU, 메모리, 네트워크만 제공하며, 학습별 기울기, 모델 수렴성 등의 ML 특화 메트릭은 포함되지 않습니다. (C) CloudWatch 메트릭 확대 — 기울기를 CloudWatch에 로깅하려면 학습 코드 수정, 커스텀 메트릭 발행 코드 작성이 필요하므로 개발 복잡도가 높습니다. 【시험 포인트】 'vanishing gradient, GPU utilization, overfitting' 세 가지 명시 → SageMaker Debugger의 세 가지 기본 규칙 매핑. '실시간 메트릭 + 자동 반응' → Debugger의 핵심 가치.

해설

【핵심 용어】 ▸ 섀도우 테스트(Shadow Testing) — 실시간 요청을 기존 모델과 새 모델에 동시 전달하되, 새 모델의 응답은 사용자에게 반환하지 않는 방식 ▸ 섀도우 변형(Shadow Variant) — SageMaker 엔드포인트의 변형으로, 프로덕션 트래픽 일부를 받지만 응답이 사용하되지 않음 ▸ 카나리 배포(Canary Deployment) — 트래픽의 일부만 새 모델로 라우팅하고 나머지는 기존 모델 유지 【정답 포인트】 '실시간 데이터를 사용하여 성능 평가' + '프로덕션 사용자 영향 없음'이 핵심 요구사항입니다. 섀도우 테스트는 정확히 이 목적으로 설계되었습니다. 실시간 트래픽을 새 모델에 전달하여 동작을 관찰하지만, 새 모델의 응답은 사용자에게 돌아가지 않습니다. 따라서 프로덕션에 미치는 영향이 없으면서 실제 데이터로 평가가 가능합니다. 카나리 배포 (C) 는 일부 사용자가 새 모델의 응답을 받게 되어 위험성이 있고, Debugger (A) 는 모니터링 도구일 뿐 배포 전략이 아닙니다. 【오답 체크】 (A) SageMaker Debugger — 학습 과정의 이상을 감지하는 모니터링 도구이며, 배포된 모델의 성능 평가나 신버전 검증 기능이 없습니다. (B) 전체 트래픽 전환 — 블루/그린의 all-at-once 방식은 문제 발생 시 모든 사용자가 영향을 받으므로 신규 모델 검증에 부적절합니다. (C) 카나리 트래픽 전환 — 트래픽 일부를 새 모델로 라우팅하므로 그 사용자들은 새 모델의 응답(정확도 미검증)을 받게 되어 비즈니스 리스크가 발생합니다. 【시험 포인트】 '실시간 데이터 + 프로덕션 영향 없음' → 섀도우 테스트. 배포 전 신버전 모델의 안전성 검증이 주제의 패턴.

해설

【핵심 용어】 ▸ 파티션(Partition) — S3 객체를 구조화된 경로(예: s3://bucket/year=2025/month=04/day=21/)로 구성하는 방식 ▸ 프루닝(Pruning) — Athena 쿼리 시 필요한 파티션만 스캔하여 비용과 성능 향상 ▸ Lifecycle 정책 — 객체의 나이에 따라 스토리지 클래스를 자동으로 전환하는 S3 기능 【정답 포인트】 '지난 3일간 분석' + '30일 보존' 요구사항에서 일별 데이터 접근 패턴이 분명합니다. 날짜 기반 파티션(예: /date=20250420/)을 사용하면 Athena가 쿼리 시 필요한 파티션만 스캔하므로 전체 데이터 스캔 없이 빠른 응답을 얻습니다. 파티션 프루닝은 Athena 성능 최적화의 필수 요소입니다. 또한 Lifecycle 정책으로 30일 후 자동 아카이빙되어 운영 부담이 없습니다. A는 분할 없어 매번 전체 스캔, B는 Lambda로 수동 복사하는 오버헤드, D는 버킷당 파티션 구조가 없어 비효율적입니다. 【오답 체크】 (A) 파티션 없음 — Athena가 매 쿼리마다 수백만 행 전체를 스캔해야 하므로 쿼리 응답 시간이 느리고, 스캔 비용도 높습니다. 특히 '3일 데이터만' 필요한 경우에도 전체 30일을 스캔합니다. (B) Lambda 복사 + Lifecycle — Lambda로 별도 버킷에 복사하는 추가 처리 단계가 필요하고, 복사 중 I/O 비용도 발생합니다. Athena 쿼리 성능 개선이 아닙니다. (D) 버킷당 하나의 날 데이터 — 버킷 수가 30개 이상으로 증가하고, Athena에서 여러 버킷을 크로스 쿼리할 때 오버헤드가 발생합니다. S3 요청 비용도 높아집니다. 【시험 포인트】 'Amazon Athena 성능' → 파티션 프루닝이 핵심. 시계열 + 날짜 필터 → 날짜 접두사 파티션이 정석.

해설

【핵심 용어】 ▸ SageMaker 실시간 추론(Real-time Inference) — 동기식 API 호출로 즉시 응답을 반환하는 배포 방식 ▸ Asynchronous Inference — 요청을 큐에 저장하고 비동기로 처리하여 응답 시간이 길 수 있음 ▸ SageMaker Model Monitor — 프로덕션 모델의 데이터 드리프트, 모델 성능 저하를 감지하는 모니터링 서비스 【정답 포인트】 문제의 핵심은 '지연 발생'입니다. Asynchronous Inference는 의도적으로 응답 대기를 포함하는 방식이므로, 지연 제거를 위해서는 real-time inference로 변경해야 합니다. Real-time inference는 즉시 응답을 제공하므로 '실시간' 부정거래 탐지에 적합합니다. 모델 품질 모니터링은 Model Monitor가 표준이며, Inference Recommender는 모델 성능 최적화 제안 도구일 뿐 모니터링 알림 기능이 없습니다. 【오답 체크】 (B) 배치 변환 — 배치 처리이므로 오프라인 작업용이며, 실시간 추론 요구사항에 부적합합니다. 또한 지연 문제는 더욱 심해집니다. (C) Serverless Inference + Inference Recommender — Serverless는 cold start 오버헤드가 있어 지연 개선에 최적이 아니며, Inference Recommender는 배포 구성 최적화 도구일 뿐 모니터링 알림 기능이 없습니다. (D) Asynchronous 유지 — 지연 문제의 근본 원인을 해결하지 않으며, Inference Recommender도 모니터링 목적에 부적합합니다. 【시험 포인트】 '실시간 추론 + 지연 제거' → Real-time Inference. '모델 품질 알림' → Model Monitor. 각 도구의 용도 구분이 핵심.

해설

【핵심 용어】 ▸ SageMaker 엔드포인트 오토스케일링 — CloudWatch 메트릭(CPU, 메모리, 요청 지연)에 따라 인스턴스 개수를 자동 조정 ▸ 비용 최적화(Cost Optimization) — 미사용 시 인스턴스 0으로 축소하거나 최소화 ▸ 피크 시간대 용량(Peak Capacity) — 트래픽 급증 시 자동으로 확장하여 처리 능력 보장 【정답 포인트】 '불균형한 요청 비율' + '미사용 시 비용 최소' + '피크 시간 용량 보장'의 세 가지 요구사항을 모두 만족해야 합니다. SageMaker 엔드포인트의 오토스케일링은 CloudWatch 메트릭을 기반으로 인스턴스 수를 동적으로 조정합니다. 저사용 시간에는 인스턴스를 0(또는 최소값)으로 축소하여 비용을 절감하고, 피크 시간에는 자동으로 확장하여 용량을 확보합니다. Lambda (A) 는 고정 동시성으로는 비용 절감이 불가능하고, ECS 정적 구성 (B) 은 피크 시간만 고려하여 저사용 시간 비용 낭비, ALB 수동 라우팅 (C) 은 자동화가 아닙니다. 【오답 체크】 (A) Lambda 고정 동시성 — '고정'이므로 미사용 시간도 비용이 발생합니다. 또한 Lambda는 모델 호스팅의 주 목적이 아니며, ML 모델 배포에 부적합합니다. (B) ECS 정적 작업 수 — 피크 시간만 고려하여 설정하면 저사용 시간에도 같은 수의 작업이 실행되어 비용 낭비입니다. 동적 조정이 없습니다. (C) SageMaker + ALB 수동 라우팅 — 다중 모델 복사본 관리와 ALB 구성이 복잡하고, 자동 확장이 아니므로 수동 개입이 필요합니다. 【시험 포인트】 '불균형 요청 + 비용 최소 + 피크 수용' → 오토스케일링. SageMaker 엔드포인트의 자동 확장이 정석 솔루션.

해설

【핵심 용어】 ▸ SageMaker 사용자 프로필(User Profile) — SageMaker Studio에서 사용자 레벨의 설정 및 태깅을 관리하는 엔티티 ▸ AWS Budgets — 비용 임계값을 설정하고 초과 시 자동 알림을 보내는 AWS Cost Management 서비스 ▸ AWS Cost Explorer — 비용 데이터를 시각화하고 분석하는 도구 (알림 기능 미포함) 【정답 포인트】 '임계값 도달 시 자동 알림'이라는 요구사항의 핵심은 알림 기능입니다. AWS Budgets는 예산을 설정하고 초과할 때 SNS로 알림을 보내는 전용 서비스입니다. AWS Cost Explorer는 비용 데이터를 시각화하고 분석하는 도구일 뿐 능동적 알림 기능이 없습니다. 또한 SageMaker Studio에서 리소스 태깅을 설정하려면 SageMaker 도메인 내 사용자 프로필을 편집해야 하며, 각 사용자의 IAM 프로필을 개별 편집하는 것은 비효율적입니다. 【오답 체크】 (A) Cost Explorer + 사용자 프로필 — Cost Explorer는 비용 분석 도구일 뿐 자동 알림 기능이 없습니다. 임계값 도달 시 수동으로 모니터링해야 합니다. (C) Cost Explorer + IAM 프로필 — Cost Explorer 자체의 알림 기능 부재와 IAM 프로필 개별 편집의 복잡성 문제를 모두 포함합니다. (D) Budgets + IAM 프로필 — Budgets는 올바른 도구이지만, SageMaker 도메인 차원의 태깅 (B) 이 더 효율적입니다. IAM 프로필 개별 편집은 관리 복잡도가 높습니다. 【시험 포인트】 '자동 알림' → AWS Budgets. 'SageMaker 환경' → SageMaker 사용자 프로필 태깅. Cost Management 도구의 용도 구분.

해설

【핵심 용어】 ▸ SageMaker Data Wrangler — 코드 작성 없이 드래그-드롭으로 데이터 전처리를 수행하는 low-code 도구 ▸ 변환 단계(Transform Step) — 열 선택, 필터링, 인코딩 등 다양한 데이터 변환을 GUI로 구성 ▸ 저노력 솔루션(Least Effort) — 코딩 최소화, 클릭 기반 설정 【정답 포인트】 '가장 적은 노력으로'라는 조건이 핵심입니다. 50MB 파일에서 불필요한 열을 삭제하는 작업은 매우 간단합니다. Data Wrangler는 정확히 이런 간단한 데이터 정제 작업을 위한 no-code 도구입니다. GUI에서 제거할 열을 선택하고 변환 단계를 구성하면 됩니다. 코드 작성이나 복잡한 인프라 구성이 필요 없습니다. Python 스크립트 (A) 나 EMR/Spark (B) , SageMaker 처리 (C) 는 모두 코드 작성이 필요하거나 인프라 오버헤드가 있습니다. 【오답 체크】 (A) 수동 다운로드 + Python 스크립트 — 로컬에서 파일을 처리하는 방식이므로 네트워크 전송 시간, 스크립트 작성 및 디버깅 시간이 소비됩니다. 또한 원-핫 인코딩은 열 선택과 무관한 작업입니다. (B) EMR + Spark — 클러스터 프로비저닝, Spark 작업 작성, 실행 모니터링 등 복잡한 절차가 필요합니다. 50MB 같은 작은 파일에는 오버엔지니어링입니다. (C) SageMaker 처리 작업 — Python SDK로 처리 코드를 작성해야 하므로 개발 시간이 필요합니다. Data Wrangler보다 복잡합니다. 【시험 포인트】 '간단한 열 선택 + 노력 최소' → Data Wrangler. No-code 도구의 최적 사용 사례 판단.

해설

【핵심 용어】 ▸ 차단된 구문(Blocked Phrases) — Amazon Q Business의 응답에서 특정 단어나 구문을 자동으로 제거하거나 마스킹 ▸ Amazon Q Business 검색기(Retriever) — RAG 시스템에서 문서를 검색하는 컴포넌트 ▸ 문서 속성 부스팅(Document Attribute Boosting) — 특정 속성을 가진 문서의 검색 순위를 높이거나 낮추는 기능 【정답 포인트】 '응답에 포함되지 않도록'이라는 요구사항은 최종 사용자에게 반환되는 텍스트에서 경쟁사 이름을 제거하는 것을 의미합니다. Amazon Q Business의 '차단된 구문' 기능은 정확히 이 목적으로 설계되었습니다. LLM이 생성한 응답에서 지정된 구문을 자동으로 필터링하거나 마스킹합니다. 검색기 제외 (B) 나 Kendra 인덱싱 (C) 은 검색 단계에서의 제어일 뿐, LLM이 이미 학습된 내용에서 경쟁사 정보를 생성할 수 있습니다. 문서 속성 부스팅 (D) 은 우선순위 조정일 뿐 완전한 제외가 아닙니다. 【오답 체크】 (B) 검색기 제외 — Retriever에서 경쟁사 관련 문서를 검색하지 않더라도, LLM의 사전 학습 지식에서 경쟁사 이름이 포함된 응답을 생성할 수 있습니다. (C) Kendra 인덱싱 제외 — 외부 데이터 소스의 인덱싱만 제어하며, 기업 지식(회사 이미지, 마케팅 자료)에 경쟁사 언급이 있으면 검색될 수 있습니다. (D) 문서 속성 부스팅 낮춤 — 우선순위만 낮출 뿐, 관련 문서가 부족하면 결국 경쟁사 정보를 포함하는 응답이 생성될 수 있습니다. 【시험 포인트】 '응답에서 제거' → 차단된 구문. 최종 출력 필터링이 핵심. RAG 컴포넌트 (Retriever vs 응답 필터링) 구분.

해설

【핵심 용어】 ▸ SageMaker Autopilot — 자동화된 머신러닝으로 특성 엔지니어링, 모델 선택, 하이퍼파라미터 튜닝을 자동 수행 ▸ SageMaker JumpStart — 사전 학습된 모델과 노트북을 한 클릭으로 제공하는 SageMaker 허브 ▸ LCNC(Low-Code No-Code) — 코드 작성 최소화 또는 불필요한 접근 방식 【정답 포인트】 'LLM 미세 조정' + 'LCNC 접근'의 결합이 핵심입니다. SageMaker Autopilot은 정확히 자동화된 머신러닝을 제공하는 LCNC 도구입니다. 그런데 Autopilot이 LLM 미세 조정을 수행하려면, 사전 학습된 LLM이 필요합니다. SageMaker JumpStart는 사전 학습된 LLM(예: Hugging Face의 BERT, GPT 계열 모델)을 제공하므로, Autopilot과 결합하면 LCNC 방식으로 LLM 미세 조정이 가능합니다. SageMaker Studio (A) 는 노트북 환경일 뿐 자동화가 아니며, 커스텀 API (B) 나 EC2 (C) 는 모두 배포 위치일 뿐 LCNC 요구사항과 무관합니다. 【오답 체크】 (A) SageMaker Studio — IDE 도구이며 LCNC가 아니라 코드 작성 환경입니다. 사전 학습 모델 제공도 없어 LLM 미세 조정 프로세스를 직접 구현해야 합니다. (B) Autopilot + 커스텀 API — Autopilot은 올바른 도구이지만, 커스텀 API 엔드포인트는 사전 학습 모델 제공이 아니며, 자체 배포해야 하므로 복잡도가 증가합니다. (C) Autopilot + EC2 — EC2 인스턴스는 SageMaker 생태계 내 배포 위치가 아니며, EC2에서의 LLM 관리는 LCNC 원칙에 맞지 않습니다. 【시험 포인트】 'LLM 미세 조정 + LCNC' → Autopilot + JumpStart. 사전 학습 모델 제공(JumpStart)과 자동 학습(Autopilot)의 결합.

해설

【핵심 용어】 ▸ SageMaker Serverless Inference — 사용 시간만큼 자동 스케일, 미사용 시 자동 종료 ▸ MaxConcurrency — 서버리스 엔드포인트가 동시에 처리하는 요청 수 ▸ 일일 배치(Daily Batch) — 정해진 시간(밤)에 한 번만 실행되는 작업 【정답 포인트】 '매일 밤 한 번씩' + '1분 미만 실행' + '미사용 시간 긴'이라는 특성이 핵심입니다. 서버리스 추론은 정확히 이런 불규칙하고 간헐적인 사용 패턴을 위해 설계되었습니다. 사용하지 않을 때는 비용이 0이고, 요청이 들어오면 자동으로 프로비저닝되어 실행됩니다. MaxConcurrency=1은 동시에 1개 요청만 처리하면 되는 간단한 작업에 적합합니다. 비동기 추론 (B) 은 비동기 처리가 필요 없는 배치 작업에 부적절하고, 실시간 + 오토스케일 (C) 은 Scale-to-Zero가 아니어서 최소 비용이 발생합니다. 다중 모델 (A) 은 요구사항과 무관합니다. 【오답 체크】 (A) 다중 모델 서버리스 — 하나의 엔드포인트에서 여러 모델을 전환하며 실행하는 방식이므로 이 문제의 단일 모델 요구사항과 맞지 않으며, 캐싱도 필요하지 않습니다. (B) 비동기 + InitialInstanceCount=0 — 비동기 추론은 요청을 큐에 저장하고 나중에 처리하는 방식이므로, '밤 1회 빠른 실행'의 배치 특성과 맞지 않습니다. 또한 InitialInstanceCount=0은 추가 오버헤드를 초래합니다. (C) 실시간 + 오토스케일 — 실시간 엔드포인트는 최소 1개 인스턴스를 항상 실행 중으로 유지해야 하므로, 하루 종일 미사용 시간에도 비용이 발생합니다. Scale-to-Zero는 지원하지 않습니다(현재 기준). 【시험 포인트】 '간헐적 배치 + 장시간 미사용' → Serverless Inference. MaxConcurrency는 동시 요청 수를 제한하는 파라미터.

해설

【핵심 용어】 ▸ 데이터 증강(Data Augmentation) — 기존 데이터에 변환을 가해 학습 샘플을 늘리고 모델의 일반화 능력 향상 ▸ 손상 이미지 변환 — 임펄스 노이즈, 흐림, 왜곡 등을 추가하여 품질 저하 시뮬레이션 ▸ 분포 불일치(Distribution Mismatch) — 학습 데이터와 실제 프로덕션 데이터의 특성 차이 【정답 포인트】 문제의 핵심은 '학습 중 잘 수행, 프로덕션 저성능' = 학습 데이터와 프로덕션 데이터의 분포 불일치입니다. 다양한 카메라의 이미지 품질 변동(노이즈, 블러, 조명 차이)이 원인입니다. 이를 해결하려면 학습 데이터에 동일한 품질 변동을 추가하여 모델을 강건하게 만들어야 합니다. Data Wrangler의 손상 이미지 변환(특히 임펄스 노이즈)은 정확히 카메라 센서 노이즈를 시뮬레이션합니다. 이 방식은 새로운 데이터 수집 (A) 과 달리 기존 데이터로 즉시 처리 가능하므로 시간이 가장 적게 소비됩니다. 명도 대비 향상 (C) 은 이미지 복원 목적이고, 크기 변환 (D) 은 해상도 표준화일 뿐 노이즈 강건성과 무관합니다. 【오답 체크】 (A) 추가 데이터 수집 — 새로운 이미지를 모든 카메라에서 수집하고 라벨링하는 과정이 매우 오래 걸립니다. 한 달 이상의 시간이 필요할 수 있습니다. (C) 명도 대비 향상 — 이미지를 복원하거나 개선하는 전처리이므로, 낮은 품질 이미지에 대한 모델의 강건성을 학습시키지 못합니다. 프로덕션 카메라의 낮은 품질을 고품질로 변환할 수 없습니다. (D) 크기 표준화 — 크기 조정은 이미지 품질 변동(노이즈, 해상도 차이)과 무관합니다. 학습 데이터의 다양성을 증가시키지 않습니다. 【시험 포인트】 '학습과 프로덕션 성능 갭 + 품질 변동' → 데이터 증강으로 분포 불일치 해결. 임펄스 노이즈 시뮬레이션이 최빠른 해결책.

해설

【핵심 용어】 ▸ AWS Secrets Manager — API 키, 데이터베이스 비밀번호, OAuth 토큰 등을 저장하고 자동 회전하는 서비스 ▸ 자동 회전(Automatic Rotation) — Secrets Manager의 기본 기능으로 Lambda를 호출하여 비밀번호/토큰 업데이트 ▸ Parameter Store — 구성 데이터와 비밀을 저장하지만 자동 회전 기능이 없음 【정답 포인트】 'API 토큰 자동 회전'은 Secrets Manager의 대표 사용 사례입니다. Secrets Manager는 정확히 이 목적으로 설계된 서비스로, 사용자 정의 회전 Lambda를 지정하면 설정된 일정(예: 3개월)에 따라 자동으로 실행됩니다. 회전 프로세스(1. 새 토큰 생성 2. 기존 토큰과 교체 3. 테스트 4. 커밋)를 Lambda에서 구현하면, Secrets Manager가 모두 자동화합니다. Parameter Store (B) 는 구성 데이터 저장 목적이며 자동 회전 기능이 없습니다. KMS(C, D)는 암호화 키 관리 서비스이며 토큰 회전 기능이 없습니다. 【오답 체크】 (B) Parameter Store + Lambda — Parameter Store는 구성 데이터(환경변수, 앱 설정) 저장에 최적화되었으며, Secrets Manager와 달리 자동 회전 오케스트레이션 기능이 없습니다. Lambda 함수를 직접 구성해도 회전 일정 관리, 버저닝, 롤백이 복잡합니다. (C) KMS + 관리 키 — KMS는 암호화 키의 회전을 관리하지만, API 토큰과 같은 비밀 데이터의 저장 및 회전 기능이 없습니다. 토큰 자동 회전에 부적절합니다. (D) KMS + 소유 키 — AWS 소유 키는 AWS가 관리하는 키로, 사용자 제어가 불가능하며 토큰 회전과 무관합니다. 【시험 포인트】 '비밀 데이터 자동 회전' → AWS Secrets Manager. 서비스 간 목적 구분: Secrets Manager(비밀 회전) vs Parameter Store(구성 데이터) vs KMS(암호화 키).

해설

【핵심 용어】 ▸ SageMaker Data Wrangler — 데이터 통합, 정제, 변환을 GUI 기반으로 수행하는 SageMaker 도구 ▸ 정제(Cleansing) — 누락된 값 채우기, 중복 제거, 이상치 처리 ▸ 보강(Enrichment) — 새로운 특성 추출, 데이터 유형 변환 【정답 포인트】 '여러 데이터 세트 통합 + 정제 + 보강'의 전체 데이터 준비 워크플로우가 필요합니다. SageMaker Data Wrangler는 정확히 이 전체 파이프라인을 GUI 기반으로 제공합니다: (1) 여러 소스에서 데이터 가져오기 (2) 자동 병합 및 통합 (3) Missing Value, Duplicate, Outlier 처리 기능 (4) Feature Engineering. 코드 작성 없이 드래그-드롭으로 수행 가능합니다. Ground Truth (B) 는 라벨링 도구이며 데이터 정제와 무관하고, Q Developer (C) 나 데이터 라벨링 (D) 도 이 문제의 정제 목표와 맞지 않습니다. 【오답 체크】 (B) Ground Truth + 인간 중심 루프 — Ground Truth는 데이터 라벨링(labeling, annotation)을 위한 서비스이며, 누락된 값 채우기나 이상치 제거 같은 데이터 정제 기능이 없습니다. 라벨 작업자를 통한 수동 라벨링은 정제 목표와 다릅니다. (C) 수동 병합 + Q Developer — 데이터 세트 병합을 수동으로 수행하고 Q Developer로 코드를 생성하는 방식은 많은 시간을 소비합니다. 또한 코드 생성만 가능하고 데이터 정제 작업 자체는 여전히 개발자가 구현해야 합니다. (D) 수동 병합 + 데이터 라벨링 — 데이터 라벨링은 이상치 제거나 누락된 값 처리가 아니라, 데이터에 정답 레이블을 부여하는 작업입니다. 이 문제의 정제 목표와 완전히 다릅니다. 【시험 포인트】 '데이터 통합 + 정제 + 보강' 전체 워크플로우 → Data Wrangler. No-code 데이터 준비 도구의 사용 사례.

해설

【핵심 용어】 ▸ 로지스틱 회귀(Logistic Regression) — 이진 분류(Binary Classification)를 위한 통계 모델로, 확률 출력 ▸ 이진 분류 — '예/아니오', '필요/불필요' 같은 두 가지 결과만 있는 문제 ▸ 확률 추정 — 입력 특성에 기반해 특정 클래스에 속할 확률을 계산 【정답 포인트】 문제의 핵심: '장기간 지원 필요 여부를 예측' = 이진 분류 문제입니다. 결과는 '필요(1)' 또는 '불필요(0)' 두 가지입니다. 로지스틱 회귀는 정확히 이진 분류를 위해 설계된 알고리즘으로, 입력 특성(고객 정보)에 기반해 특정 클래스일 확률을 출력합니다. 확률을 0.5 임계값으로 비교하여 최종 분류를 수행합니다. 선형 회귀 (B) 는 연속 값 예측(회귀)이므로 이진 분류에 부적절하고, 이상 탐지 (A) 는 비정상 행동을 찾는 것이며, 의미론적 분할 (D) 은 이미지의 픽셀 단위 분류입니다. 【오답 체크】 (A) 이상 탐지 — 정상/비정상 데이터 패턴을 구분하는 기법으로, '고객 특성'에 기반한 '지원 필요 여부' 예측과는 다릅니다. 이상치를 찾는 데 사용됩니다. (B) 선형 회귀 — 연속형 수치를 예측하는 기법(예: 주가, 판매량)으로, 이진 분류(Yes/No)에 부적합합니다. 로지스틱 회귀가 선형 회귀를 비선형으로 변환하여 이진 분류를 수행합니다. (D) 의미론적 분할 — 이미지의 각 픽셀을 특정 클래스로 분할하는 컴퓨터 비전 기법으로, 고객 정보 테이블 기반 이진 분류와 무관합니다. 【시험 포인트】 'Yes/No 예측' → 이진 분류 → 로지스틱 회귀. 문제 유형 판단: 회귀(선형) vs 분류(로지스틱).

해설

【핵심 용어】 ▸ SageMaker Model Registry — 모델 메타데이터(버전, 성능, 아티팩트 경로)를 중앙화하여 관리 ▸ Canvas 사용자 권한 — Canvas에서 모델을 로드하려면 아티팩트가 저장된 리소스에 접근 권한 필요 ▸ 동일 도메인(Same Domain) — 같은 SageMaker 도메인 내 사용자 간 리소스 공유의 전제 【정답 포인트】 'ML 엔지니어가 Canvas 사용자와 모델을 공유'하기 위한 필수 조건을 찾는 문제입니다. (B) Canvas 사용자가 S3 버킷에 접근할 수 있어야 → Canvas가 S3에서 모델 아티팩트를 로드할 수 있습니다. (C) 모델을 Model Registry에 등록 → Canvas에서 공유 모델을 발견하고 로드하는 메커니즘입니다. Model Registry는 SageMaker 도메인 내에서 모델을 중앙화하여 관리하고, Canvas 사용자는 Registry를 통해 모델을 찾아 자신의 프로젝트로 가져올 수 있습니다. (A) 별도 도메인은 오히려 공유를 방해하므로 거짓이고, (D) Marketplace는 외부 공유용이며 내부 공유와 무관하고, (E) SageMaker 엔드포인트 배포는 Canvas 사용 목적과 무관합니다. 【오답 체크】 (A) 별도 도메인 — 문제에서 '동일한 SageMaker 도메인에 속합니다'라고 명시되어 있으며, 별도 도메인은 공유를 더 어렵게 만듭니다. 거짓입니다. (D) AWS Marketplace — Marketplace 호스팅은 외부 고객들과 모델을 판매하는 경우이며, 내부 Canvas 사용자 간 공유와 무관합니다. (E) SageMaker 엔드포인트 배포 — Canvas는 배포된 엔드포인트가 아닌 모델 아티팩트 파일을 직접 로드합니다. Canvas 사용자가 모델을 추가 튜닝하려면 엔드포인트가 아닌 학습 가능한 모델 파일 접근이 필요합니다. 【시험 포인트】 다중 선택 문제 — Canvas 공유 = Model Registry 등록 + S3 접근 권한. 배포 vs 공유의 개념 구분 필수.

해설

【핵심 용어】 ▸ Hyperband — 무작위 탐색과 연속 반감(successive halving)을 결합하여 계산 효율 최적화 ▸ 연속 반감(Successive Halving) — 저성능 하이퍼파라미터 조합을 조기에 제거 ▸ 계산 시간 최소화 — Early stopping과 리소스 할당 최적화 【정답 포인트】 '가장 적은 계산 시간'이 핵심 요구사항입니다. Hyperband는 정확히 이 목표를 위해 설계된 알고리즘입니다. 작동 원리: (1) 무작위 하이퍼파라미터 후보 샘플링 (2) 작은 리소스(에포크/데이터)로 초기 평가 (3) 성능이 낮은 조합 조기 제거 (4) 남은 조합에 더 많은 리소스 할당 (5) 반복). 이 방식은 저성능 후보를 빠르게 제거하므로 전체 계산 시간을 크게 단축합니다. 격자 탐색 (B) 은 모든 조합을 평가하므로 계산량이 많고, 베이지안 (C) 은 순차 기반이므로 병렬화 어렵고, 무작위 탐색 (D) 은 모든 후보를 동등하게 평가합니다. 【오답 체크】 (B) 격자 탐색 — 모든 하이퍼파라미터 조합을 완전히 평가해야 하므로, 후보 수가 지수적으로 증가할 때 계산 시간이 급증합니다(차원의 저주). (C) 베이지안 최적화 — 확률 모델을 기반으로 순차적 탐색을 수행하므로, 병렬 처리가 어렵고 각 평가에 시간이 걸립니다. 대규모 데이터에는 부적합합니다. (D) 무작위 탐색 — 무작위 샘플링은 효율적이지만, 모든 후보를 동등하게 평가하므로 저성능 조합에도 리소스를 낭비합니다. 【시험 포인트】 '계산 시간 최소 + 대량 데이터' → Hyperband. Early stopping과 리소스 할당 최적화의 결합.

해설

【핵심 용어】 ▸ S3 게이트웨이 엔드포인트 — VPC 내에서 인터넷 게이트웨이 없이 S3에 접근하는 최적 방식 ▸ 계정 간 액세스(Cross-Account Access) — 다른 AWS 계정의 S3 버킷에 접근하려면 버킷 정책 + IAM 권한 조합 ▸ 공개 IPv4 없음(No Public IP) — 인터넷 게이트웨이 또는 NAT 없이 비공개 서브넷에서만 운영 【정답 포인트】 '공개 IPv4 없음' + '계정 간 S3 액세스'의 조합입니다. S3 게이트웨이 엔드포인트는 VPC 내 Redshift와 SageMaker에서 S3에 직접 접근하는 가장 간단하고 효율적인 방식입니다. 게이트웨이 엔드포인트는 추가 비용이 없고, NAT나 인터넷 게이트웨이 없이도 작동합니다. 계정 간 액세스를 위해 보조 계정의 S3 버킷 정책을 업데이트하여 기본 계정의 IAM 주체(Redshift의 IAM 역할, SageMaker 실행 역할)를 허용합니다. VPC 피어링 (A) 이나 Direct Connect (B) 는 VPC 간 연결이지만 S3 액세스 자체는 별도 구성이 필요하고, Site-to-Site VPN (C) 은 IPsec 오버헤드가 있습니다. 【오답 체크】 (A) VPC 피어링 — 두 VPC를 피어링 연결하지만, 보조 계정의 S3 버킷 접근을 위해 여전히 공개 IPv4가 필요합니다. 또한 피어링만으로는 계정 간 S3 액세스 권한 설정이 불완전합니다. (B) Direct Connect + 전송 게이트웨이 — 기업 전용선 연결로 비용이 매우 높고, 보조 계정의 S3 접근을 위한 게이트웨이 엔드포인트 구성이 여전히 필요합니다. 오버엔지니어링입니다. (C) Site-to-Site VPN + 인터페이스 엔드포인트 — VPN은 IPsec 터널링 오버헤드가 있고, 인터페이스 엔드포인트는 시간당 비용이 발생합니다(게이트웨이는 무료). S3 접근에 인터페이스 엔드포인트는 과도합니다. 【시험 포인트】 'S3 + 계정 간 + 공개 IP 없음' → S3 게이트웨이 엔드포인트 + 버킷 정책. VPC 엔드포인트 유형 (게이트웨이 vs 인터페이스) 선택 기준.

해설

【핵심 용어】 ▸ Amazon CloudWatch — 애플리케이션 메트릭 수집, 저장, 분석하는 모니터링 서비스 ▸ CloudWatch 알람 — 메트릭 임계값 초과 시 자동으로 SNS 알림 발송 ▸ AWS CloudTrail — API 호출 감사 로그 (메트릭 모니터링 목적 아님) 【정답 포인트】 '메트릭 모니터링 + 임계값 초과 시 이메일'은 CloudWatch의 표준 사용 사례입니다. 프로세스: (1) Lambda에서 메트릭을 CloudWatch에 발행 (2) CloudWatch에 알람 규칙 설정 (임계값, 지속 시간 등) (3) 알람이 SNS 주제로 메시지 발송 (4) SNS가 구독자(이메일)에게 알림. CloudTrail (A) 은 API 호출 감사 로그이며 메트릭 기반 알림이 아니고, CloudFront(B, D)는 CDN 콘텐츠 배포 서비스로 메트릭 모니터링과 무관합니다. 【오답 체크】 (A) CloudTrail + 이메일 — CloudTrail은 AWS API 호출 기록을 저장하는 감사 로그 서비스일 뿐, 메트릭 값 기반 알람 기능이 없습니다. 또한 CloudTrail 자체는 이메일 알림을 보낼 수 없습니다. (B) CloudFront + CloudWatch 알람 — CloudFront는 CDN(콘텐츠 배포 네트워크)이며, 애플리케이션 메트릭 저장 목적이 아닙니다. CloudWatch 알람으로 CloudFront 메트릭은 모니터링할 수 있지만, Lambda가 생성하는 모델 메트릭과 무관합니다. (D) CloudWatch + CloudFront 규칙 — CloudFront는 CDN 캐시 규칙만 가능하며, CloudWatch 메트릭 임계값 기반 알림 기능이 없습니다. 【시험 포인트】 '메트릭 임계값 알림' → CloudWatch Alarm → SNS → 이메일. 서비스 간 용도 구분: CloudTrail(감사), CloudFront(CDN), CloudWatch(모니터링).