한 번 호출하면 리눅스가 뜬다, Gemini 에이전트 API의 선

AI 요약

• 무슨 일: Google이 Gemini API Managed Agents를 Public Preview로 공개했습니다.
  • 단일 호출로 Antigravity agent가 Google 관리 Linux 샌드박스에서 추론, 도구 호출, 코드 실행, 파일 관리, 웹 브라우징을 수행합니다.
• 의미: 에이전트 경쟁의 중심이 모델 품질에서 실행 환경 API로 이동하고 있습니다.
• 주의점: preview, 기본 outbound network, interaction 보관, 100k~3M token 작업량은 운영 설계의 전제입니다.
  • 빠른 시작만 볼 것이 아니라 권한, 비용, 상태 삭제, 로그 검증, provider lock-in을 함께 봐야 합니다.

Google이 Gemini API에 Managed Agents를 넣었습니다. 발표 문장만 보면 "에이전트를 쉽게 만든다"는 익숙한 이야기처럼 보입니다. 그러나 이번 발표에서 더 중요한 변화는 모델이 똑똑해졌다는 주장보다, API 호출의 단위가 바뀌었다는 점입니다. 이제 개발자는 텍스트를 보내 답을 받는 모델 API만 호출하는 것이 아니라, Google이 관리하는 Linux 실행 환경과 에이전트 루프를 함께 호출할 수 있습니다.

Google의 공식 발표는 2026년 5월 19일 올라왔습니다. 같은 날 I/O 개발자 하이라이트에서는 Gemini 3.5 Flash, Antigravity 2.0, Antigravity CLI와 SDK, Google AI Studio 확장, Managed Agents를 하나의 "agentic future" 묶음으로 제시했습니다. 이 묶음의 메시지는 분명합니다. 프롬프트를 모델에 넣는 시대에서, 모델이 파일을 만들고 코드를 실행하고 웹을 탐색하는 작업 환경을 API 제품으로 소비하는 시대로 넘어가겠다는 것입니다.

Google이 설명한 기본 경로는 간단합니다. Gemini API의 Managed Agents는 Antigravity agent를 실행합니다. 이 에이전트는 Gemini 3.5 Flash를 기반으로 하고, Google이 관리하는 격리 Linux 샌드박스 안에서 reasoning, planning, tool calling, code execution, file management, web browsing을 수행합니다. 발표문은 "single call"을 강조합니다. 개발자가 샌드박스 인프라, 에이전트 harness, 파일 상태, 브라우징 도구를 직접 조립하지 않고도, 하나의 API 호출로 작업자를 띄운다는 뜻입니다.

이 변화가 흥미로운 이유는 에이전트 제품의 진짜 병목이 점점 모델 호출 밖으로 이동하고 있기 때문입니다. 간단한 챗봇이라면 모델 입력과 출력만으로 충분합니다. 하지만 실제 업무 에이전트는 파일을 읽고, 코드를 실행하고, 웹에서 자료를 가져오고, 중간 산출물을 저장하고, 실패했을 때 다시 시작하고, 로그를 남기고, 권한을 제한해야 합니다. 이 계층은 그동안 개발팀이 직접 만들거나 LangGraph, CrewAI, Temporal, 자체 worker, 브라우저 자동화, 컨테이너 샌드박스 조합으로 해결하던 영역이었습니다.

Managed Agents는 이 영역을 Gemini API 제품 안으로 끌어옵니다. Google의 Agents Overview 문서는 managed agents를 "configurable agent harness"라고 설명합니다. 문서상 단일 API 호출은 Linux sandbox를 프로비저닝하고, 에이전트가 자율적으로 코드 실행, 파일 관리, 웹 브라우징을 수행하게 합니다. 사용자는 Antigravity agent를 그대로 쓰거나, 자신의 instructions, skills, data를 붙여 custom agent를 만들 수 있습니다.

