정답 · 해설

해설

【핵심 용어】 ▸ AWS Services 【정답 포인트】 ▸ 정답: D ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (D) Amazon Q Developer 커스터마이제이션을 생성하고 승인된 데이터 소스를 포함합니다. 개발자들이 이 커스터마이제이션을 사용하여 애플리케... 【오답 체크】 (A) 승인된 내부 라이브러리, 알고리즘, 코드 샘플을 모두 포함하는 Git 리포지토리를 생성합니다. 이 Git 리포지토리를 워크스페... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (B) 프로젝트 루트 폴더에 .amazonq/rules라는 폴더를 생성합니다. 승인된 내부 라이브러리, 알고리즘, 코드 샘플을 폴더에... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (C) 애플리케이션 프로젝트에 rules라는 폴더를 생성합니다. Amazon Q Developer가 참조할 수 있도록 폴더에 지침과 ... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ AWS Lambda, Amazon Bedrock, Amazon DynamoDB 【정답 포인트】 ▸ 정답: A ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (A) 성능 구성의 지연시간 매개변수를 최적화로 설정하여 지연시간 최적화된 추론을 구성합니다. 반복되는 문의를 처리하기 위해 프롬프트 캐싱을 사용합니다... 【오답 체크】 (B) 피크 트래픽을 처리할 수 있도록 크기 조정된 프로비저닝된 처리량 및 모델 유닛(MU)을 구매합니다. 반복 문의를 캐시하기 위해... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (C) Amazon Bedrock Agents 및 사용자 정의 지식 기반을 사용하여 고객 문의를 전처리합니다. 트래픽을 분산하기 위해... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) AWS Lambda 함수를 사용하여 사용자 정의 프롬프트 라우팅 메커니즘으로 요청을 전처리합니다. 자주 묻는 질문을 처리하기 ... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ Amazon Bedrock, Amazon DynamoDB, Amazon OpenSearch Service, Amazon S3, Retrieval Augmented Generation 【정답 포인트】 ▸ 정답: C ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (C) 청킹 전략을 고정 토큰 제한 대신 완전한 법적 주장, 조항 또는 섹션과 같은 의미론적 경계를 사용하도록 업데이트합니다. 새로운 청크 구조에 맞추... 【오답 체크】 (A) 기존 청킹 또는 전처리 전략을 변경하지 않고 임베딩 벡터 차원을 768에서 4,096으로 증가시킵니다.... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (B) 동적 검색을 사전 작성된 정적 요약으로 바꿉니다. Amazon S3에 요약을 저장하고 Amazon CloudFront를 사용하... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) OpenSearch Service에서 Amazon DynamoDB로 마이그레이션합니다. 법적 개념의 빠른 조회를 위해 키워드 ... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ AWS API Gateway, AWS Lambda, AWS Step Functions, Amazon Bedrock, Amazon DynamoDB, Amazon S3 【정답 포인트】 ▸ 정답: B ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (B) AWS Step Functions Standard 워크플로우를 사용하여 명확화 워크플로우를 조율합니다. 워크플로우를 관리하기 위해 콜백 대기 패... 【오답 체크】 (A) AWS Step Functions Express 워크플로우를 사용하여 대화 흐름을 조율합니다. 명확화 로직을 실행하기 위해 A... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (C) Amazon API Gateway REST API를 배포하여 사용자 요청을 AWS Lambda 함수로 라우팅하고 대화 문맥을 ... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) AWS Lambda 함수를 사용하여 Amazon Bedrock 추론 API를 호출합니다. 명확화 단계를 조율하기 위해 Amaz... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ AWS Lambda, AWS Step Functions, Amazon Bedrock, Amazon CloudWatch, Amazon Comprehend, Amazon S3, Amazon SageMaker 【정답 포인트】 ▸ 정답: B ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (B) AWS Glue 크롤러를 설정하여 데이터 소스를 카탈로그합니다. 사용자 정의 변환 스크립트를 실행하기 위해 AWS Glue ETL 작업을 생성합... 【오답 체크】 (A) Amazon SageMaker Data Wrangler를 사용하여 데이터 흐름을 생성합니다. Amazon CloudWatch ... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (C) Amazon Comprehend를 사용하여 엔티티를 추출합니다. 텍스트를 청킹하기 위해 AWS Lambda 함수를 생성합니다.... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) 데이터 전처리 작업을 조율하기 위해 AWS Step Functions 워크플로우를 생성합니다. Amazon EC2 인스턴스에서... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ Amazon Bedrock, Amazon OpenSearch Service, Amazon S3, Retrieval Augmented Generation 【정답 포인트】 ▸ 정답: C ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (C) Amazon Bedrock 지식 기반 내에서 S3 객체 메타데이터를 인덱싱하여 메타데이터 인식 필터링을 활성화합니다.... 【오답 체크】 (A) 벡터 유사도 개선을 위해 긴급 뉴스 콘텐츠에 특별히 훈련된 도메인 적응 모델을 사용하여 임베딩을 향상시킵니다.... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (B) Amazon OpenSearch Service로 마이그레이션합니다. 벡터 필드와 메타데이터 필터를 사용하여 결과 검색 범위를 ... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) Amazon Q Business 인덱스로 마이그레이션하여 검색 중 구조화된 메타데이터 필터링과 문서 분류를 수행합니다.... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ Amazon Bedrock, PostgreSQL, Retrieval Augmented Generation 【정답 포인트】 ▸ 정답: A ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (A) Amazon MemoryDB 클러스터를 시작하고 Flat 알고리즘을 사용하여 인덱스를 구성합니다. 성능 메트릭을 기반으로 수평 확장 정책을 구성... 【오답 체크】 (B) Amazon MemoryDB 클러스터를 시작하고 계층적 탐색 가능한 작은 세계(HNSW) 알고리즘을 사용하여 인덱스를 구성합니... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (C) Amazon Aurora PostgreSQL 클러스터를 시작하고 Inverted File with Flat Compressio... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) Inverted File with Flat Compression(IVFFlat) 인덱스와 높은 probe 값을 가진 Amazo... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ AWS Lambda, AWS Step Functions, Amazon Bedrock, Amazon Comprehend, Amazon OpenSearch Service, Amazon S3, Amazon SageMaker, PostgreSQL, Retrieval Augmented Generation, pgvector 【정답 포인트】 ▸ 정답: D ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (D) AWS Step Functions를 사용하여 Amazon Comprehend로 PII를 감지하고 Amazon Bedrock으로 임베딩을 생성하는... 【오답 체크】 (A) AWS Lambda와 Amazon Comprehend를 사용하여 파일을 병렬로 처리하고 PII를 제거하며 Amazon Bedr... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (B) AWS Glue ETL 작업을 생성하여 데이터에 대해 PII 감지 스크립트를 실행합니다. Amazon SageMaker Pro... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (C) Apache Spark와 사용자 정의 함수(UDF)를 실행하는 Amazon EMR 클러스터를 배포하여 Amazon Compre... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ AWS API Gateway, AWS Lambda, Amazon CloudWatch, Amazon DynamoDB, Amazon EventBridge 【정답 포인트】 ▸ 정답: C ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (C) AWS AppConfig를 사용하여 모델 구성을 관리합니다. A/B 테스트를 수행하기 위해 기능 플래그를 사용합니다. 모델 매개변수에 대해 JS... 【오답 체크】 (A) AWS Systems Manager Parameter Store에 각 구성에 대한 매개변수를 생성합니다. Lambda 함수를 ... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (B) Amazon DynamoDB 테이블에 모델 구성을 저장합니다. 고객 등급에 따라 구성을 검색하는 접근 패턴을 최적화합니다. L... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) 모델 구성을 저장하기 위해 Amazon ElastiCache(Redis OSS) 클러스터를 생성합니다. 짧은 TTL 값을 설정... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ AWS Lambda, Amazon Bedrock, Amazon S3 【정답 포인트】 ▸ 정답: B ▸ 요구사항 충족: 최소 운영 오버헤드, 확장성, 성능 기준 ▸ 솔루션들: ▸ (B) 토큰 배칭을 구현하여 API 오버헤드를 줄입니다. 교차 지역 추론 프로필을 사용하여 사용 가능한 지역 전체에 트래픽을 자동으로 분산합니다.... 【오답 체크】 (A) 단일 지역에서 프로비저닝된 처리량과 충분한 모델 유닛(MU)을 구매합니다. 실패한 요청을 지수 백오프로 다시 시도하도록 애플리... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (C) 각 지역에서 AWS Lambda 함수를 자동 확장하도록 설정합니다. 클라이언트 측 라운드로빈 요청 분산을 구현합니다. 백업으로... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 (D) 모든 요청에 대해 Amazon S3 버킷을 사용하여 배치 추론을 구현합니다. 여러 지역에서 Amazon SQS를 사용하여 비동... ▸ 제한사항: 구현 복잡도, 운영 오버헤드, 또는 요구사항 부분 충족 【시험 포인트】 ▸ 패턴: AWS AI 서비스 통합 및 확장 가능 아키텍처 설계 ▸ 핵심: 요구사항 대비 최소 운영 오버헤드 솔루션 선택 ▸ 검증: 성능, 비용, 보안, 관찰성 측면의 종합 검토 ▸ 주의: 각 서비스의 기능, 제약, 통합 방식 정확히 이해

