이 글에서 다루는 것

ArgoCD AppProject와 ApplicationSet을 사용해 dev/prod 환경과 Core/Baseline/Optional 레이어 경계를 구조적으로 강제하는 방법

선수지식

• GitOps 기반 E2E ML Platform - 운영 경계

ArgoCD AppProject / ApplicationSet

• dev/prod와 레이어 경계를 강제하기

들어가며

GitOps를 사용하는 이유는 보통 다음과 같이 설명됩니다.

• Git이 Single Source of Truth다
• 배포가 자동화된다
• 변경 이력을 추적할 수 있다

이 설명은 맞지만, 운영 관점에서 GitOps의 가장 중요한 역할은 따로 있습니다.

바로

배포 경계를 구조로 강제하는 것

입니다.

예를 들어 dev와 prod 환경이 있다고 가정해봅시다.

만약 다음과 같은 구조라면 문제가 생길 수 있습니다.

• 같은 Git repository
• 같은 Kubernetes cluster
• 단지 namespace 이름만 다른 환경

이 경우 작은 실수 하나로도 다음과 같은 일이 발생할 수 있습니다.

• dev 리소스가 prod에 배포되는 경우
• 테스트용 설정이 운영 환경에 적용되는 경우
• 특정 시스템이 잘못된 namespace로 배포되는 경우

이 프로젝트에서는 이런 문제를 줄이기 위해

ArgoCD 구조 자체를 환경 경계와 레이어 구조에 맞게 설계했습니다.

GitOps 구조 개요

이 플랫폼의 GitOps 구조는 다음과 같은 계층을 가집니다.

Root Application
      ↓
AppProject
      ↓
ApplicationSet
      ↓
Application

각 계층은 서로 다른 역할을 담당합니다.

이 구조 덕분에 GitOps가 단순한 배포 자동화가 아니라

운영 경계를 강제하는 시스템이 됩니다.

AppProject: 배포 경계를 정의하는 레이어

ArgoCD에서 AppProject는 중요한 역할을 합니다.

AppProject는 다음을 정의합니다.

• 어떤 repository를 사용할 수 있는지
• 어떤 cluster / namespace에 배포할 수 있는지
• 어떤 리소스를 생성할 수 있는지

즉,

Application이 어디에 배포될 수 있는지 정의하는 경계입니다.

이 프로젝트에서는 다음과 같은 AppProject 구조를 사용합니다.

Proof:

docs/proof/latest/projects.txt

실제 일부 결과를 보면 다음과 같습니다.

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

이 구조는 단순히 이름만 다른 것이 아닙니다.

각 프로젝트는 서로 다른 배포 목적을 가지고 있습니다.

dev / prod 환경 분리

dev와 prod는 단순히 namespace만 다른 것이 아니라

ArgoCD 프로젝트 수준에서 분리되어 있습니다.

예를 들어 dev 프로젝트는 다음과 같은 목적을 가집니다.

dev environment project
destination: *-dev namespaces

반면 prod 프로젝트는 다음과 같습니다.

prod environment project
destination: *-prod namespaces

이 구조 덕분에 다음과 같은 일이 가능해집니다.

• dev 애플리케이션은 prod namespace에 배포될 수 없음
• prod 애플리케이션은 dev namespace에 배포될 수 없음

즉,

잘못된 환경 반영을 사람의 주의가 아니라 구조로 방지합니다.

Baseline 프로젝트

Baseline은 운영 기반 시스템을 담당합니다.

대표적으로 다음 시스템들이 여기에 포함됩니다.

• Monitoring
• Logging
• Object Storage

실제 배포된 애플리케이션을 보면 다음과 같은 구성이 존재합니다.

Proof:

docs/proof/latest/apps.txt

예시 일부:

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

이 시스템들은 ML 파이프라인과 직접적으로 연결되지 않지만

플랫폼 운영에 반드시 필요한 시스템입니다.

그래서 Baseline 프로젝트는

Core 시스템과 독립적으로 관리됩니다.

Optional 프로젝트

Optional 프로젝트는 확장 기능을 위한 레이어입니다.

이 프로젝트에서는 Feature Store가 여기에 포함됩니다.