여기서 눈에 띄는 것은 AGENTS.md와 SKILL.md입니다. Google은 복잡한 orchestration code를 작성하는 대신 markdown 파일로 에이전트의 지시와 스킬을 정의하고 등록할 수 있다고 말합니다. 이는 Claude Code, Codex, 로컬 agent CLI들이 이미 익숙하게 사용하는 저장소 기반 지시 파일 문화와 닮아 있습니다. 차이는 그 파일이 로컬 개발 환경에만 머무르지 않고, Google 관리 샌드박스에서 실행되는 API primitive의 구성 요소가 된다는 점입니다.

Google 발표에는 Ramp, Resemble AI, Klipy, Stitch 같은 초기 사용자의 testimonial 이미지가 포함되어 있습니다. 이들이 모두 같은 메시지를 말하는 것은 아닙니다. 그러나 공통된 신호는 있습니다. 에이전트의 실행 루프와 샌드박스가 플랫폼 안으로 들어가면, 개발자는 "어떻게 실행할 것인가"보다 "어떤 도메인 행동을 제품화할 것인가"에 더 많은 시간을 쓰게 됩니다. 좋은 방향으로 보면 이는 반복 속도를 높입니다. 나쁜 방향으로 보면 실행 계층의 통제권을 특정 플랫폼에 넘기는 선택이 됩니다.

이 구조에서 Interactions API는 단순한 부속 기능이 아닙니다. Google의 Interactions API 문서는 기존 generateContent에서 넘어오는 개발자에게 새로운 API를 소개하면서 server-side history, background tasks, agentic workflows, typed execution steps를 핵심으로 둡니다. 한 번의 interaction은 conversation 또는 task의 완전한 turn이고, 그 내부에는 모델 생각, tool call, tool result, 최종 output이 시간순 step으로 남습니다. 즉 에이전트 실행을 UI나 관측성 도구에서 재구성하기 위한 구조화된 흔적을 API가 제공하려는 방향입니다.

상태 관리도 중요한 변화입니다. 문서에 따르면 Interactions API는 기본적으로 store=true로 동작하며, previous_interaction_id를 사용해 후속 호출에서 대화와 작업 맥락을 이어갈 수 있습니다. Paid Tier의 interaction 보관 기간은 55일, Free Tier는 1일입니다. 원치 않으면 store=false를 설정할 수 있지만, 이 경우 background execution과 후속 interaction 연결에 제약이 생깁니다. 에이전트 제품을 만드는 팀에게 이는 단순 옵션이 아닙니다. 개인정보, 고객 데이터, 내부 코드, 감사 로그 정책과 직접 연결됩니다.

Managed Agents 문서의 제한도 읽어야 합니다. 환경은 7일 동안 비활성 상태가 이어지면 영구 삭제됩니다. VM은 비활성 후 spin-down되고, 다음 요청에서 상태를 복원합니다. 기본 환경은 Ubuntu 기반이며 Python 3.12와 Node.js 22가 설치되어 있습니다. 최대 managed agents 수는 1,000개입니다. 가격 항목은 더 실무적입니다. 문서상 단일 interaction은 보통 100k에서 3M tokens를 소비할 수 있고, preview 기간에는 environment compute가 과금되지 않습니다. 이 말은 preview 이후 compute 비용 구조가 제품 원가에 들어올 수 있다는 뜻이기도 합니다.

가장 민감한 부분은 네트워크입니다. Google 문서는 managed agent 환경의 outbound network access가 기본적으로 unrestricted라고 밝힙니다. allowlist를 사용해 특정 도메인이나 wildcard 패턴으로 제한할 수 있지만, 기본값만 보고 내부 업무 자동화를 붙이는 것은 위험합니다. 외부 API credential을 연결할 수 있다는 점도 마찬가지입니다. 문서는 least privilege service account, short-lived token, credential rotation을 권고합니다. 에이전트가 접근 가능한 credential은 에이전트가 실제로 사용할 수 있다는 단순한 사실을 운영 설계의 중심에 둬야 합니다.

