Docker와 Kubernetes를 같은 API로 다루는 에이전트 샌드박스 OpenSandbox, AAIF 프로젝트로 합류

9bow · 10월 25, 2026, 8:30오전

핵심 요약

Agentic AI Foundation(AAIF)이 2026년 10월 22일 블로그 글에서 OpenSandbox가 AAIF 프로젝트가 되었다고 발표했습니다. AAIF는 MCP, goose, AGENTS.md, A2A 등을 맡고 있는 Linux Foundation 산하 재단이고, 같은 날 Anthropic, OpenAI, Hugging Face가 기여한 프로젝트 3개도 함께 받아들였습니다.
발표의 핵심 주장은 샌드박스를 에이전트가 요청하는 공통 기본 단위로 다루자는 것입니다. 에이전트는 생명주기 API와 실행 API만 호출하고, Docker와 Kubernetes 중 어느 런타임이 실제로 일을 하는지는 서버 설정이 정합니다.
저장소는 opensandbox-group/OpenSandbox로 옮겨졌고(옛 alibaba/OpenSandbox 주소는 리다이렉트), Apache 2.0 라이선스를 유지합니다. 다만 npm, Maven, NuGet, Go 패키지 이름에는 아직 Alibaba 표기가 남아 있습니다.
지난 3월 PyTorchKR 소개 글 이후 Go SDK, osb CLI, Credential Vault, Firecracker 기반 Fast Sandbox가 추가되었습니다. README의 생성 지연 64ms는 캐시가 준비된 2노드 클러스터에서 잰 순차 생성 중앙값이며, 동시 20개 요청에서는 100건 중 51건만 성공했습니다.

OpenSandbox 소개

OpenSandbox는 AI 에이전트가 쓰는 격리 실행 환경을 하나의 API로 다루게 하는 오픈소스 샌드박스 플랫폼입니다. 환경을 만들고, 그 안에서 코드와 명령을 실행하고, 다 쓴 환경을 지우는 과정이 모두 이 API를 거칩니다. Alibaba가 2025년 말 공개한 프로젝트이고, PyTorchKR에서는 지난 3월 OpenSandbox: Alibaba가 오픈소스로 공개한 AI 에이전트를 위한 범용 샌드박스 플랫폼 글에서 기능과 설치 방법을 소개했습니다.

이번 소식은 기능 추가가 아니라 프로젝트의 소속이 바뀐 일입니다. Agentic AI Foundation(AAIF)은 Linux Foundation 산하의 중립 재단입니다. 이 재단은 Model Context Protocol(MCP), goose, AGENTS.md, Agent2Agent(A2A) 같은 에이전트 프로토콜과 오픈소스를 맡고 있습니다. AAIF는 10월 22일 AGNTCon + MCPCon North America에서 새 프로젝트 4개를 발표했습니다. Anthropic이 기여한 Agent Skills, OpenAI가 기여한 Open Responses, Hugging Face가 기여한 OpenEnv, Alibaba가 기여한 OpenSandbox입니다. 이로써 2025년 12월 프로젝트 3개로 출발한 AAIF의 프로젝트 목록은 10개가 되었습니다. 이 목록에는 에이전트 학습 환경을 다루는 OpenEnv도 있지만, 에이전트가 작업할 샌드박스 자체를 다루는 프로젝트는 OpenSandbox 하나입니다.

AAIF 발표 글은 OpenSandbox의 기능을 나열하기보다 "샌드박스를 에이전트의 기본 단위(primitive)로 본다" 는 설계 주장을 설명하는 데 집중합니다. 이 글은 그 주장을 먼저 정리하고, 공식 아키텍처 문서와 저장소에서 그 주장이 어떻게 구현되어 있는지, 지난 소개 글 이후 무엇이 바뀌었는지를 함께 살펴봅니다.

샌드박스 API가 런타임마다 다른 문제

