Google AX 프리뷰, 끊긴 에이전트를 이어 붙이는 런타임

Google Cloud가 2026년 5월 21일 Agent Executor를 공개했습니다. 약칭은 AX입니다. 발표문은 AX를 "에이전트 실행, 재개, 분산 배포를 위한 오픈소스 런타임 표준"으로 설명합니다. GitHub 저장소의 첫 릴리스 v0.1.0은 하루 앞선 2026년 5월 20일에 올라왔습니다. 2026년 6월 4일 취재 시점에는 저장소가 약 1.5천 개 star와 80개 fork를 표시했습니다.

이 뉴스는 새 모델이나 새 채팅 UI 발표가 아닙니다. Google이 꺼낸 대상은 에이전트가 몇 분짜리 대화형 도구를 넘어 몇 시간 또는 며칠짜리 작업자로 길어질 때 남는 운영 문제입니다. Google Cloud 발표문은 장시간 에이전트 워크플로가 장애, 연결 끊김, human-in-the-loop 확인, 세션 상태 충돌 때문에 운영하기 어렵다고 적었습니다. AX는 그 문제를 모델 밖의 런타임 레이어로 분리합니다.

GitHub README에서 AX는 Agent eXecutor의 약자로 설명됩니다. AX는 agentic loop를 조율하고, event logging으로 실행을 관리하고, local actor와 remote actor 사이의 통신을 맡습니다. 기능 목록에는 distributed runtime, resumption, skills/tools/agents 선택과 실행, auditing and policy, portability, model and harness agnostic 설계가 들어갑니다. built-in consistency 항목에는 single-writer architecture, event log, compatible platform에서의 advanced resumption이 따로 적혀 있습니다.

AX를 코딩 에이전트로 오해하면 발표의 무게가 흐려집니다. README는 AX가 managed service가 아니고, agentic framework가 아니고, Antigravity 같은 특정 harness도 아니며, 특정 모델 controller도 아니라고 못박습니다. Google이 정의한 위치는 "serving layer around harnesses"입니다. Claude Code, Codex, Antigravity, 사내 LangGraph agent 같은 실행 주체가 있다면, AX는 그 주체가 끊기고 다시 붙고 도구를 호출하고 로그를 남기는 경로를 감싸는 쪽에 가깝습니다.

발표문이 앞세운 다섯 가지 기능은 제품 구매 문구보다 운영 체크리스트에 가깝습니다. durable execution은 event log와 snapshotting을 통해 agent, harness, skill, tool, sandbox 같은 actor가 장애 뒤에도 이어서 실행되도록 하는 항목입니다. secure isolation은 코드 생성이나 멀티테넌트 데이터 처리를 할 때 component를 sandbox에 넣어 부작용을 좁히는 항목입니다. session consistency는 여러 component가 같은 세션 상태를 동시에 갱신할 때 single-writer 구조로 상태 손상을 줄이는 항목입니다.

connection recovery와 trajectory branching은 사용자 경험과 평가 방법에 직접 닿습니다. AX README의 CLI 예시는 클라이언트가 끊겼을 때 마지막으로 본 sequence number를 넘겨 서버가 이후 event를 replay하게 만드는 방식입니다. 이때 대화를 과거로 되감는 것이 아니라 놓친 응답을 따라잡습니다. 별도의 ax fork 명령은 특정 checkpoint에서 새 event log를 만들어 다른 실행 경로를 시험하는 기능으로 설명됩니다. 장시간 agent run을 운영하는 팀에게는 "처음부터 다시 시도"가 아니라 "어느 sequence 뒤부터 관찰하고 분기할 수 있는가"가 비용과 디버깅 시간을 가릅니다.

ax exec \
  --conversation d85a4b4e-c53b-4c84-b879-f10d905bce40 \
  --last-seq 12 \
  --resume