이 지점에서 Managed Agents는 두 얼굴을 가집니다. 한쪽에서는 에이전트 인프라의 반복 작업을 줄입니다. 개발자는 샌드박스를 띄우고, 파일 시스템을 유지하고, 브라우저를 붙이고, long-running task를 감시하는 코드를 덜 작성해도 됩니다. 다른 한쪽에서는 실행 계층의 세부 통제권이 줄어듭니다. 샌드박스의 이미지, 네트워크 경계, 로그 보관, 비용 모델, cold start, background task semantics가 플랫폼의 API 계약에 묶입니다. 이는 편리함의 대가로 예측 가능한 tradeoff입니다.

VentureBeat의 보조 분석은 이 점을 정확히 짚습니다. 이 매체는 Google의 접근을 "weeks of agent deployment work"를 단일 호출로 줄이는 시도라고 보면서도, execution layer control을 일부 내주는 선택이라고 해석했습니다. 또한 에이전트 orchestration이 프레임워크 계층에서 모델 제공자 플랫폼으로 흡수되는 흐름을 경쟁 구도의 핵심으로 봤습니다. 이 해석은 Google 발표문만 읽을 때 빠지기 쉬운 균형점입니다.

경쟁 구도를 보면 Google만 이 방향으로 움직이는 것이 아닙니다. Anthropic은 Claude Code, MCP, Claude Managed Agents, Microsoft 365 add-ins 같은 표면을 통해 모델을 도구와 업무 앱에 깊게 연결하고 있습니다. AWS는 Bedrock AgentCore에서 runtime, browser, code interpreter, identity, observability를 관리형 인프라로 묶는 방향을 제시했습니다. OpenAI는 Codex와 sandbox, remote control, enterprise access token 같은 흐름으로 장기 실행 코딩 작업을 운영 표면으로 끌어올리고 있습니다. GitHub Copilot coding agent는 GitHub Actions 기반의 비동기 작업자 모델을 이미 밀고 있습니다.

Google의 차별점은 Antigravity를 중심에 둔 수직 결합입니다. I/O developer highlights에 따르면 Antigravity 2.0은 standalone desktop app, CLI, SDK, Enterprise Agent Platform 연결을 포함합니다. Managed Agents는 이 Antigravity harness를 Gemini API와 AI Studio 안에서 사용할 수 있게 합니다. 다시 말해 Google은 IDE, CLI, API, 샌드박스, 모델을 따로 팔기보다 한 실행 경험으로 묶으려 합니다. Gemini 3.5 Flash가 "빠른 frontier model"이라는 메시지는 이 묶음을 지탱하는 성능 주장입니다.

개발자에게 실질적인 질문은 "이걸 써야 하나"보다 "어떤 계층을 직접 운영할 것인가"입니다. 내부 도구나 빠른 prototyping에서는 Managed Agents 같은 서비스가 강력합니다. 제품 팀이 데이터 분석 에이전트, 리서치 에이전트, 코드 변환 에이전트, QA 자동화 에이전트를 빠르게 만들고 검증할 수 있습니다. API가 state와 execution steps를 제공하면 사용자에게 중간 진행 상황을 보여주기도 쉬워집니다. 이미 Google AI Studio에서 custom template로 시작할 수 있다는 점도 진입 장벽을 낮춥니다.

반대로 규제가 강한 환경, 고객 데이터가 민감한 SaaS, 내부 소스코드와 credential을 다루는 제품에서는 체크리스트가 길어집니다. outbound allowlist를 기본값에서 바꿨는지, interaction 저장을 끌 수 있는지, background task와 state 재개가 어떤 데이터 보관 정책을 만드는지, agent가 사용하는 credential의 scope가 어디까지인지, 실패한 코드 실행 결과가 로그에 어떻게 남는지 확인해야 합니다. 특히 store=false와 previous_interaction_id, background=true 사이의 제약은 아키텍처 선택을 바꿀 수 있습니다.