코딩 에이전트는 저장소 복제, 의존성 설치, 파일 수정, 테스트 실행, 개발 서버 실행 같은 작업을 합니다. 이 작업을 호스트 머신에서 그대로 실행하면 에이전트가 작업과 상관없는 파일과 서비스에 접근할 수 있습니다. 그래서 호스트 접근이 제한된 샌드박스(Sandbox) 안에서 실행하는 것이 일반적입니다.

AAIF 글이 지적하는 문제는 그다음 단계입니다. 에이전트가 이 환경을 어떻게 만들고, 어떻게 안에서 일하고, 어떻게 지우는가입니다. 샌드박스 제공자마다 생성, 저장소, 네트워크, 보안, 삭제를 다루는 API가 다르기 때문에, 특정 구현에 맞춰 만든 에이전트는 그 구현에 강하게 묶입니다. 에이전트 프레임워크, 평가 플랫폼, AI 애플리케이션이 저마다 실행 환경을 만드는 규약을 따로 정의하면 개발자는 같은 추상화를 반복해서 다시 만들게 됩니다.

AAIF 글은 또 하나의 변화를 지적합니다. 컨테이너와 가상 머신으로 워크로드를 격리하는 기술은 오래되었지만, 지금 바뀌고 있는 것은 누가 그 환경을 만드느냐입니다. 예전에는 인프라 팀이 환경을 미리 준비했다면, 에이전트 시스템에서는 작업이 실행되는 도중에 소프트웨어가 샌드박스를 요청합니다. 그래서 샌드박스를 요청하는 인터페이스가 점점 더 중요해진다는 것이 AAIF 글의 논지입니다. OpenSandbox는 이 인터페이스를 공통 규약으로 고정하고, 그 아래의 런타임은 자유롭게 구현하게 둡니다.

생명주기 API와 실행 API로 나눈 샌드박스 프로토콜

OpenSandbox의 중심에는 샌드박스 프로토콜(Sandbox Protocol) 이 있습니다. 애플리케이션이 샌드박스와 상호작용하는 공개 규약을 OpenAPI 명세로 정의한 것이고, 저장소의 specs/ 디렉터리가 이 규약의 정본입니다. AAIF 글은 생명주기 API와 실행 API 두 부분을 중심으로 설명하고, 저장소에는 진단과 이그레스 명세가 더 있습니다.

구분	명세 파일	하는 일
생명주기 API (Lifecycle API)	`specs/sandbox-lifecycle.yml`	샌드박스 생성, 조회, 일시 정지, 재개, 만료 연장, 스냅샷, 삭제. 이미지, 스냅샷, 템플릿 중 하나로 생성
실행 API (Execution API)	`specs/execd-api.yaml`	샌드박스 안에서 명령과 코드 실행, 파일과 디렉터리 조작, 셸 세션 유지, CPU와 메모리 측정값 수집
진단 API	`specs/diagnostic-api.yml`	샌드박스 로그와 이벤트 조회
이그레스 API	`specs/egress-api.yaml`	실행 중 아웃바운드 네트워크 정책 조회와 수정, Credential Vault 관리

에이전트는 Docker 컨테이너나 Kubernetes 워크로드를 직접 만들지 않습니다. 원하는 설정(이미지, 리소스 한도, 볼륨, 네트워크 정책 등)으로 샌드박스를 요청하면, 서버가 그 요청을 설정된 런타임의 명령으로 바꿉니다. Docker 백엔드는 컨테이너를 직접 만들고, Kubernetes 백엔드는 워크로드와 관련 리소스를 만듭니다. AAIF 글의 표현대로 Docker와 Kubernetes는 여전히 다른 시스템이지만, 두 시스템이 공유하는 부분에 대해서는 에이전트가 같은 연산을 쓸 수 있습니다.

에이전트 작업 하나를 따라가 보기

AAIF 글은 코딩 에이전트가 저장소를 복제하고 테스트를 실행하는 예로 흐름을 설명합니다. 에이전트(또는 에이전트를 조율하는 애플리케이션)가 SDK로 샌드박스를 요청하면, 생명주기 서버가 요청을 검증하고 프로비저닝 작업을 런타임 서비스에 넘깁니다.