프로토콜 연결도 AX의 포지션을 보여줍니다. README는 remote agent 구현 방식으로 AX native AgentService, Google ADK agent, A2A protocol bridge, experimental Colab agents를 언급합니다. landing page는 MCP, A2A, 기타 agentic protocol 지원을 전면에 둡니다. Google Cloud 발표문은 LangChain/LangGraph, ADK, A2A를 지원 대상으로 열거했습니다. 한 vendor의 agent 앱을 쓰라는 메시지보다, 서로 다른 harness와 protocol을 같은 실행 통제면에 올리겠다는 메시지에 가깝습니다.

Kubernetes 이야기는 별도 축입니다. Google은 같은 발표에서 Agent Substrate를 언급했습니다. Substrate README는 이 프로젝트를 Kubernetes 위에서 agent-like workload를 더 높은 규모와 효율로 관리하는 시스템으로 설명합니다. 표준 Kubernetes가 장시간 떠 있는 service 수천 개에 맞춰져 있다면, Google은 agent workload가 외부 입력을 기다리며 쉬는 시간이 많고 수백만 개의 짧은 tool call chatter를 만들 수 있다고 봅니다.

Agent Substrate는 actor를 준비된 worker pod에 매핑하고, actor lifecycle의 create, destroy, suspend, resume, routing을 관리합니다. README에는 약 250개의 stateful actor session을 8개 physical pod 위에서 multiplex하는 demo 설명도 있습니다. 또 Claude Code와 Codex 같은 high-density stateful coding environment, MCP server sandbox, LangChain, ADK compatibility가 지원 범위로 적혀 있습니다. AX가 실행 로그와 runtime controller라면, Substrate는 그 actor를 어디에 올리고 어떻게 쉬게 했다가 다시 깨울지에 가깝습니다.

AX의 Kubernetes 배포 문서는 이 관계를 더 구체적으로 보여줍니다. manifests/README.md는 AX를 Agent Substrate 위의 isolated warm-standby actor로 배포한다고 설명합니다. worker는 boot 시 live snapshot을 만들고, 새 conversation이 시작되면 GCS에서 즉시 restore됩니다. 대화가 output을 더 내지 않으면 actor가 자동 suspend됩니다. 설치 절차에는 GEMINI_API_KEY, BUCKET_NAME, WorkerPool, ActorTemplate, ax-router가 등장합니다. 이 문서는 아직 개발자 preview 성격이 강하지만, Google이 "에이전트 런타임"을 Kubernetes 리소스와 snapshot 단위까지 내려서 보고 있다는 점은 분명합니다.

개발자에게 가장 가까운 변화는 평가 기준입니다. 지금까지 에이전트 도입 논의는 모델 이름, SWE benchmark 점수, IDE 안의 편의 기능으로 쉽게 좁혀졌습니다. AX 발표는 운영 질문을 앞으로 끌어냅니다. 실행이 4시간째 끊기면 어디서 이어 붙일 수 있는가. tool call은 누가 승인했고 어떤 event log에 남는가. 같은 세션 상태를 두 worker가 동시에 바꾸지 않는가. 재시도는 비용을 얼마나 다시 쓰는가. 사내 data plane에 남겨야 하는 workflow를 managed agent로 보낼 수 있는가.

보안 관점에서도 AX는 "agent가 tool을 부른다"보다 한 단계 아래를 다룹니다. README는 built-in planner가 bash tool을 가질 수 있지만, bash tool로 시작되는 실행에는 사용자 승인 confirmation flow가 필요하다고 적었습니다. Google Cloud 발표문은 secure isolation을 멀티테넌트 데이터와 코드 생성 상황에 연결했습니다. 이 조합은 agent policy를 프롬프트에만 넣는 방식보다 실행 경로에 controller와 sandbox를 두는 방식에 무게를 둡니다.

다만 프리뷰라는 사실은 기사 제목만큼 중요합니다. GitHub README 첫머리는 AX가 active early development 상태라고 경고합니다. core, resumption protocol, runtime specification을 다듬는 중이라 안정 릴리스 전 breaking change가 들어갈 수 있다고 적었습니다. 외부 pull request 수락도 core architecture 안정화 기간 동안 임시 중단되어 있고, bug와 feature request issue를 권장하는 상태입니다. 지금 AX를 production 표준으로 확정했다기보다, Google이 내부 경험을 공개 설계 검증으로 꺼내 놓은 단계로 읽어야 합니다.

