블루-그린 vs 카나리 배포: API와 DB 변경을 더 안전하게

스키마 변경과 느린 모바일 업데이트가 배포를 위험하게 만드는 이유

테스트에서는 완벽해 보이던 배포가 실제 트래픽에서 실패하는 경우가 있습니다. 보통 이유는 코드만 바뀌는 게 아니라 API 계약과 데이터베이스 스키마도 바뀌고, 이들이 같은 속도로 바뀌지 않기 때문입니다.

시스템의 서로 다른 부분이 "정상"을 다르게 이해하면 문제가 생깁니다. 새 백엔드는 아직 없는 컬럼을 기대할 수 있고, 오래된 백엔드는 새 코드가 이해하지 못하는 형식으로 데이터를 쓸 수 있습니다. 필드 이름 변경, 검증 강화, enum 값 변경 같은 작은 변화도 운영 오류를 일으킬 수 있습니다.

모바일 앱은 상황을 더 어렵게 만듭니다. 어떤 사용자는 몇 분 안에 업데이트하고 어떤 사용자는 몇 주가 걸리기도 합니다. 즉, 백엔드는 여러 세대의 클라이언트를 동시에 서비스해야 합니다. 최신 앱에서만 동작하는 API를 배포하면 일부 사용자의 결제, 온보딩, 백그라운드 동기화가 깨질 수 있고 바로 눈에 띄지 않을 수 있습니다.

"다운타임 위험"은 단순히 사이트가 내려가는 것만을 뜻하지 않습니다. 실제 시스템에서는 부분적인 실패로 나타나는 경우가 많습니다:

• 특정 엔드포인트에서 4xx/5xx 에러가 급증하지만 다른 곳은 정상인 경우
• 토큰, 역할, 사용자 레코드 불일치로 인한 로그인 실패
• 잘못된 기본값, 잘린 텍스트, 누락된 관계 같은 잠복한 데이터 문제가 며칠 뒤에 드러남
• 백그라운드 작업이 막혀서 시간이 걸리는 큐가 쌓임

이 때문에 팀들은 블루-그린 vs 카나리 배포를 비교합니다: 변경이 완전히 호환되지 않을 때 폭발 범위를 줄이려는 겁니다.

블루-그린과 카나리를 쉽게 설명하면

사람들이 블루-그린 vs 카나리 배포를 비교할 때 보통 하나의 질문에 답합니다: 큰 통제된 전환을 할 것인가, 아니면 작고 신중한 실험을 할 것인가?

블루-그린: 두 개의 완전한 버전과 트래픽 스위치

블루-그린은 두 개의 완전한 환경을 동시에 운영하는 방식입니다. "Blue"는 현재 사용자에게 서비스를 제공하는 버전이고, "Green"은 새 버전으로 병행해서 배포하고 테스트합니다. 준비가 되면 트래픽을 블루에서 그린으로 전환합니다.

이 방식은 예측 가능성이 높다는 장점이 있습니다. 프로덕션과 유사한 설정에서 새 버전을 검증한 뒤 한 번에 깔끔하게 전환할 수 있습니다.

롤백도 직관적입니다: 전환 후 문제가 생기면 트래픽을 다시 블루로 돌리면 됩니다. 즉시 되돌릴 수 있는 것처럼 보이지만, 캐시, 백그라운드 작업, 데이터 변경 때문에 회복이 복잡해질 수 있습니다.

카나리: 소수의 트래픽에 먼저 노출

카나리는 새 버전을 처음에 소수의 사용자나 요청에만 노출한 뒤 상태가 괜찮으면 비율을 단계적으로 늘리는 방식입니다.

카나리는 실제 트래픽에서의 미지의 동작이 걱정될 때 유용합니다. 대부분의 사용자가 느끼기 전에 문제를 조기에 발견할 수 있습니다.

