걱정을 멈추고 샌드박스를 사랑하게 된 과정 — Matt Brockman, E2B

URL: https://www.youtube.com/watch?v=fz6-NS7qpZc
날짜: 2026-10-06
채널: aiDotEngineer
발표자: Matt Brockman, E2B 엔지니어
형식: 샌드박스 운영 강의와 Capture the Flag(CTF) 실습 워크숍

---

📌 핵심 질문 / 핵심 논점

==임의의 사용자 코드와 AI 에이전트를 다른 사용자와 호스트 시스템으로부터 격리하면서도 100밀리초 이하로 시작하고, 중단·재개·대규모 관리를 효율적으로 수행하려면 샌드박스를 어떻게 설계해야 하는가?==

• 샌드박스는 사용자별 코드를 다른 사용자에게 영향을 주지 않게 실행하며 로컬 실행과 공유 서버 실행의 권한·시크릿·자원 문제를 동시에 완화한다.
• E2B는 실행 중인 프로세스와 파일 시스템·RAM을 스냅샷해 멈춘 상태를 저장하고, 프로세스가 이미 실행 중인 템플릿에서 샌드박스를 100밀리초 이하로 되살리는 방향을 택한다.
• CPU·메모리·디스크 고갈, 오래된 백그라운드 프로세스, 사용자별 샌드박스 매핑, 파일 시스템 권한, 수명·스토리지·네트워크 정책을 직접 관리해야 수백~수천 개의 샌드박스를 운영할 수 있다.

샌드박스의 가치는 단순한 격리에 있지 않다. 에이전트가 코드를 실행하는 동안 안전한 경계를 제공하고, 필요할 때 빠르게 복제하며, 작업이 끝나면 비용을 줄이기 위해 일시정지하고, 다음 명령이 오면 동일한 상태를 복원하는 운영 모델에 있다. 소규모 실행에서는 명확하지 않은 문제가 수백~수천 개의 샌드박스로 확장될 때 자원 쿼터, 오케스트레이션, 로그, 네트워크, 저장 공간 문제로 변한다.

1. 워크숍의 시작과 실습 환경

샌드박스의 개념 설명은 참가자들이 직접 E2B 샌드박스를 만들고 CTF 단계별 문제를 풀 수 있도록 구성됐다.

1.1. 참가자 확인과 CTF 규칙

1. 발표자와 청중 인사

   1. Matt의 소개: Matt는 E2B의 엔지니어이며 E2B가 샌드박스를 만든다고 소개했다.
   2. 청중 반응: 아침 인사를 받은 청중은 응답했지만, Matt는 청력이 좋지 않아 잘 듣지 못했다며 다시 물었고 청중은 다시 크게 응답했다.
   3. 참가자 구성: 샌프란시스코 기반 참가자와 타주에서 온 참가자가 모두 있었고, 타주 참가자가 상당수였다.

2. Capture the Flag 진행 방식

   1. 단계형 해제: 각 레벨의 문제를 풀면 다음 레벨이 잠금 해제되는 연속 구조를 사용했다.
   2. 언어 지원: E2B SDK는 Python과 JavaScript를 지원하며, 초반 여러 레벨은 코드를 작성하지 않고 설정과 샌드박스 동작을 관찰하는 방식으로 풀 수 있다.
   3. 참가자의 배경: Python 사용자가 대부분이었고 JavaScript 사용자와 Go 엔지니어도 확인했다.
   4. 채용 안내: E2B 백엔드가 주로 Go로 작성됐기 때문에 Go 엔지니어를 절실히 찾고 있으며, 행사 중이나 이후 채용 페이지를 확인해 달라고 안내했다.
   5. 비개발자 참여: 코딩을 전혀 하지 않는 참가자도 있었고, 초반 레벨은 비개발자도 진행할 수 있게 설계됐다.

1.2. 접속과 현장 운영

1. 샌드박스 접속

   1. 초대 링크와 QR 코드: 참가자는 tinyurl 링크나 화면의 QR 코드를 통해 E2B에 로그인하고 워크숍 샌드박스를 받아야 했다.
   2. 워크숍의 표현: Matt는 모든 것이 샌드박스 안에 있고, 샌드박스에서 발생하는 문제를 샌드박스로 풀기 때문에 “sandboxes all the way down”이라고 표현했다.
   3. 진행 선택권: 참가자는 바로 지시를 따라 해킹하듯 문제를 풀거나 Matt의 샌드박스 설명을 들은 뒤 함께 CTF를 시작할 수 있었다.
   4. 스타트업 프로그램: E2B는 스타트업에 크레딧과 무료 플랜을 제공하는 프로그램을 운영한다.

