AI 생성 코드를 호스트 밖에서 실행하려면: Alibaba OpenSandbox 점검법

AI가 만든 코드를 실행해야 한다면 호스트에서 바로 돌리지 말고 별도 수명 주기와 자원 제한을 가진 샌드박스에 넣어야 하며, OpenSandbox는 Docker와 Kubernetes용 관리 계층을 제공합니다. 그러나 컨테이너 사용 자체가 안전 승인은 아니며 관리 API, 볼륨, 네트워크, 비밀 전달까지 포함한 위협 모델이 필요합니다. 실제 도입 여부는 악성, 오류 코드가 제한을 넘으려 할 때 세션이 차단되고 정리되는지를 실패 시험으로 판단해야 합니다.

왜 컨테이너 하나만으로는 충분하지 않나요?

에이전트 작업은 패키지 설치, 파일 작성, 실행, 수정이 이어지는 상태 유지 세션입니다. OpenSandbox는 생성, 실행, 파일 전송, 종료를 Sandbox Protocol과 SDK로 다루며 Python, Java/Kotlin, JavaScript/TypeScript 클라이언트를 제공하는 것으로 소개됩니다.

Docker 런타임은 로컬 개발과 가벼운 환경, Kubernetes 런타임은 분산 스케줄링을 대상으로 합니다. CPU와 메모리 제한, 환경 변수와 메타데이터, 준비 상태 확인도 설정할 수 있습니다. GUI 에이전트용 데스크톱 이미지에는 Xvfb, XFCE, x11vnc가 포함된다고 원문은 설명합니다.

코드 실행 서비스에는 컨테이너 생성 전의 요청 인증, 실행 중의 자원, 네트워크 통제, 종료 뒤 파일, 로그 삭제가 모두 필요합니다. 컨테이너 내부가 제한돼도 누구나 관리 API를 호출할 수 있거나 호스트의 넓은 디렉터리를 마운트하면 경계가 무너집니다. 샌드박스 프로토콜은 수명 주기를 통일하지만 조직의 허용 정책을 대신 정해 주지는 않습니다.

먼저 어떤 위협 모델을 적어야 하나요?

입력 코드는 실수로 무한 루프를 만들 수 있고, 의도적으로 메모리, 디스크를 채우거나 외부 네트워크로 데이터를 보낼 수도 있습니다. 실행 주체가 접근해도 되는 파일, 도메인, 자격 증명과 최대 실행 시간을 먼저 목록화합니다. 코드가 신뢰되지 않는다는 가정과 플랫폼 관리자가 신뢰된다는 가정도 분리합니다.

여러 사용자가 같은 서버를 쓴다면 다른 세션의 파일, 프로세스, 네트워크와 로그를 볼 수 없어야 합니다. 세션 ID를 추측하거나 재사용했을 때 다른 결과에 접근하는지, 종료된 ID가 새 세션에 잘못 연결되는지 시험합니다. Kubernetes namespace만 다르다는 사실이나 컨테이너 이름이 다르다는 사실로 tenant 격리를 증명해서는 안 됩니다.

GUI 이미지에는 브라우저와 원격 화면 서비스가 추가돼 공격 표면이 넓어집니다. x11vnc 접근 경로의 인증, 포트 노출과 클립보드, 다운로드 디렉터리를 확인하고, GUI가 필요 없는 코드 작업에는 더 작은 이미지를 사용하는 편이 좋습니다.

상태 유지 세션은 어떻게 안전하게 닫아야 하나요?

JavaScript/TypeScript SDK는 Sandbox와 SandboxManager가 연결 설정과 Keep-Alive 풀을 관리합니다. 작업이 끝난 뒤 sandbox.close()와 manager.close()를 호출하지 않으면 세션 자원과 연결이 남을 수 있습니다. 브라우저 환경에서는 전역 fetch를 사용하고 파일 스트리밍 업로드 대신 메모리 버퍼링을 거칠 수 있어 큰 파일의 메모리 사용도 확인해야 합니다.

수명 주기는 생성, 준비 확인, 명령 실행, 파일 입출력, 결과 수집, 종료 순으로 기록하는 편이 좋습니다. 에이전트가 실패해도 종료 단계가 실행되는지 별도 테스트해야 합니다.

