How I Learned to Stop Worrying and Love the Sandbox — Matt Brockman, E2B

한 줄 핵심

에이전트와 코드를 안전하게 실행하기 위해 E2B의 sandbox를 어떻게 설계·운영하는지, 그리고 실제로 마주치는 CPU·메모리·디스크·수명·권한 문제를 CTF 형식으로 해결하는 방법을 보여주는 영상이다.

시간별 요약

1. 0:00
   소개와 CTF 준비 E2B의 sandbox 워크숍과 capture the flag 진행 방식, 사용 환경, 참가자들이 접속할 실습 페이지를 안내한다. 초반 몇 단계는 코딩보다 설정과 sandbox 동작을 이해하는 데 초점이 맞춰져 있다.
2. 2:51
   에이전트가 sandbox를 필요로 하는 이유 에이전트가 로컬이나 서버에서 마음대로 실행되면 CPU 소모, 프로세스 폭주, 파일 삭제, 환경변수 노출 같은 위험이 생기므로 격리된 실행 환경이 필요하다. sandbox는 이런 위험을 줄이면서도 빠르게 띄우고 여러 작업을 동시에 돌릴 수 있게 해준다.
3. 4:27
   스냅샷과 템플릿 sandbox는 메모리와 파일시스템 상태를 스냅샷으로 저장해, 중단 후에도 같은 상태로 즉시 재개할 수 있어야 한다. 템플릿은 이미 프로세스가 올라간 상태를 복제해 빠르게 여러 sandbox를 만드는 방식이며, 실험 분기나 병렬 작업에 유리하다.
4. 8:08
   실습실 열기와 sandbox ID 찾기 처음 단계에서는 dashboard와 실습용 sandbox에 접속하고, URL에 포함된 sandbox ID를 찾아 입력하는 방법을 익힌다. sandbox 식별자와 포트 기반 URL 구조가 어떻게 연결되는지 이해하는 것이 이 단계의 핵심이다.
5. 16:02
   폭주 프로세스와 격리된 환경 sandbox 안에서 비정상적으로 CPU를 많이 쓰는 프로세스를 발견하고 종료하는 과정을 통해, 격리가 왜 중요한지 보여준다. 템플릿에서 복제된 새로운 sandbox를 다시 불러와도 초기 상태가 보존되므로 문제를 안전하게 재현하고 수정할 수 있다.
6. 18:43
   CPU 사용량 디버깅 top 같은 도구로 CPU를 잡아먹는 프로세스를 찾고, 해당 PID를 kill 해서 자원을 회수한다. 에이전트나 자동화 작업이 예상치 못하게 무거운 작업을 만들 때 가장 먼저 확인해야 할 기본 운영 절차를 다룬다.
7. 20:30
   메모리 압박 메모리도 CPU와 마찬가지로 무제한이 아니므로, sandbox가 과도한 RAM을 쓰면 전체 fleet의 안정성이 흔들린다. 메모리 사용량이 큰 프로세스를 찾아 정리하고, 리소스 제한과 비용 균형을 함께 고려해야 한다.
8. 21:57
   가득 찬 디스크 찾기 디스크가 가득 차면 파일 생성과 작업 재개가 막히므로, 어떤 경로가 용량을 차지하는지 찾아내는 절차가 필요하다. 실습에서는 특정 임시 파일이 문제라는 사실을 확인하고, 이를 지워야만 다음 단계로 진행할 수 있음을 보여준다.
9. 25:12
   디스크 정리 실습 수정 디스크 문제 해결은 파일을 삭제하는 것이 아니라, 용량을 차지하는 경로를 정확히 찾아 입력하고 정리 명령을 실행하는 과정이다. 잘못된 조작으로 데모가 깨져도 sandbox를 재시작하면 원래 상태로 돌아가므로, 실험과 복구가 쉬운 점을 강조한다.
10. 31:14
    sandbox 수명과 유휴 타임아웃 사용자가 잠깐 머무는 경우와 장시간 작업하는 경우를 모두 고려해, sandbox의 유지 시간을 동적으로 설계해야 한다. 작업 중에는 길게 살리고, 끝난 뒤에는 짧은 유휴 타임아웃으로 정리해 비용과 응답성을 함께 맞춘다.
11. 39:04
    백그라운드 프로세스 정리 재사용되는 sandbox에서는 종료되지 않은 자식 프로세스가 누적되어 성능을 갉아먹는다. 남아 있는 프로세스를 찾아 종료하고, 정리되지 않은 리소스를 회수하는 습관이 운영 안정성의 핵심이다.
12. 42:31
    사용자와 작업공간 매핑 여러 사용자가 같은 sandbox를 공유하거나 매번 랜덤으로 받으면 상태 재현이 어려워지므로, 사용자별로 sandbox ID를 매핑해야 한다. 사용자- sandbox 대응표를 유지하면 같은 사용자가 같은 환경으로 돌아와 반복 작업을 이어가기 쉽다.
13. 48:30
    파일시스템 권한과 런타임 캐시 모든 경로에 쓰기 권한을 주는 대신 템플릿 캐시와 런타임 캐시를 분리해, 읽기 전용과 쓰기 전용 영역을 나눠야 한다. 에이전트가 어디에 무엇을 쓸 수 있는지 제한하면 안정성과 보안이 함께 좋아진다.
14. 50:08
    sandbox 운영에 대한 질의응답 실서비스에서 sandbox를 어떻게 쓰는지, GPU 작업이나 분산 처리 같은 사례가 어떤 제약을 받는지에 대한 질문이 오간다. 대규모 sandbox 운영에서는 개별 오류보다 로깅, 네트워크, 자원 관리 같은 운영 복잡도가 더 큰 문제가 된다는 점이 드러난다.
15. 54:24
    저장소, 볼륨, 오케스트레이션 여러 sandbox의 상태를 오래 보관하고 재사용하려면 저장소, 압축, 볼륨 설계가 중요하며, shared resource는 volumes로 묶어 쓸 수 있다. 동시에 Firecracker, Nomad, Kubernetes 같은 오케스트레이션 선택과 확장성 문제도 함께 다뤄진다.
16. 57:12
    템플릿, 로컬 개발, 네트워크 접근 sandbox 생태계는 아직 초기이지만, 템플릿과 재사용 패턴이 표준처럼 자리 잡을 가능성이 높다. 로컬 개발과 네트워크 규칙, 시크릿 노출 제한을 어떻게 조합하느냐가 속도와 보안의 균형을 결정한다.

실무 인사이트

• 에이전트용 sandbox는 단순한 실행 환경이 아니라, 스냅샷·수명 관리·권한 분리까지 포함한 운영 시스템으로 봐야 한다.
• 실무에서는 CPU·메모리·디스크 중 하나만 최적화하면 부족하고, 재사용성과 비용 절감을 위해 프로세스 정리와 유휴 타임아웃까지 함께 설계해야 한다.
• 사용자별 상태 고정, 캐시 분리, 네트워크 제한을 미리 넣어두면 에이전트가 커져도 디버깅과 보안 대응이 훨씬 쉬워진다.