한 번의 API 호출, Google이 에이전트 서버리스를 연 순간

AI 요약

• 무슨 일: Google이 Gemini API에 Managed Agents를 열고 Antigravity agent를 preview로 공개했습니다.
  • 한 번의 Interactions API 호출로 Google 호스팅 Linux sandbox에서 reasoning, 코드 실행, 파일 관리, 웹 브라우징을 수행합니다.
• 의미: 에이전트 경쟁축이 모델 호출에서 sandbox, 상태, tool loop, 네트워크 제어가 붙은 런타임으로 이동합니다.
• 숫자: 공식 문서는 단일 interaction이 보통 100k-3M token을 쓰고, 복잡한 workflow는 3M-5M token까지 갈 수 있다고 적습니다.
• 주의점: preview 기능이며 기본 outbound network, 데이터 보관, token 비용, 미지원 도구를 먼저 확인해야 합니다.

Google이 I/O 2026에서 Gemini API의 Managed Agents를 공개했습니다. 표면적으로는 Gemini API에 새 agent 기능이 추가됐다는 제품 뉴스입니다. 하지만 개발자 관점에서 더 중요한 변화는 따로 있습니다. Google이 agent 실행을 모델 호출의 부가 기능이 아니라, sandbox, 상태, 파일시스템, 웹 접근, tool loop, 비용 관찰을 묶은 hosted runtime으로 팔기 시작했다는 점입니다.

Google의 설명은 간단합니다. 개발자가 interactions.create를 한 번 호출하면, Antigravity agent가 Google이 호스팅하는 isolated Linux environment 안에서 추론하고, 도구를 쓰고, 코드를 실행하고, 파일을 관리하고, 웹을 탐색합니다. 이 agent는 Gemini 3.5 Flash 기반이며, Google Antigravity IDE와 같은 harness를 사용합니다. 즉, 지금까지 로컬 터미널, Docker, 브라우저 자동화, 파일 동기화, tool orchestration을 조합해 만들던 agent 실행 환경의 일부가 API 뒤로 들어갑니다.

이 뉴스가 흥미로운 이유는 "Google도 coding agent를 냈다"가 아닙니다. devlery는 이미 Gemini Spark, Antigravity CLI 전환, Android Agent Skills, AWS MCP Server 같은 I/O 주변 발표를 다뤘습니다. 이번 발표의 핵심은 소비자용 개인 agent나 CLI migration이 아니라 API 제품의 경계입니다. Managed Agents는 AI 앱 개발자가 직접 agent infrastructure를 만들지 않고도 "원격 sandbox에서 돌아가는 작업자"를 제품에 붙일 수 있게 하려는 시도입니다. 서버리스가 서버 운영을 감춘 것처럼, Google은 agent runtime 운영을 감추려 합니다.

왜 에이전트 서버리스인가

서버리스라는 표현은 비유이지만, 이번 발표를 이해하는 데 꽤 유용합니다. AWS Lambda가 이벤트 처리용 서버 provisioning, process lifetime, scaling을 추상화했듯이, Managed Agents는 agent 작업에 필요한 실행 환경 provisioning, state reuse, tool execution, file handling을 추상화합니다. 개발자는 container를 띄우고, dependency를 설치하고, agent가 만든 파일을 보존하고, long-running task를 감시하는 코드를 처음부터 짤 필요가 줄어듭니다.

Google 공식 블로그는 "production-grade agent"를 만들려면 isolated sandbox를 구축하고 관리하는 복잡한 인프라가 필요했다고 짚습니다. 그리고 Gemini Managed Agents가 그 복잡도를 추상화해 product experience와 agent behavior에 집중하게 한다고 설명합니다. 이 말은 마케팅처럼 들릴 수 있지만, agent 제품을 직접 만들어 본 팀에게는 현실적인 통증입니다. 모델 API 한 번 호출하는 것은 쉽습니다. 그런데 agent가 코드를 실행하고, 중간 파일을 만들고, 웹에서 데이터를 가져오고, 여러 단계로 실패를 회복하고, 다음 요청에서 같은 작업 공간을 이어가게 하는 순간 운영 문제가 늘어납니다.

