Gemini API 관리형 에이전트, 샌드박스가 된 모델 호출

AI 요약

• 무슨 일: Google이 Gemini API에 Managed Agents를 공개했습니다.
  • 단일 API 호출로 Antigravity agent를 띄우고, 격리된 Linux 환경에서 도구 호출, 코드 실행, 파일 작업, 웹 탐색을 수행합니다.
• 의미: 모델 API가 텍스트 생성 엔드포인트에서 상태와 실행 환경을 포함한 에이전트 런타임으로 확장되고 있습니다.
• 주의점: Public Preview, 기본 네트워크 허용, token-heavy interaction, 데이터 보관 정책은 실제 도입 전 확인해야 합니다.
  • Google 문서는 단일 interaction이 보통 100k~3M tokens를 소비할 수 있다고 설명합니다.

2026년 5월 19일 Google I/O 2026에서 나온 여러 Gemini 발표 가운데 개발자가 오래 봐야 할 변화는 모델 이름보다 API의 모양입니다. Google은 Gemini API Managed Agents를 공개하며, 단일 API 호출로 Antigravity agent를 실행할 수 있게 했습니다. 이 에이전트는 Google이 호스팅하는 격리 Linux 환경에서 reasoning, tool use, code execution, file management, web browsing을 수행합니다.

겉으로는 Gemini 3.5 Flash 발표의 부속 기능처럼 보입니다. 실제로 Google은 같은 날 Gemini 3.5 Flash를 공개하며 Terminal-Bench 2.1 76.2%, GDPval-AA 1656 Elo, MCP Atlas 83.6%, CharXiv Reasoning 84.2%, frontier model 대비 4배 output tokens/sec라는 숫자를 전면에 놓았습니다. 이 수치가 뉴스의 첫 번째 후크인 것은 맞습니다. 하지만 더 구조적인 변화는 Gemini API가 모델 응답을 반환하는 통로를 넘어, remote sandbox와 agent harness를 빌려주는 실행 계층으로 바뀌고 있다는 점입니다.

Google의 표현을 빌리면 Managed Agents는 production-grade agent를 만들 때 필요한 복잡한 인프라, scaffolding, isolated sandbox 관리를 추상화합니다. 개발자는 에이전트의 행동과 제품 경험에 집중하라는 메시지입니다. 이 말은 동시에 중요한 소유권 이동을 뜻합니다. 지금까지 많은 AI 팀은 모델 API, 자체 orchestration 코드, container sandbox, browser automation, credential proxy, logging, retry queue를 각자 이어 붙였습니다. Google은 그 중 일부를 Gemini API 안으로 가져오겠다고 선언했습니다.

모델 발표보다 중요한 API의 형태

Gemini 3.5 Flash는 분명 이번 발표의 엔진입니다. Google은 이 모델을 agentic workflow와 coding에 맞춘 Flash 계열의 새 모델로 설명합니다. 3.5 Pro는 다음 달 출시를 예고했고, 3.5 Flash는 Gemini app, Search AI Mode, Antigravity, Gemini API, AI Studio, Android Studio, Gemini Enterprise Agent Platform에서 바로 사용할 수 있다고 밝혔습니다.

하지만 API 개발자에게 더 큰 질문은 "이 모델이 얼마나 빠른가"만이 아닙니다. 이 모델을 어떤 runtime에 태울 것인가가 중요합니다. 긴 작업을 맡기는 에이전트는 단순 completion보다 많은 상태를 필요로 합니다. 파일 시스템이 있어야 하고, 명령을 실행해야 하고, 실패한 작업을 이어가야 하며, 중간 tool call과 reasoning step을 관찰할 수 있어야 합니다. 웹을 탐색한다면 network policy가 필요하고, 외부 API를 호출한다면 credential scope가 필요합니다.

Managed Agents는 이 문제를 제품화합니다. Google 공식 글은 단일 호출로 remote Linux environment를 프로비저닝하고, Antigravity agent가 그 안에서 계획하고 도구를 호출하며 코드를 실행하고 파일을 관리하고 웹을 탐색한다고 설명합니다. 각 interaction은 환경을 새로 만들거나 기존 환경을 받아 이어갈 수 있습니다. follow-up call에서 파일과 상태를 그대로 유지할 수 있다는 뜻입니다.

