Day 3 - CI/CD for ML: SageMaker Projects, CodePipeline/CodeBuild 연계, 자동 배포

CI/CD를 ML에 적용한다는 것

코드를 한 줄 고칠 때마다 사람이 노트북에서 파이프라인을 다시 돌리고, 승인 버튼을 누르고, 엔드포인트를 손으로 갱신한다면 여전히 수동 운영이다. 전통적 소프트웨어 CI/CD는 코드 푸시 → 빌드 → 테스트 → 배포인데, ML에서는 여기에 데이터와 모델이라는 축이 더해진다.

• CI (지속적 통합): 전처리·학습 스크립트 변경 시 자동으로 파이프라인을 실행해 학습·평가하고 Registry에 등록.
• CD (지속적 배포): 모델이 승인되면 자동으로 스테이징·프로덕션 엔드포인트에 배포.
• 직접 손으로 엮을 수도 있지만, AWS는 SageMaker Projects라는 템플릿으로 전체 골격을 한 번에 깔아준다.

💡 관련 이론: ML CI/CD의 핵심 사상은 "모델 배포를 소프트웨어 배포처럼 버전 관리·자동화·롤백 가능하게 만든다"이다. 코드, 데이터, 모델이 모두 추적되고, 변경이 자동 트리거로 이어지며, 문제가 생기면 이전 버전으로 되돌릴 수 있어야 한다. 시험에서 "Git 커밋 → 자동 재학습·배포"라는 흐름은 SageMaker Projects + Code* 서비스 조합을 가리킨다.

SageMaker Projects — MLOps 템플릿

SageMaker Projects는 MLOps에 필요한 CI/CD 인프라를 미리 구성된 템플릿(Service Catalog 기반)으로 프로비저닝한다. 프로젝트를 생성하면 다음이 한꺼번에 생성된다.

• 어제·그제 수동으로 만든 것들이 표준 템플릿으로 통째로 묶여 나온다.
• 대표 템플릿은 "model building, training, and deployment"로, build 저장소와 deploy 저장소 두 개를 만든다.

전체 CI/CD 사슬 한눈에

 ┌──────────── CI (코드 축) ────────────┐
 개발자 git push
      │
      ▼
 CodeCommit / Git 저장소
      │  (푸시 이벤트)
      ▼
 CodePipeline(Build) ──▶ CodeBuild (buildspec.yml)
                              │
                              ▼
                    SageMaker Pipeline 실행
              전처리 → 학습 → 평가 → ConditionStep
                              │ 통과
                              ▼
                    RegisterModel → Model Registry
                    (PendingManualApproval)
 ─────────────────────────────────────────────────
 ┌──────────── CD (모델 축) ────────────┐
      검토자가 Approved 로 변경
                              │
                              ▼
              EventBridge "Model Package State Change"
                              │
                              ▼
                    CodePipeline(Deploy)
                              │
                ┌─────────────┴─────────────┐
                ▼                           │
      CloudFormation → 스테이징 엔드포인트     │
                ▼                           │
           자동 테스트 통과                    │
                ▼                           │
      ManualApproval 액션 (사람 확인) ────────┘
                ▼
      CloudFormation → 프로덕션 엔드포인트

핵심은 점선 위아래의 트리거가 서로 다르다는 점이다. 위는 코드 푸시, 아래는 모델 승인이다.

두 개의 파이프라인: Build와 Deploy

1) Build(모델 빌드) 파이프라인 — 코드 중심

• 개발자가 학습 코드를 저장소에 푸시
• CodePipeline이 변경을 감지해 CodeBuild 실행
• CodeBuild가 SageMaker Pipeline(전처리→학습→평가→등록)을 실행
• 결과 모델이 Model Registry에 PendingManualApproval로 등록

2) Deploy(모델 배포) 파이프라인 — 모델 중심

• Model Registry에서 모델이 Approved로 변경됨
• EventBridge가 승인 이벤트를 감지해 Deploy 파이프라인 트리거
• CloudFormation으로 스테이징 엔드포인트 배포 → 자동 테스트
• 수동 승인 게이트 통과 시 프로덕션 엔드포인트 배포

CodeCommit / CodeBuild / CodePipeline의 역할

각 서비스가 맡는 부분을 명확히 구분하는 것이 시험 포인트다.

CodeBuild의 작업은 buildspec.yml로 정의한다. 예를 들어 SageMaker Pipeline을 실행하는 빌드 단계는 이렇게 생긴다.

# buildspec.yml — CodeBuild가 실행할 명령 정의
version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.11
    commands:
      - pip install -r requirements.txt
  build:
    commands:
      # 코드 변경 시 SageMaker Pipeline을 생성/갱신하고 실행
      - python pipelines/run_pipeline.py --upsert
      - python pipelines/run_pipeline.py --start

