한 번 호출로 열린 샌드박스, Gemini API의 에이전트 실행권

AI 요약

• 무슨 일: Google이 Gemini API에 Managed Agents를 preview로 공개했습니다.
  • 한 번의 Interactions API 호출로 Antigravity agent가 Google-hosted Linux sandbox에서 추론, 도구 호출, 코드 실행, 파일 관리를 수행합니다.
• 의미: 경쟁 축이 모델 API에서 agent harness와 실행 환경으로 이동합니다.
• 주의점: preview API, token 누적 비용, runtime 종속성, 관측 가능성을 함께 검토해야 합니다.
  • 공식 문서는 복잡한 workflow가 3-5M token까지 쌓이고 최대 약 $5 수준까지 갈 수 있다고 예시를 듭니다.

Google이 2026년 5월 19일 Google I/O 2026 개발자 발표에서 Gemini API Managed Agents를 공개했습니다. 발표 문장만 보면 간단합니다. 개발자는 한 번의 API 호출로 Antigravity agent를 띄우고, 이 에이전트가 Google이 호스팅하는 격리 Linux 환경에서 추론하고, 도구를 쓰고, 코드를 실행하고, 파일을 관리하고, 웹을 탐색합니다. 하지만 이 뉴스의 무게는 “Gemini가 에이전트도 합니다”보다 훨씬 큽니다.

지금 AI 개발자 도구 시장의 중심은 모델 이름에서 실행면으로 이동하고 있습니다. 작년까지 많은 팀의 질문은 어떤 모델이 더 잘 코딩하고, 어떤 모델이 더 긴 컨텍스트를 견디며, 어떤 모델이 더 싼가였습니다. 이제 질문은 바뀌었습니다. 에이전트가 장기 작업을 어디서 실행하는가. 파일 시스템과 패키지 설치는 누가 책임지는가. 세션 상태는 어디에 저장되는가. 도구 호출과 비용은 어떻게 관측되는가. Google의 Managed Agents 발표는 이 질문에 대해 “Gemini API가 agent harness와 sandbox까지 함께 제공하겠다”는 답입니다.

공식 발표는 Managed Agents를 “production-grade agent를 만들 때 필요했던 복잡한 인프라를 추상화한다”고 설명합니다. 이전에는 개발팀이 runner, sandbox, tool loop, state, retry, file mount, web access를 직접 엮어야 했습니다. 이제 Google은 Antigravity agent harness를 API로 열고, Gemini 3.5 Flash를 기반으로 한 agent runtime을 Interactions API와 Google AI Studio에서 호출하게 만들었습니다. 개발자는 제품 경험과 agent behavior에 더 집중할 수 있다는 것이 Google의 메시지입니다.

모델 API가 런타임 API로 바뀌는 순간

Gemini API의 기존 인상은 모델 호출에 가까웠습니다. 텍스트를 넣고, 이미지를 넣고, 도구 호출을 붙이고, 응답을 받습니다. 물론 function calling, code execution, search 같은 기능이 이미 있었지만, 중심 단위는 여전히 요청과 응답이었습니다. Managed Agents에서는 단위가 달라집니다. 문서의 Antigravity Agent는 “single API call”로 reasoning, code execution, file management, web browsing을 수행하는 managed agent를 얻는다고 설명합니다.

여기서 중요한 단어는 agent가 아니라 environment입니다. Google 문서에서 environment="remote"는 fresh Linux sandbox를 의미합니다. 기존 environment_id를 넘기면 같은 sandbox를 재사용하고 파일과 패키지 상태를 이어갑니다. 설정 객체를 넘기면 Git repository, Cloud Storage, inline file 같은 source를 mount하고 네트워크 규칙을 지정할 수 있습니다. 즉 API 호출은 더 이상 텍스트 생성 요청이 아니라, 작업 공간을 가진 실행 세션을 여는 행위가 됩니다.

