[CI/CD] GitOps 개요

우유·2026년 4월 10일

CI/CD GitOps cloud

[Cloud] CI/CD

목록 보기

9/13

1. GitOps란 무엇인가

1.1 GitOps의 정의

GitOps는 애플리케이션 배포와 운영 환경 변경을 Git 저장소를 기준으로 관리하는 운영 방식이다.

쉽게 말하면, 운영 환경이 어떤 상태여야 하는지를 Git에 선언하고, 실제 시스템이 그 Git 상태를 기준으로 동기화되도록 만드는 방식이다.

즉, GitOps에서는 Git 저장소가 단순히 소스코드 저장소 역할만 하는 것이 아니라, 다음까지 포함하는 기준점이 됨.

배포할 애플리케이션 버전

전통적인 배포 방식에서는 CI 도구가 서버에 접속해 명령어를 보내만, GitOps에서는 Git에 기록된 태그나 커밋 해시가 기준이 된다.

의미: deployment.yaml 내의 image: my-app:v1.2.0 처럼 이미지 태그가 수정되는 순간이 곧 "배포 시작"을 의미한다.
이점: 운영 환경에 현재 어떤 버전이 돌아가고 있는지 Git 커밋 로그만 보고도 즉시 파악할 수 있다.

Kubernetes 매니페스트

애플리케이션이 실행될 인프라의 상태를 선언적(Declarative)으로 관리한다.

내용: Deployment, Service, Ingress, ConfigMap 등 K8s 객체 정의 파일들이 포함된다.
역할: "이 애플리케이션은 3개의 복제본(replicas: 3)이 필요하다"는 선언을 Git에 저장하면, Argo CD 같은 도구가 실제 클러스터 상태를 이에 맞게 동기화한다.

Helm values 및 Kustomize 설정

동일한 애플리케이션을 여러 환경(Dev, Staging, Prod)에 배포할 때 사용하는 템플릿 관리 도구의 설정값입니다.

Helm Values: 차트(Chart)는 공용으로 사용하되, 각 환경에서 달라지는 CPU 할당량이나 도메인 주소 등을 values.yaml에 정의하여 관리합니다.
Kustomize: 베이스가 되는 YAML을 두고 환경별로 변경 사항(Patch)만 따로 관리하여 중복을 줄입니다.

환경별 구성값

보안이 필요한 비밀번호(Secrets)를 제외한 환경 변수나 설정 데이터를 포함한다.

예시: DB 접속 엔드포인트, API 타임아웃 설정, 기능 플래그(Feature Flags) 등.
관리: 이 값들이 Git에 기록되어 있으므로, 환경 설정 오류로 인한 장애 발생 시 추적이 매우 쉽다.

운영 반영 이력

누가, 언제, 무엇을 변경했는지에 대한 모든 기록이 Git 커밋 메시지로 남는다.

감사(Audit): git log를 통해 배포 이력을 확인하므로 별도의 운영 일지가 없어도 완벽한 추적이 가능하다.
복구(Rollback): 장애 발생 시 복잡한 복구 스크립트 대신 git revert를 사용하여 이전 상태로 즉시 되돌릴 수 있다.

즉, GitOps는 "Git을 이용해 배포한다"가 아니라 Git을 운영 상태의 기준점으로 삼는다는 것이 핵심이다.

1.2 왜 GitOps가 주목받게 되었는가

기존 CI/CD 환경에서는 보통 CI 서버나 배포 서버가 운영 환경에 직접 배포하는 구조가 많았음.

예:

Jenkins가 운영 서버에 SSH 접속
CI 서버가 Kubernetes에 직접 kubectl apply
배포 스크립트가 운영 자원에 직접 접근

이 방식도 충분히 동작하지만, 규모가 커질수록 다음 문제가 생기기 쉬움.

누가 어떤 변경을 운영에 반영했는지 추적이 어려움
운영 환경에서 수동 변경이 발생하면 Git과 실제 상태가 어긋남
긴급 수정이 직접 클러스터에 반영되면 이력이 Git에 남지 않음
배포 도구가 운영 환경에 많은 권한을 가져야 함
복구 시 어느 상태로 돌아가야 하는지 애매함

