Google이 서버리스 에이전트(Serverless Agents)를 현실로 만들었습니다 Part 2 of 5 — Google I/O 2026 리뷰

에이전트 데모를 출시해 본 개발자라면 누구나 그 기분을 압니다. 프로토타입은 잘 작동합니다. Loom 영상에는 '좋아요'가 달립니다. 그러다 누군가 이렇게 묻습니다: "멋지네요 — 이걸 실제 사용자 500명과 함께 사용하려면 어떻게 해야 하죠?"

그 질문이 대부분의 에이전트 프로젝트를 무너뜨립니다. 데모와 프로덕션(Production) 사이의 간극은 프롬프트(Prompt)나 도구 정의(Tool definitions)의 문제가 아닙니다. 그것은 인프라(Infrastructure)의 문제입니다 — 컨테이너 오케스트레이션(Container orchestration), 오토스케일링(Autoscaling) 정책, 헬스 체크(Health checks), 토큰 예산 강제 적용(Token budget enforcement), 멀티 턴 상태 관리(Multi-turn state management), 그리고 로그 집계(Log aggregation)에 관한 것입니다. 이는 EC2, Cloud Run, Lambda가 등장하기 전, "웹 앱을 작성했다"와 "이 웹 앱이 10,000명의 동시 접속자를 처리한다" 사이에 존재했던 것과 동일한 간극입니다.

I/O 2026에서 Google은 그 해답을 내놓았습니다. Managed Agents API는 Cloud Functions가 서버리스 컴퓨팅(Serverless computing)에 했던 역할을 에이전트에게 수행합니다. 배포(Deploy), 확장(Scale), 모니터링(Monitor), 실행당 과금(Pay per execution). 클러스터(Cluster)도 필요 없고, YAML도 필요 없습니다. 단 하나의 CLI 명령어로 가능합니다. 저는 제 Part 1 리뷰에서 이것을 I/O의 가장 중대한 발표라고 불렀습니다. 이 포스트는 그 이유를 설명합니다.

데모에서 프로덕션으로의 간극 (The Demo-to-Production Gap)

이제 에이전트를 구축하는 것은 쉽습니다. LangChain, CrewAI, AutoGen, Claude Code — 프레임워크를 선택하고, 도구를 정의하고, 시스템 프롬프트(System prompt)를 작성하면 오후 안에 작동하는 프로토타입을 가질 수 있습니다. 하지만 그 에이전트를 실제 사용자를 위해 실행하는 것은 완전히 다른 영역의 전문 지식입니다. 다음은 데모와 달리 프로덕션이 요구하는 사항들입니다:

대부분의 인디 개발자와 소규모 팀은 이 표의 어딘가에서 막히게 됩니다. 에이전트는 작동합니다. 하지만 그것을 실행할 인프라가 아직 존재하지 않습니다. 그래서 프로젝트는 데모 상태로 머물게 됩니다.

에이전트를 위한 Cloud Functions: Google의 행보는 그 전체 테이블을 관리형 런타임 (managed runtime)으로 압축하는 것입니다. 사고 모델 (mental model)은 간단합니다. 만약 Cloud Functions나 Cloud Run을 사용해 본 적이 있다면, 이미 배포 패턴을 이해하고 있는 것입니다. 차이점은 런타임이 에이전트를 인식한다는 점입니다. 즉, 도구 호출 체인 (tool call chains), 토큰 예산 (token budgets), 그리고 대화 상태 (conversation state)를 네이티브하게 이해합니다. 실제 Agents CLI를 사용한 배포 모습은 다음과 같습니다:

Agents CLI 설치

uvx google-agents-cli

Cloud Run 배포를 위한 스캐폴딩 (Scaffold)

agents-cli scaffold enhance -d cloud_run

인프라 프로비저닝 (Provision)

agents-cli infra single-project

배포

agents-cli deploy

이것은 Kubernetes 클러스터, 오토스케일러 (autoscaler) 설정, Prometheus 스택, 그리고 커스텀 토큰 추적 파이프라인을 대체합니다. 1인 개발자에게 이것은 "DevOps 인력을 채용해야 한다"와 "터미널만 있으면 된다" 사이의 차이입니다.

30개 이상의 즉시 사용 가능한 통합 (Integrations)
도구 레지스트리에는 사전 구축된 커넥터 (connectors)가 포함되어 있습니다. "지원할 계획이다"가 아니라, 프리뷰 단계에서 이미 제공됩니다:

이것이 중요한 이유는 유용한 에이전트를 구축하는 가장 어려운 부분이 LLM 호출이 아니라, 에이전트를 실제 업무가 일어나는 시스템에 연결하는 것이기 때문입니다. 고객 지원 티켓 시스템을 읽거나 CRM을 업데이트할 수 없는 고객 지원 에이전트는 에이전트가 아니라 챗봇일 뿐입니다.

MCP 네이티브 — 상호 운용성 전략
이 플랫폼은 Model Context Protocol (MCP)을 네이티브하게 지원합니다. 여기서 두 가지 결과가 도출됩니다. 첫째, 기존 REST API를 재작성 없이 Apigee를 통해 MCP 도구로 래핑 (wrapped)할 수 있습니다. 내부 API가 있다면 커스텀 커넥터를 직접 만들 필요가 없습니다. Apigee가 MCP 스키마를 생성하면, 에이전트는 이를 다른 도구와 마찬가지로 호출할 수 있습니다. 둘째, 도구 정의 (tool definitions)가 MCP 호환 클라이언트라면 어디로든 이식 가능합니다.

이 플랫폼은 프로토콜 수준에서 특정 모델에 종속되지 않습니다 (model-locked). 에이전트의 도구 정의 (tool definitions)와 대화 흐름 (conversation flows)은 MCP를 지원하는 모든 클라이언트와 함께 작동합니다. 이는 의도적인 아키텍처 설계의 결과입니다. Google은 런타임 (runtime), 거버넌스 (governance), 그리고 레지스트리 (registry)를 제어하지만, 도구 계층 (tool layer)은 개방형 프로토콜을 사용합니다. 이는 "모든 것이 독점적이다" 혹은 "모든 것이 개방적이다"라는 단순한 논리보다 더 미묘한 락인 (lock-in) 이야기입니다.

솔직히 말해서, 무엇이 여러분을 GCP에 묶어두고 무엇이 그렇지 않은지 구체적으로 밝히고 싶습니다.

GCP에 종속되는 것:

• 에이전트 런타임 (agent runtime) 자체 — 실행 (execution), 확장 (scaling), 상태 확인 (health checks)
• 거버넌스 계층 (governance layer) — 누가 배포할 수 있는지, 에이전트가 어떤 도구에 접근할 수 있는지, 감사 로그 (audit logs)
• 도구 레지스트리 형식 (tool registry format) — 커넥터가 패키징되고 버전 관리되는 방식

이식 가능한 것 (Portable):

• 프롬프트 (prompts) 및 시스템 지침 (system instructions)
• 도구 정의 (tool definitions) (MCP를 사용하는 경우, 다른 곳에서도 작동함)
• 대화 흐름 로직 (conversation flow logic)
• LLM 선택 (MCP 상호 운용성을 통해)

이 패턴은 Cloud Functions에서 익숙한 방식입니다. 함수 코드 (function code)는 이식 가능하지만, 트리거 바인딩 (trigger bindings), IAM 정책 (IAM policies), 그리고 모니터링 통합 (monitoring integrations)은 그렇지 않습니다. 여러분의 로직은 옮길 수 있지만, 운영 래퍼 (operational wrapper)는 옮길 수 없습니다. 모든 것을 전적으로 맡기기 전에 비용을 산정해 볼 가치가 있습니다. 특히 가격이나 약관이 변경될 수 있는 플랫폼 위에서 작업하는 개인 개발자라면 더욱 그렇습니다. Google이 같은 날 Gemini CLI를 통해 보여주었듯이, 이는 이론적인 우려가 아닙니다.

에이전트 우선 (Agent-First): Antigravity 2.0이 시사하는 바
Managed Agents API는 단독으로 등장한 것이 아닙니다. Google의 차세대 개발 플랫폼인 Antigravity 2.0은 에이전트를 버전 관리, 롤백 (rollback), 관찰 가능성 (observability)을 갖춘 일급 배포 대상 (first-class deployment targets)으로 명시적으로 취급합니다. 한 데모에서는 에이전트 주도 개발 (agent-driven development)을 통해 12시간 동안 93개의 에이전트가 구축한 OS와 플레이 가능한 Doom 클론을 보여주었습니다. 실행 과정에서 문제(강제 업데이트로 인해 기존 프로젝트가 깨지는 현상 — 이는 1부에서 다루었습니다)가 있었지만, 방향성 신호는 명확합니다. Google은 에이전트를 클라우드의 단순한 기능이 아니라, 컨테이너 (containers) 및 함수 (functions)와 나란히 하는 배포 기본 단위 (deployment primitive)로 보고 있습니다. 이것은 새로운 변화입니다.

