VPS에서 Firecracker microVM 실행 가능 여부 확인 방법

VPS에서 Firecracker microVM을 실행할 수 있습니까?

VPS에서 Firecracker microVM을 실행하려면 반드시 /dev/kvm를 제공받아야 합니다. Firecracker는 Linux 내부의 가상화 계층인 KVM(kernel-based virtual machine)을 기반으로 구축된 VMM(virtual machine monitor)이며, KVM은 CPU로부터 가상화 명령어를 전달받아야 합니다. VPS 환경에서는 호스팅 제공업체가 해당 명령어를 게스트 시스템으로 패스스루(passthrough)해 줄 때만 이 기능을 사용할 수 있는데, 대부분의 요금제는 이를 지원하지 않습니다.

따라서 가장 먼저 고려해야 할 사항은 어떤 microVM 도구를 설치할지가 아닙니다. 현재 비용을 지불하고 사용하는 서버가 microVM을 호스팅할 수 있는지 확인하는 것입니다. 이는 호스팅 환경에 관한 문제이며, 약 1분 내에 확인할 수 있습니다.

설치 전 /dev/kvm 확인하기

VPS에서 다음 세 가지 명령어를 실행합니다.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

microVM을 호스팅할 수 있는 환경은 다음과 같이 응답합니다.

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

첫 번째 줄은 KVM 디바이스 노드이며, kvm 그룹이 소유하고 있습니다. 두 번째 줄은 이 머신 자체가 KVM 위에서 실행 중인 게스트임을 나타내며, 이는 VPS 환경에서 정상적이고 예상된 결과입니다. 세 번째 줄은 하드웨어 가상화 플래그를 보고하는 CPU 코어 수를 나타내며, Intel은 vmx, AMD는 svm입니다. 게스트 내부에서 0보다 큰 값이 출력된다면 하이퍼바이저가 중첩 가상화(nested virtualisation)를 제공하고 있다는 의미입니다.

그다음, 현재 사용자가 해당 디바이스를 열 수 있는지 확인합니다. 이는 Firecracker 공식 시작 가이드에서 제공하는 테스트입니다.

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

노드가 존재함에도 FAIL 오류가 발생한다면 이는 하드웨어 문제가 아니라 권한 문제입니다. sudo setfacl -m u:${USER}:rw /dev/kvm 명령어로 사용자에게 접근 권한을 부여하거나, sudo usermod -aG kvm ${USER} 명령어로 사용자를 해당 그룹에 추가한 뒤 다시 로그인하십시오.

Ubuntu는 이 모든 과정을 두 줄의 출력으로 요약하는 확인 도구를 제공합니다.

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

정상적인 호스트는 INFO: /dev/kvm exists에 이어 KVM acceleration can be used을 출력합니다. 사용할 수 없는 호스트는 INFO: Your CPU does not support KVM extensions에 이어 KVM acceleration can NOT be used를 출력합니다. 물리 머신에서는 INFO: KVM (vmx) is disabled by your BIOS이 표시될 수 있으며, 이는 펌웨어 설정에서 수정 가능합니다. VPS에서는 실제 펌웨어를 직접 다루지 않으므로 해당 메시지는 거의 나타나지 않습니다.

각 /dev/kvm 응답은 무엇을 의미합니까?

노드가 존재하고 플래그 개수가 0보다 큽니다. 하드웨어 가상화 기능을 사용할 수 있으므로 Firecracker가 실행됩니다. CPU 기능보다는 메모리가 제약 사항이므로 크기 조정 섹션으로 넘어가십시오.

노드가 없고, systemd-detect-virt 명령이 kvm 또는 qemu을 출력하며, 플래그 개수가 0입니다. 사용 중인 VPS는 호스트가 가상화 기능을 전달하지 않는 가상 머신입니다. 이 플래그는 하이퍼바이저가 생성한 가상 CPU의 속성이므로, 게스트 내부에 무엇을 설치하더라도 이 상태는 변하지 않습니다. sudo modprobe kvm_intel는 modprobe: ERROR: could not insert 'kvm_intel': Operation not supported 오류와 함께 실패하며, sudo dmesg | grep -i kvm은 하드웨어 지원이 누락되었음을 기록합니다. 이는 공유 VPS 플랜에서 흔히 발생하는 경우입니다. 제공업체에 해당 플랜이 중첩 가상화(nested virtualisation)를 지원하는지 문의하십시오. 지원하지 않는다면 다른 명령어가 아니라 다른 호스팅 서비스가 필요합니다.

systemd-detect-virt 명령이 lxc, lxc-libvirt 또는 openvz을 출력합니다. 사용 중인 플랜은 컨테이너 가상화 방식이므로 호스트의 커널을 공유합니다. 모듈을 로드할 수 있는 자체 커널이 없으므로 /dev/kvm은 절대 나타나지 않습니다. 어떤 패키지를 설치해도 이 문제는 해결되지 않습니다.

