Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 2026년 런타임이 다시 흥미로워진 이유

2013년 dotCloud의 Solomon Hykes가 PyCon US에서 Docker를 공개한 뒤 십 년 동안, "컨테이너 = Docker"라는 등식은 거의 의심받지 않았다. 그러나 2020년 12월 Kubernetes가 1.20부터 dockershim deprecation을 예고하고, 2022년 4월 1.24에서 실제로 제거하면서 풍경이 바뀌었다.

2026년 5월 현재, 대형 클러스터의 기본 런타임은 containerd 2.0 또는 CRI-O 1.31이고, 로컬 개발에서도 Podman 5와 Orbstack이 Docker Desktop의 자리를 빠르게 갉아먹고 있다. 한편 멀티테넌트 SaaS와 서버리스 시장에서는 gVisor·Kata Containers·Firecracker MicroVM이 표준 격리 수단으로 굳었고, WebAssembly 런타임은 runwasi shim을 통해 Kubernetes에 정식으로 들어왔다.

이 글은 OCI 1.2 스펙부터 low-level 런타임(runc · crun · youki), high-level 런타임(containerd · CRI-O), 데몬리스(Podman · Buildah · Skopeo), 격리 강화(gVisor · Kata · Firecracker · Cloud Hypervisor), 그리고 Wasm 런타임(WasmEdge · Wasmtime · Wasmer · Spin · WasmCloud)까지 — 누가 어떤 문제를 풀고, 어떤 워크로드에 어떤 런타임을 골라야 하는지 지도를 그린다.

1장 · OCI 스펙 — 모든 런타임의 공통 기반

Open Container Initiative(OCI)는 2015년 6월 Docker가 컨테이너 포맷을 표준화하기 위해 Linux Foundation 산하로 기증한 프로젝트다. 2026년 5월 현재 세 가지 핵심 스펙이 있다.

| 스펙 | 버전 (2026.5 기준) | 무엇을 정의하나 |

| --- | --- | --- |

| image-spec | 1.1 + 1.2 RC | 이미지 매니페스트, config, layer 포맷 |

| runtime-spec | 1.2.0 | config.json, lifecycle, ops |

| distribution-spec | 1.1.1 | registry HTTP API |

핵심 메시지 — **OCI 이미지는 tar.gz·zstd·zstd-chunked로 압축된 레이어들의 모음이고, OCI 런타임은 config.json + rootfs를 입력받아 격리된 프로세스를 만드는 책임만 진다.** 그 위에 어떤 high-level 런타임을 쓰든, 결국 가장 아래 단계는 OCI 런타임 바이너리(runc, crun, youki, runsc, kata-runtime 중 하나)다.

이 그림을 머리에 두면 나머지 챕터의 구분이 명확해진다.

2장 · 런타임 계층 — Low-level vs High-level

업계에서 "컨테이너 런타임"이라는 말은 두 가지 의미로 쓰인다.

kubelet (CRI 클라이언트)

│

▼

┌──────────────────────────────┐

│ High-level 런타임 (CRI) │

│ containerd · CRI-O · cri-dockerd │

└──────────────┬───────────────┘

│ (OCI runtime API)

▼

┌──────────────────────────────┐

│ Low-level 런타임 (OCI) │

│ runc · crun · youki · runsc · kata-runtime │

└──────────────────────────────┘

- **High-level 런타임** — 이미지 pull, 레이어 unpack, 네트워크/볼륨 세팅, lifecycle 관리. 이게 kubelet의 CRI(Container Runtime Interface) 짝꿍이다.

- **Low-level 런타임** — namespaces·cgroups·capabilities·seccomp·LSM 설정. config.json만 받아서 프로세스 fork한다.

containerd는 high-level인데 안에서 기본으로 runc를 호출한다. CRI-O는 high-level인데 기본은 crun이다. 사용자가 "런타임을 바꾼다"고 할 때 어느 층을 바꾸는 건지 늘 명시해야 혼선이 없다.

3장 · runc 1.2 — 레퍼런스 OCI 런타임

runc는 Docker가 2015년 6월 OCI에 기증한 reference low-level runtime이다. Go로 짜였고 libcontainer라는 라이브러리를 묶고 있다.

2026년 5월 stable은 1.2.5. 주요 변화는:

- **CRIU integration** 안정화 — 체크포인트/복원이 더 부드러워졌다.

- **idmapped mounts** 기본 활성 — rootless 컨테이너 호환성 향상.

- **systemd cgroup v2** 완전 지원.

- **scheduling policy** 옵션 추가 — SCHED_DEADLINE 같은 실시간 스케줄러 지정 가능.

runc는 여전히 가장 널리 쓰이는 OCI 런타임이고, Kubernetes 디스트리뷰션 대다수가 기본값이다. 다만 Go 런타임이 무거워서 컨테이너 시작이 50~80ms 걸리는 게 단점으로 자주 꼽힌다. Function-as-a-Service에서는 이 50ms도 무시 못 한다.

4장 · crun — Red Hat의 C 구현, runc보다 두 배 빠른

crun은 Red Hat이 2018년에 시작한 OCI 런타임. 핵심 차별점은 **C로 짰다는 것** — Go 런타임 로딩 비용이 없다.

벤치마크 결과는 환경에 따라 다르지만 일반적으로:

- 컨테이너 시작 시간: runc 대비 약 50% 빠름.

- 메모리 풋프린트: 약 1/3.

- 의존성: glibc 정도만 있으면 됨, runc는 Go runtime 포함.

OpenShift와 Podman의 기본 OCI 런타임이고, CRI-O 1.31의 기본값이기도 하다. crun 1.20부터는 WebAssembly 핸들러를 통해 WasmEdge·Wasmtime을 직접 launching하는 기능도 들어갔다.

5장 · youki — Rust로 다시 짠 OCI 런타임

youki는 일본 NTT 데이터 엔지니어 Toru Komatsu가 2021년에 시작한 Rust 기반 OCI 런타임이다. 2026년 5월 stable은 0.4.x.

선택 이유는 보통 세 가지:

- **Memory safety** — Rust의 borrow checker로 buffer overflow 클래스 버그가 컴파일타임에 잡힌다.

- **Performance** — runc 대비 약 30% 빠른 시작.

- **Embeddability** — libcontainer 같은 Rust 라이브러리(libcontainer-rs)로 분리되어 있어 다른 도구에서 import 가능.

AWS Bottlerocket이 일부 빌드에서 youki를 채택했고, 일본 라쿠텐과 한국 NHN Cloud에서도 실험적으로 도입한 사례가 있다. youki는 아직 production-ready를 외치진 않지만 SUSE Rancher 진영에서 적극 후원하는 중이다.

6장 · containerd 2.0 — CNCF Graduated 표준

containerd는 2017년 Docker가 CNCF에 기증한 high-level 런타임이다. 2024년 9월 2.0이 GA됐고 2026년 5월 stable은 2.1.

핵심 변화 (2.0 기준):

- **Image Transfer Service** — 이미지 pull/push를 별도 서비스로 분리, 재시도와 진행률 관측이 단순해졌다.

- **NRI (Node Resource Interface) 2.0** — 플러그인이 컨테이너 생성 시점에 hook을 걸어 GPU·CPU pinning을 동적으로 조정할 수 있다.

- **Sandbox API** stable — Kata Containers와 gVisor 같은 sandbox 런타임 통합이 표준 API로 자리잡았다.

- **runwasi shim** 정식 지원 — WebAssembly 모듈을 runtime class로 등록해서 실행 가능.

containerd는 Kubernetes 1.24부터 dockershim이 제거되면서 사실상 디폴트가 됐다. AWS EKS, Google GKE, Azure AKS, NHN Cloud K8s, KT Cloud K-PaaS-TA 모두 기본값이 containerd다.

7장 · CRI-O 1.31 — Kubernetes 전용 경량 런타임

CRI-O는 2016년 Red Hat이 시작한 "Kubernetes만을 위한 OCI 런타임"이다. 2026년 5월 stable은 1.31.

containerd와 비교했을 때 포지셔닝이 다르다:

- containerd는 Docker용·K8s용 모두 노린다. CRI-O는 K8s CRI만 한다.

- CRI-O는 Kubernetes 마이너 버전(1.x)과 1:1 매칭되어 릴리즈된다. K8s 1.31 → CRI-O 1.31.

- 메모리 풋프린트가 작고 의존성 그래프가 단순해서 OpenShift의 디폴트다.