해설

【핵심 용어】 ▸ 시맨틱 캐싱(semantic caching) — 임베딩 유사도로 의미가 같은 질의를 매칭해 중복 모델 호출 감소 ▸ OpenSearch k-NN — 벡터 임베딩 근사 최근접(approximate k-NN) 검색으로 저지연 유사 질의 조회 ▸ 표현만 다른 동일 질문(40%) — 의미 기반 검색으로 일관 응답 제공 【정답 포인트】 ▸ "다양한 표현의 동일 질문 + 중복 호출 감소 + 의미적 일관 응답 + 저지연" → (C) k-NN 지원 OpenSearch에 질의-응답 쌍 저장, 근사 k-NN으로 유사 질의·응답 조회 ▸ 벡터 유사도 기반이라 표현 달라도 동일 의미 매칭, ANN으로 저지연 【오답 체크】 (A) DAX + LIKE 필터는 문자열 부분 일치일 뿐 의미 유사성 매칭 불가. (B) MemoryDB RANGE 쿼리는 벡터 유사도 검색 방식이 아님(범위 조회), 시맨틱 매칭 부적합. (D) DynamoDB 정규화 텍스트 GSI + 스테밍은 어휘 기반 정규화라 의미가 다른 표현을 못 잡음. 【시험 포인트】 "의미 기반 중복 질의 캐싱" → 임베딩 + 벡터(k-NN) 유사도 검색.

