클라우드, Docker, Kubernetes는 뭐가 다를까

#클라우드#Docker#Kubernetes#인프라

클라우드, Docker, Kubernetes는 뭐가 다를까

클라우드, Docker, Kubernetes는 배포나 서버, 컨테이너 관련 내용을 공부하다 보면 자주 함께 등장합니다.
그래서 처음에는 세 기술이 비슷한 역할을 하는 것처럼 느껴지기도 합니다.

하지만 정리해보면 이 셋은 서로 연결되어 있으면서도, 해결하려는 문제는 분명히 다릅니다.

  • 클라우드는 인프라를 빌려 쓰는 방식
  • Docker는 애플리케이션 실행 환경을 이미지로 묶고 컨테이너로 실행하는 도구
  • Kubernetes는 그렇게 만들어진 컨테이너를 여러 서버에서 운영하는 플랫폼 환경

즉, 세 기술은 같은 계층의 개념이 아니라, 서로 다른 문제를 담당하는 기술이라고 볼 수 있습니다.

이번 글에서는 이 세 가지를 한 번에 섞어서 이해하기보다, 각각이 어떤 문제를 해결하는지 기준으로 정리해보았습니다.

클라우드는 무엇일까

클라우드는 흔히 “인터넷 어딘가에 있는 서버” 정도로 이해되곤 합니다.
완전히 틀린 설명은 아니지만, 핵심은 서버의 위치보다 필요한 자원을 빌려 쓰고, 사용량에 따라 비용을 지불하며, 운영을 서비스 형태로 제공받는 방식에 있습니다.

예전에는 서비스를 운영하려면 직접 서버를 준비하고, 네트워크를 구성하고, 저장소와 장애 대응까지 함께 관리해야 했습니다.
반면 클라우드 환경에서는 이러한 자원을 필요할 때 생성하고, 필요하지 않을 때 줄일 수 있습니다.
이 때문에 초기 구축 부담이 줄어들고, 상황에 따라 유연하게 확장할 수 있습니다.

클라우드는 보통 다음과 같이 나뉩니다.

  • IaaS: 서버, 네트워크, 스토리지 같은 인프라를 제공합니다.
  • PaaS: 애플리케이션 실행 환경까지 관리형으로 제공합니다.
  • SaaS: 사용자는 소프트웨어만 이용하는 형태입니다.

즉, 클라우드는 애플리케이션을 어디에서 운영할 것인가에 데한 문제를 해결합니다.

Docker는 무엇을 해결할까

Docker는 애플리케이션과 실행 환경을 함께 묶어, 어디서든 비슷한 방식으로 실행할 수 있게 해주는 도구입니다.

개발을 하다 보면 내 컴퓨터에서는 잘 동작하지만 서버에서는 동작하지 않는 경우가 있습니다.
라이브러리 버전이 다르거나, 런타임 환경이 다르거나, OS 차이 때문에 실행 결과가 달라질 수 있기 때문입니다.

Docker는 이런 문제를 줄이기 위해, 실행에 필요한 요소를 이미지로 만들고 이를 컨테이너로 실행합니다.
덕분에 개발 환경과 운영 환경의 차이를 줄이고, 동일한 애플리케이션을 더 일관된 방식으로 실행할 수 있습니다.

즉, Docker는 애플리케이션 실행 환경을 표준화하는 도구라고 볼 수 있습니다.

레이어, 이미지, 컨테이너는 어떻게 다를까

Docker를 이해할 때 가장 자주 등장하는 개념이 레이어, 이미지, 컨테이너입니다.

  • 레이어: 파일 시스템 변경분의 스냅샷입니다.
  • 이미지: 레이어를 쌓아 만든 실행 패키지입니다.
  • 컨테이너: 이미지를 실제로 실행한 프로세스입니다.

예를 들어 Dockerfile에서 COPY, RUN, ADD 같은 명령을 실행하면 그 결과가 레이어처럼 쌓입니다.
이 구조 덕분에 바뀌지 않은 단계는 캐시를 재사용할 수 있어 빌드가 빨라집니다.

이미지는 이렇게 쌓인 레이어를 기반으로 만들어진 실행 묶음이고, 컨테이너는 그 이미지를 실제로 실행한 상태라고 이해하면 됩니다.

왜 컨테이너는 일회용이라고 할까

