AWS Lambda MicroVMs가 AI 코드 실행을 안전하게 만드는 방법

MicroVMs가 실제로 해결하고 있는 문제

서버리스 컴퓨팅 (Serverless computing)은 근본적인 가정 위에 구축되었습니다. 즉, 함수 내부에서 실행되는 코드는 플랫폼 소유자가 신뢰하는 개발자가 작성했다는 가정입니다. AWS Lambda, Azure Functions, Google Cloud Run — 이들 모두가 해당 모델에 최적화되어 있습니다. 실행은 빨랐고, 과금은 세밀했으며, 인프라는 시야에서 사라졌습니다. 아무도 낯선 사람이 작성하거나 런타임 (runtime) 중에 언어 모델 (language model)에 의해 생성된 코드를 안전하게 실행하도록 이 시스템들을 설계하지 않았습니다.

그 가정은 더 이상 유효하지 않게 되었습니다.

컨테이너 (Containers)가 그 격차를 어느 정도 좁혔습니다. Docker 및 유사한 런타임 (runtimes)은 프로세스 수준의 격리 (process-level isolation)와 일관된 환경을 제공하지만, 호스트 (host) 상의 모든 컨테이너는 동일한 운영체제 커널 (operating system kernel)을 공유합니다. 적절한 커널 익스플로잇 (kernel exploit)을 가진 충분한 동기를 가진 공격자는 해당 경계를 완전히 벗어날 수 있습니다. 알려진 코드가 실행되는 내부 워크로드 (internal workloads)의 경우 그 위험은 관리 가능합니다. 하지만 사용자가 제출하거나 AI가 생성한 코드가 지속적으로 실행되는 멀티 테넌트 (multi-tenant) 플랫폼에서는 그렇지 않습니다.

하드웨어 수준의 가상화 (Hardware-level virtualization)는 그러한 탈출 경로를 차단합니다. 가상 머신 (virtual machine) 경계는 하이퍼바이저 (hypervisor) 계층에서 격리를 강제하며, 이는 게스트 프로세스 (guest process)가 어떤 익스플로잇 (exploit)을 시도하더라도 호스트 커널 (host kernel)에 도달할 수 없음을 의미합니다. 그동안의 트레이드오프 (tradeoff)는 항상 시작 지연 시간 (startup latency)과 운영 복잡성이었습니다. VM 플릿 (fleet of VMs)을 실행하려면 대부분의 제품 기업이 갖추지 못한 깊은 인프라 전문 지식을 가진 팀이 필요합니다.

AWS가 구축하여 오픈 소스로 공개한 가상화 기술인 Firecracker는 그 트레이드오프 (tradeoff)를 깨뜨립니다. Firecracker는 이미 월간 15조 회 이상의 Lambda 함수 호출을 처리하며, 밀리초 단위의 부팅 시간과 함께 VM 수준의 격리를 제공합니다. AWS Lambda MicroVMs는 해당 Firecracker 기반을 프로그래밍 가능한 프리미티브 (programmable primitive)로서 개발자에게 직접 노출합니다. 즉, 인프라 관리 없이 전체 라이프사이클 (lifecycle) 제어가 가능한 격리된 샌드박스 (sandbox) 환경을 제공합니다.

이 출시 시점은 새로운 애플리케이션 카테고리의 물결과 직접적으로 맞물려 있습니다. 즉, 자율적으로 코드를 작성하고 실행하는 AI 코딩 에이전트 (AI coding agents), 채팅 제품에 내장된 코드 해석기 (code interpreter) 기능, 사용자 정의 자동화 워크플로 (automation workflows), 그리고 멀티 테넌트 (multi-tenant) 개발자 플랫폼이 이에 해당합니다. 이들 각각은 신뢰할 수 없거나 동적으로 생성된 코드를 대규모로 실행할 것을 요구합니다. 보안 실행 환경 (secure execution environment) 문제는 이러한 유스케이스 (use cases)들이 등장하기 전까지는 이론적인 문제였으나, 이제는 즉각적인 제품 요구 사항이 되었습니다. Lambda MicroVMs는 이러한 특정 변곡점에 대한 AWS의 해답입니다.