롤백은 카나리 비율을 0으로 줄이거나 새 버전으로 라우팅을 중단하는 방식입니다. 보통 빠르지만 항상 깔끔하지는 않습니다. 일부 사용자가 이미 데이터나 상태를 생성했을 수 있어 두 버전이 그 상태를 처리해야 하기 때문입니다.

간단한 비교 요약:

• 블루-그린은 깔끔한 컷오버와 빠른 스위치백을 선호합니다.
• 카나리는 제한된 폭발 범위에서 실 트래픽으로 배우는 것을 선호합니다.
• 둘 다 데이터베이스 리스크를 자동으로 해결하지는 않습니다. 스키마 변경이 호환되지 않으면 둘 다 실패할 수 있습니다.
• 카나리는 라이브 신호를 기반으로 결정하므로 모니터링에 의존합니다.
• 블루-그린은 두 개의 전체 스택을 운영하므로 추가 용량이 필요할 수 있습니다.

예: API가 때때로 새 필드를 반환하도록 릴리스한다면 카나리는 오래된 클라이언트가 예기치 않은 데이터로 충돌하는지 볼 수 있게 해줍니다. 만약 변경이 오래된 코드가 다룰 수 없는 컬럼 이름 변경을 필요로 한다면, 스키마 변경이 양쪽 버전을 지원하도록 설계되지 않는 한 블루-그린도 도움이 되지 않습니다.

데이터베이스 마이그레이션이 코드 배포와 다른 점

코드 배포는 보통 롤백하기 쉽습니다. 새 버전이 문제를 일으키면 이전 빌드를 다시 배포하면 대부분 원래 상태로 돌아옵니다.

데이터베이스 변경은 데이터의 형태를 바꾸기 때문에 다릅니다. 한 번 행이 재작성되거나 컬럼이 삭제되거나 제약이 강화되면 되돌리기가 거의 즉시 불가능합니다. 코드만 롤백해도 새 스키마를 이해하지 못할 수 있습니다.

그래서 스키마 마이그레이션의 다운타임 위험은 배포 방식 자체보다는 마이그레이션을 어떻게 설계했느냐에 달려 있는 경우가 많습니다.

온라인 마이그레이션 기본 원칙

가장 안전한 마이그레이션은 구버전과 신버전이 동시에 실행되는 동안 작동하도록 만들어집니다. 패턴은 단순합니다: 무시해도 안전한 변경을 먼저 하고, 코드를 업데이트해 그것을 사용한 뒤 나중에 정리합니다.

일반적인 확장-후-수축(expand-then-contract) 순서는 다음과 같습니다:

• 먼저 추가적 변경을 적용: nullable 컬럼 추가, 새 테이블 추가, 쓰기를 잠그지 않는 방식의 인덱스 추가
• 이중 동작: 구/신 둘 다에 쓰거나, 새에서 읽되 없으면 구로 폴백
• 백필은 별도로: 기존 데이터를 작은 배치로 옮김
• 스위치오버: 대부분의 트래픽을 새 동작으로 전환
• 파괴적 변경은 마지막에: 오래된 컬럼 삭제, 오래된 코드 경로 제거, 제약 강화

"빅뱅" 마이그레이션은 가장 위험한 단계들을 한 릴리스에 모아 수행합니다: 긴 락, 무거운 백필, 새 스키마가 전역에 존재한다고 가정하는 코드 등입니다.

느린 모바일 업데이트가 기준을 높이는 이유

모바일 클라이언트는 수주간 구버전에 머물 수 있습니다. 백엔드는 데이터베이스를 진화시키는 동안 옛 요청을 계속 받아야 하고 옛 응답을 계속 제공해야 합니다.

오래된 앱이 새 필드를 보내지 않는 상황에서 서버가 갑자기 그 필드를 DB에서 required로 만들 수는 없습니다. 일정 기간 동안 양쪽 동작이 모두 작동해야 합니다.

스키마 마이그레이션에서 다운타임 위험을 줄이는 전략은?