2026년에 들어온 변화 중 흥미로운 것:

- **stream isolation** — 컨테이너 로그/exec 스트림을 별도 프로세스로 분리, OOM 영향 차단.

- **userns auto-mode** — rootless 컨테이너를 위한 UID 매핑 자동화.

- **WebAssembly runtime class** 정식 지원.

Red Hat OpenShift 4.16부터는 CRI-O가 기본이고, 한국 SK텔레콤 5G MEC와 일본 NTT 도코모 클러스터 일부도 CRI-O다.

8장 · Podman 5 — 데몬리스, 루트리스, 그리고 Pod

Podman은 Red Hat이 2018년에 발표한 "데몬 없는 Docker 대안"이다. 2026년 5월 stable은 5.4.

차별점:

- **데몬 없음** — `podman run`은 fork-exec로 컨테이너를 띄운다. 데몬 크래시 같은 단일 장애점이 없다.

- **루트리스 기본** — 일반 사용자 권한으로 컨테이너 실행. user namespace + slirp4netns + fuse-overlayfs 조합.

- **Pod 개념** — Kubernetes의 Pod처럼 여러 컨테이너를 묶어서 단일 IP/볼륨을 공유.

- **Docker CLI 호환** — `alias docker=podman`이 거의 그대로 동작.

- **podman kube generate** — 실행 중인 Pod를 Kubernetes YAML로 export.

Buildah(빌드 전용), Skopeo(이미지 검사/복사)와 함께 Red Hat 생태계의 3종 세트. 2026년 시점에서 Fedora·RHEL·Rocky Linux의 기본 컨테이너 도구가 Podman으로 완전히 넘어갔다.

Mac/Windows에서는 Podman Desktop이 점유율을 빠르게 늘리는 중. Docker Desktop의 유료 정책에 반발한 기업 사용자가 많이 옮겨갔다.

9장 · Docker 27 — 여전히 개발자 워크스테이션 1위

Docker Inc.는 2022년 1월부터 대기업 유료 정책을 시행했지만, 개발자 워크스테이션 점유율은 여전히 가장 높다. 2026년 5월 stable은 Docker Engine 27.5, Docker Desktop 4.40.

2024~2026 사이 주요 변화:

- **BuildKit 0.18** — 기본 빌더로 통합. 캐시·병렬·remote builder 지원이 표준이 됐다.

- **Docker Compose v2** — Python 구현 v1을 완전히 대체. Go로 재작성되어 `docker compose` 서브커맨드.

- **Docker Init** — 새 프로젝트에 Dockerfile·compose·.dockerignore를 자동 생성.

- **Wasm 런타임 통합 (Tech Preview)** — Wasmtime·WasmEdge를 OCI 호환으로 실행.

- **Docker Hub Personal/Pro/Team** 분리 — pull rate limit이 더 빡빡해졌다.

대기업 사용자는 Docker Desktop 라이선스 비용 때문에 Podman Desktop·Rancher Desktop·Orbstack(Mac)으로 옮긴 케이스가 많지만, 개인 개발자와 스타트업에서는 여전히 Docker가 1위다.

10장 · gVisor — Google의 유저스페이스 커널

gVisor는 Google이 2018년 KubeCon에서 공개한 "유저스페이스 커널" 기반 sandbox 런타임이다. 핵심 아이디어는 — **컨테이너 안의 syscall을 호스트 커널이 직접 처리하지 않고, gVisor 사용자 공간 프로세스가 가로채서 일부만 호스트로 전달한다.**

container app

│ syscall

▼

Sentry (gVisor 유저스페이스 커널, Go)

│ filtered subset

▼

호스트 Linux 커널

장점:

- **공격면 축소** — 컨테이너 탈출 1-day가 발견돼도 Sentry가 가로막는다.

- **OCI 호환** — runsc 바이너리가 OCI 런타임 인터페이스 그대로 구현.

- **Linux 호환성** — 대부분 syscall을 흉내내서 ELF 바이너리가 그대로 동작.

단점:

- **성능 오버헤드** — syscall heavy 워크로드에서 20~50% 느림. CPU bound에는 영향 거의 없음.

- **일부 syscall 미구현** — io_uring 같은 최신 syscall은 fallback 필요.

