Perplexity SPACE Sandbox 오픈 소스화, 그러나 프로덕션 규모가 여전히 시험대

Perplexity는 신뢰할 수 있는 에이전트 인프라가 여전히 까다로운 프로덕션 작업에 의존한다고 주장하면서도 SPACE sandbox를 오픈 소스로 공개했다. Perplexity SPACE sandbox는 Perplexity Computer가 주변 시스템을 노출하지 않고 코드를 실행할 수 있도록 격리된 컴퓨터를 제공한다. 이 때문에 이번 공개는 단순한 소스 코드 배포보다 더 중요한 의미를 갖는다.

CEO Aravind Srinivas는 2026년 10월 19일 이번 공개를 발표하며 샌드박스 자체는 범용화된 기술이라고 설명했다. 하지만 그의 출시 게시물은 샌드박스를 만드는 일과 수백만 개를 운영하는 일은 다르다는 점도 분명히 했다. Perplexity는 SPACE가 Computer에서 사용되는 샌드박스 기능을 지원한다고 밝혔지만, 이러한 규모에 대한 주장은 독립적으로 검증되지 않았다.

따라서 쟁점은 오픈 소스와 클로즈드 소스의 대립이 아니다. 운영 경험을 기반으로 한 관리형 실행 환경과 자체 호스팅 인프라의 대결이다. E2B 및 다른 샌드박스 제공업체들은 신뢰할 만한 공개 대안을 마주하게 됐고, Perplexity는 코드 공개가 실질적인 프로덕션 지식까지 이전한다는 점을 입증해야 한다.

Perplexity SPACE Sandbox, 실행 계층 공개

Perplexity는 에이전트에 격리된 작업 공간을 제공하는 장치를 공개했을 뿐, 완전한 Perplexity Computer 제품을 공개한 것은 아니다.

SPACE는 Sandboxed Platform for Agentic Code Execution의 약자다. 공개된 SPACE repository는 격리된 Firecracker microVM 내부에서 에이전트 또는 사용자 코드를 실행하기 위한 플랫폼을 설명한다.

microVM은 기존 서버 VM보다 적은 오버헤드로 시작하도록 설계된 소형 가상 머신이다. 각 워크로드에 자체 커널 경계를 제공하므로, 일반적으로 커널을 공유하는 표준 컨테이너보다 더 강력한 격리를 제공한다.

애플리케이션은 HTTP API를 통해 SPACE와 통신한다. Linux 환경을 생성하고, 명령을 시작하며, 출력을 수신하고, 환경을 유지하거나 일시 중단하고, 다시 깨우거나 삭제할 수 있다.

이러한 수명 주기가 중요한 이유는 에이전트가 단일 명령을 실행한 뒤 사라지는 경우가 드물기 때문이다. 리서치 또는 코딩 워크플로는 패키지를 설치하고, 파일을 만들고, 프로그램을 실행하고, 오류를 확인한 뒤 다시 시도할 수 있다.

SPACE는 이렇게 연결된 작업을 하나의 쓰기 가능한 환경 안에 유지한다. 애플리케이션은 에이전트가 시도할 작업을 제어하고, 플랫폼은 머신, 프로세스, 출력 연결을 관리한다.

이 프로젝트는 주로 Rust로 작성됐지만, 클라이언트가 Rust 라이브러리를 내장할 필요는 없다. HTTP를 통해 상호작용하고, 표준 단방향 스트리밍 방식인 server-sent events를 통해 실시간 명령 출력을 받는다.

Perplexity는 Apache License 2.0으로 repository를 공개했다. 이는 라이선스 조건을 준수하는 한 상업적 사용, 수정, 재배포를 허용한다.

repository는 단순한 데모 래퍼보다 훨씬 실질적이다. 서비스 구성 요소, API 정의, Firecracker 템플릿, 스모크 테스트, 로컬 Kubernetes 구성, AWS 참조 배포가 포함돼 있다.

공개 문서는 warm pool, snapshot, 수명 주기 복구, 관측 가능성, 아웃바운드 네트워크 정책, 호환성 동작도 다룬다. 이는 팀이 기본적인 코드 실행기를 넘어선 이후 마주하는 운영상의 문제들이다.

검토 시점에 이 프로젝트는 약 1,600개의 GitHub star와 132개의 fork를 얻었다. 이 수치는 초기 개발자 관심을 보여주지만, 프로덕션 도입이나 보안 품질을 증명하지는 않는다.