가장 안전한 선택은 배포 도구 자체보다 한 가지 질문에 달려 있습니다: 구버전과 신버전 애플리케이션이 한동안 동일한 데이터베이스 스키마에서 올바르게 동작할 수 있나?

만약 답이 예라면 블루-그린이 종종 가장 낮은 다운타임 옵션입니다. 먼저 데이터베이스 변경을 준비하고 트래픽은 기존 스택에 두다가, 새 스택으로 한 번에 전환하면 됩니다. 문제가 보이면 빠르게 되돌릴 수 있습니다.

하지만 새 앱이 즉시 새 스키마를 필요로 하면 블루-그린도 실패합니다. 흔한 예로 오래된 버전이 계속 읽는 컬럼을 삭제하거나 이름을 바꾸거나, 앱이 값을 쓰기 전에 NOT NULL 제약을 추가하는 경우입니다. 이런 경우에는 롤백이 안전하지 않을 수 있습니다.

카나리는 실제 트래픽에서의 학습이 필요할 때 더 낫습니다. 소수의 실사용자가 먼저 새 버전을 사용하면 인덱스 누락, 예상치 못한 쿼리 패턴, 백그라운드 작업의 다른 동작 같은 엣지 케이스를 포착할 수 있습니다. 단점은 두 버전이 동시에 동작하도록 유지해야 하기 때문에 보통 하위 호환적인 데이터베이스 변경이 필요합니다.

실용적인 결정 규칙

블루-그린 vs 카나리를 스키마 마이그레이션의 다운타임 위험 관점에서 고민할 때:

• 스키마 변경을 추가적(additive)이고 호환되게 유지할 수 있고 빠른 컷오버가 목표라면 블루-그린을 선택하세요.
• 변경이 프로덕션에서 어떻게 동작할지 확신이 없거나 희귀한 데이터 형태가 문제될 것으로 예상되면 카나리를 선택하세요.
• 마이그레이션이 즉시 깨지는 변경을 강요한다면 블루-그린과 카나리 중 하나를 고르지 마세요. 대신 플랜을 바꿔 확장-후-수축 방식으로 진행하세요.

현실에서 "호환"이란 무엇인가

예를 들어 orders 테이블에 새 필드를 추가한다고 합시다. 안전한 경로는: 컬럼을 nullable로 추가하고, 해당 컬럼을 쓰는 앱을 배포하고, 기존 행을 백필한 뒤 제약을 강화하는 것입니다. 이런 셋업에서는 블루-그린이 깔끔한 컷오버를 제공하고, 카나리는 일부 경로가 여전히 옛 형태를 가정하는지 초기 경고를 줍니다.

느린 모바일 업데이트가 배포 선택에 미치는 영향

웹 사용자는 새로고침을 합니다. 모바일 사용자는 그렇지 않습니다.

iOS와 Android에서는 사람들이 구버전에 수주 또는 수개월간 머무릅니다. 어떤 기기는 오프라인 상태가 길기도 합니다. 따라서 "구" 클라이언트는 백엔드의 하위 호환성을 영구적으로 시험하는 존재가 됩니다.

이로 인해 목표가 "다운타임 없이 배포"에서 "여러 클라이언트 세대를 동시에 작동시키기"로 바뀝니다. 실무에서는 모바일 때문에 인프라에 블루-그린을 쓰더라도 API 설계는 카나리 같은 사고방식을 요구하는 경우가 많습니다.

하위 호환 변경 vs API 버전 관리

대부분의 경우 하위 호환 변경이 바람직합니다. 이렇게 하면 오래된 앱과 새 앱이 같은 엔드포인트를 공유할 수 있습니다.

하위 호환 예시: 새 필드 추가, 옛/새 페이로드 형태 둘 다 수용, 기존 응답 필드 유지, 의미 변경 회피.

동작을 변경해야 하거나 필드를 제거하거나 이름을 바꿔야 할 때는 모바일 앱에 대해 API 버전 관리가 유용합니다.

예: marketing_opt_in 같은 선택적 필드 추가는 보통 안전합니다. price 계산 방식을 바꾸는 것은 보통 안전하지 않습니다.