이 지점에서 Gemini API는 전통적인 모델 API와 다른 성격을 띱니다. 예전의 API 호출은 대체로 "입력을 보내고 출력을 받는" 구조였습니다. 물론 function calling, code execution, tool use가 이미 있었지만, 실행 환경과 장기 상태는 주로 애플리케이션 쪽 책임이었습니다. Managed Agents는 "작업을 맡길 원격 작업자"에 가까워집니다. 모델이 답변만 하는 것이 아니라, Google-hosted sandbox 안에서 실제로 파일과 도구를 다룹니다.

Interactions API가 깔아둔 바닥

이번 발표는 갑자기 나온 단독 기능이 아닙니다. Google은 2025년 12월 Interactions API를 공개하며 모델과 에이전트를 같은 인터페이스에서 다루겠다고 예고했습니다. 당시 핵심은 generateContent가 stateless request-response에 적합했다면, agentic application은 interleaved messages, thoughts, tool calls, state를 다룰 별도 데이터 모델이 필요하다는 문제의식이었습니다.

2026년 5월 19일 업데이트된 Google AI docs는 더 명확합니다. Interactions API는 신규 Gemini 프로젝트의 표준으로 권장되며, agentic workflow, server-side state management, complex multimodal multi-turn conversation에 최적화됐다고 설명합니다. generateContent는 계속 지원되지만, 새로운 agentic capabilities와 tools는 앞으로 Interactions API에 독점적으로 먼저 들어갈 수 있다는 문장도 있습니다.

이 차이는 제품 전략에 가깝습니다. Google은 completion API를 조금씩 늘려 agent runtime처럼 보이게 만드는 대신, Interaction이라는 리소스를 중심에 둡니다. 하나의 interaction은 대화나 작업의 완결된 turn이며, execution steps의 시간순 기록을 담습니다. 이 steps에는 model thoughts, server-side/client-side tool calls, results, final model output이 포함됩니다. 개발자는 interaction.output_text 같은 convenience property로 최종 출력만 볼 수도 있지만, 고급 사용에서는 steps timeline을 직접 순회해 중간 검색, tool call, thinking process를 렌더링하거나 디버깅할 수 있습니다.

이 표가 보여주는 것은 기능 추가보다 추상화의 이동입니다. 모델 호출은 더 이상 "문장 생성"만의 단위가 아닙니다. Google은 interaction을 작업 기록으로 만들고, agent를 environment와 연결하며, state와 execution trace를 API 리소스로 다루려 합니다.

AGENTS.md와 SKILL.md가 API의 일부가 되는 장면

Managed Agents 발표에서 눈에 띄는 부분은 custom agent 정의 방식입니다. Google은 개발자가 complex orchestration code를 직접 쓰는 대신, AGENTS.md와 SKILL.md 같은 markdown 파일로 instructions와 skills를 정의하고 managed agent로 등록할 수 있다고 설명합니다. 이는 로컬 코딩 에이전트 세계에서 이미 익숙한 패턴입니다. 프로젝트 루트의 지침 파일, 재사용 가능한 skill, 특정 작업용 템플릿이 에이전트의 행동을 바꿉니다.

흥미로운 점은 이 파일 기반 관습이 이제 API-managed runtime으로 올라온다는 데 있습니다. 로컬 Codex, Claude Code, Antigravity CLI, 여러 agent framework에서 보던 "프로젝트 지침" 문법이 서비스형 agent 배포 단위로 바뀝니다. 개발자는 prompt string 하나를 보내는 대신, agent definition을 versionable files로 관리합니다. 이 파일들은 코드 리뷰, 변경 이력, 배포 파이프라인의 대상이 될 수 있습니다.

이 변화는 AI 애플리케이션 개발의 운영 방식을 바꿉니다. 기존에는 prompt와 tool schema가 코드 안에 숨어 있거나 dashboard 설정에 흩어져 있었습니다. AGENTS.md와 SKILL.md 같은 파일이 공식 primitive가 되면, 에이전트 행동은 더 명시적인 구성물이 됩니다. 어떤 권한을 기대하는지, 어떤 절차를 따르는지, 어떤 출력 형식을 지키는지, 어떤 도구를 우선하는지가 파일 단위로 리뷰됩니다.

물론 파일화가 곧 안전을 보장하지는 않습니다. 지침 파일은 공격면이 될 수도 있습니다. 프로젝트 안에 있는 instruction이 외부 tool call이나 credential 사용과 결합되면, prompt injection과 supply-chain risk가 더 실질적인 문제가 됩니다. 그래서 Managed Agents의 진짜 경쟁력은 markdown 편의성이 아니라, 이 파일 기반 customization을 어떤 sandbox, network rule, credential boundary, audit trail과 묶느냐에서 갈립니다.