Perplexity Computer는 별도의 상위 수준 제품으로 남아 있다. 회사는 Computer를 도구 전반에서 리서치, 분석, 제작, 코딩, 장기 워크플로 조정을 수행할 수 있는 오케스트레이터로 설명한다.

공식 Computer 개요에 따르면 이 제품은 20개 이상의 모델에 작업을 라우팅한다. SPACE는 계획, 모델 라우팅, 커넥터, 사용자 인터페이스가 아니라 해당 워크플로 일부의 하단에 있는 실행 환경을 담당한다.

이 구분은 흔히 발생할 수 있는 오해를 막는다. SPACE를 설치한다고 해서 Perplexity Computer가 재현되는 것은 아니다. 개발자가 자체 코드 실행 에이전트와 작업 공간을 구축할 수 있는 인프라 계층을 제공할 뿐이다.

이번 공개는 인프라 코드가 운영 플랫폼의 일부에 불과하다는 점에서 이 글의 핵심 긴장을 만든다. 배포 규율, 용량 계획, 인시던트 대응, 보안 검토, 지원은 Git clone 밖에 남아 있다.

Perplexity가 지금 SPACE를 공개하는 이유

이번 공개는 에이전트 플랫폼들이 아직 인프라를 선택하는 단계에서 Perplexity의 내부 실행 아키텍처를 공개 표준 수립 노력으로 전환한다.

AI 에이전트는 점점 단순히 텍스트를 반환하는 수준을 넘어야 한다. 프로그램을 생성하고, 파일을 변환하고, 소프트웨어를 테스트하며, 데이터세트를 분석하고, 실제 운영 환경이 필요한 결과물을 만든다.

이 작업을 애플리케이션 서버에서 수행하면 명백한 위험이 발생한다. 모델이 생성한 명령은 파일을 삭제하고, 리소스를 소비하며, 비밀 정보를 살피거나, 의도하지 않은 네트워크 요청을 보낼 수 있다.

일회용 샌드박스는 에이전트의 실행 환경을 주변 서비스와 분리한다. 작업이 실패하면 운영자는 메인 애플리케이션을 다시 구축하지 않고도 해당 환경을 폐기할 수 있다.

이 기본 개념은 새롭지 않다. 달라진 점은 에이전트 작업의 빈도와 다양성이다. 프로덕션 서비스는 다수의 격리 환경을 생성하고, 출력을 스트리밍하며, 장애를 복구하고, 제한을 적용하고, 지속적으로 용량을 회수해야 할 수 있다.

Srinivas는 이 차이를 직접적으로 설명했다. 그의 발표는 샌드박스를 범용 기술로 규정하는 한편, 프로덕션 트래픽에서 이를 제공하려면 수많은 작은 세부 사항에 걸친 세심한 작업이 필요하다고 주장했다.

이 주장은 SPACE를 동시에 두 방향으로 위치시킨다. Perplexity는 인프라를 직접 소유하기 위한 진입 장벽을 낮추면서, 자사 운영 이력을 설계를 신뢰할 이유로 제시하고 있다.

오픈 소스화는 Perplexity가 개발자들이 에이전트를 컴퓨팅 자원에 연결하는 방식에 영향력을 행사하게도 한다. 많은 사용자가 자체 호스팅보다 관리형 호스팅을 선택하더라도 널리 채택된 API는 중요할 수 있다.

SPACE에는 특히 주목할 만한 E2B 호환 구성 요소가 포함돼 있다. 호환성은 이미 확립된 샌드박스 인터페이스를 기반으로 작성된 애플리케이션의 마이그레이션 부담을 줄인다.

이 접근 방식은 전문 제공업체에 압력을 가한다. 개발자는 SPACE를 직접 운영하거나, 프라이빗 인프라에 맞게 수정하거나, 인터페이스를 대체 백엔드로 사용하는 방안을 검토할 수 있다.

압력은 E2B에만 국한되지 않는다. Modal, Cloudflare, Daytona, 일반 클라우드 플랫폼 모두 서로 다른 추상화를 통해 원격 실행 문제의 일부를 다룬다.

일부는 관리형 개발자 경험을 강조한다. 다른 일부는 범용 서버리스 컴퓨팅, 지리적 분산, 영구 작업 공간 또는 배포 유연성을 강조한다.

Perplexity는 다른 자격을 내세워 이 분야에 진입한다. SPACE가 독립형 인프라 서비스로만 존재하는 것이 아니라 소비자 및 기업용 에이전트 제품의 실행 수요를 지원한다고 말한다.

