【10월 기준 Docker의 현황】 부제: 그래 그래 형은 계속 발전해

개요

요즘 같은 시대에 CLI명령어를 직접 치는 사람이 얼마나 될까 싶지만 난 자주 사용하고 있다.

간간히 테스트할때 docker run nginx같은 명령어를 가볍게 한 줄 치면 컨테이너가 뜨는 참 좋은 시대다.

 

그런데 몇 년째 매일 치는 명령어인데, 이제는 막상 "그래서 그 사이에 프로세스가 몇 개 지나가냐"고 물으면 바로 대답이 안나올 정도로 AI에 기대고 있는 내 모습을 보고 이 글을 작성하게 되었다.

 

AI가 발전하는 사이 Docker는 꽤 많이 바뀌었다.

2025년 말 Engine 29부터 신규 설치는 이미지 저장소까지 containerd에 넘겼고, 2026년 들어서는 containerd를 아예 dockerd 안에 품는 실험까지 시작했다.

Desktop은 매주 릴리스가 나오고, 메뉴에는 컨테이너보다 AI 에이전트 항목이 더 많아졌다.

 

그래서 2026년 10월 7일 기준으로 한 번 정리해 두기로 했다.

 

요즘엔 AI가 이런거도 만들어준다;;

docker run과 kubelet은 위에서 갈라지지만 containerd에서 만나고, 실제 프로세스를 만드는 건 둘 다 runc다.

 

사실 이 그림 하나가 글 전체의 요약이라고 봐도 무방하다.

 

컴포넌트 하나씩 뜯어보기

1. docker CLI와 플러그인

사실 우리가 치는 docker는 그냥 REST 클라이언트다.

Unix 소켓(/var/run/docker.sock)으로 dockerd의 Engine API를 호출할 뿐, 컨테이너를 직접 만들지 않는다.

docker compose, docker buildx도 사실 CLI 플러그인으로 붙어 있는 별도 바이너리 덩어리일 뿐 이다.

 

참고로 Engine 29부터 Go로 Docker API를 쓰던 사람은 github.com/docker/docker 대신 github.com/moby/moby/client와 api 모듈을 써야 한다.

2. dockerd (Docker Engine, Moby)

사용자 입장에서 "Docker"라고 부르는 거의 모든 기능이 여기 있다.

네트워크(bridge, overlay, iptables/nftables 규칙), 볼륨, 로그 드라이버, Swarm, 그리고 API 서버. 오픈소스 이름은 Moby다.

https://github.com/moby/moby

GitHub - moby/moby: The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems

 

2026년의 dockerd는 점점 오케스트레이션과 사용자 경험 레이어로 좁아지고 있다.

실행은 원래 containerd에 맡겼고, 29.0부터는 신규 설치에서 이미지 저장까지 containerd image store가 기본이다.

 

29.7.0에서는 containerd를 별도 프로세스가 아닌 dockerd 내부에서 돌리는 embedded-containerd가 실험 기능으로 들어왔고, 29.8.0부터는 시스템에 containerd가 없으면 자동으로 embedded 모드를 쓰도록 되어있다.

 

실험 기능이긴 하지만 네트워크 쪽도 변화가 있다.

29.0부터 firewall-backend 옵션으로 iptables 대신 nftables 규칙을 직접 만들 수 있다!

3. containerd

CNCF 졸업 프로젝트이자 Kubernetes 노드의 사실상 표준 런타임이다. (진짜 코드보면 머리 아프다...)

이미지 pull/저장(content store + snapshotter), 컨테이너 라이프사이클 관리를 맡는다.

2026-10 기준 Docker가 번들하고 있는 버전은 2.3.6이다.

 

Docker와 Kubernetes는 같은 containerd를 쓴다 여기서 유일한 차이는 위에서 누가 부르느냐!

Docker는 dockerd가 containerd API를 부르고, Kubernetes는 kubelet이 containerd의 CRI 플러그인을 부른다.

4. containerd-shim

containerd와 실제 컨테이너 프로세스 사이에 하나씩 끼는 작은 프로세스다.

컨테이너마다 shim이 있어서 containerd나 dockerd가 재시작돼도 컨테이너는 계속 살아 있을 수 있다.

live-restore가 가능한 이유가 이것이다.

 

5. runc

OCI Runtime Spec 레퍼런스 구현체이다.

namespace, cgroup, seccomp, AppArmor를 걸어서 프로세스를 띄우고 나면 빠진다.

 

컨테이너가 뜬 뒤에는 runc 프로세스가 남아 있지는 않는다.

현재 Docker 번들 버전은 1.5.2다. 필요하면 gVisor(runsc)나 Kata 같은 다른 OCI 런타임으로 갈아 끼울 수 있다.

6. BuildKit과 Buildx

참 아쉬운 친구다.

docker build의 실제 엔진이며 Dockerfile을 LLB라는 중간 표현으로 바꾼 뒤 병렬로 실행하고 캐시한다.

현재 Engine에 들어간 버전은 0.33.1이다.

 

Buildx는 BuildKit을 부르는 CLI 플러그인이다.

