zeroboot가 풀려는 에이전트 인프라 문제

2026년 3월 17일 Show HN에는 zeroboot라는 샌드박스 시스템이 올라왔다. 이 글은 Hacker News에서 크롤링 시점 기준 303 points와 69 comments를 모았다. 저수준 인프라 프로젝트 치고 반응이 나온 이유는 분명하다. 코드 에이전트와 도구형 assistant가 더 자율적으로 움직일수록, 격리된 실행 환경을 얼마나 빠르게 띄울 수 있는지가 모델 호출 비용만큼 중요해지기 때문이다.

zeroboot의 핵심 주장은 직설적이다. 단순한 “컨테이너급 격리”가 아니라, 각 샌드박스가 하드웨어 수준 메모리 격리를 갖춘 실제 KVM 가상머신이라는 것이다. README에 따르면 Firecracker 기반 템플릿 VM을 한 번 부팅하고 메모리와 CPU 상태를 스냅샷한 다음, 이후 샌드박스는 해당 메모리를 copy-on-write로 매핑해 새 KVM VM을 복원하는 방식으로 만든다. 공개 수치는 p50 스폰 0.79 ms, p99 1.74 ms, 샌드박스당 메모리 약 265 KB, Python fork+exec 경로 약 8 ms 수준이다.

벤치마크 표가 의미하는 것

README의 관심 포인트는 비교표다. zeroboot는 E2B, microsandbox, Daytona와 비교해 더 낮은 시작 지연과 더 작은 메모리 오버헤드를 주장한다. 동시에 1,000개의 동시 포크를 815 ms에 처리했다고 적었다. 물론 이 수치는 프로젝트 자체 보고값이고, 저장소도 현 상태를 production-hardened 서비스가 아닌 working prototype으로 규정한다. 따라서 절대값보다 방향성으로 보는 편이 맞다. 그래도 방향성 자체는 분명하다. 에이전트 시스템은 전통적인 VM 워크플로보다 훨씬 더 자주, 더 짧은 생애주기의 안전한 실행 환경을 요구한다.

왜 이 설계가 흥미로운가

흥미로운 부분은 속도와 격리 모델의 조합이다. 컨테이너는 빠르지만 커널을 공유하고, 전체 VM은 더 잘 격리되지만 시작 비용이 높다. zeroboot는 snapshot forking으로 이 간극을 에이전트 워크로드 수준까지 줄일 수 있다고 주장한다. 특히 같은 언어 런타임을 반복 재사용하는 코드 에이전트에게는 의미가 크다. 프로젝트는 Python과 TypeScript SDK도 제공하며, 셀프호스팅과 매니지드 API 둘 다 언급한다.

동시에 제한사항도 중요하다. README는 userspace PRNG 재시드 문제, single-vCPU 설계, 포크 내부 네트워킹 미지원, 템플릿 변경 시 전체 재스냅샷이 필요하다는 점을 명시한다. 즉 모든 보안 실행 문제를 바로 대체하는 범용 해법은 아니다. 그러나 짧은 시간의 고립된 계산을 자주 수행해야 하는 코드 에이전트 환경에서는, 이 아키텍처가 왜 HN의 관심을 끌었는지 충분히 이해할 수 있다.

원문: zeroboot README. 커뮤니티 토론: Hacker News.

#firecracker

Show HN: zeroboot, AI agent용 서브밀리초 KVM 샌드박스를 내세우다