샌드박스는 편의 기능이 아니라 보안 경계입니다

Google AI docs의 Agents Overview는 Managed Agents를 Public Preview로 표시하고, 모든 agent가 OS-level isolated sandbox에서 실행된다고 설명합니다. 동시에 중요한 주의점도 적습니다. 기본적으로 environment는 unrestricted outbound network access를 갖습니다. 필요하면 allowlist로 outbound traffic을 특정 domain이나 wildcard pattern으로 제한할 수 있습니다.

이 문장은 도입 검토에서 반드시 읽어야 합니다. "Google-hosted sandbox"는 로컬 머신을 보호하는 데 도움이 될 수 있지만, 네트워크가 기본 허용이면 외부 API 호출, 데이터 전송, package download, web browsing이 모두 agent 행동의 일부가 됩니다. 에이전트가 브라우징과 코드 실행을 함께 한다면 편의성은 높아지지만, 실수와 공격의 반경도 넓어집니다. 개발팀은 모델 성능보다 먼저 network allowlist와 credential scope를 설계해야 합니다.

credentials 처리도 마찬가지입니다. Google 문서는 외부 도구와 API를 연결할 때 신뢰할 수 있는 도구만 쓰고 권한을 최소화하라고 권합니다. credentials는 egress proxy header transformation으로 안전하게 주입될 수 있으며 sandbox 안에 직접 노출되지 않는다고 설명합니다. 그러나 에이전트는 접근 가능한 credential을 사용할 수 있습니다. 결국 "에이전트에게 어떤 credential을 주는가"가 권한 모델의 중심입니다.

실무적으로는 세 가지 원칙이 필요합니다. 첫째, long-lived key보다 short-lived token을 써야 합니다. 둘째, service account나 API key는 해당 작업에 필요한 최소 권한이어야 합니다. 셋째, 네트워크 경로는 기본 허용으로 두지 말고 업무별 allowlist로 좁혀야 합니다. Managed Agents는 sandbox를 대신 만들어주지만, 신뢰 경계를 대신 결정해주지는 않습니다.

비용과 보관 정책은 모델 가격표만으로 보이지 않습니다

Managed Agents의 비용도 단순한 "input/output token 가격"으로만 보기 어렵습니다. Google 문서는 Public Preview 기준 managed agents가 Gemini model tokens와 tool usage 기반 pay-as-you-go 모델을 쓴다고 설명합니다. 특히 단일 interaction이 여러 reasoning loop를 촉발할 수 있고, 보통 100k에서 3M tokens를 소비할 수 있다고 적습니다. preview 기간에는 environment compute가 과금되지 않지만, 이 조건은 정식 출시 때 바뀔 수 있습니다.

이 숫자는 중요합니다. 에이전트가 파일을 읽고, 웹을 탐색하고, 코드를 실행하고, 실패를 복구하면 token 사용량은 빠르게 커집니다. 한 번의 "이 앱을 고쳐줘"가 한 번의 completion이 아니라 여러 단계의 계획, 검색, 실행, 로그 해석, 재시도, 요약으로 쪼개지기 때문입니다. 비용 예측은 prompt 길이보다 작업의 반복 횟수와 tool behavior에 더 민감해집니다.

보관 정책도 제품 설계에 영향을 줍니다. Interactions API 문서는 기본적으로 store=true이며, server-side state management, background execution, observability를 위해 Interaction objects를 저장한다고 설명합니다. Paid Tier는 55일, Free Tier는 1일 retention입니다. 원하지 않으면 store=false를 설정할 수 있지만, 이 경우 background=true와 호환되지 않고 previous_interaction_id로 후속 turn을 이어갈 수 없습니다.

즉 privacy와 편의성 사이에 명확한 tradeoff가 있습니다. 상태를 서버에 맡기면 history 재전송이 줄고 implicit caching 가능성이 높아져 성능과 비용에 유리할 수 있습니다. 반대로 민감한 workflow에서는 저장 기간, 삭제 API, compliance boundary, data processing terms를 검토해야 합니다. 특히 customer data, proprietary code, financial documents를 agent에게 맡기는 팀은 retention을 단순 문서 항목으로 넘길 수 없습니다.

이 숫자들은 Managed Agents를 "편한 agent API"가 아니라 운영 자산으로 봐야 하는 이유입니다. 호출이 비싸질 수 있고, 상태가 저장될 수 있으며, environment lifecycle이 제품 동작에 영향을 줄 수 있습니다.

