코딩 에이전트를 위한 Vercel Sandbox Drive 실전 가이드

코딩 에이전트 작업 공간을 유지하는 가장 짧은 답

Drive.getOrCreate()로 Drive를 한 번 만들고, Sandbox.create()에 전달할 때 /data처럼 절대 마운트 경로를 지정한 뒤 보존해야 할 파일을 모두 그 경로 안에 두면 됩니다. 다른 Sandbox가 읽기·쓰기 권한을 요청하기 전 첫 번째 Sandbox를 중지해야 합니다. 테스트나 리뷰용 Sandbox를 병렬로 띄울 때는 대신 drive.snapshot()을 마운트합니다. 이 읽기 전용 인스턴스는 고정된 시점의 상태만 보며, 이후의 쓰기 내용은 반영되지 않습니다.

Drive는 한 머신에 내장된 더 큰 디스크라기보다 떼었다 붙일 수 있는 프로젝트 작업실에 가깝습니다. Sandbox는 잠시 머무는 작업자와 공방이고, Drive는 작업자가 떠난 뒤에도 남아 다음 공방에 연결할 수 있는 잠금식 보관실입니다.

Vercel은 Drive의 주요 용도로 에이전트 작업 공간, 디스크 기반 메모리, 의존성 트리, 데이터세트, 모델, 빌드 산출물을 제시합니다. 초기 사용자 중 한 명은 에이전트마다 Drive를 두자 재연결 시 의존성을 다시 설치하지 않아도 됐다고 전했습니다. 확인해야 할 효과는 단순히 저장 공간이 늘어나는지가 아니라 설정 작업이 실제로 줄어드는지입니다.

지속되는 작업 공간 설정하기

먼저 Vercel 프로젝트와 로컬 인증을 준비합니다. Vercel은 로컬 개발에 OIDC 토큰을 권장합니다. vercel env pull을 실행하면 개발용 토큰이 .env.local에 저장되며, 이 토큰은 12시간 후 만료됩니다. 외부 CI 시스템에서는 팀 ID, 프로젝트 ID, 액세스 토큰을 대신 사용할 수 있습니다.

게시 시점의 안정화 npm 릴리스는 @vercel/sandbox 3.5.0입니다. 일부 예전 Vercel SDK 문서에는 여전히 프라이빗 베타라는 설명과 베타 채널 사용 안내가 남아 있지만, 현재 Drive 개념 문서와 9월 23일 출시 공지는 세 요금제 모두에서 퍼블릭 베타가 제공된다고 명시합니다.

npm install @vercel/sandbox@3.5.0
npx vercel link
npx vercel env pull

이제 Drive를 생성해 마운트하고, 상태 표시 파일과 작은 캐시를 기록한 뒤 첫 Sandbox를 중지합니다. 그런 다음 새 Sandbox에서 두 파일을 읽습니다.

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

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

const first = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

await first.runCommand('bash', [
  '-lc',
  "mkdir -p /data/.cache/demo && printf 'ready\\n' > /data/marker.txt && printf 'cached\\n' > /data/.cache/demo/package.txt",
]);
await first.stop();

const next = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

const check = await next.runCommand('bash', [
  '-lc',
  'cat /data/marker.txt /data/.cache/demo/package.txt',
]);
console.log(await check.stdout());
await next.stop();

persistent: false는 예제의 초점을 Drive에 맞추기 위한 설정입니다. persistent Sandbox에는 스냅샷 기반의 자체 재개 방식이 있지만, Drive는 서로 다른 Sandbox 사이를 옮겨 다닐 수 있는 독립 디렉터리로 유지됩니다. 재사용 가능한 기본 환경과 별도로 계속 변경되는 프로젝트 폴더가 모두 필요하다면 두 방식을 함께 사용할 수 있습니다.

반드시 확인해야 할 네 가지 테스트

정상 경로에서는 지속성만 확인할 수 있습니다. 여러 작업이 같은 작업 공간을 건드릴 때 설계가 제대로 작동하는지는 다음 네 가지 테스트로 검증해야 합니다.

1. 새 Sandbox에서도 작업 공간이 남는지 확인하기

상태 표시 파일과 캐시를 모두 /data 아래에 기록하고 쓰기 Sandbox를 중지한 뒤, 같은 Drive를 사용하는 다른 Sandbox를 생성합니다. /data에서 두 파일을 읽습니다. 첫 Sandbox의 다른 위치에 남은 파일은 Drive 지속성을 입증하지 못합니다.