플래그는 존재하지만 노드가 없습니다. 모듈이 로드되지 않은 상태입니다. sudo modprobe kvm_intel(AMD의 경우 kvm_amd)를 실행하고 ls -l /dev/kvm를 다시 확인하십시오. 노드가 나타나면 재부팅 후에도 유지되도록 /etc/modules-load.d/kvm.conf에 모듈 이름을 기록하십시오.

arm64 아키텍처를 사용 중입니다. vmx과 svm은 x86 관련 명칭이므로, arm64 머신에서는 작동 여부와 관계없이 grep 개수가 항상 0입니다. arm64에서는 장치 노드 존재 여부와 읽기/쓰기 테스트 결과를 신뢰하십시오.

에이전트 작업에 컨테이너 대신 microVM을 사용하는 이유

컨테이너는 커널 위에서 실행되는 프로세스이며, namespaces와 cgroups로 격리됩니다. 호스트와 동일한 커널을 공유하므로 커널 수준의 탈출이 발생하면 호스트가 직접적인 위협에 노출됩니다. 반면 microVM은 하드웨어 가상화 경계 내부에서 자체 커널을 부팅하며, 호스트의 전체 시스템 호출 인터페이스가 아닌 소규모로 에뮬레이션된 장치 모델과 통신합니다. Firecracker는 이 모델을 의도적으로 작게 유지하며, 이것이 설계의 핵심입니다. 에뮬레이션된 장치가 적을수록 탈출 경로도 줄어들기 때문입니다.

이러한 차이는 코딩 에이전트에게 중요합니다. 에이전트가 실행하는 코드는 아무도 미리 검토하지 않은 코드일 수 있기 때문입니다. 에이전트는 패키지를 설치하고, 빌드 스크립트를 실행하며, 실패 시 기계적인 속도로 재시도합니다. 별도의 커널을 사용하면 잘못된 작업이 수행되더라도 삭제 가능한 머신에만 피해가 국한되며, 다른 곳에는 영향을 미치지 않습니다.

이러한 요구 사항은 메커니즘에서 직접적으로 도출됩니다. 하드웨어 격리를 위해서는 하드웨어 가상화가 필요하며, VPS 플랜에 따라서는 이 기능이 제공되지 않을 수 있습니다. 컨테이너는 하드웨어 가상화가 필요 없으므로 모든 플랜에서 실행할 수 있습니다.

따라서 /dev/kvm가 지원되지 않는 환경에서는 컨테이너 기반의 코딩 에이전트를 위한 일회용 VM이 여전히 올바른 해결책이며, 이는 차선책이 아닌 실질적인 통제 수단입니다. 중요한 자격 증명이 없는 호스트에서 일회용 컨테이너를 사용하고, 문제가 발생할 때마다 스냅샷으로 복구하는 방식은 대부분의 실제 오류를 방지합니다. VPS에서 코딩 에이전트 실행하기의 일반적인 설정도 마찬가지입니다. 에이전트가 검토되지 않은 코드를 대상으로 몇 시간 동안 무인으로 실행되어야 하고, 호스트를 완전히 제어할 수 있는 상황이라면 microVM을 선택하십시오.

마이크로VM 에이전트 호스트의 요구 사항

Nehemiah는 이 부류의 현재 예시입니다. Apache-2.0 데몬인 이 도구는 요청 시 AI에게 실제 Linux 머신을 제공하며, 머신당 하나의 Firecracker 마이크로VM을 할당합니다. README는 요구 사항을 모호함 없이 명시합니다. "/dev/kvm을 갖춘 Linux 박스"가 필요하며, 더 정확하게는 "root 권한으로 SSH 접속이 가능한 /dev/kvm(베어메탈 또는 중첩 가상화가 지원되는 VM) 환경의 Ubuntu 24.04, x86_64 또는 arm64"를 요구합니다.

문서화된 설정 방법은 해당 박스에서 다음 명령어를 한 번 실행하는 것입니다.

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

infra/setup.sh는 SSH를 통해 사전 점검을 수행하며, 박스 환경이 부적합하면 즉시 중단합니다. 하드웨어 관련 거부 메시지는 다음과 같습니다.

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

첫 번째 문자열이 바로 이 글의 핵심입니다. 설치 프로그램은 방금 ls -l /dev/kvm으로 질문했던 것과 같은 내용을 확인하며, 대부분의 VPS 플랜에서는 동일하게 실망스러운 답변을 받게 됩니다.