해설

【핵심 용어】 ▸ MCP(Model Context Protocol) — AI 에이전트와 서버 간 통신 표준 ▸ 전송 메커니즘 — STDIO(동기), HTTP(비동기), Streamable ▸ 인증 방식 — IAM, OAuth, API 게이트웨이, Cognito 【정답 포인트】 ▸ API Gateway HTTP API로 Lambda 앞에 인증 계층 생성 ▸ Cognito OAuth 2.1로 권한 있는 사용자만 접근 ▸ Streamable HTTP 전송으로 안전한 비동기 통신 ▸ MCP 클라이언트가 HTTP API를 통해 안전하게 호출 【오답 체크】 (A) 비동기 호출만으로는 인증/인가 메커니즘 부족 (B) STDIO는 프로세스 간 로컬 통신이므로 원격 접근 불가 (D) Lambda 레이어 + 환경변수는 권한 관리 미흡 【시험 포인트】 ▸ MCP 전송 메커니즘의 특성(STDIO vs HTTP 차이) ▸ API Gateway 기반 보안 아키텍처 ▸ OAuth 인증과 IAM 권한의 계층적 제어

해설

【핵심 용어】 ▸ AWS Step Functions — 워크플로우 조율 및 상태 관리 ▸ 에이전트 순차 실행 — 검색→추천→주문 순서 ▸ 복원력 패턴 — 재시도/catch로 우아한 성능 저하(Graceful Degradation) 【정답 포인트】 ▸ Step Functions 상태 머신으로 3개 에이전트 순차 실행 ▸ 각 작업 단계에 재시도(Retry) 및 catch 브랜치 설정 ▸ catch 브랜치로 서비스 실패 시 부분 응답 제공 ▸ Lambda 함수로 보상 계산을 마지막 단계에 통합 【오답 체크】 (A) Lambda 조율 + API Gateway는 통합 워크플로우 추상화 부족 (C) 에이전트별 폴백은 에이전트 자체만 보호, 통합 흐름 제어 미흡 (D) Step Functions 필요한데 단일 작업만으로는 순차 실행 불가 【시험 포인트】 ▸ Step Functions의 재시도/catch 브랜치 메커니즘 ▸ 우아한 성능 저하 개념과 구현 ▸ 에이전트 기반 워크플로우 조율의 모범사례

