Vercel Sandbox Docker 지원 공부 정리 | 샌드박스 안에 컨테이너가 들어온다는 것

Vercel changelog에서 Sandbox에 Docker 지원이 들어왔다는 발표를 봤다. 에이전트 관련 기능은 아직 내 공부 범위보다 조금 앞쪽에 있는데, “샌드박스 안에서 컨테이너를 돌린다”는 게 어떤 의미인지 궁금해서 문서를 읽어봤다.

Vercel Sandbox는 에이전트가 코드를 실행하거나 파일을 다룰 때 쓰는 격리된 클라우드 환경으로 쓰인다. 이번 업데이트 전까지는 이 안에서 Docker를 쓸 수 없었는데, 이번에 그 제한이 풀렸다.

1️⃣ 이게 뭐냐?

Docker 지원이 추가됐다는 건, Sandbox 안에서 docker run으로 Redis나 Postgres 같은 서비스를 직접 띄울 수 있다는 얘기인 것 같다. 에이전트가 무언가를 빌드하거나 테스트할 때, 외부 서버를 따로 준비하지 않아도 Sandbox 내부에 의존 서비스를 올릴 수 있다.

문서에서 제시된 사용 시나리오는 세 가지 정도다. 테스트용 Redis나 Postgres를 의존성으로 띄우는 것, 배포 전에 컨테이너 이미지 동작을 검증하는 것, 컨테이너로 서빙되는 앱을 Sandbox 안에서 미리 보는 것. 세 가지 모두 “배포 전에 격리된 공간에서 확인한다”는 흐름으로 이어진다.

이번 업데이트에는 FUSE 파일시스템 드라이버와 VPN 클라이언트 지원도 함께 들어왔다. FUSE는 사용자 공간에서 파일시스템을 구현할 수 있게 해주는 것이고, VPN은 네트워크 터널링이다. Docker와 이 두 가지가 더해지면서 Sandbox 안에서 할 수 있는 일의 종류가 꽤 넓어졌다는 인상을 받았다.

Persistent Sandbox와 연동되면 Docker 설치 상태와 pull한 이미지가 세션 사이에 유지된다고 한다. 새 세션을 열어도 매번 처음부터 설치하지 않아도 된다는 거다.

2️⃣ 내가 든 생각

디자이너 입장에서 Docker나 컨테이너는 아직 낯선 영역이다. “격리된 환경”이라는 말은 이해하는데, 그게 실제 개발 흐름 안에서 어떻게 쓰이는지는 감이 덜 왔다. 이번 발표를 읽으면서 조금 구체화된 부분이 있었다.

👉🏻 가장 흥미로웠던 건 “호스트 시스템에 영향 없이”라는 표현이었다. 에이전트가 Sandbox 안에서 컨테이너를 빌드하거나 패키지를 설치해도 실제 서버에는 흔적이 남지 않는다. 에이전트가 실수하거나 잘못된 명령을 내려도 파급이 Sandbox 안에서 끝난다는 얘기이기도 하다. 격리의 의미가 단순히 환경을 분리하는 게 아니라 위험의 범위를 제한하는 쪽에도 있다는 생각이 들었다.

에이전트가 쓸 수 있는 도구의 범위가 넓어진다는 점도 눈에 들어왔다. 서비스를 직접 띄우고, 동작을 확인하고, 검증까지 Sandbox 안에서 완결되는 루프가 가능해진다면, 에이전트가 다룰 수 있는 작업의 복잡도도 달라질 것 같았다.

💡 여기서 드는 질문? 격리가 가능한 범위가 계속 넓어진다면, 에이전트가 스스로 구성할 수 있는 환경의 복잡도는 어디까지 올라갈까?

⭐️ 마지막으로, 디자이너 관점에서 공부하며 느낀 것

정리해보니, 이번 업데이트는 기능 하나가 추가된 것이라기보다 에이전트가 작업할 수 있는 범위의 경계가 옮겨간 것에 가까운 것 같다. Docker, FUSE, VPN이 하나씩 들어오면서 Sandbox 안에서 완결될 수 있는 작업의 종류 자체가 달라지고 있다는 인상이었다.

컨테이너 개념은 아직 표면적으로만 훑은 상태지만, “격리란 무엇인가”라는 질문에 대한 대답이 이번에 조금 더 구체적으로 와닿았다.

---

참고 원문: Run Docker containers inside Vercel Sandbox