Proof:

docs/proof/latest/apps.txt

예시:

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

Optional 프로젝트의 특징은 다음과 같습니다.

• Core 시스템과 분리
• 필요할 때만 활성화
• 제거해도 플랫폼이 정상 동작

이 구조 덕분에 Feature Store 같은 시스템을

코어 구조에 영향을 주지 않고 추가할 수 있습니다.

Root Application: GitOps 구조의 시작점

GitOps 구조의 시작점은 Root Application입니다.

Proof:

docs/proof/latest/root-apps.txt

Root Application은 다음을 관리합니다.

root-apps
root-baseline
root-optional

이 구조는 다음과 같은 의미를 가집니다.

Root Application
   ├─ root-apps
   ├─ root-baseline
   └─ root-optional

즉, 루트 앱이 전체 플랫폼 구조를 관리합니다.

이 방식은 흔히 App-of-Apps 패턴이라고 불립니다.

ApplicationSet: 환경별 애플리케이션 생성

ApplicationSet은 GitOps 환경에서 유용한 기능입니다.

ApplicationSet을 사용하면

여러 환경에 동일한 구조의 애플리케이션을 생성할 수 있습니다.

예를 들어 다음과 같은 구조가 가능합니다.

ApplicationSet
   ├─ airflow-dev
   ├─ airflow-prod
   ├─ mlflow-dev
   ├─ mlflow-prod
   ├─ triton-dev
   └─ triton-prod

실제로 이 프로젝트에서도 ApplicationSet이 사용됩니다.

Proof:

mlops-core ApplicationSet

ApplicationSet 덕분에 다음이 가능해집니다.

• dev / prod 환경을 동일한 구조로 유지
• 환경 추가 시 자동 확장
• Git 변경으로 전체 구조 업데이트

실제 배포된 Core 시스템

Application 목록을 보면 Core 시스템이

dev와 prod 환경에 각각 배포된 것을 확인할 수 있습니다.

Proof:

docs/proof/latest/apps.txt

예시:

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

이 구조 덕분에 다음이 가능해집니다.

• dev 환경에서 모델 검증
• prod 환경에서 안정적인 서빙
• 두 환경을 동일한 구조로 유지

왜 이 구조가 중요한가

이 구조는 단순히 GitOps를 사용했다는 의미가 아닙니다.

오히려 중요한 점은 다음입니다.

GitOps를 사용해 운영 경계를 고정했다는 것입니다.

이 구조 덕분에 다음 문제가 줄어듭니다.

• dev → prod 잘못된 배포
• Optional 기능이 Core 시스템을 변경
• 운영 시스템과 ML 시스템이 뒤섞이는 문제

즉,

GitOps가 단순한 배포 자동화 도구가 아니라

운영 안정성을 확보하는 구조가 됩니다.

다음 글

이번 글에서는 GitOps 구조를 통해

• dev / prod 환경
• Core / Baseline / Optional 레이어

의 경계를 어떻게 강제했는지를 살펴보았습니다.

하지만 이 구조가 실제로 유용한지 확인하려면

다음 질문에 답할 수 있어야 합니다.

Optional 기능을 실제로 제거해도 플랫폼이 정상 동작할까?

다음 글에서는

Optional 기능을 실제로 ON/OFF하면서 Core 시스템이 독립적으로 동작하는지 검증하는 과정을 살펴보겠습니다.

Proof에서 확인할 자료:

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

이를 통해 Optional 레이어가 단순한 개념이 아니라

실제로 Attach / Detach 가능한 구조인지 확인해 보겠습니다.

설계 판단 (Why This Way?)

AppProject로 namespace 배포 경계를 강제하여 dev 리소스가 prod에 배포되는 것을 GitOps 구조 자체가 차단하고, App-of-Apps 패턴으로 전체 플랫폼을 단일 Git 커밋으로 선언적 관리합니다. ApplicationSet으로 환경별 Application을 자동 생성하여 환경 추가 시 수동 작업 없이 동일 구조가 확장됩니다.

다음에 읽을 글

→ GitOps 기반 E2E ML Platform - 토글 구조 — Optional ON/OFF 실제 검증