카나리·블루그린 배포 전략 가이드: 작은 팀이 롤링 업데이트까지 비교해 선택하는 기준 > 인사이트

본문 바로가기

인사이트

#클라우드·DevOps

카나리·블루그린 배포 전략 가이드: 작은 팀이 롤링 업데이트까지 비교해 선택하는 기준

결론부터 말하면, 작은 개발·운영팀의 기본값은 ‘롤링 업데이트에 안전장치를 붙이는 것’입니다. 다만 결제, 예약, B2B 업무 처리처럼 장애 비용이 큰 기능을 자주 배포한다면 카나리 또는 블루그린을 검토해야 합니다. 트래픽이 충분하고 버전별 지표를 볼 수 있으면 카나리·선형 배포가 유리하고, 트래픽은 적지만 전환 전 검증과 빠른 복귀가 중요하면 블루그린이 더 단순합니다. 어느 쪽이든 DB 변경이 호환되지 않으면 무중단 배포 전략은 효과가 크게 줄어듭니다.

카나리 블루그린 롤링 배포 전략을 비교하는 DevOps 대시보드
작은 팀의 배포 전략 선택은 무중단이라는 구호보다 비용, 계측, 롤백 가능성을 함께 보는 문제입니다.

‘카나리 블루그린 배포 전략’이라는 검색어로 들어오는 팀의 고민은 대개 같습니다. 배포 때마다 손으로 서버에 접속하고, 새 버전이 뜨는지는 알지만 고객이 실제로 실패하는지는 늦게 압니다. 전담 SRE는 없고 서버 비용도 빠듯합니다. 이런 상황에서 중요한 질문은 ‘가장 고급스러운 배포 방식이 무엇인가’가 아니라 ‘우리 팀이 감당할 수 있는 검증·알림·롤백 수준은 어디까지인가’입니다.

1. 세 가지 전략을 먼저 정확히 구분하기

롤링 업데이트는 기존 인스턴스나 Pod를 조금씩 새 버전으로 바꾸는 방식입니다. Kubernetes Deployment의 기본 RollingUpdate는 old Pod와 new Pod를 단계적으로 교체하고, maxUnavailable은 업데이트 중 사용할 수 없는 Pod 수, maxSurge는 원하는 replica 수보다 추가로 만들 수 있는 Pod 수를 제어합니다. Kubernetes 문서는 RollingUpdate를 기본 전략으로 설명하고, progressDeadlineSeconds로 정체된 rollout을 감지할 수 있다고 안내합니다. ([kubernetes.io](https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/))

블루그린 배포는 현재 운영 중인 blue 환경 옆에 새 green 환경을 띄우고, 검증 후 로드밸런서나 서비스 라우팅을 green으로 전환하는 방식입니다. AWS ECS 문서 기준으로도 blue/green, linear, canary는 기존 revision과 새 revision이 일정 시간 동시에 존재한다는 점이 핵심이며, ECS 배포 설정에는 ROLLING, BLUE_GREEN, LINEAR, CANARY 전략이 구분되어 있습니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeploymentConfiguration.html))

카나리 배포는 새 버전에 소량의 production traffic을 먼저 보내고, 그 결과가 안정적이면 나머지 트래픽을 옮기는 방식입니다. 선형 배포는 카나리의 한 변형처럼 실무에서 함께 비교되며, 10%, 20%, 30%처럼 동일한 간격으로 트래픽을 늘립니다. AWS ECS canary 문서는 canary percentage, canary bake time, deployment bake time을 별도 리소스로 설명하며, 카나리는 monitoring complexity와 일시적 resource usage 증가를 동반한다고 명시합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html))

2. 작은 팀을 위한 선택표