이 변화는 개발자가 에이전트를 제품에 붙이는 방식에 영향을 줍니다. 예를 들어 “분기별 매출 데이터를 분석하고 PDF 보고서를 만들라”는 작업을 생각해 보겠습니다. 일반 모델 API라면 데이터를 보내고, 응답을 받고, 코드 실행은 별도 서비스에서 돌리고, 파일 저장은 애플리케이션이 처리해야 합니다. Managed Agents에서는 agent가 sandbox 안에서 필요한 패키지를 설치하고, 파일을 만들고, 중간 결과를 보존한 뒤, 다음 interaction에서 이어 갈 수 있습니다. 물론 이것이 모든 것을 자동으로 해결한다는 뜻은 아닙니다. 다만 제품 코드가 직접 감당하던 orchestration의 일부가 provider runtime으로 이동합니다.

Interactions API가 받쳐 주는 이유

Managed Agents는 Interactions API 위에 올라갑니다. Google 문서는 Interactions API를 새 프로젝트에 권장하는 Gemini의 새 표준이라고 설명합니다. 특히 agentic workflow, server-side state management, multi-turn conversation, typed execution steps에 최적화됐다고 말합니다. 기존 generateContent API는 계속 지원되지만, 새 agentic capability와 tools는 앞으로 Interactions API에 먼저 붙는다는 방향도 명시돼 있습니다.

이 API의 핵심은 interaction이라는 단위입니다. interaction은 한 번의 대화나 작업 턴을 나타내는 리소스이고, 내부에는 model thought, tool call, function result, final output 같은 실행 단계가 시간순으로 담깁니다. 개발자는 최종 텍스트만 읽을 수도 있지만, 복잡한 agent UI나 디버깅 화면을 만들려면 steps timeline을 직접 순회할 수 있습니다. 에이전트 제품을 만드는 팀에게 이는 중요합니다. 사용자가 “지금 에이전트가 무엇을 하고 있는가”를 볼 수 있어야 하고, 장애가 났을 때 어느 tool call에서 멈췄는지 추적할 수 있어야 하기 때문입니다.

서버 측 상태 관리도 달라집니다. previous_interaction_id를 넘기면 Gemini 쪽 서버가 이전 대화 기록을 이어 줍니다. 기본값으로 interaction은 저장되며, paid tier는 55일, free tier는 1일 보존된다고 문서화돼 있습니다. 원치 않으면 store=false를 설정할 수 있지만, 그 경우 background=true나 후속 interaction 연결과 맞물리는 기능 제약이 생깁니다. 즉 편의와 데이터 보존 정책이 한 묶음으로 움직입니다.

실무적으로는 이 지점이 아키텍처 논의의 시작입니다. 이전에는 애플리케이션 서버가 대화 상태와 로그를 보존하고, provider는 모델 출력을 돌려주는 역할에 가까웠습니다. Interactions API에서는 provider가 agent execution timeline과 일부 상태를 보관합니다. 덕분에 구현은 쉬워지지만, 데이터 retention, deletion, audit export, 사용자별 권한 분리, incident investigation을 어떻게 맞출지 검토해야 합니다. agentic workflow는 일반 chat completion보다 훨씬 많은 중간 상태를 남깁니다.

AGENTS.md와 SKILL.md가 API 설정이 됐습니다

이번 발표에서 devlery 독자에게 특히 눈에 들어오는 대목은 AGENTS.md와 SKILL.md입니다. Google은 Managed Agents에서 Antigravity agent를 custom instruction, skills, data로 확장할 수 있다고 설명합니다. Building Managed Agents 문서는 시스템 지시문, 도구 override, file/skill mount를 세 가지 확장 방법으로 제시합니다. AGENTS.md는 장기 지침을 담고, .agents/skills/<skill-name>/SKILL.md는 에이전트가 자동 발견하는 skill 파일이 됩니다.

이는 우연한 이름 선택이 아닙니다. 최근 코딩 에이전트 생태계는 저장소 안의 지침 파일을 중심으로 표준 아닌 표준을 만들고 있습니다. Codex, Claude Code, Cursor, Devin, Jules 계열 도구에서 프로젝트별 agent instruction은 점점 더 중요한 개발 자산이 됐습니다. Google이 이 파일 구조를 Gemini API의 managed runtime에 넣었다는 것은, agent configuration을 코드 저장소의 일부로 취급하겠다는 뜻입니다.

