Argo CD로 확장하는 GitOps 운영 전략: 멀티 클러스터 환경에서 App of Apps와 ApplicationSet의 조합

1. 배포 자동화, 이제는 선택이 아닌 필수다

서비스가 증가하고 인프라가 복잡해지면서, 배포는 더 이상 단순한 코드 반영 작업이 아니다. 안정성과 속도를 동시에 확보해야 하는 핵심 과제로 자리 잡았다. 과거처럼 운영자가 직접 서버에 접속해 명령어를 실행하던 방식은 명백한 한계를 드러낸다. 사람의 실수는 불가피하고, 서비스 규모가 커질수록 관리 비용은 기하급수적으로 늘어난다.

이러한 문제를 해결하기 위해 등장한 것이 GitOps다. Git 저장소를 단일 진실 공급원(Single Source of Truth)으로 삼아 운영 환경을 자동으로 동기화하는 이 방법론은 자동화, 표준화, 추적 가능성을 모두 충족시킨다. 우리 팀 역시 Kubernetes 환경에서 GitOps를 도입하며 Argo CD를 중심으로 운영 체계를 발전시켜 왔다.

초기에는 단일 Application 리소스만으로 충분했다. 하지만 서비스와 환경이 늘어나면서 관리 지점이 급증했고, 자연스럽게 App of Apps 패턴과 ApplicationSet 리소스를 결합한 운영 방식으로 진화했다. 특히 멀티 클러스터 환경에서 두 방식의 조합은 탁월한 효과를 보였다.

이번 글에서는 우리 팀이 실전에서 겪은 GitOps 운영 경험을 공유한다. App of Apps 패턴과 ApplicationSet 리소스를 어떻게 조합해 확장성과 안정성을 동시에 확보했는지, 그 과정과 결과를 구체적으로 소개한다.

2. GitOps, Git 저장소가 곧 운영 환경의 청사진이다

GitOps는 Git 저장소에 정의된 상태와 실제 운영 환경을 항상 일치시키는 방법론이다. 개발자가 Git에 원하는 상태를 선언하면, 운영 환경은 그 상태를 향해 자동으로 수렴한다. 복잡한 설명이 필요 없는, 명료한 원칙이다.

GitOps의 핵심 장점

자동화: 변경 사항이 자동 적용되므로 수동 작업이 줄고 휴먼 에러를 예방한다.

일관성: 모든 환경에서 동일한 구성으로 배포가 이루어진다.

투명성: 모든 구성이 Git에 기록되어 변경 이력을 명확히 추적할 수 있다.

안정성: 문제 발생 시 이전 상태로 신속하게 롤백할 수 있다.

우리 팀의 GitOps 워크플로우

우리 팀은 다음과 같은 흐름으로 애플리케이션과 인프라를 운영한다.

1. 코드 푸시: 개발자가 GitLab 저장소에 신규 코드를 푸시한다.
2. CI 빌드 및 이미지 배포: Jenkins가 Docker 이미지를 빌드하고 Amazon ECR에 업로드한다.
3. 이미지 태그 업데이트: 매니페스트에 새로운 이미지 태그를 반영한다.
4. 리소스 설정 변경: 인프라 팀이 values.yaml 등 리소스를 수정하고 GitLab에 푸시한다.
5. GitOps 동기화: Argo CD가 Git 변경을 감지하고 Kubernetes에 자동 반영한다.
6. 클러스터 반영: EKS 클러스터에 실제 배포가 적용된다.

3. Argo CD와 두 가지 핵심 운영 방식: App of Apps와 ApplicationSet

Argo CD란

Argo CD는 CNCF가 관리하는 Kubernetes 전용 GitOps 도구다. 주요 특징은 다음과 같다.

• 자동 동기화(Self-heal): Git과 클러스터 상태를 자동으로 일치시킨다.
• 실시간 가시성: UI와 CLI로 배포 현황을 즉시 확인할 수 있다.
• 배포 이력 추적: Git Commit이 곧 배포 이력이 된다.
• 다중 클러스터 지원: 하나의 Argo CD로 여러 클러스터를 관리한다.
• 권한 제어: RBAC과 SSO를 지원한다.

App of Apps 패턴

App of Apps는 하나의 상위 애플리케이션이 여러 하위 Argo CD 애플리케이션을 정의한 YAML 파일들을 관리하는 구조다. 서비스 카탈로그처럼 서비스 단위로 Application 그룹을 관리할 수 있다.

