ReplicaSet과 Deployment 완벽 가이드

Kubernetes에서 애플리케이션을 안정적으로 운영하기 위한 핵심 컨트롤러인 ReplicaSet과 Deployment를 다룹니다. 롤링 업데이트, 롤백, 스케일링 등 실무에서 반드시 알아야 할 배포 전략을 초급자도 이해할 수 있게 설명합니다.

---

목차

1. ReplicaSet_개념과_역할
2. Deployment_생성_및_관리
3. 롤링_업데이트_전략
4. 롤백_수행하기
5. 스케일링_수평_확장
6. 배포_히스토리_관리

---

1. ReplicaSet 개념과 역할

김개발 씨는 첫 번째 Kubernetes 프로젝트에 투입되었습니다. 선배가 던진 첫 질문은 이것이었습니다.

"Pod 하나가 죽으면 어떻게 되는지 알아요?" 김개발 씨는 순간 아무 말도 할 수 없었습니다.

ReplicaSet은 한마디로 지정된 수의 Pod 복제본을 항상 유지해주는 컨트롤러입니다. 마치 호텔 프런트 데스크에서 항상 3명의 직원이 근무하도록 관리하는 것과 같습니다.

누군가 퇴근하면 즉시 다른 사람을 불러와 인원을 채우는 것처럼, ReplicaSet은 Pod가 죽으면 자동으로 새 Pod를 생성합니다.

다음 코드를 살펴봅시다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web-server-rs
  labels:
    app: web-server
spec:
  # 항상 3개의 Pod를 유지합니다
  replicas: 3
  selector:
    # 이 라벨을 가진 Pod를 관리합니다
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

김개발 씨는 입사 첫 달, 운영 중인 서버가 갑자기 다운되는 경험을 했습니다. 다행히 새벽이라 사용자가 적었지만, 30분간 서비스가 중단되었습니다.

수동으로 서버를 재시작하느라 진땀을 뺐던 기억이 생생합니다. 박시니어 씨가 커피 한 잔을 건네며 말했습니다.

"Kubernetes에서는 그런 걱정을 할 필요가 없어요. ReplicaSet이 알아서 해주거든요." 그렇다면 ReplicaSet이란 정확히 무엇일까요?

쉽게 비유하자면, ReplicaSet은 마치 24시간 편의점의 점장과 같습니다. 점장은 항상 2명의 직원이 매장에 있도록 관리합니다.

한 명이 화장실에 가거나 갑자기 아프면, 즉시 대기 중인 직원을 호출합니다. ReplicaSet도 마찬가지로 지정된 수의 Pod가 항상 실행 중이도록 보장합니다.

ReplicaSet이 없던 시절에는 어땠을까요? 개발자들은 서버가 죽으면 모니터링 알람을 받고 직접 재시작해야 했습니다.

새벽 3시에 호출받는 일이 다반사였습니다. 더 큰 문제는 트래픽이 몰릴 때 수동으로 서버를 늘려야 했다는 것입니다.

인기 있는 서비스일수록 운영 부담이 기하급수적으로 늘어났습니다. 바로 이런 문제를 해결하기 위해 ReplicaSet이 등장했습니다.

ReplicaSet을 사용하면 자동 복구가 가능해집니다. Pod가 어떤 이유로든 종료되면 ReplicaSet이 즉시 새 Pod를 생성합니다.

또한 선언적 관리도 얻을 수 있습니다. "나는 3개의 Pod를 원한다"고 선언하면, Kubernetes가 그 상태를 유지해줍니다.

무엇보다 안정적인 서비스 운영이라는 큰 이점이 있습니다. 위의 코드를 살펴보겠습니다.

먼저 replicas: 3 부분이 핵심입니다. 이것은 "항상 3개의 Pod를 유지하라"는 선언입니다.

다음으로 selector는 어떤 Pod를 관리할지 결정합니다. matchLabels로 지정한 라벨을 가진 Pod만 이 ReplicaSet의 관리 대상이 됩니다.

