본문 바로가기
IT/k8s

[k8s] Helm 차트 관리의 진화: GitOps 시대의 베스트 프랙티스 분석

by 수누다 2026. 5. 23.

목차

안녕하세요, 13년차의 서버실입니다. 제가 처음 쿠버네티스(Kubernetes)를 접했을 때를 생각하면, 마치 새로운 대륙을 발견한 콜럼버스처럼 설레면서도 막막했던 기억이 나네요. 특히 애플리케이션 배포와 관리는 정말이지 끝없는 숙제 같았어요. 처음엔 kubectl apply -f 명령어로 YAML(야믈) 파일을 직접 하나하나 적용했었죠. 그러다 Helm(헬름, 쿠버네티스 패키지 매니저)을 만나고 나서야 비로소 숨통이 트이는 느낌이었습니다.

Helm은 복잡한 쿠버네티스 애플리케이션을 패키징하고 배포하는 데 정말 혁신적인 도구였어요. 그런데 시간이 지나고 관리해야 할 차트(Chart)가 늘어나면서, 또 다른 고민이 생기더라고요. '이 많은 차트들을 어떻게 효과적으로 관리하고, 배포 이력을 추적하며, 안정적으로 운영할 수 있을까?' 하는 문제였습니다. 수동으로 helm upgrade를 반복하는 건 실수 투성이였고, CI/CD(지속적 통합/지속적 배포) 파이프라인에 Helm 명령어를 넣는 것도 생각보다 손이 많이 갔거든요. ⚠️

그러던 와중에 GitOps(깃옵스, Git 기반 운영 방식)라는 개념을 접하게 됐습니다. '아, 이거다!' 싶었죠. 인프라와 애플리케이션의 상태를 Git 리포지토리(Repository)에 코드 형태로 정의하고, 이 Git을 유일한 진실의 원천(Single Source of Truth)으로 삼아 자동으로 클러스터 상태를 동기화하는 방식. 오늘은 이 GitOps 시대에 Helm 차트를 어떻게 하면 스마트하게 관리할 수 있는지, 제가 직접 홈랩에서 겪었던 경험과 함께 베스트 프랙티스(Best Practice)를 분석해 보려고 합니다. 여러분의 쿠버네티스 배포 여정에 이 글이 작은 등불이 되기를 바랍니다!

GitOps 기반 Helm 차트 관리 아키텍처 개요 다이어그램

GitOps 기반 Helm 차트 관리의 전체적인 아키텍처를 보여줍니다. 개발자가 Git에 변경사항을 푸시하면, GitOps 오퍼레이터(예: Flux CD)가 이를 감지하여 쿠버네티스 클러스터에 Helm 차트를 배포하는 흐름입니다.

Helm과 GitOps, 그 관계를 파헤치다

먼저 핵심 개념들을 잠시 짚고 넘어가 볼까요? 이미 잘 아시는 분도 많겠지만, 혹시 처음 접하는 분들을 위해 쉽게 설명해 드릴게요.

  • Helm (헬름): 쿠버네티스 패키지 매니저예요. 복잡한 애플리케이션을 차트(Chart)라는 패키지 형태로 정의하고, 이를 쉽게 설치, 업데이트, 삭제할 수 있도록 도와줍니다. 마치 리눅스의 apt나 yum처럼이죠. Deployment, Service, Ingress(인그레스, 외부 트래픽 진입점) 등 여러 쿠버네티스 리소스(Resource)들을 하나의 묶음으로 관리할 수 있게 해줘요.
  • GitOps (깃옵스): 쉽게 말해, Git을 중심으로 모든 것을 운영하는 방식입니다. 애플리케이션 코드뿐만 아니라, 인프라 구성(Infrastructure as Code)까지 전부 Git 리포지토리에 저장하고 관리합니다. 그리고 Git 리포지토리의 변경 사항이 감지되면, GitOps 에이전트(Agent)가 자동으로 쿠버네티스 클러스터에 배포하거나 상태를 동기화(Reconciliation)하는 구조예요. 사람이 직접 명령어를 입력할 필요 없이, Git에 커밋(Commit)만 하면 배포가 이뤄지는 거죠. 🎉

