CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
  1. Cloud Pass
  2. GCP
  3. Google Professional Machine Learning Engineer
Google Professional Machine Learning Engineer

GCP

Google Professional Machine Learning Engineer

335+ 기출 문제 (AI 검증 답안 포함)

Free questions & answers실제 시험 기출 문제
AI-powered explanations상세 해설
Real exam-style questions실제 시험과 가장 유사
335+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

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

시험 도메인

Architecting Low-Code AI Solutions출제율 13%
Collaborating Within and Across Teams to Manage Data and Models출제율 14%
Scaling Prototypes into ML Models출제율 18%
Serving and Scaling Models출제율 20%
Automating and Orchestrating ML Pipelines출제율 22%
Monitoring AI Solutions출제율 13%

실전 문제

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 plan to fine-tune a video-frame classifier via transfer learning using a pre-trained ResNet-50 backbone. Your labeled dataset contains 18,000 1080p frames, and you will retrain the model once per day; each training run completes in under 60 minutes on 4 V100 GPUs, and you must minimize infrastructure cost and operational overhead. Which platform components and configuration should you choose?

4 V100s를 갖춘 단일 Deep Learning VM은 성능 요구사항을 충족할 수 있고, local SSDs는 높은 처리량을 제공합니다. 하지만 운영 오버헤드(VM lifecycle, patching, GPU/CUDA/driver 관리)를 증가시키고, 일일 학습 사이에 VM을 켜둔 채로 두면 비용이 증가할 수 있습니다. 또한 매 실행마다 데이터를 local SSD로 staging해야 하며, 내구성/백업도 직접 처리해야 합니다.

Deep Learning VM에서 Cloud Storage로 직접 읽기/쓰기를 하면 로컬 스토리지 관리는 줄어들지만, 여전히 VM 운영을 직접 책임져야 하고, start/stop 및 image maintenance를 자동화하지 않으면 보통 유휴 GPUs 비용을 지불하게 됩니다. 1080p 프레임의 경우 Cloud Storage I/O는 대체로 충분하지만, 핵심 요구사항은 운영 오버헤드 최소화이며 이는 관리형 Vertex AI Training이 더 잘 해결합니다.

GPU node pools와 자체 관리 NFS server를 사용하는 GKE는 운영 오버헤드가 가장 큰 옵션입니다: cluster 관리, GPU scheduling, node autoscaling tuning, NFS reliability/backup, security hardening. 이는 복잡한 multi-tenant 학습 플랫폼이나 많은 동시 작업에 적합하며, 단일 일일 <60-minute 학습 실행에서 단순성과 비용 최소화가 우선인 경우에는 적절하지 않습니다.

4 V100 GPUs를 사용하는 Vertex AI Training custom job과 Cloud Storage에 저장된 데이터 조합이 가장 관리형이며 ops가 가장 적은 접근입니다. 작업에 대해서만 GPUs를 프로비저닝하고 Cloud Logging/Monitoring과 통합되며, VM images, drivers, cluster 인프라를 관리할 필요가 없습니다. Cloud Storage는 내구성이 높고 비용 효율적인 데이터셋 스토리지를 제공하며, 반복 가능한 일일 재학습 실행을 위해 쉽게 접근할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 반복적인 GPU 학습을 최소한의 운영(ops)으로 수행하기 위해 적절한 관리형 학습 플랫폼을 선택하는지를 평가합니다. 자체 관리 GPU VM/GKE와 Vertex AI Training을 대비하고, 학습 데이터(Cloud Storage)를 내구성과 재현성을 위해 어떻게 저장할지도 함께 다룹니다. 정답이 맞는 이유: 관리형 Vertex AI Training 작업(custom scale tier, 4 V100 GPUs)은 하루 1회 재학습 워크로드에서 “인프라 비용과 운영 오버헤드를 최소화” 요구사항에 가장 부합합니다. Vertex AI Training은 작업 수행 시간 동안에만 GPU 리소스를 프로비저닝하고, 완료 후 자동으로 해제하며, 관리형 logging/metrics 및 artifact 처리를 제공합니다. 매일 실행이 60분 미만이라면, (스토리지를 제외하고) 학습 작업 런타임에 대해서만 비용을 지불하는 방식이 VM이나 클러스터를 상시 유지하는 것 대비 유휴 GPU 비용을 줄이는 경우가 일반적입니다. 18,000개의 1080p 프레임을 Cloud Storage에 저장하는 것은 표준 패턴입니다. 내구성이 높고 운영 부담이 적으며, 디스크나 파일 서버를 관리하지 않고도 관리형 학습에서 접근할 수 있습니다. 주요 기능 / 모범 사례: - Vertex AI Training custom jobs: machine type과 accelerators(4x V100)를 지정하고 container 기반 학습을 수행. - Cloud Storage를 데이터셋과 출력의 system of record로 사용; versioning/lifecycle policies를 지원하고 IAM과 통합. - Operational excellence (Google Cloud Architecture Framework): 관리형 서비스가 toil을 줄임(패치, driver/CUDA 관리, job retries, 중앙화된 logs). - Cost optimization: ephemeral 학습 리소스; 학습하지 않을 때 GPUs 비용을 지불할 필요 없음. (지역에서 가능하다면 추가 절감을 위해 Spot/Preemptible GPUs를 고려할 수 있으나, 문제에서 요구하지는 않습니다.) 흔한 오해: - “단일 VM이 더 단순하다”: 그럴 수 있지만, 유휴 시간에도 GPUs 비용을 지불하게 되거나 수동 start/stop 자동화가 필요해지는 경우가 많고, 지속적인 유지보수(drivers, images, security patching)도 발생합니다. - “GKE가 더 확장 가능하다”: 맞지만, 단순한 일일 학습 작업에는 상당한 운영 오버헤드를 추가합니다. 시험 팁: 반복 학습, 짧은 런타임, ops 최소화 요구사항이 보이면 Vertex AI Training + Cloud Storage를 우선 선택하세요. 자체 관리 VMs/GKE는 custom networking, 특수한 storage/latency, 또는 관리 부담을 정당화할 만큼 장시간 실행/대화형 워크플로가 필요할 때만 선택합니다.

3
문제 3

Your team is preparing to train a fraud detection model using data in BigQuery that includes several fields containing PII (for example, card_number, customer_email, and phone_number). The dataset has approximately 250 million rows and every column is required as a feature. Security requires that you reduce the sensitivity of PII before training while preserving each column’s format and length so downstream SQL joins and validations continue to work. The transformation must be deterministic so the same input always maps to the same protected value, and authorized teams must be able to decrypt values for audits. How should you proceed?

민감한 값을 무작위화하는 방식은 매핑 테이블을 유지하지 않는 한 결정적이지 않으며, 일반적으로 감사 목적의 가역성이 없습니다. 또한 무작위 출력이 원본 형식/길이 제약(예: 카드 번호 패턴)을 보존하지 못할 수 있어 참조 무결성과 다운스트림 join/검증을 깨뜨릴 위험이 있습니다. Dataflow는 2억 5천만 행까지 확장 가능하지만, 이 접근은 결정적 및 복호화 가능 요구사항을 충족하지 못합니다.

Cloud DLP는 PII를 식별할 뿐 아니라 대규모로 비식별화를 적용할 수 있습니다. DLP Format-Preserving Encryption (FPE)을 사용하면 원본 데이터의 형식과 길이를 보존하여 다운스트림 SQL join과 검증이 계속 동작할 수 있습니다. Cloud KMS가 키 재료를 보호하면, 승인된 팀이 통제된 IAM 하에서 감사 목적으로 재식별/복호화를 수행할 수 있습니다. Dataflow는 수억 개 BigQuery 행을 변환하기 위한 확장 가능한 실행 계층을 제공합니다.

행마다 랜덤 salt를 사용하는 AES-256은 변환을 비결정적으로 만듭니다(같은 입력이 매번 다르게 암호화됨). 이는 join과 일관된 특성 값에 필요한 안정적 매핑 요구사항을 깨뜨립니다. 또한 표준 ciphertext 인코딩(base64/hex)은 길이와 문자 집합을 변경하여 형식/길이 보존을 위반합니다. 커스텀 crypto를 구축하는 것은 이 사용 사례를 위해 설계된 DLP의 관리형 FPE에 비해 구현 리스크도 증가시킵니다.

PII 컬럼을 삭제하는 것은 모든 컬럼이 학습을 위한 특성으로 필요하다는 요구사항과 모순됩니다. authorized view는 접근을 제한할 수 있지만, 학습에 사용되는 데이터의 민감도를 낮추지는 못합니다. 모델 파이프라인은 여전히 원본 PII가 필요해(보안 요구사항 위반)지거나 중요한 특성을 잃게 됩니다. 이 옵션은 접근 제어를 다루지, 결정적이고 가역적인 비식별화를 다루지 않습니다.

문제 분석

핵심 개념: 이 문제는 관리형 비식별화를 사용해 ML을 위한 프라이버시 보존 특성 엔지니어링을 테스트합니다. 핵심 서비스는 비식별화와 Format-Preserving Encryption (FPE)을 위한 Cloud Data Loss Prevention (DLP), 키 관리를 위한 Cloud KMS, 그리고 BigQuery 규모 데이터셋의 확장 가능한 변환을 위한 Dataflow입니다. 정답이 맞는 이유: PII 민감도를 낮추면서 (1) 각 컬럼의 형식과 길이를 보존하고, (2) 결정적 매핑(같은 입력 -> 같은 출력)을 보장하며, (3) 감사 목적의 승인된 재식별(복호화)을 가능하게 해야 합니다. Cloud DLP의 FPE는 이를 정확히 위해 설계되었습니다. 원본 데이터의 문자 집합/길이 제약(예: 신용카드 형태 문자열)을 만족하는 ciphertext를 생성하고, 결정적으로 구성할 수 있으며, 적절한 키잉 재료와 결합하면 가역 변환을 지원합니다. wrapping key를 보호하기 위해 Cloud KMS를 사용하는 것은 엔터프라이즈 보안 및 감사 가능성 요구사항과 부합합니다. Dataflow는 약 2억 5천만 행에 필요한 처리량을 제공하며 BigQuery I/O와 잘 통합됩니다. 주요 기능 / 구성: - 형식/길이를 보존하기 위해 cryptoReplaceFfxFpeConfig (FPE/FFX 모드)를 사용하는 DLP 비식별화 템플릿. - 일관된 키잉 재료와 구성으로 결정적 동작을 보장; 정책에서 요구하면 안정적인 surrogate/“tweak” 전략을 선택적으로 사용. - DLP crypto 키 재료를 보호하기 위한 Cloud KMS 관리 key encryption key (KEK) (중앙집중식 IAM, 로테이션, 감사 로그 지원). - BigQuery에서 읽고 특정 컬럼에 DLP 변환을 적용한 뒤 학습을 위해 BigQuery로 다시 쓰는 Dataflow 파이프라인(배치). - 최소 권한 원칙: Dataflow 서비스 계정에는 BigQuery read/write 및 DLP/KMS 권한이 필요하며, decrypt 기능은 감사 팀으로 제한. 흔한 오해: - 값을 “무작위화”하면 PII는 제거되지만 join/검증이 깨지고 가역적이지 않습니다. - 랜덤 salt를 사용하는 표준 암호화는 보안을 강화하지만 결정성을 해치고 보통 길이/형식을 변경하여 다운스트림 SQL 기대를 깨뜨립니다. - PII 컬럼을 삭제하는 것은 모든 컬럼이 특성으로 필요하다는 요구사항을 위반합니다. 시험 팁: (a) 형식/길이 보존, (b) 결정적 토큰화, (c) 승인된 사용자를 위한 가역적 접근 요구사항을 보면 Cloud DLP FPE + Cloud KMS를 떠올리세요. 매우 큰 BigQuery 데이터셋의 경우 확장 가능한 배치 처리를 위해 Dataflow와 함께 사용하고, 반복성과 거버넌스를 위해 DLP 템플릿을 사용하세요( Google Cloud Architecture Framework의 보안 및 운영 우수성 기둥과 정렬).

4
문제 4

Your team deployed a regression model that predicts hourly water usage for industrial chillers. Four months after launch, a vendor firmware update changed sensor sampling and units for three input features, and the live feature distributions diverged: 5 of 18 features now have a population stability index > 0.25, 27% of temperature readings fall outside the training range, and production RMSE increased from 0.62 to 1.45. How should you address the input differences in production?

정답입니다. 증거(높은 PSI, 많은 값이 학습 범위 밖, RMSE 급증)는 업스트림 firmware 변경에 의해 유발된 데이터 drift/skew를 나타냅니다. 지속적인 drift를 탐지하고 정량화하려면 알림이 포함된 자동 모니터링이 필요하며, 최근 프로덕션 데이터(수정된 preprocessing/단위 정규화 포함)를 사용한 자동 재학습 파이프라인은 성능을 복구하고 향후 다운타임을 줄이기 위한 표준 운영 대응입니다.

오답입니다. Feature selection은 일부 drift 입력에 대한 민감도를 줄일 수는 있지만, 입력의 의미/단위/sampling이 바뀌었다는 근본 원인을 해결하지 못합니다. “중요도가 낮은” feature를 제거해도 temperature 값의 27%가 범위 밖이라는 점이나 여러 핵심 feature가 이동했다는 점은 해결되지 않습니다. 여전히 모니터링이 필요하고, 대개 preprocessing 업데이트와 올바르게 해석된 데이터로의 재학습이 필요합니다.