마지막으로 template은 새 Pod를 만들 때 사용할 템플릿입니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 온라인 쇼핑몰의 상품 조회 서비스를 운영한다고 가정해봅시다. 하루에 수백만 건의 요청을 처리해야 하는데, 서버 하나가 죽으면 큰일입니다.

ReplicaSet으로 3개의 Pod를 유지하면, 하나가 죽어도 나머지 2개가 요청을 처리하고 곧 3개로 복구됩니다. 하지만 주의할 점도 있습니다.

실무에서는 ReplicaSet을 직접 사용하는 경우가 드뭅니다. 왜냐하면 Deployment라는 더 상위 개념이 ReplicaSet을 자동으로 관리해주기 때문입니다.

ReplicaSet을 직접 수정하면 Deployment와 충돌이 발생할 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 새벽에 호출 안 받으셨군요!" ReplicaSet을 제대로 이해하면 Kubernetes의 핵심 철학인 선언적 관리를 이해할 수 있습니다.

다음 장에서는 ReplicaSet을 더 효과적으로 관리하는 Deployment에 대해 알아보겠습니다.

실전 팁

💡 - ReplicaSet은 직접 사용하기보다 Deployment를 통해 간접적으로 사용하세요

• selector와 template의 라벨이 일치해야 ReplicaSet이 정상 작동합니다
• replicas 값을 변경하면 즉시 Pod 수가 조정됩니다

---

2. Deployment 생성 및 관리

박시니어 씨가 김개발 씨에게 과제를 냈습니다. "오늘까지 새 버전 배포 좀 해줘요." 김개발 씨는 ReplicaSet YAML을 열었지만, 박시니어 씨가 손을 저었습니다.

"아니, Deployment로 해야지."

Deployment는 ReplicaSet의 상위 컨트롤러로, 애플리케이션 배포를 선언적으로 관리합니다. 마치 오케스트라 지휘자가 연주자들을 관리하는 것처럼, Deployment는 ReplicaSet을 통해 Pod를 관리하면서 버전 업데이트, 롤백 같은 고급 기능을 제공합니다.

다음 코드를 살펴봅시다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  # 배포 전략을 정의합니다
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

김개발 씨는 ReplicaSet을 배웠으니 이제 뭐든 할 수 있을 것 같았습니다. 하지만 막상 새 버전을 배포하려고 하니 막막했습니다.

이미지 버전을 바꾸면 기존 Pod는 어떻게 되는 걸까요? 한꺼번에 다 죽으면 서비스가 중단되는 것 아닌가요?

박시니어 씨가 웃으며 말했습니다. "그래서 Deployment를 쓰는 거예요.

ReplicaSet 직접 건드리면 안 돼요." Deployment란 정확히 무엇일까요? 쉽게 비유하자면, Deployment는 마치 레스토랑의 총지배인과 같습니다.

총지배인은 직접 요리를 하지 않습니다. 대신 주방장(ReplicaSet)에게 지시를 내리고, 주방장이 요리사들(Pod)을 관리합니다.

메뉴가 바뀌면 총지배인이 새로운 주방장을 고용하고, 기존 주방장은 자연스럽게 퇴장시킵니다. Deployment도 마찬가지로 ReplicaSet을 생성하고 관리합니다.

Deployment가 없이 ReplicaSet만 사용하면 어떤 문제가 있을까요? 이미지 버전을 업데이트하려면 ReplicaSet을 직접 수정하거나 새로 만들어야 합니다.

롤백하려면 이전 버전의 ReplicaSet을 기억하고 있어야 합니다. 배포 히스토리도 직접 관리해야 합니다.

이 모든 것이 수작업이라니, 생각만 해도 끔찍합니다. 바로 이런 문제를 해결하기 위해 Deployment가 등장했습니다.

Deployment를 사용하면 선언적 업데이트가 가능해집니다. 이미지 버전만 바꾸면 나머지는 Kubernetes가 알아서 처리합니다.

또한 자동 롤백도 지원됩니다. 배포에 문제가 생기면 이전 버전으로 쉽게 돌아갈 수 있습니다.