해설

【핵심 용어】 ▸ Bedrock Flows vs Step Functions — 플로우 기반 vs 상태 머신 ▸ S3 통합 — GetObject/PutObject 작업 ▸ 데이터 파싱 — Pass 단계로 표현식 처리 【정답 포인트】 ▸ Step Functions Express 사용(저지연 워크플로우) ▸ S3 GetObject로 원본 통신 검색 ▸ Pass 단계로 통신에서 부분만 파싱/추출 ▸ InvokeModel로 Bedrock 모델 호출 ▸ S3 PutObject로 모델 응답 저장 【오답 체크】 (A) Bedrock Flows는 플로우 기반이지만 S3 액션 노드 구성이 복잡 (C) 에이전트는 오버헤드이며 문서 파싱 전담 도구 아님 (D) 에이전트 + 3개 Lambda는 불필요하게 복잡하고 유지보수 어려움 【시험 포인트】 ▸ Express(저지연) vs Standard 상태 머신 선택 ▸ S3 GetObject/PutObject 통합 ▸ Pass 단계를 통한 데이터 변환

해설

【핵심 용어】 ▸ 자동 평가 — 판사 모델(Judge Model)로 응답 채점 ▸ Guardrails — 규정 준수 검증(정책 강제) ▸ 인적 검토 — Amazon A2I로 중요 상호작용 심사 【정답 포인트】 ▸ Claude Sonnet을 판사 모델로 정확성/적절성 평가 ▸ Bedrock Guardrails로 금융 규정 준수 강제 ▸ A2I(Augmented AI)로 플래그된 중요 상호작용만 인적 검토 ▸ 3계층 방어: 자동 평가 → Guardrails → 인적 검토 【오답 체크】 (A) 수동 검토는 확장성 없음, 1000건 응답 검토 불가 (C) Lex + Lambda는 평가 시스템이 아닌 챗봇 (D) CloudWatch는 모니터링일 뿐 실제 평가/검증 기능 없음 【시험 포인트】 ▸ 자동 평가 시스템의 3계층 설계 ▸ 판사 모델(Judge Model) 개념 ▸ Amazon A2I를 활용한 인적 검토 통합

해설

【핵심 용어】 ▸ 감독 에이전트 — 의도 분류 및 라우팅 ▸ 협력 에이전트 — 부서별 도메인 특화 ▸ 지식 기반 격리 — IAM 제어 + RAG 【정답 포인트】 ▸ 감독 에이전트로 자연어 의도 분류(임상→보험→예약→청구) ▸ 전문화된 협력 에이전트로 쿼리 라우팅 ▸ 부서별 지식 기반 격리로 액세스 제어 ▸ IAM 필터링 + RAG로 도메인 특화 응답 【오답 체크】 (B) 부서별 감독 에이전트는 중복, 수동 인계는 확장성 없음 (C) 단일 범용 에이전트는 도메인 특화 어려움, 액션 그룹 관리 복잡 (D) 동일 지식 기반은 부서별 격리 불가, 응답 품질 저하 【시험 포인트】 ▸ 감독/협력 에이전트 패턴 ▸ 마이크로서비스 아키텍처의 도메인 분리 ▸ 부서별 격리와 확장성 동시 달성

해설

