이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Blue-Green Deployment는 Rolling과 무엇이 다른가?
- Blue와 Green 환경을 전환하기 전에 어떤 drift와 호환성을 확인해야 하는가?
- 트래픽 전환 후 문제가 생기면 무엇을 보존하고 무엇을 되돌려야 하는가?
개요
Blue-Green Deployment는 현재 트래픽을 받는 환경과 새 버전을 준비하는 환경을 분리하는 배포 방식이다.
예를 들어 blue가 현재 운영 환경이면 green에 새 버전을 배포하고 검증한 뒤 트래픽을 green으로 전환한다.
문제가 생기면 트래픽을 다시 blue로 돌릴 수 있다.
장점은 전환이 빠르고 이전 환경을 남겨 둘 수 있다는 점이다.
단점은 두 환경의 설정, 데이터 계약, 외부 의존성이 다르면 전환 순간에 큰 장애가 날 수 있다는 점이다.
전환 흐름
blue: current production traffic
green: new version deployed but no public traffic
1. green 배포
2. green 내부 health와 smoke test
3. blue/green 설정 비교
4. traffic switch
5. green 관측
6. blue 보존 또는 폐기Blue-Green은 배포와 트래픽 전환을 분리한다.
그래서 새 버전을 사용자에게 노출하기 전에 더 많은 검증을 할 수 있다.
하지만 전환 후에는 많은 트래픽이 한 번에 새 환경으로 이동할 수 있다.
Green 환경 검증
Green 환경은 단순히 프로세스가 떠 있는지만 보면 안 된다.
Spring profile, config, Secret, DB endpoint, Redis endpoint, 외부 API mock 여부가 blue와 의도대로 같은지 확인한다.
GREEN_URL=https://green-api.example.internal
curl -fsS "$GREEN_URL/actuator/health/readiness"
curl -fsS "$GREEN_URL/actuator/info"
./smoke-test.sh --base-url "$GREEN_URL" --suite core/actuator/info로 git SHA와 build version을 확인하면 green이 기대 artifact인지 검증할 수 있다.
Drift 확인
Blue와 Green은 같은 코드만으로 충분하지 않다.
환경 변수, Secret version, JVM option, feature flag, DB migration 상태가 다르면 같은 요청도 다르게 처리될 수 있다.
blue version: 1.8.2-ff9012
green version: 1.8.3-abc1234
profile: prod
DB schema: V52
feature flag: checkout.v2=false
Secret bundle: prod-2026-07전환 전에는 의도한 차이와 의도하지 않은 차이를 구분해야 한다.
트래픽 전환
트래픽 전환은 load balancer, DNS, gateway, release controller 등 환경마다 방식이 다를 수 있다.
핵심은 “전환 시각”과 “전환 대상”을 정확히 기록하는 것이다.
DNS 기반 전환은 TTL 때문에 일부 사용자가 blue를 더 오래 볼 수 있다.
Load balancer 기반 전환은 상대적으로 빠르지만 health check 설정이 잘못되면 준비되지 않은 green으로 트래픽이 갈 수 있다.
운영 체크리스트
- Blue와 Green의 artifact version과 git SHA가 명확한가?
- Green 환경에서 readiness와 핵심 smoke test를 완료했는가?
- profile, config, Secret, feature flag 차이를 확인했는가?
- DB migration이 blue와 green 모두에 호환되는가?
- 전환 시각, 담당자, 승인자가 기록되는가?
- 전환 후 blue를 얼마나 보존할지 정했는가?
- 전환 실패 시 traffic switch back 절차가 준비되어 있는가?
장애 신호
- Green 내부 smoke test는 성공했지만 public traffic 전환 후 인증이나 callback URL이 실패한다.
- Blue와 Green의 Secret version이 달라 외부 API 인증 결과가 다르다.
- DB migration 후 blue로 되돌렸더니 이전 버전이 새 schema를 읽지 못한다.
- DNS TTL 때문에 일부 사용자는 blue, 일부 사용자는 green을 계속 본다.
- Green health는 UP인데 핵심 business API latency가 급증한다.
- 전환 후 blue를 바로 삭제해 비교와 복귀가 불가능하다.
안전한 완화 조치
전환 직후 문제가 보이면 먼저 트래픽 전환을 멈추거나 blue로 되돌릴 수 있는지 확인한다.
Blue가 아직 보존되어 있고 DB 변경이 backward compatible이면 traffic switch back이 빠른 완화가 될 수 있다.
DB 변경이 blue를 깨는 상태라면 blue 복귀가 더 큰 장애를 만들 수 있다.
Green 환경의 설정 drift가 원인이면 green을 수정한 뒤 다시 검증하고 전환한다.
전환 후 blue를 폐기하기 전에는 관측 창을 충분히 둔다.
인프라 담당자와 공유할 자료
배포 전략: blue-green
blue: order-api 1.8.2-ff9012, traffic 100%
green: order-api 1.8.3-abc1234, smoke test 성공
switch time: 2026-07-01 15:20 KST
증상: green 전환 후 OAuth callback redirect 오류
차이: green X-Forwarded-Proto 처리 설정 누락
요청: traffic을 blue로 복귀, green config 수정 후 재검증Blue-Green 공유 자료에는 두 환경의 차이와 전환 시각이 반드시 포함되어야 한다.
실전 팁
- Blue와 Green의 의도한 차이만 남기고 나머지 drift를 줄인다.
- 전환 전 Green의 내부 endpoint로 smoke test를 실행한다.
- 전환 후 바로 Blue를 삭제하지 않는다.
- DNS 기반 전환은 TTL과 mixed traffic 시간을 고려한다.
- Blue 복귀가 DB 변경 때문에 가능한지 미리 확인한다.
위험 신호!
- Green health만 보고 바로 모든 트래픽을 전환한다.
- Blue와 Green의 config 차이를 기록하지 않는다.
- 전환 직후 이전 환경을 삭제한다.
- DB migration이 이전 버전을 깨는데 Blue 복귀를 rollback 계획으로 둔다.
- DNS TTL을 고려하지 않고 즉시 전환된다고 가정한다.
확인 질문
확인 질문
- Blue-Green과 Rolling의 가장 큰 차이는 무엇인가?
- Blue-Green은 새 환경을 별도로 준비한 뒤 트래픽 전환을 수행하고, Rolling은 같은 환경 안에서 인스턴스를 조금씩 교체한다.
- Green 전환 전에 drift를 확인해야 하는 이유는 무엇인가?
- 코드가 같아도 config, Secret, feature flag, DB 상태가 다르면 전환 후 다른 동작이 나올 수 있기 때문이다.
- Blue로 되돌리기 전에 확인할 것은 무엇인가?
- Blue가 아직 살아 있는지, DB와 외부 side effect가 이전 버전과 호환되는지, 전환 방식이 즉시 복귀 가능한지 확인해야 한다.