세 가지 배포 전략을 비용과 리스크 기준으로 비교하는 회의 장면
같은 무중단 배포라도 롤링은 비용 효율, 블루그린은 빠른 복귀, 카나리는 장애 반경 축소에 강점이 있습니다.
기준롤링 업데이트블루그린 배포카나리·선형 배포
적합한 팀운영 자동화가 아직 얇고 비용을 크게 늘리기 어려운 팀릴리즈 전 검증 환경이 필요하고 빠른 traffic switch back이 중요한 팀트래픽과 관측 지표가 충분하며 배포 중 판단을 자동화하고 싶은 팀
장애 반경교체 속도와 감지 속도에 따라 새 버전 장애가 점차 확산전환 전에는 production 영향이 작지만 전환 후에는 전체 영향 가능처음에는 일부 사용자에게만 노출되어 blast radius를 제한
서버 비용대체로 낮음. 단, maxSurge나 추가 task 설정에 따라 일시 증가bake time 동안 blue와 green을 함께 운영하므로 일시 비용 증가기존·신규 revision을 병행하므로 canary 기간 동안 리소스 증가
필수 준비물헬스체크, readiness, 자동 빌드, 배포 실패 알림두 target group 또는 동등한 라우팅 구조, smoke test, 전환 런북트래픽 가중치 조절, 버전별 metric, 알람, 자동 또는 수동 promotion 기준
롤백 방식이전 이미지·revision으로 재배포 또는 rollout undo트래픽을 blue로 되돌리고 green을 격리canary traffic을 0%로 돌리거나 이전 stable revision으로 복귀
가장 큰 함정장애 감지 전까지 새 버전이 계속 퍼질 수 있음DB가 호환되지 않으면 앱만 되돌려도 장애가 남음트래픽이 적으면 카나리 구간에서 의미 있는 신호를 얻기 어려움

실무적으로는 다음처럼 판단하면 됩니다. 월간 트래픽이 작고 배포 빈도도 낮다면 카나리보다 롤링 업데이트와 배포 전 스모크 테스트가 먼저입니다. 반대로 하루에도 여러 번 배포하고, 로그인·결제·리포트 생성 같은 핵심 이벤트의 성공률을 버전별로 볼 수 있다면 카나리나 선형 배포가 의미를 갖습니다. 고객 수는 적지만 한 고객 장애가 계약 문제로 이어지는 B2B SaaS라면 블루그린과 피처 플래그 조합이 더 현실적일 수 있습니다.

3. 의사결정 플로우: 이 질문에 답하면 전략이 좁혀진다

  1. 현재 운영 중인 인스턴스가 2개 이상인가? 단일 인스턴스만 있다면 ‘무중단’이라는 표현부터 조심해야 합니다. 한 대를 끄고 한 대를 올리는 구조에서는 헬스체크와 graceful shutdown을 잘해도 순간적인 공백이 생길 수 있습니다.
  2. 새 버전과 기존 버전이 같은 DB를 동시에 써도 되는가? 안 된다면 카나리와 블루그린 모두 위험합니다. 먼저 스키마 호환성을 설계해야 합니다.
  3. 버전별 오류율과 지연시간을 볼 수 있는가? 로그·메트릭에 build SHA, image tag, service revision이 찍히지 않으면 카나리는 감에 의존하는 배포가 됩니다.
  4. 롤백 권한과 절차가 문서화되어 있는가? 배포자가 자리를 비우면 아무도 되돌리지 못하는 구조라면 전략보다 런북이 먼저입니다.
  5. 이중 인프라 비용을 몇 분 또는 몇 시간 감당할 수 있는가? 블루그린과 카나리는 안전을 위해 일정 시간 두 버전을 함께 유지합니다. 비용 알림과 예산 한도를 같이 봐야 합니다.

작은 팀의 배포 전략은 ‘무조건 카나리’가 아닙니다. 관측성이 없으면 카나리는 단지 천천히 장애를 퍼뜨리는 장치가 될 수 있고, DB 호환성이 없으면 블루그린은 전환 버튼만 빠른 위험한 배포가 됩니다.

4. 트래픽 분할은 어디에서 하는가

커밋부터 트래픽 전환과 롤백까지 이어지는 배포 워크플로우
배포 전략은 로드밸런서 설정 하나가 아니라 테스트, 계측, 알림, 롤백 런북이 연결된 운영 흐름입니다.

