[IT-방법] 디플로이먼트 설정 방법 완벽 가이드 – 실습 환경 구축과 검증 절차

디플로이먼트 관련 쿠버네티스 구조를 설명하는 대표 이미지

배포 사고를 막는 디플로이먼트 설정의 중요성

새로운 애플리케이션 버전을 배포했는데, 갑자기 서비스 전체가 먹통이 되어 당황했던 적이 있나요? 개발팀에서는 분명히 문제가 없다고 했지만, 실제 운영 환경에 올리자마자 트래픽을 견디지 못하고 파드(Pod)들이 줄지어 죽어가는 상황은 보안 담당자나 운영자에게 가장 큰 악몽이에요. 단순한 실수처럼 보여도 그 이면에는 디플로이먼트 설정 방법이 제대로 정립되지 않은 구조적인 결함이 숨어 있는 경우가 많아요.

잘못된 설정 하나가 서비스 중단은 물론, 리소스 고갈로 인한 보안 위협까지 초래할 수 있어요. 특히 보안 정책을 수립하는 입장에서는 애플리케이션이 어떻게 배포되고, 장애 시 어떻게 복구되는지를 명확히 파악하는 것이 중요해요. 단순히 명령어를 입력하는 수준을 넘어, 시스템의 안정성을 보장하는 설계를 이해해야 하죠.

이 글에서는 실무에서 바로 적용할 수 있는 쿠버네티스 디플로이먼트 환경설정 과정을 단계별로 짚어드려요. 이론적인 설명보다는 실제 환경을 어떻게 구성하고, 어떤 값을 입력해야 사고를 방지할 수 있는지에 집중해요. 무엇을 준비해야 하고, 실제 배포는 어떻게 진행하며, 발생 가능한 오류를 어떻게 해결하는지 상세히 다룰게요.

💡 이 글에서 다루는 내용

  • 실습을 위한 쿠버네티스 로컬 환경 구성법
  • 안정적인 운영을 위한 디플로이먼트 YAML 핵심 구조
  • 무중단 배포를 보장하는 롤링 업데이트 전략
  • 배포 실패 시 즉시 대응할 수 있는 트러블슈팅 기술

안정적인 실습 환경과 사전 준비물

디플로이먼트 설정을 배우기 전에 가장 먼저 결정해야 할 것은 어떤 환경에서 실습할 것인가예요. 클라우드 환경은 설정이 간편하지만 비용이 발생하고, 로컬 환경은 무료지만 내 컴퓨터의 자원을 사용한다는 차이가 있어요. 보안 담당자라면 클라우드와 온프레미스 환경의 차이를 고려해 적절한 선택 기준을 세워야 해요.

실습 환경 선택 기준 비교

구분 로컬 환경 (Minikube/Kind) 클라우드 환경 (EKS/GKE) 권장 대상
비용 무료 사용량에 따른 과금
난이도 중간 (설치 필요) 낮음 (관리형 서비스)
제어 권한 매우 높음 (모든 제어 가능) 제한적 (클라우드 정책 적용)
네트워크 구성 단순 (로컬 네트워크) 복잡 (VPC, Subnet 설정 필요)

개인적인 학습이나 간단한 테스트가 목적이라면 MinikubeKind를 활용한 로컬 환경을 강력하게 추천해요. 내 컴퓨터 안에 작은 쿠버네티스 클러스터를 만드는 방식이라 비용 부담이 전혀 없고, 네트워크나 권한 설정을 마음대로 변경해보며 보안 정책을 실험하기에 아주 좋거든요. 반면, 실제 운영 환경과 가장 유사한 경험을 원한다면 AWS의 EKS 같은 관리형 서비스를 사용하는 것이 맞아요.

필수 도구 및 체크리스트

