AWS, 탄력적 메모리와 빠른 콜드 스타트를 위해 Bedrock AgentCore 런타임을 재설계

Amazon Web Services 발표했습니다 2026년 9월 18일에 새로운 AgentCore 런타임을, 이는 Amazon Bedrock AgentCore의 관리형 컴퓨팅 레이어를 재구성한 버전으로, 회사는 에이전트 세션이 메모리를 해제할 때 메모리를 회수하고 컨테이너 이미지 크기나 동시성에 관계없이 일관된 콜드 스타트 시간을 제공한다고 밝혔습니다.

AgentCore 런타임은 개발자에게 인프라를 구축하거나 유지관리하지 않고도 에이전트를 배포하고 실행할 수 있는 완전 관리형 환경을 제공하는 관리형 컴퓨팅 레이어입니다. AWS는 출시 이후 수천 개 팀이 이를 사용해 프로덕션 에이전트를 운영해 왔으며, 최초 버전은 세션 격리, 스케일 투 제로 동작, 사용량 기반 과금이라는 서버리스 기반을 구축했다고 밝혔습니다. 이 소비 모델은 그대로 이어져, 청구는 리소스 사용량에 따라 이루어지며 I/O를 대기 중인 유휴 CPU에 대해서는 비용이 부과되지 않고, 에이전트에 작업이 없을 때 플랫폼은 완전히 0까지 스케일 다운됩니다.

출시가 해결하는 문제들

원래 런타임에서는 세션이 할당된 메모리를 할당 순간부터 세션이 종료될 때까지 유지했으며, 그 사이에 메모리를 회수하는 것이 없었습니다. AWS는 이로 인해 장시간 실행되거나 급증하는 에이전트가 메모리를 사용하지 않게 된 후에도 높은 사용량에 대해 24시간 비용을 지불하게 되었으며, 이는 가끔 급증하지만 대부분의 시간은 유휴 상태인 에이전트에게 특히 큰 격차를 만든다고 설명했습니다.

시작 동작이 두 번째 과제였습니다. AWS에 따르면 이미 초기화된 환경에 배치된 세션은 100밀리초 미만에 시작하지만, 이를 보장하기 위해 환경을 충분히 따뜻하게 유지하려면 컴퓨팅 자원을 예약해 두어야 하므로 대부분의 세션은 새 환경을 부팅하고 이미지를 가져오며 첫 요청이 실행되기 전에 에이전트를 초기화하는 콜드 스타트로 시작합니다. 이 지연 시간은 이미지 크기와 동시성이 증가함에 따라 늘어나며, 가장 많은 세션이 몰리고 준비된 환경이 가장 적은 급증 트래픽 상황에서 가장 크게 나타납니다. AWS에 따르면 고객들은 여분의 환경을 준비해 두고, 메모리 할당을 최적화하며, 용량을 축소함으로써 두 문제를 해결했습니다.

AWS가 측정한 내용

플랫폼 자체가 콜드 스타트에 추가하는 영향을 분리하기 위해, AWS는 입력을 반환하고 모델이나 도구를 호출하지 않는 빈 에코 에이전트를 테스트했습니다. us-west-2에 있는 Amazon EC2 인스턴스의 파이썬 클라이언트가 VPC 피어링 없이 퍼블릭 인터넷을 통해 us-east-1의 에이전트를 호출했으며, boto3 SDK를 사용했기 때문에 각 클라이언트 측 측정에는 두 AWS 리전 간 왕복 시간과 플랫폼 자체 시작 시간이 포함됩니다. 회사는 기본 계정 할당량 내에서 두 런타임 버전과 다섯 가지 이미지 크기에 걸쳐 에이전트당 5,000개의 콜드 호출을 전송했습니다.

이와 같이 측정한 결과, AWS는 새로운 런타임이 200 MB 이미지부터 2 GB까지 이미지 크기에 관계없이 P75 콜드 스타트 지연 시간이 약 2초에 이른다고 보고했습니다. 반면 기존 런타임은 이미지 크기에 따라 지연 시간이 약 5.4초에서 거의 30초까지 증가했습니다. 에코 테스트에서 에이전트 자체 코드가 P75 기준 약 34밀리초에 실행되었으므로 측정된 시간 대부분이 플랫폼 시작 시간임을 알 수 있습니다. AWS는 사용자가 채팅을 열거나 처음 요청을 입력하기 시작할 때 세션을 시작함으로써 인터랙티브 에이전트의 시작 시간을 숨길 것을 제안합니다. 이렇게 하면 사용자가 첫 요청을 입력하는 동안 환경이 미리 워밍업됩니다.

새 런타임 작동 방식

새 런타임은 완전 프로비저닝된 풋프린트 대신 작은 메모리 프로파일에서 각 세션을 시작하고, 워크로드가 필요에 따라 접근할 때 추가 메모리를 할당하고 페이지 인합니다. 에이전트가 요청당 버퍼를 해제하거나 요청 사이에 캐시된 데이터가 만료되면, 플랫폼은 세션이 종료될 때까지 메모리를 유지하지 않고 회수합니다. AWS는 수십억 개 세션의 할당 패턴 분석을 기반으로 회수 동작을 조정했다고 밝혔습니다.

