AI 에이전트가 오래 일하기 시작하자 인프라도 달라졌다

AI agent를 이야기할 때 가장 먼저 떠올리는 건 보통 모델이다. 어떤 모델이 더 잘 계획하는가? 더 많은 tool을 사용할 수 있는가? 더 복잡한 작업을 오래 이어갈 수 있는가?

그런데 agent가 실제 업무 안에서 오래 움직이기 시작하면 모델 바깥의 문제가 눈에 들어오기 시작한다.

작업이 없을 때도 resource를 계속 잡고 있어야 할까? 여러 session이 동시에 움직인다면 어떻게 나눠야 할까? 장시간 실행되는 작업의 memory는 어떻게 관리할까?

AWS가 공개한 새로운 Amazon Bedrock AgentCore Runtime은 바로 이런 문제를 전제로 설계됐다.

Chatbot과 agent workload는 운영 방식이 다르다

AWS는 최근 AI agent가 짧은 대화형 작업을 넘어 coding, system coordination, long-running work, event-triggered background task처럼 더 오래 실행되는 형태로 확장되고 있다고 설명했다.

AWS 공식 블로그에서 Amazon Bedrock AgentCore Runtime의 새로운 구조를 소개하는 화면

AWS는 AI agent가 long-running work와 event-triggered background task 등으로 확장되면서 새로운 AgentCore Runtime 구조가 필요해졌다고 설명한다.

출처: AWS

이 변화가 중요한 이유는 단순하다. 질문을 받고 몇 초 안에 답하는 chatbot과, 일정 시간 동안 여러 단계를 수행하는 agent는 운영 방식이 같을 수 없기 때문이다.

agent가 실제 workload가 되면 모델 호출만 관리해서는 끝나지 않는다. session을 어떻게 유지할지, 사용하지 않는 resource를 어떻게 회수할지, 필요할 때 다시 얼마나 빠르게 실행할지까지 함께 봐야 한다.

여기서부터 AI agent는 모델 기능이 아니라 하나의 운영 시스템에 가까워진다.

AWS가 이번에 공개한 AgentCore Runtime은 agent를 배포하고 실행하기 위한 managed compute 환경이다.

이번 변경에서 눈에 띄는 부분은 memory management다. AWS 설명에 따르면 새 runtime은 session이 사용을 마친 memory를 회수하도록 구조를 바꿨다.

또 container size나 agent concurrency가 달라져도 cold start 시간을 일관되게 유지하도록 설계했다고 밝히고 있다.

중요한 건 여기서 특정 성능 수치를 비교하는 게 아니다. AWS가 어떤 문제를 해결 대상으로 보고 있는지를 보는 편이 더 흥미롭다.

agent가 오래 움직이면 memory가 필요하고, 여러 session이 생기면 isolation과 resource 관리가 필요하다. 작업이 끝났다면 idle resource를 계속 유지할 이유도 줄어든다.

운영 지점	AWS 공식 설명	실무에서 볼 질문
Memory	사용이 끝난 session의 memory를 회수	장시간 작업의 resource를 어떻게 관리할 것인가?
Startup	container size와 concurrency가 달라도 cold start를 일관되게 유지하도록 설계	필요한 순간에 agent가 어떻게 다시 실행되는가?
Idle resource	workload가 없을 때 scale to zero	작업하지 않을 때 resource를 계속 유지해야 하는가?
Billing	실제 resource consumption을 기준으로 과금	agent 운영 비용을 무엇을 기준으로 볼 것인가?

AgentCore Runtime은 workload가 없을 때 scale to zero하며, 실제 resource consumption을 기준으로 과금하는 구조를 제공한다고 AWS는 설명한다.

이 부분은 agent를 일반적인 chatbot과 다르게 봐야 하는 이유를 잘 보여준다.

background task나 long-running agent는 항상 같은 강도로 일하지 않는다. 어떤 순간에는 많은 작업을 처리하고, 또 어떤 순간에는 아무 일도 하지 않을 수 있다.

그렇다면 infrastructure도 항상 켜두는 방식보다 실제 작업량에 맞춰 움직이는 구조가 더 자연스러울 수 있다.

물론 이것만으로 AgentCore가 다른 runtime보다 비용 효율적이라고 말할 수는 없다. 이번 Source가 확인해주는 것은 scale-to-zero와 resource consumption 기반 과금 구조까지다.

최근까지 AI agent 경쟁은 모델 capability 중심으로 설명되는 경우가 많았다. 더 오래 추론하는가? tool을 잘 사용하는가? 복잡한 업무를 스스로 나누는가?

하지만 agent가 실제 업무 시스템 안으로 들어오면 질문이 조금 달라진다.

이 agent를 안정적으로 오래 돌릴 수 있는가?

필요한 순간에 실행되고, 작업이 없을 때 resource를 줄이며, 여러 session을 운영하면서 memory를 관리할 수 있는가?

이런 문제는 모델 benchmark만으로는 설명하기 어렵다. 결국 agent가 worker에 가까워질수록 그 아래에서 돌아가는 runtime architecture도 제품의 일부가 된다.

AI agent를 실제 서비스나 업무 automation에 연결하려는 조직이라면 앞으로 모델 선택과 함께 runtime도 봐야 할 가능성이 크다.

agent가 얼마나 오래 실행되는가, session이 어떻게 관리되는가, idle 상태의 resource는 어떻게 처리되는가, 필요할 때 얼마나 빠르게 다시 실행되는가 같은 질문들이 함께 따라오기 때문이다.

AI agent 모델 아래에 session, memory, runtime, resource management 계층이 연결되는 구조 개념도

VECTORLOG 개념도. AI agent가 실제 workload가 되면서 모델 아래에 session, memory, runtime, resource 관리 계층이 함께 필요해지는 구조를 정리한다.

출처: VECTORLOG

AWS AgentCore Runtime은 그 흐름을 보여주는 하나의 사례다. 이것이 업계 전체의 표준이 됐다는 뜻은 아니다. 다만 AWS가 agent runtime을 별도의 managed compute layer로 설계하고 있다는 사실 자체는 주목할 만하다.

agent가 chatbot에서 worker로 이동할수록 경쟁의 중심도 모델 하나에서 더 넓은 시스템으로 이동할 수 있다.

모델은 여전히 중요하다. 다만 이제는 그 모델이 어디에서, 어떤 자원으로, 얼마나 오래, 어떤 방식으로 운영되는가?까지 같이 봐야 한다.