사용 중단(deprecation) 기간 계획

필요한 파괴적 변경이 있다면 지원 종료는 제품 측의 결정으로 다루세요. 유효한 사용 중단 기간은 달력 기준이 아니라 "구버전을 여전히 사용하는 활성 사용자 비율"로 측정해야 합니다.

실용적 순서:

• 구·신 클라이언트를 모두 지원하는 백엔드를 먼저 배포
• 새 모바일 앱을 배포하고 버전별 채택률을 추적
• 구버전 사용자가 안전 기준 이하로 떨어질 때 경고 또는 제한 적용
• 구 동작 제거는 마지막에, 롤백 계획을 준비해 두기

단계별: API + DB 변경을 위한 안전한 롤아웃 패턴

API와 데이터베이스를 동시에 변경할 때 안전한 계획은 보통 2~3단계 롤아웃입니다. 각 단계는 독립적으로 배포해도 안전해야 하며, 사용자가 구 모바일 앱을 몇 주 동안 유지하더라도 문제 없어야 합니다.

구 클라이언트를 깨지 않는 롤아웃 패턴

먼저 추가적 DB 변경부터 시작하세요. 새 컬럼이나 테이블을 추가하고 이름 변경이나 삭제는 피하며, 필요한 경우 NULL을 허용하고 기본값을 사용해 오래된 코드가 제약에 걸리지 않도록 합니다.

그다음 코드가 양쪽 데이터 형태를 견디도록 배포합니다. 읽기는 "옛 필드 없음"과 "새 필드 존재"를 모두 허용해야 하고, 쓰기는 당분간 옛 필드에 계속 쓰되 선택적으로 새 필드에도 씁니다.

일반적인 순서:

• 새 스키마(컬럼, 테이블, 인덱스)를 추가하되 기존 것을 제거하지 않음
• 옛 혹은 새에서 읽고 널에 대해 충돌하지 않는 코드를 배포
• 기존 행을 소규모 배치로 백필하고 개수, 널 비율, 쿼리 성능을 검증
• 쓰기 경로를 새 필드로 전환하되 폴백 읽기는 유지
• 오래된 모바일 버전이 사라진 뒤에만 옛 필드를 제거하고 정리

백필과 검증: 장애가 숨어있는 곳

백필은 빠른 스크립트처럼 다루면 실패합니다. 점진적으로 실행하고 부하를 관찰하며 결과를 검증하세요. 새 동작이 인덱스를 필요로 하면 읽기/쓰기 전환 전에 인덱스를 추가하세요.

예: phone_country_code를 추가해 포맷을 개선한다고 합시다. 먼저 컬럼을 nullable로 추가하고, API는 받아들이되 없을 때도 동작하게 합니다. 기존 전화번호에서 백필로 값을 채운 뒤 신규 가입에 대해 쓰기 시작합니다. 몇 주 후 구 앱들이 대부분 사라지면 레거시 파싱 경로를 제거합니다.

복잡하지 않게 양쪽 전략을 더 안전하게 만드는 도구들

복잡한 환경이 없어도 블루-그린과 카나리 배포를 더 안전하게 만드는 습관이 몇 가지 있습니다.

이중 읽기/이중 쓰기(일시적으로 유지)

이중 쓰기는 전환 기간 동안 앱이 옛 장소와 새 장소 모두에 데이터를 쓰는 것을 의미합니다(예: users.full_name과 새 users.display_name). 이중 읽기는 보통 새 필드를 우선 읽고, 없으면 옛 필드로 폴백합니다.

이 방식은 느린 클라이언트 업데이트에 시간을 벌어주지만 단기간의 다리로 유지해야 합니다. 제거 시점을 정하고 어느 경로가 사용되는지 추적하며 두 쓰기가 일관된지 기본 검사하세요.

행동 변경을 위한 피처 플래그

