20. 지속적 전달 (CD, Continuous Delivery)

핵심 인사이트 (3줄 요약)

본질: 지속적 통합(CI)의 연장선으로, 테스트를 통과한 아티팩트(컨테이너 이미지)가 스테이징(Staging) 환경을 거쳐 프로덕션(Production)에 배포될 준비를 자동으로 마치는 일련의 프로세스다. 단, 최종 운영 배포는 사람의 수동 승인(Manual Approval Gate)을 거친다.

가치: 배포 주기를 월 단위에서 주/일 단위로 단축시키며, 환경 구성과 릴리스 절차가 완벽히 스크립트화되어 있어, "클릭 한 번으로 언제든 안전하게 롤백(Rollback)과 배포가 가능"한 상태를 만든다.

융합: 컨테이너, IaC(Terraform), ArgoCD 같은 GitOps 패턴과 융합하여 인프라의 상태 편류를 막고, 블루/그린(Blue-Green) 및 카나리(Canary) 배포 전략과 결합해 무중단 배포를 실현한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

과거 IT 업계에서는 개발(Dev)이 코드를 완성하고 나면, 이를 넘겨받은 운영(Ops) 부서가 수십 페이지에 달하는 엑셀 배포 매뉴얼을 보며 새벽 내내 스크립트를 타이핑하고 설정 파일을 수정해야 했다. 이러한 수동 배포(Manual Deployment) 방식은 인간의 실수(Human Error)를 유발했고, 환경별 세팅 차이로 인해 롤백조차 불가능한 끔찍한 주말 장애를 일으키는 근본 원인이었다.

이를 해결하기 위해 등장한 것이 지속적 전달(Continuous Delivery, CD) 패러다임이다. CD는 CI(지속적 통합) 파이프라인에서 생성된 무결점 아티팩트(예: Docker Image)를 가져와, 개발망 -> 스테이징망 -> 프로덕션망에 이르기까지 일관된 방식으로 환경 설정(Config)과 조합하여 릴리스 객체를 생성하고 배포하는 과정을 100% 자동화한다. 중요한 것은 "Delivery"와 "Deployment"의 철학적 차이다. 지속적 배포(Continuous Deployment)는 코드 푸시부터 상용 서버 배포까지 기계가 전자동으로 처리하지만, 지속적 전달(Continuous Delivery)은 프로덕션 배포 직전에 사람(비즈니스 담당자)이 '승인(Approve)' 버튼을 누를 수 있는 통제권(Gate)을 남겨둔다.

아래 도식은 수동 배포의 병목 지점과 파이프라인 기반 자동 배포의 흐름을 대조한다.

이 도식은 코드 커밋 이후의 밸류 스트림(Value Stream)에서 인간 개입에 의한 병목(Waiting Time)이 어떻게 제거되는지를 보여준다.

[과거: 배포 스크립트 수동 실행 (장애 유발)]
CI(빌드 완료) ──> [운영자 이메일 수신] ──(주말 대기)──> [새벽 SSH 접속 및 명령어 타이핑] ──> 💥 (설정 누락 장애)
                   ▲ 인간 개입 (병목, 에러)

[현대: 지속적 전달 (Continuous Delivery) 파이프라인]
CI(빌드 완료) ──> [Image Registry 업로드] ──> [Staging 자동 배포 및 E2E 테스트]
                                                            │
                                  ✅ (테스트 통과) ─────────┘
                                  │
                  [Manual Approval Gate (Slack 알람/승인)] ──> [Prod 무중단 배포]
                                  ▲ 비즈니스적 결정만 남음

이 흐름의 핵심은 '배포의 기술적 준비'와 '배포의 비즈니스적 의사결정'을 분리(Decoupling)한다는 점이다. 개발과 테스트가 끝났다고 마케팅 이벤트도 안 했는데 상용에 즉시 오픈할 수는 없다. CD는 시스템이 항상 배포 가능한(Always Deployable) 상태로 대기하게 만들고, 버튼 한 번만 누르면 수 초 내에 동일한 자동화 로직으로 무중단 배포를 보장한다.

