정답 · 해설

해설

【핵심 용어】 ▸ SageMaker Clarify — 편향 감지와 공정성 메트릭 분석 전문 서비스 ▸ CloudWatch 합성 알람 — 여러 메트릭을 결합하여 종합 평가 가능 【정답 포인트】 ▸ 공정성 평가 → SageMaker Clarify 필수 ▸ 메트릭 모니터링 → CloudWatch 메트릭과 알람 ▸ Bedrock Latency와 Clarify 편향 메트릭을 합성 알람으로 결합하면 종합적 공정성 평가 대시보드 구성 【오답 체크】 (A) 커스텀 Lambda 포스트프로세싱은 개발 오버헤드 증가 (B) Guardrails는 콘텐츠 필터링용이지 공정성 평가 서비스 아님 (D) 모델 평가 작업은 일회성이며 실시간 모니터링 미지원 【시험 포인트】 공정성 메트릭 = SageMaker Clarify + CloudWatch 패턴 인식

해설

【핵심 용어】 ▸ Denied Topics — Bedrock Guardrails에서 특정 주제를 차단하는 정책 ▸ Custom Word Filters — 사용자 정의 키워드를 입력/출력에서 필터링 ▸ Grounding Score — 응답이 실제 데이터 소스에 기반하는 정도를 측정하는 점수 【정답 포인트】 ▸ (A) 고위험 대화 패턴(주식 추천, 보장 수익률) → Denied Topics로 차단하는 것이 가장 직접적이고 효과적 ▸ (D) 경쟁사 이름 → 사용자 정의 단어 필터로 입력/출력 모두 차단하여 콘텐츠 생성 방지 ▸ (F) 높은 그라운딩 점수 임계값 → 사실 기반이 아닌 응답을 배제하여 "팩트 체크" 역할 수행 【오답 체크】 (B) 콘텐츠 필터는 일반적인 해로운 콘텐츠 필터링용이며, 고위험 대화 패턴 차단에는 Denied Topics가 더 적합 (C) 경쟁사 이름은 프롬프트 필터링이 아닌 단어 필터 (D) 로 처리하는 것이 정확 (E) 낮은 임계값은 그라운딩이 약한 응답을 허용하므로 반대 【시험 포인트】 ▸ Bedrock Guardrails의 3가지 핵심 정책: Denied Topics, Content Filters, Custom Filters ▸ 고위험 패턴 차단 → Denied Topics | 금지 단어 차단 → Custom Filters ▸ Grounding: 높은 점수 요구 = 신뢰도 높은 응답만 (금융/규제 도메인의 필수 요소)

해설

【핵심 용어】 ▸ AWS Amplify AI Kit — 스트리밍 응답 최적화 전용 라이브러리 ▸ GraphQL Streaming — 부분 응답 실시간 전달 ▸ ResponseStream — 토큰 단위 응답 스트리밍 【정답 포인트】 ▸ 장시간 처리(15~45초) → 스트리밍으로 체감 지연 감소 ▸ Amplify AI Kit은 GraphQL + 스트리밍 최적화 전문 ▸ 클라이언트 렌더링 최적화로 완전 응답 대기 불필요 【오답 체크】 (B) 타임아웃 증가는 근본 해결 아님 (C) SQS는 비동기 처리로 지연 증가 (D) WebSocket은 직접 API Gateway 통합이지 GraphQL 기반 아님 【시험 포인트】 장시간 응답 = 스트리밍 + Amplify AI Kit 패턴

해설

【핵심 용어】 ▸ AWS AppConfig Agent — 실시간 구성 조회 및 즉시 전파 ▸ 환경 변수 — 배포 필요, 시간 지연 ▸ Stage Variables — 수동 업데이트 필요 【정답 포인트】 ▸ 실시간 변경 필요 → AppConfig의 자동 동기화 ▸ 수천 개 동시 요청 → 중앙 집중식 구성 관리 ▸ 시간 단위 변경 → 코드 배포 없이 AppConfig만 수정 【오답 체크】 (A) 환경 변수는 배포 필요, 즉시 전파 불가 (B) Stage 변수는 수동 업데이트 + 배포 (D) 인증자는 라우팅용이 아닌 인증용 【시험 포인트】 실시간 동적 라우팅 = AppConfig + Lambda 패턴

해설