오답입니다. Hyperparameter tuning(예: L2 regularization)은 overfitting/underfitting을 다루는 것이지, 프로덕션 데이터 계약 변경을 다루는 것이 아닙니다. 단위 변경과 분포 변화가 있는 상황에서 regularization을 튜닝하면 예측을 약간 안정화할 수는 있지만 정확도를 신뢰성 있게 복구하지는 못합니다. 올바른 접근은 drift를 탐지하고, feature semantics를 검증하며, 변환(transformations)을 업데이트하고, 대표성 있는 최신 데이터로 재학습하는 것입니다.

오답입니다. 고정된 월간 재학습 일정은 이벤트 기반 모니터링 및 대응보다 약합니다. 갑작스러운 업스트림 변경 이후 시스템이 수주 동안 성능 저하 상태로 남을 수 있습니다. Feature selection은 여전히 단위/sampling 변경을 해결하지 못합니다. Best practice는 알림이 포함된 지속적 모니터링과, drift/성능 임계값 초과 시 재학습을 수행하는 자동 파이프라인(배포 전 평가 게이트 포함)입니다.

문제 분석

핵심 개념: 이 시나리오는 데이터 skew/drift에 대한 프로덕션 ML 모니터링과 업스트림 시스템 변경 시 운영 대응을 테스트합니다. Google Cloud에서는 Vertex AI Model Monitoring(Feature skew/drift, out-of-distribution detection, 성능 모니터링)과 모델을 지속적으로 적응시키기 위한 자동 재학습 파이프라인(Vertex AI Pipelines/Cloud Composer/Cloud Build)에 해당합니다. 정답이 맞는 이유: 벤더 firmware update로 여러 입력 feature의 sampling과 단위가 변경되어, 명확한 분포 변화(5/18 features에서 PSI > 0.25, temperature의 27%가 학습 범위 밖)와 큰 성능 저하(RMSE 0.62 → 1.45)가 발생했습니다. 이는 주로 모델링/regularization 문제가 아니라 데이터 계약(data contract) 및 데이터 drift 문제입니다. 올바른 대응은 (1) skew/drift를 탐지하고 알림을 발생시키며 (2) 최근의, 올바르게 해석된 프로덕션 데이터로 모델(그리고 종종 preprocessing)을 업데이트하는 것입니다. 자동 모니터링은 조용한 성능 저하를 방지하고, 재학습 파이프라인은 업스트림 변경이 재발할 때 평균 복구 시간(mean time to recovery)을 단축합니다. 주요 기능 / Best Practices: - Vertex AI Model Monitoring을 사용해 feature skew/drift(Training vs Serving)를 추적하고, 임계값을 설정하며, 알림을 Cloud Monitoring으로 라우팅합니다. - 성능 모니터링(RMSE)과 근본 원인 분석을 가능하게 하도록 prediction 요청/응답과 ground truth(가능한 경우)를 로깅합니다. - 단위 정규화(unit normalization)와 스키마 검증(schema validation)(예: TFDV/Great Expectations)을 명시적으로 포함한 견고한 feature engineering을 구현해 단위 변경을 조기에 포착합니다. - 데이터 추출, 검증, 학습, 평가 게이트, 안전한 롤아웃(canary/rollback)을 포함하도록 Vertex AI Pipelines로 재학습을 자동화합니다. 흔한 오해: feature selection이나 더 강한 regularization으로 모델을 “고치려”는 유혹이 있지만, 이는 잘못된 단위/sampling 또는 범위 밖 입력 문제를 해결하지 못합니다. feature의 의미(semantics)가 바뀌었다면, 모델은 학습 시점과는 다른 변수를 입력으로 받는 것과 같습니다. 시험 팁: PSI drift, 학습 범위 밖 비율, 지표 악화가 보이면 monitoring + 데이터 검증 + 재학습/refresh를 우선시하세요. 업스트림 변경의 경우 preprocessing/feature store 변환을 업데이트하고 벤더와 데이터 계약을 수립하는 것도 고려하세요. Architecture Framework에서는 Operational Excellence(모니터링/자동화)와 Reliability(빠른 탐지 및 복구)에 부합합니다.

5
문제 5

You are a data scientist at a city transportation agency tasked with forecasting hourly bike-share demand per station to optimize rebalancing. Your historical trips table in BigQuery contains 24 months of data (~22 million rows) with columns: timestamp, station_id, neighborhood, weather_condition (sunny/rainy/snow), special_event (boolean), and surge_pricing_flag (boolean). You need to choose the most effective combination of a BigQuery ML model and feature engineering to minimize RMSE while capturing weekly/seasonal patterns and handling multiple categorical variables; what should you do?

최선의 선택: LINEAR_REG는 주간/계절 주기를 드러내는 강력한 시간 feature(hour, day-of-week, month)를 설계하면 매우 좋은 성능을 낼 수 있습니다. One-hot encoding은 station_id, weather_condition 같은 명목형 범주에 적합하며, 잘못된 ordinal 관계를 방지합니다. 이 조합은 여러 범주형 입력과 주기적 패턴이 있는 수요 예측에서 BigQuery ML의 표준적이며 시험에서 선호되는 접근입니다.

Boosted tree는 강력할 수 있지만, label encoding은 명목형 범주에 인위적인 순서를 도입합니다(예: station_id=10 > station_id=2). 이는 split을 왜곡하고 일반화를 떨어뜨릴 수 있습니다. timestamp를 단일 Unix time 값으로 캐스팅하면 주간/계절의 순환 패턴이 명시적으로 표현되지 않습니다. 모델이 주기성을 간접적으로 추론해야 하므로, 설계된 시간 구성요소를 사용하는 것보다 RMSE가 나빠지는 경우가 많습니다.

Autoencoder는 주로 차원 축소나 이상 탐지에 사용되는 unsupervised model이며, 수요 예측에서 supervised regression RMSE를 직접 최적화하기 위한 것이 아닙니다. Label encoding은 선택지 B와 동일한 ordinal 위험 문제가 있습니다. timestamp를 [0,1]로 정규화해도 순환 구조(예: hour 23은 hour 0과 가깝다)를 포착하지 못하므로, 주간/계절 패턴에 효과적이지 않습니다.

Matrix factorization은 collaborative filtering(user-item rating prediction)과 latent factor 발견에 적합하며, 외생 feature가 있는 시간 의존적 수요 회귀에는 맞지 않습니다. 상호작용 feature(station_id x weather)가 유용할 수는 있지만, 기본 모델 유형이 hourly 수요 예측에 부적합하고, 추가적인 시간 feature engineering과 회귀에 적합한 알고리즘 없이는 시간적 계절성을 자연스럽게 반영하지 못합니다.

문제 분석

핵심 개념: 이 문제는 많은 범주형 변수가 있는 시간 기반 수요 예측에서 적절한 BigQuery ML 모델 유형과 feature engineering을 선택하는지를 평가합니다. 모델 선택이 feature 표현(원-핫 vs label encoding)과 어떻게 상호작용하는지, 그리고 timestamp에서 계절성/주간 패턴을 어떻게 인코딩하는지를 강조합니다. 정답이 맞는 이유: 선택지 A(linear regression + one-hot encoding + 명시적 시간 feature)는 주간/계절 패턴을 포착하면서 RMSE를 최소화하기 위한 선택지 중 가장 효과적이고 신뢰할 수 있는 BigQuery ML 접근입니다. BigQuery ML에서 linear model(LINEAR_REG)은 유의미하게 설계된 feature를 제공하면 성능이 좋습니다. hour-of-day, day-of-week, month(그리고 종종 is_weekend, holiday flag, cyclic transform 같은 추가 feature)를 생성하면 모델이 주기적 수요 패턴을 학습할 수 있습니다. One-hot encoding은 명목형 범주 변수(station_id, neighborhood, weather_condition)에 적합한데, label encoding이 도입하는 인위적인 순서를 피할 수 있어 성능과 안정성이 저하되는 것을 방지합니다. 핵심 Feature / Best Practice: - BigQuery ML LINEAR_REG를 필요에 따라 자동 feature preprocessing과 함께 사용하되, 주기성을 드러내기 위해 시간 파생 feature는 명시적으로 설계합니다. - 명목형 범주는 one-hot encoding을 사용합니다. 희소성/compute 관점에서 필요하면 cardinality(예: station_id)를 낮추기 위해 드문 station을 그룹화하거나 neighborhood 수준 feature를 사용하는 것을 고려합니다. - SQL의 feature cross를 통해 지원된다면 상호작용(예: station_id x hour, weather x hour)을 고려하여 지역화된 시간 효과를 포착합니다. - 누수를 방지하고 예측 현실을 반영하기 위해 시간 기준 train/validation split(예: 마지막 N주를 eval로 사용)을 올바르게 적용합니다. 흔한 오해: Boosted tree는 종종 강력하지만, timestamp를 단일 Unix 숫자로 캐스팅(선택지 B)하면 순환 구조가 숨겨집니다. Tree가 일부 threshold를 학습할 수는 있어도, 명시적 시간 feature만큼 주간/계절 주기성을 깔끔하게 표현하지 못하는 경우가 일반적입니다. 명목형 범주에 대한 label encoding은 순위/순서를 암시하여 linear model과 tree model 모두를 오도할 수 있습니다. Autoencoder(선택지 C)는 표현 학습/이상 탐지용이지, 이 설정에서 supervised regression의 RMSE 최적화를 위한 것이 아닙니다. Matrix factorization(선택지 D)은 추천 스타일의 user-item 상호작용을 위해 설계된 것이며, 외생 변수가 있는 시계열 수요 회귀에는 적합하지 않습니다. 시험 팁: BigQuery ML에서 specialized time-series model을 사용하지 않는 forecasting 유사 문제에서는 (1) 주기성을 위한 명시적 시간 feature engineering, (2) 올바른 범주 처리(명목형은 one-hot), (3) 시간 기반 평가 split을 우선시하세요. timestamp를 단일 숫자 값으로 “단순화”하는 답을 주의하세요—이는 보통 계절성 학습을 해치며 흔한 함정입니다.

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

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

6
문제 6

You work for a vacation rental marketplace with 1.8 million property listings stored across BigQuery and Cloud Storage; the current search relies on keyword matching and filter chips, but you are seeing more complex semantic queries that reference amenities and metadata (for example, "quiet pet-friendly cabin near a lake with a fireplace, sleeps 6, under $200/night, host rating > 4.7"). You must deliver a revamped semantic search proof of concept within 2 weeks with minimal custom modeling and integration effort that can quickly index both structured listing attributes and unstructured descriptions; what should you choose as the search backend?

기반(foundation) LLM은 검색 백엔드나 인덱스가 아닙니다. LLM은 쿼리를 해석하고 응답을 생성할 수는 있지만, 문서/리스팅 인덱싱, 결정적 필터링(가격, 평점 임계값), 패싯, 180만 개 리스팅에 대한 확장 가능한 검색(retrieval)을 본질적으로 제공하지 않습니다. 지연 시간/비용 기대치를 충족하고 결과를 근거(ground)로 삼기 위해서는 여전히 검색 시스템(키워드, 벡터, 또는 관리형 검색)이 필요합니다.

Vertex AI Vector Search는 embeddings에 대한 근사 최근접 이웃(approximate nearest neighbor) 검색에 매우 뛰어나며, 대규모 시맨틱 유사도를 지원할 수 있습니다. 하지만 최소 통합으로 2주 POC를 진행하기에는 보통 작업이 더 많습니다. 설명에 대한 embeddings를 생성하고, 수집을 구축하며, 메타데이터 필터링을 설계/유지하고, 하이브리드 랭킹 및 쿼리 오케스트레이션을 구현해야 합니다. 이는 구성 요소이지 완전한 검색 제품이 아닙니다.

Vertex AI endpoint에 BERT 기반 모델을 호스팅하는 것은 커스텀 시맨틱 검색(retrieval)/랭킹 시스템을 구축한다는 의미입니다. embedding 생성, 인덱싱, 검색(retrieval), 필터링을 직접 처리해야 하며, 모델 서빙, 스케일링, 업데이트도 관리해야 합니다. 이는 2주 proof of concept에 대해 엔지니어링 노력과 리스크가 더 크고, 관리형 검색 기능이 존재하는 상황에서는 불필요합니다.

