ArgoCD ApplicationSet 도입기
jay
안녕하세요! 오늘은 최근 사내 배포 파이프라인을 고도화하며 겪은 경험을 공유해 보려고 합니다.
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 도입을 강력하게 추천드립니다! 더 자세한 코드가 궁금하다면 언제든 댓글로 남겨주세요.