이 글에서 다루는 것

Core / Baseline / Optional 세 레이어의 설계 기준과 실제 GitOps 배포 구조에서의 구현

선수지식

Core / Baseline / Optional

  • 운영 가능한 경계를 먼저 설계

들어가며

ML 플랫폼을 설계할 때 흔히 하는 접근은

필요한 도구를 하나씩 붙여 나가는 방식입니다.

예를 들어 다음과 같은 식입니다.

  • Airflow 설치
  • MLflow 추가
  • Triton 추가
  • Monitoring 추가
  • Feature Store 추가

이 방식은 처음에는 빠르게 시스템을 만들 수 있습니다.

하지만 시간이 지나면 다음 문제가 생기기 시작합니다.

  • 시스템 의존성이 서로 얽히기 시작한다
  • 특정 기능이 다른 기능을 망가뜨리기 시작한다
  • 확장 기능이 코어 시스템을 복잡하게 만든다

이 문제의 근본 원인은 대부분 같습니다.

운영 책임이 다른 시스템들이 같은 계층에 섞여 있기 때문입니다.

그래서 이 프로젝트에서는

도구를 먼저 고르는 대신 운영 경계를 먼저 설계했습니다.

그 결과가 바로

Core
Baseline
Optional

이라는 세 가지 레이어입니다.

운영 구조를 먼저 나눈 이유

ML 플랫폼에는 여러 종류의 시스템이 존재합니다.

하지만 이 시스템들은 실제로 서로 다른 책임을 가지고 있습니다.

예를 들어 다음을 생각해 볼 수 있습니다.

시스템역할
Airflow파이프라인 orchestration
MLflow모델 tracking / registry
Triton모델 serving runtime
FastAPIinference gateway
Monitoring운영 상태 관측
Logging로그 수집
Feature Store데이터 재사용

이 시스템들을 하나의 레이어로 묶어 버리면

다음 문제가 발생합니다.

  • Feature Store 장애가 서빙 시스템에 영향
  • Monitoring 변경이 모델 파이프라인에 영향
  • 데이터 시스템이 ML serving 구조에 의존

이러한 결합은 운영 안정성을 떨어뜨립니다.

그래서 이 플랫폼에서는

시스템을 기능이 아니라 운영 책임 기준으로 분리했습니다.

Core: 모델 생명주기 자동화의 핵심 경로

Core는 플랫폼에서 가장 중요한 부분입니다.

이 레이어는 다음 역할을 담당합니다.

데이터 처리
→ 모델 학습
→ 모델 등록
→ 서빙 반영

즉, 모델 생명주기(Model Lifecycle) 전체를 담당합니다.

대표적인 구성 요소는 다음과 같습니다.

  • Airflow
  • MLflow
  • Triton
  • FastAPI

이 시스템들은 서로 강하게 연결됩니다.

예를 들어 실제 흐름은 다음과 같습니다.

Airflow DAG
    ↓
MLflow Model Registry
    ↓
Triton Model Repository
    ↓
FastAPI Reload

이 경로는 플랫폼에서 가장 중요한 경로이기 때문에

다른 시스템과 섞이지 않도록 Core 레이어로 독립시켰습니다.

Baseline: 항상 살아 있어야 하는 운영 기반

Baseline은 Core와는 다른 성격의 시스템입니다.

이 레이어는 ML 기능과 관계없이 항상 필요합니다.

예를 들어 다음 시스템들이 여기에 포함됩니다.

  • Prometheus / Alertmanager
  • Grafana
  • Loki
  • Object Storage (MinIO)

이 시스템들은 다음 역할을 합니다.

Monitoring
Logging
Storage
Cluster Observability

이 기능들은 모델 학습이나 서빙과 직접적인 관계는 없습니다.

하지만 운영 환경에서는 반드시 필요합니다.

그래서 Baseline 레이어는 다음 특징을 갖습니다.

  • Core와 독립적으로 유지
  • Optional 기능과 무관하게 항상 실행
  • 운영 관측과 로그 수집 담당

이 구조 덕분에 Core 시스템에 문제가 발생하더라도

Baseline을 통해 상태를 관측할 수 있습니다.

Optional: 확장 기능을 위한 독립 레이어

Optional 레이어는 확장 기능을 위한 영역입니다.

예를 들어 다음 시스템이 여기에 포함됩니다.

  • Feature Store (Feast)

Feature Store는 유용한 시스템입니다.

하지만 모든 ML 플랫폼에 반드시 필요한 것은 아닙니다.

또한 Feature Store는 다음 특성을 가지고 있습니다.

  • 데이터 시스템과 강하게 연결됨
  • 인프라 요구사항이 커질 수 있음
  • 운영 복잡도가 증가함

그래서 Feature Store를 Core 시스템에 직접 넣으면

플랫폼 전체가 복잡해질 수 있습니다.

이 프로젝트에서는 이를 해결하기 위해

Optional 레이어를 별도로 만들었습니다.