2. 접속 장애와 현장 대응

   1. Wi-Fi 문제: 일부 참가자는 인터넷 연결 때문에 접속하지 못했고, E2B 행사 전용 Wi-Fi는 처음 한 칸만 잡히다가 연결을 끊었다가 다시 연결하면 다섯 칸으로 올라가는 우회 방법이 있었다.
   2. 화면과 URL 문제: 터미널 글씨가 작다는 요청에 Matt는 화면을 확대했고, 접속 URL을 여러 번 다시 보여주고 음성으로도 tinyurl.com/wh46sx6를 읽어 줬다.
   3. 가입 필요: E2B를 사용하려면 회원가입이 필요했고, 원격 샌드박스에서 모든 것이 실행되므로 참가자 컴퓨터와의 왕복은 최소화됐다.
   4. 협업 대응: 계속 로딩 중인 사람은 도우미에게 도움을 요청하거나, 먼저 접속한 친절한 참가자 옆에 앉아 짝을 이루도록 했다.
   5. 현장 농담: Matt는 참가자에게 손을 들고 내리는 상호작용을 반복하게 하며 다음에는 “Simon Says”를 하겠다고 농담했고, 화면에 크게 보이는 AI 생성 예술이 작은 화면보다 덜 아름답다고 말했다.

2. 샌드박스의 목적과 E2B의 설계

샌드박스는 신뢰할 수 없는 사용자 코드와 AI가 생성한 코드를 격리하면서 빠른 실행과 상태 보존을 제공하는 실행 단위다.

2.1. 왜 샌드박스가 필요한가

1. 사용자 코드 격리

   1. 기본 정의: 샌드박스는 사용자별 코드를 실행하되 다른 사용자에게 영향을 주지 않게 한다.
   2. 전통적 웹 스택의 한계: 정적인 웹 페이지는 사용자가 코드를 실험하거나 AWS EC2 같은 실행 환경에 들어가 직접 코드를 실행하는 요구를 충분히 해결하지 못한다.
   3. 협업형 실행: 사용자는 Colab처럼 코드를 가지고 놀 수 있는 공간이나 EC2처럼 직접 접근할 수 있는 환경을 원할 수 있다.

2. AI 에이전트 실행의 위험

   1. 로컬 실행 위험: Codex나 Claude Code 같은 도구를 로컬 컴퓨터에서 높은 권한으로 실행하면 에이전트가 CPU를 모두 사용하고, 여러 프로세스를 만들고, 지우지 말아야 할 파일을 삭제하고, 환경 변수를 읽을 수 있다.
   2. 서버 실행 위험: 서버로 옮겨도 시크릿과 환경 변수가 남고, 에이전트가 상호작용해야 하는 모든 도구와 파일이 올바르게 준비되어 있어야 한다.
   3. 샌드박스의 경계: 샌드박스는 에이전트가 임의 코드를 실행할 장소를 분리해 로컬 시스템과 공유 서버의 피해 범위를 줄인다.

2.2. 빠른 시작과 상태 보존

1. 빠른 기동

   1. 목표 지연 시간: E2B는 샌드박스를 100밀리초 이하에 시작하는 것을 목표로 한다.
   2. 동시 실행: 짧은 기동 시간은 여러 샌드박스를 동시에 실행할 수 있게 한다.
   3. 실행 중인 프로세스 중심 접근: Docker처럼 이미지를 시작한 뒤 start command에서 프로세스를 띄우는 대신, E2B는 프로세스를 먼저 실행해 둔 상태를 기반으로 샌드박스를 제공한다.

2. 스냅샷과 재개

   1. 상태 저장: E2B는 메모리와 파일 시스템을 스냅샷해 사용자가 노트북을 닫았다가 다시 열었을 때처럼 샌드박스를 멈춘 상태에서 이어서 사용할 수 있게 한다.
   2. 에이전트의 기대: 다른 작업을 처리하러 떠났던 에이전트는 시간이 흘렀다는 사실을 모른 채 떠나기 직전의 상태가 그대로 있을 것이라고 기대한다.
   3. 오류 감소: 메모리·파일 시스템·실행 상태를 그대로 복원하면 에이전트가 이전 상태를 잃어버려 발생하는 오류가 줄어든다.
   4. 템플릿 모델: E2B 템플릿은 프로세스를 실행한 뒤 그 VM을 스냅샷한 것이다.
   5. 템플릿과 Docker의 차이: Docker는 이미지에서 컨테이너를 시작할 때 프로세스를 실행하지만, E2B 템플릿은 이미 실행 중인 프로세스가 있는 상태로 복원된다.

3. 기술 스택과 공개성

   1. 구현 언어: E2B 백엔드는 대부분 Go로 작성됐고 SDK는 Python과 JavaScript로 제공되며 다른 언어 지원도 확장 중이다.
   2. 오픈 소스: E2B는 인프라를 오픈 소스로 공개하고 있으며 관련 링크와 문서를 제공한다.
   3. 일반 사용법: 일반적으로 e2b.dev에서 API 키를 만들고 문서를 확인해 샌드박스를 프로그래밍한다.
   4. 워크숍 사용법: 이번 워크숍에서는 API 키를 직접 다루는 대신 대시보드가 샌드박스를 생성해 참가자가 빠르게 시작하도록 했다.

2.3. 대규모 운영을 전제로 한 문제 정의

1. 규모에 따른 문제 변화

   1. 소규모: 샌드박스 한두 개는 멈추고 재개하는 과정을 사람이 직접 확인하기 쉽다.
   2. 대규모: 수백~수천 개가 되면 샌드박스가 독립적으로 움직이는 것처럼 보이고 자원·상태·네트워크·로그를 모두 관리해야 한다.
   3. 실습의 목적: 워크숍의 시뮬레이션은 단일 샌드박스의 문제가 아니라 플릿(fleet) 운영에서 발생하는 문제를 체험하게 한다.

