Blue-Green / Canary 배포: 서비스를 중단 없이 업데이트하는 기술

들어가며: "점검 안내: 오전 2시~6시 서비스 중단"

새벽 2시. 서버실 형광등 아래에서 엔지니어 세 명이 긴장한 얼굴로 모니터를 바라본다. 한 명이 "배포 시작합니다"라고 말하고, 서버를 내린다. 그 순간부터 시계와의 싸움이 시작된다. 4시간 안에 새 버전을 올리고, 테스트하고, 문제가 없는지 확인해야 한다. 만약 뭔가 잘못되면? 다시 이전 버전으로 되돌려야 한다. 시간은 오전 6시까지밖에 없다.

2026년인데, 왜 아직도 이런 일이 벌어질까?

이유는 간단하다. 배포 = 서비스 중단이라는 공식을 깨지 못했기 때문이다.

하지만 넷플릭스는 하루에 수천 번 배포한다. 아마존은 평균 11.7초마다 코드를 프로덕션에 올린다. 사용자는 전혀 눈치채지 못한다. 어떻게?

답은 배포 전략(Deployment Strategy)에 있다. 이 글에서는 서비스를 한 번도 멈추지 않고 업데이트하는 핵심 기술 — Rolling, Blue-Green, Canary 배포 — 의 원리부터 실전 구현까지 풀어본다.

1. 문제 정의: 배포가 두려운 이유

전통적 배포의 공포

전통적인 배포(Recreate 또는 Big Bang 배포)는 단순하다. 기존 서버를 전부 내리고, 새 버전을 전부 올린다. 마치 가게를 닫고, 인테리어를 바꾸고, 다시 여는 것과 같다.

이 방식의 문제점은 명확하다:

1. 다운타임: 서버를 내리는 순간부터 새 버전이 안정화될 때까지, 사용자는 서비스를 사용할 수 없다.
2. 롤백 공포: 새 버전에 버그가 있으면? 다시 이전 버전으로 되돌려야 하는데, 그것도 또 다운타임이 필요하다.
3. 데이터 불일치: 배포 중 DB 스키마가 바뀌면, 이전 버전으로 되돌리는 것 자체가 불가능할 수 있다.
4. 심리적 압박: "이번 배포 실패하면 매출 손실이 얼마야?" — 이 질문이 엔지니어를 새벽에 출근하게 만든다.

다운타임의 실제 비용

현대 소프트웨어 개발에서 배포 전략은 "선택"이 아니라 생존 전략이다. 그래서 업계는 수십 년에 걸쳐 서비스를 멈추지 않고 업데이트하는 방법을 발전시켜 왔다.

2. Rolling 배포: 하나씩 차례로 교체하기

개념

Rolling 배포는 가장 직관적인 무중단 배포 방식이다. 서버(인스턴스)를 한 대씩 또는 몇 대씩 순서대로 교체한다. 전체를 한꺼번에 내리지 않으므로, 나머지 서버들이 트래픽을 계속 처리한다.

비유하자면: 도로 위의 차선을 하나씩 보수하는 것과 같다. 전체 도로를 폐쇄하지 않고, 한 차선씩 작업하면서 나머지 차선으로 교통을 유지한다.

동작 원리

서버 4대가 v1을 실행하고 있다고 가정하자.

핵심 포인트

배포 중에는 v1과 v2가 동시에 존재한다. 이것이 Rolling 배포의 가장 큰 특징이자 주의점이다.

예를 들어, 쇼핑몰 API에서 v1은 장바구니 응답에 totalPrice를 보내고, v2는 totalAmount로 필드명을 바꿨다면? Step 2 시점에는 서버 A(v2)와 서버 B~D(v1)가 공존한다. 프론트엔드가 두 형식을 모두 처리하지 못하면, 일부 사용자에게 에러가 발생한다.

이것을 호환성(backward compatibility) 문제라고 하며, Rolling 배포에서 가장 신경 써야 하는 부분이다.

장단점

3. Blue-Green 배포: 두 개의 동일한 환경, 순간 전환

