GitOps 기반 Kubernetes 환경 배포 자동화 시스템 이해하기
Back-end

GitOps 기반 Kubernetes 환경 배포 자동화 시스템 이해하기

2026-02-064수정

summary: "GitOps의 핵심 개념(선언형/SSOT)과 Jenkins → Registry → GitOps Repo → Argo CD → Kubernetes로 이어지는 배포 자동화 흐름을 7단계로 정리합니다."

"Git이 운영의 단일 진실(Single Source of Truth)이 되면 생기는 일"

컨테이너 기반 서비스가 늘고, 멀티 서버/클라우드 환경이 보편화되면서 인프라 운영에서 반복 작업과 수동 배포는 더 이상 "사람이 버티는 방식"으로 유지되기 어렵습니다.

이 글은 GitOps 기반 DevOps 시스템을 바탕으로 다음을 한 번에 잡는 것을 목표로 합니다.

  • GitOps의 핵심 개념(선언형, SSOT)
  • 구성 요소(Jenkins/Registry/GitOps Repo/Argo CD)의 역할
  • CI/CD가 실제로 움직이는 전체 흐름

목표 문장

"Jenkins로 빌드하고, Registry(Harbor 등)에 이미지를 올리고, GitOps Repo에 배포 상태를 선언하면, Argo CD가 Kubernetes 상태를 맞춘다."

이 한 문장이 왜 강력한지 운영 관점에서 이해하는 것이 1편의 목표입니다.

1. GitOps란?

gitops-example

GitOps는 Weaveworks에서 처음 사용한 용어로, 클라우드 네이티브 애플리케이션의 지속적 배포(Continuous Deployment) 에 초점을 둔 DevOps 실천 방식 중 하나입니다.

핵심 아이디어는 다음 3가지로 요약됩니다.

  1. 배포에 관련된 모든 설정을 선언형(Declarative) 기술서 형태로 작성한다.
  2. 선언형 기술서를 Config Repository(Git 저장소) 에서 관리한다.
  3. 자동화 시스템이 Git에 기록된 상태와 운영 환경의 실제 상태를 지속적으로 비교하고, 둘이 같아지도록 동기화한다.

즉, 운영의 "정답 상태"는 서버에 있지 않고 Git에 있습니다.

2. GitOps의 특징: 선언형 + SSOT

2.1 선언형(Declarative) 기술서

GitOps에서 말하는 선언형은 "어떻게(How)"가 아니라 "무엇을(What)"을 적는 방식입니다.

현업에서 가장 이해가 쉬운 예시는 Kubernetes 리소스입니다.

  • 명령형(Imperative) 예시(즉흥 조치)
    • kubectl scale deployment api --replicas=6
    • kubectl set image deployment api api=registry.example.com/api:2026-02-07-1
  • 선언형(Declarative) 예시(원하는 상태를 기록)
    • GitOps Repo의 매니페스트(또는 Kustomize/Helm values)에 다음처럼 "원하는 상태"를 적어둠
      • replicas: 6
      • image: registry.example.com/api:2026-02-07-1

요점은, 명령형은 "지금 당장 바꾸기"이고, 선언형은 "정답 상태를 문서(코드)로 남기기"입니다.

장점은 명확합니다.

  • OS/환경별 절차에 덜 의존한다.
  • 사람이 수동으로 재현하는 단계가 줄어든다.
  • 원하는 상태가 한 곳(Git)에 명확히 기록된다.

2.2 단일 진실 공급원(SSOT: Single Source of Truth)

SSOT는 "어떤 상태(Truth)의 원인은 단 하나의 원천(Source)에 의해 결정된다"는 개념입니다.

GitOps에서는 이 원천을 Git으로 고정합니다.

  • Git 저장소(시스템 소스)와 운영 환경을 1:1로 결합
  • 모든 운영 활동의 시작이 Git 커밋/머지
  • Git의 강력한 기능(History, Merge Request/Review, Revert)을 운영에서도 그대로 사용

결과적으로 "누가/언제/왜/어디를" 바꿨는지가 운영에서도 추적 가능해집니다.