AWS에는 SageMaker 엔드포인트(endpoints)와 Bedrock 에이전트(agents)가 있지만, 전용 에이전트 CLI(Command Line Interface)를 제공하는 것은 둘 다 아닙니다. Azure에는 AI Studio가 있지만, 별도의 포털에서 운영됩니다. Google은 에이전트를 단 4개의 명령어로 스캐폴딩(scaffold) 단계에서 프로덕션(production) 단계까지 가져갈 수 있는 목적 기반의 에이전트-CLI(agents-cli)를 출시한 최초의 주요 클라우드 기업 중 하나입니다.

인디 개발자들에게 이것이 의미하는 바
다음은 프로덕션 에이전트를 출시하려는 1인 개발자의 전후(before-and-after) 비교입니다:

관리형 에이전트 API(Managed Agents API) 도입 전:

1. 에이전트 로직 작성
2. 컨테이너화 (Dockerfile, 멀티 스테이지 빌드)
3. Kubernetes 또는 Cloud Run 설정
4. 오토스케일링(autoscaling) 정책 구성
5. 토큰 추적 및 비용 모니터링 구축
6. 헬스 체크(health checks) 구현
7. 로그 집계 설정 (ELK, Datadog 등)
8. 멀티 턴(multi-turn) 상태 지속성 관리
9. 도구 자격 증명을 위한 비밀번호 로테이션(secret rotation) 관리
10. 배포 파이프라인 구축

관리형 에이전트 API 도입 후:

1. 에이전트 로직 작성
2. agents-cli deploy

2단계부터 10단계까지의 과정이 사라진 것은 아닙니다. 플랫폼에 의해 흡수된 것입니다. Cloud Functions가 백엔드 워크로드에 가져다주었던 것과 동일한 압축 효과가 이제 에이전트에도 적용됩니다. 한 가지 주의할 점은, 해당 API가 프리뷰(preview) 단계라는 것입니다. 가격 정책이 확정되지 않았으며, 프로덕션 SLA(Service Level Agreement)도 공개되지 않았습니다. 따라서 수익에 직결되는 중요한 에이전트를 지금 당장 마이그레이션하는 것은 권장하지 않습니다. 하지만 새로운 프로젝트의 경우, '직접 구축할 것인가 아니면 구매할 것인가(build-vs-buy)'에 대한 계산 방식이 근본적으로 바뀌었습니다.

더 큰 그림
Google I/O 2026은 명확한 논제를 제시했습니다: 에이전트는 이제 실험이 아니라 인프라(infrastructure)라는 것입니다. Managed Agents API, Antigravity 2.0의 에이전트 우선 배포(agent-first deployment), 그리고 30개 이상의 사전 구축된 통합(integrations)은 모두 동일한 방향을 가리키고 있습니다. 즉, AI 에이전트의 "멋진 데모" 시대는 끝나가고 있습니다. "대규모 프로덕션에서 실행되는" 시대가 시작되고 있습니다. 인디 개발자들에게 장벽은 "DevOps 팀을 고용하는 것"에서 "CLI 명령어 하나를 배우는 것"으로 낮아졌습니다. 이것은 과장이 아닙니다. 2016년의 Cloud Functions가 다시 재현되고 있는 것입니다.

이 시리즈의 3부에서는 I/O 현장에서 모두를 놀라게 했던 비디오를 위한 학습된 물리 엔진, Gemini Omni를 다룹니다. 게시되면 확인할 수 있도록 dev.to에서 저를 팔로우해 주세요. 만약 에이전트를 구축하며 관리형 플랫폼을 평가 중이거나, 이미 프리뷰를 사용해 보셨다면 여러분의 경험을 듣고 싶습니다.

댓글 또는 GitHub. 출처: Sundar Pichai I/O 2026 keynote, Model Context Protocol, Gemini CLI to Antigravity CLI transition. 한국어 번역 구글이 서버리스 에이전트를 현실로 만들었다 5편 중 2편 — Google I/O 2026 리뷰. 에이전트 데모를 만들어 본 개발자라면 그 기분을 안다. 프로토타입은 돌아간다. Loom 영상에 좋아요가 붙는다. 그런데 누가 묻는다: "좋은데 — 500명 실사용자에게 어떻게 쓰죠?" 이 질문이 대부분의 에이전트 프로젝트를 죽인다. 데모에서 프로덕션 (Production) 까지의 간극은 프롬프트 (Prompt) 나 도구 정의 문제가 아니다. 인프라 (Infrastructure) 문제다 — 컨테이너 오케스트레이션 (Container Orchestration), 오토스케일링 (Autoscaling), 헬스 체크 (Health Check), 토큰 예산 관리, 멀티턴 (Multi-turn) 상태 관리, 로그 집계. "웹앱을 만들었다"와 "이 웹앱이 1만 명 동시 접속을 처리한다" 사이에 있던 간극과 같다 — EC2, Cloud Run, Lambda가 등장하기 전까지. I/O 2026에서 구글이 답을 내놨다. Managed Agents API는 Cloud Functions가 서버리스 컴퓨팅 (Serverless Computing) 에 한 일을 에이전트 (Agent) 에 한다. 배포, 스케일, 모니터링, 실행 단위 과금. 클러스터 (Cluster) 없이. YAML 없이. CLI 명령 한 줄. Part 1 리뷰에서 I/O의 가장 중대한 발표라고 했다. 이 글에서 그 이유를 풀어본다.

