정답 · 해설

해설

【핵심 용어】 ▸ Amazon Textract — PDF/스캔 이미지에서 텍스트 추출하는 OCR 도구 ▸ Amazon Comprehend — 추출된 텍스트에서 엔티티 인식(NER) 수행 ▸ Amazon A2I — 휴먼 인-더-루프 검증(느림) 【정답 포인트】 "extract and store entities in the LEAST amount of time" → PDF에서 직접 엔티티 추출을 원한다면? Comprehend는 텍스트 입력으로 즉시 엔티티를 추출 가능. Textract는 OCR 전처리 단계이므로 불필요한 오버헤드. 직접 PDF 텍스트를 Comprehend에 전달하면 가장 빠름. 【오답 체크】 (B) 오픈소스 OCR + SageMaker — OCR 도구를 SageMaker에서 실행하는 관리 오버헤드, 엔티티 추출 추가 필요 (C) Textract + Comprehend 조합 — OCR(Textract)에서 텍스트 추출 후 Comprehend 호출은 2단계 처리로 시간 증가 (D) Textract + A2I — 휴먼 검증 루프가 포함되어 자동화된 시간이 아니라 사람 개입으로 시간 대폭 증가 【시험 포인트】 PDF에서 엔티티 추출 → PDF가 텍스트 기반이라면 Comprehend만으로 충분. Textract는 스캔 이미지 같은 OCR이 필요한 경우에만 사용. 문제에서 "entities in PDF"는 대개 텍스트 PDF를 의미하므로 Comprehend 직접 사용이 최적.

해설

【핵심 용어】 ▸ aws:sourceIp — 요청 출처 IP 주소 기반 접근 제어 ▸ aws:sourceVpc — 요청 출처 VPC 기반 접근 제어 ▸ Presigned URL — 임시 인증 토큰 포함 URL로 외부 공유 시 악용 위험 【정답 포인트】 "presigned URLs" 악용 방지 → 사전 서명된 URL은 정당한 사용자가 생성하지만, 악의적 행위자가 탈취하면 어디서든 사용 가능. VPN을 통한 제한된 네트워크만 허용하려면, IP 기반 정책(aws:sourceIp)으로 특정 VPN IP 범위만 승인하여 외부 사용 차단. 【오답 체크】 (B) aws:sourceVpc — VPC 기반 제어는 VPC 엔드포인트 사용 시에만 적용되며, presigned URL 악용 방지에는 직접적 연관성 약함 (C) aws:PrimaryTag — 역할(Role) 자체의 태그로 접근자 신원 검증 불가. VPN IP 제한과 무관 (D) aws:PrincipalTag — 사용자(Principal) 태그로 신원 검증하나, presigned URL은 토큰 탈취 시 사용자 신원 우회 가능 【시험 포인트】 Presigned URL 악용 방지 + VPN 제한 환경 → IP 기반 정책(aws:sourceIp)으로 특정 네트워크 IP 범위만 허용하여 VPN 외부 접근 차단. 가장 직접적인 보안 메커니즘.

해설

【핵심 용어】 ▸ AWS Glue — 관리형 ETL 서비스, 자동 스케일링, 메타데이터 카탈로그 제공 ▸ DynamicFrame — Glue의 네이티브 데이터 구조, 스키마 유연성 제공 ▸ Amazon EMR — Spark 클러스터 관리 필요 (운영 오버헤드) ▸ AWS Lambda — 최대 15분 제한으로 수백만 레코드 처리 부적합 【정답 포인트】 "LEAST operational overhead" + 주간 병합 작업 → AWS Glue는 관리형 서비스로 클러스터 생성/해제 자동화, 메타데이터 자동 관리. DynamicFrame의 기본 작업(join, transform)으로 명시적 Spark 코드 최소화. S3-Aurora 연결도 Glue가 자동 처리. 【오답 체크】 (A) EMR 클러스터 — 매주 클러스터 생성/구성/삭제 운영, 비용 최적화 고려 필요 (C) Lambda — 15분 타임아웃 제한으로 수백만 레코드 처리 불가능, 작은 데이터셋에만 적합 (D) AWS Batch + EC2 — EC2 인스턴스 관리, 비용 계산, 클러스터 구성 필요로 운영 복잡도 높음 【시험 포인트】 "운영 부담이 적은" + "매주 반복" + "대규모 ETL" → Glue 같은 완전관리형 서비스 우선. EMR은 더 세밀한 제어 필요할 때만 선택.