그럼 Helm과 GitOps가 만나면 어떤 시너지를 낼까요? 기존에는 Helm 명령어를 CI/CD 파이프라인에서 실행하거나, 개발자가 직접 터미널에서 입력해서 배포했었죠. 하지만 GitOps를 도입하면, Helm 차트의 설정 파일(values.yaml)이나 차트 자체의 버전 변경을 Git에 커밋하는 것만으로 배포가 자동으로 트리거(Trigger)됩니다. '선언적(Declarative)'으로 상태를 정의하고, '자동으로 동기화(Automated Synchronization)'되는 거죠. 이 덕분에 배포의 투명성, 안정성, 감사(Audit) 용이성이 크게 향상됩니다. 제가 직접 해보니, 이게 진짜 편하더라고요!

실전! GitOps 기반 Helm 차트 관리 구현: Flux CD를 중심으로

홈랩에서 다양한 GitOps 툴을 실험해 봤는데, 개인적으로는 Flux CD(플럭스 CD)가 Helm 차트 관리에 참 잘 맞았어요. 물론 Argo CD(아르고 CD)도 훌륭한 대안이고요. 오늘은 Flux CD를 활용해서 GitOps 기반 Helm 차트 관리 환경을 구축하는 방법을 단계별로 설명해 드릴게요. 따라오시면 여러분도 쉽게 구현하실 수 있을 겁니다.

  1. Flux CD 설치 및 초기 설정 
    
# Flux CLI 설치 (macOS 기준, 다른 OS는 공식 문서 참고)
brew install fluxcd/tap/flux

# Flux CD 초기화 및 Git 리포지토리 연동
# 여기서 your-git-repo는 GitOps 설정을 저장할 리포지토리 주소입니다.
# --branch main은 기본 브랜치를 main으로 설정하는 것이고요.
# --path clusters/my-cluster는 Flux가 모니터링할 Git 리포지토리 내 경로입니다.
flux bootstrap git \
  --owner=<your-git-username> \
  --repository=<your-git-repo> \
  --branch=main \
  --path=clusters/my-cluster \
  --personal
    위 명령어를 실행하면 Flux CD가 필요한 컨트롤러(Controller)들을 쿠버네티스 클러스터에 설치하고, 지정된 Git 리포지토리와 연동합니다. 이제 Git 리포지토리 clusters/my-cluster 경로에 변경 사항이 생기면 Flux CD가 자동으로 감지하게 됩니다. ✅
  2. 먼저 쿠버네티스 클러스터(Cluster)에 Flux CD를 설치해야 합니다. Flux CLI(커맨드 라인 인터페이스)를 사용하면 정말 쉽게 설치할 수 있어요.
  3. Git 리포지토리 구조 잡기 
    
.
├── clusters/
│   └── my-cluster/ # Flux CD가 모니터링할 경로
│       ├── flux-system/ # Flux CD가 생성한 리소스 (자동 관리)
│       └── applications/ # 배포할 애플리케이션 HelmRelease 정의
│           ├── nginx/
│           │   └── nginx-helmrelease.yaml
│           └── prometheus/
│               └── prometheus-helmrelease.yaml
└── helm-charts/ # 직접 만든 Helm 차트 (선택 사항, 외부 차트 사용 시 필요 없음)
    └── my-app/
        ├── Chart.yaml
        ├── values.yaml
        └── templates/
            └── ...
  4. GitOps의 핵심은 Git 리포지토리 구조를 잘 잡는 것입니다. 저는 보통 이런 식으로 구성합니다.
  5. Helm 차트 정의 및 배포 (HelmRepository, HelmRelease)먼저 Helm 차트 저장소(Repository)를 정의합니다. Nginx Ingress Controller의 공식 Helm 저장소를 추가하는 HelmRepository 리소스입니다.이 파일을 Git 리포지토리의 clusters/my-cluster/applications/nginx/ 경로에 저장하고 커밋(Commit)하면, Flux CD가 이를 감지하여 쿠버네티스 클러스터에 HelmRepository 리소스를 생성합니다. Flux CD는 이 저장소를 주기적으로 스캔하여 최신 차트 정보를 가져오게 됩니다. 💡Flux CD가 Git 리포토리의 HelmRelease 정의를 읽어 쿠버네티스 클러스터에 Helm 차트를 배포하는 과정을 시각화한 다이어그램입니다. 
    
# clusters/my-cluster/applications/nginx/nginx-helmrelease.yaml
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: ingress-nginx
  namespace: ingress-nginx # Nginx Ingress Controller가 배포될 네임스페이스