트래픽 분할은 보통 로드밸런서, Ingress, service mesh, managed platform의 revision 라우팅 중 하나에서 처리합니다. AWS ECS에서 Application Load Balancer를 사용하는 blue/green, linear, canary 구성은 primary target group과 alternate target group, production listener, 선택적인 test listener를 필요로 합니다. ECS 문서는 blue revision과 green revision을 target group으로 분리하고 listener rule로 트래픽을 전환하는 구조를 설명합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb-resources-for-blue-green.html))

Google Cloud 쪽에서는 Cloud Deploy가 Cloud Run이나 GKE 대상에 대해 canary phase를 만들고, 자동 카나리에서는 일부 traffic percentage를 단계별로 배분할 수 있습니다. 또한 deploy analysis에서 Google Cloud Observability 또는 다른 metric provider를 사용해 phase 진행 여부를 판단할 수 있습니다. ([docs.cloud.google.com](https://docs.cloud.google.com/deploy/docs/deployment-strategies/canary?authuser=01)) Cloud Run은 revision별 traffic percentage를 지정해 gradual rollout과 rollback을 수행할 수 있습니다. ([docs.cloud.google.com](https://docs.cloud.google.com/run/docs/rollouts-rollbacks-traffic-migration?authuser=8&hl=en))

Kubernetes만 쓰는 작은 팀이라면 처음부터 service mesh를 도입하기보다 Deployment RollingUpdate, readiness probe, Ingress의 기본 헬스체크, CI/CD에서의 스모크 테스트를 먼저 안정화하는 편이 낫습니다. 이미 Kubernetes 운영이 성숙했고 버전별 트래픽 분할이 필요하다면 Argo Rollouts 같은 progressive delivery 도구를 검토할 수 있지만, 그때도 알림과 metric naming이 먼저입니다.

5. 모니터링 없이 카나리를 하면 안 되는 이유

카나리는 ‘일부 사용자에게만 배포한다’가 아니라 ‘일부 사용자에게 노출한 뒤 수치로 판단한다’입니다. 최소한 다음 지표가 버전별로 분리되어야 합니다.

  • 요청 성공률: 5xx, 특정 API 실패율, timeout 비율
  • 지연시간: 평균보다 p95·p99를 우선 확인
  • 포화 지표: CPU, memory, container restart, DB connection, queue backlog
  • 핵심 비즈니스 이벤트: 가입 완료, 로그인 성공, 결제 승인, 파일 업로드, 리포트 생성, 관리자 저장 성공
  • 버전 식별: log, trace, metric label에 release version 또는 image tag 포함

임계값은 업종과 서비스마다 다르므로 하나의 정답을 만들면 안 됩니다. 예를 들어 평소 5xx가 거의 없는 내부 업무 SaaS는 1건의 500 에러도 즉시 확인 대상일 수 있고, 외부 API 의존도가 큰 서비스는 외부 장애와 신규 버전 장애를 분리해야 합니다. 중요한 것은 ‘stable 대비 canary가 나빠졌는가’를 같은 시간대에 비교하는 것입니다.

배포 게이트판단 예시조치
헬스체크 실패새 revision이 readiness를 통과하지 못함트래픽 전환 중지, 원인 확인
오류율 증가canary 버전의 5xx 또는 핵심 API 실패가 stable보다 명확히 높음canary traffic 0%, 배포 freeze
지연시간 악화p95·p99가 평소 배포 변동폭을 넘어 상승promotion 보류, 쿼리·외부 API·캐시 확인
비즈니스 이벤트 실패결제, 가입, 보고서 생성 등 핵심 성공률 저하즉시 롤백 후보, 고객 영향 범위 산정
고객 문의 발생특정 계정이나 권한 그룹에서 신규 오류 보고feature flag off 또는 해당 segment 제외

6. DB 마이그레이션은 배포 전략보다 먼저 설계한다

블루그린과 카나리에서 가장 자주 놓치는 부분은 데이터베이스입니다. 앱 버전은 두 개로 나눌 수 있지만 production DB는 보통 하나입니다. 새 앱이 컬럼을 rename하거나 enum 의미를 바꾸고, 기존 앱이 그 DB를 계속 읽으면 롤백해도 장애가 남습니다.

기본 패턴은 expand-contract입니다. 먼저 새 컬럼이나 테이블을 추가하고, 기존 앱과 새 앱이 모두 읽고 쓸 수 있게 만듭니다. 그다음 백필을 수행하고, 새 앱에서 새 스키마를 사용하게 한 뒤, 안정화 기간이 지난 후에만 오래된 컬럼을 제거합니다. 이 주제는 별도로 정리한 데이터베이스 마이그레이션 전략 가이드와 함께 보면 배포 순서를 잡기 쉽습니다.

  • 컬럼 추가는 대체로 안전하지만, not null 제약과 default 값 적용은 테이블 크기와 DB 엔진 특성을 확인합니다.
  • 컬럼 삭제, 타입 변경, 의미 변경은 앱 롤백을 막을 수 있으므로 별도 릴리즈로 분리합니다.
  • 백필 작업은 배포 파이프라인과 분리하고, 재시도 가능하며 중단 후 재개 가능한 구조로 만듭니다.
  • 카나리 중에는 old app과 new app이 동시에 쓰므로 dual write, backward compatible read를 검토합니다.
  • 블루그린에서도 traffic switch back은 쉬울 수 있지만 DB migration rollback은 별도 문제입니다.

7. 롤링 업데이트를 선택했다면 최소 안전장치는 이렇게 잡는다

작은 팀의 현실적인 1단계는 롤링 업데이트입니다. Kubernetes에서는 maxUnavailable을 낮추고 maxSurge로 여유 Pod를 먼저 띄우는 방식을 검토할 수 있습니다. 단, replica 수가 1개라면 퍼센트 설정이 기대와 다르게 동작할 수 있으므로 실제 staging에서 rollout 이벤트를 확인해야 합니다. ECS rolling을 쓰는 경우에는 minimum healthy percent와 maximum percent가 배포 중 task 수를 어떻게 조절하는지 확인해야 합니다. ECS 문서는 rolling deployment에서 batch size와 healthy task 비율이 배포 동작을 제어한다고 설명합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeploymentConfiguration.html))