Google Cloud Run, App Engine Flexible, GKE Sandbox가 모두 gVisor 기반이다. Fly.io의 Machines 일부 워크로드와 한국 Naver Cloud의 멀티테넌트 함수 서비스도 채택했다.

11장 · Kata Containers 3 — VM의 격리, 컨테이너의 UX

Kata Containers는 2017년 Intel Clear Containers + Hyper.sh runV 합병으로 시작됐다. 2026년 5월 stable은 3.6.

핵심 — **컨테이너처럼 보이지만 안쪽은 진짜 경량 가상머신.** 각 Pod 또는 컨테이너마다 별도 KVM VM이 뜨고, 그 안에서 컨테이너 프로세스가 실행된다.

지원하는 hypervisor:

- **Firecracker** — AWS의 MicroVM, 가장 가벼움.

- **Cloud Hypervisor** — Intel/Cloud Hypervisor 커뮤니티의 Rust VMM.

- **QEMU** — 가장 호환성 좋음, 가장 무거움.

2026년 시점 Kata 3.x의 주요 기능:

- **VFIO-AP** — IBM s390x에서 암호화 카드 passthrough.

- **Confidential Containers** 통합 — AMD SEV-SNP·Intel TDX·IBM SE 지원.

- **runD shim 통합** — Alibaba Cloud가 기여한 shim이 containerd에 들어옴.

쓰는 곳: Alibaba Cloud의 ECI 일부, 일본 야후재팬, Microsoft Azure Container Instances 일부, GKE Sandbox(gVisor 대신 Kata 선택지).

12장 · Firecracker 1.10 — AWS Lambda를 떠받치는 MicroVM

Firecracker는 AWS가 2018년 re:Invent에서 공개한 minimalist VMM이다. Rust로 짰고 KVM 위에서 동작한다. 2026년 5월 stable은 1.10.

설계 원칙:

- **Minimal device model** — virtio-net, virtio-block, virtio-vsock, serial console 정도만. PCI도 없다.

- **125ms 미만 부팅** — 5MB짜리 microVM 바이너리가 5MB 메모리로 부팅.

- **REST API** — 외부에서 fc-control plane이 microVM을 조작.

핵심 사용처:

- **AWS Lambda** 백엔드 — cold start의 빠른 부팅을 위해 사용.

- **AWS Fargate** 일부 워크로드.

- **Fly.io Machines** — 글로벌 엣지의 컨테이너를 microVM에 격리.

- **Kata Containers** hypervisor 옵션.

- **Northflank**, **Koyeb** 등 신생 PaaS의 격리 백엔드.

Firecracker는 직접 쓰기보다는 그 위에 wrapper(Kata, Ignite, Firepilot, Cloud Hypervisor 비교용)를 두는 게 일반적이다.

13장 · Cloud Hypervisor 42 — Rust 진영의 또 다른 VMM

Cloud Hypervisor는 Intel이 2018년 시작한 또 다른 Rust 기반 VMM이다. Firecracker와 비교했을 때 더 폭넓은 디바이스 모델을 지원한다. 2026년 5월 stable은 42.

| 항목 | Firecracker | Cloud Hypervisor |

| --- | --- | --- |

| 설계 목표 | 최소 부팅 시간 | 일반 목적 VM, 더 풍부한 디바이스 |

| 디바이스 | virtio 핵심만 | virtio + VFIO + GPU passthrough |

| Live migration | 미지원 | 지원 |

| 사용처 | Lambda, Fly | Kata 옵션, Edera Protect, Intel TDX |

Edera Protect — 2024년 etcd 출신이 시작한 스타트업이 만든 "GPU와 confidential computing을 함께 지원하는 sandbox 플랫폼"이 Cloud Hypervisor를 기반으로 만들어진다.

14장 · WebAssembly 런타임 — runwasi shim으로 K8s에 진입

2024년 containerd가 runwasi shim을 정식 지원하면서, WebAssembly 모듈이 OCI 이미지처럼 K8s에 배포 가능해졌다.

핵심 Wasm 런타임 세 가지 (2026.5 기준):

| 런타임 | 만든 곳 | 강점 |

| --- | --- | --- |

| WasmEdge 0.14 | CNCF Sandbox | LLM·텐서 가속 확장, K8s 통합 우선 |