해설

【핵심 용어】 ▸ ModelSetupTime — 서버리스 엔드포인트 콜드 스타트 시 모델 초기화 및 로딩 시간 ▸ ModelLoadingWaitTime — 존재하지 않는 메트릭 ▸ Model Monitor — 데이터 품질, 모델 품질, 편향 탐지용으로 지연 시간 측정 목적 아님 【정답 포인트】 "모델 시작 시간"(model startup time) 확인 → 서버리스 엔드포인트는 콜드 스타트(요청 시 인스턴스 생성)로 인해 지연 발생. SageMaker CloudWatch 네임스페이스의 ModelSetupTime 메트릭은 정확히 이 초기화 단계 시간을 기록. 가설 검증에 직접 유용. 【오답 체크】 (A) Model Monitor — 데이터 품질(drift), 모델 품질 모니터링용. 지연 시간 분석과 무관 (B) CloudWatch 메트릭 활성화 + Model Monitor — Model Monitor는 시작 시간 메트릭 제공 안함 (D) ModelLoadingWaitTime — SageMaker에 존재하지 않는 공식 메트릭명. 정확한 메트릭은 ModelSetupTime 【시험 포인트】 서버리스 엔드포인트 + "latency 증가" + "startup time 원인 규명" → ModelSetupTime 메트릭이 정답. SageMaker의 정확한 메트릭명 암기 필수.

해설

【핵심 용어】 ▸ Amazon Comprehend DetectPiiEntities — PII 자동 감지 및 마스킹 API ▸ AWS Glue DataBrew — UI 기반 데이터 정제 도구 (관리 오버헤드) ▸ Amazon Macie — 발견만 제공, 자동 마스킹 미지원 ▸ Amazon EFS — 추가 네트워크 I/O 오버헤드 【정답 포인트】 "가장 운영적으로 효율적인" → PII 감지/제거는 API 호출로 자동화 가능. Comprehend DetectPiiEntities는 단 2줄 코드로 PII를 감지하고 마스킹. 정제된 데이터를 S3에 저장하면 SageMaker 학습 시 표준 S3 연결 사용 가능. 관리 오버헤드 최소. 【오답 체크】 (B) EFS 마운트 — S3보다 높은 네트워크 I/O 비용과 마운트 구성 복잡도 증가 (C) DataBrew — UI 기반 시각적 정제로 자동화 어려움. 규칙 정의 및 관리 오버헤드 증가 (D) Macie — PII 자동 발견만 가능하고 마스킹 기능 미지원. 제거 후 저장 프로세스 추가 필요 【시험 포인트】 PII 규정 준수 + "운영 효율" → Comprehend API 자동화 + S3 저장이 가장 간단. DataBrew는 관리 UI 오버헤드, Macie는 발견만 지원.

해설

【핵심 용어】 ▸ Lifecycle Configuration — SageMaker 노트북 생성/시작 시 자동 실행 스크립트 ▸ ECR + Docker — 컨테이너 레지스트리 관리 오버헤드 ▸ CodeArtifact — 패키지 저장소 관리 (복잡도 증가) ▸ Lambda + EventBridge — 이벤트 기반 트리거로 불필요한 복잡도 【정답 포인트】 "새로운 노트북 인스턴스에 자동 설치" + "운영 부담 최소" → Lifecycle Configuration은 SageMaker 네이티브 기능으로, 노트북 생성 옵션에 직접 첨부. 노트북 생성 시 자동 실행되므로 별도 트리거/이벤트 처리 불필요. 가장 간단한 솔루션. 【오답 체크】 (B) ECR + Docker — 이미지 빌드, 레지스트리 관리, Studio 도메인 통합 모두 수동 작업 필요 (C) CodeArtifact + PrivateLink — 패키지 저장소 생성 및 관리로 복잡도 대폭 증가 (D) Lambda + EventBridge — EventBridge 규칙 생성, Lambda 함수 배포, 권한 설정 등 여러 단계 필요 【시험 포인트】 SageMaker 노트북 자동 설정 → Lifecycle Configuration이 표준 솔루션. 생성 시점에 자동 실행되는 네이티브 기능 활용이 핵심.

