Notes

Continuous Delivery vs Deployment

Continuous Delivery와 Continuous Deployment의 차이를 production 배포 승인, pipeline 자동화 범위, Kubernetes rollout, feature flag, canary, rollback 관점에서 정리한다.

Published: Jun 2, 2026
Updated: Jun 2, 2026
Area: Cloud Infrastructure
Type: concept
Series: DevOps Explained
Category: Notes

Continuous DeliveryContinuous DeploymentCI/CDDevOpsKubernetesCanaryFeature FlagRollback

개요

Continuous Delivery와 Continuous Deployment는 모두 CI/CD 흐름에서 자주 등장하는 개념이다. 둘 다 build, test, package, deploy 과정을 자동화해 software delivery 속도와 안정성을 높이는 것을 목표로 한다.

하지만 두 개념은 같은 의미가 아니다. 가장 중요한 차이는 production 배포에 사람이 최종 승인하는 단계가 남아 있는지다.

Continuous Delivery:
  production에 배포 가능한 상태까지 자동화한다.
  하지만 production 배포 여부는 사람이 승인한다.

Continuous Deployment:
  자동화된 검증을 통과하면 production까지 자동 배포한다.
  별도의 수동 승인 단계가 없다.

짧게 정리하면 다음과 같다.

Continuous Delivery = 언제든 배포 가능한 상태를 유지
Continuous Deployment = 검증 통과 시 production까지 자동 배포

이 차이는 단순 용어 차이가 아니다. 운영 정책, release timing, 승인 체계, rollback 전략, observability, incident response까지 연결되는 architecture decision이다.

CI/CD에서 CD가 헷갈리는 이유

CI/CD에서 CD는 문맥에 따라 두 가지 의미로 쓰인다.

약어	의미
CI	Continuous Integration
CD	Continuous Delivery
CD	Continuous Deployment

그래서 “우리 팀은 CI/CD를 한다”는 말만으로는 production까지 자동 배포하는지 알 수 없다.

예를 들어 두 팀이 모두 CI/CD를 사용한다고 말할 수 있다.

Case A:
  code push
    -> build
    -> test
    -> staging deploy
    -> production 배포 대기
    -> 사람이 승인
    -> production deploy

Case B:
  code push
    -> build
    -> test
    -> staging validation
    -> production deploy 자동 실행

Case A는 Continuous Delivery에 가깝고, Case B는 Continuous Deployment에 가깝다.

따라서 운영 관점에서는 “CI/CD를 한다”보다 다음 질문이 더 중요하다.

production 배포에 수동 승인 단계가 있는가?
자동화된 테스트를 통과하면 production까지 자동으로 가는가?
deploy와 release가 분리되어 있는가?
rollback 또는 feature flag 전략이 있는가?
배포 후 monitoring과 alert이 자동으로 연결되는가?

Continuous Integration이 전제인 이유

Continuous Delivery와 Continuous Deployment를 이해하려면 먼저 Continuous Integration을 이해해야 한다.

Continuous Integration은 개발자가 코드를 자주 통합하고, 통합될 때마다 자동 build와 test를 수행하는 practice다.

developer commit
  -> push
  -> build
  -> unit test
  -> static analysis
  -> integration test
  -> artifact 생성

CI가 약하면 Continuous Delivery나 Continuous Deployment를 안정적으로 운영하기 어렵다. production으로 보낼 변경 사항이 이미 자주 통합되고 검증되어야 하기 때문이다.

CI가 약한 조직에서는 보통 다음 문제가 생긴다.

feature branch가 오래 유지됨
  -> main branch와 차이가 커짐
  -> merge conflict 증가
  -> 통합 테스트 실패
  -> release 직전 대규모 수정
  -> 배포 위험 증가

Continuous Delivery와 Continuous Deployment는 작은 변경을 자주 통합하고, 자동화된 pipeline으로 계속 검증하는 것을 전제로 한다.

