Helm 4 vs Helm 3: 현실적인 업그레이드 가이드

4개월 지난 Helm 4, 실제로는 어떤가요?

Helm 4가 출시된 지 벌써 4개월쯤 지났습니다. 처음 릴리스 노트를 봤을 때는 "또 메이저 버전이네" 정도로 흘려 넘겼어요. 솔직히 패키지 매니저에서 메이저 버전이 올라간다고 해서 운영자가 당장 손에 쥐는 게 크게 달라지진 않거든요. 그런데 실제 프로젝트에 몇 번 물려보니 생각보다 결이 다른 변화들이 끼어 있더라고요.

많은 팀이 지금 비슷한 자리에 서 있을 겁니다. "지금 당장 업그레이드해야 하나?" Helm 3도 멀쩡히 돌아가는데 굳이 위험을 떠안을 이유가 있나 싶고. 이 고민은 사실 Helm만의 문제가 아닙니다. 잘 돌아가는 운영 환경에 손을 대는 건 언제나 비용이고, 그 비용을 정당화할 만한 이득이 있느냐가 핵심이죠.

현재 상황을 먼저 정리해보면:

• Helm 4.1.1: 2026년 2월 출시된 최신 안정판
• Helm 3.20.x: 여전히 병행 유지되고 있음
• 기존 차트들은 대부분 수정 없이 그대로 동작

다행히 Helm 팀이 3과 4를 동시에 지원하고 있어서, 마감에 쫓기듯 갈아탈 필요는 없습니다. 이 점이 의외로 중요한데, 마이그레이션을 강제하지 않는다는 건 곧 "천천히 검증할 시간을 준다"는 뜻이거든요.

Helm 4에서 달라진 핵심 기능들

WebAssembly 플러그인 지원

가장 눈에 띄는 변화는 WebAssembly(Wasm) 플러그인 지원입니다. 기존 Helm 플러그인은 OS·아키텍처별로 바이너리를 따로 관리해야 했어요. 운영 환경이 리눅스인데 개발자 노트북은 맥이고, CI 러너는 또 다른 조합이고. 이런 환경에서 플러그인 하나 깔려고 빌드 매트릭스를 신경 써야 했던 경험이 있다면 무슨 얘긴지 바로 와닿을 겁니다. 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은 자기가 마지막으로 적용한 상태만 기억하고 있으니 그 바깥의 변경을 충돌로 인식하거나 덮어써 버리는 거죠. 누가 어떤 필드를 소유하는지가 클라이언트 쪽 추측에 의존했던 게 근본 원인이었습니다. SSA는 이 소유권 판단을 API 서버로 넘깁니다. 그래서 Helm 4에서는 이런 마찰이 눈에 띄게 줄어듭니다.

# SSA 활성화
helm upgrade myapp ./chart --server-side

특히 GitOps 도구(ArgoCD, Flux)와 함께 쓰는 환경이라면 확실히 도움이 됩니다. GitOps에서는 Helm 말고도 여러 행위자가 같은 리소스를 만지니까, 필드 소유권이 명확해진다는 게 단순한 편의가 아니라 운영 안정성의 문제가 됩니다.

향상된 리소스 상태 추적

Helm이 애플리케이션 준비 상태를 판단하는 로직이 더 똑똑해졌습니다. 예전에는 Pod가 Running 상태에 들어가면 성공으로 보고하는 경우가 많았어요. 문제는 Running과 "실제로 트래픽을 받을 준비가 됨"은 다르다는 겁니다. 컨테이너는 떴는데 안에서 초기화가 끝나지 않은 상태, 다들 한 번씩 데여봤을 겁니다. Helm 4는 이제 헬스체크와 CRD 상태까지 더 꼼꼼히 확인합니다.

# 더 정확한 대기 로직
helm install myapp ./chart --wait

배포 파이프라인에서 "성공"의 정의가 정확해진다는 건, 잘못된 초록불 때문에 다음 단계로 넘어가다 터지는 사고를 줄여준다는 뜻입니다.

기타 개선사항

• 결정론적 차트 패키징: 같은 소스에서는 항상 동일한 패키지 생성
• 콘텐츠 기반 캐싱: 이름·버전이 아닌 실제 내용 해시로 캐싱
• 구조화된 로깅: Go의 slog 사용으로 더 깔끔한 로그

결정론적 패키징과 콘텐츠 기반 캐싱은 사소해 보여도 공급망 보안과 재현성 관점에서 의미가 있습니다. 같은 입력이 항상 같은 결과를 낸다는 건 감사(audit)와 검증의 출발점이거든요.

업그레이드 시 주의사항

플러그인 호환성

플러그인 시스템이 바뀌면서 기존 플러그인이 안 돌아갈 수도 있습니다. 업그레이드 전에 꼭 확인하세요.

helm plugin list
# 각 플러그인의 Helm 4 지원 여부 확인 필요

현장에서 의외로 발목 잡히는 게 이 지점입니다. 차트는 멀쩡히 넘어가는데, 팀이 오래전부터 쓰던 자작 플러그인이나 secrets 관련 플러그인 하나가 안 돌아서 파이프라인 전체가 멈추는 식이죠.