'MicroVM'이 내부적으로 실제로 의미하는 것

MicroVM은 전통적인 VM (virtual machine)이 갖춘 모든 것을 버린 경량화된 가상 머신입니다. 비대한 운영체제 (operating system) 스택, 불필요한 드라이버, 레거시 오버헤드 (legacy overhead)가 없습니다. 남은 것은 격리된 워크로드 (workloads)를 안전하게 실행할 수 있는 최소한의 메커니즘을 갖춘 최소한의 커널 (kernel)뿐입니다. 그 결과, 기존 VM이 요구하는 수 초 또는 수 분이 아니라 밀리초 (milliseconds) 단위로 부팅되는 샌드박스 (sandboxed) 실행 환경이 만들어집니다.

AWS는 Lambda MicroVMs 발표를 위해 이 개념을 발명한 것이 아닙니다. AWS는 이미 서버리스 워크로드 (serverless workloads)를 위해 특수 제작된 가상 머신 모니터 (virtual machine monitor)인 Firecracker를 구축하여 오픈 소스로 공개했으며, 수년 동안 모든 Lambda 함수 호출과 모든 Fargate 컨테이너를 조용히 구동해 왔습니다. AWS는 Firecracker를 통해 매월 15조 회 이상의 Lambda 호출을 처리합니다. Lambda MicroVMs는 본질적으로 검증된 동일한 가상화 계층 (virtualization layer)을 개발자가 직접 제어할 수 있는 직접적이고 프로그래밍 가능한 프리미티브 (primitive)로 노출하는 것입니다.

여기서는 격리 모델 (isolation model)이 중요합니다. 컨테이너 (containers)는 호스트 (host)와 커널을 공유하며, 이는 신뢰할 수 없거나 AI가 생성한 코드가 등장할 때 유의미한 공격 표면 (attack surface)을 생성합니다. MicroVM은 자체 커널을 실행하므로, 침해된 워크로드가 호스트나 이웃한 테넌트 (tenant)의 환경에 도달할 수 없습니다. 이러한 하드웨어로 강제된 경계 (hardware-enforced boundary)가 MicroVM을 단순한 편의 기능이 아닌, 멀티 테넌트 코드 실행을 위한 진지한 옵션으로 만드는 핵심입니다.

상태 유지(stateful) 차원은 Lambda MicroVMs가 기존의 서버리스 컴퓨팅(serverless compute) 방식에서 벗어나는 지점입니다. 표준 Lambda 함수는 일시적(ephemeral)입니다. 즉, 실행되고 종료되며 아무것도 남기지 않습니다. 반면 MicroVMs는 일시 중지(pause), 스냅샷(snapshot), 재개(resume) 작업을 지원하며, 이는 인메모리 실행 상태(in-memory execution state)가 호출 간에도 지속됨을 의미합니다. 장시간 실행되는 AI 에이전트 세션, 다단계 코드 인터프리터(code interpreter), 또는 대화형 샌드박스(interactive sandbox)는 실행을 중단했다가 정확히 멈췄던 지점에서 다시 시작할 수 있습니다. 개발자는 서버리스의 확장성 및 인프라 없는 운영 방식과 상태 유지 애플리케이션(stateful applications)에 필요한 연속성을 동시에 얻을 수 있습니다. 이는 이번 발표 전까지는 관리형 기본 요소(managed primitive)로서 존재하지 않았던 조합입니다.

라이프사이클 제어(Lifecycle Control): 대부분의 보도가 과소평가하고 있는 기능

AWS Lambda MicroVMs에 대한 대부분의 보도는 격리(isolation)와 보안(security)에만 집중합니다. 이는 이해할 수 있는 부분이지만, 개발자의 아키텍처 결정에 가장 직접적인 변화를 주는 능력인 '명시적 라이프사이클 제어(explicit lifecycle control)'를 묻어버리는 결과를 초래합니다.

