Amazon Bedrock AgentCore Runtime V2, 콜드 스타트를 예측 가능하게 만들지만 비용은 여전히 검증이 필요하다

Amazon은 200 MB에서 2 GB에 이르는 컨테이너 이미지 전반에서 콜드 스타트가 약 2초 수준으로 유지된다는 인상적인 주장과 함께 Amazon Bedrock AgentCore Runtime V2를 출시했다.

이 결과는 익숙한 서버리스의 절충안을 뒤흔든다. 팀은 에이전트를 0까지 확장해 비용을 절감할 수 있지만, 다음 사용자는 환경이 시작되는 동안 기다려야 하는 경우가 많다. 인스턴스를 상시 가동 상태로 유지하면 지연은 줄어들지만, 유휴 상태일 수 있는 용량도 계속 유지해야 한다.

Runtime V2는 이 절충안의 양쪽을 겨냥한다. AWS에 따르면 각 환경을 새로 구축하는 대신 준비된 스냅샷을 복원한다. 또한 세션이 살아 있는 동안 사용하지 않는 메모리를 회수하며, 세션이 과거에 기록한 최고 사용량을 기준으로 과금하지 않는다.

이번 발표가 중요한 이유는 프로덕션 에이전트가 기존 요청 핸들러와 다르게 동작하기 때문이다. 에이전트는 모델을 기다리고, 도구를 호출하며, 파일을 처리하고, 긴 요청 흐름 전반에 걸쳐 작업 상태를 유지할 수 있다. 짧은 웹 트랜잭션을 중심으로 설계된 런타임은 이러한 대기 시간이 세션의 대부분을 차지할 때 리소스를 낭비할 수 있다.

AWS는 V2를 단순히 다른 에이전트 프레임워크가 아니라 이러한 인프라 불일치에 대한 해답으로 내세우고 있다. 핵심 경쟁은 스냅샷 기반의 사용량 민감형 실행 방식과, 예측 가능한 성능을 위해 상시 가동 상태를 유지하거나 최대 할당량을 보존하는 환경 간의 대결이다.

Microsoft와 Google도 컨테이너 시작 지연에 대한 각자의 해법을 이미 제공하고 있다. Microsoft는 예열된 세션 풀을 사용하며, Google은 최소 인스턴스와 시작 CPU 가속을 권장한다. Amazon의 새로운 주장은 일관된 시작 동작을 얻기 위해 팀이 영구적으로 예열된 용량을 유지할 필요는 없다는 것이다.

수치는 유망하지만, AWS 자체 벤치마크에서 나온 결과다. 구매자는 실제 초기화 코드, 버스트 트래픽, 메모리 압박, 리전별 용량, 전체 애플리케이션 지연 시간을 포괄하는 워크로드 수준의 증거를 여전히 필요로 한다.

Amazon Bedrock AgentCore Runtime V2가 실제로 바꾸는 것

Runtime V2는 에이전트 환경이 초기화를 수행하는 시점과 할당된 메모리가 과금 대상에 남아 있는 기간을 바꾼다.

Amazon Bedrock AgentCore Runtime은 AgentCore 내의 관리형 컴퓨팅 계층이다. 이는 에이전트 또는 도구를 격리된 microVM에서 호스팅한다. microVM은 CPU, 메모리, 파일시스템 리소스가 분리된 경량 가상 머신이다.

AWS는 2026년 9월 18일 V2를 발표했다. 개발자는 런타임을 생성하거나 업데이트할 때 platformVersion을 V2로 설정해 이를 선택할 수 있다. 현재 런타임 아키텍처에 따르면 V1은 기본값으로 유지된다.

첫 번째 주요 변화는 초기화와 관련된다. 개발자가 V2 런타임을 생성하거나 업데이트하면 AgentCore는 컨테이너를 시작하고 상태 확인을 기다린다. 이후 플랫폼은 실행 중인 해당 환경의 준비된 스냅샷을 캡처한다.

이후 인스턴스는 전체 시작 과정을 반복하는 대신 스냅샷을 복원한다. 라이브러리 로드, 정적 구성 가져오기, 모델 아티팩트 준비와 같은 일회성 작업은 따라서 첫 실제 요청이 도착하기 전에 수행될 수 있다.

