Dormice로 자가 호스팅 에이전트 샌드박스 구축하기

Dormice의 정의와 역할

Dormice는 자가 호스팅형 에이전트 샌드박스입니다. 사용자가 소유한 Linux VPS에서 데몬 하나를 실행하면, 에이전트 코드가 HTTP를 통해 이 데몬을 호출하여 격리된 컨테이너 안에서 신뢰할 수 없는 코드를 실행합니다. 프로그램이 이름으로 샌드박스를 요청하면, 이전 상태와 관계없이 동일한 샌드박스를 반환받아 그 안에서 명령을 실행하고 출력 결과를 읽습니다. 이 샌드박스는 프로그래밍 방식으로 제어하는 리소스이며, 사용자가 직접 로그인하는 머신이 아닙니다.

이는 에이전트에게 컴퓨터 전체를 제공하는 방식과는 다릅니다. 코딩 에이전트를 위한 일회용 VM은 SSH로 접속하여 에이전트가 마음껏 사용하게 한 뒤 삭제하는 상자입니다. Dormice는 이보다 한 단계 아래에 위치합니다. 즉, 프로그램이 이미 코드를 가지고 있고 이를 안전하게 실행할 장소가 필요할 때 호출하는 실행 API입니다. 작업 단위가 머신 전체라면 일회용 VM을 사용하십시오. 작업 단위가 단일 exec 호출이며, VM 100대를 띄우지 않고 하루에 100번의 실행을 원한다면 Dormice를 사용하십시오.

이 프로젝트는 E2B 호환을 표방합니다. E2B는 많은 에이전트 프레임워크가 이미 클라이언트 라이브러리를 가져와 사용하는 호스팅형 샌드박스 서비스입니다. Dormice는 자체 URL 접두사를 사용하여 동일한 프로토콜을 제공하므로, 공식 e2b 패키지를 기반으로 작성된 애플리케이션을 사용자의 서버로 연결해도 그대로 작동합니다. 애플리케이션 코드를 수정할 필요는 없습니다. 두 개의 URL과 하나의 API 키 접두사만 변경하면 됩니다.

"에이전트 샌드박스계의 SQLite"가 실무에서 의미하는 바

SQLite는 운영해야 하는 서비스가 아니라 내장하는 데이터베이스이며, Dormice는 이 비유를 그대로 차용합니다. 데몬 하나, 원장(ledger)을 위한 SQLite 파일 하나, TCP 포트 하나가 전부입니다. Kubernetes도, 별도의 데이터베이스도, 스케줄러도 필요 없습니다. 데몬은 원장 옆에 잠금(lock) 파일을 생성하며, 원장과 현재 머신이 일치하지 않으면 실행을 거부하므로 스플릿 브레인(split brain) 현상이 조용히 발생할 수 없습니다. 단일 머신 운영이 설계 원칙입니다. 여러 호스트에 걸친 클러스터가 필요하다면 README에 명시된 대로 다른 도구를 선택해야 하며, 이 권고를 따르는 것이 좋습니다.

이 개념의 두 번째 핵심은 비용입니다. 호스팅형 샌드박스는 존재하는 매 초마다 비용이 청구되므로 설계상 일회용입니다. 반면 Dormice는 이미 비용을 지불하고 있는 하드웨어에서 실행되므로 샌드박스가 영구적이며, 오래 유지될수록 비용 효율이 높아집니다. 샌드박스는 활성(active), 동결(frozen), 정지(stopped), 보관(archived) 단계로 순차적으로 냉각됩니다. 어떤 단계에 있든 샌드박스를 다시 획득(acquire)하면 즉시 이전 단계로 복구됩니다.

동결(freezing)은 모든 에이전트의 샌드박스를 영구적으로 유지할 수 있게 해주는 핵심 기능이므로 이해할 가치가 있습니다. 아래 수치는 프로젝트에서 자체 하드웨어를 기준으로 측정한 공식 데이터입니다.

[
  {
    "label": "Active, holding 1 GiB",
    "resident_memory_mib": 1024,
    "wake_ms": 0
  },
  {
    "label": "Frozen",
    "resident_memory_mib": 5,
    "wake_ms": 50
  }
]