콜드 스타트가 변하는 이유는 각 에이전트가 한 번만 로드된 후 스냅샷에서 실행되기 때문입니다. 런타임이 생성되거나 업데이트될 때, AgentCore는 컨테이너를 실행하고 건강 상태를 보고할 때까지 기다린 뒤 실행 중인 환경의 스냅샷을 캡처합니다. 따라서 모델 아티팩트 로드와 정적 구성 가져오기와 같은 일회성 초기화가 이미 완료됩니다. 모든 새로운 인스턴스는 처음부터 초기화하는 대신 해당 스냅샷을 복원합니다. AWS는 런타임이 스냅샷에서 캐시와 일시적인 메모리를 제거해 컨테이너 이미지가 커져도 스냅샷 크기가 대체로 일정하게 유지되며, 이는 다양한 이미지 크기에서도 복원 지연 시간을 일정하게 유지한다고 설명했습니다.

청구 방식은 메모리 모델에 따라 변경됩니다. 새로운 런타임은 세션 전체 동안 전체 컨테이너 이미지를 메모리에 유지하는 대신, 에이전트가 실제로 사용하고 필요에 따라 로드하며 유휴 시 회수되는 메모리만 과금합니다. AWS는 이 변화를 GB‑시간이 크게 줄어든 상황에 높은 요율을 적용한 것으로 설명했으며, 대부분의 에이전트에서는 메모리 사용량 감소가 요율 상승보다 크기 때문에 비용이 감소한다고 밝혔습니다.

플랫폼 버전, 지역 및 제한 사항

개발자는 런타임을 생성하거나 업데이트할 때 platformVersion 필드를 V2로 설정하여 새로운 런타임을 활성화합니다. 이는 AgentCore 개발자 가이드에 명시되어 있습니다. V1이 기본값이며, 생성 시 필드를 생략하면 V1 런타임이 생성되고, 업데이트 시 생략하면 현재 플랫폼 버전이 유지됩니다. V2는 us-east-1, us-east-2, us-west-2, eu-west-1, ap-northeast-1에서 사용할 수 있습니다.

V2 생성 또는 업데이트는 환경을 준비하고 스냅샷을 만들기 때문에 런타임이 READY 상태가 되기까지 몇 분이 걸리며, V1 런타임은 몇 초 안에 준비됩니다. AgentCore는 컨테이너의 /ping 엔드포인트에서 첫 번째 정상 응답이 있을 때 스냅샷을 찍으며, 시작 후 120초 이내에 컨테이너가 정상 상태를 보고하지 않으면 생성이 건강 검사 오류로 실패합니다. 가이드에 따르면 V2는 현재 직접 코드 배포의 경우 총 환경 변수 크기를 1.5 KB, 컨테이너 에이전트의 경우 2.5 KB로 제한하고 있으며, V1은 4 KB였습니다. 또한 AWS CloudFormation 및 AWS CDK는 현재 platformVersion 설정을 지원하지 않습니다.

스냅샷은 런타임의 버전 및 엔드포인트를 따르며 직접 관리되지 않습니다. AgentCore는 엔드포인트가 버전을 가리킬 때 스냅샷을 준비하고, 엔드포인트가 해당 버전을 가리키지 않을 때 스냅샷을 삭제하며, 삭제는 최대 8시간(최대 세션 수명)까지 걸릴 수 있습니다. 이는 이미 스냅샷에서 실행 중인 세션이 종료될 때까지 계속되기 때문입니다. 세션은 전용 microVM에서 격리된 CPU, 메모리 및 파일 시스템 리소스로 실행되며 최대 8시간 지속하고, 비활성 상태가 15분 지속되면 종료됩니다. 그 후 microVM이 종료되고 메모리가 정리됩니다.

로드맵 및 시작하기

출시 이후 AWS는 다음과 같은 기능들을 예정하고 있다고 밝혔습니다: 온디맨드 버스팅이 가능한 메모리 바닥을 세션당 예약하는 약정 기반 기본 할인으로, 항상 활성 상태인 세션에 적합; 더 큰 RAM, vCPU 및 세션 스토리지; x86 microVM 지원; 메모리 스냅샷을 이용한 일시 중지 및 재개와 활성 세션이 종료되기 전에 상태를 직렬화하기 위한 런타임 훅; 그리고 무인 에이전트를 위한 범위가 지정된 ID를 제공하는 세션 컨텍스트 키.

AWS는 개발자들에게 AgentCore 개발자 가이드, GitHub에 있는 AgentCore 샘플 리포지토리, 그리고 사용자의 AWS 계정 내에서 새로운 런타임의 콜드 스타트 지연 시간을 보여주는 로드 테스트 예제를 참고하도록 안내했습니다.