Vercel 코드 샌드박스, 64 GB로 더 큰 에이전트 작업 수용

핵심은 단순히 “64 GB”라는 숫자가 아닙니다. 이전에는 Vercel Sandbox의 32 GB 한계에 걸리던 저장소 작업이 이제 파일을 덜어내거나 작업을 쪼개거나 다른 환경으로 옮기지 않고 코드 샌드박스 한 대에서 끝날 수 있다는 점입니다.

2026년 9월 11일, Vercel은 모든 Sandbox의 기본 작업 저장공간을 32 GB에서 64 GB로 두 배 늘렸습니다.

코드 샌드박스 한 대에 두 배 넓어진 작업 공간

Vercel Sandbox는 자체 커널, 파일 시스템, 네트워크를 갖춘 소형 가상 머신인 격리된 Linux microVM입니다. 저장소를 넣고 에이전트가 코드를 수정하게 한 다음, 패키지를 설치하고 테스트와 빌드를 실행해 결과물을 꺼낼 수 있습니다.

이 모든 단계가 같은 로컬 디스크를 사용합니다. 의존성 트리가 들어온 뒤에도 체크아웃이 남아 있을 수 있고, 빌드 캐시와 컴파일 결과물이 임시 파일과 동시에 존재할 수 있습니다. 완성된 결과물은 작더라도 만드는 도중에는 잠시 훨씬 큰 공간이 필요할 수 있습니다.

이번 릴리스가 바꾼 것은 바로 그 최대 사용량입니다. 이제 Vercel은 Sandbox에 32 GB가 아닌 64 GB의 작업 저장공간을 제공합니다. 기존보다 32 GB 늘어난 두 배 용량입니다. Vercel Managed Image, 커스텀 이미지, 그리고 더 이상 권장되지 않는 runtime 속성으로 만든 Sandbox가 모두 대상입니다.

이는 Sandbox 내부의 용량이 늘어난 것이지 데이터베이스나 오브젝트 스토리지 한도가 새로 생긴 것은 아닙니다. Vercel은 이를 임시 NVMe 스토리지라고 설명합니다. 작업이 끝난 뒤에도 파일을 남겨야 한다면 영속성은 여전히 별도로 결정해야 합니다.

비즈니스 판단의 기준은 작업 하나가 통째로 들어가는가입니다

오래 유효한 질문은 “Vercel의 디스크 한도가 얼마인가?”가 아닙니다. “이 작업 전체를 별도로 덜어내거나 넘겨주는 과정 없이 Sandbox 하나에서 실행할 수 있는가?”입니다.

다음처럼 간단한 작업 공간 예산을 세워보십시오.

최대 작업 공간 = 저장소와 체크아웃 + 설치된 의존성 + 빌드 결과물 + 최대 임시 데이터

작업이 실행되는 동안 최고 사용량을 측정해야 합니다. 최종 zip 파일 크기만 보고 추정해서는 안 됩니다. 패키지 압축 해제, 컴파일, 테스트 픽스처, 브라우저 바이너리, 캐시, 디스크로 넘긴 데이터가 단 몇 분만 겹치더라도 그 순간에 실행 완료 여부가 결정됩니다.

Vercel의 현재 요금 및 할당량은 각 스토리지 계층을 별도의 예산 항목으로 구분합니다.

이 차이를 이해하면 비용 계산도 달라집니다. 작업 디스크가 두 배가 됐다고 컴퓨팅 요율까지 두 배가 되는 것은 아닙니다. Vercel이 제시한 현재 iad1 예시에서는 4 vCPUs와 8 GB 메모리로 빌드 및 테스트를 30분간 실행할 때 CPU를 최대한 사용해도 비용은 약 $0.34입니다.

작업 시간이 길어지거나 CPU와 메모리가 더 필요하다면 큰 작업의 비용은 여전히 늘어날 수 있습니다. 패키지, 저장소, 결과물, 데이터세트 같은 다운로드는 무료지만 Sandbox 밖으로 내보내는 데이터에는 요금이 부과됩니다.

추가 파일이 새로운 스토리지 비용을 만들 수 있는 지점은 영속성입니다. 새로 확보된 32 GB 전체를 사용하고 한 달 동안 보관한다면 요금표 계산상 스냅샷-월마다 32 × $0.08 = $2.56가 듭니다. 이는 예시일 뿐 자동으로 청구되는 비용은 아닙니다. 결과물을 내보낸 뒤 작업 공간을 폐기하는 비영속 실행이라면 이 스냅샷 비용을 피할 수 있습니다.

