Gemini API Managed Agents, 한 번 호출로 뜨는 리눅스 에이전트

Google이 2026년 5월 19일 Gemini API에 Managed Agents 프리뷰를 넣었습니다. 발표 문장의 표면은 “한 번의 API 호출로 에이전트를 띄운다”입니다. 개발자가 실제로 봐야 할 변화는 더 좁고 구체적입니다. Gemini API 호출이 이제 텍스트 응답을 받는 경로만이 아니라, Google이 호스팅하는 리눅스 샌드박스에서 에이전트가 계획하고, 도구를 호출하고, 코드를 실행하고, 파일 상태를 다음 호출까지 이어가는 작업 단위가 됐습니다.

Google 발표에 따르면 이 기능은 Antigravity agent로 구동됩니다. Antigravity agent는 Gemini 3.5 Flash 기반이며, Antigravity IDE와 같은 harness를 사용합니다. API 문서의 예시는 agent: "antigravity-preview-05-2026", environment: "remote"를 넘겨 Hacker News 상위 글을 읽고 PDF로 저장하는 작업을 맡깁니다. 이 예시는 과장된 데모라기보다 Google이 API 계약으로 노출하려는 범위를 드러냅니다. 모델 호출, 파일시스템, 웹 접근, 코드 실행, 산출물 저장이 하나의 interaction 안에 묶입니다.

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "Content-Type: application/json" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Api-Revision: 2026-05-20" \
  -d '{
    "agent": "antigravity-preview-05-2026",
    "input": "Read Hacker News, summarize the top 10 stories, and save the results as a PDF.",
    "environment": "remote"
  }'

기존 Gemini API의 중심이 generateContent였다면, Google은 2025년 12월 Interactions API를 공개하면서 모델과 에이전트를 같은 인터페이스로 다루겠다고 예고했습니다. 당시 Google은 agentic application에서 interleaved messages, thoughts, tool calls, state를 다루기 위해 별도 데이터 모델이 필요하다고 설명했습니다. 이번 Managed Agents는 그 예고의 두 번째 단계입니다. Deep Research 같은 Google built-in agent를 호출하던 통로가 개발자용 Antigravity runtime으로 확장됐습니다.

I/O 2026 개발자 발표에서 Google은 Managed Agents만 따로 내놓지 않았습니다. 같은 날 Antigravity 2.0 desktop application, Antigravity CLI, Antigravity SDK, Gemini Enterprise Agent Platform 연동, Google AI Studio의 agent playground를 함께 묶었습니다. 이 묶음은 Google이 코딩 에이전트를 하나의 앱으로만 보지 않는다는 단서입니다. IDE는 사람이 여러 에이전트를 조율하는 표면이고, CLI는 터미널 작업 표면이며, SDK는 자체 인프라 배포 경로이고, Gemini API Managed Agents는 외부 제품이 에이전트 작업을 호출하는 서버 측 표면입니다.

Managed Agents의 첫 번째 실무 변화는 샌드박스 운영입니다. Google 문서는 한 API 호출이 리눅스 샌드박스를 프로비저닝하고, 에이전트가 그 안에서 Bash, Python, Node.js 명령을 실행하며, 파일을 읽고 쓰고 검색한다고 설명합니다. 기본 환경에는 Python 3.12와 Node.js 22가 들어갑니다. environment: "remote"는 새 환경을 만들고, 기존 environment ID를 넘기면 파일과 상태를 이어받습니다. “대화 기억”이 아니라 실행 파일, 중간 산출물, 설치된 패키지, 작업 디렉터리 상태가 API 호출 사이에 남는 구조입니다.

두 번째 변화는 도구 권한입니다. Antigravity agent 문서 기준 기본 도구는 code_execution, google_search, url_context입니다. environment를 지정하면 파일시스템 도구가 자동으로 활성화됩니다. 개발자는 tools 배열로 일부 도구만 남길 수 있습니다. agent가 웹에서 자료를 가져오고, 코드를 실행하고, 파일을 편집하는 동안 모델 출력만 저장하던 로깅으로는 충분하지 않습니다. 호출 요청, environment ID, network rule, tool set, 산출물 diff를 함께 기록해야 나중에 재현할 수 있습니다.

보안 문서에서 눈에 띄는 문장은 기본 outbound network입니다. Google은 모든 agent가 OS 수준으로 격리된 샌드박스에서 실행된다고 설명하지만, 환경의 outbound network는 기본적으로 제한이 없습니다. 별도 allowlist를 사용해 특정 도메인이나 wildcard pattern으로 제한할 수 있습니다. 사내 Git 저장소, 패키지 registry, ticket system, 결제 API를 연결하는 순간 “모델이 무엇을 말했는가”보다 “샌드박스가 어디로 나갈 수 있었는가”가 더 직접적인 위험 변수가 됩니다.

credential 주입 방식도 운영 기준을 바꿉니다. Google 문서는 외부 도구와 API를 연결할 때 최소 권한 service account나 API key를 쓰고, 긴 수명 key보다 짧은 수명 token을 선호하며, credential의 전체 scope를 agent에게 줄 의사가 있는지 확인하라고 권합니다. header transformation을 통해 credential을 sandbox 안에 직접 노출하지 않는 방식도 언급합니다. 그래도 agent는 접근 가능한 credential을 사용할 수 있습니다. 권한을 “모델에 주는 것”이 아니라 “원격 작업 환경에 주는 것”으로 봐야 합니다.