실제 작업을 기준으로 네 가지 시간을 기록해야 합니다. 첫 Sandbox 생성, 최초 의존성 설치, 첫 중지, 그리고 새 Sandbox 생성과 캐시 재사용에 각각 걸린 시간입니다. 핵심 수치는 두 번째 실행에서 줄어든 설정 시간입니다. 파일이 유지되더라도 실제 작업 시간이 단축되지 않았다면 Drive가 편리할 수는 있어도 컴퓨팅 예산을 바꾼 것은 아닙니다.

2. 기존 읽기 Sandbox가 이전 상태에 머무는지 확인하기

초기 상태 표시 파일을 기록하고 쓰기 Sandbox를 중지한 다음, mounts: { '/data': workspace.snapshot() }으로 읽기 Sandbox를 생성해 계속 실행해 둡니다. 다른 Sandbox에서 Drive를 읽기·쓰기 모드로 마운트하고 상태 표시 파일을 교체한 뒤 쓰기 Sandbox를 중지합니다. 기존 읽기 Sandbox의 뷰는 마운트 시점에 고정됐으므로 여전히 원래 값을 반환해야 합니다. 변경된 값을 보려면 새 스냅샷 읽기 Sandbox를 만들어야 합니다.

핵심 개념은 실시간 거울이 아니라 사진입니다. snapshot() 호출은 읽기 전용 마운트를 지정하며, 특정 시점의 뷰는 읽기 Sandbox가 이를 마운트할 때 확정됩니다. 스냅샷을 마운트하기 전에는 Drive에 최소 한 번은 데이터를 써야 합니다. 한 번도 쓰지 않은 Drive는 drive_not_initialized를 반환합니다.

3. 두 번째 쓰기 Sandbox가 거부되는지 확인하기

읽기·쓰기 모드의 Sandbox 하나를 실행한 상태에서 같은 Drive를 사용하는 또 다른 읽기·쓰기 Sandbox를 만들어 봅니다. Vercel은 동시에 하나의 읽기·쓰기 마운트만 허용합니다. 예상된 실패를 무분별한 재시도로 이어가서는 안 됩니다. 쓰기 작업 앞에 리스 또는 대기열을 두고, 소유자를 정상적으로 중지하며, 연결 대상을 확인해야 할 때는 Drive.list()나 currentSandboxName을 사용합니다.

Vercel에서 가져온 문서에는 두 번째 쓰기 Sandbox 상황에 대한 안정적인 오류 코드가 명시되어 있지 않습니다. Sandbox 생성 실패 자체를 계약으로 간주하고, 추측한 코드 문자열에 따라 프로덕션 로직이 분기되지 않도록 해야 합니다.

4. 주 리전이 일치하는지 확인하기

iad1에 Drive를 만든 뒤 주 리전이 sfo1인 Sandbox에 마운트해 봅니다. Vercel 문서에서 이 불일치는 drive_region_mismatch로 정의됩니다. Drive의 리전은 생성 후 바꿀 수 없으며, 동일한 이름에 다른 리전이나 최대 크기를 지정해 getOrCreate()를 호출하면 conflict 오류가 발생합니다.

iad1이 기본값이더라도 두 객체 모두에 리전을 지정하는 편이 안전합니다. 설정을 명시해 두면 나중에 프로젝트 기본값이 바뀌더라도 평범한 재시작이 리전 오류로 변하지 않습니다.

일회성 테스트가 끝나면 모든 쓰기·읽기 Sandbox를 중지하고 Drive.list() 또는 currentSandboxName으로 Drive 연결이 해제됐는지 확인한 다음 await workspace.delete()를 호출합니다. 삭제하면 파일은 영구적으로 사라지며, Sandbox가 연결된 상태에서는 Vercel이 삭제 요청을 거부합니다.

비용은 서로 다른 네 요소로 나뉩니다

Drive 스토리지가 Sandbox 컴퓨팅을 대체하는 것은 아닙니다. 기존 컴퓨팅 과금에 세 가지 스토리지 과금 항목이 추가됩니다. iad1의 현재 공개 요금은 다음과 같습니다.