【핵심 용어】 ▸ Bedrock Prompt Management — 프롬프트 버전 관리, 중앙 집중식 템플릿 ▸ Bedrock Guardrails — 포스트프로세싱 불필요, 모델 레벨 제어 ▸ Category Filters — 사전 정의된 필터 【정답 포인트】 ▸ 중앙 관리 → Prompt Management 필수 ▸ 포스트프로세싱 오버헤드 최소 → Guardrails로 모델 인스턴스에서 차단 ▸ 톤 조정 → 프롬프트 변형(템플릿 상속)으로 처리 【오답 체크】 (B) Guardrails의 오디언스 기반 임계값 조정은 고급 기능이지만 (A) 가 더 간단 (C/D) DynamoDB + Lambda = 유지보수 오버헤드 증가 【시험 포인트】 중앙 관리 = Prompt Management + Guardrails 패턴

해설

【핵심 용어】 ▸ OpenSearch Serverless — 벡터 검색 + 메타데이터 필터링 + 서버리스 ▸ Knowledge Bases — Bedrock의 RAG 통합 서비스 ▸ Metadata Filtering — 구조화된 데이터로 검색 범위 축소 【정답 포인트】 ▸ 1천만 임베딩 저장소 → OpenSearch Serverless 스케일링 적합 ▸ 메타데이터 필터링 필수 → OpenSearch 네이티브 지원 ▸ 운영 오버헤드 최소 → Serverless(자동 스케일) + Knowledge Bases 통합 【오답 체크】 (B) Aurora는 관리 오버헤드 증가, pgvector는 프로덕션 규모 제한 (C) S3 Vectors는 메타데이터 필터링 미지원 (D) Neptune은 그래프 DB로 벡터 검색 전문 아님 【시험 포인트】 대규모 벡터 + 메타데이터 = OpenSearch Serverless + Knowledge Bases

해설

【핵심 용어】 ▸ Hybrid Search — 벡터(의미) + 키워드(정확) 결합 검색 ▸ Vector Similarity — 의미론적 유사도 ▸ Keyword Matching — 정확 용어 매칭 【정답 포인트】 ▸ 의료 용어/약자 = 키워드 매칭 필수 ▸ 의미 이해 = 벡터 검색 보존 ▸ OpenSearch 네이티브 하이브리드 검색 지원 → 추가 인프라 불필요 【오답 체크】 (B) 임베딩 차원 증가는 의료 용어 문제 해결 안 함 (C) Kendra는 다른 검색 엔진, 마이그레이션 오버헤드 (D) SageMaker 재순위화는 지연 증가, 운영 복잡성 높음 【시험 포인트】 정확 + 의미 = 하이브리드 검색 패턴

해설

【핵심 용어】 ▸ Interface VPC Endpoint — Bedrock의 프라이빗 연결 ▸ Lake Formation LF-tag — 열 수준 세분화 접근 제어 ▸ 크로스 계정 그랜트 — 계정 간 권한 위임 【정답 포인트】 ▸ 프라이빗 연결 필수 → Interface Endpoint for Bedrock ▸ 열 수준 제어 → Lake Formation LF-tag 기반 제어 ▸ IAM 조건으로 승인된 엔드포인트만 호출 강제 【오답 체크】 (B) NAT 게이트웨이는 공개 인터넷 경유로 프라이빗 연결 아님 (C) 공개 엔드포인트 사용, 데이터베이스 수준은 열 수준 미지원 (D) IAM 경로 정책은 세분화 제어 미지원 【시험 포인트】 프라이빗 + 열 수준 = Interface Endpoint + Lake Formation LF-tag

해설

【핵심 용어】 ▸ Amazon Bedrock Prompt Management — Bedrock 자체 프롬프트 버전 관리, 승인 워크플로우, 감사 로그 통합 서비스 ▸ AWS CloudTrail — AWS 서비스의 모든 API 호출과 활동을 기록하는 감사 로깅 서비스 ▸ Parameterized Templates — 변수를 사용한 재사용 가능한 프롬프트 템플릿 【정답 포인트】 ▸ "버전 제어" + "승인 워크플로우" + "알림" + "감사 추적" → Bedrock Prompt Management가 이 모든 기능을 통합 제공 ▸ CloudTrail로 모든 프롬프트 활동의 상세한 감사 로그 자동 기록 ▸ IAM 정책으로 조직 단위 승인 권한 제어 ▸ 변수 지정으로 일관된 매개변수화 구현 【오답 체크】 (A) Bedrock Studio는 프롬프트 테스트/개발용이며, Prompt Management처럼 버전 관리, 승인 워크플로우, 자동 감사 통합 없음 (C) S3 + Step Functions + EventBridge는 수동 구축 방식이며, 운영 오버헤드가 큼. Bedrock 자체 기능 미활용 (D) SageMaker Canvas는 생성 AI가 아니라 "No-Code Analytics"용이며, 프롬프트 관리 기능 부족 【시험 포인트】 ▸ "수백 개 템플릿" + "다중 팀" + "다중 리전" → 관리형 서비스(Prompt Management) 선택 ▸ 함정: 개별 AWS 서비스들로 조합 가능하지만 "최소 운영 오버헤드" 가정 → 목적 지향 솔루션 ▸ Bedrock 플랫폼 자체의 거버넌스 기능 활용이 정답의 핵심

