Kubernetes Helm Charts 완벽 가이드 2026: 패키징, 배포, 면접 질문
Helm 3을 사용한 Kubernetes 애플리케이션 패키징과 배포 방법을 상세히 설명합니다. 차트 구조, 템플릿 작성, 의존성 관리, 그리고 기술 면접에서 자주 나오는 질문과 답변을 다룹니다.

Kubernetes Helm Charts는 모든 Kubernetes 리소스를 단일 버전 관리 아티팩트로 패키징하여 애플리케이션 배포를 간소화합니다. 현재 안정 버전인 Helm 3은 Tiller의 필요성을 제거하고 OCI 레지스트리 지원을 도입하여 차트 배포를 더욱 안전하고 표준화된 방식으로 만들었습니다. 이 튜토리얼에서는 차트 생성, 템플릿 작성, 배포 전략, 그리고 채용 팀에서 가장 자주 묻는 면접 질문에 대해 다룹니다.
Helm 차트는 Chart.yaml(메타데이터), values.yaml(기본값), 그리고 Kubernetes 매니페스트가 포함된 templates/ 디렉토리로 구성됩니다. helm install 명령어는 값으로 템플릿을 렌더링하고 클러스터에 적용합니다.
Helm 차트 구조와 컴포넌트 이해하기
Helm 차트는 미리 정의된 구조를 가진 디렉토리입니다. 차트 이름이 디렉토리 이름이 되며, 각 파일은 패키징 및 배포 프로세스에서 특정 역할을 수행합니다.
# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
- name: postgresql
version: "15.x"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabledapiVersion: v2는 Helm 3 호환성을 나타냅니다. version 필드는 차트 변경 사항을 추적하고, appVersion은 배포되는 애플리케이션 버전을 반영합니다. 의존성은 이 차트가 필요로 하는 다른 차트를 선언하며, 선택적으로 활성화/비활성화 조건을 설정할 수 있습니다.
# values.yaml
replicaCount: 3
image:
repository: myregistry.io/app
tag: "2.1.0"
pullPolicy: IfNotPresent
service:
type: ClusterIP
port: 8080
resources:
limits:
cpu: 500m
memory: 512Mi
requests:
cpu: 100m
memory: 128Mi
postgresql:
enabled: true
auth:
database: appdbvalues.yaml은 사용자가 설치 시 재정의할 수 있는 구성 기본값을 정의합니다. 의미 있는 키 아래에 값을 중첩하면 구성이 체계적으로 정리되고 자체 문서화됩니다.
Helm 템플릿으로 Kubernetes 배포 생성하기
Helm 템플릿은 Go 템플릿과 Sprig 함수를 사용하여 Kubernetes 매니페스트를 동적으로 생성합니다. {{ .Values }} 객체는 values.yaml 내용에 대한 액세스를 제공하고, {{ .Release }}에는 배포 메타데이터가 포함됩니다.
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "my-application.fullname" . }}
labels:
{{- include "my-application.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{- include "my-application.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "my-application.selectorLabels" . | nindent 8 }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- containerPort: {{ .Values.service.port }}
resources:
{{- toYaml .Values.resources | nindent 12 }}nindent 함수는 줄바꿈과 들여쓰기를 추가하며, YAML 생성에 매우 중요합니다. _helpers.tpl에 정의된 명명된 템플릿과 함께 include를 사용하면 템플릿을 DRY하게 유지하고 유지 관리성을 높일 수 있습니다.
# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}헬퍼 템플릿은 모든 리소스에 걸쳐 명명 규칙과 레이블을 표준화하여 Kubernetes 권장 레이블과의 일관성을 보장합니다.
Helm 차트 의존성과 서브차트
복잡한 애플리케이션은 종종 데이터베이스, 캐시 또는 메시지 큐에 의존합니다. Helm 의존성을 사용하면 이러한 것들을 서브차트로 포함하여 설치 중에 자동으로 관리할 수 있습니다.
# 패키징 전 의존성 업데이트
helm dependency update ./my-application
# 의존성 빌드 (charts/ 디렉토리 생성)
helm dependency build ./my-applicationhelm dependency update 명령어는 의존성을 charts/ 디렉토리로 다운로드합니다. 조건부 의존성은 값을 사용하여 포함 여부를 전환합니다:
# values.yaml
postgresql:
enabled: true
redis:
enabled: false# Chart.yaml
dependencies:
- name: postgresql
version: "15.x"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
- name: redis
version: "19.x"
repository: "https://charts.bitnami.com/bitnami"
condition: redis.enabled이 패턴을 통해 프로덕션 환경에서는 관리형 서비스를 사용하고 개발 환경에서는 클러스터 내 데이터베이스를 사용하는 환경별 구성이 가능합니다.
Helm 3.8 이상은 Docker Hub, GitHub Container Registry, AWS ECR과 같은 OCI 호환 레지스트리에 차트를 저장할 수 있습니다. helm push my-app-1.0.0.tgz oci://registry.example.com/charts 명령으로 차트를 푸시합니다.
릴리스 관리를 통한 Helm 차트 배포
Helm은 배포를 릴리스로 추적하여 버전 관리된 롤백과 업그레이드를 가능하게 합니다. 각 릴리스는 감사 및 복구를 위한 히스토리를 유지합니다.
# 사용자 정의 값으로 차트 설치
helm install my-release ./my-application \
--namespace production \
--create-namespace \
--values production-values.yaml \
--set image.tag=2.1.1
# 기존 릴리스 업그레이드
helm upgrade my-release ./my-application \
--namespace production \
--values production-values.yaml \
--set image.tag=2.2.0 \
--atomic \
--timeout 5m--atomic 플래그는 업그레이드 실패 시 자동으로 롤백되도록 보장합니다. --timeout 플래그는 Helm이 리소스가 준비될 때까지 기다리는 시간을 설정합니다.
# 릴리스 히스토리 보기
helm history my-release -n production
# 이전 리비전으로 롤백
helm rollback my-release 2 -n production
# 릴리스 삭제
helm uninstall my-release -n production --keep-history--keep-history 플래그는 삭제 후에도 릴리스 기록을 보존합니다. 이는 규정 준수 및 디버깅에 유용합니다.
DevOps 면접 준비가 되셨나요?
인터랙티브 시뮬레이터, flashcards, 기술 테스트로 연습하세요.
Helm 차트 테스트 및 검증 전략
배포 전에 Helm 차트를 테스트하면 템플릿 오류와 구성 문제를 조기에 발견할 수 있습니다. Helm은 린팅과 드라이런 테스트를 위한 내장 도구를 제공합니다.
# 차트 오류 및 모범 사례 린트
helm lint ./my-application
# 배포 없이 로컬에서 템플릿 렌더링
helm template my-release ./my-application \
--values production-values.yaml \
> rendered-manifests.yaml
# 클러스터 API에 대해 드라이런
helm install my-release ./my-application \
--dry-run \
--debug \
--namespace productionhelm template 명령어는 매니페스트를 로컬에서 렌더링하며, 생성된 YAML을 검증하는 CI 파이프라인에 유용합니다. --dry-run 플래그는 매니페스트를 Kubernetes API 서버로 보내 검증하지만 리소스를 생성하지는 않습니다.
# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
name: "{{ include "my-application.fullname" . }}-test"
labels:
{{- include "my-application.labels" . | nindent 4 }}
annotations:
"helm.sh/hook": test
spec:
containers:
- name: curl
image: curlimages/curl:8.7.1
command: ['curl']
args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
restartPolicy: Neverhelm.sh/hook: test 어노테이션이 있는 Helm 훅은 helm test my-release 후에 실행되어 설치 후 배포가 올바르게 작동하는지 검증합니다.
고급 Helm 템플릿 기술
프로덕션 차트에는 조건부 로직, 루프, 데이터 변환이 필요합니다. Sprig 함수는 문자열 조작, 인코딩, 흐름 제어를 위한 유틸리티로 Go 템플릿을 확장합니다.
# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ include "my-application.fullname" . }}-config
data:
{{- range $key, $value := .Values.config }}
{{ $key }}: {{ $value | quote }}
{{- end }}
{{- if .Values.features.enabled }}
FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
{{- end }}# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
{{- range $key, $value := .Values.secrets }}
{{ $key }}: {{ $value | b64enc }}
{{- end }}range 함수는 맵과 리스트를 반복합니다. b64enc 함수는 Kubernetes 시크릿을 위해 값을 base64로 인코딩합니다. 파이프 연산자는 데이터 변환을 위해 함수를 체이닝합니다.
values.yaml에 시크릿을 저장하면 버전 관리에 노출됩니다. 프로덕션 배포에는 HashiCorp Vault, External Secrets Operator와 AWS Secrets Manager, 또는 SOPS로 암호화된 values 파일과 같은 외부 시크릿 관리자를 사용하십시오.
Helm 차트 면접 질문과 답변
기술 면접에서는 개념적, 실용적 질문을 통해 Helm 지식을 자주 테스트합니다. 다음은 가장 자주 묻는 주제에 대한 설명입니다.
helm install과 helm upgrade --install의 차이점은 무엇입니까?
helm install은 새 릴리스를 생성하고 릴리스가 이미 존재하면 실패합니다. helm upgrade --install(--install 플래그 포함)은 릴리스가 존재하지 않으면 새로 생성하고, 존재하면 업그레이드합니다. CI/CD 파이프라인에서는 일반적으로 멱등성 있는 배포를 위해 helm upgrade --install을 사용합니다.
Helm 차트에 민감한 데이터를 전달하는 방법은 무엇입니까?
세 가지 접근 방식이 있습니다: 외부 시크릿 관리자(Vault, AWS Secrets Manager), 암호화된 values 파일(SOPS, sealed-secrets), 또는 Helm 외부에서 생성되어 템플릿에서 참조되는 Kubernetes 시크릿입니다. 버전 관리에 커밋되는 평문 values.yaml 파일에 시크릿을 저장하는 것은 피하십시오.
Helm 훅이란 무엇이며 언제 사용해야 합니까?
훅은 릴리스 라이프사이클의 특정 시점에서 실행됩니다: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback, test. 일반적인 사용 사례로는 업그레이드 전 데이터베이스 마이그레이션, 배포 후 알림 전송, 통합 테스트 실행이 있습니다.
차트 버전 관리는 어떻게 처리합니까?
Chart.yaml의 version 필드는 시맨틱 버저닝을 사용하여 차트 변경 사항을 추적합니다. appVersion 필드는 배포되는 애플리케이션 버전을 추적합니다. 애플리케이션 버전이 동일하더라도 차트가 수정되면 version을 증가시키십시오.
.helmignore의 목적은 무엇입니까?
.gitignore와 유사하게 .helmignore는 차트 패키징에서 파일을 제외합니다. 일반적인 항목으로는 *.tgz(이전 빌드 패키징 방지), .git/, 런타임에 불필요한 *.md 문서, CI 구성 파일이 있습니다.
Kubernetes 면접 준비를 더 하고 싶다면 SharpSkill의 Kubernetes 기초 및 Kubernetes 심화 질문 모듈을 확인하십시오.
결론
Helm 차트 작업 시 실용적인 핵심 사항은 다음과 같습니다:
- Chart.yaml 메타데이터, values.yaml 기본값, Kubernetes 매니페스트가 포함된 templates 디렉토리를 명확히 분리하여 차트를 구성합니다
- _helpers.tpl의 헬퍼 템플릿을 사용하여 모든 리소스에 걸쳐 명명 규칙과 레이블을 표준화합니다
- 환경별 구성을 위해 Chart.yaml에서 조건부 활성화로 의존성을 관리합니다
- 프로덕션에 배포하기 전에
helm lint,helm template,helm install --dry-run으로 차트를 테스트합니다 - 의미 있는 이름으로 릴리스를 추적하고 업그레이드 실패 시 자동 롤백을 위해
--atomic플래그를 사용합니다 - 평문 values 파일 대신 외부 관리자에 시크릿을 저장합니다
연습을 시작하세요!
면접 시뮬레이터와 기술 테스트로 지식을 테스트하세요.
태그
공유
관련 기사

ArgoCD와 GitOps 완벽 가이드 2026: Kubernetes 지속적 배포 전략과 면접 핵심 질문
ArgoCD 3.4 GitOps 튜토리얼. Kubernetes 지속적 배포, Application CRD, Sync Waves, 멀티클러스터 관리, Flux 비교, 면접 빈출 질문을 YAML 예제와 함께 해설합니다.

Kubernetes 면접 완벽 가이드: Pod, Service, Deployment 핵심 정리
Kubernetes 면접에서 자주 출제되는 Pod, Service, Deployment의 핵심 개념을 YAML 예제와 함께 상세히 정리합니다. 2026년 최신 트렌드를 반영한 실전 대비 가이드입니다.

Kubernetes: 첫 애플리케이션 배포하기
Kubernetes에서 애플리케이션을 배포하기 위한 실용 가이드입니다. minikube 설치부터 Deployment, Service, ConfigMap까지 구체적인 예제와 함께 설명합니다.