기존에는 Istio Gateway와 같은 인프라 리소스를 로컬 환경에서 kubectl apply로 반영했다. 이 방식은 변경 이력과 실제 클러스터 상태가 달라질 수 있고, 작업자에게 직접 접근 권한을 부여해야 했다. 이를 Argo CD 기반 GitOps로 전환한 배경과 운영 방식의 변화를 정리한다.
기존 방식의 불안함
기존에는 Helm chart나 매니페스트를 로컬에서 kubectl apply로 클러스터에 직접 적용했다. 배포 자체는 가능했지만 다음과 같은 운영 문제가 남았다.
- Git의 선언 상태와 클러스터의 실제 상태가 일치한다고 보장하기 어려웠다.
- 변경을 적용하는 것도, 변경을 감지하는 것도 모두 사람의 몫이었다.
- 감사 추적이라곤 CLI 로그뿐이라 "이 리소스 누가 바꿨지?"라는 질문에 답하기가 어려웠다.
- 롤백하려면 백업을 따로 떠 두었다가 그걸 다시 적용해야 했다.
- 그리고 운영자가 클러스터에 직접 접근할 권한을 늘 들고 있어야 했다.
GitOps로 바꾼 흐름
ArgoCD를 도입한 뒤로 배포 흐름은 이렇게 단순해졌다. Istio Gateway Helm chart를 수정하는 경우를 예로 든다.
1. 엔지니어가 Bitbucket 저장소의 Helm chart를 수정 (PR)
2. ArgoCD가 저장소 변경을 polling으로 주기 확인
3. Git hash 변경 감지 → ArgoCD가 sync 자동 트리거
4. 변경 내용이 Kubernetes 클러스터에 자동 반영
5. Istio Gateway 리소스 업데이트
6. sync 완료 여부를 엔지니어에게 피드백
Helm chart를 수정해 저장소에 올리면 ArgoCD가 변경을 감지해 클러스터에 자동으로 반영한다.
핵심은 Git에 머지하는 것이 곧 배포가 됐다는 점이다. 더 이상 클러스터를 직접 만지지 않는다.
무엇이 달라졌나
| 항목 | 기존 kubectl 수동 배포 | ArgoCD GitOps |
|---|---|---|
| 배포 방식 | 수동 kubectl apply | Git 변경 감지 기반 자동 sync |
| 버전 관리 | Git은 단순 백업 | Git이 단일 진실 소스 |
| 변경 감지 | 사람이 수동 확인 | ArgoCD가 자동 감지 |
| 감사 추적 | CLI 로그만 존재 | Git commit과 Argo CD 이력으로 추적 |
| 재현성 | 상태 불일치 가능 | 선언 상태와 실제 상태의 차이 감지·동기화 |
| 롤백 | 수동 백업·적용 | git revert → 자동 재배포 |
| 보안 | 운영자가 직접 kubectl | 일반 배포의 클러스터 직접 접근 최소화 |
도입 후 달라진 점
- 운영 안정성 — Git을 기준으로 상태 차이를 감지하고 설정에 따라 자동 동기화한다.
- 수동 작업 감소 — 일반적인 변경은 PR과 sync 과정으로 처리한다.
- 협업 — 인프라 변경도 PR 리뷰를 거친다. 코드와 같은 절차로 인프라 변경을 검토할 수 있게 됐다.
- 보안 — 일반 배포자의 클러스터 직접 접근을 줄였다. 장애 대응용 접근 권한은 별도 절차로 유지한다.
- 롤백 — 이전 commit으로 되돌린 뒤 다시 동기화할 수 있다.
- 멀티 클러스터 확장 — 저장소 하나로 여러 클러스터를 관리할 수 있다.
돌아보며
GitOps 도입 후 선언한 상태와 클러스터의 차이를 지속적으로 확인할 수 있게 됐다. 장애 조사에서는 Git commit과 Argo CD 동기화 이력을 함께 확인하고, 복구 시에는 이전 commit으로 되돌린 뒤 실제 상태가 정상적으로 동기화됐는지 검증한다.
GitOps 전환의 직접적인 계기는 43분간 이어진 배포 장애였다. 수동 배포와 Helm·YAML 병행 관리가 복구를 지연시킨 과정은 별도 글에 정리했다. 이 장애 이후 배포 정의와 변경 이력을 Git으로 일원화했다.
참고