The new AgentCore runtime: Elastic, optimized, and consistently fast starts

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 사용량에 따라 메모리를 할당·회수하고 스냅샷으로 시작 시간을 일정하게 유지해, 장시간 실행되는 에이전트의 비용 효율과 응답성을 높이는 새로운 Amazon Bedrock AgentCore runtime을 발표했다.

📌 핵심 요약

• Amazon Bedrock AgentCore runtime은 에이전트 배포·실행을 위한 완전관리형 컴퓨팅 계층으로, 서버리스, 세션 격리, 사용량 기반 과금, 작업이 없을 때 실행 자원을 0으로 줄이는 기능을 제공한다.
• 새 런타임은 작은 메모리 사용량으로 세션을 시작하고 필요에 따라 메모리를 추가하며, 해제되거나 다시 접근할 가능성이 낮아진 메모리를 세션 종료 전에도 회수해 과금에 반영한다.
• 컨테이너 초기화와 정상 상태 확인 후 실행 환경의 스냅샷을 만들고 새 인스턴스에서 복원한다. AWS는 불필요한 메모리를 제거해 컨테이너 이미지 크기나 동시성에 관계없이 시작 시간을 일정하게 유지한다고 설명한다.
• 모델·도구를 호출하지 않는 에코 에이전트를 대상으로, 두 버전과 5개 이미지 크기에 걸쳐 에이전트당 5,000회의 콜드 호출을 측정했다. 리전 간 인터넷 왕복 시간을 포함한 P75 콜드 스타트 지연은 200 MB~2 GB에서 새 런타임이 약 2초였고, 기존 런타임은 약 5.4초에서 거의 30초로 증가했다.
• 새 런타임은 메모리 과금 단가가 더 높지만, AWS는 대부분의 에이전트에서 GB-hours 감소 폭이 단가 상승 폭보다 커 비용이 내려간다고 설명한다. 약정 기준 메모리 할인, 더 큰 RAM·vCPU·세션 스토리지, x86 지원은 향후 제공 예정이며, 제공된 원문은 x86 설명 도중 끝난다.

🧩 주요 포인트

1. 최대 사용량을 유지하던 메모리를 실제 필요에 따라 회수 → 장시간 실행되거나 사용량이 간헐적으로 급증하는 세션의 과금 부담을 줄일 가능성.
2. 초기화된 환경의 작은 스냅샷을 반복 복원 → 이미지 크기에 따른 시작 지연 변동을 줄이지만, 약 2초의 측정값은 모델·도구 호출을 제외한 에코 시험 결과.
3. 높아진 메모리 단가와 줄어든 GB-hours의 결합 → 실제 비용 효과는 사용 패턴에 따라 달라지며, 향후 기준 메모리 예약 옵션은 지속적으로 활성화된 세션의 비용 예측 가능성을 겨냥.

🧠 상세 정리

1. 대화형 실험에서 장시간 자율 작업으로

AWS는 에이전트가 실험 단계를 넘어 청구 처리, 코드 작성·검토, 시스템 간 작업 조율을 수행하고, 감독 없이 수 시간 동안 실행되는 상황을 새 런타임의 배경으로 제시한다. 초기 챗봇의 짧은 문답에서 여러 단계의 맥락을 유지하는 코딩 에이전트로 발전했고, 이제는 이벤트로 작동하며 작업 완료나 사람의 판단이 필요할 때만 모습을 드러내는 상시 에이전트로 확장되고 있다는 설명이다. 에이전트는 제품과 일상적인 기능에 내장되고 다른 에이전트에 의해 실행되면서 수와 활용 범위도 늘고 있다. Amazon Bedrock AgentCore runtime은 이런 에이전트를 인프라 구축·유지 없이 배포하고 실행하도록 지원하는 완전관리형 컴퓨팅 계층이다. AWS는 출시 이후 수천 팀의 프로덕션 사용 경험에서 확장 시 응답성, 세밀한 자원 할당, 실제 사용량에 맞는 비용에 대한 요구를 확인했다고 밝힌다.

2. 기존 서버리스 기반과 메모리 과금의 한계

기존 AgentCore runtime은 서버리스 실행, 세션 격리, 자원을 0까지 축소하는 기능, 사용량 기반 과금을 제공하며 다양한 에이전트를 지원해 왔다. 원문에 따르면 I/O를 기다리는 유휴 CPU에는 비용을 부과하지 않고, 에이전트가 작업을 처리하지 않을 때는 실행되는 자원도 지불할 비용도 없으며, 작업이 들어오면 필요한 용량을 확보한다. 그러나 기존 방식에서는 세션이 한 번 할당한 메모리를 종료 시점까지 유지해, 실제 사용이 줄어든 뒤에도 최대 사용량에 따른 비용이 이어지는 문제가 있었다. 이 방식은 메모리를 이후 요청에서 재사용해 다시 가져오는 지연을 피할 때는 유용하지만, 장시간 실행되거나 간헐적으로 사용량이 급증하는 에이전트에는 불리할 수 있다. AWS는 대부분의 시간에는 한가하지만 때때로 메모리를 많이 쓰는 에이전트에서 최대치에 대한 과금과 실제 사용량에 대한 과금의 차이가 특히 커진다고 설명한다.

