👋 안녕하세요, 기술 애호가 여러분!

저는 복잡한 기술 문제를 단순한 솔루션으로 바꾸는 것을 즐기는 클라우드 아키텍트(Cloud Architect) Sarvar입니다. 저는 AWS, Azure, DevOps, 데이터(Data), 분석(Analytics), 생성형 AI(Generative-AI) 및 에이전트형 AI(Agentic-AI) 분야에서 실제 기업을 위한 실제 시스템을 구축하며 일해 왔습니다. 이번 아티클 시리즈를 통해, 여러분이 숙련자이든 이제 막 시작하는 단계이든 상관없이 따라오기 쉬운 방식으로 제가 배운 것들을 공유하고자 합니다.

자, 시작해 봅시다! 🚀

2026년 6월 22일, AWS는 Lambda MicroVMs를 출시했습니다. 이는 Lambda 내부의 새로운 컴퓨팅 프리미티브(compute primitive)로, 사용자 또는 세션당 전용 Firecracker 가상 머신(virtual machine)을 제공합니다. 이는 기존 Lambda 함수에 대한 업데이트가 아닙니다. 모델, 가격 책정 및 사용 사례가 모두 다른 별개의 서비스입니다.

사용자나 AI 에이전트가 임의의 코드를 실행하며 강력한 격리(isolation), 빠른 시작(startup), 그리고 지속적인 상태(persistent state)가 필요한 무언가를 구축하고 있다면, 이제 이것을 선택하시면 됩니다.

기존 방식과 그것이 충분하지 않았던 이유

이번 출시 전에는 AWS에서 신뢰할 수 없는 코드를 샌드박스(sandbox)화해야 할 경우 세 가지 옵션이 있었습니다. 각각은 타협을 강요했습니다.

EC2 인스턴스는 완전한 VM 격리와 지속적인 상태를 제공합니다. 하지만 대화형 사용을 하기에는 충분히 빠르지 않습니다. AMI 부팅, 인스턴스 초기화, 사용자 데이터 스크립트 사이의 시간 때문에 사용자가 무언가를 할 수 있기까지 30초에서 몇 분이 소요됩니다. 이는 코딩 어시스턴트(coding assistants)나 온디맨드 샌드박스(on-demand sandboxes)의 사용자 경험을 저해합니다.

**컨테이너(Containers) (ECS/Fargate)**는 더 빠르게 시작하고 실행 중 상태를 유지합니다. 하지만 컨테이너는 호스트와 커널(kernel)을 공유합니다. 인터넷상의 낯선 사람으로부터 온 코드를 실행할 때, 그 공유된 커널은 완전히 신뢰할 수 없는 보안 경계(security boundary)가 됩니다. 그 위에 보안 계층을 쌓을 수는 있지만, 근본적인 모델은 더 취약합니다.

Lambda functions는 실제 VM 수준의 격리(이미 Firecracker 위에서 실행 중임)를 제공하며 밀리초 단위로 시작됩니다. 하지만 15분 후에 종료됩니다. 이들은 호출 간에 상태를 유지하지 않는 상태 비저장(stateless) 방식입니다. 또한 요청/응답(request/response) 모델을 따릅니다. 사용자가 코드를 작성하고, 실행하고, 출력을 확인하고, 패키지를 설치한 뒤 동일한 세션 내에서 다시 실행할 수 있는 지속적인 환경을 제공할 수 없습니다.

코딩 어시스턴트, AI 에이전트 샌드박스(sandbox), 또는 멀티 테넌트(multi-tenant) 노트북 플랫폼을 구축하는 팀들은 커스텀 솔루션을 짜깁기해야 했습니다. 라이프사이클 관리자(lifecycle manager)를 갖춘 EC2, 무거운 보안 설정이 적용된 ECS, 또는 베어 메탈(bare metal)에서 직접 Firecracker를 실행하는 방식 등이 있었습니다. 이 모든 것은 관리형 솔루션이 있어야 했을 문제에 대해 운영 오버헤드(operational overhead)를 발생시켰습니다.