환경을 결정했다면 다음 도구들이 준비되어 있는지 확인해 보세요. 하나라도 빠지면 실습 과정에서 막히게 돼요.

  • Kubectl: 클러스터에 명령을 내리는 핵심 CLI 도구예요.
  • Container Runtime: Docker나 containerd 같이 컨테이너를 실행할 엔진이 필요해요.
  • YAML 에디터: VS Code 같은 도구에 Kubernetes 확장 프로그램을 설치하면 오타를 방지할 수 있어요.
  • 클러스터 접근 권한: 클러스터의 API 서버에 접속할 수 있는 인증 정보(kubeconfig)가 확보되어야 해요.
⚠️ 주의
로컬 환경에서 실습할 때 메모리 할당량을 너무 적게 잡으면, 디플로이먼트를 생성하는 도중에 클러스터 자체가 멈출 수 있어요. 최소 4GB 이상의 여유 메모리를 확보한 상태에서 시작하세요.

실무 중심의 디플로이먼트 단계별 설정 및 검증

이제 본격적으로 디플로이먼트를 구성해 볼게요. 단순히 명령어를 복사해서 붙여넣는 것이 아니라, 각 설정값이 시스템의 안정성과 보안에 어떤 영향을 미치는지 이해하며 진행하는 것이 중요해요. 총 5단계의 과정을 통해 완벽한 배포 환경을 만들어 봐요.

STEP 1. 실습을 위한 쿠버네티스 환경 준비하기

가장 먼저 로컬 환경에서 테스트할 수 있는 Minikube를 설치한다고 가정해 볼게요. 터미널을 열고 설치 명령어를 입력한 뒤, 클러스터를 실행해야 해요.

minikube start --driver=docker 명령어를 사용하면 Docker를 기반으로 가상 클러스터가 생성돼요. 클러스터가 정상적으로 떴는지 확인하려면 kubectl get nodes를 입력해 보세요. 상태(STATUS)가 Ready로 표시된다면 이제 디플로이먼트를 배포할 준비가 모두 끝난 거예요.

STEP 2. 안정성을 고려한 디플로이먼트 YAML 설계하기

디플로이먼트 설정의 핵심은 YAML 파일이에요. 여기서 정의하는 값들이 곧 우리 서비스의 생존 조건이 돼요. 보안 담당자로서 눈여겨봐야 할 핵심 필드들을 중심으로 구성해 볼게요.

💡 알아두기: 핵심 필드 해설

  • replicas: 실행할 파드의 개수예요. 서비스의 가용성을 결정하죠.
  • selector: 디플로이먼트가 어떤 파드를 관리할지 식별하는 이름표예요.
  • strategy: 배포 방식(RollingUpdate 등)을 결정하는 아주 중요한 부분이에요.
  • resources: 파드가 사용할 CPU와 메모리의 한계를 정해 시스템 전체 붕괴를 막아요.

아래는 실무에서 가장 기본이 되는 디플로이먼트 설정 예시예요. 이 내용을 메모장이나 에디터에 저장해 두세요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.21
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

여기서 resources.limits 설정을 꼭 확인하세요. 만약 특정 파드가 메모리를 무한정 사용하게 두면, 같은 노드에 있는 다른 서비스들까지 모두 중단되는 상황이 발생할 수 있어요. 이는 보안 측면에서도 자원 고갈 공격(DoS)에 취약해지는 결과를 낳아요.

STEP 3. 디플로이먼트 생성 및 상태 모니터링

작성한 파일을 클러스터에 적용해 볼 차례예요. 터미널에서 kubectl apply -f deployment.yaml을 입력하면 쿠버네티스가 즉시 작업을 시작해요. 하지만 명령어를 쳤다고 해서 바로 배포가 완료된 건 아니에요.

배포 과정을 눈으로 직접 확인하는 습나다. kubectl get deployments를 입력해 생성된 디플로이먼트를 확인하고, kubectl get pods를 통해 파드들이 하나씩 생성되는지 지켜보세요. 파드의 상태가 ContainerCreating에서 Running으로 변하는 과정을 보는 것이 중요해요. 만약 상태가 계속 Pending에 머물러 있다면, 클러스터에 리소스를 할당할 공간이 부족하다는 뜻이니 노드 상태를 다시 점검해야 해요.

