AI 코딩 에이전트(AI coding agents)들은 매우 단순한 요청을 합니다: 명령어를 실행하게 해달라는 것이죠.

이는 많은 사고가 시작되는 방식이기도 합니다. 참으로 아름다운 대칭이군요.

지난 1년 동안, 많은 에이전트 샌드박싱(agent sandboxing)은 보안 모자를 쓴 로컬 엔지니어링 프로젝트처럼 느껴졌습니다. 컨테이너를 만들고, 워크스페이스를 마운트(mount)하고, 일부 네트워크 액세스를 차단하고, 중요한 비밀 정보를 숨깁니다. 그리고 에이전트가 npm install을 일종의 퍼포먼스 아트(performance art)로 변질시키는 창의적인 새로운 방법을 찾아내지 않기를 기도하죠.

그것은 유용했습니다. 여전히 유용합니다.

하지만 AWS가 Lambda MicroVMs를 발표한 것은 이 문제의 다음 형태를 가리킵니다. 에이전트 샌드박스는 터미널을 감싸는 영리한 래퍼(wrapper)가 아니라, 클라우드 프리미티브(cloud primitive)가 되어가고 있습니다.

agent asking for just one tiny shell command

흥미로운 점은 Lambda MicroVMs가 Firecracker를 사용한다는 점이나, 시작 속도가 빠르다는 점, 또는 상태를 유지(state retention)할 수 있다는 점만이 아닙니다. 흥미로운 점은 제품의 경계(product boundary)입니다.

AWS는 다음과 같이 말하고 있습니다: 여러분은 가상화 플랫폼을 직접 구축할 필요 없이, 각 사용자, 작업 또는 AI가 생성한 코드 경로에 대해 생명주기 제어(lifecycle control), 네트워크 구성, 상태 유지 및 과금 조절 기능을 갖춘 자체 VM 수준의 실행 환경을 부여할 수 있습니다.

이는 에이전트 인프라(agent infrastructure)가 어디로 향하고 있는지에 대한 큰 힌트입니다.

컨테이너(containers)가 첫 번째 해답이었습니다

컨테이너는 엔지니어들이 이미 이해하고 있기 때문에 당연한 첫 번째 해답이었습니다. 어느 정도는 말이죠.

컨테이너는 충분히 빠르고, 충분히 저렴하며, 충분히 이식성이 높고, 이미 CI, Kubernetes, 스캐너, 레지스트리(registries), 그리고 Docker 네트워킹의 집단적 트라우마에 연결되어 있습니다. 에이전트가 저장소(repo)를 편집하고 테스트를 실행해야 한다면, 컨테이너는 시작하기에 합리적인 장소입니다.

하지만 "시작하기에 합리적인 장소"가 "임의로 생성된 코드에 대한 최종 보안 경계(final security boundary)"와 같은 의미는 아닙니다.

에이전트 워크로드(Agent workloads)는 매우 특정한 방식으로 번거롭습니다. 의존성(dependencies)을 설치해야 하고, 도구(tools)를 실행하며, 파일을 작성하고, 테스트를 실행하며, 어쩌면 브라우저를 시작하거나 내부 API를 호출해야 할 수도 있습니다. 또한 시도 사이에 상태(state)를 유지해야 할 수도 있고, 사람이 출력을 검토하는 동안 유휴(idle) 상태로 대기해야 할 수도 있습니다. 이들은 단순히 상태가 없는(stateless) 함수 호출(function invocations)이 아닙니다. 그렇다고 정확히 일반적인 서비스(services)라고 할 수도 없습니다.

이들은 야망을 품은, 지저분하고 작은 작업 공간(workspaces)입니다.