개발자는 생성(create), 실행(run), 일시 중지(pause), 재개(resume), 종료(terminate)라는 다섯 가지 개별 작업을 통해 MicroVMs를 호출합니다. 이 시퀀스는 단순해 보이지만, 서버리스 컴퓨팅이 이전에는 결코 제공하지 못했던 무언가를 가능하게 합니다. 이전에는 Lambda에서 세션과 유사한 경험을 구축하려면 VM을 지속적으로 실행하여 유휴 컴퓨팅(idle compute) 비용을 낭비하거나, 상태 유지(statefulness)를 흉내 내기 위해 복잡한 오케스트레이션(orchestration) 계층을 연결해야만 했습니다. MicroVMs는 이 두 가지 타협안을 모두 제거합니다.

일시 중지 및 재개(pause-and-resume) 기능은 경제적 측면에서 매우 흥미로운 지점입니다. 인간의 승인이 필요한 지점에 도달하는 다단계 워크플로우를 실행하는 AI 에이전트를 가정해 보십시오. 전통적인 서버리스 함수를 사용할 경우, 개발자는 타임아웃(time out)이 발생하여 상태를 잃거나, 프로세스를 계속 유지하여 유휴 시간(idle time)에 대한 비용을 지불해야 하는 나쁜 선택에 직면합니다. Lambda MicroVMs를 사용하면 에이전트는 실행 중간에 동결(freeze)됩니다. 과금은 중단됩니다. 환경은 정확한 메모리 상태를 보존합니다. 인간이 승인하면 MicroVM은 즉시 재개됩니다. 콜드 스타트(cold start)도, 상태 재구성(state reconstruction)도, 대기 시간 동안의 낭비되는 비용도 없습니다.

이러한 상태 유지 실행 모델(stateful execution model)은 서버리스(serverless)의 실제 의미를 재정립합니다. 기존의 서버리스 계약은 인프라 관리 권한을 넘겨주는 대신 일시적이고 상태가 없는(stateless) 컴퓨팅 자원을 받는 것이었습니다. Lambda MicroVMs는 그 계약을 재협상합니다. 개발자는 인프라 관리 제로(zero-infrastructure-management)라는 이점을 유지하면서도, 개별 함수 호출(function invocation)보다는 장기 실행 프로세스(long-running processes)에 더 가깝게 동작하는 지속적이고 제어 가능한 실행 환경을 얻게 됩니다.

실질적인 효과는 서버리스 함수와 상시 가동되는 가상 머신(virtual machines) 사이의 아키텍처 경계가 붕괴되는 것입니다. 이전에는 지속적인 EC2 인스턴스나 컨테이너를 요구했던 워크로드들 — 대화형 코딩 환경, 멀티 턴(multi-turn) AI 에이전트 세션, 외부 트리거를 기다리는 장기 실행 데이터 파이프라인 등 — 이 이제는 매 호출마다 상태를 처음부터 다시 구축할 필요가 없는 서버리스 경로를 갖게 되었습니다. 인프라 관리 부담은 AWS가 가져가고, 라이프사이클(lifecycle) 결정권은 개발자에게 남습니다.

아무도 명확하게 설명하지 않는 AI 에이전트 유스케이스(Use Case)

코드를 실행하는 AI 에이전트는 대부분의 제품 발표에서 교묘히 피해 가는 근본적인 보안 문제를 안고 있습니다. 바로 언어 모델(language model)이 코드를 작성하고 이를 실행할 때, 그 코드가 실제 인프라 위에서 실행된다는 점입니다. ChatGPT의 Code Interpreter, Devin, 그리고 도구 사용(tool-use) 능력을 갖춘 모든 LLM은 실행 가능한 결과물(executable artifacts)을 생성하며, 이 결과물들이 안착할 공간이 필요합니다. 그 공간은 다른 모든 사용자의 워크로드로부터 격리되어야 하고, 호스트 시스템으로부터도 격리되어야 하며, 연쇄적인 장애(cascading failures) 없이 악성 코드나 단순히 오류가 있는 코드를 처리할 수 있어야 합니다. 컨테이너(Containers)는 이를 완전히 해결하지 못합니다. 커널(kernel)을 공유한다는 것은 위험도 공유한다는 것을 의미하기 때문입니다. 전용 VM(Dedicated VMs)은 이 문제를 해결하지만, 대규모 멀티 테넌트(multi-tenant) 플랫폼의 경제성을 파괴합니다.