spec:
  interval: 5m0s # 5분마다 상태 동기화 확인
  chart:
    spec:
      chart: ingress-nginx # HelmRepository에 정의된 차트 이름
      version: ">=4.0.0 <5.0.0" # 차트 버전 범위 지정
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx # 위에서 정의한 HelmRepository 이름
        namespace: flux-system
  values: # values.yaml 내용과 동일
    controller:
      replicaCount: 2
      service:
        type: LoadBalancer
      nodeSelector:
        kubernetes.io/os: linux
    defaultBackend:
      enabled: true
    이 파일도 Git 리포지토리에 저장하고 커밋하면, Flux CD는 HelmRepository에서 차트를 가져와 이 HelmRelease 정의에 따라 Nginx Ingress Controller를 클러스터에 배포하게 됩니다. 와, 정말 깔끔하게 배포되는 거 보니까 속이 다 시원하더라고요! 이제 배포에 대한 모든 변경사항은 Git에서만 이뤄지게 됩니다. 🚀
  6. 다음으로, 실제로 Nginx Ingress Controller를 배포할 HelmRelease 리소스를 정의합니다. 여기에 어떤 차트를 어떤 버전으로, 어떤 값(values)으로 배포할지 상세하게 명시합니다.
  7. Flux CD HelmRelease를 이용한 쿠버네티스 차트 배포 흐름
  8. # clusters/my-cluster/applications/nginx/nginx-helmrepository.yaml apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: ingress-nginx namespace: flux-system # Flux CD 시스템 네임스페이스 spec: interval: 1h0m0s # 1시간마다 저장소 업데이트 확인 url: https://kubernetes.github.io/ingress-nginx
  9. 이제 애플리케이션을 배포해 볼까요? 예를 들어, 안정적인 Nginx(엔진엑스) Ingress Controller(인그레스 컨트롤러)를 배포한다고 가정해 봅시다. Flux CD에서는 HelmRepository와 HelmRelease라는 커스텀 리소스(Custom Resource)를 사용합니다.

삽질 대잔치! 겪었던 문제와 해결 과정

물론 이렇게 깔끔하게 설명했지만, 제가 이걸 처음 세팅할 때는 삽질 좀 했습니다 ㅎㅎ. 특히 몇 가지 문제로 머리를 싸맸던 기억이 나네요. 여러분은 저 같은 실수 하지 마시라고 몇 가지 팁을 공유해 드립니다. ⚠️

  • HelmRelease 동기화 실패:처음에는 Git에 커밋했는데도 클러스터에 아무런 변화가 없어서 당황했어요. 알고 보니 HelmRepository의 interval이나 HelmRelease의 interval 설정이 너무 길거나, Git 리포지토리 경로를 잘못 지정한 경우가 많았습니다. Flux CD의 로그를 꼼꼼히 확인하고, flux reconcile kustomization <kustomization-name> 명령어로 수동 동기화를 시도하면서 문제를 찾아냈습니다.
  • # Flux CD Kustomization 상태 확인 (Git 리포지토리 동기화 상태) flux get kustomizations # Flux CD HelmRelease 상태 확인 flux get hr -A # 모든 네임스페이스의 HelmRelease 확인
  • imagePullSecrets 적용 문제:프라이빗 레지스트리(Private Registry)에 있는 이미지를 사용해야 할 때, imagePullSecrets(이미지 풀 시크릿)을 ServiceAccount(서비스 어카운트)에 연결해야 하잖아요? 이걸 HelmRelease의 values에 직접 넣어도 되지만, 보안상 좋지 않거나 모든 ServiceAccount에 적용하고 싶을 때가 있습니다. 이럴 땐 Kustomize(커스터마이즈)를 활용하여 ServiceAccount에 imagePullSecrets를 패치(Patch)하는 방식으로 해결했습니다. Flux CD는 Kustomization 리소스도 지원해서, Helm과 Kustomize를 함께 사용하는 것도 가능합니다. (이건 다음 기회에 더 자세히 다뤄볼게요!)
  • 차트 버전 범위 지정 오류:HelmRelease에서 version: ">=4.0.0 <5.0.0"처럼 버전을 지정할 때, 세밀하게 지정하지 않으면 예상치 못한 마이너 버전 업데이트로 인해 문제가 생길 수 있습니다. 너무 넓은 범위보다는 안정성이 검증된 특정 버전이나, 패치 버전까지만 허용하는 것이 좋습니다.

드디어! GitOps로 배포된 Helm 차트 확인

이제 모든 설정이 완료되고 Git에 커밋까지 했다면, Flux CD가 자동으로 배포를 진행했을 겁니다. 배포가 제대로 되었는지 확인해 봐야겠죠? kubectl 명령어로 확인하면 됩니다.