해설

【핵심 용어】 ▸ InvokeModelWithResponseStream — Bedrock의 스트리밍 응답 API로 토큰을 실시간으로 전달 ▸ WebSocket API — 양방향 지속적 연결로 실시간 데이터 푸시 가능 ▸ Character-by-Character Display — 스트림되는 텍스트를 문자 단위로 UI에 표시 【정답 포인트】 ▸ "문자 단위 표시" → 스트리밍 필수 → InvokeModelWithResponseStream 필수 ▸ "15~45초 응답 시간" + "수천 동시 사용자" → 폴링/캐싱 불가, 실시간 양방향 연결 필요 → WebSocket ▸ API Gateway WebSocket + Lambda + InvokeModelWithResponseStream = 완벽한 조합 【오답 체크】 (B) REST API는 단방향이고, 100ms 폴링은 네트워크 오버헤드 증가로 지연 시간 악화. 장시간 응답에 비효율적 (C) 클라이언트가 직접 Bedrock 호출 시 IAM 자격 증명 노출 위험 + API Gateway/Lambda의 속도 제한, 로깅, 보안 기능 상실 (D) DynamoDB 캐시는 응답 완료 후 저장이므로 실시간 스트리밍 불가. 페이지 매김은 문자 단위 표시 요구사항 불만족 【시험 포인트】 ▸ 스트리밍 + 실시간 표시 → 반드시 InvokeModelWithResponseStream + WebSocket 조합 ▸ REST는 "요청-응답" 패턴이고, WebSocket은 "지속 연결" 패턴 → 실시간 푸시 필요 시 WebSocket ▸ 함정: HTTP/2 Server-Sent Events 대신 WebSocket 사용 이유 = 양방향 통신과 브라우저 호환성

해설

【핵심 용어】 ▸ Bedrock Prompt Management 변수 — 필수 입력 캡처 ▸ Detect 응답 — 차단하지 않고 감지만 수행 ▸ Hate Content Filter — 괴롭힘 언어 감지 【정답 포인트】 ▸ (A) 필수 입력 4개 → 변수로 지정, 응답 형식 지정 ▸ (D) 괴롭힘 감지 → 'insults' 필터로 'detect' 응답 설정(차단 아님) ▸ Flow의 prompts 노드에 적용 【오답 체크】 (B) 'Block' 응답이면 차단되어 요구사항 미충족 (C) Prompt Router는 라우팅용이지 입력 관리 아님 (E) Inference Profile은 모델 선택용이지 입력 변수 관리 아님 【시험 포인트】 필수 입력 = 변수, 감지만 = detect 필터 응답

해설

【핵심 용어】 ▸ LLM-as-a-Judge — 전문 LLM을 사용하여 다른 모델의 출력을 평가하는 기법 ▸ Hallucination Detection — 모델이 거짓 정보를 생성하는 것을 감지 ▸ Hybrid Evaluation System — 자동화 + 인간 검토 결합 방식 【정답 포인트】 ▸ "높은 정확도" + "할루시네이션 식별" + "인간 검토 비용 줄이기" → 자동화 먼저, 필요할 때만 인간 개입 ▸ LLM-as-a-Judge로 의료 콘텐츠 품질 판정 가능 ▸ Feature Store로 평가 데이터셋 관리 및 버전 추적 ▸ Bedrock 평가로 RAG 성능(검색 정밀도, 할루시네이션) 자동 추적 【오답 체크】 (A) Comprehend는 NER(개체명 인식)은 가능하지만, 할루시네이션 감지나 의료 전문가 수준의 정확도 평가에 부족 (B) LLM-as-a-Judge만으로는 "인간 검토 비용 절감"을 충분히 달성할 수 없음. 하이브리드 방식이 필요 (C) CloudWatch Synthetics는 "알려진 답변" 기반이므로 의료 도메인의 미묘한 정확도 차이 평가 불가 【시험 포인트】 ▸ "높은 정확도" + "비용 절감" → 자동화 우선 + 타겟 인간 검토 (하이브리드 필수) ▸ RAG의 2가지 평가 축: 검색 정밀도(Retrieval Precision) + 생성 정확도(Generation Factuality) ▸ Bedrock 통합 평가 지표 활용이 시험 포인트