컨테이너(Containers)가 이를 수용할 수는 있습니다. 하지만 테넌트 격리(tenant isolation), 프롬프트 인젝션(prompt injection), 신뢰할 수 없는 코드(untrusted code), 파일 시스템 상태(filesystem state), 네트워크 이그레스(network egress), 그리고 장기 실행 세션(long-running sessions)을 고려하기 시작하면, 결국 컨테이너 주변에 VM 형태의 많은 고려 사항들을 다시 구축하게 됩니다.

그 시점에서 아키텍처는 조용히 자백하고 있는 것입니다.

샌드박스에는 메모리가 필요합니다

과거의 샌드박스 모델은 일회용(disposable)이었습니다. 명령을 실행하고, 결과를 수집한 뒤, 환경을 버리는 방식입니다.

단순한 작업에는 이것이 작동합니다. 하지만 에이전트 작업에는 고통스럽습니다.

코딩 에이전트(coding agent)는 단 하나의 명령만 실행하지 않습니다. 탐색하고, 파일을 변경하고, 테스트를 실행하고, 패키지를 설치하고, 실패하고, 백업하고, 다시 시도하고, CI를 기다린 다음, 검토자가 "마이그레이션도 업데이트하세요"라고 말하면 다시 재개합니다. 만약 매 단계마다 환경이 사라진다면, 유용한 상태를 잃어버리거나 끊임없이 환경을 재구축해야 합니다.

Lambda MicroVMs는 상태 유지(state retention)를 기본 요소(primitive)의 일부로 만듭니다. AWS는 일시 중단(suspend) 및 재개(resume)를 통해 메모리와 디스크 상태를 보존하며 최대 8시간까지 지속될 수 있는 세션을 설명합니다. 에이전트 작업은 유휴 간격(idle gaps)으로 가득 차 있기 때문에 이는 매우 중요합니다.

the sandbox preserving state while everyone waits for CI

이는 지루한 비용 문제와 직결됩니다. 만약 모든 에이전트 작업 공간이 상태를 유지하기 위해 완전히 웜(warm) 상태로 유지되어야 한다면, 청구서는 회의 주제가 될 정도로 커질 것입니다. 만약 플랫폼이 환경을 일시 중단하고, 상태를 보존하며, 빠르게 재개할 수 있다면, 에이전트 인프라는 작업 흐름에 맞는 라이프사이클(lifecycle)을 갖게 됩니다.

마법이 아닙니다. 그저 낭비되는 대기 시간을 줄이는 것뿐입니다.

VM 레벨 격리(VM-level isolation)는 사치스러운 기능이 아닙니다

보안 논거 또한 더욱 날카로워지고 있습니다.

에이전트가 생성된 코드를 실행할 때, 위협 모델(threat model)은 단순히 "코드에 버그가 있다"는 것에 그치지 않습니다. 위협 모델은 "코드가 탈취된 프롬프트(compromised prompt), 오염된 의존성(poisoned dependency), 오도하는 이슈(misleading issue), 또는 모델이 아주 당당하게 헛소리를 생성하는 상황으로부터 생성되었을 수 있다"는 것입니다.

그 코드는 진정한 경계(boundary)를 필요로 합니다.

Firecracker microVMs가 흥미로운 이유는 에이전트 플랫폼이 필요로 하는 불편하면서도 절묘한 중간 지점에 위치하기 때문입니다. 즉, 일반적인 컨테이너(container)보다 강력한 격리를 제공하면서도, 전통적인 VM(Virtual Machine)보다 가볍고 빠르며, 클라우드 제공업체가 대규모로 운영화(operationalize)할 수 있을 만큼 친숙합니다.

그렇다고 해서 문제가 사라지는 것은 아닙니다. 향후 사고 검토(incident reviews) 과정을 즐기는 것이 아니라면, 슬라이드에 "microVM으로 해결됨"이라고 적지 마십시오.