# Flux CD가 관리하는 Kustomization 리소스 상태 확인
kubectl get kustomizations -n flux-system

# Flux CD가 관리하는 HelmRelease 리소스 상태 확인
kubectl get helmreleases -n ingress-nginx

# Nginx Ingress Controller 파드(Pod) 확인
kubectl get pods -n ingress-nginx

helmreleases의 상태가 Ready이고, pods가 모두 Running 상태라면 성공입니다! 🎉 정말 깔끔하게 배포된 걸 보니까 속이 다 시원하더라고요. 이제 어떤 변경이든 Git 리포지토리에 반영하는 것만으로 배포가 자동으로 이뤄집니다. 롤백(Rollback)도 Git에서 이전 커밋으로 되돌리는 것만으로 가능하니, 얼마나 안정적이고 편리한지 몰라요.

Kubernetes 클러스터에서 kubectl 명령어를 사용하여 Flux CD의 HelmRelease와 관련된 리소스들이 성공적으로 배포되고 실행 중인 상태를 보여주는 터미널 화면입니다.

마무리하며: Helm GitOps, 더 나은 미래를 향해

오늘은 13년차 인프라 엔지니어의 시선으로 Helm 차트 관리의 진화, 특히 GitOps 시대의 베스트 프랙티스를 Flux CD를 중심으로 알아봤습니다. 제가 직접 경험해 보니 GitOps는 단순히 도구를 사용하는 것을 넘어, 인프라 운영 방식 자체를 혁신하는 패러다임(Paradigm)이라는 생각이 들었습니다.

GitOps 기반 Helm 차트 관리는 다음과 같은 장점들을 가져다줍니다.

  • 생산성 향상: 수동 작업 감소, 자동화된 배포.
  • 안정성 증대: Git을 통한 단일 진실의 원천, 쉬운 롤백.
  • 투명성 및 감사 용이성: 모든 변경 이력이 Git에 기록.
  • 협업 강화: 코드 리뷰(Code Review)를 통한 변경 사항 검증.
전통적인 Helm 관리 방식과 GitOps 기반 Helm 관리 방식 비교표

전통적인 Helm 관리 방식과 GitOps 기반 Helm 관리 방식을 주요 특징(자동화, 롤백, 투명성 등)별로 비교하는 인포그래픽 형태의 표입니다.

물론 GitOps를 도입하는 것이 마냥 쉽지만은 않습니다. 초기 설정의 복잡성, Git 리포지토리 관리 전략 수립, 그리고 팀원들의 새로운 워크플로우(Workflow) 적응 등 넘어야 할 산들이 분명히 존재합니다. 하지만 그 모든 노력을 감수할 만큼의 가치가 충분하다고 저는 확신합니다. 결국 GitOps는 인프라 운영의 투명성과 안정성을 극대화하고, 개발팀과 운영팀 간의 협업을 더욱 매끄럽게 만드는 데 크게 기여할 겁니다.

다음 글에서는 Flux CD의 고급 기능이나 다른 GitOps 툴인 Argo CD(아르고 CD)와의 비교, 또는 Kustomize를 활용한 Helm 차트 오버레이(Overlay) 방법에 대해서도 다뤄볼 예정입니다. 계속해서 "13년차의 서버실"에 많은 관심 부탁드립니다. 궁금한 점이나 여러분의 경험담이 있다면 댓글로 남겨주세요! 함께 고민하고 성장해 나가는 것이 저의 기쁨입니다. 😊

'IT > k8s' 카테고리의 다른 글

[k8s] K3s와 AWX 통합 사례 연구: 경량 Kubernetes 자동화 워크플로우 구축  (0) 2026.05.24
[k8s] Kubernetes Operator 활용 사례: 데이터베이스 관리 자동화로 운영 효율 높이기  (0) 2026.05.23
[k8s] AWX로 쿠버네티스 워크플로우 자동화: 실전 가이드  (0) 2026.05.21
[k8s] 쿠버네티스 스토리지: CSI 드라이버를 활용한 영구 스토리지 관리 및 최적화  (0) 2026.05.20
[k8s] ArgoCD로 멀티 클러스터 GitOps 배포 자동화 완벽 가이드  (0) 2026.05.20
[k8s] 쿠버네티스 Ingress Controller 비교: Nginx, Traefik, HAProxy 장단점 분석  (0) 2026.05.18

관련글

티스토리툴바