📢 섹션 요약 비유: 잘 포장된 물건(아티팩트)을 택배 창고에 쌓아놓기만 하는 것이 아니라, 물류 시스템(CD)이 이미 고객의 문 앞(스테이징)까지 배송을 마친 상태에서, 고객이 문을 열고(수동 승인) 물건을 집어 들기만 하면 되는 초고속 유통 시스템과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

CD 파이프라인은 단순히 스크립트를 실행하는 것이 아니라, 무중단 상태를 유지하며 새로운 버전으로 트래픽을 이동시키고 실패 시 이전 상태로 회복(Resilience)시키는 복잡한 오케스트레이션을 담당한다.

핵심 요소	역할	내부 동작 메커니즘	기술 스택 예시	비유
아티팩트 저장소	불변 객체 보관	CI가 생성한 도커 이미지와 태그, 버전을 저장하고 CD 도구가 이를 풀(Pull)	AWS ECR, Nexus	창고 (진열대)
매니페스트 관리	상태 정의 선언	K8s의 배포 스펙(YAML)을 환경별로 오버레이(Overlay)하여 동적으로 렌더링	Helm, Kustomize	인테리어 도면
CD 엔진 (Controller)	배포 및 동기화 수행	저장소의 목표 상태(Desired State)와 클러스터의 현재 상태(Live State)를 일치시킴	ArgoCD, Spinnaker	현장 감리사
무중단 배포 전략	서비스 연속성 보장	구버전 파드를 하나씩 죽이고 신버전을 띄우거나(Rolling), 라우팅을 스위칭(Blue/Green)함	Kubernetes Deploy, Istio	릴레이 바통 터치
관측성 및 롤백	실패 복구 (MTTR)	배포 후 에러율(5xx)이 치솟으면 즉각적으로 이전 버전 해시로 트래픽을 되돌림	Prometheus, Kayenta	타임머신 복구 버튼

아래의 계층 구조도는 최근 CD 아키텍처의 사실상 표준(De facto)으로 자리 잡은 풀 기반(Pull-based) GitOps 아키텍처의 데이터 흐름을 보여준다.

이 도식은 외부 파이프라인(Jenkins)이 클러스터에 직접 푸시하지 않고, 클러스터 내부의 에이전트(ArgoCD)가 Git의 매니페스트 변화를 스스로 감지하여 동기화하는 가장 안전한 CD 구조를 나타낸다.

┌─────── CI Pipeline ────────┐            ┌─────── Git Repository ────────┐
│ 1. 코드 빌드/테스트        │            │ [ Manifest Repo (YAML) ]      │
│ 2. Docker Image Push       │ ──(Update) │ image: myapp:v2.0 (태그 수정) │
│ 3. 매니페스트 Git Repo 수정│            └───────┬───────────────────────┘
└────────────────────────────┘                    │ (3) Pull & Sync
                                                  ↓
                                 ┌──────── K8s Cluster (Prod) ──────────┐
  (외부망에서 내부망으로의       │  ┌── CD Controller (ArgoCD) ──────┐  │
   방화벽 오픈 불필요 - 보안성)  │  │ 1. Git과 Cluster 상태 차이 감지│  │
                                 │  │ 2. K8s API 서버에 v2.0 배포 지시│ │
                                 │  └─────────────┬──────────────────┘  │
                                 │                ↓                     │
                                 │      [ Web App Pods (v2.0) ]         │
                                 └──────────────────────────────────────┘

이 구조의 핵심은 단일 진실 공급원(Single Source of Truth)을 오직 Git으로 한정하는 것이다. 전통적인 푸시(Push) 방식에서는 해커가 CI 서버를 탈취하면 젠킨스에 저장된 클러스터 접속 키(Kubeconfig)를 이용해 전체 운영망을 날려버릴 수 있었다. 반면 풀(Pull) 기반 GitOps 방식에서는 클러스터 내부의 에이전트만 Git을 읽기 모드로 당겨오므로(Pull), 크리덴셜(인증 정보)이 클러스터 밖으로 절대 유출되지 않아 제로 트러스트 보안 원칙을 완벽히 준수한다.

코드 수준(YAML)에서 살펴보면 배포의 멱등성이 어떻게 보장되는지 알 수 있다.