1024 MiB의 메모리를 점유하던 유휴 샌드박스는 동결 시 5 MiB로 상주 메모리 사용량이 감소하며, 약 50 ms 만에 복구됩니다. 프로세스는 현재 상태 그대로 일시 중지되고 재개되므로, 장기 실행 에이전트는 동결 전후로 셸 상태와 작업 내용을 그대로 유지합니다. 용량 계획을 세우기 전에 반드시 자신의 호스트에서 직접 재현해 보시기 바랍니다.

설치 전 호스트 요구 사항

호스트 운영체제는 x86_64 아키텍처의 Ubuntu 또는 Debian이어야 하며, 설치 과정에는 root 권한이 필요합니다. 데몬은 루프 마운트와 cgroups 쓰기 작업을 수행하므로 런타임에도 root 권한을 유지합니다.

샌드박스는 gVisor(컨테이너와 호스트 커널 사이에 사용자 공간 커널을 배치하는 컨테이너 런타임)를 사용하는 Docker 환경에서 실행되며, 각 샌드박스가 사용하는 runsc 런타임을 제공합니다. 데몬은 Node 22 이상에서 실행되며, 설치 프로그램이 자체 Node 복사본을 포함하고 있으므로 시스템에 설치된 Node는 영향을 받지 않습니다.

스왑(swap)은 반드시 존재해야 하며, vm.swappiness 값은 100이어야 합니다. 이는 성능 튜닝 권장 사항이 아니라 기능적 요구 사항입니다. 프리징(freezing)은 유휴 샌드박스의 메모리를 스왑으로 밀어내는 방식으로 작동합니다. gVisor는 샌드박스 메모리를 공유 메모리로 유지하는데, 커널은 기본 swappiness 설정에서는 공유 메모리를 스왑하지 않습니다. 프로젝트 측정 결과 기본값에서는 0바이트가 회수되었으나 100으로 설정했을 때는 99.5퍼센트가 회수되었습니다. 일부 클라우드 이미지에는 사용자가 확인하기 어려운 파일에 vm.swappiness = 0 설정이 포함되어 있을 수 있으므로, 커널이 실제로 사용 중인 값을 확인하십시오.

sysctl vm.swappiness
swapon --show

sysctl vm.swappiness 명령은 vm.swappiness = 100를 출력해야 하며, swapon --show 명령은 스왑 파일을 나열해야 합니다. swappiness 값이 0으로 출력되면 모든 프리징 작업이 아무런 동작을 하지 않게 되며, 결과적으로 모든 유휴 샌드박스에 대해 전체 메모리 비용을 지불하게 됩니다.

Ubuntu에 Dormice 설치하기

문서화된 설치 방법은 bash로 파이프를 연결하는 것입니다:

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh | bash

스크립트를 실행하기 전에 먼저 가져와서 내용을 읽어보십시오. 이 스크립트는 root 권한으로 실행되며 호스트 설정을 변경합니다. Docker가 없으면 설치하고, gVisor와 Caddy를 체크섬 검증과 함께 다운로드하며, 스왑 파일을 생성하고, systemd 유닛을 작성하며, 방화벽 규칙을 추가합니다.

curl -fsSL https://raw.githubusercontent.com/BitMiracle-AI/Dormice/main/deploy/install.sh -o dormice-install.sh
less dormice-install.sh
sudo bash dormice-install.sh --swap-gb 8

--swap-gb는 스왑 파일 크기를 설정하며 기본값은 16입니다. 소규모 VPS에서는 디스크 용량을 상당히 많이 차지하는 설정입니다. --mirror cn은 다운로드 경로를 중국 본토에서 접근 가능한 미러 서버로 변경합니다. 설치 프로그램을 다시 실행하면 코드가 업그레이드되고 설정 편차가 수정되지만, API 토큰은 절대 교체되지 않습니다.

코드는 /opt/dormice에, 설정은 /etc/dormice/env에, 샌드박스 데이터는 /var/lib/dormice에 저장되며, dormice 및 dor 명령어는 /usr/local/bin에 위치합니다. 설치 프로그램은 설치 과정에서 API 토큰을 생성하여 /etc/dormice/env에 600 모드로 저장합니다.

