이종관
Back to Posts

Blue/Green 배포 (1): 무중단 배포의 기초와 전략

Blue/Green 배포의 개념, 다른 전략과의 비교, 장단점, 그리고 Feature Flag와의 차이점까지

2026년 1월 27일·9 min read·
infra
deployment
blue-green
devops
release
zero-downtime

이 글은 Blue/Green 배포 시리즈의 첫 번째 글입니다.

  1. 기초와 전략 (현재 글)
  2. Kubernetes 구현
  3. 클라우드 & CI/CD 통합
  4. 운영 및 최적화

1. Blue/Green 배포란?

Blue/Green 배포는 동일한 두 환경(Blue, Green)을 동시에 운영하고, 트래픽을 한 번에 전환하는 배포 전략입니다.

  • Blue: 현재 운영 중인 안정 버전 (Old)
  • Green: 새 버전을 배포하고 검증하는 환경 (New)

트래픽 전환은 로드밸런서/서비스 라우팅 설정으로 제어하며, 문제가 생기면 즉시 Blue로 롤백할 수 있어 무중단 운영의 핵심 기법 중 하나입니다.

왜 "Blue"와 "Green"인가?

색상에 특별한 의미는 없습니다. 단순히 두 환경을 구분하기 위한 명명 규칙입니다. 어떤 조직에서는 "A/B", "Primary/Secondary", "Live/Staging" 등의 용어를 사용하기도 합니다.

2. 배포 전략 비교

Blue/Green 배포를 이해하기 위해 주요 배포 전략들과 비교해봅시다.

2.1 전략별 특성 비교

전략설명전환 방식롤백 속도
Recreate기존 버전 중단 → 새 버전 시작전체 교체느림 (재배포 필요)
Rolling Update인스턴스를 하나씩 새 버전으로 교체점진적중간
Blue/Green전체 환경을 한 번에 전환즉시 전환즉시
Canary일부 트래픽만 먼저 노출 후 확대비율 조정빠름
A/B Testing사용자 특성별로 다른 버전 노출조건부 라우팅빠름

2.2 리소스 및 복잡도 비교

전략추가 리소스다운타임운영 복잡도테스트 격리
Recreate없음있음낮음없음
Rolling Update최소없음낮음부분적
Blue/Green2배없음중간완벽
Canary최소~중간없음높음부분적
A/B Testing중간없음높음부분적

2.3 언제 어떤 전략을 선택할까?

3. 장점과 한계

3.1 장점

무중단 전환

로드밸런서 스위칭만으로 서비스 중단 없이 배포가 가능합니다.

완벽한 격리

Green 환경에서 운영과 동일한 조건으로 최종 테스트가 가능합니다.

  • 실제 트래픽을 받기 전 내부 테스트 수행
  • 성능 테스트, 보안 스캔, QA 검증 가능
  • 문제 발견 시 사용자에게 영향 없음

초고속 롤백

문제가 발견되면 라우팅 설정만 변경하면 됩니다.

# 롤백 소요 시간
Recreate:       5-10분 (재배포)
Rolling Update: 2-5분  (점진적 롤백)
Blue/Green:     수 초   (라우팅 변경만)

3.2 한계

인프라 비용

동일한 환경이 2개 필요하므로 비용 부담이 큽니다.

일반 배포:    서버 10대 × $100/월 = $1,000/월
Blue/Green:  서버 20대 × $100/월 = $2,000/월
                                   ────────
                                   +$1,000/월

비용 최적화 팁: 시리즈 4편에서 Spot 인스턴스, 자동 스케일링 등 비용 절감 방법을 다룹니다.

데이터 일관성

전환 시점의 DB 상태나 캐시 데이터가 동기화되어 있어야 합니다.

문제 시나리오:

  1. Blue(v1)에서 사용자가 주문 생성
  2. 주문 데이터가 DB에 저장됨
  3. Green(v2)으로 전환
  4. Green에서 해당 주문 처리 시 스키마 불일치 발생 가능

세션 유지

전환 시 기존 Blue 유저들의 세션 유실 대책이 필요합니다.

해결책: Redis 같은 외부 세션 스토리지 사용

4. 기본 배포 흐름

4.1 5단계 배포 프로세스

4.2 각 단계별 체크리스트

단계수행 작업성공 기준
Step 1현재 상태 확인Blue 정상 운영 중
Step 2Green 환경에 새 버전 배포모든 Pod/인스턴스 기동
Step 3Health Check, Smoke Test모든 테스트 통과
Step 4로드밸런서 설정 변경트래픽 100% Green
Step 5모니터링 및 Blue 정리에러율 정상 범위

5. Feature Flag와의 비교

Blue/Green 배포와 Feature Flag는 모두 "안전한 릴리스"를 위한 기법이지만, 적용 계층과 목적이 다릅니다.

5.1 개념 비교

구분Blue/GreenFeature Flag
적용 계층인프라 (서버/환경)코드 (기능)
전환 단위전체 애플리케이션개별 기능
롤백 방식라우팅 변경플래그 OFF
대상 제어모든 사용자특정 사용자/그룹 가능
추가 코드불필요조건문 필요

5.2 Feature Flag 예시

# Feature Flag 사용 예시
def get_checkout_page(user):
    if feature_flags.is_enabled("new_checkout", user):
        return render_new_checkout()  # 새 기능
    else:
        return render_old_checkout()  # 기존 기능

5.3 언제 어떤 것을 사용할까?

5.4 조합 사용 (Best Practice)

실제 운영에서는 두 기법을 함께 사용하는 것이 효과적입니다.

조합 사용의 장점:

  • Blue/Green으로 인프라 수준의 안전한 배포
  • Feature Flag로 기능 수준의 세밀한 제어
  • 문제 발생 시 두 단계의 롤백 옵션

6. 다음 단계

이 글에서는 Blue/Green 배포의 기초 개념과 다른 전략과의 비교를 살펴보았습니다.

다음 글에서는 Kubernetes에서 Blue/Green 배포를 구현하는 방법을 다룹니다:

  • 순수 Kubernetes Service/Deployment 활용
  • Argo Rollouts를 통한 자동화
  • Istio Service Mesh 연동
  • DB 스키마 마이그레이션 전략

다음 글: Blue/Green 배포 (2) - Kubernetes 구현 →