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

Blue/Green은 동일한 두 환경을 두고 트래픽을 한 번에 전환해 무중단 배포와 즉시 롤백을 얻는 전략이다.

TL;DR

Blue/Green은 동일한 두 환경을 동시에 두고 트래픽을 한 번에 전환해 무중단 배포와 즉시 롤백을 얻는 전략이다.
대가는 환경 2배의 인프라 비용과 전환 시점의 데이터·세션·연결 일관성 관리다.
전체 앱 단위 전환은 Blue/Green, 기능 단위 제어는 Feature Flag로 나뉘며, 둘을 함께 쓰면 인프라와 기능 양쪽에서 롤백 옵션을 확보한다.

Blue/Green 배포란?

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

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

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

왜 "Blue"와 "Green"인가?

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

배포 전략 비교

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

전략별 특성 비교

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

리소스 및 복잡도 비교

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

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

장점과 한계

장점

무중단 전환

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

완벽한 격리

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

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

초고속 롤백

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

text

# 롤백 소요 시간 (환경·규모에 따라 다른 추정치)
Recreate:       5-10분 (재배포)
Rolling Update: 2-5분  (점진적 롤백)
Blue/Green:     수 초   (라우팅 변경만)

한계

인프라 비용

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

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

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

데이터 일관성

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

문제 시나리오:

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

세션 유지

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

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

상태 있는 연결과 작업

무상태 HTTP 요청과 달리, 오래 유지되는 연결이나 실행 중인 작업은 즉시 전환의 사각지대다. 전환 순간에 끊기거나 두 버전에 걸쳐 실행될 수 있다.

장기 연결(WebSocket, 스트리밍): 전환 후에도 기존 Blue 연결이 끝날 때까지 Blue를 유지(connection draining)한 뒤 정리한다.
비동기 작업(큐 컨슈머): 큐 메시지 포맷을 버전 간 호환되게 유지해야 Green이 Blue가 넣은 메시지를 처리할 수 있다.
배치/크론: 전환 시점에 두 환경이 같은 작업을 중복 실행하지 않도록 분산 잠금을 걸거나 한쪽 환경에서만 돌린다.

이 셋은 4편의 Connection Draining, 세션 외부화와 직접 이어진다.

기본 배포 흐름

5단계 배포 프로세스

각 단계별 체크리스트

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

Feature Flag와의 비교

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

개념 비교

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

Feature Flag 예시

python

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

is_enabled의 첫 인자는 플래그 키이고, 둘째 인자는 대상 사용자다. 같은 코드에서 사용자별로 새 기능과 기존 기능을 분기한다.

언제 어떤 것을 사용할까?

조합 사용

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

조합 사용의 장점:

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

정리

Blue/Green은 동일한 두 환경을 두고 로드밸런서 라우팅만 바꿔 트래픽을 한 번에 전환한다. 무중단 배포와 즉시 롤백을 얻는 대신 환경 2배의 인프라 비용과 전환 시점의 데이터·세션·연결 일관성 관리를 감수한다. 전체 앱 단위 전환에는 Blue/Green, 기능 단위 제어에는 Feature Flag가 맞고, 둘을 함께 쓰면 인프라와 기능 양쪽에서 롤백 옵션을 확보한다. 다음 글에서는 데이터 일관성과 세션 유지, Connection Draining 같은 전환 시점의 실무 문제를 다룬다.