| Wasmtime 27 | Bytecode Alliance | 가장 폭넓은 WASI 지원, Reference impl |

| Wasmer 5.x | Wasmer Inc. | edge-first, AOT 컴파일 |

WebAssembly 컨테이너의 장점:

- **부팅 시간 < 1ms** — 진짜 cold start 1ms 미만.

- **메모리 < 1MB** — 함수 하나에 수십 KB.

- **언어 무관 portability** — Rust·Go·C·Python(파이오딘) 모두 가능.

단점:

- **WASI 표준이 아직 진화 중** — networking, filesystem이 컨테이너만큼 풍부하지 않다.

- **GPU/하드웨어 접근 제한** — WASI-NN으로 추론 정도는 가능하지만 학습은 어려움.

Spin(Fermyon)·WasmCloud·Wasmer Edge 같은 Wasm-first PaaS가 이 위에서 자라고 있다.

15장 · Confidential Containers — 메모리까지 암호화

Confidential Containers(CoCo)는 CNCF Sandbox 프로젝트로 2022년 출발해 2026년 정식 GA를 앞두고 있다. 핵심 — **호스트 커널이나 하이퍼바이저조차 컨테이너 메모리를 못 본다.**

기반 하드웨어:

- **AMD SEV-SNP** — Secure Encrypted Virtualization with Secure Nested Paging.

- **Intel TDX** — Trust Domain Extensions, 2024년 Xeon 5세대부터 본격화.

- **Arm CCA** — Confidential Compute Architecture, 2025년 Neoverse V3에서 일부 지원.

- **IBM Z SE** — Secure Execution.

흐름:

1. Kata Container를 띄울 때 hypervisor가 SEV-SNP 또는 TDX VM을 만든다.

2. attestation server가 부팅 측정값을 검증.

3. 검증 통과 후 secret을 주입.

쓰는 곳: Azure Confidential Containers, IBM Cloud Hyper Protect, 그리고 한국·일본의 금융권 컴플라이언스 워크로드. Edera Protect는 GPU 노드까지 confidential하게 만든다는 야심을 갖고 진행 중이다.

16장 · 이미지 포맷 — OCI v1.1과 zstd:chunked

2026년 5월 시점 컨테이너 이미지 포맷의 핵심 진화:

- **OCI image-spec 1.1** — 2024년 GA. artifact manifest 정식 지원, helm chart·SBOM·서명을 같은 레지스트리에 저장 가능.

- **OCI image-spec 1.2 RC** — 압축 알고리즘 협상 표준화, zstd-chunked 명시.

- **zstd:chunked** — Red Hat이 기여, partial pull이 가능해져서 대형 이미지에서 큰 효과. 1GB 이미지에서 변경된 80MB만 받는 시나리오가 가능.

- **ORAS (OCI Registry As Storage)** — 컨테이너 이미지가 아닌 임의 파일도 OCI 레지스트리에 저장. helm chart, Tekton task, AI 모델 weights를 docker.io나 ghcr.io에 push.

Docker v2.2(legacy) 이미지는 deprecated 표시되었고 2026년 안에 대부분 레지스트리에서 새 push가 막힐 예정이다.

17장 · 로컬 개발 — Docker Desktop, Podman Desktop, Rancher Desktop, Orbstack 비교

| 도구 | 백엔드 | 라이선스 | 강점 | 약점 |

| --- | --- | --- | --- | --- |

Mac 개발자 사이에서 2025년부터 가장 많이 들리는 이름은 Orbstack. 자체 작성한 경량 hypervisor로 Docker Desktop 대비 메모리 1/3, 시작 시간 1/5을 자랑한다.

리눅스 개발자는 굳이 Desktop 도구가 필요 없다 — 네이티브로 Podman이나 Docker Engine을 깔면 된다.

18장 · CI 환경 — Sysbox, DinD, Kaniko

CI에서 컨테이너를 빌드하거나 실행할 때 호스트 권한 노출이 늘 골치다.

- **Docker-in-Docker (DinD)** — docker:dind 이미지를 sidecar로 띄움. 가장 간단하지만 privileged 컨테이너 필요.

- **Kaniko** — Google이 만든 빌드 도구. Dockerfile을 root 권한 없이 빌드하고 push.

- **Buildah / podman build** — rootless 빌드 표준.

