Google AX, 에이전트 오케스트레이션을 선언형으로

에이전트를 새로운 워크로드로 본 Google의 답

AX 소개 사이트는 에이전트 작업을 선언하면 격리된 실행 환경, 작업공간, 네트워크 경계와 모델 설정을 함께 배치하는 오픈소스 오케스트레이터를 제시한다. 저장소 이름은 google/ax이며 Apache 2.0 라이선스다. 가장 중요한 문장은 수십억 개를 실행할 수 있다는 홍보 문구보다 ‘에이전트는 마이크로서비스도 배치 작업도 아니다’라는 문제 정의다.

일반 API 서버는 같은 요청에 비슷하게 반응하고 계속 떠 있다. 배치 작업은 시작과 끝이 비교적 분명하다. 에이전트는 저장소와 도구를 붙잡은 채 모델 응답이나 사람 승인을 기다리고, 잠깐 계산한 뒤 다시 멈춘다. 외부 사이트를 호출하고 비밀정보를 써야 하며 잘못된 반복이 비용을 태울 수도 있다. AX는 이를 Task, Workspace, Gateway, Model 네 자원으로 나눈다. 공식 README는 아직 핵심 개념과 프로토콜이 바뀔 수 있는 초기 단계라고 경고한다.

Kubernetes를 닮았지만 관리 대상이 다르다

AX의 CLI는 apply, get, describe, watch, delete 같은 익숙한 명령을 제공한다. 그러나 Pod를 직접 정의하는 대신 Task에는 실행 목표와 격리 조건을, Workspace에는 Git 저장소·MCP 서버·스킬을, Gateway에는 허용할 외부 호스트를, Model에는 공급자와 자격증명을 적는다. 공식 Concepts 문서는 이 네 자원의 관계를 설명하고, Agent Substrate는 그 아래의 상태 보존형 actor 실행 기반을 맡는다.

Kubernetes의 선언형 관리와 닮은 점은 원하는 상태를 파일로 버전 관리한다는 것이다. 다른 점은 모델 호출, 유휴 대기, 작업공간 준비, 에이전트별 네트워크가 일급 자원이라는 데 있다. 따라서 AX를 ‘에이전트용 Kubernetes’로만 부르면 이해는 쉽지만, 아직 Kubernetes 위에 배포되는 초기 control plane이라는 현실도 같이 봐야 한다.

숫자보다 먼저 검증할 것

프로젝트는 cluster당 billions of tasks와 sub-second resume을 목표로 내세운다. 이는 제품 페이지와 README가 밝힌 설계 목표이지, 독립적인 대규모 운영 결과로 받아들여서는 안 된다. 실제 quick start도 Kubernetes cluster, ko, container registry, Agent Substrate Control API를 요구한다. 단일 개발자의 노트북 에이전트를 간단히 띄우는 도구라기보다 대규모 연구·평가·기업 플랫폼을 겨냥한다.

이 지점은 Claude 웹 MicroVM, 에이전트 클라우드가 보인다, RubyGems 사건, AI 에이전트 보안의 현실, 연구 에이전트는 왜 벤치마크에만 과적합하지 않나와 연결된다. 성능 좋은 모델만 고르면 끝나는 것이 아니라 실행 경계, 재현 가능한 환경, 정지 조건과 관찰 수단이 제품 품질을 결정한다.

한국 기업이 가져갈 설계 원칙

한국 기업이 AX를 즉시 표준으로 채택할 이유는 아직 부족하다. API가 v1alpha1이고 개념 변경 가능성이 명시돼 있으며, 별도 substrate와 Kubernetes 운영 역량도 필요하다. 대신 네 가지 분리는 바로 적용할 만하다. 작업 목표와 수명주기, 코드·도구가 있는 작업공간, 외부 통신 허용목록, 모델과 비밀정보 구성을 한 덩어리로 섞지 않는 것이다.

특히 금융·공공·제조 환경에서는 Gateway 같은 명시적 egress 정책이 중요하다. ‘인터넷 사용 가능’ 하나로 끝내지 말고 모델 API, 패키지 저장소, 고객 시스템을 구분해야 한다. 유휴 에이전트를 멈출 때 메모리와 파일 상태 중 무엇을 보존하는지, 재개 후 같은 권한이 유지되는지도 감사 항목에 넣어야 한다. AX가 성공하든 다른 구현이 이기든 이 운영 모델은 남을 가능성이 크다.

자주 묻는 질문

Q1: AX는 Google Cloud 관리형 서비스인가요?

A: 현재 공개된 것은 Google 조직의 Apache 2.0 오픈소스 프로젝트다. README의 quick start는 사용자가 Kubernetes와 관련 인프라를 준비하는 흐름이다.

Q2: Kubernetes를 대체하나요?

A: 아니다. 현재 AX control plane 자체가 Kubernetes에 배포되며, 그 위에서 에이전트 특화 자원을 제공한다.

Q3: 수십억 에이전트를 당장 운영할 수 있다는 뜻인가요?

A: 프로젝트가 제시한 설계 목표다. 독립 벤치마크와 실제 비용, 장애 복구 특성은 별도로 검증해야 한다.

Q4: 보안상 가장 중요한 자원은 무엇인가요?

A: 하나만 고르기 어렵지만 외부 통신을 허용목록으로 제한하는 Gateway와 untrusted code를 가두는 Task 격리가 출발점이다.

Q5: 국내 팀이 지금 할 수 있는 일은 무엇인가요?

A: 에이전트 실행 명세를 코드로 관리하고, 작업공간·네트워크·모델 자격증명·중단 정책을 분리해 작은 내부 평가부터 시작하는 것이 현실적이다.