단계	목적
Commit	변경 사항을 작은 단위로 source control에 반영
Build	code를 실행 가능한 artifact로 변환
Test	변경 사항의 동작과 regression 여부 확인
Package	container image, binary, package 생성
Store	registry 또는 artifact repository에 저장
Deploy	staging 또는 production 환경에 반영

즉, Continuous Delivery와 Continuous Deployment는 CI 위에 쌓이는 확장된 delivery practice로 이해하는 것이 좋다.

Continuous Delivery의 정의

Continuous Delivery는 software가 언제든 production에 배포될 수 있는 상태를 유지하는 방식이다.

중요한 점은 “production에 자동으로 배포한다”가 아니라, production에 배포할 준비가 항상 되어 있다는 것이다.

일반적인 Continuous Delivery pipeline은 다음과 같다.

code commit
  -> build
  -> unit test
  -> integration test
  -> package
  -> artifact 저장
  -> staging deploy
  -> smoke test
  -> acceptance test
  -> production deploy 승인 대기

이 흐름에서 build, test, package, staging deploy, 검증은 자동화되어 있다. 하지만 production 배포는 사람이 승인한다.

자동화:
  build
  test
  package
  staging deploy
  검증

수동 결정:
  production에 언제 release할 것인가

Continuous Delivery의 핵심 목표는 다음과 같다.

목표	설명
deployable state 유지	언제든 production 배포 가능한 상태를 유지
release risk 감소	작은 변경 단위로 검증
반복 가능성 확보	build/test/deploy 절차 자동화
business decision 분리	production release 시점은 사람이 결정 가능
품질 향상	자동화된 검증으로 문제 조기 발견

Continuous Delivery는 특히 production 배포에 승인, 공지, 규제, change window, 고객 일정 조율이 필요한 환경에서 현실적이다.

Continuous Delivery Pipeline 구조

Continuous Delivery pipeline은 production 직전까지의 검증 과정을 자동화한다.

1. Commit
2. Build
3. Unit Test
4. Static Analysis
5. Package
6. Artifact 저장
7. Integration Test
8. Staging Deploy
9. Smoke Test
10. Security Scan
11. Release Candidate 생성
12. Manual Approval
13. Production Deploy

각 단계의 목적은 다음과 같다.

단계	목적
Build	source code를 실행 가능한 artifact로 변환
Unit Test	작은 코드 단위 검증
Static Analysis	코드 품질, style, 취약 패턴 점검
Package	container image, binary, package 생성
Artifact 저장	registry 또는 artifact repository에 저장
Integration Test	서비스 간 연동 검증
Staging Deploy	production-like 환경에서 검증
Smoke Test	기본 기능 동작 확인
Security Scan	image, dependency, config 취약점 확인
Manual Approval	production 배포 여부 판단
Production Deploy	실제 사용자 환경에 반영

Continuous Delivery에서 중요한 것은 manual approval이 존재한다는 사실 자체가 아니다. 더 중요한 것은 production deploy 직전까지의 모든 과정이 반복 가능하고 자동화되어 있다는 점이다.

Continuous Delivery는 느린 배포 방식이 아니다. 자동화된 검증을 통해 언제든 배포 가능한 상태를 만들고, production 반영 시점만 사람이 통제하는 방식이다.

Continuous Deployment의 정의

Continuous Deployment는 Continuous Delivery에서 한 단계 더 나아간 방식이다. 자동화된 검증을 모두 통과하면 변경 사항이 production까지 자동으로 배포된다.

code commit
  -> build
  -> unit test
  -> integration test
  -> package
  -> staging deploy
  -> smoke test
  -> production deploy 자동 실행
  -> monitoring

Continuous Deployment에서는 production 배포에 수동 승인 단계가 없다.

자동화된 test와 guardrail이 충분히 신뢰 가능하다면,
사람의 승인 없이 production까지 배포한다.

Continuous Deployment의 장점은 다음과 같다.

