실전 문제

문제 1

도시 병원 네트워크의 공중보건 분석 팀은 대규모 언어 모델(LLMs)을 사용해 20~50페이지 분량의 임상 사고 보고서(PDF)를 읽고 안전성 검토를 위한 핵심 요약을 생성하는 AI 애플리케이션을 구축하려고 합니다. 시스템은 요청당 5초 이내에 상위 주요 발견사항의 간결한 요약(≤200단어)을 반환해야 하며, 최대 10명의 동시 검토자를 지원해야 합니다. 어떤 솔루션이 이러한 요구사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 명시적인 기능 및 비기능 요구 사항(출력 길이, 지연 시간, 동시성)을 바탕으로 올바른 generative AI 애플리케이션 패턴, 즉 LLM 기반 document summarization을 선택하는지를 평가합니다. AWS 관점에서 이는 일반적으로 foundation model(예: Amazon Bedrock 경유)을 사용하여 긴 문서에 대해 summarization을 수행하는 방식에 해당합니다. 정답인 이유: 팀은 20~50페이지 분량의 PDF를 읽고 요청당 5초 이내에 핵심 findings의 간결한 summary(≤200 words)를 생성하며, 최대 10명의 동시 reviewer를 지원하는 AI 애플리케이션이 필요합니다. Option C는 정확히 이 작업을 수행하는 LLM 기반 summarization assistant를 설명하며, 제약 조건(제한된 summary 길이와 낮은 지연 시간)에도 부합합니다. 다른 옵션들은 서로 다른 ML 작업(NER, recommendations, translation)을 설명하며, 핵심 findings에 대한 간결한 narrative/bulleted summary를 생성해야 한다는 주요 요구 사항을 충족하지 못합니다. 주요 AWS 기능: 일반적인 AWS 구현에서는 PDF를 저장하기 위해 Amazon S3를 사용하고, text extraction(보통 PDF의 경우 Amazon Textract)을 통해 문서를 text로 변환한 뒤, summarization을 위해 LLM(예: 적절한 model을 사용하는 Amazon Bedrock)을 사용합니다. 5초 SLA와 10명의 동시 사용자를 충족하려면 다음에 중점을 둡니다: - ≤200 words를 강제하기 위한 prompt 설계(명시적 지시 + max tokens). - 낮은 지연 시간의 inference(실시간 요청에 적합한 model/throughput 구성 선택). - 반복 접근에 대한 summary caching(예: DynamoDB/ElastiCache) 및 가능할 경우 새로 업로드된 report에 대한 비동기 pre-summarization. - API 계층에서의 동시성 제어 및 scaling(API Gateway + Lambda/ECS)과 함께 model endpoint가 병렬 요청을 처리할 수 있도록 보장. 흔한 오해: NER(Option A)는 clinical report에 drugs 및 dosages 같은 entity가 포함되어 있기 때문에 관련 있어 보일 수 있지만, entity tagging은 일관된 “top findings” summary를 생성하지 않습니다. Recommendations(Option B)는 summarization이 아니라 discovery를 돕습니다. Translation(Option D)은 multilingual output이 필요한 경우가 아니라면 관련이 없습니다. 시험 팁: 시험 문제에서는 동사와 출력을 기준으로 판단하세요: “produce key takeaways/summary”는 generative AI summarization을 강하게 시사합니다. 그런 다음 비기능 요구 사항(지연 시간, 동시성, 출력 길이)에 맞는지 검증하세요. entity extraction, search, recommendations 같은 인접한 analytics 작업이 아니라, 최종 사용자에게 전달되는 결과물과 일치하는 옵션을 선택해야 합니다.

문제 2

한 IT 운영 팀이 8~12개의 연속된 서비스 로그와 5개의 메트릭 이상 징후를 분석하여 인시던트를 진단하기 위해 LLM을 사용하며, 최종 근본 원인과 개선 조치를 정당화하는 번호가 매겨진 단계별 추론 트레이스와 중간 계산(예: latency delta 및 error-rate ratio)을 모델이 생성해야 한다고 요구한다. 이러한 요구 사항을 가장 잘 충족하는 prompt engineering 기법은 무엇인가?

문제 분석

핵심 개념: 이 문제는 generative AI/LLM을 위한 prompt engineering 기법, 특히 모델로부터 중간 계산을 포함한 구조화된 다단계 추론을 어떻게 유도하는지를 평가합니다. AWS 시험 맥락에서는 Amazon Bedrock 또는 Amazon SageMaker JumpStart 사용 패턴과 함께 자주 등장하지만, 핵심은 prompting 방법입니다. 정답이 맞는 이유: 요구 사항이 명확합니다. 팀은 최종 진단과 개선 조치를 정당화하는 번호가 매겨진 단계별 추론 트레이스와 중간 계산(latency delta, error-rate ratio)을 필요로 합니다. Chain-of-thought prompting은 모델이 최종 답만 내놓는 것이 아니라 중간 추론 단계를 산출하도록(즉, “작업 과정을 보여주도록”) 유도하기 위해 설계되었습니다. 구조화된 추론 트레이스(예: “step by step로 생각하라; 계산을 포함하라; 번호가 매겨진 단계로 출력하라”)를 요청하면, 8~12개의 연속 로그와 5개의 메트릭 이상 징후처럼 여러 증거 항목 전반에서 일관성을 높이고, 모델이 근거 없이 결론으로 점프할 가능성을 줄이기 위해 chain-of-thought prompting을 적용하는 것입니다. 주요 AWS 기능 / 모범 사례: AWS(예: Amazon Bedrock)에서 실제로는 chain-of-thought 스타일 지시와 출력 형식 제약(번호가 매겨진 단계, 계산 섹션, 최종 근본 원인, 개선 조치)을 결합합니다. 로그/메트릭 컨텍스트를 제공하기 위해 retrieval(RAG)과 함께 사용할 수도 있지만, 이 문제는 중간 추론을 산출하게 하는 prompting 기법이 무엇인지에 초점을 둡니다. 운영 환경에서는 추가로 guardrails(예: “각 단계가 어떤 로그 라인/메트릭으로 뒷받침되는지 인용하라”)를 적용하고, 계산은 외부에서 검증하는 경우가 많습니다. 흔한 오해: Few-shot prompting은 예시를 제공하여 작업 준수도를 높일 수 있지만, 본질적으로 모델이 중간 추론을 드러내도록 요구하는 기법은 아닙니다. Zero-shot은 상세한 트레이스를 안정적으로 생성할 가능성이 가장 낮습니다. Directional stimulus prompting은 특정 증거에 주의를 기울이도록 유도할 수 있지만, 계산을 포함한 명시적 다단계 추론을 끌어내는 정석적인 기법은 아닙니다. 시험 팁: 문제가 “step-by-step reasoning”, “show your work”, “intermediate steps”, “multi-hop reasoning”을 요구하면, 시험 정답은 보통 chain-of-thought prompting입니다. 반대로 “예시로부터 학습”을 강조하면 few-shot을 선택하세요. “지시만으로 수행”을 강조하면 zero-shot을 선택하세요. “특정 단서나 제약에 집중”을 강조하면 directional stimulus가 해당될 수 있습니다.

문제 3