Lambda MicroVMs의 실제 정체

Lambda MicroVMs는 바로 그 관리형 솔루션입니다.

애플리케이션 코드와 Dockerfile을 zip 아카이브로 패키징하여 S3에 업로드한 다음, Lambda API를 호출하여 MicroVM 이미지를 생성합니다. Lambda는 Dockerfile을 실행하고 애플리케이션을 시작하며, 완전히 초기화된 환경의 스냅샷(snapshot)을 캡처합니다.

사용자를 위한 샌드박스가 필요할 때 run-microvm을 호출합니다. Lambda는 해당 스냅샷으로부터 빠른 시작(rapid startup)과 함께 MicroVM을 실행합니다.

각 MicroVM은 다음을 제공받습니다:

• 전용 HTTPS 엔드포인트 (로드 밸런서나 인그레스(ingress) 인프라가 필요 없음)
• 완전한 VM 수준의 격리 (별도의 커널, 다른 테넌트와 자원 공유 없음)
• 최대 8시간 동안의 지속적인 상태 유지 (메모리와 디스크가 일시 중단/재개(suspend/resume) 시에도 유지됨)
• 유휴(idle) 상태 시 자동 일시 중단 (컴퓨팅 비용 지불 중단)
• 트래픽 유입 시 자동 또는 프로그래밍 방식의 재개 (중단된 지점부터 다시 시작)
• 구성된 기본 CPU 및 메모리의 최대 4배까지 수직 확장 (예: 2 GB / 1 vCPU 기본 설정이 8 GB / 4 vCPU로 확장)

사용자는 HTTP/2, gRPC 또는 WebSockets를 통해 연결합니다. 인증은 CreateMicrovmAuthToken API를 통해 생성한 베어러 토큰(bearer tokens)을 통해 처리됩니다.

사고 모델의 전환 (The Mental Model Shift)

이 점이 중요합니다: Lambda MicroVMs는 요청/응답(request/response) 방식이 아닙니다.

Lambda 함수(Lambda functions)의 경우, 요청이 들어오면 코드가 실행되고 응답을 반환하며 호출(invocation)이 종료됩니다. 확장은 자동으로 이루어집니다. 여러분은 개별 호출 단위로 생각하게 됩니다.

Lambda MicroVMs를 사용하면 사용자 또는 세션을 위해 지속적인 VM을 생성합니다. 이 VM은 살아있는 상태를 유지합니다. 전용 URL을 가집니다. 여러 요청이 동일한 VM으로 전달됩니다. 상태(State)가 축적됩니다. 사용자가 패키지를 설치하면 다음 요청 시에도 그 패키지가 그대로 남아 있습니다.

여러분은 플릿(fleet)을 직접 관리합니다. 언제 MicroVM을 생성할지, 어떤 사용자에게 할당할지, 그리고 언제 이를 제거(tear down)할지를 직접 결정합니다. 자동 수평 확장(automatic horizontal scaling)은 제공되지 않습니다. 해당 로직은 여러분의 애플리케이션이 담당합니다.

이는 Lambda 함수를 작성하는 것보다 서버 풀(pool of servers)을 관리하는 것에 더 가깝습니다. 차이점은 하부 인프라를 관리할 필요가 없다는 것입니다. AMI, 인스턴스 유형(instance types), 패칭(patching), 호스트를 위한 용량 계획(capacity planning)이 필요하지 않습니다.

실제 사용 모습

다음은 AWS CLI를 사용한 기본 워크플로우입니다. 아래의 명령 이름은 API 명명 규칙을 따릅니다. 사용 중인 SDK 버전에 맞는 CLI 레퍼런스를 확인하세요.

# 1단계: 애플리케이션 패키지(Dockerfile + 코드)를 S3에 업로드
aws s3 cp my-sandbox-app.zip s3://my-bucket/my-sandbox-app.zip

