정답 · 해설

해설

【핵심 용어】 SCP · 권한 경계 · Bedrock 보안정책 · 조직 수준 거버넌스 【정답 포인트】 AWS Organizations 환경에서 다중 계정 거버넌스를 달성하려면 B와 D의 조합이 필수입니다. B의 SCP는 조직 수준에서 모든 계정의 모든 주체가 보안정책 식별자를 명시적으로 지정하도록 강제하는 상한선(ceiling)을 설정합니다. D의 CloudFormation Stack Sets를 통한 차단 필터링 보안정책 배포는 각 계정 수준에서 구체적인 콘텐츠 필터링을 실행합니다. 이는 조직 전체의 일관된 정책 시행(organization-wide enforcement)을 가능하게 하며, 특정 주제와 독점 정보 누출을 원천적으로 방지합니다. 【오답 체크】 A(권한 경계 + SCP): 보안정책 배포 메커니즘 부재로 실제 필터링 기능 불가능 C(권한 경계): SCP의 긍정적 권한 위임이 아닌 경계 설정만으로는 조직 수준 강제 불완전 E(마스킹): 요구사항의 '방지'는 마스킹보다 차단(block)이 더 적절 【시험 포인트】 조직 수준 정책 + 콘텐츠 필터링 다중 선택 문제는 SCP(강제) + Stack Sets(배포)의 조합을 선택하세요.

해설

【핵심 용어】 Lambda 응답 스트리밍 · HTTP API · 토큰 제한 · 운영 오버헤드 【정답 포인트】 생성 AI API의 운영 오버헤드를 최소화하면서 스트리밍, 토큰 관리, 재시도를 모두 구현하려면 A가 최적입니다. HTTP API는 REST API 대비 20% 저가이고 더 빠른 응답 성능을 제공합니다. Lambda 응답 스트리밍(response streaming)은 Bedrock의 InvokeModelWithResponseStream API를 활용하여 진정한 스트리밍 응답을 구현하며, 클라이언트는 전체 응답을 기다리지 않고 즉시 결과를 수신합니다. Lambda 함수 내 토큰 제한은 요청 전에 프롬프트 길이를 검증하여 초과 비용을 방지합니다. API Gateway와 Lambda의 타임아웃 조합은 자동 재시도 메커니즘을 제공합니다. 【오답 체크】 B(직접 연결): 클라이언트 폴링은 실제 스트리밍 아님, 프론트엔드 토큰 제한은 보안 취약점 C(ECS + WebSocket): 컨테이너 관리 오버헤드가 크고 Bedrock 직접 사용보다 복잡도 증가 D(REST API): Lambda 로직은 A와 동일하나 REST API의 추가 오버헤드 발생 【시험 포인트】 'LEAST operational overhead' 키워드는 관리형 서비스(Lambda, HTTP API) > 자체 관리형(ECS, EC2) 우선 선택을 의미합니다.

해설

【핵심 용어】 메모리 관리 · 컨텍스트 길이 · 프롬프트 최적화 · 토큰 카운팅 · 동적 조정 【정답 포인트】 Amazon Bedrock으로 장문의 문서를 처리할 때 메모리 효율성과 생성 품질을 동시에 달성하려면 적응형 청킹과 동적 프롬프트 구성이 필수입니다. 문서를 논리적 단위로 분할하고 각 세그먼트의 관련성을 평가하여 맥락에 맞는 정보만 모델에 제공합니다. 이 방식은 모델의 효과적 컨텍스트 창 활용을 최대화하고 할루시네이션 위험을 감소시킵니다. 토큰 개수를 사전 계산하고 동적으로 조정하면 API 호출 비용을 예측 가능하게 만들고 예산 초과를 방지합니다. Amazon Bedrock의 토큰 카운팅 API는 이러한 최적화의 핵심 도구입니다. 【오답 체크】 단순 고정 크기 청킹은 의미론적 경계를 무시하여 정보 단절을 야기하고, 전체 문서 메모리 로드는 서버 리소스 고갈의 위험을 증가시키며, 프롬프트 최적화 없는 구현은 낭비적 토큰 사용을 계속하게 됩니다. 【시험 포인트】 문서 처리 시 '메모리', '효율성', '동적' 키워드가 나오면 적응형 청킹 + 동적 구성을 선택하는 것이 정답입니다.