Vertex AI Agent Builder (Search)는 수집, 인덱싱, 하이브리드 검색(retrieval), 메타데이터 필터링/패싯을 제공하는 로우코드 관리형 시맨틱 검색 백엔드입니다. 구조화된 리스팅 속성과 비정형 설명을 빠르게 통합하고 API-ready 검색 경험을 제공하는 데 적합합니다. 이는 최소 커스텀 모델링과 빠른 POC 제공이라는 요구사항과 일치합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 구조화된 속성(가격, 숙박 가능 인원, 평점)과 비정형 텍스트(설명)를 모두 인덱싱할 수 있는 로우코드, 프로덕션 준비 완료(Production-ready) 시맨틱 검색 백엔드를 최소한의 커스텀 모델링과 빠른 가치 실현(time-to-value)으로 선택하는지를 평가합니다. 정답이 맞는 이유: Vertex AI Agent Builder(특히 Search 기능, 과거 Gen App Builder/Enterprise Search와 연계됨)는 시맨틱 검색을 빠르게 구축하도록 설계되었습니다. 이 서비스는 다양한 데이터 소스에 대한 관리형 수집(ingestion), 인덱싱, 검색(retrieval)을 제공하며, 하이브리드 검색(키워드 + 시맨틱)과 구조화된 메타데이터에 대한 필터링/패싯(faceting)을 지원합니다. 이는 마켓플레이스 검색에 정확히 필요한 기능입니다. 2주짜리 proof of concept에서는 Agent Builder가 통합 노력을 최소화합니다. 데이터 스토어를 구성하고, 소스(예: Cloud Storage 문서/JSON, BigQuery 내보내기 또는 피드)를 연결하고, 메타데이터 필드를 매핑하면, 자체 검색 스택을 구축/서빙하지 않고도 API/UI에 바로 연결 가능한 검색 경험을 얻을 수 있습니다. 주요 기능 / 모범 사례: - 하이브리드 검색: 어휘(lexical) 매칭과 시맨틱 관련성을 결합해 복잡한 쿼리를 처리합니다. - 메타데이터 필터링 및 패싯: “6명 숙박”, “$200 이하”, “평점 > 4.7”, “반려동물 가능” 같은 제약 조건에 필수입니다. - 관리형 인덱싱 및 관련성 튜닝: 자체 관리 파이프라인 대비 운영 부담을 줄입니다. - 빠른 POC 경로: 커스텀 모델링이 최소이며, 이후 필요 시 embeddings/LLM 기반 쿼리 이해를 선택적으로 추가할 수 있습니다. - Architecture Framework 정렬: 차별화되지 않은 무거운 작업(undifferentiated heavy lifting)을 관리형 서비스로 줄이면서, 전달 속도(성능 및 운영 우수성)를 높이고(신뢰성 및 보안 측면에서도) 가속합니다. 흔한 오해: 많은 응시자가 시맨틱 검색이 embeddings를 의미한다고 생각해 “Vector Search”를 선택합니다. 하지만 벡터 검색만으로는 완전한 검색 제품이 되지 않습니다. 여전히 수집, 청킹(chunking), embedding 생성, 메타데이터 스키마, 필터링 로직, 랭킹, 쿼리 오케스트레이션을 구축해야 합니다. Agent Builder는 이러한 기능을 하나의 일관된 검색 백엔드로 패키징합니다. 시험 팁: - 문제에서 “2주”, “최소 커스텀 모델링”, 그리고 구조화 + 비정형 데이터를 다루는 “검색 백엔드”를 강조하면, 원시 모델 호스팅이나 단독 벡터 DB가 아니라 관리형 검색 솔루션(Agent Builder/Search)을 찾으세요. - 커스텀 RAG/검색(retrieval) 레이어를 구축하고 파이프라인 및 랭킹 로직에 투자할 수 있을 때는 Vector Search를 사용하고, 엔드투엔드 엔터프라이즈 검색 경험을 빠르게 원할 때는 Agent Builder를 사용하세요. - LLM은 검색 인덱스가 아닙니다. 검색(retrieval)을 보완할 수는 있지만, 인덱싱과 필터링 요구사항을 대체하지는 못합니다.

7
문제 7

You are a data scientist at a national power utility analyzing 850 million smart-meter readings from 3,000 substations collected over 5 years; for exploratory analysis, you must compute descriptive statistics (mean, median, mode) by device and region, perform complex hypothesis tests (e.g., differences between peak vs off-peak and seasonal periods with multiple comparisons), and plot feature variations at hourly and daily granularity over time, while using as much of the telemetry as possible and minimizing computational resources—what should you do?

이상적이지 않은 이유: 데이터를 가져온 뒤 노트북 내부에서 기술 통계를 계산하고 통계 분석을 실행하기 때문입니다. 8억 5천만 행에서는 대량을 사용자 관리 노트북으로 가져오는 것이 비싸고 느리며, 메모리/IO 한계를 초과할 수 있습니다. Looker Studio는 시각화에 적합하지만, 컴퓨팅을 최소화하고 MPP 실행을 활용하려면 무거운 계산은 BigQuery로 푸시해야 합니다.

오답인 이유: 전체 데이터셋을 가져와 분석하는 데 Vertex AI Workbench 사용자 관리 노트북에 전적으로 의존하기 때문입니다. 노트북은 수억 건의 레코드를 스캔하고 집계하는 주 엔진으로 설계되지 않았으며, 일반적으로 큰 VM 사이징, 긴 실행 시간, 높은 비용이 필요합니다. 또한 BigQuery 기반 처리에 비해 재현성과 확장성이 떨어집니다.

부분적으로 정답: BigQuery는 대규모 기술 통계를 위한 올바른 위치이고, Workbench는 복잡한 가설 검정을 실행할 수 있습니다. 그러나 모든 시간 플롯을 생성하는 데 노트북을 사용하는 것은 시간별/일별 대화형 시각적 탐색에 가장 리소스 효율적인 접근이 아닙니다. Looker Studio는 BigQuery를 직접 쿼리하여, 노트북 컴퓨팅을 계속 실행하지 않고도 시각화를 오프로딩할 수 있습니다.

정답: BigQuery는 대규모 집계와 기술 통계를 효율적으로 처리하여 컴퓨팅과 비용을 최소화합니다. Looker Studio는 데이터를 내보내지 않고도 시간별/일별 그라뉼러리티의 대화형 시계열 플롯을 위해 BigQuery에 직접 연결합니다. 그런 다음 Vertex AI Workbench는 복잡한 가설 검정과 다중 비교 절차에만 사용되며, 이상적으로는 BigQuery에서 필터링/집계된 추출물에 대해 수행하여, 충실도와 리소스 효율성의 균형을 맞춥니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 대규모 탐색적 데이터 분석(EDA)을 위한 올바른 도구 선택을 평가합니다: 집계와 필터링을 BigQuery(서버리스 MPP 분석)로 푸시하고, 대화형 시각화에는 BI 도구를 사용하며, SQL로 쉽게 표현하기 어려운 고급 통계에만 노트북을 사용합니다. 정답이 맞는 이유: 8억 5천만 개의 시계열 리딩이 있는 상황에서 “전체 데이터”를 노트북으로 가져오는 것은 비효율적이며, 메모리/IO 한계와 높은 컴퓨팅 비용 때문에 종종 불가능합니다. BigQuery는 대규모 데이터셋을 효율적으로 스캔하고 집계하도록 설계되었으며, SQL을 통해 디바이스/리전별 기술 통계(평균, 중앙값을 위한 approximate quantiles, 최빈값을 위한 카운트)를 대규모로 계산할 수 있습니다. 시간에 따른 시간별/일별 변동을 플로팅할 때는 Looker Studio(구 Data Studio)가 BigQuery를 직접 쿼리할 수 있어, 데이터를 내보내거나 노트북을 지속 실행하지 않고도 대화형 대시보드를 제공할 수 있습니다. 다중 비교가 포함된 복잡한 가설 검정(예: t-test/ANOVA 변형, 비모수 검정, p-value 조정)은 Python/R 기반의 Vertex AI Workbench에서 처리하는 것이 더 적합하며, 중요한 점은 가능한 한 많은 텔레메트리를 활용하면서도 리소스를 최소화하기 위해 노트북이 BigQuery에서 필요한 슬라이스/집계만 쿼리해야 한다는 것입니다. 주요 기능 / 모범 사례: - BigQuery: timestamp 기준 partitioning 및 device_id/region 기준 clustering으로 스캔 바이트와 비용을 절감; 확장 가능한 중앙값을 위한 approximate quantiles; 반복 롤업을 위한 materialized views 또는 scheduled queries. - Looker Studio: direct BigQuery connector, cached results, 피크/비피크 및 계절 구간을 위한 parameterized filters. - Vertex AI Workbench: BigQuery client/BigQuery Storage API를 사용해 필요한 subset만 가져오기; 가설 검정 및 다중 비교 보정을 위해 통계 라이브러리(SciPy/Statsmodels) 실행. 이는 Google Cloud Architecture Framework 원칙(관리형 서비스 선택, 비용/성능 최적화, 관심사 분리: 분석 vs 시각화 vs 고급 계산)과 일치합니다. 흔한 오해: A와 B는 노트북이 집계와 시각화 모두의 주 엔진이라고 가정하지만, 노트북은 수억 행을 스캔하는 데 최적화되어 있지 않아 과도하게 큰 인스턴스와 긴 실행 시간이 필요합니다. C는 근접하지만, 시각화에 대한 가장 리소스 효율적인 접근을 놓칩니다: Looker Studio를 BigQuery에 직접 연결하면 노트북 기반 플로팅 워크로드를 피할 수 있고, 더 많은 이해관계자가 폭넓게 탐색할 수 있습니다. 시험 팁: 매우 큰 데이터셋에서는 무거운 집계와 필터링은 BigQuery, 대시보드는 BI 도구, 특수 분석은 노트북을 기본 선택으로 두세요. “minimize computational resources”와 “use as much telemetry as possible” 같은 문구를 주의하세요—대개 서버리스 분석(BigQuery)과 direct-connect 시각화를 의미하며, 노트북으로 데이터를 내보내는 방식이 아닙니다.

8
문제 8

You are launching a grocery delivery mobile app across 3 cities and will use Google Cloud's Recommendations AI to build, test, and deploy product suggestions; you currently capture about 2.5 million user events per day, maintain a catalog of 120,000 SKUs with accurate price and availability, and your business objective is to raise average order value (AOV) by at least 6% within the next quarter while adhering to best practices. Which approach should you take to develop recommendations that most directly increase revenue under these constraints?

"You Might Also Like"는 탐색(discovery)에 흔히 사용되며 홈 피드에서 CTR을 개선할 수 있지만, CTR은 매출과 동일하지 않습니다. 홈 피드 사용자는 탐색 모드일 수 있어 추가 클릭이 더 큰 장바구니나 더 높은 AOV로 이어지지 않을 수 있습니다. 짧은 기간 내 AOV +6%라는 명시적 목표에는 홈 화면의 광범위한 개인화보다 구매 의도가 높은 순간에 교차 판매를 하는 것이 일반적으로 더 효과적입니다.

"Frequently Bought Together"는 장바구니 크기(부착률)를 늘리는 보완 상품을 추천하도록 목적에 맞게 설계되었습니다. 이러한 추천을 상품 상세 및 장바구니 페이지에 표시하면 구매 직전의 사용자를 타겟팅하게 되어 AOV와 매출에 가장 직접적인 영향을 줍니다. 이는 모범 사례와도 일치합니다. 높은 이벤트 볼륨에서 강한 purchase/add-to-cart 신호를 활용하고, 정확한 카탈로그 메타데이터(가격/재고 상태)를 사용해 품절 또는 관련 없는 상품을 추천하지 않도록 합니다.

이는 모범 사례를 거꾸로 적용한 것입니다. Recommendations AI Retail은 이벤트가 아이템에 올바르게 귀속되고 메타데이터로 보강될 수 있도록 제품 카탈로그가 먼저 존재해야 합니다. 이벤트를 먼저 가져오면 item IDs가 매칭되지 않아 학습 품질이 저하되고 가치 실현까지의 시간이 지연될 수 있습니다. 시스템은 이벤트로부터 누락된 메타데이터를 신뢰성 있게 "backfill"하지 않습니다. 카탈로그를 먼저 업로드/유지(또는 병행)한 다음 사용자 이벤트를 스트리밍/가져와야 합니다.

기본 카테고리/가격으로 placeholder SKU를 만드는 것은 추천 품질과 비즈니스 성과에 명백히 역효과입니다. Recommendations AI는 관련성 있는 결과를 학습하고 필터링/서빙하기 위해 정확한 아이템 속성(카테고리, 가격, 재고 상태)에 의존합니다. placeholder는 관련 없거나 오해를 부르는 추천(예: 잘못된 가격 또는 품절)을 유발해 사용자 신뢰와 전환을 해칠 수 있습니다. 또한 A/B 테스트 중 거버넌스와 측정을 복잡하게 만들어 결과에 노이즈를 증가시킵니다.

문제 분석

