---
title: "Show HN에 뜬 smolvm — 200ms 콜드스타트, 포터블 microVM을 한 파일로"
published: 2026-04-17T17:18:58.000Z
canonical: https://jeff.news/article/1785
---
# Show HN에 뜬 smolvm — 200ms 콜드스타트, 포터블 microVM을 한 파일로

macOS Hypervisor.framework와 Linux KVM 위에 libkrun 기반 microVM을 띄워 서브초 콜드스타트와 워크로드당 하드웨어 격리를 제공하는 CLI 도구. OCI 이미지를 Docker 데몬 없이 그대로 풀해서 부팅하고, VM 상태를 .smolmachine 단일 파일로 패킹해 어디서든 하이드레이트할 수 있다. virtio balloon으로 메모리를 엘라스틱하게 쓰고 SSH 에이전트 포워딩으로 개인키가 게스트에 진입하지 않게 막는 구조가 특징.

- **smolvm** — 서브초 콜드스타트로 뜨는 로컬 Linux VM을 관리·실행하는 CLI 도구가 Show HN에 올라옴
  - 부팅 200ms 미만, macOS·Linux 크로스플랫폼, 메모리는 virtio balloon으로 **엘라스틱**하게 잡아먹고 자동 반환
  - VM 하나를 통째로 `.smolmachine` 파일 하나로 패킹해서 아키텍처만 맞으면 어디서든 하이드레이트 가능

### 뭐가 가능한데
- **신뢰 안 가는 코드 샌드박싱** — 하드웨어 격리된 VM에서 돌리니 호스트 파일시스템·네트워크·자격증명이 하이퍼바이저 경계 밖에 있음
- **포터블 실행파일로 패킹** — 워크로드를 자립형 바이너리로 묶고 의존성 프리베이크. 설치 단계도 없고 런타임 다운로드도 없음
- **개발용 퍼시스턴트 머신** — create/stop/start 사이클에서 설치한 패키지가 재시작해도 살아남음
- **SSH 에이전트 포워딩** — 호스트 `ssh-agent`를 VM으로 포워드해 개인키가 게스트로 절대 안 들어감. 하이퍼바이저가 이 경계를 강제함
- **Smolfile로 환경 선언** — TOML 기반 재현 가능 VM 설정

### 경쟁자와의 비교표가 눈에 띔

> [!IMPORTANT]
> 핵심 차별화 — **워크로드당 VM 한 개**, 부팅 <200ms, macOS 네이티브, 임베더블 SDK, 포터블 아티팩트 지원. 컨테이너·Colima·QEMU·Firecracker·Kata 전부 이 조합을 못 맞춤

- 컨테이너는 네임스페이스 공유 커널 — 격리 약함
- Firecracker는 <125ms로 빠르지만 macOS 네이티브 지원 X, 포터블 아티팩트도 X
- Kata는 컨테이너당 VM이지만 macOS X, SDK 없음

### 아래가 어떻게 움직이냐
- 각 워크로드에 **진짜 하드웨어 격리** — macOS Hypervisor.framework 또는 Linux KVM 위에 자기 커널
- VMM은 **libkrun**, 커스텀 커널은 **libkrunfw**
- 이미지는 **OCI 포맷** — Docker Hub, ghcr.io 등 OCI 레지스트리 이미지를 그대로 풀해서 microVM으로 부팅. **Docker 데몬 필요 없음**
- 기본값 4 vCPU, 8GiB RAM. 메모리는 virtio balloon으로 게스트가 실제 쓰는 만큼만 커밋되고 나머지는 자동 회수
- idle 시 vCPU 스레드는 하이퍼바이저에서 잠들어서 **오버프로비전 코스트가 사실상 0**

### 제약 사항도 솔직함
- 네트워크는 opt-in (`--net`), TCP/UDP만 지원 (ICMP X)
- 볼륨 마운트는 디렉토리만 가능 (단일 파일 X)
- macOS는 Hypervisor.framework 엔타이틀먼트로 바이너리 서명 필수
- Linux는 `/dev/kvm` 필요 (x86_64/aarch64 양쪽 지원)
- `--ssh-agent`는 호스트에 에이전트 실행 중이어야 함 (`SSH_AUTH_SOCK` 세팅 필수)
- GPU 지원은 별도 브랜치에서 작업 중

---

## 기술 맥락

**libkrun**이 이 프로젝트의 심장이에요. Red Hat이 만든 동적 라이브러리 형태의 VMM인데, 앱 프로세스에 VM 실행 능력을 "라이브러리로" 붙일 수 있다는 게 독특해요. QEMU나 Firecracker처럼 별도 데몬/프로세스를 띄우지 않고 CLI 바이너리 안에서 microVM이 바로 떠요. 그래서 부팅이 200ms 미만까지 내려가고, 패킹된 `.smolmachine` 하나로 자립형 실행이 가능한 거죠.

**OCI 이미지를 Docker 데몬 없이** 쓸 수 있다는 점이 실무적으로 중요해요. 보통 OCI 이미지를 microVM으로 돌리려면 중간에 변환 파이프라인이 필요한데, smolvm은 레지스트리에서 바로 풀해서 커널 위에 마운트해버리거든요. 즉 기존 Dockerfile 자산을 버리지 않고도 더 강한 격리를 얻을 수 있어요.

**virtio balloon 기반 엘라스틱 메모리**는 데스크톱 VM의 고질병을 해결한 지점이에요. 8GiB 할당하면 보통 게스트가 안 써도 호스트에서 그만큼 잡혀 있잖아요. virtio balloon 드라이버가 게스트 커널과 협력해서 실제 사용량만 호스트에 커밋하고 나머지를 반환하니까, VM을 "부담 없이 많이 띄우는" 워크플로가 가능해지는 거예요.

하이퍼바이저 경계로 **SSH 에이전트를 포워딩**하는 모델도 주목할 만해요. 신뢰 안 가는 코드를 VM에서 돌릴 때 "git push는 하고 싶은데 개인키는 노출 싫은" 시나리오가 많거든요. 에이전트 프로토콜만 유닉스 소켓 경유로 포워드하고 키 자체는 게스트에 절대 진입 못하게 막으니까, 기존 컨테이너 개발 환경보다 보안 모델이 한 단계 올라가요.

## 핵심 포인트

- 부팅 200ms 미만, macOS·Linux 크로스플랫폼, 워크로드당 VM 격리
- libkrun 라이브러리 VMM 기반이라 별도 데몬 없이 CLI 바이너리로 microVM 실행
- OCI 이미지(Docker Hub, ghcr.io 등)를 Docker 데몬 없이 바로 부팅 가능
- virtio balloon 기반 엘라스틱 메모리로 실제 사용량만 호스트에 커밋
- SSH 에이전트 포워딩으로 개인키가 게스트에 들어가지 않도록 하이퍼바이저가 강제

## 인사이트

컨테이너의 가벼움과 VM의 격리를 동시에 노리는 프로젝트들이 늘어나는 흐름에서, smolvm은 macOS 네이티브 지원과 포터블 단일 파일 아티팩트라는 실용적 포인트로 차별화한다. Firecracker가 서버 전용이라면 이쪽은 개발자 데스크톱 워크플로를 겨냥한 느낌이 강하다.