안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Deploy Amazon EKS workloads with ArgoCD and GitOps]을 확인해보시기 바랍니다.

1. GitOps 개요 및 비전

1-1. GitOps의 등장 배경과 진화

기존 배포 방식의 한계

• 초기에는 단순히 Git → CI/CD → IaC → 상태 파일 → 클라우드(EKS) 흐름으로 배포 가능.
• 하지만 마이크로서비스 증가, 다중 리전 운영, 환경별(개발/스테이징/운영) 분리가 이루어지면서 아래와 같은 문생
  • 배포 복잡도 증가
  • 변경 관리 어려움
  • Source of Truth 불명확성

GitOps의 정의

• Git 리포지토리 하나가 인프라 및 애플리케이션의 단일 진실 공급원(Single Source of Truth)이 되는 운영 모델.

• 모든 상태는 Git에 선언적으로 정의되고 변경은 PR 기반으로 투명하게 추적됨.

GitOps 구성 요소

• IaC(Infrastructure as Code): 인프라를 선언적으로 정의.
• Git Repo: 버전 관리, 감사 로그(audit) 역할.
• CI/CD: 빌드·테스트·이미지 생성 담당.
• GitOps Agent: Git의 의도된 상태를 실제 인프라로 자동 반영.

2. GitOps 핵심 원칙

2-1. 4대 원칙

1. 인프라는 선언적으로 정의되어야 한다
   1. YAML/Helm/IaC로 구성 요소를 명확하게 기술하고 재현성을 확보.
2. 원하는 상태는 Git에 버전 관리된 형태로 저장되어야 한다
   1. 변경 불가(immutable) 기록, PR 리뷰 기반의 통제 가능.
3. GitOps 에이전트는 Git에서 원하는 상태를 가져와야 한다
   1. 자동화된 적용(Apply)으로 예측 가능한 릴리즈 흐름 제공.
4. 에이전트는 실시간으로 상태를 비교하고 드리프트를 수정해야 한다.
   1. 라이브 상태 vs Git 상태 차이를 지속적으로 감지 및 교정.

3. EKS 환경에서의 도전과제

3-1. 플릿(다중 클러스터) 관리의 문제

• 신뢰할 수 있는 단일 원천(Single Source of Truth)의 부재
  • Git? CI 파이프라인 artifact? Terraform state? EKS Live?
• 상태 드리프트(State Drift) 현상의 심화
  • IaC 상태와 실제 Kubernetes 상태 간 불일치가 일어남.
• 대규모 환경일수록 배포 불확실성이 커져 GitOps 필요성이 증가

4. Argo CD기반 GitOps 구현

4-1. Argo CD 소개

• Kubernetes 선언적 지속적 배포(CD) 도구
• Git Repo의 상태를 읽고, 그 상태와 EKS의 라이브 상태를 자동으로 동기화하는 GitOps 에이전트 역할 수행

4-2. Argo CD GitOps Workflow

1. 개발자가 Git에 변경 푸시
2. CI에서 테스트/빌드/이미지 생성
3. PR 승인 → 메인 브랜치 병합 → "새로운 원하는 상태"가 됨
4. Argo CD가 Git에서 최신 상태 감지
5. EKS에 적용 및 지속 동기화
6. 라이브 상태와 Git 상태를 실시간 비교하여 불일치 시 자동 수정

4-3. Argo CD 사용 시 이점

• 명확한 단일 소스(Single Source of Truth)
• 자동 롤백 지원
• 드리프트 자동 감지 및 정정
• 기존 CI/CD와 자연스럽게 결합
• 운영자의 개입 없이도 안정적이고 예측 가능한 배포 프로세스

5. Argo CD 배포 아키텍처 비교

5-1 독립 실행형 멀티 클러스터 모델

• 각 클러스터에 Argo CD 인스턴스를 별도 배포
• 관리 오버헤드 큼, 확장성 낮음

5-2 허브-스포크(Hub-Spoke) 모델

• 중앙(허브)에 단일 Argo CD
• 여러 스포크 클러스터를 리모트 관리
• 계정 간 네트워크 권한 구성 필요
• 스포크 추가 시 Argo CD 구성 변경 필요

5-3 경량(Lightweight) Argo CD 에이전트 모델 

• 중앙(허브)에 메인 Argo CD 배포
• 각 스포크에는 경량 에이전트만 설치
• 경량 에이전트는 outbound 방식으로 허브와 통신해 네트워크 구성 난이도↓
• 확장성 탁월, 중앙 UI/CLI에서 모든 클러스터 관제 가능

6. Argo CD 구성(YAML) 및 동작 원리

6-1 YAML 구성 예시

• Project / Namespace / Destination 클러스터 정의
• Source 섹션에 Git URL, path 설정
• 자동 동기화(auto-sync) 옵션 활성화 가능

6-2 애플리케이션 수명주기(Lifecycle)

• 초기 상태: Synced
• 구성 변경 → OutOfSync
• Argo CD가 자동 또는 수동으로 적용 → 다시 Synced
• 지속 모니터링으로 Git과 EKS의 상태를 일관되게 유지

7. 데모 시연 

1. K8s 클러스터 연결 및 Argo CD 네임스페이스 생성
2. Argo CD 설치, 포트 포워딩 및 관리자 암호 추출
3. UI 접속 후 애플리케이션 YAML 적용
4. 첫 상태는 OutOfSync
5. 수동 Sync → 서비스 및 Replica 2개 배포
6. Git에서 replica 수 2→3 변경 후 푸시
7. Argo CD가 OutOfSync 상태 감지
8. Sync 수행 시 Replica 자동 확대
9. CLI로 라이브 상태 확인

8. 핵심 시사점 및 모범 사례

8-1. IaC 기반 선언적 배포

• 모든 리소스와 변경 흐름은 코드로 정의해야 함

8-2. GitOps 철학 내재화

• 팀 전체가 GitOps 워크플로우를 이해하고 준수해야 성공적인 도입 가능

8-3. 지속적 관찰 가능성 확보

• Argo CD를 통해 상태, 드리프트, 배포 내역을 실시간 투명하게 관리

8-4. 적합한 GitOps 도구 선택

• Argo CD는 강력한 선택지이나, 조직/환경에 따라 Flux 등 다른 도구도 고려 가능

9. 마무리

GitOps는 단순한 배포 자동화를 넘어, 클러스터 규모 확대·서비스 복잡성 증가·멀티 환경 운영 등 현대 애플리케이션 운영이 직면한 핵심 문제들을 해결하는 근본적 운영 모델로 자리 잡고 있다.

특히 Argo CD를 통한 GitOps 구현은 다음과 같은 가치를 제공한다:

• 일관된 배포 체계: 모든 변경이 Git 기반으로 관리되어 환경 간 차이를 제거
• 안정성과 투명성 확보: 드리프트 감지, 롤백 등 운영 리스크 최소화
• 자동화된 운영 효율성: Git 상태만 바꾸면 클러스터 전체가 자동으로 최신 상태 유지
• 확장 가능한 아키텍처: 경량 에이전트 모델을 통한 멀티 클러스터·멀티 계정 효율적 관리