해설

【핵심 용어】 ▸ Amazon MSK — 고성능 스트림 처리용 관리형 Kafka ▸ Amazon Managed Service for Apache Flink — SQL + Jupyter 지원하는 실시간 스트림 처리 ▸ Amazon Kinesis Data Streams — 실시간 처리 가능하나 Jupyter 미지원 ▸ Amazon Athena — 배치 쿼리용으로 실시간 처리 부적합 【정답 포인트】 "SQL for processing" + "Jupyter notebooks" + "near real time" → Apache Flink는 SQL 쿼리(Flink SQL)와 Jupyter 노트북 통합을 모두 지원하는 유일한 오픈소스 스트림 처리 엔진. MSK에서 높은 볼륨 데이터를 수집하고 Flink에서 실시간 SQL 처리 및 Jupyter 분석 모두 가능. 【오답 체크】 (A) Firehose + Lambda + S3 — Jupyter 노트북 지원 미흡, Lambda는 SQL 쿼리 미지원 (B) Kinesis + Athena — Athena는 배치 쿼리 도구로 "near real time" 미지원. Jupyter 노트북 적분 약함 (C) MSK + Glue PySpark — PySpark는 SQL 지원하나 Jupyter와의 통합이 약함. 배치 성격의 Glue는 실시간 처리에 부적합 【시험 포인트】 "SQL" + "Jupyter" + "streaming" + "near real time" 모두 만족 → Apache Flink 관리형 서비스 선택. SQL + Jupyter 동시 지원 유일한 솔루션.

해설

【핵심 용어】 ▸ Amazon Comprehend — 일반 텍스트의 PII (이름, SSN, 주소) 감지 ▸ Amazon Comprehend Medical — 의료 특화 PHI (약물, 질환, 환자명, 의료기록번호) 감지 ▸ AWS Glue DataBrew — UI 기반 데이터 정제로 PII/PHI 자동화 어려움 ▸ 암호화 — 마스킹이 아닌 암호화는 모델 학습에 방해요소 【정답 포인트】 PII + PHI 동시 제거 → PII와 PHI는 완전히 다른 도메인. Comprehend는 일반적 개인정보(이름, 이메일), Comprehend Medical은 의료 용어(약물명, 진단코드, 의료기록번호) 인식. 두 서비스를 순차적으로 사용하면 모든 민감정보 마스킹 가능. 【오답 체크】 (A) DataBrew — UI 기반 정제로 자동화된 PII/PHI 감지 규칙 구성 복잡. 정기적 업데이트 어려움 (B) Redshift SQL 저장프로시저 — SQL만으로는 의료용어(PHI) 패턴 인식 한계. 커스텀 로직 필요로 복잡 (D) 암호화 — 암호화된 데이터는 모델이 학습 불가. 마스킹과 암호화 다름 【시험 포인트】 PII + PHI 감지 동시 필요 → 도메인별 전문화된 Comprehend 서비스 두 개 조합. 일반 Comprehend + 의료 특화 Comprehend Medical 순서로 사용.

해설

