Vercel Sandbox Drives 훑어보면서 든 생각

Vercel 블로그에서 Sandbox에 Drives 기능이 붙었다는 발표가 있었다. 지금은 Private Beta라 대기자 명단을 신청해야 하는 단계인데, 어떤 개념인지 궁금해서 문서를 읽어봤다.

처음에 이름만 봤을 땐 그냥 파일 저장 기능 추가겠거니 했다. 근데 읽다 보니 이게 단순한 스토리지 추가가 아니라, 샌드박스의 “수명(lifecycle)”이라는 개념을 다시 정의하는 느낌이었다.

1️⃣ 이게 뭐냐?

Vercel Sandbox는 코드를 실행할 수 있는 독립된 환경이다. 기존에는 샌드박스를 끄면 그 안의 데이터가 다 사라지는 구조였다. 매번 새로 시작하는 일회용 컨테이너에 가까운 개념이랄까.

Drives는 거기에 별도의 영구 저장소를 붙이는 기능이다. 드라이브를 한 번 만들어 두면, 샌드박스가 꺼진 다음에도 드라이브는 남아있다. 나중에 새 샌드박스를 시작할 때 다시 마운트해서 쓸 수 있다.

const drive = await Drive.getOrCreate({ name: "agent-workspace" });
const sandbox = await Sandbox.create({
  mounts: { "/workspace": { drive: drive.name } }
});

발표에서 제시하는 주요 사용처는 에이전트 워크스페이스 유지, 클론해둔 저장소, 의존성 패키지, 빌드 결과물 같은 것들이다. 한 번 준비해둔 환경을 여러 샌드박스 실행에 걸쳐 계속 이어받아 쓸 수 있게 된다는 게 핵심인 것 같다.

2️⃣ 내가 든 생각

👉🏻 가장 흥미로웠던 건 이게 “에이전트 워크플로우”를 염두에 두고 만든 기능이라는 점이다. 발표에서도 드라이브가 가장 유용한 경우로 에이전트 워크스페이스를 첫 번째로 꼽는다.

에이전트가 어떤 작업을 하다가 샌드박스를 종료하고, 나중에 새 샌드박스를 열어서 전에 하던 작업을 이어받는 흐름 — 지금 이런 식의 AI 에이전트 패턴이 많아지다 보니, 저장 공간의 독립성이 필요해진 거겠구나 싶었다. 실행 환경과 데이터 환경의 생명주기를 분리하는 방향이랄까.

💡 여기서 드는 질문?
샌드박스와 드라이브가 완전히 분리되면, 드라이브는 “어디까지 정리해야 하는” 대상이 되는 걸까. 일회용 컨테이너라면 그냥 끄면 됐는데, 영구 저장소가 생기면 수명 관리라는 새로운 고민이 따라오지 않을까.

Private Beta 중에는 하나의 드라이브를 동시에 하나의 샌드박스만 읽기-쓰기로 마운트할 수 있다는 제약이 있다. 지금 단계에서는 병렬로 여러 에이전트가 같은 드라이브를 공유하는 패턴은 안 된다는 뜻이기도 하다. 이 제약이 나중에 어떻게 변할지가 좀 궁금해졌다.

3️⃣ 앞으로 어떻게 쓸까?

아직 Private Beta라 직접 접근해볼 수 있는 단계가 아니긴 하다. 문서 기준으로 보면 에이전트 기반의 개발 환경에서 “환경 세팅 비용”을 줄이는 데 유용할 것 같다. 매번 의존성을 설치하거나 저장소를 다시 클론하지 않고, 한 번 준비해둔 드라이브를 재사용하는 패턴이다.

디자이너 관점에서도 흥미로운 지점이 있었다. 에이전트가 작업 맥락을 “기억”할 수 있다면, 그 이어받음을 사용자한테 어떻게 보여줄 건지 — 이런 경험 설계 쪽 질문이 자연스럽게 연결된다.

⭐️ 마지막으로, 프론트엔드 공부하면서 든 생각

공부 끝에 남은 건 “실행과 데이터를 분리한다”는 한 줄이다. 드라이브가 생겨서 뭘 더 할 수 있다는 것보다, 기존에 뭉쳐있던 것을 떼어낸다는 발상 자체가 지금 에이전트 인프라가 가는 방향을 보여주는 것 같았다.

---

참고 원문: Drives for Vercel Sandbox in Private Beta