Managed Agents가 겨냥하는 지점이 바로 여기입니다. Google은 기본 Antigravity agent를 general-purpose managed agent로 제공하고, 개발자가 AGENTS.md와 SKILL.md 같은 markdown 파일로 behavior를 정의하거나 inline configuration으로 agent를 조정할 수 있게 합니다. Anthropic Claude Code, OpenAI Agents SDK, GitHub Copilot 계열이 이미 repository instruction과 skill 개념을 제품에 넣고 있는 상황에서, Google도 같은 문법에 가까운 방식으로 agent customization을 API 표면에 올린 셈입니다.

Interactions API가 바꾸는 호출 단위

Managed Agents는 Gemini API의 Interactions API 위에서 동작합니다. 이 API 자체도 중요한 신호입니다. Google 문서는 Interactions API를 agentic workflow, server-side state management, 복잡한 multimodal multi-turn conversation에 최적화된 새 표준이라고 설명합니다. 기존 generateContent API가 여전히 지원되지만, 새 model과 agentic capability 일부는 Interactions API 쪽으로 들어간다는 방향도 명시돼 있습니다.

호출 단위도 달라집니다. 일반 chat completion이나 content generation에서는 "입력 하나, 출력 하나"라는 감각이 강합니다. Interactions API의 Interaction은 한 conversation turn이나 task의 기록입니다. 그 안에는 model thought, tool call, tool result, final model output 같은 execution step이 시간순으로 들어갑니다. 개발자는 마지막 텍스트만 읽을 수도 있지만, 복잡한 UI를 만들거나 디버깅하려면 중간 step을 렌더링하거나 추적할 수 있습니다.

이 구조는 agent 제품에서 중요합니다. 사용자가 "이 CSV를 분석해 보고서를 만들어줘"라고 입력했을 때 실제로는 웹 검색, 파일 생성, Python 실행, 검증, 재시도, 요약이 이어질 수 있습니다. 사용자가 보는 UI가 단순 spinner라면 실패 원인을 알기 어렵습니다. Interactions API의 step model은 agent가 지금 무엇을 하고 있는지 보여주거나, 어느 tool call에서 비용과 시간이 늘어났는지 추적하는 데 필요합니다.

비용 감각이 달라집니다

Managed Agents에서 가장 먼저 조심해야 할 지점은 비용입니다. Google docs는 Antigravity agent가 일반적인 standard chat request처럼 한 번 답하고 끝나는 구조가 아니라고 강조합니다. 단일 request가 autonomous loop를 돌며 reasoning, tool execution, code running, file management를 반복할 수 있습니다. 따라서 겉으로는 "API 호출 한 번"이어도 내부적으로는 많은 token과 tool call이 쌓입니다.

공식 문서의 예시는 꽤 구체적입니다. research and information synthesis 작업은 input 100k-500k token, output 10k-40k token, typical cost $0.30-$1.00 범위로 제시됩니다. document and content generation은 $0.30-$1.30, data processing and analysis는 input 300k-3M token, output 30k-150k token, $0.70-$3.25로 제시됩니다. 복잡한 agentic workflow는 3M-5M token을 누적하고 최대 약 $5까지 갈 수 있다고도 적혀 있습니다.

여기서 중요한 것은 숫자 자체보다 비용 모델의 변화입니다. 전통적인 API 제품에서는 개발자가 prompt length와 output length를 비교적 직접 통제합니다. Agent runtime에서는 agent가 몇 번 검색할지, 몇 번 코드를 실행할지, 실패한 결과를 얼마나 오래 검증할지, 파일을 몇 번 다시 읽을지에 따라 비용이 달라집니다. 사용자의 요청 문장은 짧아도 agent의 내부 작업은 길어질 수 있습니다.

따라서 Managed Agents를 제품에 붙이는 팀은 p95 token cost를 먼저 측정해야 합니다. 미리 정해진 fixed price 기능처럼 판매하기 전에 streaming으로 step을 관찰하고, 오래 걸리는 run을 cancel할 수 있어야 합니다. "환경 compute는 preview 기간 과금하지 않는다"는 문구도 오해하면 안 됩니다. CPU, memory, sandbox execution 비용이 preview 동안 무료일 뿐, underlying Gemini model token과 tool usage는 과금 모델에 들어갑니다.