【핵심 용어】 ▸ AWS CDK — Infrastructure as Code(코드로 인프라 정의) ▸ CodePipeline — CI/CD 자동화 ▸ FoundationModel API — 런타임에 모델 ID 동적 참조 【정답 포인트】 ▸ 단일 CDK 애플리케이션으로 코드 재사용 ▸ fromFoundationModelId()로 모델 ID를 파라미터로 참조 ▸ 단일 CodePipeline으로 개발/프로덕션 환경 배포 ▸ 환경별 설정만 변경하면 모델 전환 가능(코드 수정 불필요) 【오답 체크】 (A) 파이프라인 여러 개는 복잡하고 중복 코드 발생 (B) 환경별 CDK는 코드 중복, 유지보수 어려움 (D) 프로덕션만 IaC는 일관성 없음, 개발 환경도 코드로 관리해야 함 【시험 포인트】 ▸ CDK의 단일 정의 원칙 ▸ CodePipeline 다단계 배포 ▸ 런타임 파라미터를 통한 동적 모델 선택

해설

【핵심 용어】 ▸ 멀티 계정 구조 — 호텔별 완전 격리 ▸ 직접 데이터 수집 — 실시간 PMS 동기화 ▸ 정기 동기화 — 덜 중요한 정보는 배치 처리 【정답 포인트】 ▸ 호텔별 지식 기반으로 액세스 제어 구현 ▸ 직접 데이터 수집으로 실시간 객실 가용성 제공 ▸ 정기 동기화로 덜 중요한 정보는 배치 처리 ▸ 멀티 계정으로 완전 데이터 격리, 피크 시간 성능 안정 【오답 체크】 (A) 단일 지식 기반은 호텔별 격리 실패, 필터는 충분하지 않음 (B) 중앙화된 지식 기반은 호텔별 격리 불가, 성능 저하 (D) 중앙 에이전트는 병목 지점, 확장성 문제 【시험 포인트】 ▸ 멀티 계정 격리 패턴과 보안 이점 ▸ 실시간 vs 배치 동기화 선택 기준 ▸ 대규모 엔터프라이즈 아키텍처 설계

해설

【핵심 용어】 ▸ AWS AppConfig — 구성 버전 관리 및 점진적 배포 ▸ 유효성 검사기 — 잘못된 구성 배포 사전 차단 ▸ 자동 롤백 — 모니터링 기반 배포 취소 【정답 포인트】 ▸ AppConfig에 활성 모델 제공자 저장 ▸ Lambda가 런타임에 AppConfig에서 최신 구성값 읽음 ▸ 유효성 검사기로 잘못된 구성 배포 방지 ▸ 모니터링 기반 자동 롤백으로 안전한 배포 전략 【오답 체크】 (A) Parameter Store는 버전 관리/배포 전략 미지원 (C) API Gateway는 라우팅 도구일 뿐 구성 관리 못함 (D) S3 + AppConfig는 불필요하게 복잡한 구조 【시험 포인트】 ▸ AppConfig vs Parameter Store의 핵심 차이 ▸ 점진적 배포 전략(Gradual Rollout) ▸ 구성 변경 검증 및 자동 롤백

해설

【핵심 용어】 ▸ 토큰 관리 — 프롬프트 길이 제어로 입력 절단 방지 ▸ 재시도 로직 — 지수 백오프로 타임아웃 처리 ▸ 응답 청크 처리 — 손상 감지 및 재전송 【정답 포인트】 ▸ 토큰 계산/제한으로 프롬프트 크기 관리 ▸ 재시도 정책으로 API 타임아웃 처리 ▸ 응답 청크 손상 감지 및 재전송 메커니즘 ▸ 스트리밍으로 점진적 응답 전달 【오답 체크】 (A) 단순 재시도만으로는 토큰 제한 문제 미해결 (B) 임계값 설정은 불균형한 토큰 할당 (D) 라우팅은 근본 원인(타임아웃) 해결 못함 【시험 포인트】 ▸ 토큰 제한 관리 전략 ▸ API 복원력 설계(재시도/백오프) ▸ 응답 스트리밍으로 신뢰성 향상