CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Machine Learning Engineer
Google Professional Machine Learning Engineer

Practice Test #3

50개 문제와 120분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제120분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1

You deployed a TensorFlow recommendation model to a Vertex AI Prediction endpoint in us-central1 with autoscaling enabled. Over the last week, you observed sustained traffic of ~1,200 requests per hour (about 20 RPS) during business hours, which is 2x higher than your original estimate, and you need to keep P95 latency under 150 ms during future surges. You want the endpoint to scale efficiently to handle this higher baseline and upcoming spikes without causing user-visible latency. What should you do?

같은 endpoint에 두 번째 model을 배포하는 것은 주로 A/B testing, canarying, 또는 traffic splitting을 통한 점진적 rollout을 위한 것입니다. 총 replica를 늘리지 않는 한 서빙 capacity 증가나 P95 latency 감소를 본질적으로 보장하지 않습니다. 또한 warm baseline capacity 필요를 직접 해결하지 못한 채 운영 복잡성(두 model version, 두 deployment 모니터링)만 증가시킵니다.

minReplicaCount를 설정하면 일정 수의 replica가 항상 실행 중이며 서빙 준비가 되어 있어 cold-start/warm-up 지연을 방지하고 예측 가능한 업무 시간 부하 동안 queueing을 줄일 수 있습니다. 이는 트래픽이 예상보다 지속적으로 높을 때 tail latency(P95)를 보호하는 표준 접근입니다. autoscaling은 향후 surge에 대비해 minimum을 초과하여 replica를 추가로 늘릴 수 있습니다.

target utilization percentage를 높이면 scale-out이 지연되어 각 replica가 더 높은 부하로 동작한 뒤에야 새 replica가 추가됩니다. 이는 spike 동안 queueing을 증가시키고 P95 latency를 150 ms SLO 이상으로 밀어 올릴 수 있습니다. replica 수를 줄여 비용을 낮출 수는 있지만, surge 동안 사용자에게 보이는 latency를 피해야 한다는 요구사항과 충돌하며, 엄격한 latency 목표에서는 일반적으로 원하는 방향의 반대입니다.

GPU-accelerated machine으로 전환하면 compute-heavy model의 inference 시간을 줄일 수 있지만, warm capacity 부족으로 인한 scaling/latency 문제에서 첫 번째로 조정할 레버는 아닙니다. GPU는 비용을 증가시키고 us-central1에서 quota/가용성 제약이 있을 수 있습니다. 충분한 CPU replica가 warm 상태일 때 이미 latency를 충족한다면, GPU는 autoscaling 반응 시간이나 cold-start 효과를 해결하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Vertex AI Prediction 온라인 서빙의 autoscaling 동작과 더 높은 steady-state 부하에서 latency SLO를 충족하는 방법을 평가합니다. 핵심 조정 요소는 minimum/maximum replica 수와 autoscaling 신호(utilization/QPS)이며, 이는 cold-start 위험과 tail latency에 직접적인 영향을 줍니다. 정답이 맞는 이유: 지속적인 새로운 baseline(업무 시간 동안 약 20 RPS)이 기존 추정치의 2배인 상황에서, 순수하게 reactive autoscaling에만 의존하면 replica가 부족한 구간이 발생할 수 있고, 그로 인해 queueing 및 cold-start/warm-up 지연이 생겨 P95 latency가 증가합니다. 새로운 baseline에 맞춰 minReplicaCount를 설정하면 steady traffic과 작은 surge를 즉시 흡수할 수 있도록 충분한 replica가 항상 프로비저닝(“warm”)된 상태로 유지됩니다. autoscaling은 더 큰 spike에 대해 replica를 추가로 늘릴 수 있지만, 최소치(floor)가 새 replica가 시작되는 동안 사용자에게 보이는 latency를 방지합니다. 주요 기능 / Best Practices: - 관측된 replica당 steady-state 처리량과 latency 여유(headroom)를 기반으로 minReplicaCount를 구성합니다. load testing을 통해 P95 < 150 ms에서 안전한 RPS/replica를 산정합니다. - 예상되는 surge에 대비해 maxReplicaCount를 충분히 높게 설정하고, quota(CPU/GPU, regional)가 이를 지원하는지 확인합니다. - endpoint metric(latency percentile, replica 수, utilization, request backlog/error)를 모니터링하고 조정합니다. - 이는 Google Cloud Architecture Framework의 reliability 및 performance 원칙(예측 가능한 부하는 사전 프로비저닝, 변동성은 autoscale, SLO 충족을 위한 설계)과 일치합니다. 흔한 오해: 비용을 아끼기 위해 “나중에 scale”하는 것(option C)은 유혹적이지만 spike 동안 latency를 악화시킵니다. 또한 다른 model을 추가하는 것(option A)은 더 많은 replica로 이어지지 않는 한 capacity를 늘리지 못하며 routing/versioning을 복잡하게 만듭니다. GPU(option D)는 일부 model에서 요청당 latency를 줄일 수 있지만 cold-start를 해결하지 못하고, 이미 적절히 프로비저닝되면 latency를 충족하는 TensorFlow recommender에 불필요하거나 비용이 클 수 있습니다. Exam Tips: 온라인 prediction에서 지속적인 baseline traffic과 엄격한 tail-latency 목표가 보이면 “baseline을 커버하도록 min replicas 설정”과 “spike는 autoscale로 대응”을 떠올리세요. GPU는 profiling 결과 inference가 compute-bound이고 CPU로는 합리적인 replica 수에서 latency를 맞출 수 없을 때만 사용하세요. 선택한 region에서 warm capacity, scaling 반응 시간, quota를 항상 함께 고려하세요.

2
문제 2

You are part of a data science team at a ride‑sharing platform and need to train and compare multiple TensorFlow models on Vertex AI using 850 million labeled trip records (≈2.3 TB) stored in a BigQuery table; training will run on 4–8 workers and you want to minimize data‑ingestion bottlenecks while ensuring the pipeline remains scalable and repeatable. What should you do?

2.3 TB를 pandas DataFrame으로 로드하는 것은 현실적으로 불가능합니다(메모리 한계, 단일 노드 병목) 그리고 4–8 분산 워커로 확장되지 않습니다. tf.data.Dataset.from_tensor_slices()는 작은 인메모리 데이터셋이나 프로토타입에 적합하며, 프로덕션 규모 학습에는 적합하지 않습니다. 또한 이 접근은 매 실행마다 데이터셋을 메모리에서 다시 구성해야 하므로 반복성과 장애 허용을 어렵게 만듭니다.

Cloud Storage로 CSV를 export하면 BigQuery와의 분리는 개선되지만, 이 규모의 ML 학습에는 CSV가 비효율적입니다. 텍스트 파싱은 CPU를 많이 사용하고, 파일은 바이너리 포맷보다 크며, 스키마/타이핑 문제가 흔합니다. tf.data.TextLineDataset는 병렬화할 수 있지만, 전체 처리량은 일반적으로 TFRecord보다 낮아 멀티 워커 학습에서 입력 병목 위험이 커집니다.

Cloud Storage의 샤딩된 TFRecords는 고처리량 TensorFlow 학습을 위한 모범 사례 포맷입니다. 샤딩(예: 1–2 GB)은 워커 간 병렬 읽기를 가능하게 하고, 단일 파일 경합을 줄이며, 동일한 불변 데이터셋 버전을 재사용함으로써 반복 가능한 실험을 지원합니다. TFRecordDataset를 parallel interleave 및 prefetch와 함께 사용하면 I/O와 연산을 겹쳐 실행하여 데이터 수집 병목을 최소화하고 확장성을 개선합니다.