해설

【핵심 용어】 파인튜닝 · 전이 학습 · 도메인 특화 · 데이터셋 규모 · 비용-성능 트레이드오프 【정답 포인트】 특정 도메인 작업의 성능을 최적화하려면 기초 모델 크기와 파인튜닝 데이터셋 규모의 균형을 맞추는 것이 중요합니다. 소규모이지만 고품질의 파인튜닝 데이터(500~1000개 예제)는 대규모 기초 모델에서도 의미 있는 성능 개선을 가져오며, 이는 파인튜닝 데이터가 모델 가중치 조정에 미치는 강력한 영향을 입증합니다. 비용-성능 트레이드오프 분석을 통해 충분한 성능을 제공하는 최소 모델 크기를 선택하면 운영 비용을 절감하면서도 목표 품질을 유지할 수 있습니다. Amazon Bedrock의 파인튜닝 기능은 모델 크기별 성능 곡선 분석을 지원하여 최적 선택을 가능하게 합니다. 【오답 체크】 과도한 파인튜닝 데이터는 오버피팅 위험을 증가시켜 일반화 성능을 저하시키고, 기초 모델만 사용하면 도메인 특화 성능이 부족하며, 가장 큰 모델 선택은 리소스 비용을 낭비합니다. 【시험 포인트】 파인튜닝 문제에서 데이터셋 크기와 모델 크기의 최적 조합을 찾는 것이 AIP-C01의 핵심 개념입니다.

해설

【핵심 용어】 ▸ Data Residency — 데이터가 특정 지역 내에서만 처리 및 저장되어야 한다는 규정 ▸ Object Lock — S3 객체의 변경 불가능성을 보장하는 기능 ▸ Amazon Macie — ML 기반 데이터 분류 및 민감 정보 탐지 서비스 【정답 포인트】 ▸ 지역 내 전처리 → 데이터가 처리 지역 외로 이동하지 않음 ▸ S3 Object Lock + 버킷 정책 → 상주 규칙 강제 및 변경 불가능성 보장 ▸ Amazon Macie → 자동 데이터 분류로 민감 정보 관리 ▸ CloudTrail → 감시 추적으로 규제 규정 준수 【오답 체크】 (A) 교차 지역 추론(cross-region inference)은 데이터 상주 규칙 위반 가능. 지역 간 데이터 이동으로 EU GDPR 등 규정 불준수 (B) 사용자 정의 모델 배포는 구현 복잡도 높음. Macie 분류 기능 미포함으로 자동 분류 불가능 (D) 수동 보고서는 자동화 부재로 대규모 일일 수백만 데이터 포인트 처리 시 확장성 떨어짐 【시험 포인트】 ▸ Bedrock 기반 GenAI + 지역 제약 → S3 버킷 정책으로 지역별 격리 ▸ PII 포함 데이터 → Macie의 자동 분류가 핵심 기능 ▸ 감시 추적 → CloudTrail 변경 불가능 로그가 감시의 표준

해설

【핵심 용어】 벡터 임베딩 · 의미론적 검색 · 임베딩 모델 선택 · 검색 파라미터 최적화 【정답 포인트】 RAG(Retrieval Augmented Generation) 시스템의 검색 성능은 임베딩 모델의 선택에 매우 크게 영향을 받습니다. 도메인 특화 임베딩 모델은 일반 목적 모델과 비교하여 관련 문서 검색에서 현저히 높은 정확도를 제공합니다. 의료, 금융, 법률 등 특정 분야의 전문 용어와 개념을 더 정확하게 표현하는 임베딩이 유사도 계산의 정확성을 대폭 향상시킵니다. 벡터 데이터베이스의 인덱싱 전략(HNSW, IVF 등)과 검색 파라미터(top-k, 유사도 임계값) 세밀한 최적화는 검색 성능과 응답 속도의 최적 균형을 맞춥니다. Amazon Bedrock Knowledge Base는 최적화된 임베딩 및 검색 기능을 제공합니다. 【오답 체크】 잘못된 임베딩 모델은 의미론적 검색 정확도를 급락시키고, 과도한 차원 축소는 의미 있는 정보 손실을 야기하며, 검색 파라미터 미조정은 검색 품질과 속도 간 심각한 불균형을 초래합니다. 【시험 포인트】 RAG 검색 성능 문제에서 임베딩 모델 선택 및 최적화가 최우선 고려사항입니다.

