Helm 4 vs Helm 3: 현실적인 업그레이드 가이드
4개월 지난 Helm 4, 실제로는 어떤가요?
Helm 4가 출시된 지 벌써 약 4개월이 흘렀습니다. 처음엔 "또 새 버전이 나왔네" 정도로 생각했는데, 실제 프로젝트에서 써보니 생각보다 의미 있는 변화들이 있더라고요.
많은 팀들이 같은 고민을 하고 있을 겁니다. "지금 당장 업그레이드해야 할까?" Helm 3도 잘 돌아가는데 굳이 위험을 감수할 필요가 있을까 싶기도 하고요.
현재 상황을 먼저 정리해보면:
- Helm 4.1.1: 2026년 2월 출시된 최신 안정판
- Helm 3.20.x: 여전히 병행 유지되고 있음
- 기존 차트들은 대부분 수정 없이 그대로 동작
다행히 Helm 팀에서는 Helm 3과 4를 동시에 지원하고 있어서, 당장 급하게 업그레이드할 필요는 없습니다.
Helm 4에서 달라진 핵심 기능들
WebAssembly 플러그인 지원
가장 눈에 띄는 변화는 WebAssembly(Wasm) 플러그인 지원입니다. 기존 Helm 플러그인은 OS별로 따로 바이너리를 관리해야 했는데, Wasm 플러그인은 한 번 빌드하면 어디서든 돌아갑니다.
# 기존 방식
helm plugin install https://github.com/example/helm-plugin
# Wasm 플러그인
helm plugin install https://github.com/example/helm-wasm-plugin
보안 격리도 더 좋아졌고, 시작 속도도 빨라졌습니다. 다만 아직 Wasm으로 포팅된 플러그인이 많지 않아서, 당장 체감할 수 있는 변화는 제한적이긴 합니다.
서버 사이드 적용(Server-Side Apply)
개인적으로는 이게 가장 실용적인 개선이라고 봅니다. **Kubernetes Server-Side Apply(SSA)**를 활용해서 필드 소유권을 더 명확하게 관리할 수 있게 됐거든요.
Helm 3에서는 kubectl로 리소스를 수정하고 나서 helm upgrade를 하면 충돌이 생기는 경우가 종종 있었는데, Helm 4에서는 이런 문제가 많이 줄어들었습니다.
# SSA 활성화
helm upgrade myapp ./chart --server-side
특히 GitOps 도구(ArgoCD, Flux)와 함께 쓰는 환경에서는 확실히 도움이 됩니다.
향상된 리소스 상태 추적
Helm이 애플리케이션 준비 상태를 판단하는 로직이 더 똑똑해졌습니다. 이전에는 Pod가 Running 상태가 되면 성공으로 보고하는 경우가 많았는데, 이제는 실제 헬스체크와 CRD 상태까지 더 꼼꼼히 확인합니다.
# 더 정확한 대기 로직
helm install myapp ./chart --wait
기타 개선사항
- 결정론적 차트 패키징: 같은 소스에서는 항상 동일한 패키지 생성
- 콘텐츠 기반 캐싱: 이름·버전이 아닌 실제 내용 해시로 캐싱
- 구조화된 로깅: Go의 slog 사용으로 더 깔끔한 로그
업그레이드 시 주의사항
플러그인 호환성
플러그인 시스템이 바뀌면서 기존 플러그인들이 안 될 수도 있습니다. 업그레이드 전에 꼭 확인해보세요.
helm plugin list
# 각 플러그인의 Helm 4 지원 여부 확인 필요
CLI 변경사항
대부분의 명령어는 그대로 쓸 수 있지만, 일부 고급 옵션들이 바뀌었습니다. CI/CD 스크립트를 쓰고 있다면 테스트 환경에서 먼저 검증해보는 게 좋습니다.
Go SDK 사용자
Helm을 라이브러리로 쓰는 경우 import path가 바뀝니다:
// Helm 3
import "helm.sh/helm/v3/pkg/action"
// Helm 4
import "helm.sh/helm/v4/pkg/action"
실무에서의 마이그레이션 전략
언제 업그레이드하면 좋을까?
지금 업그레이드 추천:
- 새 프로젝트 시작하는 경우
- GitOps 환경에서 리소스 충돌 문제가 있었던 경우
- WebAssembly 플러그인을 써보고 싶은 경우
- 테스트 환경이 잘 갖춰져 있는 경우
조금 더 기다려도 되는 경우:
- 현재 Helm 3 환경이 안정적인 경우
- 복잡한 커스텀 플러그인을 쓰고 있는 경우
- 마이그레이션 테스트할 여유가 없는 경우
안전한 업그레이드 순서
제가 실제로 써본 방법입니다:
1단계: 병렬 설치
# Helm 4 설치 (Helm 3와 공존 가능)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash
helm version
2단계: 드라이런 테스트
# 기존 릴리스 드라이런
helm upgrade myapp ./chart --dry-run --debug
3단계: 개발 환경부터
- 1주차: 개발 환경에서 테스트
- 2주차: 스테이징 업그레이드
- 3-4주차: 프로덕션 점진적 적용
4단계: 안전 플래그 활용
helm upgrade myapp ./chart \
--wait \
--timeout=10m \
--atomic \
--cleanup-on-fail
현실적인 판단 기준
| 상황 | 추천 | 이유 |
|---|---|---|
| 신규 프로젝트 | Helm 4 | 새로 시작하는 거라면 최신 버전이 낫습니다 |
| 안정적인 운영 중 | Helm 3 유지 | 굳이 위험 감수할 필요 없음 |
| GitOps 환경 | Helm 4 검토 | SSA 기능이 실제로 도움 됨 |
| 복잡한 플러그인 사용 | 신중히 판단 | 플러그인 호환성 먼저 확인 |
솔직히 말하면, Helm 2에서 3으로의 변화만큼 혁신적이지는 않습니다. 그때는 Tiller 제거라는 큰 아키텍처 변화가 있었는데, 이번엔 점진적 개선에 가깝거든요.
그래서 급하게 업그레이드할 필요는 없지만, 새로 시작하는 프로젝트라면 Helm 4를 쓰는 게 좋을 것 같습니다. 특히 GitOps 환경에서 리소스 관리 충돌 때문에 고생한 경험이 있다면, SSA 기능만으로도 업그레이드 가치는 충분하다고 봅니다.
무엇보다 중요한 건 충분한 테스트입니다. 아무리 좋은 기능이라도 프로덕션에서 문제가 생기면 의미가 없으니까요.