Google AX — 에이전트 실행을 위한 제어 계층

다른 이름: Google AX · AX · agentexecutor · Generative Workspace내용 검토: 2026. 09. 22.

결론부터

AX는 계산과 대기를 반복하는 에이전트 작업을 작은 실행 단위로 선언하고, 환경 준비·격리·중단과 재개를 대규모로 관리하려는 제어 계층이다

에이전트 하나를 실행할 때는 코드와 도구를 준비하면 된다. 이를 여러 사용자에게 제공하면 작업별 격리, 대기 중 자원 사용, 상태 보존, 수많은 작업의 생성과 회수까지 운영 문제가 된다. Google AX는 이 실행 기반을 공통화하는 오픈소스 오케스트레이터다. 이 페이지는 사내 플랫폼의 실행 계층을 비교하는 독자가 AX가 왜 나왔고, 어떤 요구에서 검토할 만한가를 판단하도록 돕는다. 설치 실습이나 도입 결정은 포함하지 않는다.

이 덱에 대입하면 직원의 등록·승인 요청은 사내 포털이 받고, 승인된 작업 명세를 AX에 전달하는 연결을 생각할 수 있다. AX는 그 명세를 하부 실행 시스템인 Agent Substrate에 전달해 샌드박스를 마련한다. 포털과 AX의 연결은 이 덱의 설계 해석이고, AX와 Substrate의 관계는 공식 아키텍처에 따른다.

이 장에서 처음 나오는 말3개

orchestrator: 작업 명세를 받아 실행 환경과 수명주기를 관리하는 제어 계층이다.
sandbox: 에이전트가 실행하는 코드의 영향을 다른 작업과 호스트로부터 격리하는 환경이다.
Agent Substrate: AX 아래에서 격리 실행과 작업 상태의 보존·복원을 담당하는 런타임이다.

탄생 배경: 실행 패턴과 규모가 바뀐다

대기 중에도 작업 상태가 필요하다

공식 소개의 탄생 배경은 Google 내부의 에이전트 실행 시스템 연구와 대규모 격리·재개·스케줄링 경험이 만났다고 설명한다. 특히 에이전트를 상태를 갖고, 짧게 집중해서 계산한 뒤 모델·도구·사람의 응답을 기다리는 작업으로 본다.

예를 들어 코드 수정 에이전트는 파일을 바꾸고 테스트한 뒤 검토를 기다린다. 기다리는 동안에도 실행 환경을 계속 점유하면 비용이 쌓이고, 환경을 버리면 수정 파일과 작업 맥락을 복원해야 한다. AX가 강조하는 방향은 대기 중인 작업의 상태를 보존하고 실행 자원을 다른 작업에 돌려주는 것이다. 공식 소개는 개발자뿐 아니라 많은 샌드박스에서 에이전트를 평가하고 실행 기록을 수집하는 연구자도 대상으로 삼는다.

작업 수가 늘면 제어 계층도 병목이 된다

작업 수가 늘면 제어 계층에도 문제가 생긴다. AX 설계 문서는 짧게 생성·삭제되는 작업 수백만 개를 Kubernetes의 Custom Resource Definition(CRD)으로 관리할 때 etcd 저장 용량과 쓰기 처리량이 병목이 될 수 있다고 설명한다. AX는 작업 상태를 Redis에 두고, Redis Streams의 이벤트를 여러 컨트롤러가 나눠 처리하는 구조를 선택했다. 이는 대량 작업을 관리하는 AX의 설계 근거이며, 모든 에이전트 서비스에 Kubernetes가 부적합하다는 뜻은 아니다.

설계 철학: 작은 실행 단위를 조합한다

Task를 에이전트가 조합하게 한다

AX는 에이전트의 전체 사고·위임 흐름을 하나의 고정된 실행 모양으로 정의하지 않는다. 쉽게 생성하고 격리하고 중단할 수 있는 작은 Task를 제공하고, 에이전트가 필요한 수만큼 조합하게 한다. 따라서 에이전트 하나와 Task 하나가 항상 일대일일 필요는 없다. 하나의 Task가 전체 작업일 수도, 여러 하위 작업으로 분해하는 시작점일 수도 있다. Task의 설계 의도