Agent → OpenSandbox SDK → Lifecycle API → Runtime

샌드박스 생성은 비동기로 진행됩니다. 환경이 실행 상태가 되면 에이전트는 SDK로 git clone 같은 명령을 보내고, 이 명령은 샌드박스 안에서 도는 실행 데몬 execd에 전달되어 실행됩니다. 전체 작업은 다음 다섯 단계로 정리됩니다.

에이전트가 생명주기 API로 샌드박스를 요청합니다.
설정된 런타임이 샌드박스를 만듭니다.
에이전트가 명령과 파일 작업을 execd에 보냅니다.
실행 결과와 리소스 측정값이 에이전트에게 돌아옵니다.
작업이 끝나거나 만료 시간이 되면 샌드박스가 삭제됩니다.

에이전트 입장에서 이 상호작용은 백엔드가 Docker이든 Kubernetes이든 같은 인터페이스를 거칩니다. 아키텍처 문서에 따르면 실행 API 호출은 생명주기 오케스트레이션을 거치지 않고, 해석된 엔드포인트로 execd에 연결됩니다. 이 엔드포인트는 호스트나 파드 주소, 생명주기 서버의 프록시, Kubernetes 인그레스 게이트웨이 중 하나입니다. 명령과 코드 실행 결과는 Server-Sent Events(SSE)로 스트리밍됩니다.

아키텍처: 제어 평면, 데이터 평면, 네트워크 평면

공식 아키텍처 문서는 요청 경로를 세 가지로 구분합니다. 아래 그림에서 주황색 화살표는 생명주기 관리, 파란색은 실행과 서비스 접근, 초록색은 아웃바운드 제어 경로입니다.

이 구조는 여섯 개 층으로 나뉩니다.

클라이언트 층: Python, JavaScript/TypeScript, Java/Kotlin, C#/.NET, Go SDK와 osb CLI, MCP 서버. SDK는 OpenAPI에서 생성한 클라이언트 위에 스트리밍, 오류 매핑 같은 사용 편의 계층을 손으로 덧씌운 구조입니다.
프로토콜 층: specs/ 아래의 OpenAPI 명세. 공개 동작은 여기서 시작하고, 생성된 코드는 명세에서 다시 생성해야 한다는 원칙(Protocol First)을 둡니다.
생명주기 제어 평면(Control Plane): server/ 아래의 FastAPI 서버. 인증, 요청 검증, 오케스트레이션을 맡고 실제 리소스 생성은 런타임 서비스에 위임합니다. 메타데이터는 SQLite(기본값) 또는 PostgreSQL에 저장합니다.
런타임 백엔드: 로컬과 단일 호스트용 Docker, 그리고 Kubernetes. Kubernetes 모드에서는 워크로드 제공자로 OpenSandbox 자체 BatchSandbox 커스텀 리소스(CRD, Custom Resource Definition)와 kubernetes-sigs/agent-sandbox 중 하나를 고르고, 여기에 템플릿 기반 Firecracker microVM인 Fast Sandbox를 함께 쓸 수 있습니다.
샌드박스 데이터 평면(Data Plane): 사용자 워크로드와 그 옆에 주입되는 execd. execd는 Gin 기반 Go 데몬이며 명령 실행, 파일 조작, 대화형 터미널(PTY) 세션, Jupyter 기반 코드 실행, 메트릭을 담당합니다.
네트워크와 보안 평면: 엔드포인트 해석, 인그레스 게이트웨이, 이그레스 정책, Credential Vault, gVisor와 Kata Containers 같은 보안 컨테이너 런타임.