드라이버만 바꾸면 로컬 dockerd 안, 별도 컨테이너, Kubernetes 파드, Docker Build Cloud 어디서든 같은 빌드를 돌릴 수 있다.

 

Compose v5도 자체 빌더를 없애고 빌드를 Bake로 넘겼다. 즉 2026년의 Docker에서 이미지를 만드는 길은 사실상 BuildKit 하나로 수렴했다.

 

그렇다는 것은.... Dockerfile은 그대로지만 classic builder가 암묵적으로 해주던 동작(전체 스테이지 빌드, 이미지 기반 캐시)이 BuildKit에선 기본이 아니라서, CI에서 캐시·로그·provenance 옵션을 하나씩 명시해줘야 한다...

물론 이렇게 기존 정서와 크게 어긋나는 부분은 도커측에서 차차 해결해나가겠지만 그 사이에 나는....

7. Docker Compose

얘는 버전 관리가 좀 신기해서 가져와봤다.

2025년에 v2 다음 버전이 v3이 아니라 v5로 나왔다.

암흑진화 현장

건너 뛴 이유는 https://github.com/docker/compose/releases/tag/v5.0.0 여기에 명시되어 있듯

Release v5.0.0 "Mont Blanc" · docker/compose

옛 Compose 파일 포맷 version 2/3과 헷갈리지 않게 하려고 번호를 건너뛰었다고 한다.

 

v5의 핵심은 무려 공식 Go SDK다!

 

CLI 없이도 Go 코드에서 Compose 프로젝트를 로드하고 관리할 수 있다.

Overview

계층	컴포넌트	맡는 일
클라이언트	docker CLI, compose, buildx	API 호출
엔진	dockerd (Moby)	네트워크, 볼륨, 로그, API
고수준 런타임	containerd	이미지, 스냅샷, 라이프사이클
감시자	containerd-shim	프로세스 보존, stdio
저수준 런타임	runc	namespace/cgroup 설정 후 exec
빌드	BuildKit	이미지 빌드

 

누가 무엇을 정의하는가 (feat. OCI, Moby, CNCF)

가끔 아직도 k8s에서 도커가 쫓겨났다고 오해하고 있는 사람들이 많다.

실상은 컴포넌트를 쪼개서 그 중 일부만 넣은 것 이다.

 

사실 컴포넌트가 이렇게 잘게 나뉜 이유는 표준 때문이다.

2015년 Docker가 이미지 포맷과 런타임을 OCI(Open Container Initiative)에 기부하면서 Docker 고유 기술이던 것이 업계 공용 규격이 됐다.

• OCI Image Spec: 레이어와 매니페스트 구조다. Docker, Podman, Kubernetes가 같은 이미지를 쓸 수 있는 이유다.
• OCI Runtime Spec: config.json 하나로 컨테이너를 정의하는 규격이다. 놀랍게도 runc가 레퍼런스 구현이다.
• OCI Distribution Spec: 레지스트리 API다 요즘은 이미지뿐 아니라 Helm 차트, Compose 파일, AI 모델까지 이 규격으로 배포되는데 참 사람일 모르는 것 같다 ㅋㅋ

오픈소스 거버넌스로 보면 세 갈래다.

• Moby: dockerd의 업스트림이다 Docker Inc.가 주도한다.
• containerd: CNCF 졸업 프로젝트이며 Docker도, Kubernetes도 이걸 쓴다.
• runc: OCI 산하 프로젝트다.

 

그래서 Kubernetes가 2022년(1.24)에 dockershim을 제거했을 때도 Docker로 빌드한 이미지는 계속 잘 돌았던 것 이다.

빠진 건 kubelet과 dockerd 사이의 어댑터일 뿐이고, 이미지와 그 아래 containerd·runc는 쭉 그대로였다.

 

더군다나 이제는 Engine 29에서 Docker가 이미지 저장까지 containerd로 옮기면서, 같은 노드에서 Docker와 Kubernetes가 보는 철학은 점점 가까워지고 있다고 봐도 무방할 것 같다.

 

마치며

정리하면 2026년 10월의 Docker는 이렇다.

 

CLI는 API 클라이언트가 담당하고, dockerd는 네트워크·볼륨·UX를 쥔 오케스트레이터로서 살아가고 있으며 containerd는 이미지와 라이프사이클을 담당하고 있다.

runc는 커널 기능을 걸고 빠지는 일회용 실행기로서 굳건해졌으며 빌드는 BuildKit 하나로 모았다.

 

내가 보기에 Engine 29 이후의 방향은 분명해보인다.

dockerd는 얇아지고, containerd는 두꺼워지고, 그 위에 AI 제품군이 쌓이는 AI Native한 시대의 흐름에 따라 컨테이너의 세상이 나아갈 것 같다.

 

쓰다 보니 구조 글인지 릴리스 노트 요약인지 모를 난잡한 글이 됐다.

 

 

참고 자료

• Docker Engine v29 릴리스 노트
• Docker Engine v29: Foundational Updates for the Future
• Docker Desktop 릴리스 노트
• Docker Compose v5 릴리스 노트
• Docker Compose의 역사
• Docker with nftables
• Embedded containerd