개념

Blue-Green 배포는 완전히 동일한 두 세트의 프로덕션 환경을 유지하는 전략이다. 한쪽(Blue)은 현재 라이브 버전, 다른 쪽(Green)은 새 버전을 준비하는 용도다.

비유하자면: 연극 무대가 두 개인 극장이다. 한쪽 무대에서 공연이 진행되는 동안, 다른 무대에서 다음 공연을 세팅한다. 준비가 끝나면 관객석을 180도 돌려서 새 무대를 보여준다. 관객은 전환이 일어나는 순간을 거의 느끼지 못한다.

동작 원리

왜 "순간 전환"이 가능한가

핵심은 트래픽 라우팅의 분리다. 서버를 내리는 것이 아니라, 로드밸런서가 가리키는 방향만 바꾼다. 라우팅 변경은 밀리초 단위로 일어나므로, 사용자 입장에서 다운타임은 0에 가깝다.

# Green 타겟 그룹으로 트래픽 100% 전환
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-2:...:listener/... \
  --default-actions Type=forward,TargetGroupArn=arn:aws:...:targetgroup/green-tg/...

# 문제 발생 시 즉시 Blue로 롤백
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:ap-northeast-2:...:listener/... \
  --default-actions Type=forward,TargetGroupArn=arn:aws:...:targetgroup/blue-tg/...

장단점

4. Canary 배포: 새 버전에 5%의 트래픽만 먼저 보내기

개념

Canary 배포는 새 버전을 극소수의 사용자에게 먼저 노출하고, 문제가 없으면 점진적으로 전체에 확대하는 전략이다.

이름의 유래는 탄광의 카나리아새(canary in a coal mine)다. 과거 광부들은 독성 가스를 감지하기 위해 카나리아를 탄광에 먼저 보냈다. 카나리아가 무사하면 사람이 들어갔다. 마찬가지로, 소수의 트래픽으로 새 버전을 먼저 "탐지"하고, 안전하면 전체로 확대한다.

동작 원리

자동 롤백의 힘

Canary 배포의 핵심 가치는 자동화된 의사결정이다. 사람이 모니터를 뚫어져라 쳐다보며 "이거 괜찮은 것 같은데..."라고 판단하는 것이 아니라, 미리 정의한 메트릭 기준에 따라 시스템이 자동으로 진행/롤백을 결정한다.

canary:
  steps:
    - setWeight: 5
    - pause: { duration: 5m }
    - analysis:
        metrics:
          - name: error-rate
            threshold: 0.1     # 에러율 0.1% 초과 시 롤백
          - name: latency-p99
            threshold: 500     # p99 레이턴시 500ms 초과 시 롤백
          - name: success-rate
            threshold: 99.9    # 성공률 99.9% 미만 시 롤백
    - setWeight: 25
    - pause: { duration: 10m }
    - analysis: ...
    - setWeight: 50
    - pause: { duration: 10m }
    - setWeight: 100

장단점

5. A/B 테스트 vs Canary: 비슷해 보이지만 목적이 다르다

A/B 테스트와 Canary 배포는 둘 다 "일부 사용자에게 다른 버전을 보여준다"는 점에서 비슷해 보인다. 하지만 목적이 완전히 다르다.

Canary는 "이 코드가 프로덕션에서 안전한가?"를 확인하고, A/B 테스트는 "어떤 디자인/기능이 비즈니스에 더 유리한가?"를 확인한다.

실무에서는 이 둘을 결합하기도 한다. 새 기능을 Canary로 안전하게 배포한 후, Feature Flag으로 A/B 테스트를 실행하는 식이다. 이 때 Feature Flag이 핵심 역할을 한다.

6. Feature Flag: 코드는 배포하되, 기능은 아직 숨기기

개념

Feature Flag(기능 플래그, Feature Toggle이라고도 한다)은 코드를 배포하는 것과 기능을 활성화하는 것을 분리하는 기법이다.

