GitOps 배포 전략 Push vs Pull

GitOps는 Git을 단일 진실 공급원(Single Source of Truth)으로 사용하여 인프라와 애플리케이션의 선언적 상태를 관리하고 자동으로 배포하는 운영 방법론으로, 2017년 Weaveworks의 CEO인 Alexis Richardson이 처음으로 이 용어를 제안하면서 클라우드 네이티브 커뮤니티에 소개되었다. GitOps는 개발자들에게 익숙한 Git 워크플로우(Pull Request, 코드 리뷰, 브랜치 전략 등)를 인프라 운영 영역으로 확장한 것으로, Kubernetes와 같은 선언적 인프라 플랫폼과 결합하여 현대적인 DevOps 실천 방법의 핵심 패러다임으로 자리잡았다.

GitOps의 탄생과 핵심 원칙

GitOps란?

모든 인프라 구성과 애플리케이션 설정을 Git 저장소에 선언적으로 정의하고, 이 저장소를 단일 진실 공급원으로 사용하여 실제 시스템 상태를 자동으로 동기화하는 운영 방법론이다.

GitOps라는 용어는 2017년 8월 Weaveworks의 블로그 포스트 “GitOps - Operations by Pull Request"에서 처음 등장했으며, Alexis Richardson은 자사의 Kubernetes 관리 경험을 바탕으로 Git 중심의 운영 방식을 체계화하여 GitOps라는 개념으로 정립했다. 이후 CNCF(Cloud Native Computing Foundation)에서 GitOps Working Group을 결성하여 GitOps의 원칙과 모범 사례를 표준화하는 작업을 진행했으며, 2021년에는 OpenGitOps 프로젝트를 통해 GitOps의 공식 정의와 원칙을 발표했다.

GitOps의 4가지 핵심 원칙

OpenGitOps 프로젝트에서 정의한 GitOps의 핵심 원칙은 다음과 같다.

선언적 정의(Declarative): 시스템의 원하는 상태를 명령어가 아닌 선언문으로 정의해야 하며, Kubernetes의 YAML 매니페스트처럼 “무엇이 되어야 하는가"를 기술하고 “어떻게 하는가"는 시스템에 위임한다.

버전 관리(Versioned and Immutable): 모든 선언적 정의는 Git과 같은 버전 관리 시스템에 저장되어야 하며, 변경 이력이 불변(immutable)하게 보존되어 감사 추적(audit trail)이 가능하고 언제든지 이전 상태로 롤백할 수 있어야 한다.

자동 Pull(Pulled Automatically): 승인된 변경 사항은 소프트웨어 에이전트에 의해 자동으로 시스템에 적용되어야 하며, 사람이 수동으로 kubectl apply와 같은 명령어를 실행하는 것이 아니라 자동화된 프로세스가 지속적으로 Git 상태를 시스템에 반영해야 한다.

지속적 조정(Continuously Reconciled): 소프트웨어 에이전트는 실제 시스템 상태를 지속적으로 관찰하고, Git에 정의된 원하는 상태와 비교하여 차이가 발생하면 자동으로 조정(reconciliation)해야 한다.

Push 방식의 배포 전략

Push 방식이란?

외부의 CI/CD 파이프라인이 빌드 완료 후 클러스터에 직접 배포 명령을 전송하는 방식으로, 전통적인 CI/CD 파이프라인과 유사하게 동작한다.

Push 방식은 Jenkins, GitLab CI, GitHub Actions 등 기존 CI/CD 도구를 활용하여 구현할 수 있으며, CI 파이프라인에서 빌드와 테스트가 완료되면 CD 단계에서 kubectl, Helm, Kustomize 등의 도구를 사용하여 Kubernetes 클러스터에 직접 배포 명령을 전송한다.

Push 방식의 동작 과정

1단계: 소스 코드 변경 및 CI 파이프라인 시작

개발자가 애플리케이션 코드를 수정하고 Git 저장소에 푸시하면 CI 파이프라인이 트리거되어 빌드, 유닛 테스트, 통합 테스트, 정적 분석 등의 검증 과정을 거치고, 모든 검증이 통과하면 컨테이너 이미지를 빌드하여 컨테이너 레지스트리(Docker Hub, AWS ECR, Google GCR 등)에 푸시한다.

2단계: 매니페스트 업데이트

새로운 이미지가 생성되면 CI/CD 파이프라인이 자동으로 Kubernetes 매니페스트 파일(Deployment, Service 등)의 이미지 태그를 업데이트하고, 이 변경 사항을 별도의 설정 저장소(Config Repository)나 동일 저장소의 배포 관련 경로에 커밋한다.

3단계: 클러스터 배포

CD 파이프라인이 업데이트된 매니페스트를 Kubernetes 클러스터에 직접 적용하며, 이 과정에서 CI/CD 서버는 클러스터에 접근하기 위한 kubeconfig 파일이나 서비스 계정 토큰과 같은 인증 정보를 보유해야 한다.

4단계: 배포 검증