해설

【핵심 용어】 ▸ LF-Tag Expression — Lake Formation의 태그 기반 세분화 접근 제어 메커니즘 ▸ Data Governance — 데이터 액세스 및 사용 정책의 중앙화 관리 ▸ PII Redaction — 민감 정보 열을 선택적으로 제외하여 보호 【정답 포인트】 ▸ LF-Tag 기반 권한 → 비즈니스 단위·지역을 태그로 분류하여 세분화 제어 ▸ IAM 역할 인증 + LF-Tag 표현식 → 특정 데이터만 FM 접근 가능 ▸ 열 수준 필터링 → PII 포함 열을 제외하도록 LF-Tag 표현식 구성 ▸ CloudTrail → 모든 데이터 액세스 기록으로 감시 추적 완성 【오답 체크】 (A) S3 버킷 단위 분리는 비즈니스 단위별로 버킷 폭증(수백 개). PII 제거 메커니즘 없음 (C) 사용자 정의 애플리케이션 계층은 유지보수 부담 증가. PII 노출 위험이 높음(수동 필터링) (D) Presigned URL은 세분화된 제어 불가능. 행/열 단위 접근 제어 미지원 【시험 포인트】 ▸ Lake Formation 거버넌스 → LF-Tag가 중앙화 접근 제어의 핵심 ▸ 다중 비즈니스 단위 + 다중 지역 → 태그 조합으로 확장성 우수 ▸ FM의 민감 데이터 접근 → 열 수준 LF-Tag 표현식이 AIP-C01 출제 핵심

해설

【핵심 용어】 비용 최적화 · 토큰 기반 청구 · 배치 처리 · 동시성 제한 · 예산 제어 · 비용 모니터링 【정답 포인트】 생성 AI 비용을 효율적으로 관리하려면 세 가지 전략의 유기적 조합이 필수적입니다. 첫째, 프롬프트 최적화로 불필요한 토큰 사용을 최소화하여 기본 비용 구조를 절감합니다. 둘째, 배치 처리를 통해 대량의 요청을 비피크 시간에 한꺼번에 처리하여 할인 효과를 최대한 활용합니다. 셋째, 동시성 제한을 설정하여 비용 초과를 원천적으로 방지하면서도 응답 성능을 적절히 유지합니다. Amazon Bedrock의 비용 모니터링 기능과 AWS Budgets 구성은 예산 관리의 핵심 도구입니다. 이 세 계층의 통합 비용 제어를 통해 예산 가시성을 확보하고 투자 수익률을 극대화할 수 있습니다. 【오답 체크】 프롬프트 최적화 없이는 낭비적 토큰 사용이 계속 발생하며, 배치 처리를 미사용하면 할인 기회를 상실하고, 동시성 제한을 미설정하면 예산 초과 위험을 방치하게 됩니다. 【시험 포인트】 비용 최적화 문제는 항상 다층 최적화(프롬프트, 배치, 동시성) 관점에서 접근하는 것이 AIP-C01 정답입니다.

해설

