Blue-Green Deployment와 Rolling Update 차이: 배포 전략 선택 기준

신규 버전을 배포할 때 "서비스 중단 없이 안전하게"는 기본 요구사항입니다. 문제는 어떤 방식으로 무중단을 달성할지입니다. 리소스를 2배 확보해서 한 번에 전환할지, 점진적으로 교체하면서 리소스를 절약할지. 이 선택이 롤백 속도, 비용, 운영 복잡도를 결정합니다.

핵심 요약

Blue-Green Deployment는 동일한 환경 2세트를 운영하고, 트래픽을 한 번에 전환하는 방식입니다. 롤백이 빠르지만 리소스가 2배 필요합니다.
Rolling Update는 기존 인스턴스를 하나씩(또는 일정 비율씩) 새 버전으로 교체하는 방식입니다. 리소스 효율이 높지만 배포 중 두 버전이 공존합니다.
Kubernetes에서 Rolling Update는 Deployment의 기본 전략이고, Blue-Green은 Argo Rollouts 같은 추가 도구를 사용해 구현합니다.
롤백 속도가 최우선이면 Blue-Green, 리소스 효율이 최우선이면 Rolling Update를 검토합니다.
실무에서는 서비스 특성에 따라 두 전략을 혼용하는 경우도 흔합니다.

1. 왜 이 비교가 필요한가

10개의 Pod로 운영 중인 API 서버에 새 버전을 배포해야 합니다. QA를 통과했지만, 프로덕션에서 예상치 못한 문제가 발생할 가능성은 존재합니다.

이때 두 가지 선택지가 있습니다.

선택 A — Blue-Green: 새 버전용 Pod 10개를 추가로 띄우고, 준비가 완료되면 트래픽을 한 번에 전환합니다. 문제가 생기면 즉시 이전 버전으로 되돌립니다.

선택 B — Rolling Update: 기존 10개 Pod를 1~2개씩 새 버전으로 교체합니다. 교체가 완료될 때까지 구/신 버전이 동시에 트래픽을 받습니다.

선택 A는 안전하지만 일시적으로 Pod 20개 분량의 리소스가 필요합니다. 선택 B는 리소스 추가 없이 가능하지만, 두 버전이 공존하는 동안 호환성 문제가 생길 수 있습니다.

이 글에서는 두 전략의 동작 원리를 분석하고, 어떤 상황에서 어떤 전략이 적합한지 판단 기준을 정리합니다.

2. Blue-Green Deployment 동작 원리

Blue-Green Deployment는 두 개의 동일한 프로덕션 환경(Blue, Green)을 운영하는 전략입니다.

배포 과정

Blue 환경이 현재 프로덕션: 라이브 트래픽을 받고 있습니다.
Green 환경에 새 버전 배포: Blue와 동일한 스펙으로 새 버전을 구성합니다.
Green 환경 검증: Health Check, Smoke Test를 실행합니다. 이 시점에서 Green은 아직 라이브 트래픽을 받지 않습니다.
트래픽 전환: Load Balancer 또는 Service의 Selector를 Green으로 변경합니다. 전환은 즉시(atomic) 이루어집니다.
Blue 환경 유지: 롤백 대비로 일정 시간 유지한 후 정리합니다.

롤백 과정

문제 발견 시 트래픽을 다시 Blue로 전환합니다. 이전 버전이 이미 실행 중이므로 Pod 재시작 없이 즉시 롤백됩니다. 롤백 시간은 DNS/LB 전파 시간 수준(수 초)입니다.

Kubernetes에서의 구현

Kubernetes 기본 Deployment 리소스는 Blue-Green을 직접 지원하지 않습니다. 다음 방법으로 구현합니다.

방법 1: Service Selector 수동 전환

# blue-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-blue
spec:
  replicas: 10
  selector:
    matchLabels:
      app: api
      version: blue
  template:
    metadata:
      labels:
        app: api
        version: blue
    spec:
      containers:
      - name: api
        image: api:v1.2.0