비용 계산도 단순 token 가격표와 다릅니다. Agents Overview 문서는 Managed Agents가 Gemini model token과 tool usage 기반 pay-as-you-go를 쓰며, 프리뷰 동안 environment compute는 과금하지 않는다고 적습니다. 같은 문서에는 한 interaction이 여러 reasoning loop를 만들 수 있고 보통 100k-3M tokens를 소비한다는 설명이 있습니다. 3M token은 chat completion 한 번의 감각과 맞지 않습니다. 웹 검색, 파일 읽기, 코드 실행, 오류 수정, 재실행이 같은 작업 안에서 반복되면 token budget은 “질문 하나”가 아니라 “작업 하나” 기준으로 잡아야 합니다.

제한 조건은 제품의 사용 경계를 보여줍니다. environment는 7일 동안 비활성 상태이면 영구 삭제됩니다. VM은 짧은 비활성 시간 뒤 spin-down되고, 다음 요청 때 상태를 복구합니다. 최대 managed agent 수는 1,000개입니다. 이 조건은 장기 실행 daemon이나 영구 worker보다는, 요청이 들어올 때 깨워 작업하고 산출물을 남기는 ephemeral worker에 가깝습니다. 월별 배치, 문서 변환, 리서치, 테스트 실행, 코드 수정 검토처럼 작업 단위가 명확한 흐름에 먼저 맞습니다.

Google의 발표는 경쟁사와 다른 지점을 건드립니다. OpenAI Codex, GitHub Copilot coding agent, Anthropic Claude Code는 개발자가 보는 작업 표면과 리뷰 루프를 먼저 장악했습니다. Google은 이번 발표에서 API 호출자가 agent runtime을 직접 부를 수 있게 했습니다. 외부 SaaS가 “사용자가 버튼을 누르면 agent가 repo를 체크아웃하고 테스트를 돌린 뒤 보고서를 남긴다”는 기능을 만들 때, 직접 Kubernetes job, sandbox image, browser tool, secret proxy를 모두 구성하지 않아도 되는 선택지를 제시한 셈입니다.

AI Studio 쪽 배치도 실험 경로를 좁힙니다. Google 발표는 새 custom templates로 Google AI Studio Playground에서 Managed Agents를 바로 시작할 수 있다고 적었습니다. 코드로 API를 붙이기 전에 prompt, tool set, instruction file, 산출물 형태를 눈으로 확인하는 통로입니다. 제품 팀에서 이 경로가 유용한 지점은 prototype의 속도보다 handoff입니다. PM이나 운영 담당자가 AI Studio에서 agent behavior를 확인하고, 엔지니어가 같은 agent 정의를 API 호출이나 managed agent 등록으로 옮기는 구조가 가능합니다.

기업용 preview도 별도 신호입니다. Google은 Gemini Enterprise Agent Platform에서 Managed Agents 지원을 preview로 추가했다고 밝혔습니다. 이 문장은 소비자용 Antigravity 앱과 다른 구매자를 가리킵니다. 기업 고객은 단일 에이전트의 성능보다 Google Cloud project 연결, identity, audit, data boundary, network policy를 먼저 묻습니다. Managed Agents가 Gemini API 안에 들어왔다는 사실보다, 같은 harness가 desktop, CLI, SDK, enterprise platform, API에 반복 배치된 점이 Google의 판매 전략에 더 가깝습니다.

그 대가로 실행 계층의 통제권 일부가 Google로 이동합니다. VentureBeat는 이 지점을 “deployment work를 한 호출로 접는 대신 execution layer control이 쟁점이 된다”고 해석했습니다. 개발자 팀 관점에서도 같은 질문이 남습니다. sandbox image를 얼마나 재현할 수 있는지, network allowlist가 얼마나 세밀한지, tool call 로그를 감사 시스템에 어떻게 넣는지, 실패한 run을 같은 상태로 재시도할 수 있는지, 장기 저장이 필요한 산출물을 어디로 빼낼지 확인해야 합니다.

커뮤니티 반응은 아직 제품 사용 후기보다 구조 해석에 가깝습니다. 2026년 6월 1일 조사 시점의 Hacker News 첫 페이지에는 이 발표가 보이지 않았고, GeekNews 최신 목록에도 직접 항목은 없었습니다. Reddit에는 VentureBeat 재게시나 “agents-as-a-service”라는 짧은 반응이 있었지만 낮은 투표 수에 머물렀습니다. 조용한 반응은 영향이 작다는 증거라기보다, API preview가 실제 비용, quota, failure mode를 겪기 전이라는 뜻에 가깝습니다.

한국 개발자 팀이 먼저 볼 부분은 Gemini API를 이미 쓰는지보다 agent 작업의 관측성입니다. 호출 로그에는 모델명과 prompt만 남겨서는 부족합니다. agent, environment, tool 목록, network rule, 입력 파일, 산출 파일, token 사용량, tool 사용량, human approval 여부를 같은 trace로 묶어야 합니다. 특히 테스트 실패를 고치는 coding agent, 데이터셋을 가공하는 analyst agent, 사내 문서를 갱신하는 documentation agent는 성공 산출물보다 실패한 중간 상태가 나중의 감사 자료가 됩니다.

Managed Agents는 “에이전트를 쉽게 만든다”는 추상 구호보다 더 좁은 사건입니다. Google이 Gemini API 안에 원격 리눅스 환경, Antigravity harness, 파일 상태, 웹 접근, tool loop를 넣었습니다. 이 조합은 agent를 제품 기능으로 호출하려는 팀에게 배포 시간을 줄일 수 있습니다. 동시에 token budget, network egress, credential scope, environment deletion, 산출물 보존을 제품 요구사항으로 올려놓습니다. 2026년의 에이전트 API 비교표는 모델 benchmark 옆에 실행 위치와 운영 계약을 함께 적어야 합니다.