Google Professional Machine Learning Engineer

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 학습 실행에서 단순성과 비용 최소화가 우선인 경우에는 적절하지 않습니다.

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

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

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

오답입니다. 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/성능 임계값 초과 시 재학습을 수행하는 자동 파이프라인(배포 전 평가 게이트 포함)입니다.

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과 회귀에 적합한 알고리즘 없이는 시간적 계절성을 자연스럽게 반영하지 못합니다.

기반(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에 대해 엔지니어링 노력과 리스크가 더 크고, 관리형 검색 기능이 존재하는 상황에서는 불필요합니다.

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

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

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

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

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

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

틀렸습니다. 주요 문제는 이 옵션이 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분 요구사항을 더 쉽게 초과하게 됩니다.

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

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을 해결하지 못하고 “비용을 늘리지 않고”라는 요구사항을 위반합니다.

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

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를 지원하려면 다른 곳에서 전처리 로직을 중복해야 합니다.

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

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

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

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

아티팩트는 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에 부적합합니다.

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

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

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

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

오답입니다. 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에 뿌리를 두므로, 성능 모니터링이 아니라 모델 모니터링이 필요합니다.

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보다 낮아 멀티 워커 학습에서 입력 병목 위험이 커집니다.

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

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

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

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

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

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 증거를 제공하지는 못합니다.