---
# green-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-green
spec:
  replicas: 10
  selector:
    matchLabels:
      app: api
      version: green
  template:
    metadata:
      labels:
        app: api
        version: green
    spec:
      containers:
      - name: api
        image: api:v1.3.0
---
# service.yaml — selector를 blue → green으로 전환
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
    version: green  # 전환 시점에 blue → green 변경
  ports:
  - port: 80
    targetPort: 8080

방법 2: Argo Rollouts 사용 (권장)

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-rollout
spec:
  replicas: 10
  strategy:
    blueGreen:
      activeService: api-active
      previewService: api-preview
      autoPromotionEnabled: false
      scaleDownDelaySeconds: 300
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: api:v1.3.0

Argo Rollouts는 Blue-Green 배포의 전체 라이프사이클(Preview → Promote → Scale Down)을 자동으로 관리합니다. autoPromotionEnabled: false로 설정하면 수동 승인 후 전환됩니다.

Blue-Green의 장단점

장점	단점
즉시 롤백 (수 초)	리소스 2배 필요 (일시적)
두 버전 공존 없음	데이터베이스 스키마 변경 시 복잡
전환 전 충분한 검증 가능	롱 커넥션(WebSocket) 처리 필요
배포/릴리스 분리 가능	Kubernetes 기본 지원 없음

3. Rolling Update 동작 원리

Rolling Update는 기존 인스턴스를 점진적으로 새 버전으로 교체하는 전략입니다. Kubernetes Deployment의 기본 전략이기도 합니다.

배포 과정

새 버전 Pod 생성: maxSurge 설정에 따라 추가 Pod를 생성합니다.
새 Pod Ready 확인: Readiness Probe를 통과하면 트래픽을 받기 시작합니다.
구 버전 Pod 종료: maxUnavailable 설정에 따라 기존 Pod를 종료합니다.
반복: 모든 Pod가 새 버전으로 교체될 때까지 2~3을 반복합니다.

핵심 파라미터

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%        # 기본값: 25%. 추가로 생성할 수 있는 Pod 수
      maxUnavailable: 25%  # 기본값: 25%. 동시에 사용 불가능한 Pod 수
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: api:v1.3.0

maxSurge: 업데이트 중 desired replicas 대비 추가로 생성할 수 있는 최대 Pod 수. 10개 replicas에서 25%면 최대 13개까지 동시 실행됩니다.
maxUnavailable: 업데이트 중 동시에 사용 불가능한 최대 Pod 수. 10개 replicas에서 25%면 최소 8개는 항상 Available 상태를 유지합니다.

maxSurge/maxUnavailable 조합별 동작

maxSurge	maxUnavailable	동작 특성
25%	25%	(기본값) 속도와 안정성 균형
1	0	가장 안전. 항상 desired 수 유지. 가장 느림
100%	0	Blue-Green과 유사. 리소스 2배 필요
0	1	추가 리소스 없이 1개씩 교체. 매우 느림

롤백 과정

kubectl rollout undo 명령으로 이전 ReplicaSet으로 Rolling Update를 역방향으로 실행합니다. 즉, 롤백도 점진적입니다. Blue-Green처럼 즉시 전환되지 않고, 같은 Rolling Update 과정을 거쳐 복구됩니다.

# 롤백 실행
kubectl rollout undo deployment/api

# 특정 리비전으로 롤백
kubectl rollout undo deployment/api --to-revision=3

# 롤백 상태 확인
kubectl rollout status deployment/api

Rolling Update의 장단점

장점	단점
리소스 추가 최소화	롤백이 점진적 (시간 소요)
Kubernetes 기본 지원	배포 중 두 버전 공존
설정이 단순	호환성 문제 감지가 어려움
점진적이므로 문제 조기 발견 가능	DB 스키마 변경 시 양방향 호환 필수

4. 구조 비교

두 전략의 구조적 차이를 한눈에 비교합니다.