장점	설명
feedback loop 단축	사용자 반응을 빠르게 확인
release batch size 감소	변경 단위가 작아져 원인 추적이 쉬움
수동 승인 병목 제거	사람이 배포 버튼을 누르는 대기 시간 제거
delivery velocity 향상	기능과 수정 사항이 빠르게 production 반영
반복 작업 감소	배포 절차가 pipeline에 내장됨

하지만 Continuous Deployment는 높은 수준의 자동화와 운영 성숙도를 요구한다. 단순히 production deploy 버튼을 자동으로 누르게 만든다고 Continuous Deployment가 되는 것은 아니다.

Continuous Deployment Pipeline 구조

Continuous Deployment pipeline은 Continuous Delivery pipeline에서 manual approval 단계를 제거한다. 대신 자동화된 guardrail이 충분히 강해야 한다.

1. Commit
2. Build
3. Unit Test
4. Static Analysis
5. Package
6. Artifact 저장
7. Integration Test
8. Staging Deploy
9. Smoke Test
10. Security Scan
11. Canary Deploy
12. Automated Metrics Check
13. Production Rollout
14. Monitoring
15. Automated Rollback 조건 평가

Continuous Deployment에서 필요한 조건은 다음과 같다.

필요 조건	설명
높은 test 신뢰도	자동 test가 regression을 잘 잡아야 함
production-like staging	staging 검증이 production과 유사해야 함
빠른 rollback	장애 시 이전 version으로 빠르게 되돌릴 수 있어야 함
feature flag	deploy와 release를 분리할 수 있어야 함
observability	배포 후 latency, error rate, saturation을 즉시 확인
canary/gradual rollout	전체 사용자에게 한 번에 노출하지 않음
alert 품질	user impact와 연결된 alert 필요
ownership	배포 실패 시 대응 책임과 절차 명확

Continuous Deployment는 “승인을 없애는 것”이 아니라 승인의 역할을 자동화된 검증과 운영 guardrail로 대체하는 것이다.

핵심 차이: Production 배포의 최종 승인자

Continuous Delivery와 Continuous Deployment의 가장 중요한 차이는 production 배포의 최종 승인자가 누구인가다.

구분	Continuous Delivery	Continuous Deployment
production 배포	사람이 승인	pipeline이 자동 실행
자동화 범위	production 직전까지 자동화	production까지 자동화
release 시점	business/운영 판단 가능	검증 통과 즉시 배포
주요 전제	언제든 배포 가능한 상태	자동 검증과 rollback 신뢰
적합 환경	승인·규제·일정 조율 필요	빠른 사용자 피드백 필요
위험 관리	human gate 중심	automated guardrail 중심

이를 흐름으로 보면 다음과 같다.

Continuous Delivery:

commit
  -> build
  -> test
  -> staging
  -> release candidate
  -> [manual approval]
  -> production


Continuous Deployment:

commit
  -> build
  -> test
  -> staging
  -> automated validation
  -> production

Continuous Delivery에서는 pipeline이 “여기까지 검증 완료, production에 배포할 수 있음”을 만들어준다. Continuous Deployment에서는 pipeline이 “검증 완료, production에 배포함”까지 수행한다.

Delivery, Deployment, Release 구분

Continuous Delivery와 Continuous Deployment를 정확히 이해하려면 delivery, deployment, release를 구분해야 한다.

용어	의미
Delivery	production에 배포 가능한 artifact와 release candidate를 준비하는 것
Deployment	실제 환경, 특히 production에 변경 사항을 반영하는 것
Release	사용자에게 기능을 실제로 노출하는 것

Container 기반 서비스를 예로 들면 다음과 같다.

Delivery:
  source code build
  test 통과
  container image 생성
  image registry push
  Helm chart update
  staging 검증 완료
  release candidate 준비

Deployment:
  production cluster에 새 image 적용
  traffic이 새 version으로 이동
  사용자가 새 version으로 요청 처리

Release:
  feature flag를 켜서 새 기능을 사용자에게 노출