핵심 개념: 이 문제는 데이터 품질 모범 사례를 따르면서 구체적인 비즈니스 KPI(AOV/매출 증가)를 달성하기 위해 가장 적절한 Recommendations AI 모델 유형과 노출 위치를 선택하는 방법을 평가합니다. Recommendations AI는 서로 다른 사용자 의도와 노출 지면(홈 피드 vs 상품 상세 vs 장바구니)에 최적화된 다양한 추천 유형을 제공합니다. 정답이 맞는 이유: 매출/AOV를 가장 직접적으로 늘리려면 장바구니 크기와 부착률(주문에 보완 상품을 추가하는 비율)을 높여야 합니다. "Frequently Bought Together"는 동일한 거래에서 함께 구매되는 경우가 많은 상품을 추천하여 교차 판매(cross-sell)를 수행하도록 설계되었습니다. 이를 상품 상세 페이지, 특히 장바구니 페이지에 배치하면 구매 의도가 높은 사용자에게 노출되어, 분기 내에 추가 구매 전환이 일어나고 주문 금액이 증가할 가능성이 가장 큽니다. 하루 250만 이벤트와 잘 관리된 카탈로그(정확한 가격/재고 상태를 갖춘 12만 SKU)는 고품질 추천을 빠르게 학습하고 제공하기 위한 핵심 전제 조건을 충족합니다. 주요 기능 / 모범 사례: - Recommendations AI에서 Retail 도메인을 사용하고, 완전하고 정확한 제품 카탈로그(가격, 재고 상태, 카테고리, 속성 포함)와 대규모 사용자 이벤트(view, add-to-cart, purchase)를 확보합니다. - 이벤트 로깅에 user IDs(또는 visitor IDs), product IDs, timestamps, event types를 포함하고, 매출 영향도를 위해 purchase 및 add-to-cart 신호를 우선합니다. - 온라인 A/B 테스트(예: 자체 실험 프레임워크 사용)를 실행하여 노출 위치(PDP vs cart)를 비교하고, CTR만이 아니라 AOV, 전환율, 세션당 매출을 측정합니다. - Google Cloud Architecture Framework를 따릅니다: 비즈니스 목표(AOV)와 정렬하고, 데이터 품질 및 거버넌스(정확한 카탈로그)를 보장하며, 신뢰성/관측 가능성을 고려해 설계합니다(추천 서빙 지연 시간과 드리프트 모니터링). 흔한 오해: CTR에 최적화된 노출(홈 피드)은 성공적으로 보일 수 있지만 매출을 움직이지 못할 수 있습니다. 또한 카탈로그 품질을 지름길로 처리(placeholder 사용)하려 하면 모델 성능이 저하되는 경우가 많고 Retail 추천에 대한 모범 사례를 위반할 수 있습니다. 시험 팁: KPI가 매출/AOV라면 교차 판매/상향 판매(upsell) 추천 유형과 구매 의도가 높은 지면(PDP/cart)을 우선합니다. KPI가 참여/탐색이라면 홈 피드의 "You Might Also Like"가 적절할 수 있습니다. 항상 먼저 카탈로그를 가져오거나(또는 최신 상태로 유지) synthetic placeholder를 피하십시오. Recommendations AI는 정확한 아이템 메타데이터와 재고 상태에 크게 의존합니다.

9
문제 9

You are training a LightGBM model to forecast daily inventory for 120 stores using a small dataset (~60 MB) on Vertex AI; your training script needs a system library (libgomp) and several custom Python packages, and each run takes about 10 minutes, so you want job startup time to be under 2 minutes to minimize overhead. How should you configure the Vertex AI custom training job to minimize startup time while keeping the dataset easy to update?

정답입니다. 커스텀 컨테이너 이미지는 libgomp와 모든 Python 의존성을 사전 설치하여 런타임 설치 오버헤드를 제거하고 재현성을 향상시킵니다. 데이터셋을 Cloud Storage에 유지하면 컨테이너 이미지와 독립적으로 쉽게 업데이트할 수 있습니다. 60 MB 데이터셋의 경우 Cloud Storage 읽기 시간은 pip/apt 설치를 피함으로써 절약되는 시간에 비해 작아, 시작 시간 <2분 목표를 달성하는 데 도움이 됩니다.

틀렸습니다. 주요 문제는 이 옵션이 scikit-learn prebuilt container에 의존하고 런타임에 custom dependency를 설치한다는 점이며, 이는 시작 지연 시간과 변동성을 추가하여 2분 미만 요구 사항에 불리하게 작용합니다. 또한 system library인 libgomp의 필요성을 적절히 해결하지 못하는데, OS 수준 dependency는 Python source distribution이나 일반적인 pip 설치를 통해 신뢰성 있게 처리되지 않기 때문입니다. 추가로, dataset를 source package와 함께 번들링하는 것은 Vertex AI training input에 적절한 패턴이 아닙니다. dataset는 일반적으로 training code와 독립적으로 업데이트 및 버전 관리할 수 있도록 별도로 Cloud Storage에 저장해야 합니다.

오답입니다. 데이터셋을 컨테이너에 baked-in하면 데이터 다운로드 시간을 줄일 수는 있지만, 데이터가 갱신될 때마다 컨테이너 이미지를 재빌드하고 재배포해야 하므로 데이터셋 업데이트가 어려워집니다. 또한 이미지 크기가 커져 이미지 pull 시간이 증가할 수 있어 시작 시간 이점을 상쇄할 수 있습니다. 이는 데이터셋을 쉽게 업데이트해야 한다는 요구사항과 충돌합니다.

오답입니다. 데이터를 Cloud Storage에 유지하는 것은 업데이트에 유리하지만, requirements 파일로 시작 시 의존성을 설치하는 것이 핵심 문제입니다. 이는 상당한 지연을 추가하고 네트워크/패키지 리포지토리 이슈로 인해 신뢰성이 떨어질 수 있습니다. 또한 libgomp는 시스템 라이브러리이므로 apt-get 단계가 필요할 수 있어 시작 시간이 2분 요구사항을 더 쉽게 초과하게 됩니다.

문제 분석

핵심 개념: 이 문제는 Vertex AI Custom Training의 시작 시간이 환경 프로비저닝(컨테이너 이미지 pull + 의존성 설치)과 데이터 액세스 패턴(Cloud Storage에서 읽기)에 의해 어떻게 영향을 받는지 평가합니다. 또한 빠르고 반복 가능한 작업을 보장하기 위해 시스템 라이브러리(예: LightGBM용 libgomp)와 Python 의존성을 패키징하는 모범 사례도 테스트합니다. 정답인 이유: 옵션 A는 (1) OS 수준 의존성인 libgomp와 (2) 필요한 모든 Python 패키지 및 학습 entrypoint를 이미 포함한 커스텀 컨테이너 이미지를 사전 빌드하여 시작 시간을 최소화합니다. 이 접근 방식에서는 Vertex AI가 워커를 스케줄링하고 이미지를 pull하기만 하면 되며, 런타임에 apt 패키지나 pip 의존성을 설치하느라 추가 시간을 쓰지 않습니다. 데이터셋은 Cloud Storage에 유지되므로 이미지를 다시 빌드하지 않고도 쉽게 업데이트할 수 있습니다. 작은 데이터셋(~60 MB)의 경우 Cloud Storage에서 읽는 오버헤드는 최소이며, 일반적으로 런타임 의존성 설치 시간보다 훨씬 적습니다. 주요 기능 / 모범 사례: - 시스템 라이브러리 또는 비단순한 의존성이 필요할 때는 Custom Training에 커스텀 컨테이너를 사용합니다. 이는 Google Cloud Architecture Framework의 재현성과 운영 우수성에 부합합니다. - 데이터는 외부(Cloud Storage)에 유지하여 업데이트 시 이미지 재빌드가 필요 없도록 합니다. object versioning 또는 날짜 파티션 경로로 데이터를 버전 관리합니다. - 런타임 설치를 피합니다: 시작 시 pip/apt 실행은 지연을 증가시키고 네트워크 변동성을 유발하며 일시적인 리포지토리 이슈로 실패할 수 있습니다. - LightGBM은 일반적으로 libgomp(OpenMP)가 필요하므로, 이를 이미지에 baked-in하는 것이 신뢰할 수 있는 접근입니다. 흔한 오해: 자주 하는 실수는 사전 빌드된 컨테이너와 requirements.txt만 있으면 “충분하다”고 가정하는 것입니다. 실제로 작업 시작 시 시스템 패키지와 Python wheel을 설치하면 시작 시간이 2분 목표를 넘기는 경우가 많습니다. 또 다른 오해는 속도를 위해 데이터를 이미지에 포함(bake)하는 것인데, 이는 유지보수성을 해치고 데이터가 갱신될 때마다 재빌드를 강제합니다. 시험 팁: Vertex AI Custom Training에서는 OS 수준 의존성이나 엄격한 시작 시간 SLA가 필요할 때 커스텀 컨테이너를 선택합니다. 데이터셋은 쉬운 업데이트와 거버넌스를 위해 Cloud Storage(또는 BigQuery)에 유지합니다. 사전 빌드된 컨테이너는 의존성이 최소이고 빠르게 설치할 수 있거나, 더 긴 시작 시간을 허용할 수 있을 때 가장 적합합니다.

10
문제 10

You are building an end-to-end scikit-learn MLOps workflow in Vertex AI Pipelines (Kubeflow Pipelines) that ingests 50 GB of CSV data from Cloud Storage, performs data cleaning, feature selection, model training, and model evaluation, then writes a .pkl model artifact to a versioned path in a GCS bucket. You are iterating on multiple versions of the feature selection and training components, submitting each version as a new pipeline run in us-central1 on n1-standard-4 CPU-only executors; each end-to-end run currently takes about 80 minutes. You want to reduce iteration time during development without increasing your GCP costs; what should you do?

컴포넌트를 건너뛰거나 comment out하면 runtime을 줄일 수는 있지만, pipeline graph를 변경하는 수동적이고 오류가 발생하기 쉬운 워크플로우이며 중요한 validation을 우회할 수 있습니다. 또한 Vertex AI Pipelines의 built-in orchestration best practices를 활용하지 못합니다. 팀 환경에서는 재현성을 해치고, 서로 다른 run이 서로 다른 스텝 subset을 실행하게 되어 run 비교가 더 어려워집니다.

Step caching은 정확히 이 시나리오(일부 컴포넌트만 변경되는 반복적인 pipeline run)를 위해 설계되었습니다. caching을 활성화하면 ingestion과 cleaning 같은 변경되지 않은 스텝이 이전 출력물을 재사용할 수 있어 반복 시간을 단축하며, 실행되는 task 수가 줄어들기 때문에 일반적으로 비용도 낮아집니다. 이는 Vertex AI Pipelines/Kubeflow Pipelines 내에서 가장 직접적이고 MLOps에 부합하는 접근입니다.

Dataflow는 대규모 ETL에 매우 유용할 수 있지만, feature processing을 Dataflow로 마이그레이션하는 것은 운영 오버헤드를 추가하고 비용을 증가시킬 수 있는 재설계입니다(Dataflow job 과금, 잠재적인 always-on 리소스, 추가 integration). 또한 파이프라인이 여전히 비용이 큰 처리를 재트리거한다면 반복 속도를 본질적으로 해결하지 못하며, 결국 caching이 여전히 필요합니다.

T4 GPU를 추가하면 비용이 증가하며, 일반적으로 CPU-bound이고 GPU-accelerated가 아닌 scikit-learn training에는 거의 또는 전혀 이점이 없습니다. 설령 training이 빨라지더라도 전체 80분 runtime에는 상당한 data ingestion/cleaning 시간이 포함될 가능성이 높으므로, GPU는 주요 bottleneck을 해결하지 못하고 “비용을 늘리지 않고”라는 요구사항을 위반합니다.

문제 분석

핵심 개념: 이 문제는 반복적 개발(iterative development) 중 Vertex AI Pipelines(Kubeflow Pipelines) 실행 최적화, 특히 변경되지 않은 컴포넌트를 다시 계산하지 않기 위해 파이프라인/스텝 캐싱(일명 실행 결과 재사용)을 테스트합니다. 정답이 맞는 이유: 스텝 캐싱을 활성화하면 컴포넌트의 입력, container image, command, 그리고 관련 metadata가 변경되지 않았을 때 Vertex AI Pipelines가 이전 실행의 출력물을 재사용할 수 있습니다. feature selection과 training만 반복적으로 수정하는 워크플로우에서는 비용이 큰 upstream 스텝(예: Cloud Storage에서 50 GB ingest, cleaning, 그리고 안정적인 preprocessing)을 자동으로 건너뛸 수 있어, 추가 compute 리소스 없이 end-to-end runtime을 줄일 수 있습니다. machine 크기를 키우거나 accelerator를 추가하지 않으므로, 일반적으로 비용은 감소(소비되는 CPU-minutes 감소)하고 반복 속도는 향상됩니다. 주요 기능 / Best Practices: Vertex AI Pipelines는 task/component 레벨에서 caching을 지원합니다. Best practice는 다음과 같습니다: 1) deterministic 컴포넌트(동일 입력 -> 동일 출력)와 안정적인 base image를 보장합니다. 2) cache 동작이 예측 가능하도록 입력을 명시적으로 versioning합니다(예: generation number가 포함된 GCS URI 또는 versioned path). 3) cache를 의도적으로 무효화하지 않는 한, 컴포넌트 로직이나 output path에 timestamp/randomness를 포함하지 않습니다. 4) feature-selection 구성을 pipeline parameter로 사용하여 영향받는 스텝만 invalidation되도록 합니다. 이는 낭비성 재계산을 줄여 cost optimization과 operational excellence를 달성한다는 Google Cloud Architecture Framework 원칙과 일치합니다. 흔한 오해: 스텝을 “comment out”하는 것(옵션 A)이 유혹적일 수 있지만, 이는 pipeline definition을 변경하여 dependency를 깨뜨릴 수 있고 test coverage를 낮추며, 규율 있는 MLOps practice로서 확장되지 않습니다. Dataflow로 이동(옵션 C)은 성능을 개선할 수 있지만 추가 서비스가 도입되어 비용/복잡성이 증가할 수 있으며, “비용을 늘리지 않고” 반복 속도를 높이는 가장 직접적인 해결책이 아닙니다. GPU 추가(옵션 D)는 비용을 증가시키며 scikit-learn의 CPU-bound training에는 도움이 되지 않을 수 있습니다. Exam Tips: 파이프라인에서 더 빠른 반복에 대한 질문이라면, 하드웨어를 확장하기 전에 먼저 caching, modular component, parameterization을 고려하세요. 시험에서 “비용을 늘리지 않고 시간을 줄여라”는 문구는 더 큰 머신, GPU, 또는 서비스 마이그레이션이 아니라 재사용/caching을 강하게 시사합니다.

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

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

