MacBook M3에서 Firecracker MicroVM 돌리기 — Docker 대체의 가능성

Docker한테 왜 계속 기다려야 하지?

• 8K 영상을 실시간 렌더링할 수 있는 M3 MacBook Pro에서 Node.js 컨테이너 시작에 5분을 기다리고 있는 자신을 발견하고 Firecracker를 파봤다는 이야기
• Firecracker는 AWS Lambda와 Fargate를 구동하는 기술로, 이제 Apple Silicon에서 네이티브로 돌아감

MicroVM이 뭔데?

• 전통적 VM처럼 GUI 딸린 무거운 가상머신이 아니고, 컨테이너처럼 커널을 공유하는 것도 아님. 그 사이 어딘가에 있는 최소한의 보안 가상머신인데, 부팅 시간이 125밀리초임
• Docker 컨테이너가 네트워킹을 설정하는 동안 Firecracker는 이미 Linux 환경 생성 → SSH 연결 → 명령 실행 → VM 종료까지 끝냄

M3 칩의 하드웨어 가상화

• Apple Silicon은 하드웨어 레벨에서 가상화가 설계됨. Firecracker의 미니멀 디자인과 M3의 하드웨어 가속이 합쳐지면:
  • 네이티브 ARM64 성능 (x86 에뮬레이션 오버헤드 없음)
  • 하드웨어 수준 격리 (커널 네임스페이스가 아님)
  • 컨테이너가 뚱뚱해 보이는 메모리 효율성

셋업 방법

• Lima를 브릿지로 사용. brew install lima 후 nestedVirtualization=true 플래그로 시작하면 M3의 가상화 코어를 활성화함
• Lima VM 안에서 Firecracker aarch64 바이너리를 받아서 설치하고, 커널과 Ubuntu rootfs를 S3에서 다운로드
• TAP 디바이스 생성 + NAT 설정으로 microVM에 인터넷 연결. 셋업 스크립트 하나로 자동화 가능

벤치마크: Docker vs Firecracker (같은 M3 머신)

항목	Docker	Firecracker
콜드 스타트	3.2초	0.125초
메모리 사용량	150MB	25MB
네트워크 지연	0.8ms	0.3ms
격리 수준	네임스페이스	하드웨어

어디에 쓰면 좋고, 어디엔 안 맞나

• 잘 맞는 곳: CI/CD 파이프라인 (시작 시간이 중요), 재현 가능한 개발 환경, 멀티테넌트 격리, 서버리스 함수, 격리된 테스트 환경

• 안 맞는 곳: GUI 앱 (디스플레이 서버 없음), 무거운 DB 워크로드, 풀 리눅스 배포판이 필요한 레거시 앱

• 저자는 현재 M3에서 microVM 5개를 동시에 돌리고 있는데 총 메모리 사용량 150MB, 각각 200ms 이내에 부팅됨. "Docker daemon not running", "port already in use" 같은 짜증에서 해방됐다는 거임

• 셋업 저장소: git clone https://github.com/yashdiq/firecracker-lima-vm.git — 약 15분이면 완료