무엇보다 배포 히스토리 관리라는 큰 이점이 있습니다. 위의 코드를 살펴보겠습니다.

전체적인 구조는 ReplicaSet과 비슷합니다. 하지만 strategy 부분이 추가되었습니다.

이것이 Deployment의 핵심입니다. type: RollingUpdate는 점진적으로 Pod를 교체하겠다는 의미입니다.

maxSurge: 1은 업데이트 중 최대 1개의 추가 Pod를 허용한다는 뜻이고, maxUnavailable: 0은 항상 모든 Pod가 가용 상태여야 한다는 뜻입니다. 실제로 Deployment를 생성해보겠습니다.

kubectl apply 명령으로 위의 YAML을 적용하면 Deployment가 생성됩니다. Deployment는 자동으로 ReplicaSet을 만들고, ReplicaSet은 3개의 Pod를 생성합니다.

kubectl get deployments 명령으로 상태를 확인할 수 있습니다. 실무에서 Deployment는 어떻게 활용할까요?

거의 모든 상황에서 Deployment를 사용합니다. 웹 서버, API 서버, 백그라운드 워커 등 상태가 없는(Stateless) 애플리케이션은 모두 Deployment로 관리합니다.

배포 파이프라인과 연동하여 CI/CD를 구축하는 것도 일반적입니다. 하지만 주의할 점도 있습니다.

Deployment가 생성한 ReplicaSet을 직접 수정하면 안 됩니다. Deployment가 관리하는 ReplicaSet을 임의로 변경하면 예상치 못한 동작이 발생할 수 있습니다.

모든 변경은 Deployment를 통해서 해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

김개발 씨는 Deployment YAML을 작성하고 apply 명령을 실행했습니다. 잠시 후 새 버전이 배포되었다는 메시지가 떴습니다.

"이렇게 쉬운 거였어요?" Deployment를 제대로 이해하면 Kubernetes에서 가장 중요한 배포 패턴을 마스터한 것입니다. 다음 장에서는 Deployment의 핵심 기능인 롤링 업데이트에 대해 알아보겠습니다.

실전 팁

💡 - 실무에서는 거의 항상 Deployment를 사용하고, ReplicaSet은 직접 사용하지 않습니다

• Deployment의 이름은 서비스를 잘 나타내도록 명명하세요
• strategy 설정은 서비스 특성에 맞게 조정하세요

---

3. 롤링 업데이트 전략

드디어 김개발 씨의 첫 번째 기능이 완성되었습니다. 이제 배포만 하면 됩니다.

하지만 한 가지 걱정이 있었습니다. "배포하는 동안 서비스가 중단되면 어떡하죠?" 박시니어 씨가 답했습니다.

"걱정 마, 롤링 업데이트가 있으니까."

롤링 업데이트는 새 버전의 Pod를 하나씩 생성하면서 구버전 Pod를 하나씩 제거하는 배포 전략입니다. 마치 달리는 기차의 바퀴를 하나씩 교체하는 것처럼, 서비스를 중단하지 않고 점진적으로 버전을 업데이트할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # 업데이트 중 추가 생성 가능한 Pod 수
      maxSurge: 1
      # 업데이트 중 사용 불가한 Pod 수
      maxUnavailable: 1
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api-server:v2.0
        # 새 Pod가 준비되었는지 확인
        readinessProbe:
          httpGet:
            path: /health
            port: 8080

김개발 씨는 예전 회사에서 배포의 악몽을 겪었습니다. 금요일 저녁, 배포를 시작하자마자 서비스가 10분간 먹통이 되었습니다.

고객 항의가 빗발쳤고, 그날 야근은 새벽까지 이어졌습니다. Kubernetes의 롤링 업데이트는 이런 악몽을 과거의 이야기로 만들어줍니다.

롤링 업데이트란 정확히 어떻게 작동하는 걸까요? 쉽게 비유하자면, 롤링 업데이트는 마치 군인들의 교대 근무와 같습니다.