【핵심 용어】 ▸ Custom Docker Container — 모든 처리/학습/파이프라인 작업에서 재사용 가능 ▸ ECR (Elastic Container Registry) — 완전관리형 컨테이너 저장소 ▸ 수동 설치 — 매번 인스턴스마다 반복해야 함 ▸ Lambda + 노트북 — 노트북 인스턴스 관리 오버헤드 【정답 포인트】 "처리 작업, 학습 작업, 파이프라인" 모두에서 커스텀 라이브러리 필요 → 커스텀 Docker 이미지를 ECR에 저장하면, SageMaker 모든 작업 타입에서 동일 이미지 참조 가능. 라이브러리 버전 일관성 유지, 이미지 재구축 시 모든 작업 자동 반영. 【오답 체크】 (A) 수동 설치 — 처리/학습/파이프라인 작업마다 반복 설치. 라이브러리 버전 일관성 관리 불가 (C) Lambda + Notebook — 노트북 인스턴스 생성/관리 오버헤드. 파이프라인 통합 복잡 (D) EC2 외부 실행 — 결과만 S3에 저장하므로, 작업 내 라이브러리 사용 불가. 파이프라인 통합 불가능 【시험 포인트】 "처리/학습/파이프라인" 모든 컨텍스트에서 커스텀 라이브러리 필요 → Docker 이미지 한 번 구축 후 ECR에 저장. 모든 SageMaker 작업에서 동일 이미지 참조하는 것이 가장 효율적.

해설

【핵심 용어】 ▸ SageMaker Model Monitor — 프로덕션 모델의 데이터 품질(drift), 모델 품질, 편향 자동 감지 ▸ SageMaker Clarify — 모델 해석 가능성(explainability), 편향 분석용 ▸ CloudWatch 메트릭 알람 — 일반적 메트릭만 모니터링 ▸ SageMaker Data Wrangler — 데이터 전처리 도구 【정답 포인트】 "데이터 품질 문제 감지" → Model Monitor는 baseline 데이터와 비교하여 프로덕션 데이터의 drift(데이터 분포 변화), 누락된 값, 이상값 등 데이터 품질 문제를 자동 감지. CloudWatch와 통합하여 경보 설정 가능. 【오답 체크】 (A) CloudWatch 메트릭 알람 — 일반 시스템 메트릭(CPU, 메모리)만 모니터링 가능. 데이터 품질 drift 감지 불가 (B) SageMaker Clarify — 모델 출력 해석가능성(feature importance) 및 편향 분석용. 데이터 품질 모니터링 목적 아님 (D) SageMaker Data Wrangler — 데이터 정제/변환 도구로 실시간 모니터링 용도 아님 【시험 포인트】 "데이터 품질 문제" + "프로덕션 모니터링" → SageMaker Model Monitor 전용 솔루션. drift 감지 및 CloudWatch 알림 통합 표준 패턴.

해설

【핵심 용어】 ▸ S3 fast file 모드 — SageMaker에서 파일 단위로 병렬 다운로드 최적화 ▸ S3 Express One Zone — 고성능 S3이나 추가 비용 발생 ▸ Amazon FSx for Lustre — 고성능 파일시스템이나 높은 비용 ▸ Amazon EFS — NFS 프로토콜로 네트워크 I/O 오버헤드 【정답 포인트】 "MOST cost-effective" + 300GB + 200MB 파일 다수 → S3 fast file 모드는 S3 Standard에서 파일 병렬화를 통해 처리량 최적화. S3 Express One Zone 추가 비용 없이도 효율적 성능 달성. 대시보드 도구 연결도 S3 Standard 유지 가능. 【오답 체크】 (A) Amazon EFS — NFS 네트워크 오버헤드로 성능 낮음. 지속적 스토리지 비용 발생 (B) FSx for Lustre — HPC 워크로드용 고성능이나 높은 월별 요금. 300GB 규모에는 과도한 비용 (C) S3 Express One Zone — Express 티어는 1년 비용이 Standard의 수십 배. 300GB에는 비용 비효율 【시험 포인트】 "비용 효율" + "S3 Standard" + "다수 파일" → fast file 모드로 파일 병렬화. Express One Zone 추가 비용 회피가 정답.

해설

