점진 배포와 카나리 배포: 어떤 신호를 보고 범위를 넓힐 것인가

30초 요약

점진 배포는 새 변경을 한 번에 모두에게 열지 않고 대상 범위를 단계적으로 넓히는 방법이다. 카나리 배포는 새 변경을 받은 후보 집단을 제한된 시간 동안 운영하고, 기존 버전을 유지한 비교 대상인 기준 집단과 같은 시간에 비교해 계속 넓힐지 판단하는 평가 과정이다.

반복해서 기억할 문장은 이것이다.

작게 열고, 같이 비교하고, 기준을 통과할 때만 넓힌다.

후보·기준 집단 정의 → 작은 노출 → 최소 사건 수·관찰 시간 충족
→ 집단별 신호와 절대 기준 평가 → 확대·대기·중단 결정

여기서 사건 수는 후보에서 실제 관찰한 앱 시작, 서버 요청이나 핵심 흐름 실행 횟수다. 신호에 따라 세션·요청·완료 횟수처럼 세는 단위가 달라지므로 판정 계약에 단위도 함께 적는다.

퍼센트 하나는 안전장치의 시작일 뿐이다. 작은 집단이 실제 사용을 대표하는지, 새 업데이트를 정말 실행했는지, 어떤 오류·속도·핵심 동작 기준을 통과해야 하는지를 배포 전에 정해야 한다.

점진 배포는 노출 방법이고 카나리는 평가 과정이다

점진 배포
  질문: 노출 범위를 어떻게 조금씩 넓힐까?
 
카나리 평가
  질문: 이 작은 실제 운영 결과가 확대해도 된다는 근거인가?

따라서 5% → 25% → 100% 버튼만 누르는 것은 점진 배포일 수 있지만, 각 단계에 관찰과 판단이 없다면 카나리 평가라고 부르기 부족하다. 반대로 후보·기준 집단을 비교해 중단 결정을 내리더라도 노출을 한 번에 100%로 바꾸면 피해 범위를 제한하는 장점이 줄어든다.

카나리는 운영 트래픽에서만 드러나는 결함을 작은 영향으로 찾는 보완책이다. 작은 코드 단위를 보는 단위 테스트, 기능 간 연결을 보는 통합 테스트, 전체 사용자 흐름을 보는 종단간(E2E) 테스트와 사전 운영 환경 검증을 건너뛰는 지름길이 아니다.

후보 집단과 기준 집단을 함께 둔다

후보 집단(canary): 새 업데이트 C를 실행
기준 집단(control): 기존 업데이트 B를 실행

두 집단은 가능한 한 같은 시간대와 비슷한 조건에서 관찰한다. 후보가 iOS 최신 기기에만 있고 기준은 Android 저사양 기기에만 있다면 차이가 코드 때문인지 기기 때문인지 구분하기 어렵다.

비교 전에 다음 분포를 확인한다.

• 플랫폼과 운영체제 버전
• 네이티브 빌드·런타임 버전
• 기기 성능과 네트워크 조건
• 지역·언어와 사용 시간대
• 신규·기존 사용자, 로그인 상태와 주요 사용 흐름

모든 특성을 완벽히 같게 만들 수는 없다. 중요한 것은 결과에 영향을 줄 큰 차이를 알고, 집단별 자료에 업데이트 ID와 비교에 필요한 조건을 함께 기록하는 것이다.

비율보다 대표할 사건 수와 관찰 시간을 정한다

“항상 1%”, “항상 10분” 같은 숫자는 근본 규칙이 아니다.

100명 중 1%   = 1명
1,000,000명 중 1% = 10,000명

같은 비율도 관찰할 사건 수가 전혀 다르다. 시작 충돌처럼 자주 즉시 발생하는 실패는 작은 집단에서 빨리 보일 수 있다. 일주일에 한 번 쓰는 기능, 특정 시간대의 부하나 드문 기기 오류는 더 긴 시간이나 더 넓은 집단이 필요하다.

영향 반경은 결함이 있을 때 영향을 받을 수 있는 사용자·요청·자료의 범위다. 단순한 학습 모델은 다음과 같다.

예상 피해 사건 수 ≈ 노출 대상 수 × 대상당 단위 시간 사용 횟수
                   × 발견까지 걸린 시간 × 결함을 만날 비율

결과 단위를 실패한 요청·세션 같은 사건 수로 맞춘 단순 모델이다. 각 대상의 사용이 비슷하다고 가정하므로 정확한 예측식은 아니며, 자료 손상처럼 사건 한 건의 피해 크기가 다른 문제는 별도 절대 중단 기준이 필요하다. 노출을 너무 작게 하면 대표성이 사라지고, 너무 크게 하거나 오래 두면 결함의 영향이 커진다.

