Cloud & DevOps

개발자가 알아야 할 Kubernetes 기초

한 줄 요약: Kubernetes는 컨테이너 오케스트레이션 표준으로, Pod/Service/Deployment의 3가지 핵심 개념과 kubectl 기본 명령만 알면 시작할 수 있다. Docker로 컨테이너를 만들었다면, 여러 컨테이너를 자동으로 배포, 스케일링, 복구하는 것은 Kubernetes의 역할이다. Docker가 컨테이너를 만든다면, Kubernetes는 수백 개의 컨테이너를 관리 합니다.

by Lee발행: 2026-04-07

한 줄 요약: Kubernetes는 컨테이너 오케스트레이션 표준으로, Pod/Service/Deployment의 3가지 핵심 개념과 kubectl 기본 명령만 알면 시작할 수 있다.

Docker로 컨테이너를 만들었다면, 여러 컨테이너를 자동으로 배포, 스케일링, 복구하는 것은 Kubernetes의 역할이다. 이 가이드는 K8s의 핵심 개념과 개발자가 알아야 할 실전 패턴을 정리한다.

K8s가 해결하는 문제

Docker가 컨테이너를 만든다면, Kubernetes는 수백 개의 컨테이너를 관리합니다. 자동 스케일링, 롤링 업데이트, 자가 치유, 로드 밸런싱을 제공합니다.

Pod은 K8s의 최소 배포 단위로, 하나 이상의 컨테이너를 포함한다. 대부분의 경우 Pod 하나에 컨테이너 하나를 넣는다. Service는 Pod들에 대한 안정적인 네트워크 접근점(IP/DNS)을 제공한다. Pod은 수시로 생성/삭제되지만 Service는 유지된다. Deployment는 Pod의 원하는 상태(replicas 수, 이미지 버전 등)를 선언하고, K8s가 이를 유지한다.

Deployment + Service YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels: { app: my-app }
  template:
    metadata:
      labels: { app: my-app }
    spec:
      containers:
      - name: app
        image: my-app:1.0
        ports: [{ containerPort: 3000 }]
        resources:
          requests: { memory: 128Mi, cpu: 100m }
          limits: { memory: 256Mi, cpu: 200m }
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
spec:
  selector: { app: my-app }
  ports: [{ port: 80, targetPort: 3000 }]

핵심 개념 5가지

Pod: 가장 작은 배포 단위 (컨테이너 1개 이상)
Deployment: Pod의 원하는 상태 선언
Service: Pod에 접근하는 네트워크 엔드포인트
Ingress: 외부 트래픽을 서비스로 라우팅
ConfigMap/Secret: 설정과 비밀 관리

필수 kubectl 명령어

개발자가 매일 쓰는 kubectl 명령: kubectl get pods(Pod 상태 확인), kubectl logs -f pod-name(로그 실시간 확인), kubectl describe pod pod-name(상세 이벤트), kubectl exec -it pod-name -- sh(컨테이너 접속), kubectl apply -f manifest.yaml(배포/업데이트).

로컬 개발에서는 minikube나 Docker Desktop의 K8s를 사용하면 노트북에서 클러스터를 실행할 수 있다. 프로덕션에서는 AWS EKS, Google GKE, Azure AKS 같은 관리형 서비스를 사용하는 것이 운영 부담을 줄인다.

실전 팁: 처음부터 K8s가 필요하지 않다. 트래픽이 적은 초기 서비스는 Docker Compose + 단일 서버로 충분하다. K8s는 여러 서비스를 독립적으로 배포/스케일해야 할 때 도입하라.

1인 개발자 관점에서 이 주제가 왜 중요한가

이 글의 주제(개발자가 알아야 할 Kubernetes 기초)를 다룰 때 저는 버셀 + 깃허브 액션으로 자동 배포를 운영하는 입장 관점에서 봅니다. 단순히 새 기능을 소개하는 입장이 아니라, 12개 한국어 사이트를 1인으로 운영하면서 매일 클로드 코드를 켜두고 작업하는 입장이라 의사결정의 기준이 다소 좁고 실용적인 편입니다. 신기술이 출시될 때마다 곧바로 도입하기보다는 우선 한두 사이트에 시범 도입해 두고, 운영 부담이 늘지 않는지 며칠 지켜본 뒤 전체 확산을 결정하는 식입니다.