해설

【핵심 용어】 ▸ CRI(Cross-Region Inference) — 특정 리전의 모델을 다른 리전에서 호출 ▸ eu.amazon.nova-pro-v1:0 — EU 내 CRI 추론 프로필 ▸ SCP — 서비스 제어 정책으로 리전 제한 【정답 포인트】 ▸ (B) SCP 확장 → eu.amazon.nova-pro-v1:0 CRI 프로필에 대한 호출 허용 ▸ (D) 개발자 권한 검증 → eu-central-1뿐 아니라 모든 EU 리전의 CRI 엔드포인트 호출 가능해야 함 ▸ CRI = eu-central-1 모델을 다른 EU 리전에서 호출 가능 【오답 체크】 (A) AdministratorAccess는 SCP 우회 불가, 거버넌스 상실 (C) eu-west-3은 eu-central-1이 아님, 정책 위반 (E) eu.* 와일드카드는 범위 너무 넓음 【시험 포인트】 EU CRI = eu.amazon.nova-pro-v1:0 + 모든 EU 리전 권한

해설

【핵심 용어】 ▸ 중간 필터(Medium) — 거짓양성 최소화 ▸ Denied Topics — 투자 조언 차단 ▸ Mask/Block Actions — PII 응답 마스킹, 입력 차단 ▸ Audit Messages — 감사 로깅 【정답 포인트】 ▸ 거짓양성 최소 → 중간 필터 설정 ▸ 투자 조언 차단 → 명확한 정의/샘플 포함으로 정확도 향상 ▸ PII 처리 → 응답에서 마스킹(정보 제공), 입력에서 차단(수집 방지) ▸ 감시 로그 → 커스텀 차단 메시지 + 입력/출력 평가 활성화 【오답 체크】 (A) 높은 필터 = 거짓양성 증가 (B) 다중 guardrail chaining 복잡, 단일 guardrail 추천 (D) guardrail 4개 chaining = 운영 오버헤드 증가 【시험 포인트】 정확+유연 = 중간필터 + 명확한정의 + Mask/Block 조합

해설

【핵심 용어】 ▸ Knowledge Base — 소유 데이터로 모델 기초 제공 ▸ RAG — 생성 전 관련 문서 검색하여 환각 방지 ▸ PerformanceConfigLatency — 검색 성능 최적화 설정 【정답 포인트】 ▸ 제품 카탈로그 없음 → Knowledge Base에 카탈로그 저장 필수 ▸ 무관 추천 → RAG로 검색 기반 응답 생성 ▸ 느린 응답 → Latency 최적화 파라미터 사용 【오답 체크】 (A) Guardrails는 안전성/규정 준수용, 카탈로그 불일치 해결 미지원 (B) 프롬프트만으로는 없는 제품 추천 방지 불가 (D) OpenSearch + 수동 검증은 RAG 솔루션 아님 【시험 포인트】 카탈로그 정렬 + 지연 = Knowledge Base + RAG + Latency최적화

해설

【핵심 용어】 ▸ Bedrock AgentCore — 메모리, 세션, ID, 이벤트 처리 통합 ▸ 액션 등록 — API Gateway/EventBridge를 통한 선언형 통합 ▸ 커스텀 오케스트레이션 제거 — 확장성 향상 【정답 포인트】 ▸ (A) AgentCore = 메모리+세션+ID+이벤트 처리 전담 ▸ (B) AgentCore가 Lambda/REST API를 액션으로 자동 호출, 오케스트레이션 코드 불필요 ▸ 확장성 = 선언형 구성 + 서버리스 【오답 체크】 (C) Step Functions + DynamoDB는 커스텀 오케스트레이션 = 확장 제한 (D) ECS는 관리 오버헤드 증가 (E) RAG 파이프라인은 에이전트 솔루션 아님 【시험 포인트】 확장성 = AgentCore(메모리+세션) + 액션 등록(자동 호출)

