책에 포함된 노트AI 교육 7권 : 재현 가능한 AI 시스템 운영: 데이터 엔지니어링·MLOps·LLM 운영 실무

CI/CD/CT

2026-05-20Views 81약 9분생성형 AI 활용

Summary

이 장에서 배울 것

이번 장의 목표는 코드, 데이터, 모델, 파이프라인을 자동으로 테스트하고 배포하며, 필요할 때 재학습하는 운영 체계를 이해하는 것입니다.

앞 장에서는 데이터 검증, 학습, 평가, 모델 등록을 하나의 파이프라인으로 묶었습니다. 그러나 파이프라인이 있다고 해서 운영이 자동으로 안정해지는 것은 아닙니다. 누군가 실행 순서를 기억해야 하고, 배포 전에 무엇을 확인해야 하는지 문서만 보고 판단해야 한다면 여전히 위험합니다.

이 장에서는 다음을 배웁니다.

MLOps에서 CI, CD, CT가 각각 무엇을 자동화하는지
일반 DevOps의 CI/CD와 ML 시스템의 CI/CD가 어떻게 다른지
데이터 검증, 모델 성능 검증, 컨테이너 빌드, 배포 후보 생성을 하나의 흐름으로 연결하는 방법
지속적 학습, 즉 CT를 어떤 조건에서 실행해야 하는지
자동화할 부분과 사람이 승인해야 할 부분을 구분하는 방법

핵심 문장은 하나입니다. 운영 가능한 AI 시스템은 사람이 기억해서 배포하는 시스템이 아니라, 검증 절차가 자동으로 실행되는 시스템입니다.

CI/CD/CT

왜 이 주제가 중요한가

소프트웨어 서비스에서는 코드가 바뀌면 테스트하고 배포합니다. ML 시스템도 코드가 바뀝니다. 하지만 거기서 끝나지 않습니다. 데이터가 바뀌고, 피처 생성 로직이 바뀌고, 모델 파일이 바뀌고, 학습 파이프라인과 서빙 환경도 바뀝니다.

그래서 ML 시스템의 CI는 단순히 pytest를 실행하는 일이 아닙니다. 데이터 스키마가 맞는지, 피처 변환 결과가 깨지지 않았는지, 작은 샘플로 학습이 끝나는지, 새 모델의 성능이 기준보다 떨어지지 않았는지 확인해야 합니다. Google Cloud의 MLOps 가이드도 ML의 CI가 코드뿐 아니라 데이터, 데이터 스키마, 모델 검증까지 포함한다고 설명합니다.¹

배포도 마찬가지입니다. 모델 파일 하나를 서버에 복사하는 것은 CD가 아닙니다. 운영에서 실제로 필요한 것은 다음 항목을 같은 버전으로 묶어 배포하는 일입니다.

모델 서비스 코드
학습 파이프라인 코드
피처 파이프라인 코드
전처리 코드
설정 파일
컨테이너 이미지
인프라 정의
모델 레지스트리의 모델 버전

이 묶음이 어긋나면 "학습 때는 잘됐는데 운영에서는 이상하다"는 문제가 생깁니다. 예를 들어 학습에는 age를 정규화한 값이 들어갔는데, 서빙에서는 원본 age가 들어간다면 모델 파일은 정상이어도 예측은 틀어집니다.

핵심 개념 설명

CI: 지속적 통합

CI, Continuous Integration은 변경 사항을 자주 합치고 자동으로 검증하는 절차입니다. MLOps의 CI는 다음 테스트를 포함해야 합니다.

코드 테스트: 함수, API, 전처리 로직이 기대대로 동작하는지 확인
데이터 스키마 검사: 컬럼 이름, 타입, 필수값, 범주값이 계약과 맞는지 확인
피처 생성 로직 검증: 같은 입력에 같은 피처가 만들어지는지 확인
파이프라인 구성 검증: DAG, 의존성, 설정 파일이 실행 가능한지 확인
학습 스모크 테스트: 작은 샘플 데이터로 학습 코드가 끝까지 도는지 확인
메트릭 회귀 테스트: 새 모델 성능이 기존 기준보다 크게 떨어지지 않는지 확인

스모크 테스트는 전체 성능을 보려는 테스트가 아닙니다. "불이 나는지 먼저 보는" 최소 실행 테스트입니다. 전체 데이터를 쓰면 오래 걸리므로, CI에서는 작은 데이터로 빠르게 실패를 찾습니다.

CD: 지속적 제공과 지속적 배포

