Kubernetes

아닙니다. 도커는 컨테이너 1개를 다루는 도구, 쿠버네티스는 컨테이너 수백 개를 여러 서버에서 운영하는 플랫폼입니다.

두 기술이 비교 대상처럼 보이는 이유는 같은 “컨테이너”라는 단어를 공유하기 때문입니다. 하지만 층이 다릅니다. 도커(Docker)는 애플리케이션을 컨테이너 이미지로 만들고(build), 이미지를 저장소에 올리고(ship), 한 서버에서 실행하는(run) 개발자 도구 모음입니다. 쿠버네티스(Kubernetes)는 그렇게 만들어진 컨테이너를 여러 서버(클러스터)에 걸쳐 자동으로 배치하고, 죽으면 되살리고, 부하에 따라 늘리고 줄이는 컨테이너 오케스트레이션(orchestration, 다수 컨테이너의 배치·운영 자동화) 플랫폼입니다(출처: Kubernetes 공식 블로그 — Don’t Panic: Kubernetes and Docker, 2020-12).

비유하면 도커는 표준 규격의 컨테이너 박스를 만드는 공장이고, 쿠버네티스는 그 박스 수천 개를 실어 나르는 항만 관제 시스템입니다. 실제 현장에서도 “개발자는 도커로 이미지를 만들고, 운영 환경은 쿠버네티스가 그 이미지를 실행하는” 조합이 표준입니다. 쿠버네티스 자체를 처음 접하신다면 필러 글 쿠버네티스란 무엇인가에서 전체 개념을 먼저 잡으실 수 있습니다.

도커는 Dockerfile로 이미지를 빌드하고, 레지스트리로 공유하며, 단일 호스트에서 컨테이너를 실행합니다.

도커의 책임 범위는 컨테이너의 생애 앞부분입니다.

• 빌드(Build) — Dockerfile이라는 명세서에 “어떤 운영체제 위에 어떤 라이브러리와 애플리케이션을 얹을지”를 적으면, 도커가 이를 컨테이너 이미지로 만듭니다. 이 이미지는 OCI(Open Container Initiative)라는 업계 표준 형식을 따릅니다.
• 공유(Ship) — 만들어진 이미지를 Docker Hub나 사내 컨테이너 레지스트리에 올려 팀·환경 간에 동일한 실행 환경을 배포합니다. “제 PC에서는 됩니다” 문제를 없애는 핵심 장치입니다.
• 실행(Run) — docker run 명령으로 이미지를 컨테이너로 띄웁니다. 개발 PC나 단일 서버에서 몇 개의 컨테이너를 돌리는 데는 이것으로 충분합니다.

여기서 도커가 컨테이너 그 자체는 아니라는 점을 구분해 두면 좋습니다. 컨테이너는 리눅스 커널의 namespace(보이는 범위를 나누는 격리)와 cgroup(쓸 수 있는 자원의 양을 제한하는 통제)으로 만들어진 격리된 프로세스이고, 도커는 그 프로세스를 만들고 다루기 쉽게 감싼 도구이자 플랫폼입니다. 같은 일을 하는 도구가 도커만 있는 것도 아니어서, 단일 노드에서는 데몬 없이 동작하는 Podman 같은 대안도 같은 OCI 이미지를 그대로 다룹니다.

중요한 사실 하나를 짚어 두겠습니다. 도커가 만드는 이미지는 도커 전용이 아니라 OCI 표준 이미지입니다. 그래서 도커로 빌드한 이미지는 쿠버네티스에서 그대로 실행됩니다(출처: Kubernetes 공식 블로그 — Don’t Panic). 이 표준 덕분에 “빌드 도구”와 “운영 플랫폼”을 자유롭게 조합할 수 있습니다.

쿠버네티스는 선언된 상태를 유지하도록 배치·복구·확장·트래픽 분배를 자동화합니다.

서비스가 커지면 컨테이너는 몇 개가 아니라 수십·수백 개가 되고, 서버도 여러 대가 됩니다. 이때부터는 “어느 컨테이너를 어느 서버에 둘까”, “죽은 컨테이너를 누가 되살릴까”, “트래픽이 몰리면 누가 늘릴까”라는 운영 문제가 본질이 됩니다. 쿠버네티스는 이 문제를 선언적 방식으로 풉니다. 운영자가 “이 이미지를 3개 띄워 두라”고 선언하면, 쿠버네티스가 그 상태를 계속 유지합니다. 컨테이너가 죽으면 자동으로 다시 띄우고, 서버가 죽으면 다른 서버에 옮겨 만들고, 설정한 조건에 따라 개수를 자동 조절합니다(출처: Kubernetes 공식 문서 — 개요).

