무중단 배포 (Zero-Downtime Deployment)

[9ga0]

🗓️ 2026년 9월 7일 월요일

💡오늘의 질문?

서비스 운영 중 새로운 버전을 배포할 때 발생할 수 있는 다운타임(서비스를 사용할 수 없는 시간)을 최소화하기 위해 다양한 무중단 배포 전략을 사용할 수 있습니다. 대표적인 무중단 배포 방식인 Blue-Green, Rolling, Canary 배포에 대해 알아봅시다.

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

핵심 키워드와 꼬리 질문

핵키: 무중단 배포, 다운타임, 로드 밸런서, 트래픽 분산, Scale Out
꼬질: 서버가 한 대뿐이라면 무중단 배포가 어려운 이유는 무엇인가요?

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

핵심 키워드와 꼬리 질문

핵키: Blue-Green, Rolling, Canary, 트래픽 전환, 점진적 배포, 롤백
꼬질: Rolling 배포 중 구버전과 신버전이 동시에 실행될 때 어떤 문제가 발생할 수 있나요?

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

핵심 키워드와 꼬리 질문

핵키: 안정성, 장애 대응, 롤백, 트래픽 제어, 모니터링
꼬질: 선택한 배포 전략의 단점은 무엇이며, 이를 어떻게 보완할 수 있을까요?

참고자료: https://yeunever.tistory.com/62