실시간 금융 뉴스 플랫폼은 하루에 약 12 GB의 새로운 다국어 기사를 수집하며, 사내 foundation model (FM)이 가중치를 재설정하지 않고 24시간 이내에 속보성 변화를 반영하길 원합니다. 팀은 이전에 학습한 역량을 보존하기 위해 최신 checkpoint에서 warm-start하고, rolling 90-day corpus를 사용해 매일 refresh를 계획하고 있습니다. 가장 최신 데이터를 반영하면서도 이전에 학습한 지식을 유지하도록 FM을 최신 상태로 유지하는 training strategy는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 foundation model (FM)의 training lifecycle 전략, 특히 새로 유입되는 데이터를 반영하면서도 기존에 학습한 역량을 잃지 않도록 FM을 최신 상태로 유지하는 방법을 평가합니다. 관련 개념은 기존 checkpoint( warm start)를 사용해 새로운 데이터로 점진적/지속적으로 학습하는 방식이며, 이를 continuous pre-training(continued pretraining)이라고 합니다. 정답이 맞는 이유: 플랫폼은 매일 새로운 다국어 기사를 수집하고, FM이 24시간 이내에 속보를 반영해야 합니다. 또한 팀은 “가중치를 재설정”하지 않고 최신 checkpoint에서 warm-start하여 rolling 90-day corpus로 학습하길 명시합니다. 이는 continuous pre-training의 전형적인 특징입니다. 즉, 최신 가중치에서 시작해 새로 수집된 도메인 데이터를 기반으로 동일한 base model을 주기적으로 계속 학습시켜, 모델이 최신 정보를 반영하도록 하면서도 일반적인 언어 능력을 유지합니다. rolling window를 사용하면 최신성(recency)과 보존(retention) 간 균형을 맞출 수 있고, 가장 최근 하루치 데이터만 학습하는 것보다 catastrophic forgetting을 줄이는 데 도움이 됩니다. 주요 AWS 기능 / Best Practices: AWS에서는 이 패턴을 보통 스케줄된 training pipeline(예: Amazon SageMaker Pipelines 또는 AWS Step Functions로 orchestration)로 구현하며, 다음을 수행합니다: 1) 매일 데이터를 Amazon S3에 정제/적재, 2) rolling 90-day training set 구성(대개 versioning 및 lineage 포함), 3) S3에 저장된 최신 model checkpoint에서 초기화하는 training job 실행, 4) 업데이트된 model을 model registry에 등록하여 통제된 배포 수행. Best practices에는 checkpointing, data/version governance, evaluation gate(회귀 탐지), drift 및 성능 저하 모니터링이 포함됩니다. 흔한 오해: “Batch learning”은 주기적 batch를 사용하므로 비슷하게 들릴 수 있지만, ML 용어에서 보통 online learning과 대비되는 개념이며, 이전 checkpoint에서 warm-start하여 FM의 pre-training을 계속 수행해 지식을 최신화한다는 의미를 구체적으로 내포하지는 않습니다. “Static training”은 한 번 학습하고 끝내는 방식이므로 24시간 최신성 요구사항을 충족하지 못합니다. “Latent training”은 FM을 최신 상태로 유지하기 위한 표준 전략이 아닙니다. 시험 팁: “warm-start from latest checkpoint”, “rolling corpus”, “daily refresh”, “base model을 최신 상태로 유지” 같은 요구사항이 보이면 continuous/continued pre-training으로 연결하세요. 반대로, 작은 labeled dataset으로 특정 작업에 맞게 적응시키는 내용이 강조되면 pre-training보다는 fine-tuning에 가깝습니다.

문제 4

Amazon Bedrock을 사용하는 동안 한 팀이 44단어 채팅 메시지가 1,536개의 input tokens와 72개의 output tokens로 과금되는 것을 확인했다. 이 맥락에서 token이라는 용어는 무엇을 의미하는가?

문제 분석

핵심 개념: 이 문제는 generative AI 사용 및 과금에서의 “tokens”에 대한 이해를 평가하며, 특히 Amazon Bedrock에서의 개념을 다룬다. Bedrock(및 대부분의 LLM 제공업체)은 input(프롬프트 + 대화 기록 + system instructions)과 output(model이 생성한 텍스트)의 token 수를 기준으로 요청을 측정한다. 정답이 맞는 이유: Token은 model이 읽고 쓰는 텍스트의 기본 단위이다. Tokens는 항상 전체 단어가 아니며, subwords(단어 조각), 구두점, 공백 마커 또는 특수 제어 기호일 수 있다. 그래서 44단어 메시지가 훨씬 더 많은 input tokens로 매핑될 수 있다. model의 tokenizer가 단어를 여러 조각으로 분할할 수 있고, 과금되는 “input tokens”에는 눈에 보이는 사용자 메시지 외의 내용(예: system prompts, formatting wrappers, safety instructions, 이전 채팅 턴 등)이 요청과 함께 전송되어 포함되는 경우가 많기 때문이다. 주요 AWS 기능: Amazon Bedrock에서 요금 및 quota는 일반적으로 선택한 foundation model의 input tokens와 output tokens 기준으로 표현된다. Tokenization은 model별로 다르다. 서로 다른 models(심지어 서로 다른 버전)도 동일한 텍스트를 다르게 tokenize할 수 있어 token 수와 비용이 달라질 수 있다. Chat 사용 사례에서는 요청에 구조화된 message roles(system/user/assistant)이 포함되는 것이 일반적이며, 대화 context가 포함될 수 있어 input tokens가 증가한다. Token 기반 측정을 이해하면 비용 최적화(더 짧은 prompts, history trimming, context 요약)와 latency 관리에 도움이 된다. 흔한 오해: 사람들은 tokens를 embeddings(vectors)와 혼동하는 경우가 많다. 둘 다 텍스트 처리와 관련이 있기 때문이다. 또 다른 오해는 tokens가 단어와 동일하다고 가정하는 것인데, 이는 틀리다. Tokenization은 텍스트를 이산적인 IDs로 변환하는 전처리 단계이다. 또 다른 혼동은 tokens를 model parameters(weights)나 prompts 자체로 생각하는 것인데, 이는 다른 개념이다. 시험 팁: Bedrock 과금, throughput 또는 context window 관련 문제에서 “tokens”는 거의 항상 tokenizer가 생성하는 텍스트 단위(단어/subword/기호 단위)를 의미한다. Input token 수에는 숨겨진 오버헤드(system prompts, chat formatting, conversation history)가 포함될 수 있음을 기억하라. 단어 수가 token 수와 일치하지 않는 것처럼 보인다면, 이는 과금 오류가 아니라 tokenization의 세분성 및 요청 구성에 관한 문제라는 단서이다.

문제 5

비디오 스트리밍 플랫폼이 악성 트래픽으로부터 콘텐츠 전송 API를 보호하기 위해 AI를 사용하려고 합니다. 이 AI는 30일간의 기준(baseline) 트래픽 패턴과 비교하여 새로운 요청의 client IP와 user agent가 의심스러운 출처에서 왔는지 판단해야 하며, 분당 최대 12,000개의 요청을 요청당 150 ms 미만의 지연 시간으로 점수화(score)하고, 비정상적인 출처를 자동으로 플래그(flag)해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 보안 텔레메트리에서 올바른 ML 문제 유형을 선택하는지를 평가합니다. 즉, 과거 기간 동안의 “정상” 동작을 학습하여 새로운 이벤트를 거의 실시간으로 점수화하면서 비정상적인 요청 출처(client IP + user agent)를 탐지하는 것입니다. 이는 NLP, 음성, 또는 시계열 예측이 아니라 전형적인 이상 탐지(anomaly detection)(대개 비지도 또는 준지도)입니다. 정답이 맞는 이유: 플랫폼은 새로운 요청을 30일간의 기준 트래픽 패턴과 비교하고 비정상적인 출처를 자동으로 플래그해야 합니다. 이는 이상 탐지에 정확히 해당합니다. 즉, 정상 패턴(예: 일반적인 IP/user-agent 조합, 빈도, geo/ASN 분포, 요청률)의 모델을 만들고, 들어오는 요청이 그로부터 얼마나 벗어나는지 점수화합니다. 또한 “분당 최대 12,000 요청을 요청당 150 ms 미만 지연으로 점수화” 요구 사항은 저지연 온라인 추론을 의미하며, 이상 탐지 시스템은 보통 real-time endpoint를 통해 이를 지원합니다. 주요 AWS 기능: AWS에서는 일반적으로 Amazon SageMaker(실시간 추론 endpoint)를 사용하고, Random Cut Forest (RCF) 같은 이상 탐지용 built-in algorithm 또는 custom model을 활용해 구현합니다. Amazon S3에 저장된 30일치 로그(예: Amazon CloudFront, ALB, API Gateway access logs, 또는 AWS WAF logs)를 기반으로 학습한 뒤, 12k RPM 및 지연 시간 목표를 충족하도록 autoscaling을 적용한 SageMaker endpoint로 배포합니다. 스트리밍 수집 및 준실시간 점수화를 위해 Amazon Kinesis Data Streams / Firehose가 feature를 모델로 전달할 수 있으며, 결과는 자동 조치(예: AWS WAF IP sets 업데이트, Amazon EventBridge로 publish, 또는 Amazon SNS로 알림)를 트리거할 수 있습니다. 이는 Well-Architected의 Security 및 Reliability pillar(탐지/대응 자동화, 수평 확장)와도 부합합니다. 흔한 오해: 일부는 “의심 트래픽”을 “fraud forecasting”과 혼동할 수 있지만, forecasting은 미래 값(예: 수요 또는 사기량)을 예측하는 것이지 개별 요청을 이상으로 분류하는 것이 아닙니다. NLP named entity recognition과 speech recognition은 입력이 텍스트 엔터티나 오디오가 아니라 구조화된 요청 메타데이터이므로 관련이 없습니다. 시험 팁: “정상 동작의 baseline”, “비정상 플래그”, “이벤트 점수화”가 보이면 이상 탐지를 떠올리십시오. “미래 추세 예측”이 보이면 forecasting입니다. ML 작업을 데이터 유형에 맞추십시오. IP/user-agent 텔레메트리는 구조화 데이터이며 언어/오디오가 아닙니다. 또한 RPM/지연 시간 같은 운영 제약은 real-time inference endpoint와 autoscaling을 시사합니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