핵심은 “어떻게 하라”가 아니라 “어떤 상태였으면 좋겠다”를 적는다는 점입니다. 운영자는 원하는 상태를 선언하고, 오케스트레이터는 현재 상태를 관찰해 둘의 차이를 계속 좁힙니다. 이 선언형 모델 자체는 컨테이너에만 국한된 개념이 아니지만, 컨테이너처럼 빠르게 만들고 버릴 수 있는 실행 단위와 만나면서 실용성이 크게 올라갔습니다.

이 자동화를 담당하는 컨트롤 플레인과 워커 노드의 내부 구조는 쿠버네티스 아키텍처 완전 정복에서 컴포넌트 단위로 해설합니다. 여기서는 “도커가 끝나는 지점, 즉 여러 서버에 걸친 운영 자동화부터가 쿠버네티스의 영역”이라는 경계만 기억하시면 됩니다.

쿠버네티스는 CRI라는 표준 인터페이스로 containerd, CRI-O 같은 컨테이너 런타임에 실행을 맡깁니다.

도커와 쿠버네티스의 관계를 정확히 이해하려면 중간의 런타임 계층을 봐야 합니다. 쿠버네티스는 컨테이너를 직접 만들지 않습니다. 각 노드의 kubelet이 CRI(Container Runtime Interface)라는 표준 규약으로 컨테이너 런타임에 “이 이미지를 실행해 달라”고 요청할 뿐입니다(출처: cncf.co.kr — containerd·CRI-O·runc 해설).

사실 도커 엔진 안에도 같은 계층 구조가 이미 들어 있습니다. 사용자가 docker run을 치면 명령은 docker CLI → dockerd(최상위 데몬) → containerd → containerd-shim → runC 순으로 내려가고, 마지막에 runC가 리눅스 커널 기능으로 컨테이너 프로세스를 만듭니다. 각 층이 CNCF·OCI 업계 표준을 따르기 때문에 아래쪽 구현을 다른 것으로 갈아 끼울 수 있습니다.

이 계층에는 세 이름이 자주 등장합니다.

• containerd — 원래 도커 엔진의 내부 부품이었다가 독립한 런타임으로, CNCF 졸업(Graduated) 프로젝트입니다. 이미지 관리와 컨테이너 생애 관리를 담당하며, 현재 관리형 쿠버네티스 서비스 다수가 기본 런타임으로 채택하고 있습니다.
• CRI-O — 쿠버네티스 전용으로 설계된 경량 런타임입니다. CRI 규약을 그대로 구현해 쿠버네티스 외의 부가 기능을 덜어냈습니다.
• runc — containerd·CRI-O가 최종적으로 호출하는 저수준 런타임으로, 리눅스 커널 기능을 사용해 컨테이너 프로세스를 실제로 만듭니다. OCI 런타임 표준의 참조 구현입니다.

고수준 런타임과 저수준 런타임

런타임을 부르는 이름이 여럿인 이유는 층이 둘로 나뉘기 때문입니다(출처: cncf.co.kr — containerd·CRI-O·runc 해설).

• 고수준 런타임(High-Level Runtime) — 이미지와 저장소, 네트워크까지 다루며 위쪽 도구의 요청을 받는 층입니다. containerd, CRI-O, 그리고 단일 노드용 Podman이 여기 속합니다.
• 저수준 런타임(Low-Level Runtime) — 커널 기능을 직접 써서 컨테이너 프로세스를 만드는 층입니다. runc가 표준 구현이고, 격리를 더 강하게 가져가야 할 때는 시스템 콜을 사용자 공간에서 처리하는 gVisor나 가상머신으로 감싸는 Kata Containers를 고릅니다.

표준도 이름이 비슷해 헷갈리기 쉬운데, 역할이 서로 다릅니다. CRI는 쿠버네티스가 런타임에 컨테이너 생성·삭제·상태 확인을 gRPC로 요청할 때 쓰는 쿠버네티스 쪽 인터페이스이고, OCI는 컨테이너 이미지 형식과 런타임 동작을 정의해 벤더 종속을 줄이는 업계 명세입니다. containerd와 CRI-O는 둘 다 만족하고, runc는 OCI 런타임 명세의 구현입니다. 도커로 만든 이미지가 쿠버네티스에서 그대로 도는 근거는 이 가운데 OCI 쪽에 있습니다.