# [실무 코드 스니펫] Kustomize를 활용한 스테이징/운영 환경 패리티 유지
# base/deployment.yaml (공통 로직)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
      - name: app
        image: mycompany/myapp:latest # (태그는 CD 도구가 덮어씀)

# overlays/prod/kustomization.yaml (운영 전용 설정 덮어쓰기)
resources:
  - ../../base
replicas:
  - name: myapp
    count: 10 # 운영은 파드 10개
images:
  - name: mycompany/myapp
    newTag: v2.0.45 # CI가 자동 업데이트한 해시값

📢 섹션 요약 비유: 집안의 에어컨 온도를 바꾸기 위해 외부 보일러실 기사(CI 서버)가 집 안으로 직접 들어와 벽을 뜯는 것(Push)이 아니라, 내가 스마트폰(Git)에 '22도'라고 희망 온도를 입력해 두면 집 안의 스마트 온도조절기(ArgoCD)가 알아서 목표 온도에 맞게 내부 기기를 세팅(Pull)하는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

CD 영역에서는 딜리버리(Delivery)와 디플로이먼트(Deployment)의 철학적 차이, 그리고 무중단 배포 전략 간의 트레이드오프 분석이 가장 중요하다.

항목	지속적 전달 (Continuous Delivery)	지속적 배포 (Continuous Deployment)
프로세스 종착점	스테이징 배포 완료 + 운영 배포 전 수동 대기	소스 푸시부터 운영 배포까지 전자동 (No Gate)
의사결정 주체	비즈니스 팀 (PM, 마케팅)의 승인(Approve)	기계 (모든 자동화 테스트 통과 시 무조건 릴리스)
주요 적용 기업	90% 이상의 일반적인 엔터프라이즈, 금융권	넷플릭스, 아마존 등 극단적 애자일 빅테크
안전망 요구사항	E2E 테스트 및 배포 전 승인 워크플로우	카나리 분석기(통계 기반 롤백), A/B 테스팅 고도화

대다수의 기업은 지속적 '전달'을 사용한다. 아무리 테스트를 꼼꼼히 해도, 크리스마스 이벤트 쿠폰 기능을 일주일 전에 미리 병합(Merge)해두었다면 당일 00시에 사람의 통제 하에 오픈해야 하기 때문이다.

아래 다이어그램은 무중단 배포(Zero-Downtime Deployment)를 위한 세 가지 핵심 전략의 트레이드오프를 비교한다.

┌──────────┬───────────────────────┬─────────────────────────┬──────────────────────┐
│ 배포 전략│ 롤링 (Rolling Update) │ 블루/그린 (Blue/Green)  │ 카나리 (Canary)      │
├──────────┼───────────────────────┼─────────────────────────┼──────────────────────┤
│ 라우팅   │ 1대씩 순차 교체       │ 전면 스위칭 (100% 이동) │ 1% -> 10% 점진 확대  │
│ 롤백 속도│ 매우 느림             │ 1초 (즉시 라우팅 원복)  │ 1초 (에러 감지 자동) │
│ 자원 요구│ 110% (여유분만 필요)  │ 200% (동일 환경 2벌 필요)│ 110%                 │
│ 단점     │ 구/신버전 혼재로 DB   │ 클라우드 비용(Cost) 2배 │ 복잡한 모니터링 메트릭│
│          │ 하위호환성 필수       │ 일시적 낭비 발생        │ 임계치 튜닝 필요     │
└──────────┴───────────────────────┴─────────────────────────┴──────────────────────┘

이 매트릭스에서 알 수 있듯, 비용과 안전성은 정비례하지 않는다. 최근 대규모 MSA 환경에서는 하드웨어를 2배로 유지해야 하는 블루/그린의 재무적 압박(FinOps 이슈)을 피하기 위해, Istio 같은 서비스 메시(Service Mesh)를 활용하여 트래픽의 단 1%만 신버전으로 흘려보내고 에러율 메트릭(5xx)을 실시간 관측하여 이상이 없으면 100%로 점진 오픈하는 **카나리 배포(Canary Release)**가 SRE의 가장 이상적인 표준으로 자리매김했다.