- **Sysbox** — Nestybox(2022 Docker 인수)가 만든 런타임. 컨테이너 안에서 systemd·Docker를 안전하게 돌릴 수 있다. 2026년 Apache 2.0으로 오픈소스화.

- **BuildKit + rootless** — 가장 일반적인 조합.

GitHub Actions·GitLab CI·Jenkins·Tekton 모두 2026년 들어 rootless 빌드를 기본 권장으로 옮겼다.

19장 · 서버리스 — Lambda Firecracker, Fly Machines, Cloud Run gVisor

서버리스/edge 진영의 격리 백엔드 매핑:

| 서비스 | 격리 방식 | 부팅 시간 |

| --- | --- | --- |

| AWS Lambda | Firecracker MicroVM | 100~300ms (cold) |

| AWS Fargate | Firecracker 또는 EC2 | 수초 |

| GCP Cloud Run | gVisor | 200~500ms |

| GCP App Engine Flexible | gVisor | 수초 |

| Azure Container Instances | Hyper-V Container 또는 Kata | 수초 |

| Fly.io Machines | Firecracker | 수백ms |

| Northflank | Firecracker + Cloud Hypervisor | 수백ms |

| Koyeb | Firecracker | 수백ms |

| Vercel Functions | V8 isolate 또는 AWS Lambda | 수십ms |

| Cloudflare Workers | V8 isolate | 5ms |

서버리스의 격리 모델은 점점 microVM과 V8 isolate 두 진영으로 수렴하는 추세다. 컨테이너 기반은 무겁고, V8 isolate는 Node.js·WASM에만 제한된다는 트레이드오프.

20장 · 한국·일본 진영 — 누가 무엇을 쓰는가

**한국**

- **NHN Cloud** — containerd 기본, 일부 노드 youki 실험. Confidential Container PoC 진행.

- **KT Cloud** — K-PaaS-TA(클라우드 파스 타) 위에서 containerd. CRI-O 옵션도 제공.

- **Naver Cloud** — 자체 컨테이너 서비스 NCS에 containerd, 멀티테넌트 함수에는 gVisor.

- **SK텔레콤** — 5G MEC 일부 노드 CRI-O, Confidential Container 도입 계획.

- **삼성SDS** — 사내 Brity Container Platform이 containerd + Kata 옵션.

**일본**

- **NTT Data / NTT Communications** — youki 후원, CRI-O 일부 도입.

- **라쿠텐** — 모바일 RAN 컨테이너에 containerd + Kata.

- **사이버에이전트** — AKE(Adtech Container Engine)에 containerd.

- **야후재팬 / LINE** — 멀티테넌트에 Kata 일부.

- **AWS 도쿄 / GCP 도쿄 / Azure 도쿄** — 글로벌과 동일 스택.

흥미로운 점은 youki가 일본 발 프로젝트라는 데서 일본 클라우드 업체들의 후원이 두텁다는 것.

21장 · 어떤 런타임을 골라야 하나 — 의사결정 트리

질문 1. 어떤 환경?

├─ Kubernetes 클러스터

│ ├─ Red Hat 생태계? → CRI-O + crun

│ └─ 그 외 → containerd + runc

├─ 로컬 개발 (Mac)

│ ├─ 빠른 게 중요 → Orbstack

│ ├─ 오픈소스 우선 → Podman Desktop

│ └─ 호환성 최우선 → Docker Desktop

└─ 로컬 개발 (Linux) → Podman 또는 Docker Engine

질문 2. 격리가 얼마나 강해야?

├─ 일반 격리 → runc / crun (namespaces + cgroups)

├─ 멀티테넌트 SaaS → gVisor 또는 Kata

├─ 메모리까지 보호 → Confidential Containers (Kata + SEV-SNP/TDX)

└─ 가장 빠른 부팅 → Firecracker MicroVM 또는 Wasm

질문 3. 워크로드 특성?

├─ FaaS / 짧은 함수 → Wasm (WasmEdge, Spin) or Firecracker

├─ 장기 실행 서비스 → 일반 컨테이너 (containerd + runc)

├─ 데이터 인텐시브 → 일반 컨테이너, syscall 많으면 gVisor 피하기

└─ AI/ML 추론 → 일반 컨테이너 + GPU operator