Kubernetes probe 설정도 중요합니다. readiness probe는 준비되지 않은 Pod에 traffic이 가지 않도록 하는 장치이고, startup probe는 초기 로딩이 긴 앱에서 liveness가 너무 빨리 컨테이너를 죽이는 문제를 줄이는 데 쓰입니다. Kubernetes 문서는 readiness probe가 실패한 container에는 Service를 통한 traffic이 가지 않도록 한다고 설명하며, liveness probe는 잘못 설정하면 오히려 장애를 키울 수 있다고 주의합니다. ([kubernetes.io](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/))

배포 파이프라인에서는 이미지 태그를 latest로만 쓰지 말고 commit SHA나 release number로 고정해야 합니다. 테스트, 빌드, 취약점 검사, 배포 승인 단계를 어떻게 구성할지는 CI 파이프라인 가속화와 보안 가이드에서 다룬 캐시·병렬화·SAST·SCA 기준과 연결해 설계하는 것이 좋습니다.

8. 블루그린을 선택해야 하는 상황

블루그린은 배포 전 green 환경에 직접 접속해 smoke test를 돌릴 수 있다는 장점이 큽니다. 관리자 대시보드, B2B 업무 자동화, 내부 승인 시스템처럼 ‘트래픽을 일부만 나눠 검증하기 어려운 서비스’에서는 카나리보다 블루그린이 이해관계자에게 설명하기 쉽습니다. AWS ECS blue/green 문서는 managed traffic shifting을 위해 Elastic Load Balancing 또는 Service Connect를 구성할 수 있고, CloudWatch alarm, lifecycle hook, rollback procedure 테스트를 best practice로 제시합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-deployment-implementation.html))