쉽게 말하면: 가게에 새 메뉴판을 설치하되, 종이로 가려 놓는 것이다. 메뉴판(코드)은 이미 배포됐지만, 손님(사용자)은 볼 수 없다. 준비가 되면 종이(플래그)만 벗기면 된다.

# 기능 플래그 확인
if feature_flags.is_enabled("new-checkout-flow", user_id=user.id):
    # 새로운 결제 플로우
    return new_checkout_handler(request)
else:
    # 기존 결제 플로우
    return legacy_checkout_handler(request)

Feature Flag의 종류

Feature Flag + 배포 전략 = 최강 조합

Feature Flag은 단독으로도 유용하지만, 배포 전략과 결합하면 강력해진다.

이 조합의 장점:

• 배포와 릴리즈의 분리: 코드가 프로덕션에 있어도, 기능은 아직 사용자에게 보이지 않는다.
• 즉시 비활성화: 문제 발생 시 플래그만 끄면 된다. 재배포 불필요.
• 점진적 출시: 1% → 5% → 20% → 100% 식으로 기능을 점진적으로 공개할 수 있다.
• 시간 지정 릴리즈: "화요일 오전 10시에 새 기능 공개" — 마케팅 타이밍에 맞출 수 있다.

7. 전략 비교: Rolling vs Blue-Green vs Canary

여기까지 세 가지 핵심 배포 전략을 살펴봤다. 이제 한눈에 비교해 보자.

하나만 선택해야 하는 것은 아니다. 실무에서는 이 전략들을 조합한다. 예를 들어:

• Blue-Green + Canary: Green 환경에 배포 후, 전체 전환 대신 Canary 방식으로 트래픽을 점진적으로 이동
• Rolling + Feature Flag: Rolling으로 코드를 배포하되, 새 기능은 Flag으로 제어
• Canary + 자동 롤백 + Feature Flag: 가장 정교한 조합. Netflix가 이 방식을 사용

8. AWS에서 구현하기

이론을 알았으니, 실제로 AWS에서 어떻게 구현하는지 살펴보자. AWS는 각 배포 전략을 위한 도구를 이미 제공하고 있다.

8-1. ECS Rolling Update (기본 내장)

ECS(Elastic Container Service)는 Rolling 배포를 기본 배포 방식으로 제공한다. 별도 설정 없이 바로 사용할 수 있다.

{
  "serviceName": "my-web-app",
  "desiredCount": 4,
  "deploymentConfiguration": {
    "minimumHealthyPercent": 50,
    "maximumPercent": 200
  },
  "deploymentController": {
    "type": "ECS"
  }
}

• minimumHealthyPercent: 50 → 배포 중에도 최소 2대(4대의 50%)는 항상 정상 유지
• maximumPercent: 200 → 배포 중 최대 8대(4대의 200%)까지 동시 실행 가능

ECS는 자동으로 새 태스크를 시작하고, 헬스 체크를 통과하면 이전 태스크를 종료한다. 이것만으로도 무중단 Rolling 배포가 완성된다.

8-2. ALB Weighted Target Group (Blue-Green / Canary)

ALB(Application Load Balancer)의 가중치 타겟 그룹(Weighted Target Group)을 사용하면 Blue-Green과 Canary 배포를 모두 구현할 수 있다.

# Canary: v2에 5% 트래픽 할당
aws elbv2 modify-rule \
  --rule-arn $RULE_ARN \
  --actions '[
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {"TargetGroupArn": "'$BLUE_TG_ARN'", "Weight": 95},
          {"TargetGroupArn": "'$GREEN_TG_ARN'", "Weight": 5}
        ]
      }
    }
  ]'

# 안정 확인 후 50:50으로 확대
aws elbv2 modify-rule \
  --rule-arn $RULE_ARN \
  --actions '[
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {"TargetGroupArn": "'$BLUE_TG_ARN'", "Weight": 50},
          {"TargetGroupArn": "'$GREEN_TG_ARN'", "Weight": 50}
        ]
      }
    }
  ]'

# 최종 전환: v2로 100%
aws elbv2 modify-rule \
  --rule-arn $RULE_ARN \
  --actions '[
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {"TargetGroupArn": "'$GREEN_TG_ARN'", "Weight": 100}
        ]
      }
    }
  ]'

