Vertex AI 완벽 가이드 - GCP ML 플랫폼

Google Cloud Platform의 머신러닝 통합 플랫폼인 Vertex AI를 처음부터 끝까지 다룹니다. 환경 설정부터 모델 학습, AutoML, 배포, 파이프라인 구축, 모니터링까지 실무에 필요한 모든 과정을 초급자도 이해할 수 있도록 설명합니다.

---

목차

1. Vertex_AI_설정하기
2. Workbench_사용법
3. Training_Jobs_실행
4. AutoML_활용하기
5. Endpoints_배포
6. Pipelines_구축
7. Model_Monitoring_및_Feature_Store

---

1. Vertex AI 설정하기

김개발 씨는 회사에서 머신러닝 프로젝트를 맡게 되었습니다. 선배가 "우리 회사는 GCP 쓰니까 Vertex AI로 해봐"라고 했는데, 어디서부터 시작해야 할지 막막했습니다.

AWS SageMaker는 들어봤는데 Vertex AI는 처음이라 설정부터 헤매기 시작했습니다.

Vertex AI는 Google Cloud Platform에서 제공하는 통합 머신러닝 플랫폼입니다. 마치 요리를 할 때 재료 손질부터 조리, 플레이팅까지 한 주방에서 할 수 있는 것처럼, 데이터 준비부터 모델 학습, 배포까지 모든 ML 워크플로우를 하나의 플랫폼에서 처리할 수 있습니다.

제대로 설정하면 복잡한 인프라 걱정 없이 모델 개발에만 집중할 수 있습니다.

다음 코드를 살펴봅시다.

# Vertex AI SDK 설치 및 초기 설정
# pip install google-cloud-aiplatform

from google.cloud import aiplatform

# 프로젝트와 리전 설정으로 Vertex AI 초기화
aiplatform.init(
    project="my-ml-project",      # GCP 프로젝트 ID
    location="asia-northeast3",    # 서울 리전
    staging_bucket="gs://my-staging-bucket"  # 학습 데이터 저장소
)

# 초기화 확인
print(f"프로젝트: {aiplatform.initializer.global_config.project}")
print(f"리전: {aiplatform.initializer.global_config.location}")

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 그동안 Python으로 간단한 머신러닝 모델은 만들어봤지만, 클라우드 환경에서 제대로 된 ML 시스템을 구축하는 것은 처음이었습니다.

팀장님이 "이번 프로젝트는 Vertex AI로 진행해"라고 했을 때, 김개발 씨는 속으로 당황했습니다. 선배 개발자 박시니어 씨가 김개발 씨의 모니터를 슬쩍 보더니 말했습니다.

"Vertex AI 처음이구나? 걱정 마, 설정만 제대로 하면 나머지는 술술 풀려." 그렇다면 Vertex AI란 정확히 무엇일까요?

쉽게 비유하자면, Vertex AI는 마치 대형 백화점의 푸드코트와 같습니다. 한식, 중식, 일식을 먹으려면 원래 각각 다른 식당을 가야 하지만, 푸드코트에서는 한 곳에서 모든 음식을 주문할 수 있습니다.

마찬가지로 Vertex AI는 데이터 준비, 모델 학습, 하이퍼파라미터 튜닝, 배포, 모니터링을 모두 한 플랫폼에서 처리할 수 있게 해줍니다. Vertex AI가 없던 시절에는 어땠을까요?

개발자들은 Cloud ML Engine, AI Platform, AutoML 등 여러 서비스를 따로따로 사용해야 했습니다. 학습은 이 서비스에서, 배포는 저 서비스에서, 모니터링은 또 다른 서비스에서 해야 했죠.

설정도 제각각이라 혼란스러웠고, 서비스 간 연동도 골치 아팠습니다. 프로젝트가 커질수록 이런 복잡성은 눈덩이처럼 불어났습니다.

바로 이런 문제를 해결하기 위해 2021년 5월, Google은 Vertex AI를 발표했습니다. Vertex AI를 사용하면 모든 ML 도구가 하나의 통합된 API와 UI로 제공됩니다.

또한 기존 TensorFlow, PyTorch, scikit-learn 등 익숙한 프레임워크를 그대로 사용할 수 있습니다. 무엇보다 Google의 검색, 유튜브 등에서 검증된 ML 인프라를 그대로 활용할 수 있다는 큰 장점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 aiplatform.init() 함수가 핵심입니다.

여기서 project 파라미터에는 GCP 프로젝트 ID를 입력합니다. GCP 콘솔 상단에서 확인할 수 있는 그 ID입니다.

location은 리전을 의미하는데, 한국 서비스라면 서울 리전인 asia-northeast3을 사용하면 됩니다. 마지막으로 staging_bucket은 학습 데이터나 중간 결과물을 저장할 Cloud Storage 버킷입니다.

실제 현업에서는 어떻게 시작할까요? 먼저 GCP 콘솔에서 새 프로젝트를 만들고, Vertex AI API를 활성화해야 합니다.

그다음 서비스 계정을 생성하고 적절한 권한을 부여합니다. 보통 Vertex AI User 역할이면 대부분의 작업이 가능합니다.

로컬 개발 환경에서는 gcloud auth application-default login 명령어로 인증하면 됩니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 리전을 잘못 선택하는 것입니다. 데이터가 있는 Cloud Storage 버킷과 Vertex AI 리전이 다르면 데이터 전송 비용이 발생하고 속도도 느려집니다.