2. AI를 이용한 실습과 검토

   1. 에이전트 활용: 2026년의 참가자는 각 레벨에서 받은 샌드박스 ID를 AI 에이전트에 주고 E2B SDK 코드를 작성하게 할 수 있다.
   2. 학습 목적: 손으로 직접 코드를 작성하는 편이 샌드박스 동작을 배우는 데 더 좋을 수 있다.
   3. 검토 원칙: AI가 작성한 코드를 그대로 믿지 말고 항상 결과를 검토해야 한다.
   4. 자기 풍자: Matt는 “AI에게 코드를 쓰게 하더라도 검토하라”고 말한 뒤 “내가 하는 대로 하지 말고 내가 말하는 대로 하라”고 농담했다.

3. CTF 초반: 식별자와 자원 고갈

초반 레벨은 대시보드와 터미널에 익숙해지면서 CPU·메모리·디스크가 고갈될 때 원인을 찾아 정리하는 운영 기본기를 연습하게 했다.

3.1. 레벨 1 — 샌드박스 ID 찾기

1. 대시보드 구조

   1. 웹 UI: 참가자는 샌드박스를 확인하는 E2B 웹 UI와 내부 터미널에 접속했다.
   2. PTY 연결: 터미널은 샌드박스에 PTY 세션을 연결하는 인터페이스였다.
   3. API 키 위치: 대시보드의 API Keys 메뉴에서 API 키를 만들 수 있지만 초반 문제에는 필요하지 않았다.

2. 식별자와 URL

   1. 문제: 참가자는 현재 들어와 있는 샌드박스의 ID를 찾아 입력해야 했다.
   2. 치트 코드: 샌드박스 ID가 URL에 포함되어 있으므로 URL에서 ID를 복사해 답안 칸에 붙여 넣을 수 있었다.
   3. 식별자의 역할: 샌드박스 ID는 다시 같은 샌드박스로 돌아가기 위한 식별자다.
   4. 포트 URL 규칙: E2B URL은 접속 대상 포트와 샌드박스 ID를 조합해 만들어지며, 샌드박스에서 포트를 듣는 서비스를 외부에 노출하고 통신을 열 수 있다.

3. 현장 반응

   1. 난이도 농담: 참가자가 ID 찾기부터 어렵다고 반응했고, 사람마다 샌드박스 ID가 다르다는 점이 확인됐다.
   2. 도우미: 뒤쪽의 E2B go-to-market 담당자가 도우미로 소개됐고, Wi-Fi가 작동하지 않는 참가자를 지원했다.

3.2. 템플릿과 복제

1. 새 샌드박스 생성

   1. 안전한 실습: 각 레벨은 새 샌드박스를 만들어 기존 샌드박스를 망가뜨려도 초기 상태에 영향을 주지 않게 했다.
   2. 재시작 버튼: 대시보드의 reload 버튼을 누르면 스냅샷에서 새 샌드박스를 다시 만들 수 있다.
   3. 템플릿 정의: 템플릿은 VM을 시작하고 CTF에 필요한 프로세스를 실행한 뒤 저장한 스냅샷이다.

2. 대량 복제의 의미

   1. 워크숍 복제: Matt가 미리 시작한 VM을 템플릿으로 저장했고 참가자 약 200명이 같은 상태에서 각자의 샌드박스를 시작했다.
   2. 데이터 과학 사례: 데이터 프레임을 여러 방식으로 변형하는 실험을 다섯 개 하고 싶다면 현재 상태를 다섯 샌드박스로 포크해 병렬로 실행할 수 있다.
   3. 개발 사례: 에이전트가 기본 의존성을 설치한 템플릿을 GitHub Actions 캐시처럼 재사용하고, 여러 worktree를 같은 기반에서 파생할 수 있다.
   4. 외부 에이전트 연결: 샌드박스 ID와 E2B API 키를 환경 파일에 넣으면 로컬 Codex나 Claude Code가 원격 샌드박스에 접근해 문제를 풀게 할 수 있다.

3.3. 레벨 2 — CPU runaway 정리

1. 문제 상황

   1. AI 코드의 부작용: AI가 예상하지 못한 코드를 작성하면 프로세스가 CPU를 과도하게 사용할 수 있다.
   2. CPU 상태: 문제 샌드박스에는 CPU를 99.7% 사용하는 프로세스가 실행 중이었다.
   3. 확인 정보: 터미널은 프로세스 ID, CPU 사용량, 메모리 사용량 등을 보여 줬다.

2. 해결 절차

   1. 프로세스 찾기: 제공된 명령과 힌트를 이용해 CPU를 많이 사용하는 프로세스를 확인했다.
   2. 프로세스 종료: PID 1250을 종료해 runaway 프로세스를 제거했다.
   3. 레벨 해제: 종료가 확인되자 페이지에서 다음 레벨로 이동할 수 있는 코드를 제공했다.
   4. 학습 포인트: 샌드박스 안에서도 일반 Linux 서버처럼 프로세스 상태와 자원 사용량을 관찰하고 문제 프로세스를 종료해야 한다.

3.4. 레벨 3 — 메모리 고갈