사전 점검을 통과하면 전체 박스 설치가 진행됩니다. Firecracker와 jailer, Go 툴체인, 게스트 커널 및 루트 파일시스템, Python 게스트 이미지, 브라우저가 포함된 선택적 데스크톱 이미지, 그리고 nehemiahd.service와 boring-net.service라는 이름의 systemd 유닛 두 개가 설치됩니다. 이후 데몬은 8080 포트에서 응답하며, 상태 확인에 실패하면 /healthz didn't return ok을 출력합니다. SKIP_DESKTOP=1은 데스크톱 이미지 빌드를 건너뛰는데, README에 따르면 이 빌드에는 약 8분이 소요됩니다.

명령어를 붙여넣기 전에 주의 사항을 읽으십시오

이 도구는 초기화된 호스트의 root SSH 권한을 요구합니다. 설치 프로그램은 root 권한으로 시스템 패키지, systemd 유닛, 네트워크 설정을 작성합니다. 이미 운영 중인 서버가 아니라, 처음부터 다시 구축해도 상관없는 머신을 대상으로 실행하십시오.

데몬은 기본적으로 0.0.0.0:8080 포트에 바인딩됩니다. 해당 포트에 접근할 수 있는 사람은 누구나 머신을 생성할 수 있으며, 생성된 머신은 설치 프로그램에 제공한 모델 키를 사용합니다. 인증을 요구하려면 NEHEMIAH_TOKEN을 설정하거나, 데몬이 127.0.0.1에만 바인딩되도록 BIND_LOCALHOST=1를 설정한 뒤 ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP을 사용하여 터널을 통해 접근하십시오. 이 키는 서버 내의 다른 비밀 정보와 마찬가지로 AI 에이전트로부터 비밀 정보 보호하기에 따라 동일하게 관리해야 합니다.

모든 머신은 인터넷 접속이 가능하며 에이전트가 미리 설치된 컴퓨터입니다. README에는 게스트 내부에 node, python, git과 함께 claude, codex, cursor, pi가 포함되어 있다고 명시되어 있습니다. 프로젝트 측은 게스트가 이그레스(egress) 방화벽 뒤에 위치하며 격리 경계 자체가 실재한다고 설명합니다. 하지만 코딩 에이전트는 패키지를 가져올 수 없으면 무용지물이므로, 설계상 게스트는 여전히 네트워크에 접근할 수 있습니다. 에어갭(air gap) 환경이라고 가정하지 말고 이에 대비하십시오.

태그가 지정된 릴리스가 없습니다. 2026년 8월 10일 기준으로 저장소에는 태그가 전혀 없으므로, main을 클론하면 당일 아침까지 반영된 최신 상태를 가져오게 됩니다. 특정 커밋으로 고정하고, 서버에서 root 권한으로 스크립트가 실행되기 전에 내용을 확인하십시오:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

저장소는 2026년 6월 말에 생성되었으므로 초기 단계의 소프트웨어로 취급해야 합니다. 업데이트를 받을 때마다 infra/setup.sh을 다시 읽어보십시오. 승인하는 대상은 라이브러리 버전 업데이트가 아니라 머신에 대한 root 접근 권한이기 때문입니다.

설치 프로그램을 탓하기 전에 KVM이 정상 작동하는지 확인하십시오

설치가 실패했을 때 KVM이 원인인지 확인하려면 Firecracker를 단독으로 테스트하십시오. 다음은 업스트림 다운로드 단계입니다.

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

출력된 버전 정보는 바이너리가 해당 아키텍처와 일치하며 실행 가능하다는 것을 증명합니다. 하지만 이것이 KVM 접근 권한을 보장하지는 않으므로, 앞서 언급한 /dev/kvm에 대한 읽기 및 쓰기 테스트를 병행하십시오. 이 두 가지 테스트를 함께 수행하면 호스팅 문제와 패키징 문제를 분리할 수 있으며, 정상적인 설치 프로그램을 불필요하게 디버깅하는 상황을 방지할 수 있습니다.

여러 개의 microVM에는 어느 정도의 서버 자원이 필요한가?

각 microVM은 실제 게스트 커널과 할당된 메모리를 점유하며, 이 메모리는 가상 머신이 실행되는 동안 계속 유지됩니다. 따라서 호스트의 크기는 게스트의 크기와 동시에 실행할 개수를 기준으로 산정해야 합니다. 아래 수치는 측정값이 아닌 산술적인 계산 결과입니다. 헤드리스(headless) 게스트는 1 GB, 브라우저를 포함한 데스크톱 게스트는 2 GB를 기준으로 합니다. 호스트는 운영체제, 데몬, 이미지 빌드를 위해 2 GB를 기본적으로 확보해 두어야 합니다.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

헤드리스 머신을 한 번에 하나씩 실행하려면 약 3 GB가 필요하며, 이는 KVM을 지원하는 중급형 VPS로 수용할 수 있습니다. 4대를 실행하려면 6 GB가 필요합니다. 8 대의 데스크톱 머신을 실행할 경우, 동일한 계산법에 따라 디스크 용량을 제외하고도 18 GB가 필요합니다.

