SlicerVM을 적극적으로 사용 중임. 일반 사용자도 Firecracker MicroVM을 쉽게 쓸 수 있게 해주고, 더 복잡한 요구에는 플랫폼도 제공함. 에이전트와 로컬 개발 CI 같은 엣지형 작업을 로컬에서 안전하게 실행하는 데 쓰고 있음. 기존 Proxmox VM 오케스트레이터를 대체했고, 이제 어디서든 노트북에서 안전하고 빠른 VM을 실행할 수 있음. Dockerfile 방식의 빌드도 지원하므로 컨테이너보다 보안을 강화하려는 용도로도 적합함. 에이전트를 쓴다면 이런 보안 강화가 필요함.
다만 Firecracker가 Docker를 대체할 가능성은 보여도, 대부분의 엣지 함수 실행에서 V8 격리 환경(isolate) 까지 대체할 것 같지는 않음. 이 글은 외부 업체의 격리 환경을 사용해 네트워크를 몇 차례 더 거쳤다는 점에서 다소 특수함. JS/TS를 실행하는 격리 환경은 정적 분석이 비교적 쉽고, 대규모로 과거의 결함과 취약점 악용 흔적을 살펴보기에도 좋아 여러 엣지 컴퓨팅 환경에 적합함. MicroVM은 훨씬 유연한 만큼 같은 이점을 얻으려면 사용 가능한 기능을 엄격히 제한해야 함. 중견 기업에는 격리 환경 쪽이 더 유리해 보이지만, Netlify는 규모가 충분히 크고 이 기술에 대한 의존도도 높아 MicroVM 쪽으로 기울 만함.
과거에는 외부 호스팅 실행 서비스로 요청을 보냈고, 지금은 자체 엣지 네트워크의 MicroVM에서 실행해 중앙값 기준 약 5배 빨라졌다고 함. 그렇다면 실행 자체는 오히려 느려졌을 수도 있고, 단지 네트워크 구간 일부를 없앤 것 아닌가? 오해를 부르는 비교임.
Cloudflare Workers도 V8 격리 환경을 사용하는데, Netlify가 기존 환경에서 걸렸다는 25~40ms보다 훨씬 빠르므로 이해하거나 믿기 어려움.
글에 따르면 기존에는 인터넷을 통해 외부로 요청을 보내 엣지 함수를 실행한 뒤 결과를 받아 전달했고, 새 플랫폼에서는 자체 네트워크 안의 연산 노드로 요청을 전달함.
내가 알기로 Cloudflare Workers는 처음부터 Cloudflare 네트워크 안에서 실행됐으며, 인터넷을 거쳐 다른 곳에서 실행하지 않았음. 여기서 외부 실행 장소는 초대형 클라우드 사업자의 환경으로 읽힘.
기존에는 외부 호스팅 실행 서비스로 요청을 보냈다고 하니, 격리 환경이 엣지에서 실행되고 있지 않았던 것임.
다른 조건이 같다면 V8 격리 환경의 지연 시간이 Firecracker보다 짧아야 함. 글에서도 V8 런타임이 외부에 호스팅돼 있어 지연이 발생했다고 밝힘. 반면 Firecracker는 보안 모델이 더 나음.
Cloudflare Workers 플랫폼을 만든 kentonv가 참여한 예전 스레드에서 몇 가지 차이를 다룸. https://news.ycombinator.com/item?id=31740885
다음에 AWS를 욕하고 싶어지면, 최고 수준의 MicroVM 기술 중 하나인 Firecracker를 AWS가 공개했다는 점도 떠올려 주길 바람. AWS 외부의 여러 제품이 이를 기반으로 만들어졌고, 이번 제품도 그 목록에 합류함.
AWS의 기술 자체를 싫어하는 경우는 거의 없다고 봄. 짜증을 유발하는 건 주로 지대 추구와 공급업체 종속임. 원가는 거의 들지 않는 대역폭에 터무니없는 요금을 매기고, 미국 의료보험 청구만큼 불투명한 세분화된 과금으로 푼돈까지 챙기며, 기업 고객을 공격적으로 묶어두는 행태가 해당함. 경영대학원과 YC 창업 교육에서 ‘전환 비용이 높은’ 제품을 만들라고 가르칠 때 소비자, 여기서는 개발자의 이익을 염두에 두는 것은 아님.
또 S3, EC2/Lambda, 로깅·큐 서비스 같은 핵심 제품을 빼면 나머지는 인턴이 출시한 영구 베타 제품처럼 느껴짐. Cloudflare만큼 나쁘지는 않지만 비교 기준 자체가 너무 낮음. LLM 등장 전에는 Cognito 같은 서비스 때문에 개발자들이 끝없이 고생했음. 부실한 문서, 버그 많은 제품, 이해하기 어려운 콘솔 UI 등 불평할 거리가 끊이지 않음. AWS 서비스가 잘 설계됐다면 Vercel이나 Heroku 같은 회사는 존재할 이유가 없었을 것임.
고객을 이렇게 쥐어짜면서도 고위 리더가 아닌 실무 엔지니어에게는 빅테크 중 가장 낮은 수준의 보상을 준다는 점이 더 나쁨. 적어도 Facebook은 그에 걸맞은 보상을 함. Amazon이 아시아의 ‘996’ 문화를 보고 창고 직원에게 통한다면 엔지니어에게도 적용하면 되겠다고 생각한 듯함.
AWS가 Lambda를 위해 MicroVM을 만들었는데도 Lambda의 Node.js는 지연 시간과 처리량 모두 몹시 느리다는 점에서 흥미로움. 원한다면 고생담을 길게 풀 수도 있음. 인증 검증이나 규칙 검사처럼 용도도 크게 다르지 않은 경우가 많으니, AWS도 이런 기술을 활용할 수 있을 듯함.
Netlify가 웜 스타트 15ms에 콜드 스타트 추가 10ms를 달성할 수 있다면, Lambda는 나머지 1,500ms 동안 대체 뭘 하는 건가?
Firecracker는 AWS 기술이며 Lambda와 Fargate를 뒷받침해 왔음. 이런 문제는 그 위에 얹힌 온갖 기업용 부가 기능 때문일 것 같음.
MicroVM이 부팅되고 JavaScript 서버가 포트에서 수신을 시작하면 스냅샷을 찍고, 그 스냅샷으로 새 MicroVM을 시작한다는 대목이 불안함. 난수 생성기 상태가 복제되면 UUID 생성이나 암호화에서 치명적인 문제가 생길 수 있음.