기본 네트워크가 열려 있다는 사실

두 번째 핵심은 보안 경계입니다. Google의 Agents overview는 managed agents가 OS-level isolated sandbox에서 실행된다고 설명합니다. 동시에 기본값으로 unrestricted outbound network access를 가진다고 적습니다. 개발자는 allowlist로 outbound traffic을 특정 domain이나 wildcard pattern으로 제한할 수 있습니다. 이 문장은 작지만 중요합니다. hosted sandbox라고 해서 네트워크가 자동으로 좁혀지는 것은 아닙니다.

Agent가 웹을 읽고 외부 API를 호출해야 유용해지는 것은 맞습니다. 하지만 production workflow에 붙이면 이야기가 달라집니다. Agent가 내부 데이터 파일을 분석하고, 보고서를 만들고, 외부 문서를 참고하는 과정에서 어떤 domain으로 나가는지 통제해야 합니다. 특히 credential을 붙이는 순간 agent는 그 credential의 full scope를 사용할 수 있습니다. Google docs도 external tools와 API를 붙일 때 trusted source만 쓰고, least privilege service account와 short-lived token을 권합니다.

이 지점은 최근 MCP와 agent security 논의와 연결됩니다. 에이전트는 사람이 읽는 문서, 웹페이지, repository instruction, tool schema를 모두 섞어 해석합니다. 외부 입력이 agent의 tool call을 유도할 수 있다면, 네트워크와 credential 경계는 제품 설계의 핵심이 됩니다. Managed Agents가 편리하다고 해서 사용자별 API key를 넓게 넣고 unrestricted network를 둔 채 production data를 맡기는 것은 위험합니다.

상태 관리도 제품 결정입니다

Interactions API는 server-side state를 기본값으로 사용합니다. previous_interaction_id를 넘기면 이전 conversation history를 다시 보내지 않고 이어갈 수 있고, 이는 성능과 비용 측면에서 implicit caching에도 도움이 됩니다. Agent 환경도 environment ID를 재사용하면 파일과 상태를 보존할 수 있습니다. 개발자 경험만 보면 매우 편리합니다. 장기 작업과 multi-turn 작업에 필요한 상태를 Google이 관리해 주기 때문입니다.

하지만 상태는 곧 제품 정책입니다. Google 문서는 기본적으로 Interaction object를 저장하며, paid tier는 55일, free tier는 1일 보관한다고 설명합니다. 이 저장은 server-side state management, background execution, observability를 쉽게 하기 위한 것입니다. 원치 않으면 store=false를 설정할 수 있지만, 이 경우 background=true와 후속 previous_interaction_id 사용이 제한됩니다.

개발팀은 이 tradeoff를 사용자에게 숨기면 안 됩니다. 고객 데이터가 들어가는 agent 제품이라면 "작업을 이어가기 위해 provider가 어떤 interaction state를 얼마나 보관하는가"가 privacy와 compliance 질문으로 이어집니다. 내부 도구라면 55일 보관이 충분히 괜찮을 수 있습니다. 금융, 의료, 법률, 보안 업무라면 다른 판단이 필요할 수 있습니다. 서버리스 database를 쓸 때 데이터 retention을 설계하듯이, agent runtime에서도 state retention은 아키텍처 결정입니다.

아직 production 안정판은 아닙니다

Google도 제한을 꽤 분명하게 적었습니다. Antigravity agent와 Interactions API는 preview/beta입니다. schema와 feature가 바뀔 수 있습니다. Structured output은 지원하지 않고, temperature, top_p, top_k, stop_sequences, max_output_tokens 같은 generation config 일부는 400 error를 반환합니다. file_search, computer_use, google_maps, function_calling, mcp도 아직 지원되지 않습니다. Audio, video, document input도 현재는 지원되지 않고 text와 image만 가능합니다.