【핵심 용어】 ▸ Shadow Variant — 프로덕션 트래픽 일부를 신규 모델로 라우팅하여 성능 테스트 ▸ A/B Testing (A/B 테스트) — SageMaker Endpoint에서 shadow variant로 구현 가능 ▸ 수동 트래픽 분할 — 운영 부담 증가 ▸ Lambda 커스텀 로직 — 라우팅 로직 유지보수 복잡 【정답 포인트】 "새 모델 성능 비교" + "운영 노력 최소" → SageMaker의 shadow variant 기능으로 기존 엔드포인트에 신규 모델 추가. 프로덕션 트래픽 일부(예: 10%)를 자동으로 섀도우 모델에 분산. 정성평가 후 트래픽 100% 전환으로 무중단 배포. 【오답 체크】 (A) 수동 분할 — 클라이언트 코드 수정으로 매요청마다 엔드포인트 선택 로직 필요. 운영 부담 증가 (B) CloudFront — CDN은 캐싱으로 실시간 트래픽 분석에 부적합. 모델 성능 메트릭 수집 어려움 (D) Lambda 커스텀 로직 — 라우팅 로직 배포, 에러 처리, 모니터링 모두 수동 구현. 유지보수 오버헤드 【시험 포인트】 "A/B 테스트" + "새 모델 배포" → SageMaker shadow variant 네이티브 기능 활용. 엔드포인트 레벨에서 자동 트래픽 분산으로 최소 운영 노력.

해설

【핵심 용어】 ▸ Metadata Tracking Opt-out — SageMaker API에서 학습 작업의 메타데이터 수집 거부 옵션 ▸ Private Subnet — 네트워크 격리이지 메타데이터 수집과 무관 ▸ KMS 암호화 — 데이터 암호화이지 메타데이터 수집 방지 아님 ▸ AWS Nitro — 인스턴스 타입 선택으로 메타데이터 수집 방지 불가 【정답 포인트】 "aggregated metadata collection 금지" → SageMaker CreateTrainingJob API에는 EnableManagedSpotTraining, MetadataServiceConfiguration 등 메타데이터 거부 옵션 존재. API 파라미터에서 명시적으로 메타데이터 추적 비활성화하면 AWS가 집계 메타데이터 수집 중단. 【오답 체크】 (B) Private Subnet — VPC 격리는 네트워크 보안이나, AWS 내부의 메타데이터 수집과는 독립적 (C) KMS 고객 관리 키 — 데이터 암호화로 메타데이터 수집 방지 불가. 규정은 메타데이터 수집 자체 금지 (D) AWS Nitro — 인스턴스 CPU 아키텍처로 메타데이터 정책 제어 불가 【시험 포인트】 "메타데이터 수집 금지" → SageMaker API에서 메타데이터 거부 옵션 명시적 활성화. CreateTrainingJob의 파라미터 검토 필수.

해설

【핵심 용어】 ▸ AWS PrivateLink — VPC 엔드포인트를 통해 AWS 서비스에 프라이빗 연결 ▸ VPC Endpoint (Interface) — 서비스 API를 VPC 내부에서 호출 가능 ▸ 보안 그룹 수정 — 인터넷 게이트웨이 없이 외부 IP 접근 불가능하므로 효과 없음 ▸ Direct Connect — 데이터센터-AWS 간 전용 네트워크 연결로 과도 【정답 포인트】 "프라이빗 서브넷 유지" + "Bedrock API 호출" → AWS PrivateLink를 통해 VPC 내부에 Bedrock 인터페이스 엔드포인트 생성. 인터넷 게이트웨이 없이도 EC2에서 비공개로 Bedrock API 호출 가능. 보안 그룹은 VPC 엔드포인트의 보안 그룹만 열면 됨. 【오답 체크】 (A) 보안 그룹 수정 — EC2가 프라이빗 서브넷에 있고 인터넷 게이트웨이 없으면, 보안 그룹 규칙만으로는 Bedrock(퍼블릭 API) 접근 불가 (C) Bedrock 프라이빗 구성 — Bedrock은 AWS 관리형 서비스로 고객이 VPC 구성 불가능 (D) Direct Connect — 온프레미스와 AWS 간 전용 연결로 EC2-Bedrock 통신에는 필요 없음. 비용 과다 【시험 포인트】 "프라이빗 서브넷" + "AWS 서비스 접근" → PrivateLink를 통한 VPC 엔드포인트 표준 패턴. VPC 외부 서비스 비공개 접근 솔루션.

해설