경비를 서는 군인이 4명이라고 합시다. 교대할 때 4명이 한꺼번에 빠지면 경비가 비어버립니다.

그래서 1명이 먼저 교대하고, 새 군인이 자리를 잡으면 다음 1명이 교대합니다. 롤링 업데이트도 마찬가지로 Pod를 점진적으로 교체합니다.

위 코드에서 핵심은 maxSurge와 maxUnavailable입니다. maxSurge: 1은 업데이트 중에 원래 replicas(4개)보다 최대 1개 더 많은 Pod가 존재할 수 있다는 의미입니다.

즉, 최대 5개의 Pod가 동시에 실행될 수 있습니다. 새 버전 Pod가 준비되는 동안 구버전도 트래픽을 처리합니다.

maxUnavailable: 1은 업데이트 중에 최대 1개의 Pod가 사용 불가 상태여도 된다는 의미입니다. 즉, 최소 3개의 Pod는 항상 트래픽을 처리합니다.

이 두 값을 조절하여 업데이트 속도와 안정성 사이의 균형을 맞출 수 있습니다. 실제 업데이트 과정을 따라가 봅시다.

처음에는 v1.0 Pod 4개가 실행 중입니다. 이미지를 v2.0으로 변경하면 Deployment가 새 ReplicaSet을 생성합니다.

새 ReplicaSet은 v2.0 Pod를 1개 생성합니다. v2.0 Pod가 준비되면(readinessProbe 통과), 구버전 ReplicaSet의 Pod 1개가 종료됩니다.

이 과정이 반복되어 결국 v2.0 Pod 4개만 남게 됩니다. readinessProbe의 역할이 매우 중요합니다.

새 Pod가 생성되었다고 바로 트래픽을 받으면 안 됩니다. 애플리케이션이 완전히 시작되지 않았을 수도 있기 때문입니다.

readinessProbe는 Pod가 트래픽을 받을 준비가 되었는지 확인합니다. /health 엔드포인트에 HTTP 요청을 보내서 성공 응답을 받아야만 Pod가 준비된 것으로 간주합니다.

maxSurge와 maxUnavailable 설정 전략을 알아봅시다. 안정성을 최우선으로 한다면 maxSurge: 1, maxUnavailable: 0으로 설정합니다.

항상 원래 개수의 Pod가 트래픽을 처리하므로 안전합니다. 대신 업데이트 속도가 느립니다.

빠른 배포가 필요하다면 **maxSurge: 25%, maxUnavailable: 25%**처럼 설정합니다. 한 번에 여러 Pod를 교체하므로 빠르지만, 일시적으로 처리 용량이 줄어들 수 있습니다.

하지만 주의할 점도 있습니다. 롤링 업데이트 중에는 구버전과 신버전이 동시에 트래픽을 처리합니다.

만약 API 스펙이 호환되지 않는다면 문제가 발생할 수 있습니다. 따라서 하위 호환성을 유지하는 것이 중요합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 이미지 버전을 v2.0으로 변경하고 apply 명령을 실행했습니다.

kubectl rollout status 명령으로 진행 상황을 지켜보니, Pod가 하나씩 교체되는 것이 보였습니다. 서비스는 단 1초도 중단되지 않았습니다.

롤링 업데이트를 제대로 이해하면 무중단 배포의 핵심을 마스터한 것입니다. 하지만 배포 후 문제가 발견되면 어떻게 해야 할까요?

다음 장에서 롤백에 대해 알아보겠습니다.

실전 팁

💡 - 반드시 readinessProbe를 설정하여 새 Pod가 준비되었는지 확인하세요

• 중요한 서비스라면 maxUnavailable: 0으로 설정하여 안정성을 확보하세요
• 배포 전 API 하위 호환성을 반드시 검토하세요

---

4. 롤백 수행하기

배포가 완료되었습니다. 김개발 씨는 뿌듯한 마음으로 퇴근하려는데, 갑자기 슬랙 알림이 울렸습니다.

