Replit 샌드박스 microVM 전환, 공유 커널을 끊은 이유와 500ms 기동 구조

Replit 은 사용자와 AI 에이전트의 코드를 돌리던 Docker 샌드박스를 다시 짰다. 이제 샌드박스마다 자기 리눅스 커널을 갖는 KVM microVM 이 돌고, 이 내용은 2026년 11월 4일 공개됐다. 컨테이너는 호스트 커널을 함께 써서 커널 결함 하나가 다른 고객에게까지 닿을 수 있었다. 이 연결을 끊는 것이 목적이었고, 기동 시간은 웜 풀로 약 500ms 를 지켰다. 따져 볼 팀은 여러 고객의 신뢰할 수 없는 코드를 한 커널 위에서 돌리는 곳뿐이다. 그런 팀도 전환 여부보다 커널을 공유하는지부터 점검하면 된다.

01 공유 커널 하나가 모든 고객의 경계였다

Replit 의 첫 실행 환경은 Google Compute Engine VM 여러 대에 나눠 띄운 Docker 컨테이너였다. 처음에는 상태 없이 코드를 한 번 돌리는 용도였다. 그 위로 영속 작업 공간, 공개 엔드포인트, Nix 패키지 캐시, 리전별 클러스터, 디스크 즉시 포크가 차례로 붙었다. 지금은 사람이 코드를 한 줄도 쓰지 않아도 에이전트가 이 샌드박스에서 앱을 만든다.

Replit 이 걷어 내려 한 문제는 둘이다. 첫째는 격리다. 컨테이너는 호스트 커널을 함께 쓰기 때문에, 커널 결함으로 컨테이너를 빠져나오면 같은 호스트의 다른 워크로드와 자격 증명, 호스트 네트워크까지 손이 닿는다. 원문은 최근 1년 사이 나온 리눅스 로컬 권한 상승(LPE) 결함으로 Copy Fail, Dirty Frag, Fragnesia, DirtyClone, GhostLock 등을 들었다. 자율 에이전트가 원래 범위 밖의 시스템에 닿은 최근 사례들도 배경으로 꼽았다.

둘째는 스토리지다. 호스트 커널 하나가 네트워크 블록 장치 수백 개를 맡는 구조였고, 여기서 예상하지 못한 교착 상태와 노드 장애가 났다.

작업은 아래 순서로 진행됐다. 이 글은 Part 1 이 다룬 격리·커널·네트워크·스토리지·기동만 다룬다. 수만 개 microVM 을 Kubernetes 위에서 조율하는 이야기는 Part 2 몫으로 남겨 두었다.

Replit 은 기존 Docker 런타임을 microVM 위로 옮겨 심는 길도 따져 봤다. 결론은 처음부터 새로 짜는 편이 훨씬 쉽다는 것이었다. 새로 짠 덕분에 운영 중인 시스템을 위험에 빠뜨리지 않고 시제품을 빠르게 돌려 볼 수 있었다고 한다.

02 샌드박스마다 커널 하나, 그 안에서 다시 컨테이너

새 샌드박스는 자기 커널과 꼭 필요한 가상 장치만 갖춘 경량 VM 이다. KVM 이 샌드박스를 호스트와 다른 고객으로부터 떼어 놓는다. VM 안에서는 runc 컨테이너가 개발 환경과 지원 서비스(PostgreSQL, git 백업, 요청 프록시)를 다시 나눈다. 호스트의 감독 프로세스는 VM 기동, 네트워크 설정, 컨테이너 시작을 맡고, 클라이언트가 샌드박스와 주고받는 Replit 의 river 프로토콜 서버도 돌린다.

호스트
 ├─ 감독 프로세스
 │   ├─ microVM 기동(Cloud Hypervisor)
 │   ├─ 샌드박스 네트워크 설정
 │   ├─ vsock gRPC → 게스트 init
 │   └─ river 서버 ← 클라이언트
 ├─ vhost-user 블록 백엔드 → 원격 디스크
 └─ microVM(게스트 커널)
     └─ init → runc 컨테이너
         ├─ 개발 환경
         └─ PostgreSQL·git 백업·프록시