이 제한은 실망 포인트라기보다 제품의 현재 위치를 알려줍니다. Google은 agent runtime의 뼈대를 공개했지만, 모든 Gemini tool이 Antigravity agent 안에서 곧바로 작동하는 것은 아닙니다. 특히 MCP 미지원은 눈에 띕니다. 같은 Google I/O에서 Antigravity, Agent Skills, Spark, MCP 연결이 계속 언급됐기 때문에 "Gemini API managed agent도 곧바로 MCP 서버를 붙일 수 있겠지"라고 기대하기 쉽습니다. 공식 docs 기준으로는 아직 아닙니다.

따라서 지금 Managed Agents를 보는 올바른 태도는 "바로 모든 production agent를 옮기자"가 아닙니다. 내부 research pipeline, batch automation, prototype, low-risk data workflow에서 실제 비용과 실패 양상을 측정해 보는 편이 맞습니다. 기능 자체가 preview이고 API breaking change 가능성이 있기 때문에, 외부 고객에게 강한 안정성을 약속하는 core workflow에 곧장 넣기에는 이릅니다.

Google의 진짜 경쟁자는 agent framework가 아닙니다

Managed Agents는 LangGraph, CrewAI, LlamaIndex 같은 agent framework와도 경쟁하지만, 더 큰 경쟁 구도는 다릅니다. OpenAI는 Agents SDK와 Codex cloud workflow를 통해 developer task를 controlled environment로 옮기고 있습니다. Anthropic은 Claude Code, MCP ecosystem, Stainless 인수로 agent가 API와 CLI를 다루는 연결 배관을 강화했습니다. GitHub는 Copilot app, cloud agent, review feedback handoff로 GitHub workflow 자체를 agent runtime처럼 만들고 있습니다. Vercel도 Sandbox와 AI Gateway, deployment workflow를 agent 실행 표면으로 넓히고 있습니다.

Google의 차별점은 Gemini API, AI Studio, Antigravity, Android, Workspace, Google Cloud가 한 회사 안에 있다는 점입니다. Managed Agents가 API에서 시작해 AI Studio visual playground, Antigravity desktop, Gemini Enterprise Agent Platform으로 이어지면, Google은 개발자가 agent를 만들고, 시험하고, 배포하고, 기업 환경에 연결하는 전체 경로를 제공할 수 있습니다. 이 전략은 모델 하나의 benchmark보다 더 끈적합니다.

다만 Google의 약점도 여기서 나옵니다. 제품 표면이 많을수록 용어와 경계가 복잡해집니다. Antigravity IDE, Antigravity agent, Antigravity SDK, Managed Agents, Interactions API, Gemini Enterprise Agent Platform이 각각 어디까지 책임지는지 명확해야 합니다. 개발자는 "내가 써야 하는 것은 API인가, IDE인가, SDK인가, Cloud product인가"를 빠르게 이해해야 합니다. Google이 이 경계를 정리하지 못하면, agent runtime 자체가 좋아도 adoption은 느려질 수 있습니다.

커뮤니티가 주목하는 것은 편의보다 통제입니다

Hacker News와 GeekNews에서 이번 발표 자체가 폭발적으로 논의되지는 않았습니다. 다만 주변 반응은 방향을 보여줍니다. GeekNews에는 Gemini CLI가 2026년 6월 18일부터 무료/Pro/Ultra 사용자에게 중단되고 Antigravity CLI로 전환된다는 글이 올라왔고, 많은 관심은 "Google이 기존 CLI 사용자를 새 agent platform으로 밀어 넣는가"에 쏠렸습니다. Managed Agents도 같은 흐름 안에 있습니다. Google은 Gemini를 단순 모델 API가 아니라 Antigravity 중심의 agent platform으로 재배치하고 있습니다.

개발자 블로그와 초기 해설 글들은 Managed Agents를 serverless agent runtime으로 읽습니다. 긍정적인 쪽은 한 번의 API call로 sandbox, web access, code execution, file management를 얻는 friction 감소를 봅니다. 회의적인 쪽은 token cost와 preview 제한, network default, data retention을 봅니다. 두 반응은 모순되지 않습니다. agent infrastructure를 관리하지 않아도 된다는 장점은 분명하지만, 관리하지 않는다는 말은 provider의 기본값을 더 꼼꼼히 읽어야 한다는 뜻이기도 합니다.