환경과 정책을 명세로 드러낸다

실행 준비도 명세로 드러낸다. 필요한 환경과 정책을 선언하고 플랫폼이 준비하게 하면, 각 에이전트 구현에 흩어진 설정 절차를 공통으로 관리할 수 있다.

선언 단위	담는 것	줄이려는 반복 작업
`Task`	실행 이미지·명령, 자원 제한, 환경·네트워크 참조	격리된 실행 환경을 생성하고 수명주기를 관리하는 일
`Workspace`	Git 저장소, MCP(Model Context Protocol) 도구 연결, 스킬	에이전트가 시작할 때마다 코드와 도구를 준비하는 일
`Gateway`	노출할 포트와 외부 접속 허용 목록	작업마다 네트워크 경계를 구성하는 일
`Model`	제공자·모델·생성 파라미터·인증 정보 참조	AX 구성요소가 사용할 모델 설정을 여러 곳에 복사하는 일

필드의 실제 형태는 공식 manifest 예제에 있다. Model을 선언하는 것만으로 사용자 에이전트의 모든 LLM 호출이 자동 통제되는 것은 아니다. 사용자 코드의 모델 사용 정책은 별도로 연결해야 한다.

선언형 인터페이스와 저장 구조를 분리한다

CLI와 YAML은 Kubernetes에 익숙한 사용자가 이해하기 쉽게 구성되어 있다. 다만 ax apply는 AX의 gRPC API로 명세를 보내며, 각 Task를 Kubernetes CR로 저장하는 방식은 아니다. 선언형 사용 경험과 내부 저장 구조를 분리한 선택이다. 제어 계층의 구조

자연어 환경 생성: 실행 준비를 플랫폼 기능으로 만든다

AX는 생성형 AI를 플랫폼 자체에도 사용한다. Workspace 연결에 goal로 원하는 환경을 설명하면, 첫 시작 때 에이전트가 도구와 의존성을 준비한다. 예를 들어 “Python 3 개발 환경을 준비해 줘”는 환경 준비의 입력이고, 작업 명령이 사용할 환경이 마련되는 것이 결과다. Generative Workspace 소개와 Workspace 계약이 이 기능을 설명한다.

따라서 자연어 기능은 실행 인프라를 쉽게 쓰게 하는 실제 제품 방향이다. AX 전체를 이해할 때는 그 입력 경험과, 만들어진 환경을 격리·유지·회수하는 실행 기반을 함께 봐야 한다. 문서에 명시된 스킬 준비와 연결을 근거로 “임의의 스킬을 자연어로 새로 작성해 주는 빌더”까지 AX의 보장 기능으로 확대해서 읽지는 않는다.

이 덱의 승인 모델에 적용할 때는 생성한 환경의 결과도 버전 관리 대상이다. 같은 자연어 목표를 다시 실행했다고 동일한 의존성이 설치되었다고 볼 수 없으므로, 승인한 도구·스킬·코드의 버전이나 내용 해시를 남긴다. 이는 AX의 자동 보장이 아니라 사내 플랫폼의 재현성 요구다.

중단과 재개: 무엇이 이어지는가

AX는 ax suspend와 ax resume을 제공한다. 현재 runner 계약은 /workspace를 보존하고 새 컨테이너에서 복원한다고 설명한다. 파일은 이어지지만 프로세스 트리는 새로 시작한다. 따라서 메모리 안에만 있던 진행 위치나 대화 상태가 자동 복구된다고 가정해서는 안 된다.

다음은 이 계약을 적용한 설명용 사례이며, 실제 실행 결과는 아니다.

코드 수정 작업의 상태	재개에 필요한 준비와 판단
저장소를 받아 파일을 수정했다	수정 파일이 보존 대상 Workspace에 있는지 확인한다
검토를 기다리며 중단한다	에이전트가 진행 기록과 다음 행동을 파일 등 지속 저장소에 남긴다
새 프로세스가 시작된다	에이전트가 저장된 기록을 읽어 다음 행동을 정한다
중단 전에 외부 API로 변경 요청을 보냈다	상대 시스템의 처리 결과를 확인하고, 중복 요청 방지는 업무 로직에서 다룬다

