Gemini Managed Agents 업데이트: 3.6 Flash 기본값과 hooks가 바꾸는 에이전트 운영 방식

Google이 2026년 7월 28일 공개한 Gemini API Managed Agents 업데이트는 “모델이 좋아졌다”보다 운영 기능이 중요합니다. antigravity-preview-05-2026 agent가 Gemini 3.6 Flash를 기본으로 사용하고, environment hooks, 모델 선택, free tier, budget controls, scheduled triggers가 추가됐습니다.

개발자 입장에서 핵심은 하나입니다. 관리형 에이전트가 단순 API 호출이 아니라 원격 샌드박스에서 파일 관리, 코드 실행, 패키지 설치, 웹 검색, 도구 호출을 조합하는 실행 환경이 됐다는 점입니다. 따라서 모델 선택보다 중요한 질문은 “에이전트가 하는 행동을 어떻게 막고, 기록하고, 자동 검증할 것인가”입니다.

무엇이 바뀌었나

이번 업데이트의 공식 설명에 따르면 Managed Agents는 Gemini Interactions API 안에서 단일 API 호출로 reasoning, code execution, package installation, file management, web retrieval을 조율합니다. 여기에 새로 들어간 기능은 크게 네 가지입니다.

• Gemini 3.6 Flash가 기본 모델이 됨.
• agent_config.model로 Gemini 3.5 Flash, 3.5 Flash-Lite 등 모델을 명시 선택할 수 있음.
• environment hooks로 tool call 전후에 사용자 스크립트를 실행할 수 있음.
• max_total_tokens, scheduled triggers, free tier 접근이 추가됨.

표면적으로는 개발 편의 기능입니다. 하지만 실제 의미는 CI/CD와 비슷합니다. 에이전트가 코드를 쓰고, 명령을 실행하고, 결과물을 만드는 흐름 안에 정책과 검증 지점을 넣을 수 있게 됐기 때문입니다.

environment hooks가 중요한 이유

환경 hooks는 pre_tool_execution 또는 post_tool_execution 이벤트에 커스텀 스크립트를 연결하는 기능입니다. matcher는 정규식을 지원해서 code_execution, write_file 같은 특정 도구만 잡거나 전체 도구 호출을 대상으로 지정할 수 있습니다.

예를 들어 다음과 같은 운영 규칙을 만들 수 있습니다.

• 파일 쓰기 전에 금지 경로를 검사한다.
• code_execution 전에 위험 명령을 차단한다.
• write_file 후에 formatter와 linter를 실행한다.
• 산출물 생성 후 이미지, JSON, SQL 같은 결과물을 자동 검증한다.
• 모든 tool call 결과를 내부 감사 로그로 보낸다.

이전에는 에이전트에게 “위험한 명령은 실행하지 마”라고 프롬프트로 지시하는 방식이 많았습니다. 문제는 프롬프트 정책은 소프트 가드레일이라는 점입니다. hooks는 런타임 레벨에서 실행되는 하드 가드레일에 가깝습니다.

모델 선택은 비용 정책과 같이 봐야 한다

Gemini 3.6 Flash가 기본값이 됐다고 해서 모든 작업을 기본 모델로 돌릴 필요는 없습니다. Google 문서에는 Gemini 3.5 Flash-Lite를 낮은 비용과 지연시간이 중요한 워크플로우에 사용할 수 있다고 나옵니다.

실무에서는 작업을 세 등급으로 나누는 편이 안전합니다.

1. 단순 분류, 로그 요약, 형식 변환: 저비용 모델.
2. 코드 수정, 테스트 실패 분석, 리팩터링: 기본 모델.
3. 아키텍처 변경, 보안 검토, 장기 계획: 더 강한 reasoning 모델 또는 사람 리뷰.

모델 선택을 호출부마다 흩뿌리면 비용 통제가 어려워집니다. agent_config.model을 쓰더라도 내부에서는 “작업 유형 → 모델 정책” 매핑을 별도 설정으로 관리하는 편이 좋습니다.

budget controls는 필수 안전장치다

Managed Agents는 multi-turn autonomous loop를 실행합니다. 이런 구조는 단일 completion보다 비용 예측이 어렵습니다. 업데이트에서 max_total_tokens로 input, output, thinking token 전체 소비량을 제한할 수 있게 된 이유가 여기에 있습니다.

중요한 점은 한도 도달 시 작업이 실패로 끝나는 것이 아니라 status가 incomplete로 돌아오고 environment state가 보존된다는 설명입니다. previous_interaction_id로 이어갈 수 있다면, 긴 작업을 작은 예산 단위로 끊어 운영할 수 있습니다.

이 방식은 실무에서 매우 유용합니다.

• 1차 실행: 분석과 계획만 수행.
• 2차 실행: 제한된 파일 범위 수정.
• 3차 실행: 테스트와 리포트 생성.

한 번에 “전체 repo를 고쳐줘”라고 맡기는 것보다 비용, 위험, 리뷰 범위가 명확해집니다.

scheduled triggers는 자동화지만, 무조건 켜면 안 된다

scheduled triggers는 agent, environment, prompt, cron schedule을 묶어 반복 실행하는 기능입니다. 매일 dependency audit, 정기 문서 업데이트, 로그 분석 같은 작업에는 적합합니다.

하지만 반복 실행 에이전트는 장애도 반복합니다. 잘못된 prompt, 과한 권한, 느슨한 budget control이 붙으면 매일 같은 비용 낭비나 잘못된 수정이 발생할 수 있습니다.

운영 기준은 다음처럼 잡는 편이 좋습니다.

• 첫 1주일은 read-only 리포트만 생성한다.
• 자동 파일 수정은 별도 브랜치나 sandbox에서만 허용한다.
• post hook으로 테스트와 diff 요약을 강제한다.
• 실패 시 다음 실행을 자동 중단하는 kill switch를 둔다.
• 사람이 승인하기 전 production 배포로 이어지지 않게 한다.

어디에 먼저 적용하면 좋은가

Managed Agents를 바로 핵심 서비스 코드에 붙이기보다, 부작용이 작고 반복성이 높은 작업부터 시작하는 편이 낫습니다.

좋은 후보는 다음입니다.

• package.json dependency audit.
• 오래된 README와 API 문서 점검.
• 테스트 실패 로그 분류.
• screenshot, logo, JSON manifest 같은 산출물 검증.
• 코드 스타일 자동 수정 후 diff 리포트 생성.

반대로 DB migration, 결제 로직 변경, production credential이 필요한 작업은 hooks와 권한 정책을 충분히 검증한 뒤에 넘겨야 합니다.

실행 체크리스트

• Gemini Managed Agents를 free tier 프로젝트에서 먼저 실험한다.
• agent_config.model을 작업 유형별로 분리한다.
• max_total_tokens 기본값을 설정하고 incomplete 재개 흐름을 테스트한다.
• code_execution과 write_file에 pre_tool_execution hook을 붙인다.
• write_file 이후 linter, formatter, schema validator를 post hook으로 실행한다.
• scheduled trigger는 read-only 리포트부터 시작한다.
• 에이전트 산출물은 diff, 테스트 로그, 감사 로그와 함께 저장한다.

이번 업데이트는 에이전트 API가 “모델 호출”에서 “운영 가능한 작업자”로 이동하고 있다는 신호입니다. 이제 경쟁력은 어떤 모델을 쓰느냐만이 아니라, 그 모델이 실행하는 행동을 얼마나 잘 제한하고 검증하느냐에서 갈립니다.