따라서 버킷과 Vertex AI를 같은 리전에 두는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 프로젝트 ID랑 리전만 잘 설정하면 되는 거군요!" Vertex AI 설정을 제대로 해두면 이후 모든 작업이 훨씬 수월해집니다.

여러분도 프로젝트를 시작하기 전에 설정부터 꼼꼼히 확인해 보세요.

실전 팁

💡 - 서울 리전(asia-northeast3)은 모든 Vertex AI 기능을 지원하니 국내 서비스라면 이 리전을 사용하세요

• 서비스 계정 키 파일은 절대 Git에 커밋하지 말고, Secret Manager를 활용하세요

---

2. Workbench 사용법

김개발 씨가 Vertex AI 설정을 마쳤습니다. 이제 본격적으로 모델을 개발해야 하는데, 로컬 컴퓨터로는 GPU도 없고 데이터도 크기가 커서 막막했습니다.

선배가 "Workbench 써봐, 클라우드에서 주피터 노트북 쓰는 거야"라고 알려주었습니다.

Vertex AI Workbench는 클라우드에서 실행되는 관리형 주피터 노트북 환경입니다. 마치 PC방에서 고사양 컴퓨터를 빌려 쓰는 것처럼, 필요한 만큼 GPU와 메모리를 선택해서 사용할 수 있습니다.

BigQuery, Cloud Storage 등 GCP 서비스와 바로 연동되어 데이터 분석과 모델 개발을 빠르게 진행할 수 있습니다.

다음 코드를 살펴봅시다.

# Workbench에서 BigQuery 데이터 불러오기
from google.cloud import bigquery
import pandas as pd

# BigQuery 클라이언트 생성 - Workbench에서는 인증이 자동으로 처리됨
client = bigquery.Client()

# 쿼리 실행하여 데이터 로드
query = """
    SELECT user_id, purchase_amount, purchase_date
    FROM `my-project.sales.transactions`
    WHERE purchase_date >= '2024-01-01'
    LIMIT 10000
"""

# 결과를 DataFrame으로 변환
df = client.query(query).to_dataframe()
print(f"로드된 데이터: {len(df)}행")
df.head()

김개발 씨는 고민에 빠졌습니다. 회사에서 분석해야 할 데이터가 무려 500GB나 되는데, 자신의 노트북으로는 엄두가 나지 않았습니다.

메모리는 16GB밖에 안 되고, GPU도 없었습니다. 박시니어 씨가 다가와 말했습니다.

"Workbench 인스턴스 하나 만들어서 써. 거기서 개발하면 훨씬 편해." Vertex AI Workbench란 정확히 무엇일까요?

쉽게 비유하자면, Workbench는 마치 클라우드에 있는 나만의 개발 사무실과 같습니다. 내 책상에는 8GB 노트북밖에 없지만, 사무실에 가면 64GB 메모리에 GPU 4개 달린 워크스테이션을 쓸 수 있는 것과 같습니다.

필요할 때만 켜서 쓰고, 안 쓸 때는 꺼두면 비용도 절약됩니다. 로컬 개발 환경의 한계는 분명합니다.

대용량 데이터를 로컬로 다운로드하면 시간도 오래 걸리고, 디스크 공간도 부족합니다. GPU가 필요한 딥러닝 모델은 학습에 며칠이 걸리기도 합니다.

무엇보다 회사의 데이터가 담긴 BigQuery에 접근하려면 복잡한 인증 설정이 필요합니다. Workbench를 사용하면 이런 문제가 해결됩니다.

Workbench 인스턴스는 GCP 네트워크 안에 있기 때문에 BigQuery, Cloud Storage 등에 별도의 인증 없이 바로 접근할 수 있습니다. 데이터가 클라우드 안에서 이동하니 전송 속도도 빠릅니다.

GPU 인스턴스를 선택하면 NVIDIA Tesla T4나 A100 같은 고성능 GPU를 바로 사용할 수 있습니다. Workbench는 두 가지 유형이 있습니다.

Managed Notebooks는 Google이 관리하는 완전 관리형 환경입니다. 업데이트나 보안 패치를 신경 쓸 필요가 없습니다.

User-Managed Notebooks는 직접 인스턴스를 관리하는 방식입니다. 커스텀 환경이 필요하거나 특정 패키지를 설치해야 할 때 유용합니다.

위의 코드를 살펴보면, Workbench의 편리함을 알 수 있습니다. **bigquery.Client()**를 호출할 때 별도의 인증 정보를 전달하지 않았습니다.

Workbench에서는 인스턴스에 연결된 서비스 계정의 권한이 자동으로 적용되기 때문입니다. 쿼리 결과를 to_dataframe() 메서드로 바로 판다스 DataFrame으로 변환하는 것도 간편합니다.

실제 현업에서는 어떻게 활용할까요? 보통 탐색적 데이터 분석(EDA)과 프로토타이핑을 Workbench에서 진행합니다.

여러 가지 모델을 빠르게 실험하고, 유망한 모델이 정해지면 정식 Training Job으로 넘어갑니다. 인스턴스를 껐다 켜도 데이터가 유지되니 며칠에 걸쳐 작업해도 괜찮습니다.