【핵심 용어】 ▸ Amazon SageMaker JumpStart — 사전학습 오픈소스 모델 사전 최적화 배포 ▸ API Gateway + Lambda — 서버리스 대화형 UI 구축 (낮은 오버헤드) ▸ EC2 + GPU — 모델 서버 관리, GPU 비용, 운영 복잡도 증가 ▸ QuickSight — BI/대시보드 도구로 대화형 AI 인터페이스 부적합 ▸ Amazon Lex — 챗봇 플랫폼이나 LLM 통합 복잡 【정답 포인트】 "운영 부담 최소" + "LLM 배포" + "사용자 질문" → (A) SageMaker JumpStart는 오픈소스 LLM을 사전 최적화하여 한 클릭 배포 가능. 모델 선택, 인스턴스 자동 결정. (C) API Gateway + Lambda는 서버리스 인프라로 자동 스케일링, 관리 불필요. 두 서비스 모두 관리형이므로 운영 오버헤드 최소. 【오답 체크】 (B) EC2 + .zip — 모델 바이너리 다운로드, GPU 인스턴스 관리, 스케일링 설정 모두 수동 (D) QuickSight — BI 시각화 도구로 실시간 대화형 AI 부적합 (E) Amazon Lex — ASR/NLU 챗봇 플랫폼으로 커스텀 LLM 통합에 제약 많음 【시험 포인트】 "오픈소스 LLM" + "내부 인터페이스" + "최소 운영" → JumpStart (모델 배포) + API Gateway/Lambda (UI 백엔드) 조합. 완전관리형 서비스로 구성.

해설

【핵심 용어】 ▸ Amazon Kinesis Data Streams — 분당 GB 규모 고속 스트림 수집 (실시간 최적) ▸ Amazon Managed Service for Apache Flink — 스트림 변환 (SQL/Python 지원) ▸ Amazon DynamoDB — NoSQL로 빠른 쿼리, 자동 스케일링 (실시간 최적) ▸ Amazon EventBridge — 이벤트 라우팅용 (대용량 스트림 부적합) ▸ Amazon SQS — 배치 처리용 (실시간 분석 지연) 【정답 포인트】 "분당 5GB" + "실시간 변환" + "빠른 쿼리" → Kinesis Data Streams는 고처리량 스트림 수집에 최적. Flink는 실시간 스트림 변환(지연 ms 단위). DynamoDB는 NoSQL로 밀리초 응답시간 보장 및 자동 스케일링으로 분당 GB 규모 데이터 처리 가능. 【오답 체크】 (A) EventBridge + Glue + ElastiCache — EventBridge는 이벤트 라우팅용으로 분당 GB 스트림 부적합. Glue는 배치 ETL 도구 (B) SQS + Lambda + S3 — SQS 처리 지연, Lambda 15분 제한으로 대용량 스트림 처리 불가. S3는 쿼리 느림 (C) SNS + EMR + RDS — SNS는 pub/sub만 가능. EMR은 배치 클러스터로 실시간 변환 부적합. RDS는 행 기반 쿼리 느림 【시험 포인트】 "분당 5GB" + "실시간" + "빠른 쿼리" → Kinesis (수집) + Flink (변환) + DynamoDB (저장) 조합. 모두 스트림/NoSQL 기반으로 밀리초 지연.

해설

【핵심 용어】 ▸ AWS KMS (Key Management Service) — AWS의 표준 암호화 키 관리 서비스 ▸ AWS Encryption CLI — S3 파일 암호화 표준 도구 ▸ SSH 접근 키 — 로컬 머신 인증용 (S3 암호화 불가) ▸ API Gateway 키 — API 인증용 (암호화 키 아님) ▸ IAM 역할 + GenerateDataKey — 수동 키 생성 프로세스로 복잡 【정답 포인트】 "암호화 + 접근 제어" → AWS KMS는 암호화 키 생성/관리/권한 제어 통합 솔루션. KMS 키로 생성한 후 AWS Encryption CLI와 함께 사용하면 자동으로 KMS 권한 체크. 누가 KMS 키 접근 가능한지 IAM 정책으로 명확히 제어. 【오답 체크】 (A) SSH 접근 키 — SSH는 로컬 머신 인증 용도. S3 파일 암호화 불가능 (B) API Gateway 키 — API 클라이언트 인증용. 암호화 키 아님 (C) IAM 역할 + GenerateDataKey — 직접 데이터 키 생성하는 수동 프로세스. KMS 자동 통합 미흡. 키 로테이션, 접근 감시 복잡 【시험 포인트】 S3 암호화 + "접근 제어" → AWS KMS 표준 솔루션. Encryption CLI와 조합으로 권한 자동 검증. IAM과 KMS 정책 이중 제어.