8-3. AWS CodeDeploy (자동화된 Blue-Green / Canary)

CodeDeploy는 AWS의 공식 배포 자동화 서비스다. ECS, EC2, Lambda에 대해 Blue-Green 및 Canary 배포를 코드 한 줄 없이 설정할 수 있다.

version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:ap-northeast-2:...:task-definition/my-app:2"
        LoadBalancerInfo:
          ContainerName: "my-app"
          ContainerPort: 8080
        PlatformVersion: "LATEST"

Hooks:
  - BeforeAllowTraffic: "arn:aws:lambda:...:function:smoke-test"
  - AfterAllowTraffic: "arn:aws:lambda:...:function:integration-test"

BeforeAllowTraffic 훅에서 Lambda를 실행하여 새 버전의 smoke test를 자동으로 수행한다. 테스트가 실패하면 배포를 자동으로 중단하고 롤백한다.

8-4. 아키텍처 전체도

9. 실전 사례: Netflix와 Amazon

Netflix: Canary 배포의 교과서

Netflix는 Canary 배포를 가장 정교하게 운영하는 기업 중 하나다. Spinnaker라는 오픈소스 배포 플랫폼을 직접 만들어 공개했다.

Netflix의 Canary 분석 시스템 Kayenta는 단순히 "에러율이 높은가?"만 보지 않는다. 통계적 가설 검정(statistical hypothesis testing)을 사용한다.

Netflix Canary 배포의 핵심 원칙:

• 항상 Baseline을 함께 띄운다: v1 트래픽의 일부를 "새로 띄운 v1 인스턴스(Baseline)"로도 보낸다. Canary(v2) vs Baseline(v1)을 동일 조건에서 비교해야 정확하다.
• 충분한 데이터를 수집한다: 최소 30분 이상 관찰. 짧은 관찰은 노이즈에 속을 수 있다.
• 여러 메트릭을 종합 판단한다: CPU, 메모리, 에러율, 레이턴시 p50/p99, JVM GC 시간 등 수십 개의 메트릭을 동시에 비교한다.

Amazon: One-Box 배포

Amazon은 One-Box 배포라는 독자적인 Canary 변형을 사용한다. 전체 리전의 서버 중 딱 한 대(one box)에만 새 버전을 배포하고, 그 한 대의 메트릭을 나머지 서버들과 비교한다.

Amazon이 이 방식을 사용하는 이유: 글로벌 규모에서의 안전. 전 세계 수십 개 리전에 동시에 배포하면, 문제 발생 시 영향 범위가 너무 크다. One-Box → Regional → Global의 3단계 확산으로, 문제를 가장 이른 시점에 가장 작은 범위에서 잡는다.

10. 데이터베이스 마이그레이션: 배포 전략의 숨은 난제

배포 전략을 설명할 때 흔히 빠지는 것이 있다. 데이터베이스다.

애플리케이션 서버는 여러 대를 띄울 수 있고, 트래픽을 나눌 수 있지만, 데이터베이스는 보통 하나다. v1과 v2가 공존하는 Rolling/Canary 배포 중에 DB 스키마가 바뀌면 어떻게 될까?

잘못된 예: 컬럼명 변경

v1은 user_name 컬럼을 사용하고, v2는 username으로 변경했다고 가정하자.

DB를 v2에 맞게 바꾸면 v1이 깨지고, v1에 맞게 놔두면 v2가 깨진다. Blue-Green 배포라면 순간 전환이므로 이 문제가 상대적으로 적지만, Rolling과 Canary에서는 심각하다.

올바른 접근: Expand-Contract 패턴

DB 스키마 변경은 3단계로 나누어 진행한다.

이 패턴의 핵심: DB 변경은 코드 배포보다 최소 한 단계 앞서야 한다. 코드가 v1 → v2로 바뀌기 전에, DB는 이미 v1과 v2를 모두 지원하는 상태여야 한다.

