배포 도구 선정

🚀 요약

SUMMARY

배포 도구를 용도에 따라 둘로 나눴다. 플랫폼 컴포넌트는 Helmfile로 Helm만으로 안 되는 설치/삭제 라이프사이클을 자동화하고, 자사 솔루션은 Argo CD로 GitOps 워크플로우를 얹었다.

쿠버네티스에서 뭔가를 배포하는 방법은 널려 있다. 선택지가 많다는 건 좋은 일이지만, 팀마다 제각각인 포맷을 다 관리해야 한다는 뜻이기도 하다. 그래서 처음부터 “배포는 이렇게 한다”는 일관된 틀을 잡고 가는 게 낫다고 봤다.

크게 두 부류로 나눠서 접근했다. 하나는 클러스터를 굴리기 위한 플랫폼 컴포넌트(인프라성 애드온), 다른 하나는 실제로 파는 자사 솔루션(비즈니스 애플리케이션)이다. 성격이 다르니 도구도 다르게 골랐다.

두 부류가 요구하는 게 달랐다.

플랫폼 컴포넌트는 라이프사이클이 지저분하다
- cilium, prometheus, cert-manager 같은 컴포넌트는 helm install 한 방으로 끝나는 경우가 드물었다.
- CRD(Custom Resource Definition)를 먼저 깔아둬야 하거나, 차트를 올린 뒤 CR(Custom Resource)을 따로 배포해야 하거나, ConfigMap을 바꾸면 관련 Deployment를 손으로 재시작해줘야 하거나. 차트 하나 설치했다고 끝이 아니라 앞뒤로 스텝이 붙었다.
개발팀은 쉽고 안전하게 배포하고 싶어 한다
- 솔루션은 개발하면서 수시로 배포가 일어난다.
- 인프라를 잘 모르는 개발자도 자기 코드가 어떻게 배포됐는지 보고, 필요하면 직접 배포를 눌러볼 수 있어야 했다.
- 배포 이력이 다 남고, 문제가 생기면 특정 커밋으로 바로 되돌릴 수 있는 GitOps가 필요하다고 봤다.

도구	장점	단점
Helm	쿠버네티스 패키지 관리의 사실상 표준, 공개 차트 생태계가 방대함	복잡한 설치/삭제 로직은 손이 안 닿음, 여러 차트의 의존성·설정 관리가 번거로움
Helmfile	Helm 기능을 그대로 감싸면서 `Hook`으로 사전/사후 작업 자동화, 여러 릴리스를 코드로 선언	Helm 위에 얹히는 학습 곡선이 하나 더 있음

워크플로우	장점	단점
수동 배포 (kubectl)	간단하고 직관적, 유연함	휴먼 에러, 배포 이력·상태 추적이 어려움, 표준화가 안 됨
GitOps (Argo CD)	Git이 단일 진실 공급원, 배포 자동화·일관성, 감사 추적과 롤백, 개발자용 Web UI	초기 설정과 GitOps 개념 이해가 필요

Helm 차트만으로는 복잡한 의존성과 라이프사이클을 감당하기 어려웠는데, 이걸 Helmfile의 Hook으로 풀 수 있겠다 싶었다.

Hook으로 앞뒤 정리: helm install 전에 CRD를 먼저 적용하고, helm uninstall 뒤에 남는 PVC나 Namespace 같은 잔여 리소스를 Hook 스크립트로 치울 수 있었다. ConfigMap이나 Secret을 바꾼 뒤 관련 Pod를 자동으로 롤링 재시작시키는 것도 Hook으로 붙였다. 손으로 하던 스텝이 파일 안으로 들어온 셈이다.
선언적 관리: 여러 차트와 그 설정을 helmfile.yaml 하나에 코드로 박아두니, 클러스터 컴포넌트 전체를 선언적으로 관리하고 재현할 수 있었다.

GitOps 도구는 여럿이지만, 커뮤니티가 활발하고 기능이 성숙하기로는 Argo CD가 무난하다고 판단했다.

개발 편의성: 개발자가 kubectl을 붙들 필요 없이 코드를 Git에 푸시하는 것만으로 배포가 돈다. Web UI에서 배포 상태, 동기화 여부, 앱 상태가 한눈에 보이니 “지금 뭐가 어떻게 돌고 있는지” 묻는 일이 확 줄었다.
운영 안정성: Git을 단일 진실 공급원(Single Source of Truth)으로 두고 클러스터 상태를 항상 Git과 맞춰준다. 덕분에 드리프트(Drift)를 막고, 사고가 나면 특정 커밋으로 되돌려 대응할 수 있다.