이러한 프로덕션 연계는 SPACE에 즉각적인 가시성을 부여한다. 하지만 개발자들이 공개 프로젝트와 Perplexity의 내부 운영 주장 사이를 비교하게 되므로, 입증 기준도 높아진다.

이번 공개는 에이전트 시스템을 평가하는 기업 구매자에게도 도움이 된다. 아키텍처를 점검하고, 데이터 경로를 검토하며, 아웃바운드 네트워크 제한을 테스트하고, 자체 환경 내 배포를 고려할 수 있다.

점검이 위험을 없애지는 않는다. 제품 설명에 전적으로 의존하는 대신 보안팀이 평가할 수 있는 구체적 구현을 제공한다.

Perplexity 입장에서는 외부 기여자가 결함을 찾아내고, 배포 패턴을 추가하며, 호환성을 넓힐 수 있다. 공개 개발은 SPACE를 독점적 종속성이 아닌 공동 인프라로서 더 신뢰할 만하게 만들 수도 있다.

전략적 승부수는 분명하다. Perplexity는 실행 계층이 개방적이고 교체 가능한 영역이 되기를 바라면서, 오케스트레이션, 모델, 인터페이스, 데이터 접근, 운영 역량에서 제품 차별화를 유지하려 한다.

이 구분이 유지된다면 SPACE 공개는 Computer의 우위를 약화시키지 않을 것이다. 오히려 Perplexity가 이미 사용하는 아키텍처를 중심으로 개발하는 개발자 수를 늘릴 것이다.

그렇지 않다면 경쟁자는 이를 개발하는 비용을 부담하지 않고도 Perplexity 스택의 의미 있는 부분에 접근하게 된다. 따라서 운영 지식이 얼마나 잘 이전되는지가 이번 공개가 레버리지를 만들지, 유출을 초래할지를 결정한다.

Perplexity SPACE가 Computer 아래에서 작동하는 방식

SPACE는 제어 결정을 명령 실행과 분리해, 모든 명령을 새 머신으로 취급하지 않으면서도 에이전트에 지속 가능한 환경을 제공한다.

SPACE 배포는 템플릿에서 시작한다. 템플릿은 샌드박스 인스턴스를 생성하는 초기 환경을 정의한다.

각 샌드박스는 자체 가상 머신과 쓰기 가능한 파일 시스템을 받는다. 이후 여러 명령이 동일한 환경 안에서 실행될 수 있으며, 단계 사이에 파일과 설치된 종속성을 유지한다.

이러한 지속성은 현실적인 에이전트 동작을 지원한다. 에이전트는 프로젝트를 생성하고, 종속성을 설치하고, 테스트를 실행하며, 실패를 검토하고, 파일을 수정한 뒤 다시 테스트를 실행할 수 있다.

애플리케이션은 먼저 제어 API에 샌드박스를 요청한다. 수명 주기 변경은 비동기식이므로, API는 작업이 완료될 때까지 클라이언트가 확인할 수 있는 작업 식별자를 반환한다.

이 패턴은 장시간 인프라 작업이 단일 요청을 차단하지 않도록 한다. 또한 클라이언트가 불완전한 작업을 재시도하거나 점검하는 더 명확한 방식을 제공한다.

명령 실행은 세션 모델을 사용한다. 애플리케이션은 명령 세션을 생성하고, 세션에 연결하며, 프로세스를 시작하고, 출력과 최종 종료 결과를 수신한다.

출력은 세션별 연결 토큰을 사용해 별도의 데이터 플레인 연결로 전달된다. 이러한 분리는 프로세스 출력 클라이언트가 사용할 수 있는 자격 증명을 제한한다.

SPACE는 단순한 생성과 삭제를 넘어 여러 상태를 제공한다. 필요한 준비 상태와 리소스 사용 간의 절충에 따라 샌드박스는 활성 상태를 유지하거나, 일시 정지, 중단, 재개, 종료될 수 있다.

가격이 논의되지 않더라도 이러한 상태는 경제적으로 중요하다. 모든 환경을 완전히 활성 상태로 유지하면 지연 시간은 줄어들지만, 유휴 기간에 더 많은 용량을 소비한다.

모든 환경을 종료하면 리소스는 절약되지만 사용자는 복구를 기다려야 한다. 프로덕션 플랫폼에는 다수의 워크로드에 걸쳐 이 결과들 사이에서 선택하는 정책이 필요하다.

