목차
- Firecracker가 microVM을 1초 안에 띄우는 메커니즘
- 브라우저 자동화 백엔드 후보 3개와 비교 기준
- 콜드 스타트 — snapshot 복원이 워머 풀보다 빠른 이유
- 격리 — 왜 컨테이너가 아니라 microVM인가
- 비용 계산 — 10,000세션/일 시나리오
- 결정 — 어떤 워크로드에 뭘 골랐나
Firecracker는 AWS가 2018년 오픈소스로 공개한 microVM 전용 VMM(Virtual Machine Monitor)이다. KVM 위에서 동작하면서 일반 VM보다 훨씬 가볍게 뜬다. Lambda와 Fargate의 격리 계층이 내부적으로 쓰는 게 이거다. 2025~2026년 들어 AWS Bedrock AgentCore Browser Tool처럼 "AI 에이전트가 임의 사이트의 브라우저를 띄워야 하는" 워크로드가 늘면서, EC2 인스턴스 위에 Firecracker microVM을 다시 띄우는 구조가 다시 주목받고 있다.
이 글은 사내에서 브라우저 자동화 백엔드를 재설계하면서 후보 3개를 놓고 비교한 정리다. ECS Fargate에 Playwright 컨테이너 풀, Lambda + chromium 레이어, 그리고 EC2 .metal 위에 Firecracker microVM 풀. 1초 미만 콜드 스타트가 가능한 건 마지막 하나뿐인데, 운영 부담이 가장 크다. 항목별 비교 데이터와 손익분기점을 짚어본다.
Firecracker가 microVM을 1초 안에 띄우는 메커니즘
이처럼, Firecracker는 Rust로 작성된 VMM이다. 코드베이스가 5만 라인 미만이라 attack surface가 작다는 게 설계 의도다(출처: Firecracker GitHub README, v1.7 기준). 핵심은 두 가지 특성에서 나온다.
첫째, 시작 시간이 빠르다. 공식 벤치마크는 125ms 이내다. 일반 KVM 기반 VM이 수십 초 걸리는 이유는 BIOS/UEFI 펌웨어 에뮬레이션, PCI 디바이스 초기화, 부트로더, 커널 초기화를 다 거치기 때문이다. Firecracker는 이 단계를 거의 다 잘라낸다. PCI도 없고 USB도 없다. virtio-net, virtio-block, vsock 같은 최소 디바이스만 남긴다.
둘째, 메모리 footprint가 작다. microVM당 약 5MB 수준이다. 단일 호스트에 microVM을 수백 개 띄울 수 있다는 얘기다. 컨테이너의 vCPU/메모리 오버헤드보다 큰 차이는 아닌데, 격리 강도를 감안하면 효율이 좋다.
EC2 안에서 굳이 Firecracker를 띄우는 이유는 nested virtualization과 격리 비용 사이의 트레이드오프다. 컨테이너만으로 신뢰할 수 없는 코드(사용자 입력으로 띄우는 브라우저 세션)를 격리하기엔 부담스럽다. 컨테이너 탈출 취약점은 매년 나온다. CVE-2024-21626(runc)을 기억하는 사람이 많을 것이다.
물론, :::tip
EC2 일반 인스턴스에서는 nested KVM이 비활성화되어 있다. Firecracker를 직접 띄우려면 m7i.metal-24xl, c7i.metal-24xl 같은 .metal 인스턴스 타입을 써야 한다. 이 제약이 비용 구조 전체에 영향을 준다.
:::
브라우저 자동화 백엔드 후보 3개와 비교 기준
이처럼, 브라우저 자동화 서버를 운영하면서 콜드 스타트가 7초쯤 나오는 게 늘 거슬렸다. 사용자가 "이 사이트 스크린샷 떠줘"라고 하면, 워머 풀이 비어있을 경우 7초 기다리게 된다. AI 에이전트 응답 흐름에서 7초는 길다. 사용자가 한 번 더 입력을 보내거나 이탈한다.
후보 3개를 같은 기준에 올렸다.
- (A) ECS Fargate + Playwright 컨테이너 풀
- (B) Lambda + chromium 레이어
- (C) EC2 .metal + Firecracker microVM 풀(또는 매니지드 AgentCore Browser Tool)
게다가, 기준이 너무 많으면 비교가 흐려진다. 4개로 압축했다.
- 콜드 스타트 시간 (브라우저가 첫 페이지 로드 준비까지)
- 격리 수준 (멀티테넌트 안전성)
- 비용 (10,000세션/일 기준)
- 운영 부담 (패치, 장애 대응, 모니터링)
반면, 직전에 검토했던 후보 중에 Kata Containers + containerd를 잠깐 올렸다가 뺐다. 격리 수준은 비슷한데 brower-snapshot 같은 최적화 레이어가 부족했다. 이건 다른 워크로드에 더 맞는 것 같다.
콜드 스타트 — snapshot 복원이 워머 풀보다 빠른 이유
실제로, Firecracker의 핵심 기능 중 하나가 snapshot/restore다. v0.23부터 들어왔고, v1.0 이후 안정화됐다(출처: Firecracker Release Notes). 브라우저가 "특정 URL이 로드된 상태"까지 부팅된 메모리 이미지를 디스크에 떠두고, 요청이 들어오면 그 이미지를 mmap으로 복원한다. 부팅 자체를 안 하니까 빠르다.
그래서, 워머 풀 방식과의 차이를 짚을 필요가 있다. 워머 풀은 "이미 떠 있는 컨테이너에 새 페이지를 로드"한다. Chromium 프로세스가 살아 있어도, 페이지 렌더링은 매번 새로 일어난다. snapshot 복원은 "특정 페이지가 떠 있는 메모리 상태"를 통째로 복원한다. 페이지 렌더링조차 캐시한다고 보면 된다.
| 백엔드 | 워머 풀 워크플로우 | 콜드 스타트 | 1세션 메모리 |
|---|---|---|---|
| Fargate + Playwright | ~250ms | 5~7s | 약 1.5GB |
| Lambda + chromium | ~800ms | 3~4s | 약 1.0GB |
| Firecracker + snapshot | ~150ms | ~200ms | 약 256MB |
위 수치는 단일 노드 기준이다. 분산 환경에서 라우팅 오버헤드, ALB latency, S3에서 snapshot 가져오는 시간(스냅샷을 디스크에 미리 안 두면 발생)을 더하면 격차가 줄어든다. 실측에서는 Firecracker 경로도 첫 응답까지 400~600ms 정도 나오는 게 일반적이다.
체감상 가장 큰 차이는 "워머 풀이 비어있을 때"다. Fargate는 task 시작에 3~5초가 박혀 있어서 트래픽 스파이크에 약하다. Firecracker는 snapshot만 미리 떠두면 풀 크기를 0에서 100으로 늘리는 데 5초가 안 걸린다.
격리 — 왜 컨테이너가 아니라 microVM인가
AWS가 Bedrock AgentCore Browser Tool을 microVM 기반으로 만든 이유의 절반은 보안이다(여담이지만 이건 좀 의외였다 — 처음엔 성능 때문일 거라 짐작했다). AI 에이전트가 띄우는 브라우저는 사용자의 인증 토큰을 다루고, 외부 사이트의 임의 JS를 실행한다. 멀티테넌트 환경에서 이 워크로드를 컨테이너에 돌리는 건 부담스럽다.
컨테이너 격리는 cgroups + namespaces + seccomp 기반이라 커널을 공유한다. 호스트 커널 익스플로잇이 있으면 격리가 무너진다. Firecracker는 게스트 커널을 별도로 띄우니까 호스트 커널 attack surface가 훨씬 작다. VMM 자체도 jailer라는 별도 프로세스에 가둬져서 호스트 시스템콜 표면을 줄인다.
격리가 강하다고 "안전하다"는 보장은 아니다. 2023~2024년 사이 VMM 계열 취약점이 몇 건 보고됐다(CVE-2024-7264 등). 다만 격리 레벨은 컨테이너보다 한 단계 위라고 보는 게 합리적이다.
이처럼, 회사 환경에서 이게 결정적이었다. 사용자 인증 쿠키를 들고 임의 사이트를 띄우는 워크로드라, 격리 강도가 보통 우선순위 1번이 된다. 이게 아니었으면 Fargate로 끝났을 가능성이 크다.
비용 계산 — 10,000세션/일 시나리오
대략적인 계산이다. 한 세션이 평균 30초 지속하고, 동시 세션 피크가 300으로 잡히는 시나리오를 기준으로 했다(작성 시점 us-east-1 가격, 2026년 6월 기준).
| 백엔드 | 일 비용 | 비고 |
|---|---|---|
| Fargate (2 vCPU/세션) | $40~60 | 워머 풀 항상 유지 |
| Lambda (chromium 레이어) | $30~50 | 콜드 스타트 페널티 큼 |
| c7i.metal-24xl × 1 (Firecracker) | ~$96 | 동시 300세션 처리 가능 |
| AgentCore Browser Tool (매니지드) | 별도 단가 | 세션 시간 기준 과금 |
즉, 작은 규모에선 Lambda나 Fargate가 저렴하다. 동시 세션 수가 늘수록 .metal이 역전한다. 단일 c7i.metal-24xl에 microVM 500개까지 띄울 여유가 있다는 게 PoC 결론이었다. 동시 세션 1,000을 넘어가면 .metal이 비용 면에서도 유리해진다.
매니지드 서비스를 쓰면 이 손익분기점이 더 낮아진다. 운영 부담 비용(엔지니어 시간)을 고려하면 더 일찍 갈아탈 만하다. 다만 매니지드 서비스의 분당/세션당 단가가 직접 운영보다 비쌀 수 있어서, 트래픽 패턴에 따라 손익이 갈린다.
운영 부담 항목이 비교에서 가장 컸다. Firecracker는 매니지드 서비스가 아니다. jailer, vsock, snapshot lifecycle, microVM 헬스체크, 노드 단위 패치를 직접 짜야 한다. KubeVirt나 Kata Containers 같은 통합 솔루션이 있긴 한데, 안정성 검증을 더 해야 한다. 사내에 KVM 운영 경험이 있는 인원이 1~2명이라 부담이 컸다.
결정 — 어떤 워크로드에 뭘 골랐나
또한, 같은 비교 기준을 워크로드 특성에 대입했더니 결론이 셋으로 갈렸다.
- 동시 세션 50개 미만, 격리 요구 낮음 → Fargate. 운영 부담 가장 적다.
- 짧은 단발 호출, 격리 중간 → Lambda + chromium 레이어. 사용량 적으면 가장 싸다.
- 동시 세션 200개 이상, 멀티테넌트 격리 필수 → Firecracker 기반. 직접 운영이 부담되면 AgentCore Browser Tool.
회사 환경에서는 매니지드 옵션인 AWS Bedrock AgentCore Browser Tool로 PoC를 잡았다. 직접 .metal + Firecracker 스택을 운영할 인원이 부족하다는 게 컸고, 격리 강도를 포기할 수 없는 워크로드라 Fargate 회귀는 어려웠다.
이처럼, 다음에는 AgentCore Browser Tool의 실제 콜드 스타트, 동시 세션 한계, 분당 단가를 직접 측정해서 손익분기점을 다시 그려볼 생각이다.
관련 글
- Supabase Auth 소셜 로그인 완전 가이드 — Google·GitHub OAuth와 RLS 연동 3개월 회고 – Supabase Auth 소셜 로그인을 붙이는 데 첫 주를 통째로 날렸다. Google·GitHub OAuth부터 RLS 연동까지, 사이드…
- Lovable의 Google Cloud 5배 약속, 스타트업 클라우드 다년 계약의 실체 – Lovable이 Google Cloud에 사용량 5배를 약속한 다년 계약 뉴스가 화제다. AI 스타트업이면 무조건 다년 commit이 유리…
- Vite 만든 VoidZero가 Cloudflare로 간 이유 — 프론트엔드 인프라 지각변동 – Vite 만든 팀이 Cloudflare로 들어갔다. 번들러부터 테스트 러너까지 다 들고 갔다. 이게 무슨 의미인지 정리해본다.