학습 중 BigQuery에서 직접 스트리밍하면 BigQuery 읽기 처리량 제한, 동시성/quota, 요청당 오버헤드 때문에(특히 여러 워커에서) 수집 병목이 발생할 수 있습니다. 또한 학습 안정성을 BigQuery 가용성과 query 성능에 결합시켜 반복성을 떨어뜨립니다. TensorFlow I/O는 더 작은 데이터셋이나 실험에는 동작할 수 있지만, TB 규모 멀티 워커 학습에서는 일반적으로 효율적인 포맷으로 Cloud Storage에 물리화하는 것이 더 안전합니다.

문제 분석

핵심 개념: 이 문제는 Vertex AI에서 분산 TensorFlow 학습을 위한 확장 가능한 입력 파이프라인을 평가합니다. 핵심은 학습을 소스 시스템(BigQuery)과 분리하고, 효율적이며 병렬화 가능한 파일 포맷과 tf.data 모범 사례를 사용하여 멀티 워커 규모에서 입력 병목을 피하는 것입니다. 정답이 맞는 이유: 850M 행(~2.3 TB)과 4–8 워커 환경에서 BigQuery에서 직접 스트리밍하거나 단일 노드 구조로 물리화하면 네트워크, 요청당 오버헤드, 그리고/또는 BigQuery 동시성 제한으로 인해 병목이 발생합니다. Cloud Storage의 샤딩된 TFRecords는 표준적이고 반복 가능한 “학습 준비 완료(training-ready)” 데이터셋 포맷입니다. 이는 고처리량 순차 읽기, 워커 간 쉬운 병렬화, 실험 간 결정적 재사용을 가능하게 합니다. 적절한 샤딩(예: 1–2 GB)은 메타데이터 오버헤드(너무 많은 작은 파일)와 병렬성(너무 적은 큰 파일) 사이의 균형을 맞춥니다. tf.data.TFRecordDataset를 parallel interleave, map, prefetch와 함께 사용하면 I/O와 연산을 겹쳐 실행할 수 있어 accelerator/CPU 활용률을 극대화합니다. 주요 기능 / 모범 사례: - 학습 데이터를 Cloud Storage에 바이너리, 분할 가능한 포맷(TFRecord)으로 저장하고 필요 시 압축(예: GZIP)을 사용합니다. - 많은 샤드를 사용하고 각 워커가 서로 다른 샤드를 읽도록(파일 패턴 및 dataset sharding 옵션을 통해) 하여 경합을 줄입니다. - tf.data 최적화를 사용합니다: parallel_interleave(또는 num_parallel_calls를 사용하는 Dataset.interleave), AUTOTUNE을 사용하는 map, prefetch(AUTOTUNE), 그리고 적합한 경우에만 cache를 선택적으로 사용합니다. - 파이프라인을 반복 가능하게 만듭니다: BigQuery에서 TFRecords로의 1회(또는 스케줄된) export/transform 단계를 오케스트레이션(예: Vertex AI Pipelines / Dataflow)하고 버전 관리할 수 있습니다. 흔한 오해: - “BigQuery에서 직접 읽기”는 편리해 보이지만, 학습 처리량을 BigQuery 읽기 성능, quota, 그리고 일시적인 query/streaming 동작에 결합시키므로 대규모에서는 위험합니다. - “CSV는 범용”이지만 비효율적입니다: 큰 텍스트 파싱 오버헤드, 더 큰 저장 공간, 더 느린 입력 파이프라인. - “pandas로 로드”는 흔한 프로토타입 패턴이지만, 멀티 TB 데이터셋과 분산 학습에서는 실패합니다. 시험 팁: Vertex AI에서 대규모 학습을 할 때는 Cloud Storage + TFRecords(또는 유사하게 효율적인 포맷)와 tf.data 성능 패턴을 선호하세요. 데이터 준비를 학습과 분리하고, 멀티 워커 병렬 읽기를 지원하며, 레코드당 파싱 오버헤드를 최소화하는 아키텍처를 선택하세요. TB 규모 데이터와 여러 워커가 보이면 pandas를 피하고, 명시적으로 요구되지 않는 한 텍스트 포맷을 피하세요.

3
문제 3

You are designing a TensorFlow Extended (TFX) pipeline with standard TFX components for a global media-streaming platform that analyzes user interaction logs; the pipeline includes feature engineering and data validation steps, and after promotion to production it must process up to 120 TB of historical clickstream data per day stored in BigQuery across 12 daily partitions (with an additional 2 TB ingested each day); you need the preprocessing steps to scale efficiently, automatically publish metrics and parameters to Vertex AI Experiments, and track all artifacts with Vertex ML Metadata. How should you configure the pipeline run?

Vertex AI Pipelines는 올바른 orchestrator이지만, distributed Vertex AI Training job을 구성하는 것은 모델 training 규모를 다루는 것이지, 무거운 preprocessing/validation workload를 다루는 것이 아닙니다. TFX preprocessing component(Transform, StatisticsGen, ExampleValidator)는 Beam 기반이며 scalable Beam runner가 필요합니다. Beam을 Dataflow에서 명시적으로 실행하지 않으면 preprocessing이 로컬 또는 제한된 리소스에서 실행되어 하루 120 TB에서 bottleneck이 될 수 있습니다.

이는 의도된 아키텍처와 일치합니다: Vertex AI Pipelines(managed orchestration + ML Metadata integration)로 표준 TFX pipeline을 orchestration하고, Apache Beam pipeline_args를 구성하여 Beam 기반 component가 Dataflow에서 실행되도록 합니다. Dataflow는 TB 규모 BigQuery partition에 적합한 autoscaling과 distributed processing을 제공합니다. 이는 preprocessing의 효율적 확장을 가장 잘 충족하면서 Vertex AI Pipelines run과 정렬된 Vertex AI Experiments/MLMD 통합을 유지합니다.

Dataproc는 Spark/Hadoop workload를 실행할 수 있고 custom orchestration을 호스팅할 수 있지만, Dataproc에서 Beam TFX orchestrator를 사용하는 것은 Google Cloud에서 TFX를 위한 표준 managed 경로가 아닙니다. 이는 운영 오버헤드(cluster lifecycle, scaling, upgrade)를 증가시키고, 네이티브 Vertex AI Pipelines + Dataflow runner 접근과 비교해 Vertex AI Pipelines, Experiments, ML Metadata와의 “자동” 통합 스토리를 약화시킵니다.