11
문제 11

Your team must deliver an ML solution on Google Cloud to triage warranty claim emails for a global appliance manufacturer into 8 categories within 4 weeks. You are required to use TensorFlow to maintain full control over the model's code, serving, and deployment, and you will orchestrate the workflow with Kubeflow Pipelines. You have 30,000 labeled examples and want to accelerate delivery by leveraging existing resources and managed services instead of training a brand-new model from scratch. How should you build the classifier?

Natural Language API는 pretrained NLP 기능(sentiment, entity extraction, 제한된 content classification taxonomy)을 제공합니다. 통합은 빠르지만 모델 architecture, training, deployment에 대한 제어가 최소입니다. 또한 custom 8-category warranty triage 라벨을 지원하지 않을 수 있습니다. 이는 TensorFlow를 사용하고 code, serving, deployment를 완전히 제어해야 한다는 요구사항과 충돌하므로 여기에는 부적합합니다.

AutoML Natural Language는 라벨링된 데이터로 custom text classifier를 빠르게 학습할 수 있어 신속한 delivery에 종종 좋은 선택입니다. 하지만 이는 관리형 training 및 serving 솔루션이므로 TensorFlow 모델 code와 deployment 메커니즘을 완전히 제어할 수 없습니다. pipeline에서 orchestration할 수는 있지만, TensorFlow에 대한 완전한 제어라는 명시적 요구사항을 위반하므로 최선의 답이 아닙니다.

검증된 text classification 모델(pretrained language model 또는 embedding backbone)로 transfer learning을 하면 30,000개의 라벨링된 이메일에 대해 빠르고 안정적으로 fine-tuning할 수 있습니다. TensorFlow로 training을 구현하고 모델을 패키징한 뒤 custom serving(Vertex AI custom containers 또는 GKE/KServe)으로 배포함으로써 완전한 제어를 유지합니다. 이는 4주 타임라인에 부합하고 기존 리소스를 활용하며 Kubeflow Pipelines orchestration에도 적합합니다.

기존 text classification 모델을 “그대로” 사용하는 것은 타깃 라벨이 구체적(8개의 warranty triage 카테고리)이라 pretrained 모델의 원래 label set 또는 taxonomy와 일치하지 않기 때문에 성공 가능성이 낮습니다. 모델이 generic category를 출력하더라도 비즈니스 class로 깔끔하게 매핑되지 않습니다. 요구사항은 기존 리소스 활용을 강조하지만 여전히 customization을 내포하므로 transfer learning이 필요합니다.

문제 분석

핵심 개념: 이 문제는 TensorFlow를 사용한 Google Cloud(Vertex AI/legacy AI Platform)에서의 transfer learning 적용 시점과, 완전 관리형 “no/low-code” NLP 서비스 사용 시점을 구분하는지를 평가합니다. 또한 모델 코드, serving, deployment에 대한 완전한 제어와 Kubeflow Pipelines를 통한 pipeline orchestration 요구사항이 있는 제약 조건을 다룹니다. 정답이 맞는 이유: 라벨링된 이메일이 30,000개이고 기간이 4주뿐이므로, 최신 NLP 모델을 처음부터 학습하는 것은 불필요하고 리스크가 큽니다. “TensorFlow를 사용해 모델의 code, serving, deployment를 완전히 제어”해야 한다는 요구사항은 관리형 black-box training/serving 접근(Natural Language API classification, AutoML Natural Language)을 배제합니다. 최적의 선택은 검증된 text classification 모델(예: pretrained Transformer encoder 또는 TF Hub text embedding/classifier backbone)에서 시작해 8개의 warranty 카테고리에 맞게 fine-tuning하는 것입니다. 이는 전형적인 transfer learning으로, 수렴을 가속하고 데이터 요구량을 줄이며 정확도와 time-to-market을 개선합니다. TensorFlow로 training을 구현하고, model artifact를 패키징한 뒤, Vertex AI Prediction(또는 GKE)에 custom containers로 배포하며, 전체를 Kubeflow Pipelines로 orchestration할 수 있습니다. 주요 기능 / best practices: pretrained language representations(예: BERT-style encoders 또는 TF Hub text embeddings)을 사용하고 8개 class에 대한 classification head를 fine-tuning합니다. data validation, preprocessing(tokenization), training, evaluation(클래스별 precision/recall, confusion matrix), conditional deployment를 위한 component로 Kubeflow Pipeline을 구성합니다. 재현성을 위해 Vertex AI custom training jobs(또는 GKE)를 사용하고, 제어된 serving을 위해 Vertex AI Model Registry + endpoints(또는 KFServing/KServe)를 사용합니다. 글로벌 이메일 언어 고려사항(필요 시 multilingual models)과 drift monitoring을 보장합니다. 흔한 오해: Managed APIs(Natural Language API)는 빠르게 느껴지지만 모델 code와 deployment에 대한 완전한 제어를 제공하지 않습니다. AutoML도 빠르지만 training을 추상화하며 일반적으로 “완전한 제어” 요구사항을 충족하지 못합니다. pretrained model을 “그대로” 사용하는 것은 warranty triage 카테고리 같은 도메인 특화 라벨에 거의 맞지 않습니다. 시험 팁: 문제가 TensorFlow 제어와 custom deployment를 명시적으로 요구하면 AutoML/APIs보다 custom training/transfer learning을 우선합니다. 라벨이 도메인 특화인 경우 zero-shot이나 off-the-shelf classification보다 fine-tuning을 예상해야 합니다. “delivery 가속” + “limited data”는 transfer learning으로 매핑하세요.

12
문제 12

You are building an anomaly detection model for an industrial IoT platform using Keras and TensorFlow. The last 24 months of sensor events (~900 million rows, ~2.6 TB) are stored in a single partitioned table in BigQuery, and you need to apply feature scaling, categorical encoding, and time-window aggregations in a cost-effective and efficient way before training. The trained model will be used to run weekly batch inference directly in BigQuery against newly ingested partitions. How should you implement the preprocessing workflow?

Dataproc/Spark는 대규모 데이터셋을 전처리할 수 있지만, 변환된 Parquet를 Cloud Storage로 export하면 추가적인 데이터 이동, 스토리지 관리, pipeline 운영이 발생합니다. 또한 주간 inference가 BigQuery에서 직접 실행되어야 하므로 training/serving skew 위험이 있습니다. 동일한 feature logic을 BigQuery에 재구현하거나 새 partitions를 지속적으로 export해야 합니다. 일반적으로 BigQuery에서 feature engineering을 수행하는 것보다 비용 효율성과 일관성이 떨어집니다.

2.6 TB(900M rows)를 로컬 pandas DataFrame으로 로드하는 것은 메모리와 compute 제약으로 인해 불가능하며, 매우 느리고 비용이 많이 듭니다. 또한 프로덕션 ML을 위한 확장성과 운영 Best Practices를 위반합니다. 이 옵션은 distributed processing과 BigQuery의 강점을 무시하며, BigQuery에서의 지속적인 주간 inference를 지원하려면 다른 곳에서 전처리 로직을 중복해야 합니다.

BigQuery SQL은 partition pruning, clustering, window functions를 사용해 이 규모에서 feature scaling, categorical encoding, time-window aggregations에 이상적입니다. 전처리를 BigQuery에 유지하면 데이터 이동이 줄어들고, training과 새 partitions에 대한 주간 batch inference 모두에서 일관된 feature definitions를 지원합니다. TensorFlow I/O BigQuery connector로 tf.data pipeline에 데이터를 공급하면 거대한 중간 파일을 export하지 않고도 확장 가능한 training input을 구현할 수 있습니다.

Dataflow/Beam은 streaming과 ETL에 강하지만, 전처리된 데이터를 CSV로 쓰는 것은 비효율적입니다(큰 크기, 느린 parsing, poor typing) 그리고 스토리지 및 pipeline 오버헤드를 증가시킵니다. 옵션 A와 마찬가지로 inference가 BigQuery에서 실행되어야 하므로 training/serving consistency를 복잡하게 만듭니다. 여전히 동등한 SQL feature logic 또는 새 partitions에 대한 반복 exports가 필요해 비용과 운영 복잡성이 증가합니다.

문제 분석

핵심 개념: 이 문제는 source of truth가 BigQuery이고 inference가 BigQuery에서 실행될 때, 확장 가능한 feature engineering과 training data input pipeline을 테스트합니다. 전처리를 데이터(BigQuery SQL) 쪽으로 밀어 넣고, TensorFlow로 효율적이고 분산된 ingestion을 사용하는 것을 강조합니다. 정답이 맞는 이유: 옵션 C는 전체 워크플로를 BigQuery를 중앙 분석 엔진으로 정렬합니다. BigQuery는 partition pruning, clustering, window functions, SQL 기반 feature engineering을 사용해 대규모 변환(2.6 TB, 900M rows)에 매우 적합합니다. scaling, categorical encoding, time-window aggregations를 BigQuery에서 수행하는 것은 관련 partition(예: 최근 24개월)만 스캔하도록 제한하고, features를 파생 테이블 또는 view로 materialize할 수 있기 때문에 비용 효율적입니다. training의 경우 TensorFlow I/O BigQuery connector(또는 동등한 BigQuery-to-tf.data integration)를 사용하면 거대한 중간 파일을 export하지 않고도 데이터를 tf.data pipeline으로 streaming할 수 있어 shuffling, batching, parallel reads를 지원합니다. 또한 이는 주간 batch inference를 “BigQuery에서 직접” 수행하는 요구사항과도 feature logic을 일관되게 유지합니다(예: BigQuery ML remote models를 통해 또는 동일한 SQL feature view를 새 partitions에 적용). 주요 기능 / Best Practices: - partitioned tables와 partition column에 대한 WHERE filters를 사용해 스캔되는 bytes와 비용을 최소화합니다. - 성능을 위해 window functions(예: 시간 window에 대한 SUM/AVG)와 필요 시 APPROX functions를 사용합니다. - engineered features를 partitioned/clustered feature table로 materialize하여 재계산을 피하고 재현성을 개선합니다. - training과 주간 inference 모두에서 동일한 SQL feature definitions를 재사용하여 training/serving consistency를 보장합니다. - Google Cloud Architecture Framework 원칙을 따릅니다: 비용 최적화(partition pruning), 성능(BigQuery의 distributed execution), 운영 우수성(feature truth의 단일 source). 흔한 오해: Spark/Dataflow pipelines는 강력할 수 있지만, 큰 중간 데이터셋을 export하면 운영 오버헤드, 스토리지 비용이 증가하고, inference가 BigQuery에서 다른 로직으로 수행될 경우 training/serving skew 위험이 커집니다. 특히 CSV exports는 이 규모에서 매우 비효율적입니다. 시험 팁: 데이터가 이미 BigQuery에 있고 inference가 BigQuery에서 실행된다면, SQL 기반 feature engineering을 선호하고 불필요한 ETL exports를 피하세요. 데이터 이동을 최소화하고, partitioning/clustering을 활용하며, training과 serving 전반에서 전처리 로직을 일관되게 유지하는 답을 고르세요.

13
문제 13

Your edtech company operates a live Q&A chat in virtual classrooms, where an automated text moderation model flags toxic messages. After recent complaints, you discover that benign messages referencing certain indigenous festivals are being misclassified as abusive; an audit on a 10,000-message holdout shows a 12–15% false positive rate for messages containing those festival names versus 3% overall, and those references make up <1% of your training set. With a tight budget and an overextended team this quarter, a major overhaul or full replacement is not feasible; what should you do?

정답. 해당 하위 그룹 용어는 학습에서 드물고, 홀드아웃 감사에서 큰 false positive 격차가 확인됩니다. 그 축제 문구를 포함하는 큐레이션된 또는 신중히 검토된 합성 non-toxic 예시를 추가하면 대표성이 증가하고 모델이 올바른 문맥을 학습하는 데 도움이 됩니다. 이는 근본 원인을 해결하는 타깃형, 예산 친화적 완화책이며, 재배포 전에 슬라이스 기반 지표로 검증할 수 있습니다.

오답. 사람 검수로 완전히 전환하면 모델 기반 편향은 줄일 수 있지만, 일반적으로 비용이 많이 들고 느리며 실시간 교실 채팅에서 확장하기 어렵습니다. 또한 자동화의 이점(지연 시간과 커버리지)을 제거하며, 팀이 과부하이고 예산이 빠듯하다는 제약과도 맞지 않습니다. 타깃형 모델 개선이 더 실용적입니다.