설치할 수 있는 태그가 지정된 릴리스는 없습니다. 2026년 8월 4일 기준으로 저장소에는 git 태그나 GitHub 릴리스가 없으므로, 설치 프로그램은 main을 복제하며 사용자는 당일 아침까지 반영된 최신 코드를 받게 됩니다. 따라서 버전을 고정하려면 실제로 설치한 커밋 해시를 기록해 두어야 합니다.

git -C /opt/dormice rev-parse HEAD

해당 해시를 배포 노트에 저장하십시오. 업그레이드 후 문제가 발생하면 버전 번호가 없기 때문에 해당 커밋으로 되돌리는 것이 유일한 복구 방법입니다.

설치 프로그램은 마지막에 dor doctor를 실행합니다. 이는 패키지 목록을 신뢰하는 대신 실제 gVisor 컨테이너를 부팅하여 런타임이 정상 작동하는지 확인하는 읽기 전용 호스트 점검 도구입니다. 데몬이 오작동할 때마다 이 명령어를 다시 실행하십시오.

sudo dor doctor
systemctl is-active dormice

systemctl is-active dormice은 active를 출력해야 합니다. 만약 failed가 출력된다면 journalctl -u dormice -n 50에 그 이유가 기록되어 있습니다. 시작 실패는 보통 데몬 자체의 문제보다는 스왑이나 gVisor 필수 요건이 충족되지 않았을 때 발생합니다.

설치 프로그램은 Caddy도 함께 설치하므로, 방화벽 설정이 완료되었다고 판단하기 전에 어떤 포트가 리스닝 중인지 확인하십시오.

sudo ss -lntp

데몬은 127.0.0.1:3676에 바인딩되며, 설계상 이를 변경하는 설정은 없습니다. 노트북에서 이 포트에 접근하는 것은 의도적인 작업이어야 하며, 가장 간단한 방법은 SSH 터널을 사용하는 것입니다.

ssh -L 3676:127.0.0.1:3676 root@your-server

터널이 열리면 노트북에서 http://127.0.0.1:3676/console을 통해 웹 콘솔에 접속할 수 있습니다. 토큰으로 한 번 로그인하면 httpOnly 세션 쿠키로 전환되므로, 토큰 자체가 페이지에서 읽을 수 있는 곳에 저장되지 않습니다. 웹 콘솔의 Connect 페이지에는 사용자의 엔드포인트를 가리키도록 미리 설정된 복사-붙여넣기용 클라이언트 스니펫이 표시됩니다.

샌드박스를 생성하고 코드 실행하기

샌드박스를 생성하는 작업은 acquire 하나뿐입니다. 이 작업은 멱등성을 가지므로, 동일한 키를 사용하면 항상 같은 샌드박스를 반환하며 필요에 따라 생성, 활성화, 시작 또는 복원합니다. 그 외의 모든 동사는 이전에 본 적 없는 키에 대해 404 오류를 반환합니다. dor CLI에는 acquire 동사가 없으므로, 첫 번째 샌드박스는 콘솔이나 클라이언트 라이브러리를 통해 생성해야 합니다.

콘솔을 이용하는 방법이 가장 빠릅니다. 터널을 통해 /console을 열고 my-agent이라는 이름의 샌드박스를 생성하십시오. 그러면 CLI에서 해당 샌드박스를 사용할 수 있습니다.

sudo grep DORMICE_API_TOKEN /etc/dormice/env
export DORMICE_ENDPOINT=http://127.0.0.1:3676
export DORMICE_API_TOKEN=paste-the-value-here
dor sandbox ls
dor sandbox exec my-agent 'python3 --version'

dor sandbox ls는 각 샌드박스의 수명 주기 상태를 나열하며, 이를 통해 샌드박스가 활성 상태에서 중단 상태로 전환되는 과정을 모니터링할 수 있습니다. dor sandbox exec은 Python 3.12 버전을 출력합니다. 기본 이미지에는 Ubuntu 24.04와 함께 Python 3.12, Node 24, git, ripgrep이 이미 설치되어 있기 때문입니다. 인증 오류가 발생한다면 복사한 토큰 줄에 변수 이름이 포함되어 있는지 확인하십시오.

