AI 에이전트 인프라
에이전트 세션 14일, 장기 실행 인프라가 바뀝니다
AWS가 관리형 EC2 기반 Runtime Instances를 공개했습니다. 공유 세션 최대 14일, 멀티에이전트 협업, GPU 가속의 공식 범위를 정리합니다.
이 글에서 다룰 내용
Runtime Instances의 핵심, 멀티에이전트 협업 방식, GPU·지원 리전·운영 체크포인트
이 글에서 다룰 내용
AWS AgentCore Runtime Instances의 의미, 최대 14일 세션 지속성이 필요한 이유, 멀티에이전트·GPU 지원 범위, 기업이 준비해야 할 에이전트 운영 전략
AI 에이전트의 공유 세션이 최대 14일 유지됩니다
기존의 AI 에이전트는 질문을 받으면 짧은 시간 안에 답을 만들거나, 정해진 도구를 몇 번 호출한 뒤 작업을 종료하는 방식이 일반적이었습니다. 하지만 실제 기업 업무는 그렇게 단순하지 않습니다.
시장 조사, 대규모 코드 분석, 복잡한 문서 검토처럼 며칠에 걸쳐 진행되는 일도 많습니다. 작업 도중 사람의 승인을 기다리거나 다른 에이전트의 결과를 받아야 하는 상황도 생깁니다.
AWS가 공개한 AWS AgentCore Runtime Instances는 이런 장기 작업을 겨냥한 Amazon Bedrock AgentCore Runtime의 보완형 컴퓨팅 옵션입니다. AWS가 관리하는 EC2 인프라에 여러 에이전트를 배포하고, 같은 호스트의 공유 세션을 최대 14일 유지할 수 있다는 점이 핵심입니다.
여기서 중요한 것은 단순히 서버가 오래 켜져 있다는 의미가 아닙니다. 에이전트가 중간 결과와 작업 맥락을 이어가며 복잡한 목표를 단계적으로 처리할 수 있는 지속 컴퓨팅 기반이 마련됐다는 뜻에 가깝습니다.
지속 컴퓨팅이 필요한 이유
AI 에이전트가 맡는 업무는 점점 길고 복잡해지고 있습니다. 예를 들어 소프트웨어 개발 에이전트라면 저장소를 분석하고, 코드를 수정하고, 테스트 결과를 확인한 뒤 다시 오류를 고쳐야 합니다.
리서치 에이전트도 여러 출처를 탐색한 후 자료를 비교하고, 부족한 정보를 추가로 조사해야 합니다. 중간에 사용자의 검토를 기다리는 시간이 포함되면 전체 작업은 몇 시간에서 며칠까지 이어질 수 있습니다.
이런 환경에서는 실행 제한 때문에 작업이 중단될 때마다 상태를 저장하고 다시 복원하는 과정이 필요합니다. 개발자는 복구 로직과 재시도 절차를 별도로 구현해야 하므로 시스템이 빠르게 복잡해집니다.
최대 14일 동안 유지되는 공유 세션은 이러한 부담을 줄여 줍니다. 세션을 중지했다가 다시 시작할 수 있어 유휴 시간의 비용을 관리하면서 장기 분석, 반복 테스트, 승인 대기처럼 시간이 필요한 워크플로를 구성하기 쉬워집니다.
멀티에이전트 협업도 현실적인 선택이 됩니다
하나의 AI 에이전트가 모든 일을 처리하면 역할이 많아질수록 프롬프트와 도구 구성이 복잡해집니다. 그래서 계획 담당, 조사 담당, 실행 담당, 검증 담당처럼 역할을 나눈 멀티에이전트 구조가 주목받고 있습니다.
AWS의 공식 예시는 코드 작성 에이전트와 코드 리뷰 에이전트를 같은 세션에 배치했습니다. 두 에이전트는 별도 메시지나 API 호출 대신 공유 파일 시스템을 통해 생성 코드와 리뷰 결과를 이어받았습니다.
이 과정은 각 에이전트의 처리 시간과 외부 도구의 응답 시간에 영향을 받습니다. 실행 시간이 짧으면 협업 도중 세션이 끝나거나 상태를 잃을 위험이 커집니다.
AWS AgentCore Runtime Instances를 활용하면 여러 AI 에이전트가 같은 호스트에서 역할을 나눠 일하는 구조를 설계하기 쉬워집니다. AWS 발표 기준으로 에이전트는 공유 세션 안에서 서로를 도구로 호출할 수도 있으며, CrewAI·LangGraph·LlamaIndex·Strands 등 다양한 프레임워크와 모델을 사용할 수 있습니다.
GPU 가속은 어떤 작업에 유용할까요?
모든 AI 에이전트 업무에 GPU가 필요한 것은 아닙니다. API 호출과 문서 정리가 중심이라면 CPU 기반 실행 환경으로도 충분할 수 있습니다.
AWS는 계산 집약적 작업을 위해 GPU 가속 인스턴스 유형을 지원한다고 밝혔습니다. 직접 운영체제에 접근해야 하거나 코드 컴파일, 보안 스캔, GUI 자동화처럼 지속 상태가 필요한 작업도 runtime instances의 대상입니다.
runtime microVMs와 runtime instances는 같은 AgentCore API 아래에서 독립적으로 또는 함께 사용할 수 있습니다. 예를 들어 빠르게 확장되는 경량 오케스트레이터는 microVM에, 지속 상태나 직접 OS 접근이 필요한 작업 에이전트는 runtime instances에 배치할 수 있습니다.
다만 GPU는 성능만큼 비용 관리도 중요합니다. AWS가 공개한 과금 구조는 표준 EC2 요금에 AgentCore 오케스트레이션 관리 수수료가 더해지는 방식이므로, 세션 중지·재시작과 CPU·GPU 자원 분리를 함께 설계해야 합니다.
AWS가 공식 확인한 제공 범위
출시 시점 기준 지원 운영체제는 Linux ARM64와 x86_64이며, Python 3.11부터 3.14까지의 네이티브 코드와 컨테이너 이미지를 지원합니다. 런타임은 기존 AgentCore의 API, 아이덴티티, 관찰성, 정책 통제와 통합됩니다.
초기 제공 리전은 미국 동부 오하이오·버지니아 북부, 미국 서부 오리건, 아시아 태평양 뭄바이·싱가포르·시드니·도쿄, 유럽 프랑크푸르트·아일랜드입니다. 리전과 지원 인스턴스는 바뀔 수 있으므로 실제 도입 전 공식 문서를 다시 확인해야 합니다.
이제는 에이전트 운영을 준비해야 합니다
실행 시간이 길어질수록 장애가 발생할 수 있는 지점도 많아집니다. 외부 API 오류, 잘못된 도구 호출, 반복 작업, 권한 문제, 예상보다 긴 대기 시간이 대표적입니다.
따라서 기업은 에이전트가 정상적으로 실행됐는지만 확인해서는 부족합니다. 현재 어떤 단계에 있는지, 어떤 도구를 호출했는지, 비용이 얼마나 발생했는지까지 추적해야 합니다.
특히 최대 14일 유지되는 공유 세션에는 작업 중단 조건과 승인 절차가 필요합니다. 최대 실행 시간, API 호출 횟수, 비용 한도, 재시도 횟수를 정하고 이상 행동이 감지되면 자동으로 멈추도록 구성해야 합니다.
이제 에이전트 운영은 일반적인 애플리케이션 운영과 비슷한 수준의 관찰성과 통제가 요구되는 영역입니다. 로그, 모니터링, 권한 분리, 비밀정보 관리, 실패 복구 전략을 초기 설계부터 포함해야 합니다.
14일 세션 시대가 바꾸는 것
Amazon Bedrock AgentCore의 변화는 AI 에이전트를 단순한 챗봇이 아니라 장기간 업무를 수행하는 디지털 작업자로 바라보게 합니다. 사람이 목표를 전달하면 에이전트가 여러 단계를 거쳐 결과를 만들고, 필요한 순간에만 승인을 요청하는 방식이 더 현실적으로 다가옵니다.
물론 오래 실행된다고 해서 더 정확한 결과가 자동으로 보장되는 것은 아닙니다. 명확한 목표와 도구 권한, 검증 절차, 비용 제한이 함께 마련돼야 지속 컴퓨팅의 장점을 제대로 활용할 수 있습니다.
AWS AgentCore Runtime Instances는 장기 세션, 멀티에이전트 협업, GPU 가속을 하나의 운영 관점에서 검토하게 만드는 계기입니다. 앞으로의 경쟁력은 에이전트를 만드는 기술뿐 아니라 안전하고 효율적으로 오래 운영하는 능력에서 갈릴 가능성이 큽니다.
한 줄 요약: AI 에이전트 공유 세션을 최대 14일 유지할 수 있는 시대에는 실행 시간보다 상태·비용·권한을 통제하는 운영 역량이 더 중요합니다.