다만 블루그린은 서버 비용과 capacity planning이 분명히 필요합니다. green을 띄우는 동안 blue를 유지해야 하고, 전환 후에도 bake time 동안 old revision을 남겨두면 비용이 추가됩니다. 이 비용을 줄이려고 검증 시간을 지나치게 줄이면 블루그린의 장점도 함께 사라집니다. 작은 팀이라면 ‘항상 두 벌 운영’이 아니라 ‘배포 창 동안만 두 벌 운영하고 자동 정리’하는 방식으로 시작하는 것이 보통 더 현실적입니다.

9. 카나리·선형 배포를 선택해야 하는 상황

카나리와 선형 배포는 새 버전의 위험을 작게 시작해 관찰하는 전략입니다. AWS ECS linear 문서는 step percent와 step bake time으로 동일한 비율의 traffic shift를 반복하고, 각 단계 사이에 모니터링 시간을 둘 수 있다고 설명합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-linear.html)) 고객 수가 충분하고, API 호출량이 많고, 버전별 지표가 정확히 분리되는 SaaS라면 카나리는 장애 반경을 줄이는 데 효과적입니다.

하지만 트래픽이 너무 적으면 5% 카나리에 하루 동안 요청이 몇 건만 들어올 수 있습니다. 이 경우 통계적으로 의미 있는 판단을 하기 어렵고, 특정 고객 한 명의 사용 패턴에 결과가 좌우됩니다. 이때는 카나리보다 내부 사용자, 베타 고객, 특정 account segment, feature flag를 활용하는 쪽이 낫습니다. 즉 카나리는 대기업 전용은 아니지만, ‘작은 팀도 트래픽과 계측이 준비되었을 때’ 효과가 있습니다.

10. 배포 전 체크리스트와 롤백 런북

배포 전 체크리스트와 롤백 런북을 점검하는 PM과 개발팀
롤백 기준은 장애가 난 뒤 정하는 문서가 아니라 배포 버튼을 누르기 전에 합의해야 할 운영 계약입니다.

배포 전에는 아래 체크리스트를 담당자와 함께 확인하세요. 문서가 거창할 필요는 없지만, 장애가 난 뒤 슬랙에서 즉석으로 정하면 늦습니다.

배포 전 체크리스트

  • 이번 배포의 변경 범위가 기능, 설정, DB, 인프라 중 어디에 해당하는지 분리했는가?
  • 이미지 태그, commit SHA, migration version을 릴리즈 노트에 남겼는가?
  • 스모크 테스트가 실제 production 의존성의 최소 경로를 확인하는가?
  • DB migration이 old app과 new app 모두와 호환되는가?
  • readiness, liveness, startup probe 또는 동등한 health check가 환경에 맞게 설정됐는가?
  • 버전별 오류율, 지연시간, 핵심 이벤트 성공률을 볼 수 있는가?
  • 롤백 버튼 또는 명령을 누를 권한자가 명확한가?
  • 고객 공지가 필요한 배포인지 PM·CS가 알고 있는가?
  • 배포 실패 시 1차 판단 시간을 몇 분으로 볼지 정했는가?
  • 이전 버전 이미지와 설정을 즉시 재사용할 수 있는가?

롤백 런북 예시

  1. 배포 freeze 선언: 추가 배포와 수동 hotfix를 잠시 중단합니다.
  2. traffic 복귀: 카나리는 canary weight를 0%로, 블루그린은 blue target group 또는 이전 revision으로 돌립니다.
  3. DB 상태 확인: destructive migration이 있었는지, 백필이 진행 중인지 확인합니다.
  4. 고객 영향 범위 산정: 시간대, 계정, API, 기능 단위로 영향 범위를 남깁니다.
  5. 복구 검증: 단순히 서버가 200을 반환하는지보다 핵심 업무 플로우가 성공하는지 확인합니다.
  6. 사후 정리: 실패한 green/canary 리소스, 임시 feature flag, 알람 mute를 제거합니다.

복구 절차는 배포 롤백만으로 끝나지 않습니다. 백업과 복원까지 포함한 운영 복원력을 점검하려면 백업 복원 테스트 자동화 가이드처럼 RTO/RPO 관점의 검증도 함께 필요합니다.