1. 자원 트레이드오프

   1. CPU 수와 속도: CPU를 여러 개 할당하면 작업이 빨라지지만 더 많은 자원을 소비하고, CPU 수를 줄이면 실행 속도가 느려진다.
   2. 플릿 쿼터: 샌드박스 플릿에는 사용할 수 있는 CPU와 RAM의 총량 쿼터가 있으므로 한 인스턴스가 자원을 과도하게 쓰면 다른 작업을 실행하기 어렵다.
   3. 운영 목표: 같은 작업을 수행하면서 RAM 사용량을 최소화하는 방법을 찾아야 한다.

2. 해결 절차

   1. 메모리 프로세스 확인: 제공된 명령으로 어떤 프로세스가 메모리를 소비하는지 확인했다.
   2. 문제 프로세스 종료: 메모리를 과도하게 사용하는 프로세스를 종료해 레벨을 해결했다.
   3. 실습 속도: 참가자가 진행 속도를 묻자 Matt는 빠르지도 느리지도 않은 적절한 속도라는 청중의 반응을 확인했다.

3.5. 레벨 4 — 디스크 채우기

1. 디스크 고갈 확인

   1. 새 상태: 새 샌드박스에는 문제 지시문과 README가 있었고 ls로 파일을 확인할 수 있었다.
   2. 원인 탐색: 디스크 사용량을 확인해 어떤 경로가 공간을 모두 차지했는지 찾아야 했다.
   3. 문제 파일: /tmp/selfone_diskfill.bin 파일이 512MB의 디스크 공간을 차지했다.

2. 정리와 실수

   1. 스크립트 사용: 힌트의 스크립트 또는 du 명령으로 큰 파일을 찾고, 경로를 페이지의 path checker에 붙여 넣었다.
   2. 정리 버튼: 경로를 제출한 뒤 cleanup을 누르면 페이지가 삭제 명령을 실행하고 완료 플래그를 반환했다.
   3. 데모 오류: Matt는 경로를 삭제 명령에 넣어야 하는데 파일을 먼저 지워 버리는 식으로 시연을 한 번 망쳤고, “쉬운 레벨이 생각보다 쉽지 않았다”고 말했다.
   4. 복구: reload 버튼으로 원래 스냅샷에서 새 복사본을 만들어 다시 시도했고, 이번에는 파일 경로를 올바른 칸에 넣어 문제를 해결했다.
   5. 참가자 지원: 파일이 보이지 않는 참가자에게는 샌드박스를 재시작하면 초기 스냅샷이 복원된다고 안내했다.

3. 초반 레벨의 결론

   1. 운영 기본기: CPU·RAM·디스크 문제는 임의 코드 실행 환경에서 가장 먼저 감시해야 할 자원이다.
   2. 재현성: 스냅샷을 다시 불러오는 기능은 데모 실수와 참가자별 상태 차이를 빠르게 복구한다.
   3. 휴식: 쉬운 Linux 문제 세 개를 끝낸 뒤 Matt는 참가자에게 잠깐 일어나 스트레칭하자고 했고, E2B를 “calisthenics 회사”라고 농담했다.

4. 샌드박스 수명 주기와 비용 관리

샌드박스의 수명은 작업 실행 시간에는 길게 허용하고 작업 종료 후에는 짧게 줄이는 상태 머신으로 설계해야 비용과 응답성을 함께 맞출 수 있다.

4.1. 사용자 행동에 따른 수명 설계

1. 짧은 사용과 낭비

   1. 사용자당 샌드박스: 수천~수만 명에게 애플리케이션 방문 즉시 샌드박스를 하나씩 주는 모델을 생각할 수 있다.
   2. 고정 20분의 문제: 방문자가 20분 동안 사용하지 않으면 종료하는 단순한 정책도, 한 번만 쓰거나 아예 상호작용하지 않는 사용자가 많으면 샌드박스 자원을 낭비한다.
   3. 짧은 확인 사용: 사용자가 잠깐 실행해 보고 “작동하네”라고 떠나는 경우에는 첫 명령을 처리한 뒤 샌드박스가 사라지고, 약 10분 뒤 다시 방문할 때 다시 나타나는 방식이 더 적합하다.

2. 장시간 작업과 반대되는 요구

   1. 작업 유형: 데이터 과학, 웹 스크래핑, 대용량 파일 읽기, 비디오 처리는 10~15분 또는 그 이상 걸릴 수 있다.
   2. 긴 실행 허용: 작업이 진행되는 동안 샌드박스가 너무 빨리 종료되면 사용자의 결과가 사라지므로 작업 시간만큼 긴 런타임을 줘야 한다.
   3. 비용 절감: 작업이 끝난 뒤에도 계속 실행하면 비용을 “태양을 향해 돈을 먹이는” 것처럼 낭비하게 되므로 완료 후 짧은 timeout을 적용해야 한다.

4.2. 레벨 — runtime lifetime 정책

1. 정책 설정

   1. 명령 타임아웃: 작업이 최대 한 시간 실행될 수 있도록 command timeout을 한 시간으로 설정했다.
   2. 짧은 사후 수명: 작업이 끝난 뒤 샌드박스가 한 분만 남도록 lifetime을 1분으로 줄였다.
   3. 시뮬레이션: 실제로 한 시간을 기다리지 않도록 긴 작업을 시뮬레이션해 상태 전환을 확인했다.