런타임 선택은 서버 설정의 [runtime].type으로 정합니다. 값은 docker와 kubernetes 둘뿐이고, 모든 구현이 같은 SandboxService 인터페이스를 따릅니다. Kubernetes 모드에서는 CompositeSandboxService가 요청을 나눕니다. templateId가 있는 생성 요청은 Fast Sandbox로, image나 snapshotId가 있는 요청은 컨테이너 워크로드 제공자로 보냅니다. 이미 만들어진 샌드박스는 ID 접두사(fsb-)로 경로를 정합니다. Fast Sandbox 문서는 새 공개 API 없이 기존 생명주기 규약 위에 백엔드를 추가했다고 설명합니다. 다만 SDK에는 템플릿 생성용 메서드(create_from_template)가 1.1.0에서 추가되었습니다.

AAIF 글이 말하는 공통 기본 단위 주장이 코드에서 실제로 지켜지는 부분이 바로 이 서비스 경계입니다.

다만 이 공통성에는 범위가 있습니다. 아키텍처 문서도 런타임과 네트워크 기능은 선택한 백엔드에 따라 달라진다고 밝힙니다. 예를 들어 아키텍처 문서는 공개 스냅샷 API가 모든 Kubernetes 제공자나 VM 런타임을 지원하지는 않는다고 적고 있고, gVisor(runsc) 샌드박스의 스냅샷 요청은 1.1.0부터 409 오류로 거부됩니다. Fast Sandbox 어댑터는 현재 볼륨 마운트를 거부합니다. 같은 API라도 모든 연산이 모든 백엔드에서 동작하지는 않으니, 쓰려는 기능이 대상 백엔드에서 지원되는지 문서에서 먼저 확인해야 합니다.

3월 소개 이후 달라진 것

지난 3월 소개 글 이후 프로젝트는 소속뿐 아니라 배포 방식과 기능도 바뀌었습니다. 확인한 변화를 표로 정리하면 다음과 같습니다.

항목	2026년 3월 소개 시점	2026년 10월 22일 기준
저장소	`alibaba/OpenSandbox`	`opensandbox-group/OpenSandbox` (옛 주소는 리다이렉트)
소속	Alibaba 오픈소스	AAIF 프로젝트 (Linux Foundation 산하)
버전 체계	구성요소별 개별 버전	2026년 9월 21일 `1.1.0`부터 서버, 이미지, 차트, CLI, SDK를 한 버전으로 묶어 배포. 최신 안정판은 10월 9일(UTC) `1.1.1`, `1.2.0-rc.2`가 진행 중
SDK	Python, Java/Kotlin, JavaScript/TypeScript, C#/.NET	Go SDK 추가(첫 릴리스 2026년 4월 13일)
터미널, 에이전트 연동	MCP 서버는 2026년 1월 말부터 있었으나 이전 글에서 다루지 않음	`osb` CLI 추가(2026년 4월 첫 배포), MCP 서버(`opensandbox-mcp`)는 계속 제공
자격 증명	언급 없음	Credential Vault: 실제 비밀 값을 샌드박스에 넣지 않고 이그레스 사이드카가 요청 헤더에 주입
고속 생성	언급 없음	Fast Sandbox: 미리 준비된 Fastlet 파드 안에서 Firecracker microVM을 템플릿으로 복원

PyPI의 opensandbox, opensandbox-server, opensandbox-cli, opensandbox-mcp 패키지와 npm의 @alibaba-group/opensandbox 패키지는 10월 22일 현재 모두 1.1.1입니다. 버전이 1.x이지만 로드맵의 "현재 계획 없음" 항목은 "생명주기 의미, 런타임 동작, SDK 호환성이 충분히 성숙하기 전에 안정 v1 API를 선언하는 것" 을 들고 있습니다. 패키지 버전 번호와 API 안정성 선언은 별개이므로, 운영 환경에 도입할 때는 이 점을 감안해야 합니다.

Fast Sandbox의 64ms는 어떤 조건에서 잰 값인가

README는 Fast Sandbox의 Firecracker 생성 시간을 "64 ms P50 (serial) / 125.4 ms P99 (10 concurrent)" 로 소개합니다. 성능 문서를 열어 보면 이 수치의 측정 조건과 한계가 자세히 적혀 있습니다.