한 헬스케어 스타트업이 Amazon Bedrock에서 호스팅되는 foundation model로 few-shot prompting을 사용하고 있습니다. 현재 프롬프트에는 12개의 예제가 포함되어 있고, 모델은 매일 07:00 UTC에 하루 1회 호출되며, 출력 품질은 만족스럽습니다. 회사는 현재 성능을 유지하면서 월간 비용을 낮추고자 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 대부분의 foundation model에 대한 Amazon Bedrock 요금은 주로 사용량 기반(입력 token + 출력 token)입니다. Few-shot prompting은 각 예제가 프롬프트에 텍스트를 추가하므로 입력 token을 증가시킵니다. 품질이 이미 만족스럽다면, 동일한 모델과 호출 패턴을 유지하면서 비용을 줄이는 가장 직접적인 방법은 token 사용량을 줄이는 것입니다. 정답인 이유: 모델은 하루에 한 번만 호출되므로 처리량/지연 시간 보장은 요구 사항이 아닙니다. 12개의 few-shot 예제로 인해 프롬프트에는 매 호출마다 과금되는 많은 token이 포함될 가능성이 큽니다. 프롬프트의 token 수를 줄이면(예: 예제 수를 줄이기, 예제를 더 짧게 만들기, 중복 지시문 제거, 포맷 압축) 입력 token 소비가 감소하여 월간 비용이 낮아집니다. 현재 출력 품질이 만족스럽기 때문에, 성능이 허용 가능한 수준으로 유지되는지 검증하면서 token을 점진적으로 줄일 수 있어 “현재 성능 유지” 요구 사항을 충족합니다. 주요 AWS 기능: Bedrock 모델 호출 비용은 token 수에 비례해 증가하므로, prompt engineering은 지출을 제어하는 운영적 레버입니다. 실용적인 기법으로는: 가장 대표적인 few-shot 예제만 유지하기, 더 짧은 exemplar 사용하기, 장황한 system instruction 제거하기, 간결한 schema로 표준화하기 등이 있습니다. 로깅/observability(예: 프롬프트/응답 메타데이터 캡처)를 통해 token 사용량과 응답 품질을 측정하고, A/B test를 실행하여 품질이 유지되는지 확인할 수 있습니다. 흔한 오해: fine-tuning/Customize는 품질을 개선하거나 프롬프트 길이를 줄일 수 있지만, 추가 비용(학습 및 잠재적으로 호스팅/관리)과 오버헤드를 유발하며, 품질이 이미 만족스럽고 트래픽이 매우 낮은 경우에는 불필요합니다. Provisioned Throughput은 비용 절감 수단으로 오해되는 경우가 많지만, 이는 하루 1회 호출이 아니라 일관된 고처리량 워크로드와 예약 용량을 위해 설계되었습니다. 시험 팁: LLM에서 “비용을 낮추라”는 질문이 나오면, Customize나 예약 용량을 고려하기 전에 먼저 token 감소 전략(더 짧은 프롬프트, 더 적은 예제, 더 작은 출력)을 확인하십시오. Provisioned Throughput은 워크로드가 대규모에서 예측 가능한 용량/지연 시간이 필요하거나 지속적으로 높은 요청률이 있을 때만 선택하십시오. 간헐적이고 저용량 사용의 경우, on-demand token 기반 요금 + 프롬프트 최적화가 일반적으로 가장 비용 효율적인 접근입니다.

문제 7

한 리테일 분석 팀이 Amazon OpenSearch Service에 2,000만 개의 768차원 텍스트 임베딩을 저장하는 retrieval-augmented generation (RAG) 프로토타입을 구축하고 있으며, 100 ms 이내에 가장 유사한 벡터 상위 20개를 검색해야 합니다. 이러한 유형의 벡터 데이터베이스 애플리케이션을 가능하게 하는 OpenSearch 기능은 구체적으로 무엇입니까?

문제 분석

핵심 개념: 이 문제는 retrieval-augmented generation (RAG)에서 사용되는 Amazon OpenSearch Service의 벡터 데이터베이스 기능, 즉 고차원 임베딩을 저장하고 대규모로 빠른 근사 유사도 검색(k-nearest neighbor)을 수행하는 능력을 평가합니다. 정답인 이유: RAG 시스템은 쿼리 임베딩에 대해 의미적으로 가장 유사한 문서를 검색해야 합니다. 2,000만 개의 768차원 벡터와 엄격한 지연 시간 목표(100 ms 이내 상위 20개)를 고려할 때, 핵심 OpenSearch 기능은 확장 가능한 벡터 인덱싱과 k-NN 검색입니다. OpenSearch는 벡터 필드와 k-NN/ANN (approximate nearest neighbor) 검색을 제공하므로 2,000만 개 임베딩을 모두 스캔하지 않고도 가장 가까운 벡터를 효율적으로 찾을 수 있습니다. 이것이 바로 OpenSearch가 시맨틱 검색과 RAG를 위한 벡터 데이터베이스로 동작하게 하는 기능입니다. 주요 AWS 기능: OpenSearch는 k-NN 기능(일반적으로 HNSW와 같은 ANN 알고리즘 기반)을 통해 벡터 검색을 지원하며, 수평 확장성을 위해 샤드와 노드 전반에서 벡터 인덱스를 관리합니다. 일반적으로 임베딩을 벡터 필드에 저장하고, ANN 인덱스 유형/파라미터를 선택한 뒤, k-NN로 쿼리하여 상위 K 결과(여기서는 K=20)를 반환합니다. 성능은 인덱스 파라미터(예: 그래프 구성/ef 설정), 샤드 크기, 인스턴스 유형(메모리/CPU), 그리고 적용 가능한 경우 후보 집합을 좁히기 위한 필터 사용에 따라 달라집니다. 이는 Well-Architected의 성능 효율성 원칙(무차별 스캔이 아니라 데이터 구조 최적화 및 scale-out)에 부합합니다. 흔한 오해: S3 통합(A)은 스냅샷 저장 또는 데이터 수집과 관련된 것이지, 저지연 벡터 유사도 검색이 아닙니다. 지리공간 인덱싱(B)은 위치 기반 쿼리에 특화된 기능으로 임베딩 유사도와는 무관합니다. 스트리밍 분석(D)은 준실시간 로그/이벤트 분석과 관련되며 ANN 벡터 검색과는 다릅니다. 시험 팁: “embeddings”, “top K similar”, “vector database”, “RAG”를 보면 “vector search”, “k-NN”, “ANN”을 찾으십시오. OpenSearch/Elasticsearch 계열 서비스에서 이를 가능하게 하는 기능은 일반 검색, 스토리지 통합, 스트리밍 기능이 아니라 k-NN/벡터 인덱스입니다. 또한 수천만 개 벡터에서 엄격한 지연 시간을 요구한다는 것은 정확한 brute-force 유사도 계산이 아니라 approximate nearest neighbor 인덱싱을 강하게 시사합니다.

