Vercel Sandbox Drives 베타, 사라지는 VM 밖의 작업 폴더

Vercel이 2026년 6월 5일 Sandbox Drives private beta를 공개했습니다. 발표문은 길지 않습니다. Drive를 한 번 만들고, 새 sandbox를 시작할 때 원하는 경로에 mount하며, sandbox가 멈춘 뒤에도 drive를 보존한다는 내용입니다. 그러나 AI 에이전트 관점에서는 작은 storage 옵션보다 큰 실행 모델 변화입니다. 일회용 Firecracker microVM은 계속 사라지지만, agent가 작업하던 repo와 dependency와 build output은 별도 생명주기로 남길 수 있기 때문입니다.

Vercel Sandbox는 공식 문서에서 untrusted code, user-generated code, AI agent output을 안전하게 실행하기 위한 ephemeral compute primitive로 설명됩니다. 문서는 sandbox가 Firecracker microVM 안에서 실행되고, 각 sandbox가 자체 filesystem과 network를 가진다고 적습니다. 이 격리는 AI coding agent, UI builder, code playground에는 필요한 조건입니다. 사용자가 만든 코드를 production system과 같은 process 또는 filesystem에서 실행할 수는 없습니다.

문제는 격리가 비용을 동반한다는 점입니다. agent가 매번 깨끗한 sandbox에서 시작하면 repository clone, package manager install, browser dependency 설치, test fixture 생성, build cache 재생성이 반복됩니다. 짧은 코드 실행에는 acceptable한 비용일 수 있지만, monorepo를 열고 여러 test와 preview server를 돌리는 agent workflow에서는 대기 시간과 compute cost가 누적됩니다. Drives는 이 반복 작업 중 일부를 sandbox 밖으로 빼는 기능입니다.

발표문이 제시한 API 모양은 단순합니다. Drive.getOrCreate({ name: "agent-workspace" })로 drive를 만들고, Sandbox.create()에서 mounts에 /workspace 경로를 지정합니다. mount mode는 예시 기준 read-write입니다. Vercel은 Drives의 사용처를 disposable sandbox 사이에서 agent workspace 유지, cloned repositories와 dependencies와 build outputs 보존, sandbox lifecycle과 data lifecycle 분리로 요약했습니다.

import { Drive, Sandbox } from '@vercel/sandbox';

const drive = await Drive.getOrCreate({
  name: 'agent-workspace',
});

const sandbox = await Sandbox.create({
  mounts: {
    '/workspace': {
      drive: drive.name,
      mode: 'read-write',
    },
  },
});

이 코드는 storage API라기보다 agent runtime의 경계 선언에 가깝습니다. sandbox는 task execution boundary이고, drive는 workspace boundary입니다. 사람 개발자에게 local working directory가 있듯이 agent도 작업 폴더가 필요합니다. 차이는 그 작업 폴더가 신뢰할 수 없는 코드 실행 환경과 같은 생명주기를 가져야 하는지입니다. Drives는 둘을 분리합니다.

기존 Vercel Sandbox 문서에도 Snapshotting이 있습니다. snapshot은 실행 중인 sandbox 상태를 저장해 dependency installation을 건너뛰는 용도로 설명됩니다. Drives와 snapshot은 같은 문제를 다른 단위로 봅니다. snapshot은 sandbox image 또는 filesystem state를 재사용하는 접근에 가깝고, Drive는 named storage를 sandbox 시작 시 mount하는 접근입니다. 에이전트 제품을 설계하는 팀에는 이 차이가 큽니다. base environment는 snapshot으로 줄이고, repository workspace는 Drive로 분리하는 식의 조합이 가능해집니다.

Vercel 문서의 시스템 사양도 운영자가 봐야 할 부분입니다. Sandbox는 Amazon Linux 2023 위에서 node24, node22, python3.13 runtime을 지원하고, 기본 runtime은 node24입니다. 실행 사용자는 vercel-sandbox이며 sudo access와 기본 작업 디렉터리 /vercel/sandbox를 갖습니다. 이 환경은 web app builder와 JavaScript/Python agent workload에는 맞지만, 모든 system dependency가 자동으로 들어있다는 뜻은 아닙니다. agent가 Playwright, native package, language runtime을 설치한다면 Drive에 남길 데이터와 snapshot에 넣을 dependency를 구분해야 합니다.

