GitOps 는 무엇과 다르고 무엇 위에 서는가 — 관련 실천과 패턴

한 줄 요약

IaC·CaC 는 "상태를 파일로 적는다" 까지이고, CI/CD 는 "미리 정한 트리거로 자동화한다" 이며, GitOps 는 그 위에 에이전트가 스스로 가져와(pull) 어긋남이 있을 때마다 맞추는(reconcile) 부분을 더한 것입니다. 패턴은 이 조정 루프를 어디에 두고 언제 깨우느냐의 선택입니다.

왜 이게 필요했나

CGOA 의 Related Practices 도메인(16%)은 GitOps 를 이웃 개념과 구분하라고 요구합니다. 실무에서 "우리는 Terraform 을 Git 에 두니 GitOps 다", "Jenkins 가 kubectl apply 를 하니 GitOps 다" 라는 말을 자주 듣는데, OpenGitOps 원칙에 비추면 둘 다 절반만 맞습니다. 원칙 3(Pulled Automatically)과 원칙 4(Continuously Reconciled)가 빠져 있기 때문입니다. 경계를 정확히 알아야 무엇을 더해야 GitOps 가 되는지 말할 수 있습니다.

Patterns 도메인(20%)은 그다음 질문입니다. 조정기(reconciler)를 클러스터 안에 둘지 밖에 둘지, 주기적으로 당길지 이벤트로 깨울지, 점진적 배포를 어떻게 GitOps 루프 안에 넣을지, 상태 저장소를 Git 으로만 둘지. 각 선택에는 공식 문서가 적어 둔 이유가 있습니다.

어떻게 동작하나

관련 실천 — CNCF 용어집의 정의로 구분한다

| 실천 | CNCF 용어집의 정의 | GitOps 와의 관계 |
| --- | --- | --- |
| IaC | 인프라 정의를 파일로 저장해 수동 프로비저닝을 대체. 단일 진실 원천, CI/CD 파이프라인에서 관리 | 원칙 1·2(선언적, 버전·불변)를 채운다. 원칙 3·4 는 도구에 따라 있을 수도 없을 수도 있다 |
| CaC | 설정을 코드처럼 버전 관리한다. opengitops.dev 에 실린 Kelsey Hightower 의 말 "GitOps 는 configuration as code 이후 가장 좋은 것" 이 그 관계를 요약 | 저장소는 같되 GitOps 는 적용 주체를 사람·파이프라인에서 에이전트로 옮긴다 |
| DevOps | 개발부터 운영까지 한 팀이 전 과정을 소유. 인수인계를 줄이는 문화·과정의 전환 | GitOps 는 그 문화를 구현하는 운영 방식 중 하나 |
| DevSecOps | DevOps 에 보안 책임을 합침. 자동화된 CI/CD 워크플로와 정책 집행으로 개발자를 막지 않고 보안을 강제 | Git 의 리뷰·감사 이력과 조정기의 최소 권한이 그 정책 집행의 자리다 |
| CI | 코드 변경을 가능한 한 자주 통합. 커밋에서 시작해 시험된 아티팩트로 끝난다 | GitOps 는 CI 를 대체하지 않는다. CI 가 만든 아티팩트를 참조하는 선언이 GitOps 의 입력 |
| CD | 변경을 인수 환경(continuous deployment 면 운영)으로 자동 배포. 시험과 롤백 절차 포함 | 전통 CD 는 트리거로 밀어 넣고(push), GitOps 는 에이전트가 당긴다(pull) |

OpenGitOps 용어집은 pull 을 이렇게 설명합니다. 에이전트가 변경이 있을 때만이 아니라 언제든 상태 저장소의 원하는 상태(desired state)에 접근할 수 있어야 하고, 그래야 원칙 4 의 지속적 조정이 가능합니다. 전통 CI/CD 는 "미리 정한 트리거" 로 자동화가 돌지만 GitOps 의 조정은 어긋남(divergence)이 있을 때마다 일어나며, 어긋남은 의도적으로 새 버전을 올렸을 때뿐 아니라 실제 상태가 의도치 않게 흘러갔을 때(drift)도 생깁니다. 피드백(feedback)은 제어 이론의 닫힌 루프에서 온 말로, 이전 적용 시도가 실제 상태에 어떤 영향을 줬는지를 뜻하며 에이전트는 그에 따라 재시도·롤백·경보를 합니다.

패턴 1 — pull 주기와 이벤트 기반 조정

두 조정기 모두 기본은 주기적 pull 입니다. Argo CD 는 Git·OCI·Helm 저장소를 3분마다 폴링하고, Flux 의 Kustomization 은 5분마다(.spec.interval) 조정합니다. 이 지연을 없애려고 둘 다 웹훅을 받습니다. Argo CD 는 API 서버의 /api/webhook 으로 GitHub·GitLab·Bitbucket·Azure DevOps 등의 push 사건을 받고, Flux 는 notification-controller 의 Receiver(포트 9292)가 GitHub·GitLab·Harbor·Jenkins 등의 사건을 받아 "pull 파이프라인을 push 만큼 반응적으로" 만듭니다.