비교 항목	Blue-Green	Rolling Update
전환 방식	Atomic (한 번에 전환)	Gradual (점진적 교체)
버전 공존	없음 (전환 순간 제외)	있음 (배포 중 구/신 공존)
리소스 요구량	2배 (일시적)	25~50% 추가 (기본값 기준)
롤백 속도	즉시 (수 초)	점진적 (배포 시간과 동일)
다운타임	없음	없음
배포 실패 영향	전환 전이면 영향 없음	부분 트래픽에 영향
Kubernetes 기본 지원	❌ (추가 도구 필요)	✅ (기본 전략)
배포/릴리스 분리	가능 (Preview → Promote)	불가 (배포 = 릴리스)
적합한 스케일	중~대규모 (리소스 여유 시)	모든 규모
구현 복잡도	중간~높음	낮음

5. 실무 시나리오로 이해하기

시나리오 1: 결제 API 서버 배포

상황: 결제 처리 API가 10개 Pod로 운영 중입니다. 새 버전에서 결제 로직이 변경되었습니다. 장애 발생 시 매출 손실이 직접적입니다.

적합한 전략: Blue-Green

근거: - 결제 시스템은 롤백 속도가 가장 중요합니다. 문제 발견 후 수 초 내에 복구해야 합니다. - 구/신 버전이 동시에 결제를 처리하면 중복 결제나 누락이 발생할 수 있습니다. - Green 환경에서 실 트래픽 없이 충분한 검증이 가능합니다. - 리소스 2배 비용보다 장애 시 매출 손실이 훨씬 큽니다.

# Argo Rollouts Blue-Green 설정
spec:
  strategy:
    blueGreen:
      activeService: payment-active
      previewService: payment-preview
      autoPromotionEnabled: false  # 수동 승인 필수
      prePromotionAnalysis:        # 전환 전 자동 검증
        templates:
        - templateName: payment-smoke-test
      scaleDownDelaySeconds: 600   # 롤백 대비 10분 유지

시나리오 2: 내부 관리자 페이지 배포

상황: 5개 Pod로 운영 중인 내부 어드민 대시보드입니다. 사용자가 50명 이내이고, 일시적 오류가 치명적이지 않습니다.

적합한 전략: Rolling Update

근거: - 내부 서비스이므로 즉시 롤백 요구사항이 낮습니다. - 리소스를 2배로 확보할 필요가 없습니다. - 두 버전이 잠시 공존해도 비즈니스 영향이 작습니다. - Kubernetes 기본 지원이므로 추가 도구 없이 바로 사용 가능합니다.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

시나리오 3: 마이크로서비스 아키텍처의 API Gateway

상황: API Gateway가 30개 Pod로 운영 중입니다. 모든 트래픽이 이 서비스를 경유합니다. 새 버전에서 라우팅 규칙이 변경되었습니다.

적합한 전략: Blue-Green (또는 Canary)

근거: - 전체 트래픽이 경유하므로 문제 발생 시 영향 범위가 큽니다. - 라우팅 규칙 변경은 구/신 버전 공존 시 일관성 문제가 생깁니다. - 다만 30개 Pod를 2배(60개)로 운영하는 비용이 부담스러울 수 있습니다. - 비용이 우려된다면 Canary 배포(소수 트래픽으로 검증 → 전환)를 고려합니다.

6. 배포 중 두 버전 공존 문제

Rolling Update의 가장 큰 trade-off는 배포 중 구/신 버전이 동시에 트래픽을 처리한다는 점입니다.

문제가 되는 경우

API 응답 형식 변경

사용자 A → v1 Pod → {"data": {"name": "Kim"}}
사용자 B → v2 Pod → {"data": {"name": "Kim", "email": "kim@example.com"}}

클라이언트가 응답 형식의 일관성을 기대하면 문제가 됩니다. 프론트엔드가 v2 응답 형식에 맞춰 배포되었는데, 일부 요청이 v1으로 라우팅되면 오류가 발생합니다.

데이터베이스 스키마 변경

v2에서 컬럼을 추가하면서 v1은 해당 컬럼을 모르는 상태. 두 버전이 같은 DB를 사용하므로 양방향 호환이 필수입니다.

