프로그레시브 딜리버리 — 위험을 점진적으로 흘려보내는 배포

지난 글에서 Git 머지가 곧 배포가 되는 GitOps의 세계에 도착했다. 그런데 “배포한다”는 행위 자체를 한 번 더 들여다볼 필요가 있다. 새 버전을 모든 사용자에게 동시에 노출하는 순간, 그 버전에 숨은 버그는 곧바로 전체 트래픽에 영향을 준다. 프로그레시브 딜리버리(progressive delivery)는 바로 이 “한 방에 전부” 노출되는 위험을 잘게 쪼개, 새 버전을 소수에게 먼저 보여주고 실제 운영 메트릭으로 건강 상태를 확인하면서 점진적으로 비중을 넓혀가는 배포 철학이다.

롤링 업데이트만으로 충분하지 않은 이유

Deployment의 기본 전략인 롤링 업데이트는 이미 훌륭하다. Pod를 하나씩 새 버전으로 교체하며 무중단으로 배포한다. 하지만 두 가지 본질적인 한계가 있다.

첫째, 검증의 부재다. 롤링 업데이트는 새 Pod가 readiness 프로브를 통과하면 “건강하다”고 판단한다. 하지만 프로브가 통과해도 비즈니스 로직에 버그가 있을 수 있다. 에러율이 치솟거나 응답이 느려져도, 프로브만 OK라면 롤링은 멈추지 않고 끝까지 진행한다.

둘째, 롤백의 비용이다. 문제를 발견했을 때 이미 상당수 Pod가 새 버전으로 바뀐 상태이고, 되돌리려면 또 한 번의 롤링이 필요하다. 그동안 사용자는 계속 깨진 버전을 만난다.

블루-그린과 카나리는 이 한계를 서로 다른 방식으로 보완한다.

블루-그린 — 전체를 띄워두고 전환

블루-그린은 현재 운영 중인 버전(Blue)을 그대로 두고, 새 버전(Green)을 별도의 전체 세트로 띄운다. Green이 완전히 준비되고 스모크 테스트까지 끝나면, 서비스가 가리키는 대상을 Blue에서 Green으로 한 번에 전환한다.

장점은 명확하다. 전환이 즉각적이고, 문제가 생기면 다시 Blue로 즉시 되돌릴 수 있다(Green을 지우지 않았으므로). 전환 전에 운영과 동일한 환경에서 새 버전을 충분히 검증할 수도 있다.

단점도 분명하다. 두 버전을 동시에 띄우므로 리소스가 약 2배 필요하고, 무엇보다 전환 자체는 여전히 “100%를 한 번에” 바꾸는 행위다. Green에 숨은 버그가 있다면 전환 직후 전체 사용자가 영향을 받는다. 빠른 롤백이 가능할 뿐, 노출을 점진적으로 줄이는 것은 아니다.

카나리 — 소수의 트래픽으로 먼저 확인한다

카나리(canary)는 이름 그대로 “탄광의 카나리아”에서 왔다. 새 버전에 전체 트래픽의 일부(예: 5%)만 흘려보내고, 그 소수 트래픽에서 나오는 에러율과 지연을 관찰한다. 건강하면 비중을 25%, 50%, 100%로 단계적으로 넓히고, 이상이 보이면 즉시 트래픽을 원래 버전으로 되돌린다.

핵심은 각 단계 사이에 “분석 게이트”가 있다는 점이다. 단순히 시간이 지나면 다음 단계로 가는 게 아니라, 실제 메트릭이 임계치를 통과해야만 승급한다.

이 분석 게이트가 프로그레시브 딜리버리를 단순한 트래픽 분배와 구분 짓는 핵심이다. 사람이 대시보드를 보며 “괜찮은 것 같다”고 판단하는 대신, 정량적 기준으로 자동 판정한다.

무엇을 기준으로 “건강하다”고 판단할까

분석 게이트가 의미를 가지려면 좋은 메트릭을 골라야 한다. 흔히 쓰이는 신호는 다음과 같다.

# 카나리 분석에서 자주 쓰는 메트릭(개념 예시)
metrics:
  - name: error-rate          # HTTP 5xx 비율
    threshold: "< 1%"
  - name: latency-p99         # 99 백분위 응답 지연
    threshold: "< 500ms"
  - name: success-rate        # 정상 응답 비율
    threshold: "> 99%"
  # 카나리 vs 안정 버전을 '동시에' 비교하면 더 정확하다

여기서 중요한 기법이 카나리와 안정 버전을 동시에 비교하는 것이다. 단순히 “카나리의 에러율이 1% 미만인가”가 아니라, “카나리의 에러율이 안정 버전보다 유의미하게 높은가”를 본다. 트래픽 패턴이나 외부 의존성 때문에 양쪽 모두 에러율이 잠깐 오를 수 있는데, 절대 임계치만 보면 멀쩡한 카나리를 잘못 롤백할 수 있기 때문이다.

트래픽을 어떻게 나눌 것인가

카나리가 성립하려면 “5%만 새 버전으로”를 실제로 구현할 수단이 필요하다. 크게 두 갈래다.

# 1) Pod 개수 비율로 근사 (단순)
replicas: stable=9, canary=1   →  Service가 10개로 분산 ≈ 10%

# 2) 트래픽 레이어에서 정밀 분배 (정확)
Ingress / Gateway API / Service Mesh
  → 헤더·가중치 기반으로 정확히 5% 라우팅

Pod 개수 비율은 별도 도구 없이 가능하지만, replica 수에 비율이 묶여 정밀하지 않다(10%를 만들려면 최소 10개 필요). 반면 인그레스 컨트롤러, Gateway API, 또는 서비스 메시(Istio, Linkerd)는 트래픽 레이어에서 가중치를 직접 제어하므로 replica 수와 무관하게 정확한 비율을 만들 수 있다. 실무에서 정밀한 카나리는 거의 트래픽 레이어 분배에 의존한다.

정리 — 그리고 다음

프로그레시브 딜리버리는 “배포 = 위험한 한 순간”이라는 전제를 “배포 = 관찰하며 통제 가능한 과정”으로 바꾼다. 롤링은 간단하지만 검증과 롤백이 약하고, 블루-그린은 빠른 전환·롤백을 주지만 노출은 여전히 한 번에 일어나며, 카나리는 메트릭 기반 자동 분석으로 노출을 잘게 쪼개고 단계적으로 넓힌다. 셋은 배타적이지 않아서, 블루-그린의 환경 격리와 카나리의 점진 노출을 섞어 쓰기도 한다.

다만 이 모든 것을 직접 손으로 구현하려면 트래픽 분배, 메트릭 조회, 단계 진행, 자동 롤백을 일일이 엮어야 한다. 그래서 Kubernetes 생태계에는 이를 선언형 CRD로 자동화해 주는 도구가 있다. 다음 글에서는 그중 대표 격인 Argo Rollouts로 카나리와 블루-그린을 실제로 구현하는 방법을 살펴본다.

---

지난 글: Flux — GitOps 툴킷으로 구축하는 자동 배포

다음 글: Argo Rollouts — 카나리·블루그린 배포 자동화

읽어주셔서 감사합니다. 😊