예를 들어 데이터 분석 에이전트를 만든다면 AGENTS.md에 “항상 시각화와 요약 표를 포함하라”고 쓰고, skills/slide-maker/SKILL.md에 HTML slide deck 생성 절차를 넣을 수 있습니다. API 호출 시 이 파일을 inline으로 mount하거나 repository source로 sandbox에 붙입니다. 빠른 실험에서는 registration 없이 interaction마다 설정을 넘기고, 준비가 되면 agents.create로 managed agent를 저장해 ID로 호출합니다. 에이전트 제품을 운영하는 팀이라면 이 구조가 configuration-as-code와 비슷하게 보일 것입니다.

하지만 configuration-as-code는 곧 review-as-code이기도 합니다. AGENTS.md가 단순 프롬프트가 아니라 실제 agent behavior를 바꾼다면, 변경 리뷰와 버전 관리가 필요합니다. 어떤 skill이 어떤 tool을 쓰는지, 어떤 data source를 mount하는지, 어떤 network rule을 요구하는지 봐야 합니다. 에이전트가 만든 결과물을 사람이 검토하는 것도 중요하지만, 에이전트가 어떤 지침으로 움직이는지 자체가 이제 운영 대상입니다.

비용은 단일 응답 가격으로 읽으면 안 됩니다

Managed Agents에서 가장 쉽게 오해할 부분은 가격입니다. 표준 chat request는 대체로 입력 token과 출력 token의 함수로 계산됩니다. agent request도 결국 token과 tool 사용량을 기반으로 하겠지만, 동작 방식이 다릅니다. Google의 Antigravity Agent 문서는 이 차이를 분명히 씁니다. 한 번의 Antigravity interaction은 단일 출력이 아니라 autonomous loop입니다. reasoning, tool execution, code running, file management가 반복되면서 token이 누적될 수 있습니다.

공식 문서의 예시는 꽤 현실적입니다. research와 information synthesis는 input 100k-500k, output 10k-40k, typical cost $0.30-$1.00 수준으로 제시됩니다. data processing과 analysis는 input 300k-3M, output 30k-150k, $0.70-$3.25입니다. 더 복잡한 agentic workflow는 3-5M token까지 누적되고 최대 약 $5까지 갈 수 있다고 경고합니다. preview 기간에는 environment compute, 즉 CPU와 memory와 sandbox execution 비용을 청구하지 않는다고 하지만, 이것이 장기적으로 그대로 유지된다는 뜻은 아닙니다.

이 수치는 공포 마케팅으로 읽을 필요는 없습니다. 오히려 중요한 것은 비용 단위가 바뀐다는 점입니다. 에이전트가 스스로 웹을 탐색하고, 파일을 열고, 코드를 돌리고, 오류를 고치며, 여러 loop를 돈다면 “요청 1회”는 더 이상 같은 요청 1회가 아닙니다. 사용자는 버튼을 한 번 눌렀지만, 내부에서는 수십 번의 reasoning step과 tool call이 일어날 수 있습니다. 제품 팀은 usage meter를 모델 응답 단위가 아니라 task run 단위로 다시 설계해야 합니다.

비용 제어도 UI 문제가 됩니다. 문서는 SSE streaming으로 agent run을 모니터링하고, agent가 stuck 상태로 보이거나 예상보다 오래 실행될 때 cancel할 수 있다고 안내합니다. 이는 단순한 개발자 편의 기능이 아닙니다. 실제 제품에서는 사용자가 agent run의 진행 상황, 비용 추정, 취소 버튼, 중간 산출물을 볼 수 있어야 합니다. 그렇지 않으면 “AI가 알아서 처리 중”이라는 화면 뒤에서 비용과 시간이 계속 쌓입니다.

Preview라는 단어가 가진 무게

Google 발표는 크지만, 현재 상태를 과대평가하면 안 됩니다. Interactions API는 beta/preview이고, features와 schemas가 breaking change를 겪을 수 있다고 문서화돼 있습니다. Antigravity agent도 preview입니다. 문서는 production workload에는 여전히 표준 generateContent API가 안정 경로라고 말합니다. 이는 Managed Agents가 흥미로운 방향이지만, 핵심 업무 자동화에 바로 깊게 묶기 전에는 변경 가능성을 감안해야 한다는 뜻입니다.

