Argocd - GitOps 활용하기(App of Apps 패턴)

개요

2026.01.03 - [Devops] - Argocd - Application CR 이해하기

 

지난 글에서는 Argo CD의 기본 단위인 Application CR을 중심으로, Application이 어떤 스펙(source/destination/project 등)으로 구성되고 Argo CD가 이를 기반으로 리소스를 관리·동기화하는 동작원리를 정리했습니다.

 

하지만 운영 단계로 넘어가면 Application을 서비스/환경 단위로 늘려야 하고, 그 과정에서 Application YAML 자체를 사람이 수동으로 생성·수정·적용하는 흐름이 자주 발생합니다. 이 방식은 “배포 정의가 Git에 존재하고, 클러스터 변경은 Git 변경을 통해 재현된다”는 GitOps 관점에서 Application 정의의 확장/일관성/재현성을 유지하기가 어렵습니다.

 

이 글에서는 Application도 Git에서 선언적으로 관리할 수 있도록 구성하는 패턴 중 하나인 App of Apps를 다룹니다.

 

App of Apps 패턴이란 무엇인가?

 

App-of-Apps 패턴을 잘 보여주는 사진이라고 생각하며 Application을 배포할 때의 문제점을 개선한 디자인 패턴이라고 할 수 있습니다.

 

App of Apps는 “Application이 또 다른 Application들을 쿠버네티스 리소스로서 생성·관리하도록 구성”하는 패턴입니다.

 

부모(Root) Application의 배포 대상(Target)이 워크로드(Deployment/Service)가 아니라, 자식(Child) Application CR들의 매니페스트가 됩니다.

 

개발자는 Root Application을 배포하고 그 Root Application이 앱들을 배포하는 소스들을 가리키고 자식(Child) Applications들은 실제 배포 대상(desired deploy resource)들을 가리켜 배포하게 되는 구조라고 할 수 있습니다.

Application이 모니터링하고 배포하는 대상이 실제 리소스들로만 구성되는 것이 아니라 Applications 그 자체를 대상으로 할 수 있으며 배포 대상을 확장했다는 것에 의의를 둘 수 있는 패턴입니다.

 

App-of-Apps 패턴의 구조

• Root Application
  • 리소스들을 가리키는 Child Application YAML 들이 관리되고 있는 디렉터리(혹은 헬름 차트)를 spec.source로 가리킵니다.
  • Root Application 하나만 존재하며 spec.source의 경로엔 실제 배포 대상이 아니라 Application YAML 명세만 존재해야 합니다.
  • 배포하는 Applications들의 Destination은 모두 동일한 네임스페이스로 배포해 관리합니다.
• Child Applications
  
  • 각 Application 마다 배포하려는 대상의 소스 경로 즉 spec.source가 다르며 배포 대상 destination이 다를 수 있습니다.
  • ArgoCD가 Application을 배포 대상으로 관리하기 때문에 하단의 사진과 같이 각각 Application마다 Sync/Health를 추적하게 됩니다.
• 하단과 같이 App of Apps는 UI를 통해 확인이 가능하며 Application이 Application을 가리켜 배포한다는 특수성 때문인지 UI에서도 Root App의 관리 대상의 화면에서 개별적인 App을 빨간 박스의 버튼을 눌러 접속이 가능합니다.
  • 자식 Application의 git에 선언된 대로 배포가 됐는지의 여부는 표시된 칸처럼 확인이 되지만 실제 리소스의 배포 상태 여부는 개별 Application에 접속하여 확인해야 함을 유의해야 합니다.

 

App-of-Apps의 동작 흐름

• Parent Application이 Git에서 “Child Application 매니페스트들”을 읽습니다.
• Parent를 Sync하면, 클러스터에 Child Application CR들이 생성/갱신됩니다.
• 생성된 Child Application들은 각각 자신의 Source를 기준으로 워크로드를 Sync 합니다.

이 구조 덕분에 “애플리케이션 목록 자체 즉 Application”도 Git으로 선언적으로 관리됩니다.

 

App-of-Apps의 구조 예시

실제 배포하려는 App들이 git으로 관리된다는 가정하에 폴더 구조는 배포하려는 Application들을 폴더 구조로 모아놓는 형태가 되며 깊이는 각자의 App을 묶으려는 성격상 더 깊어질 수 있지만 전체적인 구조는 이와 같습니다.

ArgoCD/
└── RootApplication/
    ├── root-app.yaml          # Parent Application
    apps/                  # Parent가 바라보는 디렉터리
      ├── monitoring.yaml    # Child Application (ex. grafana/loki/tempo)
      ├── ingress.yaml       # Child Application
      └── platform.yaml      # Child Application

 

Application 스펙의 일부만 가져왔으며 source경로는 App이 모여있는 경로를 가리키며 일반적인 App을 작성하는 것과 똑같습니다.

 source:
    path: ArgoCD/apps
    repoURL: <git>
    targetRevision: main

 