TFX orchestrator 자체를 Dataflow에서 실행하는 것은 일반적이거나 권장되는 패턴이 아닙니다. Dataflow는 multi-step ML pipeline의 primary orchestrator로서 artifact lineage와 experiment tracking을 제공하기보다는, Beam pipeline(데이터 처리 단계)을 실행하도록 설계되었습니다. 이 옵션은 또한 Vertex AI Pipelines가 제공하는 managed orchestration, UI, 그리고 MLMD 우선 통합을 잃을 위험이 있습니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 표준 TFX pipeline을 실행하여 (1) 대규모 preprocessing/validation이 탄력적으로 확장될 수 있고, (2) 실행이 orchestration, Experiments tracking, 그리고 ML Metadata artifact lineage를 위해 Vertex AI와 네이티브하게 통합되도록 하는 방법을 평가합니다. 정답이 맞는 이유: Vertex AI Pipelines는 Google Cloud에서 TFX를 위한 managed orchestration 계층이며 artifact tracking을 위해 Vertex ML Metadata와 통합됩니다. 제시된 규모( BigQuery의 partition 전반에 걸쳐 하루 최대 약 120 TB)에서 preprocessing과 validation을 수행하려면, 핵심 요구사항은 TFX의 Beam 기반 component(예: BigQuery를 사용하는 ExampleGen, StatisticsGen, SchemaGen, ExampleValidator, Transform)를 확장 가능한 distributed runner에서 실행하는 것입니다. Apache Beam pipeline arguments를 Dataflow runner를 사용하도록 구성하는 것이 표준적인 best practice 접근입니다. Dataflow는 Beam에 대해 autoscaling, parallelism, managed execution을 제공하며, 이는 해당 component들이 내부적으로 사용하는 방식과 정확히 일치합니다. 주요 기능 / 구성: - MLMD integration과 재현 가능한 run을 얻기 위해 Vertex AI Pipelines(managed Kubeflow Pipelines)로 orchestration합니다. - Beam pipeline_args를 Dataflow에 맞게 설정합니다(runner=DataflowRunner, project, region, temp_location, staging_location, service_account, 필요 시 network/subnetwork, worker 설정, autoscaling). 이렇게 하면 Transform/validation 단계가 TB 규모 데이터로 확장됩니다. - Vertex AI Pipelines/TFX integration을 사용해 run parameter와 metric을 게시합니다. Experiments tracking은 pipeline step이 metric/param을 Vertex AI에 로깅할 때(종종 built-in integration 또는 custom component를 통해) 가장 잘 달성되며, MLMD는 artifact와 lineage를 캡처합니다. 흔한 오해: Option A는 “distributed training”이 중요하다는 점 때문에 그럴듯해 보이지만, 설명된 bottleneck은 모델 training이 아니라 방대한 BigQuery 데이터에 대한 preprocessing/validation입니다. Distributed training은 Beam 기반 데이터 처리를 자동으로 확장하지 않습니다. Options C와 D는 Dataproc/Dataflow에서 Beam orchestrator를 직접 사용하는 것을 제안하지만, 이는 Vertex AI Pipelines의 managed orchestration과 MLMD/Experiments의 긴밀한 통합을 활용하면서 표준 TFX component를 사용해야 한다는 핵심 요구사항을 우회합니다. 시험 팁: - Google Cloud에서 TFX: orchestrator는 Vertex AI Pipelines, Beam 기반 TFX component를 위한 scalable runner는 Dataflow입니다. - TB 규모 feature engineering/validation을 보면 “더 큰 training job”이 아니라 “Dataflow에서 Beam”을 떠올리세요. - 요구사항을 계층에 매핑하세요: orchestration(Vertex AI Pipelines), data processing(Dataflow), metadata/lineage(Vertex ML Metadata), experiment tracking(Vertex AI Experiments).

4
문제 4

You are part of an operations team managing a fleet of 250 refrigerated delivery trucks. Each truck’s refrigeration unit streams telemetry at 10-second intervals, including compressor current (A), condenser coil temperature (°C), discharge pressure (kPa), and vibration RMS (g), resulting in roughly 14 months of historical data per truck. No breakdowns or incident events have been hand-labeled yet. Management asks for a predictive maintenance solution that can detect potential refrigeration unit failures with at least a 24-hour lead time so that routes can be rescheduled. What should you do first?

정답. 예측 기반 이상 탐지는 라벨링된 고장 없이도 정상적인 시간적 동작을 학습하고 큰 residual에 대해 알림을 발생시킬 수 있습니다. 즉각적인 가치를 제공하고, 미래를 예측함으로써 24시간 리드 타임을 지원하며, 이후 확인/라벨링을 위한 후보 인시던트를 표면화하는 파이프라인을 만듭니다. 텔레메트리만 존재하는 예지정비에서 표준적인 첫 단계입니다.

예지정비 솔루션의 첫 단계로는 최선이 아닙니다. 순수 휴리스틱은 빠르게 배포할 수 있지만 취약하고, 트럭과 계절 전반에 걸쳐 지속적인 튜닝이 필요하며, 많은 false positive/negative를 유발하는 경우가 많습니다. 또한 시간적 동역학을 잘 활용하지 못하고, 단순 임계값 초과를 넘어서는 신뢰할 만한 24시간 조기 경보를 제공하지 못할 수 있습니다.

매력적이지만 위험합니다. 휴리스틱으로 생성한 라벨로 학습하면 모델이 실제 고장 전조를 학습하기보다 휴리스틱을 복제하는 경우가 많습니다. 이로 인해 오프라인 지표가 실제 고장이 아니라 휴리스틱을 반영하므로 모델 품질에 대한 잘못된 확신을 만들 수 있습니다. 이후 weak supervision으로는 유용할 수 있지만, 실제로 확인된 이벤트로 검증을 확립한 뒤에야 적절합니다.

첫 단계로는 비현실적이며 필요하지도 않습니다. 250대 트럭의 14개월 고주파 텔레메트리를 수작업으로 라벨링하는 것은 비용이 많이 들고 느리며, “고장”과 리드 타임 윈도우에 대한 명확한 정의가 없으면 모호합니다. 더 나은 접근은 비지도 탐지로 시작해 triage하고, 전문가 리뷰를 위해 훨씬 더 작은 구간 집합을 우선순위화하는 것입니다.

문제 분석

핵심 개념: 이 문제는 텔레메트리는 풍부하지만 라벨링된 고장 이벤트가 없을 때 예지정비 이니셔티브를 어떻게 시작하는지 평가합니다. 이런 상황에서 첫 번째로 실용적인 ML 접근은 지도 분류보다는 시계열에 대한 비지도 또는 self-supervised 이상 탐지/예측인 경우가 일반적입니다. 정답이 맞는 이유: 수작업으로 라벨링된 고장 데이터가 없으면 지도 학습 기반의 “24시간 내 고장” 분류기를 직접 학습할 수 없습니다. 강력한 첫 단계는 신호별(또는 다변량) 시계열 예측 baseline을 구축하고 통계적으로 유의미한 residual(실제값 - 예측값)에 대해 알림을 발생시키는 것입니다. 이는 초기 탐지 역량을 제공하고, 더 중요하게는 조사 및 향후 라벨링을 위한 후보 인시던트를 생성하는 메커니즘을 만듭니다. 또한 비즈니스 요구사항(24시간 리드 타임)과도 부합합니다. 24시간 이상을 미리 예측하고 정상 운전 범위를 벗어날 가능성이 높은 추세를 플래그할 수 있기 때문입니다. 핵심 기능 / 모범 사례: 트럭별 holdout 기간을 두고 residual 분포를 평가하여 false positive를 제어하는 임계값을 설정합니다. 계절성(외기 온도, 경로 패턴)과 자산별 정규화를 고려합니다. Google Cloud에서는 일반적으로 Vertex AI(커스텀 트레이닝 또는 적용 가능한 경우 AutoML tabular/time-series)와 함께, 과거 집계를 위한 feature store 또는 BigQuery, 운영화를 위한 Cloud Monitoring/Alerting으로 구현합니다. 아키텍처 관점에서는 단순하고 설명 가능한 baseline(Architecture Framework: reliability 및 operational excellence)으로 시작해 반복적으로 개선합니다. 흔한 오해: 규칙 기반 휴리스틱(B)은 빠르기 때문에 매력적일 수 있지만, 취약하고 트럭 및 계절 전반에 걸쳐 지속적인 튜닝이 필요하며 false positive/negative가 많이 발생하는 경우가 많습니다. 또한 다변량 패턴과 drift를 놓치기 쉽습니다. 휴리스틱으로 라벨을 만든 뒤 모델을 학습하는 방식(C)은 실제 고장이 아니라 “휴리스틱을 학습”할 위험이 있어, 현실 성능이 낮은 과신 모델을 만들 수 있습니다. 전수 수작업 라벨링(D)은 특히 명확한 고장 정의가 없을 때 비용과 시간이 과도하게 들고 진행이 느립니다. 시험 팁: 라벨이 없을 때는 라벨링을 위한 피드백 루프를 부트스트랩하기 위해 비지도/self-supervised 접근(예측, reconstruction error, 클러스터링)을 먼저 선호합니다. 반복 가능한 경로를 만드는 선택지를 찾으세요: baseline 탐지 → 확인된 이벤트 수집 → 지도 예측으로 고도화. 또한 비용, time-to-value, 유지보수성 같은 운영 제약도 고려하세요.

