[IT-방법] 디플로이먼트 실전 예제 단계별 따라하기 – 배포부터 동작 검증까지 완벽 실습

왜 지금 디플로이먼트 실무 능력이 필요한가요?

새벽에 갑자기 서버가 다운되었다는 알람을 받고 잠에서 깬 적이 있으신가요? 온프레미스 환경에서 운영하던 서비스가 예기치 못한 트래픽 폭주로 죽어버리면, 일일이 파드를 확인하고 수동으로 다시 띄우느라 진땀을 빼게 돼요. 이런 상황을 반복하지 않으려면 디플로이먼트(Deployment)를 제대로 다룰 줄 알아야 해요.

단순히 파드를 하나 띄우는 것과 디플로이먼트를 사용하는 것은 하늘과 땅 차이에요. 디플로이먼트는 우리가 원하는 상태를 정의해두면, 클러스터가 스스로 그 상태를 유지하도록 도와주는 아주 똑똑한 관리자거든요. 서비스가 죽으면 알아서 살려내고, 새로운 버전을 배포할 때도 서비스 중단 없이 부드럽게 교체해 줘요.

특히 인프라를 직접 관리하는 운영자라면, 단순히 명령어를 외우는 것이 아니라 각 설정값이 클러스터 내부에서 어떻게 동작하는지 그 원리를 이해하는 것이 중요해요. 그래야 장애가 발생했을 때 당황하지 않고 원인을 찾아낼 수 있어요.

이번 실습을 통해 여러분은 다음과 같은 실무 역량을 갖추게 돼요.

• 실제 현업에서 사용하는 표준 YAML 매니페스트 작성법
• 안정적인 롤링 업데이트를 통한 무중단 배포 전략
• 부하에 따른 스케일링 조절 및 상태 검증 방법
• 흔히 발생하는 배포 오류와 그 해결책

이제 이론적인 설명은 잠시 접어두고, 바로 실습 환경을 준비해서 코드를 직접 입력하며 몸으로 익혀볼까요?

실습을 시작하기 위한 준비물과 사전 지식

본격적인 실습에 들어가기에 앞서, 여러분의 환경이 준비되었는지 확인이 필요해요. 아무런 준비 없이 명령어를 입력하다가는 에러 메시지만 잔뜩 마주하게 될 수도 있거든요.

실습 필수 환경 체크리스트

가장 먼저 쿠버네티스 클러스터에 접근할 수 있는 환경이 갖춰져야 해요. 온프레미스 환경이라면 이미 구축된 클러스터가 있을 것이고, 개인 학습용이라면 Minikube나 Kind 같은 도구를 활용하는 것을 추천해요.

• 쿠버네티스 클러스터: 노드가 최소 1개 이상 동작 중이어야 해요.
• kubectl CLI: 클러스터와 통신하기 위한 명령줄 도구가 설치되어 있어야 해요.
• 컨테이너 이미지: 실습에 사용할 Nginx 같은 공개 이미지가 필요해요.
• YAML 에디터: VS Code처럼 문법 강조가 되는 도구를 사용하면 실수를 줄일 수 있어요.

리소스 객체 선택 기준 비교

쿠버네티스에는 다양한 관리 객체가 있어요. 무조건 디플로이먼트를 쓰는 것이 아니라, 상황에 맞는 도구를 선택하는 안목이 필요해요. 아래 표를 통해 차이점을 명확히 이해해 보세요.

준비가 모두 끝났다면, 이제 실제 코드를 작성하러 가볼까요? 다음 단계에서는 실무에서 가장 많이 쓰이는 형태의 매니페스트 파일을 직접 만들어 볼 거예요.

디플로이먼트 실전 배포 및 운영 실습

이제 본격적으로 손을 움직여 볼 시간이에요. 단순히 명령어를 복사해서 붙여넣는 것이 아니라, 각 설정이 어떤 의미를 갖는지 파헤치면서 진행할게요.

STEP 1. 배포 매니페스트 파일 작성하기

먼저 텍스트 에디터를 열고 nginx-deployment.yaml이라는 파일을 생성해 주세요. 아래의 내용을 입력하되, 각 항목의 의미를 눈여겨봐야 해요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-server
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.21
        ports:
        - containerPort: 80

