왜 이 둘을 같이 이야기할까

Docker와 Kubernetes는 늘 세트처럼 언급되지만, 사실 하는 일이 완전히 다르다.
Docker는 컨테이너를 "만들고 실행하는" 도구고, Kubernetes는 그 컨테이너들을 "여러 대의 서버에 걸쳐 관리하는" 도구다.
인프라 관점에서 보면 이 둘은 "포장"과 "물류"의 관계에 가깝다.
Docker — 애플리케이션을 상자에 포장하기
문제 상황: "제 컴퓨터에서는 됐는데요?"

개발자가 자기 컴퓨터에서는 잘 돌아가던 프로그램이, 서버에 올리면 안 되는 경우가 흔하다. 이유는 다양하다. 서버의 Python 버전이 다르거나, 특정 라이브러리가 안 깔려 있거나, 설정 파일 경로가 다르거나. 결국 "실행 환경"이 서로 다른 게 문제다.
Docker의 해결 방식

Docker는 애플리케이션과 그걸 돌리는 데 필요한 모든 것(코드, 라이브러리, 설정, 실행 환경)을 이미지(Image)라는 하나의 상자에 통째로 포장해버린다. 이 상자를 어느 서버로 옮기든, 안에 필요한 게 다 들어있으니 "제 컴퓨터에서는 됐는데요" 문제가 사라진다.
이 이미지를 실제로 실행한 상태를 컨테이너(Container)라고 부른다.
이미지가 설계도라면, 컨테이너는 그 설계도로 실제로 돌아가고 있는 프로세스인 셈이다.
인프라 관점에서 Docker가 바꾼 것

예전에는 서버 하나에 애플리케이션을 배포하려면, 그 서버에 직접 접속해서 필요한 프로그램들을 하나하나 설치하고 설정해야 했다. Docker를 쓰면 "이미지 하나 내려받아서 실행"만 하면 끝난다.
서버가 물리 서버든, 클라우드의 가상 서버든 상관없이 똑같은 방식으로 배포할 수 있다는 점에서, Docker는 "온프레미스와 클라우드를 가리지 않는 표준 배포 단위"를 만들어준 셈이다. 앞서 다룬 벤더 락인 완화 전략 중 하나로 컨테이너 기술이 언급되는 이유가 바로 여기 있다.
Kubernetes — 컨테이너를 관리하는 오케스트라 지휘자
Docker만으로는 부족한 이유

컨테이너 하나를 서버 한 대에서 돌리는 건 Docker만으로 충분하다. 그런데 실제 서비스는 다르다. 트래픽이 몰리면 컨테이너를 여러 개 더 띄워야 하고, 서버 한 대가 죽으면 다른 서버에서 대신 컨테이너를 살려야 하고, 수십 개의 컨테이너가 서로 통신할 수 있도록 네트워크도 관리해야 한다. 이걸 사람이 손으로 다 챙기기는 불가능하다.
Kubernetes가 하는 일

Kubernetes(줄여서 K8s)는 여러 대의 서버(클러스터)에 걸쳐 수많은 컨테이너를 자동으로 배치하고, 감시하고, 필요하면 되살리는 오케스트레이션 도구다.
- 자동 배치: "이 컨테이너 10개를 띄워줘"라고 하면, Kubernetes가 클러스터 안의 여러 서버 중 자원이 남는 곳을 골라 알아서 나눠 배치한다.
- 자가 치유(Self-healing): 컨테이너 하나가 갑자기 죽으면, Kubernetes가 이를 감지하고 자동으로 새 컨테이너를 다시 띄워 원래 상태로 되돌린다.
- 오토스케일링: 트래픽이 늘어나면 컨테이너 수를 자동으로 늘리고, 트래픽이 줄면 다시 줄인다. 앞서 다룬 Scale-out을 컨테이너 단위로 자동화한 것이라고 보면 된다.
- 로드밸런싱: 여러 컨테이너에 요청을 고르게 분산해준다.
클러스터 구조를 인프라 관점에서 보면

Kubernetes 클러스터는 크게 두 종류의 서버로 나뉜다. 클러스터 전체를 지휘하는 컨트롤 플레인(Control Plane)과, 실제로 컨테이너가 돌아가는 워커 노드(Worker Node)다.
여기서 워커 노드는 대부분 AWS EC2 같은 VM으로 만들어지고, 그 VM 안에서 여러 개의 컨테이너(Kubernetes 용어로는 Pod)가 실행된다. 즉 앞서 다룬 "VM 위에 컨테이너를 올리는 이중 구조"가 바로 Kubernetes 클러스터의 실제 모습이다.
클라우드는 왜 이 둘을 반긴다

클라우드 업체 입장에서 Docker와 Kubernetes는 궁합이 아주 좋다. Kubernetes가 알아서 트래픽에 맞춰 컨테이너 수를 늘리고 줄이면, 그 밑에서 VM(워커 노드) 자체도 오토스케일링으로 함께 늘고 줄일 수 있다.
그래서 AWS(EKS), Google Cloud(GKE), Azure(AKS) 같은 클라우드 업체들은 전부 Kubernetes를 관리형 서비스로 제공하며, 사용자는 복잡한 클러스터 구축 과정 없이 바로 컨테이너를 올릴 수 있게 됐다.
정리

Docker는 애플리케이션을 어디서든 똑같이 돌아가게 포장하는 도구고, Kubernetes는 그렇게 포장된 컨테이너 수백, 수천 개를 여러 서버에 걸쳐 자동으로 배치하고 관리하는 도구다.
인프라 관점에서 보면 둘의 조합은 "표준화된 배포 단위(Docker)"와 "그걸 자동으로 운영하는 관제탑(Kubernetes)"의 결합이며, 이 조합 덕분에 클라우드 환경에서 서비스를 확장하고 장애에 대응하는 과정이 크게 자동화될 수 있었다.
'Cloud, IT Infra > Docker & Kubernetes' 카테고리의 다른 글
| 운영비용 관점에서 본 docker의 Container (0) | 2026.07.14 |
|---|---|
| 하이퍼바이저, 그리고 VM vs 컨테이너 (0) | 2026.07.13 |
| Kubernetes 실습 (1) | 2025.12.30 |
| Docker 실습 (0) | 2025.12.30 |
| Docker란? (0) | 2025.11.07 |