문제 8

한 대학 연구팀이 Amazon Bedrock을 사용하여 캠퍼스 서비스에 대한 질문에 답변하도록 foundation model을 커스터마이징했습니다. 이제 2,500개의 새로운 미확인(unseen) 쿼리에 대해 구조화된 검증을 실행하려고 하며, Amazon Bedrock이 평가를 위해 액세스할 수 있는 단일 150 MB JSONL 파일을 Bedrock 인스턴스와 동일한 AWS Region에 업로드해야 합니다. Bedrock이 object storage에서 이 데이터를 직접 읽을 수 있도록, 이 데이터셋을 저장하는 데 어떤 AWS 서비스를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon Bedrock이 모델 평가 데이터셋을 직접 읽을 수 있는 object storage를 제공하는 AWS 스토리지 서비스를 묻습니다. Bedrock 평가 워크플로는 일반적으로 Amazon S3에 저장된 데이터셋(예: JSONL 파일)을 동일한 AWS Region에서 S3 URI로 참조합니다. 정답이 맞는 이유: Amazon S3는 단일 150 MB JSONL 데이터셋과 같은 파일(객체)을 저장하고 검색하도록 설계된 AWS의 리전 기반 object storage 서비스입니다. S3는 AWS 서비스 전반에 네이티브로 통합되어 있고 관리형 AI/ML 서비스가 표준적으로 참조하는 “object storage” 대상이므로 Bedrock은 S3에서 평가 입력을 액세스할 수 있습니다. Bedrock 리소스와 동일한 Region의 S3 bucket에 데이터셋을 저장하면 리전 액세스 요구 사항을 충족하고 지연 시간 및 데이터 전송 복잡성을 최소화할 수 있습니다. 주요 AWS 기능 / 모범 사례: S3는 내구성이 높고 가용성이 뛰어난 스토리지를 간단한 액세스 패턴(S3 URI)으로 제공하며, 150 MB를 훨씬 초과하는 대용량 객체도 잘 지원하고, IAM과 통합되어 세분화된 액세스 제어가 가능합니다. Bedrock이 데이터셋을 읽을 수 있도록 일반적으로 Bedrock 서비스 role 또는 평가 job에 사용되는 execution role에 권한(예: bucket/prefix에 대한 s3:GetObject)을 부여합니다. 또한 bucket policy, 암호화(SSE-S3 또는 SSE-KMS), S3 versioning을 적용하여 거버넌스와 반복 가능한 평가를 구현할 수 있습니다. 흔한 오해: EBS와 EFS는 컴퓨팅(EC2, 일부 container runtime)에 연결되는 파일/블록 스토리지이며, Bedrock이 직접 읽는 “object storage” 엔드포인트가 아닙니다. Snowcone은 엣지/오프라인 데이터 전송 및 컴퓨팅 디바이스로, 온라인 서비스 액세스를 위한 리전 기반 object store가 아닙니다. 이 옵션들도 데이터를 저장할 수 있어 그럴듯해 보이지만, “object storage에서 직접 읽기” 요구 사항과는 맞지 않습니다. 시험 팁: 문제에서 “object storage”, “파일 업로드”, “서비스가 bucket에서 읽음”, 또는 관리형 ML/GenAI 서비스용 데이터셋을 언급하면, 특정 제약으로 다른 서비스를 선택해야 하는 경우가 아니라면 기본적으로 Amazon S3를 선택하세요. 또한 Region 요구 사항을 확인하세요. 동일한 Region의 S3 bucket을 선택하고, IAM 권한 및(필요한 경우) KMS key policy가 서비스가 객체를 읽을 수 있도록 허용하는지 확인해야 합니다.

문제 9

한 e-commerce 마켓플레이스가 Amazon Bedrock에서 managed large language model을 사용해 제품 Q&A assistant를 배포할 계획이다. 2일간의 파일럿에서 각 요청은 평균 800 prompt tokens와 200 completion tokens를 사용하며, temperature는 0.7로 설정되어 있고, 모델에 대해 custom training 또는 fine-tuning은 수행하지 않는다. 시스템이 10,000개의 요청을 처리할 때, 일일 inference 요금을 주로 좌우하는 요인은 무엇인가?

문제 분석

핵심 개념: Amazon Bedrock의 managed foundation models에 대한 inference pricing은 주로 사용량 기반이다. 대부분의 Bedrock 모델에서 on-demand inference 요금은 처리된 tokens 수(입력/prompt tokens + 출력/completion tokens)에 의해 결정된다. 이 문제는 generative AI inference가 어떻게 측정되고 과금되는지에 대한 이해를 평가한다. 정답이 맞는 이유: 하루 10,000건의 요청과 요청당 평균 800 prompt tokens + 200 completion tokens라면, 요청당 약 1,000 tokens를 소비하며 하루 총 약 10,000,000 tokens를 소비한다. Bedrock의 inference 비용은 서비스가 모델에 보내는 텍스트 양과 모델이 생성하는 텍스트 양을 측정하기 때문에 이 token 볼륨에 따라 증가한다. fine-tuning이나 custom training을 수행하지 않으므로 training 관련 요금은 고려할 필요가 없다. 따라서 지배적인 비용 요인은 요청당 소비되는 tokens 수이다. 주요 AWS 기능: Bedrock은 여러 foundation models에 대한 액세스를 제공하며, pricing은 일반적으로 1,000(또는 1 million) input tokens당 요금과 1,000(또는 1 million) output tokens당 요금으로 표시되고, 종종 서로 다른 요율이 적용된다. 이는 prompt optimization(더 짧은 prompts), 응답 길이 제한(max tokens), caching/retrieval 전략(RAG로 불필요한 context 감소), 그리고 지원되는 경우 request batching을 통해 비용을 제어하도록 유도한다. Temperature는 무작위성에 영향을 주는 inference parameter이지만, 과금 단위를 바꾸지는 않는다. 흔한 오해: 많은 사람들이 “temperature” 또는 다른 generation 설정이 비용을 직접 바꾼다고 생각한다. Temperature가 출력 길이나 재시도에 간접적으로 영향을 줄 수는 있지만(그 결과 tokens가 늘어날 수 있음), 과금 메커니즘 자체는 여전히 token 기반이다. 또 다른 오해는 training 시간이나 training 데이터가 inference 요금에 영향을 준다는 것인데, 이는 실제로 모델을 training하거나 fine-tuning할 때만 해당된다(그리고 Bedrock의 managed FMs는 보통 고객이 직접 training을 관리하지 않고 사용한다). 시험 팁: Bedrock 및 대부분의 LLM 서비스에서 inference 비용은 보통 입력 + 출력 tokens에 비례한다는 점을 기억하라. 요청 수와 평균 token 수로부터 일/월간 token 총량을 항상 대략 계산하라. Inference pricing과 customization(fine-tuning) pricing을 구분하고, 문제에서 compute time 또는 provisioned throughput 기반 pricing을 명시하지 않는 한 모델 hyperparameters(temperature, top-p)를 과금 차원과 혼동하지 마라.

문제 10

한 핀테크 스타트업은 Amazon S3에 매일 도착하는 120개의 CSV 파일(약 80 GB)을 처리하기 위해 AWS Glue ETL job을 구축해야 하지만, 팀은 AWS Glue 프로그래밍 경험이 거의 없고 2일 이내에 작동하는 PySpark job을 만들기 위해 AWS console에서 직접 단계별 안내와 코드 제안을 원한다. AWS Glue를 구축하고 사용하는 데 도움을 받기 위해 어떤 AWS service를 사용해야 하는가?

문제 11

