퍼플렉시티 SPACE란? AI 에이전트 코드를 격리하는 오픈소스 샌드박스

SPACE(Sandboxed Platform for Agentic Code Execution)는 AI 에이전트 코드를 격리된 Firecracker 마이크로VM에서 실행하는 퍼플렉시티의 오픈소스 플랫폼이다 ^[1]. 애플리케이션은 HTTP API로 Linux 샌드박스를 만들고, 명령을 실행하고, 출력을 받고, 샌드박스의 수명 주기를 관리한다. 코드는 Apache License 2.0으로 공개됐다 ^[1]. 네트워크와 자격 증명은 게스트 안이 아니라 호스트 쪽 워커 서비스가 처리한다 ^[2].

SPACE는 무엇인가?

SPACE는 에이전트에게 쓰고 버릴 수 있는 Linux 머신을 내주는 서비스이고, 직접 호스팅할 수 있다 ^[1]. 애플리케이션은 HTTP API를 호출해 샌드박스를 만들고, 명령을 실행하고, 그 출력을 서버 전송 이벤트(server-sent events)로 받고, 일이 끝나면 샌드박스를 지운다. README는 역할 분담을 분명히 적는다. 무엇을 실행하고 어떤 결과를 남길지는 애플리케이션이 정하고, 샌드박스와 그 안의 프로세스, 명령 출력을 실어 나르는 연결은 SPACE가 관리한다.

코드는 Rust로 썼고, 설치와 클러스터 진단에는 Bash를 쓴다. 공개된 API 레퍼런스는 0.8.0 버전 기준이다 ^[1][6]. 저장소에는 가이드도 여럿 들어 있다. 운영자용 송신 프로필, 부팅을 마친 샌드박스를 미리 준비해 두어 생성 때 콜드 부팅을 건너뛰게 하는 웜 풀, 베이스 스냅숏, 관측성, 네이티브 API 보안 강화를 다룬다 ^[1].

SPACE는 이미 퍼플렉시티 자체 문서 밖에서도 쓰인다. CoreWeave는 자사 쿠버네티스 서비스인 CKS의 CPU 노드에 SPACE를 배포하는 가이드를 냈고, 이 배포는 평가 용도로만 쓰라고 밝힌다 ^[8].

SPACE는 어떻게 동작하나?

SPACE는 무엇을 실행할지 정하는 부분과 신뢰할 수 없는 코드를 실제로 실행하는 부분을 나눈다. API는 요청을 인증하고 원하는 상태를 PostgreSQL에 기록한다. 그러면 컨트롤러와 워커 서비스가 실제 시스템을 그 상태에 맞춘다 ^[2]. 워커 서비스는 VM, 네트워크, 볼륨, 템플릿, 자격 증명을 관리한다. 클라이언트와 게스트 안 프로세스 사이의 연결은 별도의 데이터 플레인이 맡는다.

아키텍처 가이드는 API에서 만나게 될 개념 5가지를 정의한다 ^[2].

두 플레인은 토큰 종류로도 갈린다. 관리 요청에는 사용자 세션 토큰이나 서비스 베어러 토큰을 쓰고, 명령 연결에는 세션 범위의 연결 토큰을 쓴다. 두 토큰은 서로 바꿔 쓸 수 없다 ^[2]. SPACE는 로컬 가이드가 쓰는 쿠버네티스 어댑터로 돌릴 수도 있고, 쿠버네티스 파드를 만들지 않고 워커 서비스를 바로 호출하는 직접 어댑터로 돌릴 수도 있다.

일시 정지, 중단, 재개

SPACE는 수명 주기 상태 4가지로 긴 에이전트 세션을 유지한다 ^[2]. 일시 정지(pause)한 샌드박스는 실행을 멈추지만 메모리와 파일 시스템은 워커에 그대로 남는다. 이 상태는 영속적인 스냅숏이 아니다. 중단(suspend)한 샌드박스는 메모리, 런타임 상태, 루트 파일 시스템을 스냅숏으로 저장하고 VM 자원을 반납한다. 재개(wake)하면 두 상태 모두 다시 실행 상태로 돌아간다.