"API 응답이 이상해요!" 새 버전에 버그가 있었습니다. 김개발 씨의 손이 떨리기 시작했습니다.

"어떻게 하죠?"

롤백은 문제가 발생했을 때 이전 버전으로 되돌리는 기능입니다. 마치 문서 편집기의 실행 취소(Ctrl+Z)처럼, Deployment는 이전 상태를 기억하고 있다가 언제든 복원할 수 있습니다.

Kubernetes가 배포 히스토리를 자동으로 관리하기 때문에 가능한 일입니다.

다음 코드를 살펴봅시다.

# 현재 배포 상태 확인
kubectl rollout status deployment/api-server

# 배포 히스토리 조회
kubectl rollout history deployment/api-server

# 바로 이전 버전으로 롤백
kubectl rollout undo deployment/api-server

# 특정 리비전으로 롤백
kubectl rollout undo deployment/api-server --to-revision=2

# 롤백 진행 상황 확인
kubectl rollout status deployment/api-server

# 롤백 후 Pod 상태 확인
kubectl get pods -l app=api-server

김개발 씨의 심장이 빠르게 뛰었습니다. 새 버전에 치명적인 버그가 있었습니다.

사용자들이 불편을 겪고 있고, 고객센터에 문의가 쏟아지고 있습니다. 빨리 수정해야 하는데, 버그 원인을 찾으려면 시간이 걸릴 것 같습니다.

박시니어 씨가 침착하게 말했습니다. "일단 롤백부터 하고, 버그는 천천히 찾아보자." 롤백이란 정확히 무엇일까요?

쉽게 비유하자면, 롤백은 마치 타임머신과 같습니다. 새로 산 가구 배치가 마음에 들지 않으면, 사진을 보고 예전 배치로 되돌릴 수 있습니다.

Deployment도 마찬가지로 이전 상태의 스냅샷을 보관하고 있다가 필요할 때 복원합니다. Deployment는 어떻게 히스토리를 관리할까요?

매번 업데이트할 때마다 Deployment는 새로운 ReplicaSet을 생성합니다. 하지만 이전 ReplicaSet을 바로 삭제하지 않습니다.

revisionHistoryLimit(기본값 10) 설정에 따라 이전 ReplicaSet들을 보관합니다. 이것이 롤백의 비밀입니다.

롤백은 사실 이전 ReplicaSet을 다시 활성화하는 것입니다. 위의 명령어들을 살펴보겠습니다.

kubectl rollout history는 배포 히스토리를 보여줍니다. 각 리비전 번호와 변경 사유를 확인할 수 있습니다.

kubectl rollout undo는 바로 이전 버전으로 롤백합니다. --to-revision 옵션을 사용하면 특정 리비전으로 롤백할 수 있습니다.

실제 롤백 과정을 따라가 봅시다. 먼저 kubectl rollout history로 히스토리를 확인합니다.

리비전 3이 현재 버전이고, 문제가 있습니다. kubectl rollout undo를 실행하면 리비전 2로 돌아갑니다.

내부적으로는 리비전 2의 ReplicaSet이 다시 활성화되고, 리비전 3의 ReplicaSet은 축소됩니다. 롤백도 롤링 업데이트 방식으로 진행됩니다.

롤백이라고 해서 모든 Pod가 한꺼번에 교체되는 것이 아닙니다. 배포할 때와 마찬가지로 점진적으로 교체됩니다.

따라서 롤백 중에도 서비스 중단은 발생하지 않습니다. 롤백 상황에서 유용한 팁이 있습니다.

배포할 때 --record 플래그를 사용하면 어떤 명령으로 배포했는지 기록됩니다. 나중에 히스토리를 볼 때 변경 사유를 확인할 수 있어 편리합니다.

또한 중요한 배포 전에는 현재 상태를 메모해두는 것도 좋습니다. 하지만 주의할 점도 있습니다.

롤백은 긴급 상황에서의 응급 처치입니다. 롤백 후에는 반드시 원인을 분석하고 근본적인 해결책을 찾아야 합니다.

