카나리 배포, 언제 블루그린 대신 고르나

카나리 배포, 언제 블루그린 대신 골라야 할까?

결론부터 적으면 이렇다. 배포 실패 시 영향 범위를 좁게 잡고 싶고, 관측·롤백 자동화에 투자할 여력이 있다면 카나리 쪽으로 기운다. 반대로 전환 절차의 단순함과 롤백 속도가 우선이고 인프라 중복 비용을 감수할 수 있다면 블루그린이 더 맞는 선택이다. 다만 어느 쪽도 "무중단을 보장"하지는 않는다 — 카나리는 관측이 느리면 소용없고, 블루그린은 전환 자체가 급격해서 잘못 넘어가면 100%가 한 번에 흔들린다.

핵심 요약

• 블루그린은 100% 트래픽을 한 번에 전환하는 방식이고, 카나리는 1%→5%→20%→50%→100%처럼 점진 확대하는 방식이다 NGINX 블로그 기준 설명이 이렇게 갈린다.
• 카나리는 관측·게이팅·롤백 자동화가 전제되지 않으면 오히려 위험 신호를 늦게 잡는다. 2026 벤치마크에서 롤백 원인의 37%가 flag 지연, 타게팅 규칙 누락, 감사 로그 공백이었다.
• DB 마이그레이션은 앱 레벨 카나리와 같은 속도로 태우면 안 된다. expand(스키마 확장) → 카나리 라우팅 → 검증 → contract(정리) 순서가 권장된다.
• 파이프라인 앞단에서 캐싱(30–60% 절감)과 병렬화(20–40% 절감)를 먼저 해결해야 카나리 관측 주기를 짧게 돌릴 수 있다.

이 선택은 실무에서 보통 세 축으로 갈린다. 첫째, 트래픽을 얼마나 천천히 늘릴지(전환 속도 vs 안전성). 둘째, 상태를 가진 컴포넌트(DB)를 같은 속도로 카나리 태울 수 있는지. 셋째, 파이프라인 앞단 구성이 카나리 관측 주기에 얼마나 영향을 주는지. 아래에서 하나씩 뜯어본다.

트래픽을 얼마나 천천히 늘려야 안전한가?

블루그린은 두 개의 동일한 운영 환경을 유지하다가 트래픽을 한 번에 전환하는 방식이고, 카나리는 새 버전에 소량 트래픽부터 흘려보내 1%, 5%, 20%, 50%, 100% 순으로 확대하는 방식이라고 정리된다 NGINX. Azure AKS의 2026 문서도 카나리를 "안정 버전과 카나리 버전을 함께 두고 트래픽 일부를 먼저 보내 관측한 뒤 확장하거나 롤백하는 점진적 릴리스 제어"로 설명한다 Microsoft Learn.

직접 겪어보니 이 "느린 확대"가 장점이자 단점이었다. 결제 서버처럼 실패 비용이 큰 서비스는 1% → 5%로 넘어가는 데만 관측 지표를 30분씩 지켜본 적도 있다. 반면 내부 관리자 도구처럼 실패해도 되돌리기 쉬운 서비스는 굳이 5단계를 다 거칠 필요 없이 블루그린으로 한 번에 전환하고 문제 생기면 즉시 되돌리는 편이 총 소요 시간이 짧았다. 결국 이 선택은 "실패했을 때 되돌리는 비용"과 "실패를 미리 잡는 데 드는 시간" 사이의 트레이드오프였다.

DB 마이그레이션도 카나리처럼 점진적으로 태울 수 있나?

답은 "아니오, 다른 속도로 가야 한다"에 가깝다. 2026 Redgate 자료는 블루/그린 전환에서 스키마를 확장(expand)하고, 카나리 트래픽을 라우팅한 뒤, 검증이 끝나면 전체 전환하고, 마지막에 옛 스키마를 정리(contract)하는 순서를 권장한다 Redgate. 이 순서가 중요한 이유는 앱 레이어의 카나리 비율과 DB 스키마 상태가 항상 같은 타임라인으로 움직이지 않기 때문이다.

내가 겪은 실패 사례 하나를 적으면, 앱은 카나리 10%까지 올렸는데 DB 마이그레이션 스크립트가 이미 구 스키마 컬럼을 drop해버려서 나머지 90% 트래픽이 500 에러를 뱉은 적이 있다. 원인은 "카나리는 트래픽만 나누면 된다"는 잘못된 가정이었다. 실제로는 앱 배포 비율과 스키마 변경 단계를 분리해서 추적해야 하고, contract(구 스키마 정리)는 카나리가 100%로 완전히 확대되고 나서, 충분한 관측 기간이 지난 뒤에 해야 안전했다.

파이프라인 앞단 구성이 카나리 판단 속도에 영향을 주나?

영향이 크다. 카나리는 결국 "관측 → 판단 → 확대/롤백"의 반복인데, 이 사이클이 길어지면 카나리의 장점(빠른 조기 발견)이 사라진다. 2026 CI/CD 최적화 자료는 캐싱으로 평균 30–60%, 병렬 작업으로 20–40%의 파이프라인 시간 절감을 제시하고, 테스트를 유닛 70% · 통합 20% · E2E 10% 비중으로 배치하는 구성을 권장한다 [CI/CD 최적화 자료 참고]. 무거운 E2E를 앞단에 두면 카나리 배포 전 단계에서만 시간을 다 쓰고, 정작 카나리 관측 사이클을 돌릴 여력이 줄어든다.