API로 만든 샌드박스는 기본값으로 접근이나 명령 활동이 6시간 동안 없으면 중단된다. 가이드는 이 값이 최대 수명은 아니라고 덧붙인다 ^[2]. SPACE의 스토리지는 루트 파일 시스템에 btrfs의 기록 시 복사(copy-on-write)를 쓰고, 템플릿과 스냅숏은 오브젝트 스토리지에 둔다.

SPACE는 샌드박스가 닿을 수 있는 곳을 어떻게 통제하나?

SPACE는 에이전트 코드 둘레에 경계를 두 겹 친다. Firecracker가 게스트 실행을 격리하고, 밖으로 나가는 트래픽은 호스트 쪽 정책을 거친다 ^[2]. 아키텍처 가이드는 호스트 쪽이 특권을 쥐고 있다는 점도 숨기지 않는다. 호스트 서비스가 VM, 스토리지, 네트워크를 관리하려면 여전히 특권이 필요하다.

운영자는 송신 프로필(egress profile)로 네트워크 접근 범위를 정한다. SPACE_EGRESS_PROFILES에 이름 붙은 정책을 설정하고, 정책은 서로 더해진다. 허용 목록과 예외 목록에는 IP 주소, CIDR 대역, 정확한 도메인 이름을 쓸 수 있다 ^[7]. 프로필을 조합하면 허용과 예외가 중복 없이 합쳐진다. 그래도 테넌트의 명시적 거부와 플랫폼 거부는 어떤 허용보다 우선한다. 기본 거부 정책에는 E2B 래퍼가 쓰는 DNS 리졸버 허용도 함께 들어간다.

TLS 가로채기 예외는 두 번 읽어 둘 대목이다. 예외만으로는 송신 권한이 생기지 않는다. 일반적인 목적지 허가를 통과한 뒤, 게이트웨이는 일치하는 SNI 호스트 이름이나 목적지 IP의 트래픽을 TLS를 풀지 않고 그대로 넘긴다. 이 트래픽은 HTTP 검사와 자격 증명 주입을 건너뛴다는 뜻이다 ^[2]. 운영자가 비어 있지 않은 예외 목록을 설정하려면, 정책을 읽는 모든 구성 요소와 실행 중인 모든 게이트웨이가 예외를 지원해야 한다 ^[7].

기본값이 중요하다. SPACE_EGRESS_PROFILES가 비어 있거나 {}이면 프로필이 꺼진다. 이때 연합(federated)이 아닌 생성 요청은 프로필 헤더를 무시하고, 기본 프로필을 포함해 어떤 프로필도 적용하지 않는다 ^[7]. 로컬 Kind 환경에서는 샌드박스 파드의 NetworkPolicy가 송신을 공용 IPv4 인터넷과 클러스터 DNS로만 제한한다 ^[2]. 대략적인 제한일 뿐, 목적지별 허용 목록은 아니다.

AI 에이전트를 쓰는 팀에는 무엇이 달라지나?

팀 입장에서 SPACE는 실무 질문 하나에 답한다. 에이전트가 실제 데이터와 실제 서비스를 다룰 때 그 코드를 어디서 돌려야 하는가. 코드를 쓰고 실행하거나, 패키지를 설치하거나, 웹을 탐색하는 에이전트에게는 망가뜨려도 되는 머신이 필요하다. SPACE는 에이전트마다 쓰기 가능한 자체 파일 시스템을 갖춘 마이크로VM을 준다 ^[2]. 일시 정지와 중단은 사람의 검토 과정과 그대로 맞물린다. 에이전트는 체크포인트에서 멈추고, 사람이 다음 단계를 승인할 때까지 기다렸다가, 상태를 고스란히 지닌 채 재개할 수 있다. Hardi AI처럼 공유 채널에서 에이전트와 사람을 한 워크스페이스에 모아 일하는 팀이라면, 이 체크포인트를 사람이 최종 승인하는 지점으로 쓸 수 있다.

자체 KVM 호스트부터 마련하고 싶지 않은 팀은 CoreWeave의 가이드를 따르면 된다. Cilium을 네트워크 플러그인으로 쓰는 CKS 클러스터가 필요하고, 워커 노드는 /dev/kvm을 노출하는 amd64 베어메탈 CPU 인스턴스여야 한다 ^[8].

SPACE를 로컬에서 시험하려면?

