ArgoCD ApplicationSet 도입기

안녕하세요! 오늘은 최근 사내 배포 파이프라인을 고도화하며 겪은 경험을 공유해 보려고 합니다.

DevOps 엔지니어로서 가장 고민되는 지점은 언제나 “어떻게 하면 개발자들이 인프라를 몰라도 편하게 배포할 수 있을까?” 인 것 같습니다. 기존에 우리는 ArgoCD의 App of Apps 패턴을 사용하고 있었는데, 유연성은 좋았지만 서비스가 늘어날수록 관리 포인트가 비대해지는 문제가 있었습니다.

이를 해결하기 위해 ApplicationSet을 도입했고, 그 결과 “폴더만 만들면 배포가 끝나는” 마법 같은 환경을 구축하게 되었습니다. 그 과정을 정리해 봅니다.

---

1. 왜 바꾸게 되었나? (Background)

기존 App of Apps 방식은 훌륭했지만, 치명적인 귀찮음(?)이 존재했습니다. 새로운 애플리케이션을 하나 추가하려면, 개발자가 애플리케이션 코드를 짜는 것 외에도 ArgoCD용 Manifest 파일을 또 작성해야 했기 때문이죠.

😫 기존의 문제점:

• 반복 작업(Boilerplate): 서비스 A, B, C… 설정이 거의 비슷한데도 매번 Manifest를 복사/붙여넣기 해야 함.
• 높은 진입장벽: 개발자가 Kubernetes나 ArgoCD의 CRD 설정을 어느 정도 이해해야 함.
• 표준화의 어려움: 누구는 A 방식으로, 누구는 B 방식으로 차트를 참조하여 파편화 발생.

💡 우리의 목표:

“개발자는 values.yaml만 작성해라. 나머지는 우리가 알아서 할게.”

---

2. 무엇이 달라졌나요?

가장 큰 변화는 ‘자동화’와 ‘관심사의 분리’입니다.

구분	기존 (App of Apps)	변경 후 (ApplicationSet)
새 앱 추가	Application Manifest 파일 직접 작성	폴더 생성 및 values.yaml 추가만 하면 끝
작동 원리	수동 설정	Git 디렉토리 자동 감지 (Generator)
관리 포인트	ArgoCD 설정 + Helm 설정	Helm Values 설정 (집중)
유지보수	템플릿 변경 시 모든 앱 수정 필요	템플릿 하나만 수정하면 일괄 적용

이제 개발자는 더 이상 “ArgoCD에 애플리케이션 등록해주세요”라고 요청하거나, 복잡한 YAML 파일을 건드릴 필요가 없습니다.

---

3. 개발자 경험(DX)을 위한 3가지 패턴

ApplicationSet을 도입하면서 가장 공을 들인 부분은 표준화입니다. 무조건 자동화만 한다고 능사는 아니니까요. 서비스의 성격에 따라 딱 3가지 패턴만 기억하면 되도록 구조를 잡았습니다.

새로운 구조는 application-set/ 디렉토리 하위에 폴더를 만드는 것만으로 작동합니다.

application-set/
├── <namespace> (예: product)
│   └── <app-name> (예: user-service)
│       ├── chart/   (📌 패턴 3 사용 시에만 생성)
│       └── values/
│           ├── common-values.yaml
│           └── gke-dev-values.yaml

✅ Pattern 1. 공통 표준 차트 (Spring Boot 등)

대부분의 백엔드 서비스는 이 패턴을 따릅니다. 사내에서 미리 정의해 둔 springboot-docker 공용 차트를 가져다 쓰기만 하면 됩니다. chart 폴더도 필요 없습니다.

설정 예시 (values.yaml):

# 우리 회사 표준 차트를 쓸게요!
chartConfig:
  path: springboot-docker/springboot-docker 

✅ Pattern 2. 외부 오픈소스 차트

Redis, Jenkins 처럼 Docker Hub나 공식 Helm 저장소에 있는 차트를 그대로 배포해야 할 때 사용합니다.

설정 예시 (values.yaml):

# 젠킨스 공식 차트를 쓸게요!
chartConfig:
  repoURL: [https://charts.jenkins.io](https://charts.jenkins.io)
  chart: jenkins
  targetRevision: 4.3.23

✅ Pattern 3. 커스텀 차트 (Custom)

Frontend 앱이나 StatefulSet 처럼 표준 차트로 해결이 안 되는 특수한 경우입니다. 이때는 chart/ 폴더를 직접 만들어서 그 안에 차트 파일을 넣으면 시스템이 자동으로 로컬 차트를 인식합니다.

---

4. 환경별 설정 관리

ApplicationSet Generator가 파일 이름을 보고 자동으로 환경(Dev/Prod)을 매핑하도록 네이밍 규칙을 정했습니다. 이 규칙만 지키면 실수로 운영 환경에 개발 설정을 덮어씌울 일이 사라집니다.

• common-values.yaml: 모든 환경에 공통으로 들어가는 값 (포트 번호, 헬스 체크 경로 등)
• <cluster>-<env>-values.yaml: 특정 환경 전용 값 (도메인 주소, 레플리카 수 등)
  • 예: eks-dev-values.yaml, gke-prod-values.yaml

---

5. 마치며

이번 ApplicationSet 도입을 통해 운영 리소스를 줄이고, 배포 복잡도를 덜어내는 Win-Win 구조를 만들 수 있었습니다.

처음에는 구조를 잡고 Generator 규칙을 만드는 게 조금 복잡했지만, 한번 구축해 두고 나니 “폴더 하나 만들었을 뿐인데 배포 파이프라인이 생기는” 경험이 정말 짜릿했습니다. 😄

혹시 ArgoCD를 사용하면서 비슷한 고민을 하고 계신 분들이 있다면, ApplicationSet 도입을 강력하게 추천드립니다! 더 자세한 코드가 궁금하다면 언제든 댓글로 남겨주세요.