스냅샷 방식 자체가 새로운 것은 아니다. AWS Lambda SnapStart 역시 초기화된 실행 환경을 복원해 시작 지연을 줄인다. AgentCore는 이 접근 방식을 사용자 지정 컨테이너와 상태 유지형 상호작용을 갖춘, 더 오래 지속되는 격리된 에이전트 세션에 적용한다.

두 번째 변화는 메모리 계측과 관련된다. V1은 에이전트가 버퍼를 해제하거나 캐시된 데이터를 더 이상 사용하지 않아도 세션이 끝날 때까지 할당된 메모리를 유지했다. 따라서 사용량은 해당 세션에서 기록된 최고 메모리 할당량을 따를 수 있었다.

V2는 더 작은 상주 메모리 사용량으로 시작하고 워크로드가 메모리를 사용할 때 이를 페이지 인한다. AWS는 애플리케이션이 메모리를 해제하거나 데이터가 콜드 상태가 된 뒤 플랫폼이 메모리를 회수한다고 설명한다.

현재 사용 규칙은 V2의 유휴 메모리가 120초 후 자동으로 회수된다고 명시한다. 메모리 과금에는 128 MB 최소 기준이 적용되며, 시스템 오버헤드도 측정 사용량에 포함된다.

CPU는 이미 소비량 중심 모델을 따랐다. 에이전트가 모델, 도구, 데이터베이스 또는 외부 API를 기다릴 때 백그라운드 프로세스가 활성 상태로 남아 있지 않다면 CPU 비용은 0까지 떨어질 수 있다. V2는 이러한 탄력성을 메모리에도 더 의미 있게 확장한다.

이러한 변화는 하나의 세션이 크게 다른 단계를 거칠 때 가장 중요하다. 문서 에이전트는 대용량 파일을 파싱하는 동안 메모리를 할당하고, 해당 버퍼를 해제한 뒤 모델 호출을 기다리며 수분을 보낼 수 있다.

최고 사용량 기준 모델에서는 파싱 단계가 세션의 나머지 기간 동안 메모리 사용량을 결정할 수 있다. V2에서는 이 임시 할당이 사라진 후 후속 사용량이 감소할 수 있다고 AWS는 설명한다.

AgentCore 세션에는 여전히 신중한 수명 주기 관리가 필요하다. microVM은 최대 8시간 동안 실행될 수 있고, 기본 비활성 타임아웃은 그보다 먼저 컴퓨팅을 중지할 수 있다. 애플리케이션은 임시 세션 메모리 외부에 영속 정보도 보존해야 한다.

따라서 이번 출시가 에이전트 컨테이너를 무제한 영구 인프라로 바꾸는 것은 아니다. AgentCore의 세션 경계를 유지하면서 관리형 환경의 효율성과 시작 동작을 바꾸는 것이다.

이 구분이 실제 긴장을 만든다. AWS는 준비된 용량과 연관된 응답성을 약속하면서도, 0까지 확장되는 실행 방식의 경제성을 유지하겠다고 말한다.

에이전트 워크로드가 기존 메모리 모델을 무너뜨린 이유

기존 모델은 에이전트 세션이 연산 폭증, 메모리 증가, 외부 대기를 번갈아 겪으며 장시간 유지되기 때문에 비효율적이 됐다.

일반적인 웹 요청은 대체로 짧고 이해하기 쉬운 수명 주기를 가진다. 요청이 들어오고, 애플리케이션 코드가 실행되며, 데이터베이스에 접근하고, 응답을 반환한 뒤 실행 환경을 해제한다.

에이전트는 임시 작업자에 더 가깝게 동작할 수 있다. 목표를 받아 모델을 호출하고, 여러 도구를 실행하며, 자료를 다운로드하고, 중간 파일을 만들고, 승인을 기다렸다가 나중에 다시 작업을 재개한다.

이 단계들은 런타임에 서로 다른 요구를 부과한다. 도구 호출 중에는 CPU가 거의 유휴 상태일 수 있다. 문서 처리는 짧은 메모리 피크를 만들 수 있다. 대화형 상호작용은 시작 지연에 민감한 반면, 무인 작업은 즉각적인 응답보다 비용을 우선시한다.

V1은 이미 세션 격리, 0까지 확장되는 동작, 소비량 기반 CPU 과금을 제공했다. 그러나 메모리 처리는 유용한 단계가 지난 뒤에도 할당량을 유지했다.