11. 서버 비용을 줄이면서 안전성을 확보하는 방법

롤링 업데이트는 비용 측면에서 가장 가볍지만 장애 감지 전파 지연을 감수합니다. 블루그린과 카나리는 비용이 증가하지만 장애 반경과 롤백 시간을 줄일 수 있습니다. 작은 팀은 다음 순서로 비용을 조정하면 됩니다.

  • 상시 blue/green이 아니라 배포 중에만 green을 생성하고 안정화 후 정리합니다.
  • bake time을 임의로 길게 잡지 말고 핵심 사용자 여정과 배치 주기를 기준으로 정합니다.
  • preview 환경은 production과 동일한 설정을 쓰되, 트래픽 검증 전에는 replica 수를 낮게 시작합니다.
  • 배포 창을 트래픽이 낮은 시간대로 잡되, 장애 감지가 가능한 담당자가 있는 시간에 진행합니다.
  • 비용 알림과 배포 알림을 같은 채널에 연결해 green 리소스 방치 여부를 확인합니다.

결국 배포 전략은 비용 절감만의 문제가 아닙니다. 장애 한 번으로 고객 신뢰, CS 시간, 정부지원사업 중간점검 데모 일정, B2B PoC 일정이 흔들릴 수 있다면 일정 시간의 추가 인프라 비용은 보험 성격을 가집니다. 반대로 아직 고객이 적고 배포가 월 1회라면, 복잡한 카나리 플랫폼보다 테스트 자동화와 롤백 문서가 먼저입니다.

12. AgentMit 관점의 현실적인 도입 순서

AgentMit은 SaaS, AI 서비스 개발, 업무 자동화, 관리자 대시보드, 정부지원사업 MVP를 다루는 작은 팀에서 처음부터 과한 플랫폼을 만들기보다 현재 구조에 맞는 최소 안전장치를 먼저 설계하는 편을 권합니다. 예를 들어 1단계는 CI/CD에서 image tag, migration 순서, smoke test, 배포 알림을 정리하는 것입니다. 2단계는 로드밸런서 기반 blue/green 또는 managed canary를 붙이고, 3단계에서 feature flag와 자동 rollback 기준을 고도화합니다.

구현이 필요하다면 BizMit 기반 서비스 구조, AWS·GCP·Kubernetes 배포 환경, 관리자 화면, AI 자동화 API까지 함께 보면서 ‘어떤 전략을 쓸지’보다 ‘어디에서 traffic을 나누고, 어떤 metric으로 멈추며, 누가 rollback할지’를 먼저 정리하는 것이 좋습니다. 내부에 운영자가 없다면 AgentMit 제작 문의를 통해 릴리즈 리스크 진단, CI/CD 연동, 모니터링 임계값, 롤백 런북 범위를 작게 시작할 수 있습니다.

FAQ

Q1. 작은 개발팀은 카나리, 블루그린, 롤링 업데이트 중 무엇부터 도입해야 하나요?

대부분은 롤링 업데이트에 readiness check, 스모크 테스트, 배포 실패 알림, 수동 롤백 절차를 먼저 붙이는 것이 현실적입니다. 트래픽을 버전별로 나눠 볼 수 있고 모니터링 지표가 충분하면 카나리나 선형 배포를 검토하고, 즉시 전환과 빠른 복귀가 중요하며 일시적 이중 인프라 비용을 감당할 수 있으면 블루그린을 선택합니다.

Q2. 블루그린 배포는 서버 비용이 항상 두 배로 드나요?

항상 장기간 두 배라는 뜻은 아니지만, 전환 전후 bake time 동안 기존 버전과 새 버전을 동시에 운영해야 하므로 일시적인 리소스 증가는 계획해야 합니다. 비용을 줄이려면 배포 창을 짧게 잡고, 검증 자동화를 압축하고, preview 용량과 production 용량을 구분하는 방식이 필요합니다.

Q3. 카나리 배포를 하려면 어떤 모니터링 지표가 최소로 필요하나요?