2. 상태 전환

   1. 실행 상태: 사용자가 작업을 시작하면 샌드박스는 작업이 끝날 때까지 살아 있어야 한다.
   2. 완료 상태: 결과를 반환하면 짧은 유예 시간 동안 다음 명령을 기다린다.
   3. 일시정지 상태: 추가 상호작용이 없으면 샌드박스를 일시정지하거나 종료해 자원을 회수한다.
   4. 재개: 사용자가 돌아오면 저장된 상태를 재개해 이전 작업을 이어간다.

3. 속도와 비용의 균형

   1. 실행 중 비용: 샌드박스가 실행 중이면 응답이 빠르지만 CPU와 RAM을 점유한다.
   2. 일시정지 비용: 샌드박스를 일시정지하면 비용이 저렴하고 많은 샌드박스를 보관할 수 있지만 다시 깨우는 시간이 필요하다.
   3. 에이전트의 불확실성: AI가 언제 같은 샌드박스를 다시 사용할지 모르므로 에이전트당 20개처럼 여러 샌드박스를 갖는 환경에서는 속도·비용·동시성 정책을 함께 정해야 한다.
   4. 장기 데몬의 한계: 하루 종일 지속되는 데몬은 샌드박스로도 실행할 수 있지만 CDN이 최적화된 전통적 서버 등 더 저렴하고 적합한 방법이 있을 수 있다.

4.3. 개발 환경과 세션 재사용

1. 개발에의 적용
   1. 기본 의존성 캐시: AI 에이전트가 샌드박스에 기본 의존성을 미리 설치하면 GitHub Actions 캐시처럼 재사용할 수 있다.
   2. 작업 트리: 하나의 기본 환경에서 여러 worktree를 파생해 각 작업을 독립적으로 진행할 수 있다.
   3. 클라우드 세션: 클라우드에서 실행되는 에이전트도 언제 돌아올지 불확실하므로 상태를 남겨 두고 빠르게 복원하는 세션 모델이 유용하다.

5. 백그라운드 프로세스 누수와 고아 정리

스냅샷 재개는 빠른 복원의 장점과 함께 이전 실행에서 남은 프로세스가 누적되는 단점을 가져오므로 고아 프로세스 정리가 샌드박스 관리의 핵심 업무가 된다.

5.1. 프로세스 누수의 원인

1. 재사용의 양면성

   1. 누적: 샌드박스에서 프로세스를 실행한 뒤 다른 작업을 하고 돌아오면 이전 프로세스가 계속 살아 있어 새 프로세스와 함께 쌓일 수 있다.
   2. 성능 저하: 고아 프로세스가 늘어나면 CPU·메모리를 소비하고 샌드박스 성능을 떨어뜨린다.
   3. 이미지 재생성과의 차이: 매번 새 이미지를 만드는 시스템은 이전 프로세스가 남지 않지만, 상태를 재개하는 샌드박스는 빠른 대신 정리하지 않은 상태도 그대로 복원한다.

2. 운영 관찰

   1. 관리 추적: 샌드박스를 생성할 때 추적 정보를 잃으면 더 이상 관리하지 않는 샌드박스를 찾아 자원을 회수해야 한다.
   2. 일반 서버 문제: 고아 프로세스는 샌드박스에만 있는 문제가 아니며, 일반 서버에서도 사용하지 않는 프로세스가 쌓이는 일이 흔하다.
   3. Matt의 요약: 샌드박스 관리의 상당 부분은 고아 프로세스를 죽이는 일로 귀결될 수 있다.

5.2. 고아 프로세스 CTF

1. 탐색

   1. 현황 확인: 샌드박스에 살아 있는 고아 자식 프로세스가 세 개 있었다.
   2. 검색 규칙: 실습에서는 프로세스 이름이 orphan worker로 단순화돼 있어 grep으로 쉽게 찾을 수 있었다.
   3. 현실의 차이: 실제 운영 환경에서는 누수 프로세스가 이렇게 친절한 이름을 갖지 않는다고 강조했다.

2. 종료

   1. 첫 번째 정리: PID 448을 종료한 뒤 다시 확인하자 고아 프로세스가 두 개 남았다.
   2. 두 번째 정리: PID 449와 450을 종료했다.
   3. 완료 확인: 모든 고아 프로세스가 사라지자 웹 페이지가 상태를 감지해 다음 레벨 코드를 표시했다.

6. 사용자별 워크스페이스와 샌드박스 할당

라운드 로빈으로 샌드박스를 무작위 배정하면 같은 사용자의 상태가 유지되지 않으므로 사용자 ID와 샌드박스 ID의 매핑을 보존해야 한다.

6.1. 라운드 로빈의 문제

1. 나이브한 관리

   1. 기존 방식: 샌드박스 풀을 사용자에게 순서대로 나눠 주는 라운드 로빈 방식은 어떤 사용자가 어떤 샌드박스를 받았는지 기억하지 않는다.
   2. 상태 손실: 사용자가 다시 요청하면 다른 샌드박스를 받아 이전 코드와 파일을 찾지 못할 수 있다.
   3. 과도한 생성 방지: 요청마다 새 샌드박스를 만들면 실제로 필요하지 않은 인스턴스가 늘어나므로 할당 결과를 재사용해야 한다.