DORA 지표(배포 빈도, 변경 리드타임, 변경 실패율, 복구 시간)도 이 맥락과 맞닿아 있다. 파이프라인이 느리면 배포 빈도가 낮아지고, 카나리로 소량씩 자주 내보내는 전략 자체가 성립하기 어려워진다. 실무에서는 정적 검사·유닛 테스트·빌드 캐시를 파이프라인 앞단에, 통합·E2E 같은 무거운 검증은 후단에 배치하는 편이 카나리 관측 주기를 짧게 유지하는 데 유리했다.

feature flag 벤치마크가 카나리 신뢰도에 뭘 말해주나?

카나리는 대개 feature flag나 트래픽 라우팅 규칙으로 구현되는데, 이 도구의 응답 지연이 카나리 품질에 직접 영향을 준다. AWS c7g.2xlarge, Kubernetes 1.32, k6 0.49, 초당 1만 flag 평가 조건에서 진행된 2026 벤치마크는 p99 평가 지연이 LaunchDarkly 2026.0.1에서 1.2ms, Unleash 6.0.2에서 0.4ms로 나타났다고 보고한다. 같은 조건에서 UI 토글 후 95% 노드 반영까지 걸린 시간은 LaunchDarkly 2.1초, Unleash 0.8초였다.

이 수치가 의미 있는 이유는 "카나리 10%를 설정했다"와 "실제로 10%가 노출됐다"가 항상 같지 않기 때문이다. 같은 벤치마크는 10% 카나리를 1만 테스트 사용자에 배포한 뒤 실제 노출 비율이 의도한 비율과 일치하는지 평가 로그로 확인했다고 적시한다. 재현 조건(버전, 인스턴스 타입, k8s 버전, 부하 도구, 동시성)이 모두 명시돼 있어, 우리 환경에서 재현 가능한지 판단하는 근거로 쓸 수 있다는 점이 이 자료의 실무 가치다. 단, 이 수치는 특정 인프라·부하 조건에서의 측정값이라 다른 환경에서 그대로 재현된다고 단정할 수는 없다.

카나리에서 가장 자주 놓치는 함정은 뭘까?

가장 흔한 오해는 "카나리는 트래픽을 조금씩 늘리는 것"이라는 이해에서 멈추는 것이다. 실제로는 관측·정책·감사 추적이 병목이 된다. 앞의 2026 벤치마크는 롤백 원인의 37%가 feature flag 지연, 타게팅 규칙 누락, 감사 로그 공백에서 비롯됐다고 보고한다. 즉 카나리가 실패하는 이유는 대부분 "트래픽이 느리게 새는 것"이 아니라 "무슨 일이 벌어졌는지 제때 못 본 것"이었다.

내가 겪은 사례에서도 카나리 5%에서 에러율이 이미 올라가고 있었는데, 대시보드가 카나리 버전과 안정 버전의 지표를 분리해서 보여주지 않아 20%까지 확대된 뒤에야 문제를 알아챈 적이 있다. 이후로는 카나리 롤아웃 전에 "버전별로 분리된 대시보드가 있는가", "타게팅 규칙 변경 이력이 감사 로그에 남는가"를 체크리스트에 넣었다. 카나리는 배포 전략이 아니라 관측 전략에 더 가깝다는 게 이 실패에서 얻은 결론이다.

그래서 실무에서는 뭘 기준으로 고르나?

정리하면 이렇다.

• 실패 시 영향 범위를 좁게 통제해야 하고, 대시보드·감사 로그·자동 롤백을 갖출 여력이 있다 → 카나리.
• 롤백 절차를 단순하게 유지하고 싶고, 인프라 두 벌을 유지할 예산이 있다 → 블루그린.
• DB 스키마 변경이 얽혀 있다 → 앱 카나리 비율과 별개로 expand/contract 순서를 반드시 분리해서 추적한다.
• 파이프라인 자체가 느리다 → 카나리를 도입하기 전에 캐싱·병렬화·테스트 배치부터 손보는 게 먼저다.

핵심 정리

• 카나리는 1%→100% 점진 확대, 블루그린은 100% 일괄 전환이라는 구조적 차이에서 선택이 갈린다.
• feature flag 도구의 p99 지연(1.2ms vs 0.4ms)과 전파 시간(2.1s vs 0.8s) 차이는 카나리 관측 신뢰도에 직접 영향을 준다(2026 벤치마크, 특정 인스턴스·k8s 버전 조건).
• 롤백 원인의 37%가 flag 지연·타게팅 규칙 누락·감사 로그 공백에서 나왔다는 점은, 카나리의 병목이 배포 자체보다 관측에 있다는 걸 보여준다.
• DB 마이그레이션은 앱 카나리와 다른 속도로, expand → 카나리 라우팅 → 검증 → contract 순서로 분리해야 한다.
• 파이프라인 캐싱(30–60%)·병렬화(20–40%) 절감을 먼저 확보해야 카나리 관측 사이클을 짧게 유지할 수 있다.