지역 e-commerce 스타트업이 6주간의 연말(holiday) 캠페인을 계획하고 있으며, 라벨링된 과거 데이터셋에 의존하지 않고 100단어 이하의 텍스트 브리프에서 주당 300개의 고유한 마케팅 에셋을 자동으로 생성할 수 있는 솔루션이 필요합니다. 다음 중 이 요구사항에 대한 generative AI 사용 사례를 가장 잘 나타내는 것은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 generative AI 사용 사례를 식별하는지를 평가합니다. 즉, 라벨링된 과거 학습 데이터 없이도 프롬프트로부터 새로운 콘텐츠(이미지, 텍스트, 오디오)를 생성하기 위해 foundation model을 사용하는 것입니다. AWS에서는 일반적으로 Amazon Bedrock(또는 Amazon SageMaker JumpStart)을 사용해 pretrained 이미지 생성 모델에 접근하고 짧은 텍스트 브리프에서 에셋을 생성하는 것으로 매핑됩니다. 정답이 맞는 이유: 스타트업은 6주 캠페인 동안 짧은(<=100단어) 텍스트 브리프에서 주당 300개의 고유한 마케팅 에셋을 자동 생성해야 하며, 라벨링된 과거 데이터셋에 의존할 수 없다고 명시되어 있습니다. 이는 텍스트-투-이미지 생성과 정확히 일치합니다. generative model은 프롬프트로부터 새롭고 photorealistic한 제품/마케팅 이미지를 합성할 수 있습니다. “고유한 에셋” 요구사항은 generative AI의 대표적 특징(새로운 출력 생성)이며, “라벨링된 데이터 없음” 제약은 supervised ML에서 벗어나, 처음부터 학습시키기보다 프롬프트로 사용할 수 있는 pretrained foundation model(필요 시 제한적 커스터마이징 가능) 쪽을 가리킵니다. 주요 AWS 기능: Amazon Bedrock을 사용하면 API를 통해 이미지 생성 foundation model을 호출하고, 파라미터(예: seed, guidance, style)로 변동성/고유성을 제어하며, serverless 패턴(AWS Lambda, Step Functions, EventBridge)을 통해 생성 규모를 확장하여 주간 물량을 충족할 수 있습니다. 결과물은 Amazon S3에 저장하고, 프롬프트/메타데이터를 추적하며, IAM으로 최소 권한 액세스를 적용할 수 있습니다. 브랜드 일관성이 필요하다면, 지원되는 경우 model customization을 검토하거나 프롬프트 템플릿 및 reference image(모델에 따라 다름)를 사용하면서도 라벨링된 데이터셋은 피할 수 있습니다. 흔한 오해: 이상 탐지, 예측, 성능 튜닝 옵션은 “predictive/analytical” 또는 “systems engineering” 작업이지 콘텐츠 생성이 아닙니다. ML을 사용할 수는 있지만, 프롬프트로부터 새로운 창작 에셋을 만들어내지는 않습니다. 또한 어떤 사람들은 모든 AI 자동화를 generative AI로 생각할 수 있으나, 시험에서는 “generative AI”가 구체적으로 새로운 콘텐츠를 생성하는 것을 의미합니다. 시험 팁: “generate”, “create”, “from prompts”, “unique assets”, “no labeled data”, “foundation model” 같은 키워드를 찾으세요. 이는 generative AI 및 Amazon Bedrock 같은 서비스를 강하게 시사합니다. 작업이 classification, detection, forecasting이라면 보통 generative AI가 아니라 전통적인 ML/analytics입니다.

문제 12

FERPA의 적용을 받는 학생 PII를 포함한 12 TB의 독점 학습 콘텐츠를 관리하고 3개 리전에서 운영하는 한 edtech 회사가, 제안된 4가지 솔루션 범위 전반에서 보안 책임을 평가하기 위해 AWS Generative AI Security Scoping Matrix를 사용하고 있습니다. 이 매트릭스에 따르면, 어떤 접근 방식이 회사에 보안 책임에 대한 가장 큰 소유권을 부여합니까?

문제 분석

핵심 개념: 이 문제는 AWS Generative AI Security Scoping Matrix 개념을 평가합니다. 관리형 SaaS로 GenAI를 소비하는 단계에서 자체 모델을 구축 및 학습하는 단계로 이동할수록, 조직이 부담하는 보안 책임(데이터 거버넌스, 모델 보안, 인프라, SDLC, 모니터링, 컴플라이언스)이 점진적으로 증가합니다. 정답인 이유: 옵션 D(회사의 자체 데이터를 사용하여 모델을 처음부터 설계, 구축 및 학습)는 회사에 보안 책임에 대한 가장 큰 소유권을 부여합니다. scoping matrix에서 이는 고객 책임이 가장 높은 시나리오로, 고객이 전체 스택을 통제하며(그리고 보안도 책임져야 하며) 데이터 수집 및 라벨링, 학습 파이프라인, 모델 아티팩트, 평가, 배포 엔드포인트, 지속적인 운영까지 모두 포함됩니다. 3개 리전에 걸쳐 FERPA의 적용을 받는 학생 PII와 12 TB의 독점 콘텐츠가 있는 상황에서는, 회사가 기밀성, 무결성, 접근, 데이터 레지던시, 보존, 감사 가능성에 대한 엔드투엔드 통제를 구현해야 합니다. 주요 AWS 기능 / 모범 사례: 이 범위에서 회사는 기본 클라우드에 대한 AWS shared responsibility에 의존하되, 그 위의 모든 것을 구성해야 합니다. 예: IAM least privilege, 데이터/모델 아티팩트에 대한 KMS 암호화, VPC 격리 및 private connectivity, Secrets Manager, CloudTrail/CloudWatch 로깅, GuardDuty/Security Hub, S3 bucket policy 및 access point, 데이터 분류 및 DLP 통제, 강력한 SDLC 통제(code scanning, artifact signing). 멀티 리전 운영의 경우, replication, key policy, 리전별 컴플라이언스 통제도 관리해야 합니다. 흔한 오해: fine-tuning(옵션 C)은 독점/PII 데이터가 사용되므로 “가장 책임이 큰” 것처럼 느껴질 수 있지만, base model과 플랫폼 책임의 상당 부분은 여전히 모델 제공자 및/또는 managed service에 있습니다. API를 통해 FM을 사용하는 것(옵션 B)은 민감한 prompt가 포함될 수 있으나, 제공자가 여전히 대부분의 model-layer 보안을 소유합니다. SaaS(옵션 A)는 벤더가 애플리케이션, 모델, 운영 보안의 상당 부분을 관리하므로 고객 소유권이 가장 낮습니다. 시험 팁: “가장 큰 소유권/책임(MOST ownership/responsibility)”을 묻는 문제에서는, 모델을 직접 build/train/host하는 옵션을 선택하십시오. “가장 적은(LEAST)”은 SaaS를 선택하십시오. 옵션을 스펙트럼에 매핑하십시오: SaaS(최저) -> API 소비 -> fine-tune -> 처음부터 build/train(최고).

문제 13