3. GitOps의 주요 장점(운영 관점)

3.1 신뢰할 수 있는 정보 공유

운영에서 자주 나오는 질문(진짜로 자주 나옵니다):

  • "지금 프로덕션에 떠 있는 API 이미지 태그가 뭐였지? 핫픽스가 들어간 버전이 맞나?"
  • "지난주에 Ingress 경로(/api, /admin) 라우팅이 왜 바뀌었지? 누가 MR을 머지했지?"
  • "이번 장애 이후에 HPA/리소스 limit를 조정했다는데, 현재 값이 정확히 뭐지?"

GitOps에서는 답이 단순합니다.

  • Git 이력을 보면 현재 상태는 물론 변경 이유까지 파악 가능
  • 서버에 직접 SSH로 들어가 확인할 필요가 줄어듦
  • 별도의 문서화 부담도 감소(이력 자체가 문서)

3.2 에러 복구 시간 감소

새 배포 후 장애가 발생하면:

  • git revert로 선언 상태를 되돌리고
  • 자동화 시스템이 운영 환경을 이전 상태로 동기화(롤백)

복구가 "수동 조치"가 아니라 정답 상태를 되돌리는 행위로 단순화됩니다.

3.3 익숙한 절차(교육 비용 감소)

개발자에게 익숙한 Git 워크플로우:

  • commit -> push -> merge request -> review -> merge

이 흐름이 운영에도 확장되면:

  • 별도 배포 절차/교육이 줄고
  • 리뷰로 휴먼 에러를 조기에 발견
  • 책임 분담(승인/변경 기록)이 명확해집니다

4. 시스템 아키텍처(역할 분담)

대표적인 GitOps 구성 요소를 역할 기준으로 정리하면 아래와 같습니다.

  • Jenkins: 빌드/테스트/이미지 생성(CI)
  • Registry(Harbor 등): Docker 이미지(및 Helm chart) 저장소
  • GitOps Repository: 배포 매니페스트(선언 상태) 저장소
  • Argo CD: GitOps 구현체. Git을 모니터링하고 Kubernetes로 동기화(CD)

핵심 포인트:

  • Jenkins가 배포를 직접 "실행"하기보다는,
  • 배포 상태를 Git에 반영(선언) 하는 쪽으로 역할이 이동합니다.

5. GitOps 기반 CI/CD 동작 흐름(7단계)

문서의 흐름을 운영 관점으로 재정리하면 다음 7단계입니다.

  1. 코드 커밋(Commit Code)
    • 개발자가 Source Repo에 커밋/푸시
  2. 빌드 파이프라인 트리거
    • Jenkins가 Webhook 또는 Polling으로 변경 감지
  3. 이미지 빌드 & 푸시(Push Image)
    • Jenkins가 Docker 이미지를 만들고 Registry에 Push
  4. 설정 업데이트(Update Values) - GitOps의 핵심
    • 새 이미지 태그(버전)를 GitOps Repo 매니페스트에 반영하고 커밋
  5. Repo 변경 감지(Pull Repo)
    • Argo CD가 GitOps Repo 변경을 감지
  6. 상태 동기화(State Sync)
    • Argo CD가 Kubernetes 리소스를 Git 상태에 맞게 Sync
  7. 이미지 Pull & 배포 완료(Pull Images)
    • 워커 노드가 Registry에서 이미지를 Pull하여 Pod 기동

6. 설치 요구사항(요약): "어디에 설치하느냐"로 다시 보기

GitOps 파이프라인은 특정 OS 버전보다 어떤 환경에 배포/운영할지가 더 중요합니다. 실무에서는 보통 아래 3가지 시나리오로 나뉩니다.

시나리오 A) 관리형 Kubernetes(EKS/GKE/AKS 등)를 쓰는 경우

  • Kubernetes 클러스터: 클라우드가 컨트롤 플레인/노드 관리를 상당 부분 대신해줌
  • GitOps 컨트롤러(Argo CD 등): 클러스터 안에 설치
  • CI(Jenkins/GitHub Actions 등): 클라우드/사내 어디든 가능(보통은 별도 실행 환경)
  • Registry(ECR/GAR/ACR 또는 Harbor 등): 관리형 레지스트리 또는 사내 레지스트리

