Terraform과 Kubeflow로 완성하는 MLOps 완전 자동화 파이프라인 구축 가이드

머신러닝 모델의 가치는 '개발'에만 국한되지 않습니다. 실제 비즈니스 가치는 모델이 얼마나 빠르고 안정적으로 프로덕션 환경에 배포되어 지속적으로 운영되는가에 달려있습니다. 이 과정, 즉 MLOps(Machine Learning Operations)의 복잡성은 전통적인 소프트웨어 배포보다 훨씬 많은 변수(데이터 버전, 모델 아티팩트, 환경 의존성 등)를 포함합니다.

이러한 복잡성을 수동으로 관리하는 것은 곧 '기술 부채'를 쌓는 것과 같습니다. 본 가이드는 AI 워크플로우 전체를 Infrastructure as Code (IaC) 원칙으로 관리하여, 모델의 재현성(Reproducibility)과 확장성(Scalability)을 극대화하는 실질적인 아키텍처 청사진을 제시합니다.

AI 워크플로우 자동화의 필요성: 왜 IaC가 필수인가?

기존의 MLOps 파이프라인은 종종 다음과 같은 병목 현상을 겪습니다.

1. 환경 불일치: 개발 환경과 스테이징, 프로덕션 환경의 클라우드 리소스 설정이 미묘하게 다릅니다.
2. 수동 개입: 데이터 전처리 스크립트 실행, 모델 학습 트리거, 컨테이너 이미지 빌드 등의 과정에 사람이 개입할 여지가 많아 오류가 발생하기 쉽습니다.
3. 버전 관리의 어려움: 인프라 설정 파일, 데이터셋 버전, 모델 코드가 분리되어 관리되면서 전체 시스템의 상태 추적이 어렵습니다.

IaC는 이 모든 것을 해결합니다. Terraform과 같은 도구를 사용하여 클라우드 인프라 자체를 코드로 정의하고, Kubeflow와 같은 오케스트레이션 툴을 사용하여 워크플로우를 코드로 정의함으로써, 시스템 전체를 '버전 관리 가능한 아티팩트'로 취급할 수 있게 됩니다.

1단계: 기반 인프라 구축 (The Foundation) - Terraform 활용

MLOps 파이프라인이 구동될 클라우드 환경(EKS 클러스터, 스토리지 버킷 등)을 먼저 코드로 정의해야 합니다. Terraform은 이 역할을 수행하는 가장 강력한 도구입니다.

우리는 AWS 환경을 가정하고, 모델 아티팩트와 데이터셋을 저장할 S3 버킷과, 파이프라인을 실행할 쿠버네티스 클러스터(EKS)를 정의합니다.

# AWS S3 버킷 정의 (데이터 및 모델 아티팩트 저장소)
resource "aws_s3_bucket" "ml_artifacts" {
  bucket = "my-mlops-artifact-bucket-unique"
  acl    = "private"
}

# EKS 클러스터 정의 (파이프라인 실행 환경)
resource "aws_eks_cluster" "mlops_cluster" {
  name     = "mlops-pipeline-cluster"
  role_arn = aws_iam_role.eks_master.arn
  version  = "1.28"
  # ... 기타 설정 생략 ...
}

# EKS 노드 그룹 정의 (실제 워크로드가 구동될 컴퓨팅 자원)
resource "aws_eks_node_group" "workers" {
  cluster_name    = aws_eks_cluster.mlops_cluster.name
  node_group_name = "ml-workers"
  subnet_ids      = var.private_subnet_ids
  instance_type   = "t3.medium"
  scaling_config {
    desired_size = 3
    max_size     = 10
    min_size     = 2
  }
}

이 코드를 terraform apply 하는 순간, 우리가 원하는 상태의 클라우드 인프라가 완벽하게 구축됩니다. 이 과정 자체가 **'인프라의 버전 관리'**를 의미합니다.

2단계: 핵심 워크플로우 정의 (The Pipeline) - Kubeflow 활용