인증 경로도 Vercel답게 project boundary에 붙습니다. 문서는 Vercel OIDC token을 권장하고, local development에서는 vercel link와 vercel env pull로 development token을 얻으며, Vercel production에서는 인증이 자동이라고 안내합니다. 외부 CI/CD나 non-Vercel environment에서는 access token을 쓰는 방식이 남습니다. Drive가 작업공간을 오래 보존하는 기능이기 때문에 token scope, project boundary, team policy는 sandbox 생성 권한만큼 중요해집니다.

이번 발표가 AI agent 인프라 시장에서 보이는 위치는 분명합니다. 2026년 들어 agent runtime은 모델 호출보다 실행 표면 쪽으로 경쟁하고 있습니다. Google Gemini API Managed Agents는 Google-hosted isolated Linux sandbox를 내세웠고, Microsoft MXC는 OS별 containment backend를 문서화했습니다. CoreWeave와 Modal은 sandbox를 RL, evaluation, code execution primitive로 포지셔닝합니다. Vercel은 web deployment, AI SDK, AI Gateway, Sandbox를 한 surface로 묶습니다. Drives는 그 surface에서 "agent가 실제 repo를 오래 들고 있는가"라는 질문에 답합니다.

OpenAI Agents SDK 문서도 이 시장의 연결 방식을 보여줍니다. VercelSandboxClient는 @openai/agents-extensions/sandbox/vercel 경로와 @vercel/sandbox peer dependency로 문서화되어 있습니다. 같은 표에는 E2B, Modal, Runloop, Cloudflare sandbox client도 나옵니다. agent framework가 sandbox provider를 plug-in처럼 바꿀 수 있다면, provider 경쟁은 isolation뿐 아니라 mount strategy, startup time, persistent workspace, logs, network policy, cost model로 갈립니다.

개발팀이 바로 기대할 수 있는 이득은 세 가지입니다. 첫째, agent task 재시작 비용이 줄어듭니다. repo clone과 package install을 Drive에 남기면 새 sandbox를 띄운 뒤 같은 workspace를 다시 붙일 수 있습니다. 둘째, long-running 작업을 여러 execution window로 나누기 쉬워집니다. sandbox timeout이나 실패 때문에 VM을 버려도 작업 폴더를 이어받을 수 있습니다. 셋째, build output과 test artifact를 agent가 다음 단계의 근거로 삼을 수 있습니다. 에이전트가 실패 로그를 보고 수정하는 loop에서는 artifact 지속성이 품질에 직접 연결됩니다.

하지만 이번 beta를 production storage처럼 읽으면 안 됩니다. Vercel은 private beta 동안 drive를 read-write로 mount할 수 있는 sandbox가 한 번에 하나라고 명시했습니다. parallel agent sessions가 같은 workspace를 동시에 수정하는 구조라면 이 제한이 설계에 걸립니다. 예를 들어 한 agent가 migration을 만들고 다른 agent가 UI를 수정하는 식의 병렬 작업은 drive 단위 lock, branch 분리, read-only clone, artifact export 정책을 따로 가져야 합니다.

Vercel은 또 Sandbox Drives를 private beta 동안 production data에 쓰지 말라고 적었습니다. 이 문장은 기능 제한이라기보다 책임 경계입니다. agent workspace에는 repository, .env sample, generated code, logs, dependency cache, test data가 들어갈 수 있습니다. production database dump나 customer PII를 그대로 mount하면 sandbox isolation과 storage lifecycle을 한꺼번에 감사해야 합니다. beta 단계에서는 synthetic fixture, open-source repo, 내부 non-sensitive code path부터 검증하는 편이 안전합니다.

비용 모델도 아직 사용자가 검증해야 할 영역입니다. 발표문은 dependency와 build output 보존을 강조하지만, storage size, retention policy, cleanup automation, quota, team-level visibility가 실제 운영비를 좌우합니다. agent가 매번 node_modules, browser cache, build artifact를 남기면 startup은 빨라질 수 있지만 storage가 빠르게 커집니다. Drive 이름을 task별로 만들지 repo별로 만들지, branch별로 분리할지, TTL cleanup을 어디서 실행할지도 제품 설계 질문입니다.