파일은 dor sandbox push my-agent ./script.py를 사용하여 이동하며 /home/user/script.py에 저장되고, dor sandbox pull my-agent notes.txt을 사용하여 다시 가져올 수 있습니다. 기본 파일 동사는 파일당 16 MiB로 제한되지만, E2B 파일 인터페이스는 스트리밍 방식을 사용하므로 샌드박스 디스크 할당량만이 유일한 제한이 됩니다.

삭제는 데이터를 손실시키는 유일한 동사이며, 이 프로젝트의 연혁을 잘 보여주는 사례이기도 합니다. 메인 README와 번들로 제공되는 에이전트 스킬은 모두 dor sandbox destroy <key>을 문서화하고 있지만, CLI 패키지 README는 dor sandbox release <key>을 문서화하고 있습니다. 직접 빌드한 환경에서 dor sandbox --help를 실행하고 그 결과를 신뢰하십시오.

기존 E2B 코드를 자신의 서버로 연결하기

이것이 바로 이 작업을 수행해야 하는 이유입니다. npm에서 제공하는 공식 e2b 패키지는 수정하지 않은 상태로 Dormice와 통신합니다. 서버에 새로운 포트가 열리지 않도록 SSH 터널을 연 상태에서 노트북으로 이 명령을 실행하십시오.

npm init -y
npm i e2b tsx

import { Sandbox } from 'e2b';

const sbx = await Sandbox.create({
  apiKey: `e2b_${process.env.DORMICE_API_TOKEN}`,
  apiUrl: 'http://127.0.0.1:3676/e2b/api',
  sandboxUrl: 'http://127.0.0.1:3676/e2b/envd',
});

const result = await sbx.commands.run('python3 -c "print(6 * 7)"');
console.log(result.exitCode, result.stdout);

await sbx.kill();

DORMICE_API_TOKEN=paste-the-value-here npx tsx index.ts

정상적으로 실행되면 종료 코드 0과 42이 출력됩니다. API 키는 Dormice 토큰 앞에 e2b_ 접두사를 붙인 형태여야 하며, 이는 호환성 계층이 요구하는 형식입니다.

이 호환성 기능은 단순한 스텁이 아닙니다. 표준 출력 및 표준 에러 스트리밍, 백그라운드 명령, 대화형 PTY, 서명된 업로드 및 다운로드 URL, 디렉터리 감시 및 포트 프록시 기능 모두가 공식 패키지를 통해 실제 Docker 및 gVisor 데몬을 대상으로 프로젝트의 엔드투엔드 테스트 스위트에서 검증되었습니다. 실제 환경을 마이그레이션하기 전에 다음 몇 가지 차이점을 확인하십시오.

• 템플릿 빌드 기능은 구현되지 않았습니다. 템플릿은 사용자가 직접 빌드하여 dor template add에 등록하는 Docker 이미지이며, Sandbox.create('name')가 이를 해석합니다. 등록되지 않은 이름을 요청하면 가짜 응답 대신 404 오류를 반환합니다.
• E2B 인터페이스를 통해 생성된 샌드박스에는 실제 마감 기한이 적용됩니다. 이는 E2B의 의미론적 요구사항이기 때문입니다. 네이티브 API를 통해 생성된 샌드박스에는 마감 기한이 적용되지 않습니다.
• 일시 중지된(frozen) 샌드박스는 프로세스를 유지하다가 실행을 재개하므로, 여기서의 일시 중지 및 재개는 기존에 익숙한 중지 및 콜드 스타트 방식과는 다릅니다.

샌드박스가 차단하는 것과 차단하지 않는 것

gVisor는 컨테이너의 시스템 호출을 사용자 공간(userspace)에서 가로채 직접 처리하므로, 샌드박스 내부의 코드는 호스트 커널과 직접 통신하지 않습니다. 샌드박스 내부의 모든 프로세스는 권한이 없는 사용자(uid 1000)로 실행됩니다. 이러한 구조는 일반적인 상황을 방어합니다. 예를 들어, rm -rf /를 실행하거나, 디스크를 가득 채우거나, 프로세스가 죽을 때까지 포크(fork)를 반복하는 생성된 스크립트는 자신의 샌드박스 내부에서만 피해를 입히고 종료됩니다.

다음은 샌드박스가 차단하지 않는 항목들입니다. 이 항목들에 대한 보안은 사용자의 책임입니다.