주요 개념:

• Root Application이 여러 Application 디렉토리를 참조한다.
• 신규 서비스 추가 시 디렉토리만 추가하면 Root Application이 자동 반영한다.
• 프로젝트나 팀 단위 서비스 관리에 적합하다.

적합한 환경:

• 신규 서비스가 빈번하게 추가되는 환경
• 여러 팀이 각각의 애플리케이션을 소유하며 상위에서 전체를 관리해야 하는 경우
• 상위 레벨에서 거버넌스를 통제해야 하는 환경

ApplicationSet 리소스

ApplicationSet은 Argo CD가 공식 제공하는 Kubernetes CRD와 컨트롤러다. 반복되는 애플리케이션을 템플릿 기반으로 자동 생성할 수 있으며, 멀티 환경 및 멀티 클러스터 배포에 최적화되어 있다.

주요 개념:

• Generator: 어떤 애플리케이션을 생성할지 정의한다(예: 여러 디렉토리, 여러 클러스터).
• Template: 생성된 애플리케이션의 공통 구조를 정의한다.
• Git 저장소 구조와 Generator 설정이 핵심이다.

적합한 환경:

• 동일한 애플리케이션을 여러 클러스터나 환경에 배포해야 하는 경우
• Helm, Kustomize 등으로 배포 템플릿을 표준화한 환경
• 반복 정의를 최소화하고 싶은 경우

App of Apps와 ApplicationSet 비교

4. 하이브리드 구조로 완성한 실전 운영 전략

하이브리드 접근이 필요했던 이유

초기에는 App of Apps 패턴만으로도 충분했다. 하지만 여러 클러스터를 동시에 운영하고 서비스가 늘어나면서 한계가 드러났다. App of Apps만 사용하면 구조는 명확하지만 신규 서비스 추가 시마다 Application YAML을 직접 작성해야 한다. ApplicationSet만 사용하면 자동화는 강력하지만 서비스 카탈로그 관리에는 약하다.

우리는 이 두 방식의 한계를 다음과 같이 해결했다.

• 상위(루트 레벨): App of Apps 패턴으로 서비스 카탈로그 및 부트스트랩을 관리한다.
• 서비스/도메인: ApplicationSet 리소스로 반복되는 서비스 배포 패턴을 자동화한다.

매니페스트(Manifest) 구조

├── apps-serviceA.yaml       (루트 Application - service A 도메인)
├── apps-serviceB.yaml       (루트 Application - service B 도메인)
├── apps-serviceC.yaml       (루트 Application - service C 도메인)
│
├── _projects               (AppProject 정의 - RBAC/경계)
│   ├── Chart.yaml
│   ├── templates/applicationset.yaml
│   └── values.yaml
│
├── service A               (서비스별 ApplicationSet)
│   ├── Chart.yaml
│   ├── templates/applicationset.yaml
│   └── values.yaml
│
├── service B
│   ├── Chart.yaml
│   ├── templates/applicationset.yaml
│   └── values.yaml
│
├── service C
    ├── Chart.yaml
    ├── templates/applicationset.yaml
    └── values.yaml

구조적 특징:

• 루트 Application(apps-*.yaml): 서비스별 ApplicationSet을 호출하여 App of Apps 역할을 수행한다.
• 서비스별 ApplicationSet: 반복되는 애플리케이션을 자동 생성한다.
• AppProject(_projects): RBAC, 소스 리포지토리, 네임스페이스 범위 등을 강제하여 서비스 간 충돌을 방지한다.

도입 효과

5. 효율과 안정성, 두 마리 토끼를 잡은 여정

Kubernetes 환경에서 GitOps를 운영하며 Argo CD의 App of Apps 패턴과 ApplicationSet을 조합해온 과정을 공유했다. 단순히 자동화에 그치지 않고 서비스 일관성과 운영 효율성을 함께 고려한 구조를 만들어가는 여정이었다.

멀티 클러스터 환경에서 배포 복잡도가 증가할 때, 두 방식의 장점을 결합한 하이브리드 접근은 명확한 해답이 될 수 있다. 상위에서는 거버넌스를 유지하고, 하위에서는 반복을 자동화하는 구조는 확장성과 관리 편의성을 동시에 제공한다.

이 글이 GitOps 도입이나 멀티 클러스터 운영을 고민하는 분들께 실질적인 인사이트가 되길 바란다.