AWS Lambda MicroVMs는 그 간극을 직접적으로 메워줍니다. 각 microVM은 이미 매월 15조 회 이상의 Lambda 함수 호출(invocations)을 처리하고 있는 동일한 가상화 계층인 Firecracker 가상 머신(virtual machine) 내부에서 실행됩니다. 이 검증된 격리 경계(isolation boundary)는 이제 개별 사용자 세션이나 개별 에이전트 실행을 감싸며, 멀티 테넌트(multi-tenant) AI 플랫폼에 사용자당 별도의 EC2 인스턴스를 프로비저닝하지 않고도 진정한 VM급 샌드박싱(sandboxing)을 제공합니다. 만 명의 동시 에이전트 세션을 서비스하는 플랫폼은 각 세션마다 별도의 인프라 점유(infrastructure footprint) 없이도 만 개의 격리된 실행 환경을 확보하게 됩니다.

상태 유지(stateful) 설계는 격리만큼이나 중요합니다. 전통적인 서버리스 함수(serverless functions)는 실행 후 해제되며, 모든 호출(invocation)은 콜드 스타트(cold start)로 시작됩니다. 다단계 코딩 작업을 수행하는 AI 에이전트에게는 지속성(persistence)이 필요합니다. 즉, 3단계 전에 설치한 패키지, 중간 데이터 파일, 여전히 실행 중인 백그라운드 프로세스 등이 유지되어야 합니다. Lambda MicroVMs는 작업의 전체 생명주기(lifecycle) 동안 해당 환경을 열어두어, 에이전트가 매 도구 호출(tool call)마다 컨텍스트를 처음부터 다시 구축하는 대신 일관된 작업 공간(workspace) 내에서 구축하고 반복할 수 있도록 합니다.

실질적인 결과로, AI 에이전트를 위한 안전한 코드 실행은 더 이상 인프라 전문 프로젝트가 아니게 됩니다. 자율 코딩 어시스턴트, 데이터 분석 에이전트 또는 AI 기반 개발 환경을 구축하는 팀은 가상화 전문 지식 없이도 서버리스 API를 통해 VM 수준의 프로세스 격리(process isolation), 거의 즉각적인 시작 및 재개, 그리고 전체 생명주기 제어 기능을 얻을 수 있습니다. 대규모 AI 에이전트 배포를 조용히 제약해 왔던 위협 모델(threat model)에 대해, 이제 이를 해결하기 위해 특수 설계된 아키텍처가 마련된 것입니다.

이것이 AI 네이티브 제품을 구축하는 개발자들에게 의미하는 바

AI 코딩 어시스턴트, 대화형 노트북 환경 또는 로우코드(low-code) 플랫폼을 구축하려면 과거에는 고통스러운 두 가지 선택지 중 하나를 택해야 했습니다. 맞춤형 샌드박싱 인프라를 엔지니어링하는 데 수개월을 투자하거나, 아니면 안전하지 않은 제품을 출시하는 것이었습니다. AWS Lambda MicroVMs는 이러한 트레이드오프(tradeoff)를 제거합니다.

커스텀 샌드박스 인프라(Custom sandbox infrastructure)를 구축하는 것은 팀이 맡을 수 있는 가장 보안에 민감한 엔지니어링 문제 중 하나입니다. VM 수준의 격리(isolation)를 제대로 구현하려면 가상화(virtualization), 커널 보안(kernel security), 그리고 멀티 테넌트 리소스 격리(multi-tenant resource isolation)에 대한 깊은 전문 지식이 필요합니다. 이는 대부분의 제품 중심 엔지니어링 팀이 당장 보유하고 있지 않은 기술입니다. Lambda MicroVMs는 관리형 API(managed API) 뒤에서 이 모든 복잡성을 처리합니다. 팀은 가상화 코드를 한 줄도 작성하거나 하이퍼바이저 보안(hypervisor security) 전문가를 고용할 필요 없이, Firecracker 기반의 격리된 실행 환경에 접근할 수 있습니다.