오답. 상용 분류기로 교체하는 것은 통합, 평가, 재학습 비용이 드는 큰 변경이며, 유사한 편향을 보이거나 도메인 특화 언어(축제 이름, 슬랭, 교실 문맥)에서 성능이 낮을 수 있습니다. 설령 도입하더라도 대표성 있는 데이터와 슬라이스 기반 평가가 여전히 필요하므로, 핵심 문제를 효율적으로 해결하지 못합니다.

오답. 전역 임계값을 높이면 전체 플래그는 줄지만 이는 둔감한 수단입니다. 영향을 받는 하위 그룹의 false positive를 특정적으로 줄이지 못하고, 실제로 toxic한 메시지에 대한 false negative를 크게 늘려 안전성을 훼손할 수 있습니다. 또한 전체 플래그율이 떨어지더라도 격차가 지속될 수 있어 공정성 목표에도 부합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 책임 있는 ML 운영을 평가합니다. 즉, 하위 그룹 간 상이한 오류율을 유발하는 편향/대표성 격차를 진단하고 완화하는 것입니다. 또한 큰 아키텍처 변경보다는 제약 조건 하에서의 실용적인 모델 개선—타깃 데이터 증강과 재학습—을 다룹니다. 이는 Google Cloud Architecture Framework의 Responsible AI 및 Operational Excellence 원칙(측정, 모니터링, 최소 위험 변경으로 반복적 개선)과 일치합니다. 정답이 맞는 이유: 감사 결과는 명확한 슬라이스 기반 성능 문제를 보여줍니다. 특정 축제 이름이 포함된 메시지는 false positive rate가 12–15%로 전체 3% 대비 높고, 해당 용어는 학습 데이터에서 과소대표(<1%)되어 있습니다. 이는 소수 하위 그룹에 대한 일반화가 떨어지는 전형적인 데이터 불균형/커버리지 문제입니다. 해당 문구를 포함하는 명확한 non-toxic 예시(합성 또는 큐레이션)를 타깃으로 추가하면 대표성을 개선하고, 모델이 이러한 토큰이 본질적으로 toxic가 아님을 학습하도록 도와 근본 원인을 직접 해결합니다. 이는 시스템 교체나 전역 임계값 변경에 비해 레버리지가 크고 비용이 낮은 개입입니다. 핵심 특징 / 모범 사례: 슬라이스 기반 평가(예: 키워드, 로케일, 또는 인구통계 프록시 기준)를 사용하고, 재학습 전/후 하위 그룹 지표(false positive rate, precision)를 추적합니다. 과적합이나 아티팩트 유입을 피하기 위해 소량의 고품질 증강 세트와 검증을 선호합니다. 합성 데이터(LLM 생성)를 사용하는 경우, 사람 검토와 중복 제거를 적용하고 프로덕션 언어 패턴과 일치하도록 보장합니다. class/feature balancing으로 재학습하고, 예측된 toxicity가 실제 비율과 정렬되도록 calibration 점검도 고려합니다. 흔한 오해: 전역 임계값(D)을 올리면 플래그는 줄 수 있지만 하위 그룹 격차를 해결하지 못하며, 실제로 toxic한 콘텐츠에 대한 false negative가 증가할 수 있습니다. 모델 교체(C)는 비용과 위험이 크며, 상용 모델도 유사한 편향을 공유하는 경우가 많고 여전히 도메인 적응이 필요합니다. 자동화를 제거(B)하면 운영 비용이 커지고 확장성/지연 시간에 악영향을 줍니다. 시험 팁: “하위 그룹의 오류율이 훨씬 나쁨”과 “학습에서 과소대표”가 함께 보이면, 시험은 보통 데이터 중심 해결책을 기대합니다. 즉, 대표성 있는 데이터를 수집/증강한 뒤 재학습하고 슬라이스 지표로 재평가하는 것입니다. 근본 원인을 최소한의 영향 범위로 해결하며 Responsible AI 모니터링과 지속적 개선에 부합하는 선택지를 고르세요.

14
문제 14

A fintech analytics team has migrated 12 time-series forecasting and anomaly-detection models to Google Cloud over the last 90 days and is now standardizing new training on Vertex AI. You must implement a system that automatically tracks model artifacts (datasets, feature snapshots, checkpoints, and model binaries) and end-to-end lineage across pipeline steps for dev, staging, and prod; the solution must be simple to adopt via reusable templates, require minimal custom code, retain lineage for at least 180 days, and scale to future models without re-architecting; what should you do?

Vertex AI Pipelines는 Vertex ML Metadata와 native로 통합되어 lineage를 자동으로 캡처합니다. 즉, 컴포넌트 실행별로 어떤 inputs가 어떤 outputs를 생성했는지, pipeline runs 전반에서 추적합니다. Vertex AI SDK를 사용하면 재사용 가능한 pipeline templates와 components를 구현할 수 있어 custom code를 최소화하면서 dev/stage/prod 워크플로를 표준화할 수 있습니다. 새로운 모델이 추가되어도 lineage 캡처가 built-in이고 일관되며, artifact URIs가 중앙에서 추적되므로 확장성이 뛰어납니다.

아티팩트는 Vertex AI Pipelines로, lineage는 MLflow로 혼합하면 불필요한 운영 복잡성이 추가되고 표준화가 약화됩니다. MLflow tracking은 Vertex Pipelines의 native lineage store가 아니므로, 파이프라인 단계, 아티팩트, environments를 상관관계로 묶기 위한 custom integration이 필요합니다. 이는 “minimal custom code” 및 “재사용 가능한 templates로 간단히 도입” 요구사항을 위반하며, 시간이 지날수록 유지보수 부담이 증가합니다.

Vertex AI Experiments는 주로 experiment/run tracking(parameters, metrics, comparisons)을 위한 것이며, multi-step pipelines와 아티팩트 의존성 전반에 대한 완전한 end-to-end lineage를 제공하도록 설계되지 않았습니다. ML Metadata가 lineage를 저장할 수는 있지만, Experiments를 아티팩트에 사용하는 것은 부적절합니다. datasets, checkpoints, binaries 같은 아티팩트는 일반적으로 pipeline artifacts와 storage로 관리되고, MLMD가 그 관계를 자동으로 캡처합니다.

Cloud Composer로 Cloud Run functions를 스케줄링해 lineage 캡처를 수행하는 것은 custom-built metadata 시스템입니다. lineage를 추론하고, 아티팩트를 단계에 매핑하며, dev/stage/prod 전반에서 일관성을 유지하기 위해 상당한 bespoke code가 필요합니다. 이 접근은 표준화가 더 어렵고, audit-grade provenance에 대해 신뢰성이 낮으며, Vertex AI의 native MLMD 통합을 활용하지 못하므로 low-code, scalable governance에 부적합합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 엔드투엔드 ML 거버넌스를 테스트합니다. 즉, Vertex AI Pipelines와 Vertex ML Metadata (MLMD)를 사용해 파이프라인 단계/환경 전반에서 아티팩트(datasets, feature snapshots, checkpoints, model binaries)와 계보(lineage)를 추적하는 것입니다. 이는 Google Cloud Architecture Framework의 Operational Excellence(반복 가능한 자동화), Reliability(일관된 provenance), Security/Compliance(감사 가능성) 원칙과 정렬됩니다. 정답이 맞는 이유: Vertex AI Pipelines(Kubeflow Pipelines on Vertex)는 각 파이프라인 컴포넌트의 실행, 입력/출력, 아티팩트 URI를 기록하기 위해 Vertex ML Metadata와 자동으로 통합됩니다. Vertex AI SDK와 재사용 가능한 pipeline templates/components를 사용하면 low-code로 도입할 수 있습니다. 팀이 파이프라인 패턴을 한 번 표준화하면, 이후 모델들은 재설계 없이 아티팩트 및 계보 추적을 상속받습니다. 이는 최소한의 custom code, 재사용 가능한 templates, 추가 모델로의 확장 요구사항을 직접 충족합니다. 주요 기능 / 구현 방법: - Vertex AI SDK(KFP v2)와 표준 components(예: data extraction, feature generation, training, evaluation, deployment)로 pipelines를 정의합니다. - 각 단계가 typed artifacts(Dataset, Model, Metrics 등)를 생성하고 outputs를 durable storage(일반적으로 Cloud Storage)에 기록하도록 보장합니다. MLMD는 이러한 아티팩트에 대한 metadata/lineage 참조를 저장합니다. - 일관된 pipeline templates로 분리된 projects 또는 environments(dev/stage/prod)를 사용합니다. 계보는 run별로 캡처되며 감사 및 디버깅을 위해 query할 수 있습니다. - Retention: MLMD는 lineage/metadata를 보존합니다. 180-day 요구사항은 metadata와 기반 아티팩트 storage를 유지함으로써 충족됩니다(예: binaries/checkpoints에 대한 GCS lifecycle policies). 조직 정책이 요구한다면 dataset/model artifact retention 및 access controls를 구성합니다. 흔한 오해: 일부는 lineage에 MLflow가 필요하다고 가정하지만, Vertex에서는 MLMD가 Pipelines와 긴밀히 통합된 native lineage 시스템입니다. 또 다른 오해는 Vertex AI Experiments(run tracking)와 파이프라인 단계 전반의 전체 아티팩트 계보를 혼동하는 것입니다. Experiments는 multi-step pipelines에 대한 완전한 lineage 솔루션이 아닙니다. 시험 팁: “파이프라인 단계 전반의 end-to-end lineage”와 “templates/최소 custom code로 간단”을 보면, 기본 선택은 Vertex AI Pipelines + Vertex ML Metadata입니다. 요구사항이 명시적으로 third-party portability를 요구하지 않는 한 여러 도구를 조합하기보다 native integrations를 우선하세요. 또한 기억할 점: metadata는 references를 저장하고, artifact retention은 backing storage(대개 GCS)와 lifecycle policies로 처리됩니다.

15
문제 15

You manage the ML engineering team for a regional logistics network; most training runs are multi-node PyTorch Lightning jobs on managed training with NVIDIA T4 GPUs where a single experiment consumes ~3,000 GPU-hours, new model versions are released every 6–10 weeks, and finance requires at least a 40% reduction in training compute spend without degrading model quality or materially increasing wall-clock time; your pipeline already writes restartable checkpoints to Cloud Storage every 10 minutes with <2% overhead and can tolerate node interruptions. What should you do to reduce Google Cloud compute costs without impacting the model’s performance?

Vertex AI Training을 checkpoints와 함께 계속 사용하는 것은 resiliency를 개선하지만, 그것만으로는 요구되는 >=40% 비용 절감을 보장하지 않습니다. 기반 compute가 on-demand T4 GPUs로 유지된다면 지출은 현재 수준과 유사할 것입니다. 운영 측면에서는 단순해 매력적이지만, 문제의 명시적 비용 목표와 중단 허용 조건은 단순한 내결함성 개선이 아니라 할인된 interruptible capacity 사용을 가리킵니다.

checkpoints 없이 distributed training을 실행하는 것은 위험하며, 중단 허용이라는 조건과도 충돌합니다. checkpoints가 없으면 node preemption 또는 failure 시 처음부터 재시작하거나 상당한 진행 상황을 잃을 수 있어 wall-clock time이 실질적으로 증가하고 총 비용이 오히려 늘 수 있습니다. 작은 checkpoint 오버헤드(<2%)는 GPU-hour 비용에 비해 의미 있는 절감 레버가 아니므로, checkpoints 제거는 나쁜 트레이드오프입니다.

이 선택지는 가장 강력한 비용 레버(Spot/Preemptible GPU pricing)와 필요한 engineering control plane(Kubeflow on GKE), 그리고 이미 구현된 빈번한 Cloud Storage checkpoints를 결합합니다. 워크로드가 중단을 허용하고 checkpoints가 빈번하므로, preemption당 손실 작업이 작아 wall-clock time을 대체로 안정적으로 유지하면서 큰 compute 비용 절감을 달성하는 데 도움이 됩니다. 이는 모델 품질에 영향을 주지 않으면서 재무 요구사항을 가장 잘 충족합니다.

Spot/Preemptible GPU node pools를 사용하면 비용을 줄일 수 있지만, checkpoints 없이 그렇게 하면 eviction 이후 큰 재계산이 발생할 가능성이 높고 wall-clock time이 크게 증가할 수 있습니다. multi-node distributed training에서는 단일 node 중단이 전체 job을 방해할 수 있으며, checkpoints가 없으면 복구 비용이 커져 절감 효과를 상쇄할 수 있습니다. 파이프라인이 이미 효율적인 checkpointing을 지원하므로 이를 생략할 이유가 없습니다.

문제 분석