STEP 4. 무중단 배포를 위한 롤링 업데이트 실습

운영 중인 서비스의 코드를 수정해야 할 때, 서비스를 끄지 않고 업데이트하는 방법이 바로 롤링 업데이트(Rolling Update)예요. 앞서 작성한 YAML에서 이미지를 nginx:1.23으로 변경했다고 가정해 볼게요.

수정된 파일을 다시 kubectl apply로 적용하면, 쿠버네티스는 기존 파드를 하나씩 죽이면서 새로운 버전의 파드를 하나씩 생성해요. 이때 maxSurgemaxUnavailable 설정값이 핵심 역할을 수행해요. maxSurge: 1은 업데이트 중에 원래 개수보다 최대 1개의 파드를 더 만들 수 있다는 뜻이고, maxUnavailable: 1은 업데이트 중에도 최소한 원래 개수에서 1개를 뺀 만큼의 파드는 항상 유지되어야 한다는 의미예요. 이 설정 덕분에 사용자는 배포 중에도 끊김 없는 서비스를 경험할 수 있어요.

STEP 5. 헬스 체크(Probe) 설정을 통한 자동 복구 구현

마지막 단계는 가장 강력한 안정성 장치인 프로브(Probe) 설정이에요. 파드가 생성은 되었지만, 내부 애플리케이션이 아직 준비되지 않아 요청을 처리하지 못하는 경우가 있거든요. 이를 방지하기 위해 livenessProbereadinessProbe를 반드시 설정해야 해요.

readinessProbe는 파드가 트래픽을 받을 준비가 되었는지 확인해요. 이 체크를 통과하지 못한 파드는 서비스 엔드포인트에서 제외되어 사용자에게 에러를 노출하지 않아요. livenessProbe는 파드가 살아있는지 주기적으로 확인해요. 만약 애플리케이션이 교착 상태(Deadlock)에 빠져 응답이 없다면, 쿠버네티스가 알아서 해당 파드를 죽이고 새로 살려내죠. 이 자동 복구 메커니즘이야말로 운영자의 개입을 최소화하는 핵심 기술이에요.

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

디플로이먼트를 설정하다 보면 누구나 한 번쯤은 예상치 못한 벽에 부딪히게 돼요. 실무에서 가장 빈번하게 발생하는 오류 패턴들을 정리했으니, 문제가 생기면 바로 대조해 보세요.

자주 하는 실수와 해결법

ImagePullBackOff 발생
왜 발생하는가: 설정한 컨테이너 이미지가 저장소(Registry)에 없거나, 접근 권한(ImagePullSecret)이 없어서 이미지를 가져오지 못할 때 발생해요.
✅ 해결법: 이미지 이름과 태그가 정확한지 확인하고, Private 저장소를 사용한다면 인증 정보가 제대로 설정되었는지 점검하세요.

CrashLoopBackOff 발생
왜 발생하는가: 컨테이너는 실행되었지만, 애플리케이션 내부 로직 오류나 환경 변수 누락으로 인해 즉시 종료될 때 반복적으로 나타나요.
✅ 해결법: kubectl logs [파드명] 명령어로 애플리케이션 로그를 확인하여 에러 메시지를 찾아내야 해요.

Selector와 Label 불일치
왜 발생하는가: 디플로이먼트의 spec.selector.matchLabels에 적은 이름과 파드 템플릿의 metadata.labels에 적은 이름이 다를 때 발생해요. 이 경우 디플로이먼트가 자기가 만든 파드를 찾지 못하는 미아가 되어버려요.
✅ 해결법: 두 레이블 값이 글자 하나 틀리지 않고 일치하는지 반드시 재확인하세요.

리소스 부족으로 인한 Pending 상태
왜 발생하는가: 요청한 CPU나 메모리 양이 클러스터 노드의 남은 용량보다 클 때 파드가 생성되지 못하고 대기해요.
✅ 해결법: kubectl describe node로 노드 여유 공간을 확인하고, YAML의 resources.requests 값을 현실적으로 조정하세요.