2. 영속적 관리

   1. 데이터베이스 모델: 일반적인 구현은 사용자 목록과 사용자별 활성 샌드박스를 데이터베이스에 기록한다.
   2. 운영 이력: 영속 데이터를 보관하면 샌드박스를 사용자에게 너무 자주 재할당했는지와 과거 운영 상황을 확인할 수 있다.
   3. 실습 단순화: CTF에서는 데이터베이스 대신 assignments 딕셔너리를 캐시로 사용했다.

6.2. Python 핸들러 수정

1. 할당 함수

   1. 파일 선택: Python 참가자가 많아 router.py를 열었고 JavaScript 경로도 있었지만 Python으로 진행했다.
   2. 기존 함수: assign_sandbox 함수는 매번 샌드박스를 할당하는 뼈대를 제공했다.
   3. 캐시 조회: 사용자 ID가 assignments에 이미 있으면 저장된 샌드박스 ID를 반환한다.
   4. 최초 할당: 사용자 ID가 없으면 새 샌드박스를 만들고, 샌드박스에서 ID를 얻어 사용자 키에 저장한 뒤 그 ID를 반환한다.

2. 테스트와 실수

   1. 시간 제약: 이 레벨을 풀 수 있는 시간은 약 15분 남아 있었고, 화면 아래에 있는 키보드로 코드를 입력하기가 어려웠다.
   2. 테스트 실패: 처음에는 샌드박스 ID를 assignments에 추가하지 않아 “false is not true” 테스트 실패가 발생했다.
   3. 청중의 도움: 한 참가자가 누락된 추가 작업을 지적했고 Matt는 그 문제가 청중을 시험한 것이라며 참가자가 통과했다고 농담했다.
   4. 통과와 고아: 매핑 저장을 추가하자 테스트가 통과했지만, 데모 중 새 샌드박스를 여러 번 만들어 고아 프로세스가 다시 생겼고 웹 페이지가 갱신될 때까지 잠시 기다려야 했다.

6.3. 사용자 전용 워크스페이스의 의미

1. 핵심 매핑
   1. 자료구조: user_id → sandbox_id 매핑이 각 사용자가 같은 샌드박스를 재사용하게 하는 최소 모델이다.
   2. 재실행: 사용자는 같은 샌드박스에서 코드를 다시 실행하므로 파일과 프로세스 상태를 이어갈 수 있다.
   3. 확장 방향: 실제 서비스에서는 매핑을 데이터베이스에 두고 수명·상태·소유권을 함께 관리해야 한다.

7. 파일 시스템 권한과 캐시 분리

AI 에이전트가 파일 시스템 전체를 읽고 쓰지 못하게 하려면 허용된 읽기·쓰기 경로를 명확히 나누고 실행 코드가 올바른 캐시를 사용하게 해야 한다.

7.1. 에이전트의 파일 권한

1. 권한 범위

   1. 읽기·쓰기 제한: Codex와 Claude Code 같은 에이전트가 파일 시스템의 모든 영역에 쓰지 못하도록 읽고 쓸 경로를 구분해야 한다.
   2. 에이전트 지침: 실제 제품에서는 agents.md 같은 파일에 에이전트가 읽거나 쓸 수 있는 위치를 명시할 수 있다.
   3. 실습 방식: 워크숍에서는 이해하기 쉽도록 허용 경로를 코드에 하드코딩했다.

2. 캐시 종류

   1. 템플릿 캐시: 템플릿을 빌드할 때 생성되는 정보는 읽기 전용으로 두는 캐시다.
   2. 런타임 캐시: 실행 중인 크래셔(crasher) 또는 애플리케이션이 기록해야 하는 정보는 별도의 런타임 캐시에 둔다.
   3. 문제 해결: 코드가 템플릿 캐시에 쓰려고 하면 권한 문제가 생기므로 런타임 캐시를 참조하도록 수정했다.

7.2. 남은 레벨과 학습 목표

1. 레벨 진행

   1. 실습 범위: 파일 시스템 권한 레벨까지 진행한 뒤 약 10분이 남았다.
   2. 남은 문제: 이후에도 약 여덟 개의 레벨이 남아 있었지만 현장에서 모두 걸어가며 풀 시간은 부족했다.
   3. 참가자 선택: Matt는 남은 레벨을 계속 설명할지 샌드박스에 대해 대화할지 물었고 청중은 대화를 선택했다.

2. 운영 주제

   1. 관리 범위: 샌드박스 운영에는 실행 자원뿐 아니라 어떤 주체가 무엇을 읽고 쓸 수 있는지까지 포함된다.
   2. 기본 원칙: 사용자별 상태, 자원 상한, 프로세스 정리, 권한 분리를 함께 적용해야 에이전트 실행을 예측 가능하게 만들 수 있다.

8. 공개 Q&A: 실전 사용 사례와 한계

질의응답은 이미 프로덕션에서 샌드박스를 쓰는 팀의 요구, GPU 분산 처리, 스토리지 정리, Kubernetes·Nomad, 중첩 샌드박스, 생태계와 보안 정책을 다뤘다.

8.1. 프로덕션 에이전트 워크로드