가장 자주 보는 변수는 버셀 무료 티어 한도 vs 유료 전환 시점, 그리고 1인 개발자의 현금흐름 한계입니다. 두 변수는 신기술을 도입할지 말지 결정할 때 거의 매번 영향을 줍니다. 글의 본문은 위의 두 축을 직접 명시하지는 않지만, 본문에서 다루는 항목을 이 축에 비춰 보시면 본인 환경에 맞는지 빠르게 판단할 수 있습니다. 특히 한국어 응답 품질의 미세한 한계 같은 운영 변수는 도구 자체 성능보다 더 큰 영향을 주는 경우가 많기 때문에 본문 비교표를 볼 때 같이 떠올리시면 좋습니다.

한 가지 더 강조하면, Cloud & DevOps 영역의 글을 읽을 때 저는 본문이 다루는 도구·서비스가 ① 한국 결제 가능 여부 ② 한국어 응답 품질 ③ 종량제 비용의 예측 가능성 ④ 1인 개발자 학습 시간 대비 효과, 네 항목을 모두 충족해야 실제 도입을 결정합니다. 네 항목 중 하나라도 명확하지 않으면 도입을 1~2주 미루는 편이고, 그 사이 같은 카테고리의 다른 글도 확인합니다.

본문의 각 비교·코드·체크리스트는 이 네 항목 중 어느 부분에 영향을 주는지 의식하면서 보시면 더 빠르게 결론에 도달하실 수 있습니다. 본 사이트의 다른 Cloud & DevOps 글과 함께 보시면 같은 평가 축이 반복되는 것을 확인하실 수 있습니다. 토픽 페이지 또는 같은 카테고리 태그를 따라가시면 동일한 평가 기준이 적용된 글을 한 번에 모아 보실 수 있습니다.

본인 환경에 적용하기 전 확인할 체크포인트

본문의 내용을 본인 환경에 적용하기 전에 다음 항목을 빠르게 확인하시면 도입 실패 가능성을 줄일 수 있습니다.

공식 문서 버전 일치 — 본문 작성 시점과 현재 배포 버전이 다른 경우, 같은 명령어가 다르게 동작할 수 있습니다.
한국 결제·환율 검증 — 카드 결제, 부가가치세 처리, 원화 환산 시점에 따라 실제 청구액이 본문 예시와 다를 수 있습니다.
기존 스택과의 호환성 — Next.js·Vercel·Supabase 같은 기본 스택과 충돌이 없는지 패키지 의존성을 먼저 확인하세요.
롤백 절차 사전 정리 — 도입 후 문제가 생겼을 때 1회 명령으로 이전 상태로 되돌릴 수 있는 절차를 도입 전에 메모해 두시면 운영 부담이 크게 줄어듭니다.

위 네 항목을 모두 통과하면 보통 1~2시간 내에 도입을 마칠 수 있고, 통과하지 못한 항목이 있다면 그 항목을 우선 해결한 뒤 다시 시작하는 것이 효율적입니다.

자주 묻는 질문

더 깊게 공부하려면 어떤 자료를 보면 좋을까요?

손으로 익히는 게 먼저입니다. 노트북에 minikube나 Docker Desktop 내장 K8s를 켜고, Kubernetes 공식 문서(kubernetes.io/docs)의 'Kubernetes Basics' 인터랙티브 튜토리얼로 Pod·Service·Deployment를 직접 배포해 보시길 권합니다. 그다음 kubectl 치트시트 문서로 get·logs·describe·apply 명령을 손에 붙이세요. 개념이 잡히면 ConfigMap·Secret으로 설정을 분리하고, Ingress로 외부 트래픽을 라우팅하는 항목으로 넓히면 됩니다. 검색 키워드는 'Kubernetes resource requests limits', 'kubectl describe pod', 'Ingress controller', 'Helm chart'가 유용하고, 운영은 EKS·GKE·AKS 각 공식 가이드를 참고하시면 됩니다.

