Kubernetes and Cloud Native Associate (KCNA) #7 Cloud Native Application Delivery (8%): GitOps, CI/CD

2026년 6월 2일 화요일

8 분 소요

#6 Cloud Native Observability에서는 돌아가는 시스템을 어떻게 들여다보는지를 정리했습니다. 이제 시선을 한 단계 앞으로 옮깁니다. 개발자가 작성한 애플리케이션이 어떤 경로를 거쳐 클러스터까지 안전하게 배달되는지가 이번 글의 주제입니다.

Domain 5 Cloud Native Application Delivery는 비중 8%로 작은 도메인이지만, CI/CD와 GitOps라는 현대 클라우드 네이티브 운영의 핵심 어휘가 모여 있습니다. 코드가 커밋되는 순간부터 클러스터에서 실제로 돌기까지의 흐름, 그 흐름을 자동화하고 신뢰 가능하게 만드는 원칙을 이번 글에서 정리하겠습니다.

배달이라는 문제 #

개발자가 코드를 작성하는 것과 그 코드가 클러스터에서 사용자에게 서비스되는 것 사이에는 긴 거리가 있습니다. 그 사이에서 거치는 모든 단계, 즉 빌드,테스트,이미지 생성,배포,검증을 묶어 Application Delivery라고 부릅니다. 클라우드 네이티브 세계에서 이 배달의 단위는 항상 컨테이너 이미지입니다.

소스 코드가 아니라 이미지가 배달 단위라는 점이 핵심입니다. 한 번 빌드된 이미지는 불변(immutable)이며, 개발,스테이징,운영 환경에 동일한 이미지가 흘러갑니다. “내 PC에서는 됐는데” 문제를 구조적으로 없애는 출발점이 바로 이 불변 이미지입니다.

CI/CD 기초 #

CI/CD는 두 개의 분리된 개념을 한 묶음으로 부르는 표현입니다. 시험에서 둘의 경계를 정확히 가르는 문항이 자주 나오므로 분리해서 외워 두어야 합니다.

CI (Continuous Integration) #

CI는 코드를 합치고 검증하는 단계입니다. 개발자가 커밋을 푸시하면 자동으로 다음 작업이 돌아갑니다.

소스 코드 빌드
단위 테스트,통합 테스트 실행
정적 분석,린트
컨테이너 이미지 빌드와 레지스트리 푸시

CI의 산출물은 테스트를 통과한 컨테이너 이미지입니다. 여기까지는 아직 클러스터에 아무것도 배포되지 않았습니다.

CD (Continuous Delivery / Deployment) #

CD는 CI가 만들어 낸 이미지를 실제 환경에 배포하는 단계입니다. CD는 두 가지로 다시 나뉩니다.

Continuous Delivery. 운영 배포 직전까지 자동화하되, 운영 반영은 사람이 승인 버튼을 눌러 트리거합니다.
Continuous Deployment. 운영 반영까지 사람 개입 없이 완전 자동으로 진행합니다.

CI와 CD를 가르는 기준은 명확합니다. 이미지를 만드는 일까지가 CI, 그 이미지를 클러스터에 띄우는 일부터가 CD입니다.

파이프라인 #

CI와 CD를 이어 붙인 자동화 흐름이 파이프라인(pipeline)입니다. 커밋 한 번이 빌드,테스트,이미지 푸시,배포,검증으로 자동 연결됩니다. Jenkins, GitLab CI, GitHub Actions, Tekton 같은 도구가 이 파이프라인을 구성합니다. 그중 Tekton은 쿠버네티스 네이티브 CI/CD 프레임워크로 CNCF 프로젝트입니다.

GitOps #

GitOps는 CD를 구현하는 운영 패러다임입니다. 클라우드 네이티브 배달에서 가장 자주 출제되는 개념이므로 정의와 원칙을 정확히 잡아야 합니다.

정의 #

GitOps는 Git을 단일 진실 공급원(single source of truth)으로 삼아 시스템의 desired state를 선언형 매니페스트로 관리하고, 그 상태를 클러스터에 자동으로 반영하는 방식입니다. 한 문장으로 줄이면 “원하는 상태를 Git에 적고, 클러스터를 그 상태에 맞춘다"입니다.

4대 원칙 #

OpenGitOps 프로젝트가 정리한 GitOps의 네 가지 원칙은 시험 단골입니다.

