AWS Lambda MicroVM은 AWS의 표현을 그대로 빌리자면, 사용자나 AI가 생성한 코드를 격리되고 상태를 유지하는 환경에서 실행하기 위해 만들어진 새로운 서버리스 프리미티브다. 여기서 주목할 단어는 바로 두 번째 단어다. 이 출시는 사실 함수에 관한 것이 아니다. AI agent가 방금 작성한 코드를 안전하게 실행할 공간을 제공하는 것이 핵심이며, AWS가 "사용자나 AI"를 앞세웠다는 사실이 이 기능이 누구를 위한 것인지 말해준다.

agent를 만들어 본 사람이라면 이미 이 벽에 부딪쳤을 것이다. 모델이 코드를 작성하면, 그 코드를 어딘가에서 실행해야 한다. 신뢰할 수 없는, 모델이 생성한 코드를 자신의 인프라에서 실행하는 것은 누구나 과소평가하는 부분이며, 바로 그 부담을 덜어주도록 MicroVM이 설계되었다.

agent가 실제로 안고 있는 sandbox 문제

유능한 agent는 단순히 답만 하지 않는다. 스크립트를 작성하고, 실행하고, 결과를 읽고, 반복한다. code interpreter, 데이터 분석 agent, 자율 코딩 도구는 모두 한 가지 질문에서 성패가 갈린다. 그 코드는 어디서 실행되는가?

순진한 답은 모두 나쁘다. 애플리케이션 프로세스 안에서 실행하면, 적대적이거나 버그가 있는 단 한 번의 생성으로 호스트가 다운되거나 다른 사용자의 데이터를 읽을 수 있다. 공유 컨테이너에서 실행하면, 컨테이너는 커널을 공유하기 때문에 커널 익스플로잇 하나로 테넌트 간 침해가 발생할 수 있다. 자체 VM 플릿을 구축하면, 스택에서 가장 어렵고 차별화되지 않는 인프라를 직접 운영하겠다고 서명한 셈이다. 모델이 생성한 코드는 정의상 신뢰할 수 없는 코드다. 형식적인 경계가 아니라 진짜 격리 경계가 필요하다.

왜 MicroVM이 agent의 형태에 들어맞는가

Lambda MicroVM은 agent가 실제로 동작하는 방식과 세 가지 축에서 맞아떨어진다.

적대적 출력을 막아내는 격리

각 세션은 자체 Firecracker MicroVM에서 실행된다. 공유 커널도, 공유 리소스도 없고, 한 환경에서 다른 환경으로 또는 호스트로 이어지는 경로도 없다. agent가 사용자의 프롬프트로부터 언어 모델이 만든 코드를 실행할 때, "agent가 이상한 짓을 했다"와 "agent가 플랫폼을 장악했다" 사이에 두고 싶은 경계가 바로 이것이다. prompt injection을 당해 데이터를 빼돌리거나 파괴하기로 마음먹은 agent도 일회용 VM 안에 갇힌다.

다단계 작업에 맞는 상태 유지

agent 작업은 한 번에 끝나는 경우가 드물다. 패키지를 설치하고, 데이터셋을 불러오고, 중간 파일을 쓴 뒤 세 단계 후에 다시 그 파일로 돌아온다. MicroVM은 세션 전반에 걸쳐 메모리, 디스크, 실행 중인 프로세스를 유지하며, 모델이 생각하거나 사용자가 잠시 자리를 비운 긴 정지 구간 동안 그 상태를 그대로 보존한 채 일시 중단했다가 거의 즉시 재개할 수 있다. 불러온 모델과 작업 중인 파일 세트는 그냥 그대로 남아 있다. 이는 모든 도구 호출마다 새 컨테이너를 다시 부트스트랩하는 것보다 훨씬 잘 들어맞는다.

상호작용처럼 느껴질 만큼 빠른 시작

모든 MicroVM은 콜드 부팅 대신 미리 초기화된 Firecracker snapshot에서 재개되기 때문에, 수 기가바이트짜리 세션도 빠르게 돌아온다. 사람이 커서가 깜빡이는 것을 지켜보는 상호작용형 agent에서, snapshot 재개와 콜드 컨테이너 시작의 차이는 쓸 만한 것과 버려지는 것의 차이다. 세션은 최대 8시간까지 실행할 수 있어, 긴 분석이나 길게 늘어지는 코딩 세션을 넉넉히 감당한다.

AWS는 런타임만이 아니라 agent 루프 전체를 만들고 있다

MicroVM 출시는 단독으로 등장하지 않았다. AWS는 coding agent인 Claude Code, Codex, Cursor, Kiro, Copilot, Windsurf, OpenCode를 플러그인, agent skill, MCP Server를 통해 서버리스 개발과 연결하는 agent 설정 가이드도 함께 내놓았다. 두 가지를 함께 읽으면 전략이 분명해진다. agent는 서버리스 애플리케이션을 만드는 것을 돕고, MicroVM은 그 agent가 생성한 코드를 안전하게 실행할 수 있는 곳이다. AWS는 코드를 작성하는 agent와 그것을 실행하는 sandbox라는 루프의 양쪽 끝을 모두 차지하려 하고 있다.

해결되지 않는 것

격리는 경계이지 두뇌가 아니다. MicroVM은 모델이 생성한 코드가 sandbox를 벗어나지 못하게 막는다. 하지만 상자 안에서 agent가 허용된 범위 내에서 멍청한 짓을 하는 것은 막지 못하며, 블래스트 반경을 상자 밖까지 넓힐 수 있는 자격 증명이 agent에게 쥐어지는 것도 막지 못한다. 진짜 시크릿을 마운트하거나 sandbox에 광범위한 IAM 역할을 부여하면, injection된 프롬프트가 정당한 API 호출을 통해 입힐 수 있는 피해에 대해서는 VM 경계가 무의미하다. sandbox를 격리하는 만큼 sandbox가 닿을 수 있는 범위도 빡빡하게 좁혀라. 런타임은 쉬운 절반이고, agent에 대한 최소 권한은 여전히 당신의 몫이다.

핵심 정리

agentic 붐의 대부분 기간 동안, 생성된 코드가 실제로 어디서 실행되는가라는 런타임 질문은 임시방편으로 답해져 왔다. 여기엔 컨테이너 하나, 저기엔 잠가둔 프로세스 하나, 그리고 여유가 있는 팀에는 직접 만든 VM 풀 하나. Lambda MicroVM은 그것을 VM 수준의 격리, 상태 유지 세션, snapshot 속도의 재개를 갖추고 API 호출로 노출되는 관리형 프리미티브로 바꾼다. 이것이 agent가 무엇을 결정하느냐에서 더 똑똑하거나 더 안전하게 만들어 주지는 않는다. 하지만 agent가 작성한 코드에 주변 모든 것을 무너뜨릴 수 없는 실행 공간을 제공하며, 프로덕션 agent에게 이것이 바로 빠져 있던 조각이었다.

다음으로 읽을 글

동일한 출시에 대한 서버리스와 인프라 관점의 분석, 라이프사이클, CLI, 그리고 일반 Lambda와 비교했을 때의 위치가 궁금하다면 ercan.cloud의 필드 노트를 참고하라. AI, AWS, 플랫폼 작업에 대한 컨설팅 문의 또는 그냥 인사를 건네고 싶다면 ercanermis.com에서 시작하라.

참고 자료