VMM(가상 머신 모니터)은 Cloud Hypervisor 를 골랐다. Rust 로 쓴 오픈소스 VMM 이고 Firecracker 와 rust-vmm 구성 요소를 나눠 쓴다. 프로젝트 README 는 컨테이너·서버리스나 클라이언트 워크로드에 한정되지 않는 범용 클라우드 VMM 을 지향한다고 적었다. Replit 이 꼽은 이유는 기능이다. virtiofs, 투명 대형 페이지, 장치 핫플러그, 라이브 마이그레이션이 되고, 중첩 가상화가 돼서 개발 환경 안에서 다시 VM 을 띄울 수 있다. Replit 은 베어메탈과 가상화 환경 사이에서 스냅샷을 옮길 수 있도록 Cloud Hypervisor 를 직접 고치기도 했다.

호스트는 게스트 안의 최소 init 프로세스와 vsock 위 gRPC 로 통신한다. vsock 은 호스트와 VM 사이의 전용 소켓이라서, 게스트에 IP 네트워크가 없어도 제어 통로가 생긴다.

구성 요소마다 microVM 을 따로 두는 안도 검토했지만 버렸다. 늘어나는 오버헤드에 비해 고객 간 격리 모델은 크게 달라지지 않는다는 판단이었다. 대신 컨테이너마다 네임스페이스, seccomp, 장치 접근, Linux capabilities 를 역할에 맞춰 따로 준다. 사용자 프로세스가 감시 에이전트의 권한을 물려받지 못하게 하려는 것이다. VMM 자체도 capability 가 하나도 없는 비특권 계정으로 돈다.

커널을 따로 가지면서 얻은 것도 있다. Docker 처럼 높은 권한이 필요한 도구도 이제 쓸 수 있다. 공유 커널에서는 안전하게 내줄 수 없던 권한을 게스트 안에서만 주면 되고, 그 권한은 물리 호스트까지 닿지 않는다.

03 게스트 커널은 tinyconfig 에서 시작해 필요한 것만 넣었다

게스트 커널은 배포판 기본 설정이 아니라 tinyconfig 에서 출발한다. 커널 README 가 가능한 한 가장 작은 커널을 만드는 설정 타깃으로 소개하는 그 설정이다. Replit 은 여기서 Bluetooth, 무선, USB, 디스플레이 드라이버를 뺐다. 필요한 드라이버는 커널에 내장하고, 게스트 초기화 때 모듈 적재를 끈다. 커널 빌드 갱신은 Replit 의 에이전트가 돌리는 일 단위 자동화가 맡는다.

Replit 은 이 커널을 Linux 커널 CNA 가 2026년 6월 1일부터 11월 4일 사이 공개한 CVE 와 맞대 본 결과도 실었다.

이 표는 Replit 이 자기 기준으로 잰 값이다. '피했다'의 정의는 업스트림 수정을 빨리 반영했거나 해당 코드를 뺐다는 한 구절뿐이다. 나머지 약 918건이 어느 쪽인지는 나눠 적지 않았고, 피하지 못한 242건을 어떻게 처리했는지도 글에 없다. 그래도 설정에서 뺀 676건은 커널을 깎는 방식이 노출면을 실제로 줄인다는 근거로 볼 수 있다. 원문은 Anthropic 이 원격 root 획득을 시연한 TCP 결함 CVE-2026-98432 의 수정 커널을, CVE 공개 전인 10월 12일에 넣었다고도 밝혔다.

04 막는 장치는 게스트 밖에 둔다