같은 시간의 기준 집단과 비교한다

나쁜 비교: 후보의 오늘 10시 vs 전체의 어제 10시
더 나은 비교: 후보의 오늘 10시 vs 기준 집단의 오늘 10시

동시 비교도 완벽하지 않다. 후보와 기준이 같은 서버 기능·데이터베이스를 쓰면 후보의 과도한 요청이 기준 집단까지 느리게 만들 수 있다. 그래서 다음 두 질문을 함께 묻는다.

1. 후보가 기준보다 나빠졌는가?
2. 전체 서비스가 허용 가능한 절대 기준 안에 있는가?

첫 질문은 변경과 결과를 연결하고, 둘째 질문은 두 집단이 함께 망가지는 상황을 잡는다.

전체 평균은 작은 카나리의 실패를 숨길 수 있다

후보: 전체의 5%, 후보 안 오류율 20%
기준: 전체의 95%, 오류율 0%
 
전체 오류율 = 5% × 20% = 1%

업데이트 ID, 네이티브 빌드와 런타임 버전으로 최소한 후보와 기준을 나눈다. 13편에서 본 것처럼 사용자 ID를 메트릭 레이블로 넣어 무제한 분류를 만들지는 않는다. 제한된 배포 집단 ID를 사용하고 개별 재현 정보는 오류·트레이스에 둔다.

신호는 사용자 피해와 변경에 가까워야 한다

초기 작은 단계에서는 명확하고 빠른 실패부터 본다.

• 앱 시작 실패와 충돌 없는 세션 비율
• 핵심 서버 요청 실패와 인증 실패
• 첫 화면·핵심 화면 표시 시간
• 결제·저장·전송 같은 핵심 흐름 완료율

집단을 넓히면 더 많은 사건이 필요한 신호도 본다.

• 긴 세션의 메모리 증가와 앱 응답 멈춤
• 배터리·네트워크 사용량
• 드문 기기·운영체제 조합의 오류
• 업무 결과의 정확성과 취소·재시도 증가

연산을 처리하는 중앙 처리 장치(CPU)나 메모리 숫자가 변했다는 사실만으로 무조건 중단하지 않는다. 사용자 체감 문제와 연결되는지, 후보 변경에 원인을 돌릴 수 있는지 본다. 신호를 너무 많이 두면 우연한 흔들림으로 정상 배포를 자주 막고, 팀이 경보를 무시하게 될 수 있다. 소수의 강한 안전 신호부터 시작한다.

배포 전에 확대·대기·중단 기준을 쓴다

한 단계의 계약을 다음처럼 적을 수 있다.

대상: 호환 기기의 작은 후보 집단
최소 자료: 핵심 흐름 N건 + 최소 관찰 시간 T
 
즉시 중단:
  - 시작 실패가 절대 안전 기준을 넘음
  - 자료 손상·보안·결제 정확성 문제 1건이라도 확인
 
확대:
  - 최소 자료 충족
  - 후보가 기준보다 합의한 허용 차이 이상 나쁘지 않음
  - 전체 서비스 절대 기준도 정상
 
대기:
  - 표본 부족, 자료 누락, 결과가 모호함

N, T, 허용 차이는 서비스의 사건 빈도와 피해 비용으로 정한다. 예시 숫자를 모든 앱의 모범 답안으로 복사하지 않는다. 자료가 없는 상태를 성공으로 처리하지 않고 대기라는 별도 상태로 둔다.

설정한 노출 비율과 실제 채택 비율은 다르다

이것은 현재 Expo 제품의 노출 제어 방식이지 카나리 평가의 보편 구조가 아니다. 한 업데이트만 점진적으로 열 것인지, 수정 업데이트가 이어지는 별도 흐름 전체를 점진적으로 열 것인지에 따라 선택 단위가 다르다.

서버 목표 노출: 10%
실제 실행 채택: 앱 시작·다운로드·다음 시작에 따라 시간차 발생

따라서 확대 판단은 설정값이 아니라 실제 updateId별 실행 기기·세션과 신호를 사용한다. 후보 집단의 다운로드가 거의 안 됐는데 오류가 없다는 이유로 안전하다고 판단하지 않는다.

Web, React, React Native의 연결점

Web 서버는 요청이나 사용자 단위로 후보 산출물에 트래픽을 나눌 수 있다. 브라우저 캐시와 열린 탭 때문에 설정한 서버 비율과 실제 JavaScript 실행 비율은 다를 수 있으므로 실행 산출물 ID를 남긴다.