측정 환경: 2026년 10월 8일, Alibaba Cloud 관리형 Kubernetes(ACK) 노드 2대. 노드마다 AMD EPYC 9T95, 192 CPU, 약 742GiB 메모리. Fastlet 5개, 슬롯 20개.
측정 조건: 템플릿 아티팩트가 두 노드에 이미 캐시된 웜(warm) 생성. 준비 상태 확인 간격은 10ms로, SDK 기본값 200ms보다 짧게 설정했습니다. 컴포넌트는 release-1.1.1-rc.1, SDK는 개발 빌드를 썼습니다.
결과: 순차 생성 중앙값 64.0ms(100건 모두 성공), 동시 10개 p99 125.4ms(100건 모두 성공). 동시성 측정과 함께 다시 잰 순차 측정은 중앙값 77.9ms였습니다. 두 배치는 클라이언트 CPU 한도와 배치 위치가 달라서, 문서는 이를 통제된 비교로 보지 않는다고 밝힙니다.
포화 결과: 동시 20개에서는 100건 중 51건만 성공했습니다. 48건은 용량 거부(HTTP 429), 1건은 준비 시간 초과였습니다. 문서는 이 실행이 "신뢰할 수 있는 20개 동시 처리나 지속 가능한 초당 요청 수를 보여 주지 않는다" 고 적었습니다.
일시 정지와 재개: 런타임 복원 자체는 약 35ms였지만, SDK 기준으로 재개 후 사용 가능해지기까지 중앙값은 62.66초였습니다(표본 3개). SDK 기본 재개 대기 시간은 30초라서 측정에서는 4분으로 늘렸고, 세 표본 모두 같은 노드 안에서의 재개입니다. 문서는 이 차이의 원인을 아직 분리하지 못했다고 밝힙니다.

즉 64ms는 캐시와 용량이 준비된 상태의 순차 생성 시간이고, 콜드 아티팩트 전달과 콜드 커널 부팅은 이번 측정에서 검증되지 않았습니다. 저자들이 실패 건수와 측정 조건을 숨기지 않고 함께 공개한 점은, 비슷한 수치를 내세우는 다른 샌드박스와 비교할 때 기준으로 삼을 만합니다.

Credential Vault의 동작 방식과 제약

에이전트가 모델 API나 GitHub를 호출하려면 자격 증명이 필요하지만, 샌드박스 안에 실제 키를 두면 프롬프트 인젝션이나 신뢰할 수 없는 코드가 키를 빼낼 수 있습니다. Credential Vault는 이 문제를 이그레스 사이드카에서 해결합니다. 호스트 쪽 SDK가 실제 자격 증명을 사이드카에 쓰고, 샌드박스 프로세스는 가짜 값이나 빈 값만 받습니다. 샌드박스가 허용된 HTTPS 요청을 보내면 사이드카가 요청을 가로채(TLS MITM) 바인딩 규칙과 정확히 하나가 일치할 때만 인증 헤더를 넣어 내보냅니다.

이 기능에는 지켜야 할 조건이 있습니다. 서버 설정에서 [egress].mode = "dns+nft"가 필요하고, DNS 전용 모드에서는 직접 IP 연결로 정책을 우회할 수 있어 기능이 켜지지 않습니다. 아웃바운드 정책은 기본 거부(defaultAction="deny")로 두고, 자격 증명이 쓰일 호스트만 명시적으로 허용해야 합니다. Istio나 Envoy 같은 서비스 메시 사이드카가 같은 파드에 주입되어 있으면 함께 쓸 수 없습니다. 또한 컨테이너 백엔드에서 볼트 내용은 사이드카 메모리에만 있습니다. 그래서 Kubernetes에서 일시 정지 후 재개하면 볼트가 비어 있고, 자격 증명을 다시 주입해야 합니다.

로컬에서 시작하기

로컬에서 Docker와 Python 3.10 이상이 준비되어 있다면, README 기준으로 다음과 같이 시작할 수 있습니다. 먼저 Docker 런타임 예제 설정 파일을 만들고 생명주기 서버를 실행합니다.

