From fork() to Fleet: Designing an Agent Sandbox Cloud — Abhishek Bhardwaj, OpenAI

한 줄 핵심

에이전트가 코드와 도구를 안전하게 실행하려면 단순한 fork()나 컨테이너를 넘어, 하드웨어 격리되는 micro VM과 스냅샷 기반 저장·오케스트레이션까지 포함한 sandbox cloud가 필요하다.

시간별 요약

1. 0:01
   이 영상은 ChatGPT와 Codex 같은 제품에서 불확실한 코드를 안전하게 실행하기 위한 agent sandbox cloud의 설계 원리를 처음부터 설명한다. 연구에서는 높은 처리량이, 제품에서는 낮은 지연시간과 신뢰성·보안이 핵심이며, 특히 runtime·persistence·orchestration이 중심 축이 된다.
2. 9:00
   Linux에서 가장 단순한 fork()+exec는 가장 빠르지만, 커널 공격과 noisy neighbor 문제를 동시에 안고 있어 실사용에 부적합하다. container는 namespaces와 cgroups, seccomp로 보호를 강화하지만 여전히 host kernel을 직접 공유하므로 보안 경계가 충분히 강하지 않다.
3. 16:00
   gVisor는 syscall을 user space에서 처리해 커널 노출을 줄이지만, 결국 host kernel 위에 있어 체인형 exploit 가능성을 완전히 없애지 못한다. 반면 virtualization과 micro VM은 guest와 host를 하드웨어 수준으로 분리해 host 보호를 크게 강화하며, Rust 기반 VMM과 device jail로 안전성을 더 높인다.
4. 30:00
   에이전트 작업이 길어질수록 disk persistence는 선택이 아니라 필수가 된다. incremental snapshot, copy-on-write, block-level diff, save API, tiered storage를 통해 작업 상태를 빠르게 저장·복원해야 노드 장애에도 중단 없이 이어갈 수 있고, 장기 탐색과 Monte Carlo식 재시도도 가능해진다.
5. 41:02
   여러 노드와 리전으로 확장하려면 스케줄러가 cluster 상태와 snapshot lineage를 함께 고려해야 한다. warm pool, memory snapshot의 즉시 기동, snapshot-rich restore를 조합하면 지연시간과 비용의 균형을 맞추면서 더 빠르고 안정적인 대규모 sandbox 운영이 가능하다.

실무 인사이트

• 실무에서는 보안을 먼저 기준으로 잡고, 성능은 pre-warm, 캐시, snapshot 최적화 같은 시스템 기법으로 보완하는 접근이 가장 안전하다.
• 에이전트용 sandbox는 실행 환경만이 아니라 저장·복원·스케줄링까지 하나의 제품 경험으로 설계해야 장기 작업과 실패 복구를 자연스럽게 지원할 수 있다.
• 장기적으로는 단발성 실행보다 checkpointable한 작업 흐름이 중요하므로, save/restore API와 snapshot lineage를 초기에 설계에 포함하는 것이 유리하다.