• 샌드박스는 외부 네트워크 통신이 가능합니다. 생성된 코드는 원하는 데이터를 다운로드하거나 발견한 정보를 외부로 전송할 수 있습니다. 설치 프로그램의 네트워크 강화 조치는 두 가지 특정 사항만 다룹니다. 클라우드 인스턴스 자격 증명이 노출될 수 있는 169.254.0.0/16 대역의 클라우드 메타데이터 서비스로 향하는 컨테이너 트래픽을 차단하며, Docker의 daemon.json에서 "icc": false을 사용하여 컨테이너 간 통신을 비활성화합니다. 그 외에는 아무것도 차단되지 않습니다. sudo iptables -S DOCKER-USER을 읽고 샌드박스가 접근할 필요가 없는 사설 IP 대역에 대해 직접 DROP 규칙을 추가하십시오.
• Docker는 방화벽보다 앞서 자체 규칙을 삽입합니다. 따라서 ufw에서 포트가 닫혀 있다고 표시되어도, 게시된 컨테이너 포트는 인터넷에서 응답할 수 있습니다. 이 호스트에서 서비스를 노출하기 전에 Docker가 ufw를 우회하여 포트를 게시하는 방식과 VPS를 위한 ufw 방화벽 기초를 읽어보십시오.
• gVisor는 하이퍼바이저가 아닌 사용자 공간 커널입니다. 이는 의도적인 선택입니다. 샌드박스를 프로세스로 유지해야 일시 중지(freezing)가 가능하며, KVM을 요구하면 어디서든 설치할 수 있는 범용성이 떨어지기 때문입니다. 위협 모델상 하드웨어 가상화가 필수라면 Firecracker 수준의 격리를 사용하고 그에 따른 운영 비용을 감수하십시오.
• API 토큰은 클라이언트 측의 유일한 보안 경계입니다. DORMICE_API_TOKEN를 가진 모든 주체는 해당 머신의 모든 샌드박스를 생성, 조회, 삭제할 수 있습니다. 에이전트 프로세스에는 VPS의 최소 권한 사용자를 별도로 부여하고, 토큰을 SSH 키와 동일하게 취급하십시오. VPS에서 Claude Code를 안전하게 실행하는 방법에서 다룬 습관을 그대로 적용하십시오.

데몬 자체는 호스트에서 root 권한으로 실행됩니다. gVisor는 샌드박스 내부의 코드로부터 호스트를 보호하지만, 데몬 자체나 토큰을 탈취한 공격자로부터 호스트를 보호할 수는 없습니다. 따라서 Dormice를 실행하는 머신은 해당 작업만 전담해야 합니다. 에이전트가 MCP(Model Context Protocol)를 통해 도구에 접근하는 경우, 같은 이유로 해당 MCP 서버를 별도의 VPS에 분리하여 운영하십시오.

4 GB와 8 GB 메모리에서 샌드박스를 몇 개나 실행할 수 있습니까?

메모리를 소모하는 요소는 두 가지입니다. 호스트 자체의 기본 점유량과 현재 활성화된 각 샌드박스의 워킹 셋입니다. Ubuntu, Docker, 데몬을 위해 약 1 GB를 확보한 뒤, 남은 용량을 샌드박스 하나가 실제로 사용하는 메모리 양으로 나눕니다. 파일 몇 개를 읽는 Python 스크립트를 실행하는 샌드박스는 200~300 MiB 정도를 사용합니다. 컴파일러나 전체 테스트 스위트를 실행하는 샌드박스는 1 GiB를 넘길 수 있습니다.

[
  {
    "host": "4 GB VPS",
    "active_at_512_mib": 6,
    "active_at_1_gib": 3,
    "frozen_on_16gb_swap": 16
  },
  {
    "host": "8 GB VPS",
    "active_at_512_mib": 14,
    "active_at_1_gib": 7,
    "frozen_on_16gb_swap": 16
  }
]

4 GB VPS는 각 샌드박스가 512 MiB를 사용할 경우 동시에 6개를, 1 GiB를 사용할 경우 3개를 활성화 상태로 유지할 수 있습니다. 8 GB VPS에서는 이 수치가 각각 14개와 7개로 늘어납니다. 이는 동시 작업의 최대치이며 벤치마크가 아닌 산술적인 계산 결과이므로, 실제 부하가 발생하는 동안 free -m을 모니터링하십시오.