하지만 주의할 점이 있습니다. Workbench 인스턴스는 켜져 있는 동안 계속 비용이 발생합니다.

퇴근할 때 끄는 것을 잊으면 주말 내내 요금이 청구될 수 있습니다. 일정 자동 종료 기능을 설정해두면 이런 실수를 방지할 수 있습니다.

또한 처음부터 고사양 인스턴스를 선택하지 말고, 필요에 따라 점진적으로 업그레이드하는 것이 비용 효율적입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Workbench를 사용해보니 정말 편했습니다. BigQuery에서 500GB 데이터를 쿼리해도 몇 분 만에 결과가 나왔고, GPU로 모델을 학습시키니 속도가 로컬의 10배는 빠른 것 같았습니다.

실전 팁

💡 - 인스턴스 자동 종료를 설정하여 비용 누수를 방지하세요

• 처음에는 n1-standard-4 정도로 시작하고, 필요하면 머신 유형을 변경하세요

---

3. Training Jobs 실행

김개발 씨가 Workbench에서 프로토타입 모델을 만들었습니다. 로컬에서 작은 데이터로 테스트했을 때는 잘 됐는데, 전체 데이터로 학습시키려니 몇 시간이 걸릴 것 같았습니다.

"노트북 열어두고 기다려야 하나?" 고민하던 중, Training Job이라는 것을 알게 되었습니다.

Training Job은 모델 학습을 클라우드 인프라에서 독립적으로 실행하는 방식입니다. 마치 세탁소에 빨래를 맡기는 것처럼, 학습 코드와 데이터를 전달하면 Vertex AI가 알아서 학습을 수행합니다.

컴퓨터를 끄고 퇴근해도 학습은 계속 진행되며, 완료되면 알림을 받을 수 있습니다.

다음 코드를 살펴봅시다.

from google.cloud import aiplatform

# 커스텀 학습 잡 생성
job = aiplatform.CustomTrainingJob(
    display_name="sales-prediction-training",
    script_path="trainer/train.py",          # 학습 스크립트 경로
    container_uri="gcr.io/cloud-aiplatform/training/tf-gpu.2-12:latest",
    requirements=["pandas>=1.5.0", "scikit-learn>=1.2.0"],
    model_serving_container_image_uri="gcr.io/cloud-aiplatform/prediction/tf2-gpu.2-12:latest"
)

# 학습 실행 - 완료되면 모델 객체 반환
model = job.run(
    replica_count=1,
    machine_type="n1-standard-8",
    accelerator_type="NVIDIA_TESLA_T4",
    accelerator_count=1,
    args=["--epochs", "100", "--batch-size", "32"]
)

김개발 씨는 난감한 상황에 처했습니다. 모델 학습에 8시간이 걸릴 것 같은데, Workbench 노트북을 8시간 동안 열어두고 기다려야 할까요?

브라우저를 실수로 닫으면 어떻게 될까요? 박시니어 씨가 웃으며 말했습니다.

"그럴 필요 없어. Training Job으로 돌리면 퇴근해도 돼.

내일 아침에 결과 확인하면 되지." Training Job이란 정확히 무엇일까요? 쉽게 비유하자면, Training Job은 마치 세탁소에 빨래를 맡기는 것과 같습니다.

집에서 세탁기를 돌리면 끝날 때까지 기다려야 하지만, 세탁소에 맡기면 다른 일을 하다가 나중에 찾으러 가면 됩니다. Training Job도 마찬가지로, 학습 코드를 제출하면 Vertex AI가 알아서 인프라를 프로비저닝하고, 학습을 수행하고, 완료되면 결과를 저장합니다.

Workbench에서 직접 학습을 돌리면 어떤 문제가 있을까요? 우선 세션이 끊기면 학습도 중단됩니다.

네트워크 문제나 브라우저 종료로 연결이 끊어지면 몇 시간의 학습이 물거품이 될 수 있습니다. 또한 Workbench 인스턴스는 학습 중에도 계속 비용이 발생합니다.

학습이 끝나면 인스턴스를 종료해야 하는데, 밤새 학습시키고 다음 날 끄는 것을 잊으면 불필요한 비용이 발생합니다. Training Job을 사용하면 이런 걱정이 사라집니다.

학습 작업이 독립적인 컨테이너에서 실행되므로, 로컬 환경과 완전히 분리됩니다. 학습이 완료되면 자동으로 리소스가 해제되어 비용 낭비가 없습니다.

여러 개의 Training Job을 동시에 실행하여 하이퍼파라미터 튜닝을 병렬로 수행할 수도 있습니다. 위의 코드를 자세히 살펴보겠습니다.

CustomTrainingJob 클래스를 사용하여 학습 작업을 정의합니다. script_path는 학습 스크립트의 경로입니다.

이 스크립트는 Cloud Storage에 업로드되어 컨테이너 안에서 실행됩니다. container_uri는 학습에 사용할 Docker 이미지입니다.

Google에서 제공하는 사전 빌드된 이미지를 사용하면 TensorFlow, PyTorch 등이 이미 설치되어 있습니다. job.run() 메서드를 호출하면 실제 학습이 시작됩니다.

machine_type으로 머신 사양을 지정하고, accelerator_type과 accelerator_count로 GPU를 설정합니다. args를 통해 학습 스크립트에 인자를 전달할 수 있습니다.

