개발자든 운영자든 한 번쯤은 고민해봤을 겁니다. “Kubernetes 배포, 매번 이렇게 수동으로 해도 되는 걸까?” Helm 차트는 그 질문에 ‘이제 그만 힘들어하라’고 말해주는 자동화 마법 도구입니다. 하나의 YAML로 수십 개의 리소스를 관리하고, 환경별 설정도 간편하게 나눌 수 있죠. 이 포스팅에서는 Helm 차트 작성법을 단순한 매뉴얼이 아닌, 실제 사용 경험과 실무 노하우를 바탕으로 쉽게 풀어드립니다. 설정 실수로 새벽에 알람받고 깬 적 있다면 꼭 끝까지 읽어보세요.
- 헬름 차트의 구조와 역할을 이해하면 배포가 두렵지 않다 – helm create 명령어로 자동 생성되는 디렉토리 구조는 처음 보는 사람도 쉽게 적응할 수 있다.
- values.yaml을 중심으로 한 템플릿화가 핵심 – 변수화된 템플릿 구조 덕분에 환경별 설정도 걱정 없다.
- 의존성 관리로 복합 애플리케이션도 문제없다 – DB나 Redis처럼 별도 리소스를 함께 배포할 수 있어 편하다.
- 민감 정보는 Helm Secrets로 암호화 – values.yaml에 비밀번호 적지 마세요, Git에 노출됩니다.
- 환경별 설정 파일로 테스트 환경과 실서비스 환경을 분리 – dev, stage, prod 등 설정을 나눠서 실수 없는 배포를 구현한다.
- 업그레이드와 롤백이 쉬운 릴리즈 관리 – helm upgrade, helm rollback 명령으로 자유자재로 되돌릴 수 있다.
- CI/CD 파이프라인과 연계로 자동 배포까지 – GitHub Actions나 Argo CD와의 연계는 현대적 DevOps의 정수다.
- 실무 팁으로 품질과 안정성을 높이자 – helm lint, dry-run, _helpers.tpl의 효율적인 사용이 차이를 만든다.
헬름 차트 구조 이해: 이걸 알면 반은 먹고 들어간다
처음 Helm을 다룰 때 helm create mychart 명령어를 입력하면, 디렉토리 구조가 자동으로 생성됩니다. 이 구조는 Helm 차트를 작성하는 데 필요한 최소한의 틀을 제공합니다. 주요 파일은 아래와 같습니다.
| 파일/폴더 | 설명 |
|---|---|
| Chart.yaml | 차트 메타 정보(이름, 버전, 설명 등) |
| values.yaml | 배포 시 변경 가능한 값들의 기본 설정 파일 |
| templates/ | 쿠버네티스 매니페스트 템플릿 (deployment, service 등) |
| _helpers.tpl | 템플릿 내 공통 변수 및 함수 정의 |
처음엔 템플릿 파일 내 {{ .Values.image.repository }} 같은 문법이 생소할 수 있지만, 결국 모든 것은 values.yaml에 정의된 값을 끌어다 쓰는 구조입니다. 복잡해 보이지만, 익숙해지면 자유자재로 리소스를 조합할 수 있죠.
values.yaml을 제대로 활용하면 유지보수도 쉬워진다
values.yaml은 헬름 차트의 핵심입니다. 여기서 설정한 값이 템플릿 곳곳에서 사용되는데요, 예를 들어:
replicaCount: 3 image: repository: myapp tag: v1
이 값은 deployment.yaml 템플릿에서 이렇게 참조됩니다:
replicas: {{ .Values.replicaCount }}
image:
name: {{ .Values.image.repository }}
tag: {{ .Values.image.tag }}
환경마다 레플리카 수나 이미지 태그가 달라져야 한다면 values 파일을 환경별로 분리하면 됩니다. helm install -f dev-values.yaml 형식으로 말이죠.
의존성 관리로 복합 시스템도 한 방에 배포
우리 앱이 PostgreSQL 데이터베이스를 필요로 한다면 어떻게 할까요? Chart.yaml의 dependencies 항목에 서브차트를 추가해줍니다.
dependencies:
- name: postgresql
version: 11.6.17
repository: "https://charts.bitnami.com/bitnami"
그 다음 helm dependency update 명령어로 필요한 차트를 받아오면 됩니다. 이렇게 하면 DB와 애플리케이션이 동시에 배포되죠.
비밀번호는 절대 평문으로 넣지 마세요
보안은 항상 중요합니다. values.yaml에 민감한 정보를 직접 쓰는 건 지양해야 하죠. Helm Secrets 플러그인을 사용하면 values 파일을 SOPS로 암호화할 수 있습니다.
암호화된 파일은 Git에 안전하게 커밋할 수 있고, 배포 시 helm-secrets 명령으로 자동 복호화됩니다. 실제 운영 환경에서는 필수입니다.
dev/prod 환경 설정 분리로 실수 방지
개발환경과 운영환경은 설정이 크게 다릅니다. 예를 들어, 운영환경에선 레플리카 수를 5개로 늘리고 로깅도 강화해야 하죠. 이를 위해 아래처럼 환경별 values 파일을 나눕니다.
- dev-values.yaml
- prod-values.yaml
- stage-values.yaml
설치 시에는 helm install myapp ./mychart -f prod-values.yaml처럼 환경에 맞는 설정 파일을 선택하면 됩니다.
헬름 릴리즈 관리로 배포 실수? 걱정 붙들어 매세요
Helm은 릴리즈라는 개념을 도입해 배포 이력을 관리합니다. helm install, helm upgrade, helm rollback 명령어만 알아도 충분하죠.
예를 들어 v2 이미지로 배포했는데 문제가 생겼다면 helm rollback myapp 1으로 이전 릴리즈로 돌아갈 수 있어요. 새벽 3시 장애에도 빠르게 대처할 수 있는 생명줄 같은 기능입니다.
CI/CD 연동으로 자동 배포까지 한 번에
단순히 수동 배포에 그치지 않고, GitHub Actions 또는 Jenkins와 연계하면 코드 푸시만으로 자동 배포가 가능합니다. 아래는 예시입니다.
- name: Helm Deploy run: helm upgrade --install myapp ./mychart -f prod-values.yaml
GitOps 툴인 Argo CD를 사용하면 Git 저장소의 차트 변경이 실시간으로 클러스터에 반영됩니다. 요즘 대세죠.
실무에서 가장 많이 쓰는 팁들
템플릿 내 변수 이름을 직관적으로 짓는 게 중요합니다. {{ .Values.dbPassword }}보단 {{ .Values.postgres.password }}처럼 명확한 구조가 좋죠.
그리고 항상 helm lint로 문법 체크, helm install --dry-run으로 배포 시뮬레이션을 해보세요. 버전은 SemVer2를 따르며, 쿠버네티스 API 버전이 바뀌면 메이저 버전도 올리는 것이 좋습니다.
마무리하며 – 헬름 차트는 진짜 개발자의 친구
저는 Helm을 쓰면서 배포 스트레스가 90%는 줄었다고 자신 있게 말할 수 있어요. 특히 팀 단위에서 작업할 때 누가 어떤 설정을 했는지, 어떤 값으로 배포됐는지 명확하게 추적이 되니까 협업 효율도 좋아졌죠.
개인 프로젝트든 대규모 서비스든, Helm은 이제 선택이 아닌 필수입니다. 꼭 한 번 손에 익혀보세요. 처음에는 낯설지만, 써보면 절대 못 놓습니다. 마치 Git을 처음 배웠을 때처럼요.
이 글이 헬름 차트를 처음 접하거나 도입을 고민 중인 분들께 실질적인 도움이 되었길 바랍니다 🙂