연습 문제

문제 1

실시간 금융 뉴스 플랫폼은 하루에 약 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에 가깝습니다.

문제 2

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의 세분성 및 요청 구성에 관한 문제라는 단서이다.

문제 3

비디오 스트리밍 플랫폼이 악성 트래픽으로부터 콘텐츠 전송 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을 시사합니다.

문제 4

한 헬스케어 스타트업이 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 기반 요금 + 프롬프트 최적화가 일반적으로 가장 비용 효율적인 접근입니다.

문제 5

한 대학 연구팀이 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가 서비스가 객체를 읽을 수 있도록 허용하는지 확인해야 합니다.

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

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

문제 6

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

문제 7

지역 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입니다.

문제 8

한 지역 의료 서비스 제공업체가 대규모 언어 모델(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, 입력/출력 검증, 데이터 최소화)를 선택하십시오. 무작위성, 벤더/카탈로그 선택만으로 해결하려는 접근, 또는 피상적인 컨텍스트 축소를 주요 보안 대책으로 삼는 답은 피하십시오.

문제 9

한 지역 병원 네트워크가 Amazon Bedrock를 통해 Claude 3 Sonnet foundation model을 사용하여 고객 대상 Q&A assistant를 배포하고 있습니다. 팀은 custom fine-tuning 없이, Amazon S3에 비공개로 저장된 75,000개의 내부 정책 PDF에서 최신 사실을 기반으로 모델이 답변하길 원합니다. 또한 매일 밤 데이터 refresh와 응답 내 source citation을 원하며, 목표 latency는 2초 미만입니다. 어떤 솔루션이 이 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 custom fine-tuning 없이 Amazon S3에 저장된 비공개 엔터프라이즈 데이터를 기반으로 foundation model의 응답을 grounding하기 위해 Amazon Bedrock Knowledge Bases를 사용한 Amazon Bedrock의 retrieval-augmented generation (RAG)을 테스트합니다. 정답인 이유: 요구 사항은 Claude 3 Sonnet이 S3에 비공개로 저장된 75,000개의 내부 정책 PDF에서 최신 사실을 기반으로 답변하고, 매일 밤 refresh되며, 낮은 latency로 source citation을 포함하는 것입니다. S3 data source에 연결된 Bedrock knowledge base는 이를 위해 설계되었습니다. S3에서 문서를 ingest하고, chunking 및 indexing을 수행하여 vector store에 저장한 뒤, query 시점에 가장 관련성 높은 passage를 retrieve하여 model prompt에 주입합니다. 이러한 “grounding”은 custom fine-tuning 없이도 정확하고 최신의 답변을 가능하게 하며, retrieve된 source document를 참조하는 citations도 반환할 수 있습니다. 주요 AWS 기능: - Amazon Bedrock Knowledge Bases: 관리형 RAG workflow (ingestion, chunking, embeddings, retrieval, orchestration). - data source로서의 S3: PDF와 같은 대규모 문서 corpus를 지원하며, ingestion job을 스케줄링/트리거하여 nightly refresh를 수행할 수 있습니다. - vector store integration: Knowledge Bases는 지원되는 vector database( AWS-native 옵션 포함)를 사용할 수 있어 빠른 semantic retrieval을 가능하게 하며, 적절한 sizing과 tuning을 통해 2초 미만 latency 목표를 충족하는 데 도움이 됩니다. - Citations: Knowledge Bases는 retrieve된 reference/attribution을 반환할 수 있어 애플리케이션이 답변과 함께 source citation을 표시할 수 있습니다. - Security: IAM 기반 access control로 고객의 AWS account 내에서 데이터를 비공개로 유지하며, least privilege 및 data governance best practice에 부합합니다. 흔한 오해: model을 변경(A)한다고 해서 비공개이면서 최신인 내부 PDF에 대한 접근이 자동으로 제공되지는 않습니다. temperature(B)는 무작위성/창의성에 영향을 줄 뿐, 사실적 grounding이나 독점 데이터에 대한 접근을 제공하지 않습니다. invocation logging(D)은 observability/auditing을 위한 것이며 답변 정확도를 높이거나 citations를 추가하지 않습니다. 시험 팁: “private S3 documents”, “no fine-tuning”, “fresh data”, “citations”가 보이면 Bedrock Knowledge Bases (RAG)를 떠올리세요. fine-tuning은 지속적으로 업데이트되는 사실 corpus를 위한 것이 아니라 스타일/작업 적응을 위한 것입니다. 또한 latency 요구 사항은 수천 개 문서를 prompt에 그대로 넣는 방식이 아니라 retrieval + prompt augmentation을 의미하는 경우가 많습니다.