해결 방법

방법	설명
API 버저닝	`/v1/users`, `/v2/users`로 엔드포인트 분리
Feature Flag	새 기능을 플래그로 제어, 코드는 배포하되 기능은 비활성화
Backward Compatible Schema	DB 변경 시 ADD COLUMN → 코드 배포 → DROP COLUMN 순서
Blue-Green 전환	호환성 관리가 어려우면 Blue-Green으로 전환 검토

Tip
Rolling Update를 사용할 때 API 변경이 있다면 "Expand and Contract" 패턴을 적용합니다. 먼저 새 필드를 추가(expand)하고, 모든 클라이언트가 전환된 후 이전 필드를 제거(contract)합니다. 한 번의 배포로 breaking change를 적용하지 않는 것이 핵심입니다.

7. 롤백 시간 비교

배포 후 문제를 발견했을 때 복구까지 걸리는 시간은 전략에 따라 크게 다릅니다.

Blue-Green 롤백

문제 감지 → Service Selector 변경 → 트래픽 전환 완료
        [~수 초]         [~수 초]
총 소요: 5~30초 (DNS/LB 전파 포함)

이전 버전이 이미 실행 중이므로 컨테이너 시작 시간이 없습니다. Service Selector만 변경하면 됩니다.

Rolling Update 롤백

문제 감지 → kubectl rollout undo → 새 Pod 생성 → 기존 Pod 종료 → 완료
        [수 초]            [Pod 시작 시간 × 반복]
총 소요: 배포 시간과 동일 (수 분~수십 분)

롤백도 Rolling Update 방식으로 진행됩니다. 10개 Pod를 하나씩 교체하면 배포 시 걸린 시간과 비슷하게 소요됩니다.

실무에서의 롤백 시간 차이

조건	Blue-Green	Rolling Update
Pod 10개, 시작 시간 30초	~10초	~3~5분
Pod 50개, 시작 시간 1분	~10초	~10~15분
Pod 100개, 시작 시간 2분	~10초	~20~30분

Pod 수가 많고 시작 시간이 긴 서비스일수록 Blue-Green의 롤백 이점이 두드러집니다.

8. 비용과 리소스 비교

Blue-Green 리소스 요구량

배포 시점에 현재 프로덕션과 동일한 스펙의 환경이 추가로 필요합니다.

평상시:  Pod 10개 (1 CPU, 2Gi 메모리 각각) = 10 CPU, 20Gi
배포 중: Pod 20개 = 20 CPU, 40Gi (일시적으로 2배)
배포 후: Pod 10개 (이전 환경 정리 후) = 10 CPU, 20Gi

scaleDownDelaySeconds를 300초(5분)로 설정하면 배포 후 5분간만 2배 리소스가 필요합니다. 다만 이 5분 동안 클러스터에 여유 리소스가 없으면 Green 환경이 Pending 상태에 빠집니다.

Rolling Update 리소스 요구량

maxSurge 설정에 따라 결정됩니다.

maxSurge: 25% (기본값)
평상시:  Pod 10개 = 10 CPU, 20Gi
배포 중: Pod 최대 13개 = 13 CPU, 26Gi (30% 추가)
배포 후: Pod 10개 = 10 CPU, 20Gi

비용 시나리오

시나리오: 월 20회 배포, Pod 20개, 배포당 10분 소요

Blue-Green (클라우드 환경): - 추가 리소스 시간: 20회 × 10분 = 200분/월 - 추가 비용: Pod 20개 × 200분 × On-Demand 단가 - 실질 비용: 월 전체의 0.5% 미만 (리소스가 이미 예약된 경우 추가 비용 없음)

Rolling Update: - 추가 리소스: maxSurge 25% = Pod 5개 × 200분 - 추가 비용: Blue-Green의 약 25% 수준