KVM이 있는 apt 기반 Linux x86_64 호스트가 필요하다 ^[3]. 가이드는 이 밖에도 /dev/kvm과 /dev/net/tun, 루프 장치를 쓰는 btrfs 지원, 특권 컨테이너를 허용하는 Docker 데몬을 요구한다. 설치 절차는 macOS에서 바로 동작하지 않고, Kind로 띄우는 쿠버네티스 기반 로컬 환경만 다룬다.

1. 저장소를 클론하고 설치 가이드의 호스트 점검 블록을 실행한다 ^[3].
2. 사전 요구 사항 설치 스크립트를 실행한다. Kind, kubectl, Helm, grpcurl, Tilt, Go, jq가 설치된다.
3. 셸에 설정된 AWS와 Datadog 자격 증명을 해제한다. 부트스트랩이 이 값을 클러스터 시크릿으로 복사하기 때문이다. 콘솔 비밀번호도 문서의 기본값을 그대로 두지 말고 SPACE_CONSOLE_PASSWORD로 직접 정한다.
4. 벤더 설치 스크립트와 부트스트랩 스크립트를 실행하고, API가 127.0.0.1:8080에서 응답할 때까지 기다린다.
5. 저장소 루트에서 첫 샌드박스 예제를 실행한다 ^[5].

python3 examples/first_sandbox.py

예제는 seed:latest로 샌드박스를 만들고, 오퍼레이션이 성공하고 샌드박스가 running 상태가 될 때까지 기다린다. 그다음 명령 세션을 만들고 이벤트 스트림에 붙는다 ^[5]. 실행하는 명령은 JSON 모양의 평범한 객체다.

COMMAND = {
    "command": ["sh", "-c", "printf '%s\\n' \"$GREETING\"; pwd"],
    "cwd": "/tmp",
    "env": {"GREETING": "Hello from Python"},
    "timeout": "30s",
}

수명 주기 변경은 POST /v1/sandboxes/{id}:pause, :suspend, :wake 같은 경로로 보내고, 수명 주기를 바꾸는 요청마다 Idempotency-Key가 필요하다 ^[5]. 요청이 수락됐다는 응답은 결과가 아니라 약속으로 봐야 한다. 아키텍처 가이드도 "수락된 요청은 준비가 끝났다는 신호가 아니다"라고 적는다 ^[2].

E2B에서 옮겨 오기

에이전트가 이미 E2B를 쓰고 있다면, E2B 호환 래퍼(E2B Compatibility Wrapper)가 E2B 요청을 SPACE 오퍼레이션으로 바꿔 준다 ^[4]. 래퍼는 Python 패키지 e2b==2.21.1과 e2b-code-interpreter==2.6.2로 시험했다. 생성, 목록, 조회, 삭제, 연결, 타임아웃, 갱신, 일시 정지, 재개, 포크를 지원한다. E2B의 pause는 SPACE의 suspend에, E2B의 resume은 SPACE의 restore에 대응한다.

한계와 남은 질문은?

래퍼가 모든 기능을 다루지는 않는다. mcp, volumeMounts, iam 기능을 요청하는 생성 요청은 400을 돌려받고, JSON 파일 쓰기는 1 MiB로 제한된다 ^[4]. 다른 SDK 버전이나 JavaScript SDK도 동작할 수는 있지만, 저장소의 호환성 테스트는 이들을 다루지 않는다.

데이터 보존에도 빈틈이 있다. 파일은 쓸 때마다 저장되지 않고 수명 주기가 바뀌는 시점에 저장된다. 그래서 쓰기가 확인된 데이터도 크래시, 강제 종료, 호스트 장애가 나면 사라질 수 있다 ^[2]. 스키마에서 incubating으로 표시된 필드는 지원 범위 밖이다 ^[1].

공개 문서는 경계를 어떻게 만들었는지 설명할 뿐, 공격을 받았을 때 그 경계가 얼마나 버티는지는 말하지 않는다. 성능 벤치마크도 내놓지 않았다. 신뢰할 수 없는 에이전트 코드를 SPACE에서 돌릴 계획이라면, VM 격리와 네트워크 송신 제한을 자체 호스트에서 먼저 시험한 뒤에 기대는 편이 안전하다.