GitOps는 이런 문제를 줄이기 위해 등장한 방식이다.

핵심은 운영 환경의 중심을 Git으로 옮기고, 실제 시스템은 Git에 선언된 상태를 맞추도록 동작하게 만드는 것이다.

2. GitOps의 핵심 철학

GitOps를 제대로 이해하려면 몇 가지 핵심 철학을 먼저 정리해야 함.

2.1 선언형(Declarative) 관리

GitOps는 보통 선언형 방식과 함께 설명됨.

선언형이란 "어떻게 할지"보다 "원하는 상태가 무엇인지"를 정의하는 방식이다.

예를 들어 명령형 방식은 다음 느낌이다.

서버에 접속한다
파일을 복사한다
프로세스를 재시작한다
서비스 상태를 확인한다

반면 선언형 방식은 다음 느낌이다.

애플리케이션은 replica 3개여야 한다
이미지 버전은 myapp:1.0.3이어야 한다
Service는 80 포트로 노출돼야 한다

즉, GitOps는 "작업 절차"보다

원하는 최종 상태(desired state) 를 Git에 적어두고, 시스템이 그 상태를 향해 동기화되도록 하는 방식이다.

2.2 Git을 단일 진실 공급원(Single Source of Truth)으로 사용

GitOps에서 매우 중요한 표현이 Single Source of Truth다.

뜻은, 운영 환경이 어떤 상태여야 하는지에 대한 가장 신뢰할 수 있는 기준이 Git이라는 뜻이다.

즉, 다음 질문에 대한 답이 Git에 있어야 함.

현재 운영에 어떤 버전이 올라가 있어야 하는가
스테이징에는 어떤 설정이 적용돼야 하는가
replica 수는 몇 개인가
어떤 매니페스트가 기준인가

이 구조가 중요한 이유는 다음과 같음.

변경 이력이 Git commit으로 남음
리뷰와 승인 절차를 붙일 수 있음
특정 시점 상태를 쉽게 되돌릴 수 있음
Git만 보면 원하는 운영 상태를 설명할 수 있음

즉, GitOps는 Git을 단순한 코드 저장소가 아니라 운영 상태 기록과 통제의 중심으로 활용함.

2.3 자동 동기화(Reconciliation)

GitOps에서는 실제 시스템 상태와 Git에 적힌 상태가 다를 수 있음.

예를 들면 다음 상황이 가능함.

누군가 클러스터에서 직접 리소스를 수정함
파드가 비정상 종료됨
설정이 운영 환경에서 임의로 바뀜
수동 핫픽스가 들어감

이때 GitOps 도구는 Git의 원하는 상태와 실제 상태를 비교하고, 차이가 있으면(drift) 다시 맞추려고 시도함.

이 과정을 보통 Reconciliation, 즉 동기화/수렴 과정이라고 볼 수 있음.

즉, GitOps는 한 번 배포하고 끝나는 구조가 아니라 계속해서 원하는 상태를 유지하려는 운영 모델이다.

3. 기존 배포 방식과 GitOps 방식의 차이

GitOps를 이해하려면 기존 CD 방식과 비교하는 것이 가장 효과적임.

3.1 기존 Push 기반 배포

전통적인 CI/CD에서는 보통 CI 도구가 운영 환경에 직접 변경을 밀어 넣는 구조가 많았음.

예:

개발자 코드 변경
   ↓
CI 도구 빌드 / 테스트
   ↓
CI 도구가 운영 환경에 직접 배포

이 구조에서는 배포 도구가 운영 환경에 직접 접속할 수 있어야 함.

예:

SSH 접속 권한
Kubernetes API 접근 권한
클라우드 배포 권한

즉, 배포의 주체가 CI 서버다.

3.2 GitOps Pull 기반 배포

GitOps에서는 운영 환경 쪽의 에이전트 또는 배포 도구가 Git을 감시하고, 변경이 생기면 그 상태를 가져와 반영함.