정상 완료 경로만 테스트하면 시간 초과, 클라이언트 연결 끊김과 관리 서버 재시작 때 자원이 남는 문제를 놓칩니다. 세션마다 만료 시간과 소유자를 기록하고, 클라이언트가 close()를 호출하지 못해도 서버가 고아 세션을 회수하는지 확인합니다. 정리 작업이 실패했을 때 재시도 횟수와 관리자 알림도 필요합니다.

부분 실행과 재시도는 어떻게 다뤄야 하나요?

명령이 시간 초과됐다고 프로세스가 실제로 종료됐는지, 자식 프로세스와 백그라운드 작업이 남지 않았는지 봅니다. 같은 요청을 다시 보낼 때 이전 파일과 출력이 재사용되는지, 새 세션으로 시작되는지 명확히 해야 합니다. 상태 유지가 장점이지만 실패 상태까지 조용히 유지되면 재시도 결과를 해석하기 어렵습니다.

파일 업로드가 중간에 끊겼을 때 부분 파일을 실행하지 않는지, 결과 다운로드 중 세션이 종료돼도 접근 권한이 남지 않는지 시험합니다. 큰 파일을 메모리에 버퍼링하는 클라이언트는 샌드박스 자원과 별개로 호출 애플리케이션의 메모리를 소모하므로 양쪽 제한을 함께 측정합니다.

감사 로그에는 사용자 요청, 이미지와 런타임 버전, 실행 명령, 종료 사유와 자원 사용량을 연결하되 환경 변수나 출력의 비밀값을 마스킹합니다. 로그가 문제 해결에는 충분하면서도 실행 코드가 출력한 민감 데이터를 장기 보존하지 않는 균형이 필요합니다.

설치 명령에서 빠진 운영 전제는 무엇인가요?

원문에 실린 서버 시작 예시는 다음과 같습니다.

uv pip install opensandbox-server
opensandbox-server init-config ~/.sandbox.toml --example docker
opensandbox-server

이 조각에는 패키지 버전, Python 버전, Docker 데몬 설정, 인증과 네트워크 정책이 없습니다. 따라서 복사만 하면 안전한 서버가 완성되는 절차가 아닙니다. 소스 설치 예시와 Node SDK 설치도 원문에 있지만, 먼저 GitHub 저장소와 NPM 패키지의 사용 시점 안내를 대조해야 합니다.

서버를 띄운 다음에는 관리 API가 어느 인터페이스에 바인딩되는지와 TLS, 인증 설정을 확인합니다. 개발용 기본 포트를 외부에 공개하지 않고, Kubernetes에서는 네트워크 정책과 서비스 계정 권한을 최소화합니다. 설정 파일과 컨테이너 이미지의 버전을 고정해 같은 배포를 재현할 수 있게 해야 합니다.

이미지와 패키지 공급망은 어떻게 확인하나요?

샌드박스가 패키지를 자유롭게 설치하면 악성 또는 변조된 의존성을 내려받을 수 있습니다. 허용 레지스트리, 패키지 캐시와 네트워크 범위를 정하고, 기본 이미지의 digest와 포함 패키지를 기록합니다. GUI 이미지처럼 구성 요소가 많은 경우 보안 업데이트 주기와 이미지 재빌드 절차도 포함합니다.

실행 코드에 자격 증명이 필요하다면 장기 키를 이미지나 환경 변수에 고정하지 말고 작업 범위와 수명이 짧은 값을 검토합니다. 세션 프로세스, 오류 메시지와 로그에서 그 값이 보이지 않는지 확인하고 종료 뒤 폐기합니다. 비밀 전달 기능이 있다는 사실보다 누가 어떤 세션에 무엇을 줄 수 있는지가 통제돼야 합니다.

격리는 어떤 실패 시험으로 확인해야 하나요?

CPU 1개와 메모리 2Gi 같은 제한을 설정했다면 실제로 초과 작업이 종료되는지 확인합니다. 샌드박스에서 호스트 파일, 다른 세션, 클라우드 자격 증명에 접근할 수 없는지도 시험해야 합니다. 네트워크가 필요한 작업과 차단해야 할 목적지를 구분하고, 이미지와 패키지 출처를 고정해야 합니다.

컨테이너를 사용한다는 사실만으로 완벽한 보호가 증명되지는 않습니다. 관리 API의 인증, 볼륨 마운트, 권한 상승, 로그의 비밀값 노출 같은 경계도 함께 검토해야 합니다.