데모-프로덕션 간극
에이전트를 만드는 건 이제 쉽다. LangChain, CrewAI, AutoGen, Claude Code — 프레임워크 (Framework) 하나 골라서 도구 정의하고 시스템 프롬프트 (System Prompt) 쓰면 오후 한나절이면 작동하는 프로토타입이 나온다. 그 에이전트를 실사용자에게 돌리는 건 완전히 다른 분야다.

대부분 인디 개발자와 소규모 팀이 이 표 어딘가에서 막힌다. 에이전트는 돌아간다. 돌릴 인프라가 아직 없다. 그래서 프로젝트가 데모에 머문다.

Cloud Functions, 에이전트 버전
구글의 수는 이 표 전체를 관리형 런타임 (Managed Runtime) 으로 압축하는 것이다. 멘탈 모델 (Mental Model) 은 직관적이다: Cloud Functions나 Cloud Run을 써봤으면 배포 패턴을 이미 안다. 차이는 런타임이 에이전트를 이해한다는 것 — 도구 호출 체인 (Tool Call Chain), 토큰 예산, 대화 상태를 네이티브 (Native) 로 안다. 실제 Agents CLI 로 배포하면 이렇게 생겼다:

# Agents CLI 설치
uvx google-agents-cli

# Cloud Run 배포용 스캐폴딩 (Scaffolding)
agents-cli scaffold enhance -d cloud_run

# 인프라 프로비저닝 (Provisioning)
agents-cli infra single-project

# 배포
agents-cli deploy

이게 쿠버네티스 (Kubernetes) 클러스터, 오토스케일러 (Autoscaler) 설정, 프로메테우스 (Prometheus) 스택, 커스텀 토큰 추적 파이프라인을 대체한다. 솔로 빌더 (Solo Builder) 에게 이건 "DevOps 채용이 필요하다"와 "터미널이 필요하다"의 차이다.

30개 이상 연동, 바로 사용 가능 도구
레지스트리 (Registry) 에 사전 구축된 커넥터 (Connector) 가 딸려 나온다.

"지원 예정"이 아니라 프리뷰에 포함:

• 카테고리 연동
  • 개발 도구: 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)

이게 중요한 이유: 유용한 에이전트 (Agent)를 만드는 데서 가장 어려운 부분은 LLM 호출이 아니라, 에이전트를 실제 업무가 일어나는 시스템에 연결하는 것이다. 티켓 시스템을 못 읽고 CRM을 못 업데이트하는 고객지원 에이전트는 에이전트가 아니라 챗봇 (Chatbot)이다.

MCP 네이티브 — 상호운용성 (Interoperability)
플랫폼이 Model Context Protocol (MCP)을 네이티브로 지원한다. 두 가지가 따라온다.

첫째, 기존 REST API를 Apigee를 통해 재작성 없이 MCP 도구 (Tool)로 감쌀 수 있다. 사내 API가 있으면 커스텀 커넥터 (Custom Connector)를 안 만들어도 된다. Apigee가 MCP 스키마 (Schema)를 생성하고, 에이전트가 다른 도구처럼 호출한다.

둘째, 도구 정의 (Tool Definition)가 MCP 호환 클라이언트 (Client)라면 어디든 이식 가능하다. 플랫폼이 프로토콜 (Protocol) 수준에서 모델에 종속되지 않는다. 에이전트의 도구 정의와 대화 흐름 (Conversation Flow)은 MCP를 지원하는 모든 클라이언트에서 작동한다.

이건 의도적인 아키텍처 (Architecture) 선택이다. 구글이 런타임 (Runtime), 거버넌스 (Governance), 레지스트리 (Registry)를 제어한다. 하지만 도구 레이어 (Tool Layer)는 오픈 프로토콜 (Open Protocol)을 지향한다. "전부 독점"도 아니고 "전부 오픈"도 아닌, 더 미묘한 락인 (Lock-in) 구조다.