해설

【핵심 용어】 ▸ Graph RAG — 그래프 구조로 다중 홉 관계 자동 추적 ▸ Neptune Analytics — 고성능 그래프 쿼리 엔진 ▸ 다중 홉 관계 — 간접 관계 파악 【정답 포인트】 ▸ 다중 홉 관계 필수 → 그래프 기반 모델링 필수 ▸ Graph RAG → Bedrock Knowledge Bases + Neptune으로 통합 ▸ 자동 관계 식별 → 수동 매핑 제거, 3초 응답 달성 【오답 체크】 (B) 순차적 벡터 쿼리는 다중 홉 관계 추적 제한 (C) 수동 관계 매핑 = 운영 오버헤드 증가 (D) DynamoDB는 관계 쿼리 전문 아님 【시험 포인트】 다중 홉 관계 = Graph RAG + Neptune Analytics

해설

【핵심 용어】 ▸ Bedrock Guardrails Contextual Grounding — 환각 감지 전문 ▸ CloudWatch Anomaly Detection — 실시간 이상 탐지 ▸ 모델 호출 로그 → 감시 기반 【정답 포인트】 ▸ 환각 감지 → Guardrails contextual grounding 체크(내장 기능) ▸ 토큰 사용 이상 → CloudWatch 이상 감지 알람 ▸ 최소 개발 → Bedrock 내장 기능 조합 【오답 체크】 (A) Glue/Athena는 배치 처리, 실시간 모니터링 미지원 (B) 평가 작업은 정기적 실행, 실시간 성능 저하 (D) QuickSight/SageMaker는 추가 개발 필요 【시험 포인트】 환각+비용 모니터링 = Guardrails grounding + CloudWatch 이상 감지

해설

【핵심 용어】 ▸ AWS Glue Data Catalog — 데이터 소스 중앙 등록, 메타데이터 관리 ▸ Metadata Tags — 출처 속성 부여 ▸ CloudTrail — 전 서비스 접근/활동 감시 【정답 포인트】 ▸ 데이터 소스 등록 → Glue Data Catalog 통합 카탈로그 ▸ 메타데이터 태깅 → Glue의 태그 기능으로 출처 명확화 ▸ 전체 감시 → CloudTrail이 모든 AWS 서비스 API 호출 기록 【오답 체크】 (A) Lake Formation은 접근 제어 전담, 등록용이 아님 (B) CloudWatch Logs는 애플리케이션만 기록, 서비스 간 활동 미포함 (C) S3 객체 태깅은 저수준, Glue Catalog 메타데이터와 비교 확장성 낮음 【시험 포인트】 추적성 = Glue Catalog(등록+태깅) + CloudTrail(전체 감시)

해설

【핵심 용어】 Amazon Bedrock 【정답 포인트】 정답: B 이 문제는 Amazon Bedrock을 사용하는 금융 문서 분석 시스템에서 처리 속도 개선이 핵심입니다. Step Functions의 Parallel 상태를 활용하면 재무 데이터 분석, 감정 분석, 규정 준수 검증을 동시에 실행할 수 있습니다. 45초 소요되던 순차 처리를 병렬 실행으로 10초 이내로 단축 가능합니다. 각 Lambda 함수가 독립적으로 Bedrock을 호출하여 최대 병렬성을 확보하고, CloudWatch 메트릭으로 실행 시간과 모델 추론 지연 시간을 실시간 모니터링합니다. Bedrock 클라이언트 타임아웃 구성으로 장시간 실행 오류를 사전 방지합니다. 【오답 체크】 A: 순차 처리로 병렬화 이점 상실 | C: SQS 순차 처리로 시간 요구사항 미충족 【시험 포인트】 AWS AIP-C01 시험에서 정답 B는 AWS 베스트 프랙티스를 반영합니다. 이 문제는 실제 운영 환경의 복잡한 요구사항을 효율적으로 해결하는 아키텍처 설계 능력을 평가합니다. 정답 선택 시 다른 선택지의 구체적 제한사항을 명확히 구분하고, 성능, 보안, 비용, 운영성 측면에서 종합적으로 검토하는 능력이 필수입니다. AWS 서비스의 기능과 제약을 정확히 이해하고, 요구사항 전체를 만족하는지 체계적으로 검증하세요.