(카나리vs블루그린 이미지 출처: https://xn--jaenung-9k94a.net/tree/43432)

[k9425mino]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드밸런서는 어떤 역할을 하나요?

무중단 배포란 서비스를 중단하지 않고 새 버전의 애플리케이션을 배포하는 방식이다. 사용자가 서비스를 이용할 수 없는 시간인 다운타임을 없애는 것이 목적이다.

이때 로드 밸런서는 여러 서버로 요청을 나누는 트래픽 분산 역할을 한다. 배포할 때는 특정 서버로 들어가는 신규 요청을 차단하고, 나머지 서버가 요청을 처리하도록 한다. 해당 서버의 기존 요청 처리가 끝나면 새 버전을 배포하고, 정상 동작을 확인한 뒤 다시 트래픽을 보낸다. 이 과정을 서버별로 반복하면 서비스를 유지하며 배포할 수 있다.

따라서 서버 수를 늘리는 Scale Out으로 여러 서버를 확보하면 무중단 배포가 쉬워진다. 다만 일부 서버가 배포 중이어도 나머지 서버가 전체 트래픽을 감당할 수 있어야 한다.

서버가 한 대 뿐이라면 왜 어려울까요?

애플리케이션을 종료하고 새 버전을 실행하는 동안 요청을 대신 처리할 서버가 없기 때문이다. 로드 밸런서가 있어도 트래픽을 보낼 정상 서버가 없다면 다운타임이 발생한다.

다만 물리 서버 한 대에서도 기존 버전과 새 버전을 서로 다른 포트나 컨테이너로 동시에 실행하고 트래픽을 전환하면 무중단 배포가 가능하다. 이 경우 두 버전을 실행할 자원이 필요하며, 서버 자체의 장애나 재부팅에는 대응할 수 없다.

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

세 방식의 핵심 차이는 신버전을 얼마나 넓은 범위에, 어떤 순서로 적용하고 트래픽을 전환하느냐이다.

[ Blue-Green ] : 현재 버전인 Blue와 별도 환경인 Green에 신버전을 준비한 뒤, 트래픽을 Green으로 한꺼번에 전환

• 장점: 전환이 빠르고, Blue를 유지하면 트래픽을 되돌려 빠르게 롤백 가능
• 단점: 두 환경을 동시에 유지할 자원이 필요하며 , 전환 후 전체 사용자가 오류에 노출될 수 있음

[ Rolling ] : 기존 서버를 일부씩 신버전으로 교체하는 점진적 배포

• 장점: 전체 환경을 복제하지 않아 추가 자원 부담이 비교적 작고, 서비스를 유지하며 배포 가능
• 단점: 구버전·신버전이 공존해 호환성이 필요하며, 롤백도 서버를 순차적으로 되돌려야 해 시간이 걸림

[ Canary ] : 신버전에 소량의 트래픽만 보내 검증한 뒤, 이상이 없으면 비율을 점차 확대

• 장점: 실제 트래픽으로 검증하면서 장애 영향을 제한하고, 문제가 생기면 시버전 트래픽을 차단하기 쉬움
• 단점: 정교한 트래픽 제어와 모니터링이 필요하며, 적은 트래픽으로는 일부 오류를 발견하기 어려움

예를 들어 서버가 10대라면, Rolling은 서버를 1~2대씩 교체하는 방식이고, Canary는 신버전에 트래픽을 1% → 10% → 50% → 100%로 늘리는 방식이다. Rolling도 신버전 노출이 점차 늘어나지만, Canary는 일부 사용자에게 노출한 결과를 평가해 확대 여부를 결정하는 것이 핵심이다.

Rolling 배포 중 구버전과 신버전이 동시에 실행되면 어떤 문제가 생기나요?

• API 호환성 문제: 신버전이 필드 이름이나 응답 형식을 바꾸면 구버전 클라이언트나 다른 서버가 이를 처리하지 못할 수 있다.
• DB 스키마 호환성 문제: 신버전 배포와 함께 컬럼을 삭제하거나 변경하면, 해당 컬럼을 사용하는 구버전 서버에서 오류가 발생할 수 있다.
• 세션·캐시 호환성 문제: 두 버전의 데이터 저장 형식이 다르면 세션이나 캐시를 읽지 못해 로그인 상태가 풀리거나 오류가 발생할 수 있다.
• 동작 불일치: 같은 사용자의 요청이 서로 다른 버전으로 전달되면서 계산 결과나 기능 동작이 달라질 수 있다.

따라서 두 버전이 함께 동작할 수 있도록 하위 호환성을 유지해야 한다. DB 변경은 보통 새 구조를 먼저 추가하고, 코드를 전환한 뒤, 구버전이 완전히 제거된 후 기존 구조를 삭제하는 순서로 진해한다. 또한 어떤 방식이든 이미 변경된 데이터까지 트래픽 전환만으로 롤백되지 않는다는 점을 고려해야 한다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

(GPT6-Astra의 판단) 결제 시스템이라면 Canary 배포를 선택할 것이다. 장애가 발생했을 때 영향을 받는 결제 요청을 제안하면서, 실제 트래픽으로 신버전의 안정성을 확인할 수 있기 때문이다.

구체적으로는 다음과 같이 운영할 것이다.

1. 트래픽 제어: 신버전에 소량의 트래픽만 보내고, 검증 결과에 따라 비율을 단계적으로 늘린다. 동일한 결제 흐름은 가능한 같은 버전에서 처리되도록 라우팅한다.
2. 모니터링: 에러율·응답 시간뿐 아니라 결제 승인 성공률, 중복 결제, 결제 상태 불일치 같은 업무 지표를 함께 확인한다.
3. 장애 대응과 롤백: 지표가 기준을 벗어나면 배포 확대를 중단하고, 신규 트래픽을 구버전으로 되돌린다. 처리 중인 결제는 갑자기 종료하지 않고 완료하거나 상태를 확인하도록 한다.

다만 코드를 롤백해도 이미 발생한 결제가 취소되는 것은 아니다. 따라서 중복 요청에도 결제가 한 번만 실행되도록 하는 멱등성, 결제 이력 기록, 결제사와 내부 상태를 대조하는 절차도 필요하다.

선택한 배포 전략의 단점은 무엇이며, 이를 어떻게 보완할 수 있을까요?

단점	보완 방법
트래픽 분배와 모니터링 구성이 복잡함	배포·트래픽 전환을 자동화하고, 중단 기준과 대응 절차를 미리 정해 훈련
적은 트래픽으로는 드문 장애를 발견하기 어려움	충분한 관찰 시간과 요청 수를 확보하고, 결제 수단별 지표 및 사전 테스트로 보완
구버전과 신버전이 공존해 호환성 문제가 발생할 수 있음	API·DB·이벤트 형식의 하위 호환성을 유지하고, 파괴적인 DB 변경은 나중에 수정
문제가 생기면 일부 실제 사용자에게 영향이 발생함	초기 노출 범위를 작게 제한하고, 이상 징후 감지 시 즉시 트래픽을 회수

핵심은 트래픽을 조금씩 늘리는 것과 함께, 확대를 멈출 기준과 빠르게 복구할 수단을 준비하는 것이다.

[JM-220]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

서버에 올려 사용자들에게 실제 배포가 된 프로그램의 경우를 보자. 만약 서비스 관련 기능에 업데이트가 생긴다면 이걸 사용자들에게 보여주기 위해 기존에 올려둔 프로그램을 종료시키고 다시 프로그램을 실행한다. 이게 가볍게 생각해볼 수 있는 수순이다. 서버 한대를 운용하고 그 위에 프로그램을 올려서 사용하는 것. 중단배포라고 한다. 근데 서비스를 종료시키기 어려운 서비스가 있을 수 있다. 예를 들어서 유튜브(유튜브가 404가 뜨는 걸 본적 있는 사람? 일단 난 아님)의 경우가 그러하다. 그러면 어떻게 해야할까? 업데이트는 해야하는데 서비스를 종료시키기 어려운 상황에서. 이 때 고려해야하는 것이 무중단 배포이다. 대략적인 원리는 이렇다

서버를 n대 운용한다. A서버에서 v1 으로 배포된 서비스를 v2로 업데이트한다고 하자. 이 경우 서버 B에 업데이트를 적용하고 A서버로 가던 트래픽을 로드 밸런서가 스위칭해서 서버 B로 보내면 된다. 기존에 A서버에서 작업하던 사람들의 작업이 끝나면 A서버에도 업데이트를 적용하면 된다.

1-1. 서버가 한 대뿐이라면 무중단 배포가 어려운 이유는 무엇인가요?

불가능은 아니다. 생각해보니 포트가 여러개니까 프로그램을 두개 띄워서 업데이트 된 프로그램을 새 포트에 옮기면 된다. 근데 그러면 전제가 사실상 서버 한대의 리소스를 대략 절반 이하로 사용하고 있는 상황이었어야 하는 것이다. cpu, mem 등…

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

Blue-Green : 이전 버전 혹은 수정이 필요한 프로그램이 있다고 할 때, 이전 버전에 남겨둘 서버를 Blue 서버, 먼저 수정을 적용시킬 서버를 Green 서버라고 한다. 두 서버가 마련이 되면 Blue 로 가던 트래픽을 Green 으로 바로 옮기는 방식이 Blue-Green 방식이다

장점	단점
다운타임 없이 업데이트 가능	인프라 비용 증가
빠른 롤백 가능	서버 간 공유 자원 간의 상태 충돌 가능성
운영 상태 분리 가능	데이터 마이그레이션 복잡
배포 리스크 최소화	트래픽 전환 시 타이밍과 헬스체크가 중요

Rolling : 운용하는 서버 수에 초점을 맞춘 무중단 배포 방식이다. 서버를 한번에 다 무중단 배포로 수정을 해버리는 게 아니라 하나씩 순차적으로 적용시키는 것.

장점	단점
점진적 배포 : 배포 중에 문제가 발생하면 배포를 중단하고 영향 범위를 제한할 수 있음.	롤백이 복잡함
	전 후 버전간 호환성 문제가 발생할 수 있음
	배포 시간 증가
	사용자 경험 불일치

Canary : Rolling 이 서버 수에 초점을 맞췄다면 Canary 는 사용자 비율에 초점을 맞춘다. 사용자 일부를 업데이트 적용된 서버로 옮겨가면서 점차 트래픽을 올리는 것이다. Rolling 과 방식은 다르지만 겉보기에는 유사한 방식이다.

장점	단점
리스크 최소화 : 소수의 사용자가 문제를 조기 탐지해줄 수 있다	운영 복잡도 증가
A/B 테스트 활용이 가능하다	롤링과 마찬가지로 호환성 문제가 발생할 수 있음
	롤백 설계가 필요함

2-2 Rolling 배포 중 구버전과 신버전이 동시에 실행될 때 어떤 문제가 발생할 수 있나요?

업데이트 적용 전 후 서버를 동시 운용할 때에도, 두 서버가 DB, 캐시, 메시지 시스템은 함께 사용하는데 두 서버가 서로가 만든 데이터를 이해하지 못하면 호환성 문제가 발생한다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

솔직히 둘다 상관 없을 것 같긴하다. 그래도 한다면 카나리로 할 것 같다. 왜냐하면 카나리는 A/B 테스트의 사용자 비중을 극도로 줄여서 업데이트된 서비스를 전체 사용자의 12% 정도로도 조정이 가능할 것 같은데 롤링에서 이렇게 하려면 서버가 50100 대를 운영해야 동일한 효과를 볼 것 같기 때문이다. 소규모 사용자(12%)로 테스트 해보고 잘 되면 늘리면 되니까… 망해도 12퍼만 망하는 거니까

3-2. 선택한 배포 전략의 단점은 무엇이며, 이를 어떻게 보완할 수 있을까요?

2번에서 적은 것처럼 카나리의 경우 운영 복잡도가 증가한다. 소수의 A/B 테스트를 계속 모니터링해봐야 하고 테스트 실패 시, 롤백과 같은 과정을 거쳐야 한다. 카나리 비율을 잘 조절해보면서 보완하자!

[eunji719]

1. 무중단 배포란 무엇이며, 이를 구현할 때 로드 밸런서는 어떤 역할을 하나요?

무중단 배포란 새 버전을 배포하는 동안에도 서비스가 중단되지 않고 사용자 요청을 계속 처리할 수 있도록 하는 배포 방식이다. 기존에는 서버를 내리고 새 버전을 올린 뒤 다시 켜는 방식이었다면, 무중단 배포는 신/구 버전이 공존하는 시점을 만들어 트래픽을 자연스럽게 전환한다.

이때 로드밸런서는 여러 서버 인스턴스 중 어디로 요청을 보낼지 결정한다. 새 버전 서버가 준비되면 로드 밸런서가 트래픽을 점진적으로 또는 즉시 새 서버로 돌린다. 또한 각 인스턴스의 상태를 주기적으로 확인하여, 준비되지 않았거나 장애가 난 서버로는 트래픽을 보내지 않는다. 기존 서버를 내리기 전에 이미 연결된 요청은 마무리하도록 유예 시간을 주고 새 요청만 새 서버로 보내고 Canary나 Rolling배포에서 트래픽 비율을 점진적으로 조절하는 주체가 바로 로드 밸런서이다.

로드 밸런서가 없다면 신구 버전 간 트래픽 전환 자체가 불가능 하여, 무중단 배포의 기술적 기반이라고 할 수 있다.

2. Blue-Green, Rolling, Canary 배포 방식의 차이점과 각각의 장단점을 설명해 주세요.

• Blue-Green 배포

  기존 환경(Blue)과 동일한 새 환경(Green)을 통째로 하나 더 만들고, 검증이 끝나면 밸런서의 트래픽을 한번에 Green으로 전환하는 방식이다. 전환이 즉각적이라 배포 시간이 짧고 문제가 발생하면 트래픽을 다시 Blue로 돌리기만 하면 돼서 롤백이 매우 빠르고 간단하다. 또한 신구 버전이 섞이지 않아 상태 일관성 문제가 적다는 장점이 있다. 하지만 두 환경이 있는 만큼 인프라를 두 개 유지해야 해서 비용도 2배이고 db스키마 변경이 있으면 양쪽 버전이 같은 db를 써야 해서 호환성 설계도 까다롭다. 또한 전체가 한 번에 전환되므로, 일부 사용자에게만 미리 테스트 해보는 것이 어렵다.

• Rolling배포

  여러 서버 인스턴스를 한 번에 몇 대씩 순차적으로 새 버전으로 교체해나가는 방식이다. 예를 들어 서버 10대 중 2대씩 순서대로 내리고 새 버전으로 교체한다. 이 방법은 추가 인프라가 거의 필요 없어 비용이 효율적이고 점진적으로 진행되므로 급격한 부하 변화가 적다. 배포 중간에는 신구 버전이 동시에 트래픽을 처리하므로 api호환성이 깨지면 문제가 생기고 롤백이 Blue-Green방식보다 느리다. 배포 완료까지 시간이 상대적으로 오래 걸린다.

• Canary배포

  신버전을 소수의 인스턴스에만 먼저 배포해서 실제 사용자 트래픽으로 검증한 뒤, 문제가 없으면 점진적으로 비율을 늘리는 방식이다. 실제 트래픽 기반으로 검증 가능해 위험이 낮고 문제가 발생하면 소수의 사용자에게 영향이 제한된다. 또 에러율,응답시간이 적힌 모니터링 지표를 보면서 배포 속도를 조절 가능하다. 하지만 트래픽 분배/모니터링/자동롤백 등 구현이 복잡하고 신구버전이 오래 공존할 수 있어 데이터 일관성 관리가 필요하다. 또한 배포까지 시간이 가장 오래 걸린다.

3. 결제 시스템처럼 장애에 민감한 서비스를 배포한다면 어떤 무중단 배포 전략을 선택하시겠습니까? 그 이유는 무엇인가요?

결제 시스템은 장애에 매우 민감하다. 오류가 나면 안된다. 이런 민감한 시스템에서는 작게 시작해서 지표를 보며 넓혀가고, 문제가 생기면 즉시 되돌릴 수 있는 능력이 가장 중요하여 Cannary배포가 가장 적합하다고 한다. 상황에 따라 빠른 롤백이라는 장점을 가진 Blue-Green과 결합하여도 좋다. 그러나 Rolling 방식은 신구 버전이 동시에 살아있는 동안 api나 데이터 스키마 호환성이 깨지면 결제 데이터 정합성 문제로 이어질 수 있기 때문에 리스크가 크다.