대규모 저장소를 검토하는 코딩 에이전트를 생각해 보자. 이 에이전트는 인덱스를 로드하고, 빌드 출력을 검사하며, 여러 도구 응답을 보관한 뒤 모델을 기다리기 전에 데이터 대부분을 해제할 수 있다.

원래 런타임에서는 메모리 피크가 이후 사용량에도 계속 영향을 미쳤다. 초기 할당이 세션의 사용량에 계속 붙어 있을 수 있었기 때문에 긴 세션일수록 그 영향은 커졌다.

AWS는 V2를 조정하면서 수십억 개 세션의 할당 패턴을 연구했다고 말한다. 이 발언은 폭넓은 내부 텔레메트리를 시사하지만, 회사는 분석의 분포, 방법론 또는 대표적인 워크로드 구성은 공개하지 않았다.

콜드 메모리를 회수하면 계측값이 에이전트의 변화하는 워크로드와 더 밀접하게 맞춰진다. 동시에 새로운 운영상 질문도 생긴다. 에이전트가 예기치 않게 다시 필요로 할 때 페이지 아웃된 데이터는 얼마나 빨리 돌아올 수 있을까?

AWS는 메모리가 필요에 따라 로드되고, 해제 시 회수되며, 콜드 상태가 되면 회수된다고 설명한다. 공개 발표에는 모든 워크로드 패턴에 대한 상세한 페이지 폴트 지연 시간이나 임계값이 제시되지 않았다.

이러한 누락은 대규모 재사용 캐시를 보유한 에이전트에 중요하다. 캐시를 회수하면 측정 메모리는 줄어들 수 있지만, 나중에 다시 구축하면 CPU를 소비하고 지연 시간을 늘리거나 네트워크 전송을 반복할 수 있다.

개발자는 실제로 폐기 가능한 할당과 이후 턴의 성능을 높이는 데이터를 구분해야 한다. 더 낮은 메모리 그래프가 전체 워크플로의 속도 향상이나 비용 절감을 자동으로 뜻하지는 않는다.

아키텍처는 애플리케이션 동작의 중요성도 높인다. 임시 버퍼를 해제하는 소프트웨어는 플랫폼에 메모리를 회수할 기회를 제공한다. 참조를 무기한 유지하는 프로세스는 런타임이 데이터가 불필요하다고 추론해 주기를 기대할 수 없다.

긴 에이전트 세션에서는 이러한 규율이 특히 가치 있다. AWS 문서에 따르면 각 microVM 세션에는 격리된 컴퓨팅, 메모리, 파일시스템 리소스가 할당된다. 중지된 세션은 나중에 새 컴퓨팅을 받을 수 있지만, 애플리케이션이 영속 세션 스토리지나 다른 내구성 있는 서비스를 사용하지 않는 한 임시 상태는 사라진다.

이 설계는 사용자 간 분리를 보호하지만, 개발자가 프로세스 내 메모리를 영구적인 지식 저장소로 취급하지 못하게 한다. 대화 기록, 학습된 선호도, 재사용 가능한 사실에는 microVM 외부의 내구성 있는 스토리지가 필요하다.

이 구분은 지식 집약형 에이전트에 특히 중요하다. 팀에는 프롬프트, 소스 문서, 테스트 결과, 런타임 변경 사항을 포괄하는 검색 가능한 운영 기록도 필요하다. 잘 관리되는 엔지니어링 지식 베이스는 이러한 맥락을 개별 실행 세션 이후에도 보존할 수 있다.

Runtime V2는 이러한 아키텍처상의 책임을 없애지 않는다. 일시적인 컴퓨팅 계층을 더 탄력적으로 만들며, 그 결과 일시적 작업 데이터와 내구성 있는 조직 지식을 분리하는 가치가 높아진다.

스냅샷 복원이 콜드 스타트 절충안을 다시 쓴다

핵심 개선은 컨테이너 이미지가 커져도 크기가 비교적 안정적으로 유지되는, 정리된 초기화 스냅샷을 복원하는 데서 나온다.