여기서 replicas: 3은 우리가 원하는 파드의 개수가 항상 3개여야 함을 의미해요. 만약 노드 하나가 고장 나서 파드 하나가 사라지면, 쿠버네티스는 즉시 새로운 파드를 다른 노드에 띄워서 3개를 맞춰요.

또한 selector와 template.metadata.labels 부분이 매우 중요해요. 이 둘의 라벨이 일치해야 디플로이먼트가 자신이 관리해야 할 파드를 정확히 찾아낼 수 있거든요. 만약 이 라벨이 어긋나면, 디플로이먼트는 파드를 만들어놓고도 정작 본인이 관리하는 파드가 아니라고 판단해서 계속해서 새로운 파드를 만들어내는 무한 루프에 빠질 수도 있어요.

STEP 2. 클러스터 배포 및 동작 확인

파일 작성을 마쳤다면 터미널을 열고 명령어를 입력해 보세요. 파일을 클러스터에 전달하는 과정이에요.

kubectl apply -f nginx-deployment.yaml

명령어를 입력한 후, 실제로 파드가 잘 생성되었는지 확인해야 해요. 아래 명령어를 통해 실시간 상태를 관찰해 보세요.

kubectl get pods -l app=nginx

잠시 기다리면 파드 3개가 Running 상태로 바뀌는 것을 볼 수 있어요. 만약 상태가 Pending에 머물러 있다면, 클러스터에 리소스(CPU, 메모리)가 부족하거나 파드를 배치할 노드가 없는 상황일 가능성이 커요.

STEP 3. 무중단 롤링 업데이트 수행하기

운영 중인 서비스의 버전을 올릴 때, 서비스를 끄고 작업하는 시대는 지났어요. 디플로이먼트의 진가는 바로 이 롤링 업데이트(Rolling Update)에서 나타나요. Nginx 버전을 1.21에서 1.23으로 올려볼까요?

매니페스트 파일을 수정하거나, 아래 명령어를 통해 직접 이미지를 교체할 수 있어요.

kubectl set image deployment/my-web-server nginx-container=nginx:1.23

업데이트가 시작되면 쿠버네티스는 기존 파드를 하나씩 종료하면서 새로운 버전의 파드를 하나씩 생성해요. 이 과정을 관찰하려면 kubectl rollout status deployment/my-web-server 명령어를 사용해 보세요. 서비스 중단 없이 순차적으로 교체되는 모습을 확인할 수 있어요.

STEP 4. 스케일링을 통한 트래픽 대응

갑자기 사용자가 몰려 서버가 느려진다면 어떻게 해야 할까요? 파드의 개수를 늘려 대응할 수 있어요.

kubectl scale deployment/my-web-server --replicas=5

명령어를 실행하자마자 쿠버네티스는 즉시 파드 2개를 추가로 생성해요. 반대로 트래픽이 줄어들어 비용을 절감해야 한다면, 다시 숫자를 줄여주면 돼요. 이것이 바로 클라우드 네이티브 환경에서 운영 비용을 최적화하는 핵심 방법이에요.

[실무 시나리오] 장애 발생 시 대응 프로세스

실제 업무 환경에서는 다음과 같은 순서로 문제가 발생하고 해결되는 경우가 많아요.

1. 상황 발생: 특정 버전 배포 후 애플리케이션 응답 속도 저하 감지
2. 원인 파악: kubectl describe pod [파드이름] 명령어로 이벤트 로그 확인
3. 긴급 조치: kubectl rollout undo를 통한 이전 버전 롤백
4. 사후 분석: 스테이징 환경에서 이미지 및 설정값 재검증

자주 하는 실수와 해결법 및 FAQ

실습을 진행하다 보면 예상치 못한 에러를 마주하게 마련이에요. 당황하지 말고 아래의 케이스들을 참고해 보세요.

자주 하는 실수와 해결법

• ❌ ImagePullBackOff 에러가 발생해요
  왜 발생하는가: 입력한 컨테이너 이미지 이름이 틀렸거나, 프라이빗 레지스트리에 접근할 권한이 없어서 이미지를 가져오지 못하는 경우예요.
  ✅ 해결법: 이미지 이름과 태그를 다시 확인하고, imagePullSecrets 설정이 되어 있는지 체크해 보세요.