CPU, 메모리뿐 아니라 프로세스 수, 디스크 용량과 실행 시간을 초과하는 시험을 둡니다. 제한에 도달했을 때 해당 세션만 종료되고 관리 서버와 다른 세션이 계속 작동하는지 확인합니다. 반복적으로 제한을 초과하는 요청을 보내도 노드 전체가 불안정해지지 않는지 부하 시험이 필요합니다.

네트워크는 전면 허용과 전면 차단 사이에서 작업별 정책을 설계합니다. 패키지 설치가 필요한 세션과 민감한 데이터 분석 세션을 분리하고, 내부 메타데이터 주소, 사설망과 허가되지 않은 외부 목적지에 접근하지 못하는지 시험합니다. DNS만 막거나 HTTP만 검사하면 다른 프로토콜로 우회할 가능성이 남습니다.

볼륨 시험에서는 읽기 전용, 쓰기 가능 경로를 구분하고 심볼릭 링크나 경로 이동으로 범위를 벗어나지 않는지 봅니다. Docker 소켓이나 과도한 Linux capability가 노출되지 않았는지도 확인합니다. 이 검사는 설정한 경계가 실제로 유지되는지 확인하는 운영 검증입니다.

Docker와 Kubernetes 중 어느 규모에 맞나요?

로컬 Docker부터 Kubernetes까지 같은 SDK로 수명 주기를 다루고, 코드 인터프리터와 GUI 에이전트 평가를 한 플랫폼에 두려는 팀에는 검토 가치가 있습니다. 반면 직접 서버와 런타임을 운영해야 하므로 관리형 API보다 초기 구성과 유지 부담이 큽니다.

도입은 신뢰하지 않는 짧은 작업 하나로 시작해 생성 시간, 동시 세션 수, 강제 종료, 정리 실패를 측정해야 합니다. OpenSandbox는 격리 정책을 구현할 재료이지, 모든 배포에 맞는 보안 승인을 자동으로 제공하는 해답은 아닙니다.

Docker 런타임은 한 호스트에서 작은 동시성으로 개발, 평가할 때 단순하지만 호스트 장애와 용량 한계가 한곳에 모입니다. Kubernetes는 여러 노드에 세션을 배치하고 자원 할당을 관리할 수 있지만 클러스터 권한, 네트워크, 이미지 운영이 추가됩니다. 같은 SDK를 쓴다는 사실이 두 환경의 보안 설정을 같게 만들지는 않습니다.

전환 기준은 평균 세션 수보다 동시 peak, 생성 대기 시간, 노드 장애 때 중단 가능한 작업 비율로 잡을 수 있습니다. 작은 부하에서 Kubernetes를 먼저 선택하면 운영 복잡도가 이득보다 클 수 있고, 여러 사용자와 고가용성이 필요한데 단일 Docker 호스트를 유지하면 정리와 용량 관리가 병목이 됩니다.

PoC의 완료 조건에는 악성, 오류 작업 차단, 정상 작업 성능, 고아 세션 0개, 비밀값 노출 0건과 빈 환경 복구 시간을 포함합니다. 이 증거가 있어야 OpenSandbox가 단순한 컨테이너 실행 래퍼가 아니라 팀의 코드 실행 경계를 일관되게 관리하는 계층으로 작동한다고 볼 수 있습니다.

함께 읽으면 이해가 이어지는 글

• Qwen-Agent로 함수 호출, RAG, WebUI를 묶기 전 확인할 것 — Qwen-Agent의 LLM, Tool, Memory/RAG, Agent 구조와 WebUI, 코드 실행 기능을 살피고, 원문 예제의 가짜 응답, 버전 누락, 격리 한계를 짚습니다.
• OpenHands는 Docker 안이면 안전할까? Event Stream, 위임, 권한 점검 — OpenHands의 Event Stream, Docker 샌드박스와 에이전트 위임 구조를 읽고, 설치 전에 확인할 권한, 비용, 중단 조건을 실무 관점에서 정리합니다.
• Agent Zero에 컴퓨터를 통째로 줘도 될까: Docker 권한의 실제 경계 — Agent Zero의 터미널, 코드 실행형 구조를 살펴보고, Docker를 완전한 격리로 오해하지 않기 위한 권한, 네트워크, 승인 체크리스트를 정리합니다.