Replit 은 통제 대부분을 VM 밖의 호스트와 VMM 쪽에 뒀다. 원문은 게스트가 호스트 쪽 규칙을 끌 수 없고, 게스트의 네트워크 설정을 바꿔도 VMM 의 속도 제한은 그대로라는 점을 짚는다. 게스트에 Docker 권한까지 주는 구조라면 이렇게 밖에 두는 편이 맞다고 본다. 영역별 장치는 이렇다.

자격 증명 브로커는 호출자가 보낸 인증 헤더를 지우고, 응답의 민감한 헤더도 걸러 낸다. 레지스트리 방화벽이 패키지를 막으면 코딩 에이전트가 그 사실을 알아채고 의존성을 바꾸거나 뺀다. 감시 모니터는 샌드박스마다 호스트 쪽과 게스트 쪽에 하나씩 붙고, 죽거나 변조되면 스스로 복구해 다시 뜬다.

이 구조가 실제로 쓰인 예도 있다. 인증 기관 eMudhra 의 중간 CA 키가 침해됐을 때, Replit 의 샌드박스 하네스는 실행 중인 모든 샌드박스에 갱신한 CA 번들을 자동으로 넣었다. 고객에게 환경마다 손보라고 요청하지 않아도 됐다. 이 사건은 Oracle Java 2026년 10월 취약점, 정기 패치 다음 날 긴급 수정까지에서 다뤘다.

05 약 500ms 는 웜 풀과 원격 디스크가 만든다

샌드박스 하나를 띄우려면 커널을 부팅하고, 이미지를 받고, 컨테이너와 게스트 에이전트를 올려야 한다. 부팅은 작은 커널이 줄이고, 나머지는 웜 풀이 대부분 미리 해 둔다. 요청이 오면 아래 순서로 넘어간다.

1. 웜 풀에서 부팅과 준비를 대부분 마친 VM 을 꺼낸다.
2. 장치 핫플러그로 고객 디스크를 붙이고 마운트한다.
3. 지원 서비스 설정을 병렬로 마친다.
4. 클라이언트에 넘긴다. 1번부터 여기까지 약 500ms 다.

빈 VM 만 부팅하는 시간은 이보다 훨씬 짧다고만 했고, 숫자는 없다. 핫플러그와 메모리 스냅샷이 이 설계에 특히 쓸모 있었다고 적었지만, 스냅샷을 웜 풀에서 구체적으로 어떻게 쓰는지는 설명하지 않았다.

디스크는 원격 블록 스토리지에 있고, 필요한 블록만 그때그때 가져온다. 그래서 큰 작업 공간도 통째로 내려받기 전에 시작할 수 있다. Replit 은 Cloud Hypervisor 옆에서 도는 vhost-user virtio-blk 백엔드를 직접 만들었고, 게스트는 이 백엔드를 거쳐 원격 디스크를 평범한 가상 블록 장치로 본다. 호스트 커널이 블록 장치 수백 개를 떠안던 예전 구조를 걷어 낸 곳도 여기다. 쓰기 시 복사(COW)라서 포크하면 바뀐 블록만 따로 생긴다. Replit 은 이 백엔드를 Claude Sonnet 4 시절 전부 AI 가 쓴 초기 구성 요소로 소개했다. 다섯 번에서 일곱 번을 고쳐 쓴 끝에 동기·비동기 혼합 설계로 정착했다고 한다.

무중단 이전과 바로 이어지는 장치는 스토리지 재연결이다. 배포 중에 진행 중인 I/O 를 마무리하고 디스크를 영속화한 뒤, 게스트를 재시작하지 않고 다시 붙인다. 다만 수억 개 프로젝트를 어떤 순서로 옮겼는지, 두 엔진을 함께 돌렸는지 같은 이전 절차는 Part 1 에 없다. 글이 밝힌 것은 데이터를 잃지 않고 매끄럽게 옮겼다는 결과, 그리고 새 엔진이 몇 달째 운영 중이라는 사실까지다.

06 microVM 도 경계를 옮길 뿐이고 비용 수치는 없다