실제 현업에서는 학습 스크립트를 어떻게 작성할까요? 학습 스크립트는 보통 argparse로 인자를 받고, 데이터를 로드하고, 모델을 학습시킨 뒤, 결과를 Cloud Storage에 저장하는 구조입니다.

중요한 점은 환경 변수 AIP_MODEL_DIR에 모델을 저장해야 한다는 것입니다. 이 경로에 저장된 모델은 자동으로 Vertex AI Model Registry에 등록됩니다.

주의할 점도 있습니다. 처음 Training Job을 실행하면 컨테이너 빌드와 리소스 프로비저닝에 시간이 걸립니다.

5분에서 10분 정도 기다려야 실제 학습이 시작될 수 있습니다. 또한 학습 스크립트에 버그가 있으면 비용만 나가고 실패할 수 있으니, 작은 데이터로 먼저 테스트하는 것이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. Training Job을 제출하고 퇴근한 김개발 씨는 다음 날 아침 Vertex AI 콘솔을 확인했습니다.

"Training completed"라는 메시지와 함께 모델이 저장되어 있었습니다. 밤새 컴퓨터 앞에 있지 않아도 된다니, 정말 편리했습니다.

실전 팁

💡 - 처음에는 작은 데이터와 적은 epoch로 테스트 학습을 먼저 실행하여 스크립트 오류를 확인하세요

• preemptible VM을 사용하면 비용을 최대 80%까지 절약할 수 있습니다

---

4. AutoML 활용하기

김개발 씨의 동료 이신입 씨는 머신러닝을 전혀 모르는 기획자입니다. 그런데 팀장님이 "다음 달까지 고객 이탈 예측 모델 만들어봐"라고 했습니다.

이신입 씨는 당황했지만, AutoML이라는 것을 알게 되고 희망을 품었습니다.

AutoML은 머신러닝 전문 지식 없이도 고품질 모델을 만들 수 있는 자동화된 머신러닝 서비스입니다. 마치 전문 셰프가 없어도 밀키트로 훌륭한 요리를 만들 수 있는 것처럼, 데이터만 준비하면 Vertex AI가 알아서 최적의 모델 구조와 하이퍼파라미터를 찾아줍니다.

다음 코드를 살펴봅시다.

from google.cloud import aiplatform

# 학습 데이터가 있는 BigQuery 테이블 또는 CSV 지정
dataset = aiplatform.TabularDataset.create(
    display_name="customer-churn-dataset",
    bq_source="bq://my-project.analytics.customer_data"
)

# AutoML 학습 잡 생성 및 실행
job = aiplatform.AutoMLTabularTrainingJob(
    display_name="churn-prediction-automl",
    optimization_prediction_type="classification",  # 분류 문제
    optimization_objective="maximize-au-roc"        # AUC-ROC 최적화
)

# 모델 학습 시작 - target_column이 예측 대상
model = job.run(
    dataset=dataset,
    target_column="churned",           # 예측할 컬럼
    budget_milli_node_hours=1000,      # 학습 시간 예산 (1시간)
    model_display_name="churn-predictor-v1"
)

이신입 씨는 기획팀에서 일하는 3년 차 직원입니다. 데이터 분석은 Excel로 피벗 테이블 만드는 정도가 전부였습니다.

그런데 갑자기 머신러닝 모델을 만들라니, 막막하기만 했습니다. 점심시간에 김개발 씨에게 하소연했더니, 김개발 씨가 말했습니다.

"AutoML 써봐요. 데이터만 있으면 알아서 모델 만들어줘요." AutoML이란 정확히 무엇일까요?

쉽게 비유하자면, AutoML은 마치 밀키트와 같습니다. 전문 셰프가 아니어도 밀키트를 따라 만들면 맛있는 요리가 완성되듯이, 머신러닝 전문가가 아니어도 AutoML을 사용하면 훌륭한 모델을 만들 수 있습니다.

재료를 손질하고, 양념을 계량하고, 조리 순서를 정하는 모든 과정을 AutoML이 대신 해줍니다. 직접 모델을 만든다면 어떤 과정을 거쳐야 할까요?

먼저 어떤 알고리즘을 사용할지 결정해야 합니다. 로지스틱 회귀, 랜덤 포레스트, XGBoost, 신경망 중 무엇이 좋을까요?

알고리즘을 정했다면 하이퍼파라미터를 튜닝해야 합니다. 학습률은 얼마로 할지, 레이어는 몇 개로 할지, 정규화는 어떻게 할지 결정해야 합니다.

이 모든 과정에 전문 지식과 많은 시행착오가 필요합니다. AutoML을 사용하면 이 복잡한 과정이 자동화됩니다.

데이터를 업로드하고 예측하고 싶은 컬럼만 지정하면, Vertex AI가 수십 가지 모델 구조와 수천 가지 하이퍼파라미터 조합을 자동으로 탐색합니다. 내부적으로 Neural Architecture Search라는 기술을 사용하여 최적의 모델을 찾아냅니다.

구글의 연구 역량이 집약된 기술입니다. 위의 코드를 살펴보겠습니다.

먼저 **TabularDataset.create()**로 데이터셋을 등록합니다. BigQuery 테이블이나 Cloud Storage의 CSV 파일을 지정할 수 있습니다.