또한 데이터베이스 스키마 변경 같은 상황에서는 롤백이 복잡해질 수 있습니다. 애플리케이션만 이전 버전으로 돌려도 DB는 그대로이기 때문입니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. kubectl rollout undo 명령을 실행하자, 곧 이전 버전이 복구되었습니다.

사용자 불만이 멈췄습니다. 김개발 씨는 안도의 한숨을 쉬었습니다.

"롤백이 이렇게 간단한 거였어요?" 박시니어 씨가 말했습니다. "그래, 하지만 이건 응급 처치야.

내일 출근하면 버그 원인을 찾아보자." 롤백을 제대로 이해하면 장애 상황에서도 침착하게 대응할 수 있습니다. 다음 장에서는 트래픽 변화에 대응하는 스케일링에 대해 알아보겠습니다.

실전 팁

💡 - 롤백은 응급 처치입니다. 롤백 후 반드시 근본 원인을 해결하세요

• revisionHistoryLimit을 적절히 설정하여 충분한 히스토리를 보관하세요
• 데이터베이스 변경이 포함된 배포는 롤백 전략을 미리 세워두세요

---

5. 스케일링 수평 확장

김개발 씨네 서비스가 인기를 끌기 시작했습니다. 평소에는 잘 돌아가던 서버가 점심시간만 되면 느려집니다.

모니터링 대시보드를 보니 CPU 사용률이 90%를 넘습니다. "서버를 더 늘려야 하는데..."

스케일링은 트래픽 변화에 따라 Pod 수를 조절하는 것입니다. 마치 레스토랑에서 손님이 많을 때 직원을 더 부르고, 한가할 때 줄이는 것과 같습니다.

Kubernetes에서는 명령어 하나로 즉시 Pod 수를 늘리거나 줄일 수 있습니다.

다음 코드를 살펴봅시다.

# 수동 스케일링: Pod 수를 5개로 변경
kubectl scale deployment/api-server --replicas=5

# 현재 상태 확인
kubectl get deployment api-server

# YAML로 스케일링 (선언적 방식)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  # Pod 수를 10개로 변경
  replicas: 10
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api-server:v2.0

김개발 씨네 서비스는 점심시간에 트래픽이 폭발합니다. 12시부터 1시 사이에 평소의 10배 트래픽이 몰립니다.

3개의 Pod로는 버거웠습니다. 응답 시간이 느려지고, 일부 사용자는 타임아웃 에러를 경험했습니다.

박시니어 씨가 말했습니다. "스케일 아웃 해야겠네.

잠깐이면 돼." 스케일링이란 정확히 무엇일까요? 쉽게 비유하자면, 스케일링은 마치 마트 계산대를 운영하는 것과 같습니다.

평소에는 계산대 3개로 충분합니다. 하지만 주말이나 명절에는 손님이 몰립니다.

이때 계산대를 10개로 늘리면 대기 시간이 줄어듭니다. 손님이 빠지면 다시 3개로 줄입니다.

Kubernetes의 스케일링도 마찬가지입니다. 두 가지 스케일링 방식이 있습니다.

**수직 스케일링(Scale Up)**은 각 Pod의 자원(CPU, 메모리)을 늘리는 것입니다. 작은 컴퓨터를 큰 컴퓨터로 바꾸는 것과 같습니다.

**수평 스케일링(Scale Out)**은 Pod의 수를 늘리는 것입니다. 컴퓨터 대수를 늘리는 것과 같습니다.

Kubernetes에서는 수평 스케일링이 더 일반적이고 권장됩니다. 위의 코드를 살펴보겠습니다.

kubectl scale 명령은 가장 간단한 스케일링 방법입니다. --replicas 옵션으로 원하는 Pod 수를 지정하면 즉시 적용됩니다.

YAML 파일의 replicas 값을 변경하고 apply하는 방법도 있습니다. 이 방식은 Git으로 변경 이력을 관리할 수 있어서 더 권장됩니다.