Warm pool은 이 문제의 일부를 해결한다. 부팅된 환경을 준비 상태로 유지해 새 요청이 완전한 콜드 스타트를 피할 수 있도록 한다.

Warm pool은 응답성을 개선하지만 용량 관련 질문을 새로 제기한다. 운영자는 얼마나 많은 환경을 예약할지, 비정상 인스턴스를 어떻게 교체할지, 낭비를 어떻게 방지할지 결정해야 한다.

SPACE는 base snapshot도 문서화한다. snapshot은 작업마다 다시 구축하는 대신 준비된 파일 시스템 상태를 복원할 수 있다.

snapshot은 에이전트가 같은 언어, 라이브러리 또는 프로젝트 설정을 반복적으로 필요로 할 때 유용하다. 또한 신중하게 다뤄야 하는 버전 관리 및 스토리지 관리 책임도 만든다.

격리 계층에서 SPACE는 기본적으로 Firecracker를 사용한다. Amazon Web Services는 서버리스 함수와 컨테이너를 포함한 경량 가상화 워크로드를 위해 Firecracker를 만들었다.

공개된 Firecracker 아키텍처는 하드웨어 지원 격리를 제공하기 위해 Linux의 kernel-based virtual machine 기술을 사용한다. 축소된 디바이스 모델은 시작 오버헤드와 사용 가능한 공격 표면을 제한하는 것을 목표로 한다.

Firecracker를 사용한다고 해서 서비스 전체가 자동으로 안전해지는 것은 아닙니다. 인증, 호스트 구성, 이미지 출처, 네트워크 정책, 커널 업데이트, 리소스 제한, 테넌트 분리는 여전히 올바르게 구현되어야 합니다.

SPACE는 이그레스 프로필을 통한 아웃바운드 네트워크 제어도 지원합니다. 이그레스는 샌드박스에서 나가는 트래픽으로, 예를 들어 명령이 패키지를 다운로드하거나 외부 API에 접속하는 경우를 말합니다.

이는 에이전트에 매우 중요한 정책 영역입니다. 아웃바운드 접근이 제한되지 않은 샌드박스는 가상 머신을 직접 탈출할 수 없더라도 민감한 자료를 외부로 전송할 수 있습니다.

운영자는 필요한 네트워크 활동과 위험한 접근을 구분하는 규칙이 필요합니다. 코딩 에이전트는 패키지 레지스트리에 접근해야 할 수 있지만, 내부 관리 서비스에 접속할 이유는 없습니다.

공개 저장소에는 로컬 컨테이너를 통해 Kubernetes 클러스터를 실행하는 Kind 기반의 로컬 배포 지침이 포함되어 있습니다. 또한 Amazon의 관리형 Kubernetes 서비스용 참조 인프라도 담고 있습니다.

문서에는 SPACE가 Kubernetes 없이도 실행될 수 있다고 명시되어 있습니다. 이러한 유연성은 잠재적 사용자를 넓히지만, 동시에 운영자가 어떤 보장이 SPACE에서 제공되고 어떤 보장이 주변 스케줄러에서 비롯되는지 이해해야 한다는 뜻이기도 합니다.

따라서 Perplexity SPACE 샌드박스는 서로 조율된 인프라 결정들의 집합을 의미합니다. microVM은 그저 하나의 구성 요소일 뿐입니다.

API 계약, 수명 주기 상태 머신, 워밍 용량, 스냅샷, 인증, 명령 스트리밍, 복구 동작이 실제 워크로드에서도 시스템의 사용성을 유지할 수 있는지를 결정합니다.

이 메커니즘은 Srinivas가 이 기본 요소를 범용 상품이라고 부르면서도 운영 작업을 옹호할 수 있는 이유를 설명합니다. 하나의 격리된 VM을 만드는 일은 반복되는 장애와 변동하는 수요 속에서 예측 가능한 동작을 유지하는 일에 비하면 간단합니다.

Perplexity SPACE vs E2B는 결국 셀프 호스팅과 관리형 운영의 대결이다

핵심 경쟁은 어느 프로젝트가 microVM을 부팅할 수 있느냐가 아니라, 에이전트가 이를 사용하기 시작한 뒤 누가 운영 부담을 떠안느냐에 있다.

E2B는 에이전트에 원격 환경을 제공하기 위한 익숙한 인터페이스가 되었습니다. 개발자는 SDK를 사용해 샌드박스를 생성하고, 명령을 실행하고, 파일을 조작하며, 도구 호출 간 상태를 유지합니다.