【핵심 용어】 모니터링 · 성능 메트릭 · 데이터 드리프트 · 자동 알람 · 프로덕션 안정성 · 조기 감지 【정답 포인트】 프로덕션 환경의 생성 AI 모델은 지속적이고 자동화된 성능 모니터링을 요구합니다. 입력 데이터 분포의 변화(data drift)는 모델 성능 저하의 주요 원인이며, 조기 감지를 통해 모델 재학습 또는 재배포의 필요성을 과학적으로 결정할 수 있습니다. 응답 지연도, 에러율, 토큰 사용 통계를 실시간으로 추적하고 임계값 초과 시 자동 알림을 구성하면 문제를 신속하게 해결할 수 있습니다. AWS CloudWatch와 Amazon SageMaker Model Monitor는 프로덕션 생성 AI 모니터링의 핵심 도구입니다. 이러한 자동 감시 시스템은 SLA 위반을 선제적으로 방지합니다. 【오답 체크】 모니터링 부재 시 성능 저하를 사후에만 발견하게 되고, 수동 모니터링은 대규모 시스템에서 비효율적이며, 알람 미구성은 SLA 위반 위험을 크게 증가시킵니다. 【시험 포인트】 프로덕션 시스템은 항상 자동 모니터링과 알람 구성을 필수 요소로 간주하는 것이 정답입니다.

해설

【핵심 용어】 모델 선택 · 레이턴시-정확도 트레이드오프 · 비용 고려 · 벤치마크 테스트 · 성능 측정 · 비용 효율 【정답 포인트】 적절한 기초 모델 선택은 비용, 성능, 레이턴시 간 복잡한 삼각형 최적화 문제입니다. 실시간 대화형 애플리케이션(챗봇, 검색 등)은 작은 모델의 빠른 응답 시간을 우선하고, 정확도가 극도로 중요한 작업(데이터 분석, 의료 의사결정 지원 등)은 대형 모델의 높은 품질을 요구합니다. 벤치마크 테스트를 통해 구체적인 실제 작업 환경에서의 성능을 측정하고 비용 대비 효과를 평가하여 최적 모델을 과학적으로 선택합니다. 단일 모델보다는 작업별 다중 모델 활용이 비용 효율적일 수 있습니다. Amazon Bedrock은 다양한 기초 모델 간 성능 비교 기능을 제공합니다. 【오답 체크】 일반적 벤치마크만으로는 특정 도메인 성능 예측이 부정확하고, 가장 큰 모델 선택이 항상 최적은 아니며, 비용을 무시한 선택은 예산 초과로 직결됩니다. 【시험 포인트】 모델 선택 문제에서는 구체적 작업 특성에 맞춘 벤치마크 기반 선택을 강조하는 것이 AIP-C01 정답입니다.

해설

【핵심 용어】 ▸ Guardrail — Amazon Bedrock의 응답 필터링 정책으로 PII 노출 방지 ▸ Mask Mode — PII를 감지하면 마스킹하여 시스템은 동작하되 민감 정보 보호 ▸ Block Mode — PII가 감지되면 응답을 완전 차단 【정답 포인트】 ▸ 민감 정보 필터 적용 → guardrail의 기본 기능 ▸ Mask Mode(개발/테스트) → PII를 감지하면서도 시스템 작동 확인(평가 가능) ▸ Block Mode(프로덕션) → 최종 환경에서 PII 노출 완전 방지 ▸ 지역별 배포 → 각 지역에 guardrail 사본으로 데이터 상주 준수 【오답 체크】 (A) Cross-Region guardrail은 데이터 상주 규칙 위반(지역 간 호출 교차) (C) Detect Mode만으로는 보호 안 됨(PII 노출 감지만 함). 로깅 비활성화는 감시 추적 상실 (D) Mask Mode를 프로덕션에서 사용하면 PII가 마스킹되어 실제 데이터 손실. 차단 모드 필요 【시험 포인트】 ▸ GuardRail 모드 선택 → Mask(개발/테스트) vs Block(프로덕션)의 의도 파악 중요 ▸ 데이터 상주 + PII 보호 → 지역별 guardrail 배포가 이중 요구사항 충족 ▸ PII 평가 단계 → Mask Mode로 시스템 동작 확인 후 프로덕션 전환

해설