AI agent 제품을 만드는 팀에게 이 반응은 좋은 체크리스트입니다. "agent가 할 수 있다"는 데모보다 "agent가 어디에서 실행되는가", "어떤 state가 남는가", "네트워크가 어디까지 열려 있는가", "사용자가 비용을 예측할 수 있는가", "실패한 tool loop를 어떻게 중단하는가"가 더 중요해지고 있습니다. Managed Agents는 이 질문들을 한 화면에 모아 둔 제품입니다.

실무적으로 무엇을 해볼 만한가

첫째, low-risk workflow에서 실제 token cost를 측정해야 합니다. 예를 들어 공개 웹 데이터를 요약하거나, 샘플 CSV를 분석하거나, 내부 문서가 아닌 synthetic repository를 수정하는 작업이 적당합니다. 단일 prompt가 어떤 step으로 쪼개지고, 몇 번 tool을 호출하고, 총 token이 얼마나 나오는지 기록해야 합니다. 이 측정 없이 사용자당 fixed quota나 pricing을 설계하면 비용이 흔들릴 수 있습니다.

둘째, network allowlist와 credential scope를 기본 설계에 넣어야 합니다. Managed Agents가 Google hosted sandbox에서 실행된다는 점은 편리하지만, outbound network가 기본적으로 열려 있다는 문서 내용을 무시하면 안 됩니다. 사내 API, SaaS API, database proxy를 붙이는 순간 agent가 접근할 수 있는 범위는 곧 제품 책임입니다.

셋째, state retention을 사용자 정책으로 바꿔야 합니다. previous_interaction_id와 reusable environment는 좋은 기능입니다. 그러나 고객 데이터가 들어가는 agent라면 "작업을 이어가기 위해 provider에 보관되는 interaction state"를 제품 약관, 관리자 설정, deletion workflow와 연결해야 합니다. 이 영역은 모델 성능보다 법무/보안/플랫폼 팀의 검토가 더 중요할 수 있습니다.

넷째, 기존 agent framework와의 역할을 나눠야 합니다. LangGraph나 CrewAI로 orchestration을 직접 관리하는 팀이라면 Managed Agents가 모든 것을 대체하지 않습니다. 오히려 특정 작업을 Google hosted Antigravity agent에게 위임하고, 나머지 business logic은 기존 backend가 통제하는 hybrid 구조가 현실적입니다. 반대로 agent infra를 만들 여력이 없는 팀에게는 API 하나로 sandbox worker를 얻는 것이 빠른 출발점이 될 수 있습니다.

결론: 모델 API 다음의 전장은 런타임입니다

Gemini API Managed Agents는 아직 preview이고, 제한도 많습니다. MCP도 아직 붙지 않고, structured output도 안 되며, production 안정성을 요구하는 핵심 업무에 바로 넣기에는 조심해야 합니다. 그럼에도 이 발표가 중요한 이유는 분명합니다. Google이 AI agent를 "모델이 도구를 부르는 패턴"이 아니라 "호스팅되는 실행 환경과 상태를 가진 API 제품"으로 정의하기 시작했기 때문입니다.

앞으로 AI 앱의 경쟁은 모델 이름만으로 설명되지 않을 가능성이 큽니다. 어떤 sandbox에서 실행되는지, 상태를 얼마나 오래 보관하는지, tool loop를 어떻게 관찰하는지, network와 credential을 어떻게 제한하는지, 비용이 어떤 단위로 튀는지가 더 중요해집니다. Managed Agents는 이 변화를 Google식으로 보여주는 신호입니다. 한 번의 API 호출은 편리합니다. 하지만 그 한 번의 호출 안에서 3백만 token, 외부 네트워크, 보관되는 state, 자동화된 파일 작업이 함께 움직인다면, 개발자가 설계해야 할 것은 prompt가 아니라 운영 경계입니다.