콜드 스타트는 새로 생성된 환경이 애플리케이션 작업을 처리할 준비가 되기 전까지의 기간이다. 여기에는 이미지 가져오기, 컴퓨팅 프로비저닝, 프로세스 시작, 종속성 로드, 초기화 코드 실행이 포함될 수 있다.

콜드 스타트는 서비스가 0까지 확장된 뒤 트래픽이 도착할 때 특히 눈에 띈다. 기존 환경이 모든 새 세션을 처리하지 못하는 갑작스러운 버스트 중에도 발생한다.

대형 에이전트 컨테이너는 문제를 더 악화시킬 수 있다. 여기에는 언어 런타임, 브라우저 종속성, 에이전트 프레임워크, 문서 파서, 머신러닝 라이브러리, 내부 도구가 포함될 수 있다.

Runtime V2는 이 경로를 바꾼다. AgentCore는 런타임 버전을 준비할 때 환경을 초기화하고, 그 상태를 캡처한 뒤, 이후 인스턴스에 해당 상태를 복원한다.

AWS는 플랫폼이 복원된 인스턴스에 필요하지 않은 캐시와 일시적 메모리도 제거한다고 말한다. 이 정리는 더 큰 컨테이너의 전체 상주 메모리 사용량에 따라 스냅샷 크기가 증가하지 않도록 설계됐다.

회사의 출시 벤치마크는 V1과 V2에서 에이전트당 5,000회의 콜드 호출을 전송했다. 이 테스트는 기본 계정 할당량 아래에서 다섯 가지 이미지 크기를 다뤘다.

V2는 200 MB 이미지부터 2 GB 이미지까지 약 2초의 P75 콜드 스타트 지연 시간을 기록했다. P75는 측정된 시작의 75%가 보고된 시간 이하로 완료됐다는 뜻이다.

같은 AWS 테스트에서 V1은 다르게 동작했다. P75 결과는 가장 작은 이미지에서 약 5.4초였고, 가장 큰 이미지에서는 거의 30초까지 증가했다.

이 수치는 단순한 퍼센트 개선보다 메커니즘을 더 흥미롭게 만든다. AWS는 테스트된 범위에서 이미지 크기가 복원 지연 시간을 좌우하는 의미 있는 요인이 아니게 된다고 주장하고 있다.

벤치마크는 코드가 P75 기준 약 34밀리초에 실행되는 에코 애플리케이션도 사용했다. 이 설정은 인프라 시작 시간을 분리해 측정하지만, 정교한 에이전트의 전체 실행 경로와는 닮아 있지 않다.

실제 에이전트는 각 모델 호출에 수초를 쓰는 경우가 많다. 또한 환경이 준비된 뒤 원격 도구에 연결하거나, 컨텍스트를 검색하고, 사용자를 인증하거나, 네트워크 연결을 설정할 수 있다.

플랫폼 시작 시간이 2초라는 것은 응답 시간이 2초라는 뜻이 아니다. 이는 에이전트 코드가 첫 요청을 받기 전 인프라가 추가하는 지연이 더 작고 예측 가능해진다는 의미다.

이러한 예측 가능성은 평균값보다 더 중요할 수 있다. 시작 지연 시간이 좁은 범위 안에 머물면 제품 팀은 로딩 상태, 타임아웃, 첫 토큰에 대한 기대치를 더 자신 있게 설계할 수 있다.

AWS는 사용자가 첫 프롬프트를 제출하기 전에 인터페이스를 열 때 세션을 시작할 것을 제안한다. 환영 문구와 입력 시간으로 남은 시작 구간의 상당 부분을 숨길 수 있다.

이 전략은 실용적이지만 수요 양상도 바꾼다. 인터페이스를 열기만 해도 메시지를 한 번도 받지 않는 세션이 생성될 수 있으므로, 팀은 이탈 세션과 불필요한 환경 생성량을 측정해야 한다.

스냅샷은 배포 측면에서도 고려 사항을 도입한다. 스냅샷 이전에 캡처되는 초기화 과정에는 만료된 자격 증명, 안전하지 않은 난수 상태, 사용자별 상태가 포함되어서는 안 된다.

정적 구성은 잘 맞을 수 있다. 시간에 민감한 시크릿과 세션별 신원 정보는 복원에 안전한 메커니즘으로 확보해야 한다. 헬스 체크 역시 단순히 네트워크 포트가 수신 대기 중인 상태가 아니라, 실제로 준비된 환경을 나타내야 한다.