5
문제 5

A logistics platform has trained three versions of an ETA prediction model (v1, v2, v3), imported them into Vertex AI Model Registry, and deployed them to a single online prediction endpoint; you expect about 120,000 prediction requests per day and want to run a 7-day A/B/n test by initially routing 50%/25%/25% of traffic to v1/v2/v3 while tracking per-version accuracy and p95 latency with the least engineering overhead. What should you do to identify the best-performing model using the simplest approach?

정답. Vertex AI Endpoints는 여러 model version을 배포하고 A/B/n 테스트를 위한 weighted traffic splitting(예: 50/25/25)을 구성할 수 있습니다. Cloud Monitoring 통합을 통해 p95 latency 같은 serving metrics를 모니터링할 수 있고, prediction logging을 사용해 ground truth가 확보되면 각 deployed model/version에 요청을 귀속시켜 accuracy 분석을 수행할 수 있습니다. 이는 minimal custom infrastructure로 가능한 가장 단순한 managed 접근입니다.

오답. GKE와 Traffic Director는 정교한 traffic management가 가능하지만, cluster 운영, service mesh/proxy 구성, scaling, security hardening 등 상당한 엔지니어링 오버헤드를 유발합니다. 또한 Vertex AI Endpoints가 이미 제공하는 multi-model deployment 및 traffic splitting 기능을 중복 구현하게 됩니다. 단순성과 기존 Vertex AI 배포를 강조하는 시험 시나리오에서는 과도한 설계입니다.

오답(“가장 단순한 접근”으로는 부적절). 로그를 export하고 Looker Studio dashboard를 구축하는 방식은 특히 accuracy 분석에 활용될 수 있지만, 추가 단계와 지속적인 유지보수(log sink, schema 관리, dashboard 유지)가 필요합니다. 또한 이것만으로는 traffic splitting을 해결하지 못하며, 별도의 routing mechanism이 여전히 필요합니다. Vertex AI의 built-in endpoint traffic splitting과 monitoring은 core serving metrics에 대해 custom dashboard 필요성을 줄여줍니다.

오답. Cloud Run revision 간 traffic splitting은 web service에 유용하지만, 버전별로 자체 model server를 패키징/운영하고 autoscaling 동작을 처리하며, 일관된 model loading과 성능을 보장해야 합니다. 모델이 이미 Vertex AI Model Registry에 있고 Vertex endpoint에 배포되어 있으므로, Cloud Run으로 이동하면 엔지니어링 노력이 증가하고 Vertex AI의 목적 특화된 model deployment 및 management 기능을 잃게 됩니다.

문제 분석

핵심 개념: 이 문제는 Vertex AI online prediction 배포 패턴을 테스트합니다. 단일 Endpoint에 여러 deployed model(또는 model version)을 배포하고, Endpoint traffic splitting을 사용해 A/B/n 실험을 수행하면서, 최소한의 custom infrastructure로 운영 지표(latency)와 결과 지표(accuracy)를 관찰하는 방식입니다. 정답인 이유: 옵션 A는 Vertex AI Endpoint weighted traffic splitting을 사용해 v1/v2/v3로 50%/25%/25% 트래픽을 라우팅합니다. 이는 트래픽 관리가 Vertex AI Endpoints의 first-class feature이기 때문에 가장 단순하고 오버헤드가 가장 낮은 접근입니다. 하나의 endpoint에 여러 model을 배포하고 deployed model별 트래픽 비율을 설정할 수 있습니다. p95 latency의 경우 Vertex AI는 Cloud Monitoring/Cloud Logging과 통합되어 custom serving stack을 구축하지 않고도 request/response 및 serving metrics를 제공합니다. 버전별 accuracy는 prediction logging을 통해 prediction을 deployed model ID/version에 귀속시킨 뒤, label이 도착하면(ETA 문제에서 흔함) ground truth와 비교할 수 있어, bespoke routing layer 대신 managed logging/monitoring을 활용함으로써 엔지니어링을 최소화합니다. 주요 기능 / Best Practices: - Vertex AI Endpoint trafficSplit: deployed model별 weight를 구성해 A/B/n testing을 수행하고 점진적으로 조정( canary-style rollout 지원). - Prediction logging: request/response logging을(적절한 privacy control과 함께) 활성화하여 prediction을 이후 도착하는 실제 ETA와 조인해 model version별 accuracy를 산출. - Cloud Monitoring metrics: latency distribution(p95 포함), error rate, throughput을 endpoint별로 모니터링하고, (labels/deployed_model_id를 통해) deployment별로도 모니터링. - Architecture Framework 정렬: operational excellence(관리형 serving, 더 적은 구성요소), reliability(Google-managed autoscaling), cost optimization(추가 cluster/service 불필요). 흔한 오해: A/B 테스트를 위해 GKE/Traffic Director 또는 Cloud Run traffic splitting을 반드시 사용해야 한다고 생각하기 쉽습니다. 이는 범용적으로는 유효한 패턴이지만, Vertex AI가 이미 model-level traffic splitting과 managed observability를 제공하는 상황에서는 불필요한 구성요소를 추가하게 됩니다. 또 다른 오해는 “accuracy monitoring”이 Vertex AI에서 완전 자동화되어야 한다는 것입니다. 실제로 accuracy는 종종 prediction을 나중에 들어오는 ground truth와 조인해야 하지만, Vertex AI logging을 사용하면 custom router를 만들지 않고도 이를 쉽게 수행할 수 있습니다. Exam Tips: 문제에서 “least engineering overhead”를 강조하고, 모델이 이미 Vertex AI Model Registry에 있으며 단일 endpoint에 배포되어 있다면, native Vertex AI Endpoint 기능(여러 deployment + traffic split + managed monitoring/logging)을 우선 선택하세요. custom serving logic, non-Vertex runtime, 또는 Vertex AI의 managed serving을 넘어서는 advanced mesh feature가 필요할 때만 GKE/Cloud Run/Traffic Director를 고려하세요.

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

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

6
문제 6

