Gemini API Managed Agents 업데이트: hooks와 예산 제한으로 에이전트 운영하기

Gemini API Managed Agents 업데이트는 에이전트를 데모에서 운영 작업자로 옮기려는 개발팀에 직접적인 의미가 있다. Google은 2026년 7월 28일 Managed Agents가 Gemini 3.6 Flash를 기본 모델로 쓰고, environment hooks, 예산 제한, scheduled triggers, free tier access를 지원한다고 발표했다. 7월 7일에는 background execution, remote MCP server, custom function calling, credential refresh도 공개했다.

핵심은 “에이전트가 더 똑똑해졌다”보다 “에이전트가 샌드박스 안에서 오래 일하고, 도구 호출을 검사받고, 비용 한도에 걸리면 멈추며, 스케줄에 따라 반복 실행될 수 있다”는 점이다. 실무에서는 모델 성능보다 이런 운영 장치가 더 중요하다.

Managed Agents가 해결하려는 문제

일반적인 에이전트 구현은 개발자가 루프를 직접 만든다. 모델에게 다음 행동을 묻고, 도구를 실행하고, 결과를 다시 넣고, 실패하면 재시도하고, 파일을 저장하고, 로그를 남긴다. 작은 데모에서는 괜찮지만 실제 업무에서는 연결 유지, 패키지 설치, 파일 관리, 외부 검색, 코드 실행, 인증 갱신이 엉킨다.

Gemini Interactions API의 Managed Agents는 이 중 상당 부분을 하나의 API 호출과 원격 샌드박스로 묶는다. Google 설명에 따르면 reasoning, code execution, package installation, file management, web retrieval을 isolated cloud sandbox 안에서 조정한다. 개발자는 모든 tool loop를 직접 짜기보다 작업과 환경, 도구, 예산을 정의하는 쪽에 가까워진다.

이 구조는 특히 “짧은 답변”이 아니라 “작업 완료”가 필요한 경우에 맞다. 저장소를 클론해 TODO를 분류하거나, dependency를 업데이트하고 테스트를 돌리거나, 내부 observability 서버에서 latency spike를 찾아 commit과 연결하는 식의 작업이다.

Gemini 3.6 Flash 기본값의 의미

7월 28일 업데이트 이후 antigravity-preview-05-2026 agent는 Gemini 3.6 Flash를 기본값으로 사용한다. 별도 코드 변경 없이 다음 interaction부터 적용된다. 동시에 agent_config.model로 Gemini 3.5 Flash-Lite 같은 더 낮은 비용·지연 모델을 명시할 수도 있다.

운영팀이 여기서 볼 것은 모델 이름보다 변경 관리다. 기본 모델이 자동으로 바뀌면 같은 프롬프트도 다른 결과를 낼 수 있다. 일부 팀에는 성능 향상이지만, 규제·금융·의료처럼 결과 일관성이 중요한 서비스에는 리스크다. 따라서 production agent는 기본값에 맡기기보다 모델을 pinning하고, 새 모델은 staging에서 eval을 통과한 뒤 올리는 편이 낫다.

반대로 내부 자동화나 실험용 작업은 기본값을 따라가는 전략도 가능하다. 최신 기본 모델을 쓰면 관리 비용이 줄고, Google이 의도한 balanced model을 바로 활용할 수 있다. 결론은 하나다. “기본값을 쓴다”도 결정이고, “모델을 고정한다”도 결정이다. 문서화하지 않은 기본값 의존이 가장 위험하다.

hooks는 에이전트의 안전벨트다

이번 업데이트에서 가장 실무적인 기능은 environment hooks다. 샌드박스 안에서 agent가 tool call을 실행하기 전이나 후에 custom script를 돌릴 수 있다. 예를 들어 pre_tool_execution에서 code_execution 또는 write_file을 검사하고, 위험한 명령이면 deny를 반환해 실행을 막을 수 있다. post_tool_execution에서는 auto_lint, 포맷 검사, 산출물 검증을 붙일 수 있다.

이 기능은 단순한 로그보다 강하다. 에이전트가 “테스트를 돌리겠다”고 말했을 때 실제 명령이 npm test인지, rm -rf가 섞였는지, production endpoint를 호출하는지 gate.py가 판단할 수 있다. 결과가 거부되면 rejection reason이 모델 문맥에 들어가 다음 행동을 고치게 된다.

Google이 소개한 OffDeal 사례도 이 방향이다. 원격 샌드박스에서 회사 로고 후보를 가져오고, 크기·비율·투명 배경·대비를 검사하고, Gemini vision으로 검증한 뒤 승인된 manifest만 deck에 넣는 파이프라인을 post_tool_execution hook으로 구성했다. 즉 hooks는 보안뿐 아니라 품질 관리에도 쓸 수 있다.