22장 · 마치며 — 2026년의 런타임 풍경

2026년 5월 현재 정리하면:

1. **클러스터 표준은 containerd 2.0** — Kubernetes 디스트리뷰션 대다수의 디폴트.

2. **Red Hat 생태계는 CRI-O + crun + Podman** — OpenShift 사용자라면 이 셋이 일관된 선택.

3. **로컬 개발은 다양화** — Docker Desktop, Podman Desktop, Rancher Desktop, Orbstack이 공존.

4. **멀티테넌트는 gVisor 또는 Kata** — 클라우드 공급자에 따라 다름.

5. **서버리스는 Firecracker MicroVM 또는 V8 isolate** — 컨테이너는 너무 무거움.

6. **Wasm은 본격 진입 시작** — runwasi shim 덕에 K8s에 정상적으로 들어옴.

7. **Confidential Containers는 2026년 후반 정식 GA 예상** — AMD SEV-SNP·Intel TDX가 충분히 성숙.

8. **youki·crun 같은 대안 OCI 런타임이 자라는 중** — Rust와 C 진영에서 runc를 흔드는 중.

런타임 선택은 "성능 vs 격리 vs 호환성"의 삼각형이다. 한 가지 답은 없다. 다만 이 글에 그린 지도를 들고 들어가면, 어느 꼭짓점으로 가야 할지 다섯 번째 질문쯤에서 결정할 수 있을 것이다.

참고 자료 (References)

1. Open Container Initiative — [https://opencontainers.org/](https://opencontainers.org/)

2. OCI Runtime Specification — [https://github.com/opencontainers/runtime-spec](https://github.com/opencontainers/runtime-spec)

3. OCI Image Specification — [https://github.com/opencontainers/image-spec](https://github.com/opencontainers/image-spec)

4. OCI Distribution Specification — [https://github.com/opencontainers/distribution-spec](https://github.com/opencontainers/distribution-spec)

5. runc — [https://github.com/opencontainers/runc](https://github.com/opencontainers/runc)

6. crun — [https://github.com/containers/crun](https://github.com/containers/crun)

7. youki — [https://github.com/youki-dev/youki](https://github.com/youki-dev/youki)

8. containerd — [https://containerd.io/](https://containerd.io/)

9. CRI-O — [https://cri-o.io/](https://cri-o.io/)

10. Podman — [https://podman.io/](https://podman.io/)

11. Buildah — [https://buildah.io/](https://buildah.io/)

12. Skopeo — [https://github.com/containers/skopeo](https://github.com/containers/skopeo)

13. Docker — [https://www.docker.com/](https://www.docker.com/)

14. BuildKit — [https://github.com/moby/buildkit](https://github.com/moby/buildkit)

15. gVisor — [https://gvisor.dev/](https://gvisor.dev/)

16. Kata Containers — [https://katacontainers.io/](https://katacontainers.io/)

17. Firecracker — [https://firecracker-microvm.github.io/](https://firecracker-microvm.github.io/)

18. Cloud Hypervisor — [https://www.cloudhypervisor.org/](https://www.cloudhypervisor.org/)

19. WasmEdge — [https://wasmedge.org/](https://wasmedge.org/)

20. Wasmtime — [https://wasmtime.dev/](https://wasmtime.dev/)

21. Wasmer — [https://wasmer.io/](https://wasmer.io/)

22. runwasi — [https://github.com/containerd/runwasi](https://github.com/containerd/runwasi)

23. Spin (Fermyon) — [https://www.fermyon.com/spin](https://www.fermyon.com/spin)

24. WasmCloud — [https://wasmcloud.com/](https://wasmcloud.com/)

25. Confidential Containers — [https://github.com/confidential-containers](https://github.com/confidential-containers)

26. Edera Protect — [https://edera.dev/](https://edera.dev/)

27. Kubernetes CRI — [https://kubernetes.io/docs/concepts/architecture/cri/](https://kubernetes.io/docs/concepts/architecture/cri/)

28. Orbstack — [https://orbstack.dev/](https://orbstack.dev/)

29. Rancher Desktop — [https://rancherdesktop.io/](https://rancherdesktop.io/)

30. Sysbox — [https://github.com/nestybox/sysbox](https://github.com/nestybox/sysbox)