AWS, Bedrock AgentCore Runtime Instances 소개: AI 에이전트 최장 14일 실행, GPU 사용, 한 인스턴스에서 다중 에이전트 협업

무슨 일이 있었나

AWS는 2026-09-30 자사 Artificial Intelligence 블로그에 Amazon Bedrock AgentCore Runtime Instances에서 다중 에이전트 음악 제작 파이프라인을 구축하는 방법을 설명하는 글을 게시했다. 여기서 AI 에이전트란 AI 모델을 이용해 맡은 작업을 스스로 수행하는 프로그램을 말한다. AWS에 따르면 AgentCore는 현재 AI 에이전트 호스팅을 위해 두 가지 컴퓨팅 옵션을 제공한다. 하나는 서버리스(서버를 직접 관리하지 않고 사용한 만큼 요금을 내는 방식) MicroVMs이고, 다른 하나는 '새 옵션'으로 소개된 Runtime Instances다. 후자는 AWS가 관리하는 EC2(AWS의 가상 서버) 인프라로, 지속적이고 장시간 실행되는 에이전트 워크플로를 겨냥한다.

AWS는 조직이 단일 목적 에이전트에서 다중 에이전트 시스템으로 옮겨 가면서 인프라 요구도 달라진다고 지적했다. 여러 에이전트가 며칠에 걸친 작업에서 컨텍스트(작업 내용과 맥락)를 공유해야 한다면, 몇 시간이 상한인 서버리스 세션(에이전트가 한 번 연속으로 작업하는 단위)만으로는 부족하다는 것이다. 글에는 Runtime Instances의 공식 출시일이 나와 있지 않다.

자세한 설명 보기

출처를 수집하고 독립적으로 검증한 뒤 Jev가 판단합니다.

MicroVM과 Runtime Instances는 무엇이 다른가

AWS에 따르면 두 옵션 모두 CrewAI, LangGraph, LlamaIndex, Strands Agents 등의 에이전트 개발 프레임워크를 지원하고, 기반 모델을 자유롭게 선택할 수 있으며, MCP 및 A2A와 통합된다. 차이는 주로 기반 컴퓨팅 모델에 있다. 아래 표는 AWS 글의 비교를 정리한 것이다. GPU는 AI 모델 계산에 널리 쓰이는 고성능 연산 장치이고, Amazon EBS는 서버에 연결해 데이터를 계속 보관하는 저장 공간이다. ODCR은 On-Demand Capacity Reservations(온디맨드 용량 예약)의 약자다.

AWS 설명에 따르면 핵심 메커니즘은 '공유 세션'이다. 용량 공급자(capacity provider)는 에이전트에 어떤 서버를 준비할지 AgentCore에 알려 주는 설정이다. 두 에이전트 runtime이 같은 용량 공급자를 사용하고 동일한 세션 식별자(runtimeSessionId)로 호출되면 같은 EC2 인스턴스에 배치된다. 이렇게 배치된 에이전트는 파일 시스템을 공유하며 서로의 산출물을 직접 읽을 수 있다.

AWS의 시연: 세 에이전트가 함께 곡을 만들다

• 작곡 에이전트: AWS에 따르면 Claude Sonnet 4.6으로 프로듀서의 요구를 음악 브리프로 바꾼다. 이어서 오픈소스 음악 생성 기반 모델 ACE-Step으로 인스턴스의 GPU에서 오디오를 생성한다.
• 딜리버리 에이전트: 공유 파일 시스템의 트랙을 읽어 측정한다. Claude Sonnet 4.6이 측정 결과를 바탕으로 이퀄라이징, 컴프레션, 리미팅 계획을 세우면, 이를 적용한 뒤 다시 측정해 목표 달성 여부를 확인한다.
• 컴플라이언스 에이전트: 완성본을 독립적으로 재측정하고 납품 목표를 점검한다. 스튜디오 자체 곡 라이브러리와의 화성 유사도도 비교한다. 유사성이 발견되면 작곡 에이전트를 다시 호출해 대체 버전을 생성한다.

AWS는 us-east-2 리전의 g6.xlarge 인스턴스에서 얻은 예시 결과를 공개했다. 모델 스택 준비 239초, 작곡 25초(NVIDIA L4에서 렌더링 8.98초, 최대 VRAM 7.63 GiB), 딜리버리 41초, 컴플라이언스 검사 28초였다. 다섯 단계 모두 같은 인스턴스에서 수행됐다. 음량 단위 LUFS와 피크 단위 dBTP로 보면, 딜리버리 처리 전 오디오는 -7.5 LUFS, 피크 0.42 dBTP였고 처리 후에는 -14.0 LUFS, 피크 -3.2 dBTP였다. 컴플라이언스 검사 결과는 'REVIEW REQUIRED'(검토 필요)였다. 이 수치는 AWS의 단일 시연 결과이며 독립적인 테스트가 아니다.

일반 독자와 기업에 미치는 실제 영향

이 변화가 일반 사용자가 일상적으로 쓰는 앱을 곧바로 바꾸지는 않는다. 다만 AI 에이전트가 '일문일답'에서 '여러 에이전트가 분업해 며칠에 걸쳐 긴 작업을 완수하는' 방향으로 나아가고 있음을 보여 준다. AWS는 이 아키텍처가 음악 전용이 아니며 3D 렌더링, 시뮬레이션, 모델 추론, 미디어 처리 등 GPU가 필요한 작업에 적용할 수 있다고 밝혔다.

AWS가 기업 팀에 강조한 이점은 세 가지다. 첫째, 각 팀이 다른 에이전트에 영향을 주지 않고 자기 에이전트를 업데이트할 수 있다. 둘째, 컨테이너와 코드 패키지가 같은 인프라에 공존할 수 있다. 셋째, 작업을 멈출 때 세션을 중지했다가 나중에 재개할 수 있다. 다만 이러한 장점은 현재 모두 AWS 자체의 주장과 시연에 근거한다.

아직 지켜볼 부분

• 현재 정보는 AWS 공식 블로그에서만 나왔으며, 성능과 비용에 대한 독립적인 제3자 검증은 아직 없다.
• AWS 글은 Runtime Instances의 공식 출시일이나 리전별 가용 현황 전체 목록을 제공하지 않았다.
• 시연의 곡 라이브러리 비교는 스튜디오 자체 라이브러리에만 사용됐다. 실제 저작권 검토에 적용했을 때의 효과는 더 지켜봐야 한다.

이 주제의 최신 뉴스 보기

• AI 뉴스