예:

개발자 코드 변경
   ↓
CI 도구 빌드 / 테스트 / 이미지 Push
   ↓
Git 저장소에 배포 매니페스트 변경 반영
   ↓
GitOps 도구가 Git 변경 감지
   ↓
클러스터에 동기화

즉, GitOps에서는 운영 환경이 외부에서 명령을 받기보다

스스로 Git에서 원하는 상태를 가져와 반영하는 구조에 가까움.

3.3 왜 이 차이가 중요한가

Push 방식은 단순하고 익숙하지만, 운영 환경에 대한 직접 접근 권한을 배포 도구가 가져야 한다는 부담이 있음.

반면 Pull 기반 GitOps는 다음 장점이 생김.

운영 환경의 인바운드 접근을 줄일 수 있음
Git 변경 이력이 곧 운영 반영 이력이 됨
운영 상태를 Git 기준으로 추적 가능함
Drift 발생 시 자동 복원 가능성이 높아짐

즉, GitOps는 단순한 기술 차이보다 운영 통제 방식의 변화라고 보는 것이 더 정확함.

4. GitOps에서 Git은 무엇을 저장하는가

GitOps라고 해서 무조건 애플리케이션 소스코드 저장소를 그대로 쓰는 것은 아님.

보통 GitOps 저장소는 운영 반영에 필요한 선언형 설정을 저장함.

4.1 대표적으로 저장되는 것

Kubernetes YAML 매니페스트
Helm chart 또는 values 파일
Kustomize overlay
환경별 설정
이미지 태그 버전
네임스페이스 구조
배포 전략 관련 설정

즉, GitOps 저장소는 애플리케이션 코드 저장소와 역할이 다를 수 있음.

4.2 애플리케이션 저장소와 운영 저장소 분리

애플리케이션 저장소

소스코드
Dockerfile
테스트 코드
CI Workflow

운영 저장소(GitOps 저장소)

Kubernetes 매니페스트
환경별 배포 설정
이미지 태그
운영 구성 정보

이렇게 분리하면 장점이 있음.

개발과 운영 반영 흐름을 구분 가능
운영 승인 절차를 별도로 둘 수 있음
환경별 설정 관리를 명확히 할 수 있음

즉, GitOps에서는 저장소 설계도 중요한 주제다.

5. GitOps의 기본 동작 흐름

GitOps의 전체 흐름을 단순화하면 보통 다음과 같음.

개발자 코드 변경
   ↓
CI 실행
   ├─ Build
   ├─ Test
   └─ Image Push
   ↓
GitOps 저장소의 이미지 태그 또는 매니페스트 갱신
   ↓
GitOps 도구가 변경 감지
   ↓
클러스터에 적용
   ↓
실제 상태와 Git 상태 동기화 유지

이 흐름에서 중요한 점은 CI와 GitOps의 역할이 분리된다는 것이다.

CI: 빌드하고 검증하고 결과물 생성
GitOps: 원하는 배포 상태를 Git에 반영하고 실제 환경을 동기화

즉, GitOps는 CI를 대체하는 것이 아니라 CD와 운영 반영 방식을 재구성하는 접근이다.

6. GitOps의 장점

GitOps가 주목받는 이유는 단순히 "요즘 많이 쓰이기 때문"이 아니라, 운영상 분명한 장점이 있기 때문임.

6.1 변경 이력 추적이 쉬움

모든 운영 변경이 Git commit으로 남기 쉬움.

즉, 다음 질문에 대한 답을 찾기가 쉬워짐.

누가 바꿨는가
언제 바꿨는가
무엇을 바꿨는가
왜 바꿨는가

이것은 감사 추적성과 운영 투명성 측면에서 매우 중요함.

6.2 롤백이 쉬움

Git에 이전 상태가 남아 있으므로, 특정 커밋 상태로 되돌리는 방식이 가능함.

즉, 문제가 발생했을 때 "이전 커밋 기준 상태"로 복원하기가 쉬워짐.