다음으로 AutoMLTabularTrainingJob을 생성하는데, 여기서 optimization_prediction_type으로 분류인지 회귀인지 지정합니다. optimization_objective는 어떤 지표를 최적화할지 결정합니다.

budget_milli_node_hours는 학습에 사용할 컴퓨팅 시간 예산입니다. 1000은 1노드 시간을 의미합니다.

예산을 늘리면 더 많은 모델을 탐색하여 성능이 좋아질 수 있지만, 비용도 증가합니다. 실제로 AutoML의 성능은 어느 정도일까요?

놀랍게도, 많은 케이스에서 AutoML은 전문가가 직접 튜닝한 모델과 비슷하거나 더 좋은 성능을 보입니다. 특히 정형 데이터(테이블 데이터)에서 강력한 성능을 발휘합니다.

물론 아주 특수한 도메인이나 복잡한 요구사항이 있다면 커스텀 모델이 필요할 수 있지만, 대부분의 비즈니스 문제에는 AutoML로 충분합니다. 하지만 알아두어야 할 점이 있습니다.

AutoML은 편리하지만 비용이 커스텀 학습보다 높을 수 있습니다. 또한 모델의 내부 구조를 직접 제어할 수 없기 때문에, 모델이 왜 그런 예측을 하는지 설명하기 어려울 수 있습니다.

규제가 엄격한 금융이나 의료 분야에서는 이 점을 고려해야 합니다. 다시 이신입 씨의 이야기로 돌아가 봅시다.

고객 데이터를 BigQuery에서 가져와 AutoML에 넣었더니, 하루 만에 AUC 0.87의 모델이 완성되었습니다. 팀장님께 보고했더니 "오, 벌써 다 만들었어?"라며 놀라워했습니다.

실전 팁

💡 - 데이터 품질이 모델 성능의 80%를 결정합니다. AutoML에 넣기 전에 데이터 전처리에 시간을 투자하세요

• 처음에는 적은 예산으로 시작하고, 결과를 보고 예산을 늘려가는 것이 효율적입니다

---

5. Endpoints 배포

김개발 씨가 드디어 만족스러운 모델을 완성했습니다. 그런데 이제 뭘 해야 할까요?

다른 서비스에서 이 모델을 사용하려면 API로 만들어야 할 것 같은데, Flask로 서버를 만들고 Docker로 패키징하고... 생각만 해도 머리가 아팠습니다.

Endpoint는 학습된 모델을 API로 서빙하는 관리형 인프라입니다. 마치 식당에서 음식을 만들면 서빙 직원이 손님에게 가져다주는 것처럼, 모델만 배포하면 Vertex AI가 API 서버, 로드 밸런싱, 오토스케일링을 모두 처리해줍니다.

코드 한 줄 없이 프로덕션 수준의 예측 서비스를 만들 수 있습니다.

다음 코드를 살펴봅시다.

from google.cloud import aiplatform

# 등록된 모델 가져오기
model = aiplatform.Model("projects/my-project/locations/asia-northeast3/models/123456789")

# 엔드포인트 생성 및 모델 배포
endpoint = model.deploy(
    deployed_model_display_name="churn-predictor-prod",
    machine_type="n1-standard-4",
    min_replica_count=1,           # 최소 인스턴스 수
    max_replica_count=5,           # 최대 인스턴스 수 (오토스케일링)
    traffic_percentage=100,        # 이 모델로 100% 트래픽 전송
    accelerator_type=None          # CPU만 사용
)

# 예측 요청 보내기
predictions = endpoint.predict(
    instances=[{"feature1": 0.5, "feature2": "A", "feature3": 100}]
)
print(predictions.predictions)

김개발 씨는 모델을 완성하고 기뻐했지만, 곧 현실의 벽에 부딪혔습니다. 마케팅팀에서 "그 모델로 실시간 예측 API 만들어줄 수 있어요?"라고 요청했기 때문입니다.

Flask로 서버를 만들고, Docker로 패키징하고, Kubernetes에 배포하고... 머릿속이 복잡해졌습니다.

박시니어 씨가 말했습니다. "Endpoint로 배포하면 그런 거 다 필요 없어.

몇 줄이면 끝나." Endpoint란 정확히 무엇일까요? 쉽게 비유하자면, Endpoint는 마치 배달 대행 서비스와 같습니다.

식당은 음식만 잘 만들면 되고, 배달은 배민이나 쿠팡이츠가 알아서 처리해주는 것처럼, 여러분은 모델만 잘 만들면 되고, API 서버, 확장성, 안정성은 Vertex AI Endpoint가 처리해줍니다. 직접 모델 서빙 인프라를 구축한다면 어떤 일을 해야 할까요?

우선 Flask나 FastAPI로 웹 서버를 만들어야 합니다. 모델을 로드하고 예측을 수행하는 코드를 작성해야 합니다.

이것을 Docker 이미지로 패키징해야 합니다. 그 다음 Kubernetes에 배포하고, 로드 밸런서를 설정하고, 오토스케일링 정책을 정의해야 합니다.

이 모든 과정에 수주에서 수개월이 걸릴 수 있습니다. Endpoint를 사용하면 이 복잡한 과정이 코드 몇 줄로 줄어듭니다.

model.deploy() 한 번 호출하면 Vertex AI가 자동으로 예측 서버를 프로비저닝합니다. min_replica_count와 max_replica_count로 오토스케일링 범위를 지정하면, 트래픽에 따라 자동으로 인스턴스가 늘어나거나 줄어듭니다.

