GitOps란 무엇인가: OpenGitOps 4원칙과 CI/CD 차이

GitOps는 Kubernetes YAML을 Git에 올리는 이름이 아니다. desired state를 선언하고 version history를 남긴 뒤, software agent가 source에서 이를 가져와 actual state와 계속 맞추는 운영 model이다. GitOps란 무엇인지 판단하려면 도구 이름보다 reconciliation이 실제로 존재하는지 봐야 한다.

『GitOps Cookbook』 1장을 읽으며 정리했던 개념을 OpenGitOps v1.0.0 원칙과 현재의 CI·CD 경계에 맞춰 다시 구성했다.

OpenGitOps는 네 원칙으로 범위를 정한다

OpenGitOps가 제시한 네 원칙은 다음과 같다.

원칙	뜻	확인할 증거
Declarative	system의 desired state를 선언으로 표현	manifest·policy·configuration
Versioned and Immutable	desired state의 version과 전체 history를 보존	commit·tag·artifact revision
Pulled Automatically	software agent가 source에서 선언을 자동으로 가져옴	controller identity·fetch log
Continuously Reconciled	actual state를 관찰하고 desired state 적용을 계속 시도	diff·sync status·event

Git을 흔히 source로 쓰지만 원칙의 핵심은 repository 브랜드가 아니라 versioned desired state와 pull·reconcile loop다. PR review는 변경 품질을 높이는 workflow이고, agent는 그 결과를 system에 적용하고 drift를 감지하는 실행 주체다.

비슷해 보여도 GitOps가 아닌 경우

구성	빠진 부분
YAML을 Git에 저장만 함	자동 pull과 continuous reconciliation 없음
merge 뒤 CI가 kubectl apply	cluster로 push하는 CD이며 agent pull model과 다름
사람이 매주 repository를 apply	자동 pull·지속적 관찰이 아님
Argo CD를 설치했지만 app은 CLI로만 생성	declarative source와 변경 history가 일부 밖에 남을 수 있음
drift alert만 있고 적용은 항상 수동	reconciliation policy는 있으나 자동 적용 범위를 명확히 표현해야 함

Manual approval을 쓰면 GitOps가 아니라고 단정할 필요는 없다. agent가 source를 pull해 diff를 계속 관찰하고, 승인 뒤 그 desired state를 적용하는 구조일 수 있다. 중요한 것은 자동화의 유무를 한 단어로 뭉개지 않고 detection, approval, apply 단계를 분리하는 일이다.

CI는 artifact를 만들고 GitOps CD는 desired state를 맞춘다

CI와 GitOps CD를 한 pipeline으로 표현하면 책임이 잘 보인다.

application source commit
  → CI test·build·scan
  → immutable image digest
  → config repository의 digest 변경 PR
  → review·merge
  → GitOps agent가 pull·compare·reconcile
  → workload 검증

CI의 output은 재현 가능한 artifact와 검증 기록이다. GitOps CD의 input은 어떤 artifact를 어느 환경에 배포할지 적은 desired configuration이다. CI가 image를 build했다고 자동으로 production에 올라가는 것은 아니고, config PR이 merge됐다고 application health가 보장되는 것도 아니다.

direct deploy가 항상 나쁜 것은 아니다. 작은 disposable environment나 단순한 system에서는 push CD가 더 적은 운영 비용으로 충분할 수 있다. 다만 그 구조를 GitOps라고 부르면 cluster credential과 drift owner가 어디에 있는지 가려진다.

source of truth의 범위를 명시한다

“Git이 단일 진실의 원천”이라는 표현은 scope와 함께 써야 한다. Git이 일반적으로 잘 보관하는 것은 desired configuration과 policy다.

Git만으로 복구되지 않는 대표적인 상태는 다음과 같다.

• database와 PersistentVolume의 business data
• secret manager의 secret value와 encryption key
• runtime event, metric, log, controller status
• cloud provider가 관리하는 실제 resource와 service-side setting
• identity provider, DNS, certificate 같은 external dependency

Git에는 이런 resource의 선언, reference, version, 복구 runbook을 남길 수 있다. 하지만 data backup과 secret rotation을 GitOps controller에 떠넘길 수는 없다. disaster recovery에서는 Git, cluster object backup, application data backup, external system 복구를 함께 시험한다.

GitOps의 장점은 조건이 맞을 때 생긴다

GitOps를 도입하면 변경 review, history, environment diff, drift detection을 한 흐름으로 연결할 수 있다. pull agent만 cluster credential을 가지게 하면 CI가 여러 production cluster의 kubeconfig를 들고 다니는 구조도 줄일 수 있다.

반대로 새 운영 component와 failure mode가 생긴다.

• Git provider나 repository credential 장애
• manifest rendering tool·plugin supply chain
• 잘못된 merge의 빠른 확산
• prune과 self-heal에 의한 의도하지 않은 삭제·복구
• controller queue와 target cluster API 병목
• emergency change가 Git history와 갈라지는 문제

“Git에 기록되니 보안이 강화된다”는 자동 보장도 없다. 민감 값을 평문 commit하면 history에 오래 남고, agent의 cluster 권한이 넓으면 repository compromise의 영향도 커진다.

도입 전에 여섯 가지를 결정한다

1. 어떤 repository·path·revision이 어느 environment의 authority인가
2. desired state 변경을 누가 review·merge할 수 있는가
3. CI와 GitOps agent가 각각 어떤 credential을 가지는가
4. drift를 알림, 수동 sync, self-heal 중 어떻게 처리하는가
5. prune 대상과 보호 resource, break-glass 절차는 무엇인가
6. sync 뒤 Kubernetes health와 사용자 여정을 어떻게 검증하는가

repository와 environment가 하나뿐이고 변경 빈도가 낮다면 먼저 manifest versioning과 repeatable deployment부터 만들 수 있다. 여러 cluster의 일관성, audit, drift correction이 실제 문제로 나타날 때 controller 운영 비용과 비교해 도입한다.

Kubernetes controller와 GitOps agent의 차이는 kind로 보는 두 reconciliation loop, Tekton에서 CI와 CD를 나누는 법은 Tekton CI와 GitOps CD, Argo CD 구현 관점은 Argo CD 적용 흐름에서 이어진다.

참고 자료

• OpenGitOps: GitOps Principles
• OpenGitOps GitHub: GitOps Principles v1.0.0
• Kubernetes: Controllers
• CNCF TAG App Delivery