【핵심 용어】 자동화 · AWS Step Functions · 오류 처리 · 재시도 정책 · 폴백 메커니즘 · 신뢰성 · 조정 가능성 【정답 포인트】 생성 AI 워크플로우의 자동화는 AWS Step Functions를 통해 선언적으로 구현되며, 순차 처리, 병렬 처리, 조건 분기 로직 등 복잡한 워크플로우를 명확하고 유지보수하기 쉽게 표현할 수 있습니다. 각 단계별로 세밀한 오류 처리 로직(자동 재시도, 예외 캐치, 폴백 실행)을 정의하면 일시적 오류에 자동으로 대응합니다. 최종 실패 시 폴백 메커니즘을 활용하여 서비스 연속성을 보장할 수 있습니다. 상태 머신 정의를 통한 선언적 접근은 복잡한 비즈니스 로직을 명확하게 표현하고 운영 유지보수성을 극대화합니다. 이러한 기법은 엔터프라이즈 수준의 높은 신뢰성을 확보합니다. 【오답 체크】 수동 워크플로우는 확장성이 부족하고 인적 오류 가능성을 증가시키며, 오류 처리 로직 부재 시 부분 실패에 취약한 결과를 초래합니다. 【시험 포인트】 엔터프라이즈 워크플로우 자동화는 Step Functions와 체계적 오류 처리가 필수 요소입니다.

해설

【핵심 용어】 규정 준수 · 데이터 보호 · 감사 추적 · 자동 정책 시행 · 컴플라이언스 · 법적 요구사항 · 위험 관리 【정답 포인트】 규제 산업(의료 HIPAA, 금융 PCI-DSS, 개인정보 GDPR)의 생성 AI 도입은 엄격한 규정 준수를 법적으로 요구합니다. AWS CloudTrail과 AWS Config를 통한 자동화된 감시는 모든 시스템 변경을 시간 순서대로 기록하고 정책 위반을 실시간으로 감지합니다. 데이터 암호화(전송 중/저장 시), 세밀한 접근 제어(IAM), 완전한 감사 로그 유지(CloudTrail)는 규제 기관의 감시에 대응하는 필수 기술 요소입니다. 자동화된 규정 준수 검증은 수동 감시의 오류 가능성을 완전히 제거하고 규제 위험을 최소화합니다. 이는 법적 책임을 보호합니다. 【오답 체크】 규정 준수를 기술적 구현 없이 절차와 정책만으로 달성할 수 없으며, 감시 메커니즘 부재 시 위반 사실의 증명이 극히 어렵고, 수동 감시는 누락 위험이 높습니다. 【시험 포인트】 규정 준수 문제는 자동 감시 + 정책 기반 제어 조합을 필수로 선택하는 것이 정답입니다.

해설

【핵심 용어】 성능 튜닝 · 캐싱 기법 · 병렬화 처리 · 리소스 최적화 · 처리량 향상 · 응답 가속화 · 효율성 【정답 포인트】 대규모 생성 AI 워크로드 처리는 포괄적인 다층 성능 최적화를 요구합니다. 첫째, 캐싱은 반복되는 계산과 API 호출을 제거하여 응답 속도를 극적으로 단축시킵니다. 둘째, 병렬 처리(멀티스레드, 분산 처리)는 처리량을 선형적으로 증대시키고 개별 요청의 지연도를 유의미하게 감소시킵니다. 셋째, GPU/가속기 활용과 배치 크기 동적 조정은 하드웨어 리소스 활용 효율을 극대화합니다. 이 세 가지 전략의 조화로운 적용을 통해 성능 목표를 달성할 수 있습니다. Amazon SageMaker와 Amazon EC2 인스턴스는 성능 최적화를 위한 다양한 기능을 제공합니다. 【오답 체크】 순차 처리만으로는 처리량 한계에 신속히 도달하고, 캐싱 전략 부재 시 불필요한 재계산이 반복되며, 리소스 미최적화는 비용 증가와 성능 저하로 이어집니다. 【시험 포인트】 성능 튜닝 문제는 캐싱 + 병렬화 + 리소스 최적화의 3단계 통합 접근을 사용하는 것이 정답입니다.

해설