제한도 많습니다. Antigravity agent는 temperature, top_p, top_k, stop_sequences, max_output_tokens 같은 generation config를 지원하지 않습니다. structured output도 지원하지 않습니다. 현재 unavailable tools에는 file_search, computer_use, google_maps, function_calling, mcp가 포함됩니다. background 실행도 지원하지 않고 store=True가 필요합니다. multimodal input은 text와 image 중심이며 audio, video, document input은 아직 지원되지 않습니다.

이 제한은 Managed Agents의 가치를 없애지 않습니다. 다만 용도를 선명하게 만듭니다. 지금의 Antigravity agent는 “복잡한 장기 업무를 production SLA로 돌리는 안정 플랫폼”이라기보다, Google이 agent runtime과 API surface를 어디로 가져가려는지 보여 주는 preview입니다. 내부 도구, 프로토타입, 연구 자동화, 파일 기반 분석, 개발자 workflow 실험에는 의미가 큽니다. 반대로 금융 거래, 고객 데이터 변경, 보안 민감 업무처럼 deterministic control과 audit가 먼저인 영역에서는 더 신중해야 합니다.

Claude Managed Agents와 다른 방향

최근 Anthropic도 Claude Managed Agents를 빠르게 밀고 있습니다. 특히 self-hosted sandboxes와 MCP tunnels 업데이트는 기업이 실행 환경과 사설 도구 연결을 더 직접 통제하게 만드는 방향이었습니다. agent loop는 Anthropic에 남기되, filesystem과 shell 실행은 고객 인프라에 둘 수 있는 모델입니다. 반면 Google의 이번 Managed Agents 발표는 Google-hosted Antigravity harness와 Linux sandbox를 API로 빠르게 호출하는 경험에 무게가 있습니다.

두 접근은 서로 우열이 아니라 trade-off입니다. Google식 one-call managed sandbox는 진입 장벽을 낮춥니다. 개발자는 runner를 직접 만들기보다 API 호출로 agent workspace를 얻습니다. Antigravity IDE, CLI, SDK, AI Studio, Gemini Enterprise Agent Platform과 같은 Google 생태계 표면도 함께 따라옵니다. 반대로 실행권이 Google runtime에 모이면, 네트워크 경계, 데이터 보존, 로그 export, sandbox image 제어, provider 종속성 질문이 커집니다.

Anthropic식 self-hosted 방향은 기업 보안팀이 익숙한 경계에 가깝습니다. 다만 직접 운영해야 할 runner, tunnel, credential, trace 상관관계가 늘어납니다. Google식 managed direction은 빠르게 시작하기 좋지만, provider runtime 안에서 관측과 통제를 어디까지 받을 수 있는지가 중요합니다. 결국 에이전트 플랫폼 선택은 “어느 모델이 더 똑똑한가”가 아니라 “agent loop, execution, storage, network, audit의 어느 층을 누구에게 맡길 것인가”로 바뀝니다.

Google 생태계의 큰 그림

Managed Agents는 단독 발표가 아닙니다. 같은 I/O 개발자 하이라이트에서 Google은 Gemini 3.5 Flash, Antigravity 2.0 desktop app, Antigravity CLI, Antigravity SDK, Google AI Studio mobile, Workspace integration, Android app generation, Firebase와의 연결을 함께 제시했습니다. 이 묶음은 Google이 AI 개발자 경험을 여러 화면에 흩뿌리는 것이 아니라, 하나의 agent-first development platform으로 묶으려 한다는 신호입니다.

Antigravity 2.0은 여러 agent를 병렬로 orchestration하고, scheduled task와 ecosystem integration을 제공하는 desktop surface로 소개됐습니다. CLI는 터미널 사용자를 위한 경량 표면입니다. SDK는 같은 harness에 programmatic access를 제공합니다. Managed Agents는 그 harness를 Gemini API로 호출하는 길입니다. AI Studio는 브라우저에서 prototype과 custom template을 시작하는 곳이고, Gemini Enterprise Agent Platform은 Google Cloud 고객을 위한 private preview 경로입니다.

이 그림에서 Gemini 3.5 Flash는 단순 모델 출시가 아닙니다. Google은 3.5 Flash가 Gemini 3.1 Pro를 대부분 benchmark에서 앞서고 frontier model 대비 네 배 빠르다고 주장하며, agentic workflow의 고속 엔진으로 배치했습니다. 에이전트 runtime은 많은 loop를 돌기 때문에 모델 latency와 cost가 훨씬 중요해집니다. 빠른 모델, managed sandbox, server-side state, IDE/CLI/Studio 표면이 한 세트가 될 때 Google의 전략이 보입니다.