App-of-Apps의 장점

1. Application(Child)까지 Git에서 선언적으로 관리
   • App of Apps는 “하나의 Argo CD Application이 다른 Application들을 포함하도록 선언”하는 방식이라, 워크로드 리소스뿐 아니라 Application 목록/구성 자체도 Git 변경으로 관리됩니다. (Application도 GitOps로 관리)
2. Root Application 1회 생성 이후, 확장은 “Git 커밋”으로 표준화
   • 개발자는 Root Application 만 한 번 생성해 두면 배포할 자식 App들은 UI/CLI로 수동으로 반복해 생성/오류를 겪을 일 없이 Git 선언 + Sync 흐름으로 자동화하게 됩니다.
3. 배포에서의 유지보수 및 재현성 확보
   • 새로운 클러스터에 동일한 형상을 배포하여 한번에 설치해야 할 때, 혹은 개발 환경에서 배포 테스트를 진행해야 한 경우 및 테스트를 한 배포 구조를 타 환경으로 적용할 때에 App of Apps는 Root App 1개를 기준으로 동일한 배포 세트를 선언적으로 재현하는 것을 가능하게 해 줍니다.

 한번의한 번의 App은 수동으로 배포해야 자동화가 이뤄지며 이 한 번의 App을 배포하는 것도 귀찮음을 유발하게 된다면 IAC툴과 함께 자동화로 처리하여 더 나은 자동화를 만들 수 있고 Application을 관리하는 복잡성과 피곤함을 해결해 주는 해결사처럼 보이기도 합니다.

App-of-Apps의 한계

App-of-Apps는 보기좋은 장점과 달리 한계도 명확하며 그 한계를 설명드리겠습니다.

1. 모든 환경에 Root Application을 반드시 한 번은 배포해야만 하고 멀티 클러스터를 ArgoCD로 관리하는 분이라면 각 클러스터 용 Root App을 하나씩 배포해야 한다는 한계가 존재합니다.
   • Root Application을 배포한다고 모든 환경, 모든 클러스터에 자동화 배포가 가능하지 않고 각 환경마다 일일이 Application을 배포해야 하며 IAC로 자동화한다고 하더라도 이는 분명한 한계로 존재합니다.
2. 환경이 늘어날 수록 Application들 또한 반복적으로 작성해야 하며 spec.source, destination, cluster만 변경됨에도 불구 불필요한 보일러 플레이트 코드를 작성해야 합니다.
   • Helm 같은 템플릿 엔진이나 Go 언어를 활용한 ApplicationSet을 사용하지 않는다면 보일러 플레이트 늪에 빠질 수 있습니다.
3. 장애 대처
   • Root가 Child Application CR을 생성/갱신하는 단계에서 막히는 케이스이고 Application YAML에 필드 오타/스펙 오류가 있으면, Root Sync 자체가 실패하거나 Child 생성이 꼬여서 “배포 파이프라인(앱 생성 단계)”이 멈춘 상태가 됩니다.
     • 이럴 땐 로그 등으로 디버깅도 되지 않으며 실패한 이유를 찾을 수 없는 상황이 명확한 한계라고 할 수 있습니다.

정리/회고

ArgoCD에서 Application을 배포할 때의 단점을 해결하고 GitOps에 맞게 배포하게 만들어주는 App of Apps 패턴에 대해 정리했습니다.

 

ArgoCD를 사용할 때 App of Apps를 적용하는 건 처음 이해하기가 어려울 수 있지만 러닝 커브가 크지 않아 쉽고 빠르게 Application의 GitOps를 달성해 주는 패턴이라고 할 수 있습니다.

 

App of Apps는 상기 써놓은 것과 같이 좋은 장점도 많지만 명확한 한계들도 분명하게 존재하며 이 때문에 저는 현재 App of Apps는 사용하고 있지 않습니다.

• 보일러 플레이트 코드의 늪에 빠진다거나, 멀티 클러스터 환경에 자동화된 배포가 가능하지 않다거나 하는 등이 그러합니다.

App of Apps는 어디까지나 GitOps를 할 수 있게 Application을 기존 ArgoCD의 배포흐름에 맞춘 것이기 때문에 그러하며 이를 극복한 ApplicationSet이란 Controller와 CR이 존재하고 이것을 사용하는 것을 권장하기는 합니다.

 

하지만 App of Apps는 App 배포 또한 GitOps에 맞게 배포한다는 철학을 배우고 쉽게 적용할 수 있고 기존의 템플릿 엔진과도 연동이 가능하기 때문에 처음부터 적용하기 어려운 ApplicationSet을 사용하는 것보단 명확한 장점을 느끼고 한계를 느낀다면 이후에 넘어가는 것이 어떤가 생각하고는 합니다.

 

지금까지 읽어주셔서 감사하며 다음엔 ApplicationSet 소개와 적용에 관련된 글과 함께 돌아오겠습니다.