보안팀은 Drives를 sandbox escape 방어와 별개로 봐야 합니다. Firecracker microVM isolation은 process와 kernel boundary의 문제입니다. Drive는 data persistence와 sharing boundary의 문제입니다. 공격자가 sandbox 안에서 악성 dependency를 설치하거나 generated file을 남기면, 다음 sandbox가 같은 Drive를 mount할 때 그 상태를 이어받을 수 있습니다. 따라서 workspace reuse에는 dependency integrity check, lockfile review, cache poisoning 방어, post-task cleanup 같은 절차가 필요합니다.

이 지점은 GitHub Actions cache poisoning이나 package lifecycle script 사고와 같은 공급망 문제와 닮았습니다. 캐시는 속도를 높이지만 신뢰 경계를 흐립니다. AI agent workspace도 같습니다. agent가 만든 파일을 다음 agent가 "기존 상태"로 받아들이면, 편의성과 위험이 함께 이동합니다. Drive는 작업 연속성을 주지만, 운영자는 어떤 상태가 오래 살아도 되는지 정해야 합니다.

제품 관점에서 Drives는 v0 같은 AI app builder에도 직접 연결됩니다. Vercel Community에는 2026년 2월 v0의 sandbox-based runtime이 기존 GitHub repo와 Vercel project를 어떻게 연결하는지 묻는 글이 올라왔습니다. 이런 질문은 단순 import UX 문제가 아닙니다. agent가 existing codebase를 다루려면 repo state, environment configuration, preview build, branch output을 반복 가능한 workspace로 유지해야 합니다. Drives는 그 하부 primitive 중 하나가 될 수 있습니다.

다만 발표 자체는 아직 매우 초기입니다. 확인 시점에 Hacker News와 Reddit에서 Drives for Vercel Sandbox만을 다루는 큰 독립 토론은 찾기 어려웠습니다. 커뮤니티 검증이 약한 이유는 private beta 접근성, 짧은 changelog, 실제 quota와 pricing 경험 부족 때문일 가능성이 높습니다. dev team이 평가하려면 공식 예제만 보는 대신, repo size 1GB, dependency install 10분, Playwright cache, parallel session 같은 자기 workload를 넣어 봐야 합니다.

경쟁사와 비교하면 Vercel의 차별점은 web app 배포 표면과 agent runtime이 가까이 있다는 데 있습니다. GitHub Copilot app은 issue, PR, worktree, review flow에 강합니다. E2B와 Modal은 sandbox primitive와 execution API에 집중합니다. Cloudflare는 Workers, Durable Objects, Browser Run, network edge를 agent infrastructure로 엮습니다. Vercel은 Next.js, deployment preview, v0, AI SDK, AI Gateway를 같은 개발자 workflow 안에 둡니다. Drives는 이 묶음에서 "생성된 앱이 다음 prompt까지 살아남는가"를 담당합니다.

도입 판단은 화려한 agent demo보다 운영 체크리스트로 해야 합니다. 첫째, Drive에 들어갈 데이터 등급을 정합니다. 둘째, read-write one-sandbox limit이 team workflow와 맞는지 확인합니다. 셋째, Drive cleanup과 quota 알림을 준비합니다. 넷째, sandbox 재시작 후 artifact를 신뢰하기 전에 test와 dependency verification을 다시 돌립니다. 다섯째, OpenAI Agents SDK나 자체 agent harness에서 Vercel Sandbox provider를 쓸 때 mount path와 credential 전달 방식을 명시합니다.

Vercel changelog의 짧은 코드 예시는 그래서 product preview보다 운영 contract에 가깝습니다. Drive.getOrCreate, mounts, mode: 'read-write' 세 필드가 agent workspace의 이름, 연결 지점, 동시 쓰기 정책을 드러냅니다.

이번 뉴스의 실제 의미는 "Vercel이 storage 기능을 하나 더 넣었다"가 아닙니다. AI 에이전트가 코드를 만들고 실행하고 검증하는 과정에서 compute와 workspace가 분리된다는 점입니다. disposable microVM은 보안과 isolation을 담당하고, persistent drive는 작업 연속성과 비용 절감을 담당합니다. 이 둘을 같은 것으로 취급하면 느리거나 위험한 agent runtime이 됩니다. Vercel Sandbox Drives는 아직 beta이지만, agent infrastructure가 앞으로 어떤 단위로 쪼개질지를 꽤 선명하게 보여주는 발표입니다.

출처

• Vercel Changelog, Drives for Vercel Sandbox in Private Beta.
• Vercel Docs, Vercel Sandbox.
• Vercel Docs, Sandbox SDK Reference.
• OpenAI Agents SDK, Sandbox clients.