1. GitOps 도구의 필요성
- Git에 변경이 생겼는지 누가 감지할 것인가
- 변경이 생기면 누가 클러스터에 반영할 것인가
- Git 상태와 실제 클러스터 상태가 다른지 누가 비교할 것인가
- 운영자가 클러스터를 직접 수정했을 때 누가 원래 상태로 되돌릴 것인가
즉, GitOps는 단순히 Git 저장소를 사용하는 것이 아니라
Git 상태를 실제 시스템과 계속 맞추는 운영 메커니즘이 필요함.
1.2 GitOps 도구의 역할
GitOps 도구는 보통 다음 역할을 수행함.
- Git 저장소 감시
- 변경 감지
- Kubernetes 리소스 렌더링 및 적용
- 실제 상태와 원하는 상태 비교
- 차이 감지 및 동기화
- 상태 시각화
- 운영 이력 확인
즉, GitOps 도구는 Git과 Kubernetes 사이에서 상태 동기화 컨트롤러 역할을 한다.
2. Argo CD란 무엇인가
2.1 Argo CD의 정의
Argo CD는 Kubernetes 환경에서 GitOps 방식 배포를 구현하기 위한 대표적인 오픈소스 도구다.
Argo CD는 Git 저장소를 애플리케이션의 원하는 상태가 정의된 기준점으로 보고, 클러스터의 실제 상태를 그 Git 상태에 맞추도록 동작한다.
즉, Argo CD는 단순히 배포 명령을 대신 실행하는 도구가 아니라,
Git 저장소를 기준으로 클러스터 상태를 지속적으로 관리하는 도구다.
2.2 Argo CD가 많이 쓰이는 이유
Argo CD가 널리 쓰이는 이유는 다음과 같음.
- Kubernetes와 GitOps 철학에 잘 맞음
- Git 상태와 실제 상태 차이를 시각적으로 보여줌
- 수동/자동 동기화 모두 지원함
- 멀티 애플리케이션 관리가 쉬움
- Helm, Kustomize 등과 잘 연동됨
- 운영자가 현재 상태를 이해하기 쉬운 UI를 제공함
즉, Argo CD는 GitOps 개념을 실제 운영에 적용할 수 있게 해주는 실용적 도구다.
3. Argo CD가 필요한 이유
3.1 CI 도구가 직접 배포하는 방식의 한계
전통적인 방식에서는 Jenkins나 GitHub Actions가 직접 Kubernetes에 배포할 수 있음.
예:
kubectl apply- Helm install/upgrade
- kubeconfig 기반 직접 반영
이 방식은 익숙하고 단순해 보일 수 있지만, 다음 문제가 생기기 쉬움.
- CI 도구가 클러스터에 대한 많은 권한을 가져야 함
- 실제 클러스터 상태와 Git 상태를 계속 비교하지 않음
- 누군가 클러스터를 수동 수정하면 Drift가 생김
- "배포는 했지만 현재 상태가 기준과 같은가"를 알기 어려움
즉, CI 도구 직접 배포는 "반영"에는 강하지만, 지속적 상태 관리에는 한계가 있을 수 있음.
3.2 Argo CD는 배포보다 상태 동기화에 강함
Argo CD의 핵심은 "명령을 한 번 실행한다"가 아니라,
Git에 적힌 상태를 계속 유지하려 한다는 점이다.
즉, Argo CD는 다음 질문에 답하기 쉬움.
- Git 기준 현재 어떤 버전이 배포돼야 하는가
- 클러스터 상태가 Git과 일치하는가
- 차이가 있다면 무엇이 다른가
- 원래 상태로 되돌릴 수 있는가
이 구조가 GitOps 운영의 핵심 가치다.
4. Argo CD의 기본 동작 흐름
Argo CD의 기본 흐름은 다음처럼 이해할 수 있음.
Git 저장소에 매니페스트 존재
↓
Argo CD가 저장소 감시
↓
변경 감지
↓
원하는 상태 렌더링
↓
클러스터의 실제 상태와 비교
↓
차이가 있으면 Sync 수행
↓
클러스터 상태를 Git 기준으로 맞춤이 구조에서 중요한 점은
Argo CD가 "변경 감지"와 "상태 비교"와 "동기화"를 모두 맡는다는 점이다.
5. Argo CD의 핵심 구성 개념
Argo CD를 이해할 때 자주 등장하는 핵심 개념 몇 가지를 먼저 정리해야 함.
5.1 Application
의미
Argo CD에서 Application은 배포 및 동기화 관리의 기본 단위다.
"이 Git 저장소의 특정 경로에 있는 매니페스트를 이 클러스터의 특정 네임스페이스에 반영하라"는 정의라고 볼 수 있음.
즉, Application은 다음을 연결함.
- 어떤 Git 저장소인가
- 어떤 경로인가
- 어떤 브랜치/리비전인가
- 어떤 클러스터인가
- 어떤 네임스페이스인가
Application은 Argo CD에서 가장 중요한 객체다.
5.2 Source
Source는 원하는 상태가 어디에 정의되어 있는지를 의미함.
예:
- Git 저장소 URL
- 특정 경로
- 특정 브랜치
- 특정 태그
- Helm chart source
즉, Argo CD는 Source를 통해 "무엇을 기준으로 삼을지"를 결정함.
5.3 Destination
Destination은 실제로 반영할 대상 위치다.
예:
- Kubernetes 클러스터
- 특정 네임스페이스
즉, Source가 기준점이라면 Destination은 반영 대상이다.
5.4 Sync Policy
Sync Policy는 Git 상태를 실제 클러스터에 어떤 방식으로 반영할지를 정하는 정책이다.
예:
- 수동 동기화
- 자동 동기화
- 차이 발생 시 자동 복원
- 불필요 리소스 자동 제거(prune)
즉, Argo CD는 단순 감시만 하는 것이 아니라
차이가 생겼을 때 어떤 행동을 할지 정책적으로 결정할 수 있음.
6. Argo CD가 보는 상태 개념
Argo CD는 상태를 매우 중요하게 다룸.
대표적으로 자주 보는 상태가 있음.
6.1 Sync Status
Sync Status는 Git에 정의된 원하는 상태와 클러스터 실제 상태가 일치하는지를 보여줌.
대표 상태:
SyncedOutOfSync
Synced
Git 기준 상태와 실제 클러스터 상태가 일치함.
OutOfSync
Git 기준 상태와 실제 상태가 다름.
이 상태는 GitOps 운영에서 매우 중요함.
왜냐하면 "배포를 했는가"보다 "현재 기준 상태와 같은가"가 더 중요하기 때문임.
6.2 Health Status
Health Status는 애플리케이션 리소스가 정상적으로 동작하고 있는지를 보여줌.
대표 상태 예:
HealthyProgressingDegradedMissing
즉, Sync와 Health는 다름.
- Sync: Git과 같은가
- Health: 실제 리소스가 정상 동작 중인가
이 구분은 매우 중요함.
예를 들어,
- Sync는 맞지만 Pod가 Crash 상태일 수 있음
- Health는 괜찮아 보여도 Git 기준과 다른 설정일 수 있음
즉, 두 가지 정보를 확인해야 운영 상태를 제대로 이해할 수 있음.
7. 수동 동기화와 자동 동기화
Argo CD는 동기화 방식을 크게 두 가지로 볼 수 있음.
7.1 수동 동기화(Manual Sync)
Git에 변경이 있어도 Argo CD가 자동으로 적용하지 않고, 운영자가 확인 후 Sync를 수행하는 방식이다.
장점
- 운영 반영 전에 사람이 확인 가능
- 실수 반영을 줄일 수 있음
- 운영 승인 절차와 결합하기 쉬움
한계
- 자동화 수준이 낮아짐
- 반영 지연 가능
- 운영자 개입이 필요함
즉, 수동 동기화는 GitOps이면서도 통제 중심 운영에 가깝다.
7.2 자동 동기화(Auto Sync)
Git에 변경이 생기면 Argo CD가 이를 감지하고 자동으로 클러스터에 반영하는 방식이다.
장점
- 완전한 Git 중심 운영 가능
- 반영 속도 빠름
- 수동 개입 감소
- 운영 표준화 강함
한계
- 잘못된 Git 변경이 바로 반영될 수 있음
- 리뷰/승인 구조가 약하면 위험할 수 있음
즉, 자동 동기화는 강력하지만
Git 저장소에 대한 통제가 충분히 갖춰져 있어야 안전함.
8. Drift 감지와 복원
8.1 Drift란 무엇인가
Drift는 Git에 정의된 상태와 실제 클러스터 상태가 어긋나는 현상을 의미함.
예:
- 운영자가 직접
kubectl edit로 수정 - 수동으로 replica 변경
- 일부 리소스 삭제
- 설정값 임시 변경
이런 변화가 Git에 반영되지 않으면 Drift가 생김.
8.2 Argo CD는 Drift를 어떻게 다루는가
Argo CD는 Git 상태와 실제 상태를 비교해서 OutOfSync를 표시할 수 있음.
정책에 따라 다음도 가능함.
- 차이만 보여주고 운영자가 판단
- Sync를 통해 Git 기준으로 다시 맞춤
- 자동 동기화로 원래 상태 복원
즉, Argo CD는 단순 배포 도구가 아니라
운영 환경의 무단 또는 임시 변경을 감지하는 감시 장치 역할도 함.
9. Argo CD와 Kubernetes 선언형 구조의 관계
Argo CD가 잘 동작하는 이유는 Kubernetes 자체가 선언형 모델이기 때문임.
9.1 YAML 기반 원하는 상태 정의
Argo CD는 Git에 있는 YAML, Helm, Kustomize 결과를 원하는 상태로 해석함.
9.2 Kubernetes는 그 상태를 유지하려고 함
Argo CD가 반영하면 Kubernetes 내부 컨트롤러가 세부 상태를 맞춰감.
즉, Argo CD와 Kubernetes는 역할이 다름.
- Argo CD: Git과 클러스터 상태 동기화
- Kubernetes: 클러스터 내부 실행 상태 유지
이 둘이 합쳐져 GitOps 운영 모델이 완성됨.
10. Argo CD와 CI의 역할 분리
10.1 CI가 하는 일
- 소스코드 빌드
- 테스트
- 이미지 생성
- 이미지 레지스트리 Push
10.2 Argo CD가 하는 일
- Git 저장소의 배포 상태 감시
- 변경 감지
- 클러스터 반영
- 상태 비교 및 동기화
즉, Argo CD는 빌드 도구가 아님.
또한 테스트 도구도 아님.
Argo CD는 배포 상태 동기화 도구다.
11. Git 저장소 구조와 Argo CD
Argo CD를 운영할 때는 저장소 구조가 매우 중요함.
11.1 대표 구조 예시
단일 앱 단일 환경
- app1/dev
- app1/prod
다중 앱 다중 환경
- apps/app1/dev
- apps/app1/prod
- apps/app2/dev
- apps/app2/prod
즉, Git 저장소 안에서 환경 구분과 애플리케이션 구분이 명확해야 Argo CD 운영도 쉬워짐.
11.2 왜 구조가 중요한가
저장소 구조가 혼란스러우면 다음 문제가 생김.
- 어떤 Application이 어떤 경로를 보는지 불명확함
- dev와 prod가 섞임
- 승인/리뷰 범위가 애매해짐
- 이미지 태그 반영 위치를 찾기 어려움
즉, Argo CD는 강력하지만, 정리된 Git 구조 위에서 더 큰 힘을 발휘함.
12. Argo CD의 장점
12.1 Git 중심 운영 가시성
운영 상태 기준이 명확해짐.
12.2 Drift 감지
수동 변경이나 상태 어긋남을 발견하기 쉬움.
12.3 수동/자동 동기화 선택 가능
조직 성숙도에 따라 조절 가능함.
12.4 멀티 애플리케이션 관리 용이
여러 앱을 중앙에서 상태 확인 가능함.
12.5 GitOps 운영 실현
Git 변경 → 상태 동기화 구조를 실무에 적용하기 좋음.
13. Argo CD 운영 시 주의점
13.1 Git 변경 통제가 매우 중요함
자동 동기화를 쓰면 Git merge가 곧 운영 반영으로 이어질 수 있음.
13.2 클러스터 직접 수정을 줄여야 함
직접 수정이 많아지면 Drift가 반복되고 운영 원칙이 흔들림.
13.3 Sync와 Health를 구분해서 봐야 함
둘 중 하나만 보고 판단하면 오해가 생길 수 있음.
13.4 저장소 구조 설계가 중요함
환경과 앱 구분이 흐리면 운영이 복잡해짐.
13.5 Argo CD 자체도 운영 대상임
접근 권한, UI 보안, 클러스터 연결, 장애 대응을 고려해야 함.
14. 아키텍처 관점에서 본 Argo CD 운영 구조
Application Source Repository
↓
CI Pipeline
├─ Build
├─ Test
└─ Image Push
↓
GitOps Repository
└─ Kubernetes Manifest / Helm / Kustomize
↓
Argo CD
├─ Git 감시
├─ 상태 비교
├─ Sync 수행
└─ Health 확인
↓
Kubernetes Cluster이 구조에서 중요한 점은 다음임.
- CI와 Argo CD의 역할이 분리됨
- GitOps 저장소가 운영 기준점이 됨
- Argo CD가 Git과 클러스터를 이어주는 핵심 컨트롤러 역할을 함
- 운영자는 UI와 상태를 통해 현재 상태를 파악할 수 있음
요약
- Argo CD는 Kubernetes 환경에서 GitOps를 구현하는 대표 도구임
- Git 저장소의 원하는 상태와 클러스터 실제 상태를 비교하고 동기화함
- 핵심 객체는 Application이며, Source와 Destination을 연결함
- Sync Status는 Git과의 일치 여부, Health Status는 실제 동작 정상 여부를 의미함
- 수동 동기화와 자동 동기화는 운영 통제 수준에 따라 선택 가능함
- Drift 감지와 복구는 Argo CD의 중요한 운영 가치 중 하나임
- Argo CD는 CI를 대체하지 않으며, 빌드가 아닌 배포 상태 동기화를 담당함
- Git 구조, 권한 정책, 승인 절차가 함께 설계돼야 안정적인 GitOps 운영이 가능함