가격 모델은 두 번째 장벽인 비용 문제를 해결합니다. Lambda MicroVMs는 서버리스(serverless) 과금 방식을 따르므로, 개발자는 샌드박스가 실제로 소비한 컴퓨팅 시간(compute time)에 대해서만 비용을 지불합니다. 세밀한 일시 중지 및 재개 라이프사이클 제어(fine-grained pause and resume lifecycle control) 덕분에 유휴 샌드박스 시간 동안에는 비용이 발생하지 않습니다. 이는 하루에 수천 개의 일시적인(ephemeral) 코드 실행 세션을 실행하는 모든 AI 툴링 스타트업의 기본 운영 비용을 직접적으로 절감해 줍니다. 제품을 검증하는 초기 단계의 팀에게, 대기 중인 인프라에 컴퓨팅 자원을 낭비하는 것과 실제 실행 시간에 대해서만 비용을 지불하는 것 사이의 차이는 비즈니스 모델의 생존 가능 여부를 결정지을 수 있습니다.

여기서 나타나는 민주화 효과는 실질적입니다. 에이전트형 코딩 도구(agentic coding tools), AI 기반 데이터 과학 노트북(AI-powered data science notebooks), 또는 사용자용 코드 인터프리터(code interpreters)를 구축하는 스타트업들은 이제 전 세계적으로 매월 15조 회 이상의 Lambda 함수 호출을 지원하는 것과 동일한 VM 수준의 보안 격리에 접근할 수 있습니다. 이는 Amazon이 자체 인프라 규모에서 사용하는 것과 동일한 Firecracker 기술입니다. 과거에는 이러한 보안 기준을 맞추기 위해 전담 플랫폼 엔지니어링 팀이 필요했습니다. 이제는 거의 즉각적인 MicroVM 실행 시간을 가진 서버리스 기본 요소(serverless primitive)로 제공됩니다.

개발자들에게 있어 실질적인 결과는 더 빠른 프로덕션(production) 출시 속도입니다. 격리된 샌드박스(sandbox) 문제는 해결되었습니다. 엔지니어링 사이클은 보안이 확보된 멀티 테넌트 컴퓨팅(multi-tenant compute)을 처음부터 다시 만드는 대신, 더 나은 AI 에이전트 오케스트레이션(orchestration), 더 풍부한 실행 환경(execution environments), 더 긴밀한 사용자 경험(user experiences)과 같은 제품 차별화로 전환됩니다.

놓치고 있는 맥락: 경쟁 및 산업적 영향

AWS는 진공 상태에서 움직이는 것이 아닙니다. Google은 Gemini의 도구 사용(tool-use) 아키텍처에 샌드박스화된 코드 실행을 직접 내장했으며, Microsoft는 Copilot Studio와 Azure AI Foundry에 격리된 실행 환경을 연결했습니다. 두 회사 모두 안전한 코드 실행을 통제된 내부 기능, 즉 자신들의 AI 제품 내에서 자신들이 정한 방식대로 노출하는 기능으로 취급합니다. AWS Lambda MicroVMs는 다른 접근 방식을 취합니다. 이는 샌드박스화된 실행을 특정 AI 제품과 무관하게 어떤 개발자라도 독립적으로 호출할 수 있는 범용 서버리스 기본 요소(serverless primitive)로 제공합니다. 이러한 아키텍처적 선택은 Google과 Microsoft로 하여금 자신들의 폐쇄형 정원(walled-garden) 방식이 개발자들에게 충분한 서비스를 제공하지 못하고 있는 것은 아닌지 재고하게 만듭니다.