한 지역 의료 서비스 제공업체가 대규모 언어 모델(LLM)로 구동되는 트리아지 챗봇을 배포하고 있습니다. 이 챗봇은 예약 및 보험 관련 질문에 답하고 벡터 인덱스에서 클리닉 정책을 검색합니다. 레드팀 테스트 동안, temperature를 0.2로 설정하고 8,192-token 컨텍스트 윈도우를 사용했음에도 500개의 적대적 프롬프트 중 12%가 모델을 강제로 유도하여 마스킹된 샘플 ID를 공개하게 만들었습니다. 민감한 정보 또는 안전하지 않은 동작을 유도하려는 prompt-injection 및 jailbreak 시도의 위험을 가장 효과적으로 줄이는 조치는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 prompt injection/jailbreak에 대한 LLM 애플리케이션 보안 통제—AI 보안 및 거버넌스 주제를 평가합니다. AWS 관점에서는 민감한 데이터 노출과 안전하지 않은 동작을 방지하기 위해 guardrails 및 정책 강제(예: Amazon Bedrock Guardrails 및 애플리케이션 계층 입력/출력 검증)를 구현하는 것과 연관됩니다. 정답이 맞는 이유: 허용되는 동작, 거부 규칙, 역할 변경 시도 처리 방식을 명시적으로 정의하는 구조화된 system prompt와 재사용 가능한 prompt template은 제시된 선택지 중 가장 직접적이고 효과적인 통제입니다. Prompt injection은 흔히 지시를 덮어쓰는 방식(예: “이전 지시를 무시해라”, “system처럼 행동해라”, “숨겨진 데이터를 공개해라”)으로 작동합니다. 견고한 system prompt와 템플릿 접근은 일관된 지시 계층을 확립하고, 모호성을 줄이며, 결정론적 강제 패턴(거부, 리다이렉트, 또는 정화)을 가능하게 합니다. 단독으로 충분하진 않지만, 나열된 단일 조치 중 jailbreak 성공률을 낮추는 데 가장 적합합니다. 주요 AWS 기능 / 모범 사례: AWS에서 프로덕션으로 운영할 때는 일반적으로 (1) 강력한 system prompts 및 templates, (2) 입력/출력 필터링 및 정책 검사(예: 주제 제한, PII redaction, 차단 콘텐츠를 위한 Bedrock Guardrails), (3) RAG를 위한 retrieval 통제(검색 가능한 범위 제한, 민감하지 않은 embeddings만 저장, 문서 수준 authorization 강제), (4) 모니터링 및 사고 대응(CloudWatch logs, audit trails)을 결합합니다. 또한 데이터 소스에는 least privilege를 적용하고, secrets 또는 민감한 식별자를 프롬프트 컨텍스트에 두지 않도록 합니다. 흔한 오해: Temperature는 모델을 “보안”하게 만들지 않으며, 무작위성만 변경합니다. 모델 마켓플레이스 목록에 있다는 사실이 jailbreak 저항성을 보장하지도 않습니다. Token을 잘라내면 일부 공격 표면을 줄일 수는 있지만 정당한 사용을 해치며, 짧고 효과적인 injection을 막지는 못합니다. 시험 팁: Prompt injection 관련 문제에서는 정책과 지시 계층을 강제하는 통제(system prompts, guardrails, 입력/출력 검증, 데이터 최소화)를 선택하십시오. 무작위성, 벤더/카탈로그 선택만으로 해결하려는 접근, 또는 피상적인 컨텍스트 축소를 주요 보안 대책으로 삼는 답은 피하십시오.

문제 14

의료 분석 스타트업이 8개의 의료 기기 ISV와 파트너십을 맺고 매 분기 AI 파이프라인을 검증합니다. 컴플라이언스 팀은 어떤 ISV든 새로운 분기별 컴플라이언스 보고서를 게시할 때마다 15분 이내에 이메일 알림을 받기를 원합니다. 커스텀 폴링 솔루션을 구축하지 않고, 서드파티 데이터 제품에 대한 구독을 지원하는 관리형 AWS 서비스를 사용하려고 합니다. 스타트업은 어떤 AWS 서비스를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 커스텀 폴링 없이 업데이트에 대한 알림을 트리거하면서 서드파티 데이터 제품을 배포하고 구독하기 위한 AWS 관리형 서비스에 대한 지식을 테스트합니다. 또한 컴플라이언스 워크플로와 이벤트 기반 통합도 다룹니다. 정답이 맞는 이유: AWS Data Exchange는 제공자(ISV)가 데이터 제품을 게시하고 구독자(스타트업)가 해당 제품을 구독하도록 설계되었습니다. 제공자가 새 revision(예: 분기별 컴플라이언스 보고서)을 게시하면, 구독자는 관리형 통합(일반적으로 AWS Data Exchange 작업에 대한 Amazon EventBridge 이벤트)을 통해 알림을 받을 수 있어, 폴링 메커니즘을 구축하지 않고도 거의 실시간(15분 이내)으로 경고를 받을 수 있습니다. 이는 “관리형 AWS 서비스”, “서드파티 데이터 제품에 대한 구독”, “게시 시 이메일 알림” 요구사항과 일치합니다. 주요 AWS 기능: 1) 데이터 제품과 revision: ISV는 데이터셋을 제품으로 게시할 수 있으며, 각 분기 보고서는 새로운 revision이 될 수 있습니다. 2) 구독 모델: 스타트업은 한 번 구독하면, 게시되는 즉시 새로운 revision에 대한 액세스를 받습니다. 3) 이벤트 기반 알림: AWS Data Exchange 이벤트(예: 새 revision 게시)에 대해 Amazon EventBridge 규칙을 사용하고 Amazon SNS로 라우팅하여 이메일로 전달합니다. 이는 표준 서버리스 패턴인 EventBridge -> SNS(이메일 구독)로, “커스텀 폴링 없음” 요구사항을 충족합니다. 4) 거버넌스 및 감사 가능성: Data Exchange는 액세스 제어를 위해 IAM과 통합되고 API 감사를 위해 CloudTrail과 통합되어, 컴플라이언스 요구에 부합합니다. 흔한 오해: AWS Artifact와 AWS Audit Manager는 컴플라이언스 관련이므로 관련 있어 보일 수 있습니다. 하지만 Artifact는 서드파티 ISV 게시물이 아니라 AWS 자체 컴플라이언스 보고서를 위한 것입니다. Audit Manager는 프레임워크에 대한 증거 수집을 자동화하는 데 도움을 주지만, 외부 ISV 보고서를 위한 마켓플레이스/구독 서비스 역할을 하지는 않습니다. Trusted Advisor는 AWS 계정 상태에 대한 모범 사례 점검과 알림을 제공할 뿐, 서드파티 보고서 게시와는 관련이 없습니다. 시험 팁: “서드파티 데이터 제품 구독”과 “제공자가 업데이트를 게시”라는 문구가 보이면 AWS Data Exchange를 떠올리세요. 또한 “폴링 없이 알림”이 요구되면 EventBridge와 SNS를 함께 연상하세요. Artifact는 특히 “AWS 컴플라이언스 문서”이고, Audit Manager는 “증거 수집 및 통제 평가”, Trusted Advisor는 “계정 최적화 점검”입니다.

문제 15

한 지역 은행이 신청자 텍스트 요약과 구조화된 재무 특성을 모두 사용하여 소기업 대출에 대한 승인 권고를 생성하도록 foundation model (FM)을 fine-tuning하고 있습니다. 규제 기관은 4개 인구통계학적 그룹 전반의 편향 지표와 각 예측별 특성 기여도(예: SHAP)를 포함한 투명하고 감사 준비가 된 설명을 요구하며, 매주 모델 업데이트 후 24시간 이내에 샘플링된 추론의 최소 90%에 대해 이를 제공해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS에서 Responsible AI 거버넌스와 모델 설명 가능성—특히 편향 탐지/모니터링과 (예: SHAP) 같은 추론별 설명 가능 아티팩트를 모델 업데이트 후 감사 가능한 형태로 보고하는 것을 테스트합니다. 정답이 맞는 이유: Amazon SageMaker Clarify는 (1) 민감/인구통계학적 그룹 전반의 편향 지표를 계산하고 (2) 모델 예측에 대한 특성 기여도 설명( SHAP 기반 설명 포함)을 생성하도록 설계된 AWS 서비스입니다. 요구 사항은 규제 기관이 요구하는 투명하고 감사 준비가 된 설명, 4개 인구통계학적 그룹 전반의 편향 지표, 그리고 매주 모델 업데이트 후 24시간 이내에 샘플링된 추론의 최소 90%에 대한 예측별 특성 기여도를 포함합니다. Clarify는 학습 전 및 학습 후(그룹 기반 지표 포함) 편향 분석을 지원하고, 특성 기여도를 포함하는 설명 가능성 보고서를 생성할 수 있습니다. 이러한 아티팩트는 (예: Amazon S3에) 저장하여 감사에 활용할 수 있으며, 분석 작업은 주간 모델 업데이트 파이프라인의 일부로 스케줄링/자동화할 수 있습니다. 주요 AWS 기능 및 모범 사례: 각 모델 업데이트 후 SageMaker Clarify processing job을 사용하여 편향 및 설명 가능성 분석을 실행합니다. 민감 속성(4개 인구통계학적 그룹)과 레이블/결과를 구성하여 편향 지표를 계산합니다. 설명 가능성의 경우 SHAP explainer를 활성화하여 샘플링된 추론 데이터셋에 대해 예측별 기여도를 생성(“샘플링된 추론의 90%” 요구 사항 충족)합니다. SageMaker Pipelines 또는 AWS Step Functions로 주간 워크플로를 오케스트레이션하고, SageMaker Model Registry에서 model package 승인 시 트리거하며, 감사 가능성을 위해 버전 관리 및 보존 정책을 적용한 S3에 보고서를 기록합니다. 흔한 오해: 보안/규정 준수 스캐너(Inspector)와 데이터 탐지/분류 도구(Macie)는 거버넌스에 중요하지만, 편향 지표나 SHAP 설명을 생성하지는 않습니다. Rekognition은 표/텍스트 기반 대출 심사 설명 가능성과 관련이 없으며 규제 투명성 요구 사항을 해결하지 못합니다. 시험 팁: “bias metrics”, “demographic groups”, “explainability”, “feature attributions”, “SHAP”를 보면, 시험은 보통 SageMaker Clarify를 가리킵니다. 이를 자동화(Pipelines/Step Functions) 및 내구성 있는 저장소(S3)와 함께 감사 준비가 된 보고 타임라인으로 연결해 생각하세요.