인프라가 준비되었다면, 이제 모델 개발의 핵심 로직을 정의해야 합니다. Kubeflow Pipelines는 데이터 수집 $\rightarrow$ 전처리 $\rightarrow$ 모델 학습 $\rightarrow$ 모델 검증 $\rightarrow$ 배포의 전 과정을 DAG(Directed Acyclic Graph) 형태로 코드로 정의할 수 있게 합니다.

다음은 가상의 데이터 전처리 및 모델 학습 단계를 정의하는 Kubeflow Pipeline YAML 예시입니다.

# Kubeflow Pipeline YAML (개념적 예시)
apiVersion: kubeflow.org/v1
kind: PipelineRun
metadata:
  name: model-training-pipeline
spec:
  template:
    # 1. 데이터 전처리 단계 (Data Preprocessing)
    components:
    - name: data_prep
      containerImage: myregistry/data-processor:v1.2
      arguments:
      - --input-data-path: s3://my-mlops-artifact-bucket/raw/data.csv
      - --output-path: s3://my-mlops-artifact-bucket/processed/data.parquet
    
    # 2. 모델 학습 단계 (Model Training)
    - name: model_trainer
      dependencies: [data_prep] # data_prep이 완료된 후에 실행
      containerImage: myregistry/trainer:latest
      arguments:
      - --train-data-path: s3://my-mlops-artifact-bucket/processed/data.parquet
      - --hyperparameters: '{"lr": 0.001}'
      - --output-model-path: s3://my-mlops-artifact-bucket/models/run_$(date).pkl
      
    # 3. 모델 검증 및 배포 준비 단계 (Validation & Deployment Artifact)
    - name: model_validator
      dependencies: [model_trainer]
      script: |
        # 모델 로드 및 성능 지표 계산 로직 실행
        if [ $accuracy > 0.9 ]; then
          echo "Validation Success. Triggering deployment."
          # 이 단계에서 ArgoCD 또는 Flux를 통해 GitOps 배포를 트리거할 수 있음
        else
          echo "Validation Failed. Stopping pipeline."
          exit 1
        fi

이 YAML은 단순한 스크립트 나열이 아닙니다. 이는 **'실행 순서'와 '의존성'**을 명시한 계약서와 같습니다.

3단계: 통합 및 검증 - GitOps 기반 CI/CD 원리

진정한 자동화는 이 두 가지 요소(인프라 코드 + 워크플로우 코드)가 Git이라는 단일 진실 공급원(Single Source of Truth)을 통해 연결될 때 완성됩니다. 이것이 바로 GitOps의 핵심 원리입니다.

[시스템 흐름 설명: Terraform $\rightarrow$ EKS $\rightarrow$ Kubeflow]

1. Git Commit: 엔지니어가 모델 코드 변경 또는 인프라 변경을 Git에 커밋합니다.
2. CI (Continuous Integration): CI 툴(GitHub Actions 등)이 트리거되어 코드를 테스트하고, 필요한 컨테이너 이미지를 빌드하여 레지스트리에 푸시합니다.
3. CD (Continuous Deployment):
   • 인프라 배포: Terraform 코드가 변경되었다면, CD 툴이 terraform plan 및 apply를 실행하여 EKS 클러스터의 상태를 업데이트합니다.
   • 워크플로우 배포: Kubeflow 파이프라인 YAML이 변경되었다면, CD 툴이 이를 클러스터에 적용하여 새로운 파이프라인 정의를 배포합니다.
4. 실행: 사용자가 Git에서 '배포' 브랜치에 머지하거나, 특정 태그를 지정하면, Kubeflow가 정의된 DAG에 따라 자율적으로 리소스를 할당받아 학습을 시작합니다.

수동 배포 vs. IaC 기반 배포 비교 분석

이처럼 IaC(Infrastructure as Code)와 Workflow as Code를 결합하는 것이 현대 MLOps의 핵심입니다.

이러한 체계적인 접근 방식을 통해 개발팀은 모델 개발 자체에 집중할 수 있으며, 운영팀은 예측 가능하고 안정적인 파이프라인을 운영할 수 있게 됩니다.