Gemini 3.5 Flash와 Antigravity 2.0의 관리형 에이전트 운영

Google I/O 2026 이후 Gemini 3.5 Flash가 정식 운영(GA)에 들어서면서 에이전트 플랫폼의 경쟁 지점도 달라졌다. 이제 단일 모델의 추론 품질뿐 아니라 여러 에이전트를 얼마나 저렴하게 배치하고, 상태를 유지하며, 사람의 개입 없이 반복 실행할 수 있는지가 플랫폼 선택을 좌우한다.

Gemini 3.5 Flash와 Managed Agents API, Antigravity 2.0은 이 변화를 한 묶음으로 보여준다. Flash가 반복 작업을 처리하는 경량 워크호스를 맡고, 관리형 API가 런타임을 추상화하며, 데스크톱 클라이언트가 병렬 실행과 백그라운드 자동화를 담당하는 구조다.

경량 모델을 운영 자원으로 쓰는 방식

Gemini 3.5 Flash는 Pro보다 토큰당 비용이 수 분의 1 수준이면서 도구 호출(tool calling), 함수 실행, 구조화 출력에 필요한 안정성을 확보했다. 복잡한 판단을 모두 Flash에 맡긴다는 뜻은 아니다. 정형화된 반복 처리는 Flash가 담당하고, 더 깊은 추론이 필요한 분기만 Pro로 넘기는 계층형 운용이 핵심이다.

이 접근은 모델 한 개의 성능을 극대화하기보다 작업 특성에 따라 처리 자원을 나누는 데 초점을 둔다. 코드 리뷰, 로그 분석, 문서 분류처럼 대량으로 반복되는 작업에는 Flash를 배치하고, 아키텍처 설계나 복잡한 디버깅에는 Pro를 선택적으로 투입한다.

Antigravity 2.0까지 결합하면 운영 범위가 더 넓어진다. Managed Agents API가 인프라와 상태, 도구 연결을 관리하고, Antigravity는 여러 서브에이전트의 병렬 실행과 스케줄 기반 작업을 로컬 개발 환경에서 다룬다.

에이전트 런타임을 API 뒤로 숨긴다

직접 에이전트를 구현하려면 에이전트 루프, 도구 라우팅, 세션 상태와 메모리 저장소를 각각 구성해야 한다. Managed Agents API는 이 책임을 단일 엔드포인트 뒤로 옮긴다. 개발자는 한 번의 API 호출로 에이전트를 생성하고 실행하며, 런타임 프로비저닝과 세션 복원은 관리형 계층이 맡는다.

⤢✕

세션의 대화 컨텍스트와 도구 실행 이력, 메모리는 구글 측 관리형 스토어에 저장된다. 클라이언트가 에이전트 ID를 보유하고 있으면 다른 위치에서도 이전 세션을 이어갈 수 있다. 상태 저장소를 애플리케이션마다 별도로 설계해야 했던 부담을 플랫폼으로 넘기는 셈이다.

모델 라우팅도 런타임에 포함된다. 단순한 도구 호출은 Flash로 처리하고, 복잡한 추론이 필요한 작업은 Pro로 에스컬레이션하는 하이브리드 구성이 가능하다. 비용과 추론 깊이를 한 모델로 타협하는 대신 작업 단위로 나눈다.

복합 요청에서는 메인 에이전트가 작업을 분해한 뒤 서브에이전트에 병렬 배분한다. 각 결과를 모아 하나의 응답으로 만드는 fan-out/fan-in 패턴이 런타임 수준에 들어가 있다.

⤢✕

Antigravity가 데스크톱으로 가져온 운영 모델

Antigravity 2.0은 Managed Agents API를 사용하는 데스크톱 IDE이자 클라이언트다. 이전 세대와 비교해 가장 두드러진 변화는 서브에이전트를 순차적으로 돌리는 대신 병렬로 실행하고, 대화형 세션이 끝난 뒤에도 스케줄에 따라 작업을 수행할 수 있다는 점이다.

기능	Antigravity 1.x	Antigravity 2.0	비고
서브에이전트	순차 실행	병렬 실행	fan-out 오케스트레이션
백그라운드 작업	미지원	스케줄 기반 지원	cron 트리거
모델 라우팅	Pro 고정	Flash 기본 + Pro 에스컬레이션	비용 최적화
상태 관리	로컬	관리형 원격 + 로컬 캐시	세션 재개 가능
MCP 커넥터	수동 설정	자동 디스커버리	도구 연결 자동화
동시 에이전트 수	1개	다중 (워크스페이스별)	워크호스 패턴

스케줄 백그라운드 에이전트는 cron 형태의 트리거로 비대화형(non-interactive) 작업을 실행한다. 이를테면 매일 오전 6시에 의존성 취약점을 스캔하고 PR을 생성하는 흐름을 사람의 입력 없이 돌릴 수 있다.