문제 16

한 원격의료 플랫폼이 자연어 질의에 응답하여 AI가 큐레이션한 의학 일러스트 이미지들을 반환하는 가상 진료 어시스턴트를 배포했습니다. 임상 가이드라인과 앱 스토어 정책을 준수하기 위해, 회사는 노골적인 누드, 잔혹한 폭력, 또는 자해가 포함된 이미지가 표시되지 않도록 방지해야 하며, 추론 시점에 해당 카테고리에 대해 moderation label confidence가 90% 이상인 모든 이미지를 차단하고 로깅해야 합니다. 또한 base model을 재학습하지 않고 이를 수행해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 기본 모델을 변경하지 않고 generative AI 출력에 대해 추론 시점의 안전 제어와 거버넌스를 테스트합니다. 핵심 패턴은 사용자에게 표시되기 전에 생성/검색된 모든 이미지에 자동화된 content moderation(정책 집행)을 적용하고, 감사/컴플라이언스를 위해 집행 조치를 로깅하는 것입니다. 정답이 맞는 이유: 요구 사항은 명확합니다. 노골적인 누드, 잔혹한 폭력, 또는 자해가 포함된 이미지 중 moderation label confidence가 90% 이상인 것은 차단하고 로깅해야 하며, 이를 추론 시점에 base model 재학습 없이 수행해야 합니다. 선택지 A는 각 이미지 출력에 대해 스캔을 수행하고 임계값(≥90%) 기반으로 차단/블러 및 이벤트 기록을 하는 런타임 “safety filter”를 직접 구현합니다. 이는 이미지가 어떻게 생성되었는지(생성 또는 검색)와 무관하게 안전하지 않은 콘텐츠가 표시되지 않도록 하므로 임상 가이드라인 및 앱 스토어 정책 요구를 충족합니다. 주요 AWS 기능: Amazon Rekognition은 이미지에 대해 DetectModerationLabels를 제공하며, 라벨과 confidence score를 반환하므로 90% 임계값과 비교할 수 있습니다. 이를 추론 경로(예: Lambda/ECS/EKS middleware)에 구현하고 결과를 CloudWatch Logs, S3 또는 데이터베이스에 로깅하여 감사 추적을 만들 수 있습니다. Amazon Bedrock을 사용하는 경우 Guardrails는 런타임에 안전 정책을 집행하는 데 도움이 될 수 있습니다(주로 텍스트에 해당하며, 이미지는 일반적으로 Rekognition 같은 image moderation 또는 Bedrock 호환 moderation 워크플로와 함께 사용). 모범 사례로는 fail-closed 동작(moderation 실패 시 차단), 카테고리별 구성 가능한 임계값, 그리고 거버넌스를 위한 구조화된 로깅(라벨, confidence, 요청 메타데이터)이 포함됩니다. 흔한 오해: 재학습(B)은 위험을 줄일 수는 있지만 런타임 컴플라이언스를 보장할 수 없고 “재학습 없이”라는 제약을 위반합니다. 일회성 검증(C)은 필요할 수 있으나 generative 출력은 변동성이 크고 새로운 프롬프트로 출시 후에도 안전하지 않은 콘텐츠가 생성될 수 있으므로 충분하지 않습니다. 사용자 피드백 루프(D)는 지속적 개선에는 유용하지만 추론 시점에서 즉각적이고 결정론적인 차단을 제공하지 못합니다. 시험 팁: “추론 시점에 차단해야 함”, “confidence 임계값”, “재학습 없음”을 보면 런타임 guardrails/moderation 서비스를 선택하십시오. 이미지의 경우 Amazon Rekognition moderation labels를, foundation model 애플리케이션의 경우 Bedrock guardrails와 로깅/감사를 떠올리십시오. 컴플라이언스 및 거버넌스 요구 사항을 위해 항상 집행 + 관측성(로깅)을 포함하십시오.

문제 17

한 리테일 마켓플레이스가 foundation model을 사용하여 상품 사진을 200개 카테고리로 분류한다. 출시 전에 팀은 10,000개의 라벨링된 이미지로 구성된 held-out benchmark를 사용해 정확도를 검증하려고 하며, 목표는 top-1 accuracy가 최소 92%이다. 모델의 정확도를 평가하기 위한 가장 적절한 전략은 무엇인가?

문제 18

미디어 스트리밍 플랫폼이 3개 AWS Regions에 걸쳐 150개의 ML inference containers를 운영하며 분당 25,000건의 요청을 처리하고 있습니다. 이 워크로드에 대해 P95 latency, 5xx error rate, 그리고 GPU/CPU utilization을 중앙에서 추적하고 경고할 수 있는 고도로 확장 가능한 AWS 서비스를 필요로 합니다. 회사는 어떤 AWS 서비스를 사용해야 합니까?

문제 분석

핵심 개념: 이 문제는 AWS에서의 observability 및 운영 모니터링을 평가합니다—metrics를 수집하고, 다수의 containers와 Regions 전반에서 집계하며, percentiles(P95)를 생성하고, 임계값 기반 alerting을 구성하는 능력입니다. metrics, logs, dashboards, alarms를 위한 AWS 네이티브 서비스는 Amazon CloudWatch입니다. 정답이 맞는 이유: 플랫폼은 높은 요청량 환경에서 3개 Regions에 분산된 150개의 inference containers 전반에 대해 P95 latency, 5xx error rate, GPU/CPU utilization을 중앙에서 추적하고 alerting해야 합니다. CloudWatch는 높은 cardinality의 time-series metrics를 수집하도록 설계되어 있으며, 분포에 대한 statistics(분위수/percentiles 포함)를 계산하고 alarms를 트리거할 수 있습니다. custom metrics 또는 embedded metric format을 통해 application metrics(latency, HTTP 5xx)를 수집할 수 있고, CloudWatch Agent 및 Container Insights(ECS/EKS)를 통해 infrastructure/container metrics(CPU, memory, GPU)를 수집할 수 있습니다. multi-Region 운영을 위해 CloudWatch는 cross-account 및 cross-Region dashboards를 지원하며, Amazon SNS, OpsCenter 또는 incident tooling을 통해 alarms/notifications를 라우팅할 수 있습니다. 주요 AWS 기능: 1) CloudWatch Metrics + Alarms: P95 latency 및 5xx rate에 대한 alarms를 생성하고, metric math로 error rate(5xx/total)를 계산합니다. 2) Container Insights: container 및 node 단위 CPU/memory/network를 수집하고 EKS/ECS와 통합합니다. 3) GPU monitoring: GPU utilization을 custom metrics로 게시(예: CloudWatch Agent/telegraf/nvidia-smi exporters)하고 임계값에 대해 alarm을 설정합니다. 4) Dashboards 및 cross-Region 가시성: 모든 Regions를 보는 중앙 dashboards; 필요 시 cross-account observability로 중앙화합니다. 5) Anomaly Detection 및 Logs Insights(선택): latency regression을 탐지하고 상관관계를 위해 logs를 쿼리합니다. 흔한 오해: CloudTrail은 종종 monitoring과 혼동되지만, 성능 metrics가 아니라 API activity(누가 무엇을 했는지)를 기록합니다. Trusted Advisor는 best-practice checks 및 cost/security 권고를 제공하지만, 실시간 P95 latency 추적을 제공하지 않습니다. AWS Config는 리소스 configuration changes 및 compliance를 추적하며, runtime latency나 GPU utilization을 다루지 않습니다. 시험 팁: “track metrics”, “percentiles (P95)”, “alerting”, “dashboards”, “operational monitoring”이 보이면 기본적으로 CloudWatch를 선택합니다. audit/API history는 CloudTrail, configuration compliance/drift는 Config, account-level recommendations는 Trusted Advisor를 선택합니다. containerized ML inference에서는 Container Insights + model latency 및 GPU utilization을 위한 custom metrics가 흔한 패턴임을 기억하세요.

