🐳 쿠버네티스(Kubernetes) 장단점 완벽 정리 — 도입 전 반드시 알아야 할 것들

쿠버네티스, 왜 이렇게 핫한 거야?

요즘 백엔드 개발자라면 쿠버네티스(Kubernetes, 줄여서 k8s) 한 번쯤은 들어봤을 거예요. 근데 막상 “그래서 이게 뭐가 좋은데?” 하면 명확하게 대답하기 어려운 사람도 꽤 많더라고요. 저도 처음엔 그랬어요.

그래서 이번에 쿠버네티스의 장단점을 실무 관점에서 제대로 정리해봤어요. 도입을 고민하고 있는 분들이라면 끝까지 읽어보시면 도움이 될 거예요.

쿠버네티스 장점 — 쓰면 진짜 편한 것들

1. 자동 스케일링 (Auto Scaling)

트래픽이 갑자기 몰리면? 쿠버네티스가 알아서 Pod(컨테이너)를 늘려줘요. 트래픽 빠지면 다시 줄이고요. HPA(Horizontal Pod Autoscaler)를 설정해두면 CPU나 메모리 사용량 기준으로 자동으로 스케일 인/아웃을 해줘요.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

이거 한번 설정해두면 새벽에 서버 터질까봐 노심초사할 일이 확 줄어요.

2. 셀프힐링 (Self-Healing)

컨테이너가 죽으면? 쿠버네티스가 알아서 다시 살려요. 노드가 통째로 날아가도 다른 노드에서 자동으로 Pod를 띄워줘요. 예전에 서버 하나 죽으면 새벽에 전화받고 달려가던 시절 생각하면 눈물이 나요.

liveness probe, readiness probe 설정해두면 “이 컨테이너 살아있긴 한데 제대로 동작 안 하는” 상황까지 잡아내요.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

3. 서비스 디스커버리 & 로드밸런싱

마이크로서비스 아키텍처에서 제일 골치 아픈 게 “저 서비스 IP가 뭐지?”인데, 쿠버네티스는 서비스 이름만으로 통신이 가능해요. DNS 기반으로 알아서 찾아줘요. 로드밸런싱도 기본 내장이고요.

# Pod 안에서 다른 서비스 호출할 때
curl http://user-service.default.svc.cluster.local:8080/api/users

IP 하드코딩하던 시절은 이제 안녕이에요.

4. 롤링 업데이트 & 롤백

배포할 때 무중단으로 하나씩 교체해주는 롤링 업데이트가 기본이에요. 배포했는데 문제가 생기면? 한 줄이면 이전 버전으로 롤백돼요.

# 롤백은 이거 한 줄이면 끝
kubectl rollout undo deployment/my-app

배포 때마다 식은땀 흘리던 게 거짓말처럼 편해져요.

5. 멀티클라우드 & 하이브리드

AWS에서 GCP로 옮기고 싶다? 쿠버네티스 쓰면 비교적 수월해요. 인프라를 추상화해주니까 특정 클라우드에 종속되는 걸 어느 정도 피할 수 있어요. 온프레미스 + 클라우드 조합도 가능하고요.

6. 선언적 설정 관리

YAML 파일로 “나는 이런 상태를 원해”라고 선언하면, 쿠버네티스가 그 상태를 맞춰줘요. 인프라를 코드로 관리(IaC)할 수 있으니까 Git으로 버전 관리도 되고, 코드 리뷰도 가능해요.

쿠버네티스 단점 — 솔직히 힘든 것들

1. 학습 곡선이 미친 듯이 가파름

솔직히 이게 제일 큰 단점이에요. Pod, Service, Deployment, Ingress, ConfigMap, Secret, PV, PVC, StatefulSet… 개념이 끝도 없이 나와요. Docker도 모르면 거기서부터 시작해야 하고요.

팀원 전체가 쿠버네티스를 이해하는 데까지 최소 몇 달은 잡아야 해요. 그 동안 생산성이 확 떨어지는 건 감수해야 해요.

2. 리소스 오버헤드가 생각보다 큼

쿠버네티스 자체가 먹는 리소스가 꽤 돼요. etcd, API Server, Controller Manager, Scheduler, kube-proxy… 컨트롤 플레인만 해도 CPU/메모리를 잡아먹어요. 작은 서비스 하나 띄우려고 클러스터 구축하면 배보다 배꼽이 더 큰 상황이 벌어져요.

3. 네트워킹이 복잡함

쿠버네티스 네트워킹은 진짜 한 세계예요. CNI 플러그인 선택부터 시작해서, Service mesh(Istio 같은 거), Ingress Controller, NetworkPolicy까지… 네트워크 이슈 디버깅할 때 머리가 하얘질 수 있어요.

“Pod끼리 통신이 안 돼요” 이 한 줄 에러 잡으려고 반나절 날린 적도 있어요.

4. 소규모 프로젝트에는 과도함

사용자 100명짜리 서비스에 쿠버네티스? 솔직히 닭 잡는 데 소 잡는 칼 쓰는 거예요. Docker Compose로 충분한 규모인데 “요즘 트렌드니까” 하고 도입하면 운영 비용만 늘어나요.

5. YAML 지옥

쿠버네티스 설정은 전부 YAML이에요. 서비스 하나 배포하려면 Deployment, Service, Ingress, ConfigMap 등등 YAML을 4~5개씩 작성해야 해요. 들여쓰기 하나 잘못하면 에러 나고요. Helm이나 Kustomize로 관리할 수 있긴 한데, 그것도 또 배워야 해요.

6. 모니터링/로깅 별도 구축 필요

쿠버네티스 자체는 모니터링 도구를 안 줘요. Prometheus + Grafana 조합이나 ELK 스택을 직접 구축해야 해요. 이것만 해도 일이 하나 더 늘어나는 거예요.

그래서 도입해야 해? 말아야 해?

결론부터 말하면, “규모와 상황에 따라 다르다”예요. 뻔한 답이긴 한데, 진짜 그래요.

도입하면 좋은 경우:

• 마이크로서비스가 10개 이상이거나 계속 늘어날 예정
• 트래픽 변동이 크고 자동 스케일링이 필요한 경우
• 무중단 배포, 롤백이 빈번한 경우
• 팀에 DevOps/인프라 엔지니어가 있는 경우

굳이 안 써도 되는 경우:

• 모놀리식 서비스 1~2개만 운영 중
• 팀 규모가 작고 인프라 전담자가 없음
• 트래픽이 예측 가능하고 안정적
• Docker Compose나 ECS로 충분히 커버 가능

쿠버네티스는 강력한 도구지만, 모든 상황에 정답은 아니에요. 본인 팀과 서비스 규모에 맞게 판단하는 게 제일 중요해요. 일단 Docker부터 확실히 익히고, 필요성을 느낄 때 도입해도 늦지 않아요!