여러 서브에이전트가 독립 작업을 동시에 처리하면 개발자의 역할도 실행자에서 감독자(supervisor)로 이동한다. 개발자 1명이 다수의 에이전트를 관찰하면서 결과 검토와 승인에 필요한 휴먼-인-더-루프(human-in-the-loop) 게이트를 유지하는 방식이다.

비용과 처리량을 함께 조정하는 배포 패턴

Flash 기반 에이전트는 반복량이 많고 작업 형식이 비교적 분명할 때 적합하다. 응답 지연이 중요하고 정형화된 작업이라면 Flash를 우선하며, 비정형 문제나 고난도 추론에는 Pro를 배치한다. 판단 기준은 추론 깊이, 허용할 수 있는 응답 지연, 비용 민감도다.

운영 단계에서는 작업 난이도에 따라 Flash와 Pro를 동적으로 선택하는 티어드 모델 라우팅으로 평균 토큰 비용을 낮춘다. 병렬 서브에이전트는 필요한 동안만 짧게 스핀업한 뒤 소멸시키는 풀링 방식으로 유휴 비용을 제거할 수 있다.

백그라운드 작업은 저트래픽 시간대에 배치해 처리량을 분산한다. 기존 관리형 세션을 다시 사용하면 같은 컨텍스트를 반복해서 전달하며 토큰을 소비하는 문제도 줄일 수 있다.

이 패턴은 CI 파이프라인의 자동 코드 리뷰 봇, 야간 배치 데이터 정제 에이전트, 여러 저장소를 동시에 리팩터링하는 서브에이전트 군집에 적용할 수 있다.

플랫폼마다 다른 선택 기준

2026년의 주요 경쟁 구도는 Google Antigravity, Anthropic Claude Code, OpenAI Codex CLI를 중심으로 형성됐다. 같은 에이전트 플랫폼이라도 강조하는 지점은 서로 다르다.

⤢✕

경량 모델과 오케스트레이션 방식을 나란히 놓으면 플랫폼별 위치가 더 선명해진다.

항목	Gemini 3.5 Flash	Claude Haiku 4.5	GPT-4o mini
포지셔닝	경량 워크호스	경량 고속 추론	경량 범용
강점	단일 호출 에이전트·병렬성	안전성·지시 준수	생태계·범용성
에이전트 플랫폼	Antigravity 2.0	Claude Code	Codex CLI
오케스트레이션	관리형 fan-out 내장	MCP 기반	함수 호출 기반
비용 효율	매우 높음	높음	높음
백그라운드 스케줄	네이티브 지원	외부 도구 필요	외부 도구 필요

Google은 관리형 인프라로 진입 장벽을 낮추고 Flash를 통해 비용 우위를 확보하는 전략이다. Anthropic은 추론 품질과 안전성, OpenAI는 폭넓은 생태계 통합에 무게를 둔다. 비용과 병렬성이 우선이라면 Google, 추론 품질을 중시하면 Anthropic, 기존 생태계와의 통합 편의성이 필요하면 OpenAI가 각각 선택지가 된다.

자동화가 커질수록 통제 지점도 필요하다

Managed Agents API의 구조는 관리형 서비스를 통한 관심사 분리와 플랫폼 추상화 사례로 볼 수 있다. 에이전트 런타임을 PaaS 형태로 감추고, 클라이언트가 실행 요청과 결과 소비에 집중하도록 경계를 나눈다. 동시에 fan-out/fan-in과 태스크 분배 같은 분산 시스템·병렬 처리 원리가 서브에이전트 오케스트레이션의 기반으로 쓰인다.

자동화 범위가 넓어지면 실행 편의성만으로는 충분하지 않다. 백그라운드에서 동작하는 자율 에이전트에는 감사(audit), 책임 추적성(accountability), 변경 관리 통제가 필요하다. 결과를 외부 시스템에 반영하기 전에 사람이 검토하고 승인하도록 휴먼-인-더-루프 게이트를 배치하는 이유다.

MCP 커넥터 자동 디스커버리와 멀티 에이전트 협업은 이기종 시스템을 연결하는 방식에도 변화를 준다. 다만 연결 자동화와 실행 권한 확대가 함께 진행되므로, 도구 접근 범위와 승인 경계를 오케스트레이션 설계에 포함해야 한다.

Gemini 3.5 Flash와 Antigravity 2.0이 보여주는 방향은 에이전트를 고가의 특수 도구가 아니라 저비용으로 대량 운영하는 자원으로 다루는 것이다. 이후의 경쟁력은 어느 모델이 더 똑똑한지만으로 결정되지 않는다. 에이전트를 얼마나 저렴하고 안정적으로 배치하고, 상태를 이어가며, 병렬 작업과 통제 절차를 함께 운용할 수 있는지가 플랫폼의 차이를 만든다.