...

사용자는 자신의 인증 토큰(auth token)을 사용하여 run-microvm이 반환한 전용 HTTPS 엔드포인트에 연결합니다. 거기서부터 여러분의 애플리케이션이 노출하는 방식에 따라 HTTP/2, gRPC 또는 WebSockets를 통해 상호작용합니다.

셸 접속(사용자에게 VM 내부의 터미널 제공)의 경우:

aws lambda create-microvm-shell-auth-token \
  --microvm-id mvm-abc123

이 명령은 MicroVM 내부의 의사 터미널(pseudo-terminal)에 직접 연결할 수 있는 자격 증명(credentials)을 반환합니다. AI 코딩 도구들은 이를 사용하여 최종 사용자에게 실제 터미널 경험을 제공합니다.

중요한 실무적 세부 사항

시작(Startup): MicroVM은 Lambda SnapStart가 작동하는 방식과 유사하게, 미리 초기화된 스냅샷(snapshots)으로부터 실행됩니다. 이는 애플리케이션 초기화 과정을 완전히 건너뛰므로, 시작 시점에 환경이 이미 워밍업(warm)된 상태가 됩니다.

지속 시간 (Duration): 세션당 최대 8시간. 그 이후에는 MicroVM이 종료됩니다.

일시 중단/재개 (Suspend/Resume): MicroVM에 트래픽이 도달하지 않으면, 사용자가 설정한 유휴 시간 제한(idle timeout, 일시 중단 전 인바운드 트래픽 없이 대기하는 시간)에 따라 자동으로 일시 중단됩니다. 이 기간 동안에는 컴퓨팅 비용을 지불하지 않습니다. 요청이 도착하면 메모리 및 디스크 상태가 완전히 유지된 채로 재개됩니다. 또한 suspend-microvm 및 resume-microvm API를 통해 프로그래밍 방식으로 일시 중단 및 재개를 트리거할 수도 있습니다. 재개 지연 시간(Resume latency)은 완전한 콜드 스타트(cold start)가 아니라 메모리 스냅샷(memory snapshot)으로부터 복구하는 방식이므로, 처음부터 부팅하는 것보다 훨씬 빠릅니다. AWS는 출시 시점에 정확한 재개 지연 시간 수치를 공개하지 않았으므로, 특정 워크로드에 대해 직접 벤치마크를 수행해 보시기 바랍니다.

수직 확장 (Vertical scaling): 기본값(baseline)을 설정합니다(기본값은 2 GB 메모리 / 1 vCPU이며, 메모리 대 CPU 비율은 2:1로 할당됩니다). 피크 활동 중에는 MicroVM이 자동으로 해당 기본값의 4배까지 버스트(burst)할 수 있습니다. 예를 들어, 2 GB / 1 vCPU 기본값은 8 GB / 4 vCPU까지 버스트할 수 있으며, 8 GB / 4 vCPU 기본값은 32 GB / 16 vCPU까지 버스트할 수 있습니다. 버스트 리소스는 실제로 소비되는 시간 동안에만 비용을 지불합니다.

셸 액세스 (Shell access): 전체 의사 터미널 (/dev/ptmx)을 지원합니다. CreateMicrovmShellAuthToken API를 사용하면 사용자에게 VM 내부의 실제 터미널을 제공할 수 있습니다. 이는 AI 코딩 도구들이 대화형 터미널 경험을 제공하는 방식입니다.

내부 Docker (Docker inside): MicroVM 내부에서 컨테이너를 실행할 수 있습니다. 시스템 패키지 설치, 파일 시스템 마운트, 중첩 컨테이너(nested containers) 실행 등 전체 OS 기능을 사용할 수 있습니다. 주의할 점 하나는, 아웃바운드 UDP가 기본적으로 차단되어 있어 중첩 컨테이너 내부의 DNS 확인(DNS resolution)이 실패할 수 있다는 것입니다. 이에 대한 커뮤니티의 해결 방법(workarounds)들이 존재합니다.