새벽에는 1대만 돌고, 피크 시간에는 5대로 확장되는 식입니다. 배포된 Endpoint의 강력한 기능 중 하나는 트래픽 분할입니다.

새 모델을 배포할 때 기존 모델과 함께 10%의 트래픽만 새 모델로 보내볼 수 있습니다. 문제가 없으면 점차 비율을 높여 100%로 전환합니다.

이것이 바로 카나리 배포입니다. A/B 테스트도 같은 방식으로 수행할 수 있습니다.

위의 코드를 자세히 살펴보겠습니다. 먼저 **aiplatform.Model()**로 등록된 모델을 가져옵니다.

Training Job이나 AutoML로 학습하면 모델이 자동으로 등록되고, 이 리소스 경로를 얻을 수 있습니다. deploy() 메서드를 호출하면 배포가 시작됩니다.

배포에는 10분에서 15분 정도 걸릴 수 있습니다. **endpoint.predict()**로 예측 요청을 보냅니다.

instances는 리스트 형태로, 한 번에 여러 건의 예측을 요청할 수 있습니다. 배치 예측이 필요하다면 batch_predict() 메서드도 있습니다.

실제 현업에서는 Endpoint를 어떻게 호출할까요? Python SDK 외에도 REST API로 직접 호출할 수 있습니다.

인증에는 서비스 계정 토큰을 사용합니다. 다른 서비스에서 HTTP 요청으로 예측을 받아갈 수 있어, 어떤 언어나 플랫폼에서도 사용 가능합니다.

주의할 점이 있습니다. Endpoint는 배포되어 있는 동안 지속적으로 비용이 발생합니다.

최소 1대의 인스턴스가 항상 켜져 있어야 하기 때문입니다. 개발 단계에서는 필요할 때만 배포하고, 테스트가 끝나면 **undeploy()**로 해제하는 것이 좋습니다.

프로덕션에서는 트래픽 패턴에 맞게 min/max replica를 조정하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Endpoint 배포를 마치고 마케팅팀에 API 문서를 전달했습니다. "엥, 벌써요?

저번에 다른 팀은 한 달 걸렸는데..." 마케팅팀의 놀란 반응에 김개발 씨는 뿌듯했습니다.

실전 팁

💡 - 개발 중에는 Endpoint를 undeploy하여 비용을 절약하세요

• 프로덕션 배포 전에 부하 테스트를 수행하여 적절한 머신 타입과 replica 수를 결정하세요

---

6. Pipelines 구축

김개발 씨가 모델을 운영한 지 한 달이 지났습니다. 매주 새로운 데이터로 모델을 재학습하고 배포해야 하는데, 매번 수동으로 하려니 귀찮고 실수도 잦았습니다.

"이걸 자동화할 수 없을까?" 고민하던 중, Pipelines라는 것을 알게 되었습니다.

Vertex AI Pipelines는 ML 워크플로우를 자동화하고 오케스트레이션하는 서비스입니다. 마치 공장의 조립 라인처럼, 데이터 전처리부터 학습, 평가, 배포까지의 단계를 정의해두면 자동으로 순서대로 실행됩니다.

한 번 파이프라인을 구축해두면 버튼 하나로, 또는 스케줄에 따라 전체 과정이 자동으로 돌아갑니다.

다음 코드를 살펴봅시다.

from kfp.v2 import dsl
from kfp.v2.dsl import component
from google.cloud import aiplatform

# 데이터 전처리 컴포넌트 정의
@component(base_image="python:3.9")
def preprocess_data(input_path: str, output_path: str):
    import pandas as pd
    df = pd.read_csv(input_path)
    df = df.dropna()  # 결측치 제거
    df.to_csv(output_path, index=False)

# 파이프라인 정의
@dsl.pipeline(name="ml-training-pipeline")
def training_pipeline(data_path: str):
    # 단계 1: 데이터 전처리
    preprocess_task = preprocess_data(
        input_path=data_path,
        output_path="gs://my-bucket/processed.csv"
    )
    # 단계 2, 3... 학습, 평가, 배포 컴포넌트 연결

# 파이프라인 실행
aiplatform.PipelineJob(
    display_name="weekly-training",
    template_path="pipeline.json",
    parameter_values={"data_path": "gs://my-bucket/data.csv"}
).run()

김개발 씨는 점점 지쳐가고 있었습니다. 매주 월요일마다 같은 작업의 반복이었습니다.

BigQuery에서 데이터 내려받고, 전처리하고, 모델 학습시키고, 평가하고, 성능이 좋으면 배포하고... 이 모든 과정에 반나절이 걸렸습니다.

어느 날 실수로 전처리 코드를 잘못 실행해서 모델 성능이 뚝 떨어졌습니다. 원인을 찾느라 하루를 날렸습니다.

박시니어 씨가 말했습니다. "이제 Pipeline으로 자동화할 때가 됐어." Vertex AI Pipelines란 정확히 무엇일까요?

쉽게 비유하자면, Pipelines는 마치 공장의 조립 라인과 같습니다. 자동차 공장에서는 차체 조립, 도색, 엔진 장착, 품질 검사가 순서대로 자동으로 진행됩니다.