원칙	의미
선언형 (Declarative)	시스템의 desired state를 선언형으로 기술
버전 관리,불변 (Versioned and Immutable)	desired state를 Git에 저장해 버전 관리하고 변경 이력을 불변으로 보존
자동 적용 (Pulled Automatically)	승인된 desired state를 소프트웨어 에이전트가 자동으로 가져와 적용
지속 조정 (Continuously Reconciled)	에이전트가 실제 상태를 desired state와 끊임없이 비교해 일치시킴

push 기반과 pull 기반 #

GitOps의 핵심 차별점은 pull 기반 배포입니다. 둘의 차이를 정확히 구분하는 문항이 자주 나옵니다.

push 기반. CI 파이프라인이 클러스터 바깥에서 kubectl apply 같은 명령으로 클러스터에 변경을 밀어 넣습니다. 외부 파이프라인이 클러스터 자격 증명을 들고 있어야 합니다.
pull 기반(GitOps). 클러스터 안에 상주하는 에이전트가 Git 저장소를 주기적으로 관찰하다가, 변경을 감지하면 스스로 끌어와 적용합니다. 자격 증명이 클러스터 밖으로 나가지 않습니다.

GitOps는 기본적으로 pull 기반을 지향하며, 이 점이 보안과 일관성 측면의 강점으로 이어집니다.

GitOps의 장점 #

장점	설명
감사 가능성	모든 변경이 Git 커밋으로 남아 누가,언제,무엇을 바꿨는지 추적
손쉬운 롤백	이전 커밋으로 되돌리면 클러스터 상태도 그 시점으로 복원
재현성	같은 매니페스트로 동일한 클러스터를 언제든 재구성
drift 자동 교정	누군가 클러스터를 직접 손대도 Git 상태로 되돌림

GitOps 도구 #

KCNA는 두 도구의 역할과 위치를 인지하는 수준을 묻습니다.

ArgoCD. 가장 널리 쓰이는 GitOps 도구입니다. 웹 UI가 강력해 애플리케이션의 sync 상태와 리소스 트리를 시각적으로 보여 줍니다. CNCF Graduated 프로젝트입니다.
Flux. 컨트롤러 묶음으로 동작하는 GitOps 도구입니다. 쿠버네티스 네이티브하게 설계되어 다른 도구와 조합하기 좋습니다. 역시 CNCF Graduated 프로젝트입니다.

두 도구 모두 동작 원리는 같습니다. Git에 정의된 desired state와 클러스터의 실제 state를 끊임없이 비교(diff)하고, 둘이 어긋나면 drift로 감지해 desired state에 맞춰 sync합니다. 이 desired state와 cluster state의 비교,일치 과정이 reconciliation의 본질입니다.

실무 흐름은 실무 트랙 고급 #6 GitOps에서 ArgoCD와 Flux로 직접 다룹니다.

배포 전략 #

새 버전을 기존 버전과 어떻게 교체하느냐가 배포 전략입니다. KCNA는 각 전략의 개념과 트레이드오프를 묻습니다.

전략	방식	트레이드오프
Recreate	기존 Pod 를 모두 내리고 새 버전을 띄움	가장 단순하지만 교체 사이에 다운타임 발생
Rolling update	기존 Pod 를 조금씩 새 버전으로 점진 교체 (쿠버네티스 기본값)	다운타임 없이 점진 교체. 두 버전이 잠시 공존
Blue-green	운영(blue)과 동일한 새 환경(green)을 띄우고 트래픽을 한 번에 전환	즉시 롤백 가능. 두 배의 리소스 필요
Canary	새 버전에 트래픽 일부만 먼저 보내 검증 후 점진 확대	위험을 작게 노출. 트래픽 분배 제어가 필요

쿠버네티스 Deployment의 기본 전략은 rolling update라는 점이 시험에 자주 나옵니다. blue-green과 canary는 Deployment 단독으로는 한계가 있어 Service Mesh나 Argo Rollouts 같은 도구의 도움을 받는 경우가 많습니다.

매니페스트 관리 #

환경마다 다른 설정값을 반복 작성하지 않고 매니페스트를 효율적으로 관리하는 두 가지 대표 도구입니다.

Helm #

Helm은 쿠버네티스의 패키지 매니저입니다. 핵심 어휘는 다음과 같습니다.

차트(Chart). 쿠버네티스 매니페스트를 묶은 패키지
템플릿(Template). 변수를 끼워 넣을 수 있는 매니페스트 틀
values. 템플릿에 주입하는 환경별 설정값
릴리스(Release). 차트를 클러스터에 설치한 한 인스턴스

