1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • 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 미만
  • 불신 코드 샌드박싱

    • 하이퍼바이저 경계를 통해 호스트 파일시스템, 네트워크, 자격증명을 완전히 분리
    • 기본 네트워크는 비활성화 상태이며, --allow-host 옵션으로 특정 호스트만 허용 가능
  • 지속형 개발용 VM

    • machine create, start, stop 명령으로 VM 생성 및 관리
    • 설치된 패키지가 재시작 후에도 유지되어 개발 환경으로 활용 가능
  • SSH 에이전트 포워딩

    • 호스트의 SSH 에이전트를 VM 내부로 전달하되, 개인키는 게스트로 복사되지 않음
    • --ssh-agent 옵션으로 호스트의 SSH 인증을 안전하게 활용 가능
  • Smolfile 기반 환경 선언

    • TOML 형식의 Smolfile로 VM 설정을 선언
    • 이미지, 네트워크, 초기화 명령, 볼륨, 인증 옵션 등을 지정해 재현 가능한 환경 구성 가능

사용 예시

  • 임시 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초 미만 부팅 시간을 달성하기 위해 가장 어려웠던 설계 과제가 무엇이었는지 궁금함
      그리고 그 시간을 더 줄이려면 현재 어떤 병목 구간이 있는지도 알고 싶음
  • 이 프로젝트가 여러 unikernel 구현체들과 비슷하게 들림 — 예를 들어 Unikraft 같은 것들

    • Unikraft의 내부는 오픈소스가 아니라 잘 모르겠음
      하지만 Smol Machines는 unikernel 구현이 아니라, 리눅스 커널을 슬림화한 버전
      그래서 대부분의 소프트웨어와 호환성이 높음
  • 자급자족형 바이너리 생성 기능이 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 같은 툴도 이런 방식으로 배포되면 좋겠음
    • 다들 한 번쯤 “개발 환경을 망쳐버린 경험”이 있을 것임
      이건 그런 문제를 해결하기 위한 ‘배포 가능한 머신’ 개념임
      한 번 세팅만 잘 하면 누구에게나 바로 공유하고 실행할 수 있음
  • .smolmachine 파일이 디지털 서명 및 자체 인증을 지원하는지 궁금함
    Sylabs의 서명/검증 문서처럼 동작할 수 있는지 알고 싶음

  • zeroboot의 아이디어를 적용하면 더 빠르게 만들 수 있을지 궁금함

  • 비교표가 정말 잘 되어 있음
    처음엔 “Firecracker랑 비슷하네” 싶었는데, 표를 보고 차이점이 명확하게 보였음
    보기 쉬웠고, 전체적으로 매우 인상적인 작업

    • 고마움
  • CLI 문서에서 alpinepython: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를 써야 하는 핵심 이유가 무엇인지, 짧게 설명해줄 수 있는지 궁금함

  • 정말 멋진 결과물임. 축하함