Your supply chain analytics team plans to run 180 training jobs per day for 10 days (3 feature sets × 4 model architectures × 15 hyperparameter grids) using containerized trainers; they must log per-run metrics (AUC, F1, and loss) with timestamps and be able to query trends over time (for example, 7-day rolling averages and the top 10 configurations by mean F1 in the last 30 days) via an API while minimizing manual effort. Which approach should they use to track and report these experiments?

Vertex AI Pipelines는 오케스트레이션과 반복성 측면에서는 강력하지만 분석 datastore는 아닙니다. pipeline run이 메트릭을 기록할 수는 있지만, Pipelines API로 복잡한 트렌드(7일 이동 평균, 여러 차원에 걸친 최근 30일 평균 기준 top-N)를 쿼리하는 것은 번거롭고 최적화된 용도가 아닙니다. 일반적으로 리포팅을 위해 Pipelines API에 의존하기보다는 pipeline metadata를 BigQuery 또는 다른 저장소로 export하여 분석합니다.

Vertex AI Training은 컨테이너화된 트레이너를 대규모로 실행하며, BigQuery는 타임스탬프와 풍부한 메타데이터가 포함된 실행별 메트릭을 저장하기에 이상적입니다. BigQuery SQL은 이동 평균을 위한 window function, 시간 필터링(최근 30일), 랭킹(상위 10개 구성)을 지원합니다. 시간 기준 partitioning과 구성 필드 기준 clustering은 비용을 최소화하고 성능을 개선합니다. BigQuery API는 최소한의 수작업으로 프로그래밍 방식 접근을 가능하게 합니다.

Cloud Monitoring custom metrics는 심층 실험 분석이 아니라 운영 telemetry, 대시보드, 알림을 위해 설계되었습니다. 높은 cardinality label(feature set, architecture, hyperparameter grid, run_id)은 quota에 걸리거나 비용이 증가하거나 관리가 어려워질 수 있습니다. “최근 30일 평균 F1 기준 top 10 구성”을 쿼리하고 여러 차원에 걸쳐 이동 평균을 계산하는 작업은 Monitoring의 time-series 모델보다 BigQuery에서 더 자연스럽습니다.

Workbench notebooks + Google Sheets는 수작업 비중이 크고, 하루 180회 실행을 신뢰성 있고 일관되게 로깅하는 방식으로는 확장되지 않습니다. Sheets는 강력한 schema 강제, lineage 추적, rolling window 및 대규모 데이터셋에서의 top-N에 대한 효율적인 분석 쿼리를 제공하지 않습니다. 또한 협업 및 데이터 무결성 리스크를 유발합니다. 이 옵션은 수작업 최소화 요구사항을 위반하며, 프로덕션급 실험 추적과도 부합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 대규모 ML 학습 실행에 대한 실험 추적과 시계열 분석을 테스트합니다. 핵심 요구사항은: (1) 타임스탬프가 포함된 실행별 메트릭의 자동 수집, (2) 트렌드(이동 평균, 시간 윈도우 기준 top-N) 분석을 위한 유연한 쿼리, (3) 최소한의 수작업으로 가능한 API 접근입니다. 정답이 맞는 이유: 옵션 B가 가장 적합한 이유는 BigQuery가 대규모 append-only 데이터셋에 대한 분석 쿼리를 위해 설계되었고, 이동 평균을 위한 SQL window function, 기간 제한 집계(예: 최근 30일), 랭킹(평균 F1 기준 top 10 구성) 등을 지원하기 때문입니다. 실행마다 한 행(run_id, feature_set, architecture, hyperparameter_grid_id, timestamp, auc, f1, loss, 그리고 메타데이터)을 기록하면 트렌드 분석과 BigQuery API(또는 얇은 서비스 레이어)를 통한 결과 제공이 간단해집니다. 이는 Google Cloud Architecture Framework의 운영 우수성(반복 가능한 수집), 성능 효율성(columnar analytics), 신뢰성(내구성 있는 저장)과도 부합합니다. 주요 기능 / 모범 사례: 컨테이너 기반 커스텀 학습 작업을 위해 Vertex AI Training을 사용하고, 각 실행 종료 시(또는 주기적으로) 경량 클라이언트 또는 Cloud Logging sink + Dataflow/BigQuery를 통해 BigQuery로 메트릭을 내보내세요. 비용을 제어하고 쿼리 성능을 개선하기 위해 테이블을 날짜/타임스탬프로 partitioning하고 모델/feature 식별자로 clustering하세요. 재현성을 위해 일관된 schema를 강제하고 실행 계보 필드(dataset version, code version, container image digest)를 포함하세요. 흔한 오해: Cloud Monitoring(옵션 C)은 운영 모니터링과 알림에는 훌륭하지만, 여러 차원에 걸친 이동 평균이나 장기간 윈도우에서 평균 기준 top-N 같은 복잡한 분석 쿼리에는 적합하지 않습니다. 또한 custom metrics에는 cardinality 및 quota 고려사항이 있습니다. Vertex AI Pipelines(옵션 A)은 워크플로 오케스트레이션을 하지만, Pipelines API는 임의의 메트릭 트렌드 쿼리를 위한 분석 저장소로 의도된 것이 아닙니다. Sheets(옵션 D)는 수작업이며 확장성이 없습니다. 시험 팁: “이동 평균(rolling averages)”, “최근 X일 기준 top-N”, “API로 쿼리”를 보면 모니터링 시스템이 아니라 분석 데이터베이스(BigQuery)를 떠올리세요. 실행은 Vertex AI로 하되, 실험 결과는 쿼리 최적화된 시스템에 저장하세요. 또한 메트릭 cardinality와 비용을 주의하세요: BigQuery partitioning/clustering은 시계열 실험 테이블에서 시험에 자주 나오는 모범 사례입니다.

7
문제 7

You are the lead ML engineer at a smart-meter analytics company; you trained a TensorFlow model that flags consumption anomalies, and each day at 01:00 UTC your ETL job writes the previous day’s readings (~1.5 million records, ~60 GB) as newline-delimited JSON to Cloud Storage under prefixes like gs://meter-prod/daily/2025-08-31/*.jsonl; you need to run inference over the entire daily batch with minimal manual intervention and do not require low-latency, per-request responses; what should you do?

Vertex AI Batch Prediction은 대규모 오프라인 스코어링을 위해 목적에 맞게 설계되었습니다. Cloud Storage URI/prefix(매일의 폴더 패턴과 매칭)에서 JSONL을 읽고, 샤딩된 prediction 출력물을 Cloud Storage로 다시 기록할 수 있습니다. 관리형이며 수평 확장이 가능하고 대규모 데이터셋을 지원하며, 매일 실행을 위해 schedulers/orchestrators와 깔끔하게 통합되어 수동 개입과 운영 오버헤드를 최소화합니다.

Compute Engine VMs에서 스케줄된 추론을 실행하는 것은 가능하지만 instance sizing, autoscaling, retries, logging, patching, failure handling을 직접 관리해야 합니다. 또한 데이터 다운로드/스트리밍 로직을 구축하고 매일 60 GB 처리량을 보장해야 합니다. 이는 운영 부담을 증가시키며 Vertex AI batch prediction에 비해 관리형 모범 사례에 덜 부합합니다.