일시 정지(frozen)된 샌드박스는 RAM 대신 스왑 메모리의 제한을 받으며, 이것이 바로 이 설계의 핵심입니다. 1 GiB를 점유하던 샌드박스를 일시 정지하면 해당 용량만큼 스왑에 유지되고 상주 메모리는 거의 차지하지 않으므로, 설치 시 기본값인 16 GB 스왑 파일에는 약 16개를 보관할 수 있습니다. 이 수치를 넘어서면 샌드박스를 완전히 정지(stopped) 상태로 전환해야 하며, 이때는 디스크 공간만 차지합니다. 장기적으로는 디스크가 실질적인 제한 요소가 됩니다. 모든 샌드박스는 자체 파일 시스템을 유지하며, node_modules 디렉터리를 포함한 에이전트 수십 개는 메모리 문제가 발생하기 훨씬 전에 작은 볼륨을 가득 채우게 됩니다.

동결, 정지, 아카이브: 수명 주기 제어 설정

기본값은 유휴 상태 10분 후 동결, 3일 후 정지이며, 아카이브가 설정된 경우 7일 후 아카이브됩니다. stopAfterSeconds를 null로 설정하면 상주 에이전트가 됩니다. 이 에이전트는 유휴 상태에서 동결될 수는 있으나, 콜드 스타트(cold start)는 발생하지 않습니다.

아카이브는 선택 사항이며, 데몬은 이에 대해 명확하게 동작합니다. 4개의 DORMICE_S3_* 변수를 설정하면 정지된 샌드박스의 디스크는 tar 및 zstd로 압축되어 S3 호환 버킷으로 전송된 뒤 로컬에서 삭제됩니다. 해당 버킷은 직접 호스팅하는 MinIO 버킷을 다른 머신에 구성하여 사용할 수 있습니다. 변수를 설정하지 않으면 샌드박스는 정지 상태로 영구히 유지되며, 아카이브 정책을 요청할 경우 무시되는 대신 거부됩니다. 복구 과정은 사용자에게 명확히 표시됩니다. 다음 acquire 요청 시 즉시 복구 중 상태와 진행률 값을 반환하며, 디스크가 준비되면 ready 상태로 전환됩니다.

지금 당장 의존해도 될까요?

결론부터 말씀드리면, 다시 구축할 수 없는 환경에는 사용하지 마십시오. 저장소의 첫 번째 커밋 날짜는 2026년 7월 8일입니다. 2026년 8월 4일 기준으로 별 446개, 포크 37개, Apache-2.0 라이선스를 기록하고 있으며, 태그가 지정된 릴리스는 전혀 없습니다. README의 상태 표시줄에도 프로덕션 환경에 적합한 것은 없다고 명시되어 있습니다.

이러한 조합은 특정한 형태의 위험을 내포합니다. 설치 프로그램이 main을 추적하므로 코드는 예고 없이 변경될 수 있습니다. 인터페이스는 여전히 정립되는 단계이며, 같은 저장소 내의 두 파일에서 삭제 명령(delete verb)의 이름이 서로 다른 이유도 바로 이 때문입니다. 또한 4주 된 프로젝트는 라이선스 조항상 유지 의무가 없으므로 언제든 개발이 중단될 수 있습니다.

이러한 위험을 감수할 수 있는 이유는 E2B 호환성 때문입니다. 귀하의 애플리케이션은 호스팅된 구현체가 뒷받침하는 프로토콜과 통신하므로, Dormice가 중단되더라도 URL 두 개만 변경하면 계속 운영할 수 있습니다. 네이티브 API 대신 E2B 인터페이스를 기준으로 에이전트를 작성하면 이러한 탈출구를 확보할 수 있습니다. 네이티브 @dormice/sdk 패키지 역시 아직 npm에 등록되지 않았으므로, 이를 사용하려면 저장소에서 직접 빌드해야 하며 이는 호환 가능한 경로로 시작해야 하는 두 번째 이유가 됩니다.