요금은 리전마다 다릅니다. npm 패키지나 Git 저장소 같은 인터넷 다운로드에는 요금이 없지만, 설치에 사용되는 CPU와 provisioned memory에는 여전히 요금이 부과됩니다. 이 차이 때문에 의존성 캐시가 비용을 줄일 수 있습니다. 다운로드 트래픽이 아니라 반복되는 설정 작업을 없애기 때문입니다.

다음은 벤치마크가 아니라 Pro 또는 Enterprise용 계획 예시입니다. 10 GB 의존성 트리를 한 달 내내 저장하면 $0.50입니다. 전체 트리를 100회 읽으면 논리적 읽기 용량은 1,000 GB, 비용은 $1.50입니다. 10 GB를 한 번 쓰는 비용은 $0.04입니다. 따라서 컴퓨팅, 메모리, 전송, 이후의 쓰기 비용을 제외한 Drive 비용은 $2.04입니다.

Vercel의 요금 예시에서는 iad1에서 100% CPU 사용률로 실행한 5분, 2-vCPU, 4 GB AI 코드 검증 작업의 비용을 약 $0.03으로 계산합니다. Drive가 이 금액 전부를 절감한다고 가정해서는 안 됩니다. 실제로 제거되는 설치 구간을 측정하고, 줄어든 컴퓨팅 비용과 대기 시간을 Drive의 스토리지·읽기·쓰기 비용과 비교해야 합니다.

Hobby에는 Drive 스토리지 15 GB와 월별 읽기·쓰기 각각 30 GB가 포함됩니다. 이와 별도로 개별 Hobby Drive의 기본 최대 용량은 1 GiB입니다. Hobby는 초과 요금을 부과하지 않으며, 할당량을 넘으면 새 Sandbox 생성이 중단됩니다. 유료 요금제에서는 maxSize를 생략할 경우 Drive의 기본 최대 용량이 1 TiB이며, 기본 할당량은 최대 16 TiB까지 설정할 수 있습니다.

효과가 큰 순서로 본 일곱 가지 활용 사례

1. 사용자가 프로젝트에 다시 돌아오는 코딩 에이전트 제품

에이전트 작업 공간마다 Drive를 할당하고, 저장소와 생성 파일, 작업 메모, 패키지 캐시를 마운트 경로 아래에 저장한 뒤 다음 작업에서 새 Sandbox에 연결합니다. 제품 팀은 Sandbox 수명 주기가 끝날 때마다 같은 작업 공간을 다시 만들지 않아도 되고, 사용자는 컴퓨팅을 계속 켜 두지 않고도 작업을 이어갈 수 있습니다.

재시작 횟수와 반복 설정이 누적되기 때문에 가장 효과적인 활용 사례입니다. 쓰기 Sandbox를 하나만 허용하는 규칙도 작업 공간별 활성 에이전트 하나라는 구조와 자연스럽게 맞아떨어지며, 미리보기와 테스트에는 고정된 읽기 Sandbox를 사용할 수 있습니다.

2. 같은 의존성 설치를 반복하는 빌드 팀

통제된 쓰기 Sandbox에서 Drive 하나를 채운 뒤, 후속 작업이 의존성 트리의 읽기 전용 스냅샷을 마운트하도록 합니다. 팀은 반복적인 설치 CPU와 대기 시간을 저장된 사본 하나와 읽기 비용으로 바꿉니다. 의존성 규모가 크고, 작업 실행 빈도보다 변경 빈도가 낮으며, 캐시 경로를 소스 트리와 분리할 수 있을 때 가장 경제적입니다.

3. 멀티 에이전트 리뷰 파이프라인

코디네이터 하나가 후보 저장소를 쓰도록 한 뒤, 보안 리뷰·테스트·린트·문서 검사를 스냅샷 읽기 Sandbox에 분산합니다. 모든 리뷰어는 동일한 시작 상태를 보고 공유 소스를 변경할 수 없습니다. 단, 코디네이터가 나중에 수정한 내용을 리뷰어가 봐야 한다면 새 스냅샷으로 다시 생성해야 합니다.

4. 준비된 데이터세트를 재사용하는 데이터 팀