SPACE는 문서화된 E2B 호환성 레이어를 통해 이러한 설치 기반을 인정합니다. 이 래퍼를 사용하면 지원되는 E2B 클라이언트 동작이 SPACE 배포 환경을 대상으로 작동할 수 있습니다.

이는 실용적인 경쟁 전략입니다. 팀은 에이전트 애플리케이션의 모든 호출을 즉시 다시 작성하지 않고도 SPACE를 평가할 수 있습니다.

호환성이 동일한 동작을 의미하지는 않습니다. 각 제공업체는 수명 주기 의미론, 제한, 네트워킹, 영속성, 오류 처리, 관측성, 지원 SDK 기능에서 차이를 보일 수 있습니다.

개발자는 에이전트가 사용하는 정확한 작업을 테스트해야 합니다. 기본적인 명령 예시는 취소, 네트워크 중단, 동시 세션 또는 호스트 장애 상황에서의 동작을 보여줄 수 없습니다.

Perplexity SPACE와 E2B 사이의 선택은 소유권에서 시작됩니다. 관리형 플랫폼은 제공업체가 용량, 업데이트, 가용성 및 보안 경계의 상당 부분을 운영하게 합니다.

SPACE를 셀프 호스팅하면 도입 기업은 배포, 수정, 데이터 위치, 네트워크 통합에 대한 통제력을 더 많이 확보합니다. 동시에 더 많은 운영 책임도 그 도입 기업으로 이전됩니다.

소규모 개발팀에게 관리형 인프라는 에이전트 출시 전에 필요한 작업을 줄일 수 있습니다. 팀은 API를 통합하고 애플리케이션에 집중할 수 있습니다.

규제를 받는 기업은 승인된 클라우드 계정 내부의 인프라를 선호할 수 있습니다. 기존의 ID, 로깅, 네트워크, 규정 준수 제어를 샌드박스 서비스 주변에 적용할 수 있습니다.

어느 선택도 보편적으로 우위에 있지는 않습니다. 올바른 경로는 워크로드의 민감도, 규모, 인력, 지연 시간 요구 사항, 외부 서비스 의존성에 대한 허용도에 따라 달라집니다.

오픈 소스는 이를 배포하지 않는 팀에게도 협상력을 바꿉니다. 구매자는 대안 아키텍처를 평가하고 하나의 독점 실행 서비스에 맞춰 설계할 위험을 줄일 수 있습니다.

Apache 라이선스는 벤더가 SPACE를 기반으로 상업적 서비스를 구축하는 것도 허용합니다. 이는 관리형 배포, 엔터프라이즈 지원 또는 특화된 배포판으로 이어질 수 있습니다.

호환 가능한 서비스가 인터페이스를 유지한다면 이러한 생태계는 Perplexity의 입지를 강화할 것입니다. 구현이 파편화되거나 보안 수정 사항을 따라가지 못한다면 프로젝트에는 불리하게 작용할 것입니다.

전문 벤더는 여러 방어 수단을 유지합니다. 호스팅 서비스는 신뢰성, 지역별 용량, 지원, 온보딩, 모니터링, 새로운 런타임 기능에 대한 더 빠른 접근성을 통해 경쟁할 수 있습니다.

관리형 제공업체는 오픈 소스가 드러내는 운영 복잡성을 숨길 수도 있습니다. 구성 요소로 가득한 저장소는 인프라 팀에는 가치가 있지만 애플리케이션 팀에는 부담스러울 수 있습니다.

Perplexity의 강점은 내부적 관련성을 뒷받침하는 증거입니다. 회사는 이 플랫폼이 Computer를 뒷받침하는 샌드박스 기능을 지원한다고 밝혔으며, 이는 설계에 까다로운 참조 워크로드를 제공합니다.

그러나 저장소만으로는 외부인이 이 주장을 재현할 수 없습니다. Perplexity의 플릿 규모, 서비스 수준 결과, 지역 토폴로지, 장애 이력 또는 인프라 지출을 공개하지 않기 때문입니다.

“수백만 개의 샌드박스”라는 표현도 신중하게 해석해야 합니다. 누적 생성 수, 최대 동시성, 활성 환경 또는 다른 내부 지표를 설명하는 것일 수 있습니다.

이러한 지표는 실질적으로 서로 다릅니다. 시간이 지남에 따라 수백만 개의 단기 샌드박스가 생성되었다고 해서 수백만 대의 가상 머신이 동시에 운영된다는 뜻은 아닙니다.