정리하면 “kubelet → (CRI) → containerd 또는 CRI-O → runc → 컨테이너”의 사슬입니다. 그리고 도커 엔진 역시 내부적으로 containerd와 runc를 사용합니다. 즉 도커로 실행하든 쿠버네티스로 실행하든, 맨 아래에서 컨테이너를 만드는 기술은 사실상 같은 뿌리입니다. 이 계층 구조를 슬라이드로 한 번에 훑고 싶으시면 컨테이너 런타임 — 주요 기술과 비교 자료를 참고하실 수 있습니다.

중단된 것은 도커 엔진을 런타임으로 잇던 어댑터(dockershim)이며, 도커로 만든 이미지는 지금도 그대로 동작합니다.

2020년 말 쿠버네티스 1.20이 도커 런타임 지원 중단(deprecation)을 예고하자 “쿠버네티스에서 도커를 못 쓴다”는 오해가 퍼졌습니다. 실제 사정은 이렇습니다. 도커 엔진은 CRI 표준이 생기기 전의 도구라 CRI를 직접 말하지 못했고, 쿠버네티스는 dockershim이라는 어댑터 코드를 자체 유지하며 도커 엔진을 런타임으로 이어 왔습니다. 이 어댑터의 유지 부담을 정리하기로 하면서 1.20에서 사용 중단을 예고했고(출처: Kubernetes 공식 블로그 — Don’t Panic: Kubernetes and Docker, 2020-12), 쿠버네티스 1.24에서 dockershim이 실제로 제거됐습니다(출처: Kubernetes 공식 블로그 — Dockershim FAQ, 2022-02).

실무 영향은 두 가지로 명확히 갈립니다.

• 영향 없음 — 도커로 빌드한 이미지. OCI 표준이므로 containerd·CRI-O에서 그대로 실행됩니다. 개발자가 도커 데스크톱으로 개발하고 Dockerfile로 빌드하는 워크플로도 그대로 유효합니다.
• 조치 필요(당시) — 노드 런타임으로 도커 엔진을 쓰던 클러스터. containerd나 CRI-O로 전환이 필요했고, 현재의 관리형 서비스와 배포판은 이미 CRI 네이티브 런타임이 기본입니다.

요컨대 “도커 지원 중단”의 정확한 번역은 “쿠버네티스 노드의 실행 엔진 자리가 도커 엔진에서 CRI 표준 런타임으로 정리됐다”입니다. 도커라는 개발 도구의 가치나 도커 이미지의 호환성은 달라진 것이 없습니다.

컨테이너 수가 적고 서버가 한 대면 도커로 충분하고, 여러 서버에서 자동 복구·확장이 필요해지는 순간부터 쿠버네티스를 검토합니다.

의사결정을 단계별 질문으로 정리하면 다음과 같습니다.

1. 개발 환경 표준화가 목적인가? → 도커(또는 호환 도구)만으로 충분합니다. 쿠버네티스는 아직 필요 없습니다.
2. 단일 서버에서 컨테이너 몇 개를 운영하는가? → 도커와 docker compose 수준으로 운영 가능합니다. 오케스트레이션 도입은 과합니다.
3. 서버 여러 대에 걸쳐 서비스를 돌리고, 장애 시 자동 복구가 필요한가? → 쿠버네티스 검토 시점입니다. 직접 구축이 부담스러우면 관리형 서비스나 쿠버네티스 배포판부터 시작하는 선택지가 있습니다.
4. 트래픽 변동이 크고 무중단 배포·자동 확장이 요구되는가? → 쿠버네티스의 효용이 가장 큰 구간입니다. 이 단계에서는 조직의 운영 역량(모니터링·CI/CD)도 함께 준비되어야 합니다.
5. 팀에 쿠버네티스 경험이 없는가? → 도커로 컨테이너 개념을 먼저 체득한 뒤 쿠버네티스로 넓히는 경로가 학습 순서로도 자연스럽습니다. 학습·소규모 환경이라면 단일 바이너리로 설치가 끝나는 경량 배포판 K3s로 첫 클러스터를 띄워 보는 방법이 부담이 적습니다.

주의할 점은 “쿠버네티스가 항상 정답”이 아니라는 사실입니다. 소규모 시스템에 쿠버네티스를 얹으면 운영 복잡도가 이득을 넘어섭니다. 반대로 서비스가 성장 중이라면, 컨테이너 표준화(도커) 단계에서 멈추지 말고 오케스트레이션까지 내다보는 로드맵을 세우는 편이 이후 클라우드 네이티브 전환 비용을 줄입니다.

도커에는 Swarm mode라는 자체 오케스트레이션이 내장돼 있지만, 생태계와 확장성 때문에 사실상 표준 자리는 쿠버네티스가 차지했습니다.