3. 시작 시간의 변동과 사전 용량 확보의 부담

새 세션이 작업을 수행하려면 먼저 실행 환경이 준비되어야 하므로, 빠르고 예측 가능한 시작 시간은 특히 사람이 응답을 기다리는 대화형 에이전트에 중요하다. 기존 환경에서도 이미 초기화된 환경에 배치된 세션은 100밀리초 미만에 시작하지만, 하드웨어로 강제되는 세션 격리를 유지하면서 이를 보장하려면 준비된 컴퓨팅 자원을 여유분으로 확보해야 한다. 대부분의 세션은 새 환경 부팅, 이미지 가져오기, 에이전트 초기화를 거치는 콜드 스타트로 시작하며, 그 지연은 이미지 크기와 동시성이 커질수록 증가한다고 원문은 설명한다. 특히 트래픽이 몰릴 때 준비된 환경은 부족해지고 세션 요청은 늘어나므로, 사용자가 체감하는 지연의 불규칙성이 두드러진다. 고객은 이를 완화하려고 예비 환경 유지, 메모리 할당 최적화, 비용 절감을 위한 자원 해제를 직접 운영하지만, 이 방식은 복잡하고 비용이 들며 준비한 용량을 넘는 급증에는 한계가 있다.

4. 필요할 때 할당하고 사용이 줄면 회수하는 메모리

새 런타임은 전체 프로비저닝 용량을 처음부터 차지하는 대신 작고 효율적인 메모리 사용량으로 각 세션을 시작한다. 작업이 메모리에 접근하며 필요로 할 때 추가 메모리를 할당하고 페이지를 불러오므로, 실행 중인 세션의 실제 요구에 맞춰 메모리 사용량이 변한다. AWS는 수십억 세션의 할당 패턴을 분석해 한동안 사용되지 않았고 다시 접근할 가능성이 낮은 메모리를 회수하도록 런타임을 조정했다고 설명한다. 에이전트가 요청별 버퍼를 해제하거나 요청 사이에 캐시 데이터가 만료되면, 플랫폼은 해당 메모리를 세션 종료까지 계속 점유하지 않고 회수한다. 이에 따라 기존 런타임에서 최대 사용량을 따라가던 메모리 사용량과 과금이 새 런타임에서는 세션 수명 동안의 할당·회수 변화에 맞춰 움직이며, 세션 종료 시에도 메모리가 즉시 반환된다.

5. 초기화된 환경을 작은 스냅샷으로 복원

새 런타임의 시작 방식은 실행 환경을 한 번 준비한 뒤 스냅샷을 생성하고, 새 인스턴스마다 이를 복원하는 구조다. 런타임 인스턴스를 생성하거나 업데이트하면 AgentCore가 컨테이너를 실행하고 정상 상태 보고를 기다린 다음 실행 환경을 캡처하므로, 모델 아티팩트 로딩과 정적 설정 가져오기 같은 일회성 초기화 작업이 스냅샷에 반영된다. 이후 인스턴스는 부팅과 초기화를 처음부터 반복하지 않고 이미 준비된 환경을 복원해 실행을 시작한다. 실행 프로세스를 그대로 캡처하면 캐시와 임시 메모리가 스냅샷을 부풀릴 수 있지만, 새 런타임은 복원 후 재개에 필요한 작업 상태만 남기도록 초과분을 제거한다. AWS는 이 처리로 컨테이너 이미지가 커져도 스냅샷 크기가 대체로 일정하게 유지되며, 이미지 크기나 동시성에 관계없이 콜드 스타트 시간을 좁고 예측 가능한 범위로 유지한다고 설명한다.

6. 콜드 스타트 측정 조건과 성능 결과

AWS는 플랫폼이 콜드 스타트에 더하는 시간을 분리해 보기 위해 입력을 그대로 반환하고 모델이나 도구를 호출하지 않는 빈 에코 에이전트를 사용했다. us-west-2의 Amazon EC2 인스턴스에서 Python 클라이언트와 boto3 SDK로 us-east-1의 에이전트를 호출했으며, VPC 피어링 없이 공용 인터넷을 사용했다. 측정은 기본 계정 할당량 안에서 두 런타임 버전과 5개 이미지 크기에 걸쳐 에이전트당 5,000회의 콜드 호출로 진행했고, 클라이언트 측 수치에는 두 AWS 리전 사이의 왕복 시간이 포함된다. 이 조건에서 새 런타임의 P75 콜드 스타트 지연은 200 MB부터 2 GB까지 약 2초로 유지됐지만, 기존 런타임은 이미지 크기에 따라 약 5.4초에서 거의 30초까지 늘어났다. 따라서 이 결과는 해당 시험 조건에서 이미지 크기에 따른 지연 증가가 줄었음을 보여주며, 모델이나 도구를 사용하는 실제 에이전트의 전체 작업 시간을 직접 측정한 결과는 아니다.