파일 쓰기마다 Cloud Function을 트리거하면 대규모 일일 배치에서 제어하기 어려운 이벤트 기반 fan-out이 발생할 수 있습니다. Cloud Functions는 실행 시간 및 리소스 제약이 있으며, 무거운 장시간 추론 워크로드에 적합하지 않습니다. 또한 많은 파일에 대한 aggregation/coordination이 필요하고 retries/idempotency를 신중히 처리해야 하므로, 단일 관리형 batch job 대비 복잡성이 증가합니다.

Online prediction endpoints는 저지연, 요청 단위 서빙에 최적화되어 있습니다. 150만 레코드에 대해 레코드별로 endpoint를 호출하면 요청 오버헤드가 크게 증가하고 quota/QPS 제한에 걸릴 수 있으며, 대규모 오프라인 워크로드에서는 일반적으로 batch prediction보다 비용이 더 듭니다. 또한 지연 시간이 필요하지 않은데도 불필요한 복잡성(client batching, retries, throttling)을 도입하게 됩니다.

문제 분석

핵심 개념: 이 문제는 비대화형, 고처리량 추론에 적합한 서빙 패턴을 선택하는지를 평가합니다. Google Cloud에서 Vertex AI Batch Prediction은 Cloud Storage(또는 BigQuery)에서 오프라인/배치 스코어링을 수행하고, 커스텀 인프라를 구축·운영하지 않고도 결과를 Cloud Storage/BigQuery로 다시 기록하도록 설계되었습니다. 정답이 맞는 이유: 매일 대용량 배치(~60 GB, ~150만 레코드)가 예측 가능한 prefix로 Cloud Storage에 적재되며, 낮은 지연 시간 요구사항이 없습니다. Vertex AI batch prediction은 GCS URI/prefix에서 newline-delimited JSON을 읽고, 분산 추론을 위해 컴퓨트를 확장하며, 예측 결과를 대상 GCS 경로로 기록할 수 있습니다. 이를 통해 수동 개입을 최소화할 수 있습니다. 매일 반복되는 batch prediction job을 스케줄링(일반적으로 Cloud Scheduler + Cloud Functions/Cloud Run, 또는 Vertex AI Pipelines/Workflows 사용)하여 해당 날짜의 prefix를 가리키게 하고 자동으로 실행할 수 있습니다. 또한 Google Cloud Architecture Framework에 부합하게 운영 우수성(관리형 서비스), 신뢰성(재시도/관리형 실행), 비용 최적화(항상 켜져 있는 endpoint 대신 일시적 컴퓨트)를 개선합니다. 주요 기능 / 구성: - 입력: JSONL이 있는 GCS source; 필요에 따라 instances format과 schema를 지정. - 출력: GCS destination prefix; Vertex AI가 샤딩된 prediction 파일을 작성. - 스케일링: 관리형 worker pool; 모델에 이점이 있다면 machine types/accelerators 선택. - 오케스트레이션: 매일 01:00 UTC에 job을 스케줄; 날짜 기반 prefix를 파라미터화. - 모니터링: Vertex AI 및 Cloud Logging을 통한 job status, logs, metrics. 흔한 오해: “서빙”이므로 online endpoint(D)를 배포하고 싶을 수 있지만, 레코드 단위 호출은 오버헤드를 추가하고 QPS/quotas에 걸릴 수 있으며 대규모 배치에서는 비용이 더 들 수 있습니다. 파일 단위 Cloud Functions(C) 이벤트 기반 방식은 자동화처럼 보이지만, functions는 장시간 실행되는 고연산 추론에 적합하지 않고 통제되지 않는 병렬성과 운영 복잡성을 만들 수 있습니다. 커스텀 VMs(B)도 가능하지만 관리형 서비스 의도에 어긋나며 유지보수 부담이 증가합니다. 시험 팁: “daily batch”, “GCS prefix”, “no low latency”, “minimal ops”를 보면 기본 선택은 Vertex AI Batch Prediction입니다. online prediction은 대화형/저지연 사용 사례에만 사용하세요. 자동화는 VM fleet를 직접 구축하기보다 batch prediction을 Cloud Scheduler/Workflows/Vertex AI Pipelines와 함께 사용하는 방식으로 구성하세요.

8
문제 8

You are fine-tuning a Vision Transformer classifier on 1.2 million 224x224 product images using Keras; on a single NVIDIA T4 GPU with a global batch size of 64, each epoch takes about 90 minutes, and you have already enabled tf.data prefetch(AUTOTUNE), caching, and mixed precision. You switch to a VM with 4 T4 GPUs and wrap model creation/training with tf.distribute.MirroredStrategy, making no other changes and keeping the global batch size at 64; however, the epoch time remains ~90 minutes and per-GPU utilization hovers at 30–40%. Disk throughput and input pipeline profiling show no bottlenecks. What should you do to reduce wall-clock training time?

experimental_distribute_dataset(또는 최신의 strategy.distribute_datasets_from_function)은 주로 strategy가 replica들에 input을 shard/distribute해야 할 때 관련이 있습니다. MirroredStrategy와 model.fit에서는 Keras가 보통 distribution을 자동으로 처리합니다. profiling에서 input bottleneck이 없고 per-replica 작업량이 작아 GPU가 underutilized된 것으로 나타났으므로, dataset distribution을 바꿔도 epoch time을 유의미하게 줄이지 못합니다.

custom training loop(GradientTape)는 유연성을 제공할 수 있지만, 본질적으로 GPU utilization을 높이거나 all-reduce overhead를 줄이지는 못합니다. 근본 문제가 각 replica가 batch=16만 처리한다는 점이라면 GPU는 여전히 충분히 일을 받지 못합니다. 또한 custom loop는 신중히 graph-compile하지 않으면 추가적인 Python overhead를 유발할 수 있으므로, 성능을 위한 최선의 첫 조치가 아닙니다.

TPUStrategy로 TPU로 옮기면 학습이 빨라질 수는 있지만, 관찰된 증상에 대한 타깃 해결책은 아닙니다. TPU도 효율을 위해 충분히 큰 per-core batch size가 필요하며, 마이그레이션은 운영 복잡도(TPU 호환 ops, input pipeline 변경, XLA 동작)를 추가합니다. 문제는 utilization이 낮은 4개의 GPU에서 지금 무엇을 해야 하는지를 묻고 있으며, batch scaling이 직접적인 처방입니다.

global batch size를 늘리면 MirroredStrategy에서 per-replica batch size가 증가하여 step당 연산량이 커지고 GPU occupancy가 개선됩니다. 이는 고정 overhead(kernel launch, framework overhead, gradient all-reduce)를 상쇄하며, 모델이 compute-bound일 때 일반적으로 거의 선형에 가까운 speedup을 제공합니다. batch size를 스케일링한 뒤에는 convergence를 유지하기 위해 learning rate도 스케일/튜닝(종종 linear scaling + warmup)해야 합니다.

문제 분석