비용도 단순하지 않습니다. "단일 호출"이라는 표현은 developer experience를 설명할 때 유용하지만, 실행 내부에서는 여러 reasoning loop와 도구 호출이 이어질 수 있습니다. Google 문서가 100k~3M tokens라는 범위를 제시한 이유가 여기에 있습니다. 일반적인 chat completion 비용 감각으로 agent task를 추정하면 빗나갈 수 있습니다. 에이전트가 웹을 탐색하고, 파일을 만들고, 코드를 실행하고, 실패를 수정하며 다시 실행하면 한 번의 사용자 요청이 긴 작업 그래프로 커집니다.

흥미로운 것은 Google이 이 기능을 "custom agent"와 "coding agent setup" 문맥에 같이 놓았다는 점입니다. Gemini Docs는 coding agent가 최신 문서를 직접 참고하도록 MCP와 skill 설치를 안내합니다. 그리고 Managed Agents는 AGENTS.md, SKILL.md 파일로 에이전트 동작을 정의할 수 있게 합니다. 개발 생태계에서 사람이 읽는 README, 자동화가 읽는 workflow, 에이전트가 읽는 instruction file의 경계가 점점 흐려지고 있습니다. 저장소 안의 문서가 곧 원격 실행 환경의 행동 계약이 되는 셈입니다.

이 변화는 한국 개발팀에도 꽤 직접적입니다. 지금까지 AI agent를 제품에 넣으려면 모델 API 선택 다음에 worker queue, browser runtime, filesystem sandbox, secrets handling, log viewer, retry, cancellation을 따로 설계해야 했습니다. Managed Agents류 서비스가 성숙하면 초기 제품은 이 대부분을 API로 빌릴 수 있습니다. 대신 나중에 자체 런타임으로 이전하려면 agent instruction, tool schema, 상태 형식, execution trace, 비용 모델을 다시 분리해야 합니다. 빠르게 시작할수록 exit plan을 늦게 생각하기 쉽습니다.

따라서 이번 발표의 핵심은 "Google도 에이전트를 냈다"가 아닙니다. Google은 Gemini API의 구매 단위를 모델 token에서 실행 가능한 작업 환경으로 확장했습니다. 이는 AI 인프라 시장에서 꽤 큰 선 긋기입니다. 모델 제공자가 runtime까지 흡수하면 개발자는 더 빨리 만들 수 있지만, 벤더 간 전환 비용도 runtime semantics까지 넓어집니다. 어느 쪽이 더 중요한지는 팀의 단계와 데이터 민감도, 운영 역량에 따라 달라집니다.

지금 시점의 실용적 결론은 보수적입니다. Managed Agents는 prototyping, 내부 자동화, 비민감 데이터 분석, 도구형 agent의 빠른 검증에 먼저 맞습니다. production workload에서는 Public Preview라는 상태, Interactions API의 Beta 성격, 문서상 breaking changes 가능성, 기본 network behavior, interaction retention, 비용 상한을 먼저 확인해야 합니다. Google 문서도 민감한 workflow에서는 agent action과 output을 검토하라고 말합니다. 에이전트가 실행 환경까지 얻는 순간, 검토 대상은 답변 품질이 아니라 실제 작업 행위가 됩니다.

에이전트 시대의 API는 더 이상 "질문에 답하는 함수"가 아닙니다. 파일을 만들고, 셸을 돌리고, 브라우저를 열고, 상태를 보관하는 작은 운영체제에 가까워지고 있습니다. Gemini Managed Agents는 그 방향을 가장 노골적으로 보여준 발표 중 하나입니다. 한 번 호출하면 리눅스가 뜨는 시대에는, 개발자가 가장 먼저 물어야 할 질문도 바뀝니다. "무엇을 할 수 있나"보다 "어디까지 하게 둘 것인가"가 더 중요한 설계 문제가 됩니다.