개발자가 알아야 할 Kubernetes 기초, 한 줄로 정리하면 어떻게 되나요?

Kubernetes는 여러 컨테이너를 자동으로 배포·스케일링·복구하는 오케스트레이션 표준으로, Pod(최소 배포 단위), Service(안정적 네트워크 접근점), Deployment(원하는 상태 선언) 세 개념과 kubectl 기본 명령만 알면 시작할 수 있습니다. Deployment에 requests·limits를 반드시 명시하고, Pod의 변하는 IP 대신 Service로 접근하는 것이 안전의 핵심입니다. 다만 처음부터 필요한 기술은 아니어서, 트래픽이 적으면 Docker Compose로 시작하고 여러 서비스를 독립 운영해야 할 때 도입하는 게 맞습니다.

실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?

가장 먼저 확인할 것은 의외로 기술이 아니라 도입 시점입니다. 본문 callout에도 적었지만, 트래픽이 적은 초기 서비스라면 Kubernetes는 아직 필요 없고 Docker Compose에 단일 서버면 충분합니다. K8s는 여러 서비스를 독립적으로 배포하고 각각 따로 스케일해야 할 때 비로소 값을 합니다. 도입을 정했다면 운영용 클러스터를 직접 세우지 말고 AWS EKS, Google GKE, Azure AKS 같은 관리형부터 시작하시길 권합니다. 컨트롤 플레인을 직접 운영하는 부담이 1인 개발자에게는 상당하기 때문입니다. 학습은 노트북에서 minikube나 Docker Desktop 내장 K8s로 Pod, Service, Deployment 세 개념을 손에 익힌 뒤 옮기는 순서가 안전합니다.

가장 자주 발생하는 실수나 함정은 무엇인가요?

가장 큰 함정은 필요하지도 않은데 K8s부터 깔고 보는 것입니다. 단일 앱 하나를 굴리는데 클러스터를 세우면 얻는 것보다 운영 부담이 훨씬 큽니다. 기술적으로 자주 막히는 지점은 Deployment의 resources 설정인데, requests와 limits에 메모리/CPU를 명시하지 않으면 Pod 하나가 노드 자원을 다 먹어 다른 Pod가 쫓겨나는 OOMKilled가 납니다. 본문 YAML처럼 requests와 limits를 반드시 지정하셔야 합니다. 또 Pod에 직접 접속해 디버깅할 때 Pod는 수시로 재생성되므로 그 IP를 신뢰하면 안 되고, 안정적인 접근점은 항상 Service를 통해야 합니다. Pod의 상태가 이상하면 kubectl describe pod로 이벤트 로그부터 보시는 습관이 트러블슈팅 시간을 크게 줄여줍니다.

다른 대안과 비교했을 때 어떤 상황에 적합한가요?

Kubernetes는 여러 서비스를 독립적으로 배포·스케일하고, 장애 시 자가 치유와 롤링 업데이트가 필요한 규모에서 값을 합니다. 마이크로서비스가 여러 개로 쪼개져 있고 트래픽에 따라 자동 스케일링이 필요하며 팀이 표준화된 배포 체계를 원한다면 K8s가 적합합니다. 반대로 단일 앱이거나 트래픽이 적은 초기 서비스라면 Docker Compose에 단일 서버, 또는 버셀·Railway·Fly.io 같은 관리형 PaaS가 운영 부담이 훨씬 작아 더 낫습니다. 컨트롤 플레인을 직접 굴리는 비용이 1인 개발자에게는 크기 때문에, K8s를 쓰기로 했더라도 자체 구축 대신 AWS EKS·Google GKE·Azure AKS 같은 관리형부터 시작하는 편이 맞습니다. 한마디로 서비스가 여러 개로 늘고 무중단·자동 복구가 절실해지는 시점이 K8s 도입 신호입니다.

kubernetesk8s컨테이너오케스트레이션배포