Gemini 3.8 Flash 에이전트 운영법: Managed Agents 기본 모델 변경 전에 점검할 지표

검색 의도: Gemini 3.8 Flash, Gemini Managed Agents, Antigravity agent 기본 모델, Gemini API 에이전트 운영 지표

Google AI for Developers 문서에는 Gemini 3.8 Flash가 제공되고, Gemini Managed Agents의 Antigravity agent가 기본적으로 Gemini 3.8 Flash를 사용한다는 업데이트가 올라왔다. Managed Agents는 Google이 호스팅하는 격리된 Linux sandbox에서 상태ful autonomous agent를 만들고 배포하는 기능으로 소개된다. 개발자 입장에서는 “새 모델이 빠르고 좋아졌다”보다 “에이전트 런타임의 기본 모델이 바뀌면 운영 지표를 다시 봐야 한다”가 더 중요하다.

에이전트는 단발성 챗봇과 다르다. 도구를 호출하고, 파일을 만들고, 여러 단계의 계획을 실행하고, 실패하면 복구를 시도한다. 기본 모델이 바뀌면 답변 품질뿐 아니라 tool call 수, latency, sandbox 사용 시간, 비용, 실패 패턴이 함께 바뀐다.

모델 교체를 기능 배포처럼 다뤄야 하는 이유

일반 API 호출에서는 모델을 바꿔도 입력과 출력만 비교하면 되는 경우가 많다. 하지만 agent runtime에서는 중간 과정이 중요하다. 같은 목표를 줬을 때 이전 모델은 3번의 tool call로 끝내던 일을 새 모델은 8번 호출할 수 있다. 반대로 더 좋은 계획을 세워 호출 수를 줄일 수도 있다. 결과물만 보면 둘 다 성공이지만 비용과 안정성은 다르다.

특히 sandbox 기반 Managed Agents에서는 실행 시간이 비용과 장애 가능성에 영향을 준다. 모델이 더 적극적으로 탐색하면 파일 읽기, web search, build command가 늘 수 있다. 따라서 기본 모델 변경은 “성능 개선” 공지가 아니라 runtime behavior 변경으로 봐야 한다.

먼저 볼 지표는 정답률이 아니라 실행 경로다

에이전트 평가에서 최종 성공률만 보면 늦다. 운영 지표는 경로를 보여줘야 한다. 최소한 다음 다섯 가지를 비교한다. 첫째, 평균 tool call 수. 둘째, p50/p95 완료 시간. 셋째, 중간 실패 후 self-recovery 비율. 넷째, 사람이 승인해야 하는 action 발생률. 다섯째, 같은 작업을 반복했을 때 출력 diff 크기다.

예를 들어 “GitHub issue를 읽고 수정 PR 초안을 만들라”는 평가 세트를 만든다. 이전 모델과 Gemini 3.8 Flash 기반 agent를 같은 입력으로 30회 이상 돌린다. 성공률만 보지 말고 어떤 파일을 읽었는지, 필요 없는 명령을 실행했는지, 테스트를 실제로 돌렸는지, PR 설명이 issue 요구사항을 빠뜨리지 않았는지 확인한다.

이 작업은 귀찮지만 필요하다. 에이전트가 실패할 때는 대개 마지막 답변이 아니라 중간 선택에서 문제가 생긴다.

sandbox 권한은 기본 모델보다 먼저 고정한다

Managed Agents가 격리된 Linux sandbox에서 실행된다는 점은 장점이다. 그러나 격리되어 있다고 해서 모든 권한을 열어도 된다는 뜻은 아니다. 모델 교체 테스트를 하려면 sandbox 권한과 도구 구성을 먼저 고정해야 한다. 그래야 모델 차이와 환경 차이를 분리할 수 있다.

권장 설정은 단순하다. 읽기 가능한 저장소, 쓰기 가능한 작업 디렉터리, 네트워크 접근 도메인, secret 접근 여부, 설치 가능한 패키지 범위를 명시한다. 테스트 중에는 외부 write action을 막는다. Slack 전송, 이슈 댓글 작성, PR 생성, 배포 같은 작업은 초안 생성까지만 허용한다. 실제 write는 사람 승인 뒤 별도 단계에서 실행한다.

권한을 고정하지 않으면 “새 모델이 더 공격적이다”와 “새 테스트 환경이 더 넓게 열려 있다”를 구분할 수 없다.

비용은 token보다 session 단위로 봐야 한다

에이전트 비용은 입력·출력 토큰만으로 설명되지 않는다. tool call, sandbox 실행 시간, 재시도, 긴 context 유지, 로그 저장이 모두 영향을 준다. 따라서 Gemini 3.8 Flash로 바꾸기 전후에는 작업당 총비용을 봐야 한다. 특히 p95 비용을 확인해야 한다. 평균은 괜찮아도 일부 세션이 긴 탐색으로 튀면 운영 예산이 흔들린다.

작업을 세 등급으로 나누는 것도 좋다. 1분 이내의 짧은 질문형 작업, 5~15분의 개발 보조 작업, 30분 이상 걸릴 수 있는 장기 에이전트 작업이다. 각 등급마다 timeout, max tool call, max retry, budget cap을 다르게 둔다. 같은 기본 모델이라도 작업 등급별 guardrail이 달라야 한다.

배포는 전체 전환보다 canary가 안전하다

기본 모델 변경은 canary로 시작한다. 전체 agent traffic의 5~10%만 Gemini 3.8 Flash로 돌리고, 나머지는 기존 모델에 둔다. 비교 지표가 안정적이면 25%, 50%, 100%로 늘린다. 이때 rollback 조건을 숫자로 정한다. 예를 들어 p95 latency가 30% 이상 증가하거나, 사람 개입률이 2배 이상 늘거나, 실패 후 복구율이 10%p 이상 떨어지면 롤백한다.

평가 세트도 함께 유지한다. 모델이 바뀔 때마다 매번 새로 감으로 판단하면 팀이 지친다. 대표 작업 20~50개를 golden task로 묶고, release note가 나올 때마다 자동 실행한다. 에이전트 운영의 핵심은 최신 모델을 빨리 쓰는 것이 아니라, 모델 변경에도 서비스 행동을 예측 가능하게 유지하는 것이다.

실행 체크리스트

• 기존 Managed Agents 작업을 질문형, 개발 보조, 장기 작업으로 분류한다.
• 각 작업의 평균 tool call 수, p95 latency, 실패율, 사람 승인률을 baseline으로 저장한다.
• Gemini 3.8 Flash 적용 전 sandbox 권한, 네트워크, secret 접근 범위를 고정한다.
• golden task 20~50개를 만들어 이전 모델과 새 모델을 같은 입력으로 비교한다.
• 결과물뿐 아니라 읽은 파일, 실행한 명령, 테스트 여부, self-recovery 경로를 기록한다.
• canary traffic 5~10%부터 시작하고 rollback 조건을 숫자로 정한다.
• 작업 등급별 timeout, max tool call, budget cap을 따로 설정한다.
• 모델 변경 후 1주일은 p95 비용과 장기 세션 outlier를 별도로 본다.

Gemini 3.8 Flash가 Managed Agents의 기본 모델로 들어간다는 소식은 에이전트 운영팀에게 좋은 기회다. 다만 새 모델을 “더 빠른 답변기”로만 보면 놓치는 것이 많다. 에이전트에서는 모델이 곧 실행 전략이다. 그래서 모델 변경은 코드 배포처럼 측정하고, 제한하고, 단계적으로 늘려야 한다.