쓰기 Sandbox 하나로 데이터세트를 다운로드하고 정규화와 인덱싱까지 마친 뒤, 단기 분석 Sandbox에 스냅샷을 마운트합니다. 비용이 큰 준비 과정은 한 번만 수행되고, 동시에 실행되는 읽기 Sandbox는 일관된 입력을 받습니다. 반복 가능한 평가에는 잘 맞지만, 모든 읽기 Sandbox가 즉시 변경하기를 기대하는 실시간 데이터세트에는 적합하지 않습니다.

5. 여러 세션에 걸쳐 파일을 쌓는 리서치 에이전트

인용 자료, 추출한 텍스트, 중간 테이블, 로컬 검색 인덱스를 Drive에 저장합니다. 새 Sandbox는 같은 출처를 다시 수집하고 인덱싱하는 대신 그 폴더에서 작업을 이어갈 수 있습니다. 재현 가능한 작업 자료를 얻는 것이 장점이지만, 별도의 백업이나 출처 추적 체계 없이 파일을 영구적인 진실로 간주해서는 안 됩니다.

6. 간헐적으로 실행하는 작업용 모델 또는 툴체인 캐시

모델 가중치, 컴파일러 등 용량이 큰 입력을 Drive에 미리 채워 두고 작업이 들어올 때만 컴퓨팅을 시작합니다. 첫 캐시 미스 읽기는 Vercel이 영구 스토리지에서 데이터를 가져오므로 더 느릴 수 있지만, 이후 캐시 히트 읽기는 NVMe 속도로 실행됩니다. 유휴 컴퓨팅 비용이 사용 중인 바이트를 저장하는 비용보다 클 때 효과적입니다.

7. 재개 가능한 학생 프로젝트를 제공하는 교육 플랫폼

프로젝트마다 Drive를 배정하고 세션이 시작되면 새 Sandbox에 마운트하며, 세션이 끝나면 연결을 해제합니다. 학생의 파일은 유지하면서 플랫폼은 컴퓨팅 자원을 반납할 수 있습니다. 쓰기 Sandbox 하나만 허용하는 제한은 두 활성 세션이 같은 프로젝트를 동시에 수정하지 못하게 하는 데 도움이 되지만, 제품 자체의 사용자 식별·백업·보존 정책은 여전히 필요합니다.

제품화할 만한 두 가지 아이디어

검색량은 수요 신호일 뿐 매출 전망이 아닙니다. 더 중요한 질문은 이미 해결책을 찾는 집단의 고통스러운 작업을 이 기능이 없애 주는가입니다.

가장 유망한 선택: 에이전트 작업 공간 리스 브로커

에이전트 또는 사용자 프로젝트를 Drive에 매핑하고, 시간이 제한된 쓰기 리스 하나를 부여하며, 테스트와 미리보기용 읽기 Sandbox를 생성하고, 리전·연결·삭제 상태를 보여 주는 작은 컨트롤 플레인을 구축합니다. 코딩 에이전트를 만드는 팀은 스토리지 원시 기능만으로는 쓰기 권한의 소유자를 정할 수 없기 때문에 이런 조정 계층에 비용을 지불할 가능성이 있습니다.

미국 키워드 데이터에서 “ai powered coding agent”의 월간 검색량은 약 8,100회이며 구매 의도를 보입니다. 인접 시장에는 이미 플랫폼 비용을 받아들이는 수요가 있습니다. E2B의 Pro 요금제는 월 $150에 사용량 요금이 추가되고, 며칠간 지속되는 세션은 맞춤형 Enterprise 요금제에서 제공됩니다. 직접적인 가격 비교는 아니지만, 에이전트 인프라를 구매하는 팀이 고려할 만한 예산 기준입니다.

판매 가능한 최소 버전에는 작업 공간별 Drive 매핑, 만료 기능이 있는 쓰기 대기열, 스냅샷 읽기 Sandbox 생성, 사용량 화면, 안전한 정리가 필요합니다. 문제는 방어력입니다. Vercel이나 에이전트 프레임워크가 얇은 래퍼를 흡수할 수 있으므로, 단순히 보기 좋은 getOrCreate() 버튼을 만드는 데 그치지 않고 운영 정책, 감사 이력, 복구, 공급자 간 이식성을 갖춰야 합니다.

클라우드 개발 환경을 위한 웜 스타트 계층

저장소 템플릿, Drive 기반 의존성 경로, 캐시 워머, 명시적인 리전 정책, 설정 전후의 텔레메트리를 하나로 묶어 플랫폼 팀에 제공합니다. 완전한 개발 환경이 아니라 기존 Vercel 환경의 콜드 스타트를 단축하는 제품으로 판매해야 합니다.