데이터 손실을 감수할 수 있는 환경에서 실행하십시오. 스크립트로 호스트를 재구축할 수 있도록 준비하고, 모든 프롬프트와 커밋에서 토큰이 노출되지 않도록 관리하며, 보존 가치가 있는 데이터는 자체 백업 일정에 따라 샌드박스 외부로 추출하십시오.

FAQ

Dormice는 프로덕션 환경에서 사용할 준비가 되었습니까?

아니요, 프로젝트 자체적으로도 그렇게 명시하고 있습니다. README의 상태 줄에는 아직 프로덕션 환경에 적합한 것이 없다고 나와 있으며, 2026년 8월 4일 기준으로 저장소는 생성된 지 4주 정도 되었고 git 태그나 릴리스가 없어 고정할 버전 번호가 없습니다. 설치 프로그램은 main 브랜치를 복제하므로, 실행할 때마다 가장 최신 커밋을 가져오게 됩니다. 설치할 때마다 git -C /opt/dormice rev-parse HEAD를 기록하고, 중요한 데이터는 샌드박스 외부에 보관하십시오.

Dormice는 에이전트에게 일회용 VM을 제공하는 것과 무엇이 다릅니까?

일회용 VM은 세션 동안 생성하고 이후 삭제하는 SSH 기반의 머신입니다. Dormice는 실행 API입니다. 프로그램이 acquire를 호출한 뒤 exec를 실행하면, 중간에 셸 세션 없이 stdout과 종료 코드를 바로 반환받습니다. VM은 잠시 동안 컴퓨터 전체를 사용하려는 사람이나 에이전트에게 적합합니다. Dormice는 생성된 코드를 하루에 여러 번 실행하면서 매번 머신을 설정하고 해제하는 과정을 거치고 싶지 않은 애플리케이션에 적합합니다.

공식 E2B SDK가 코드 변경 없이 정말로 작동합니까?

네, 설정 변경만으로 가능합니다. apiUrl과 sandboxUrl을 데몬의 /e2b/api와 /e2b/envd으로 지정하고, e2b_ 접두사를 붙여 Dormice 토큰을 API 키로 전달하십시오. 명령어 실행, PTY 세션, 파일 전송, 서명된 URL, 포트 프록시는 모두 공식 패키지를 통해 실행되는 프로젝트의 엔드투엔드 테스트 스위트에서 지원합니다. 템플릿 빌드는 눈에 띄는 차이점입니다. e2b template build는 구현되지 않았으므로, 템플릿은 직접 빌드하여 dor template add으로 등록하는 Docker 이미지여야 합니다.

4 GB VPS에 샌드박스를 몇 개나 올릴 수 있습니까?

운영체제, Docker, 데몬을 위해 약 1 GB를 예약한 후, 각 샌드박스가 512 MiB를 사용한다면 동시에 6개를, 각 1 GiB를 사용한다면 3개를 실행할 수 있습니다. 정지된(frozen) 샌드박스는 스왑 용량에 제한을 받으므로, 설치 프로그램의 기본값인 16 GB 스왑 파일은 각 1 GiB를 점유하는 샌드박스를 약 16개까지 수용할 수 있습니다. 테스트 스위트를 실행하는 샌드박스는 작은 스크립트를 실행하는 샌드박스보다 메모리를 훨씬 많이 사용하므로, 실제 부하 상태에서 free -m을 사용하여 직접 측정하십시오.

왜 Dormice는 vm.swappiness를 100으로 설정해야 합니까?

샌드박스를 정지한다는 것은 유휴 메모리를 스왑으로 밀어내는 것을 의미합니다. gVisor는 샌드박스 메모리를 공유 메모리로 유지하는데, Linux 커널은 기본 swappiness 설정에서 공유 메모리를 스왑하지 않습니다. 따라서 기본값에서는 정지해도 메모리가 회수되지 않아 샌드박스가 계속 전체 메모리 비용을 발생시킵니다. 프로젝트 측정 결과 기본값에서는 0 바이트가 회수되었으나 100으로 설정했을 때는 99.5 퍼센트가 회수되었습니다. 일부 클라우드 이미지는 0으로 설정되어 배포되므로, 설정 파일을 읽는 대신 sysctl vm.swappiness을 사용하여 실제 적용된 값을 확인하십시오.