마지막 두 행은 파일 복원만으로 해결되지 않는 애플리케이션 책임이다. 이것이 workload lifecycle과 execution durability를 나누는 이유다. 샌드박스 재개 지원만으로 업무 단계 복구나 외부 부수 효과의 중복 방지가 해결되지는 않는다.

다른 솔루션과 무엇이 다른가

아래는 기능의 유무를 단정하는 순위표가 아니라 각 솔루션이 중심에 놓는 운영 단위와 책임을 비교한 표다. kagent는 이 덱이 다루는 0.x 계열, AgentCore는 Runtime의 microVM 실행 방식을 기준으로 한다.

비교 대상	중심에 놓는 책임	AX와 비교할 지점
Google ADK의 workflow	에이전트와 하위 에이전트의 실행 흐름 구성	에이전트 로직을 구성하는 층과, 그 코드를 실행할 환경을 제공하는 층을 구분한다
Kubernetes Job	Pod를 실행해 지정한 완료 조건을 충족	AX는 작업 환경 준비와 중단·재개를 공통 계약으로 제공하고, 작업 상태를 자체 제어 계층에 둔다
kagent 0.x	`Agent`·`SandboxAgent` 등의 CR을 통해 에이전트 실행 관리	AX는 작은 Task와 독립적인 gRPC·Redis 제어 계층을 중심에 둔다. 아래 실행 기반인 Substrate는 겹칠 수 있다
Amazon Bedrock AgentCore Runtime	AWS가 인프라·확장·세션별 microVM 격리를 관리	AX는 클러스터와 Substrate를 마련해 운영하는 오픈소스 선택지다. 관리 책임과 배치 제약을 함께 비교한다
Temporal	이벤트 이력과 replay로 Workflow 실행 상태 복구	AX의 환경·파일 복원과 업무 흐름의 복구는 서로 다른 책임이다

특히 샌드박스와 대기 자원 절감은 AX만의 기능이 아니다. kagent도 SandboxAgent와 AgentHarness를 통해 Agent Substrate를 사용한다. AX의 차별점은 이 기반 위에 어떤 실행 단위와 API를 노출하고, 대량 작업을 어떻게 관리하는가에서 찾아야 한다. kagent의 Substrate 연결

AX에 에이전트를 올릴 때도 연결 계약은 필요하다. 사용자 정의 이미지와 runner를 지원하지만, 이미지는 AX가 기대하는 실행 경로와 준비 상태 응답을 제공해야 한다. 기존 컨테이너 이미지를 아무 변경 없이 실행할 수 있다는 뜻은 아니다. 사용자 정의 runner 계약

사내 플랫폼에서 검토할 자리

이 덱에서 AX는 실행 계층을 이해하기 위한 비교 대상이다. 기존 runtime 후보를 교체하기로 한 결정은 아니다. 등록된 Agent의 정체성·승인·직원별 접근권한은 사내 control plane에 남긴다. AX의 Task는 실행 리소스이므로 회사의 Agent ID나 승인된 AgentVersion과 동일한 객체로 취급하지 않는다. 네트워크 허용 목록도 직원별 호출·업무 권한을 대신하지 않는다.

가령 저장소 수백 개의 코드 변경 작업을 운영한다면, 작업별 환경 구성과 격리를 재사용하는 가치가 있다. 사람을 기다리는 작업이 많다면 상태를 보존하면서 실행 자원을 반환하는 방식도 검토할 만하다. 이는 기능에서 도출한 적용 예시다. 도입 판단에는 실제 대기 비율, 복원할 상태, 재개 지연, Redis·컨트롤러·Substrate를 유지하는 비용을 함께 측정해야 한다.

기준 시점과 확인 범위

검토 기준은 2026년 9월 22일의 main 문서와 ax.io/v1alpha1 API 설명이다. README는 안정 버전 이전의 큰 호환성 변경 가능성을 명시한다. 공식 사이트의 수십억 작업·초 단위 미만 재개 수치는 프로젝트가 내세우는 확장성과 성능 주장으로 읽으며, 이 페이지에서 검증한 처리량이나 지연 보장으로 제시하지 않는다. AX 배포·성능 실험은 수행하지 않았다.