Feature flag를 사용하면 code는 production에 deploy되어 있지만, 기능은 아직 release되지 않은 상태를 만들 수 있다.

production deploy 완료:
  app:v2가 production에서 실행 중

feature release:
  feature flag를 켜서 사용자에게 노출

이 구조를 사용하면 Continuous Deployment를 하면서도 business release timing을 통제할 수 있다.

Continuous Delivery가 적합한 경우

Continuous Deployment가 더 자동화된 방식이라고 해서 항상 더 좋은 것은 아니다. 다음 조건에서는 Continuous Delivery가 더 적합할 수 있다.

- production 배포에 승인 기록이 필요하다.
- 금융, 의료, 공공 등 규제 환경이다.
- 고객별 release timing이 다르다.
- 배포와 공지가 함께 조율되어야 한다.
- database 또는 infrastructure 변경이 많다.
- 자동화된 test와 rollback이 아직 충분하지 않다.
- 운영팀이 change window를 관리해야 한다.

Continuous Delivery가 적합한 환경에서는 manual approval이 release governance 역할을 한다.

상황	manual approval이 제공하는 가치
규제 환경	변경 승인 기록과 audit trail 확보
고객 공지 필요	release timing 조율
database 변경	backup, migration, rollback plan 확인
대규모 변경	여러 팀 간 coordination
운영 시간 제약	change window 관리

주의할 점은 manual approval이 형식적인 버튼이 되면 안 된다는 것이다. 승인 단계는 test 결과, risk, rollback plan, release timing을 확인하는 실질적 절차여야 한다.

Continuous Deployment가 적합한 경우

Continuous Deployment는 빠른 feedback loop가 중요한 환경에 적합하다.

- 작은 변경을 매우 자주 배포한다.
- 자동화된 test suite가 신뢰 가능하다.
- feature flag와 canary가 잘 구성되어 있다.
- rollback이 빠르고 안전하다.
- monitoring과 alert이 user impact 중심으로 구성되어 있다.
- on-call과 incident response 체계가 있다.
- product feedback loop가 중요하다.

Continuous Deployment는 특히 SaaS, web service, internal platform, 빠른 실험이 중요한 제품에서 효과적이다.

하지만 다음 조건이 부족하면 위험하다.

부족한 요소	위험
test 자동화 부족	defect가 production으로 바로 배포됨
observability 부족	장애를 늦게 감지함
rollback 미흡	실패한 배포 복구가 지연됨
feature flag 부재	기능 노출 범위를 제어하기 어려움
canary 부재	전체 사용자에게 한 번에 장애 전파
on-call 부재	자동 배포 후 장애 대응 책임이 불명확

Continuous Deployment는 조직의 운영 성숙도가 뒷받침될 때 안전하게 작동한다.

Kubernetes 환경에서 Continuous Delivery

Kubernetes 환경에서 Continuous Delivery는 보통 다음처럼 구성된다.

Git push
  -> CI pipeline
  -> test
  -> container image build
  -> image registry push
  -> Helm chart 또는 manifest update
  -> staging cluster deploy
  -> smoke test
  -> production approval 대기

도구 조합은 다음과 같을 수 있다.

역할	예시 도구
Source control	GitHub, GitLab
CI	Jenkins, Tekton, GitHub Actions, GitLab CI
Image build	Docker, BuildKit, Kaniko, Buildah
Registry	Nexus, Harbor, Docker Registry
Manifest 관리	Helm, Kustomize
CD/GitOps	Argo CD, Flux
Observability	Prometheus, Grafana, Loki, Alertmanager

Continuous Delivery에서는 production 반영 전에 다음 검증을 수행할 수 있다.

staging에서 새 image 실행
  -> readinessProbe 확인
  -> smoke test 실행
  -> migration dry-run 확인
  -> security scan 결과 확인
  -> 운영자가 production sync 승인

GitOps를 사용하는 경우 production 배포 승인 방식은 다음처럼 표현될 수 있다.