CD는 Continuous Delivery 또는 Continuous Deployment를 뜻합니다. Delivery는 배포 가능한 상태까지 자동화하고 최종 반영은 사람이 승인하는 방식입니다. Deployment는 조건을 통과하면 프로덕션 반영까지 자동으로 진행하는 방식입니다.

ML 시스템에서는 보통 처음부터 완전 자동 배포를 하지 않습니다. 다음과 같은 게이트가 필요합니다.

성능 기준 통과
데이터 품질 기준 통과
모델 크기와 추론 지연 시간 기준 통과
보안 또는 개인정보 검사 통과
스테이징 환경 검증 통과
운영자 승인
롤백 가능한 이전 버전 존재

모델 배포는 예측 API 하나만 바꾸는 일이 아닐 수 있습니다. 학습 파이프라인과 피처 파이프라인까지 함께 배포해야 합니다. ML 시스템에서는 학습 파이프라인 자체가 배포 대상이 될 수 있다는 점이 일반 소프트웨어와 다릅니다.¹

CT: 지속적 학습

MLOps에서 CT는 Continuous Testing이 아니라 Continuous Training, 즉 지속적 학습입니다. 운영 데이터가 변하면 모델도 낡습니다. CT는 새 데이터나 성능 저하 신호에 따라 재학습, 재평가, 재등록, 배포 후보 생성을 자동화합니다.

CT의 대표 트리거는 다음과 같습니다.

매일, 매주, 매월 실행하는 일정 기반 트리거
새 학습 데이터가 도착했을 때 실행하는 데이터 기반 트리거
운영 성능이 기준 아래로 떨어졌을 때 실행하는 성능 기반 트리거
입력 데이터 분포가 바뀌었을 때 실행하는 드리프트 기반 트리거
운영자가 장애 대응이나 캠페인 변화 때문에 직접 실행하는 수동 승인 트리거

중요한 점은 CT가 "새 모델을 무조건 운영에 배포한다"는 뜻이 아니라는 것입니다. CT의 결과는 우선 배포 후보 모델입니다. 후보 모델은 모델 레지스트리에 등록되고, 검증 기준을 통과해야 다음 단계로 갑니다.

쉬운 비유 또는 사례

음식점 주방을 생각해 봅시다. 수동 운영은 요리사가 기억으로만 조리하는 방식입니다. "소금은 적당히, 불은 알아서, 재료 상태는 눈대중"으로 일합니다. 손맛이 좋은 동안에는 괜찮지만, 사람이 바뀌거나 재료가 달라지면 품질이 흔들립니다.

CI/CD/CT가 있는 주방은 다릅니다.

CI는 새 레시피가 들어왔을 때 계량, 조리 순서, 알레르기 성분을 검사합니다.
CD는 검증된 레시피와 재료 목록, 조리 도구 설정을 지점에 배포합니다.
CT는 계절이 바뀌어 재료 맛이 달라지면 레시피를 다시 조정하고 시식 평가를 거쳐 후보 레시피로 올립니다.

AI 시스템도 같습니다. 모델은 레시피이고, 데이터는 재료이며, 파이프라인은 조리 순서입니다. 운영 품질은 뛰어난 모델 하나보다 반복 가능한 절차에서 나옵니다.

직접 해보는 실습

이번 실습에서는 GitHub Actions를 기준으로 간단한 MLOps CI 흐름을 만듭니다. GitLab CI를 사용한다면 단계 이름만 바꾸어 적용하면 됩니다.

실습 목표

다음 작업을 자동으로 실행합니다.

코드 테스트
데이터 스키마 검사
컨테이너 빌드 확인
작은 샘플 학습 스모크 테스트
모델 메트릭 검증
모델 레지스트리 등록 후보 생성

예시 저장소 구조

mlops-project/
  data/sample.csv
  schemas/train_schema.json
  src/train.py
  src/validate_data.py
  src/evaluate.py
  tests/test_features.py
  Dockerfile
  requirements.txt
  .github/workflows/mlops-ci.yml

데이터 스키마 검사 예시

validate_data.py는 최소한 다음을 확인합니다.

필수 컬럼이 있는가
타입이 맞는가
결측률이 기준 이하인가
라벨 컬럼이 비어 있지 않은가

예를 들어 고객 이탈 예측이라면 customer_id, age, plan_type, churn 같은 필수 컬럼이 있어야 합니다. 이 검사를 CI에서 실행하면 잘못된 데이터 파일이 학습 파이프라인으로 들어가기 전에 멈출 수 있습니다.

GitHub Actions 예시

