Apr 2, 2026

Kubernetes Deployment 가이드: Pod 대신 왜 Deployment를 쓸까

쿠버네티스를 처음 배울 때 Pod를 직접 만들면 앱이 뜨는 것처럼 보여서, 왜 굳이 Deployment가 필요한지 감이 잘 안 오는 경우가 많습니다. 하지만 실제 운영에서는 Pod를 하나씩 수동으로 다루는 방식이 거의 유지되지 않습니다.

Deployment는 “이 애플리케이션이 어떤 상태로 몇 개 떠 있어야 하는가”를 선언하는 리소스입니다. 즉, Pod 하나를 띄우는 것보다 훨씬 운영적인 관점의 도구입니다.

이 글에서는 아래 내용을 정리합니다.

Deployment가 무엇인지
Pod, ReplicaSet과 어떤 관계인지
롤링 업데이트와 롤백을 어떻게 이해하면 좋은지

핵심은 Deployment는 Pod 자체보다 원하는 상태를 관리하는 상위 리소스라는 점입니다.

Kubernetes Deployment란 무엇인가

Deployment는 특정 Pod 템플릿을 몇 개 유지할지 선언하고, 그 상태가 계속 유지되도록 관리합니다. 사람이 Pod를 하나씩 직접 올리고 내리는 대신, Deployment에 원하는 상태를 적어 두면 쿠버네티스가 그 상태를 맞추려고 동작합니다.

예를 들어 이런 요구를 표현할 수 있습니다.

웹 앱 Pod를 3개 유지하고 싶다
새 이미지 버전으로 점진적으로 바꾸고 싶다
배포가 잘못되면 이전 상태로 되돌리고 싶다

이런 운영 요구를 Pod 단독으로 다루는 것은 불편하지만, Deployment는 이를 기본 흐름으로 제공합니다.

Pod 와 ReplicaSet 과 Deployment 관계

입문자에게 가장 헷갈리는 부분 중 하나가 이 셋의 관계입니다.

Pod: 실제 앱 인스턴스
ReplicaSet: 같은 Pod를 몇 개 유지할지 관리
Deployment: ReplicaSet을 통해 배포와 업데이트 전략을 관리

보통은 Deployment를 만들면, 그 아래에 ReplicaSet이 생기고, ReplicaSet이 실제 Pod를 생성합니다.

그래서 실무에서는 보통 Pod를 직접 만들기보다 Deployment를 사용합니다.

왜 Pod를 직접 만들지 않을까

Pod를 직접 만들면 아래 문제가 생깁니다.

죽었을 때 자동 복구 흐름이 제한적이다
replica 수를 관리하기 번거롭다
버전 업데이트가 불편하다
이전 버전으로 되돌리기 어렵다

반대로 Deployment는 “이 앱은 항상 3개 떠 있어야 함” 같은 목표 상태를 갖고 있기 때문에, Pod 하나가 사라져도 새 Pod를 맞춰 줍니다.

가장 기본적인 Deployment 예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: my-api:1.0.0
          ports:
            - containerPort: 8080

이 설정은 my-api:1.0.0 컨테이너를 사용하는 Pod 3개를 유지하겠다는 선언입니다.

중요한 건 “지금 3개를 한 번 만들겠다”가 아니라, “계속 3개 상태를 유지하겠다”는 의미라는 점입니다.

롤링 업데이트는 어떻게 이해하면 좋을까

Deployment의 핵심 장점 중 하나는 롤링 업데이트입니다. 이미지 버전을 바꾸면 기존 Pod를 한 번에 모두 내리는 것이 아니라, 일부를 새 버전으로 교체하면서 점진적으로 전환합니다.

예를 들어 이미지 태그를 바꾸면:

일부 새 Pod가 먼저 뜬다
준비가 되면 기존 Pod가 일부 내려간다
이 과정을 반복하며 전체가 교체된다

이 방식 덕분에 다운타임 없이 배포하는 흐름을 만들기 쉬워집니다.

롤백은 왜 중요한가

배포는 항상 성공하지 않습니다. 새 버전이 readiness를 통과하지 못하거나, 실제 트래픽에서만 문제가 드러날 수도 있습니다.

Deployment는 이전 배포 이력을 바탕으로 롤백할 수 있게 도와줍니다. 그래서 Deployment는 단순 생성 리소스가 아니라, 운영 중인 애플리케이션의 배포 기록과 전략을 함께 관리하는 도구로 보는 편이 좋습니다.

replicas 는 어떻게 생각해야 할까

replicas는 같은 역할을 하는 Pod 수입니다. 예를 들어 웹 서버라면 보통 2개 이상을 두어 가용성을 확보합니다.

하지만 replicas를 늘린다고 항상 모든 문제가 해결되지는 않습니다. 앱이 stateless한지, startup이 안정적인지, readiness가 제대로 설정됐는지 같이 봐야 합니다.

즉, replica 수는 단순 숫자보다 운영 가정의 일부입니다.

Deployment 와 Service 는 어떻게 연결될까

Deployment는 Pod를 만들고 관리합니다. Service는 그 Pod 집합으로 안정적으로 접근하게 해 줍니다.

보통 흐름은 이렇습니다.

Deployment가 label을 가진 Pod를 만든다
Service가 그 label을 selector로 잡는다
클라이언트는 Service로 접근한다

즉, Deployment와 Service는 경쟁 관계가 아니라 서로 다른 역할을 가진 짝입니다. Service 쪽 개념은 Kubernetes Service 가이드를 같이 보면 더 명확해집니다.

자주 하는 오해

1. Deployment가 곧 Pod다

Deployment는 Pod 그 자체가 아닙니다. Pod를 관리하는 상위 선언 리소스입니다.

2. 이미지 태그만 바꾸면 무조건 안전하게 배포된다

readiness, startup time, resource limit, probe 같은 조건이 맞지 않으면 새 버전이 안정적으로 올라오지 않을 수 있습니다.

3. replicas를 늘리면 서비스가 자동으로 안정적이 된다

앱 자체가 crash 하거나 readiness가 실패하면 replicas만 늘려도 충분하지 않습니다.

처음 공부할 때 추천하는 실습

nginx Deployment를 replicas: 2로 만들기
이미지를 다른 태그로 바꿔서 rollout 보기
replica 수를 1, 3, 5로 바꿔 보며 Pod 수 변화 확인하기
일부러 잘못된 이미지 태그를 넣어 rollout이 꼬이는 상황 보기

이 실습을 해 보면 Deployment가 단순한 “Pod 생성기”가 아니라, 원하는 상태를 유지하고 배포를 관리하는 도구라는 감각이 빨리 생깁니다.

FAQ

Q. ReplicaSet을 직접 써도 되나요?

가능은 하지만, 보통은 Deployment를 쓰는 편이 더 자연스럽습니다. 업데이트와 롤백 관리가 더 쉽기 때문입니다.

Q. Pod 하나만 필요하면 Deployment 없이 써도 되나요?

학습용 예제는 가능하지만, 실제 운영 흐름에서는 Deployment가 훨씬 일반적입니다.

Q. 배포 후 Pod가 계속 안 떠요. Deployment가 고장 난 건가요?

보통은 이미지, probe, resource, config 문제일 가능성이 큽니다. 증상에 따라 Kubernetes CrashLoopBackOff나 Kubernetes ImagePullBackOff를 같이 보면 좋습니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.