1. 현장 사용 현황
   1. 사용자 확인: 청중 중 일부는 이미 프로덕션에서 샌드박스를 사용하고 있었고, 그중 한 팀은 에이전트 워크로드를 실행했다.
   2. 문제 경험: 해당 팀은 아직 이날 다룬 CPU·메모리·고아·권한 문제를 겪지 않았지만, 샌드박스를 쓰면 결국 내부에 들어가 원인을 디버깅해야 하는 상황이 생긴다고 설명했다.
   3. E2B의 목표: E2B는 사용자가 이런 문제를 덜 겪도록 만드는 것을 목표로 하지만 모든 예외를 없앨 수는 없다.

8.2. 여러 GPU로 분산하는 사용 사례

1. 질문 내용

   1. 로컬 코드와 원격 GPU: 한 참가자는 노트북의 바닐라 프로덕션 코드를 여러 클라우드 제공자의 작은 GPU에 분산해 실행하고 결과 데이터를 로컬로 되돌리고 싶다고 설명했다.
   2. 워크로드 흐름: 로컬 코드가 여러 네트워크의 GPU 프로세스로 작업을 보내고 결과를 다시 수집하는 구조였다.

2. E2B의 답변

   1. 현재 한계: E2B는 당시 GPU를 지원하지 않으므로 해당 요구를 직접 해결하지 못한다.
   2. 일반적인 패턴: VM이나 컨테이너에서 작업을 실행하고 결과를 POST 요청으로 외부에 보내는 방식이 흔한 구현이다.
   3. 병목: 작업 크기에 따라 네트워크·스토리지·처리 속도 등 다른 병목과 문제가 나타난다.
   4. 사용자의 이유: 참가자는 어디에서든 원하는 비용으로 GPU를 얻을 수 있기 때문에 이 구조를 원한다고 답했다.
   5. 답변의 한계 인정: Matt는 그 GPU 활용 사례의 세부 내용을 충분히 알지 못해 확정적인 답변을 주기 어렵다고 인정했다.

8.3. Kubernetes, 스토리지와 볼륨

1. 오래된 샌드박스의 저장 문제

   1. 핵심 질문: 샌드박스를 많이 만들었을 때 시간이 지나며 생성된 리소스를 어떻게 가지치기(prune)하고 어디에 저장할지 질문이 나왔다.
   2. 진행 중인 과제: 샌드박스를 많이 생성한 뒤 저장 공간을 관리하는 일은 E2B가 현재 풀고 있는 적극적인 과제다.
   3. 기술 과제: 속도와 성능을 유지하면서 스토리지를 압축하고 최적화하는 방법이 중요하다.
   4. 채용 연결: 이 문제는 E2B Go 백엔드 팀이 풀고 있는 재미있는 문제이며 Go 엔지니어 채용과도 연결됐다.

2. 볼륨과 오케스트레이션

   1. 공유 볼륨: 여러 샌드박스가 공유 자원을 사용해야 할 때 볼륨이 적합하다.
   2. Kubernetes: E2B는 Firecracker 기반이며 Kubernetes에서 해결해야 할 기술적 문제가 남아 있어 당시에는 Nomad를 사용하고 Kubernetes 도입을 진행 중이었다.
   3. 초기 생태계: 샌드박스 운영 방식은 아직 이르고 표준적인 정답이 정해지지 않았으므로 새로운 저장·압축·오케스트레이션 해법이 나올 여지가 크다.

8.4. 클라우드 에이전트, 중첩 샌드박스와 API 키

1. 에이전트 실행

   1. 지원 도구: Claude Code와 OpenCode, Codex를 샌드박스 안에서 실행할 수 있다.
   2. 실행 위치: 에이전트는 원격 또는 로컬에서 실행되고 샌드박스와 통신하면서 코드를 실행할 수 있다.
   3. 중첩 구조: 샌드박스 하나가 템플릿으로부터 다른 샌드박스를 생성하는 “샌드박스 안의 샌드박스” 구조도 가능하다.

2. 워크숍에서 자동화를 제한한 이유

   1. 수동 코디네이터: 참가자가 버튼을 눌러 템플릿에서 새 샌드박스를 만들었고, 이번 실습에서는 Matt가 코디네이터 역할을 했다.
   2. API 키 문제: 자동화를 사용하려면 모든 참가자가 API 키를 가져야 했고, 녹화 화면에 자신의 API 키를 노출할 위험이 있었다.
   3. 보안 판단: Matt는 녹화 중 자신의 키를 화면에 보여 주는 실수를 믿고 맡길 수 없어서 자동화를 생략했다.

8.5. 샌드박스 생태계와 Docker 비교

1. 생태계 전망
   1. 질문: 샌드박스가 Docker처럼 널리 퍼지고 표준화된 생태계를 만들지 질문이 나왔다.
   2. 현재 시점: AI 에이전트는 약 2년, LLM-as-a-Service는 약 5년 정도 된 초기 기술이라 최종 생태계를 아무도 알 수 없다.
   3. 표준화 과정: 사람들이 유용한 도구를 만들고 사용법을 공유하면 커뮤니티가 그 방식으로 표준화되는 경향이 있다.
   4. 템플릿의 역할: 워크숍에서 하나의 템플릿을 약 200명이 재사용한 것처럼 템플릿이 공통 실행 단위가 될 수 있다.
   5. 결론: 샌드박스는 Docker와 비슷한 방향으로 발전할 수 있지만 시간이 지나야 생태계의 형태를 알 수 있다.

8.6. 로컬 개발과 네트워크 보안