미국 키워드 데이터에서 “cloud integrated development environment”의 월간 검색량은 약 1,900회이고 CPC는 $9.03입니다. 이 유료 검색 가치는 공급자들이 해당 고객층을 두고 경쟁하고 있음을 시사합니다. MVP는 좁게 시작할 수 있습니다. Node와 pnpm을 먼저 지원하고, 리전 하나와 캐시 정책 하나를 제공하며, 스토리지·읽기·쓰기·Active CPU·메모리를 구분해 보여 주는 대시보드를 만들면 됩니다.

범위를 주의해야 합니다. Drive가 제공하는 것은 영구 디렉터리 하나입니다. IDE, 비밀 정보 관리, 협업, 이미지 관리, 백업, 리전 간 복제는 제공하지 않습니다. 이 기능만으로 완전한 클라우드 워크스테이션을 약속하면 구매자의 기대를 충족하기 어렵습니다.

설계를 바꿔야 할 제약 사항

• 쓰기 주체와 소유자는 하나뿐입니다. 변경 작업을 직렬화해야 합니다. 스냅샷 읽기 Sandbox는 작업 분산용이지 공동 편집용이 아닙니다.
• 읽기 Sandbox의 상태는 고정됩니다. 실행 중인 읽기 Sandbox에는 이후의 쓰기 내용이 반영되지 않습니다. 새 스냅샷으로 다시 생성해야 합니다.
• 첫 스냅샷 전에 쓰기가 필요합니다. 읽기 Sandbox를 시작하기 전에 Drive를 초기화해야 합니다.
• 주 리전이 일치해야 합니다. Drive는 한 리전에 머물며 이동할 수 없습니다. 리전을 명시적으로 설정해야 합니다.
• Sandbox 하나에는 네 개의 마운트를 연결할 수 있습니다. 각 경로는 절대 경로여야 하며 마운트 경로끼리 겹칠 수 없습니다.
• Drive가 머신 전체를 보존하는 것은 아닙니다. 전체 환경에는 Sandbox 스냅샷을, 독립적으로 변경돼야 할 디렉터리에는 Drive를 사용합니다.
• 콜드 리드는 더 느릴 수 있습니다. 캐시 히트 읽기와 쓰기는 NVMe 속도로 동작하지만, 영구 스토리지 캐시 미스는 그렇지 않습니다.
• 삭제는 되돌릴 수 없습니다. Vercel은 drive.delete()가 영구적이라고 설명합니다. Drive를 유일한 백업으로 삼아서는 안 됩니다.

현재 문서 사이에는 충돌도 있습니다. 9월 23일 출시 공지는 Drive를 마운트한 Sandbox가 장애 조치 리전을 사용할 수 없다고 설명합니다. 반면 9월 22일자 리전 문서에는 장애 조치 시 더 높은 읽기 지연을 감수하고 리전 간에 Drive를 불러올 수 있다고 적혀 있습니다. Vercel이 두 설명을 정리하기 전까지는 아키텍처에서 Drive 장애 조치를 지원되지 않는 기능으로 간주하고, 의존하기 전에 다시 테스트해야 합니다.

작업 한 번에 임시 공간만 더 필요하다면 Drive부터 도입할 이유가 없습니다. 더 큰 임시 디스크를 활용하는 Vercel Sandbox 가이드를 참고하고, 설계에서 지속성을 제외하는 편이 낫습니다.

다음 주 월요일에 바로 해볼 일

다음 주에는 재시작이 잦은 에이전트 워크플로 하나를 고릅니다. 프로젝트 파일과 의존성 캐시만 Drive 하나에 두고 쓰기 Sandbox를 하나로 제한한 뒤, 앞서 설명한 네 가지 테스트를 실행합니다. 적용 전후의 설정 시간과 Drive 스토리지, 읽기, 쓰기, Active CPU, 메모리를 각각 기록합니다. 재시작 단축 효과가 추가 스토리지 비용과 조정 규칙을 감수할 만큼 클 때만 이 패턴을 확대해야 합니다.

지속 가능한 에이전트 작업 공간을 프로덕션 환경에 맞게 설계하고 계측하려면 AI 프로덕션 시스템 구축을 의뢰하세요.