• ❌ Pod가 계속해서 CrashLoopBackOff 상태예요
  왜 발생하는가: 컨테이너는 실행되었지만, 애플리케이션 내부 로직 오류나 환경 변수 누락으로 인해 프로세스가 즉시 종료되는 상황이에요.
  ✅ 해결법: kubectl logs [파드이름] 명령어로 애플리케이션의 로그를 반드시 확인해야 해요.
• ❌ Deployment를 적용했는데 파드가 생성되지 않아요
  왜 발생하는가: YAML 파일의 selector와 template.labels가 서로 일치하지 않아 디플로이먼트가 파드를 관리할 수 없는 상태예요.
  ✅ 해결법: 두 부분의 라벨 값이 완전히 동일한지 다시 한번 대조해 보세요.
• ❌ 스케일링을 했는데 파드가 늘어나지 않아요
  왜 발생하는가: 클러스터의 노드 자원이 이미 가득 차서 새로운 파드를 배치할 공간이 없는 경우예요.
  ✅ 해결법: kubectl describe node 명령어로 각 노드의 자원 사용량을 확인해 보세요.

자주 묻는 질문

Q. Deployment와 ReplicaSet의 차이점은 무엇인가요?

ReplicaSet은 단순히 지정된 개수의 파드를 유지하는 역할만 해요. 반면 디플로이먼트는 ReplicaSet을 관리하면서, 앱의 버전을 올리거나 내리는 ‘배포 전략’까지 담당하는 상위 개념이라고 이해하시면 돼요. 따라서 실무에서는 항상 디플로이먼트를 사용해요.

Q. 롤링 업데이트 중에 서비스 중단이 발생할 수도 있나요?

설정이 올바르다면 이론적으로는 중단이 없어야 해요. 하지만 새 버전의 파드가 준비(Ready) 상태가 되기 전에 기존 파드를 너무 빨리 삭제하도록 설정되어 있다면 아주 짧은 순간 서비스 끊김이 발생할 수 있어요. readinessProbe를 설정해 파드가 완전히 준비되었는지 확인하는 과정이 꼭 필요해요.

Q. 파드의 로그는 어디서 확인하나요?

가장 기본적인 명령어는 kubectl logs [파드이름]이에요. 만약 파드가 이미 죽어서 사라졌다면 kubectl logs [파드이름] --previous 명령어를 통해 직전에 죽었던 파드의 로그를 확인할 수 있어요.

Q. 매니페스트 파일을 수정할 때마다 kubectl create를 써야 하나요?

아니요, kubectl apply를 쓰는 습관을 들이는 것이 좋아요. apply는 기존 설정과 비교해서 변경된 부분만 반영하는 ‘선언적’ 방식이라 훨씬 안전하고 효율적이에요.

실습 마무리와 더 넓은 세계로의 확장

오늘 우리는 쿠버네티스의 심장부라고 할 수 있는 디플로이먼트를 직접 다뤄봤어요. 매니페스트를 작성하고, 배포하며, 업데이트와 장애 대응까지 해보는 과정이 처음에는 낯설 수 있지만, 이 흐름을 몸에 익히면 인프라 운영의 자신감이 완전히 달라질 거예요.

실습을 마친 여러분이 다음에 도전해 보면 좋을 과제들을 정리해 드릴게요.

• 오늘 할 일: 작성한 YAML 파일의 각 필드 의미를 다시 한번 복기하기
• 이번 주 할 일: 서비스(Service) 객체를 추가하여 외부에서도 접속 가능하게 만들어 보기
• 실행 직전 할 일: Helm을 사용하여 디플로이먼트를 패키징하고 관리하는 방법 공부하기

실습 환경에서 직접 적용해 보시다가 막히는 부분이나 궁금한 점이 생기면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하면 훨씬 빨리 배울 수 있어요!

관련하여 더 깊이 있는 내용이 궁금하다면 아래 글들도 함께 읽어보시길 권장해요.

🔗 쿠버네티스 디플로이먼트 기본 개념 총정리
🔗 클러스터 구축 및 초기 설정 입문 가이드