피처 플래그는 위험한 동작을 켜지 않은 채 코드를 배포하게 해 줍니다. 배포와 활성화를 분리할 수 있어 작동 전환을 안전하게 관리할 수 있습니다.

예: 새 응답 필드 지원 코드를 배포하되 서버가 기존 형태를 반환하도록 유지하다가, 소수의 사용자부터 활성화해 지표를 관찰하고 점차 확대하세요. 문제가 생기면 플래그를 끄면 됩니다.

계약(contract) 테스트 마인드셋 (API는 약속이다)

많은 마이그레이션 사고는 사실 데이터베이스 문제가 아니라 클라이언트 기대의 문제입니다.

API를 약속으로 다루세요. 필드를 제거하거나 의미를 바꾸지 마세요. 알려지지 않은 필드는 선택적으로 처리하세요. 추가적 변경(새 필드, 새 엔드포인트)이 보통 안전하고 파괴적 변경은 새 API 버전을 기다리세요.

신뢰할 수 있는 데이터 마이그레이션 잡

스키마 마이그레이션에는 데이터를 복사하고 값을 계산하거나 정리하는 백필 작업이 필요합니다. 이 작업은 재실행해도 안전하고 재시도 가능하며 추적이 쉽고 부하를 급증시키지 않도록 제한되어야 합니다.

마이그레이션 중 장애를 일으키는 흔한 실수

대부분의 마이그레이션 장애는 릴리스가 모든 것이 한꺼번에 이동할 것을 전제로 할 때 발생합니다: 모든 서비스가 동시에 배포되고, 모든 데이터가 깨끗하며, 모든 클라이언트가 제때 업데이트될 것이라는 가정입니다. 특히 모바일 환경에서는 현실이 그렇지 않습니다.

흔한 실패 패턴:

• 컬럼을 너무 일찍 삭제하거나 이름을 바꿈. 구 API 코드, 백그라운드 잡, 옛 모바일 앱이 여전히 사용 중일 수 있음
• 클라이언트가 빨리 업데이트할 것이라고 가정함. 모바일 릴리스는 도달하는 데 시간이 걸림
• 피크 시간에 큰 테이블을 잠그는 마이그레이션 실행. 작은 인덱스나 컬럼 변경도 쓰기를 막을 수 있음
• 깨끗한 샘플 데이터만 테스트함. 운영 데이터에는 널, 이상한 포맷, 중복, 레거시 값이 있음
• 코드와 데이터에 대한 실질적 롤백 계획이 없음. "우리는 이전 버전을 재배포하면 된다"는 스키마가 바뀐 경우 충분치 않음

예: status를 order_status로 이름 바꾸고 새 API를 배포하면 웹은 동작할 수 있습니다. 하지만 오래된 모바일 클라이언트는 여전히 status를 보내고 API가 이를 거부하면 결제 실패가 발생할 수 있습니다. 컬럼을 삭제했다면 동작 복구가 빠르지 않습니다.

더 나은 기본값은: 작은 가역적 단계로 변경하고, 옛/신 경로를 함께 유지하며, 지표가 급증하면 무엇을 할지(어떻게 트래픽을 되돌릴지, 어떤 피처 플래그가 새 동작을 끄는지, 백필이 망했을 때 데이터를 어떻게 검증하고 복구할지)를 문서화해 두는 것입니다.

배포 직전 빠른 체크리스트

릴리스 직전에 짧은 체크리스트는 야간 롤백을 부르는 문제들을 잡아냅니다. 특히 API와 데이터베이스를 동시에 변경할 때, 느린 모바일 업데이트가 있을 때 중요합니다.

대부분의 장애를 막는 다섯 가지 확인 사항

