서버리스 AgentCore 런타임 위에서 무언가를 만들 때, 사실상 두 개의 숫자가 설계를 조용히 지배해 왔다. 세션에 예약해 둔 메모리, 그리고 이미지가 커서 치른 콜드 스타트다. 둘 다 장점을 보고 선택한 값이 아니라, 피해 가려고 설계한 고정 비용이었다. 2세대 런타임은 이 둘을 동시에 움직인다. 흔한 “what’s new” 메모보다 한 번 더 뜯어볼 가치가 있다.

2026년 9월 18일 AWS는 Amazon Bedrock AgentCore 안의 서버리스 마이크로VM 컴퓨팅인 AgentCore Runtime의 차세대 버전을 발표했다. 서버리스 모델 자체는 그대로다. 사전 프로비저닝 없음, 0으로 스케일, 하드웨어 수준 세션 격리, 사용한 만큼만 과금. 달라진 것은 메모리와 기동이 과금되고 타이밍되는 방식이다.

V2가 실제로 바꾸는 것

발표 내용을 기계적인 항목으로 줄이면 다음과 같다.

  • 메모리가 탄력적으로 바뀐다. 세션은 작은 프로파일로 시작하고, 워크로드가 필요로 할 때 메모리를 온디맨드로 할당하며, 더 이상 활발히 쓰지 않는 메모리는 세션이 끝날 때까지 붙잡아 두는 대신 세션 도중 회수한다. 예약한 피크가 아니라 실제 사용량에 과금된다.
  • 콜드 스타트가 평평해진다. 런타임이 에이전트 환경을 한 번 준비해 스냅샷으로 찍어 두고, 새 인스턴스는 전체 기동 시퀀스를 반복하지 않고 그 스냅샷에서 복원한다. 기동 시간이 더 이상 이미지 크기를 따라가지 않는다.
  • 서버리스 계약은 유지된다. 미리 데워 둘 인스턴스 없음, 0으로 스케일, 세션 간 하드웨어 강제 격리, 사용량 기반 과금.
  • 런타임 단위로 선택한다. 자동 업그레이드가 아니다. 런타임을 생성하거나 갱신할 때 platformVersion을 V2로 설정해야 한다.

핵심 숫자 두 개: 테스트에서 V2는 200MB에서 2GB까지의 컨테이너 이미지에 대해 P75 콜드 스타트 1.9~2.0초를 기록했고, 이는 V1의 5.4~30초와 대비된다. 그리고 과금되는 메모리는 이제 예약 상한이 아니라 세션의 실제 사용량을 따른다.

1
2
3
4
5
6
7

V1 (피크를 예약하고, 매 기동마다 재구성)
  시작: 인스턴스마다 전체 초기화 시퀀스 -> 콜드 스타트가 이미지 크기를 따라감
  메모리: 세션 내내 피크를 예약          -> 순간 스파이크여도 피크 값을 계속 지불

V2 (스냅샷 복원, 탄력 메모리)
  시작: 준비된 스냅샷에서 복원          -> 약 2초 P75, 200MB~2GB에서 평평
  메모리: 작게 시작 -> 온디맨드로 확장   -> 유휴분 회수, 실제 사용량만 지불

콜드 스타트 변화가 숫자보다 중요한 이유

V1에서는 새 인스턴스마다 기동 시퀀스가 반복됐기 때문에 콜드 스타트가 이미지에 담긴 양을 따라갔다. 그래서 이미지 크기가 곧 지연 레버가 됐고, 사람들은 그 레버를 세게 당겼다. 거의 쓰지 않는 ML SDK를 걷어내고, 헤드리스 브라우저를 빼고, 임포트 그래프를 짧게 유지하려고 모놀리식 서비스를 둘로 쪼개기도 했다. 이건 아키텍처가 원해서 한 결정이 아니라 p95를 지키기 위한 결정이었다.

스냅샷 복원은 기동 시간을 이미지 크기에서 분리한다. 그러면 그 의존성 다이어트가 선택 사항이 된다. 뚱뚱한 이미지 하나로 두는 편이 에이전트를 이해하고 배포하기 더 단순하다면, V2는 그걸 막던 주된 이유를 없애 준다. 전형적인 트레이드다. V1은 코드 명료성을 기동 속도와 맞바꾸게 했고, V2는 그 교환 자체를 대부분 없앤다.

메모리 변화는 먼저 과금 변화다

V1에서는 세션의 피크만큼 메모리를 예약하고 세션 내내 그 값을 지불했다. 임베딩 작업 몇 초 동안 2GB로 튀었다가 이후 20분을 200MB로 놀아도, 피크 비용을 처음부터 끝까지 물었다.

