사용자가 AI에게 “이 코드를 작성해 줘”라고 요청합니다. 몇 초 뒤, 생성된 코드를 실행하고 결과를 확인합니다. 그렇다면 그 코드는 실제로 어디에서 실행되고 있을까요?
기존의 Serverless 모델이라면 답은 비교적 단순했습니다. 이벤트가 발생하면 함수가 실행되고, 작업이 끝나면 실행 환경은 더 이상 유지될 필요가 없습니다. 이미지 리사이징, 웹훅 처리, 파일 변환처럼 한 번의 요청으로 끝나는 작업에는 이 방식이 매우 효율적입니다.
하지만 AI가 만든 코드를 실행하거나, 브라우저 기반 IDE에서 사용자가 여러 차례 코드를 수정·실행하거나, 에이전트가 이전 작업의 맥락을 이어받아 다음 작업을 수행해야 한다면 이야기가 달라집니다. 실행 환경은 단지 “한 번 호출되고 끝나는 함수”가 아니라, 상태와 맥락을 일정 시간 유지하는 작업 공간이 되어야 합니다.
AWS Lambda MicroVMs는 바로 이 지점에서 등장합니다.
기존 AWS Lambda가 이벤트 중심의 짧고 stateless한 함수 실행에 최적화됐다면, Lambda MicroVMs는 VM 수준의 격리, 빠른 시작과 재개, 상태 유지를 결합한 새로운 Serverless 실행 환경입니다. 개발자는 여전히 서버를 직접 프로비저닝하거나 운영하지 않습니다. 그러나 실행 환경은 요청이 끝났다는 이유만으로 즉시 모든 맥락을 잃지 않습니다.
이 차이는 특히 AI 시대에 중요합니다. AI가 생성한 코드는 편리하지만, 항상 신뢰할 수 있는 것은 아닙니다. 의도하지 않은 파일 접근, 과도한 리소스 사용, 취약한 의존성 호출 같은 위험이 존재할 수 있습니다. 따라서 생성된 코드는 애플리케이션의 핵심 프로세스가 아니라, 작업별로 분리된 격리 환경에서 실행하는 편이 안전합니다.
Lambda MicroVMs는 이런 요구에 맞춰 각 사용자, 에이전트 또는 작업에 독립적인 실행 공간을 제공하는 방향을 제시합니다. 즉, 서버를 운영하지 않으면서도 VM에 가까운 격리 경계를 확보하는 모델입니다.
함수처럼 간편하게 시작하지만, 필요할 때는 서버처럼 작업 맥락을 이어가는 것.
이것이 Lambda MicroVMs가 제시하는 새로운 Serverless의 모습입니다.
이제 Serverless는 더 이상 “실행 후 사라지는 함수”만을 의미하지 않습니다. 사용자 코드, AI 에이전트, 인터랙티브 개발 환경처럼 지속적인 컨텍스트와 강한 격리가 필요한 워크로드까지 포괄하는 실행 레이어로 확장되고 있습니다.
Serverless와 가상머신의 경계에서 탄생한 MicroVM
기존 서버리스는 빠르고 편리합니다. 개발자는 함수만 작성하면 되고, 서버 프로비저닝과 패치, 자동 확장은 클라우드가 처리합니다. 하지만 실행 환경은 기본적으로 일시적입니다. 호출이 끝난 뒤에도 동일한 실행 컨텍스트가 유지된다고 보장하기 어렵기 때문에, 세션이나 작업 상태는 데이터베이스·캐시 같은 외부 저장소에 별도로 관리해야 합니다.
반대로 전통적인 가상머신(VM)은 운영체제와 실행 환경을 비교적 자유롭게 제어할 수 있고, 장시간 실행되는 상태ful 워크로드에도 적합합니다. 그러나 인스턴스 생성, 보안 패치, 용량 계획, 장애 대응, 확장 정책까지 운영자가 책임져야 한다는 부담이 따릅니다.
그렇다면 서버리스의 운영 편의성과 VM의 격리·지속성을 함께 얻을 수는 없을까요? AWS Lambda MicroVMs는 바로 이 질문에서 출발한 컴퓨트 모델입니다.
함수 실행을 넘어선 Serverless 실행 환경
Lambda MicroVMs는 작은 가상머신 기반의 실행 환경을 서버리스 방식으로 제공합니다. 개발자는 VM을 직접 생성하거나 운영하지 않지만, 실행 환경은 단순한 일회성 함수 컨테이너보다 더 강한 격리와 상태 유지 기능을 제공합니다.
핵심은 다음 세 가지입니다.
VM 수준 격리
각 워크로드를 독립된 MicroVM에서 실행해 사용자 코드, 플러그인, AI 생성 코드처럼 신뢰하기 어려운 프로그램을 분리할 수 있습니다.빠른 시작과 재개
전통적인 VM처럼 무거운 부팅 과정을 거치지 않고, 빠르게 실행하거나 이전 상태를 재개하는 경험을 목표로 합니다.상태 보존
호출이 끝날 때마다 모든 컨텍스트가 사라지는 일반적인 FaaS와 달리, 인터랙션 사이의 실행 상태를 유지할 수 있습니다. 따라서 세션 기반 작업이나 여러 단계로 이어지는 작업 흐름에 더 자연스럽게 대응할 수 있습니다.
즉, 기존 AWS Lambda가 “이벤트에 반응해 짧게 실행되는 함수”에 가깝다면, Lambda MicroVMs는 상태를 가진 격리형 Serverless 실행 공간에 가깝습니다.
FaaS와 VM 사이의 빈틈을 메우는 구조
MicroVM은 FaaS를 대체하기보다, FaaS가 다루기 어려웠던 영역을 보완합니다.
| 구분 | 기존 FaaS | 전통적 VM | Lambda MicroVMs |
|---|---|---|---|
| 운영 책임 | 클라우드가 관리 | 운영자가 관리 | 클라우드가 관리 |
| 실행 방식 | 짧은 이벤트 중심 | 지속 실행 가능 | 빠른 실행과 지속적 컨텍스트 |
| 상태 관리 | 외부 저장소 중심 | 로컬 환경 활용 가능 | 실행 환경 상태 보존 지원 |
| 격리 수준 | 함수·컨테이너 기반 격리 | VM 수준 격리 | VM 수준 격리 |
| 적합한 작업 | 웹훅, 파일 처리, 큐 소비 | 장시간 서비스, 복잡한 서버 | AI 코드 실행, 샌드박스, 웹 IDE |
예를 들어 이미지 리사이징, 결제 웹훅 처리, 메시지 큐 소비처럼 요청 단위로 빠르게 끝나는 작업은 기존 Serverless 함수가 여전히 효율적입니다. 반면 브라우저 기반 IDE, 코드 실행 플랫폼, AI 에이전트가 생성한 프로그램 검증처럼 세션과 실행 컨텍스트가 중요한 작업은 MicroVM 모델이 더 적합할 수 있습니다.
왜 지금 MicroVM이 중요한가
AI가 코드를 생성하고, 사용자가 브라우저에서 직접 코드를 실행하며, 서비스가 외부 플러그인을 받아들이는 환경에서는 “코드를 실행하는 것” 자체가 보안 경계가 됩니다. 특히 AI가 만든 코드는 정상 동작 여부뿐 아니라 파일 접근, 네트워크 호출, 리소스 과점유 같은 위험까지 고려해야 합니다.
MicroVM은 이런 비신뢰 코드에 별도의 격리 공간을 제공하면서도, 서버를 직접 관리해야 하는 부담을 줄입니다. 다시 말해, 강한 격리는 필요하지만 VM 운영팀까지 두기 어려운 서비스에 새로운 선택지를 제시합니다.
Lambda MicroVMs는 Serverless가 단순한 함수 실행 모델을 넘어, AI 시대의 안전한 코드 실행 플랫폼으로 확장되고 있음을 보여주는 대표적인 사례입니다.
Serverless 환경에서 AI가 만든 코드를 믿지 않는 가장 현실적인 방법
AI가 생성한 코드가 악의적이지 않다는 보장은 누가 할 수 있을까요? 한 줄의 스크립트가 파일 시스템, 네트워크, 인증 정보에 접근하는 순간 일반적인 함수 실행 방식만으로는 부족해집니다.
문제는 AI가 의도적으로 악성 코드를 만든다는 데만 있지 않습니다. 잘못된 패키지를 설치하거나, 무한 루프에 빠지거나, 환경 변수에 담긴 비밀값을 출력하거나, 과도한 네트워크 요청을 보내는 코드도 서비스에는 충분히 위험합니다. 사용자가 업로드한 플러그인과 LLM이 작성한 자동화 스크립트 역시 같은 기준으로 다뤄야 합니다.
가장 현실적인 원칙은 단순합니다.
AI가 만든 코드는 신뢰된 애플리케이션 프로세스 안에서 실행하지 않는다.
이 원칙을 구현하는 데 적합한 선택지가 바로 AWS Lambda MicroVMs와 같은 Serverless 기반 격리 실행 환경입니다. 애플리케이션 서버가 AI 생성 코드를 직접 실행하는 대신, 작업마다 독립된 MicroVM으로 코드를 전달하고 결과만 받아오는 구조입니다.
왜 일반적인 함수 실행만으로는 부족할까?
기존 FaaS는 이미지 변환, 웹훅 처리, 큐 메시지 소비처럼 짧고 명확한 이벤트 작업에 매우 효율적입니다. 그러나 AI 코드 실행은 성격이 다릅니다.
- 실행 중 임시 파일과 의존성을 유지해야 할 수 있습니다.
- 여러 단계의 명령 실행과 디버깅 세션이 이어질 수 있습니다.
- 사용자별 작업 환경을 분리해야 합니다.
- 코드가 외부 네트워크, 파일 시스템, 인증 정보에 접근하지 못하도록 통제해야 합니다.
이때 단순히 “함수 하나를 호출한다”는 모델만으로는 세션 지속성, 격리 경계, 실행 정책을 충분히 설계하기 어렵습니다. Lambda MicroVMs는 VM 수준의 격리와 상태 보존을 제공하면서도, 개발자가 VM 프로비저닝과 패치, 용량 계획을 직접 운영하지 않도록 돕습니다.
안전한 AI 코드 실행 아키텍처
권장 구조는 프런트엔드와 신뢰된 API 계층, 그리고 비신뢰 코드 실행 계층을 분리하는 것입니다.
- 사용자가 코드 실행을 요청합니다.
- API는 코드와 실행 정책을 검증한 뒤 MicroVM 실행 작업을 생성합니다.
- 격리된 MicroVM이 제한된 권한으로 코드를 실행합니다.
- 표준 출력, 오류 로그, 생성 파일 등 필요한 결과만 API 계층으로 반환합니다.
- 실행이 끝난 환경은 정책에 따라 폐기하거나, 허용된 세션에 한해 상태를 유지합니다.
이 구조의 핵심은 실행 결과는 받아오되, 실행 권한까지 넘겨주지 않는 것입니다. AI 코드가 실패하거나 예상 밖의 동작을 해도 피해 범위를 해당 MicroVM과 해당 작업 단위로 제한할 수 있습니다.
반드시 함께 적용해야 할 보안 원칙
MicroVM을 도입했다고 해서 자동으로 안전해지는 것은 아닙니다. 격리 환경 위에도 최소 권한 원칙을 적용해야 합니다.
- IAM 권한 최소화: 실행 환경에는 꼭 필요한 AWS 권한만 부여합니다. 가능하다면 기본 권한을 거의 비워 둡니다.
- 네트워크 기본 차단: 외부 통신은 기본적으로 제한하고, 패키지 저장소나 내부 API처럼 필요한 목적지만 허용합니다.
- 짧은 수명의 자격 증명: 장기 액세스 키 대신 제한된 범위와 짧은 만료 시간을 가진 토큰을 사용합니다.
- 리소스 한도 설정: CPU, 메모리, 디스크, 실행 시간, 동시 실행 수를 제한해 무한 루프와 자원 고갈을 막습니다.
- 민감 정보 분리: 환경 변수, 시크릿, 운영 데이터베이스 자격 증명을 코드 실행 환경에 직접 주입하지 않습니다.
- 관측성과 감사 로그: 실행 요청자, 코드 해시, 네트워크 시도, 오류 로그를 기록해 사고 대응이 가능하도록 합니다.
Serverless가 만드는 운영상의 이점
전통적인 샌드박스 서버는 컨테이너나 VM 풀을 직접 관리해야 합니다. 사용자가 몰리지 않는 시간에도 인프라를 유지해야 하고, 이미지 업데이트와 보안 패치, 오토스케일링 정책도 운영팀의 몫입니다.
반면 Serverless MicroVM 접근 방식은 실행 환경의 프로비저닝과 확장 부담을 줄입니다. 온라인 IDE, 교육용 코딩 서비스, AI 에이전트 플랫폼, 취약점 스캐닝 SaaS처럼 실행량이 불규칙한 서비스에서 특히 유리합니다.
결국 중요한 것은 AI를 “신뢰할 수 있는 개발자”처럼 대하지 않는 것입니다. AI가 만든 코드도 외부 사용자가 올린 코드처럼 취급하고, 독립된 환경에서 최소 권한으로 실행해야 합니다. 이것이 AI 시대에 가장 현실적이고 확장 가능한 코드 실행 보안 전략입니다.
AI 에이전트와 Serverless: 작업마다 서버를 빌려주는 새로운 운영 모델
AI 에이전트가 작업마다 코드를 만들고, 실행하고, 오류를 분석한 뒤 다시 수정하는 시대가 오고 있습니다. 이때 고정된 서버 몇 대를 항상 켜 두는 방식만으로는 충분할까요?
에이전트가 생성하는 코드는 신뢰하기 어렵고, 작업량은 예측하기 힘들며, 실행 환경은 서로 완전히 분리되어야 합니다. AWS Lambda MicroVMs는 이러한 문제에 대응해, AI 에이전트가 필요할 때만 자신만의 격리된 실행 공간을 확보하는 새로운 Serverless 운영 모델을 제시합니다.
에이전트가 필요할 때만 실행 환경을 만든다
기존 서버 운영 방식에서는 애플리케이션이나 에이전트가 사용할 서버를 미리 준비해야 합니다. 트래픽이 적어도 서버는 계속 실행되고, 갑작스러운 작업 증가에 대비하려면 여유 용량도 확보해야 합니다.
MicroVMs는 이 과정을 바꿉니다.
AI 에이전트가 코드 실행, 테스트, 취약점 검사, 데이터 처리 같은 작업을 요청하면 AWS가 필요한 실행 환경을 준비합니다. 작업이 끝난 뒤에는 인프라를 직접 정리하거나 패치할 필요가 없습니다. 개발팀은 서버 수명 주기를 관리하는 대신, 에이전트의 작업 흐름과 권한 정책에 집중할 수 있습니다.
즉, 서버를 항상 소유하는 모델이 아니라 작업 단위로 안전한 실행 공간을 빌려 쓰는 모델에 가깝습니다.
코드 생성부터 수정까지, 독립된 작업 공간으로 처리한다
AI 에이전트의 일반적인 작업 흐름은 단순한 API 호출보다 복잡합니다.
- 에이전트가 요구사항을 해석합니다.
- 코드를 생성합니다.
- 생성한 코드를 실행하거나 테스트합니다.
- 오류 로그와 결과를 분석합니다.
- 코드를 수정한 뒤 다시 실행합니다.
이 과정에는 일시적인 파일, 의존성, 실행 결과, 디버그 정보 등 세션 상태가 필요할 수 있습니다. 기존의 완전한 stateless FaaS 환경에서는 상태를 외부 데이터베이스나 스토리지로 계속 옮겨야 하므로, 인터랙티브한 실행 흐름이 복잡해질 수 있습니다.
Lambda MicroVMs는 상태 유지(state persistence) 를 지원하는 실행 환경을 지향합니다. 따라서 하나의 에이전트 작업이 여러 단계로 이어질 때, 이전 실행의 컨텍스트를 활용하는 구조를 설계하기 쉬워집니다. 예를 들어 코딩 에이전트가 프로젝트 파일을 생성하고, 테스트를 수행하고, 실패한 테스트를 기준으로 코드를 수정하는 반복 과정에 적합합니다.
“에이전트마다 한 대의 서버”가 아니라 “작업마다 하나의 격리 공간”
중요한 점은 MicroVMs가 단순히 빠른 서버를 제공하는 기술이 아니라는 것입니다. 핵심은 VM 수준의 격리입니다.
AI가 생성한 코드, 사용자가 업로드한 스크립트, 외부 플러그인 코드는 모두 잠재적으로 위험할 수 있습니다. 따라서 이를 애플리케이션의 핵심 백엔드 프로세스에서 직접 실행해서는 안 됩니다.
MicroVMs 기반 아키텍처에서는 다음과 같은 분리가 가능합니다.
- 에이전트 또는 사용자별 실행 환경 분리
- 코드 실행 실패가 다른 작업에 미치는 영향 최소화
- 악성 코드나 과도한 리소스 사용의 격리
- 작업별 IAM 권한과 네트워크 정책의 세분화
- 짧은 수명의 자격 증명을 통한 접근 범위 제한
예를 들어 SaaS 형태의 AI 코딩 플랫폼이라면, 사용자 A가 만든 코드와 사용자 B가 만든 코드를 같은 실행 프로세스에서 처리할 이유가 없습니다. 각 작업을 독립된 MicroVM에서 실행하면 장애와 보안 위험을 더 작은 단위로 가둘 수 있습니다.
Serverless 운영 모델이 바꾸는 역할 분담
이 모델에서 개발자는 VM 이미지 관리, OS 패치, 호스트 장애 대응, 용량 계획을 직접 수행하지 않습니다. AWS가 실행 환경의 프로비저닝과 확장, 유지보수를 담당하고, 팀은 다음과 같은 애플리케이션 수준의 제어에 집중합니다.
- 어떤 작업을 MicroVM에서 실행할지 결정
- 작업별 CPU·메모리·시간 제한 설계
- 최소 권한 IAM 정책 구성
- 기본 차단 원칙의 네트워크 정책 적용
- 실행 로그와 감사 기록 수집
- 실패한 작업의 재시도 및 폐기 정책 정의
이는 “서버를 운영하지 않는다”는 단순한 의미를 넘어섭니다. AI 에이전트가 필요한 순간에만 실행 공간을 요청하고, 독립된 환경에서 작업을 마친 뒤 사라지는 구조를 설계할 수 있다는 뜻입니다.
고정 서버와 MicroVMs를 함께 쓰는 현실적인 구조
모든 워크로드를 MicroVMs로 옮길 필요는 없습니다. 일반적인 웹 API, 웹훅 처리, 이미지 변환, 큐 기반 비동기 작업은 기존 AWS Lambda 같은 FaaS가 더 간단하고 효율적일 수 있습니다.
대신 다음처럼 역할을 나누는 구성이 현실적입니다.
- 프런트엔드·API·이벤트 처리: 기존 Serverless FaaS와 관리형 서비스
- 세션·업무 데이터 저장: 데이터베이스, 객체 스토리지, 캐시
- AI 추론과 벡터 검색: 관리형 AI·벡터 서비스
- AI 생성 코드와 사용자 코드 실행: Lambda MicroVMs 기반 샌드박스
결국 MicroVMs는 기존 서버를 완전히 대체하기보다, AI 에이전트 시대에 새롭게 등장한 비신뢰 코드 실행 영역을 맡는 실행 레이어입니다. 에이전트가 코드를 생성하고 스스로 검증하는 서비스라면, 이제 중요한 질문은 “서버를 몇 대 운영할 것인가?”가 아닙니다. “각 작업에 얼마나 안전하고 독립적인 실행 공간을 제공할 것인가?”가 됩니다.
Serverless 설계의 핵심: 모든 워크로드에 MicroVMs가 필요한 것은 아니다
새로운 기술이라고 해서 모든 서비스를 MicroVMs로 옮겨야 하는 것은 아닙니다. 오히려 좋은 아키텍처는 최신 기술을 가장 많이 쓰는 구조가 아니라, 워크로드의 특성에 맞는 실행 모델을 선택하는 구조입니다.
AWS Lambda MicroVMs는 VM 수준의 격리, 상태 유지, 빠른 시작·재시작이라는 강력한 장점을 제공합니다. 하지만 이 장점은 특히 비신뢰 코드 실행, 세션 유지, 인터랙티브 작업에서 빛을 발합니다. 단순한 이벤트 처리까지 모두 MicroVMs로 전환하면, 필요 이상의 복잡성과 비용을 감수할 수 있습니다.
MicroVMs가 적합한 워크로드
다음과 같은 경우에는 MicroVMs를 우선 검토할 만합니다.
사용자 또는 AI가 생성한 코드를 실행하는 경우
- 온라인 IDE, 코드 채점 서비스, 플러그인 플랫폼
- LLM이 생성한 스크립트나 자동화 코드를 검증하는 서비스
- 사용자별로 실행 환경을 분리해야 하는 SaaS
실행 환경의 상태를 유지해야 하는 경우
- 긴 개발 세션
- 디버깅 및 REPL 환경
- 여러 단계에 걸쳐 작업 맥락을 유지하는 AI 에이전트
강한 격리가 필요한 멀티테넌트 환경
- 테넌트별 실행 프로세스를 분리해야 하는 서비스
- 잠재적으로 악성일 수 있는 코드나 파일을 분석하는 보안 서비스
- 취약점 스캐닝, 샌드박스 기반 검증 환경