【핵심 용어】 시스템 통합 · API 설계 · 데이터 포맷 표준화 · 상호운용성 · 버전 관리 · 스키마 정의 · 하위 호환성 【정답 포인트】 이기종 시스템과의 생성 AI 통합은 표준 API와 일관된 데이터 포맷 준수가 필수적입니다. RESTful API는 간단하고 광범위하게 지원되어 가장 범용적인 통합 방식이며, GraphQL은 클라이언트가 필요한 필드만 선택하여 효율적인 유연한 쿼리를 가능하게 합니다. JSON 기반 데이터 교환과 명확한 스키마 정의(OpenAPI/Swagger)는 시스템 간 상호운용성을 보장하고 통합 오류를 최소화합니다. API 버전 관리와 하위 호환성 유지는 지속적인 서비스 개선을 가능하게 합니다. 이러한 표준은 장기적 통합 안정성을 보장하고 유지보수 비용을 절감합니다. 【오답 체크】 프로토콜 불일치는 통합 복잡도를 급증시키고, 스키마 미정의로 인한 데이터 변환 오류가 발생하며, API 버전 미관리는 호환성 문제를 야기합니다. 【시험 포인트】 시스템 통합 문제에서는 표준 API + 명확한 스키마 + 버전 관리 조합을 선택하는 것이 정답입니다.

해설

【핵심 용어】 ▸ Inference Profiles — Amazon Bedrock의 교차 지역 추론 최적화 기능 ▸ eu.amazon.* Endpoint — 유럽 내 모든 호출을 유럽 내에서만 처리하는 엔드포인트 ▸ SCP Constraint — AWS Organizations의 Service Control Policy로 지역 사용 제한 【정답 포인트】 ▸ Inference Profiles → eu-central-1, eu-west-3의 모델을 eu-north-1에서 액세스 ▸ eu.amazon.* 엔드포인트 → 모든 호출이 유럽 경계 내에서 유지 ▸ VPC Endpoint → Amazon Bedrock으로의 요청을 프라이빗 네트워크로 한정 ▸ SCP 확장 → inference profile 사용 권한 부여로 기존 제약 준수 【오답 체크】 (A) Lambda 래핑은 불필요한 복잡도 추가. 호출 간 레이턴시 증가 (B) EC2 자체 관리는 오버헤드 큼. SCP 제약(eu-north-1, eu-west-1만)을 우회 불가능 (D) SageMaker는 eu-north-1 호스팅만 가능. eu-central-1, eu-west-3 모델 활용 불가 【시험 포인트】 ▸ 지역 제약 + 호스팅 지역 불일치 → Inference Profiles로 우아하게 해결 ▸ Private Network 유지 → VPC Endpoint + eu.amazon.* 엔드포인트 조합 ▸ Bedrock 최신 기능 → AIP-C01에서 Inference Profiles 강조 증가 중

해설

【핵심 용어】 확장성 · 마이크로서비스 아키텍처 · 분산 처리 · 로드 밸런싱 · 오토스케일링 · 장애 격리 【정답 포인트】 대규모 생성 AI 워크로드의 확장성은 마이크로서비스 아키텍처와 분산 처리를 기초로 설계되어야 합니다. 로드 밸런싱을 통한 적절한 요청 분산은 단일 서버의 과부하를 효과적으로 방지하고 가용성을 현저히 향상시킵니다. 오토스케일링은 시간대별 트래픽 변동에 자동으로 대응하여 리소스 활용도를 최적화합니다. 상태 비저장(stateless) 설계는 인스턴스 간 요청 라우팅을 유연하게 하고 장애 격리(fault isolation)를 가능하게 하여 부분 장애가 전체 시스템으로 확대되는 것을 원천적으로 방지합니다. AWS Auto Scaling과 Elastic Load Balancing은 이러한 확장성을 극대화합니다. 【오답 체크】 모놀리식 아키텍처는 확장성 한계에 신속히 도달하고, 수동 확장은 트래픽 급증에 대응할 수 없으며, 상태 저장 설계는 장애 파급을 증가시킵니다. 【시험 포인트】 확장성 문제는 마이크로서비스 + 오토스케일링 조합을 선택하는 것이 정답입니다.