GitOps 구조는 어떻게 진화해왔을까 – 멀티리전 배포를 가능하게 만든 선택들

Context

기존 배포 시스템에서 운영 중인 서비스의 현재 상태를 정확히 파악할 수 없었고, Jenkins와 Argo CD 설정이 EC2 내부에 분산되어 있어 배포 이력 추적이 불가능했다. Argo CD가 장애 나면 현재 배포 상태를 알 수 없었고, 롤백 시 과거 이미지를 새로 빌드해야 했다. 글로벌 서비스 확장 과정에서 멀티리전 배포 관리가 필요해지자 단순 복사-붙여넣기 방식으로는 구조적 한계에 직면했다.

Technical Solution

• GitOps 체계 구축: Argo CD 업그레이드 + GitHub Actions 도입으로 배포 상태를 Git 저장소를 단일 진실 공급원으로 관리
• 저장소 구조 표준화: bootstrap(Argo CD 초기 설정), products(ApplicationSet), charts(공통 Helm Chart), applications(서비스별 배포 설정)으로 디렉토리 정리
• Helm + Kustomize 조합: 공통 설정은 Helm Chart로 관리하고 서비스별 특이사항만 Kustomize로 커스터마이징 (예: NGINX 설정)
• 구조적 전환을 통한 멀티리전 단순화: 리전별 다른 점을 values.yaml 파일로만 관리(기본값 + 리전별 추가 설정)하고 Kustomize patch 제거
• ArgoCD Matrix Generator 도입: 메타 파일에서 서비스별 리전 배포 정책을 선언하면 자동으로 서비스 × 리전 조합 생성 (예: 서비스 A는 한국·일본·미국 배포, 서비스 B는 한국·미국만)

Impact

수치 형태의 정량적 영향은 아티클에 명시되지 않음.

Key Takeaway

구조적 설계가 확장성을 결정한다는 것을 실증했다. 멀티리전 도입 시 기존의 Kustomize patch 기반 설계에서 Helm values 기반 설계로 전환함으로써 새 리전 추가 시 모든 서비스 디렉토리를 복사할 필요 없이 메타 파일 수정만으로 자동 배포가 가능해졌다.