Vercel은 2026년 5월 26일 Sandbox Persistence가 GA가 되었다고 발표했다. 핵심은 간단하다. Vercel Sandboxes가 세션 사이의 파일 시스템 상태를 자동으로 저장하고 복원한다. persistence는 기본값으로 켜져 있고, 각 sandbox는 프로젝트 안에서 고유하게 참조할 수 있는 이름을 가진다. 개발자는 이름으로 sandbox를 만들고, 다시 가져오고, 이어서 실행할 수 있다.
겉으로 보면 작은 런타임 기능처럼 보인다. 하지만 AI 에이전트 관점에서는 꽤 중요한 변화다. 에이전트 실행 환경이 매번 새로 시작하는 휘발성 컨테이너에서, 작업 상태를 유지하는 개발 런타임으로 이동하고 있기 때문이다.
휘발성 샌드박스의 장점
샌드박스가 매번 깨끗하게 시작하는 구조는 나쁘지 않다. 오히려 운영 관점에서는 장점이 많다.
- 실행 결과가 이전 세션의 오염에 덜 영향을 받는다.
- 재현성이 좋다.
- 민감 파일이 오래 남을 가능성이 줄어든다.
- 실패한 작업을 버리기 쉽다.
- 비용과 리소스 수명을 통제하기 쉽다.
특히 테스트 실행, 일회성 코드 분석, 임시 빌드처럼 입력과 출력이 명확한 작업에는 휘발성 환경이 잘 맞는다. 작업이 끝나면 환경을 버리면 된다. 운영자는 상태를 청소할 필요가 없고, 다음 실행은 다시 깨끗한 기준점에서 시작한다.
문제는 AI 코딩 에이전트의 작업이 항상 그렇게 짧고 깨끗하지 않다는 점이다.
에이전트 작업은 상태를 만든다
AI 에이전트가 실제 개발 업무를 수행하면 자연스럽게 상태가 생긴다.
- 의존성 설치 결과
- 패키지 매니저 캐시
- 빌드 산출물
- 테스트 로그
- 실패한 시도와 수정 내역
- 생성한 임시 스크립트
- 수정 중인 파일
- 도구별 인증/설정 파일
에이전트가 npm install을 매번 다시 실행해야 한다면 비용과 시간이 낭비된다. 대형 저장소에서 테스트 환경을 매번 처음부터 구성해야 한다면 작업 흐름이 끊긴다. 장시간 디버깅 중인 에이전트가 세션 종료와 함께 모든 흔적을 잃는다면, 다음 실행은 같은 탐색을 반복할 가능성이 높다.
그래서 persistence는 단순한 편의 기능이 아니다. 에이전트가 긴 작업을 이어서 수행할 수 있게 만드는 런타임 특성이다.
Vercel이 제공하는 모델
Vercel 발표에 따르면 Sandbox Persistence는 다음 방향을 갖는다.
- 파일 시스템 상태를 세션 사이에 자동 저장하고 복원한다.
- persistence는 기본값으로 켜져 있다.
- sandbox는 durable하고 customizable한 이름을 가진다.
- 이름을 기준으로 sandbox를 create, retrieve, resume할 수 있다.
- Vercel은 세션을 자동으로 올리고 내리면서 작업 흐름을 유지한다.
- 자동 snapshot은 별도 snapshot storage 비용을 발생시킨다.
- 휘발성 작업은
persistent: false또는 CLI의--non-persistent로 opt-out할 수 있다.
이 설계는 서버리스와 개발 VM의 중간 지점에 가깝다. compute는 필요할 때 켜지고 꺼지지만, 파일 시스템 상태는 이어진다. 개발자는 VM처럼 상태를 기대할 수 있고, 플랫폼은 서버리스처럼 실행 수명을 관리한다.
얻는 것: 속도와 연속성
persistence가 켜진 sandbox에서 에이전트는 여러 이점을 얻는다.
1. 의존성 설치 비용 감소
에이전트 개발에서 가장 흔한 낭비는 반복 설치다. Node, Python, Ruby, Java 프로젝트 모두 의존성 설치 시간이 무시할 수 없다. 파일 시스템이 유지되면 같은 sandbox 안에서 패키지 설치 결과를 재사용할 수 있다.
물론 이것이 완전한 빌드 캐시 전략을 대체하지는 않는다. 하지만 에이전트가 같은 작업 맥락에서 여러 번 테스트를 돌리는 상황에서는 체감 차이가 크다.
2. 장시간 작업의 이어하기
에이전트가 기능 구현, 테스트 실패 분석, 리팩터링을 순차적으로 수행한다면 중간 상태가 중요하다. 실패 로그, 임시 분석 스크립트, 수정 중인 파일이 남아 있어야 다음 액션이 자연스럽다.
휘발성 환경에서는 이 상태를 외부 저장소나 별도 로그 시스템으로 계속 밀어내야 한다. persistent sandbox는 그 부담을 줄인다.
3. 이름 기반 작업 공간
durable한 이름으로 sandbox를 다시 찾을 수 있다는 점도 중요하다. 에이전트 업무를 이슈, 브랜치, 사용자, 실험 단위로 나누려면 실행 환경을 식별할 수 있어야 한다.
예를 들면 다음 같은 매핑이 가능하다.
jira-1234-frontend-fixpr-567-reviewincident-2026-05-28-slack-botexperiment-agent-eval-a
이름이 있는 sandbox는 단순 실행 컨테이너보다 작업 공간에 가깝다.
잃는 것: 깨끗함과 단순함
하지만 persistence는 공짜가 아니다. 상태가 생기면 운영 복잡도도 생긴다.
1. 상태 오염
오래 유지되는 파일 시스템은 편리하지만, 이전 실행의 부산물이 다음 실행에 영향을 줄 수 있다.
- 오래된 의존성이 남아 있다.
- 실패한 빌드 산출물이 테스트 결과를 왜곡한다.
- 임시 설정 파일이 실제 설정처럼 사용된다.
- 에이전트가 만든 스크립트가 나중에 의도치 않게 실행된다.
깨끗한 환경에서는 발생하지 않던 문제다. persistent sandbox를 쓴다면 언제 재사용하고 언제 폐기할지 정책이 필요하다.
2. 재현성 저하
상태가 유지되는 환경은 디버깅에는 좋지만, 재현성에는 불리할 수 있다. 어떤 테스트가 통과했을 때 그 이유가 코드 변경 때문인지, sandbox 안의 캐시와 로컬 상태 때문인지 분리하기 어려워진다.
따라서 persistent sandbox에서 작업하더라도 최종 검증은 깨끗한 환경에서 한 번 더 실행하는 편이 안전하다. 특히 배포 전 테스트와 보안 검사는 상태가 남은 개발 sandbox에만 의존하면 안 된다.
3. 보안 경계 확대
파일 시스템이 오래 남으면 민감 정보도 오래 남을 수 있다.
.env파일- API 토큰이 포함된 설정 파일
- 내부 저장소 clone 결과
- 고객 데이터 샘플
- 에이전트가 다운로드한 첨부 파일
에이전트에게 파일 시스템 권한을 준다는 것은 결국 데이터 보존 정책을 설계해야 한다는 뜻이다. 어떤 파일이 저장되고, 누가 접근할 수 있고, 언제 삭제되는지 명확해야 한다.
4. 비용 관리
Vercel 발표는 자동 snapshot이 별도 snapshot storage 비용을 발생시킨다고 설명한다. 이 부분은 실무에서 중요하다. persistence를 기본값으로 켜면 편하지만, 모든 작업이 상태 보존을 필요로 하지는 않는다.
일회성 실행, 짧은 코드 평가, 단순 변환 작업까지 모두 persistent하게 만들면 저장 비용과 관리 대상이 늘어난다. 기본값이 편하다고 해서 모든 워크로드에 맞는 것은 아니다.
에이전트 런타임 설계 기준
AI 에이전트용 sandbox를 설계하거나 선택할 때는 persistence 여부를 단순 옵션으로 보면 안 된다. 작업 유형별로 나눠야 한다.
persistent가 어울리는 작업
- 코딩 에이전트의 기능 구현
- 장시간 디버깅
- 대형 저장소의 반복 테스트
- 의존성 설치 비용이 큰 프로젝트
- 이슈나 PR 단위로 이어지는 작업
- 사용자와 여러 차례 왕복하는 개발 세션
non-persistent가 어울리는 작업
- 신뢰할 수 없는 코드 실행
- 일회성 계산
- 짧은 파일 변환
- 보안 검사 샘플 실행
- 외부 입력을 그대로 실행하는 평가 작업
- 민감 데이터가 포함된 임시 분석
핵심은 기본값보다 정책이다. 어떤 작업은 상태가 있어야 효율적이고, 어떤 작업은 상태가 남으면 위험하다.
운영 체크리스트
persistent sandbox를 에이전트 업무에 도입한다면 최소한 다음을 확인해야 한다.
- sandbox 이름 규칙이 있는가?
- 작업 종료 후 sandbox를 보존할지 삭제할지 기준이 있는가?
- 오래된 sandbox를 자동 정리하는 TTL이 있는가?
- 민감 파일 경로를 탐지하거나 차단하는가?
- 최종 테스트를 깨끗한 환경에서 다시 실행하는가?
- snapshot storage 비용을 모니터링하는가?
- 사용자가 sandbox 상태를 확인하고 초기화할 수 있는가?
- 에이전트가 만든 파일과 사용자가 만든 파일을 구분할 수 있는가?
- 감사 로그가 tool call뿐 아니라 파일 변경까지 포함하는가?
- persistence opt-out을 위험 작업의 기본값으로 둘 수 있는가?
이 목록이 없다면 persistent sandbox는 생산성 향상보다 디버깅하기 어려운 상태 저장소가 될 수 있다.
서버리스와 개발 VM 사이
Vercel Sandbox Persistence가 흥미로운 이유는 실행 환경의 경계를 흐리기 때문이다.
서버리스는 짧고 stateless한 실행에 강하다. 개발 VM은 오래 유지되는 상태와 상호작용에 강하다. AI 에이전트는 둘 다 필요하다. 코드를 실행할 때는 서버리스처럼 격리되고 자동으로 관리되어야 하지만, 개발 작업을 이어갈 때는 VM처럼 상태가 남아 있어야 한다.
이 중간 영역이 앞으로 에이전트 런타임의 중요한 경쟁 지점이 될 가능성이 높다. 모델 성능이 비슷해질수록 차이는 실행 환경에서 난다.
- 얼마나 빨리 시작하는가?
- 얼마나 안전하게 격리하는가?
- 상태를 얼마나 잘 보존하는가?
- 비용을 얼마나 예측 가능하게 만드는가?
- 실패한 에이전트 작업을 얼마나 쉽게 조사할 수 있는가?
에이전트 플랫폼은 단순히 모델 API를 감싸는 레이어가 아니다. 실행 환경, 파일 시스템, 네트워크, 권한, 로그, 비용 관리까지 포함하는 운영 플랫폼이다.
결론
Vercel Sandbox Persistence GA는 작은 기능 발표처럼 보이지만, AI 에이전트 인프라 관점에서는 중요한 신호다. 에이전트가 실제 개발 업무를 맡으려면 상태가 필요하다. 의존성을 설치하고, 실패 로그를 남기고, 작업 중인 파일을 이어서 수정해야 한다.
하지만 상태는 항상 양날의 검이다. 속도와 연속성을 주는 대신 오염, 보안, 비용, 재현성 문제를 만든다. 그래서 좋은 에이전트 런타임은 persistence를 제공하는 것에서 끝나지 않는다. 언제 상태를 보존하고, 언제 버릴지 결정할 수 있어야 한다.
앞으로 AI 코딩 에이전트의 품질은 모델 답변만으로 평가되지 않을 것이다. 같은 모델이라도 어떤 sandbox에서 실행되는지에 따라 실제 생산성은 크게 달라진다. 에이전트는 생각만 하는 도구가 아니라 코드를 실행하고 파일을 바꾸는 작업자다. 작업자에게는 기억할 공간도 필요하지만, 깨끗하게 초기화할 수 있는 공간도 필요하다.
참고
- Vercel Changelog, 2026-05-26: “Sandbox persistence is now GA”