Argo CD GitOps 운영 가이드 - Kubernetes 배포를 어떻게 안정화할까

왜 GitOps가 필요한가

쿠버네티스 운영이 어려운 가장 큰 이유 중 하나는 “현재 상태”와 “원하는 상태”가 자주 어긋나기 때문입니다.

대표적인 문제:

누군가 클러스터에서 직접 kubectl edit 수행
배포 이력이 Git에 남지 않음
환경별 설정 차이가 누적됨
롤백 기준이 불명확함

GitOps는 “Git에 정의된 상태를 실제 클러스터의 기준으로 삼는 방식”입니다.

Argo CD의 기본 개념

Argo CD는 Git 저장소에 선언된 Kubernetes 매니페스트를 지속적으로 클러스터와 동기화합니다.

Git Repository
 -> Argo CD watches changes
 -> Compare desired state with live state
 -> Sync manifests to cluster

핵심 장점:

배포 이력 추적 가능
Drift 자동 감지
롤백 기준 명확
수동 조작 최소화

권장 저장소 구조

초기부터 애플리케이션 코드와 배포 매니페스트를 어떻게 나눌지 정하는 것이 중요합니다.

많이 쓰는 구조:

앱 코드 저장소
인프라 또는 GitOps 저장소

예:

gitops-repo/
├─ apps/
│  ├─ api/
│  │  ├─ base/
│  │  ├─ overlays/dev/
│  │  ├─ overlays/staging/
│  │  └─ overlays/prod/
│  └─ worker/
├─ platform/
│  ├─ ingress-nginx/
│  ├─ cert-manager/
│  └─ external-secrets/

이렇게 나누면 애플리케이션 릴리스와 클러스터 운영 리소스를 분리하기 쉽습니다.

Kustomize와 Helm은 어떻게 고를까

둘 다 많이 사용됩니다.

Kustomize가 좋은 경우:

환경별 차이가 단순함
YAML 커스터마이징 위주
템플릿 로직을 최소화하고 싶음

Helm이 좋은 경우:

반복 파라미터가 많음
재사용 가능한 차트가 필요함
복잡한 패키징이 필요함

중요한 건 도구보다 일관성입니다. 팀 전체가 같은 패턴을 쓰는 편이 운영성이 좋습니다.

App of Apps 패턴

Argo CD를 여러 애플리케이션에 확장할 때 자주 쓰는 구조입니다.

root app
 ├─ platform app
 ├─ monitoring app
 ├─ api app
 └─ worker app

장점:

클러스터 온보딩이 쉬움
공통 컴포넌트 관리가 편함
환경별 애플리케이션 구성이 명확함

단, 처음부터 너무 거대한 트리를 만들면 관리가 복잡해질 수 있으니 적정 수준에서 시작하는 게 좋습니다.

Sync 전략은 어떻게 가져갈까

Argo CD에는 자동 동기화와 수동 동기화가 있습니다.

권장 기준:

dev: 자동 sync 허용
staging: 자동 sync 또는 제한적 승인
prod: PR 승인 + 명시적 sync

프로덕션까지 무조건 자동 sync를 걸어두면 실수 전파 속도도 빨라집니다.

Drift 감지는 왜 중요할까

운영 중 누군가 클러스터에 직접 변경을 가하면 Git과 실제 상태가 달라집니다.

Argo CD는 이 Drift를 보여주기 때문에 다음이 가능해집니다.

누가 수동 변경을 했는지 추적 단서 확보
의도치 않은 변경 롤백
Git 기준 운영 원칙 유지

특히 장애 대응 중 임시 수정이 많이 일어나는 팀이라면 Drift 가시화만으로도 큰 효과가 있습니다.

운영에서 꼭 보는 포인트

Health와 Sync 상태

배포 성공 여부는 Synced만 보면 부족합니다. 실제 리소스 헬스까지 함께 봐야 합니다.

이미지 태그 정책

latest 같은 태그는 피하고, SHA 기반 또는 버전 태그를 쓰는 것이 좋습니다.

롤백 절차

롤백도 Git 변경으로 처리하는 원칙을 유지해야 합니다.

권한 제어

Argo CD UI 접근 권한과 클러스터 권한은 별도로 관리해야 합니다.

흔한 실수

1. GitOps 저장소에 비밀값을 직접 넣는 경우

시크릿은 Sealed Secrets, External Secrets Operator, Vault 같은 별도 체계와 결합해야 합니다.

2. 플랫폼 리소스와 앱 리소스를 한꺼번에 관리하는 경우

문제가 생겼을 때 영향 범위가 너무 커집니다.

3. Sync 실패 알림이 없는 경우

배포 실패를 사람이 늦게 발견하게 됩니다. Slack, Teams, PagerDuty 같은 채널 연동이 필요합니다.

4. 수동 kubectl 사용을 계속 허용하는 경우

GitOps를 도입해도 수동 조작 문화가 그대로면 Drift가 반복됩니다.

마무리

Argo CD와 GitOps의 핵심은 배포 도구를 하나 더 추가하는 것이 아니라, “클러스터 변경의 기준점을 Git으로 통일하는 것”입니다.

이 원칙이 자리잡으면 배포, 감사, 롤백, 운영 실수 방지까지 전체 운영 품질이 같이 올라갑니다.