• 호환성: 옛 버전과 새 버전이 같은 데이터베이스 스키마에서 모두 동작하는지 확인하세요. 실용적 테스트는 현재 프로덕션 빌드를 새로운 마이그레이션이 적용된 스테이징 DB에서 실행해 보는 것입니다.
• 마이그레이션 순서: 첫 마이그레이션은 추가적이어야 하고, 파괴적 변경(컬럼 삭제, 제약 강화)은 나중으로 예약하세요.
• 롤백: 가장 빠른 되돌리기 방법을 정의하세요. 블루-그린은 트래픽을 되돌리는 것이고, 카나리는 트래픽을 안정 버전으로 100% 돌리는 것입니다. 롤백에 또 다른 마이그레이션이 필요하면 간단하지 않습니다.
• 성능: 정확성만이 아니라 스키마 변경 후 쿼리 지연 시간을 측정하세요. 인덱스 누락은 한 엔드포인트를 사실상 장애처럼 느끼게 할 수 있습니다.
• 클라이언트 현실: 아직 API를 호출하는 가장 오래된 모바일 앱 버전을 파악하세요. 의미 있는 비율이 남아있다면 더 긴 호환성 창을 계획하세요.

빠른 실전 시나리오

preferred_language 같은 새 필드를 추가한다면 먼저 DB 변경을 nullable로 적용하세요. 그런 다음 서버 코드를 배포해 필드가 있어도 되고 없어도 동작하도록 하세요. 대부분의 트래픽이 업데이트된 앱으로 넘어간 뒤에 필수를 적용하거나 옛 동작을 제거하세요.

예: 오래된 모바일 앱을 깨지 않고 새 필드를 추가하기

프로필 필드 country를 추가하고 비즈니스에서 이를 필수로 만들고 싶어 한다고 합시다. 문제는 두 곳에서 발생할 수 있습니다: 오래된 클라이언트가 필드를 보내지 않거나 DB가 NOT NULL로 쓰기를 거부할 수 있습니다.

더 안전한 접근은 두 단계로 나누는 것입니다: 먼저 하위 호환 방식으로 필드를 추가하고, 클라이언트가 따라온 뒤 나중에 필수로 만듭니다.

블루-그린으로 할 때 모습

블루-그린에서는 새 버전을 옛 버전과 함께 배포합니다. 그래도 DB 변경은 양쪽 버전을 지원해야 합니다.

안전한 흐름:

• 마이그레이션 배포(country를 nullable로 추가)
• country가 없을 때 폴백하는 그린 버전 배포
• 그린에서 주요 흐름(회원가입, 프로필 수정, 결제) 테스트
• 트래픽 스위치

문제가 생기면 다시 스위치하면 됩니다. 단, 되돌리기가 가능한 것은 스키마가 여전히 옛 버전을 지원할 때뿐입니다.

카나리로 할 때 모습

카나리에서는 새 API 동작을 소수(보통 1%~5%)에 먼저 노출하고, 누락된 필드에 대한 검증 오류, 지연 변화, 예상치 못한 DB 실패를 관찰합니다.

흔한 놀라움은 오래된 모바일 클라이언트가 country 없이 프로필 업데이트를 보내는 것입니다. API가 즉시 이를 필수로 처리하면 400 오류가 보일 것이고, 데이터베이스가 NOT NULL을 강제하면 500 오류가 발생할 수 있습니다.

안전한 순서:

• country를 nullable로 추가(선택적으로 "unknown" 같은 안전한 기본값 사용)
• 오래된 클라이언트의 누락을 수용
• 백그라운드 잡으로 기존 사용자에 대해 country 백필
• 나중에(먼저 API에서, 그다음 DB에서) 필수화

릴리스 후에는 옛 클라이언트가 보낼 수 있는 것과 서버가 보장하는 것을 문서화하세요. 그 계약이 다음 마이그레이션에서 같은 문제를 반복하지 않게 합니다.

만약 AppMaster (appmaster.io)로 개발 중이라면 동일한 롤아웃 규율이 적용됩니다. 하나의 모델에서 백엔드, 웹, 네이티브 모바일 앱을 생성할 수 있더라도, 우선 추가적 스키마 변경과 관용적인 API 로직을 배포하고 채택률이 올라간 뒤에 제약을 강화하세요.