락인, 솔직하게 GCP에 묶이는 것과 아닌 것을 구체적으로 짚겠다.

• GCP에 묶임:

  • 에이전트 런타임 자체 — 실행, 스케일링 (Scaling), 헬스 체크 (Health Check)
  • 거버넌스 레이어 — 배포 권한, 도구 접근 제어, 감사 로그 (Audit Log)
  • 도구 레지스트리 포맷 — 커넥터 패키징, 버전 관리 방식

• 이식 가능:

  • 프롬프트 (Prompt), 시스템 지시 (System Instruction)
  • 도구 정의 (MCP 사용 시 다른 곳에서도 작동)
  • 대화 흐름 로직 (Conversation Flow Logic)
  • LLM 선택 (MCP 상호운용을 통해)

Cloud Functions에서 익숙한 패턴이다: 함수 코드는 이식 가능하지만, 트리거 바인딩 (Trigger Binding), IAM 정책, 모니터링 연동은 안 된다. 로직은 옮길 수 있다. 운영 래퍼 (Operational Wrapper)는 못 옮긴다. 올인하기 전에 비용에 반영해야 할 사항이다. 특히 가격이나 조건을 바꿀 수 있는 플랫폼 위에 짓는 인디 개발자라면 — 같은 날 구글이 Gemini CLI로 보여줬듯이, 이론적 우려가 아니다.

Agent-First: Antigravity 2.0이 보내는 신호
Managed Agents API가 단독으로 나온 게 아니다. Antigravity 2.0 — 구글의 차세대 개발 플랫폼 — 이 에이전트를 버전 관리 (Versioning), 롤백 (Rollback), 관측성 (Observability)을 갖춘 1급 배포 대상으로 명시적으로 취급한다.

93개 에이전트가 12시간에 걸쳐 OS를 만드는 데모와 플레이 가능한 Doom 클론을 에이전트 기반 개발로 선보였다. 실행에는 문제가 있었다 (강제 업데이트가 기존 프로젝트를 깨뜨렸다 — Part 1에서 다뤘다). 하지만 방향 신호는 명확하다: 구글은 에이전트를 클라우드의 기능이 아니라, 컨테이너 (Container)와 함수 (Function) 옆에 서는 배포 기본 요소 (Deployment Primitive)로 본다.

이건 새롭다. AWS에 SageMaker 엔드포인트 (Endpoint)와 Bedrock 에이전트가 있지만, 전용 에이전트 CLI는 없다. Azure에 AI Studio가 있지만, 별도 포털에 산다. 스캐폴드 (Scaffold)부터 프로덕션 (Production)까지 4개 명령어로 끝나는 전용 agents-cli 를 출시한 메이저 클라우드 중 구글이 선두 주자다.

인디 개발자에게 무슨 의미인가? 프로덕션 에이전트를 출시하려는 솔로 빌더(Solo Builder)의 전후 비교:

Managed Agents API 이전:

• 에이전트 로직 작성
• 컨테이너화 (Dockerfile, 멀티스테이지 빌드)
• 쿠버네티스 (Kubernetes) 또는 Cloud Run 세팅
• 오토스케일링 (Autoscaling) 정책 설정
• 토큰 추적, 비용 모니터링 구축
• 헬스 체크 (Health Check) 구현
• 로그 집계 (ELK, Datadog 등)
• 멀티턴 (Multi-turn) 상태 영속 처리 도구
• 자격 증명 (Credential) 시크릿 로테이션
• 배포 파이프라인 구축

이후:

• 에이전트 로직 작성
• agents-cli deploy

2~10단계가 사라진 게 아니라, 플랫폼에 흡수됐다. Cloud Functions가 백엔드 워크로드에 가져온 압축이 이제 에이전트에 적용된다. 한 가지 유의: API가 프리뷰 (Preview) 단계다. 가격이 확정되지 않았다. 프로덕션 SLA가 공개되지 않았다. 매출에 직결되는 에이전트를 오늘 당장 옮기진 않겠다. 하지만 새 프로젝트라면, 빌드-vs-바이 (Build-vs-Buy) 계산이 근본적으로 바뀌었다.

큰 그림
Google I/O 2026의 논지는 명확했다: 에이전트는 이제 실험이 아니라 인프라다. Managed Agents API, Antigravity 2.0의 에이전트 퍼스트 (Agent-first) 배포, 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://develo