Google Just Made Serverless Agents Real
Part 2 of 5 — Google I/O 2026 Review
Every developer who has shipped an agent demo knows the feeling. The prototype works. The Loom video gets likes. Then someone asks: "Cool — how do I use this with 500 real users?"
That question kills most agent projects.
The gap between demo and production is not about prompts or tool definitions. It is about infrastructure — container orchestration, autoscaling policies, health checks, token budget enforcement, multi-turn state management, and log aggregation. The same gap that existed between "I wrote a web app" and "this web app handles 10,000 concurrent users" before EC2, Cloud Run, and Lambda showed up.
At I/O 2026, Google shipped the answer. The Managed Agents API does for agents what Cloud Functions did for serverless computing. Deploy, scale, monitor, pay per execution. No cluster. No YAML. One CLI command.
I called it the most consequential announcement from I/O in my Part 1 review. This post explains why.
The Demo-to-Production Gap
Building an agent is easy now. LangChain, CrewAI, AutoGen, Claude Code — pick a framework, define tools, write a system prompt, and you have a working prototype in an afternoon.
Running that agent for real users is a different discipline entirely. Here is what production demands that demos do not:
| Concern | Demo | Production |
|---|---|---|
| Scaling | Your laptop | 1 to 10,000 concurrent sessions |
| State | In-memory dict | Persistent multi-turn across sessions |
| Monitoring | Print statements | Token consumption, latency p95, error rates, cost attribution |
| Rollback | Ctrl+Z | Version pinning, canary deploys, instant rollback |
| Tool auth | Hardcoded API keys | Scoped service accounts, secret rotation |
| Cost control | "I'll watch it" | Per-agent token budgets, kill switches |
Most indie developers and small teams get stuck somewhere in this table. The agent works. The infrastructure to run it does not exist yet. So the project stays a demo.
Cloud Functions, But for Agents
Google's move is to compress that entire table into a managed runtime. The mental model is straightforward: if you have used Cloud Functions or Cloud Run, you already understand the deployment pattern. The difference is that the runtime is agent-aware — it understands tool call chains, token budgets, and conversation state natively.
Here is what a deploy looks like with the actual Agents CLI:
# Install Agents CLI
uvx google-agents-cli
# Scaffold for Cloud Run deployment
agents-cli scaffold enhance -d cloud_run
# Provision infrastructure
agents-cli infra single-project
# Deploy
agents-cli deploy
That replaces a Kubernetes cluster, an autoscaler config, a Prometheus stack, and a custom token-tracking pipeline. For a solo builder, this is the difference between "I need a DevOps hire" and "I need a terminal."
30+ Integrations Out of the Box
The tool registry ships with pre-built connectors. Not "we plan to support" — shipping in preview:
| Category | Integrations |
|---|---|
| Dev tools | GitHub, GitLab, Jira, Linear |
| Productivity | Notion, Google Workspace, Slack, Asana |
| Data | MongoDB, BigQuery |
| Payments & CRM | Stripe, Salesforce (via StackOne), HubSpot (via StackOne) |
| Cloud | GCP services (Cloud Storage, Pub/Sub, Cloud SQL) |
| Communication | Twilio (via StackOne) |
This matters because the hardest part of building a useful agent is not the LLM call — it is connecting the agent to the systems where work actually happens. A customer support agent that cannot read your ticket system or update your CRM is a chatbot, not an agent.
MCP Native — The Interoperability Play
The platform speaks Model Context Protocol natively. Two things follow from this:
First, existing REST APIs can be wrapped as MCP tools through Apigee without rewriting. If you have an internal API, you do not need to build a custom connector. Apigee generates the MCP schema, and the agent can call it like any other tool.
Second, tool definitions are portable to any MCP-compatible client. The platform is not model-locked at the protocol level. Your agent's tool definitions and conversation flows work with any client that speaks MCP.
This is a deliberate architectural choice. Google controls the runtime, the governance, and the registry. But the tool layer speaks an open protocol. That is a more nuanced lock-in story than "everything is proprietary" or "everything is open."
The Lock-In, Honestly
I want to be specific about what ties you to GCP and what does not.
Locked to GCP:
- The agent runtime itself — execution, scaling, health checks
- The governance layer — who can deploy, what tools an agent can access, audit logs
- The tool registry format — how connectors are packaged and versioned
Portable:
- Your prompts and system instructions
- Tool definitions (if you use MCP, they work elsewhere)
- Conversation flow logic
- The LLM choice (through MCP interoperability)
The pattern is familiar from Cloud Functions: your function code is portable, but the trigger bindings, IAM policies, and monitoring integrations are not. You can move your logic. You cannot move your operational wrapper.
Worth pricing in before going all-in. Especially if you are an indie developer building on a platform that could change pricing or terms — which, as Google demonstrated the same day with Gemini CLI, is not a theoretical concern.
Agent-First: What Antigravity 2.0 Signals
The Managed Agents API did not arrive in isolation. Antigravity 2.0 — Google's next-generation development platform — explicitly treats agents as first-class deployment targets with versioning, rollback, and observability. A demo showed an OS built by 93 agents over 12 hours, plus a playable Doom clone, with agent-driven development.
The execution had problems (forced updates broke existing projects — I covered this in Part 1). But the directional signal is clear: Google sees agents not as a feature of its cloud, but as a deployment primitive alongside containers and functions.
That is new. AWS has SageMaker endpoints and Bedrock agents, but neither ships a dedicated agent CLI. Azure has AI Studio, but it lives in a separate portal. Google is among the first major clouds to ship a purpose-built agents-cli that takes an agent from scaffold to production in four commands.
What This Means for Indie Developers
Here is the before-and-after for a solo builder who wants to ship a production agent:
Before Managed Agents API:
- Write agent logic
- Containerize (Dockerfile, multi-stage builds)
- Set up Kubernetes or Cloud Run
- Configure autoscaling policies
- Build token tracking and cost monitoring
- Implement health checks
- Set up log aggregation (ELK, Datadog, etc.)
- Handle multi-turn state persistence
- Manage secret rotation for tool credentials
- Build a deployment pipeline
After:
- Write agent logic
agents-cli deploy
Steps 2-10 are not eliminated — they are absorbed by the platform. The same compression Cloud Functions brought to backend workloads now applies to agents.
One caveat: the API is in preview. Pricing is not finalized. Production SLAs are not published. I would not migrate a revenue-critical agent today. But for new projects, the build-vs-buy calculation just changed fundamentally.
The Bigger Picture
Google I/O 2026 had a clear thesis: agents are infrastructure now, not experiments. The Managed Agents API, Antigravity 2.0's agent-first deployment, and the 30+ pre-built integrations all point the same direction — the "cool demo" era of AI agents is ending. The "runs in production at scale" era is starting.
For indie developers, the barrier just dropped from "hire a DevOps team" to "learn one CLI command." That is not hype. That is Cloud Functions, 2016, happening again.
Part 3 of this series covers Gemini Omni — the learned physics engine for video that stopped the room at I/O. Follow me on dev.to to catch it when it drops.
If you are building agents and evaluating managed platforms — or if you have tried the preview — I would like to hear your experience. Comments or GitHub.
Sources:
한국어 번역
구글이 서버리스 에이전트를 현실로 만들었다
5편 중 2편 — Google I/O 2026 리뷰
에이전트 데모를 만들어 본 개발자라면 그 기분을 안다. 프로토타입은 돌아간다. Loom 영상에 좋아요가 붙는다. 그런데 누가 묻는다: "좋은데 — 500명 실사용자에게 어떻게 쓰죠?"
이 질문이 대부분의 에이전트 프로젝트를 죽인다.
데모에서 프로덕션까지의 간극은 프롬프트나 도구 정의 문제가 아니다. 인프라 문제다 — 컨테이너 오케스트레이션, 오토스케일링, 헬스 체크, 토큰 예산 관리, 멀티턴 상태 관리, 로그 집계. "웹앱을 만들었다"와 "이 웹앱이 1만 명 동시 접속을 처리한다" 사이에 있던 간극과 같다 — EC2, Cloud Run, Lambda가 등장하기 전까지.
I/O 2026에서 구글이 답을 내놨다. Managed Agents API는 Cloud Functions가 서버리스 컴퓨팅에 한 일을 에이전트에 한다. 배포, 스케일, 모니터링, 실행 단위 과금. 클러스터 없이. YAML 없이. CLI 명령 한 줄.
Part 1 리뷰에서 I/O의 가장 중대한 발표라고 했다. 이 글에서 그 이유를 풀어본다.
데모-프로덕션 간극
에이전트를 만드는 건 이제 쉽다. LangChain, CrewAI, AutoGen, Claude Code — 프레임워크 하나 골라서 도구 정의하고 시스템 프롬프트 쓰면 오후 한나절이면 작동하는 프로토타입이 나온다.
그 에이전트를 실사용자에게 돌리는 건 완전히 다른 분야다.
| 항목 | 데모 | 프로덕션 |
|---|---|---|
| 스케일링 | 내 노트북 | 1~10,000 동시 세션 |
| 상태 | 메모리 딕셔너리 | 세션 간 영속 멀티턴 |
| 모니터링 | print문 | 토큰 소비, 레이턴시 p95, 에러율, 비용 귀속 |
| 롤백 | Ctrl+Z | 버전 고정, 카나리 배포, 즉시 롤백 |
| 도구 인증 | 하드코딩 API 키 | 스코프 서비스 계정, 시크릿 로테이션 |
| 비용 관리 | "내가 볼게" | 에이전트별 토큰 예산, 킬 스위치 |
대부분 인디 개발자와 소규모 팀이 이 표 어딘가에서 막힌다. 에이전트는 돌아간다. 돌릴 인프라가 아직 없다. 그래서 프로젝트가 데모에 머문다.
Cloud Functions, 에이전트 버전
구글의 수는 이 표 전체를 관리형 런타임으로 압축하는 것이다. 멘탈 모델은 직관적이다: Cloud Functions나 Cloud Run을 써봤으면 배포 패턴을 이미 안다. 차이는 런타임이 에이전트를 이해한다는 것 — 도구 호출 체인, 토큰 예산, 대화 상태를 네이티브로 안다.
실제 Agents CLI로 배포하면 이렇게 생겼다:
# Agents CLI 설치
uvx google-agents-cli
# Cloud Run 배포용 스캐폴딩
agents-cli scaffold enhance -d cloud_run
# 인프라 프로비저닝
agents-cli infra single-project
# 배포
agents-cli deploy
이게 쿠버네티스 클러스터, 오토스케일러 설정, 프로메테우스 스택, 커스텀 토큰 추적 파이프라인을 대체한다. 솔로 빌더에게 이건 "DevOps 채용이 필요하다"와 "터미널이 필요하다"의 차이다.
30개 이상 연동, 바로 사용 가능
도구 레지스트리에 사전 구축된 커넥터가 딸려 나온다. "지원 예정"이 아니라 프리뷰에 포함:
| 카테고리 | 연동 |
|---|---|
| 개발 도구 | GitHub, GitLab, Jira, Linear |
| 생산성 | Notion, Google Workspace, Slack, Asana |
| 데이터 | MongoDB, BigQuery |
| 결제 & CRM | Stripe, Salesforce (via StackOne), HubSpot (via StackOne) |
| 클라우드 | GCP 서비스 (Cloud Storage, Pub/Sub, Cloud SQL) |
| 커뮤니케이션 | Twilio (via StackOne) |
이게 중요한 이유: 유용한 에이전트를 만드는 데서 가장 어려운 부분은 LLM 호출이 아니라, 에이전트를 실제 업무가 일어나는 시스템에 연결하는 것이다. 티켓 시스템을 못 읽고 CRM을 못 업데이트하는 고객지원 에이전트는 에이전트가 아니라 챗봇이다.
MCP 네이티브 — 상호운용성 전략
플랫폼이 Model Context Protocol을 네이티브로 지원한다. 두 가지가 따라온다.
첫째, 기존 REST API를 Apigee를 통해 재작성 없이 MCP 도구로 감쌀 수 있다. 사내 API가 있으면 커스텀 커넥터를 안 만들어도 된다. Apigee가 MCP 스키마를 생성하고, 에이전트가 다른 도구처럼 호출한다.
둘째, 도구 정의가 MCP 호환 클라이언트라면 어디든 이식 가능하다. 플랫폼이 프로토콜 수준에서 모델에 종속되지 않는다. 에이전트의 도구 정의와 대화 흐름은 MCP를 지원하는 모든 클라이언트에서 작동한다.
이건 의도적 아키텍처 선택이다. 구글이 런타임, 거버넌스, 레지스트리를 제어한다. 하지만 도구 레이어는 오픈 프로토콜을 말한다. "전부 독점"도 아니고 "전부 오픈"도 아닌, 더 미묘한 락인 구조다.
락인, 솔직하게
GCP에 묶이는 것과 아닌 것을 구체적으로 짚겠다.
GCP에 묶임:
- 에이전트 런타임 자체 — 실행, 스케일링, 헬스 체크
- 거버넌스 레이어 — 배포 권한, 도구 접근 제어, 감사 로그
- 도구 레지스트리 포맷 — 커넥터 패키징, 버전 관리 방식
이식 가능:
- 프롬프트, 시스템 지시
- 도구 정의 (MCP 사용 시 다른 곳에서도 작동)
- 대화 흐름 로직
- LLM 선택 (MCP 상호운용을 통해)
Cloud Functions에서 익숙한 패턴이다: 함수 코드는 이식 가능하지만, 트리거 바인딩, IAM 정책, 모니터링 연동은 안 된다. 로직은 옮길 수 있다. 운영 래퍼는 못 옮긴다.
올인하기 전에 비용에 반영해야 할 사항이다. 특히 가격이나 조건을 바꿀 수 있는 플랫폼 위에 짓는 인디 개발자라면 — 같은 날 구글이 Gemini CLI로 보여줬듯이, 이론적 우려가 아니다.
Agent-First: Antigravity 2.0이 보내는 신호
Managed Agents API가 단독으로 나온 게 아니다. Antigravity 2.0 — 구글의 차세대 개발 플랫폼 — 이 에이전트를 버전 관리, 롤백, 관측성을 갖춘 1급 배포 대상으로 명시적으로 취급한다. 93개 에이전트가 12시간에 걸쳐 OS를 만드는 데모와 플레이 가능한 Doom 클론을 에이전트 기반 개발로 선보였다.
실행에는 문제가 있었다 (강제 업데이트가 기존 프로젝트를 깨뜨렸다 — Part 1에서 다뤘다). 하지만 방향 신호는 명확하다: 구글은 에이전트를 클라우드의 기능이 아니라, 컨테이너와 함수 옆에 서는 배포 기본 요소로 본다.
이건 새롭다. AWS에 SageMaker 엔드포인트와 Bedrock 에이전트가 있지만, 전용 에이전트 CLI는 없다. Azure에 AI Studio가 있지만, 별도 포털에 산다. 스캐폴드부터 프로덕션까지 4개 명령어로 끝나는 전용 agents-cli를 출시한 메이저 클라우드 중 구글이 선두 주자다.
인디 개발자에게 무슨 의미인가
프로덕션 에이전트를 출시하려는 솔로 빌더의 전후 비교:
Managed Agents API 이전:
- 에이전트 로직 작성
- 컨테이너화 (Dockerfile, 멀티스테이지 빌드)
- 쿠버네티스 또는 Cloud Run 세팅
- 오토스케일링 정책 설정
- 토큰 추적, 비용 모니터링 구축
- 헬스 체크 구현
- 로그 집계 (ELK, Datadog 등)
- 멀티턴 상태 영속 처리
- 도구 자격증명 시크릿 로테이션
- 배포 파이프라인 구축
이후:
- 에이전트 로직 작성
agents-cli deploy
2~10단계가 사라진 게 아니라, 플랫폼에 흡수됐다. Cloud Functions가 백엔드 워크로드에 가져온 압축이 이제 에이전트에 적용된다.
한 가지 유의: API가 프리뷰 단계다. 가격이 확정되지 않았다. 프로덕션 SLA가 공개되지 않았다. 매출에 직결되는 에이전트를 오늘 당장 옮기진 않겠다. 하지만 새 프로젝트라면, 빌드-vs-바이 계산이 근본적으로 바뀌었다.
큰 그림
Google I/O 2026의 논지는 명확했다: 에이전트는 이제 실험이 아니라 인프라다. Managed Agents API, Antigravity 2.0의 에이전트 퍼스트 배포, 30개 이상 사전 연동이 모두 같은 방향을 가리킨다 — AI 에이전트의 "멋진 데모" 시대가 끝나가고 있다. "프로덕션에서 스케일로 돌린다" 시대가 시작되고 있다.
인디 개발자에게 진입 장벽이 "DevOps 팀 채용"에서 "CLI 명령 하나 배우기"로 내려갔다. 과장이 아니다. 2016년의 Cloud Functions가 다시 일어나고 있다.
이 시리즈 Part 3에서는 Gemini Omni를 다룬다 — I/O 현장을 멈춘 학습된 물리 엔진 기반 영상 생성. dev.to에서 팔로우하시면 올라올 때 받아보실 수 있습니다.
관리형 플랫폼을 평가 중이거나, 프리뷰를 이미 써보셨다면 — 경험 공유해주시면 좋겠습니다. 댓글이나 GitHub에서.
출처:
- Sundar Pichai I/O 2026 키노트 (https://blog.google/innovation-and-ai/sundar-pichai-io-2026/)
- Model Context Protocol (https://modelcontextprotocol.io/)
- Gemini CLI → Antigravity CLI 전환 (https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/)
Top comments (0)