구글이 기다리는 AI의 컴퓨터를 멈추려는 이유
구글의 에이전트 실행환경 설계에서 대기·상태 보존을 살펴보고, Firecracker와 AWS 문서로 복원 뒤 연결·고유성·비용을 따로 확인해야 하는 이유를 설명합니다.
구글은 10월 22일 공개한 Agent Compute Engine 설계에서, 에이전트가 도구 실행을 마치고 다음 응답을 기다릴 때 작업 상태를 보존한 채 실행 자원을 회수한다고 설명했습니다. 파일과 메모리를 남겨 다음 명령에서 이어가는 방식입니다. 구글의 기술 설명에 따르면 외부 고객용 프리뷰는 앞으로 수개월 안에 제공할 목표입니다.
여기에는 서로 다른 요구가 들어 있습니다. 일을 멈춘 컴퓨터에 연산 자원을 계속 배정하고 싶지는 않지만, 다시 시작할 때 이전 작업을 잃어버려서도 안 됩니다. 에이전트가 무엇을 답하는지뿐 아니라, 답변 사이에 무엇을 남겨 두는지가 서비스의 비용과 신뢰성을 가릅니다.
컴퓨터를 계속 켜 두는 대신 상태를 남깁니다
이 문제는 에이전트가 등장하면서 처음 생긴 것은 아닙니다. AWS 연구진이 2020년 NSDI 학회에 발표한 Firecracker 논문의 공개 초록은 여러 고객의 작업을 같은 하드웨어에서 실행하면서도 서로 격리하고, 실행에 드는 부가 비용은 줄여야 한다는 과제를 설명합니다. 연구진은 이를 위해 서버리스 작업에 맞춘 가상머신 관리 프로그램을 개발했다고 밝혔습니다.
microVM은 이런 작은 가상머신을 가리킵니다. 한 물리 서버의 자원을 나누어 쓰되 실행환경 사이에는 가상머신의 경계를 두는 방식입니다. 이 논문은 구글의 새 서비스를 평가한 자료가 아닙니다. 격리와 효율을 함께 확보하려는 문제가 이전 클라우드 기술에서도 중요했다는 비교 근거입니다. 이번 기사에서는 논문 전문이 아닌 공개 초록을 읽었습니다.
작업을 이어가는 데 필요한 장치는 스냅샷입니다. Firecracker의 공식 문서는 실행 중인 가상머신의 메모리와 장치 상태 등을 저장했다가 특정 시점의 작업을 복원하는 방식이라고 설명합니다. 저장한 파일을 바탕으로 필요한 메모리를 불러오고, 이후 바뀐 부분은 따로 다룰 수 있습니다.
따라서 작업을 기억한다는 말과 계속 계산한다는 말은 다릅니다. 파일을 보관하는 저장장치, 실행 중인 프로그램의 상태, 실제 명령을 처리하는 연산 자원을 나누면 기다리는 작업까지 같은 방식으로 붙잡아 둘 필요가 줄어듭니다. 다만 이것은 구조를 설명한 것이며, 특정 서비스의 절감률을 측정한 결과는 아닙니다.
복원된 컴퓨터 바깥에서는 시간이 흘렀습니다
스냅샷을 불러왔다고 해서 모든 것이 저장 당시처럼 작동하지는 않습니다. Firecracker 문서는 복원 뒤 기존 네트워크 연결이 유지된다고 보장하지 않으며, 스냅샷 파일의 인증과 암호화도 통합하는 쪽에서 마련해야 한다고 명시합니다. 저장 파일을 읽는 기능과 안전하게 보관·이동하는 운영은 별개의 책임입니다.
AWS의 Lambda SnapStart 안내는 다른 위험도 보여줍니다. 여러 실행환경이 같은 초기 스냅샷에서 시작하면, 초기화 때 만든 고유 식별자가 복제될 수 있습니다. 임시 인증정보나 저장된 시각은 다시 사용할 때 갱신해야 하며 네트워크 연결도 확인하고 필요하면 재설정해야 합니다.
이는 Google에서 같은 문제가 발생했다는 증거가 아닙니다. 스냅샷을 쓰는 별도 서비스가 공개한 운영 조건입니다. 그러나 작업을 남겨 두는 기술을 평가할 때 왜 복원 속도만으로 충분하지 않은지는 설명해 줍니다. 컴퓨터 안의 상태를 되돌려도 바깥 서비스의 연결과 정보 유효기간까지 되돌릴 수는 없기 때문입니다.
비용도 같은 방식으로 나누어 봐야 합니다. SnapStart 문서는 적용 조건에 따라 스냅샷의 보관·유지와 복원에 요금이 생길 수 있다고 안내합니다. 이 요금체계를 구글에 적용할 수는 없지만, 실행 중인 연산 자원을 줄였다는 설명을 전체 서비스가 무료라는 뜻으로 읽어서는 안 됩니다.
남길 작업과 남기지 않을 권한
구글은 이 설계에서 장기 사용자 인증정보를 실행환경 안에 두지 않고 외부 게이트웨이가 요청의 권한을 확인하도록 했다고 설명합니다. 작업 상태는 이어가되, 작업을 수행할 권한까지 같은 장소에 보관하지 않는 구상입니다. 실제 서비스의 보안성을 독립 시험한 결과가 아니라 회사가 공개한 설계입니다.
구글의 설명은 기다리는 동안의 연산 사용을 줄이는 데 초점을 둡니다. 공개 프리뷰의 실제 재개 시간, 총비용, 장애 상황의 동작은 이번 자료만으로 검증할 수 없습니다. Firecracker와 SnapStart 역시 이 서비스의 성능을 대신 증명하지 않습니다.
다음에 확인할 대상은 다시 켜진 컴퓨터가 단지 빨리 응답하는지가 아닙니다. 이전 파일을 정확히 이어 쓰는지, 오래된 연결을 새로 확인하는지, 지금 허용된 권한으로만 행동하는지입니다. 일을 기억하는 에이전트에는 상태를 잘 남기는 기술과, 그대로 남겨서는 안 되는 것을 구분하는 기술이 함께 필요합니다.