📢 섹션 요약 비유: 낡은 다리를 새 다리로 바꿀 때, 기존 다리 옆에 새 다리를 완벽히 지어놓고 바리케이드를 한 번에 옮기면(블루/그린, 비싸지만 안전), 차선을 하나씩만 옮겨 차를 통과시키며 무너지는지 관찰하는 것(카나리, 저렴하고 스마트)의 차이와 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무에서 CD를 적용할 때 시스템 장애를 막고 복구력을 높이기 위해 SRE가 내려야 할 판단 시나리오는 다음과 같다.

배포 직후 메모리 누수(Memory Leak) 장애 발생
- 상황: 금요일 오후, 롤링 배포가 정상 완료되었으나 30분 뒤 신버전 파드들이 순차적으로 OOM(Out of Memory) 킬러에 의해 죽으며 서비스가 중단됨.
- 판단: 배포 직후 장애 발생 시 "원인 파악(디버깅) 후 수정 코드를 다시 CI/CD 태워 재배포(Roll-forward)"하는 것은 절대 금지 안티패턴이다. 다운타임을 최소화(MTTR 1분 이내)하기 위해 즉시 CD 도구(ArgoCD)의 롤백(Rollback) 버튼을 눌러 이전 해시(Hash) 버전으로 트래픽을 원상복구시킨 후, 격리된 스테이징망에서 천천히 메모리 누수 원인을 디버깅해야 한다.
카나리(Canary) 배포 시 DB 스키마 락(Lock) 문제
- 상황: 트래픽의 5%만 신버전으로 보내는 카나리 배포를 수행했는데, 신버전이 DB 스키마의 특정 컬럼을 지워버려(Drop) 구버전(95%)의 트래픽이 몽땅 DB 에러를 뱉음.
- 판단: 카나리나 롤링 배포는 "필연적으로 구버전 코드와 신버전 코드가 동일한 DB를 동시에 바라보는 구간"이 존재한다. 따라서 CD 파이프라인에서 데이터베이스 마이그레이션은 철저히 확장 후 수축(Expand and Contract) 패턴을 통해 하위 호환성을 보장하도록 강제해야 한다. 컬럼 삭제는 이번 배포가 아닌 다음번 릴리스(계약 축소)에서 이루어져야 한다.

다음은 배포 파이프라인에서 롤백을 트리거할지 결정하는 SRE의 실무 운영 의사결정 트리이다.

이 도식은 배포 후 카나리 분석기(Spinnaker Kayenta 등)가 실시간 메트릭을 평가하여 배포를 승격(Promote)시킬지 롤백할지 자동 판단하는 흐름이다.

[ CD Pipeline: 카나리 파드 생성 (트래픽 5% 할당) ]
   │
   ├─ [5분간 관측 (Prometheus Metics)]
   │       ↓
   ├─ Q1. HTTP 5xx 에러율이 이전 버전(Baseline) 대비 증가했는가?
   │   ├─ Yes ──> ❌ 카나리 파괴 및 자동 롤백 (안전망 가동)
   │   └─ No ───> ↓
   │
   ├─ Q2. P99 Latency(응답 지연 시간)가 임계치(예: 500ms)를 초과했는가?
   │   ├─ Yes ──> ❌ 메모리 병목 의심, 자동 롤백 및 슬랙 경보
   │   └─ No ───> ↓
   │
   └─ ✅ 통계적 검증 통과 (Confidence Score 95%+)
          ↓
   [ 트래픽 100% 점진 전환 및 구버전 파드 삭제 (Success) ]

이러한 자동화된 카나리 분석(Automated Canary Analysis)은 CD의 궁극적 지향점이다. 사람이 대시보드를 뚫어져라 쳐다보며 식은땀을 흘리는 것이 아니라, 알고리즘이 메트릭을 비교 채점하여 장애 반경(Blast Radius)이 전체 고객의 5% 미만일 때 선제적으로 폭발을 차단하고 롤백하는 회복 탄력성(Resiliency)을 시스템에 부여한다.

📢 섹션 요약 비유: 신제품 화장품을 전국 1,000개 매장에 동시에 풀기 전에, 강남점(카나리 매장) 한 곳에만 먼저 진열해보고 고객 클레임(에러 메트릭)이 단 1건이라도 들어오면 즉각 회수하여 브랜드 이미지 타격을 막는 똑똑한 출시 전략과 같습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