Antigravity가 IDE에서 API로 내려온다

같은 날 Google은 I/O developer highlights에서 Antigravity 2.0 desktop app, Antigravity CLI, Antigravity SDK, Gemini Enterprise Agent Platform 연결을 함께 발표했습니다. 최근 Gemini CLI 개인 사용자 경로를 Antigravity CLI로 옮기는 발표까지 고려하면, Google의 방향은 꽤 일관됩니다. Antigravity를 하나의 제품 이름이 아니라 agent harness의 중심으로 만들려는 것입니다.

Managed Agents도 이 흐름 안에 있습니다. Google은 Managed Agents가 Antigravity agent harness로 구동되고 Gemini 3.5 Flash에 맞춰 최적화됐다고 말합니다. 개발자 표면은 여러 개입니다. 데스크톱 앱에서는 여러 에이전트를 병렬로 조정합니다. CLI에서는 터미널에서 가볍게 에이전트를 생성합니다. SDK는 같은 harness에 대한 programmatic access를 제공합니다. Gemini API Managed Agents는 그 harness를 cloud sandbox와 API primitive로 엽니다.

이 전략의 강점은 일관성입니다. 모델, agent harness, API, AI Studio, Android, Firebase, Search, Gemini Enterprise가 같은 흐름으로 묶이면 Google 생태계 안에서는 agentic workflow를 빠르게 확장할 수 있습니다. Google AI Studio에서 만든 프로젝트를 Antigravity로 가져오고, Managed Agents로 API화하고, Workspace API를 native call로 붙이는 그림도 가능합니다.

약점도 분명합니다. 개발자는 Google의 runtime 추상화에 더 깊이 들어가게 됩니다. 에이전트 행동, state, sandbox, token usage, network rule, credential injection, retention이 모두 플랫폼 정책과 문서 변화에 영향을 받습니다. Interactions API 자체도 Beta이며, docs는 features와 schemas가 breaking changes를 겪을 수 있다고 명시합니다. 안정성이 중요한 production workload에서는 기존 generateContent가 여전히 권장되는 경우도 있습니다.

Search의 generative UI와 같은 방향을 본다

Google은 Search 발표에서도 Gemini 3.5 Flash와 Antigravity를 연결했습니다. AI Mode의 기본 모델을 Gemini 3.5 Flash로 올리고, Search 안에서 custom generative UI, visual tools, simulations, dashboards, trackers를 만들어주는 기능을 예고했습니다. 이 기능은 올해 여름 Search에서 무료로 제공될 generative UI와, 미국 Google AI Pro/Ultra 사용자를 대상으로 먼저 시작될 custom experiences로 나뉩니다.

이것은 consumer product 이야기처럼 보이지만 개발자에게도 힌트가 됩니다. Google이 그리고 있는 agentic future는 "chatbot이 답변한다"가 아닙니다. 사용자의 질문에 맞춰 mini app, dashboard, tracker, simulation을 즉석에서 구성하고, fresh real-time sources와 도구를 결합해 계속 업데이트하는 방향입니다. 그러려면 모델만으로는 부족합니다. 실행 환경, 상태, 데이터 접근, UI 생성, 검증 가능한 tool trace가 필요합니다.

Managed Agents는 그 개발자 버전입니다. Search가 사용자에게 "질문하면 에이전트가 mini app을 만든다"고 말한다면, Gemini API는 개발자에게 "단일 API 호출로 sandboxed agent를 만들고 이어서 운영하라"고 말합니다. 두 발표는 같은 플랫폼적 상상력 위에 있습니다. 모델은 답변자가 아니라 작업자이고, API는 문자열 반환자가 아니라 실행 조정자가 됩니다.

커뮤니티의 의심은 benchmark와 제품 경험 사이에 있다

Google 발표는 benchmark와 partner 사례가 많습니다. Shopify, Macquarie Bank, Salesforce, Ramp, Xero, Databricks 같은 이름도 언급됩니다. 하지만 에이전트 제품은 benchmark만으로 판단하기 어렵습니다. Hacker News의 관련 Gemini 토론에서는 Gemini가 benchmark에서 강하다는 평가와 함께, 실제 Antigravity 제품 경험이 Claude Code나 Codex보다 만족스럽지 않다는 반응도 보입니다. 표현은 거칠지만 메시지는 분명합니다. 모델 성능과 day-to-day agent experience는 별도 문제입니다.