11. 선택 가이드: 우리 팀에 맞는 전략은?

"어떤 전략이 가장 좋은가?"라는 질문에 정답은 없다. 팀의 상황에 따라 다르다.

의사결정 프레임워크

팀 규모와 성숙도별 추천

산업별 고려사항

• 핀테크/금융: Blue-Green 선호. 즉시 롤백이 규제 요건인 경우가 많다. Canary의 "5% 사용자가 버그를 경험"이 허용되지 않을 수 있다.
• 이커머스: Canary + Feature Flag. 매출에 직접 영향을 미치므로, 실제 트래픽으로 전환율을 검증해야 한다.
• 미디어/스트리밍: Canary가 필수. 비디오 재생 품질, 버퍼링 비율 같은 사용자 경험 메트릭을 실시간 비교해야 한다.
• 내부 도구/B2B SaaS: Rolling으로 시작해도 충분. 사용자가 상대적으로 적고, 문제 발생 시 직접 소통이 가능하다.

12. 실전 체크리스트: 무중단 배포를 시작하기 전에

어떤 전략을 선택하든, 다음 사항을 먼저 갖춰야 한다.

필수 인프라

코드 레벨 준비사항

1. Graceful Shutdown: 서버가 종료 신호(SIGTERM)를 받으면, 처리 중인 요청을 완료한 후 종료해야 한다. 갑자기 끊으면 사용자가 에러를 경험한다.

process.on('SIGTERM', async () => {
  console.log('SIGTERM received. Graceful shutdown...');
  
  // 새 요청 수신 중단
  server.close();
  
  // 처리 중인 요청 완료 대기 (최대 30초)
  await new Promise(resolve => setTimeout(resolve, 30000));
  
  // DB 연결 종료
  await db.disconnect();
  
  process.exit(0);
});

1. Backward Compatible API: v1과 v2가 공존할 수 있도록, API 변경은 항상 하위 호환성을 유지한다. 필드를 삭제하지 말고, 새 필드를 추가하라.

2. DB 마이그레이션 분리: 스키마 변경은 코드 배포와 별도로 실행한다. Expand-Contract 패턴을 사용한다.

3. 헬스 체크 엔드포인트: 단순 200 OK가 아니라, DB 연결, 캐시 상태, 의존 서비스 연결까지 확인하는 심층 헬스 체크를 구현한다.

{
  "status": "healthy",
  "version": "2.3.1",
  "uptime": "4h 23m",
  "checks": {
    "database": { "status": "healthy", "latency_ms": 3 },
    "redis": { "status": "healthy", "latency_ms": 1 },
    "external_api": { "status": "degraded", "latency_ms": 450 }
  }
}

마치며: 배포는 이벤트가 아니라 일상이어야 한다

"다음 주 금요일 자정에 배포합니다" — 이 문장에는 무의식적인 가정이 들어 있다. 배포는 특별한 이벤트이고, 위험하고, 사람이 적은 시간에 해야 한다는 가정.

하지만 Netflix, Amazon, Google 같은 기업에서 배포는 이벤트가 아니다. 코드를 푸시하면 자동으로 일어나는 일상이다. 하루에 수천 번 배포하면서도 사용자는 전혀 눈치채지 못한다.

이것이 가능한 이유는 특별한 마법이 아니라, 이 글에서 다룬 기술들의 조합이다:

처음부터 Canary + Feature Flag + 자동 롤백을 구축할 필요는 없다. Rolling 배포로 시작하고, 팀이 성장하고 서비스가 커지면서 한 단계씩 올라가면 된다.

중요한 것은 방향이다. "점검 안내: 오전 2시~6시 서비스 중단"이라는 공지를 보내야 하는 상황에서, 그 공지를 영영 보내지 않아도 되는 상황으로. 그 여정의 첫걸음이 이 글에서 다룬 배포 전략이다.

서비스를 멈추지 않고 업데이트하는 것. 그것은 사용자에 대한 존중이고, 엔지니어 삶의 질에 대한 투자이며, 비즈니스 연속성에 대한 보장이다.