따라서 스냅샷 모델은 일부 작업을 요청 시점에서 배포 시점으로 옮긴다. 팀은 더 빠른 인스턴스 생성을 얻는 대신, 캡처된 상태에 포함되는 항목을 감사해야 한다.

AWS는 사전 예열 풀 모델에 압박을 가하고 있다

Amazon의 경쟁력 주장은 단순히 더 빠른 컨테이너가 아니라, 모든 팀이 상시 예열 용량에 비용을 지출하지 않아도 일관된 시작 시간을 제공한다는 데 있다.

클라우드 제공업체들은 이미 콜드 스타트 지연 시간을 줄이는 여러 방법을 제공하고 있다. 대부분의 접근 방식은 더 빠른 응답을 위해 유휴 리소스, 운영 튜닝 또는 애플리케이션 제약을 감수하는 방식이다.

Microsoft의 Azure Container Apps는 dynamic sessions를 제공한다. 이는 사전 예열된 환경 풀을 사용해 격리된 세션을 밀리초 단위로 할당할 수 있게 한다.

이 모델은 코드 인터프리터와 일회용 샌드박스가 필요한 워크로드에 적합하다. 그 속도는 요청이 도착하기 전에 준비된 환경을 확보해 두는 데서 나온다.

Google Cloud Run은 더 광범위한 컨테이너 접근 방식을 취한다. 개발자는 컨테이너를 예열 상태로 유지하기 위해 minimum instances를 구성할 수 있으며, 시작 CPU 부스트로 초기화를 가속할 수 있다.

최소 인스턴스를 유지하면 콜드 스타트에 대한 노출은 줄어들지만 유휴 인스턴스가 비용을 추가할 수 있다. 시작 CPU 부스트는 애플리케이션을 로드하고 시작해야 하는 필요성을 없애지는 않으면서 초기화 경로를 개선한다.

Amazon의 V2 설계는 다른 지점에 위치한다. 런타임 스냅샷을 한 번 준비하고, 불필요한 상태를 제거한 뒤, 세션이 도착할 때 격리된 인스턴스를 복원한다.

비교가 절대적인 것은 아니다. 사전 예열 풀은 AWS가 보고한 약 2초의 P75 결과보다 더 낮은 할당 지연 시간을 제공할 수 있다. 예측 가능한 수요 상황에서는 더 명확한 용량 하한도 제공할 수 있다.

스냅샷은 트래픽이 간헐적일 때 더 강력한 스케일 투 제로 경제성을 유지한다. 장기간 사용되지 않지만 호출될 때는 일관되게 응답해야 하는 에이전트가 많은 팀일수록 그 가치가 커진다.

이 경쟁은 오랫동안 이어진 서버리스의 질문을 반영한다. 고객은 용량을 준비 상태로 유지하기 위해 비용을 내야 할까, 아니면 플랫폼이 적시 생성의 예측 가능성을 충분히 높여 예열 용량을 선택 사항으로 만들 수 있을까?

에이전트 워크로드는 이 질문을 더욱 첨예하게 만든다. 한 기업은 수백 개의 전문 에이전트를 운영할 수 있지만, 어느 순간 실제 작업을 처리하는 것은 그중 일부에 불과할 수 있다. 모든 환경을 예열 상태로 유지하는 것은 용량 낭비가 된다.

버스트 트래픽은 반대의 우려를 낳는다. 많은 세션이 동시에 시작되면 플랫폼은 동시성 페널티를 유발하지 않고 스냅샷을 신속히 복원해야 한다.

AWS는 V2가 동시성과 관계없이 콜드 스타트 지연 시간을 일관되게 유지한다고 말한다. 그러나 공개된 벤치마크 설명은 이미지 크기와 기본 할당량을 강조한다. 모든 동시성 수준이나 리전 조건을 공개하지는 않았다.

AgentCore를 평가하는 팀은 하나의 시작 시간 수치가 아니라 완전한 서비스 수준 목표를 비교해야 한다. 유용한 지표로는 꼬리 지연 시간, 첫 모델 토큰까지의 시간, 복원된 캐시의 동작, 시작 실패, 급격한 트래픽 급증 시 성능 등이 있다.