배포 후 파이프라인은 롤아웃 상태를 확인하고, 헬스 체크를 수행하며, 필요시 스모크 테스트를 실행하고, 문제가 발견되면 자동 또는 수동으로 롤백을 수행한다.

Push 방식의 장단점

장점:

• 기존 CI/CD 도구와 파이프라인을 그대로 활용할 수 있어 도입 비용이 낮음
• 구현이 직관적이고 개발자들에게 익숙한 워크플로우
• 배포 시점과 내용을 CI/CD 파이프라인에서 완전히 제어 가능
• 다양한 환경(Kubernetes 외 VM, 서버리스 등)에도 동일한 방식 적용 가능

단점:

• CI/CD 서버가 클러스터 접근 권한을 가져야 하므로 보안 위험 존재
• 배포 후 상태 드리프트(drift)가 발생해도 자동으로 감지하거나 복구하지 않음
• 누군가 kubectl로 직접 클러스터를 수정하면 Git 상태와 불일치 발생
• 파이프라인 실패 시 수동 재실행 또는 별도의 재시도 로직 필요

Pull 방식의 배포 전략

Pull 방식이란?

Kubernetes 클러스터 내부에 설치된 GitOps 오퍼레이터가 Git 저장소의 변경을 감지하고, 클러스터 상태를 Git에 정의된 원하는 상태로 자동 동기화하는 방식이다.

Pull 방식은 GitOps의 원래 의도에 더 부합하는 배포 전략으로, ArgoCD와 Flux가 대표적인 구현체이며, 클러스터 내부의 오퍼레이터가 주기적으로 또는 웹훅을 통해 Git 저장소의 변경을 감지하고 이를 클러스터에 반영한다.

Pull 방식의 동작 과정

1단계: 소스 코드 변경 및 이미지 빌드

개발자가 애플리케이션 코드를 수정하고 Git 저장소에 푸시하면 CI 파이프라인이 트리거되어 빌드와 테스트를 수행하고, 검증이 통과하면 새로운 컨테이너 이미지를 레지스트리에 푸시하는데, 여기까지는 Push 방식과 동일하다.

2단계: 매니페스트 저장소 업데이트

CI 파이프라인이 Config Repository의 Kubernetes 매니페스트에서 이미지 태그를 업데이트하고 커밋하거나, 또는 이미지 태그 자동 업데이트 기능(ArgoCD Image Updater, Flux Image Automation 등)을 활용하여 새 이미지를 감지하고 매니페스트를 자동으로 업데이트할 수 있다.

3단계: GitOps 오퍼레이터의 변경 감지

클러스터 내부에서 실행 중인 GitOps 오퍼레이터(ArgoCD Application Controller, Flux Source Controller 등)가 설정된 주기(기본 3분)마다 또는 웹훅 알림을 통해 Git 저장소의 변경을 감지하고, 현재 클러스터 상태와 Git에 정의된 원하는 상태를 비교한다.

4단계: 자동 동기화(Reconciliation)

Git 상태와 클러스터 상태 간에 차이(drift)가 발견되면 오퍼레이터가 자동으로 클러스터를 Git 상태에 맞게 조정하며, 이 조정 과정은 Reconciliation Loop라고 불리며 지속적으로 반복 실행되어 항상 일관된 상태를 유지한다.

5단계: 상태 모니터링 및 Self-Healing

배포 후에도 오퍼레이터는 지속적으로 클러스터 상태를 모니터링하고, 누군가 kubectl로 직접 변경을 가하거나 Pod가 예기치 않게 삭제되는 등의 상황이 발생해도 Git에 정의된 상태로 자동 복구(Self-Healing)한다.

Pull 방식의 장단점

장점:

• 클러스터 접근 권한이 외부로 노출되지 않아 보안성이 높음
• 상태 드리프트를 자동으로 감지하고 복구하는 Self-Healing 기능
• Git 저장소가 유일한 진실 공급원으로 작동하여 일관성 보장
• Reconciliation Loop를 통한 지속적인 상태 동기화
• 장애 발생 시 자동 재시도 및 복구

단점:

• 전용 GitOps 도구(ArgoCD, Flux) 설치 및 운영 필요
• 기존 CI/CD 파이프라인과 별도로 GitOps 워크플로우 학습 필요
• 초기 설정 및 구성이 Push 방식보다 복잡할 수 있음
• 디버깅 시 파이프라인 로그 대신 오퍼레이터 로그 확인 필요

Push 방식과 Pull 방식 비교

두 배포 전략은 핵심적인 차이점이 있으며, 조직의 상황과 요구사항에 따라 적절한 방식을 선택해야 한다.

주요 GitOps 도구 비교

ArgoCD

ArgoCD는 2018년 Intuit에서 개발하여 오픈소스로 공개한 Kubernetes 네이티브 GitOps 도구로, 현재 CNCF Graduated 프로젝트로 선정되어 클라우드 네이티브 생태계에서 가장 널리 사용되는 GitOps 도구 중 하나이다.