Hacker News 토론에서는 시각이 갈렸다. 한 참여자는 보안 실무자들이 gVisor 와 Firecracker·Cloud Hypervisor 를 대체로 비슷한 수준으로 본다고 전했다. 갈림길은 하드웨어냐 소프트웨어냐가 아니라 고객끼리 커널을 공유하느냐라는 것이다. 같은 참여자도 gVisor 를 부분적으로 흉내 낸 게스트 커널, 곧 완전하지 않은 해법이라고 불렀다. 다른 참여자는 gVisor 가 커널 수준 문제의 일부만 다룬다며 둘을 같은 것으로 보는 데 반대했다. 공식 문서 기준으로 세 방식을 견주면 이렇다.

gVisor 문서는 Go 로 쓴 응용 커널이 사용자 공간에서 시스템 콜을 받아 처리한다고 설명한다. 자원은 고정된 게스트 물리 자원이 아니라 스레드와 메모리 매핑 단위로 쓴다. 대가로 일부 시스템 콜과 /proc·/sys 파일을 아직 구현하지 않았고, 시스템 콜이 잦은 작업은 느릴 수 있다고 적었다.

microVM 도 끝점은 아니다. Replit 은 게스트 커널이 뚫려도 공격자가 가상화 경계를 한 번 더 넘어야 한다고 썼다. 하지만 그 경계를 지키는 호스트 커널과 VMM 의 공격면은 따로 분석하지 않았다. 2026년 10월에는 KVM·Firecracker 호스트의 virtio-net 경로에 있던 호스트 커널 결함이 알려졌다. 게스트 안의 권한 사용자가 이 결함으로 호스트를 노릴 수 있었다(PwnEscape 리눅스 VM 탈출, 고칠 곳은 게스트가 아닌 호스트 커널). 게스트 root 를 내주는 구조라면 경계를 옮긴 뒤에도 호스트 커널 패치는 계속 해야 한다.

중첩 가상화에도 값이 붙는다. 같은 토론에서 Firecracker 를 제대로 돌리려면 대개 베어메탈 호스트가 필요하고, VM 안에서 다시 VM 을 띄우면 보안 비용이 생긴다는 지적이 나왔다. Firecracker 시작 문서는 EC2 가 .metal 인스턴스에서만 KVM 을 지원해서 그 유형만 쓴다고 적었다. 다만 이 설명은 AWS 의 최근 변화와 어긋난다. AWS 는 2026년 2월 16일 C8i·M8i·R8i 가상 인스턴스에서 KVM 중첩 VM 을 돌릴 수 있게 했고(모든 상용 리전), 6월 18일 C7i·M7i·R7i 같은 인텔 기반 유형으로 넓혔다. 이제 .metal 이 아니어도 시험은 할 수 있지만, 중첩 비용 지적은 그대로 남는다.

비용 쪽은 비어 있다. Replit 은 VM 하나당 메모리, 호스트당 밀도, 전환에 든 인력을 밝히지 않았다. 컨테이너보다 얼마나 더 드는지는 이 글로 판단할 수 없다.

07 고객끼리 커널을 나눠 쓰는 팀만 따져 보면 된다

이 사례가 닿는 곳은 상황에 따라 갈린다.

국내에서 세 번째 줄에 드는 곳은 코딩 교육 플랫폼, 온라인 채점 서비스, 고객 대신 코드를 실행하는 AI 에이전트 SaaS 다. 사용자가 짠 코드든 에이전트가 만든 코드든 다르지 않다. 신뢰할 수 없는 코드를 여러 고객이 한 커널 위에서 돌린다면 Replit 이 걷어 낸 구조와 같다.

