이것은 교차 게시물입니다. 원문은 저희 사이트에 있습니다: stellarbytecapital.com/blog/gvisor-firecracker-docker-ai-sandbox

AI가 생성한 코드를 샌드박스(sandbox)에서 실행하기로 결정했다면, 다음 질문은 _어떤 샌드박스를 사용할 것인가_입니다. 계속해서 접하게 될 세 가지 이름은 Docker, gVisor, 그리고 Firecracker입니다. 이들은 서로 경쟁하는 제품이라기보다 경계(boundary)를 설정하는 세 가지 서로 다른 강점을 가지고 있습니다. 잘못된 선택을 하면 보안에 노출되거나 불필요한 성능 손실을 초래할 수 있습니다.

이들이 실제로 어떻게 다른지, 그리고 어떻게 선택해야 하는지 설명해 드리겠습니다.

이들을 구분하는 단 한 가지: 경계가 어디에 있는가

세 가지 모두 코드를 격리하지만, 서로 다른 계층(layer)에서 격리합니다. 그리고 그 계층이 경계를 깨뜨리기가 얼마나 어려운지를 결정합니다.

• Docker (runc) — 표준 컨테이너(containers). 격리는 Linux namespaces, cgroups, 그리고 seccomp를 통해 이루어집니다. 컨테이너는 호스트 커널(host kernel)을 공유합니다. 빠르고 범용적이지만, 커널 익스플로잇(kernel exploit)이 발생하면 경계를 넘어설 수 있습니다.
• gVisor (runsc) — Google에서 만든 사용자 공간 커널(user-space kernel)입니다. 컨테이너의 시스템 콜(syscalls)을 가로채어 호스트 커널로 직접 전달하는 대신 샌드박스된 프로세스 내에서 처리합니다. 이는 코드와 실제 커널 사이에 두 번째 벽을 세우는 것입니다.
• Firecracker — KVM 하드웨어 가상화(hardware virtualization)를 기반으로 구축된 마이크로VM(microVM)입니다. 각 샌드박스는 자체 게스트 커널(guest kernel)을 가진 실제 (매우 작은) 가상 머신이며, 약 125ms 내에 부팅됩니다. 이는 세 가지 중 가장 강력한 경계입니다. AWS Lambda와 Fargate가 테넌트(tenants)를 격리하기 위해 사용하는 방식입니다.

한눈에 보는 비교

Docker: 기준점이지만, 신뢰할 수 없는 코드에 대한 정답은 아님

강화된 원샷 (one-shot) Docker 컨테이너 — non-root, 권한 삭제 (dropped capabilities), seccomp 활성화, 읽기 전용 파일 시스템 (read-only filesystem), 기본적으로 네트워크 없음 — 는 영향 범위 (blast radius)가 제한적인 내부 도구용으로는 완벽하게 합리적인 샌드박스입니다. 이는 가장 빠르고 단순한 옵션입니다.

그 약점은 구조적입니다: 컨테이너가 호스트 커널 (host kernel)을 공유한다는 점입니다. 커널 취약점이 하나라도 발생하면, "격리된" 코드가 호스트에 도달하게 됩니다. 만약 진정으로 신뢰할 수 없거나 멀티 테넌트 (multi-tenant) 코드를 실행하고 있다면, Docker만 사용하는 것은 커널이 결함이 없기를 바라는 도박과 같습니다.

gVisor: 호환성을 대가로 얻는 두 번째 커널 장벽

gVisor는 컨테이너 런타임 (runsc)으로 끼어들기 때문에, 바로 교체 가능한 업그레이드에 가깝습니다. 코드의 시스템 콜 (syscall)이 호스트 커널에 직접 닿는 대신, 먼저 gVisor의 사용자 공간 커널 (user-space kernel)에 닿게 됩니다. 이제 공격자는 gVisor와 호스트 커널을 모두 뚫어야 합니다.

트레이드오프 (tradeoffs): gVisor는 모든 시스템 콜을 구현하지 않으므로 일부 워크로드가 중단될 수 있으며, 시스템 콜이 많은 프로그램은 성능 저하 (performance tax)를 겪게 됩니다. 데이터 분석이나 API 호출을 수행하는 샌드박스화된 Python의 경우 대개 괜찮습니다. 특이한 저수준 (low-level) 코드의 경우, 호환성을 먼저 테스트하십시오.

Firecracker: 진정한 격리, 진정한 VM 라이프사이클

Firecracker는 각 실행에 별도의 게스트 커널 (guest kernel)을 가진 고유한 마이크로VM (microVM)을 제공합니다. 경계가 하드웨어 가상화 (hardware virtualization)이기 때문에 세 가지 중 가장 강력합니다. 탈출하려면 단순히 네임스페이스 (namespace)를 벗어나는 것이 아니라 VM을 뚫고 나가야 합니다. 약 125ms 만에 부팅되며, 디바이스 모델 (device model)을 거의 없는 수준으로 축소했습니다.

비용은 운영 측면에서 발생합니다: VM, 게스트 이미지 (guest images), 인스턴스당 메모리 하한선 (memory floor)을 관리해야 합니다. 만약 멀티 테넌트 환경이거나, 타인의 데이터나 자금을 다루거나, 적대적인 (adversarial) 코드를 실행하고 있다면, 그 비용은 실제로 방어 가능한 격리를 보장해 줍니다.

그래서 어떤 것을 사용해야 할까요?

• 내부 도구, 자체 코드/데이터 (Internal tool, your own code/data) → 보안이 강화된 일회성 Docker (hardened one-shot Docker). 빠르고 단순하며 충분합니다.
• 신뢰할 수 없는 코드, 중간 정도의 리스크 (Untrusted code, moderate risk) → gVisor. 운영상의 큰 변화 없이 격리 수준을 크게 높일 수 있습니다. 시스템 호출 (syscall) 호환성만 확인하세요.
• 멀티 테넌트, 실제 자산/데이터, 적대적 입력 (Multi-tenant, real money/data, adversarial input) → Firecracker (또는 Kata Containers). 가상 머신 (VM) 오버헤드 비용을 지불하십시오. 하드웨어 경계 (hardware boundary)가 필요할 것입니다.

격리 기술은 하나의 결정 사항일 뿐입니다. 어떤 런타임 (runtime)을 선택하든, 실행당 일회성 폐기 (disposable per-run), 기본 거부형 외부 통신 (default-deny egress), 읽기 전용 마운트 (read-only mounts), 할당량 (quotas)과 같은 관련 정책들이 그만큼 중요합니다.

저희는 Xingyao Byte입니다 — 보안 AI 실행 계층 (secure AI-execution layers), 퀀트 트레이딩 시스템 (quant trading systems), 그리고 결제 플랫폼을 구축하고 있습니다. 원격 근무 및 비동기 우선 (async-first) 방식으로 운영됩니다. 자세한 내용은 **stellarbytecapital.com**에서 확인하세요.