이 검증 격차가 프로젝트를 무효화하는 것은 아닙니다. 다만 독자가 발표만으로 어떤 결론을 내려야 하는지에 한계를 둡니다.

개발자는 공개 API, 코드, 배포 지침 및 테스트를 검증할 수 있습니다. 그러나 그러한 산출물만으로 내부 프로덕션 규모를 검증할 수는 없습니다.

따라서 가장 신뢰할 수 있는 비교는 독립적인 배포에서 나올 것입니다. 팀은 생성 지연 시간, 장애 복구, 명령 스트리밍, 호스트 활용률, 적대적 워크로드에서의 동작을 측정해야 합니다.

또한 플랫폼 운영에 드는 인적 비용도 추적해야 합니다. 기술적으로 뛰어난 시스템이라도 전문 인프라 팀의 지속적인 개입이 필요하다면 경제성이 없을 수 있습니다.

이번 오픈 릴리스는 검토 가능한 또 하나의 선택지를 만들었기 때문에 이미 경쟁 구도를 바꿨습니다. 하지만 SPACE가 관리형 서비스보다 더 나은 운영 결과를 제공하는지는 아직 결론 나지 않았습니다.

공개된 코드가 프로덕션 안전성을 증명하지는 않는다

SPACE는 의미 있는 구현 세부 정보를 제공하지만, 공개된 증거만으로는 Perplexity의 가장 광범위한 규모 및 보안 관련 주장을 아직 검증할 수 없다.

에이전트 샌드박스는 유난히 위험한 워크로드를 처리합니다. 그 핵심 목적은 모델이 생성했거나, 사용자가 제공했거나, 외부 콘텐츠에서 조합된 명령을 실행하는 것입니다.

이는 운영자가 일부 명령이 잘못 구성될 것이라고 가정해야 한다는 뜻입니다. 또한 공격자가 격리 경계를 의도적으로 시험할 것이라고도 가정해야 합니다.

microVM은 신뢰할 수 없는 명령을 공유 애플리케이션 호스트에서 직접 실행하는 것과 비교해 노출을 줄여 줍니다. 그러나 다층 방어의 필요성을 없애지는 않습니다.

호스트 커널, 가상화 구성 요소, 스토리지 경로, 네트워킹, 제어 API, 이미지 파이프라인에는 모두 취약점이 있을 수 있습니다. 잘못된 구성은 그 외에는 건전한 아키텍처를 약화시킬 수 있습니다.

저장소에는 비공개 취약점 보고 절차가 포함되어 있으며, 최신 마이너 릴리스에만 보안 수정이 제공된다고 명시되어 있습니다. 검토 시점에 공개 보안 정책에는 게시된 권고문이 없었습니다.

권고문이 없다는 사실은 취약점이 존재하지 않는다는 증거가 아닙니다. 새 프로젝트는 약점이 드러나기까지 시간, 채택, 적대적 테스트가 필요한 경우가 많습니다.

최신 마이너 버전 정책은 도입 기업의 작업도 늘립니다. SPACE를 셀프 호스팅하는 팀은 지원되는 보안 기간 내에 머무르기 위해 릴리스를 추적하고 신속하게 업데이트해야 합니다.

프로덕션 준비 상태에는 VM 탈출 방지 이상의 요소가 포함됩니다. 운영자에게는 테넌트 인증, 권한 부여, 할당량, 시크릿 처리, 감사 기록, 신뢰할 수 있는 정리가 필요합니다.

정리 실패는 비용이 크거나 위험해질 수 있습니다. 버려진 샌드박스는 계속 리소스를 소비하거나, 민감한 파일을 보관하거나, 의도한 것보다 오래 네트워크 자격 증명을 유지할 수 있습니다.

아웃바운드 접근도 동등한 주의가 필요합니다. 격리된 워크로드도 외부 시스템을 탐색하거나, 악성 코드를 다운로드하거나, 공격자에게 데이터를 보내며 피해를 일으킬 수 있습니다.

SPACE는 정책 메커니즘을 제공하지만, 도입 기업이 이를 구성해야 합니다. 이그레스 프로필이 존재한다고 해서 모든 배포에 제한적인 기본값이 적용되는 것은 아닙니다.

템플릿과 스냅샷은 또 다른 공급망 공격 표면을 만듭니다. 손상된 기본 이미지는 이를 기반으로 생성되는 모든 샌드박스에 영향을 줄 수 있습니다.