컨테이너는 실행 중 파일을 만들거나 수정할 수 있지만, 그 변경은 기본적으로 컨테이너의 writable layer에 저장됩니다.
따라서 컨테이너를 삭제하면 그 안의 변경 사항도 함께 사라질 수 있습니다.

반면 이미지는 바뀌지 않습니다.
그래서 보통 이미지는 그대로 두고, 컨테이너는 필요하면 삭제하고 다시 만드는 방식으로 운영합니다.

중요한 데이터는 컨테이너 안에만 두지 않고, 일반적으로 volume, 외부 스토리지, 데이터베이스 등에 저장합니다.

즉, 컨테이너는 영구 보관 대상이라기보다 쉽게 교체할 수 있는 실행 단위에 가깝습니다.

Dockerfile은 왜 필요할까

Dockerfile은 이미지를 만들기 위한 설계도입니다.
어떤 베이스 이미지를 사용할지, 어떤 파일을 복사할지, 어떤 명령을 실행할지, 컨테이너가 시작될 때 무엇을 실행할지를 적어두는 파일입니다.

예를 들면 다음과 같습니다.

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/server.js"]

여기서 각 명령은 다음 의미를 가집니다.

  • FROM: 어떤 이미지를 기반으로 시작할지 지정합니다.
  • COPY: 파일을 이미지 안으로 복사합니다.
  • RUN: 빌드 중 명령을 실행합니다.
  • CMD: 컨테이너 시작 시 실행할 기본 명령을 지정합니다.

즉, Dockerfile은 실행 환경을 코드로 기록하는 파일이라고 볼 수 있습니다.

Kubernetes는 무엇을 해결할까

Docker로 이미지를 만들고 컨테이너를 실행할 수는 있지만, 실제 운영에서는 그것만으로 충분하지 않은 경우가 많습니다.

예를 들어 다음과 같은 문제가 생길 수 있습니다.

  • 컨테이너가 죽으면 어떻게 다시 띄울 것인가
  • 트래픽이 늘어나면 개수를 어떻게 늘릴 것인가
  • 여러 서버에 나누어 배포하려면 어떻게 할 것인가
  • 새 버전을 무중단으로 배포하려면 어떻게 할 것인가

Kubernetes는 이러한 문제를 해결하기 위한 플랫폼입니다.
즉, Docker가 컨테이너를 만드는 도구에 가깝다면, Kubernetes는 그 컨테이너를 여러 서버에서 운영하는 플랫폼에 가깝습니다.

Docker와 Kubernetes는 어떻게 연결될까

둘의 관계를 단순하게 정리하면 다음과 같습니다.

  1. Docker로 애플리케이션 이미지를 만듭니다.
  2. 그 이미지를 컨테이너로 실행할 수 있게 준비합니다.
  3. Kubernetes가 그 컨테이너를 여러 서버에서 관리합니다.

즉, Docker는 실행 단위를 만들고, Kubernetes는 그 실행 단위를 운영 단위로 관리한다고 이해하면 됩니다.

로컬에서는 무엇을 쓰면 될까

처음부터 클라우드 환경에서 실습하기보다, 로컬에서 구조를 직접 확인해보는 편이 이해하기 쉽습니다.
이때 자주 사용하는 도구가 kind와 kubectl입니다.

  • kind: Docker 컨테이너를 노드처럼 사용해 로컬에 Kubernetes 클러스터를 만드는 도구입니다.
  • kubectl: Kubernetes 클러스터를 조회하고 조작하는 CLI 도구입니다.

이 조합을 사용하면 로컬에서도 클러스터 생성, 리소스 배포, 서비스 연결 같은 기본 흐름을 직접 실습해볼 수 있습니다.

마무리

처음에는 클라우드, Docker, Kubernetes가 전부 비슷한 기술처럼 보일 수 있습니다.
하지만 정리해보면 각각 담당하는 역할은 분명히 다릅니다.

  • 클라우드는 인프라를 빌려 쓰는 환경
  • Docker는 애플리케이션 실행 환경을 묶는 도구
  • Kubernetes는 그 컨테이너를 운영하는 플랫폼

즉, 클러스터는 단순히 컨테이너 몇 개를 띄우는 환경이 아니라, 여러 노드와 관리 컴포넌트가 함께 동작하는 구조입니다.

Control Plane과 Worker Node

Control Plane