조직이 고도화된 지속적 전달(CD) 파이프라인과 GitOps 체계를 갖추게 되면, 소프트웨어 개발 생태계는 완전히 다른 차원의 속도와 안정성을 확보하게 된다.

가치 영역	기존 시스템 (수동 배포)	CD 파이프라인 정착 후	비즈니스 파급력
배포 빈도 (Deployment Frequency)	분기별 / 월별 1회 (빅뱅)	주별 / 일별 수십 회 (Micro)	고객 피드백에 즉각 대응하는 시장 경쟁력(TTM) 우위
변경 실패율 (Change Failure Rate)	30% 이상 (인적 오류 빈번)	1% 미만 (검증된 파이프라인)	운영팀 밤샘 작업(Toil) 소멸, 엔지니어 이직률 감소
재해 복구 시간 (MTTR)	장애 복구에 수 시간 소요	클릭 한 번으로 1분 내 롤백 완료	대고객 SLA(가용성) 준수 및 금전적 손실 방어

앞으로의 CD 표준은 멀티 클라우드(Multi-Cloud) 배포 및 엣지 컴퓨팅(Edge Computing) 연계로 확장될 것이다. KubeVela, ArgoCD 등은 단일 클러스터를 넘어 전 세계에 분산된 수천 개의 노드에 동일한 상태를 파동처럼 동기화하는 도구로 진화 중이다. 또한, 내부 개발자 포털(IDP, Backstage 등)과 결합하여 개발자가 인프라 지식 없이도 UI 클릭 한 번으로 K8s 환경부터 CI/CD 파이프라인, 모니터링까지 골든 패스(Golden Path)를 셀프 서비스로 프로비저닝하는 플랫폼 엔지니어링(Platform Engineering) 사상으로 완벽히 융합될 것이다.

📢 섹션 요약 비유: 과거에는 배를 띄우기 위해 수백 명의 노잡이가 땀을 흘려야 했다면, 이제는 완벽히 프로그래밍된 자동항법장치(CD)를 통해 선장(비즈니스)이 목적지만 누르면 거친 풍랑(장애) 속에서도 알아서 궤도를 수정하며 부드럽게 항해하는 자율 운항 시대가 열린 것입니다.

📌 관련 개념 맵 (Knowledge Graph)

CI (Continuous Integration) (CD의 선행 조건으로, 지속적인 빌드와 자동화 테스트를 통해 검증된 아티팩트를 만들어내는 파이프라인)
GitOps (ArgoCD / Flux) (모든 클러스터 상태를 선언적 파일로 Git에 저장하고, 에이전트가 이를 Pull하여 무중단 동기화를 보장하는 클라우드 네이티브 CD 표준)
DORA Metrics (구글이 제시한 고성과 데브옵스 조직의 4대 지표: 배포 빈도, 변경 리드 타임, 변경 실패율, 복구 시간. CD가 직접적으로 개선하는 수치)
Feature Flag (피처 토글) (CD 파이프라인을 타서 코드는 운영에 배포되었으나, 비즈니스 요건에 맞춰 실제 UI 노출 여부를 런타임 변수로 켜고 끄는 기술)
Canary Release (카나리 배포) (광산의 카나리아 새처럼, 소수의 트래픽만 신버전에 노출시켜 에러를 관측한 후 점진적으로 전체를 배포하는 가장 진보된 무중단 전략)

👶 어린이를 위한 3줄 비유 설명

공장에서 장난감(앱 코드)을 잘 만들었는지 꼼꼼히 검사하는 과정이 CI라면, 그 장난감을 트럭에 싣고 마트 진열대 앞까지 가져다 놓는 과정이 CD예요.
예전에는 아저씨들이 상자를 하나하나 직접 뜯어서 힘들게 진열하느라(수동 배포) 장난감이 부서지는 사고가 많았어요.
하지만 지금은 CD라는 똑똑한 로봇 트럭이 가게 진열대에 장난감을 마술처럼 짠! 하고 예쁘게 교체해 주어서(자동화 릴리스), 아이들이 언제나 새 장난감을 안전하게 가지고 놀 수 있게 되었답니다.