Vercel Sandbox Drives: 에이전트 워크스페이스가 영속 인프라가 되는 순간
AI 코딩 에이전트의 병목은 더 이상 “코드를 쓸 수 있느냐”만이 아닙니다. 실제 팀에서 더 자주 부딪히는 문제는 작업 상태입니다. 에이전트가 새 샌드박스에서 다시 저장소를 clone하고, 의존성을 설치하고, 이전 실행에서 만든 임시 산출물을 잃어버리면 자동화는 빠르게 보이지만 운영은 느려집니다.
Vercel이 2026년 6월 5일 공개한 Vercel Sandbox Drives private beta는 이 지점을 직접 겨냥합니다. 드라이브는 샌드박스와 독립된 생명주기를 가진 영속 스토리지이며, 새 Sandbox를 만들 때 원하는 경로에 mount할 수 있습니다. 샌드박스는 버리고, 워크스페이스는 이어받는 구조입니다.
무슨 일이 있었나
Vercel 발표에 따르면 Sandbox Drives는 @vercel/sandbox@beta 또는 beta CLI에서 사용할 수 있고, Drive.getOrCreate()로 만든 드라이브를 Sandbox.create()의 mounts 옵션에 연결하는 방식입니다. 예시는 /workspace 경로에 read-write 모드로 붙이는 형태를 보여줍니다.
공식 설명에서 제시한 사용처는 명확합니다. 일회용 샌드박스 사이에서 에이전트 워크스페이스를 유지하고, cloned repository, dependency, build output을 남기며, 데이터를 샌드박스 생명주기와 독립적으로 관리하는 것입니다. 다만 private beta 단계에서는 하나의 드라이브를 동시에 read-write로 mount할 수 있는 Sandbox가 하나뿐이고, production data 저장소로 쓰지 말라는 제한도 함께 붙었습니다.
왜 개발팀에 중요한가
에이전트 기반 개발은 작업 단위가 길어지고 있습니다. GitHub Copilot app은 agent-native desktop 경험에서 custom agent skills, MCP server connection, configurable Actions workflow를 강조했고, OpenAI Codex 역시 plugins, Sites, annotations처럼 팀 도구와 연결되는 흐름을 넓히고 있습니다. 이런 방향에서는 에이전트가 “한 번 답변하고 끝나는 도구”가 아니라, 여러 단계의 작업을 수행하는 실행자에 가까워집니다.
그런데 실행자가 파일 시스템을 다룰수록 상태 관리가 제품 품질이 됩니다. 의존성 캐시가 사라지면 비용과 대기 시간이 늘고, build output이 사라지면 검증을 반복해야 하며, 이전 실행 로그가 흩어지면 리뷰가 어려워집니다. Drives는 이 문제를 “샌드박스를 오래 살린다”가 아니라 “상태를 별도 리소스로 분리한다”는 방식으로 풀려는 시도입니다.
커뮤니티 신호
이번 발표 전에도 Vercel Community에는 sandbox-volume처럼 Sandbox 파일을 Vercel Blob 등 외부 저장소에 동기화해 workspace continuity를 만들려는 실험이 올라왔습니다. Reddit과 커뮤니티 글에서도 개발자들이 샌드박스 자체보다 “작업 상태가 다음 실행까지 살아남는가”, “의존성·산출물·dirty files를 어떻게 보존하는가”를 묻는 흐름이 보였습니다. 이는 공식 기능이 생긴 배경을 설명하는 신호로 볼 수 있지만, 기능의 실제 보장 범위는 Vercel 공식 문서와 beta 제한을 기준으로 봐야 합니다.
운영 영향
- 에이전트 플랫폼: 사용자별 또는 작업별 드라이브를 두면 agent task가 재시작되어도 저장소와 중간 산출물을 이어받을 수 있습니다.
- CI 보조 워크플로: 반복 설치와 빌드 준비를 줄일 수 있지만, 캐시 무효화 정책을 설계하지 않으면 오래된 dependency가 테스트를 오염시킬 수 있습니다.
- 보안: 영속 스토리지는 편리하지만, 토큰·쿠키·고객 데이터가 남으면 사고 표면도 영속화됩니다. networkPolicy, secret injection, cleanup job을 함께 설계해야 합니다.
- 비용: 일회용 실행과 영속 저장을 분리하면 compute 시간을 줄일 가능성이 있지만, storage lifecycle과 stale workspace 정리 비용을 새로 관리해야 합니다.
지금 해볼 체크리스트
- 드라이브 단위를
user,repository,task중 어디에 둘지 정한다. /workspace에는 소스, lockfile, build output만 두고 secrets는 환경 변수나 별도 secret broker로 주입한다.- agent run이 끝날 때
git status, test result, generated artifact manifest를 남긴다. - beta 제한상 read-write writer를 하나로 가정하고, 병렬 agent에는 작업별 drive 또는 read-only 복제 전략을 둔다.
- 오래된 dependency cache와 실패한 build artifact를 지우는 TTL 정책을 만든다.
- production data는 넣지 않는다. 공식 발표가 private beta에서 이를 명시적으로 제한하고 있다.
반론과 리스크
Drives가 모든 팀에 즉시 필요한 것은 아닙니다. 단발성 코드 실행, 짧은 lint/test, 재현 가능한 clean-room 검증은 여전히 ephemeral Sandbox가 더 단순합니다. 또한 snapshot, automatic persistence, drive는 비슷해 보이지만 운영 의미가 다릅니다. snapshot은 특정 시점의 파일 시스템 복원에 가깝고, drive는 워크스페이스를 장기 리소스로 다루는 모델입니다. 어떤 상태를 재사용해야 하는지 먼저 정하지 않으면 “빠른 에이전트”가 아니라 “오염된 에이전트”가 됩니다.
결론은 단순합니다. 에이전트를 제품에 넣는 팀이라면 이제 prompt와 model만 고를 수 없습니다. sandbox, drive, secret boundary, audit trail, cleanup policy까지 하나의 런타임 설계로 봐야 합니다. Vercel Sandbox Drives는 그 설계에서 영속 워크스페이스를 1급 리소스로 끌어올리는 신호입니다.