무한 재시작 루프(Liveness Probe 실패)
왜 발생하는가: 헬스 체크 경로를 잘못 설정했거나, 체크 주기가 너무 짧아 애플리케이션이 응답하기 전에 다시 체크를 시도할 때 발생해요.
✅ 해결법: 프로브의 initialDelaySeconds를 늘려 애플리케이션이 완전히 뜰 시간을 충분히 확보해 주세요.

자주 묻는 질문

Q. 배포를 했는데 문제가 생겼어요. 이전 버전으로 어떻게 되돌리나요?

kubectl rollout undo deployment/[디플로이먼트명] 명령어를 사용하면 아주 간단하게 직전 버전으로 롤백할 수 있어요. 긴급 상황에서 가장 먼저 기억해야 할 명령어예요.

Q. ReplicaSet과 Deployment의 차이가 무엇인가요?

ReplicaSet은 파드의 개수를 유지하는 데 집중하지만, Deployment는 ReplicaSet을 관리하는 상위 개념이에요. 우리가 배포 전략을 수정하거나 롤백을 할 수 있는 이유는 바로 Deployment가 관리해주기 때문이에요.

Q. 파드의 개수를 실시간으로 늘리고 싶을 때는 어떻게 하나요?

kubectl scale deployment/[디플로이먼트명] --replicas=5 명령어를 입력하면 즉시 파드 개수를 5개로 늘릴 수 있어요. 트래픽 급증 시 유용하죠.

Q. 보안 담당자로서 디플로이먼트에서 가장 중요하게 봐야 할 점은 무엇인가요?
가장 중요한 것은 resources.limits 설정과 SecurityContext예요. 리소스 제한을 통해 자원 독점을 막고, 컨테이너가 루트 권한으로 실행되지 않도록 제한하는 것이 보안의 기초예요.

성공적인 운영을 위한 마무리 가이드

지금까지 쿠버네티스 디플로이먼트 설정 방법의 기초부터 실무 적용, 그리고 문제 해결까지 모두 살펴보았어요. 처음에는 YAML 파일의 수많은 필드가 낯설게 느껴지겠지만, 하나씩 직접 입력하고 배포하며 그 영향을 확인하다 보면 자연스럽게 익숙해질 거예요. 안정적인 시스템 운영은 완벽한 도구가 아니라, 세밀한 설정과 철저한 검증에서 시작된다는 점을 잊지 마세요.

✅ 핵심 요약

  • 로컬 실습 환경(Minikube/Kind)을 구축하여 비용 없이 연습하세요.
  • YAML 작성 시 resources.limits를 설정해 자원 고갈을 방지하세요.
  • 무중단 배포를 위해 RollingUpdate 전략을 적극 활용하세요.
  • Liveness/Readiness Probe로 서비스의 자가 치유 능력을 높이세요.
  • 장애 시에는 rollout undo로 즉시 복구할 준비를 하세요.
  • 로그 확인(kubectl logs)과 이벤트 확인(kubectl describe)은 기본 중의 기본이에요.

오늘 배운 내용을 바탕으로 지금 바로 작은 웹 서버 하나를 디플로이먼트로 배포해 보는 건 어떨까요? 직접 부딪히며 겪는 오류들이 여러분을 진짜 전문가로 만들어줄 거예요. 실습 중에 막히는 부분이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민해 드릴게요.

🚀 다음 단계로 나아가기

  • 오늘 할 일: Minikube 설치하고 첫 번째 Nginx 디플로이먼트 배포하기
  • 이번 주 할 일: 롤링 업데이트를 직접 수행하며 서비스 끊김 없는지 확인하기
  • 실행 직전 할 일: 리소스 제한(Limits)이 설정된 YAML 파일 미리 준비하기

함께 읽으면 좋은 글: 쿠버네티스 디플로이먼트 기본 개념 가이드, 클러스터 구축 및 초기 설정 입문

댓글 남기기