핵심 특징:

• 직관적인 웹 UI 대시보드로 애플리케이션 상태와 동기화 현황을 시각적으로 확인 가능
• 멀티 클러스터 관리를 기본 지원하여 여러 Kubernetes 클러스터를 중앙에서 관리
• Blue/Green, Canary, Progressive Delivery 등 다양한 배포 전략을 Argo Rollouts와 연계하여 지원
• RBAC(Role-Based Access Control)를 통한 세밀한 권한 관리
• SSO(Single Sign-On) 통합 지원(OIDC, SAML, LDAP 등)
• ApplicationSet을 통한 대규모 애플리케이션 템플릿화 및 자동 생성

적합한 환경:

• 팀 규모가 크고 다양한 역할의 사용자가 배포 상태를 확인해야 하는 경우
• 멀티 클러스터 환경에서 중앙 집중식 관리가 필요한 경우
• 복잡한 배포 전략(Canary, Blue/Green)을 적용해야 하는 경우
• 강력한 UI와 시각화가 중요한 경우

Flux

Flux는 Weaveworks에서 개발한 GitOps 도구로, GitOps라는 용어를 처음 만든 회사에서 직접 개발한 도구이며, 현재 CNCF Graduated 프로젝트로 선정되어 ArgoCD와 함께 GitOps 도구의 양대 산맥을 이루고 있다.

핵심 특징:

• GitOps Toolkit이라는 컨트롤러 집합으로 구성되어 모듈화된 아키텍처 제공
• Helm과 Kustomize를 네이티브로 지원하여 기존 Kubernetes 패키지 관리 방식과 자연스럽게 통합
• 이미지 자동 업데이트 기능(Image Automation Controller)으로 새 이미지 감지 시 자동 배포
• 경량화된 설계로 리소스 사용량이 적음
• CLI 중심의 워크플로우로 자동화 및 스크립팅에 적합
• 알림 컨트롤러를 통해 Slack, Microsoft Teams, Discord 등으로 배포 상태 알림

적합한 환경:

• CLI와 자동화 중심의 워크플로우를 선호하는 경우
• 리소스가 제한된 환경에서 경량 솔루션이 필요한 경우
• Helm과 Kustomize를 적극 활용하는 경우
• 모듈화된 아키텍처로 필요한 기능만 선택적으로 사용하고 싶은 경우

ArgoCD vs Flux 비교

도구 선택 가이드

조직의 상황과 요구사항에 따라 적절한 GitOps 도구를 선택하는 것이 중요하며, 다음 기준을 고려하여 결정할 수 있다.

ArgoCD를 선택해야 하는 경우:

• 개발자, 운영자, 관리자 등 다양한 역할의 팀원이 배포 상태를 직관적으로 확인해야 하는 경우
• 멀티 클러스터를 중앙에서 통합 관리해야 하는 경우
• Canary, Blue/Green 등 고급 배포 전략이 필요한 경우
• GitOps 도입 초기 단계로 시각적 피드백이 학습에 도움이 되는 경우

Flux를 선택해야 하는 경우:

• CLI와 자동화 중심의 워크플로우를 선호하고 UI가 필수적이지 않은 경우
• 리소스가 제한적이거나 경량 솔루션이 필요한 경우
• Helm과 Kustomize를 핵심 도구로 사용하는 경우
• 모듈화된 아키텍처로 필요한 기능만 선택적으로 구성하고 싶은 경우

Push 방식(Jenkins, GitLab CI 등)을 유지해야 하는 경우:

• 기존 CI/CD 파이프라인 투자가 크고 당장 전환이 어려운 경우
• GitOps 도입 초기 단계로 점진적 전환을 계획하는 경우
• Kubernetes 외에 VM, 서버리스 등 다양한 환경을 동일한 방식으로 배포해야 하는 경우
• 레거시 시스템과의 통합이 필수적인 경우

결론

GitOps는 2017년 Weaveworks에서 탄생한 이후 클라우드 네이티브 환경에서의 배포 자동화를 위한 핵심 패러다임으로 자리잡았으며, Push 방식과 Pull 방식은 각각의 장단점을 가지고 있다. Push 방식은 기존 CI/CD 도구를 활용할 수 있어 도입이 쉽지만 보안성과 상태 일관성 측면에서 제약이 있고, Pull 방식은 보안성과 Self-Healing 기능이 우수하지만 전용 도구 도입과 학습이 필요하다. ArgoCD는 강력한 UI와 멀티 클러스터 지원으로 대규모 팀에 적합하고, Flux는 경량화된 CLI 중심 워크플로우로 자동화 선호 팀에 적합하다. 조직의 규모, 기술 역량, 보안 요구사항, 기존 인프라 등을 종합적으로 고려하여 적절한 전략과 도구를 선택해야 하며, 어떤 방식을 선택하든 Git을 단일 진실 공급원으로 활용하여 일관되고 추적 가능한 배포 프로세스를 구축하는 것이 GitOps의 핵심 가치이다.