아키텍처 (Architecture): 출시 시점에는 ARM64 (Graviton)만 지원합니다.

리전 (Regions): US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo).

가격 책정 (Pricing)

Lambda MicroVMs의 가격 책정은 컴퓨팅(compute), 스냅샷(snapshots), 데이터 전송(data transfer)의 세 가지 구성 요소로 이루어집니다.

컴퓨팅 (Compute) (US East, ARM/Graviton):

• vCPU: vCPU-초당 $0.0000276944
• Memory: GB-초당 $0.0000036667
• 초 단위 과금 (Lambda 함수와 달리 밀리초 단위가 아님)

스냅샷 (Snapshots):

• 스냅샷 쓰기 (중단 시): GB당 $0.0038
• 스냅샷 읽기 (실행 또는 재개 시): GB당 $0.00155
• 이미지 저장: GB-월당 $0.08 (최소 1주일 보관)

구체적인 예시 - 코딩 어시스턴트 플랫폼:

100명의 개발자가 각각 2 GB / 1 vCPU MicroVM을 사용하여 하루 2.5시간 동안 20일 동안 작업합니다. 각 환경은 유휴 시간 동안 하루에 6번 중단(suspend)됩니다. 월간 비용: 총 약 $1,241, 또는 개발자 1인당 월 약 $12.41입니다.

구체적인 예시 - CI/CD 작업 러너 (job runner):

월 10,000개의 작업이 실행되며, 각 작업은 8 GB / 4 vCPU 환경에서 10분 동안 실행됩니다. 중단/재개는 없습니다 (작업이 완료될 때까지 실행됨). 월간 비용: 총 약 $1,124, 또는 작업당 약 $0.11입니다.

이 가격 체계는 Lambda 함수의 경제성보다는 Fargate의 경제성에 더 가깝습니다. 호출당 비용이 아니라 전용 컴퓨팅 시간에 대해 비용을 지불하게 됩니다.

사용 시점

다음과 같은 경우에 Lambda MicroVMs를 사용하세요:

• 코딩 어시스턴트를 구축 중이며 AI가 생성한 코드를 안전하게 실행해야 할 때
• 각 사용자가 커스텀 스크립트를 실행하는 멀티 테넌트 (multi-tenant) 플랫폼을 운영할 때
• AI 에이전트가 도구를 실행하고, 패키지를 설치하며, 단계 간에 상태를 유지하는 에이전트 샌드박스 (agent sandboxes)가 필요할 때
• 사용자별 격리가 필요한 대화형 노트북 또는 REPL을 구축할 때
• 신뢰할 수 없는 페이로드 (payloads)를 실행하는 취약점 스캐너를 운영할 때
• 사용자 제공 스크립트를 격리된 상태로 실행하는 게임 서버가 필요할 때
• 각 실행마다 신선하고 격리된 샌드박스가 필요한 강화학습 (reinforcement learning) 환경을 구축할 때

다음과 같은 경우에는 Lambda MicroVMs를 사용하지 마세요:

• 일반적인 API 백엔드를 운영하는 경우 (Lambda 함수 사용 권장)
• 플릿 (fleet) 로직을 관리하지 않고 자동 수평 확장 (automatic horizontal scaling)이 필요한 경우 (Lambda 함수 또는 Fargate 사용 권장)
• 완전 관리형 에이전트 호스팅 플랫폼을 원하는 경우 (Bedrock AgentCore Runtime 사용 권장)
• 워크로드에 신뢰할 수 없는 코드 실행 (untrusted code execution)이 포함되지 않는 경우 (이 정도 수준의 격리 (isolation)가 필요하지 않을 가능성이 높음)
• x86 아키텍처가 필요한 경우 (출시 시점에는 ARM64만 지원)