1. 로컬과 클라우드의 선택

   1. E2B 내부 관행: E2B도 테스트와 개발에서는 클라우드 실행이 번거롭기 때문에 로컬 환경을 많이 사용한다.
   2. 샌드박스의 장점: 에이전트가 접근할 시크릿과 파일을 제한해야 할 때 샌드박스는 격리된 실행 경계를 제공한다.

2. 네트워크 정책

   1. 정책 설정: E2B 샌드박스에는 네트워크에 적용할 수 있는 규칙이 있다.
   2. 시크릿 보호: 시크릿을 샌드박스에 넣는다면 에이전트가 외부로 전송할 수 있는 범위를 반드시 제한해야 한다.
   3. 개발 키의 위험: 시크릿 대신 개발용 키만 제공하면 피해가 줄어들 수 있지만, 네트워크 정책을 생략해도 된다는 뜻은 아니다.
   4. 핵심 트레이드오프: 사용 편의성과 보안 사이에서 어떤 권한과 네트워크 접근을 허용할지 결정해야 한다.

주요 발언 모음

“Everything is basically sandboxes all the way down.”
“E2B aims to spin up sandboxes in less than 100 milliseconds.”
“Don’t just let it code for you. You should always review what the AI does.”
“Do what I say, not what I do.”
“A lot of sandbox management ends up being killing orphans.”
“If a sandbox is running, things are fast; if it’s paused, it’s cheap.”
“Nobody knows where the ecosystem is going to go.”

핵심 데이터 & 수치

• 100밀리초 이하: E2B가 목표로 하는 샌드박스 기동 시간이다.
• 약 200개: 워크숍에서 하나의 템플릿으로부터 만들어 재사용한 참가자용 샌드박스 수다.
• 99.7% CPU: CPU runaway 레벨에서 문제 프로세스가 사용한 CPU 비율이다.
• 512MB: 디스크 고갈 레벨에서 /tmp/selfone_diskfill.bin이 차지한 디스크 공간이다.
• 1시간: 장시간 실행 작업에 설정한 command timeout이다.
• 1분: 작업 완료 후 샌드박스를 유지하는 짧은 lifetime이다.
• 10~15분: 데이터 과학이나 웹 스크래핑 같은 사용자 작업이 걸릴 수 있다고 제시한 예시 시간이다.
• 약 10분: 짧은 작업 후 사용자가 다시 돌아올 수 있다고 가정한 재방문 간격이다.
• 3개 → 2개 → 0개: 고아 프로세스 정리 전후의 개수 변화다.
• PID 1250: CPU를 과도하게 사용한 프로세스를 종료할 때 사용한 예시 PID다.
• PID 448, 449, 450: 고아 프로세스를 순서대로 종료할 때 사용한 예시 PID다.
• 약 8개: 파일 시스템 권한 레벨 뒤에 남았지만 시간 관계로 함께 진행하지 않은 레벨 수다.
• 약 2년 / 약 5년: AI 에이전트와 LLM-as-a-Service가 각각 등장한 지 지난 시간에 대한 현장 추정치다.

결론 및 시사점

1. 에이전트 실행 경계: AI 에이전트가 로컬 CPU·파일·환경 변수·시크릿을 마음대로 건드리지 않게 하려면 최소 권한의 샌드박스와 네트워크 정책이 필요하다.
2. 복원 가능한 상태: 메모리와 파일 시스템을 함께 스냅샷하면 에이전트가 떠난 뒤에도 동일한 실행 상태를 빠르게 복원할 수 있다.
3. 자원 관찰: CPU·RAM·디스크의 사용량을 지속적으로 관찰하고 runaway 프로세스와 큰 파일을 자동으로 찾아야 한다.
4. 누수 정리: 재사용 가능한 상태는 성능을 높이지만 이전 프로세스와 관리되지 않는 샌드박스도 보존하므로 고아 탐색·종료와 소유권 추적을 운영 기본값으로 삼아야 한다.
5. 수명 정책: 작업이 끝날 때까지는 긴 command timeout을 주고, 완료 후에는 짧은 lifetime을 적용해 응답성과 비용을 균형 잡아야 한다.
6. 사용자 매핑: 라운드 로빈보다 user_id → sandbox_id 매핑을 보존해야 사용자가 같은 워크스페이스에서 코드를 이어서 실행할 수 있다.
7. 권한 분리: 템플릿 캐시와 런타임 캐시를 분리하고 에이전트의 읽기·쓰기 경로를 제한하면 예기치 않은 파일 변경을 줄일 수 있다.
8. 확장성의 비용: 수백~수천 개로 확장하면 단일 샌드박스의 CPU 문제는 전체 플릿의 쿼터·로그·네트워크·스토리지·오케스트레이션 문제로 바뀐다.
9. 적합성 판단: GPU 분산 처리나 장시간 데몬처럼 샌드박스가 맞지 않는 사용 사례에는 전통적 서버·컨테이너·GPU 오케스트레이션·공유 볼륨을 함께 검토해야 한다.
10. 생태계의 현재 상태: 샌드박스 표준은 아직 형성 중이며 템플릿·볼륨·오픈 소스 구현·커뮤니티 공유가 Docker와 같은 생태계로 이어질지는 실제 사용 사례와 시간이 결정한다.