문제 19

한 healthtech startup이 3개 AWS Regions(us-east-1, eu-west-1, ap-southeast-1)에 걸쳐 다국어 증상 확인 chatbot과 제품 설명 생성기를 출시해야 합니다. 여러 provider의 최소 4가지 서로 다른 foundation models를 실험해야 하며, 내장 guardrails 및 retrieval-augmented generation 통합을 갖춘 serverless pay-per-request inference가 필요합니다. 또한 model hosting을 관리하지 않고 하루 500건에서 50,000건 요청까지 확장해야 합니다—이러한 generative AI 애플리케이션을 구축하고 확장하기 위해 foundation models에 대한 managed access를 제공하는 AWS service는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 model infrastructure를 프로비저닝하거나 운영하지 않고 foundation models(FMs)을 사용해 generative AI 애플리케이션을 구축하기 위한 AWS managed services 지식을 평가합니다. 핵심 요구사항은 “foundation models에 대한 managed access”이며, serverless, pay-per-request inference, 다중 모델 실험, 내장 safety 및 RAG 통합이 포함됩니다. 정답이 맞는 이유: Amazon Bedrock은 여러 provider의 다양한 foundation models에 API 기반으로 접근할 수 있게 해주는 AWS의 fully managed service입니다(예: Anthropic, Meta, Mistral, Amazon Titan, Cohere, Stability AI—제공 여부는 Region 및 시점에 따라 달라질 수 있음). 이는 여러 FMs를 빠르게 실험하고, generative AI 앱(chatbots, 콘텐츠 생성)을 배포하며, model hosting을 관리하지 않고 사용량을 확장해야 하는 시나리오에 정확히 부합합니다. Bedrock은 serverless이며 on-demand throughput을 지원하므로 하루 500~50,000 requests로 확장해야 한다는 요구사항과 일치합니다. 주요 AWS 기능: Bedrock은 (1) 일관된 API를 통해 provider 간 model 선택, (2) on-demand 및(필요 시) provisioned throughput 옵션, (3) 안전 정책을 적용하는 데 도움이 되는 Amazon Bedrock Guardrails를 통한 내장 guardrails(예: 주제 제한, PII 처리, toxicity filters), (4) Knowledge Bases for Amazon Bedrock을 통한 retrieval-augmented generation 지원을 제공하며, 이는 vector stores(예: Amazon OpenSearch Service 등)와 통합되어 enterprise data에 근거한 응답을 생성할 수 있습니다. 또한 healthtech 맥락에서 중요한 governance 및 auditing을 위해 AWS security primitives(IAM, KMS, CloudWatch, CloudTrail)와도 통합됩니다. 흔한 오해: Amazon Kendra는 “search + RAG”와 연관되어 자주 언급되지만, 이는 enterprise search service이지 managed multi-FM inference platform이 아닙니다. Amazon Comprehend는 generative text 생성이 아니라 classic NLP(entity extraction, sentiment, PII detection)를 위한 서비스입니다. Amazon Q Developer는 software development 작업을 위한 특화 assistant로, 다국어 증상 확인 및 제품 생성용의 범용 FM hosting/access 계층이 아닙니다. 시험 팁: “multiple foundation models”, “serverless pay-per-request inference”, “no model hosting”, “guardrails”, “RAG integrations”를 보면 시험은 Amazon Bedrock을 가리키는 것입니다. Bedrock(FM access + genAI 앱 구축)과 SageMaker(custom ML training/hosting), 그리고 search/NLP 포인트 서비스(Kendra/Comprehend)를 구분하세요. 또한 multi-Region 배포는 애플리케이션 아키텍처 선택이며, Bedrock은 지원되는 Regions에서 managed endpoints를 제공하고, 지연 시간과 복원력을 위해 앱 스택을 Region별로 배포합니다.

문제 20

Amazon Bedrock에서 호스팅되는 금융 자문 chatbot이 temperature=0.9 및 top_p=0.95로 호출될 때 500개 프롬프트에 대한 내부 평가에서 12%의 hallucination 비율을 보이며, 팀은 재학습하거나 foundation model을 변경하지 않고 24시간 내에 hallucination을 5% 미만으로 줄여야 합니다—무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon Bedrock의 foundation model에 대한 추론 시점 제어—특히 decoding 파라미터(temperature 및 top_p)가 출력 변동성과 hallucination 위험에 어떤 영향을 미치는지—를 평가합니다. 재학습, fine-tune, 또는 모델 변경이 불가능할 때 가장 빠른 레버는 생성 구성(generation configuration)입니다. 정답이 맞는 이유: temperature 0.9와 top_p=0.95는 token 선택에서 무작위성을 높여 다양하고 창의적인 출력을 유도합니다. 금융 자문 chatbot에서는 이러한 창의성이 종종 조작된 사실, 출처, 또는 과도하게 확신하는 잘못된 진술(hallucinations)로 나타납니다. temperature를 낮추면(예: ~0.2) sampling이 더 결정적이 되어 모델이 더 높은 확률의 token을 선택하고 더 보수적인 완성을 생성하도록 유도합니다. 이는 일반적으로 hallucination을 빠르게 줄이며, Bedrock 호출 파라미터를 변경하는 것만으로 즉시(수 분 내) 적용할 수 있어 24시간 제약을 충족합니다. 주요 AWS 기능: Amazon Bedrock runtime APIs는 temperature 및 top_p(nucleus sampling) 같은 추론 파라미터를 요청별(per-request) 또는 기본값(default)으로 구성할 수 있습니다. 팀은 동일한 평가 프롬프트에 대해 파라미터 세트를 A/B 테스트하여 hallucination 감소를 정량화할 수 있습니다. 프로덕션에서는 이러한 설정을 애플리케이션 계층 또는 오케스트레이션 구성 요소(예: Bedrock invocation wrapper)를 통해 일관되게 적용할 수 있으며, 기반 foundation model을 수정할 필요가 없습니다. 흔한 오해: “hallucinations는 더 나은 학습 데이터가 필요하다” 또는 “다른 모델이 필요하다”라고 생각하기 쉽지만, 문제는 재학습과 모델 변경을 명시적으로 금지합니다. 또 다른 오해는 Agents for Amazon Bedrock가 “학습을 감독한다”는 것인데, agents는 추론 시점에서 tool 사용, retrieval, action 실행을 오케스트레이션할 뿐 모델 학습을 수행하지 않습니다. retrieval-augmented generation (RAG) 및 guardrails도 hallucination을 줄일 수 있지만, 여기의 선택지는 가장 빠르고 확실한 변경인 decoding 무작위성 조정에 초점을 둡니다. 시험 팁: 제약 조건이 “재학습/fine-tuning 불가” 및 “빠르게 해결해야 함”이라면, 추론 시점 완화책을 찾으세요: temperature/top_p 낮추기, retrieval로 grounding 추가, guardrails 추가, citations 요구. 높은 temperature/top_p는 창의성을 증가시키고, 낮은 temperature는 결정성을 증가시키며—금융, 의료, 법률 같은 규제 도메인에 선호됩니다. 완화책을 제약과 타임라인에 매핑하세요: 파라미터 튜닝이 가장 빠르고 위험이 낮은 변경입니다.