staging:
  main branch 변경 자동 sync

production:
  release branch 또는 tag 변경 시 sync
  또는 Argo CD manual sync

이 구조에서는 production 변경이 자동화된 도구로 수행되지만, sync 시점은 사람이 결정할 수 있다.

Kubernetes 환경에서 Continuous Deployment

Kubernetes 환경에서 Continuous Deployment는 main branch 또는 release branch에 변경이 merge되면 production까지 자동 반영되는 구조에 가깝다.

Git merge to main
  -> CI test
  -> image build
  -> registry push
  -> manifest image tag update
  -> GitOps repository update
  -> Argo CD auto-sync
  -> production rollout
  -> metrics 확인

이때 Kubernetes Deployment의 rolling update만 믿으면 안 된다. Rolling update는 pod를 점진적으로 교체해주지만, application-level correctness까지 보장하지는 않는다.

예를 들어 pod가 Running이고 readinessProbe가 통과해도 다음 문제가 있을 수 있다.

신규 version이 특정 API에서 500 error 발생
DB migration과 app version이 호환되지 않음
cache key format 변경으로 일부 사용자 장애 발생
외부 API 호출 timeout 증가
p99 latency 급증

따라서 Continuous Deployment에는 Kubernetes rollout 외에도 application-level 검증이 필요하다.

검증 항목	설명
readinessProbe	traffic을 받을 준비가 되었는지 확인
livenessProbe	process가 비정상 상태인지 확인
startupProbe	느린 시작으로 인한 오탐 방지
smoke test	핵심 API 기본 동작 확인
canary metric	일부 traffic에서 error/latency 확인
SLO burn rate	error budget이 빠르게 소모되는지 확인
rollback rule	조건 충족 시 이전 version으로 복구

Manual Approval은 나쁜 것인가?

Continuous Deployment 관점에서 manual approval은 병목처럼 보일 수 있다. 하지만 manual approval이 항상 나쁜 것은 아니다.

수동 승인에는 다음 역할이 있을 수 있다.

역할	설명
business timing 조율	마케팅, 고객 공지, 계약 조건과 release 시점 조율
규제 준수	금융, 의료, 공공 환경에서 변경 승인 기록 필요
change window 관리	운영 시간 외 배포 또는 정해진 window 사용
위험 검토	database, network, IAM 변경 등 high-risk change 확인
cross-team coordination	여러 팀의 변경이 동시에 영향을 줄 때 조율

문제는 manual approval이 실제 검토 없이 “버튼 누르기”만 되는 경우다.

나쁜 manual approval:
  아무도 plan/test 결과를 보지 않음
  습관적으로 approve만 누름
  배포 실패 시 책임 회피용으로만 존재
  lead time만 늘림

좋은 manual approval:
  위험 변경을 식별함
  test 결과와 rollout plan을 확인함
  rollback plan을 검토함
  business release timing을 조율함
  audit trail을 남김

Continuous Deployment로 넘어갈 수 있는 시점은 manual approval이 더 이상 실질적 가치를 제공하지 않고, 자동화된 검증과 rollback 체계가 그 역할을 대체할 수 있을 때다.

자동화된 Test가 충분하지 않으면 위험하다

Continuous Deployment는 자동화된 test를 강하게 신뢰하는 방식이다. 따라서 테스트가 약하면 production 장애를 자동으로 밀어 넣는 구조가 될 수 있다.

Continuous Deployment를 위해 필요한 테스트 계층은 다음과 같다.

테스트	목적
Unit test	작은 코드 단위 검증
Integration test	module/service 간 상호작용 검증
Contract test	API provider/consumer 간 계약 검증
End-to-end test	사용자 시나리오 검증
Smoke test	배포 직후 핵심 기능 확인
Load test	성능과 capacity 확인
Security scan	dependency, image, IaC 취약점 확인
Migration test	schema 변경과 app compatibility 확인