비용 판단 기준
Blue-Green의 "리소스 2배"는 배포 시점에만 일시적으로 발생합니다. 배포 빈도가 낮거나 배포 시간이 짧다면 실질 추가 비용은 크지 않을 수 있습니다. 반면, Pod 수가 많고 배포 빈도가 높은 서비스라면 클러스터 리소스 여유를 별도로 확보해야 하므로 고정 비용이 증가합니다.

9. 데이터베이스 마이그레이션 시 고려사항

배포 전략과 무관하게, DB 스키마 변경은 별도 전략이 필요합니다. 다만 전략에 따라 복잡도가 달라집니다.

Blue-Green + DB 변경

1. DB 스키마 변경 (v1, v2 모두 호환되도록)
2. Green 환경에 v2 코드 배포
3. Green 검증
4. 트래픽 전환 (Blue → Green)
5. Blue 환경 정리
6. (선택) 불필요한 스키마 정리

주의점: 전환 직후 롤백하면 v1 코드가 변경된 스키마를 사용합니다. 따라서 DB 변경은 v1과 v2 모두 호환되는 형태(additive change)여야 합니다.

Rolling Update + DB 변경

1. DB 스키마 변경 (v1, v2 모두 호환되도록)
2. Rolling Update 시작 (v1 → v2 점진적 교체)
3. 배포 중 v1 Pod와 v2 Pod가 동시에 새 스키마 사용
4. 배포 완료
5. (선택) 불필요한 스키마 정리

주의점: Blue-Green과 동일하게 양방향 호환이 필요합니다. 차이점은 Rolling Update에서는 구/신 버전이 동시에 동작하는 시간이 더 길다는 것입니다.

공통 원칙: Expand and Contract

Phase 1: 새 컬럼 추가 (nullable 또는 default 값)
         → v1, v2 모두 동작 가능
Phase 2: 코드 배포 (새 컬럼 사용 시작)
Phase 3: 이전 컬럼 정리 (모든 인스턴스가 v2인 것을 확인 후)

10. 선택 의사결정 플로우

1단계: 롤백 요구사항 확인

수 초 내 롤백이 필수인가? → Blue-Green
수 분 내 롤백이면 충분한가? → Rolling Update도 가능

2단계: 버전 공존 허용 여부

구/신 버전이 동시에 트래픽을 받으면 안 되는가? → Blue-Green
양방향 호환이 보장되어 공존 가능한가? → Rolling Update 가능

3단계: 리소스 여유 확인

클러스터에 2배 리소스 확보 가능한가? → Blue-Green 가능
리소스 여유가 제한적인가? → Rolling Update

4단계: 운영 도구/역량 확인

Argo Rollouts 등 도구를 운영할 수 있는가? → Blue-Green 가능
Kubernetes 기본 기능만으로 운영하고 싶은가? → Rolling Update

종합 판단 기준

상황	권장 전략
결제, 인증 등 핵심 서비스	Blue-Green
내부 도구, 관리자 페이지	Rolling Update
API 계약 변경이 잦은 서비스	Blue-Green
Stateless + Backward Compatible	Rolling Update
대규모 Pod + 긴 시작 시간	Blue-Green (롤백 속도)
리소스 제약이 큰 환경	Rolling Update
배포 빈도가 매우 높은 서비스 (일 10회+)	Rolling Update

11. Argo Rollouts로 두 전략 구현하기

Kubernetes 기본 Deployment는 Rolling Update만 지원합니다. Blue-Green을 포함한 고급 배포 전략을 사용하려면 Argo Rollouts가 현재 가장 널리 사용되는 도구입니다.

Argo Rollouts 개요

Argo Rollouts는 Kubernetes CRD(Custom Resource Definition)와 Controller로 구성됩니다. 기존 Deployment 대신 Rollout 리소스를 사용하며, Blue-Green과 Canary 전략을 선언적으로 정의할 수 있습니다.

