[DevOps] 서비스 중단 없는 배포: 무중단 배포의 원리와 전략 (Rolling vs Blue-Green)

새로운 기능이 추가되거나 버그가 수정되어 서버를 배포할 때, 과거에는 "새벽 2시~4시 점검 안내" 팝업을 띄우고 기존 서버를 잠시 꺼둔 채 작업을 진행하곤 했습니다.

24시간 끊김 없이 가동되어야 하는 글로벌 매시브 서비스나 빅테크 인프라에서는 단 1분의 다운타임(Downtime, 서비스 중단 시간)도 치명적인 매출 타격과 유저 이탈로 이어집니다.

이를 해결하기 위해 등장한 개념이 바로 무중단 배포(Zero-Downtime Deployment)입니다. 오늘은 사용자가 서비스를 이용하는 도중에도 자연스럽게 신버전 코드를 반영하는 핵심 원리와 대표적인 배포 전략들을 파헤쳐 봅니다.

1. 무중단 배포의 핵심 심장: 리버스 프록시의 라우팅 스위칭

어떻게 서버를 끄지 않고 새 코드를 올릴 수 있을까요? 비밀은 사용자와 서버 사이에 위치한 로드 밸런서 혹은 리버스 프록시에 있습니다. 가장 대중적으로 쓰이는 오픈소스 툴이 바로 Nginx입니다.

사용자는 백엔드 가동 서버의 IP로 직접 찌르는 것이 아니라, 언제나 앞단에 서 있는 Nginx의 대표 IP(포트 80/443)로만 요청을 보냅니다. Nginx는 내부 설정 파일(nginx.conf)의 라우팅 룰에 따라 뒤쪽에 있는 가동 서버 컨테이너들로 패킷을 배달해 줍니다.

• 스위칭 원리: 1. 구버전(V1) 컨테이너가 돌고 있는 상태에서, 구석의 빈 포트에 슬그머니 신버전(V2) 컨테이너를 실행합니다.3. Nginx에게 "이제부터 V1 말고 V2 포트로 트래픽을 보내라"고 명령(nginx -s reload)을 내립니다.
• 4. Nginx는 단 0.001초 만에 라우팅 경로를 전환하며, 유저는 세션이 끊기는 느낌을 전혀 받지 못한 채 신버전 서비스를 이용하게 됩니다.
• 2. 신버전 컨테이너가 에러 없이 완벽히 켜진 것(Health Check 패스)을 확인합니다.

2. 무중단 배포의 대표 전략 2가지 비교

인프라의 스펙과 자원 상황에 따라 선택하는 대표적인 두 가지 아키텍처 전략이 있습니다.

① 롤링 배포 (Rolling Deployment)

• 개념: 전체 서버 인프라 풀에서 컨테이너를 하나씩 혹은 일정 비율씩 차례대로 교체해 나가는 점진적 방식입니다.
• 프로세스: 서버 3대가 돌고 있다면, 1번 서버를 트래픽 차단 후 V2로 업데이트 → 가동 확인 후 다시 트래픽 투입 → 2번 서버 작업 순으로 릴레이 진행합니다.
• 장점: 추가적인 예산이나 컴퓨터 자원이 거의 들지 않습니다. 기존 서버 자원 내에서 쪼개어 배포하므로 가성비가 훌륭합니다.
• 단점: 배포가 진행되는 동안 V1 서버와 V2 서버가 공존하는 '버전 호환성 문제'가 발생합니다. 유저 A가 새로고침을 누를 때마다 구버전 화면과 신버전 화면을 번갈아 보게 되는 불일치 병목이 생길 수 있으며, 데이터베이스 스키마 하위 호환성 관리가 까다롭습니다.

② 블루-그린 배포 (Blue-Green Deployment)

• 개념: 구버전 환경(Blue)과 똑같은 스펙의 신버전 환경(Green) 인프라 세트를 임시로 통째로 하나 더 구축하여 한 방에 트래픽을 토글하는 방식입니다.
• 프로세스: Blue 인프라가 실시간 트래픽을 받고 있는 동안, 아무도 모르게 Green 인프라에 V2 코드를 다 올려둡니다. 세팅이 완료되면 앞단의 Nginx/로드 밸런서 스위치를 Blue에서 Green으로 100% 한 방에 돌려버립니다.
• 장점: 버전 공존 기간이 없어 하위 호환성 스트레스가 없습니다. 무엇보다 신버전 환경에 치명적인 예외 버그가 발견되었을 때, 라우팅 스위치를 다시 Blue로 슥 돌려버리기만 하면 되는 초고속 롤백 안전망을 가집니다.
• 단점: 배포 순간만큼은 물리적인 서버 인프라 자원이 정확히 2배로 필요하므로, 인프라 예산이 넉넉해야 채택할 수 있습니다.

3. 나에게 맞는 아키텍처 선택 기준

비교 항목	롤링 배포 (Rolling)	블루-그린 배포 (Blue-Green)
인프라 비용 추가	없음 (가성비 최상)	2배 일시 폭증
롤백 속도	다소 느림 (다시 하나씩 되돌려야 함)	즉시 가능 (스위치 토글)
구-신버전 공존	있음 (데이터 정합성 유의 필요)	없음 (깔끔한 스위칭)
적합한 환경	자원이 한정된 스타트업, 쿠버네티스 환경	예산이 넉넉하고 무조건적인 안정성이 필요한 빅테크

 무중단 배포의 진정한 허들, DB 스키마 마이그레이션

백엔드 엔지니어들이 Nginx 셋업만 하면 무중단 배포가 완벽해진다고 오해하곤 합니다. 하지만 진짜 병목은 애플리케이션 코드가 아니라 데이터베이스에 있습니다.

새로운 코드에서 DB 컬럼 명을 바꾸거나 테이블을 찢었는데, 구버전 서버가 여전히 구형 DB 구조를 바라보고 쿼리를 던지면 에러가 터지게 됩니다.

따라서 진정한 무중단 인프라를 가동하려면, DB 컬럼을 다룰 때 한 번에 지우거나 수정하지 않고 [1단계: 신규 컬럼 추가 및 데이터 마이그레이션] → [2단계: 신버전 애플리케이션 배포 완료] → [3단계: 구형 컬럼 제거] 형태로 데이터 아키텍처 가드레일을 촘촘히 쪼개어 릴리즈하는 설계 훈련이 병행되어야 합니다.