Continuous Deployment에서 중요한 것은 테스트 수가 많다는 것이 아니라, 실제 production 장애를 일으킬 수 있는 failure mode를 얼마나 잘 막는가다.

예를 들어 unit test가 많아도 다음은 못 잡을 수 있다.

DB schema migration 순서 오류
외부 API timeout 증가
Kubernetes resource limit 부족
cache invalidation 실패
feature flag default 값 오류
TLS certificate 설정 오류

따라서 Continuous Deployment는 test automation뿐 아니라 observability, progressive delivery, rollback strategy와 함께 설계해야 한다.

Feature Flag로 Deploy와 Release 분리하기

Continuous Deployment를 운영할 때 자주 사용되는 기법이 feature flag다.

Feature flag는 deploy와 release를 분리한다.

Deploy:
  code가 production에 배포됨

Release:
  기능이 사용자에게 노출됨

예를 들어 새 검색 기능을 배포한다고 하자.

app:v2 production 배포 완료
  -> new_search_enabled = false

내부 사용자에게만 활성화
  -> new_search_enabled = true for internal users

일부 사용자에게 활성화
  -> 5% rollout

문제 없음
  -> 50% rollout
  -> 100% rollout

Feature flag의 장점은 다음과 같다.

장점	설명
배포 위험 감소	code는 미리 배포하고 기능 노출은 단계적으로 진행
빠른 rollback	문제가 있으면 flag를 끄면 됨
A/B testing 가능	사용자 그룹별 기능 비교 가능
business release 조율	deploy와 release 시점을 분리
Continuous Deployment와 호환	code는 자동 배포하되 기능 공개는 제어 가능

주의할 점도 있다.

오래된 flag를 제거해야 한다.
flag 조합이 복잡해질 수 있다.
테스트 matrix가 늘어난다.
default 값 실수로 production 영향이 생길 수 있다.
authorization과 혼동하면 안 된다.

Feature flag는 Continuous Deployment를 안전하게 만드는 도구이지만, flag lifecycle 관리가 필요하다.

Canary와 Progressive Delivery

Continuous Deployment에서 모든 사용자에게 한 번에 배포하는 것은 위험할 수 있다. 그래서 canary deployment를 사용한다.

Canary는 일부 사용자 또는 일부 traffic에만 새 version을 노출하고, metrics를 확인한 뒤 점진적으로 확대하는 방식이다.

v1:
  100% traffic

v2 canary:
  5% traffic
  error rate 확인
  latency 확인
  business metric 확인

정상:
  25% -> 50% -> 100%

비정상:
  rollback

Canary에서 확인할 수 있는 지표는 다음과 같다.

지표	확인 목적
HTTP 5xx rate	새 version의 server error 증가 여부
p95/p99 latency	지연 증가 여부
request success rate	사용자 요청 성공률
pod restart count	application crash 여부
CPU/memory usage	resource regression
business transaction success	실제 사용자 journey 성공 여부
SLO burn rate	reliability 목표에 미치는 영향

Canary가 제대로 작동하려면 metrics가 version별로 구분되어야 한다. v1과 v2의 error rate를 분리해서 보지 못하면 canary의 의미가 약해진다.

Rollback과 Compatibility

Continuous Deployment에서는 rollback이 매우 중요하다. 사람이 production 배포를 승인하지 않기 때문에, 문제가 생겼을 때 자동 또는 빠른 수동 rollback이 가능해야 한다.

Rollback 방식은 여러 가지가 있다.

방식	설명
Kubernetes rollout undo	이전 ReplicaSet으로 되돌림
Git revert	GitOps repository에서 이전 manifest로 되돌림
image tag rollback	이전 image tag로 Deployment 변경
feature flag off	code는 유지하고 기능만 비활성화
traffic shift	service mesh나 ingress에서 traffic을 이전 version으로 이동
blue-green switchback	이전 green/blue 환경으로 traffic 복귀

주의할 점은 rollback이 항상 쉬운 것은 아니라는 점이다.

