이 글에서 다루는 것
GitOps 기반 E2E ML Platform의 4가지 설계 원칙과 시리즈 전체 구조
선수지식
- 이 글부터 시작 가능 (시리즈 첫 글)
- Kubernetes, ArgoCD 기본 개념을 알면 더 좋음
GitOps 기반 E2E ML Platform
- 설계 의도
들어가며
머신러닝 프로젝트를 처음 접하면 보통 이런 흐름으로 시작합니다.
- 데이터를 준비한다
- 모델을 학습한다
- 모델을 배포한다
이 흐름은 학습이나 실험에는 충분합니다.
하지만 운영 환경에서는 이야기가 조금 달라집니다.
운영 환경에서는 다음 질문이 먼저 등장합니다.
- 잘못된 모델이 배포되면 어떻게 막을 것인가
- dev와 prod를 어떻게 분리할 것인가
- 관측이 실패했을 때 롤백은 어떻게 할 것인가
- 확장 기능이 코어 시스템을 망가뜨리지 않도록 어떻게 설계할 것인가
즉, 문제는 모델을 배포하는 방법이 아니라 운영 환경에서 변경을 통제하는 방법입니다.
이 프로젝트는 이러한 문제를 해결하기 위해 설계한
GitOps 기반 End-to-End ML Platform입니다.
이 시리즈는 설치 과정을 설명하는 글이 아니라
운영 구조를 어떻게 설계했는지와 그 설계를 어떻게 검증했는지를 기록하는 글입니다.
이 프로젝트가 풀려고 한 문제
ML 플랫폼을 처음 설계할 때 가장 먼저 고민했던 것은
“어떤 도구를 사용할 것인가”가 아니었습니다.
오히려 다음 질문이 먼저였습니다.
- 모델 변경이 운영 서비스에 언제 반영되어야 하는가
- 검증되지 않은 모델이 운영 경로로 들어오는 것을 어떻게 막을 것인가
- 확장 기능이 추가되더라도 코어 시스템이 흔들리지 않도록 만들 수 있을까
- 플랫폼의 동작을 문서가 아니라 실행 결과로 증명할 수 있을까
이 질문들을 바탕으로 다음 세 가지 원칙을 세웠습니다.
설계 원칙 1
운영 리스크를 먼저 통제한다
많은 ML 프로젝트가 다음과 같은 구조를 가집니다.
train → register → deploy
이 구조에서는 학습 성공이 곧 운영 반영을 의미하게 됩니다.
하지만 운영 환경에서는 이 접근이 위험합니다.
- 데이터 드리프트가 있을 수 있고
- 모델 성능이 특정 환경에서만 좋을 수 있으며
- 서빙 환경에서 문제가 발생할 수도 있기 때문입니다.
그래서 이 플랫폼에서는 다음과 같은 흐름을 사용합니다.
Feature Pipeline
↓
Drift Gate
↓
Train
↓
Promotion / Shadow 분기
↓
Model Register
↓
READY Sensor
↓
Deploy
↓
FastAPI Reload
↓
Post Deploy Observability
↓
Auto Rollback
즉,
학습 성공 = 배포 성공
이라는 가정을 제거하고
운영 반영 전에 여러 단계의 검증을 거치도록 설계했습니다.
설계 원칙 2
운영 책임 경계를 먼저 분리한다
이 플랫폼의 가장 중요한 구조는
Core / Baseline / Optional 레이어 분리입니다.
Core
모델 생명주기 자동화를 담당합니다.
대표 구성 요소
- Airflow
- MLflow
- Triton
- FastAPI
즉,
데이터 → 학습 → 등록 → 서빙 반영
을 담당하는 핵심 경로입니다.
Baseline
Baseline은 항상 살아 있어야 하는 운영 기반입니다.
예를 들어
- Monitoring
- Logging
- Object Storage
이러한 시스템은 ML 기능과 무관하게
플랫폼 운영에 반드시 필요합니다.
그래서 Baseline은 Optional 기능과 완전히 분리된 계층으로 두었습니다.
Optional
Optional은 말 그대로 필요할 때만 붙이는 확장 기능입니다.
예를 들어
- Feature Store
- 추가 실험 시스템
- 데이터 플랫폼
이 기능들이 코어 시스템에 직접 의존하면
플랫폼 복잡도가 급격히 증가합니다.
그래서 Optional은
Attach / Detach 가능한 독립 레이어
로 설계했습니다.
이 구조 덕분에
- Optional 기능을 제거해도
- Core와 Baseline은 그대로 동작합니다.
이 부분은 이후 글에서 실제 Proof와 함께 설명합니다.
설계 원칙 3
구조로 배포 경계를 고정한다
GitOps를 사용하는 이유는 단순히 자동화를 위해서가 아닙니다.
이 프로젝트에서는 GitOps를 배포 경계를 강제하기 위한 구조로 사용합니다.
예를 들어 dev와 prod는 단순히 네임스페이스만 다른 것이 아닙니다.
실제로는 다음과 같은 구조로 분리되어 있습니다.
ArgoCD Root Application
↓
AppProject (dev / prod / baseline / optional)
↓
ApplicationSet
↓
Applications
이 구조를 통해 다음을 보장합니다.
- dev 리소스가 prod로 잘못 배포되는 것을 방지
- Optional 기능이 Core 시스템을 건드리지 못하도록 분리
- Baseline 운영 시스템을 독립적으로 관리
즉,
사람의 주의가 아니라 구조로 배포 범위를 통제하는 방식입니다.
설계 원칙 4
플랫폼의 동작을 Proof로 증명한다
많은 기술 글이 다음과 같은 방식으로 작성됩니다.
- 코드 설명
- 아키텍처 다이어그램
- 실행 스크린샷
하지만 이런 방식은 종종 다음 문제를 남깁니다.
“정말로 이 시스템이 동작하는가?”
그래서 이 프로젝트에서는
플랫폼의 동작을 Proof 파일로 남기도록 설계했습니다.
예를 들어 다음과 같은 증거들이 존재합니다.
GitOps 구조 증명
docs/proof/latest/projects.txt
docs/proof/latest/apps.txt
docs/proof/latest/root-apps.txt
Optional ON/OFF 동작 증명
docs/proof/latest/core_only/*
docs/proof/latest/optional_on/*
Serving Runtime 증명
docs/proof/latest/e2e_success/*
Observability 구성 증명
docs/proof/latest/observability/*
이 Proof 파일들은 단순 로그가 아니라
- 플랫폼 구조
- 실행 상태
- 서빙 결과
- 모니터링 구성
을 실제 실행 결과로 검증한 기록입니다.
이 시리즈에서 다룰 내용
이 시리즈에서는 다음 내용을 순서대로 설명합니다.
1️⃣ Core / Baseline / Optional 구조 설계
2️⃣ ArgoCD GitOps로 dev/prod 경계를 고정하는 방법
3️⃣ Optional Feature Store를 Attach/Detach 가능한 구조로 만드는 방법
4️⃣ 학습 파이프라인이 아닌 운영 반영 통제 파이프라인 설계
5️⃣ Drift Gate / Promotion / Shadow 전략
6️⃣ MLflow + Triton + FastAPI 서빙 구조
7️⃣ 실제 Serving Runtime 동작 증명
8️⃣ Observability와 Auto Rollback 정책
9️⃣ Runbook / Security / Audit 문서화
이 과정을 통해
ML 모델을 배포하는 시스템이 아니라 운영 환경에서 변경을 통제하는 플랫폼을 어떻게 설계했는지를 설명하려 합니다.
마무리
이 프로젝트의 목표는 단순한 ML 데모 환경을 만드는 것이 아니었습니다.
오히려 다음 질문에 대한 답을 찾는 과정이었습니다.
- 모델 변경을 어떻게 안전하게 운영 환경에 반영할 것인가
- 확장 기능이 추가되어도 플랫폼이 복잡해지지 않도록 할 수 있을까
- 플랫폼의 동작을 문서가 아니라 실행 결과로 증명할 수 있을까
이 시리즈에서는 그 과정에서 만들어진 구조와 설계 결정을 하나씩 설명하려 합니다.
다음 글에서는
Core / Baseline / Optional 구조를 어떻게 나누었는지와
그 구조가 실제 GitOps 환경에서 어떻게 동작하는지를 살펴보겠습니다.
설계 판단 (Why This Way?)
train에서 deploy로 직결하는 구조는 검증 없이 운영에 반영되는 위험이 있으므로, Drift Gate/Promotion-Shadow 분기/Auto Rollback을 파이프라인에 내장하여 운영 리스크를 구조적으로 차단했습니다. Core/Baseline/Optional 레이어 분리로 확장 기능 장애가 코어 서빙에 전파되지 않도록 격리했습니다.
다음에 읽을 글
→ GitOps 기반 E2E ML Platform - 운영 경계 — Core / Baseline / Optional 아키텍처