핵심 개념: 이 문제는 tf.distribute.MirroredStrategy(데이터 병렬 동기 학습)를 사용한 분산 학습 성능과 global batch size가 GPU utilization 및 step time에 미치는 영향을 평가합니다. 동기식 multi-GPU 학습에서는 각 step마다 global batch를 replica들에 분할하고, 각 GPU에서 forward/backward를 실행한 뒤, gradient를 집계하기 위해 all-reduce를 수행합니다. 정답이 맞는 이유: 4개의 GPU와 고정된 global batch size 64를 사용하면 per-replica batch는 16이 됩니다. 224x224 ViT의 경우, 이 per-step workload는 각 T4를 효율적으로 포화(saturate)시키기에는 너무 작을 수 있으며, 특히 mixed precision(더 빠른 연산)과 상대적으로 큰 per-step overhead(kernel launch, framework overhead, all-reduce) 때문에 더 두드러집니다. 그 결과 utilization이 낮게(30–40%) 나타나고 speedup이 거의 없으며, epoch time이 약 90분으로 유지되는 증상과 일치합니다. global batch size를 늘리면 per-replica batch도 증가합니다(예: global 256 -> per-replica 64). 이는 arithmetic intensity를 높이고 overhead 및 communication을 분산(상쇄)하여, 일반적으로 epoch당 wall-clock time을 줄입니다. 주요 기능 / Best Practices: - MirroredStrategy에서는 replica 수에 맞춰 global batch size를 스케일링하여 per-replica batch를 대략 일정하게 유지하는 것(강한 스케일링, strong scaling)을 기대합니다. 흔한 규칙은: new_global_batch = old_global_batch * num_replicas. - batch size를 늘린 뒤에는 convergence를 유지하기 위해 learning rate를 조정(종종 linear scaling rule)하고 warmup을 고려합니다. - 작은 step 또는 지나치게 잦은 host/device sync 지점(예: 과도하게 빈번한 callbacks)으로 인해 병렬성이 의도치 않게 제한되지 않도록 확인하되, 여기서의 1차 레버는 batch sizing입니다. - 이는 Google Cloud Architecture Framework의 성능 원칙(가속기 utilization 극대화 및 per-step overhead 감소)과도 부합합니다. 흔한 오해: - input pipeline을 탓하며 dataset distribution API로 해결하려는 유혹이 있지만, profiling에서 이미 I/O bottleneck이 아님이 확인되었습니다. - custom training loop는 per-replica batch가 너무 작아서 생기는 underutilization을 거의 해결하지 못하며, 신중히 최적화하지 않으면 오히려 성능을 떨어뜨릴 수도 있습니다. - TPU로 전환하는 것은 근본 원인을 해결하지 못합니다. TPU도 충분히 큰 per-core batch size가 필요하며, 유사한 overhead/communication 패턴에 의해 제한될 수 있습니다. Exam Tips: multi-GPU speedup이 낮고 input이 bottleneck이 아니라면 (1) per-replica batch size, (2) all-reduce/communication overhead, (3) step overhead를 확인하세요. MirroredStrategy에서는 global batch size를 스케일링하고(그리고 그에 맞게 LR를 튜닝하는 것) 하는 것이 가장 흔하고 기대되는 해결책입니다.

9
문제 9

You work for an online marketplace that must automatically flag product photos containing restricted brand logos; each image belongs to exactly one class (logo present vs. not present). You trained a convolutional neural network, deployed a model version to Vertex AI Prediction, and attached a model evaluation job to that version. At a softmax decision threshold of 0.50, the evaluation reports precision = 0.71, but the business requires precision >= 0.90. To increase precision by changing only the final layer softmax threshold, what should happen as a consequence of your adjustment?

precision을 개선하기 위해 임계값을 올리는 것은 일반적으로 recall을 증가시키지 않습니다. Recall은 가능한 많은 true positive를 포착하는 것에 달려 있습니다. 더 높은 임계값은 분류기를 더 엄격하게 만들어, 경계선상의 true positive 일부가 음성으로 분류되어 TP가 줄고 FN이 늘어납니다. 이는 기본 모델이 변하지 않는 한 보통 recall을 높이기보다 낮춥니다.

정답입니다. softmax threshold만 조정해서 precision을 0.71에서 >= 0.90으로 올리려면, 일반적으로 임계값을 올려 모델이 “logo present”를 더 적게 예측하도록 합니다. 이는 false positive를 줄여(precision 개선) false negative를 늘리며, 그 결과 recall(TP/(TP+FN))이 감소합니다. 이는 고정된 분류기에서의 전형적인 precision–recall 트레이드오프입니다.

precision을 높이기 위해 임계값을 올리면 보통 false positive 수는 증가가 아니라 감소합니다. False positive는 음성 이미지가 양성으로 예측될 때 발생합니다. 더 엄격한 임계값은 전체적으로 예측되는 양성 수를 줄이므로, 더 적은 음성 예시가 임계값을 넘어 잘못 플래그됩니다. False positive가 증가하면 일반적으로 precision이 감소하여 목표와 반대입니다.

precision을 높이기 위해 임계값을 올리면 일반적으로 false negative는 감소가 아니라 증가합니다. False negative는 양성이 음성으로 예측되는 경우인데, 임계값이 높아지면 중간 수준의 confidence를 가진 일부 실제 로고 이미지가 cutoff 아래로 떨어져 놓치게 됩니다. False negative를 줄이려면 보통 임계값을 낮춰야 하며, 이는 recall을 높이는 경향이 있지만 precision을 해칠 수 있습니다.

문제 분석

핵심 개념: 이 문제는 이진 분류기(로고 존재 vs. 로고 없음)에 대한 분류 임계값(thresholding)과 precision–recall 트레이드오프를 평가합니다. Vertex AI Model Evaluation에서는 선택한 결정 임계값(예: softmax probability >= 0.50이면 “logo present”로 예측)에서 confusion matrix를 기반으로 precision과 recall 같은 metric이 계산됩니다. 정답이 맞는 이유: Precision = TP / (TP + FP)입니다. 비즈니스 요구사항은 precision >= 0.90으로, 현재 0.71보다 높습니다. 최종 레이어의 softmax threshold만 변경할 수 있고(모델 재학습은 불가) 조정 가능한 주요 수단은 양성 클래스(“logo present”)를 더 보수적으로 예측하도록 만드는 것입니다. 즉, 0.50보다 임계값을 올려 양성으로 라벨링되는 이미지 수를 줄입니다. 임계값이 증가하면 일반적으로 false positive가 true positive보다 더 빠르게 감소하여 precision이 상승합니다. 하지만 양성으로 예측되는 예시가 줄어들기 때문에, 일부 true positive가 임계값 아래로 내려가 음성으로 예측되어 false negative가 증가하고, 그 결과 recall(recall = TP / (TP + FN))은 감소합니다. 따라서 예상되는 결과는 recall 감소입니다. 주요 기능 / 모범 사례: Vertex AI evaluation은 비즈니스 목표에 맞는 운영 지점을 선택할 수 있도록 threshold 기반 metric과 curve(precision-recall curve, ROC curve)를 지원합니다. 높은 precision 요구사항(예: 컴플라이언스 또는 제한 콘텐츠)에서는 낮은 recall을 수용하고 불확실한 케이스를 human review로 라우팅하는 것이 일반적입니다. 이는 비즈니스 요구사항과 리스크 관리를 중심으로 설계하라는 Google Cloud Architecture Framework의 강조점과도 일치합니다. 흔한 오해: 많은 사람들이 “precision을 개선하면” recall도 함께 개선된다고 가정하지만, 고정된 모델에서는 임계값을 올리면 보통 recall을 희생하고 precision을 얻는 형태가 됩니다. 또 다른 혼동은 threshold 변경이 모델의 학습된 parameter를 바꾼다고 생각하는 것인데, 그렇지 않습니다—결정 규칙만 바뀝니다. 시험 팁: 임계값 변화가 FP/FN에 미치는 영향을 암기하세요: 임계값을 올리면 predicted positive가 감소 → FP 감소, FN 증가 → precision 증가, recall 감소. 특히 positive class가 희소하거나 false positive 비용이 큰 경우, PR curve를 사용해 threshold 선택을 정당화하세요.