CLI 변경사항

대부분의 명령어는 그대로 쓸 수 있지만, 일부 고급 옵션이 바뀌었습니다. CI/CD 스크립트에 helm 명령을 박아두고 있다면 테스트 환경에서 먼저 검증하는 게 좋습니다. 손으로 칠 때는 잘 되던 게, 스크립트 안의 특정 플래그 조합에서만 깨지는 경우가 있거든요.

Go SDK 사용자

Helm을 라이브러리로 끌어다 쓰는 경우 import path가 바뀝니다:

// Helm 3
import "helm.sh/helm/v3/pkg/action"

// Helm 4  
import "helm.sh/helm/v4/pkg/action"

사내에 Helm을 감싼 배포 도구나 자동화 컨트롤러를 직접 만들어 쓰는 조직이라면 이 부분이 가장 손이 많이 갑니다. CLI 사용자보다 SDK 사용자가 마이그레이션 부담을 더 크게 짊어진다는 점은 미리 계산에 넣어둬야 합니다.

실무에서의 마이그레이션 전략

언제 업그레이드하면 좋을까?

지금 업그레이드해도 좋은 경우:

• 새 프로젝트를 시작하는 경우
• GitOps 환경에서 리소스 충돌 문제로 고생한 적 있는 경우
• WebAssembly 플러그인을 본격적으로 써보고 싶은 경우
• 테스트 환경이 잘 갖춰져 있는 경우

조금 더 기다려도 되는 경우:

• 현재 Helm 3 환경이 안정적인 경우
• 복잡한 커스텀 플러그인에 의존하는 경우
• 마이그레이션을 검증할 여유가 없는 경우

판단 기준을 한 줄로 줄이면 이렇습니다. 얻을 이득이 명확한가, 아니면 그냥 최신이라서 끌리는가. 후자라면 급할 게 없습니다.

안전한 업그레이드 순서

제가 실제로 밟아본 순서입니다:

1단계: 병렬 설치

# Helm 4 설치 (Helm 3와 공존 가능)
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4 | bash
helm version

3과 4가 공존할 수 있다는 점을 적극 활용하는 게 핵심입니다. 한쪽을 지우고 시작하면 문제가 생겼을 때 되돌아갈 자리가 없어지니까요.

2단계: 드라이런 테스트

# 기존 릴리스 드라이런
helm upgrade myapp ./chart --dry-run --debug

드라이런 결과의 diff를 눈으로 한 번 훑어보는 걸 권합니다. SSA로 바뀌면서 리소스 처리 방식이 달라진 부분이 여기서 드러나는 경우가 있습니다.

3단계: 개발 환경부터

• 1주차: 개발 환경에서 테스트
• 2주차: 스테이징 업그레이드
• 3-4주차: 프로덕션 점진적 적용

환경을 한 단계씩 올리는 이 리듬은 답답해 보여도, 문제를 만났을 때 영향 범위를 그 단계 안에 가둬준다는 게 진짜 가치입니다.

4단계: 안전 플래그 활용

helm upgrade myapp ./chart \
  --wait \
  --timeout=10m \
  --atomic \
  --cleanup-on-fail

특히 --atomic은 업그레이드가 실패하면 이전 릴리스로 자동 롤백해줍니다. 프로덕션 적용에서는 이 플래그를 기본값처럼 깔고 가는 편이 마음 편합니다.

현실적인 판단 기준

상황	추천	이유
신규 프로젝트	Helm 4	새로 시작하는 거라면 최신 버전이 낫습니다
안정적인 운영 중	Helm 3 유지	굳이 위험 감수할 필요 없음
GitOps 환경	Helm 4 검토	SSA 기능이 실제로 도움 됨
복잡한 플러그인 사용	신중히 판단	플러그인 호환성 먼저 확인

솔직히 말하면 이번 변화는 Helm 2에서 3으로 넘어갈 때만큼 극적이지는 않습니다. 그때는 Tiller 제거라는 굵직한 아키텍처 전환이 있었죠. 클러스터 안에 서버 컴포넌트를 띄워두던 모델 자체가 사라졌으니까요. 이번 4는 그런 패러다임 전환이라기보다, 운영하면서 쌓인 불편들을 한 단계씩 다듬은 점진적 개선에 가깝습니다.

그래서 등 떠밀리듯 갈아탈 이유는 없습니다. 다만 새로 시작하는 프로젝트라면 Helm 4로 출발하는 쪽이 낫다고 봅니다. 어차피 언젠가 넘어갈 거라면, 마이그레이션 부채를 미리 쌓아둘 이유가 없으니까요. 특히 GitOps 환경에서 리소스 소유권 충돌로 새벽에 불려나가 본 적이 있다면, SSA 하나만으로도 업그레이드 명분은 충분합니다.

결국 이건 기능 비교표의 문제가 아니라 운영 리스크를 어디에 둘 것이냐의 문제입니다. 좋은 기능이라도 프로덕션에서 한 번 터지면 그동안 아낀 시간을 전부 토해내게 되거든요. 충분히 검증할 시간을 확보했는지, 저는 그걸 업그레이드 결정의 마지막 관문으로 봅니다.