총 리소스 소비량도 비교해야 한다. 사전 예열 풀은 유휴 용량이 눈에 보이지만, 스냅샷 기반 서비스는 복원, 메모리 페이징, 네트워킹 또는 배포 변경 후 반복 초기화 과정에 비용을 숨길 수 있다.

이식성도 또 다른 요인이다. AgentCore는 컨테이너화된 애플리케이션을 수용하고 LangGraph, CrewAI, Strands Agents를 포함한 프레임워크를 지원한다. 그러나 런타임 제어, 세션 API, 신원 계층, 과금 모델은 AWS 전용이다.

Microsoft와 Google 역시 주변의 신원 관리, 모니터링, 스토리지, AI 서비스와의 통합을 장려한다. 따라서 경쟁적 선택은 콜드 스타트를 넘어선다.

이미 하나의 클라우드에 표준화된 기업은 벤치마크 우위보다 운영 일관성을 더 중시할 수 있다. 반면 지연 시간에 민감한 에이전트 플랫폼을 구축하는 팀은 모든 런타임을 직접 테스트할 수 있다.

AWS는 여전히 중요한 영업 논거를 얻는다. V2를 통해 스케일 투 제로가 더는 시작 지연 시간이 컨테이너 이미지와 함께 증가해야 함을 의미하지 않는다고 주장할 수 있다.

독립적인 워크로드가 이 결과를 재현한다면, 클라우드 구매자들은 유사한 애플리케이션에 예열 풀이나 최소 인스턴스가 여전히 필요한 이유를 경쟁 플랫폼에 요구하게 될 것이다.

벤치마크는 강력하지만 범위가 좁다

AWS는 신뢰할 만한 인프라 개선을 보여줬지만, 아직 모든 프로덕션 에이전트에서 더 낮은 총비용이나 예측 가능한 애플리케이션 지연 시간을 입증한 것은 아니다.

첫 번째 한계는 출처의 독립성이다. AWS가 런타임을 설계하고, 테스트 구성을 선택하고, 벤치마크를 실행하고, 결과를 공개했다.

함께 제공된 테스트 코드는 고객이 자신의 계정에서 실험을 재현할 수 있게 한다. 이는 유용하지만, 재현성은 여전히 리전, 할당량, 컨테이너 설계, 트래픽 형태, 각 실행 시점에 좌우된다.

두 번째 한계는 백분위수 선택이다. P75는 평균보다 더 나은 관점을 제공하지만, 지연 시간에 민감한 서비스는 흔히 P95나 P99 결과를 중심으로 계획한다.

안정적인 2초 P75는 더 느린 꼬리 이벤트와 공존할 수 있다. 이번 발표는 엄격한 사용자 대면 목표를 평가하는 데 필요한 전체 분포를 제공하지 않는다.

세 번째 한계는 워크로드의 단순성이다. 에코 테스트는 플랫폼 시작 시간을 분리하는 데 도움이 되지만, 프로덕션 컨테이너는 더 많은 초기화를 수행하고 더 많은 외부 연결을 만든다.

스냅샷 캡처는 일부 초기화를 포함할 수 있다. 그러나 모든 데이터베이스 연결, 자격 증명 교환, 네트워크 경로 또는 외부 종속성이 복원 직후 즉시 사용할 수 있음을 보장할 수는 없다.

네 번째 쟁점은 비용 해석이다. AWS는 V2가 V1보다 높은 리소스 요율을 부과하지만, 대부분의 에이전트가 충분히 적은 메모리를 사용하게 되어 총 청구액은 낮아질 것이라고 말한다.

이는 회사의 전망이지 보편적인 결과는 아니다. 할당을 거의 해제하지 않는 메모리 안정형 에이전트는 더 높은 V2 요율을 내면서도 절감 효과가 제한적일 수 있다.

일시적인 메모리 급증이 있는 에이전트는 더 유리한 사례다. 큰 버퍼가 일찍 사라지고 남은 세션이 작은 메모리 사용량으로 상당 시간을 보낼 때 절감 효과는 개선될 것이다.

팀은 동일한 트레이스를 대상으로 두 버전을 모두 테스트해야 한다. 초 단위 메모리 사용량, CPU 소비량, 세션 기간, 복원 지연 시간, 모델 비용, 스토리지 비용, 네트워크 전송량을 기록해야 한다.