핵심 개념: 이 문제는 GPUs에서 대규모 학습을 수행할 때의 비용 최적화를 평가하며, 특히 중단 가능한 용량(Spot/Preemptible GPUs)을 자주 수행하는 checkpoints를 통한 내결함성 학습과 함께 사용하는지를 묻습니다. 또한 특정 가격 모델을 활용하기 위해 managed training(Vertex AI Training)과 self-managed orchestration(GKE/Kubeflow) 중 언제 무엇을 선택해야 하는지도 간접적으로 테스트합니다. 정답인 이유: 모델 품질을 저하시키지 않으면서 학습 compute 지출을 최소 40% 절감하려면, 가장 직접적인 레버는 on-demand GPU VMs에서 Spot(Preemptible) GPU 용량으로 전환하는 것입니다. 이는 일반적으로 on-demand 대비 큰 폭으로 할인됩니다. 해당 워크로드는 이미 10분마다 Cloud Storage에 재시작 가능한 checkpoints를 최소 오버헤드(<2%)로 기록하고 있으며 중단을 허용할 수 있는데, 이는 Spot/Preemptible 리소스를 사용하되 wall-clock time을 실질적으로 증가시키지 않기 위한 정확한 전제 조건입니다. multi-node distributed PyTorch Lightning에서는 worker를 재시작하고 최신 checkpoint에서 재개함으로써 중단을 처리할 수 있어, 손실되는 작업량은 대략 checkpoint 간격 수준으로 제한됩니다. 주요 기능 / 구성 / 모범 사례: - Spot/Preemptible GPU nodes(예: T4)를 사용하는 GKE node pools를 사용하고, 필요에 따라 autoscaling 및 node auto-provisioning을 구성합니다. - Kubeflow(예: PyTorchJob)로 학습을 실행하여 controller가 eviction 이후 pods를 재생성하고 Cloud Storage checkpoints에서 재개할 수 있게 합니다. - 품질 저하를 방지하기 위해 checkpointing에 optimizer state, RNG seeds(필요 시), distributed state를 포함합니다. - PodDisruptionBudgets 및 적절한 retry/backoff policies를 사용하고, checkpoint 빈도를 허용 가능한 작업 손실량에 맞춥니다. - 이는 Google Cloud Architecture Framework의 비용 최적화와 일치합니다: 중단 가능한 워크로드에는 할인된 compute를 사용하고 resiliency를 고려해 설계합니다. 흔한 오해: 흔한 함정은 Vertex AI Training이 자동으로 동일한 Spot GPU 절감 효과를 제공한다고 가정하는 것입니다. Vertex AI는 다양한 accelerators와 managed infrastructure를 지원하지만, 여기 제시된 선택지의 맥락에서는 Spot/Preemptible GPU node pools를 확실히 사용하려면 GKE/Kubeflow로 마이그레이션하는 것이 보장된 경로임을 시사합니다. 또 다른 오해는 오버헤드를 줄이기 위해 checkpoints를 비활성화하는 것인데, 오버헤드는 이미 <2%이며 checkpoints를 제거하면 중단 시 대규모 재계산 위험이 커집니다. 시험 팁: “>=40% 비용 절감”, “중단 허용”, “빈번한 checkpoints” 같은 요구사항이 보이면 Spot/Preemptible compute와 견고한 재시작 로직을 떠올리세요. 또한 모델 품질을 보존(알고리즘 변경 없음)하고 checkpointing으로 작업 손실을 최소화해 wall-clock time의 큰 증가를 피하는 선택지를 우선하세요.

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

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

16
문제 16

Your robotics team is deploying a quality inspection system for ceramic floor tiles on a high-speed conveyor line; each tile is captured as a 3840x3840 RGB image under controlled lighting, and you have 60,000 labeled images (defective vs. non-defective); operations managers require pixel-level attribution heatmaps overlaid on each image so they can pinpoint hairline cracks and decide whether to discard a tile within the same shift. How should you build the model?

오답입니다. scikit-learn의 tree 기반 모델은 tabular feature를 대상으로 하며, raw pixel을 사용하면 이미지당 수천만 개의 feature가 되어 비현실적입니다. 엔지니어링된 feature를 쓰더라도 공간적 국소화 정보가 손실됩니다. SHAP value는 feature attribution을 제공할 수 있지만, 이미지에서는 계산 비용이 매우 커지고, 프로덕션 환경에서 3840x3840 해상도에서 깔끔한 픽셀 수준 크랙 국소화를 자연스럽게 제공하기 어렵습니다.

오답입니다. Partial dependence plot은 하나(또는 소수)의 feature를 변화시켰을 때 예측이 평균적으로 어떻게 변하는지 보여주는 전역 해석 도구입니다. 개별 예제에 대한 픽셀 수준 attribution을 위해 설계되지 않았고, tabular feature 표현을 전제로 합니다. 국소화된 히트맵이 필요한 이미지 검사에서는 PDP가 잘못된 설명 방식이며, 각 타일에서 헤어라인 크랙 위치를 특정해야 하는 운영 요구사항을 충족하지 못합니다.

정답입니다. TensorFlow 딥러닝 모델(CNN/transfer learning)은 이미지 분류의 표준 접근이며, 헤어라인 크랙 같은 공간 패턴을 픽셀로부터 직접 학습할 수 있습니다. Integrated Gradients는 미분 가능한 모델을 위한 gradient 기반 설명 기법으로 입력별(per-input) 기여도를 생성하며, 이를 이미지 위에 픽셀 수준 히트맵으로 시각화할 수 있어—국소화된 결함 증거를 요구하는 매니저의 요구사항과 일치합니다.

이 시나리오에서는 대체로 오답입니다. TensorFlow는 비전 모델에 적합하지만, sampled Shapley 방법은 3840x3840 RGB 이미지처럼 매우 고차원 입력에서 보통 계산 부담이 너무 큽니다(특히 운영에서 설명을 반복적으로 생성해야 하는 경우). Shapley 근사는 노이즈가 있을 수 있고 안정적인 픽셀 수준 맵을 위해 많은 샘플이 필요하므로, Integrated Gradients가 더 실용적이고 시험에서도 더 흔히 다뤄지는 선택입니다.

문제 분석

핵심 개념: 이 문제는 고해상도 이미지 검사에 적합한 모델 패밀리를 선택하고, 픽셀 수준 기여도(Attribution) 히트맵을 생성하는 설명(Explainability) 방법을 고르는지를 평가합니다. GCP/ML Engineer 관점에서는 딥 비전 모델(예: TensorFlow의 CNN/ViT)을 사용하고, 조밀한(dense) 픽셀 단위 해석 가능성에 적합한 gradient 기반 설명 기법을 적용하는 내용입니다. 정답이 맞는 이유: 3840x3840 RGB 이미지에서 헤어라인 크랙을 탐지하는 경우, scikit-learn의 tree 기반 모델은 엔지니어링된 tabular feature를 필요로 하고 공간적 구조를 자연스럽게 보존할 수 없기 때문에 부적합합니다. 딥러닝 비전 모델(TensorFlow/Keras)은 픽셀로부터 공간 패턴을 직접 학습할 수 있고, 대규모 데이터셋(라벨된 이미지 60,000장)에도 확장 가능합니다. 운영 매니저는 픽셀 수준 기여도 오버레이를 요구하며, Integrated Gradients(IG)는 미분 가능한(differentiable) 모델을 위해 설계되어 입력 픽셀에 정렬된 saliency/attribution 맵을 생성하므로 크랙 영역을 하이라이트하는 데 적합합니다. 또한 IG는 큰 입력에서 Shapley 계열 방법보다 상대적으로 효율적입니다. 주요 특징 / Best Practices: CNN 기반 분류기(또는 EfficientNet/ResNet을 활용한 transfer learning)를 사용하고, 각 예측에 대해 IG attribution을 생성합니다. 이미지가 매우 크므로 지연 시간(latency) 요구를 맞추기 위해 일반적으로 downsample, crop/patch, 또는 2단계 접근(거친(coarse) 모델 후 고해상도 patch 검사)을 사용합니다. IG는 baseline(예: 검은 이미지 또는 blurred 이미지)과 여러 interpolation step이 필요하므로, 충실도(fidelity)와 처리량(throughput) 간 균형을 고려해 step 수를 선택합니다. 이는 Google Cloud Architecture Framework의 성능 및 신뢰성 원칙(저지연 추론과 운영 사용성—동일 근무조 내 의사결정을 위한 해석 가능한 출력)을 충족하는 설계와도 일치합니다. 흔한 오해: SHAP은 설명 가능성에서 인기가 있지만, Shapley 방법은 계산 비용이 크고 3840x3840x3처럼 매우 고차원 입력에서는 확장성이 떨어집니다. PDP는 tabular 환경에서 전역(global) feature 효과를 설명하며 픽셀 수준 위치 추정을 제공하지 않습니다. 이미지에 대한 sampled Shapley는 이론적으로 가능하지만, 고해상도·고처리량 검사에서는 보통 너무 느리거나 노이즈가 큽니다. 시험 팁: “pixel-level heatmap” + “images” + “localize defects”를 보면, 딥 비전 모델 + gradient 기반 attribution(Integrated Gradients, Grad-CAM)을 우선 고려하세요. SHAP/PDP는 주로 tabular 모델에 사용합니다. 또한 실무 제약도 고려해야 합니다. 고차원 입력은 Shapley 계열 설명의 비용을 크게 만들며, 이는 프로덕션 검사 파이프라인에서 중요합니다.

17
문제 17

A digital payments startup trained a binary classification model on Vertex AI to flag potentially fraudulent card transactions using 24 months of historical data (validation AUC = 0.93) and deployed it to a Vertex AI online endpoint that processes ~60,000 requests per day; after 4 weeks, the production AUC computed from feedback labels has dropped to 0.76, while autoscaling shows sufficient replicas and Cloud Monitoring reports P95 latency around 110 ms and error rate < 0.1%. What should you do first to troubleshoot the drop in predictive performance?

정답입니다. latency/error rate가 안정적인데 AUC가 저하되는 것은 서빙 용량 문제라기보다 data drift 또는 training-serving skew를 가리킵니다. Vertex AI Model Monitoring은 서빙 feature 분포를 baseline과 비교하고 어떤 feature가 drift되었거나 skew가 있는지 드러내도록 설계되었습니다. 이는 프로덕션 모집단이 바뀌었는지, feature 파이프라인이 깨졌는지, 또는 모델이 retraining/refresh가 필요한지 식별하는 가장 빠른 방법입니다.

오답입니다. CPU 및 memory utilization은 서빙 병목(예: saturation으로 인한 timeout)을 진단하는 데 도움이 되지만, 문제에서 autoscaling이 충분하고 latency가 낮으며 error rate가 <0.1%라고 명시합니다. 리소스 병목은 보통 latency 상승, throttling, 또는 error로 나타나며, 피드백 label로 계산한 AUC의 깔끔한 하락으로 나타나지 않습니다. 예측 성능 손실에 대한 첫 트러블슈팅 단계가 아닙니다.

첫 단계로는 오답입니다. Explainable AI attribution은 어떤 feature가 예측에 영향을 주는지 이해하는 데 도움이 되며, drift된 feature를 식별했거나 spurious correlation을 의심할 때 유용할 수 있습니다. 하지만 explanation은 분포 이동을 직접 측정하거나 training-serving mismatch를 확인하지 못합니다. 먼저 drift/skew를 확인하지 않으면, 실제로는 입력 분포 변화로 인해 발생한 attribution 변화를 잘못 해석할 수 있습니다.

오답입니다. latency/throughput 점검은 서빙 SLO를 검증하지만, 문제는 이미 건강한 서빙 metric(P95 ~110 ms, 낮은 error rate, 충분한 replica)을 제공합니다. SLO 준수 확인만으로는 AUC가 왜 떨어졌는지 설명할 수 없습니다. ML 시스템에서 예측 품질 이슈는 보통 데이터/label 변화, drift, skew, 또는 concept drift에 뿌리를 두므로, 성능 모니터링이 아니라 모델 모니터링이 필요합니다.

문제 분석

핵심 개념: 이 문제는 프로덕션에서 ML 솔루션 모니터링을 테스트하며, 특히 서빙 상태(지연 시간, 오류, autoscaling)가 정상으로 보이는데도 예측 품질(AUC)이 하락하는 상황을 진단하는 것입니다. Vertex AI에서 1차로 사용할 도구는 Vertex AI Model Monitoring이며, 성능 저하의 흔한 근본 원인인 data drift와 training-serving skew를 탐지합니다. 정답이 맞는 이유: 몇 주 후 AUC가 0.93(검증)에서 0.76(프로덕션 피드백)으로 떨어졌다는 것은, 모델이 더 이상 학습 분포와 일치하는 데이터를 보지 못하고 있거나, feature engineering/서빙 파이프라인이 학습 시점과 달라졌다는(skew) 강한 신호입니다. endpoint replica가 충분하고, P95 latency가 안정적(~110 ms)이며, error rate가 낮으므로 시스템은 예측을 올바르고 빠르게 서빙하고 있습니다. 문제는 인프라가 아니라 통계적(데이터/분포)일 가능성이 큽니다. 가장 효과적인 첫 트러블슈팅 단계는 입력 feature 분포가 이동했는지(data drift)와 online feature가 training feature와 일치하는지(training-serving skew)를 정량화하는 것입니다. Model Monitoring은 drift metric, threshold, feature별 신호를 제공하여 어떤 feature가 변했는지 빠르게 식별하고, 재학습(retraining), feature 파이프라인 수정, 또는 labeling 전략 업데이트 같은 개선 조치를 안내합니다. 주요 기능 / 모범 사례: Vertex AI Model Monitoring은 다음을 수행하도록 구성할 수 있습니다: - prediction request를 캡처(sampling)하고 feature 분포를 baseline(학습 데이터 또는 참조 기간)과 비교 - training data 통계와 serving request 통계를 비교하여 training-serving skew 탐지 - drift/skew가 threshold를 초과하면 Cloud Monitoring을 통해 알림 운영 측면에서 이는 Google Cloud Architecture Framework의 Reliability 및 Operational Excellence 원칙과 정렬됩니다: 모델 품질을 관측하고, 변화를 조기에 감지하며, 알림을 자동화합니다. drift를 식별한 후에는 일반적으로 upstream 데이터 소스, feature store freshness, schema 변경, seasonality, 새로운 fraud 패턴, 또는 정책 변경을 검증한 다음, retraining cadence, feature 업데이트, 또는 모델 교체를 결정합니다. 흔한 오해: CPU/memory, latency, throughput에 집중하고 싶어지는데, 이는 전형적인 프로덕션 이슈이기 때문입니다. 하지만 이러한 metric은 가용성/성능을 설명할 뿐 예측 품질을 설명하지는 못합니다. Explainable AI는 모델 동작 해석에 도움을 줄 수 있지만, 분포 이동이나 skew를 직접 진단하지는 못하며, 보통 drift를 확인한 뒤의 2차 단계입니다. 시험 팁: 서빙 metric은 건강한데 예측 metric이 악화되었다고 하면, drift/skew 및 label/feedback 무결성 모니터링을 우선시하세요. 먼저 Vertex AI Model Monitoring을 사용하고, 그다음 데이터 파이프라인, feature 생성, retraining trigger를 조사합니다.