한 공정이 끝나면 다음 공정으로 자동으로 넘어가고, 문제가 생기면 라인이 멈추고 알람이 울립니다. ML Pipeline도 마찬가지입니다.

수동으로 ML 워크플로우를 관리하면 어떤 문제가 생길까요? 첫째, 재현성 문제가 있습니다.

"지난달에 어떤 파라미터로 학습했더라?" 기억이 나지 않습니다. 둘째, 일관성 문제가 있습니다.

사람이 하다 보면 실수가 생깁니다. 셋째, 확장성 문제가 있습니다.

모델이 10개, 100개로 늘어나면 수동 관리가 불가능합니다. Pipelines를 사용하면 이런 문제가 해결됩니다.

모든 단계가 코드로 정의되어 있어 재현성이 보장됩니다. 언제든 같은 파이프라인을 실행하면 같은 결과를 얻습니다.

자동으로 실행되니 일관성도 유지됩니다. 스케줄러를 설정하면 매주 월요일 자정에 자동으로 파이프라인이 돌아갑니다.

위의 코드를 살펴보겠습니다. Vertex AI Pipelines는 Kubeflow Pipelines(KFP) 기반입니다.

@component 데코레이터로 각 단계를 정의합니다. 이 컴포넌트는 독립적인 컨테이너에서 실행되므로 의존성 충돌 걱정이 없습니다.

@dsl.pipeline 데코레이터로 전체 파이프라인을 정의하고, 컴포넌트들을 연결합니다. PipelineJob으로 파이프라인을 실행합니다.

template_path에는 컴파일된 파이프라인 정의 파일을 지정합니다. KFP 컴파일러로 파이프라인을 JSON 파일로 컴파일한 뒤 사용합니다.

실제 파이프라인은 어떤 구조로 만들까요? 일반적인 ML 파이프라인은 다음과 같은 단계로 구성됩니다.

데이터 수집 -> 데이터 검증 -> 전처리 -> 학습 -> 평가 -> 조건부 배포. 평가 단계에서 성능이 기준치 이상이면 배포하고, 아니면 알람을 보내는 식입니다.

각 단계 사이에 조건 분기나 병렬 실행도 가능합니다. 파이프라인의 또 다른 장점은 추적성입니다.

Vertex AI 콘솔에서 파이프라인 실행 이력을 모두 볼 수 있습니다. 각 실행에서 어떤 데이터를 사용했는지, 어떤 파라미터로 학습했는지, 결과 모델의 성능은 어땠는지 모두 기록됩니다.

문제가 생겼을 때 원인을 추적하기 쉽습니다. 주의할 점도 있습니다.

파이프라인을 처음 구축할 때는 시간이 꽤 걸립니다. 각 컴포넌트를 정의하고, 컨테이너 이미지를 빌드하고, 연결하는 작업이 필요합니다.

하지만 한 번 만들어두면 그 이후로는 편해집니다. 또한 디버깅이 까다로울 수 있으니, 각 컴포넌트를 먼저 독립적으로 테스트한 뒤 파이프라인으로 연결하는 것이 좋습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 파이프라인을 구축하고 나서 월요일 아침이 달라졌습니다.

출근하면 이미 새 모델이 학습되어 있고, 평가 결과가 Slack으로 와 있었습니다. "이제 진짜 개발에만 집중할 수 있겠다!" 김개발 씨는 뿌듯했습니다.

실전 팁

💡 - 작은 파이프라인부터 시작하세요. 처음부터 완벽한 파이프라인을 만들려고 하지 말고, 점진적으로 개선하세요

• 각 컴포넌트는 독립적으로 테스트 가능하게 설계하면 디버깅이 쉬워집니다

---

7. Model Monitoring 및 Feature Store

김개발 씨의 모델이 운영된 지 3개월이 지났습니다. 처음에는 정확도가 90%였는데, 요즘 들어 예측이 자주 틀린다는 피드백이 들어왔습니다.

확인해보니 정확도가 75%까지 떨어져 있었습니다. 무슨 일이 벌어진 걸까요?

Model Monitoring은 배포된 모델의 성능을 실시간으로 감시하고, 문제가 생기면 알려주는 서비스입니다. Feature Store는 피처를 중앙에서 관리하고 일관되게 제공하는 저장소입니다.

마치 자동차의 계기판이 엔진 상태를 실시간으로 보여주고, 정비 기록을 관리하는 것처럼, 모델의 건강 상태를 지속적으로 확인하고 데이터 품질을 유지할 수 있습니다.

다음 코드를 살펴봅시다.

from google.cloud import aiplatform

# 모델 모니터링 설정
model_monitoring_job = aiplatform.ModelDeploymentMonitoringJob.create(
    display_name="churn-model-monitoring",
    endpoint=endpoint,
    logging_sampling_strategy={"random_sample_config": {"sample_rate": 0.1}},
    # 데이터 드리프트 감지 설정
    model_monitoring_objective_configs=[{
        "training_dataset": "bq://my-project.ml.training_data",
        "training_prediction_skew_detection_config": {
            "skew_thresholds": {"churned": {"value": 0.1}}
        },
        "prediction_drift_detection_config": {
            "drift_thresholds": {"churned": {"value": 0.1}}
        }
    }],
    # 알림 설정
    model_monitoring_alert_config={
        "email_alert_config": {"user_emails": ["dev@company.com"]}
    }
)

