GitOps 배포를 두려워하지 않기 위한 작은 자동화

Context

초기 GitOps 구성에서 모든 서비스가 Git 저장소 메인 브랜치의 단일 Helm Chart 디렉토리(helmGlobals.chartHome: ../../../../charts)를 참조했기 때문에, Chart 변경 시 강남언니의 모든 서비스가 동시에 영향받았다. 이로 인해 작은 변경도 심각한 버그를 초래할 수 있어 배포 시마다 높은 심리적 부담과 리뷰 부담이 발생했다.

Technical Solution

• Helm Chart 저장소 구축: ChartMuseum을 쿠버네티스 환경에 설치하고 AWS S3를 백엔드 스토리지로 구성하여 서비스별 버전 명시 가능하게 변경 (helmGlobals 제거 → repo + version 필드 추가)
• Release Please를 통한 자동 릴리즈 관리: Conventional Commit 규칙 기반으로 커밋 메시지 헤더에 따라 자동 버전 관리 (feat → 마이너, fix → 패치, feat! → 메이저 버전)
• CHANGELOG.md 자동 생성: Release Please가 GitHub Actions를 통해 릴리즈 PR 병합 시 Git 태그 생성, Chart.yaml 버전 업데이트, 변경사항 기록을 자동화
• 애플리케이션 배포 CI 자동화: GitHub Actions에서 values.yaml과 Helm Chart 변경 PR에 대해 kustomize build 결과물을 이전·이후 버전으로 각각 생성 후 dyff 도구로 의미있는 차이만 비교하여 PR 커멘트로 자동 등록
• dyff를 통한 의미론적 차이 비교: 리소스 순서 변경이나 환경변수 배열 순서 차이 같은 의미없는 변경은 제외하고 실질적 Kubernetes 리소스 변화만 식별

Impact

• 배포 PR의 평균 리뷰 시간: 10분 → 1분으로 감소
• Helm Chart 변경으로 인한 운영 환경 배포 실패: 월 1-2회 → 0회로 감소

Key Takeaway

GitOps 환경에서 Helm Chart를 중앙집중식 디렉토리 참조에서 버저닝된 저장소로 전환하고, 배포 PR에 자동화된 Manifest 차이 분석을 추가하면 서비스 간 독립적 업그레이드와 빠른 리뷰 판단이 가능해진다. 작은 자동화가 플랫폼 엔지니어의 심리적 부담과 개발자의 리뷰 비용을 동시에 해결할 수 있다.