React의 기능 플래그는 같은 JavaScript 산출물 안에서 화면 동작을 일부 사용자에게 켤 수 있다. 배포 카나리는 새 산출물의 운영 안전성을 보는 과정이고, 제품 실험은 사용자 행동 가설을 평가하는 과정이다. 같은 집단 분할 도구를 써도 성공 질문과 신호가 다르다.

React Native OTA는 기기가 업데이트를 확인하고 다시 시작해야 후보가 실제 실행될 수 있다. 플랫폼, 네이티브 빌드·런타임과 업데이트 ID를 함께 기록하고, 오래 실행하는 세션과 드문 기기 조합이 관찰 창에 들어왔는지 확인한다.

자주 실패하는 설계

퍼센트만 정하고 판단 기준을 쓰지 않는다

“문제 없어 보이면 확대”는 관찰자마다 뜻이 다르다. 최소 자료, 비교 신호와 확대·대기·중단 기준을 배포 전에 적는다.

가능한 가장 작은 집단을 가장 짧게 본다

피해는 줄지만 실제 기능을 거의 사용하지 않아 거짓 안전 신호를 얻을 수 있다. 대표할 사건 수와 시간대를 먼저 계산한다.

전체 대시보드만 본다

작은 후보의 큰 실패가 전체 평균에 희석된다. 후보·기준 집단으로 신호를 나누고 절대 기준도 함께 본다.

어제와 오늘만 비교한다

시간대, 마케팅·외부 장애와 사용량 변화가 섞인다. 같은 시간의 기준 집단을 유지한다.

관측 자료가 없는데 오류가 없다고 판단한다

업데이트 채택이나 이벤트 전송이 실패했을 수 있다. 자료 완전성과 최소 사건 수를 배포 단계 판정의 선행 조건으로 둔다.

여러 카나리를 겹쳐 같은 신호를 본다

어느 변경이 결과를 만들었는지 흐려진다. 공유 집단과 신호를 쓰는 변경은 한 번에 하나씩 평가하거나 서로 분리된 귀속 경계를 만든다.

카나리 단계를 설계하는 순서

1. 후보 산출물과 현재 기준 산출물의 불변 ID를 고정한다.
2. 후보·기준 집단이 비교 가능한 조건인지 확인한다.
3. 첫 노출 크기와 최대 영향 반경을 정한다.
4. 최소 사건 수·관찰 시간과 자료 완전성 조건을 정한다.
5. 후보·기준 비교 신호와 전체 서비스 절대 기준을 고른다.
6. 확대·대기·중단 조건과 담당 행동을 배포 전에 기록한다.
7. 실제 채택과 집단별 신호가 조건을 통과할 때만 다음 단계로 넓힌다.

18편에서는 중단 뒤 “더 넓히지 않기”, 이전 산출물 재승격, 이미 새 코드를 실행한 클라이언트 복구가 왜 서로 다른지 다룬다. 이 글은 그 결정을 내릴 증거와 노출 제한에 집중한다.

한 문장으로 다시 설명하기

점진 배포는 새 변경의 노출 범위를 단계적으로 넓히는 방법이고, 카나리 배포는 제한된 후보를 같은 시간의 기준 집단과 평가해 확대 여부를 결정하는 과정이다. 가능한 가장 작은 퍼센트가 아니라 실제 사용을 대표할 사건 수와 시간을 정하고, 업데이트 ID별 신호와 절대 안전 기준을 배포 전에 정의한다. 설정한 비율이 아니라 실제 실행 채택이 기준을 통과할 때만 범위를 넓힌다.

스스로 확인하기

1. 점진 배포와 카나리 평가는 어떤 질문에 각각 답하는가?
2. 항상 가장 작은 비율과 가장 짧은 관찰 시간이 안전하지 않은 이유는 무엇인가?
3. 후보를 배포 전후가 아니라 같은 시간의 기준 집단과 비교해야 하는 이유는 무엇인가?
4. 작은 카나리의 큰 오류가 전체 평균에서 어떻게 숨겨질 수 있는가?
5. 카나리 신호가 사용자 피해와 변경 원인에 가까워야 하는 이유는 무엇인가?
6. 확대·대기·중단을 정하는 배포 단계 판정에는 어떤 최소 자료와 판단 기준이 필요한가?
7. EAS rollout percentage와 실제 업데이트 채택 비율이 다른 이유는 무엇인가?
8. 배포 카나리와 React 기능 플래그 기반 제품 실험은 무엇을 다르게 평가하는가?