문제 10

대도시 공공 대중교통 기관은 고객 불만을 분류(triage)하고 올바른 부서로 라우팅하기 위해 large language model (LLM)을 배포할 계획이다. 6주 파일럿 동안 시스템은 5개 언어로 약 20,000건의 티켓을 처리할 예정이며, 기관은 서로 다른 인구통계학적 집단의 승객에 대한 편향(bias) 및 잠재적 차별(discrimination) 여부를 LLM 출력에서 평가해야 한다. 어떤 데이터 소스가 기관이 가장 적은 행정적 노력으로 LLM 출력을 평가할 수 있게 해주는가?

문제 분석

핵심 개념: 이 문제는 Responsible AI 평가를 테스트한다. 즉, 운영 오버헤드를 최소화하면서 편향/toxicity/fairness 평가를 가능하게 하는 평가 데이터셋을 선택하는 것이다. AWS 시험 맥락에서는, 맞춤형 레이블 데이터셋을 새로 구축하기보다 표준화되고 레이블이 있는 평가 리소스(종종 Amazon SageMaker Clarify 또는 모델 평가 파이프라인과 함께 사용됨)를 활용하는 것과 맞닿아 있다. 정답이 맞는 이유: 사전 정의된 레이블이 포함된 편향/toxicity/fairness용 공개 벤치마크 데이터셋은 이미 큐레이션되어 있고 문서화되어 있으며 특정 Responsible-AI 메트릭을 위해 레이블링되어 있으므로 행정적 노력이 가장 적다. 기관은 민감 속성(sensitive attribute) 분류 체계를 정의하거나, 인구통계 추론을 위한 동의를 수집하거나, 레이블링 프로그램을 먼저 만들 필요 없이, 인구통계 식별자 전반의 독성(toxicity) 차이, 고정관념(stereotyping) 프롬프트, 또는 fairness 슬라이스(slices) 같은 반복 가능한 평가를 빠르게 수행할 수 있다. 6주라는 짧은 파일럿과 약 20,000건의 티켓 규모에서는, 초기 편향/차별 신호를 가장 빠르게 얻는 경로가 확립된 벤치마크를 사용하는 것이다. 주요 AWS 기능 / 모범 사례: AWS에서 Responsible AI 평가는 일반적으로 다음을 활용한다: - 데이터셋 기반 편향 분석 및 슬라이스 메트릭(예: SageMaker Clarify 편향 메트릭 및 explainability 워크플로). - 고정된 벤치마크 데이터셋을 사용해 회귀(regression)를 추적하는 반복 가능한 평가 파이프라인(SageMaker Pipelines). - 거버넌스 관행: AWS Well-Architected ML 가이드(거버넌스, 모니터링, 지속적 평가)에 부합하도록 평가 데이터셋, 메트릭, 한계를 문서화(model cards / evaluation reports). 벤치마크는 모델 버전과 프롬프트 템플릿 간 비교를 표준화하는 데도 도움이 된다. 흔한 오해: 실시간 파일럿 티켓(A)이나 과거 로그(B)는 “현실 데이터”이므로 직관적으로 좋아 보일 수 있다. 그러나 편향 평가를 위해서는 보통 보호 속성(protected attributes)과 결과(outcomes)에 대한 ground-truth 레이블이 부족하며, 이를 책임 있게 사용하려면 추가적인 프라이버시 검토, 인구통계 레이블링/추론 결정, 사람에 의한 어노테이션이 필요해 행정적 작업이 크게 늘어난다. 정책 문서(C)는 요구사항에는 중요하지만 평가 데이터셋은 아니다. 시험 팁: 문제가 편향/toxicity/fairness 평가에서 “가장 적은 행정적 노력”을 강조하면, “사전 레이블된 벤치마크 데이터셋” 또는 “표준 평가 세트”를 찾는다. 현실 데이터는 이후 도메인 특화 검증에 유용하지만, 보통 레이블링, 프라이버시, 거버넌스 단계 때문에 노력이 증가한다. “요구사항/정책”과 “평가 데이터”를 구분하라.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(11)

다른 모의고사

Practice Test #2

지금 학습 시작하기