“오케스트레이션 = 쿠버네티스”로 알고 계셨다면 한 가지 사실을 더할 필요가 있습니다. 도커 엔진 1.12부터는 Swarm mode가 엔진 자체에 들어가 있어, 별도 설치 없이 docker swarm init과 join만으로 클러스터를 만들 수 있습니다. 옛 standalone Swarm이 관리자 컴포넌트와 키-값 저장소를 따로 깔아야 했던 것과 달리, 지금의 Swarm mode는 진입 장벽이 낮습니다. 동작 원리도 쿠버네티스와 같은 선언형입니다. 컨테이너 하나하나가 아니라 “이 서비스를 복제본 3개로”를 선언하면 Swarm이 태스크를 노드에 배치하고 그 수를 유지합니다.

그럼에도 실무의 선택이 쿠버네티스로 모인 이유는 기능 한 줄의 차이가 아니라 층의 두께 차이입니다. 오케스트레이션 계층에는 쿠버네티스, Docker Swarm mode, 그리고 쿠버네티스 위에 CI/CD와 운영 기능을 얹은 엔터프라이즈 배포판이 함께 놓여 있는데(출처: cncf.co.kr — containerd·CRI-O·runc 해설), 이 가운데 네트워킹·스토리지·모니터링·보안까지 표준 인터페이스로 확장되는 생태계를 갖춘 쪽이 쿠버네티스입니다. Swarm은 여전히 소규모 클러스터에서 쓸 만한 선택지이지만, 조직이 마이크로서비스와 클라우드 네이티브 4대 요소까지 내다본다면 표준 쪽에 서는 편이 나중의 이동 비용을 줄입니다.

정리하면 “도커냐 쿠버네티스냐”의 진짜 갈림길은 빌드 도구가 아니라 오케스트레이션을 Swarm으로 할 것인가 쿠버네티스로 할 것인가입니다. 그리고 어느 쪽을 고르든 앞 단계에서 만드는 이미지는 같은 OCI 표준입니다.

실제 현장의 표준 흐름은 “도커로 빌드 → 레지스트리로 공유 → 쿠버네티스가 배포·운영”의 연속 파이프라인입니다.

두 기술이 어떻게 이어지는지 배포 한 사이클로 따라가 보겠습니다. 개발자가 코드를 저장소에 올리면, CI(지속적 통합) 서버가 Dockerfile로 이미지를 빌드하고 버전 태그를 붙여 레지스트리에 올립니다. 여기까지가 도커의 영역입니다. 이어서 배포 매니페스트의 이미지 태그가 새 버전으로 바뀌면, 쿠버네티스가 이를 감지해 롤링 업데이트(rolling update, 구버전 컨테이너를 순차적으로 새 버전으로 교체하는 무중단 배포)를 수행합니다. 배포 중 문제가 감지되면 이전 버전으로 되돌리는 롤백도 명령 하나로 가능합니다(출처: Kubernetes 공식 문서 — 개요).

이 흐름에서 두 도구의 접점은 오직 하나, OCI 이미지입니다. 도커는 이미지를 “만들어 올리는” 데까지, 쿠버네티스는 이미지를 “받아 운영하는” 데부터 책임집니다. 접점이 표준으로 좁게 정의되어 있기 때문에, 빌드 쪽 도구를 바꾸든 운영 쪽 플랫폼을 바꾸든 반대편에 영향이 없습니다. IT 담당자 관점에서는 이 구조가 곧 도입 전략이 됩니다. 컨테이너 표준화(도커)와 오케스트레이션 도입(쿠버네티스)을 한 번에 결정할 필요 없이, 단계를 나눠 진행해도 이후 통합이 자연스럽다는 뜻입니다.

아래 표는 “무엇이 더 낫냐”가 아니라 “무엇이 다른 일을 하느냐”를 보여 줍니다.

표가 보여 주듯 도커의 출력물(OCI 이미지)이 쿠버네티스의 입력물입니다. 그래서 “도커 vs 쿠버네티스”라는 질문의 실무적 정답은 대부분 “도커 그리고 쿠버네티스”입니다. 컨테이너 기반 체계가 조직의 더 큰 전환, 즉 클라우드 네이티브 전환의 첫 단추라는 점은 클라우드 네이티브란 무엇인가에서 확인하실 수 있습니다.

컨테이너 생태계는 표준(OCI·CRI) 위에서 역할 분담이 정리되는 방향으로 성숙해 왔습니다. 빌드 도구와 런타임과 오케스트레이터를 자유롭게 조합할 수 있게 된 지금, 조직이 정할 일은 도구의 승자를 고르는 것이 아니라 자신의 규모와 성장 단계에 맞는 조합을 고르는 것입니다.