최소한 버전별 5xx 오류율, p95 또는 p99 지연시간, CPU·메모리·DB 커넥션 등 포화 지표, 핵심 비즈니스 이벤트 성공률, 배포 버전이 찍힌 로그가 필요합니다. 절대값만 보지 말고 기존 stable 버전과 canary 버전을 같은 시간대에 비교해야 합니다.

Q4. DB 마이그레이션이 있으면 카나리나 블루그린 배포가 안전한가요?

배포 전략만으로는 안전하지 않습니다. 기존 앱과 새 앱이 같은 DB를 동시에 사용할 수 있도록 expand-contract 방식으로 스키마를 먼저 호환시켜야 합니다. 컬럼 삭제, 타입 변경, 의미가 바뀌는 rename은 앱 롤백을 막을 수 있으므로 별도 릴리즈로 분리하는 것이 좋습니다.

Q5. 피처 플래그와 카나리 배포는 같은 개념인가요?

다릅니다. 카나리는 인프라나 라우팅 계층에서 새 버전으로 가는 트래픽 비율을 조절하는 방식이고, 피처 플래그는 같은 배포 버전 안에서 기능 노출 대상을 조절하는 방식입니다. 작은 팀은 둘 중 하나만 고르기보다 위험한 기능은 플래그로 끄고, 배포 자체는 롤링 또는 카나리로 관리하는 조합을 자주 사용합니다.

참고한 공식 문서

자주 묻는 질문

작은 개발팀은 카나리, 블루그린, 롤링 업데이트 중 무엇부터 도입해야 하나요?
대부분은 롤링 업데이트에 readiness check, 스모크 테스트, 배포 실패 알림, 수동 롤백 절차를 먼저 붙이는 것이 현실적입니다. 트래픽을 버전별로 나눠 볼 수 있고 모니터링 지표가 충분하면 카나리나 선형 배포를 검토하고, 즉시 전환과 빠른 복귀가 중요하며 일시적 이중 인프라 비용을 감당할 수 있으면 블루그린을 선택합니다.
블루그린 배포는 서버 비용이 항상 두 배로 드나요?
항상 장기간 두 배라는 뜻은 아니지만, 전환 전후 bake time 동안 기존 버전과 새 버전을 동시에 운영해야 하므로 일시적인 리소스 증가는 계획해야 합니다. 비용을 줄이려면 배포 창을 짧게 잡고, 검증 자동화를 압축하고, preview 용량과 production 용량을 구분하는 방식이 필요합니다.
카나리 배포를 하려면 어떤 모니터링 지표가 최소로 필요하나요?
최소한 버전별 5xx 오류율, p95 또는 p99 지연시간, CPU·메모리·DB 커넥션 등 포화 지표, 핵심 비즈니스 이벤트 성공률, 배포 버전이 찍힌 로그가 필요합니다. 절대값만 보지 말고 기존 stable 버전과 canary 버전을 같은 시간대에 비교해야 합니다.
DB 마이그레이션이 있으면 카나리나 블루그린 배포가 안전한가요?
배포 전략만으로는 안전하지 않습니다. 기존 앱과 새 앱이 같은 DB를 동시에 사용할 수 있도록 expand-contract 방식으로 스키마를 먼저 호환시켜야 합니다. 컬럼 삭제, 타입 변경, 의미가 바뀌는 rename은 앱 롤백을 막을 수 있으므로 별도 릴리즈로 분리하는 것이 좋습니다.
피처 플래그와 카나리 배포는 같은 개념인가요?
다릅니다. 카나리는 인프라나 라우팅 계층에서 새 버전으로 가는 트래픽 비율을 조절하는 방식이고, 피처 플래그는 같은 배포 버전 안에서 기능 노출 대상을 조절하는 방식입니다. 작은 팀은 둘 중 하나만 고르기보다 위험한 기능은 플래그로 끄고, 배포 자체는 롤링 또는 카나리로 관리하는 조합을 자주 사용합니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 남구 전포대로 133, 11층 102호(문현동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.