자동 배포 트리거: 승인 → EventBridge → 배포

CD의 심장은 어제 배운 모델 승인 이벤트다. Model Registry에서 승인 상태가 바뀌면 EventBridge가 이를 잡아 Deploy 파이프라인을 시작한다.

import boto3
events = boto3.client("events")
 
# 모델 승인 상태가 Approved로 바뀌면 Deploy 파이프라인을 트리거하는 규칙
events.put_rule(
    Name="trigger-deploy-on-approval",
    EventPattern="""{
      "source": ["aws.sagemaker"],
      "detail-type": ["SageMaker Model Package State Change"],
      "detail": {
        "ModelApprovalStatus": ["Approved"]
      }
    }""",
)

이 규칙의 타깃을 Deploy용 CodePipeline으로 지정하면, 사람이 모델을 승인하는 순간 배포가 자동으로 굴러간다. 스테이징 검증 후 프로덕션 배포 전에 수동 승인 단계(manual approval action)를 한 번 더 두는 것이 안전 패턴이다.

# CodePipeline 단계 예시(개념): 스테이징 → 수동 승인 → 프로덕션
# 1. DeployStaging   (CloudFormation으로 스테이징 엔드포인트 생성)
# 2. ApprovalGate    (사람이 스테이징 결과 확인 후 승인)
# 3. DeployProd      (프로덕션 엔드포인트 배포)

CI/CD에서 스테이징 → 수동 승인 → 프로덕션의 단계적 배포는 "blast radius(영향 반경) 최소화" 원칙이다. 신모델을 곧장 프로덕션에 넣지 않고 스테이징에서 검증한 뒤 게이트를 통과시키면, 결함이 사용자에게 닿기 전에 걸러진다. 시험에서 "안전하게 자동 배포하되 프로덕션 직전 통제를 두려면"이라는 문장은 CodePipeline의 수동 승인 액션을 가리킨다.

⚠️ 함정: "모델 승인 시 자동 배포"와 "프로덕션 직전 사람 확인"은 서로 모순이 아니다. 승인이 두 번 나온다 — 첫 번째는 Registry의 Approved(모델을 배포 흐름에 태우는 결정), 두 번째는 CodePipeline의 ManualApproval 액션(스테이징 검증 결과를 보고 프로덕션에 내보내는 결정)이다. 보기에서 이 둘을 하나로 뭉뚱그린 선택지는 오답인 경우가 많다.

직접 구성 vs SageMaker Projects

SageMaker Projects 없이 CodePipeline·CodeBuild·EventBridge를 직접 엮어도 동일한 결과를 만들 수 있다.

어느 쪽이든 재학습을 무엇이 촉발하는가는 따로 설계해야 한다. 코드 푸시만으로는 데이터가 바뀌는 상황을 못 잡는다.

CI/CD가 꼬일 때: 증상 → 원인 → 조치

CI/CD 장애는 대부분 트리거·권한·정의 셋 중 하나다. 아무 일도 안 일어나면 트리거, 시작은 했는데 중간에 거부되면 권한, 끝까지 갔는데 결과가 틀리면 정의(buildspec·템플릿) 문제다. 이 순서로 좁히면 로그를 다 뒤지지 않아도 된다.

내일은 이 배포를 떠받치는 인프라 자체를 코드로 관리하는 IaC와, SageMaker 밖까지 아우르는 오케스트레이터들을 비교한다.

📖 용어

• CI (지속적 통합) : 코드가 바뀌면 자동으로 학습·평가까지 돌려 결과 모델을 등록하는 단계.
• CD (지속적 배포) : 승인된 모델을 사람 손 없이 엔드포인트까지 밀어 넣는 단계.
• SageMaker Projects : MLOps용 저장소·파이프라인·Registry·트리거를 템플릿 하나로 통째로 깔아 주는 기능.
• Service Catalog : 조직이 승인한 인프라 템플릿을 모아 두고 표준대로만 만들게 하는 AWS 서비스. Projects의 바탕이다.
• Build 파이프라인 : 코드 푸시로 시작해 모델을 학습·등록까지 하는 쪽 파이프라인.
• Deploy 파이프라인 : 모델 승인으로 시작해 엔드포인트를 배포하는 쪽 파이프라인.
• buildspec.yml : CodeBuild가 어떤 명령을 어떤 순서로 실행할지 적어 둔 파일.
• ManualApproval 액션 : CodePipeline 중간에 사람이 눌러야만 다음으로 넘어가는 정지 지점.
• EventBridge 규칙 : "이런 이벤트가 오면 저기로 보내라"는 라우팅 규칙. 배포 자동화의 방아쇠.
• blast radius (영향 반경) : 문제가 터졌을 때 피해가 미치는 범위. 스테이징을 거치는 이유가 이걸 줄이기 위해서다.