운영자에게는 재현 가능한 빌드, 종속성 검토, 이미지 서명, 취약점 스캔, 통제된 승격 절차가 필요합니다. 이러한 관행은 오픈 라이선스만으로 자동 제공되지 않습니다.

관측성은 상충하는 위험을 노출할 수 있습니다. 로그와 추적은 장애 진단에 도움이 되지만, 부주의한 텔레메트리는 명령 내용, 파일 경로, 토큰 또는 사용자 데이터를 수집할 수 있습니다.

팀은 무엇을 기록하고 얼마나 오래 보관할지 결정해야 합니다. 엔터프라이즈 배포에는 누가 에이전트 활동을 검토할 수 있는지에 관한 제어도 필요합니다.

신뢰성은 별도의 불확실성으로 남습니다. 샌드박스는 시작, 실행, 일시 중지, 복원 또는 출력 스트리밍 중에 실패할 수 있습니다.

애플리케이션은 지연된 작업과 실패한 작업을 구분해야 합니다. 또한 응답이 유실되었을 때 중복 리소스 생성을 피하는 멱등적 재시도도 필요합니다.

Perplexity의 문서는 복구 및 격리 동작을 다루며, 프로젝트가 이러한 장애 유형을 고려하고 있음을 시사합니다. 공개 벤치마크는 이러한 역량을 더 쉽게 평가할 수 있게 할 것입니다.

현재 릴리스는 독립적으로 감사된 처리량이나 가용성 수치를 제공하지 않습니다. 또한 공개 구성과 Perplexity의 내부 프로덕션 환경이 얼마나 밀접하게 일치하는지도 입증하지 않습니다.

기업은 종종 오픈 소스 코어 주변에 추가 시스템을 운영합니다. 내부 스케줄러, 용량 예측, 보안 서비스, 배포 자동화, 사고 대응 도구가 운영 결과의 상당 부분을 차지할 수 있습니다.

따라서 Perplexity의 주장은 좁게 읽어야 합니다. 회사는 샌드박스 아키텍처와 관련된 상당한 코드를 공개했습니다.

그러나 Perplexity Computer 뒤의 서비스를 재현하는 데 필요한 모든 절차를 이전한 것은 아닙니다. 또한 외부인이 주장된 프로덕션 규모를 검증할 수 있을 만큼 충분한 데이터를 공개하지도 않았습니다.

이것이 이번 릴리스의 핵심적인 상충 관계입니다. 오픈 코드는 검토 가능성과 통제력을 높이지만, 셀프 호스팅은 도입 기업에 더 큰 책임을 부여합니다.

SPACE를 평가하는 팀은 기능 체크리스트가 아니라 위협 모델에서 시작해야 합니다. 신뢰할 수 없는 입력, 보호 대상 자산, 허용된 목적지, 수용 가능한 복구 시간을 식별해야 합니다.

그런 다음 일반적인 데모가 피하는 실패 사례를 테스트해야 합니다. 여기에는 멈춘 부팅, 중단된 출력 스트림, 고갈된 호스트 용량, 잘못된 스냅샷, 취소된 자격 증명, 강제 종료가 포함됩니다.

독립적인 보안 검토를 통해 탈출 저항성도 테스트해야 합니다. 적대적 코드를 실행하도록 설계된 플랫폼은 일반적인 내부 서비스보다 더 엄격한 검토를 받아야 합니다.

SPACE는 그러한 작업을 정당화할 만큼 진지해 보입니다. 현재 이용 가능한 증거만으로는 이를 생략할 근거가 되지 않습니다.

SPACE가 공동 인프라가 될지 보여줄 세 가지 신호

다음 단계는 저장소에 대한 관심만이 아니라 외부 운영, 보안 대응, 실제 호환성에 의해 결정될 것이다.

첫 번째 신호는 독립적인 프로덕션 배포입니다. 개발자는 Perplexity 자체 환경 밖에서 Perplexity SPACE 샌드박스를 운영하는 조직이 등장하는지 지켜봐야 합니다.

의미 있는 사례 연구는 워크로드 형태, 동시성, 생성 지연 시간, 장애율, 인력을 설명해야 합니다. 로고나 설치 발표만으로는 훨씬 적은 정보를 알 수 있습니다.

독립적인 운영은 이 코드가 실사용 가능한 프로덕션 지식을 이전한다는 Perplexity의 주장을 강화할 것이다. 반대로 배포 복잡성에 대한 반복적인 보고는 그 주장을 약화시킬 것이다.