특히 다음 변경은 rollback이 어렵다.

database schema migration
data format 변경
message queue event schema 변경
external API contract 변경
cache key format 변경
stateful workload 변경

따라서 Continuous Deployment에서는 backward compatibility가 중요하다.

Database migration은 다음처럼 단계적으로 설계할 수 있다.

1. 새 column 추가
2. app이 old/new schema 모두 읽을 수 있게 배포
3. data backfill
4. app이 new schema만 사용하도록 변경
5. old column 제거

이 방식은 expand-and-contract pattern에 가깝다. Continuous Deployment에서는 code rollback뿐 아니라 data compatibility까지 고려해야 한다.

장단점 비교

Continuous Delivery와 Continuous Deployment의 장단점은 다음과 같다.

구분	Continuous Delivery	Continuous Deployment
장점	production timing 제어 가능	feedback loop가 매우 짧음
장점	규제·승인 환경에 적합	수동 승인 병목 제거
장점	high-risk 변경 검토 가능	작은 변경을 빠르게 사용자에게 전달
장점	business release 조율 쉬움	배포 절차가 완전히 반복 가능
단점	manual approval이 병목 가능	자동화 품질이 낮으면 위험
단점	승인만 하고 실검토가 없을 수 있음	rollback/observability 미흡 시 장애 확대
단점	release batch가 커질 수 있음	조직 문화와 on-call 체계 필요
단점	배포 대기열 발생 가능	규제 환경에서는 적용 어려울 수 있음

정리하면 Continuous Delivery는 통제 가능성이 강하고, Continuous Deployment는 속도와 자동화가 강하다.

운영 성숙도 단계

Continuous Deployment로 바로 가기보다 단계적으로 성숙도를 높이는 것이 안전하다.

Level 1:
  수동 build, 수동 test, 수동 deploy

Level 2:
  CI 도입
  build/test 자동화

Level 3:
  Continuous Delivery
  production 직전까지 자동화
  manual approval 유지

Level 4:
  Progressive Delivery
  canary, feature flag, automated verification 도입

Level 5:
  Continuous Deployment
  검증 통과 시 production 자동 배포
  rollback/monitoring/incident response 통합

중요한 것은 단계를 건너뛰지 않는 것이다. 자동 test와 observability가 약한 상태에서 Continuous Deployment를 도입하면 장애를 더 빠르게 production에 전달하는 결과가 될 수 있다.

Kubernetes Homelab 관점에서 적용하기

개인 k3s나 homelab 환경에서도 Continuous Delivery와 Continuous Deployment의 차이는 유용하다.

Continuous Delivery 방식

Git push
  -> GitHub Actions 또는 Jenkins/Tekton
  -> image build
  -> registry push
  -> staging namespace deploy
  -> smoke test
  -> production namespace 수동 sync

이 방식은 production 반영 전에 한 번 확인할 수 있어서 상대적으로 안전하다.

Continuous Deployment 방식

Git push to main
  -> image build
  -> registry push
  -> manifest update
  -> Argo CD auto-sync
  -> production deploy

이 방식은 편하지만, 최소한 다음은 있어야 한다.

항목	이유
readinessProbe	준비되지 않은 pod에 traffic 방지
livenessProbe	비정상 pod 자동 재시작
basic smoke test	배포 직후 핵심 기능 확인
rollback 방법	이전 image로 빠르게 복구
monitoring	error와 latency 확인
secret 분리	token/password 노출 방지
Git history	어떤 변경이 배포됐는지 추적

개인 homelab에서는 모든 서비스를 Continuous Deployment로 운영할 필요는 없다. 중요도가 낮은 내부 도구는 자동 배포하고, storage나 database가 얽힌 서비스는 Continuous Delivery로 수동 승인 단계를 남기는 식으로 나누는 것이 현실적이다.

자칫 실수하기 쉬운 부분

CI만 있는데 CD라고 부르는 경우