물론 데이터 마이그레이션 같은 요소까지 자동 해결되는 것은 아니지만,

적어도 배포 상태 기준으로는 롤백 논리가 단순해짐.

6.3 운영 상태 가시성이 좋아짐

Git만 보면 원하는 상태를 알 수 있다는 점이 큼.

특히 Kubernetes처럼 선언형 리소스를 많이 쓰는 환경에서는 큰 장점이 됨.

즉, "현재 무엇이 운영돼야 하는가"를 설명할 때 클러스터에 직접 들어가기보다 Git을 보는 구조가 가능해짐.

6.4 Drift 감지와 복구 가능성

운영 환경에서 누군가 수동으로 바꿔도 Git과 실제 상태가 달라지면 이를 감지할 수 있음.

도구에 따라 자동으로 원래 상태로 되돌릴 수도 있음.

이 점은 "수동 변경이 누적되면서 운영 환경이 망가지는" 문제를 줄이는 데 유리함.

6.5 보안상 유리한 구조를 만들 수 있음

Push 기반 배포에서는 CI 서버가 운영 환경에 직접 접속해야 하는 경우가 많음.

GitOps는 운영 환경이 Git을 감시하고 가져오는 Pull 기반이므로, 인바운드 접근을 줄이는 구조를 만들기 쉬움.

즉, 배포 권한을 Git 변경 권한과 운영 환경 동기화 권한으로 나눠서 볼 수 있음.

7. GitOps의 한계와 주의점

7.1 Git에 반영되지 않는 수동 변경은 문제를 만든다

GitOps의 핵심은 Git이 기준이라는 점임.

그런데 운영자가 클러스터에서 직접 수정해버리면 Git과 실제 상태가 어긋남.

이런 상황이 반복되면 GitOps의 장점이 약해짐.

즉, GitOps는 기술 도입만이 아니라 운영 원칙 준수가 매우 중요함.

7.2 모든 작업이 GitOps에 잘 맞는 것은 아님

GitOps는 선언형 상태 관리에는 매우 잘 맞지만,

다음 같은 작업은 별도 고민이 필요할 수 있음.

데이터베이스 스키마 마이그레이션
일회성 운영 작업
긴급 수동 복구
복잡한 절차형 배포 작업
외부 시스템 상태에 따라 달라지는 작업

즉, GitOps는 배포와 상태 관리에 강하지만, 모든 운영 절차를 단순 선언형으로 만들 수 있는 것은 아님.

7.3 저장소 구조와 승인 절차를 잘 설계해야 함

GitOps를 도입하면 Git 변경이 곧 운영 반영과 연결될 수 있음.

따라서 다음이 중요해짐.

누가 매니페스트를 바꿀 수 있는가
PR 승인 절차는 어떻게 둘 것인가
dev / stage / prod를 어떻게 나눌 것인가
이미지 태그를 누가 올릴 것인가

즉, GitOps는 Git만 있으면 자동으로 되는 것이 아니라 저장소 전략과 권한 정책이 함께 설계돼야 함.

8. GitOps와 CI/CD의 관계

8.1 GitOps는 CI를 대체하지 않는다

GitOps는 빌드와 테스트를 대신하는 것이 아님.

보통 역할은 다음처럼 나뉨.

CI: 코드 검증, 빌드, 테스트, 이미지 생성
GitOps: 원하는 배포 상태를 Git에 반영하고 실제 환경 동기화

즉, GitOps는 주로 CD와 운영 반영 측면의 방식이다.

8.2 GitOps는 CD의 구현 방식을 바꾼다

전통적인 CD는 CI 서버가 직접 배포할 수 있음.

반면 GitOps는 Git을 통해 배포 상태를 선언하고, 운영 환경이 그 선언을 따라가게 함.

즉, GitOps는

배포를 없애는 개념이 아니라, 배포 반영의 주체와 경로를 바꾸는 개념이다.

9. GitOps가 특히 잘 맞는 환경

9.1 Kubernetes 중심 환경

