소프트웨어 기업 Octopus Deploy의 2025년 설문 조사에 따르면, 이미 GitOps를 도입한 조직 중 93%가 GitOps를 계속 또는 확대해서 도입할 예정이라고 응답했다고 합니다.
이렇듯 GitOps는 조직 입장에서도 안정성을 인정받는 트렌드라고 볼 수 있는데요.
이번 아티클에선 GitOps 도입과 활용에 도움이 될 수 있도록 GitOps와 다른 관련 방법론들을 비교하고 정리해봅니다. 그리고 대표적인 배포 전략도 GitOps 관점에서 알아볼 예정입니다. 여기서 다루는 내용 중에 아직 헷갈리는 키워드가 있다면 이번 기회에 제대로 잡아보세요.
GitOps와 다른 방법론 비교
개발팀-운영팀 간의 원활한 협업과 자동화 등, DevOps의 가치를 실현하려는 방법론은 지금까지 다양하게 등장해왔습니다. 이런 방법론들과 GitOps와의 차이를 이해하는 것은 GitOps를 활용하는 데에 필수적인데요.
그래서 GitOps와 DevOps, Iac 등 여러 방법론들을 비교하고 정리해보겠습니다.
GitOps와 DevOps
가장 먼저 GitOps와 DevOps의 관계를 살펴보겠습니다.
GitOps는 개발자가 Git 저장소에 코드를 Push하는 것만으로 배포를 가능하게 하고, 운영자가 Git을 통해 모든 배포 상태를 명확히 파악할 수 있도록 하여 두 팀 간의 협업을 촉진합니다.
그래서 GitOps는 DevOps 문화의 핵심 가치인 개발팀과 운영팀 간의 긴밀한 협업을 Git 기반으로 구현한 것이라고 할 수 있습니다.
즉, DevOps 문화를 좀 더 구체적인 툴과 시스템으로 구현한 것이 GitOps입니다.
GitOps와 DevSecOps
모든 인프라 및 애플리케이션 구성 변경이 Git과 Pull Request를 통해 이루어지는 GitOps는 자동화된 보안 검사(예: 정적 분석, 취약점 스캔)와 통합되기 매우 용이합니다. Pull Request로 트리거되는 CI 파이프라인에 보안 검사를 수행하는 과정을 추가하는 방식으로 말이죠.
또한 Git 저장소의 접근 제어와 브랜치 보호 규칙을 통해 누가 시스템을 변경할 수 있는지를 엄격하게 통제할 수 있습니다. GitOps에서 Git 저장소는 단일 진실 공급원이기 때문에 이런 보안 조치가 필수입니다.
단일 진실 공급원(Single Source of Truth, SSoT)이란?
시스템이 참조할 수 있는 진짜 정보가 있는 단 하나의 저장소를 의미합니다. GitOps에선 Desired State를 오로지 Git 저장소에만 저장되고 변경되므로 Git 저장소가 단일 진실 공급원이라고 할 수 있습니다. Aiden’s Lab의 관련 아티클
이렇게 GitOps는 개발 초기 단계부터 보안을 고려하는 DevSecOps 문화를 효과적으로 실현 가능합니다.
GitOps와 Configuration as Code
Configuration as Code(CaC)는 인프라 또는 애플리케이션의 설정(Configuration)을 스크립트나 선언적 코드 파일로 관리하는 방법론입니다.
GitOps에서는 Kubernetes 매니페스트(YAML)를 사용하여 애플리케이션의 구성(배포 버전, 리소스 요구량, 환경 변수 등)을 코드로 명확하게 정의하고, 이를 Git으로 버전 관리함으로써 CaC를 실현할 수 있는데요.
그래서 구성 변경 사항을 투명하게 추적하고 검토할 수 있게 됩니다.
GitOps와 Infrastructure as Code
Infrastructure as Code(IaC)는 인프라(VM, 네트워크 등)를 코드로 관리하는 방법론입니다.
IaC 역시 GitOps에서 실현 가능한데요. Terraform이나 Pulumi와 같은 IaC 도구의 인프라 코드를 Git 저장소에 저장하고 관리함으로써 인프라 코드의 변경 사항을 추적할 수 있는 겁니다.
또한 이런 인프라 코드는 GitOps에서의 Desired State가 되죠.
GitOps의 Desired State란?
‘바람직한 상태’ 또는 ‘원하는 상태’란 뜻의 Desired State는 Git 저장소에 코드로 정의된 시스템의 ‘최종 목표 구성’을 의미합니다. Kubernetes 클러스터에 배포할 애플리케이션의 매니페스트 YAML 파일이나, Terraform이 사용하는 인프라 정의 코드가 GitOps에서 사용될 때 Desired State라고 할 수 있습니다. Aiden’s Lab의 관련 아티클
Progressive Delivery 패턴
실제 GitOps를 도입하거나 활용할 때 배포 패턴에 대한 이해가 있다면 훨씬 수월해집니다. 결국 GitOps는 Git에 저장된 시스템의 상태를 클러스터에 배포하는 과정을 다루기 때문이죠.
특히 점진적 전달이 가능한 배포 패턴이 중요합니다. 그래서 GitOps에서의 점진적 전달 배포 패턴 2가지를 알아보겠습니다.
점진적 전달(Progressive Delivery)이란?
제품의 새로운 버전(업데이트)을 한 번에 배포하지 않고 일부 사용자에게 먼저 배포 후, 점차 그 비중을 늘려가는 배포 방식을 말합니다. 릴리즈한 새 버전에서 문제가 발생해도 그 영향을 최소화하고 다시 이전 버전으로 롤백하기 유리한 전략입니다.
Canary 패턴
GitOps 워크플로우에서는 Argo Rollouts, Flagger 등의 점진적 배포 툴과 통합해서 Canary 패턴으로 애플리케이션을 배포할 수 있습니다. (Argo 프로젝트 툴 중 하나인 Argo Rollouts는 이전 아티클에서 다룬 적이 있습니다.)
Git 저장소에 저장되는 매니페스트 파일에서 트래픽 가중치(예: stable: 90%, canary: 10%)를 변경하는 것만으로도, 새로운 애플리케이션 버전을 일부 사용자에게만 먼저 배포하는 Canary 배포를 수행할 수 있는 것입니다.
이를 통해 새 버전의 안정성을 실제 트래픽으로 검증하여 위험을 최소화할 수 있죠.
(출처: https://www.tatvasoft.com/outsourcing/2024/05/canary-vs-blue-green-deployment.html)
Blue/Green 패턴
Blue/Green 배포는 현재 운영 중인 버전(Blue)과 동일한 환경에 새로운 버전(Green)을 배포한 후, 트래픽을 한 번에 전환하는 전략입니다.
GitOps 워크플로우에서는 Git에 저장된 매니페스트를 수정하여 트래픽 라우팅 대상을 Green 버전으로 직접 변경하거나, Argo Rollouts를 통해서 Blue/Green 패턴으로 배포할 수 있습니다.
문제가 발생하면 즉시 트래픽을 다시 Blue 버전으로 되돌릴 수도 있어, 다운타임 없는 안전한 배포가 가능합니다.
마무리
DevOps 문화를 보다 안정적이고 효율적으로 구현하기 위해 등장한 GitOps는 이제 꼭 알아야 할 방법론이 되었습니다.
GitOps 방법론 자체에 대한 개념과 원리도 중요하지만, DevOps와 관련된 다른 방법론과 GitOps가 어떤 관계이고 어떻게 상호작용하는지를 알면 GitOps를 더 깊이 있게 이해하고 활용할 수 있습니다.
그래서 이번 아티클에서 GitOps와 다른 방법론, 그리고 배포 전략까지 함께 비교하며 정리해봤는데요.
GitOps를 더 깊이 이해하는 데에 도움이 되셨나요?
혹시 GitOps에 대해 더 다뤄줬으면 하는 주제가 있다면 아래 피드백으로 알려주세요. Aiden’s Lab 뉴스레터는 여러분의 의견과 피드백을 적극 반영하여 운영되고 있습니다.
그럼 다음 아티클에서 더 유익하고 흥미로운 주제로 찾아오겠습니다.
감사합니다.😸
참고 자료
✨이번 아티클은 어떠셨나요?
이번 글의 주제에 대해 어떻게 생각하는지 알려주세요! 더 나은 아티클을 전달해드리기 위해 아래 폼에서 짧은 피드백을 받고 있어요.
여러분들의 소중한 의견은 Aiden’s Lab에 큰 힘이 됩니다!