에이전트 VM을 계속 켜 둬야 할까? 구글의 대기·복원 설계

도구가 쉬는 동안 실행용 컴퓨터도 멈춘다

에이전트가 다음 답을 생각한다고 코드를 실행하는 VM까지 계속 일하는 것은 아니다. 구글의 Agent Compute Engine 설계는 이 차이를 이용한다. 실행 중인 명령이나 백그라운드 작업이 없으면 샌드박스가 신호를 보내고, 호스트는 상태를 저장한 뒤 자원을 회수한다. 다음 도구 호출이 오면 저장한 상태에서 재개한다.

모델 호출과 다음 행동 결정은 바깥의 하네스가 맡고, 셸·브라우저·코드 실행은 안쪽의 격리된 microVM이 맡는다. 에이전트 전체를 종료하고 처음부터 다시 시작하는 것과 다르다. 모델을 기다리는 시간에 실행 공간까지 상시 점유할 필요를 줄이는 설계다.

환경을 복원해도 사람의 답까지 대신할 수는 없다

작업을 재개하려면 파일과 실행 환경이 이어져야 한다. 10월 22일 발표는 장기간 이어지는 작업 공간과 에이전트 컨텍스트를 유지하기 위해 microVM별 Hyperdisk를 사용한다고 설명한다. 유휴 자원을 회수한다는 이유로 저장한 작업까지 버리는 구조는 아니다.

다만 VM의 복원과 업무 흐름의 진행은 별개다. 사용자가 배포 대상을 고르지 않아 작업이 멈췄다면, 실행 환경을 되살려도 그 선택은 여전히 필요하다. 하네스가 판단하고 샌드박스가 실행하는 구조인 만큼, 운영자는 ‘환경이 다시 실행 가능하다’와 ‘다음 행동이 승인됐다’를 구분해야 한다.

이전 작업을 이어도 접근 권한은 요청마다 적용한다

구글은 장기 자격증명을 샌드박스 밖에 두고 외부 연결을 중개한다. 이는 복원된 환경이 보관된 비밀키를 꺼내 곧바로 서비스에 접근하는 방식을 피하려는 설계다. Agent Gateway 문서는 신원, 승인된 도구·주소 목록, 접근 정책을 연결해 통신을 제어한다고 설명한다.

샌드박스의 격리는 실행 환경을 나누고, 게이트웨이의 정책은 무엇에 접근할 수 있는지를 정한다. 두 장치는 역할이 다르다. 데이터를 읽을 수 있는 권한과 업무를 변경할 수 있는 권한을 같은 것으로 취급해서는 안 된다.

현재 문서는 일부 런타임의 지원 확대와 토큰 관리 정책을 ‘coming soon’으로 표시한다. 새 인프라 발표에 함께 등장했다고 모든 환경에서 비용 제한까지 즉시 적용할 수 있는 것은 아니다.

관리형 서비스는 프리뷰 예정, Kubernetes 경로는 따로 있다

10월 26일 기준 고객용 Agent Compute Engine의 안내는 ‘향후 수개월 내 프리뷰’다. 내부에서 Gemini를 지원하는 상태와 외부 개발자가 자기 에이전트를 배포할 수 있는 시점은 구분해야 한다.

Kubernetes를 이미 운영한다면 Agent Substrate가 별도 검토 대상이다. 구글은 9월 15일 GKE에서의 제공을 발표했으며, 다른 Kubernetes 인프라에서도 실행할 수 있는 오픈소스 런타임이라고 설명한다. 유휴 실행을 멈추고 필요한 때 재개하는 접근을 공유하지만 관리형 Compute Engine과 같은 상품은 아니다.

도입 판단의 출발점은 현재 에이전트가 실제 도구 실행에 쓰는 시간과 모델·사용자 응답을 기다리는 시간을 나눠 보는 것이다. 대기가 길고 작업 상태를 오래 유지해야 한다면, 상시 VM의 크기뿐 아니라 중단·복원 방식도 비용 설계의 대상이 된다.