커뮤니티 기여 역시 이 첫 번째 신호에서 중요하다. 스케줄링, 런타임, 배포 대상 또는 진단 기능에 대한 실질적인 변경은 외부 기여자들이 아키텍처를 이해하고 확장하고 있음을 시사한다.

두 번째 신호는 프로젝트의 보안 및 릴리스 기록이다. 이 플랫폼은 설계상 신뢰할 수 없는 코드를 받아들이므로, 연구자들은 SPACE를 시험할 것이다.

이 계층에서 프롬프트 처리는 핵심 쟁점이 아니다. 본질적인 질문은 적대적인 프로세스가 격리 경계를 넘거나, 자격 증명을 오용하거나, 금지된 네트워크에 접근할 수 있는지다.

투명한 권고 프로세스, 시의적절한 패치, 명확한 업그레이드 가이드는 신뢰를 구축할 것이다. 조용한 수정이나 호환성을 깨는 보안 업데이트는 기업 도입을 더 어렵게 만들 것이다.

사용자들은 Perplexity가 공개 저장소를 얼마나 일관되게 관리하는지도 지켜봐야 한다. 내부 개발은 앞서가는데 공개 릴리스가 뒤처지면 오픈 소스 플랫폼의 가치는 떨어진다.

세 번째 신호는 실제 에이전트 워크로드에서의 호환성이다. E2B 래퍼는 애플리케이션이 동작을 바꾸지 않고 인프라를 변경할 수 있는지를 직접 검증하게 한다.

개발자는 장시간 실행 명령, 파일 전송, 취소, 재연결, 지속성 및 동시 세션을 살펴봐야 한다. 이러한 예외 상황은 성공적인 “hello world” 명령보다 더 많은 것을 보여준다.

신뢰할 수 있는 호환성은 관리형 샌드박스 제공업체에 대한 압박을 높일 것이다. 팀이 실행 백엔드를 교체 가능한 구성 요소로 다룰 수 있게 해주기 때문이다.

불완전한 호환성은 전환 비용을 유지할 것이다. 제공업체는 애플리케이션이 암묵적으로 의존하는 동작을 통해 계속 차별화할 수 있다.

Perplexity Computer는 또 다른 관찰 지점을 제공한다. Computer가 더 복잡한 결과물을 처리할수록 사용자는 실행 환경의 실질적인 한계를 마주하게 될 것이다.

패키지 설치, 장시간 작업, 유지되는 상태 또는 생성된 파일과 관련된 실패는 샌드박스 인프라가 여전히 제품을 제약하는 지점을 드러낼 수 있다. 개선 사항은 기반 플랫폼이 얼마나 빠르게 발전하는지도 보여줄 수 있다.

지식 집약적인 에이전트를 구축하는 개발자는 실행이 컨텍스트와 어떻게 연결되는지도 고려해야 한다. 샌드박스는 코드를 실행할 수 있지만, 여전히 신중하게 선택된 파일과 지침이 필요하다.

따라서 정보 검색과 권한 설계는 컴퓨팅 격리만큼 중요하다. 검색 가능한 AI knowledge base는 에이전트에 접근 권한을 부여하기 전에 소스 자료를 정리할 수 있다.

Perplexity SPACE 샌드박스 출시는 오늘날 하나의 결론을 합리적으로 뒷받침한다. 에이전트 실행은 자체 인터페이스, 호환성 문제 및 배포 선택지를 갖춘 독립적인 인프라 계층으로 자리 잡고 있다.

그러나 이것이 모든 팀에 셀프 호스팅이 최선의 해답이라는 점을 아직 입증하지는 않는다. 인프라 제어보다 안정성이 더 중요할 때 관리형 운영은 여전히 가치가 있다.

따라서 실질적인 질문은 구체적이다. 조직이 실행 경계를 직접 소유해야 하는가, 그리고 그 경계를 안전하게 운영할 수 있는가?

답이 그렇다면 적대적 워크로드와 현실적인 장애 조건을 대상으로 SPACE를 테스트하라. 답이 아니라면 공개된 설계를 활용해 관리형 제공업체에 더 날카로운 질문을 던져라.

향후 3개월 동안 독립적인 배포, 보안 공개 및 호환성 결과를 지켜보라. 이러한 신호는 SPACE가 공동의 에이전트 인프라가 될지, 아니면 주로 Perplexity가 공개한 참조 구현으로 남을지를 보여줄 것이다.