E2B 샌드박스 실행이란 무엇이며, 왜 당신의 AI 에이전트가 필요할까요?

E2B 샌드박스 실행이란?

AI 에이전트가 코드를 생성하고 실행할 때, 그 코드는 어딘가에서 실행되어야 합니다. 질문은 어디에서 — 그리고 어떤 수준의 접근 권한으로 실행할 것인가입니다.

E2B(“Environment to Binary"의 약자)는 AI 생성 코드를 클라우드 샌드박스에서 실행하기 위한 오픈 소스 인프라입니다. 로컬 머신에서 사용자 권한, 파일 및 네트워크 접근 권한으로 코드를 실행하는 대신, E2B는 격리된 클라우드 컨테이너를 생성합니다. 코드는 그 컨테이너 안에서 실행됩니다. 작업이 끝나면 컨테이너는 파괴됩니다.

이 개념은 간단합니다: 모든 코드 실행을 신뢰할 수 없는 것으로 간주합니다. 일회용 환경을 제공합니다. 작업을 수행하게 합니다. 결과를 가져옵니다. 환경을 버립니다.

이것은 클라우드 CI/CD 시스템이 작동하는 원리와 동일합니다. GitHub Actions는 빌드 스크립트를 서로 다른 프로젝트의 비밀을 읽을 수 있는 공유 서버에서 실행하지 않습니다. 각 실행은 새 컨테이너에서 시작됩니다. E2B는 AI 에이전트 코드 실행에 동일한 모델을 적용합니다.

컨테이너 생애 주기 작동 방식

E2B 샌드박스의 생애 주기는 예측 가능한 패턴을 따릅니다.

AI 에이전트가 코드를 실행해야 할 때, 플랫폼은 E2B에 새 컨테이너를 요청합니다. 이 컨테이너는 가벼운 리눅스 환경입니다 — 1초 이내에 부팅되는 최소한의 가상 머신이라고 생각하면 됩니다. 자체 파일 시스템, 프로세스 트리, 네트워크 네임스페이스를 가지고 있습니다.

컨테이너는 필요한 것만 받습니다: 실행할 코드, 작업과 관련된 작업 공간 파일, 실행 요청에서 지정한 모든 종속성. SSH 키는 받지 않습니다. .env 파일도 받지 않습니다. 로컬 네트워크에 대한 접근 권한도 받지 않습니다.

코드가 실행됩니다. 출력 파일이 생성되면, 해당 파일은 추출되어 지속적인 작업 공간에 저장됩니다. 만약 충돌이 발생하면, 컨테이너 안에서 충돌이 발생하며 — 시스템에는 영향을 미치지 않습니다. 데이터베이스에 접근하기 위해 localhost:5432에 네트워크 요청을 시도하면, 그 요청은 아무데도 가지 않습니다.

실행이 완료되거나 타임아웃이 만료되면, 컨테이너는 종료되고 파일 시스템이 지워집니다. 잔여 상태는 없습니다. 다음 작업은 이전 실행의 잔여 아티팩트가 없는 새 컨테이너에서 시작됩니다.

왜 이것이 중요한가: 대안은 생각보다 나쁩니다

샌드박스 실행이 중요한 이유를 이해하려면, 그것이 없을 때 어떤 일이 발생하는지 살펴보세요.

OpenClaw — 10주 만에 150,000 GitHub 스타를 기록한 오픈 소스 AI 에이전트 프레임워크 — 는 AI 생성 코드를 직접 당신의 머신에서 실행합니다. AI 에이전트는 전체 셸 접근 권한을 가지고 있습니다. 사용자의 계정이 접근할 수 있는 모든 파일을 읽고 쓸 수 있습니다. 머신이 접근할 수 있는 모든 서비스에 네트워크 요청을 할 수 있습니다. 패키지를 설치하고, 시스템 구성을 수정하며, 임의의 명령을 실행할 수 있습니다.

그 뒤에 이어진 보안 연구는 그리 긍정적이지 않았습니다. Snyk 연구원들은 ClawHub 마켓플레이스에서 광범위한 보안 문제를 문서화했으며, 여기에는 악성 코드 배포와 프롬프트 주입이 포함됩니다.

마켓플레이스를 넘어, 아키텍처 자체가 문제입니다. 플랫폼은 자격 증명을 평문으로 저장하며, 여러 보안 기관이 아키텍처에 대한 경고를 발표했습니다.

이것은 이론적인 위험이 아닙니다. AI 생성 코드가 샌드박스 없이 실행될 때 발생하는 일입니다.

샌드박스 실행이 가능하게 하는 것

코드 실행이 컨테이너에서 격리되면, 이전에는 너무 위험했던 여러 가지가 가능해집니다.

모든 모델에서 안전한 코드 실행. AI 에이전트가 데이터를 처리하기 위해 Python 스크립트를 작성할 때, 실행하기 전에 모든 줄을 검토할 필요가 없습니다. 스크립트는 샌드박스에서 실행됩니다. 예상치 못한 작업을 수행하더라도, 폭발 반경은 제로입니다. 이는 “이 코드가 안전하길 바란다"와 “이 코드가 안전한지 상관없다, 왜냐하면 중요한 것에 접근할 수 없기 때문이다"의 차이입니다.

누출 위험 없는 데이터 처리. 민감한 데이터를 샌드박스에 전달하여 처리할 수 있습니다 — 재무 기록, 고객 목록, 내부 메트릭 — 데이터가 작업 기간 동안 컨테이너 내부에만 존재한다는 것을 알고 있습니다. 공유 파일 시스템에 기록되지 않습니다. 동일한 플랫폼의 다른 사용자에게 접근할 수 없습니다. 컨테이너가 파괴되면 데이터는 사라집니다.

다중 사용자 격리. 여러 사용자가 있는 플랫폼에서 샌드박스는 한 사용자의 코드 실행이 다른 사용자와 간섭할 수 없음을 의미합니다. 컨테이너 간에 공유 상태가 없습니다. 이는 모든 진지한 클라우드 플랫폼의 기본 조건이지만, 로컬 우선 AI 에이전트 도구에서는 완전히 결여되어 있습니다.

재현 가능한 환경. 모든 실행은 알려진 상태에서 시작됩니다. “내 머신에서는 작동한다"는 문제는 없습니다. 이전 실행에서 누적된 상태로 인해 예상치 못한 동작이 발생하지 않습니다. 작업이 한 번 작동하면, 매번 작동합니다. 왜냐하면 환경이 매번 동일하기 때문입니다.

샌드박스가 전체 AI 에이전트 산업의 방향이라는 이유에 대한 더 깊은 통찰을 원하신다면, 샌드박스 AI 에이전트가 미래인 이유에 대한 게시물을 참조하세요. 샌드박스 실행을 실제로 보고 싶다면, 코드 실행 사용 사례에서 실제 워크플로우를 살펴볼 수 있습니다.

성능: 클라우드 실행은 예상하는 병목이 아닙니다

원격 컨테이너에서 코드를 실행하는 것이 로컬에서 실행하는 것보다 느릴 것이라는 일반적인 가정이 있습니다. 많은 작업 부하에 대해, 그 반대가 사실입니다.

당신의 노트북은 브라우저, 채팅 클라이언트, IDE, 백그라운드 동기화 및 열려 있는 모든 것을 실행하고 있습니다. AI 에이전트가 로컬에서 CPU 집약적인 스크립트를 실행할 때, 모든 리소스를 두고 경쟁하게 됩니다. 클라우드 컨테이너는 전용 리소스를 받습니다. Spotify와 CPU를 공유하지 않습니다.

병렬 처리의 이점을 누릴 수 있는 작업에 대해 — 여러 파일 처리, 배치 작업 실행, 테스트 스위트 실행 — 클라우드 컨테이너는 병렬로 생성될 수 있습니다. 다섯 개의 컨테이너가 동시에 다섯 개의 데이터 세트를 처리하면, 하나의 노트북이 순차적으로 처리하는 것보다 더 빨리 완료됩니다.

종속성 설치는 또 다른 장점입니다. 로컬 설정은 Python 패키지, Node 모듈 또는 시스템 라이브러리를 머신에 설치해야 합니다. 클라우드 컨테이너는 이미 일반 종속성이 설치된 미리 빌드된 이미지를 사용할 수 있습니다. pip install 대기 시간도 없습니다. 기존 환경과의 버전 충돌도 없습니다.

작업을 클라우드로 보내고 결과를 다시 받는 지연 오버헤드는 실제로 존재하지만, 일반적으로 밀리초에서 몇 초로 측정됩니다 — 대부분의 의미 있는 작업의 실행 시간에 비해 무시할 수 있는 수준입니다.

한계: 샌드박스 실행이 할 수 없는 것

경계를 솔직하게 인식하는 것이 능력을 과장하는 것보다 더 중요합니다.

시스템 수준 접근. 작업이 시스템 구성을 수정하거나, 로컬 하드웨어(USB 장치, 프린터, 머신에 연결된 GPU)와 상호작용하거나, 로컬 파일 시스템에만 존재하고 업로드할 수 없는 파일을 읽어야 하는 경우, 클라우드 샌드박스는 도움이 되지 않습니다. 이러한 작업은 정의상 로컬 실행이 필요합니다.

극도로 낮은 지연 시간 상호작용. 서브 밀리초 응답 시간이 필요하거나 로컬 애플리케이션의 이벤트 루프와 긴밀하게 통합된 작업의 경우, 클라우드 컨테이너로의 네트워크 왕복이 허용할 수 없는 지연을 추가합니다. 이는 실시간 오디오 처리, 게임 엔진 스크립팅, 하드웨어 제어 루프 등 좁은 범위의 사용 사례에 적용되지만, 실제 제약입니다.

지속적인 시스템 변경. 머신에 소프트웨어를 설치하거나, 셸 구성을 수정하거나, 로컬 개발 환경을 변경하는 것이 목표라면, 실행 후 파괴되는 샌드박스는 잘못된 도구입니다. 샌드박스는 출력을 생성하도록 설계되었지, 호스트를 수정하도록 설계되지 않았습니다.

대부분의 AI 에이전트 작업 — 코드 실행, 데이터 처리, 파일 생성, API 상호작용, 배치 작업, 분석 — 에 대해 샌드박스 실행은 단순히 충분한 것이 아닙니다. 더 나은 것입니다. 위험 없이 동일한 코드 실행 기능을 얻을 수 있습니다.

LikeClaw가 E2B를 사용하는 방법

LikeClaw는 모든 코드 실행 작업을 E2B 샌드박스에서 실행합니다. 이는 선택적 보안 설정이 아닙니다. 그것이 아키텍처입니다.

AI 에이전트가 코드를 실행해야 할 때, 컨테이너가 생성됩니다. 작업 공간 파일은 작업에 쓰기 접근이 필요하지 않는 한 읽기 전용으로 마운트됩니다. API 키는 암호화되어 저장되며 런타임에 환경 변수로 주입됩니다 — 컨테이너 내부의 디스크에 기록되지 않으며, 평문으로 저장되지 않습니다. 코드가 실행됩니다. 결과가 돌아옵니다. 컨테이너는 파괴됩니다.

이것이 자율 AI 에이전트의 힘을 얻는 방법입니다 — 실제 코드 실행, 실제 파일 처리, 실제 자동화 — Kaspersky, Cisco 및 Snyk가 경고를 발행하게 만든 보안 모델 없이 말입니다.

샌드박스 실행은 기능이 아닙니다. 그것이 기반입니다.