요약: Google I/O 2026 개발자 발표에서 가장 실무적인 변화는 Gemini 3.5 Flash보다 Managed Agents일 수 있다. Google은 Gemini API에서 단일 API 호출로 도구 사용과 코드 실행이 가능한 샌드박스 에이전트를 띄우는 흐름을 공개했다. 모델 성능 경쟁보다 중요한 변화는 “에이전트 인프라를 누가 대신 운영해주느냐”로 넘어가고 있다는 점이다.
검색 의도: Gemini API Managed Agents, Google I/O 2026 개발자 발표, Gemini 3.5 Flash, 에이전트 API
Google은 I/O 2026에서 Gemini 3.5 Flash, Antigravity 2.0, Antigravity CLI, SDK, Gemini API의 Managed Agents를 함께 발표했다. 발표 문구만 보면 모델 속도와 성능이 먼저 눈에 들어온다. Gemini 3.5 Flash가 frontier급 지능을 빠르게 제공한다는 메시지도 중요하다. 하지만 개발자가 실제로 부딪히는 문제는 모델 호출 자체보다 그 주변 인프라다.
운영 가능한 에이전트를 만들려면 모델 외에도 많은 것이 필요하다. 도구 호출 규칙, 파일 시스템, 실행 샌드박스, 상태 저장, 권한 관리, 로그, 재시도, 비용 제어, 실패 복구가 있어야 한다. 데모에서는 함수 호출 몇 개로 충분해 보이지만, 실제 서비스에서는 이 부분이 대부분의 시간을 먹는다.
Managed Agents는 이 병목을 줄이겠다는 방향이다. Google 발표에 따르면 Gemini API에서 단일 API 호출로 reasoning, tool use, code execution을 수행하는 에이전트를 띄울 수 있고, 격리된 Linux 환경과 persistent state를 제공하는 방향이다. 이 말은 곧 “에이전트 런타임”이 클라우드 API 상품으로 들어오고 있다는 뜻이다.
기존 tool calling은 모델이 어떤 함수를 호출해야 할지 결정하고, 실제 실행은 개발자 서버가 담당하는 방식이 일반적이었다. 이 방식은 통제력이 크다. 대신 개발자가 tool router, permission layer, 실행 환경, 결과 정규화, timeout, audit log를 직접 만들어야 한다.
Managed Agents는 이 중 일부를 플랫폼이 맡는다. 에이전트가 사용할 수 있는 환경을 만들고, 코드를 실행하고, 상태를 이어가고, 후속 호출에서 컨텍스트를 유지한다. 개발자는 개별 함수 호출보다 “작업을 맡기는 단위”로 설계를 할 수 있다.
차이를 간단히 정리하면 이렇다.
이 차이 때문에 Managed Agents는 단순 Q&A보다 개발 보조, 데이터 정리, 리포트 생성, 테스트 자동화, 문서 변환 같은 작업에 더 잘 맞는다.
첫 번째는 AI 기능을 빠르게 검증해야 하는 작은 제품팀이다. 자체 agent runtime을 만들 여력이 없지만, 사용자별 작업 공간과 도구 실행이 필요한 경우가 있다. 예를 들어 고객이 업로드한 CSV를 분석해 정리하고, 오류를 찾고, 후속 질문에 답하는 기능이 그렇다. 단순 chat completion으로는 상태 관리가 번거롭다.
두 번째는 내부 운영 자동화 팀이다. 반복 리포트 생성, 로그 분석, QA 보조, 문서 업데이트처럼 외부 사용자에게 바로 노출되지 않는 작업은 Managed Agents로 실험하기 좋다. 실패하더라도 영향 범위가 제한되고, 사람이 검토할 수 있다.
세 번째는 개발자 도구를 만드는 팀이다. 샌드박스 코드 실행과 persistent environment가 제공되면 “사용자의 repo 일부를 읽고 테스트를 제안하는 기능” 같은 것을 더 빠르게 만들 수 있다. 물론 이 경우 보안 설계가 핵심이다.
반대로 결제, 의료, 법률, 금융 의사결정처럼 오류 비용이 큰 영역은 바로 자동화하지 않는 편이 낫다. Managed Agents가 편해질수록 자동화 유혹이 커지지만, 검증 체계 없이 붙이면 위험도 같이 커진다.
첫째, 에이전트의 작업 경계를 정해야 한다. “무엇이든 해줘”는 운영할 수 없다. 좋은 작업 정의는 입력, 허용 도구, 산출물 형식, 실패 시 행동이 명확하다. 예를 들어 “CSV를 읽고 결측치와 이상치를 탐지한 뒤 Markdown 리포트로 요약”은 괜찮다. “데이터를 분석해서 인사이트를 줘”는 너무 넓다.
둘째, 상태 유지 범위를 정해야 한다. Persistent environment는 편하지만, 오래 남는 상태는 버그와 보안 리스크를 만든다. 사용자별로 격리할지, 작업별로 새로 만들지, 몇 시간 뒤 폐기할지, 파일을 어디까지 남길지 정책이 필요하다.
셋째, 도구 권한을 최소화해야 한다. 에이전트가 모든 API를 호출할 수 있게 만들면 편하지만, 디버깅이 어렵고 사고 범위가 커진다. 읽기 전용 도구, 제한된 쓰기 도구, 승인 필요한 도구를 분리해야 한다.
넷째, 검증 가능한 산출물을 요구해야 한다. 에이전트가 실행한 코드, 사용한 입력, 생성한 파일, 실패한 단계, 재시도 횟수, 최종 요약이 기록되어야 한다. 그렇지 않으면 나중에 “왜 이런 결과가 나왔는지” 설명할 수 없다.
Managed Agents는 단순 토큰 과금만으로 계산하면 안 된다. 에이전트는 생각하고, 도구를 부르고, 코드를 실행하고, 다시 생각한다. 한 번의 사용자 요청이 여러 번의 모델 호출과 실행 비용으로 이어질 수 있다. Gemini 3.5 Flash처럼 빠르고 저렴한 모델이 중요해지는 이유도 여기에 있다.
비용을 줄이려면 세 가지가 필요하다. 첫째, 작업을 작은 단계로 나눈다. 둘째, 모델이 긴 문서를 매번 다시 읽지 않도록 캐싱이나 상태를 활용한다. 셋째, 사람이 볼 필요 없는 대량 작업은 동기 에이전트가 아니라 Batch API나 별도 worker로 넘긴다.
예를 들어 10,000개 고객 문의를 분류하는 작업은 Managed Agents보다 batch 처리에 맞다. 반면 한 고객의 복잡한 장애 로그를 읽고 원인 후보를 좁히고 추가 질문을 받는 작업은 Managed Agents에 맞다. “대화형 판단이 필요한가?”가 비용 판단의 기준이 된다.
가장 큰 위험은 사용자가 에이전트를 신뢰하는 속도가 개발팀의 검증 속도보다 빠르다는 점이다. UI가 자연스러우면 사용자는 결과를 자동으로 믿는다. 그래서 초기 버전에서는 자동 실행보다 제안형 흐름이 안전하다. “이렇게 처리했습니다”보다 “이렇게 처리할 수 있습니다. 적용할까요?”가 낫다.
두 번째 위험은 권한 상승이다. 처음에는 읽기 전용으로 시작했지만, 고객 요구 때문에 쓰기 권한, 외부 전송, 결제 API 접근이 하나씩 붙는다. 이때 권한 정책이 코드 곳곳에 흩어져 있으면 통제하기 어렵다. 작업 유형별 policy를 별도 레이어로 분리해야 한다.
세 번째 위험은 관측성 부족이다. 에이전트가 실패했을 때 모델 문제인지, 도구 설명 문제인지, 입력 데이터 문제인지, 권한 문제인지 구분되지 않으면 개선이 멈춘다. tracing, structured log, eval dataset을 초기에 넣어야 한다.
Gemini API Managed Agents의 의미는 개발자가 에이전트 인프라를 덜 만들 수 있다는 데 있다. 하지만 운영 책임까지 사라지는 것은 아니다. 오히려 작업 경계, 권한, 검증, 비용 관리가 더 중요해진다. 이 네 가지를 먼저 설계한 팀이 Managed Agents를 제품 기능으로 빠르게 가져갈 수 있다.