Helm은 템플릿에 values를 주입해 환경별 매니페스트를 찍어 내고, 릴리스 단위로 설치,업그레이드,롤백을 관리합니다. CNCF Graduated 프로젝트입니다.

Kustomize #

Kustomize는 템플릿 없이 매니페스트를 커스터마이즈하는 도구입니다. 핵심 어휘는 base와 overlay입니다.

base. 공통 매니페스트의 기준
overlay. base 위에 환경별 차이(이미지 태그,레플리카 수 등)만 덧씌우는 패치

Kustomize는 변수 치환이 아니라 순수 YAML 병합 방식으로 동작하며, kubectl에 내장되어 별도 설치 없이 kubectl apply -k로 쓸 수 있습니다.

Helm vs Kustomize #

한 줄로 구분하면, Helm은 템플릿과 values로 패키징하는 패키지 매니저이고, Kustomize는 템플릿 없이 base에 overlay를 덧씌우는 YAML 병합 도구입니다.

공급망 보안 기초 #

배달 흐름이 자동화될수록 “어떤 이미지를 신뢰할 수 있는가"가 중요해집니다. KCNA는 공급망 보안을 인지 수준으로만 다룹니다.

이미지 출처 신뢰. 검증된 레지스트리에서 받은 이미지인지, 빌드 과정이 변조되지 않았는지를 확인합니다.
이미지 서명(cosign). Sigstore 프로젝트의 cosign으로 이미지에 서명해 출처와 무결성을 보장합니다.
SBOM (Software Bill of Materials). 이미지가 어떤 구성 요소,의존성으로 만들어졌는지를 목록화한 명세입니다. 취약점 추적의 기준이 됩니다.

세 용어가 “공급망 보안” 어휘로 묶인다는 사실만 알아도 KCNA 수준에서는 충분합니다.

시험 포인트 #

CI vs CD. 이미지를 만드는 일까지가 CI, 그 이미지를 클러스터에 띄우는 일부터가 CD. Continuous Delivery는 운영 반영에 승인이 필요하고 Continuous Deployment는 완전 자동
GitOps 4대 원칙. 선언형, 버전 관리,불변, 자동 적용, 지속 조정
pull 기반. GitOps는 클러스터 안 에이전트가 Git을 끌어와 적용. 자격 증명이 클러스터 밖으로 나가지 않음
drift와 reconciliation. desired state와 cluster state를 비교해 어긋나면 되돌림
배포 전략. Deployment 기본값은 rolling update. recreate(다운타임),blue-green(즉시 전환,두 배 리소스),canary(일부 트래픽 먼저) 구분
Helm vs Kustomize. Helm은 템플릿,values 기반 패키지 매니저, Kustomize는 템플릿 없는 base,overlay 병합
ArgoCD,Flux. 둘 다 GitOps 도구이자 CNCF Graduated 프로젝트

실무 파이프라인 구성은 실무 트랙 #4 CI/CD에서 직접 다룹니다.

정리 #

이번 글에서 잡은 것:

배달 단위는 컨테이너 이미지. 한 번 빌드한 불변 이미지가 모든 환경에 동일하게 흐름
CI는 빌드,테스트,이미지 생성, CD는 배포. Continuous Delivery는 승인 트리거, Continuous Deployment는 완전 자동
GitOps는 Git을 single source of truth로 삼는 pull 기반 CD 패러다임. 4대 원칙(선언형,버전 관리,자동 적용,지속 조정)과 drift 교정
GitOps 도구는 ArgoCD와 Flux. desired state와 cluster state를 비교해 sync
배포 전략. rolling update(기본),recreate,blue-green,canary의 트레이드오프
매니페스트 관리. Helm(패키지 매니저)과 Kustomize(YAML 병합)
공급망 보안. 이미지 출처 신뢰, cosign 서명, SBOM (인지 수준)

다음: 시험 팁 #

다섯 도메인을 모두 살펴봤습니다. 이제 시험장에서 점수로 바꾸는 단계입니다.

#8 시험 팁과 자주 틀리는 패턴에서는 도메인별로 자주 헷갈리는 개념 쌍, 객관식 문항을 읽는 요령, 시간 배분과 다중 응답 함정까지 합격선을 넘기기 위한 실전 전략을 정리하겠습니다.