Build와 unit test만 자동화되어 있는데 CI/CD라고 부르는 경우가 많다. production에 배포 가능한 artifact를 만들고, staging 또는 production-like 환경 검증까지 자동화되어야 Continuous Delivery에 가까워진다.

Continuous Delivery와 Deployment를 같은 뜻으로 쓰는 경우

둘의 핵심 차이는 production 배포에 manual approval이 있는지다. 이 차이를 무시하면 운영 정책과 배포 자동화 수준을 정확히 설명하기 어렵다.

Test가 약한데 Continuous Deployment를 도입하는 경우

자동화된 검증이 약하면 Continuous Deployment는 장애를 빠르게 배포하는 구조가 된다. test, canary, rollback, monitoring이 먼저 준비되어야 한다.

Manual Approval이 형식적 버튼이 되는 경우

Continuous Delivery에서 manual approval이 실질적 검토 없이 버튼 누르기만 된다면 lead time만 늘리는 병목이 된다. approval은 test 결과, risk, rollback plan, release timing을 확인하는 의미가 있어야 한다.

Rollback을 단순히 이전 image로 되돌리는 것으로만 보는 경우

Database migration, event schema, cache key, external API contract가 바뀌면 image rollback만으로 복구되지 않을 수 있다. Continuous Deployment에서는 backward compatibility 설계가 중요하다.

Deploy와 Release를 구분하지 않는 경우

Production에 code가 올라간 것과 사용자에게 기능이 노출된 것은 다르다. Feature flag를 사용하면 deploy와 release를 분리할 수 있다.

운영 검증 포인트

Continuous Delivery 또는 Continuous Deployment를 운영할 때는 다음을 확인해야 한다.

검증 포인트	확인 질문
Pipeline coverage	build, test, package, deploy가 자동화되어 있는가?
Test 신뢰도	production 장애를 일으킬 failure mode를 충분히 잡는가?
Manual approval 의미	approval이 실제 risk 검토를 포함하는가?
Rollback 가능성	이전 version으로 빠르게 복구 가능한가?
Data compatibility	DB migration과 event schema가 backward compatible한가?
Observability	배포 후 error rate, latency, saturation을 볼 수 있는가?
Progressive rollout	canary, blue-green, feature flag를 사용할 수 있는가?
Security	secret, token, internal hostname이 log나 artifact에 노출되지 않는가?
Audit trail	누가, 언제, 어떤 변경을 production에 반영했는가?
Ownership	배포 실패 시 누가 대응하는지 명확한가?

정리

Continuous Delivery와 Continuous Deployment는 모두 delivery pipeline을 자동화하는 DevOps practice다. 하지만 production 배포의 경계에서 중요한 차이가 있다.

Continuous Delivery는 모든 변경 사항을 production에 배포 가능한 상태까지 자동화하되, 최종 production 배포는 사람이 승인한다.
Continuous Deployment는 자동화된 검증을 통과한 변경 사항을 production까지 자동으로 배포한다.
둘의 핵심 차이는 manual approval 여부다.
Continuous Deployment는 더 빠른 feedback loop를 만들지만, test, observability, rollback, canary, feature flag, incident response가 충분해야 안전하다.
Continuous Delivery는 production release timing을 사람이 통제할 수 있어 규제, 승인, 고객 공지, high-risk 변경이 있는 환경에 적합하다.
Kubernetes 환경에서는 rolling update만으로 application correctness를 보장할 수 없으므로 application-level metric과 progressive rollout이 필요하다.
Feature flag를 사용하면 deploy와 release를 분리해 Continuous Deployment에서도 business release timing을 제어할 수 있다.

핵심을 짧게 정리하면 다음과 같다.

Continuous Delivery:
  언제든 배포할 수 있다.

Continuous Deployment:
  검증되면 자동으로 배포된다.

운영 관점에서는 다음 표현이 더 정확하다.

Continuous Delivery는 release timing을 사람이 통제한다.
Continuous Deployment는 release path를 pipeline이 통제한다.