커뮤니티 반응은 아직 초기입니다. 2026년 6월 4일 GeekNews에는 "Agent Executor - Google의 분산 에이전트 런타임 오픈소스" 항목이 올라왔습니다. 이 항목은 신뢰성, 안전성, 커스터마이징, 효율성, event logging, local/remote actor 통신을 요약했습니다. Hacker News에서 대형 토론으로 번진 흔적은 취재 시점에 확인하지 못했습니다. Reddit의 LLM 개발자 커뮤니티에서는 Cloudflare Agents, AWS Bedrock AgentCore, Claude Managed Agents, Agyn, Vercel 같은 runtime/agent platform과 함께 AX를 비교하는 글이 보입니다.

이 비교표에서 AX가 차지하는 칸은 self-hosted distributed runtime입니다. Cloudflare Agents는 Workers와 Durable Objects에 가까운 serverless agent runtime이고, AWS Bedrock AgentCore는 AWS IAM과 managed runtime에 무게가 있습니다. Claude Managed Agents와 OpenAI Codex류 제품은 agent harness와 사용자 workflow가 강합니다. AX는 그보다 낮은 층에서 "하네스와 모델을 가져오라, 실행과 상태와 감사는 runtime으로 묶자"는 쪽입니다.

팀이 지금 바로 확인할 질문은 세 가지입니다. 첫째, 현재 쓰는 agent workflow가 conversational assistant인지 long-running worker인지 분리해야 합니다. 10분 안에 끝나는 IDE 보조라면 AX 같은 런타임은 부담일 수 있습니다. 반대로 agent가 repository, ticket, browser, database, MCP server를 오가며 승인 대기를 포함한다면 event log와 resume은 제품 기능이 아니라 운영 요구사항이 됩니다.

둘째, 데이터와 실행 위치를 분리해서 봐야 합니다. Google Cloud 발표문은 AX가 on-prem infrastructure, proprietary workflow, compliance, self-managed compute를 원하는 팀에게 선택권을 준다고 설명했습니다. 관리형 agent API가 빠른 time-to-value를 주더라도, 코드 저장소와 고객 데이터와 내부 도구 호출을 모두 외부 control plane에 맡기기 어려운 조직은 self-hosted runtime을 검토합니다. AX는 그 논의를 Google 생태계 안으로 가져옵니다.

셋째, 표준 경쟁은 protocol 이름만으로 끝나지 않습니다. MCP와 A2A를 지원한다고 해서 production agent 문제가 자동으로 풀리지는 않습니다. tool discovery, credential boundary, approval, event replay, cost attribution, branch evaluation, sandbox snapshot이 함께 붙어야 합니다. AX 발표가 개발자에게 주는 직접 신호는 "프로토콜 다음에는 runtime semantics가 필요하다"입니다.

Google이 AX를 넓게 발표하면서도 README에 "will announce this project widely soon"이라고 남겨 둔 점은 약간 어색합니다. 저장소와 Cloud Blog는 이미 공개됐지만, 프로젝트 문구와 외부 PR 정책은 아직 초기 설계 검증 단계에 머물러 있습니다. 이 불균형은 도입 판단에도 그대로 적용됩니다. 관심 있게 읽을 만한 발표지만, 운영 표준으로 채택하려면 API 안정성, security review, protocol 호환성, Agent Substrate 의존성, Google Cloud 밖의 배포 경험을 따로 검증해야 합니다.

AX가 당장 모든 에이전트 팀의 기본 런타임이 된다는 뜻은 아닙니다. 그래도 이번 공개는 Google이 에이전트 경쟁을 모델, 앱, IDE에만 두지 않는다는 사실을 보여줍니다. 장시간 실행되는 agent가 실제 업무 시스템 안에 들어가면 장애 복구, 승인, 감사, 격리, 비용, state consistency가 사용자-visible 기능만큼 중요해집니다. Google AX 프리뷰는 그 문제를 오픈소스 runtime과 Kubernetes substrate로 끌어내린 첫 신호입니다.