uvx opensandbox-server init-config ~/.sandbox.toml --example docker
uvx opensandbox-server

서버가 떠 있는 상태에서 Python SDK를 설치합니다.

uv pip install opensandbox

다음은 README의 예제로, alpine 이미지로 샌드박스를 만들고 명령 실행, 파일 쓰기와 읽기, 스크립트 실행을 거쳐 샌드박스를 정리합니다. destroy() 메서드는 PyPI의 opensandbox 1.1.1 휠에 있는 것을 확인했습니다.

import asyncio

from opensandbox import Sandbox
from opensandbox.models import WriteEntry

async def main() -> None:
    # 1. Create a sandbox from the alpine image
    sandbox = await Sandbox.create("alpine")

    try:
        # 2. Execute a shell command
        execution = await sandbox.commands.run("echo 'Hello OpenSandbox!'")
        print(execution.logs.stdout[0].text)

        # 3. Write a script file
        await sandbox.files.write_files([
            WriteEntry(
                path="/tmp/hello.sh",
                data="echo \"Hello $1\"\necho '2 + 2 =' $((2 + 2))",
                mode=755,
            )
        ])

        # 4. Read the file back
        content = await sandbox.files.read_file("/tmp/hello.sh")
        print(f"Content: {content}")

        # 5. Execute the script
        execution = await sandbox.commands.run("sh /tmp/hello.sh OpenSandbox")
        for log in execution.logs.stdout:
            print(log.text)

    finally:
        # 6. Cleanup the sandbox
        await sandbox.destroy()

if __name__ == "__main__":
    asyncio.run(main())

터미널에서 바로 다루려면 osb CLI를, Claude Code나 Cursor 같은 MCP 클라이언트에 연결하려면 MCP 서버를 씁니다. 아래 osb 명령은 앞에서 실행한 서버가 localhost:8080에서 응답한다고 가정합니다.

pip install opensandbox-cli
osb config init
osb config set connection.domain localhost:8080
osb config set connection.protocol http
osb config set connection.api_key <your-api-key>
osb sandbox create --image python:3.12 --timeout 30m -o json
osb command run <sandbox-id> -o raw -- python -c "print(1 + 1)"

pip install opensandbox-mcp
opensandbox-mcp --domain localhost:8080 --protocol http

저장소의 예제 목록에는 Claude Code, Gemini CLI, Codex CLI, Qwen Code, Kimi CLI, DeerFlow 같은 코딩 에이전트를 샌드박스에서 실행하는 예제가 있습니다. Playwright와 Chrome을 쓰는 브라우저 자동화 예제와, 시도마다 샌드박스를 따로 쓰는 Harbor 평가 예제도 있습니다.

운영 환경에 배포할 때는 공식 컨테이너 이미지의 출처도 확인합니다. 릴리스 이미지는 Docker Hub(docker.io/opensandbox/<component>), GitHub Container Registry, Alibaba Cloud Container Registry에 같은 이름으로 올라가고, 태그된 릴리스 이미지는 Cosign 키리스 서명과 출처 증명(provenance attestation)을 함께 제공합니다. README는 운영 환경에서 이미지를 태그가 아닌 다이제스트로 고정하고, 릴리스 검증 가이드에 따라 OpenSandbox GitHub Actions 신원으로 서명을 검증한 뒤 배포하라고 권합니다.

AAIF 안에서 OpenSandbox가 맡는 자리

AAIF가 맡은 프로젝트들을 역할별로 놓고 보면, MCP는 에이전트와 도구를, A2A는 에이전트와 에이전트를, Agent Router와 agentgateway는 에이전트와 모델, 도구 사이의 트래픽을 다룹니다. OpenSandbox는 여기에 에이전트가 작업하는 장소를 다루는 규약을 더합니다. 클라우드 네이티브 쪽에서는 이미 CNCF Landscape의 스케줄링과 오케스트레이션 항목에도 올라 있습니다. 강화 학습 환경 인터페이스인 OpenEnv와도 맞닿아 있는데, OpenSandbox는 BatchSandbox와 Pool 리소스로 평가와 강화 학습용 대량 샌드박스 생성을 지원한다고 밝힙니다.