GitOps는 선언형 리소스와 매우 잘 맞기 때문에 Kubernetes와 궁합이 좋음.

9.2 컨테이너 이미지 기반 배포 환경

이미지 태그를 바꾸는 방식으로 배포 상태를 표현하기 쉬움.

9.3 여러 환경을 일관되게 운영해야 하는 경우

dev, stage, prod를 Git 구조로 명확히 분리해 관리하기 좋음.

9.4 운영 감사 추적이 중요한 경우

누가 어떤 변경을 반영했는지 Git 이력으로 관리하기 좋음.

9.5 수동 변경을 줄이고 싶은 경우

운영 표준화를 강하게 가져가고 싶을 때 유리함.

10. GitOps가 부담이 될 수 있는 환경

10.1 선언형 관리 경험이 부족한 경우

명령형 배포에 익숙한 조직은 사고방식 전환이 필요함.

10.2 Kubernetes나 컨테이너 기반이 아닌 환경

GitOps의 장점이 상대적으로 줄어들 수 있음.

10.3 운영 수동 변경이 잦은 문화

Git 기준 운영 원칙이 지켜지지 않으면 혼란이 커질 수 있음.

10.4 저장소와 승인 구조가 미정리된 경우

GitOps 도입만 하고 권한/리뷰 구조를 안 잡으면 오히려 위험할 수 있음.

11. GitOps를 이해할 때 꼭 구분해야 할 것

11.1 GitOps는 Git으로 배포 명령을 실행하는 것이 아니다

핵심은 Git 명령이 아니라, Git을 원하는 상태의 기준점으로 쓰는 것이다.

11.2 GitOps는 Kubernetes 전용 개념은 아니지만 Kubernetes에서 특히 강하다

다른 환경에도 아이디어를 적용할 수 있지만, 실제로는 Kubernetes에서 가장 널리 활용됨.

11.3 GitOps는 도구 이름이 아니다

Argo CD나 Flux 같은 도구가 GitOps를 구현하는 수단이지, GitOps 자체가 특정 제품명은 아님.

11.4 GitOps는 수동 작업을 완전히 없애는 마법이 아니다

운영 정책, 긴급 대응, 승인 절차, 데이터 작업은 별도 고려가 필요함.

12. 아키텍처 관점에서 본 GitOps

GitOps의 기본 구조를 단순화하면 다음과 같음.

Application Source Repository
   ↓
CI Pipeline
   ├─ Build
   ├─ Test
   └─ Image Push
   ↓
GitOps Repository
   └─ Deployment Manifest / Image Tag / Config
   ↓
GitOps Controller
   ↓
Kubernetes Cluster

이 구조에서 중요한 점은 다음임.

CI는 이미지까지 만든다
GitOps 저장소는 원하는 운영 상태를 기록한다
GitOps Controller가 이를 감지해 실제 환경에 반영한다
실제 상태와 Git 상태가 지속적으로 비교된다

즉, GitOps는 배포 구조를 "명령 실행"에서 "상태 동기화" 중심으로 바꾼다.

요약

이 장에서는 GitOps의 개념과 핵심 철학을 정리했음.

핵심만 다시 정리하면 다음과 같음.

GitOps는 Git을 운영 상태의 기준점으로 삼는 운영 방식임
핵심 개념은 선언형 관리, Single Source of Truth, 자동 동기화임
기존 Push 기반 배포와 달리 Pull 기반 상태 동기화 구조를 많이 사용함
GitOps는 변경 추적, 롤백, Drift 감지, 운영 가시성 측면에서 장점이 큼
반면 수동 변경 통제, 저장소 설계, 승인 정책이 매우 중요함
GitOps는 CI를 대체하지 않으며, 주로 CD와 운영 반영 방식을 재구성함
Kubernetes와 컨테이너 기반 환경에서 특히 강력한 접근 방식임

우유

Front-end Developer, Cloud Engineer

이전 포스트

[CI/CD] GitHub Actions 기반 CI 파이프라인 구성 (실습)

다음 포스트