스케일링이 실제로 어떻게 이루어지는지 봅시다. replicas를 3에서 10으로 변경하면, Deployment가 ReplicaSet에 지시합니다.

ReplicaSet은 7개의 새 Pod를 생성합니다. 각 Pod는 스케줄러에 의해 적절한 노드에 배치됩니다.

Pod가 준비되면(readinessProbe 통과) 트래픽을 받기 시작합니다. 스케일 다운도 마찬가지입니다.

replicas를 10에서 3으로 변경하면, 7개의 Pod가 종료됩니다. 이때 graceful shutdown이 이루어집니다.

처리 중인 요청을 마무리하고 종료되므로 사용자는 영향을 받지 않습니다. 실무에서 스케일링은 어떻게 활용할까요?

일정한 패턴이 있는 트래픽이라면 미리 스케줄링해둘 수 있습니다. 예를 들어, 점심시간 전에 Pod를 늘리고 오후에 줄이는 스크립트를 cron으로 돌릴 수 있습니다.

더 나아가 **HorizontalPodAutoscaler(HPA)**를 사용하면 CPU나 메모리 사용률에 따라 자동으로 스케일링됩니다. 하지만 주의할 점도 있습니다.

Pod를 무작정 늘린다고 성능이 좋아지는 것은 아닙니다. 데이터베이스가 병목이라면 Pod를 늘려도 소용없습니다.

또한 노드의 자원이 부족하면 새 Pod가 Pending 상태에 머물 수 있습니다. 스케일링 전에 전체 시스템의 병목을 파악하는 것이 중요합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. kubectl scale 명령을 실행하자 곧 Pod가 10개로 늘어났습니다.

응답 시간이 정상으로 돌아왔습니다. "이렇게 간단하다니!" 박시니어 씨가 덧붙였습니다.

"나중에 HPA 설정하면 자동으로 되니까 더 편해. 다음에 알려줄게." 스케일링을 제대로 이해하면 트래픽 급증 상황에서도 서비스 품질을 유지할 수 있습니다.

다음 장에서는 배포 히스토리를 체계적으로 관리하는 방법을 알아보겠습니다.

실전 팁

💡 - 스케일링 전에 병목 지점을 먼저 파악하세요. Pod 수만 늘려서는 해결되지 않는 문제도 있습니다

• 예측 가능한 트래픽 패턴이 있다면 미리 스케줄링하세요
• HPA를 사용하면 자동 스케일링이 가능합니다

---

6. 배포 히스토리 관리

어느 날 장애가 발생했습니다. "3일 전 배포 때부터 이상했던 것 같아요." 김개발 씨는 당황했습니다.

3일 전에 무엇을 배포했는지 기억이 나지 않습니다. "배포 기록이 어디 있죠?"

배포 히스토리 관리는 언제, 무엇을, 왜 배포했는지 추적하는 것입니다. 마치 회사의 결재 문서처럼, 모든 배포는 기록되어야 합니다.

Kubernetes는 기본적인 히스토리를 제공하지만, 효과적인 관리를 위해서는 추가적인 전략이 필요합니다.

다음 코드를 살펴봅시다.

# 배포 히스토리 조회
kubectl rollout history deployment/api-server

# 특정 리비전 상세 정보 조회
kubectl rollout history deployment/api-server --revision=3

# 변경 사유를 기록하면서 배포
kubectl apply -f deployment.yaml --record

# annotation으로 변경 사유 기록
kubectl annotate deployment/api-server \
  kubernetes.io/change-cause="v2.1 배포: 로그인 버그 수정"

# 히스토리 보관 개수 설정 (YAML)
apiVersion: apps/v1
kind: Deployment
spec:
  # 최근 10개 리비전 보관
  revisionHistoryLimit: 10

김개발 씨는 이번 장애로 큰 교훈을 얻었습니다. 배포 기록을 제대로 관리하지 않으면 문제가 생겼을 때 원인을 찾기 어렵습니다.

3일 전에 무엇을 변경했는지 알 수 없어서 원인 분석에 반나절이 걸렸습니다. 박시니어 씨가 말했습니다.

