Gemini API의 Managed Agents가 단순한 모델 호출 기능에서 비용과 실행 환경을 통제할 수 있는 자동화 작업자에 가까워졌다. 이번 변화의 핵심은 Gemini 3.6 Flash의 기본 모델 적용, 도구 호출 전후에 개입하는 환경 훅, 총 토큰 예산 제한, 예약 실행, 무료 등급 접근, 샌드박스 관리 API다.
다만 기능이 늘었다고 바로 기존 자동화 시스템을 교체할 이유가 생기는 것은 아니다. 개인 사용자와 학생에게는 실험 비용과 설정 난도가, 연구자에게는 데이터 보존과 재현성이, 개발자에게는 권한 통제와 실패 복구 방식이 더 중요한 판단 기준이다. 특히 Managed Agents는 추론만 하는 모델이 아니라 코드 실행, 패키지 설치, 파일 관리, 웹 검색을 여러 단계에 걸쳐 수행할 수 있으므로 결과 품질뿐 아니라 어떤 작업을 어디까지 허용할지를 먼저 정해야 한다.
이번 업데이트에서 달라진 핵심
Gemini 3.6 Flash가 기본 모델로 적용된다
antigravity-preview-05-2026 에이전트는 이제 Gemini 3.6 Flash를 기본으로 사용한다. 기존에 이 에이전트를 호출하고 있었다면 별도의 코드 변경 없이 다음 상호작용부터 새 기본 모델이 적용된다. 이는 편리한 변화이지만, 같은 프롬프트와 도구 구성에서도 응답 내용, 실행 순서, 토큰 사용량이 달라질 가능성을 함께 뜻한다.
운영 중인 작업이라면 기본값을 그대로 받아들이기 전에 대표 작업을 다시 평가하는 편이 안전하다. 예를 들어 의존성 검사, 코드 수정, 테스트 실행처럼 여러 도구 호출이 이어지는 작업을 골라 성공률, 수정 파일 수, 실행 시간, 토큰 소비량을 이전 기록과 비교할 수 있다. 결과 안정성이 중요한 파이프라인은 모델을 명시적으로 지정해 예기치 않은 기본값 변경을 피하는 방법도 고려할 수 있다.
발표에서 제시한 선택지는 다음과 같다.
- Gemini 3.6 Flash: 추론, 코딩, 도구 사용의 균형을 목표로 하는 기본 모델
- Gemini 3.5 Flash: 일반적인 에이전트 작업에 사용할 수 있는 이전 세대 모델
- Gemini 3.5 Flash-Lite: Gemini 3.5 계열에서 지연 시간과 비용을 낮추는 선택지
모델 선택은 최신 여부만으로 결정하기 어렵다. 복잡한 코드 분석과 다단계 도구 사용이 중요하면 작업 완결성을 우선하고, 반복 횟수가 많거나 단순한 분류·정리 작업이라면 비용과 지연 시간을 함께 비교해야 한다. 실제 비용은 작업 길이와 호출 방식에 따라 달라질 수 있으므로 적용 시점의 공식 가격표와 프로젝트별 사용 한도를 확인해야 한다.
환경 훅으로 도구 호출 전후를 통제할 수 있다
환경 훅은 에이전트가 샌드박스 안에서 도구를 호출하기 전이나 호출한 뒤에 사용자 정의 검증 절차를 실행하는 기능이다. 환경에 .agents/hooks.json 설정을 두고, pre_tool_execution 또는 post_tool_execution 이벤트에 실행할 핸들러를 연결하는 방식이다. 정규식 매처를 이용하면 코드 실행과 파일 쓰기처럼 특정 도구만 고르거나 모든 도구 호출을 대상으로 삼을 수 있다.
호출 전 훅은 위험한 명령, 허용되지 않은 경로의 파일 변경, 승인되지 않은 패키지 설치를 차단하는 데 활용할 수 있다. 훅이 거부 결정을 반환하면 해당 도구 호출은 건너뛰고 거부 사유가 모델의 문맥에 전달된다. 호출 후 훅은 생성된 코드의 린트 검사, 파일 형식 확인, 결과물 감사 기록, 이미지 품질 검증 등에 적합하다. 명령 실행형 핸들러뿐 아니라 외부 엔드포인트로 요청을 보내는 HTTP형 핸들러도 지원한다.
이 기능의 가치는 에이전트의 판단을 무조건 신뢰하는 데 있지 않다. 오히려 에이전트가 무엇을 결정하더라도 지켜야 할 규칙을 별도의 검증 계층으로 만드는 데 있다. 코드 저장소라면 테스트 실패 시 쓰기를 중단하고, 연구 데이터 처리라면 허용된 디렉터리 밖으로 결과가 나가지 않게 하며, 문서 자동화라면 개인정보나 민감한 문자열 검사를 추가할 수 있다.
훅 자체도 운영 코드이므로 다음 조건을 확인해야 한다.
- 훅이 실패하거나 제한 시간을 넘겼을 때 도구 호출이 허용되는지 차단되는지
- 검사 스크립트가 읽을 수 있는 파일과 환경 변수의 범위
- HTTP 핸들러가 외부로 전송하는 데이터의 종류와 대상
- 검사 결과와 거부 사유가 로그 또는 모델 문맥에 얼마나 남는지
- 모든 도구에 훅을 적용했을 때 생기는 지연 시간과 추가 비용
총 토큰 예산으로 자율 실행의 상한을 정한다
Managed Agents는 한 번의 요청 안에서도 여러 차례 추론하고 도구를 실행할 수 있다. 복잡한 작업일수록 입력, 출력, 사고 과정에 사용되는 토큰이 커질 수 있으므로 일반적인 단일 응답 호출보다 소비량을 예측하기 어렵다. 이번 업데이트에서는 max_total_tokens를 통해 전체 소비량의 상한을 지정할 수 있다.
설정한 한도에 도달하면 작업이 무한히 계속되는 대신 실행이 안전하게 일시 정지되고 상호작용 상태가 incomplete로 반환된다. 샌드박스 환경은 보존되며, 추가 예산을 배정한 뒤 이전 상호작용 식별자를 사용해 중단 지점에서 계속할 수 있다.
이 기능은 비용 폭주를 막는 장치이지만, 예산을 설정하는 것만으로 작업 완료가 보장되지는 않는다. 한도를 너무 낮게 잡으면 파일 일부만 수정된 채 멈추거나 검증 단계 전에 종료될 수 있다. 따라서 중단 가능한 작업 단위, 완료 여부를 판정하는 조건, 재개 전 확인할 파일 상태를 함께 설계해야 한다. 처음에는 작은 저장소나 제한된 문서 집합으로 실행해 정상 완료에 필요한 토큰 범위를 관찰하고, 그 결과를 바탕으로 상한을 정하는 접근이 현실적이다.
예약 트리거로 반복 작업을 자동 실행한다
예약 트리거는 에이전트, 환경, 프롬프트, cron 일정을 지속적인 리소스로 묶어 수동 호출 없이 실행하는 기능이다. 각 실행은 같은 샌드박스를 다시 사용하므로 이전 실행에서 만든 파일이 다음 실행에도 남을 수 있다.
예를 들어 정기적인 의존성 점검, 반복 보고서 생성, 저장소 상태 검사처럼 일정이 명확한 작업에 적용할 수 있다. 그러나 같은 환경을 계속 사용하는 구조에서는 오래된 파일과 새로운 결과가 섞이거나, 이전 실패 상태가 다음 실행에 영향을 줄 수 있다. 예약 작업을 만들기 전에는 입력 갱신 방식, 산출물 이름 규칙, 중복 실행 처리, 실패 알림, 오래된 파일 정리 조건을 정해야 한다.
또한 자동 실행되는 프롬프트에 광범위한 파일 쓰기나 외부 통신 권한을 주면 사람이 지켜보지 않는 시간에도 변경이 발생할 수 있다. 처음에는 읽기 중심 작업으로 시작하고, 쓰기가 필요한 경우 훅을 통해 대상 경로와 명령을 제한하는 구성이 적절하다.
무료 등급과 환경 관리 API가 추가된다
Managed Agents는 활성 결제가 연결되지 않은 무료 등급 프로젝트에서도 API 키를 이용해 실험할 수 있게 됐다. 학생이나 개인 개발자가 에이전트 작업 흐름을 검증하기에는 접근 장벽이 낮아진 셈이다. 다만 무료 등급의 구체적인 호출량, 모델별 제한, 지역과 계정 조건은 변경될 수 있으므로 실제 사용 전 공식 콘솔과 문서에서 현재 적용되는 한도를 확인해야 한다.
Environments API를 이용하면 코드에서 샌드박스 세션을 조회하고 세부 정보를 확인하거나 삭제할 수 있다. 연결이 끊어진 뒤 환경 식별자를 다시 찾거나, 파이프라인 종료 후 샌드박스를 명시적으로 정리할 때 유용하다. 발표에서는 자동 만료 기간으로 7일을 언급하지만, 민감한 파일을 다루는 작업은 자동 만료만 기다리지 말고 종료 시점에 삭제 절차를 실행하는 편이 안전하다.
사용자 유형별로 봐야 할 기준
| 사용자 | 유용할 수 있는 작업 | 우선 확인할 조건 |
|---|---|---|
| 개인 사용자·학생 | 자료 정리, 작은 프로젝트 검사, 반복 학습 작업 | 무료 등급 한도, 실행 실패 시 재개 방법, 예상 토큰 소비량 |
| 연구자 | 자료 검색, 파일 전처리, 정기적인 결과 생성 | 데이터 외부 전송, 샌드박스 보존 기간, 재현 가능한 모델 고정 |
| 개인 개발자 | 의존성 감사, 코드 품질 검사, 테스트 자동화 | 파일 쓰기 범위, 패키지 설치 권한, 훅 실패 처리, 기존 CI와의 중복 |
| 팀·서비스 운영자 | 예약 점검, 규칙 기반 검증, 장시간 다단계 작업 | 예산 상한, 감사 로그, 계정 권한, 실패 알림, 샌드박스 정리 정책 |
기존 자동화와 비교할 때의 판단 기준
Managed Agents의 장점은 하나의 API 호출이 추론, 코드 실행, 패키지 설치, 파일 관리, 웹 검색을 격리된 클라우드 샌드박스에서 조정한다는 점이다. 여러 서비스를 직접 연결하는 코드를 줄일 가능성이 있지만, 모든 반복 작업을 에이전트로 옮기는 것이 항상 효율적인 것은 아니다.
입력과 출력이 고정되고 예외가 거의 없는 작업은 일반 스크립트나 기존 CI가 더 단순하고 예측 가능할 수 있다. 반대로 저장소 상태를 해석해 다음 행동을 고르거나, 여러 파일과 도구를 오가며 문제를 해결해야 하는 작업은 Managed Agents의 이점을 살리기 쉽다. 다음 질문 가운데 여러 항목에 명확히 답할 수 있을 때 도입 우선순위를 높일 만하다.
- 현재 사람이 반복해서 판단하는 단계가 있는가?
- 에이전트가 실패해도 원래 상태로 되돌리거나 중단 지점에서 재개할 수 있는가?
- 도구 호출을 훅으로 검사하고 위험한 행동을 차단할 수 있는가?
- 작업당 토큰 상한과 월간 사용량을 추적할 수 있는가?
- 기존 스크립트나 CI보다 유지 관리해야 할 연결 코드가 실제로 줄어드는가?
- 같은 샌드박스를 재사용할 때 남는 파일과 상태를 통제할 수 있는가?
안전하게 검증하는 순서
- 대표 작업 하나를 고른다. 전체 개발 흐름을 옮기기보다 의존성 목록 검사나 보고서 생성처럼 성공 여부를 확인하기 쉬운 작업으로 시작한다.
- 모델을 명시해 기준선을 만든다. 기본 모델과 저비용 선택지를 같은 입력으로 비교하되 결과 품질, 호출 횟수, 토큰 소비량을 함께 기록한다.
- 토큰 상한을 설정한다. 불완전 종료가 발생했을 때 남는 파일과 상태를 확인하고, 재개 요청이 중복 변경을 만들지 않는지 시험한다.
- 쓰기와 코드 실행 앞에 훅을 둔다. 허용 경로, 금지 명령, 패키지 설치 정책을 검사하고 거부 사유가 예상대로 전달되는지 확인한다.
- 예약 실행 전에 수동 반복한다. 여러 번 실행해도 결과가 중복되거나 오염되지 않는 작업만 트리거로 전환한다.
- 종료와 삭제 절차를 검증한다. 작업 완료 후 샌드박스를 조회하고 불필요한 환경을 삭제할 수 있는지 확인한다.
최종 판단은 기능 수보다 반복 작업이 얼마나 줄어드는지에 달려 있다. 테스트 한두 번으로 끝나는 기능이라면 기존 도구를 유지하는 편이 나을 수 있다. 반대로 매주 수행하는 검사와 정리 작업을 일정한 비용 안에서 실행하고, 훅으로 권한과 품질을 통제할 수 있다면 Managed Agents를 별도 자동화 계층으로 검토할 가치가 있다.
적용 전에 반드시 확인할 사항
- 사용 중인 프로젝트와 지역에서 Managed Agents 및 선택한 모델을 사용할 수 있는가?
- 무료 등급과 유료 사용의 최신 호출 한도 및 과금 기준은 무엇인가?
- 기본 모델 변경이 기존 결과 품질과 토큰 사용량에 어떤 영향을 주는가?
- 샌드박스에 올린 파일, 실행 로그, 훅 데이터가 어디에 얼마나 오래 보존되는가?
- HTTP 훅이 조직 밖으로 데이터를 보내는 경우 별도 승인이 필요한가?
- 예약 작업의 실패, 중복 실행, 장기 미완료 상태를 어떻게 발견할 것인가?
- 환경을 재사용하거나 삭제할 수 있는 주체와 권한 범위가 명확한가?
업무 문서, 비공개 코드, 연구 자료처럼 민감한 데이터를 넣는다면 기능 시험보다 데이터 처리 조건과 계정 권한 검토가 먼저다. 가격과 할당량, 지원 모델, 훅의 실패 처리 방식은 적용 시점의 공식 문서를 기준으로 다시 확인해야 한다.
출처와 검증
Google AI Blog의 발표 내용을 바탕으로 기능 범위와 적용 기준을 정리했다. 최신 지원 조건, 가격, 무료 등급 한도와 세부 API 동작은 Gemini API Managed Agents 공식 발표 및 발표에서 연결된 공식 문서를 함께 확인해야 한다.