여전히 네트워크 정책(network policy)이 필요합니다. 여전히 비밀 정보 격리(secret isolation)가 필요합니다. 여전히 송신 제어(egress controls)가 필요합니다. 여전히 감사 로그(audit logs)가 필요합니다. 또한 에이전트가 무엇을 호출할 수 있는지, 그리고 에이전트가 운영 환경(production)에 배포해도 되냐고 아주 정중하게 요청할 때 어떤 일이 벌어져야 하는지를 여전히 결정해야 합니다.

하지만 VM 레벨 격리는 기본 폭발 반경(blast radius)을 변화시킵니다. 만약 에이전트가 파괴적인 무언가를 작성한다면, 그것이 가장 먼저 파괴해야 할 대상은 개발자의 노트북도, 공유 워커(shared worker)도, 화요일 데모 때문에 누군가 마운트된 사실조차 잊어버린 운영 환경 자격 증명 캐시(production credential cache)도 아닌, 바로 에이전트 자신의 임시 환경이어야 합니다.

그것이 진보입니다.

정책(policy)은 프롬프트 내부에 존재할 수 없습니다

AWS는 Lambda MicroVM의 스토리를 Agent Toolkit 가이드 및 Bedrock AgentCore Policy와 결합합니다. 이 조합은 개별 제품명보다 더 중요합니다.

그 패턴은 다음과 같습니다: 실행을 격리하고, 에이전트에게 올바른 워크플로우(workflow)를 가르치며, 에이전트 외부에서 정책을 강제(enforce)하는 것입니다.

마지막 부분은 팀들이 AgentCore를 전혀 사용하지 않더라도 반드시 가져가야 할 부분입니다.

에이전트가 자신의 계획을 스스로 다시 쓸 수 있다면, 정책은 계획 내부에만 존재할 수 없습니다. "운영 환경에 배포하지 마세요"라고 말하는 프롬프트는 친절하긴 합니다. 하지만 그것은 마치 전기톱에 붙여놓은 포스트잇과 같습니다.

강제 집행 지점(enforcement point)은 도구 경계(tool boundary)에 위치해야 합니다. 에이전트가 배포 도구(deployment tool) 실행을 요청할 때, 게이트웨이는 사용자, 도구, 환경, 파라미터(parameters), 그리고 정책(policy)을 알고 있어야 합니다. 모델이 아주 멋진 추론(reasoning)의 순간을 경험하고 있더라도, 게이트웨이는

이것들이 중요한 이유는 원시 요소(primitive)의 이름을 정의하기 때문입니다. AI가 생성한 코드는 격리되어 있고(isolated), 상태를 유지하며(stateful), 일시 중단 가능하고(suspendable), 관찰 가능하며(observable), 통제 가능하고(governable), 일반적인 작업에 사용할 수 있을 만큼 충분히 저렴한(cheap) 실행 경계(execution boundary)가 필요합니다.

컨테이너(Containers)는 여전히 이야기의 일부일 것입니다. Kubernetes도 여전히 이야기의 일부일 것입니다. 로컬 샌드박스(Local sandboxes) 또한 여전히 중요할 것입니다. 하지만 에이전트 시대는 코드 실행을 더 강력한 경계와 더 명확한 라이프사이클 제어(lifecycle controls)를 향해 밀어붙이고 있습니다.

샌드박스(sandbox)는 더 이상 부수적인 스크립트가 아닙니다.

그것은 제품의 일부입니다.

만약 당신의 에이전트 플랫폼이 격리(isolation), 상태(state), 정책(policy), 그리고 정리(cleanup)에 대한 진정한 해답을 가지고 있지 않다면, 그것은 아마 아직 에이전트 플랫폼이 아닐 것입니다.

그것은 단지 낙관주의를 담은 터미널일 뿐입니다.

references

• AWS Compute Blog: Announcing Lambda MicroVMs
• AWS Compute Blog: Secure code execution for AI agents with AWS Lambda MicroVMs
• Firecracker: secure and fast microVMs for serverless computing

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위한 20달러(USD)를 원하신다면, 이 링크를 사용하세요.