Bedrock AgentCore Runtime과의 비교

두 서비스 모두 Firecracker 위에서 실행됩니다. 두 서비스 모두 8시간 세션을 지원합니다. 두 서비스 모두 셸 액세스 (shell access)를 지원합니다. 하지만 해결하고자 하는 문제는 서로 다릅니다.

AgentCore Runtime은 관리형 에이전트 플랫폼입니다. 에이전트 코드를 배포하면 AWS가 세션 라우팅 (session routing), 확장 (scaling), 정리 (teardown), 에이전트 통신 프로토콜 (agent communication protocols) 및 인증 (authentication)을 처리합니다. 사용자는 VM (가상 머신)에 대해 고민할 필요가 없습니다. 사용자는 관리형 엔드포인트 (managed endpoint)를 통해 에이전트와 통신합니다.

Lambda MicroVMs는 로우 레벨 컴퓨팅 프리미티브 (raw compute primitive)입니다. 사용자는 VM을 할당받습니다. 어떤 사용자가 어떤 VM을 가질지 직접 관리해야 합니다. 라이프사이클 (lifecycle), 정리 (cleanup) 및 라우팅 (routing)을 직접 처리합니다. 내부에서 실행되는 것에 대해 완전한 제어권을 가집니다.

비유하자면: AgentCore Runtime과 Lambda MicroVMs의 관계는 Fargate와 EC2의 관계와 같습니다. 밑단에서는 동일한 격리 기술을 사용하지만, 상단의 추상화 수준 (level of abstraction)이 다릅니다.

AI 에이전트를 구축 중이며 관리형 호스팅을 원한다면 AgentCore를 선택하십시오. 각 사용자가 원하는 무엇이든 실행할 수 있도록 격리된 환경을 제공하는 플랫폼을 구축 중이라면 Lambda MicroVMs를 선택하십시오.

시작하기

AWS 콘솔, CloudFormation, CDK 또는 Agent Toolkit for AWS를 통해 Lambda MicroVMs를 프로비저닝할 수 있습니다.

개발자 가이드는 여기에서 확인할 수 있습니다: Lambda MicroVMs Guide

API 레퍼런스: MicroVM API

마치며

Lambda MicroVMs는 서버리스 (serverless)가 주류가 된 이후 존재해 온 공백을 메워줍니다. "타인의 코드를 어떻게 안전하게 실행할 것인가?"라는 질문에 대해, 이제 AWS에서는 세 가지 서비스를 하나로 엮거나 커스텀 오케스트레이터 (orchestrator)를 직접 작성할 필요 없이 명쾌한 해답을 얻을 수 있습니다.

이것은 마법이 아닙니다. 여전히 MicroVM 플릿 (fleet)을 관리하고, 라우팅 (routing)을 처리하며, 라이프사이클 (lifecycle) 로직을 구축해야 합니다. 하지만 인프라를 관리하지 않으면서도 빠르고, 격리되며, 상태를 유지하는 (stateful) VM을 사용하는 데 필요한 어려운 부분은 AWS가 대신 처리해 줍니다.

AI 기반 개발자 도구를 구축하는 팀들에게, 이것은 아마도 2026년 현재까지 출시된 컴퓨팅 서비스 중 가장 관련성이 높은 서비스일 것입니다.

📌 마치며

읽어주셔서 감사합니다! 이 글이 도움이 되었다면:

• ❤️ 가치가 있었다면 '좋아요'를 눌러주세요
• 💾 나중에 보기 위해 저장하세요
• 🔄 팀원들과 공유하세요

다음 주제에 대한 더 많은 정보를 원하시면 저를 팔로우하세요: AWS 아키텍처 (architecture), FinOps, DevOps, 그리고 AI 인프라 (infrastructure).

👉 제 웹사이트 방문하기 | LinkedIn에서 연결하기 | 이메일: simplynadaf@gmail.com

즐거운 학습 되세요 🚀