그래도 바로 microVM 으로 갈 일은 아니다. 먼저 되돌리기가 어렵다. Replit 도 기존 런타임을 옮기지 않고 새로 짰고, 작업을 시작해 전체 이전 결과를 발표하기까지 1년이 걸렸다. 운영 부담도 새로 생긴다. 게스트 커널을 직접 빌드하고 CVE 를 따라가야 하는데, Replit 은 이 일을 자동화와 에이전트에 맡겼다. Cloud Hypervisor README 는 스냅샷 복원과 라이브 마이그레이션이 다른 버전 사이에서는 보장되지 않는다고 적었다. 그러니 VMM 버전을 고정하고 올리는 절차도 따로 짜야 한다.

작은 팀이라면 순서를 이렇게 잡는 편이 낫다. 컨테이너를 그대로 두고도 줄일 수 있는 노출면을 먼저 막는다. 메타데이터 차단, 아웃바운드 제한, 자격 증명 분리가 여기에 든다. 격리 방식 교체는 하드웨어 가상화를 쓸 수 있는지 확인한 뒤 작은 워크로드로 시험한다. microVM 을 직접 운영할 여력이 없으면 외부 샌드박스 서비스도 후보다. 원문은 업계 예로 Daytona, E2B 등을 들었다. 이때도 고객 간 커널 공유 여부와 데이터가 머무는 리전은 계약 전에 확인한다.

08 점검은 커널 공유 여부와 KVM 사용 가능 여부부터

지금 해 볼 수 있는 점검을 순서대로 적는다.

1. 신뢰할 수 없는 코드가 도는 곳을 적고, 서로 다른 고객의 코드가 같은 커널을 쓰는지 표시한다.
2. 컨테이너를 계속 쓴다면 호스트 커널 패치 주기를 정하고, 컨테이너별 seccomp·capabilities 를 역할에 맞게 줄인다.
3. 샌드박스에서 클라우드 메타데이터 주소와 내부 인프라 대역으로 나가는 길을 막는다. Replit 은 이것을 기본 방화벽으로 뒀다.
4. API 키를 샌드박스 환경 변수로 넣지 말고, 샌드박스 밖에서 키를 붙이는 프록시를 둔다.
5. microVM 을 검토한다면 쓰려는 호스트에서 KVM 을 쓸 수 있는지부터 본다. 아래는 Firecracker 시작 문서에 있는 확인 명령이다.

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"
lsmod | grep kvm

FAIL 이 나오면 원인부터 가린다. kvm 그룹 같은 접근 권한 문제일 수도 있고, 인스턴스 유형이 KVM 을 내주지 않는 것일 수도 있다. EC2 가상 인스턴스라면 중첩 가상화를 지원하는 유형인지, 켜고 띄웠는지도 함께 본다.

앞으로 지켜볼 것도 있다. Replit 은 Part 2 에서 Kubernetes 위 microVM 조율을, 별도 글에서 자동화한 보안 연구와 대응을 다루겠다고 예고했다. 날짜는 밝히지 않았다. 웜 풀 규모와 이전 절차가 어디까지 공개되는지가 작은 팀이 따라 할 수 있는 범위를 가를 것이다.

09 자주 묻는 질문

gVisor 로 바꾸는 것만으로 충분한가

단정하기 어렵다. 고객 간 커널 공유를 끊는다는 점에서 gVisor 를 microVM 과 비슷하게 보는 의견이 있지만, 같은 토론에서 반대 의견도 나왔다. gVisor 문서도 일부 시스템 콜과 /proc·/sys 파일을 아직 구현하지 않았다고 적었으니, 우리 워크로드로 호환성부터 시험해야 한다.

클라우드 VM 안에서 microVM 을 띄울 수 있나

중첩 가상화를 지원하는 인스턴스라면 된다. EC2 도 2026년부터 .metal 이 아닌 일부 인텔 기반 유형에서 KVM 중첩 VM 을 허용한다. 다만 중첩에는 보안 비용이 붙는다는 지적이 있다.

Replit 의 무중단 이전 절차는 공개됐나

아니다. Part 1 은 결과와 스토리지 재연결 장치만 밝혔고, 이전 순서나 두 엔진을 함께 돌렸는지는 적지 않았다.