7. 플랫폼 시작 시간과 사용자가 기다리는 시간

원문은 에이전트 코드가 첫 요청을 처리할 수 있도록 환경을 준비하는 시작 시간과, 에이전트가 실제 작업을 수행하는 시간을 구분한다. 프로덕션 에이전트에서 사용자가 경험하는 전체 경과 시간의 대부분은 에이전트 루프와 모델 호출에서 발생하며, 모델 호출은 각각 수 초가 걸리는 경우가 많다고 설명한다. 에코 시험에서는 에이전트 자체 코드의 P75 실행 시간이 약 34밀리초여서, 측정된 지연의 거의 전부가 플랫폼 시작 과정에 해당했다. 새 런타임의 효과는 이 플랫폼 부분을 빠르고 예측 가능하게 만드는 데 있으며, 특히 사람이 대화형 에이전트의 응답을 기다릴 때 의미가 있다. AWS는 사용자가 첫 메시지를 제출할 때까지 기다리지 않고 채팅을 여는 등 상호작용을 시작하는 순간 세션을 시작하면, 인사말을 보거나 입력하는 동안 환경이 준비되어 시작 지연을 거의 숨길 수 있다는 활용 팁도 제시한다.

8. 단가와 사용량의 관계 및 향후 기능

새 런타임은 메모리 과금 단가가 더 높지만, 전체 컨테이너 이미지를 세션 내내 메모리에 유지하는 대신 필요할 때 불러오고 유휴 상태에서 회수한 실제 사용량을 기준으로 과금한다. AWS는 대부분의 에이전트에서 GB-hours 감소 폭이 단가 상승 폭보다 커 최종 비용이 내려간다고 주장하며, 원문은 구체적인 단가나 절감률을 제시하지 않는다. 향후에는 현재의 소비량 기반 요금을 유지하면서 세션의 기준 메모리 용량을 예약하고 필요할 때 그 이상을 사용하는 기준 요금 옵션과 약정 할인을 추가할 예정이다. 이 옵션은 지속적으로 활성화된 세션의 비용 예측 가능성을 겨냥하며, 소비량 기반 요금은 사용량이 급증하거나 자원을 0까지 축소하는 작업에 더 큰 탄력성을 제공한다는 설명이다. 더 큰 RAM, vCPU, 세션 스토리지와 x86 지원도 향후 항목으로 제시되지만, 제공된 원문은 x86 지원 설명 도중 끊겨 그 이후의 세부 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 메모리 회수가 세션 종료와 분리되면서, 장시간 실행되는 에이전트도 세션을 유지한 채 사용량 감소를 과금에 반영할 수 있다는 점이 핵심 변화다.
• 스냅샷 최적화는 초기화 작업의 반복과 이미지 크기에 따른 복원 부담을 줄이는 접근이며, 성능 결과는 모델·도구 호출을 제외한 플랫폼 시작 경로의 개선으로 해석해야 한다.
• 비용 절감은 단가 인하가 아니라 과금 대상 메모리 사용량 감소에 달려 있으므로, 지속적으로 메모리를 많이 쓰는 세션과 간헐적으로 사용량이 급증하는 세션의 효과는 같다고 단정할 수 없다.

✅ 액션 아이템

• 장시간 실행되거나 사용량이 간헐적으로 급증하는 세션을 대상으로, 메모리 회수가 실제 사용량과 과금에 미치는 영향 검토.
• 약 2초의 P75 콜드 스타트 결과를 적용할 때 모델·도구 호출 제외와 리전 간 인터넷 왕복 시간 포함이라는 측정 조건 반영.
• 새 런타임의 높은 메모리 단가와 줄어든 GB-hours를 함께 비교하고, 지속적으로 활성화된 세션은 향후 기준 메모리 예약 옵션의 적합성 검토.

❓ 열린 질문

• 장시간 실행되거나 사용량이 간헐적으로 급증하는 세션에서 메모리 회수로 GB-hours가 얼마나 줄어드는가?
• 모델·도구 호출을 포함한 실제 에이전트에서 약 2초의 P75 콜드 스타트가 전체 응답 시간에 미치는 영향은 어느 정도인가?
• 향후 기준 메모리 예약 옵션은 지속적으로 활성화된 세션에서 소비량 기반 과금보다 어떤 조건에서 유리해지는가?