이 경우 요구사항은 "OS"가 아니라:

  • Argo CD가 동작할 네임스페이스/리소스 여유
  • 클러스터 ↔ Registry ↔ Git 접근 네트워크/권한
  • Ingress/도메인/TLS(필요 시)

시나리오 B) 내부 서버(온프레/사내 VM)에서 클러스터를 직접 운영하는 경우

  • kubeadm/kubespray/RKE2 등으로 클러스터를 직접 구성
  • 로드밸런서/스토리지/인증서(또는 외부 프록시)까지 포함해 "플랫폼"을 스스로 책임져야 함

이 경우 체크해야 할 것은:

  • 노드 리소스(특히 Registry/CI까지 같이 올릴지 여부)
  • 영구 스토리지(PV) 제공 방식(NFS/CSI/로컬 등)
  • 외부 노출 방식(NodePort + 프록시 / MetalLB / 사내 L4)

시나리오 C) 1대(또는 소수) 서버에서 여러 환경(dev/stage/prod)을 굴리는 경우

  • 엄밀한 의미의 고가용성보다는 "환경 분리"와 "업데이트 자동화"에 초점
  • 방법 예시
    • 네임스페이스를 dev/stage/prod로 분리
    • GitOps Repo에서 overlays로 환경 차이를 관리
    • Argo CD는 1개(또는 프로젝트 분리)로 운영

이 경우 핵심 요구사항은:

  • 한 서버에 올라갈 컴포넌트(Argo CD/Registry/CI/앱)가 공유할 수 있는 리소스 여유
  • 장애/업데이트 시 영향 범위가 커지므로 백업/롤백 전략(특히 DB/PV)

결론: 설치 요구사항은 "OS 버전"보다도, (1) 어떤 Kubernetes를 쓰는지 (2) Git/Registry/클러스터 간 권한과 네트워크가 연결되는지 (3) 환경을 어떻게 분리/롤백할지가 품질을 좌우합니다.

7. Harbor와 Jenkins를 많이 쓰는 이유

7.1 Harbor(Registry)

Harbor는 기업 환경에서 컨테이너 이미지와 Helm 차트를 안전하게 저장/관리/배포하기 위한 오픈소스 엔터프라이즈 레지스트리입니다.

  • 기본 Docker Registry 대비 보안/거버넌스/멀티 테넌시 기능 강화
  • 대규모 Kubernetes/클라우드 네이티브 환경에 적합

7.2 Jenkins(CI)

Jenkins는 대표적인 오픈소스 CI 도구로, 빌드/테스트 자동화와 플러그인 생태계가 강점입니다.

  • Credentials(자격 증명) 관리로 토큰/SSH 키/인증서 등을 안전하게 보관
  • Git 기반 워크플로우와 결합하기 쉬움

8. 정리

GitOps는 단순히 "배포 자동화"가 아니라, 운영의 기준점을 Git으로 바꾸는 것입니다.

  • 운영 상태의 기준이 서버가 아니라 Git
  • 변경은 버튼이 아니라 커밋/리뷰/머지
  • 복구는 수동 조치가 아니라 revert

다음 글(2편)에서는 Kubernetes 클러스터(kubeadm) 구성과 Argo CD 설치/동기화 흐름을 실전 체크리스트 형태로 정리합니다.

9. 참고 링크

https://www.samsungsds.com/kr/insights/gitops.html https://techblog.gccompany.co.kr/여기어때-ci-cd-개선기-part-1-문제-파악-ed6aa91f0d7b https://blog.bizspring.co.kr/테크/argocd를-이용한-kubernetes-ci-cd-구현/ https://blog.pages.kr/3026 https://www.linkedin.com/pulse/devops-day-87-argo-cd-maninder-singh/ https://kimjingo.tistory.com/79#toc1 https://beer1.tistory.com/46