Gemini Managed Agents는 AI 모델 하나를 호출하는 기능이라기보다, 모델이 코드를 실행하고 파일을 만들고 도구를 부르는 작업 환경까지 API로 묶은 형태에 가깝습니다. Google은 2026년 7월 28일 업데이트에서 이 관리형 에이전트의 기본 모델을 Gemini 3.6 Flash로 바꾸고, 샌드박스 안의 도구 호출을 훅으로 막거나 검사하거나 기록하는 기능을 공개했습니다.
중요한 변화는 “더 똑똑한 모델”보다 “더 통제 가능한 실행”입니다. 에이전트가 패키지를 설치하고 테스트를 돌리고 원격 파일을 고치는 순간, 개발팀의 관심사는 답변 품질만이 아닙니다. 어떤 명령을 허용할지, 비용이 어디까지 불어날 수 있는지, 반복 작업을 누가 감시할지가 운영 문제가 됩니다.
핵심만 보면 Managed Agents는 모델 호출, 원격 샌드박스, 도구 실행, 파일 상태, 예산 제한, 예약 실행을 하나의 개발자 API로 묶으려는 시도입니다.
배경
Google 발표에 따르면 Managed Agents는 Gemini Interactions API 위에서 동작하며, 하나의 API 호출이 추론, 코드 실행, 패키지 설치, 파일 관리, 웹 검색을 격리된 클라우드 샌드박스 안에서 조율합니다. 이번 업데이트의 기본 에이전트 antigravity-preview-05-2026은 Gemini 3.6 Flash를 사용합니다. 모델 문서에는 gemini-3.6-flash가 텍스트·이미지·비디오·오디오·PDF 입력을 받고 텍스트를 출력하며, 입력 토큰 한도 1,048,576과 출력 토큰 한도 65,536을 제공한다고 정리돼 있습니다.
이 숫자가 의미하는 바는 단순한 긴 문맥 처리만이 아닙니다. 저장소 전체를 읽고, 로그와 문서를 함께 넣고, 테스트 실패 원인을 추적하는 에이전트 작업은 짧은 채팅보다 훨씬 많은 문맥을 씁니다. 여기에 코드 실행, 파일 검색, 함수 호출, 검색 기반 grounding, 구조화 출력, thinking 지원이 붙으면 “질문에 답하는 AI”보다 “작업을 끝내는 작업자”에 가까워집니다.
다만 이런 자동화는 위험도 함께 키웁니다. 잘못된 파일 삭제, 의존성 과다 업그레이드, 비용 폭주, 비밀값 노출 같은 문제는 모델 성능만으로 막기 어렵습니다. 그래서 이번 업데이트에서 봐야 할 중심은 Gemini 3.6 Flash 자체보다 환경 훅, 토큰 예산, 예약 트리거입니다.
원리
환경 훅은 에이전트가 샌드박스 안에서 도구를 실행하기 전후에 개발자가 정한 스크립트를 끼워 넣는 장치입니다. 예를 들어 write_file이나 코드 실행 도구가 호출되기 직전에 보안 스크립트를 돌려 특정 경로 쓰기를 거부할 수 있습니다. 실행 뒤에는 포맷터나 린터를 호출해 결과물을 자동 검사할 수 있습니다.
실무 시나리오로 보면, 사내 저장소의 의존성 업그레이드를 에이전트에게 맡길 때 훅은 작은 승인 게이트 역할을 합니다. package.json 수정은 허용하되 배포 키가 들어 있는 경로 쓰기는 차단하고, 테스트 명령 뒤에는 취약점 스캔을 자동 실행하는 식입니다. 에이전트는 여전히 자동으로 움직이지만, 조직이 정한 울타리 안에서만 움직입니다.
| 구성 요소 | 하는 일 | 운영상 의미 |
|---|---|---|
| Gemini 3.6 Flash | 추론·코딩·도구 사용의 기본 모델 | 빠른 반복 작업의 엔진 |
| 원격 샌드박스 | 파일·패키지·명령 실행 환경 | 로컬 개발 PC와 격리 |
| 환경 훅 | 도구 호출 전후 검사 스크립트 | 보안·품질 정책 삽입 |
| 예산 제한 | max_total_tokens로 총 토큰 사용 제한 |
비용 폭주 완화 |
| 예약 트리거 | cron 형태의 반복 실행 | 정기 점검 자동화 |
구조
위 장면에서 중요한 것은 에이전트가 사람을 완전히 대체한다는 느낌이 아니라, 사람이 정의한 실행 환경 안에서 움직인다는 점입니다. 모델은 작업 계획을 세우고 도구를 부르지만, 샌드박스는 파일과 명령의 범위를 제한합니다. 훅은 그 경계에서 정책을 검사합니다.
다이어그램의 흐름은 사용자 작업이 관리형 에이전트로 들어가고, 에이전트가 샌드박스 도구를 호출하며, 그 앞뒤를 훅이 감시하는 구조입니다. 예산 제한은 긴 루프를 중간에 멈추게 하고, 예약 트리거는 같은 샌드박스 상태를 유지한 채 정기 작업을 실행합니다.
체크포인트
첫째, 훅은 만능 보안 제품이 아닙니다. 어떤 도구 호출을 막을지, 어떤 파일을 허용할지, 실패한 검사 결과를 어떻게 처리할지는 팀이 직접 설계해야 합니다. 허술한 훅은 자동화에 안전하다는 착각만 더할 수 있습니다.
둘째, 비용 통제는 기능 목록이 아니라 운영 정책입니다. Google은 max_total_tokens에 도달하면 상태를 보존한 채 incomplete로 멈추고, 이후 previous_interaction_id로 이어갈 수 있다고 설명합니다. 긴 코드베이스 점검에는 유용하지만, 어디에서 멈춰도 안전한 작업 단위로 나누는 설계가 필요합니다.
셋째, 예약 실행은 편하지만 책임 소재를 흐릴 수 있습니다. 매일 취약점 점검이나 문서 업데이트를 돌리는 것은 좋지만, 자동 커밋·자동 배포까지 이어질수록 리뷰와 롤백 경로가 더 중요해집니다.
Managed Agents의 방향은 분명합니다. AI 에이전트는 채팅창 바깥으로 나와 개발 환경에서 실제 작업을 수행하고, 플랫폼은 그 작업을 격리·감사·예산화하는 쪽으로 움직입니다. 기업이나 팀이 지금 살펴봐야 할 질문은 “어떤 모델이 더 좋은가”보다 “어떤 작업을 샌드박스에 맡기고, 어떤 호출을 반드시 막을 것인가”에 가깝습니다.
댓글 없음:
댓글 쓰기