V2는 세션을 작게 시작해 온디맨드로 키우고, 유휴분을 회수한다. 즉 최악의 순간 값을 기준으로 정해 두던 그 파라미터가 더 이상 지배적인 비용 동인이 아니다. 곧바로 두 가지가 따라온다.

  1. 비용 모델의 모양이 바뀐다. “메모리 × 세션 지속시간(피크 기준)“이던 항목이 “세션 동안의 적분된 메모리 사용량"에 가까워진다. V1 모양으로 맞춰 둔 예산 알람은 엉뚱한 신호에 울린다.
  2. 사이징 감각의 의미가 바뀐다. 설정하는 메모리는 이제 “지불 대상"이 아니라 “확인해야 할 상한"이다. 비용을 위해 돌리는 다이얼이 아니다.

어떤 에이전트가 실제로 이득인가

지금의 에이전트V2가 하는 일
콜드 스타트 때문에만 다이어트한 뚱뚱한 이미지(ML 라이브러리, 브라우저, 큰 SDK)큰 이득: 기동 시간이 평평해지고 다이어트 압박이 대부분 사라짐
메모리가 버스트형(무거운 컨텍스트나 임베딩 후 유휴)이득: 조용한 구간에서 피크 값을 더는 지불하지 않음
작은 이미지, 일정한 메모리, 짧은 세션소폭: 맞는 판단이지만 마이그레이션할 이유는 아님
GPU 또는 8시간 초과 세션해당 없음: 그건 런타임 인스턴스이지 서버리스 마이크로VM이 아니다

놓치기 쉬운 지점

  • platformVersion은 런타임 단위이고 자동 업그레이드가 없다. 기존 런타임은 바꾸기 전까지 V1로 계속 돈다. 중요한 런타임 하나에서 먼저 켜고 측정한 뒤, 콘솔 클릭이 아니라 IaC로 전체에 적용하자.
  • 리전 커버리지가 부분적이다. 출시 시점에 V2는 us-east-1, us-east-2, us-west-2, eu-west-1, ap-northeast-1에서 제공된다. 다른 AgentCore 신기능과 마찬가지로, 설계 전에 내 리전을 먼저 확인하자.
  • 탄력적이라는 것이 무제한은 아니다. 세션은 여전히 작은 프로파일에서 시작해 온디맨드로 커진다. 순간 피크가 실제로 큰 워크로드는 설정 가능한 상한에 그대로 부딪힌다. 공들여 잡아 둔 메모리를 지우기 전에, 최대치와 상한 도달 시 동작을 확인하자. 회수 모델이 바꾸는 것은 무엇을 지불하는가이지, 스파이크가 한 번에 담을 수 있는 양이 아닐 수 있다.
  • 대시보드와 알람을 다시 맞추자. V1과 V2 사이에서 메모리 차원의 의미가 달라진다. 예약 피크 과금 기준으로 튜닝한 비용·활용도 알람은 전환 후 잘못 읽힌다. 연속성을 가정하지 말고 재기준화하자.
  • 이건 마이크로VM 경로이지 런타임 인스턴스가 아니다. GPU나 8시간 초과 세션 때문에 에이전트를 런타임 인스턴스로 옮겼다면 여기 해당 사항이 없다. V1과 V2는 서버리스 런타임의 두 세대다.

그래서 무엇을 할까

  1. 런타임 하나를 전환한다. 중요하지 않은 에이전트에서 platformVersion을 V2로 켜고, 프로덕션을 건드리기 전에 일주일간 콜드 스타트와 과금 메모리를 측정한다.
  2. 비용 모델을 다시 유도한다. V1에서 가져온 예약 피크 공식이 아니라 관측된 사용량으로. 알람도 그에 맞춰 갱신한다.
  3. 콜드 스타트만을 위해 했던 의존성 정리를 재검토한다. 더 뚱뚱한 이미지가 유지보수에 단순하다면, V2가 그 선택권을 돌려준다.
  4. 표준화 전에 리전과 상한을 확인한다. V2 리전 목록을 배포 매트릭스에 넣어 두자.

관통하는 요점은, V2가 아키텍처 결정인 척하던 두 가지 제약을 없앤다는 것이다. AgentCore 런타임 인스턴스 글은 서버리스 마이크로VM이 더는 맞지 않을 때 무엇 위에서 돌릴지를 다뤘다. 이번 글은 그 서버리스 마이크로VM 자체가 더 싸지고 빨라진 이야기이며, 이것이 “계속 여기에 남을지"의 계산을 바꾼다. 주변 경계는 AgentCore 서비스 맵과 durable 장기 실행 작업 패턴을 참고하자.