Blue-Green 설정 예시

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  replicas: 10
  strategy:
    blueGreen:
      activeService: api-active       # 프로덕션 트래픽용 Service
      previewService: api-preview     # 검증용 Service
      autoPromotionEnabled: false     # 수동 승인 필요
      scaleDownDelaySeconds: 300      # 롤백 대비 5분 유지
      prePromotionAnalysis:           # 전환 전 자동 검증
        templates:
        - templateName: smoke-test
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: api:v1.3.0
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

운영 명령어

# 배포 상태 확인
kubectl argo rollouts get rollout api

# 수동 승인 (Blue → Green 전환)
kubectl argo rollouts promote api

# 롤백 (Green → Blue)
kubectl argo rollouts abort api

# 배포 이력 확인
kubectl argo rollouts list rollouts

12. 정리

Blue-Green Deployment는 안전한 전환과 즉시 롤백을 제공합니다. 대신 리소스 2배와 추가 도구 운영이 필요합니다.
Rolling Update는 리소스 효율이 높고 Kubernetes 기본 지원됩니다. 대신 롤백이 점진적이고 버전 공존 문제를 관리해야 합니다.
도구 선택은 "롤백 속도 × 버전 공존 허용 × 리소스 여유 × 운영 역량"의 조합으로 결정합니다.
실무에서는 핵심 서비스(결제, 인증)에 Blue-Green, 나머지 서비스에 Rolling Update를 적용하는 하이브리드 패턴이 흔합니다.
어떤 전략을 선택하든 DB 스키마 변경은 Expand and Contract 패턴으로 별도 관리해야 합니다.
Kubernetes 생태계에서는 Argo Rollouts가 두 전략을 모두 지원하는 사실상 표준(de facto standard) 도구입니다.

참고 문서

'DevOps' 카테고리의 다른 글

GitHub Actions와 Jenkins 차이: CI/CD 도구 선택 기준 (0)	2026.06.08
GitHub Actions로 Docker 이미지를 빌드하고 배포하기: CI/CD 파이프라인 실습 (0)	2026.06.06
Terraform S3 Backend와 State Lock 구성하기: 팀 협업을 위한 원격 상태 관리 (0)	2026.05.31
CI/CD 파이프라인 기본 구조: 코드 커밋부터 프로덕션 배포까지 (0)	2026.05.29
Terraform State란 무엇인가: 상태 관리의 개념과 실무 운영 전략 (0)	2026.05.28

Blue-Green Deployment와 Rolling Update 차이: 배포 전략 선택 기준

핵심 요약

1. 왜 이 비교가 필요한가

2. Blue-Green Deployment 동작 원리

배포 과정

롤백 과정

Kubernetes에서의 구현

Blue-Green의 장단점

3. Rolling Update 동작 원리

배포 과정

핵심 파라미터

maxSurge/maxUnavailable 조합별 동작

롤백 과정

Rolling Update의 장단점

4. 구조 비교

5. 실무 시나리오로 이해하기

시나리오 1: 결제 API 서버 배포

시나리오 2: 내부 관리자 페이지 배포

시나리오 3: 마이크로서비스 아키텍처의 API Gateway

6. 배포 중 두 버전 공존 문제

문제가 되는 경우

해결 방법

7. 롤백 시간 비교

Blue-Green 롤백

Rolling Update 롤백

실무에서의 롤백 시간 차이

8. 비용과 리소스 비교

Blue-Green 리소스 요구량

Rolling Update 리소스 요구량

비용 시나리오

시나리오: 월 20회 배포, Pod 20개, 배포당 10분 소요

9. 데이터베이스 마이그레이션 시 고려사항

Blue-Green + DB 변경

Rolling Update + DB 변경

공통 원칙: Expand and Contract

10. 선택 의사결정 플로우

1단계: 롤백 요구사항 확인

2단계: 버전 공존 허용 여부

3단계: 리소스 여유 확인

4단계: 운영 도구/역량 확인

종합 판단 기준

11. Argo Rollouts로 두 전략 구현하기

Argo Rollouts 개요

Blue-Green 설정 예시

운영 명령어

12. 정리

참고 문서

'DevOps' 카테고리의 다른 글

'DevOps' Related Articles

티스토리툴바