name: mlops-ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test-build-train:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: |
          pip install -r requirements.txt

      - name: Run unit tests
        run: |
          pytest tests

      - name: Validate data schema
        run: |
          python src/validate_data.py --data data/sample.csv --schema schemas/train_schema.json

      - name: Build container
        run: |
          docker build -t churn-model:${{ github.sha }} .

      - name: Training smoke test
        run: |
          python src/train.py --data data/sample.csv --epochs 1 --output outputs/model.pkl

      - name: Evaluate metrics
        run: |
          python src/evaluate.py --model outputs/model.pkl --min-f1 0.70

이 예시는 간단하지만 중요한 원칙을 담고 있습니다. Pull Request가 열릴 때마다 코드와 데이터 계약을 확인합니다. main에 병합되면 같은 절차를 다시 실행합니다. 실제 프로젝트에서는 여기에 MLflow 등록, DVC 데이터 버전 확인, 컨테이너 레지스트리 푸시, 스테이징 배포를 추가할 수 있습니다.

자동 테스트는 빠른 피드백을 주고, 운영 결함을 조기에 막는 역할을 합니다. 특히 ML 시스템에서는 소프트웨어 로직, 데이터 파이프라인, 모델 지표, API 동작을 나누어 테스트해야 합니다.²

승인 게이트 추가하기

자동화가 늘어날수록 승인 기준도 코드로 남겨야 합니다.

예시는 다음과 같습니다.

배포 후보 조건
- f1_score >= 0.70
- 기존 운영 모델보다 f1_score 하락 폭 <= 0.02
- p95 추론 지연 시간 <= 200ms
- 모델 크기 <= 500MB
- 데이터 스키마 검사 통과
- 스테이징 예측 API 헬스체크 통과

이 조건을 통과한 모델만 모델 레지스트리에 후보로 등록합니다. MLflow를 쓴다면 새 모델 버전에 validation_status=pending 같은 tag를 붙이고, candidate alias를 부여할 수 있습니다. 스테이징 검증이 끝나면 staging alias를 붙이고, 최종 승인 후에는 production alias를 전환합니다. 과거에는 Staging, Production, Archived 같은 stage를 많이 썼지만, 최신 MLflow 흐름에서는 alias와 tag를 이용한 표현이 더 유연합니다.

프로덕션 승격은 처음에는 사람이 승인하도록 두는 것이 안전합니다. 완전 자동 배포는 모니터링, 롤백, 책임 경계가 충분히 준비된 뒤에 단계적으로 도입해야 합니다.

흔한 실수와 오류 분석

실수 1: CI를 코드 테스트로만 이해한다

ML 시스템에서는 데이터가 코드만큼 중요합니다. 코드 테스트가 모두 통과해도 데이터 컬럼이 하나 사라지면 학습은 실패하거나 더 나쁘게는 조용히 잘못된 모델을 만들 수 있습니다.

해결책은 데이터 계약을 만드는 것입니다. 컬럼, 타입, 허용 범위, 결측률, 라벨 분포 기준을 명시하고 CI에서 검사합니다.

실수 2: 모델 파일만 배포한다

모델 파일과 전처리 코드 버전이 맞지 않으면 예측 품질이 깨집니다. 모델, 전처리, 설정, 컨테이너 이미지를 하나의 릴리스 단위로 묶어야 합니다.

해결책은 배포 단위에 Git 커밋, 데이터 버전, 모델 버전, 이미지 태그, 파이프라인 실행 ID를 함께 기록하는 것입니다.

실수 3: CT를 완전 자동 운영 배포로 착각한다

지속적 학습은 재학습 자동화이지 무조건적인 프로덕션 배포가 아닙니다. 새 모델은 성능이 더 낮을 수도 있고, 특정 사용자 세그먼트에서만 나빠질 수도 있습니다.

해결책은 CT 결과를 배포 후보로 만들고, 모델 검증과 승인 게이트를 거쳐 승격하는 것입니다.

실수 4: 개발, 스테이징, 프로덕션을 섞는다

개발 환경에서 만든 임시 데이터와 운영 데이터가 섞이면 재현성이 사라집니다. 실험 모델이 운영 모델처럼 보이거나, 운영 설정이 실험 중에 바뀌는 사고가 납니다.

해결책은 환경을 분리하고 권한도 분리하는 것입니다. 개발은 자유롭게 실험하되, 스테이징과 프로덕션에는 승인된 파이프라인만 접근하게 합니다.

실수 5: 실패 알림과 롤백 조건이 없다