재단 이관으로 바뀌는 것과 아직 바뀌지 않은 것도 구분해 둘 필요가 있습니다. AAIF 프로젝트 페이지(LFX Insights 기준)는 기여자 581명, 기여 조직 90곳을 보여 주고, 저장소 스타는 10월 22일 기준 약 16,000개입니다. 저장소의 GOVERNANCE.md는 현재 CODEOWNERS 파일을 메인테이너 목록으로 씁니다. 이 문서는 프로젝트가 성장하면 더 공식적인 거버넌스로 바뀔 수 있다고 적고 있습니다. 한편 SDK 패키지 이름은 여전히 @alibaba-group/opensandbox(npm), com.alibaba.opensandbox(Maven), Alibaba.OpenSandbox(NuGet)이고, Go SDK의 모듈 경로도 github.com/alibaba/OpenSandbox/sdks/sandbox/go입니다. AAIF 블로그 글은 Alibaba를 언급하지 않지만, 재단 보도자료는 OpenSandbox를 Alibaba가 기여한 프로젝트로 소개합니다. 이번 발표에는 패키지 이름 변경 계획이 나오지 않으므로, 이름이 바뀌는지는 향후 릴리스 노트에서 확인해야 합니다.

보도자료에 실린 Alibaba 측 발언은 이관 이유를 다음과 같이 설명합니다.

"OpenSandbox는 Alibaba에서 만들어졌지만, 그 미래가 한 회사에 의해 정해지기를 원하지 않습니다. 프로젝트를 AAIF로 가져옴으로써 더 많은 개발자와 조직이 에이전트 생태계 전반에서 샌드박스 환경이 동작하는 방식을 함께 만들어 갈 길을 열고 있습니다." (Xiaobin Xu, Alibaba 개발 인프라 책임자)

"While OpenSandbox was created at Alibaba, we don't want its future to be defined by a single company. By bringing the project to AAIF, we're creating a path for more developers and organizations to help shape how sandbox environments work across the agent ecosystem."

에이전트 샌드박스는 Cloudflare Dynamic Workers, CubeSandbox, NVIDIA OpenShell처럼 구현이 빠르게 늘어나는 분야입니다. OpenSandbox가 재단으로 옮기면서 내세운 것은 개별 구현의 속도보다 그 위에 놓일 공통 규약입니다. AAIF 글은 런타임과 인프라가 바뀌어도 에이전트는 바뀌지 않아야 한다는 생각을 "OpenSandbox의 베팅(bet)" 이라고 부릅니다. 다른 구현들이 이 규약을 따르게 될지는 아직 알 수 없습니다.

여러분은 에이전트 샌드박스를 고를 때 생성 속도와 API 이식성 중 무엇을 더 중요하게 보시나요?

커뮤니티 참여

AAIF 발표 글은 문서와 아키텍처 개요를 읽고, GitHub에서 기여하고, Discord 커뮤니티에 참여하라고 안내합니다. 질문과 설계 논의는 GitHub Issues와 OpenSandbox Discord에서 할 수 있고, 큰 아키텍처나 공개 API 변경은 OSEP(OpenSandbox Enhancement Proposal) 문서로 먼저 제안하는 절차를 따릅니다.

라이선스

OpenSandbox는 Apache License 2.0으로 배포되고 있어, 연구 목적은 물론 상업적 용도로도 자유롭게 사용 및 수정이 가능합니다.

The Sandbox as an Agent Primitive 소개 블로그 (AAIF)

AAIF 신규 프로젝트 4종 발표 보도자료

OpenSandbox 홈페이지

OpenSandbox 아키텍처 문서

OpenSandbox GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임에서 이런 글들을 계속 정리하고 있습니다. 회원 가입으로 주요 글들을 이메일로, 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 새 글 알림을 받아보세요!

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~