과금 텔레메트리에도 주의가 필요하다. AWS는 모니터링 데이터가 지연될 수 있으며 집계와 조정 과정 때문에 권위 있는 청구 기록과 다를 수 있다고 말한다.

다섯 번째 우려는 캐시 변동이다. V2가 에이전트가 곧 다시 필요로 할 데이터를 회수한다면, 워크로드는 그 데이터를 재구성하는 데 추가 시간을 쓸 수 있다.

AWS의 120초 유휴 회수 규칙은 하나의 가시적인 임계값을 제공하지만, 모든 메모리 범주가 어떻게 동작하는지 완전히 설명하지는 않는다. 개발자는 해당 임계값을 넘는 턴 간격을 테스트해야 한다.

여섯 번째 우려는 스냅샷의 정확성과 관련된다. 애플리케이션은 시작 중에 난수 생성기, 자격 증명, 네트워크 클라이언트, 임시 파일, 백그라운드 스레드를 초기화하는 경우가 많다.

복원된 프로세스는 격리된 세션 간에 안전하지 않은 상태를 재사용해서는 안 된다. 팀은 라이브러리가 복원 후 어떻게 동작하는지 검증하고 세션별 신원 정보가 스냅샷 경계 이후에 전달되도록 해야 한다.

AgentCore는 격리된 microVM을 제공하지만, 애플리케이션은 여전히 사용자-세션 매핑을 책임진다. 클라이언트 백엔드는 한 사용자가 다른 사용자의 세션 식별자를 제공하거나 재사용하지 못하게 해야 한다.

운영상의 실패 가능성도 남아 있다. 할당량, 리전 용량, 비정상 컨테이너, 결함 있는 헬스 체크, 다운스트림 서비스 제한은 모두 사용자 경험을 좌우할 수 있다.

이 질문들 중 어느 것도 V2의 벤치마크를 무효화하지 않는다. 이는 유망한 플랫폼 결과와 프로덕션 도입 결정 사이의 격차를 정의한다.

올바른 결론은 조건부다. V2는 대형 이미지, 비용이 큰 초기화, 일시적 메모리 피크, 모델 또는 도구 대기 시간이 긴 버스티 에이전트에 특히 매력적으로 보인다.

메모리 사용량이 안정적이거나, 수요가 지속적으로 활성 상태이거나, 특수 프로세서를 사용하거나, 엄격한 1초 미만 요구 사항이 있는 에이전트는 더 폭넓은 비교가 필요하다. AWS 역시 이런 워크로드 일부를 위해 더 큰 컴퓨팅 옵션과 기준 용량 약정을 준비하고 있다.

V2의 승패를 결정할 세 가지 신호

다음 시험대는 고객 측정치가 AWS의 통제된 벤치마크 밖에서도 안정적인 시작 지연 시간, 더 낮은 총 청구액, 안전한 스냅샷 동작을 확인하는지 여부다.

첫 번째 신호는 독립적인 지연 시간 결과의 형태다. 개발자는 여러 리전과 트래픽 패턴에서 P50, P75, P95, P99 콜드 스타트를 공개해야 한다.

이미지 크기는 이 테스트의 일부로 남아야 하지만, 동시성도 그만큼 중요하다. 유용한 평가는 런타임이 스케일 투 제로된 후 격리 세션의 갑작스러운 파동을 시작하는 방식일 것이다.

이미지 크기와 동시성이 증가해도 꼬리 지연 시간이 안정적으로 유지된다면 AWS의 핵심 주장은 훨씬 강해진다. 대형 컨테이너가 더는 팀에게 여분 환경을 계속 실행하도록 강요하지 않게 된다.

P95와 P99 결과가 크게 달라진다면, 2초 P75라는 헤드라인의 운영상 가치는 낮아질 것이다. 대화형 에이전트를 운영하는 팀은 여전히 예열 용량이나 적극적인 세션 사전 생성을 필요로 할 것이다.

두 번째 신호는 완전한 세션 전반에서 측정된 비용이다. V2의 더 높은 리소스 요율은 경제적 결과가 런타임이 실제로 얼마나 많은 메모리를 회수하는지에 달렸다는 뜻이다.