이 지점이 Managed Agents의 관전 포인트입니다. Google이 말한 remote sandbox와 agent harness가 실제 개발자에게 좋은 경험을 주려면, API가 안정적이어야 하고, logs와 steps가 이해 가능해야 하며, 실패 복구가 예측 가능해야 합니다. network allowlist, credential injection, cold start, token cost, retention control도 documentation 수준을 넘어 제품 경험으로 이어져야 합니다.

특히 "단일 API 호출"이라는 표현은 양면적입니다. 시작은 쉬워집니다. 그러나 그 호출이 100k~3M tokens를 쓰고, 여러 tool loop를 돌고, 외부 웹을 탐색하고, credentials가 붙은 API를 호출한다면, 운영자는 그 안에서 무슨 일이 일어났는지 알아야 합니다. 에이전트의 편의성은 추적 가능성과 함께 와야 합니다.

개발팀이 지금 확인할 것

첫째, 새 프로젝트에서 Interactions API를 검토해야 합니다. Google docs는 Interactions API를 신규 Gemini 프로젝트의 표준으로 권장하지만, Beta와 breaking changes를 명시합니다. production 안정성이 우선이면 generateContent 유지가 나을 수 있고, agentic workflow와 server-side state가 핵심이면 Interactions API를 실험해야 합니다.

둘째, Managed Agents를 "코드 실행 가능한 LLM" 정도로 생각하면 위험합니다. 이것은 sandbox, network, credentials, state, lifecycle, billing을 포함한 runtime입니다. 팀은 allowlist 기본값, egress policy, service account 범위, token budget, deletion policy를 설계해야 합니다.

셋째, agent definition을 파일로 관리하는 방식을 준비해야 합니다. AGENTS.md와 SKILL.md는 단순한 prompt 문서가 아니라 배포 가능한 행동 정의가 될 수 있습니다. 코드 리뷰, linting, secret scanning, prompt injection review, versioning이 필요해집니다. AI 팀과 보안팀, 플랫폼팀이 같은 파일을 다른 관점으로 봐야 합니다.

넷째, cost observability를 처음부터 넣어야 합니다. 단일 interaction이 여러 loop로 확장되는 구조에서는 평균 token 사용량보다 tail cost가 더 중요합니다. 실패한 작업, 무한 재시도, 큰 repository scan, web browsing loop, generated UI 반복은 비용을 크게 흔들 수 있습니다. 모델 가격표가 아니라 작업 유형별 budget을 봐야 합니다.

결론: Gemini API가 작업자를 호스팅하기 시작했습니다

Gemini API Managed Agents는 "Google도 agent API를 냈다" 정도로 끝낼 발표가 아닙니다. 더 정확히는 모델 API의 경계가 바뀌는 사건입니다. 개발자는 이제 텍스트를 생성하는 모델뿐 아니라, 격리된 Linux 환경에서 파일을 만들고 코드를 실행하고 웹을 탐색하는 원격 작업자를 API로 호출할 수 있습니다. 그 작업자는 Gemini 3.5 Flash와 Antigravity harness를 쓰고, Interactions API의 상태와 execution steps 위에서 움직입니다.

이 변화는 편리합니다. 직접 sandbox infrastructure를 만들지 않아도 되고, agent harness를 처음부터 설계하지 않아도 됩니다. AGENTS.md와 SKILL.md로 custom agent를 정의하는 방식은 개발자 워크플로와도 잘 맞습니다. 하지만 편리한 만큼 운영 질문도 커집니다. 네트워크는 어디까지 허용할 것인가. 어떤 credential을 줄 것인가. 상태는 며칠 보관할 것인가. 한 interaction의 token budget은 얼마인가. preview API의 breaking changes를 어떻게 흡수할 것인가.

Gemini 3.5 Flash의 benchmark는 발표를 이해하는 데 필요합니다. 그러나 이 뉴스의 본질은 benchmark 1위 경쟁보다 agent runtime의 cloud primitive화입니다. Google은 Antigravity를 앱, CLI, SDK, Enterprise, API로 넓히며 "모델을 호출한다"는 개발자 경험을 "관리형 작업자를 실행한다"로 바꾸려 합니다. 이제 AI 애플리케이션 팀이 비교해야 할 것은 모델 품질만이 아닙니다. 누가 더 안전하고, 관찰 가능하고, 비용 예측 가능한 에이전트 실행 계층을 제공하는지가 다음 경쟁 축입니다.