10
문제 10

You work for a nationwide e-commerce marketplace. After receiving approval to collect the necessary customer behavior data, you trained a Vertex AI AutoML Tabular model to predict the probability that an order will be returned within 30 days. You deployed the model to online prediction, and it serves about 200,000 predictions per day. Seasonal promotions and marketing campaigns may change how features such as discount_rate, shipping_speed, and product_category interact, which could degrade accuracy over time. You want to be alerted if feature interactions change and to understand which features drive the predictions, while keeping monitoring costs low. What should you do?

Sampling rate 1(100%)의 feature drift monitoring은 입력 feature 분포의 변화를 감지하지만, 어떤 feature가 예측을 주도하는지 직접 설명하거나 모델 reliance/interaction 효과의 변화를 포착하지는 못합니다. 또한 모든 온라인 predictions(~200k/day)을 logging하고 분석하므로 가장 비용이 큰 옵션이며, storage 및 monitoring 비용이 증가합니다. Weekly cadence는 도움이 되지만, full sampling은 여전히 “모니터링 비용을 낮게 유지”라는 요구와 충돌합니다.

이 옵션은 predictions의 10%만 sampling하고 weekly로 실행하여 비용을 개선하므로, 좋은 비용 제어 패턴입니다. 그러나 여전히 feature drift(입력 분포 변화)에 초점을 맞추며, 모델이 feature를 사용하는 방식에 대한 변화는 다루지 않습니다. Marginal distribution 변화가 크지 않은 상태에서 feature interactions만 변하면 feature drift가 적절히 알림을 주지 못할 수 있고, 어떤 feature가 예측을 주도하는지 이해해야 한다는 요구도 충족하지 못합니다.

Feature attribution drift monitoring은 어떤 feature가 예측을 주도하는지 이해하고 시간에 따른 모델 reliance 변화를 감지해야 한다는 요구에 부합합니다. 하지만 sampling rate 1은 고트래픽 온라인 endpoint에서 불필요하게 비용이 큽니다. 모든 prediction에 대해 logging하고 attributions를 계산하면 모니터링 및 storage 비용이 크게 증가합니다. Weekly frequency는 job 실행 횟수를 줄이지만, full sampling은 여전히 “모니터링 비용을 낮게 유지” 요구를 위반합니다.

Feature attribution drift monitoring은 시간에 따른 feature attributions의 변화를 추적함으로써, 변하는 feature interactions와 예측의 driver를 이해해야 한다는 요구를 직접적으로 해결합니다. Sampling rate 0.1을 사용하면 logging 및 모니터링 비용을 크게 줄이면서도 200,000 predictions/day 기준으로 충분히 큰 sample size를 확보할 수 있습니다. Weekly monitoring은 캠페인/계절성 기반 변화에 합리적인 cadence이며 비용을 추가로 제어합니다.

문제 분석

핵심 개념: 이 문제는 온라인 예측을 위한 Vertex AI Model Monitoring을 평가하며, 특히 feature drift와 feature attribution drift의 차이, 그리고 sampling rate와 monitoring frequency를 통해 모니터링 비용을 제어하는 방법을 다룹니다. 정답인 이유: 비즈니스 우려는 계절성과 캠페인으로 인해 “feature interactions”가 변하면서 정확도가 저하된다는 점입니다. 순수한 feature drift는 입력 feature의 분포 변화(예: discount_rate 값 분포 이동)를 감지하지만, 모델이 feature(모델이 학습한 interaction 효과 포함)에 얼마나 의존하는지가 변했는지를 직접적으로 알려주지는 않습니다. Feature attribution drift monitoring은 feature attribution의 변화(예: 시간이 지남에 따라 예측에 대해 discount_rate 대비 shipping_speed가 얼마나 기여하는지)를 추적합니다. 이는 “어떤 feature가 예측을 주도하는지 이해”하고, feature와 예측 간 관계가 변할 때 알림을 받으려는 요구사항에 더 잘 부합합니다. ~200,000 predictions/day를 제공하면서 모니터링 비용을 낮게 유지하려면 요청의 100%를 log/monitor하면 안 됩니다. Sampling rate 0.1(10%)은 logged predictions의 양과 모니터링 계산량을 약 10배 줄이면서도, 트래픽이 높은 시스템에서 주간 추세 감지를 위한 충분한 신호를 제공합니다. 주요 기능 / 구성: - Vertex AI Model Monitoring은 입력 feature와 feature attributions에 대한 drift monitoring을 지원합니다. - Attribution drift는 marginal feature distributions가 크게 변하지 않더라도, interaction 변화로 인해 모델의 의사결정 로직이 바뀌는 경우에 특히 유용합니다. - Sampling rate는 어떤 비율의 prediction request를 logging하고 모니터링에 사용할지 제어합니다. 더 낮은 sampling은 BigQuery/logging/storage 및 monitoring job 비용을 줄입니다. - 주간 monitoring frequency는 계절성/캠페인 기반 변화에 합리적이며, 일간 대비 비용을 추가로 절감합니다. 흔한 오해: - “features가 변한다”는 이유로 feature drift를 선택하기 쉽지만, 예측의 driver와 interaction/importance 변화에 대한 명시적 요구를 놓치게 됩니다. - Sampling을 1로 설정하면 “더 정확”해 보이지만, 이 규모에서는 불필요하게 비싸며 주간 알림에는 필요하지 않습니다. 시험 팁: 프롬프트에 “which features drive predictions”, “model reliance”, 또는 “interactions changing”이 언급되면 feature attribution monitoring(및 attribution drift)을 떠올리세요. 높은 QPS/대량 endpoint에서 비용 제약이 있으면, 모든 요청을 모니터링하기보다 낮은 sampling rate와 적절한 monitoring cadence를 선호하세요.

합격 후기(7)

C
C***************Nov 24, 2025

학습 기간: 1 month

Just want to say a massive thank you to the entire Cloud pass, for helping me pass my exam first time. I wont lie, it wasn't easy, especially the way the real exam is worded, however the way practice questions teaches you why your option was wrong, really helps to frame your mind and helps you to understand what the question is asking for and the solutions your mind should be focusing on. Thanks once again.

F
f****Nov 23, 2025

학습 기간: 1 month

Good questions banks and explanations that help me practise and pass the exam.

민
민**Nov 12, 2025

학습 기간: 1 month

강의 듣고 바로 문제 풀었는데 정답률 80% 가량 나왔고, 높은 점수로 시험 합격했어요. 앱 잘 이용했습니다

S
S************Nov 11, 2025

학습 기간: 1 month

Good mix of theory and practical scenarios

A
A***********Nov 6, 2025

학습 기간: 1 month

I used the app mainly to review the fundamentals—data preparation, model tuning, and deployment options on GCP. The explanations were simple and to the point, which really helped before the exam.

다른 모의고사

Practice Test #1

50 문제·120분·합격 700/1000

Practice Test #2

50 문제·120분·합격 700/1000
← 모든 Google Professional Machine Learning Engineer 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 Google Professional Machine Learning Engineer 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

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

앱 받기

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