쿠버네티스와 도커의 차이를 한 문장으로 정리하면?

도커는 컨테이너 하나를 만들고 실행하는 도구이고, 쿠버네티스는 그런 컨테이너 수십·수백 개를 여러 서버에 걸쳐 자동으로 배치·복구·확장하는 운영 플랫폼입니다. 층이 다른 기술이라 직접 경쟁하지 않습니다.

쿠버네티스를 쓰면 도커는 더 이상 필요 없나요?

빌드 단계에서는 여전히 널리 쓰입니다. 도커로 만든 OCI 표준 이미지는 쿠버네티스에서 그대로 실행되므로, “개발·빌드는 도커, 운영은 쿠버네티스” 조합이 일반적입니다. 노드의 실행 엔진 자리만 containerd·CRI-O 같은 CRI 런타임이 맡습니다.

도커로 만든 이미지가 쿠버네티스에서 안 돌아갈 수 있나요?

dockershim 제거와 무관하게 정상 동작합니다. 도커가 만드는 이미지는 OCI 업계 표준 형식이고, 쿠버네티스의 런타임들이 이 표준을 그대로 지원하기 때문입니다. 호환성 문제를 이유로 빌드 도구를 바꿀 필요는 없습니다.

소규모 서비스도 쿠버네티스를 도입해야 하나요?

반드시 그렇지는 않습니다. 단일 서버에 컨테이너 몇 개 수준이면 도커와 docker compose로 충분하고, 쿠버네티스는 오히려 운영 부담을 키울 수 있습니다. 서버 여러 대, 자동 복구, 자동 확장이 필요해지는 시점이 도입 검토의 적기입니다.

dockershim 제거는 언제, 왜 이루어졌나요?

쿠버네티스 1.20(2020년 말)에서 사용 중단이 예고되고 1.24(2022년)에서 제거됐습니다. 도커 엔진이 CRI 표준을 직접 지원하지 않아 쿠버네티스가 어댑터(dockershim)를 따로 유지해야 했는데, 이 부담을 없애고 CRI 표준 런타임으로 일원화한 조치입니다.

CRI와 OCI는 어떻게 다른가요?

CRI는 쿠버네티스가 컨테이너 런타임에 생성·삭제·상태 확인을 gRPC로 요청할 때 쓰는 쿠버네티스 쪽 인터페이스이고, OCI는 컨테이너 이미지 형식과 런타임 동작을 정의한 업계 명세입니다. containerd와 CRI-O는 두 표준을 모두 만족하고, runc는 OCI 런타임 명세의 구현입니다. 도커 이미지의 호환성을 보장하는 쪽은 OCI입니다.

Docker Swarm이 있는데 왜 쿠버네티스를 쓰나요?

Swarm mode도 선언형으로 서비스 복제본을 유지하는 오케스트레이터라 소규모 클러스터에는 충분합니다. 다만 네트워킹·스토리지·모니터링·보안을 표준 인터페이스로 확장하는 생태계는 쿠버네티스 쪽이 훨씬 두텁습니다. 규모가 커지고 연동할 도구가 늘어날수록 이 차이가 선택을 가릅니다.

• 쿠버네티스란 무엇인가 — 개념부터 도입 판단까지
• 쿠버네티스 아키텍처 완전 정복 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 Pod 완벽 가이드 — 개념·생명주기·멀티컨테이너 패턴
• 컨테이너 런타임 — containerd·CRI-O·runc 기술 표준과 구분
• Podman이란? — 데몬 없는 컨테이너 엔진
• 컨테이너 레지스트리 — 이미지 저장과 배포
• 쿠버네티스 배포판 비교 — 무엇을 고를 것인가
• K3s — 경량 쿠버네티스로 시작하기
• 클라우드 네이티브 4대 요소 — 컨테이너·MSA·CI/CD·DevOps
• 클라우드 네이티브란 무엇인가

• Don’t Panic: Kubernetes and Docker (Kubernetes 공식 블로그)
• Updated: Dockershim Removal FAQ (Kubernetes 공식 블로그)
• containerd, CRI-O, runc — 컨테이너 런타임 해설 (cncf.co.kr)
• 쿠버네티스란 무엇인가 (cncf.co.kr)
• 컨테이너 런타임 — 주요 기술과 비교 (자료 다운로드, cncf.co.kr)
• 컨테이너와 쿠버네티스 기술 자료 (자료 다운로드, cncf.co.kr)
• Kubernetes 공식 문서 — 개요(한국어)