롤링 배포는 쿠버네티스 전용 기능이 아니라, 구버전과 신버전 인스턴스를 일정 시간 겹쳐 두면서 순차 교체하는 배포 패턴 자체를 가리킵니다. 이 패턴의 성공 여부는 오케스트레이터 종류보다 readiness 판정, 연결 드레이닝, replica 여유분 설계에 더 크게 좌우됩니다. 서비스 수가 적고 트래픽이 안정적이면 단일 런타임이나 매니지드 플랫폼의 롤링 배포로도 충분할 수 있고, 서비스·팀이 늘어날수록 쿠버네티스의 선언적 제어가 운영 비용을 상쇄하기 시작합니다.
롤링 배포는 정확히 무엇을 교체하는 과정인가?
롤링 배포는 구버전 인스턴스를 한 번에 모두 내리지 않고, 신버전 인스턴스를 순차적으로 올리면서 트래픽을 조금씩 옮기는 방식입니다. 전체를 동시에 바꾸는 배포와 달리 '교체 단위'를 쪼개서, 항상 일부 인스턴스는 살아있는 상태를 유지하는 것이 설계의 핵심입니다.
- 롤링 배포는 구버전·신버전이 일정 시간 공존하는 배포 패턴이지, 특정 오케스트레이터만의 기능이 아닙니다.
- 쿠버네티스는 이 패턴을
maxSurge,maxUnavailable, readiness probe로 선언적으로 자동화합니다. - 단일 호스트 런타임에서도 순차 교체·헬스체크·드레이닝을 직접 구현하면 같은 패턴을 재현할 수 있습니다.
- 실패 지점은 오케스트레이터보다 애플리케이션의 graceful shutdown·readiness 설계에 있는 경우가 많습니다.
이 개념 자체는 쿠버네티스가 만든 것이 아니라, 로드밸런서 뒤에서 서버를 하나씩 내리고 올리던 전통적인 운영 방식을 오케스트레이터가 선언적 설정으로 자동화한 것에 가깝습니다. 문제는 '겹쳐 가며 교체한다'는 말이 쉬워 보여도, 실제로는 세 질문에 답해야 한다는 점입니다. 언제 새 인스턴스를 트래픽에 투입해도 안전한가, 언제 구 인스턴스에서 연결을 끊어도 안전한가, 이 과정에서 가용 용량이 얼마나 줄어드는 것을 허용할 것인가입니다. 쿠버네티스 Deployment 공식문서는 이 세 질문에 각각 readiness probe, terminationGracePeriodSeconds, maxSurge/maxUnavailable이 대응한다고 설명합니다. Docker Compose나 systemd로 직접 운영한다면 이 세 가지를 스크립트와 헬스체크 로직으로 손수 구현해야 합니다.
maxSurge와 maxUnavailable은 배포 속도와 안전성을 어떻게 가르나?
maxSurge는 업데이트 중 기존 복제본 수보다 추가로 띄울 수 있는 Pod 수, maxUnavailable은 업데이트 중 사용 불가 상태를 허용하는 Pod 수를 제어합니다. 둘 다 0에 가까울수록 보수적이고, 값이 클수록 배포는 빠르지만 순간적으로 여러 버전이 섞인 트래픽을 더 넓게 허용합니다.
maxSurge: 0, maxUnavailable: 1 조합은 여분 Pod를 추가로 띄우지 않고, 기존 Pod를 하나씩 내린 자리에 새 Pod를 채우는 방식입니다. 추가 리소스를 쓰지 않는 대신, 복제본 수가 적거나 새 Pod 기동이 느린 서비스에서는 전체 배포 시간이 길어질 수 있습니다. 검색된 사례 중 하나는 Kubernetes 1.32, 이 설정 조합에서 평균 배포 시간이 22분 14초에서 11분 2초로, p99가 47분 32초에서 18분 41초로, 배포 실패율이 12.3%에서 1.1%로 줄었다고 보고합니다. 다만 이 수치는 공식 클라우드 사업자 자료나 재현 가능한 벤치마크가 아니라 개인 사이트의 사례 작성자가 보고한 수치이며, 같은 글이 빌드 시간 단축까지 쿠버네티스 전환 효과로 묶어 제시해 인과관계를 분리하기 어렵습니다. 따라서 이 숫자는 "이런 조건에서 이런 결과가 보고된 적이 있다" 정도로만 참고하는 편이 안전합니다.
반대로 maxSurge를 늘리면 배포는 빨라지지만, 순간적으로 전체 Pod 수가 평소보다 많아지므로 노드 리소스 여유가 있어야 합니다. replica가 2~3개뿐인 서비스에서 maxUnavailable: 1은 배포 중 가용 복제본이 절반 이하로 떨어질 수 있다는 뜻이므로, 이 값은 replica 수와 함께 봐야 의미가 생깁니다.
Ready 판정은 어떤 기준으로 이뤄지나?
새 Pod가 트래픽을 받아도 되는 시점은 컨테이너 프로세스가 떴는지가 아니라 readiness probe 결과로 판정됩니다. liveness probe는 '죽었으면 재시작', readiness probe는 '아직 트래픽을 보내면 안 됨'을 구분하는 역할이고, 이 둘을 같은 엔드포인트로 섞으면 초기화 중인 Pod가 재시작 루프에 빠지거나, 반대로 준비되지 않은 상태로 트래픽을 받는 문제가 생깁니다.
실무에서 흔한 함정은 readiness probe를 단순 /health 200 응답으로만 두는 것입니다. 애플리케이션이 캐시 워밍업, DB 커넥션 풀 초기화, 설정 로딩을 끝내기 전에 200을 반환하면, 쿠버네티스 입장에서는 "준비 완료"로 보이지만 실제로는 첫 요청 몇 건에서 지연이나 오류가 발생합니다. startup probe를 별도로 둬서 초기화가 오래 걸리는 애플리케이션의 기동 유예 시간을 분리하는 것도 이 때문입니다. 롤링 배포의 체감 안전성은 결국 이 probe 설계의 정밀도에 크게 좌우됩니다.
트래픽을 끊지 않고 넘기려면 어떤 계층이 더 필요한가?
readiness probe만으로는 연결 드레이닝이 보장되지 않습니다. 구 Pod를 종료할 때 로드밸런서나 Ingress가 이미 그 Pod로 보낸 연결을 끊지 않고 마무리할 시간을 줘야 하는데, 이 역할은 terminationGracePeriodSeconds와 preStop hook, 그리고 서비스 디스커버리가 엔드포인트 목록을 갱신하는 타이밍이 함께 맞아야 합니다. Pod가 SIGTERM을 받은 직후 바로 연결을 끊으면, 엔드포인트 목록이 갱신되기 전에 들어온 요청이 실패할 수 있습니다.
PodDisruptionBudget(PDB)은 자발적 중단(노드 드레인, 배포) 중 최소 가용 Pod 수를 보장하는 장치입니다. replica 3개짜리 서비스에 minAvailable: 2를 설정하면, 배포와 노드 유지보수가 겹쳐도 최소 2개는 항상 떠 있도록 스케줄러가 순서를 조정합니다. 이 계층이 빠지면 롤링 배포 자체는 정상 동작해도, 다른 운영 이벤트와 겹쳤을 때 가용 복제본이 예상보다 더 줄어드는 상황이 생길 수 있습니다.
롤링 배포가 적용되면 다운타임은 완전히 사라지나?
아니요, 롤링 배포는 '완전 무중단'을 보장하는 장치가 아니라 중단 범위를 줄이는 설계입니다. readiness probe가 통과해도 신버전 코드에 성능 저하나 호환성 문제가 있으면 5xx나 재시도율이 일시적으로 올라갈 수 있고, 데이터베이스 스키마가 구버전·신버전 양쪽에서 호환되지 않으면 롤링 중 일부 요청이 실패합니다.
또 하나 흔한 오해는 "배포 시간이 짧아졌다 = 쿠버네티스 덕분이다"로 단순화하는 것입니다. 검색된 사례 중 하나는 같은 전환 과정에서 빌드 시간 단축까지 함께 제시했는데, 이는 실행 환경(오케스트레이터) 변경 효과인지 빌드 파이프라인 변경 효과인지 분리되지 않습니다. 롤링 배포 품질을 평가할 때는 배포 시간 단축 자체보다, 배포 중 p95/p99 지연시간 변화, 5xx 비율, 롤백 소요 시간처럼 사용자 영향과 직결된 지표를 먼저 봐야 합니다.
쿠버네티스 없이도 롤링 배포를 돌릴 수 있나?
가능하지만, 복제본 수·팀 수·운영 인력에 따라 비용 구조가 달라집니다. 단일 호스트나 소수 호스트에서 서비스 수가 적고 트래픽 변동이 작다면, Docker Compose 수준에서 순차 교체·헬스체크·연결 드레이닝을 스크립트로 구현해도 충분할 수 있습니다. 다만 이 경우 자동 롤백, 다중 호스트 간 순서 조정, 배포 중 가용 복제본 최솟값 보장은 모두 직접 짜야 하는 부분입니다.
Amazon ECS 같은 매니지드 컨테이너 플랫폼은 배포·서비스 디스커버리·오토스케일링을 제공하면서 쿠버네티스 클러스터 자체를 직접 운영하지 않는 절충안입니다. 서비스 수가 늘고 팀별 독립 배포, 세밀한 리소스 격리, 다중 리전이 필요해지면 쿠버네티스의 표준화된 롤링 업데이트 제어가 운영 복잡도를 상쇄하기 시작합니다. 다만 그 비용은 클러스터 업그레이드, CNI·Ingress·RBAC 관리, 노드 패치, 관측성 스택 구축으로 이동할 뿐 사라지지 않습니다. 검색된 비교 자료 하나는 단일 호스트 컨테이너 시작 시간을 평균 0.5초, 쿠버네티스 Pod 스케줄링 포함 시간을 2~4초로, 메모리 오버헤드를 Docker Engine 약 100MB 대 쿠버네티스 노드당 약 500MB로 제시했지만, 노드 사양·CNI·이미지 캐시 상태가 공개되지 않아 방향성 참고 이상으로 쓰기는 어렵습니다. 2026년 기준으로도 이런 숫자는 자체 환경에서 재현해 확인하는 편이 안전합니다.
정리하면 롤링 배포 판단 기준은 무엇인가?
- 롤링 배포는 오케스트레이터 기능이 아니라 '순차 교체 + 일부 가용성 유지'라는 패턴이다.
- 안전성은 readiness/startup/liveness probe 설계와 연결 드레이닝 타이밍이 결정한다.
maxSurge/maxUnavailable은 배포 속도와 리소스 여유, replica 수와 함께 해석해야 한다.- PodDisruptionBudget 없이 롤링 배포만 설정하면 다른 운영 이벤트와 겹쳤을 때 가용성이 예상보다 떨어질 수 있다.
- 서비스 수·팀 규모·운영 인력이 작다면 단일 런타임이나 매니지드 플랫폼으로도 같은 패턴을 재현할 수 있고, 규모가 커질수록 쿠버네티스의 표준화 효과가 운영 비용을 상쇄하기 시작한다.
핵심 정리
- 롤링 배포의 본질은 구버전·신버전 공존 + 순차 교체이며, 성공 여부는 readiness probe와 연결 드레이닝 설계에 좌우된다.
maxSurge: 0,maxUnavailable: 1같은 보수적 설정은 리소스를 아끼는 대신 배포 시간이 길어질 수 있다는 트레이드오프를 동반한다.- "배포 시간이 줄었다"는 수치만으로 특정 오케스트레이터의 효과를 단정하기 전에, 빌드 파이프라인 변경 같은 다른 변수와 분리했는지 확인해야 한다.
- 롤링 배포는 다운타임을 완전히 없애는 장치가 아니라 중단 범위와 실패율을 줄이는 설계이며, 스키마 호환성·재시도율 같은 지표를 함께 봐야 한다.
- 서비스 수·팀 규모·운영 인력에 따라 단일 런타임, 매니지드 플랫폼, 쿠버네티스 중 어디서 같은 패턴을 구현할지가 갈린다.