GitOps는 Git 등 버전 관리 시스템에 선언적으로 정의한 원하는 상태를 진실의 근원으로 삼고, 실행 중인 실제 상태를
지속적으로 관찰·비교한 뒤 차이가 생기면 자동으로 조정하여 일치시키는 방식으로 소프트웨어 애플리케이션과 인프라를
관리하는 운영 방식입니다.
- 상태 조정에는 배포 또는 업데이트를 통해 정의된 상태에 맞게 리소스를 변경하는 것이 포함됩니다.
- GitOps에선 시스템의 상태와 구성은 버전 관리 저장소의 파일에 완전하게 기술되며, 버전과 이력이 불변 형태로 보존됩니다.
Argocd In Actions을 읽고 공신력 있는 사이트들의 말에 따라 GitOps의 원칙을 다음과 같이 정리했습니다.
GitOps의 5가지 원칙
- 선언적 구성
- 버전 제어 불변 저장소
- 자동 배포
- 소프트웨어 에이전트
- 제어 루프
지금부터 GitOps의 5가지 원칙을 하나하나 설명드리겠습니다.
Declarative Configuration (선언적 구성)
GitOps에서는 원하는 상태(Desired State)를 선언적으로 기술합니다.
운영자는 무엇이 최종적으로 성립해야 하는지만 명시하고, 어떻게 그 상태에 도달할지는 에이전트가 수행합니다.
- 지시형(잘못된 예): “컨테이너를 3개 더 실행하라”처럼 절차를 명령합니다.
- 선언형(올바른 예): “해당 애플리케이션의 복제 수는 3이어야 한다”처럼 최종 상태를 규정합니다.
필요한 것은 결과의 조건을 문서화하는 것이며, 실행 순서나 명령은 문서화 대상이 아닙니다.
이렇게 해야 상태 비교와 자동 조정이 일관되게 작동합니다.
Version-controlled immutable storage (버전 제어 불변 저장소)
원하는 상태는 버전 관리되고 불변성이 보장되는 저장소에 보관합니다.
일반적으로 Git을 사용하지만, **동일한 속성(버전·불변·전체 이력 보존)**을 만족하는 시스템이라면 원칙에 부합합니다.
Automated Delivery (자동화된 전달)
최종 상태의 변경 사항이 버전 관리 시스템(Git 등)에 반영되면 배포는 별도의 수동 작업 없이 진행됩니다.
Software agent (소프트웨어 에이전트)
버전 관리 저장소(Git 등)에 구성이 업데이트되면 소프트웨어 에이전트(GitOps 에이전트)는 변경을 자동으로 감지하고,
선언된 구성에 도달하기 위해 필요한 작업을 계산한 뒤 수행하여 실제 상태를 목표 상태에 맞춥니다.
- 변경 감지: 저장소의 변경 커밋을 인지합니다.
- 작업 계산: 원하는 상태와 현재 상태를 비교해 추가·수정·삭제 목록을 산출합니다.
- 적용: 계산된 변경을 시스템에 반영합니다.
- 확인: 적용 결과를 관찰해 목표 상태에 도달했는지 확인합니다.
- 지속 조정: 차이가 남아 있으면 위 과정을 반복하여 일치시킵니다.
Closed loop (제어 루프)
제어 루프는 버전 관리 저장소에 선언된 원하는 상태를 기준으로 실행 중인 실제 상태를 지속적으로 관찰·비교하고,
차이가 감지되면 자동으로 조정하여 원하는 상태에 수렴시키는 반복 절차를 의미합니다.
핵심 속성
- 지속·자동: 사람의 수동 개입 없이 루프가 계속 동작합니다.
- 불변 기준 기반: 기준은 버전 관리 저장소의 커밋처럼 고정된 참조를 사용합니다.
- 드리프트 대응: 외부에서 상태가 바뀌어도 루프가 감지하고 다시 원하는 상태로 되돌립니다.
GitOps가 해결하는 문제들
전통적인 배포 방식에서는 다음과 같은 문제점들이 존재하고 GitOps는 이러한 문제점들을 해결해 줍니다.
- 구성 드리프트: 원하는 상태와 실제 상태의 차이가 누적되어 감지·원인 파악·복구가 어렵습니다.
- 환경 일관성 붕괴: 개발·스테이징·운영(또는 시점별) 설정 불일치로 테스트 신뢰도와 배포 성공률이 떨어집니다.
- 변경 이력·책임 추적 곤란: 누가·언제·무엇을 변경했는지 단일 기준 기록이 없어 감사·원인 분석·롤백 기준점이 없습니다.
- 배포 실패/재현 불가: 절차형 스크립트와 수동 절차 의존으로 실행자·순서에 따라 결과가 달라집니다.
- 복구 시간(MTTR) 증가: 기준 스냅샷(커밋 등)이 없어 실패 시 안전한 복귀 지점 확보가 지연됩니다.
GitOps의 이점
- 단일·통합 프로세스: 인프라·애플리케이션·배포 전 과정을 하나의 동일 절차로 관리합니다.
- 투명성·추적성: PR·커밋 이력으로 누가·언제·무엇을 변경했는지 명확히 남깁니다.
- 신뢰성·보안: 선언형 상태를 기준으로 어긋난 설정을 자동으로 찾아 맞추어 일관성을 유지합니다.
- 롤백/자동 복구: 커밋 기준으로 즉시 롤백하고, 자동 복구로 장애 영향을 최소화합니다.
GitOps 방식에서는 모든 변경 사항을 Pull Request(PR) 기반으로 관리합니다.
직접 push 하지 않고 PR을 거치도록 함으로써 동료 리뷰가 가능해지고, 변경 이력과 책임이 명확해집니다.
운영 중인 리소스는 Git에 기록된 선언과 자동으로 동기화되며, 결과적으로 Git이 실제 상태의 기준이 됩니다
견해
GitOps를 사용했던 1년 반 이상 저는 선언적인 상태를 PR을 거치지 않고 직접적인 push로 dev, prd 등 환경을 가리지
않고 변경했었습니다. PR은 불편하고 인프라에 적용되는 데 있어 시간이 더 오래 걸리는 비효율적인 것으로 인식됐을뿐더러
제가 생각했던 GitOps는 git에 선언적인 상태를 저장하고 변하지 않는 커밋을 기반으로 배포하는 것뿐이라고 생각했기 때문입니다.
- 버전으로 관리되는 커밋만 존재하면 되는데 굳이 왜 PR을 해야 하지? 오래 걸리고 더 나은 것도 없는 것 같은데?
라는 게 지난 시간 동안의 제 현주소였던 것 같습니다.
하지만 git을 통해 버전 관리가 될 수 있고 PR을 활용할 수 있다는 진짜 의의는 동료 리뷰를 통해 배포하려는 상태를 동료에게
더욱 쉽게 이해할 수 있게 하고 최종 상태 변경 단위의 pr을 통해 의도를 명확히 할 수 있는 데 있다고 생각합니다.
‘ArgoCD in Action’라는 책을 읽고 관련 글들을 찾아보면서 PR의 중요성이 반복해서 강조된다는 점을 확인하였습니다.
전 그 PR의 중요성이 대체 뭐길래?라는 의문이 의도를 명확히 설명하고 동료와 지식을 공유하고 논의를 통해 휴먼 오류를 방지하거나
개선한다 라는 핵심으로 이어진 결과 이젠 개발 코드뿐만 아니라 배포를 위한 선언적 상태도 PR로 관리하는 것 같습니다.
저는 GitOps를 관행으로 사용하는 팀이라면 이러한 PR 중심 시스템을 적극 활용할수록 배포가 더 안정화된다고 생각합니다.
의도를 명시한 기록과 동료와의 논의가 축적되면서 배포의 안정성과 깊이를 갖출 수 있다고 생각하고 아직 gitops를
제대로 활용하고 있지 않다면 이 글을 통해 제가 생각한 점들 공감하고 적용될 수 있었으면 좋겠습니다.
참고한 링크 및 문서
'Devops' 카테고리의 다른 글
| Argocd - Application CR 이해하기 (0) | 2026.01.03 |
|---|---|
| Iac- Terraform이란? (0) | 2025.12.13 |
| Argocd - GitOps 활용하기(App of Apps 패턴) (0) | 2025.11.05 |
| GitOps란? 1부: 왜 GitOps인가 (4) | 2025.08.12 |
| Docker 컨테이너 메모리 관리 및 OOM 대응 (0) | 2023.06.25 |