팀은 알려진 단계가 있는 워크로드를 재실행해야 한다. 대표적인 테스트는 대형 문서를 파싱하고, 버퍼를 해제한 뒤, 여러 모델 호출을 수행하고, 120초를 넘겨 대기한 다음 재개하는 방식일 수 있다.

파싱 단계 후 계량 메모리가 감소하고 낮은 수준을 유지한다면, V2는 AWS의 비용 논거를 뒷받침한다. 소비량이 이전 피크 부근에 머문다면 예상 절감 효과는 약화된다.

비교에는 Runtime 요금 이상이 포함되어야 한다. 모델 추론, 관측성, 스토리지, 네트워크 전송, 컨테이너 스토리지, 브라우저 세션, 도구 서비스가 최종 청구액의 대부분을 차지할 수 있다.

이러한 더 넓은 관점은 작은 런타임 절감 효과가 극적인 애플리케이션 수준의 절감으로 제시되는 것을 막는다. 또한 더 빠른 시작 시간이 팀으로 하여금 불필요한 세션을 생성하도록 유도하는지도 드러낸다.

세 번째 신호는 AWS가 출시 예정으로 나열한 기능을 제공하는지다. 로드맵에는 약정 기준 용량 할인, 더 큰 컴퓨팅 및 스토리지, x86 microVM 지원, 강화된 수명 주기 제어, 세션 범위 신원 정보가 포함된다.

각 항목은 현재의 한계를 다룹니다. 더 큰 환경은 적격 워크로드의 범위를 넓힙니다. x86 지원은 다른 아키텍처로 쉽게 옮길 수 없는 종속성의 마이그레이션 부담을 줄입니다.

일시 중지 및 재개 제어 기능은 에이전트가 단일 컴퓨팅 수명 주기를 넘어 계속 실행되도록 도울 수 있습니다. 범위가 지정된 ID는 사람이 적극적으로 감독하지 않을 때 무인 에이전트가 무엇에 접근할 수 있는지를 명확히 할 것입니다.

AWS가 명확한 문서와 안정적인 동작을 갖춘 이러한 기능을 제공한다면, Runtime V2는 특정 콜드 스타트 최적화를 넘어 더 폭넓은 플랫폼이 될 것입니다.

지연이 발생한다면 현 릴리스의 한계가 드러날 것입니다. 일부 지속형, 특수 목적 또는 무인 워크로드는 여전히 다른 AgentCore 컴퓨팅 옵션이나 외부 인프라가 필요할 수 있습니다.

개발자는 통제된 V1-to-V2 테스트부터 시작할 수 있습니다. 에이전트 코드, 모델 호출, 트래픽 추적, 리전, 관측 가능성 설정은 동일하게 유지해야 합니다.

판단은 다섯 가지 결과에 근거해야 합니다. 시작 시간 백분위수, 세션 실패율, 시간에 따른 메모리 사용량, 전체 워크플로 지연 시간, 그리고 최종 클라우드 비용입니다.

대화형 제품은 AWS의 초기 세션 전략도 시험해야 합니다. 사용자가 채팅을 열 때 환경을 시작하면 시작 시간을 감출 수 있지만, 이탈한 세션은 분석에서 계속 확인할 수 있어야 합니다.

프로덕션 에이전트는 지속적인 CPU 작업을 수행하는 시간보다 대기하고, 상태를 유지하며, 도구를 조율하는 데 더 많은 시간을 쓰는 경우가 점점 늘고 있습니다. 이 때문에 전통적인 컨테이너 경제성은 많은 워크로드에 적합하지 않습니다.

Amazon Bedrock AgentCore Runtime V2는 기술적으로 일관된 해답을 제시합니다. 작업을 한 번 준비하고, 더 작은 스냅샷을 복원하며, 세션의 요구가 줄어들면 메모리를 해제합니다.

남은 질문은 실증적인 것입니다. Amazon Bedrock AgentCore Runtime V2는 귀사의 컨테이너, 트래픽 급증, 종속성, 보안 제어 환경에서도 이러한 이점을 유지할 수 있을까요?

두 플랫폼 버전에서 동일한 워크로드를 실행하고, 전체 지연 시간 분포를 보존하며, 정산 후 비용을 검토하십시오. 마이그레이션 결정은 출시 헤드라인이 아니라 그 증거에 따라 내려져야 합니다.