Helm vs Kustomize, 결국 언제 뭘 써야 할까?

Kubernetes 리소스를 관리하다 보면 한 번쯤 이런 고민을 하게 된다.

Helm을 써야 할까, Kustomize를 써야 할까?

 

둘 다 여러 YAML을 효율적으로 관리하기 위한 도구지만, 접근 방식은 꽤 다르다.
결론부터 말하면 나는 이렇게 나눠 쓰는 편이 가장 깔끔하다고 생각한다.

• 외부에서 가져온 애플리케이션 → Helm
• 내가 직접 만든 애플리케이션 → Kustomize

왜 이렇게 나누는지 하나씩 살펴보자.

---

Helm이란?

Helm은 흔히 Kubernetes의 패키지 매니저라고 불린다.

Deployment, Service, ConfigMap처럼 애플리케이션에 필요한 리소스를 Chart라는 단위로 묶고, values.yaml을 통해 설정값을 주입한다.

예를 들면 이런 값들을 환경에 맞게 바꿀 수 있다.

• 컨테이너 이미지와 태그
• replica 수
• Service 타입
• Ingress 도메인
• CPU·메모리 제한

Prometheus, Grafana, ingress-nginx처럼 구성 요소가 많은 오픈소스 애플리케이션도 Chart 하나와 values 파일만 있으면 비교적 간단하게 설치할 수 있다.

Helm의 좋은 점

• 애플리케이션을 하나의 패키지로 배포하고 버전 관리하기 좋다.
• 공식·커뮤니티 Chart 생태계가 잘 갖춰져 있다.
• 설치, 업그레이드, 롤백 흐름이 편하다.
• 다양한 옵션을 values.yaml로 노출하기 좋다.

Helm이 아쉬운 순간

Helm 템플릿에 조건문과 반복문이 늘어나기 시작하면 YAML이 금방 복잡해진다.

템플릿만 봐서는 실제로 어떤 매니페스트가 만들어지는지 바로 알기 어렵고, 단순한 환경 차이만 관리하려는데 구조가 지나치게 커질 때도 있다.

---

Kustomize란?

Kustomize는 기존 Kubernetes YAML을 템플릿으로 바꾸지 않고, 필요한 부분만 덧붙이거나 수정하는 도구다.

보통 공통 설정은 base에 두고, 개발·스테이징·운영 환경의 차이는 overlay에서 관리한다.

k8s/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    └── production/

예를 들어 모든 환경이 같은 Deployment를 사용하지만 운영 환경에서만 replica 수와 리소스 제한이 다르다면, 공통 리소스는 base에 두고 production overlay에서 차이만 패치하면 된다.

Kustomize의 좋은 점

• 순수한 Kubernetes YAML을 그대로 유지할 수 있다.
• base와 overlay 구조가 직관적이다.
• 실제로 무엇이 바뀌는지 코드 리뷰에서 확인하기 쉽다.
• 별도의 템플릿 문법을 거의 배우지 않아도 된다.
• kubectl apply -k로 바로 사용할 수 있다.

Kustomize가 아쉬운 순간

조건 분기가 많거나 하나의 리소스를 수많은 옵션 조합으로 배포해야 한다면 패치가 빠르게 늘어난다.

overlay가 너무 많아지면 오히려 최종 결과를 추적하기 어려워질 수 있고, Helm처럼 릴리스 단위의 설치 이력과 롤백을 직접 관리해 주지도 않는다.

---

Helm vs Kustomize 한눈에 비교

구분	Helm	Kustomize
핵심 방식	값을 넣어 YAML을 생성	기존 YAML에 차이를 패치
관리 단위	Chart와 Release	Base와 Overlay
강점	패키징, 재사용, 배포 이력	단순함, 가독성, 환경별 차이
설정 방법	values.yaml	Patch, Generator
잘 맞는 대상	외부 솔루션, 범용 패키지	직접 만든 서비스
주의할 점	템플릿이 복잡해질 수 있음	Overlay가 많아질 수 있음

짧게 요약하면 이렇다.

• Helm: 다양한 값을 받아 재사용할 수 있는 패키지를 만드는 데 강하다.
• Kustomize: 이미 존재하는 YAML의 환경별 차이를 관리하는 데 강하다.

---

언제 Helm을 쓰면 좋을까?

다음 상황이라면 Helm이 자연스럽다.

• 외부 오픈소스 애플리케이션을 설치할 때
• 여러 팀이나 사용자가 다양한 설정으로 재사용할 패키지를 만들 때
• 릴리스 단위의 설치, 업그레이드, 롤백이 중요할 때
• 많은 옵션을 values.yaml 하나로 제공해야 할 때

특히 공식 Helm Chart가 잘 관리되고 있다면 굳이 Chart를 풀어서 직접 YAML로 관리할 이유가 크지 않다.

Chart는 그대로 사용하고, 우리 환경에 필요한 값만 별도의 values 파일로 관리하는 편이 업그레이드도 편하고 유지보수 비용도 적다.

---

언제 Kustomize를 쓰면 좋을까?

다음 상황에서는 Kustomize가 더 편하다.

• 내가 직접 만든 애플리케이션의 리소스를 관리할 때
• 환경별 차이가 이미지 태그, replica, 도메인, 리소스 제한 정도일 때
• 렌더링 전에도 리소스 구조를 쉽게 읽고 싶을 때
• GitOps 저장소에서 변경 내용을 명확하게 리뷰하고 싶을 때

직접 작성한 리소스라면 모든 필드를 억지로 변수로 만들기보다, 읽기 쉬운 기본 YAML과 작은 overlay를 유지하는 편이 단순하다.

---

내가 선호하는 조합

나는 둘 중 하나만 고집하기보다 역할을 나눠 쓰는 쪽을 선호한다.

외부 애플리케이션은 Helm

• ingress-nginx
• cert-manager
• Prometheus
• Grafana

이런 도구는 공식 Chart와 별도의 values 파일로 관리한다. 그러면 Chart가 제공하는 업그레이드 경로와 기본 구성을 그대로 활용할 수 있다.

직접 만든 애플리케이션은 Kustomize

사내 API나 직접 개발한 서비스의 Deployment, Service, Ingress는 Kustomize의 base와 overlay로 관리한다.

리소스 구조가 그대로 보이고, 환경별 변경 사항도 리뷰에서 명확하게 드러난다.

---

마무리

Helm과 Kustomize는 경쟁 관계라기보다 서로 다른 문제를 푸는 도구에 가깝다.

• 재사용 가능한 애플리케이션 패키지가 필요하다면 Helm
• 기존 YAML의 환경별 차이를 깔끔하게 관리하고 싶다면 Kustomize

그래서 “둘 중 무엇이 더 좋은가?”보다 먼저 물어볼 질문은 이것이다.

지금 관리하려는 대상이 외부 패키지인가, 내가 직접 만든 리소스인가?

내 기준에서는 외부 Chart는 Helm으로, 직접 만든 리소스는 Kustomize로 관리하는 조합이 가장 단순하고 오래 유지하기 좋다.