Smol machines – 서브초 콜드스타트, 이식 가능한 가상머신
(github.com/smol-machines)- smolvm은 macOS와 Linux에서 동작하는 CLI 기반 가상머신 관리 도구로, 격리된 환경에서 소프트웨어를 실행함
- 서브초(1초 미만) 콜드스타트, 탄력적 메모리 관리, 단일 파일 이식성을 지원해 빠르고 가벼운 VM 실행 가능
- VM은 리눅스 커널 기반 마이크로VM 형태로 구동되며,
.smolmachine파일로 패키징해 의존성 없이 재실행 가능 - 하이퍼바이저 경계 격리, SSH 에이전트 포워딩, Smolfile 기반 환경 선언 등으로 개발·보안 환경을 통합 지원
- Docker 데몬 없이 OCI 이미지 부팅을 지원하며, 200ms 미만 부팅 시간과 하드웨어 수준 격리로 경량 가상화 대안 제시
개요
- smolvm은 격리된 환경에서 소프트웨어를 실행하기 위한 CLI 기반 가상머신 관리 도구
- macOS와 Linux에서 동작하며, 서브초 콜드스타트, 탄력적 메모리 사용, 이식 가능한 단일 파일 패키징을 지원
- 각 워크로드는 리눅스 커널 기반 마이크로VM으로 실행되며, 하드웨어 수준의 격리를 제공
.smolmachine파일로 패키징된 VM은 동일 아키텍처의 플랫폼에서 의존성 없이 재실행 가능
주요 기능
-
로컬 가상머신 관리 및 실행
smolvm machine run명령으로 커스텀 리눅스 VM 실행- 콜드스타트는 1초 미만이며, macOS와 Linux 모두 지원
- 메모리는 virtio balloon으로 탄력 관리되어 실제 사용량만 호스트에 할당됨
-
이식 가능한 단일 파일 패키징
- VM 상태를 포함한
.smolmachine파일로 묶어 다른 플랫폼에서 재생성 가능 - 모든 의존성이 내장되어 설치 없이 즉시 실행 가능, 부팅 시간은 200ms 미만
- VM 상태를 포함한
-
불신 코드 샌드박싱
- 하이퍼바이저 경계를 통해 호스트 파일시스템, 네트워크, 자격증명을 완전히 분리
- 기본 네트워크는 비활성화 상태이며,
--allow-host옵션으로 특정 호스트만 허용 가능
-
지속형 개발용 VM
machine create,start,stop명령으로 VM 생성 및 관리- 설치된 패키지가 재시작 후에도 유지되어 개발 환경으로 활용 가능
-
SSH 에이전트 포워딩
- 호스트의 SSH 에이전트를 VM 내부로 전달하되, 개인키는 게스트로 복사되지 않음
--ssh-agent옵션으로 호스트의 SSH 인증을 안전하게 활용 가능
-
Smolfile 기반 환경 선언
- TOML 형식의
Smolfile로 VM 설정을 선언 - 이미지, 네트워크, 초기화 명령, 볼륨, 인증 옵션 등을 지정해 재현 가능한 환경 구성 가능
- TOML 형식의
사용 예시
-
임시 VM 실행
smolvm machine run --net --image alpine -- sh -c "echo 'Hello world'"- 종료 시 VM이 자동 정리되는 일회성 실행 방식
-
패키징된 실행 파일 생성
smolvm pack create --image python:3.12-alpine -o ./python312- 생성된 실행 파일로 독립적인 Python 환경 실행 가능
-
네트워크 제어
- 기본 네트워크는 비활성화
--allow-host옵션으로 특정 도메인만 접근 허용
-
SSH 및 Git 사용
smolvm machine run --ssh-agent --net --image alpine- 호스트의 SSH 키를 안전하게 사용해 Git 리포지토리 접근 가능
내부 구조 및 동작 방식
- 각 워크로드는 Hypervisor.framework(macOS) 또는 KVM(Linux) 위에서 독립 커널을 실행
- libkrun 기반 VMM과 커스텀 커널(libkrunfw) 을 사용
- OCI 이미지 포맷을 지원해 Docker Hub, ghcr.io 등에서 이미지를 직접 가져와 실행 가능
- Docker 데몬 불필요, 표준 OCI 이미지를 그대로 부팅 가능
- 기본 설정은 4 vCPU, 8GiB RAM,
--cpus,--mem옵션으로 조정 가능 - vCPU 스레드는 유휴 시 하이퍼바이저에서 자동 절전되어 과할당 비용이 거의 없음
비교
| 항목 | smolvm | Containers | Colima | QEMU | Firecracker | Kata |
|---|---|---|---|---|---|---|
| 격리 수준 | 워크로드별 VM | 네임스페이스(공유 커널) | 네임스페이스(단일 VM) | 개별 VM | 개별 VM | 컨테이너별 VM |
| 부팅 시간 | <200ms | 약 100ms | 수 초 | 15~30초 | <125ms | 약 500ms |
| 아키텍처 | 라이브러리(libkrun) | 데몬 | VM 내 데몬 | 프로세스 | 프로세스 | 런타임 스택 |
| 워크로드별 VM | 지원 | 미지원 | 공유 | 지원 | 지원 | 지원 |
| macOS 네이티브 | 지원 | Docker VM 경유 | krunkit 기반 | 지원 | 미지원 | 미지원 |
| SDK 내장 | 지원 | 미지원 | 미지원 | 미지원 | 미지원 | 미지원 |
| 이식 가능한 아티팩트 | .smolmachine |
데몬 필요 이미지 | 미지원 | 미지원 | 미지원 | 미지원 |
플랫폼 지원
| 호스트 | 게스트 | 요구사항 |
|---|---|---|
| macOS Apple Silicon | arm64 Linux | macOS 11 이상 |
| macOS Intel | x86_64 Linux | macOS 11 이상 (테스트 미완료) |
| Linux x86_64 | x86_64 Linux | KVM(/dev/kvm) 필요 |
| Linux aarch64 | aarch64 Linux | KVM(/dev/kvm) 필요 |
알려진 제한 사항
- 네트워크는 기본 비활성화,
--net옵션으로만 활성화 가능 - TCP/UDP만 지원, ICMP 미지원
- 볼륨 마운트는 디렉터리 단위만 가능, 단일 파일은 불가
- macOS에서는 Hypervisor.framework 권한으로 서명된 바이너리만 실행 가능
--ssh-agent사용 시 호스트에 SSH 에이전트가 실행 중이어야 함 (SSH_AUTH_SOCK설정 필요)
개발 관련
- 개발 지침은
docs/DEVELOPMENT.md에서 확인 가능 - Apache-2.0 라이선스로 공개되어 있으며, @binsquare가 제작
Hacker News 의견들
-
나는 Docker 컨테이너를 대체할 가상머신을 만들고 있음
컨테이너의 사용성(ergonomics)을 그대로 유지하면서도 1초 미만의 시작 시간을 목표로 함
AWS에서 Firecracker 관련 일을 하며 컨테이너가 불필요한 레이어라는 걸 깨달았고, Firecracker는 AWS 내부 구조에 맞춰 설계된 기술이었음
그래서 컨테이너의 장점과 Firecracker의 장점을 결합한 하이브리드 형태를 직접 만들게 되었음
의견을 듣고 싶음- 이거 정말 멋짐. 나도 AI 샌드박싱 솔루션을 연구하다가 Lima+Incus 조합으로 Locki를 만들었음
microVM은 보통 Docker나 Kubernetes를 실행하지 못해서 고민이었음
나는 전체 Kubernetes 클러스터를 샌드박스 안에 넣고 싶음. 혹시 k3s 실행도 지원하는지 궁금함 - 라이브 마이그레이션 지원 상태가 어떤지 궁금함
비슷한 시스템에서 항상 빠지는 기능인데, 클라우드 네이티브 워크로드 외에도 여전히 그런 기능이 필요한 환경이 많음
만약 이 기능을 넣는다면 진짜 차별화 포인트가 될 것 같음 - 코드 중 어느 정도가 LLM/AI로 작성된 부분인지 궁금함
- 나도 비슷한 걸 만들어봤음 — 이름은 shuru.run
Firecracker가 macOS에서 안 돌아가서, AI 앱용 microVM 샌드박스를 쉽게 만들고 싶었음
일반 사용자 입장에서는 Firecracker가 너무 무거움 - 1초 미만 부팅 시간을 달성하기 위해 가장 어려웠던 설계 과제가 무엇이었는지 궁금함
그리고 그 시간을 더 줄이려면 현재 어떤 병목 구간이 있는지도 알고 싶음
- 이거 정말 멋짐. 나도 AI 샌드박싱 솔루션을 연구하다가 Lima+Incus 조합으로 Locki를 만들었음
-
이 프로젝트가 여러 unikernel 구현체들과 비슷하게 들림 — 예를 들어 Unikraft 같은 것들
- Unikraft의 내부는 오픈소스가 아니라 잘 모르겠음
하지만 Smol Machines는 unikernel 구현이 아니라, 리눅스 커널을 슬림화한 버전임
그래서 대부분의 소프트웨어와 호환성이 높음
- Unikraft의 내부는 오픈소스가 아니라 잘 모르겠음
-
자급자족형 바이너리 생성 기능이 JVM 앱을 GraalVM Native보다 더 간단히 패키징할 수 있는 방법처럼 보임
예시 명령어:
smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
→ Python 3.12.x가 완전히 격리된 상태로 실행됨, pyenv/venv/conda 불필요함- 이건 Electron과 비슷한 개념임
Electron이 웹앱을 브라우저와 함께 배포하듯, Smol Machines는 소프트웨어를 리눅스 VM과 함께 패키징함
의존성 관리나 호환성 문제를 피할 수 있음
개인적으로 Codex나 Claude Code 같은 툴도 이런 방식으로 배포되면 좋겠음 - 다들 한 번쯤 “개발 환경을 망쳐버린 경험”이 있을 것임
이건 그런 문제를 해결하기 위한 ‘배포 가능한 머신’ 개념임
한 번 세팅만 잘 하면 누구에게나 바로 공유하고 실행할 수 있음
- 이건 Electron과 비슷한 개념임
-
.smolmachine파일이 디지털 서명 및 자체 인증을 지원하는지 궁금함
Sylabs의 서명/검증 문서처럼 동작할 수 있는지 알고 싶음 -
zeroboot의 아이디어를 적용하면 더 빠르게 만들 수 있을지 궁금함
-
비교표가 정말 잘 되어 있음
처음엔 “Firecracker랑 비슷하네” 싶었는데, 표를 보고 차이점이 명확하게 보였음
보기 쉬웠고, 전체적으로 매우 인상적인 작업임- 고마움
-
CLI 문서에서 alpine과 python:3.12-alpine 이미지를 봤는데, 이게 어디서 오는지 궁금함
Docker 레지스트리 같은 곳에서 가져오는 건지, 내장된 건지, 아니면 smolfile로 직접 만드는 건지 알고 싶음
Ubuntu 이미지도 있는지 궁금함
메모리/CPU 핫 리사이즈 기능이 추가되면 좋겠고, 고객별 백엔드 인프라 오케스트레이션에도 쓸 수 있을 것 같음 -
대부분의 오픈소스 프로젝트가 Docker Compose로 컨테이너를 띄우는데, Smol Machines는 microVM 안에서 Docker를 지원하지 않음
또한 Vagrant 같은 nested VM도 지원하지 않아서 아쉬움- Docker는 지원 예정임. 다음 릴리스에서 필요한 커널 플래그를 포함한 호환 커널을 배포할 계획임
- Vagrant가 로컬에서 VM을 띄우기 때문에 nesting이 필요한 것 같음
대신 트램펄린 방식으로 Vagrant VM의 형제 VM으로 실행하는 건 어떤지 제안함
-
Docker 샌드박스 대신 Smol Machines를 써야 하는 핵심 이유가 무엇인지, 짧게 설명해줄 수 있는지 궁금함
-
정말 멋진 결과물임. 축하함