해설

【핵심 용어】 ▸ SageMaker Feature Processing — 피처 엔지니어링, 데이터 변환 및 정규화를 위한 서버리스 완전관리형 서비스 ▸ SageMaker Feature Store — 머신러닝 피처의 중앙집중식 저장소로 온라인/오프라인 스토어 제공 【정답 포인트】 ▸ 기능 엔지니어링 + 피처 저장 → Feature Processing과 Feature Store의 네이티브 통합이 가장 자연스럽고 효율적입니다. Feature Processing은 데이터 준비 전문, Feature Store는 피처 관리 전문입니다. 【오답 체크】 (B) Model Monitor는 프로덕션 모델 성능 모니터링용이며 데이터 수집/변환 도구가 아닙니다. S3는 피처 저장소로 부적절합니다. (C) Managed Flink는 실시간 스트리밍 전문이고 feature engineering이 아니며, 초기 데이터 준비에는 오버킬입니다. (D) Batch transform은 모델 추론용이며 데이터 변환용이 아닙니다. DynamoDB는 피처 저장소 용도로 설계되지 않았습니다. 【시험 포인트】 기능 엔지니어링 → Feature Processing / 피처 저장 → Feature Store 는 MLA-C01의 핵심 매핑입니다.

해설

【핵심 용어】 ▸ Real-time Inference Endpoint — 동기식 즉시 응답을 위한 엔드포인트로 밀리초 단위 지연 보장 ▸ Serverless Inference — 부하에 따라 자동 스케일링되는 비용 효율적 옵션이지만 콜드 스타트 지연 존재 【정답 포인트】 ▸ "응답 시간 지연 최소화" → Real-time endpoint의 낮은 지연 시간이 가장 중요합니다. 제품 추천 애플리케이션은 온라인 고객이 기다리므로 지연이 치명적입니다. 실시간 엔드포인트는 보장된 응답 시간을 제공합니다. 【오답 체크】 (A) Batch transform은 오프라인 배치 처리용이며 실시간 요청에 부적절합니다. (C) Serverless endpoint는 비용 효율적이지만 콜드 스타트로 인한 지연이 발생하여 "응답 시간 최소화" 요구사항을 충족하지 못합니다. (D) Asynchronous endpoint는 수 분 이상의 처리 시간이 필요한 경우용이며 온라인 고객 상호작용에 부적절합니다. 【시험 포인트】 응답 시간 최소화 → Real-time endpoint / 비용 최적화 → Serverless endpoint 는 구분이 명확합니다.

해설

【핵심 용어】 ▸ PutRecord API — 개별 레코드를 온라인 스토어에만 저장하는 저수준 인터페이스 ▸ Feature Store Spark connector — 온/오프라인 스토어 동시 수집을 지원하는 고수준 통합 도구 【정답 포인트】 ▸ "온라인 + 오프라인 모두 필요" + "실시간 + 배치 데이터" → Spark connector with both stores enabled가 유일한 완전한 솔루션입니다. 온라인은 실시간 제공, 오프라인은 배치 처리를 담당합니다. 【오답 체크】 (A) PutRecord는 온라인만 지원하며 오프라인 스토어 요구사항을 충족하지 못합니다. (B) PutRecord는 오프라인 수집을 지원하지 않습니다. (D) 오프라인 스토어를 비활성화하면 배치 처리 요구사항을 충족할 수 없습니다. 【시험 포인트】 온/오프라인 동시 필요 → Spark connector with both enabled 는 명확한 선택입니다.