Firecracker microVM 쉽게 이해하기: 1초도 안 걸려 부팅되는 진짜 VM

AI가 생성한 코드를 안전하게 실행하는 방법에 관해 무엇이든 읽어 봤다면 microVM이라는 단어를 봤을 겁니다. 대개 Firecracker 옆에 있습니다. 설명은 보통 '가벼운 VM'(맞지만 도움이 안 됨)이거나 커널 내부 구조도입니다. 여기서는 그 중간 버전을 소개합니다.

오래된 두 가지 선택지, 그리고 둘 다 맞지 않는 이유

microVM이 그 사이에 놓인 두 가지부터 시작하겠습니다.

컨테이너는 여러분의 머신 위에 있는 평범한 프로세스 묶음으로, 커널이 그들에게 '거짓말'을 해 주기로 한 것입니다. namespaces는 그들에게 자기만의 파일 시스템, 프로세스 목록, 네트워크를 보여 주고, cgroups는 쓸 수 있는 CPU와 메모리 양을 제한합니다. 새로 부팅하는 게 없으니 밀리초 만에 시작됩니다. 하지만 한 호스트의 모든 컨테이너는 같은 커널과 대화합니다. 한 컨테이너 안에서 닿을 수 있는 커널 버그는 모든 컨테이너의 탈출구가 됩니다.

가상 머신은 자기 커널을 가져옵니다. 호스트의 CPU는 하드웨어 가상화(Linux에서는 KVM)를 통해 게스트를 마치 자기 컴퓨터를 가진 것처럼 실행합니다. 경계는 하이퍼바이저이며, 커널의 수백 가지 시스템 콜보다 훨씬 적은 것만 노출합니다. 대가는 무게입니다. 전통적인 VM은 PC 전체를 에뮬레이션합니다. 펌웨어, PCI 버스, USB 컨트롤러, 그래픽 카드, 때로는 사운드 카드까지. 그 모든 것을 거쳐 부팅하므로 몇 초에서 몇 분이 걸리고, 인스턴스마다 수십에서 수백 메가바이트의 오버헤드를 안고 갑니다.

꽤 잘 들어맞는 비유가 있습니다. 컨테이너는 한 건물 안의 아파트로, 기초와 배관과 배선을 공유합니다. VM은 따로 떨어진 단독 주택입니다. 단독 주택이 더 안전한 이웃이지만, 20초짜리 방문을 위해 집을 짓는 사람은 없습니다.

Firecracker가 없앤 것

Firecracker는 virtual machine monitor(KVM 위에서 VM을 설정하고 실행하는 프로그램)로, Rust로 작성되었고 2018년에 오픈 소스로 공개되었습니다. 목적은 하나, 서로를 신뢰하지 않는 짧은 수명의 워크로드를 공유 하드웨어 위에서 엄청나게 많이 실행하는 것입니다. 그 목표에는 주로 무언가를 지워서 도달했습니다.

• 펌웨어 없음, 하드웨어 탐색 없음. 커널을 메모리에 바로 로드하고 시작합니다. 존재하지 않는 디바이스를 찾아다니는 것은 없습니다.
• 아주 작은 디바이스 모델. 네트워크 카드, 블록 디바이스, 시리얼 콘솔 등 몇 개뿐이며, 모두 virtio(물리 장치를 흉내 내는 대신 가상 머신용으로 설계된 디바이스)입니다. USB도, 그래픽도, PCI도 없습니다.
• 작고 메모리 안전한 코드베이스. 디바이스를 에뮬레이션하는 코드가 적을수록 게스트가 호스트에 닿게 하는 버그가 숨을 곳도 적습니다.
• VMM 자체를 둘러싼 감옥. 각 Firecracker 프로세스는 chroot 안에서 실행되며, 자신의 시스템 콜은 seccomp 필터로, 자원은 cgroups로 제한됩니다. 무언가가 게스트를 빠져나오더라도 호스트가 아니라 우리 안에 떨어지게 됩니다.

프로젝트가 직접 공개한 수치는 최소 125ms 만에 사용자 공간에 진입하고, microVM당 메모리 오버헤드가 5MiB 미만이라는 것입니다. 이는 최상의 실험실 수치입니다. 실제 샌드박스는 디스크와 네트워크를 준비하고 명령을 받을 에이전트가 안에서 준비되어야 하므로, 우리 샌드박스는 약 1초 만에 준비됩니다. 그래도 작업마다 하나씩 만들고 끝나면 버릴 수 있을 만큼 컨테이너 속도에 가깝습니다.

컨테이너 대 microVM, 실제로는

중요한 건 두 번째 행입니다. 컨테이너에서 '이 코드가 탈출할 수 있나?'라는 질문은 '호스트 커널 어딘가에 닿을 수 있는 버그가 있나?'가 됩니다. microVM에서는 '하이퍼바이저나 몇 안 되는 가상 디바이스에 버그가 있나?'가 됩니다. 후자의 표면이 훨씬 작고, 클라우드 플랫폼들이 자신의 멀티테넌트 호스팅을 위해 이미 방어하고 있는 쪽도 바로 이것입니다.

포기하는 것

microVM은 공짜 업그레이드가 아닙니다.

• GPU도 화면도 없습니다. 코드 실행용이지, 데스크톱이나 그래픽 워크로드용이 아닙니다.
• 디바이스가 적고 유연성도 떨어집니다. 실제 하드웨어나 긴 커널 모듈 목록을 기대하는 것은 편하게 돌아가지 않습니다.
• 경계에는 여전히 정책이 필요합니다. 아웃바운드가 열린 microVM은 여전히 원치 않는 트래픽을 보낼 수 있고, API 키가 들어 있는 microVM은 여전히 그것을 유출할 수 있습니다. 격리는 게스트로부터 호스트를 지키는 것이지, 여러분이 건넨 코드로부터 여러분의 비밀을 지키는 것이 아닙니다.

우리 샌드박스에서의 활용

각 EQVPS 샌드박스는 자체 커널을 가진 Firecracker microVM 하나로, 0.25 vCPU·512MB부터 8 vCPU·16GB까지 있습니다. Python 3.12, Node.js 22, bash, git, curl이 들어 있고, 아웃바운드 인터넷은 되며 인바운드 포트는 없습니다. 임시 샌드박스는 다 쓰면 삭제되고, persistent 샌드박스는 디스크를 유지합니다. 일시 정지하면 microVM의 스냅숏을 디스크에 기록하므로 재개될 때까지 비용이 들지 않습니다. 일시 중지 스냅샷은 14일 동안 보관됩니다. 그 뒤 샌드박스는 삭제되고 그 id는 410 sandbox_deleted를 반환합니다.

컨테이너 대신 microVM을 고른 이유는 하나입니다. 샌드박스에서 실행되는 코드는 애초에 아무도 검토하지 않은 코드이기 때문입니다. AI 에이전트의 출력, 낯선 사람의 pull request, 모델이 작성한 프로그램 1,000개로 이루어진 벤치마크. 이런 것에는 자체 커널이야말로 돈을 낼 가치가 있는 경계입니다. 그 주변에 우리가 마련한 것, 즉 요금제, 할당량, 동기 명령의 55초 제한 등의 세부 사항은 샌드박스 문서에 있습니다.

이 경계를 다른 선택지와 더 깊이 비교하고 싶다면 신뢰할 수 없는 코드를 위한 격리 수준에서 프로세스, 컨테이너, microVM, 완전한 VM을 나란히 놓고 비교합니다. 초 단위 가격이 눈길을 끌었다면 초 단위 과금은 실제로 어떻게 계산되나에서 계산 과정을 보여 줍니다.