Optional 레이어의 핵심 특징은 다음과 같습니다.

Attach / Detach 가능
Core와 독립
Baseline과도 독립

즉, Optional 기능을 제거해도

  • Core는 정상 동작하고
  • Baseline도 정상 동작합니다.

실제 GitOps 구조

이 구조는 단순한 개념이 아니라

ArgoCD GitOps 환경에서 실제로 구현되어 있습니다.

예를 들어 플랫폼의 AppProject 구성은 다음과 같습니다.

baseline
bootstrap
dev
prod
optional

이 구조는 실제 ArgoCD 프로젝트 목록에서도 확인할 수 있습니다.

Proof:

docs/proof/latest/projects.txt

예시 일부:

baseline   Baseline stack project (minio / loki / alloy)
bootstrap  Root/Bootstrap project
dev        Dev environment project
prod       Prod environment project
optional   Optional project (feature-store / feast)

즉, 레이어 구조가 단순한 문서가 아니라

GitOps 배포 구조 자체에 반영되어 있습니다.

실제 배포된 애플리케이션 구조

ArgoCD Application 목록을 보면

각 레이어가 실제로 분리되어 있는 것을 확인할 수 있습니다.

Proof:

docs/proof/latest/apps.txt

예시 일부:

Core

airflow-dev
airflow-prod
mlflow-dev
mlflow-prod
fastapi-dev
fastapi-prod
triton-dev
triton-prod

Baseline

monitoring-dev
monitoring-prod
loki-dev
loki-prod
minio-dev
minio-prod
alloy-dev
alloy-prod

Optional

feast-dev
feast-prod
optional-envs-dev
optional-envs-prod

이 구조를 보면 다음 특징을 확인할 수 있습니다.

  • Core 시스템은 dev/prod 환경별로 분리
  • Baseline 시스템은 운영 기반으로 별도 관리
  • Optional 기능은 독립 프로젝트로 분리

Root Application 구조

GitOps의 루트 구조 역시 레이어 개념을 기반으로 설계했습니다.

Proof:

docs/proof/latest/root-apps.txt

루트 애플리케이션은 다음을 관리합니다.

root-apps
root-baseline
root-optional

이 구조는 다음을 의미합니다.

Root App
   ↓
Layer Management
   ↓
Environment Applications

즉, 루트 앱이 전체 구조를 관리하고

각 레이어는 독립적으로 배포됩니다.

왜 이 구조가 중요한가

이 구조의 가장 큰 장점은

운영 복잡도를 통제할 수 있다는 점입니다.

예를 들어 다음 상황을 생각해볼 수 있습니다.

Feature Store 장애

Optional 레이어 장애

→ Core 영향 없음

→ Serving 영향 없음

Monitoring 변경

Baseline 레이어 변경

→ Core 영향 없음

모델 파이프라인 변경

Core 레이어 변경

→ Optional 영향 없음

이러한 구조 덕분에

각 시스템의 변경 범위를 레이어 단위로 제한할 수 있습니다.

이 구조가 실제로 검증되는 방식

이 시리즈에서는 이 구조를 단순히 설명하는 것이 아니라

실제로 동작한다는 것을 Proof로 확인합니다.

예를 들어 다음 글에서는

  • Optional ON/OFF 테스트
  • Core-only 환경 동작
  • Feature Store detach

을 실제 실행 결과로 확인합니다.

관련 Proof:

docs/proof/latest/core_only/*
docs/proof/latest/optional_on/*

즉, Optional 레이어가 실제로 Attach / Detach 가능한 구조인지

실행 결과로 검증합니다.

마무리

이 플랫폼을 설계하면서 가장 먼저 결정한 것은

어떤 도구를 사용할지가 아니었습니다.

대신 다음 질문을 먼저 고민했습니다.

운영 책임이 다른 시스템들을 어떻게 분리할 것인가

그 결과 만들어진 구조가 바로

Core
Baseline
Optional

이라는 세 가지 레이어입니다.

이 구조 덕분에

  • 모델 생명주기 자동화
  • 운영 관측 시스템
  • 확장 기능

이 서로 간섭하지 않도록 만들 수 있었습니다.

다음 글에서는

ArgoCD AppProject와 ApplicationSet을 사용해 dev / prod 환경과 레이어 경계를 어떻게 강제했는지를 살펴보겠습니다.

설계 판단 (Why This Way?)

도구 종류가 아닌 장애 영향 범위와 변경 빈도를 기준으로 Core/Baseline/Optional을 분리하고, 이 레이어 경계를 ArgoCD AppProject에 직접 반영하여 잘못된 배포를 구조적으로 방지합니다. Baseline(Monitoring, Logging, Storage)은 ML 기능과 무관하지만 운영에 필수이므로 Core와 분리하여 상호 영향을 차단했습니다.

다음에 읽을 글

→ GitOps 기반 E2E ML Platform - GitOps 구조 — ArgoCD AppProject / ApplicationSet으로 배포 경계 강제