# Feature Store 생성 및 피처 등록
featurestore = aiplatform.Featurestore.create(
    featurestore_id="customer_features",
    online_store_fixed_node_count=1
)

김개발 씨는 당황했습니다. 분명히 배포할 때는 잘 동작했는데, 왜 갑자기 성능이 떨어진 걸까요?

데이터를 살펴보니 이상한 점이 발견되었습니다. 학습할 때는 고객 평균 나이가 35세였는데, 최근 예측 요청 데이터는 평균 나이가 50세였습니다.

새로운 마케팅 캠페인 때문에 고객층이 바뀐 것이었습니다. 박시니어 씨가 말했습니다.

"이런 걸 데이터 드리프트라고 해. Model Monitoring을 설정해뒀으면 진작 알았을 텐데." Model Monitoring과 Feature Store는 왜 필요할까요?

쉽게 비유하자면, 모델을 배포하는 것은 마치 자동차를 출고하는 것과 같습니다. 출고할 때는 완벽하게 작동하지만, 시간이 지나면 엔진 오일도 갈아야 하고 타이어도 점검해야 합니다.

자동차에 계기판이 있어서 엔진 온도, 연료량, 오일 상태를 실시간으로 알려주는 것처럼, Model Monitoring은 모델의 건강 상태를 실시간으로 알려줍니다. 모델 성능이 저하되는 원인은 크게 두 가지입니다.

첫째, 데이터 드리프트입니다. 입력 데이터의 분포가 학습 때와 달라지는 것입니다.

위의 예시처럼 고객층이 바뀌거나, 계절에 따라 구매 패턴이 달라지는 경우입니다. 둘째, 컨셉 드리프트입니다.

입력과 출력의 관계 자체가 바뀌는 것입니다. 예를 들어 경제 상황이 변해서 같은 조건의 고객도 이전과 다르게 행동하는 경우입니다.

Model Monitoring은 이런 드리프트를 자동으로 감지합니다. 예측 요청 데이터를 샘플링하여 학습 데이터와 비교합니다.

분포가 크게 달라지면 알림을 보냅니다. 이메일, Slack, PagerDuty 등 다양한 알림 채널을 설정할 수 있습니다.

문제를 빨리 발견하면 빨리 대응할 수 있습니다. 모델을 재학습하거나, 일시적으로 규칙 기반 시스템으로 전환하는 등의 조치를 취할 수 있습니다.

Feature Store는 또 다른 문제를 해결합니다. 학습할 때와 서빙할 때 피처를 다르게 계산하면 성능이 달라집니다.

이것을 학습-서빙 스큐라고 합니다. 예를 들어 학습할 때는 "최근 30일 구매 금액"을 어떤 방식으로 계산했는데, 서빙할 때는 다른 방식으로 계산하면 모델 성능이 떨어집니다.

Feature Store에 피처 계산 로직을 등록해두면, 학습과 서빙에서 동일한 피처를 사용할 수 있습니다. 위의 코드를 살펴보겠습니다.

**ModelDeploymentMonitoringJob.create()**로 모니터링 작업을 생성합니다. logging_sampling_strategy로 요청의 몇 퍼센트를 로깅할지 설정합니다.

너무 높으면 비용이 많이 들고, 너무 낮으면 드리프트 감지가 느려집니다. skew_thresholds와 drift_thresholds로 알림을 보낼 임계값을 설정합니다.

Feature Store는 **aiplatform.Featurestore.create()**로 생성합니다. 그 안에 EntityType(예: 고객, 상품)을 만들고, 각 EntityType에 Feature(예: 연령, 구매횟수)를 등록합니다.

온라인 서빙을 위한 노드를 설정하면 밀리초 단위의 빠른 피처 조회가 가능합니다. 실제 현업에서는 어떻게 활용할까요?

대부분의 MLOps 성숙 기업은 모니터링을 필수로 설정합니다. 주요 지표(정확도, 레이턴시, 처리량)를 대시보드로 시각화하고, 이상 징후가 감지되면 자동으로 파이프라인을 트리거하여 모델을 재학습합니다.

Feature Store는 여러 모델에서 공통으로 사용하는 피처를 중앙에서 관리하여 중복 작업을 줄입니다. 주의할 점도 있습니다.

모니터링 임계값을 너무 민감하게 설정하면 거짓 알람이 많아져 피로해집니다. 반대로 너무 둔감하게 설정하면 문제를 놓칠 수 있습니다.

처음에는 느슨하게 시작하고, 운영 경험을 쌓으면서 조정하는 것이 좋습니다. Feature Store는 초기 설정에 시간이 걸리지만, 모델이 여러 개로 늘어나면 투자 대비 효과가 큽니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. Model Monitoring을 설정한 후, 다음 번에는 드리프트 발생 후 2시간 만에 알림을 받았습니다.

빠르게 데이터를 분석하고 모델을 재학습하여 성능 저하를 최소화할 수 있었습니다. "모니터링 없이 모델을 운영하면 안 되겠구나..." 김개발 씨는 깨달았습니다.

실전 팁

💡 - 모니터링 알림은 처음에 느슨하게 시작하고 점차 조정하세요. 너무 민감하면 알람 피로가 옵니다

• Feature Store는 모델이 3개 이상일 때 도입 효과가 큽니다. 처음에는 단순하게 시작하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!