중요한 것은 웹훅이 원칙 3 을 깨지 않는다는 점입니다. Argo CD 문서는 웹훅 페이로드를 신뢰하지 않으며, 인증되지 않은 사건이 와도 하는 일은 3분마다 어차피 일어나는 refresh 뿐이라고 적습니다. 사건은 "지금 당겨라" 는 신호일 뿐 상태를 밀어 넣지 않습니다. 이벤트 기반 조정은 pull 을 대체하는 것이 아니라 pull 의 시점을 앞당기는 것입니다.

패턴 2 — 조정기가 클러스터 안에 있는가 밖에 있는가

in-cluster 조정기는 자기가 도는 클러스터를 맞춥니다. Argo CD 의 destination.server: https://kubernetes.default.svc 가 그것이고, Flux 는 bootstrap 으로 자기 자신까지 같은 방식으로 관리합니다. external 조정기는 한 곳에서 여러 클러스터를 맞춥니다. Argo CD 는 대상 클러스터의 자격증명을 argocd.argoproj.io/secret-type: cluster 라벨이 붙은 시크릿(name, server, config)으로 등록하고, namespaces 로 접근 범위를 좁힐 수 있습니다. Flux 문서도 "한 클러스터로 같은 클러스터나 다른 클러스터의 앱을 관리할 수 있다" 고 적습니다. 차이는 자격증명이 어디에 모이느냐입니다. in-cluster 는 각 클러스터가 자기 것만 갖고, external 은 관리 클러스터가 모든 클러스터의 자격증명을 갖습니다.

패턴 3 — 점진적 배포를 루프 안에 넣기

Flux 용어집은 점진적 배포(progressive delivery)를 "새 기능을 일부 사용자에게 먼저 내보내 관찰하고 조정한 뒤 전체에 배포하는 것" 으로 정의하고, 카나리·A/B·기능 플래그를 기법으로 듭니다. Flux 는 Flagger 라는 별도 컨트롤러가, Argo 는 Argo Rollouts 가 이를 맡습니다. Argo Rollouts 는 Deployment 대신 Rollout 리소스로 ReplicaSet 을 관리하며 spec.template 이 바뀌면 strategy(blue-green, canary)에 따라 진행하고, 지표 분석을 통과하면 새 ReplicaSet 을 stable 로 표시합니다. GitOps 관점에서 핵심은 배포 전략 자체가 선언(desired state)의 일부라는 점입니다. Git 에는 "새 이미지" 와 "10% 씩 늘리며 오류율을 본다" 가 함께 적히고, 조정기는 그 선언대로 천천히 맞춥니다.

패턴 4 — 상태 저장소를 무엇으로 두는가

OpenGitOps 용어집은 상태 저장소(state store)를 "불변 버전의 원하는 상태를 저장하고 접근 제어와 감사를 제공하는 시스템" 으로 정의하며, Git 이 이름의 유래이자 대표 사례이지만 조건을 만족하는 다른 시스템도 된다고 적습니다. Flux 는 OCIRepository 와 OCI 아티팩트로 "Gitless GitOps" 를 구현했습니다. 사용자는 여전히 Git 으로 상태를 관리하지만 컨트롤러는 컨테이너 레지스트리만 바라보므로 Git 서버가 운영 의존성에서 빠집니다. Argo CD 도 Kustomize·Helm·OCI 이미지·YAML 디렉터리·플러그인을 소스로 받습니다. 반대로 Argo CD 의 --local 매니페스트 업로드는 문서가 스스로 "GitOps 의 반패턴" 이라 부르는 개발용 기능입니다.

현장에서 만나는 모습

한 팀이 Jenkins 에서 kubectl apply 로 배포하다가 Argo CD 를 붙이면서 Jenkins 의 apply 단계를 남겨 두었습니다. 두 주체가 같은 리소스를 두고 서로 되돌리는 상황이 되었고, Argo CD 는 계속 OutOfSync 를 보고했습니다. CI 의 역할을 "이미지를 만들고 Git 의 태그를 바꾸는 것" 까지로 줄이자 문제가 사라졌습니다. CI 와 GitOps 의 경계를 정하지 않으면 생기는 전형적인 사례입니다.

점진적 배포에서는 자동 롤백이 트래픽과 ReplicaSet 을 되돌리지만 Git 의 선언은 그대로라는 점을 놓치기 쉽습니다. 조정기는 여전히 새 이미지를 원하는 상태로 보기 때문에 사람이 Git 을 되돌리기 전까지 같은 시도가 반복될 수 있습니다. 롤백을 Git 커밋으로 마무리하는 절차가 필요합니다.

다음 이론에서 볼 것

이어지는 이론에서는 이 패턴을 구현하는 두 도구, Argo CD 와 Flux 의 구조를 직접 견주고 알림·관측성·CI 연동이 어디에 붙는지 봅니다. 참고: [OpenGitOps Principles](https://opengitops.dev/), [GitOps Glossary](https://github.com/open-gitops/documents/blob/main/GLOSSARY.md), [CNCF Glossary — GitOps](https://glossary.cncf.io/gitops/), [Argo CD Webhook Configuration](https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/), [Flux Core Concepts](https://fluxcd.io/flux/concepts/), [Flux Webhook Receivers](https://fluxcd.io/flux/guides/webhook-receivers/).