디스크 용량은 아무도 미리 계획하지 않는 부분입니다. 호스트는 게스트 커널, 기본 루트 파일 시스템, 게스트 유형별 이미지 하나, 실행 중인 머신당 스냅샷 하나를 저장하며, 브라우저가 포함된 데스크톱 이미지는 용량이 큽니다. README에는 디스크 사용량에 대한 수치가 명시되어 있지 않으므로, 추측에 의존하기보다 첫 빌드 중에 df -h /을 모니터링하십시오.

이것이 "Firecracker를 실행할 VPS는 무엇인가"라는 질문에 대한 솔직한 답변이 종종 "다른 등급의 머신"이 되는 이유입니다. 베어메탈 서버는 하이퍼바이저의 간섭 없이 CPU 플래그를 그대로 제공하며, 이것이 VPS와 전용 서버 사이의 선택에서 고려해야 할 상충 관계입니다. 일부 제공업체는 가상화 플랜에서 중첩 가상화(nested virtualisation)를 지원하며, VPS에서의 중첩 가상화 문서를 통해 결제 전 지원 여부를 확인하는 방법을 다룹니다. 이미 하드웨어를 보유하고 있다면 Proxmox와 일반 VPS 비교는 하이퍼바이저 측면에서 동일한 질문이 됩니다.

서버 비용은 전체 비용의 저렴한 절반에 불과합니다. 에이전트에 할당된 모든 머신은 실행되는 동안 모델 토큰을 소모하므로, 유휴 상태의 microVM은 메모리 비용을 발생시키고, 작업 중인 microVM은 메모리 비용과 API 사용료를 동시에 발생시킵니다. 1 GB 플랜으로는 호스트를 수용할 수 없습니다. 호스트를 수용할 수 있는 플랜이라 하더라도 API 키 비용까지 해결해주지는 않습니다.

FAQ

VPS에서 Firecracker를 실행할 수 있는지 어떻게 확인합니까?

VPS에서 ls -l /dev/kvm, systemd-detect-virt 및 grep -cE '\b(vmx|svm)\b' /proc/cpuinfo 명령을 실행하십시오. kvm 그룹이 소유한 디바이스 노드가 존재하고 플래그 개수가 0보다 크다면 Firecracker를 실행할 수 있습니다. 노드가 없거나 개수가 0이라면 하이퍼바이저가 가상화 기능을 전달하지 않는 상태이며, cpu-checker 패키지의 sudo kvm-ok 명령을 실행하여 KVM acceleration can NOT be used 결과로 이를 확인할 수 있습니다. arm64 아키텍처에서는 vmx 및 svm가 x86 전용 이름이므로 개수를 무시하십시오.

VPS 내부에서 중첩 가상화(nested virtualisation)를 활성화할 수 있습니까?

아니요. 중첩 가상화는 호스트의 하이퍼바이저 커널 모듈에서 설정하며, 가상 프로세서에 CPU 플래그 형태로 전달됩니다. 게스트 내부에서 sudo modprobe kvm_intel 명령을 실행하면 가상 CPU가 VMX를 사용할 수 없으므로 modprobe: ERROR: could not insert 'kvm_intel': Operation not supported 결과가 반환됩니다. 중첩 가상화를 지원하는 요금제를 제공하는 공급자를 선택하거나, 직접 하이퍼바이저를 제어할 수 있는 장비를 사용해야 합니다.

코딩 에이전트를 샌드박싱하는 데 컨테이너로 충분합니까?

대부분 충분합니다. 컨테이너는 커널을 공유하므로 커널 수준의 탈출이 발생하면 호스트에 영향을 줄 수 있지만, 중요한 자격 증명이 없는 장비에서 일회용 컨테이너를 사용하면 실제 위험의 대부분을 제거할 수 있습니다. 에이전트가 검토되지 않은 코드를 대상으로 장시간 무인 실행되거나 /dev/kvm가 설정된 호스트를 제공할 수 있는 경우에는 microVM을 선택하십시오. 그렇지 않은 상황이라면, 부팅조차 어려운 microVM보다 작업이 끝날 때마다 삭제하는 컨테이너가 더 효과적입니다.

microVM 에이전트 호스트에는 어느 정도의 RAM이 필요합니까?

게스트 크기부터 고려하십시오. 1 GB 크기의 헤드리스 게스트 1개와 2 GB의 호스트 예비 메모리를 합치면 총 3 GB가 필요하며, 2 GB 크기의 데스크톱 게스트 8개는 약 18 GB가 필요합니다. 디스크 용량은 별도로 계산해야 하며 과소평가하기 쉽습니다. 호스트는 커널, 루트 파일 시스템, 게스트 유형별 이미지 1개, 그리고 실행 중인 모든 머신에 대한 스냅샷을 유지해야 하기 때문입니다.