넓어진 공간이 유용한 사람들

대규모 모노레포를 다루는 스태프 엔지니어

저장소, 의존성 그래프, 빌드 결과물이 기존 한도 안에 함께 들어가지 않아 지금도 패키지를 덜어내고 테스트 픽스처를 지우거나 빌드를 나누는 스태프 엔지니어가 있을 수 있습니다.

측정한 최대 사용량이 현재 제공되는 64 GB 파일 시스템 안에 들어간다면 체크아웃, 설치, 테스트, 빌드를 다시 작업 하나로 합칠 수 있습니다. 인계 과정과 불완전한 결과물이 줄고, 빌드 실패 시 재시도 지점도 하나가 되는 운영상의 이점이 생깁니다.

그렇다고 Vercel이 자동으로 최적의 Sandbox 제공업체가 되는 것은 아닙니다. 실행 계층을 아직 고르는 중이라면 더 폭넓은 AI 에이전트 코드 샌드박스 비교에서 격리와 과금 방식의 장단점을 확인할 수 있습니다. 이번 릴리스가 옮긴 것은 Vercel의 디스크 경계뿐입니다.

저장소 수정 작업을 실행하는 에이전트 플랫폼 엔지니어

코딩 에이전트는 작업하면서 저장공간을 계속 사용합니다. 저장소를 복제하고 툴을 설치한 뒤 파일을 바꾸고 테스트 스위트를 실행해 결과물을 패키징합니다. 여러 접근법을 탐색하는 에이전트라면 캐시와 중간 결과물도 남길 수 있습니다.

추가된 32 GB 덕분에 이 전체 루프가 Sandbox 하나에서 끝날 여유가 커졌습니다. 디스크 부족으로 인한 재시도나 에이전트 워크플로의 별도 정리 툴을 없앨 수도 있습니다. 다만 실제 실패 원인이 디스크였을 때만 효과가 있습니다. 메모리, CPU, 네트워크 정책, 세션 시간 때문에 막힌 작업에는 더 큰 파일 시스템이 도움이 되지 않습니다.

변환 중 디스크로 데이터를 넘기는 데이터 엔지니어

데이터 엔지니어는 내려받은 데이터를 정렬·조인·확장하는 동안 로컬 파일 시스템을 임시 공간으로 쓸 수 있습니다. 디스크가 커지면 작업을 일찍 분할하거나 원격 볼륨을 마운트하지 않고도 임시 처리를 로컬에서 마칠 가능성이 높아집니다.

결과물을 빼낼 계획은 여전히 필요합니다. 보존할 결과를 밖으로 복사하거나 적절한 오브젝트 스토리지에 기록하고, 이후 실행에서도 같은 디렉터리가 필요하다면 Drive를 마운트해야 합니다. 64 GB 임시 디스크의 강점은 필요 없을 때 버릴 수 있다는 데 있습니다. 이를 영구 스토리지처럼 다루면 목적도 비용도 다른 두 작업을 뒤섞게 됩니다.

여전히 runtime을 사용하는 팀

9월 11일 릴리스에는 더 이상 권장되지 않는 runtime 속성으로 구성한 Sandbox도 명시적으로 포함됩니다. 기존 코드는 이미지를 마이그레이션하지 않아도 더 큰 디스크를 받아야 합니다.

다만 현재 플랫폼이 향하는 방향은 여전히 이미지입니다. Sandbox SDK 버전 3부터 runtime과 image를 모두 지정하지 않은 Sandbox는 vercel/sandbox/universal:latest를 사용합니다. 관리형 이미지는 매일 밤 업데이트되며, 재현 가능한 빌드가 중요하다면 다이제스트를 고정해 변경되지 않는 환경을 만들 수 있습니다.

워크플로를 바꾸기 전에 대표 작업 하나를 측정하십시오

이번 릴리스는 기존 한도를 끌어올렸을 뿐, 사용하는 이미지와 작업에 실제로 공간이 얼마나 남는지는 알려주지 않습니다. 정리 단계를 없애거나 나눠둔 빌드를 다시 합치기 전에 실제 작업 하나를 측정해야 합니다.

1. 1

   판단을 입증할 작업을 고릅니다

   최근 디스크 부족으로 실패했거나 기존 한도를 넘지 않기 위해서만 현재 분할 실행하는 작업 하나를 고릅니다. 운영 환경과 같은 저장소, 락파일, 빌드 명령, 입력 데이터를 사용하십시오. 장난감 저장소로는 비즈니스 판단에 필요한 답을 얻을 수 없습니다.