예산 제한과 background execution은 같이 봐야 한다

에이전트는 실패할 때 조용히 비싸진다. 한 번의 답변이 아니라 여러 턴의 자율 루프를 돌기 때문이다. Managed Agents는 agent_config.max_total_tokens로 input, output, thinking을 합친 총 사용량을 제한할 수 있다. 한도에 닿으면 status가 incomplete로 돌아오고, environment state는 보존된다. 이후 previous_interaction_id와 새 예산으로 이어서 실행할 수 있다.

이 방식은 운영 사고를 줄인다. 예산을 넘으면 작업을 죽이는 대신 중단 상태와 파일을 남긴다. 개발자는 “왜 여기서 멈췄는지” 확인하고 추가 예산을 줄지 결정할 수 있다. 장시간 작업에는 background: true도 중요하다. HTTP 연결을 오래 붙잡지 않고 interaction ID를 받은 뒤 상태를 조회하거나 나중에 재연결할 수 있다.

실무 기준으로는 작업 종류별 기본 예산을 두는 편이 좋다. dependency audit은 10,000 tokens, 저장소 전체 migration report는 50,000 tokens, 대규모 리팩터링은 단계별 승인처럼 나눈다. 비용 한도 없이 “repo 전체를 분석해줘”는 금지해야 한다.

scheduled triggers와 Environments API가 만드는 운영 패턴

scheduled triggers는 agent, environment, prompt, cron schedule을 묶어 반복 실행한다. 같은 sandbox를 재사용하므로 파일이 실행 간에 유지된다. 이 구조는 주간 dependency report, 야간 테스트 실패 분석, 매일 로그 이상치 요약, 문서 최신화 점검 같은 작업에 맞다.

하지만 같은 sandbox를 재사용한다는 점은 장점이자 위험이다. 파일이 남아 있어 캐시를 활용할 수 있지만, 이전 실행의 임시 파일이나 토큰이 다음 실행에 영향을 줄 수 있다. Environments API로 sandbox를 list, inspect, delete할 수 있으므로 운영자는 TTL에만 맡기지 말고 정리 정책을 만들어야 한다.

credential refresh도 실무에 중요하다. 단기 토큰이 만료되면 같은 environment_id에 새 network configuration을 넘겨 토큰을 교체할 수 있다. 파일과 설치 패키지는 유지하면서 접근 권한만 갱신하는 구조다. 토큰 회전을 수동 재시작 없이 처리할 수 있지만, 새 토큰의 allowlist가 기존보다 넓어지지 않았는지 검사해야 한다.

바로 적용할 수 있는 설계 기준

첫 번째 기준은 “작업을 짧게 나누기”다. 에이전트에게 저장소 전체를 고치라고 하지 말고, 분석 보고서 작성, 수정 계획 제안, 제한된 파일 변경, 테스트 실행, 결과 요약으로 쪼갠다. 두 번째 기준은 “hooks에서 정책을 코드로 만들기”다. 프롬프트로 위험 명령을 금지하는 것보다 실제 실행 전에 검사하는 스크립트가 더 안전하다.

세 번째 기준은 “예산과 시간 제한을 기본값으로 두기”다. max_total_tokens, hook timeout, 외부 API timeout, scheduled trigger frequency를 모두 명시한다. 네 번째 기준은 “모델 변경을 배포처럼 관리하기”다. 기본 모델이 3.6 Flash로 바뀌었더라도 production 작업은 staging eval 후 pin을 바꾼다.

실행 체크리스트

• 실험용과 운영용 agent를 분리하고, 운영용은 model pinning 여부를 명시한다.
• 모든 write_file, code_execution, 외부 API 호출 앞에 pre_tool_execution hook을 둔다.
• post_tool_execution hook으로 lint, 테스트, 산출물 schema 검증을 자동화한다.
• 작업 종류별 max_total_tokens 기본값을 정하고, incomplete 상태의 재개 절차를 문서화한다.
• long-running 작업은 background execution으로 시작하고 interaction ID를 저장한다.
• scheduled trigger는 같은 sandbox 재사용 영향을 고려해 정리 정책과 Environments API 삭제 기준을 둔다.
• remote MCP와 credential refresh는 allowlist, 토큰 만료 시간, 감사 로그를 함께 설계한다.

출처: Google Blog ‘Gemini API Managed Agents: 3.6 Flash, hooks, and more’, ‘Expanding Managed Agents in Gemini API’.