18
문제 18

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를 피하고, 명시적으로 요구되지 않는 한 텍스트 포맷을 피하세요.

19
문제 19

Your e-commerce price-optimization model serves about 30,000 predictions per hour on a Vertex AI endpoint, and a Vertex AI Model Monitoring job is configured to detect training-serving skew using a 24-hour sliding window with a 0.3 sampling rate and a baseline dataset at gs://retail-ml/training/2025-06/data.parquet; after three consecutive windows reporting skew on features inventory_days and competitor_price, you retrained the model using the last 45 days of data at gs://retail-ml/training/2025-08/data.parquet and deployed version v2 to the same endpoint, but the monitoring job still raises the same skew alert—what should you do?

Sampling rate를 낮추면 서빙 분포를 추정하는 데 사용되는 prediction request 수가 줄어 monitoring 비용을 낮추고 때로는 노이즈가 큰 추정을 줄일 수 있습니다. 하지만 오래된 baseline과 비교해서 발생하는 체계적인 skew를 교정하지는 못합니다. 또한 분산을 증가시켜 실제 skew/drift를 놓칠 수 있어 reliability와 observability를 약화시킬 수 있습니다.

Training-serving skew는 baseline dataset을 기준으로 정의됩니다. gs://retail-ml/training/2025-08/data.parquet로 재학습하고 v2를 배포한 후에는, 비교가 새 model이 기대하는 feature 분포를 반영하도록 monitoring baseline을 동일한 데이터셋(또는 동등한 reference)으로 업데이트해야 합니다. 이는 근본 원인인 baseline/model 불일치를 직접 해결합니다.

더 많은 production traffic을 기다리는 것은 샘플 수가 부족하거나 cold-start 동작이 문제일 때 도움이 될 수 있습니다. 하지만 여기서는 배포 후에도 이미 3개의 연속 윈도우에서 alert가 발생했으므로 지속적인 분포 차이를 시사합니다. Baseline이 6월 데이터셋으로 유지된다면 추가 트래픽은 skew를 해결하지 못하고, 오히려 더 강하게 확인해줄 가능성이 큽니다.

다음 retrain까지 alert를 비활성화하는 것은 위험하며 좋은 MLOps 관행에 반합니다. Monitoring 커버리지를 희생하고 실제 데이터 문제(pipeline bug, upstream 변경, seasonality 영향)를 숨길 수 있습니다. 또한 monitoring baseline/구성을 수정하지 않고 다시 retrain하더라도, monitor가 여전히 잘못된 reference와 비교한다면 동일한 alert 패턴이 반복될 수 있습니다.

문제 분석

핵심 개념: 이 문제는 training-serving skew에 대한 Vertex AI Model Monitoring을 평가합니다. Skew detection은 정의된 윈도우(여기서는 24시간 sliding window)와 sampling rate 동안 온라인 예측(서빙 데이터)에서 관측된 feature 분포를 구성된 baseline dataset(일반적으로 training dataset)과 비교합니다. 정답인 이유: 더 최신의 45일 데이터셋(gs://retail-ml/training/2025-08/data.parquet)으로 model version v2를 재학습하고 배포했지만, monitoring job은 여전히 이전 baseline(gs://retail-ml/training/2025-06/data.parquet)과 서빙 트래픽을 비교하도록 구성되어 있습니다. 6월과 8월 사이에 feature 분포가 실제로 변화했다면(리테일의 가격, 재고, 경쟁사 동향에서 흔함), monitor는 오래된 기준 분포를 참조해 계속 skew를 감지하게 됩니다. 올바른 조치는 현재 배포된 model의 training data에 해당하는 데이터셋으로 Model Monitoring job의 baseline을 업데이트하는 것입니다. 주요 기능 / 모범 사례: - Baseline 관리: training-serving skew의 baseline은 배포된 model version의 training set(또는 큐레이션된 “golden” reference)과 정렬되어야 하며, model을 재학습할 때 업데이트되어야 합니다. - Windowing 및 sampling: Sliding window와 sampling rate는 민감도와 비용에 영향을 주지만, baseline 불일치를 해결하지는 못합니다. - 운영 관행: Baseline 업데이트를 배포/릴리스 프로세스(MLOps)의 일부로 취급하세요. 이는 Google Cloud Architecture Framework의 operational excellence 및 reliability 원칙과 정렬됩니다—monitoring은 현재 시스템 상태를 반영해야 합니다. 흔한 오해: - Sampling을 낮추는 것(Option A)은 알림 빈도를 줄일 수 있지만 실제 문제를 숨길 수 있으며, 근본 원인(잘못된 baseline)을 해결하지 못합니다. - 72시간을 기다리는 것(Option C)은 비교 대상이 이전 baseline인 한 도움이 되지 않습니다. 더 많은 트래픽은 동일한 불일치에 대한 증거만 더 제공합니다. - 다음 재학습까지 알림을 비활성화하는 것(Option D)은 anti-pattern입니다. Observability를 낮추고 실제 drift/skew가 탐지되지 않게 만들 수 있습니다. 시험 팁: Model 업데이트 후 monitoring alert가 지속되면 구성 결합(configuration coupling)을 확인하세요: baseline dataset, feature schema, objective thresholds, 그리고 monitor가 어떤 model/version에 연결되어 있는지. 특히 training-serving skew의 경우, 가장 먼저 확인할 것은 baseline이 현재 배포된 model version의 training data에 대응하는지 여부입니다.

20
문제 20

You trained an automated scholarship eligibility classifier for a national education nonprofit using Vertex AI on 1.2 million labeled applications, reaching an offline ROC AUC of 0.95; the review board is concerned that predictions may be biased by applicant demographics (e.g., gender, ZIP-code–derived income bracket, first-generation college status) and asks you to deliver transparent insight into how the model makes decisions for 500 sampled approvals and denials and to identify any fairness issues across these cohorts. What should you do?

Feature Store에서 feature를 분리하고 인구통계 없이 재학습하는 것은 요청된 분석이 아니라 remediation 시도입니다. 또한 이는 종종 실패하는 “fairness through unawareness” 위험이 있는데, proxy variable(예: ZIP code, 학교, 에세이 주제)이 여전히 인구통계를 인코딩할 수 있기 때문입니다. 더불어 민감 feature를 제거하면 보호 집단별 공정성 측정과 결과 감사가 더 어려워질 수 있습니다. 이사회는 먼저 투명한 인사이트와 cohort 공정성 평가를 요구했습니다.

Vertex AI feature attribution(Explainable AI)은 승인과 거절에 대해 인스턴스별 설명을 제공하며, 각 feature가 각 예측에 어떤 영향을 미쳤는지 정량화합니다. 이후 attribution과 결과를 cohort(성별, 소득 구간, 1세대)별로 집계·비교하여 잠재적 bias와 proxy-feature 의존성을 드러낼 수 있습니다. 이는 500개 샘플 의사결정에 대한 투명성 요구를 직접 충족하며, 그룹 수준 비교와 fairness metric을 사용한 공정성 분석을 지원합니다.

Vertex AI Model Monitoring은 training-serving skew, feature drift, prediction drift 같은 운영 이슈에 초점을 둡니다. 프로덕션 신뢰성에는 유용하지만, 특정 케이스에 대한 의사결정 투명성을 제공하지 않으며 인구통계 cohort 전반의 공정성 이슈를 직접 식별하지도 못합니다. 최근 데이터로 재학습하는 것은 기본 라벨링이나 과거 의사결정 프로세스가 bias되어 있다면 오히려 bias를 유지하거나 증폭시킬 수 있습니다. 이 선택지는 요청된 문제와 다른 문제를 다룹니다.

Vector Search의 nearest-neighbor retrieval은 유사한 예시를 찾는 데 도움이 될 수 있지만, explainability나 공정성 감사의 주요 도구는 아닙니다. similarity search는 embedding과 distance metric에 의존하며, 어떤 feature가 모델의 결정을 유도했는지 드러내거나 인구통계 영향도를 정량화하지 못할 수 있습니다. 보조적인 정성 조사 기법이 될 수는 있지만, 이사회가 요구한 체계적이고 feature별·cohort 기반의 투명성과 bias 증거를 제공하지는 못합니다.

문제 분석

핵심 개념: 이 문제는 Vertex AI에서의 모델 투명성과 공정성 평가를 테스트합니다. 구체적으로 explainability(feature attribution)를 사용해 개별 예측이 왜 발생했는지 이해한 뒤, 그 설명을 인구통계학적 cohort 전반에 걸쳐 분석하여 잠재적 bias를 탐지하는 것입니다. 이는 Google Cloud Architecture Framework(거버넌스, 리스크 관리, 신뢰)의 responsible AI 실천과 일치합니다. 정답이 맞는 이유: 이사회는 500개 샘플 승인/거절에 대한 “투명한 인사이트”와 “cohort 전반의 공정성 이슈 식별”을 요구합니다. Vertex AI feature attribution(Vertex Explainable AI)은 각 예측에 대한 설명(local explanations)을 제공하여 각 입력 feature가 특정 결정에 어떻게 기여했는지 보여줍니다. attribution과 결과를 cohort(예: 성별, 소득 구간, 1세대 여부)별로 집계하면, 민감 feature 또는 proxy feature가 승인/거절을 불균형하게 좌우하는지, 그리고 유사한 자격의 지원자가 그룹에 따라 다른 결과를 받는지 확인할 수 있으며, 이는 bias 조사를 위한 핵심 증거입니다. 주요 기능 / 수행 방법: 배포된 모델 또는 500개 샘플 케이스에 대한 batch predictions에 Vertex AI Explainable AI를 적용해 attribution(모델 유형에 따라 Integrated Gradients / sampled Shapley 등)을 얻습니다. 그런 다음 cohort별로 결과를 슬라이싱하여 (1) prediction score 분포, (2) 상위 기여 feature, (3) demographic parity difference, equal opportunity / TPR gaps, group별 calibration 같은 fairness metric을 비교합니다(이러한 metric은 종종 Vertex AI 밖에서 BigQuery/Looker/Python으로 계산하지만, attribution 출력이 분석을 주도합니다). 또한 ZIP-code 기반 소득처럼 민감 feature의 대리(surrogate)로 작동하는 proxy variable도 확인합니다. 흔한 오해: 높은 ROC AUC(0.95)는 공정성을 의미하지 않으며, 차별적 동작과 공존할 수 있습니다. drift/skew 모니터링은 운영 측면에서 중요하지만, 의사결정이 “왜” 내려졌는지 또는 bias가 있는지에 답하지 못합니다. 인구통계 feature를 제거해도 proxy가 남아 bias가 제거되지 않을 수 있고, 공정성 측정/완화 능력을 떨어뜨릴 수 있습니다. 시험 팁: 프롬프트가 투명성, 해석 가능성, cohort 기반 bias 분석을 요구하면 “Vertex Explainable AI/feature attribution + 그룹별 슬라이싱”을 떠올리세요. 프로덕션 데이터 drift 또는 training-serving skew를 묻는다면 “Vertex Model Monitoring”을 떠올리세요. 공정성의 경우, reweighting, constraints, feature 제거 같은 remediation 전에 측정과 증거(설명 + 그룹 metric)를 우선하는 것이 좋습니다.

합격 후기(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

Practice Test #3

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

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Google Professional Cloud Network Engineer

Professional

Google Associate Data Practitioner

Google Associate Data Practitioner

Associate

Google Cloud Digital Leader

Google Cloud Digital Leader

Foundational

Google Professional Cloud Security Engineer

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Architect

Google Professional Cloud Architect

Professional

Google Professional Cloud Database Engineer

Google Professional Cloud Database Engineer

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Google Professional Cloud Developer

Professional

지금 학습 시작하기

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.