왜 GitOps에서는 Docker Compose 대신 Helm과 Kustomize를 사용하는가 — DevOps 관점에서 보는 배포 선언 관리

1. 서론 — Docker Compose로 시작한 개발자가 Kubernetes에서 마주하는 질문

많은 백엔드 개발자들이 컨테이너 기반 운영을 시작할 때 가장 먼저 사용하는 도구는 Docker Compose입니다.

Docker Compose는 여러 컨테이너를 하나의 서비스로 묶어 실행할 수 있기 때문에 로컬 개발이나 간단한 서버 운영에서는 매우 편리합니다.

예를 들어 다음과 같은 구성이 가능합니다.

• API 서버
• PostgreSQL
• Redis
• Elasticsearch

Compose 파일 하나로 전체 서비스를 실행할 수 있습니다.

하지만 DevOps 환경, 특히 Kubernetes + GitOps 구조로 넘어오면 상황이 달라집니다.

이때 등장하는 도구가 바로 Helm과 Kustomize입니다.

많은 개발자들이 여기서 질문을 하게 됩니다.

“Docker Compose로도 충분히 서비스 배포가 가능한데
왜 Kubernetes에서는 Helm이나 Kustomize를 사용하는가?”

이 글에서는 DevOps와 GitOps 관점에서 그 이유를 정리해보겠습니다.

---

2. Docker Compose의 역할 — 컨테이너 실행 도구

Docker Compose는 기본적으로 컨테이너 실행 오케스트레이션 도구입니다.

Compose의 핵심 역할은 다음과 같습니다.

• 여러 컨테이너를 동시에 실행
• 네트워크 연결
• 볼륨 연결
• 환경 변수 설정
• 의존성 순서 관리

예를 들어 다음과 같은 구조입니다.

docker-compose.yml

 

API Server
PostgreSQL
Redis
Elasticsearch

 

이 파일을 기반으로 다음 명령어 하나로 서비스를 실행합니다.

docker compose up -d

 

즉 Docker Compose는

**“컨테이너를 어떻게 실행할 것인가”**에 집중합니다.

하지만 DevOps 환경에서는 단순 실행 이상의 관리가 필요합니다.

---

3. DevOps 환경에서 필요한 것

DevOps 운영에서는 단순히 컨테이너를 실행하는 것보다 더 중요한 요소들이 있습니다.

예를 들면 다음과 같습니다.

• 배포 이력 관리
• 환경별 설정 관리 (dev / staging / prod)
• 롤백
• 선언 기반 인프라 관리
• 자동화된 배포
• 클러스터 상태 관리

이러한 요구사항을 충족시키기 위해 Kubernetes에서는 선언형(Declarative) 방식을 사용합니다.

예를 들어 다음과 같은 YAML이 존재합니다.

Deployment
Service
ConfigMap
Secret
Ingress
CronJob

 

이 YAML 파일들이 모여 서비스의 상태를 정의합니다.

그리고 GitOps에서는 이 YAML 파일들이 바로 **운영 상태의 진실(Source of Truth)**이 됩니다.

---

4. GitOps의 핵심 개념 — 선언 기반 운영

GitOps의 핵심 철학은 다음 한 문장으로 정리됩니다.

Git에 정의된 상태가 곧 실제 시스템의 상태다.

즉 Git에 다음과 같이 정의되어 있다면

replicas: 3

 

클러스터에는 실제로

Pod 3개

 

가 존재해야 합니다.

만약 누군가 서버에서 직접 다음과 같이 수정한다면

kubectl scale deployment api --replicas=5

 

GitOps 도구(예: ArgoCD)는 이를 감지하고 다시 Git 상태로 되돌립니다.

이 과정을 Drift Correction이라고 합니다.

이처럼 GitOps 환경에서는 배포 상태 자체가 Git으로 관리됩니다.

---

5. Docker Compose가 GitOps와 맞지 않는 이유

Docker Compose는 다음과 같은 특징을 가지고 있습니다.

• 서버에서 직접 실행된다
• 서버 상태가 기준이 된다
• YAML이 있지만 실행은 명령어 기반이다

예를 들어 일반적인 배포 흐름은 다음과 같습니다.

GitHub
↓
SSH 접속
↓
docker compose pull
↓
docker compose up -d

 

이 방식의 문제는 서버 상태가 기준이 된다는 것입니다.

즉 Git이 아니라 서버가 Source of Truth가 됩니다.

이 경우 다음 문제가 발생할 수 있습니다.

• 누가 언제 배포했는지 추적 어려움
• 서버에서 직접 수정 가능
• 환경 설정 drift 발생
• 롤백 복잡

이러한 이유로 GitOps에서는 Compose 기반 배포보다 선언 기반 Kubernetes 리소스 관리를 사용합니다.

---

6. Helm과 Kustomize의 역할

Kubernetes YAML은 실제 서비스 운영에서는 매우 빠르게 복잡해집니다.

예를 들어 다음과 같은 문제가 발생합니다.

• 환경별 설정
• 공통 리소스 관리
• 이미지 버전 관리
• 서비스별 설정

이 문제를 해결하기 위해 사용하는 도구가 바로 Helm과 Kustomize입니다.

---

Helm

Helm은 Kubernetes의 패키지 매니저입니다.

개념적으로는 다음과 같습니다.

apt / yum → 패키지 관리
Helm → Kubernetes 서비스 패키지 관리

 

Helm을 사용하면 다음이 가능합니다.

• 템플릿 기반 YAML 생성
• values 파일로 환경 설정 관리
• 버전 관리
• 배포 및 롤백

즉 Helm은 Kubernetes 애플리케이션 패키징 도구입니다.

---

Kustomize

Kustomize는 YAML Overlay 관리 도구입니다.

예를 들어 다음과 같은 구조를 만들 수 있습니다.

base
├ deployment.yaml
└ service.yaml

overlays
├ dev
└ prod

 

이렇게 하면 공통 설정은 유지하면서 환경별 차이만 관리할 수 있습니다.

Kustomize는 Kubernetes에 기본 내장되어 있기 때문에 별도 설치 없이 사용할 수 있습니다.

---

7. DevOps 관점에서 보는 선택 기준

도구                                                                            역할

Docker Compose	컨테이너 실행
Helm	Kubernetes 애플리케이션 패키징
Kustomize	환경별 YAML 관리
ArgoCD	GitOps 배포 관리

즉 DevOps 환경에서는 다음과 같은 구조가 만들어집니다.

GitHub
├ source code
├ Dockerfile
└ k8s manifests (Helm / Kustomize)

↓

ArgoCD

↓

Kubernetes Cluster

 

---

8. 정리

Docker Compose는 훌륭한 도구입니다.
하지만 그 목적은 컨테이너 실행입니다.

반면 GitOps 환경에서는 다음이 필요합니다.

• 선언형 배포
• Git 기반 상태 관리
• 환경별 구성
• 자동화된 배포
• 클러스터 상태 동기화

이러한 요구사항을 충족시키기 위해 Kubernetes 생태계에서는

Helm과 Kustomize를 사용합니다.

결국 차이는 다음 한 문장으로 정리됩니다.

Docker Compose는 “컨테이너 실행 도구”이고
Helm과 Kustomize는 “배포 상태 관리 도구”이다.