Control Plane은 클러스터 전체를 관리하는 역할을 합니다.
대표적으로 다음과 같은 구성 요소가 있습니다.

  • API Server: 클러스터의 모든 요청이 통과하는 관문입니다.
  • Scheduler: 어떤 Pod를 어떤 노드에 배치할지 결정합니다.
  • Controller: 현재 상태를 원하는 상태에 맞게 유지합니다.

예를 들어 “Pod 3개를 유지한다”는 상태가 정의되어 있다면, Pod 하나가 사라졌을 때 Controller가 다시 맞추는 식입니다.

Worker Node

Worker Node는 실제로 Pod가 실행되는 노드입니다.
즉, 애플리케이션이 실제로 돌아가는 실행 환경이라고 볼 수 있습니다.

Namespace는 왜 필요할까

Namespace는 같은 클러스터 안의 리소스를 논리적으로 분리하는 공간입니다.

예를 들어 다음과 같은 방식으로 사용할 수 있습니다.

  • 개발 / 스테이징 / 운영 환경 분리
  • 팀별 리소스 분리
  • 같은 이름의 리소스를 서로 다른 공간에서 관리

즉, Namespace는 하나의 클러스터 안에서 리소스를 구분하고 정리하기 위한 단위입니다.

Pod는 무엇일까

Pod는 Kubernetes에서 실행의 최소 단위입니다.
하나 이상의 컨테이너로 구성될 수 있으며, 같은 Pod 안의 컨테이너는 네트워크와 볼륨을 공유할 수 있습니다.

중요한 점은 Pod가 영구적인 인스턴스가 아니라는 점입니다.
노드 장애나 재배치, 업데이트 상황에 따라 언제든 다시 생성될 수 있습니다.

즉, Pod는 직접 오래 붙잡고 관리하는 대상이라기보다, 필요에 따라 교체될 수 있는 실행 단위입니다.

Deployment는 왜 필요할까

Pod는 재생성될 수 있기 때문에, 일반적으로 Pod를 직접 운영하지 않습니다.
대신 Deployment를 통해 Pod를 관리합니다.

Deployment는 다음과 같은 역할을 합니다.

  • 원하는 개수의 Pod 유지
  • 롤링 업데이트
  • 롤백
  • 장애 발생 시 복구

내부적으로는 다음과 같은 구조로 동작합니다.

Deployment → ReplicaSet → Pod

즉, Deployment가 원하는 상태를 선언하면, ReplicaSet이 실제 Pod 수를 맞추는 방식입니다.

Service는 왜 필요할까

Pod는 재생성되면 IP가 바뀔 수 있습니다.
이 때문에 Pod에 직접 접근하는 방식은 안정적이지 않습니다.

Service는 이런 문제를 해결하기 위해 고정된 접근점을 제공합니다.
Service는 라벨 셀렉터를 통해 특정 Pod들을 찾아 연결하고, 클라이언트는 Pod가 아니라 Service를 통해 접근하게 됩니다.

즉, Pod가 교체되더라도 Service가 계속 같은 이름과 가상 IP로 요청을 받아줄 수 있습니다.

로컬에서는 무엇을 쓰면 될까

처음부터 클라우드 환경에서 실습하기보다, 로컬에서 구조를 직접 확인해보는 편이 이해하기 쉽습니다.
이때 자주 사용하는 도구가 kind와 kubectl입니다.

  • kind: Docker 컨테이너를 노드처럼 사용해 로컬에 Kubernetes 클러스터를 만드는 도구입니다.
  • kubectl: Kubernetes 클러스터를 조회하고 조작하는 CLI 도구입니다.

이 조합을 사용하면 로컬에서도 클러스터 생성, 리소스 배포, 서비스 연결 같은 기본 흐름을 직접 실습해볼 수 있습니다.

마무리

클라우드, Docker, Kubernetes는 자주 함께 등장하지만, 각각 담당하는 문제는 다릅니다.

  • 클라우드는 인프라를 빌려 쓰는 환경입니다.
  • Docker는 애플리케이션 실행 환경을 묶는 도구입니다.
  • Kubernetes는 그 컨테이너를 운영하는 플랫폼입니다.

그리고 Kubernetes 내부에서는 다시 다음과 같은 구조가 중요합니다.

  • 클러스터
  • Control Plane / Worker Node
  • Namespace
  • Pod
  • Deployment
  • Service

이 흐름을 먼저 이해하면 이후에 Storage, Gateway API, HPA 같은 리소스를 볼 때도 훨씬 수월해집니다.