AWS 람다가 'MicroVM'을 열었다 — AI가 짠 코드를 안전하게 굴릴 샌드박스의 새 기준

무슨 일이냐면

AWS가 람다(Lambda)에 'MicroVM(마이크로 VM)'이라는 기능을 새로 내놨어요. 한 줄로 말하면, 격리된 작은 가상 컴퓨터를 코드로 만들고-멈추고-재개하고-없애는 전체 생애주기(lifecycle)를 개발자가 직접 제어할 수 있게 된 거예요.

배경부터 짚을게요. 람다가 뭐냐면, 서버를 직접 띄우지 않고 함수 하나만 올려두면 요청이 올 때마다 알아서 실행되고 끝나는 서버리스 서비스예요. 편하긴 한데, 원래 람다는 '한 번 호출되면 잠깐 실행하고 종료'가 기본이라, 상태를 길게 들고 있거나 내가 원하는 순간에 멈췄다 다시 켜는 세밀한 제어는 안 됐어요. 이번 MicroVM은 바로 그 한계를 풀어준 거예요.

핵심: Firecracker와 단단한 격리

사실 람다는 처음부터 'Firecracker(파이어크래커)'라는 마이크로VM 기술 위에서 돌아갔어요. Firecracker는 AWS가 만든 초경량 가상화 기술인데, 일반 가상머신(VM)이 부팅에 수십 초 걸리는 것과 달리 100밀리초 안팎이면 새 가상 컴퓨터 하나를 띄워요. 그러면서도 각 인스턴스가 커널 수준에서 완전히 분리돼서, 한 샌드박스 안에서 무슨 짓을 해도 옆 샌드박스나 호스트 서버엔 손을 못 대요.

여기서 컨테이너(도커)와 비교하면 이해가 빨라요. 컨테이너는 같은 운영체제 커널을 여러 개가 나눠 쓰는 구조라 가볍지만, 커널에 구멍이 뚫리면 격리가 무너질 위험이 있어요. 반면 마이크로VM은 각자 별도의 미니 커널을 갖는 진짜 '가상 컴퓨터'라 격리 벽이 훨씬 두껍죠. 이번 발표의 핵심은 이 Firecracker의 힘을 개발자 손에 직접 쥐여줬다는 거예요. 샌드박스를 프로그램으로 생성하고, 작업이 없을 땐 일시정지(pause)해서 비용과 메모리를 아끼고, 필요하면 그 상태 그대로 재개(resume)하는 게 가능해졌어요.

왜 지금 이게 중요하냐면

이 기능이 딱 맞아떨어지는 분야가 바로 'AI 에이전트'예요. 요즘 LLM은 코드를 직접 짜서 실행해보고 결과를 확인하잖아요. 그런데 AI가 생성한 코드는 신뢰할 수 없는(untrusted) 코드라, 그냥 우리 서버에서 돌리면 큰일 나요. 무한루프를 돌릴 수도, 시스템 파일을 건드릴 수도 있으니까요. 그래서 'AI가 만든 코드는 격리된 샌드박스 안에서만 실행'하는 게 정석인데, MicroVM이 바로 그 격리된 일회용 실행 공간을 빠르고 안전하게 제공해주는 거예요. 사용자별로 격리된 작업 공간을 띄우는 코드 인터프리터 서비스에도 잘 맞고요.

업계 맥락

사실 이 'AI 코드 실행용 샌드박스' 시장은 이미 뜨거워요. E2B, Modal, Daytona 같은 스타트업이 'AI 에이전트를 위한 안전한 실행 환경'을 내세워 빠르게 자리를 잡았고, 클라우드플레어도 Sandboxes를 내놨어요. 구글이 만든 gVisor(컨테이너에 보안 격리를 덧씌우는 기술)도 비슷한 문제를 푸는 도구고요. AWS가 람다에 MicroVM을 직접 붙였다는 건, 이 스타트업들이 개척한 영역을 거대 클라우드가 표준 기능으로 흡수하기 시작했다는 신호예요. 인프라를 따로 옮기지 않고 이미 쓰던 AWS 안에서 해결할 수 있다는 게 큰 무기죠.

한국 개발자에게는

AI 에이전트나 'AI가 코드를 짜서 실행해주는' 기능을 만들고 있다면 당장 후보에 올릴 만해요. 직접 Firecracker를 깔고 운영하는 건 난이도가 높은데, 그걸 관리형으로 쓸 수 있으니까요. 멀티테넌트(여러 고객이 한 서비스를 같이 쓰는) 구조에서 고객 코드를 안전하게 격리 실행해야 하는 SaaS에도 유용하고요. 다만 일시정지·재개 같은 세밀한 제어가 붙으면 과금 모델이 복잡해질 수 있으니, 도입 전에 비용 시뮬레이션은 꼭 해보세요.