자동화는 실패도 빠르게 만듭니다. 실패했을 때 누가, 무엇을, 언제 확인해야 하는지 없으면 자동화는 오히려 장애를 키웁니다.

해결책은 알림 채널, 담당자, 중단 조건, 롤백 조건을 함께 정의하는 것입니다. MLOps 자동화 수준이 높아질수록 모니터링 이벤트, 데이터 변화, 코드 변화 같은 트리거를 명확히 관리해야 합니다.³

실수 6: 자동화 수준을 한 번에 너무 높인다

수동 검증도 제대로 정리되지 않은 상태에서 완전 자동 재학습과 자동 배포를 붙이면 위험합니다. 자동화는 잘못된 결정을 빠르게 반복할 수도 있습니다.

해결책은 단계적으로 도입하는 것입니다. 먼저 테스트와 데이터 검증을 자동화하고, 다음으로 학습 스모크 테스트와 모델 등록 후보 생성을 자동화합니다. 프로덕션 전환은 충분한 모니터링과 롤백 훈련이 끝난 뒤 자동화 범위를 넓힙니다.

요약

CI/CD/CT는 ML 시스템을 운영 가능한 형태로 만드는 핵심 자동화입니다.

CI는 코드뿐 아니라 데이터, 피처 로직, 파이프라인, 모델 메트릭을 검증합니다.
CD는 모델 파일 하나가 아니라 서비스 코드, 파이프라인, 설정, 이미지, 인프라 정의를 일관된 버전으로 배포합니다.
CT는 지속적 테스트가 아니라 지속적 학습입니다. 새 데이터, 성능 저하, 드리프트, 일정, 수동 승인에 따라 재학습을 실행합니다.
자동화는 단계적으로 도입해야 합니다. 수동 실험에서 시작해 학습 파이프라인 자동화, 모델 검증, 배포 후보 생성, 승인 기반 운영 배포로 발전시키는 것이 안전합니다.
개발, 스테이징, 프로덕션 환경을 분리하고 롤백 가능한 버전을 남겨야 합니다.

좋은 MLOps 파이프라인은 "누가 배포했는가"보다 "어떤 검증을 통과했는가"를 먼저 보여줍니다.

퀴즈

MLOps의 CI가 일반 소프트웨어 CI보다 더 확인해야 하는 항목은 무엇인가?
CT는 MLOps에서 무엇의 약자인가?
모델 파일만 서버에 올리는 배포가 위험한 이유는 무엇인가?
학습 스모크 테스트의 목적은 높은 성능 측정인가, 빠른 실행 가능성 확인인가?
새 모델이 기존 모델보다 전체 성능은 높지만 특정 세그먼트 성능이 낮다면 바로 배포해도 되는가?

체크리스트

Pull Request마다 코드 테스트가 자동 실행되는가?
데이터 스키마와 결측률 검사가 자동화되어 있는가?
피처 생성 로직에 테스트가 있는가?
작은 샘플 학습 스모크 테스트가 있는가?
모델 성능 기준이 코드나 설정으로 관리되는가?
모델, 데이터, 코드, 컨테이너 이미지, 파이프라인 실행 ID가 함께 추적되는가?
스테이징과 프로덕션 환경이 분리되어 있는가?
모델 레지스트리에 상태값이 있는가? 예: alias candidate, staging, production 또는 tag validation_status=passed
배포 승인 조건과 롤백 조건이 문서화되어 있는가?
CT 트리거가 명확한가? 예: 일정, 새 데이터, 성능 저하, 드리프트, 수동 승인
실패 시 알림을 받을 담당자와 채널이 정해져 있는가?

다음 장 연결

이번 장에서는 검증된 모델과 파이프라인을 배포 후보로 만드는 방법을 배웠습니다. 다음 장에서는 이 후보 모델을 실제 사용자 요청에 응답하는 서비스로 만드는 방법을 다룹니다.

모델 서빙에서는 API 방식, 배치 예측, 실시간 추론, 컨테이너 배포, 카나리 배포, 롤백 전략이 중요해집니다. CI/CD/CT가 "안전하게 내보낼 준비"라면, 모델 서빙은 "운영 트래픽을 안정적으로 처리하는 방법"입니다.

참고

¹Google Cloud Architecture Center, MLOps: Continuous delivery and automation pipelines in machine learning

²한빛+, ML 프로젝트의 테스트 자동화와 CD4ML 전략

³MLOps Principles

책 목록

AI 교육 7권 : 재현 가능한 AI 시스템 운영: 데이터 엔지니어링·MLOps·LLM 운영 실무

전체 목차 보기