Smolvm에 HN이 다시 꺼낸 질문: container 대신 microVM이면 충분한가

smolvm은 “software를 isolation by default로 ship and run”하겠다는 CLI다. README 기준으로 macOS와 Linux에서 custom Linux virtual machine을 sub-second cold start로 실행하고, stateful VM을 하나의 .smolmachine 파일로 pack해 다른 지원 플랫폼에서 rehydrate할 수 있다. HN에서 반응이 나온 이유는 container와 VM의 경계를 다시 찌르는 도구였기 때문이다.

프로젝트는 untrusted code를 host filesystem, network, credentials에서 떼어내고, network를 기본 off로 두며, 필요할 때 특정 host만 허용하는 흐름을 보여준다. 또 python:3.12-alpine 같은 OCI image를 가져와 self-contained binary로 pack하는 예시도 제시한다. README의 비교표는 container의 shared kernel 대신 workload마다 VM을 주고, macOS에서는 Hypervisor.framework, Linux에서는 KVM 위에서 동작한다고 설명한다.

HN discussion에서 만든 사람은 Docker container를 대체하는 방향을 보고 있으며, Firecracker 경험에서 container layer와 AWS 내부 use case의 무게를 덜어낸 hybrid라고 설명했다. 댓글들은 바로 현실적인 질문으로 갔다. OCI registry에서 image를 가져오는 방식, .smolmachine 서명, Windows/WSL 지원, Docker-in-VM이나 nested VM 부재 같은 제한이 쟁점이었다.

특히 agent 시대에는 이 질문이 더 실용적이다. coding agent, eval runner, plugin sandbox는 빠른 start와 강한 isolation을 동시에 원한다. container는 빠르지만 shared kernel이고, 전통적인 VM은 무겁다. smolvm은 그 사이를 노리며, host SSH agent forwarding처럼 개발 workflow를 망가뜨리지 않는 기능도 넣었다.

아직 limitation도 분명하다. network는 opt-in이고, volume mount는 directory 단위이며, GPU support는 별도 branch에서 작업 중이다. 그래도 HN이 본 핵심은 명확했다. agent가 낯선 code를 더 자주 실행할수록, “가벼운 VM”은 다시 매력적인 기본 단위가 된다.