"배포 기록은 개발자의 블랙박스야. 평소에 잘 관리해둬야 해." 배포 히스토리란 무엇일까요?

쉽게 비유하자면, 배포 히스토리는 마치 병원의 진료 기록과 같습니다. 환자가 언제 어떤 치료를 받았는지 기록해두면, 나중에 문제가 생겼을 때 원인을 찾기 쉽습니다.

배포 히스토리도 마찬가지로 언제, 어떤 버전을, 왜 배포했는지 기록합니다. Kubernetes는 어떻게 히스토리를 관리할까요?

Deployment는 매번 업데이트할 때마다 새로운 ReplicaSet을 생성합니다. 이전 ReplicaSet들은 revisionHistoryLimit 설정에 따라 보관됩니다.

기본값은 10입니다. 즉, 최근 10번의 배포 기록이 유지됩니다.

위의 명령어들을 살펴보겠습니다. kubectl rollout history는 배포 히스토리를 보여줍니다.

리비전 번호와 변경 사유가 표시됩니다. --revision 옵션을 사용하면 특정 리비전의 상세 정보를 볼 수 있습니다.

어떤 이미지가 사용되었는지, 환경 변수는 무엇이었는지 확인할 수 있습니다. 변경 사유를 기록하는 것이 중요합니다.

--record 플래그를 사용하면 실행한 명령이 자동으로 기록됩니다. 하지만 더 좋은 방법은 annotation을 직접 설정하는 것입니다.

"v2.1 배포: 로그인 버그 수정"처럼 의미 있는 메시지를 남기면 나중에 이해하기 쉽습니다. 실무에서의 히스토리 관리 전략을 알아봅시다.

첫째, 모든 배포에는 변경 사유를 기록합니다. 왜 이 배포를 했는지 미래의 자신이 이해할 수 있어야 합니다.

둘째, revisionHistoryLimit을 적절히 설정합니다. 너무 작으면 히스토리가 부족하고, 너무 크면 리소스를 낭비합니다.

셋째, 별도의 배포 로그 시스템을 구축합니다. Jira 티켓이나 Slack 채널과 연동하면 더 풍부한 맥락을 기록할 수 있습니다.

CI/CD 파이프라인과의 연동도 중요합니다. 대부분의 회사에서는 Jenkins, GitLab CI, GitHub Actions 같은 CI/CD 도구를 사용합니다.

배포가 파이프라인을 통해 이루어지면 자동으로 기록이 남습니다. Git 커밋 해시, PR 번호, 배포자 정보 등이 함께 기록되어 추적이 쉬워집니다.

하지만 주의할 점도 있습니다. revisionHistoryLimit을 너무 작게 설정하면 롤백할 수 있는 버전이 제한됩니다.

예를 들어 2로 설정하면 바로 직전 버전으로만 롤백할 수 있습니다. 또한 ReplicaSet을 직접 삭제하면 히스토리도 함께 사라지므로 주의해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 이번 교훈 이후 김개발 씨는 모든 배포에 변경 사유를 기록하기 시작했습니다.

팀에서 배포 규칙도 만들었습니다. 한 달 뒤 비슷한 장애가 발생했을 때, 5분 만에 원인을 찾을 수 있었습니다.

박시니어 씨가 흐뭇하게 웃었습니다. "성장했네!" 배포 히스토리 관리를 제대로 이해하면 장애 대응 속도가 빨라지고, 팀의 배포 문화가 성숙해집니다.

지금까지 배운 ReplicaSet, Deployment, 롤링 업데이트, 롤백, 스케일링, 히스토리 관리를 종합하면 Kubernetes 배포의 핵심을 마스터한 것입니다.

실전 팁

💡 - 모든 배포에 의미 있는 변경 사유를 annotation으로 기록하세요

• revisionHistoryLimit은 팀의 배포 주기에 맞게 설정하세요 (최소 5 이상 권장)
• CI/CD 파이프라인과 연동하여 자동으로 배포 기록을 남기세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!