개발팀이 당장 확인할 질문

첫째, Managed Agents를 붙일 작업이 Google-hosted sandbox에 적합한지 봐야 합니다. 공개 데이터 분석, 문서 생성, 연구 요약, 프로토타입 코드 실행처럼 외부 runtime에 두기 쉬운 작업은 좋은 후보입니다. 반면 private repository, 고객 데이터, 내부 API, secret이 깊게 얽힌 업무는 데이터 이동과 credential boundary를 먼저 그려야 합니다.

둘째, interaction과 environment의 수명 주기를 제품 요구사항으로 잡아야 합니다. paid tier의 55일 retention, store=false와 후속 interaction 제약, environment 재사용 시 파일과 패키지 상태 보존, deletion API 사용 가능성은 모두 사용자 데이터 정책에 영향을 줍니다. “에이전트가 작업을 이어 간다”는 경험은 매력적이지만, 이어 가기 위해 무엇을 어디에 저장하는지 설명할 수 있어야 합니다.

셋째, 비용과 취소 UX를 처음부터 넣어야 합니다. agent run은 사용자가 예상한 것보다 오래 돌 수 있고, tool call과 token이 빠르게 늘 수 있습니다. SSE streaming, run status, cancel button, budget threshold, per-run receipt는 선택 기능이 아니라 신뢰 기능입니다. 특히 내부 자동화나 고객-facing product에 넣는다면, 에이전트가 지금 어떤 근거로 어떤 작업을 수행 중인지 보여줘야 합니다.

넷째, AGENTS.md와 skill 파일을 코드 리뷰 대상으로 다뤄야 합니다. prompt instruction이 곧 runtime behavior가 됩니다. 누가 skill을 추가했는지, 어떤 source를 mount하는지, 어떤 tool을 허용하는지, 민감한 데이터를 읽을 수 있는지, output artifact를 어디에 저장하는지 확인해야 합니다. 에이전트 시대에는 instruction file 변경이 application logic 변경과 비슷한 영향을 가질 수 있습니다.

결론: 편의의 뉴스이자 실행권의 뉴스입니다

Gemini API Managed Agents는 개발자에게 분명한 편의를 줍니다. runner를 직접 만들지 않고도 Antigravity agent를 호출하고, Linux sandbox에서 파일과 코드를 다루며, AGENTS.md와 SKILL.md로 behavior를 구성할 수 있습니다. 프로토타입과 내부 자동화의 속도는 빨라질 수 있습니다. 특히 Google AI Studio, Antigravity CLI/SDK, Android와 Workspace 통합까지 생각하면 Google은 agent-first development workflow를 제품군 전체에 깔고 있습니다.

하지만 이 발표를 “AI agent를 한 번에 배포할 수 있게 됐다”로만 읽으면 핵심을 놓칩니다. 더 큰 뉴스는 실행권입니다. 에이전트의 loop, state, sandbox, file system, tool call timeline 중 어디가 provider runtime에 있고, 어디가 애플리케이션과 기업 경계에 남는지의 문제입니다. Google은 이 중 많은 부분을 Gemini API 쪽으로 끌어와 편의를 제공합니다. 그만큼 비용, 관측, 데이터 보존, vendor lock-in의 질문도 함께 커집니다.

AI 개발자 도구의 다음 전장은 더 좋은 자동완성이 아닙니다. 장기 실행 agent가 안전하게 실패하고, 중간 상태를 설명하고, 비용을 멈출 수 있고, 저장소의 지침 파일로 관리되며, 필요한 실행 환경을 즉시 얻는 플랫폼입니다. Gemini Managed Agents는 그 전장이 모델 API 밖에서 벌어지고 있음을 보여 주는 발표입니다. 이제 개발팀이 볼 것은 “한 번 호출로 된다”는 데모가 아니라, 그 한 번의 호출 뒤에서 누가 에이전트의 손과 작업장을 소유하는가입니다.

출처: Google 공식 발표, Google I/O 2026 개발자 하이라이트, Interactions API 문서, Antigravity Agent 문서, Building Managed Agents 문서, Managed Agents environment 문서.