2. 2

   새 이미지 기반 Sandbox를 시작합니다

   현재 CLI와 이미지 경로를 사용하면 결과를 재현하기가 쉽습니다. 아래 순서는 Vercel이 문서화한 Sandbox CLI 흐름을 따르며, 측정 때문에 자동 스냅샷이 생기지 않도록 영속성을 끕니다.

   npm i -g sandbox
   sandbox login
   sandbox create --name workspace-check --image vercel/sandbox/node:24 --timeout 30m --non-persistent
   
   tar -czf app.tgz -C ./my-app .
   sandbox copy ./app.tgz workspace-check:/tmp/app.tgz
   sandbox exec workspace-check -- sh -c "mkdir -p /app && tar -xzf /tmp/app.tgz -C /app"

3. 3

   단계마다 스토리지 사용량을 기록합니다

   체크아웃 후, 의존성 설치 후, 가능하다면 빌드가 가장 무거운 시점, 결과물 완성 후에 각각 디스크를 확인합니다. .next와 dist는 프로젝트에서 실제로 사용하는 출력 경로로 바꾸십시오.

   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm install
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm run build
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'

   df -h /는 Sandbox에 공간이 얼마나 남았는지 보여줍니다. du 명령은 작업 공간의 어느 부분이 용량을 차지하는지 알려줍니다. 빌드가 끝난 뒤에만 확인하면 최대 사용 시점을 놓칠 수 있습니다.

4. 4

   기존 우회책을 빼고 한 번 재시도합니다

   측정한 최고 사용량이 표시된 여유 공간 안에 머문다면 의존성을 덜어내거나 빌드를 나눠 넘기던 기존 절차 없이 같은 작업을 재시도합니다. 성공 여부, 실행 시간, Active CPU, 프로비저닝된 메모리, 전송량, 스냅샷 또는 Drive 스토리지 생성 여부를 기록한 뒤 Sandbox를 중지합니다.

   sandbox stop workspace-check

반드시 알아야 할 한계

디스크가 커져도 메모리, CPU, 시간은 늘어나지 않습니다. Sandbox 세션의 기본값은 여전히 5분입니다. Hobby 세션은 최대 45분, Pro와 Enterprise 세션은 최대 24시간 실행할 수 있습니다.

또한 64 GB 미만인 모든 워크로드가 문제없이 들어간다고 보장하는 릴리스도 아닙니다. 시작 이미지가 파일 시스템의 일부를 차지하고, Vercel이 매일 밤 업데이트를 배포하면 롤링 이미지 태그의 내용도 달라질 수 있습니다. 부팅 후 실제 여유 공간을 확인하십시오. 같은 빌드가 매번 동일한 환경에서 시작해야 한다면 이미지 다이제스트를 고정해야 합니다.

여러 실행에서 공유할 영구 데이터가 필요하다면 Drive나 다른 영속 스토리지를 사용하십시오. Sandbox에 표시된 공간보다 더 큰 작업 공간이 필요하다면 분할 방식을 유지하거나, 대규모 임시 데이터 세트를 마운트된 스토리지로 옮기거나, 다른 환경에서 실행해야 합니다. 새 한도는 선택지의 형태가 아니라 기준선을 바꿉니다.

월요일에 해야 할 일

실제 저장소, 에이전트, 데이터 작업이 기존 디스크 한계에서 실패했거나 오직 그 한계를 피하려고 정리 코드를 두고 있다면 이번 주에 움직일 가치가 있습니다. 최대 사용량을 측정하지 않았다면 기다리십시오. 추측만으로 잘 작동하던 분할 방식을 없애면 다음 실패 시점만 늦출 뿐입니다. 작업이 이미 기존 용량보다 충분히 작거나 실제 병목이 CPU, 메모리, 네트워크 접근, 세션 시간, 영속 스토리지라면 이번 변화의 영향은 없습니다.

월요일에는 대표 작업 하나를 골라 새로운 64 GB 이미지 기반 Sandbox에서 위 측정을 실행하고, 기존 스토리지 우회책 없이 한 번 재시도하십시오. 측정한 실행이 완료되고 컴퓨팅과 영속성을 합친 전체 비용도 합리적일 때만 더 단순한 단일 작업 방식을 유지하면 됩니다.

운영 비용을 실제로 바꾸는 업데이트를 쉬운 언어로 계속 받아보려면 뉴스레터를 구독하십시오.