Gemini Managed Agents는 2026년 7월 현재 개발자가 AI 기능을 제품과 업무 흐름에 넣는 방식을 다시 생각하게 만드는 기술입니다. 단순히 새 기능이 하나 더 붙은 발표라기보다, 모델 호출·도구 실행·검증·비용 통제가 하나의 운영 문제로 합쳐지고 있다는 신호에 가깝습니다. 이 글에서는 Gemini Managed Agents의 배경과 기본 원리를 쉬운 예시로 풀고, 실제 도입 전에 확인해야 할 한계도 함께 정리하겠습니다.
2026-07-23에 OpenAI Codex와 Claude 4 에이전틱 코딩을 다뤘기 때문에, 이번 글은 특정 코딩 제품이 아니라 Gemini API가 에이전트 실행 환경 자체를 서비스로 포장하는 방식을 다시 보는 글입니다. 관련 맥락으로는 에이전틱 코딩 흐름과 AI 반도체 인프라 흐름이 함께 움직이고 있습니다. 모델이 강해질수록 호출 인터페이스, 보안 검사, 로컬 추론, 품질 게이트 같은 주변 기술이 더 중요해지는 이유입니다.
배경: 왜 지금 등장했나
Gemini Managed Agents의 핵심은 모델을 한 번 호출하는 API가 아니라, 긴 작업을 맡길 수 있는 실행 단위입니다. Google의 2026년 7월 발표는 Managed Agents에 배경 실행, 원격 MCP, custom function calling, credential refresh 같은 기능이 붙었다고 설명합니다. 이것은 “모델이 답한다”에서 “모델이 도구와 환경을 갖고 일을 계속한다”로 무게중심이 옮겨가는 변화입니다.
원격 MCP가 중요한 이유는 에이전트가 사내 문서, 이슈 트래커, 데이터베이스, 배포 도구 같은 외부 시스템을 표준화된 방식으로 호출할 수 있기 때문입니다. 예전에는 각 도구를 직접 API 연동해야 했지만, MCP를 통하면 도구 연결부를 더 일관되게 관리할 수 있습니다. 반대로 말하면, 어떤 MCP 서버를 허용할지와 어떤 권한을 줄지가 곧 보안 설계가 됩니다.
배경 실행도 실무에서는 큽니다. 코드 분석, 긴 문서 작성, 테스트 실행처럼 오래 걸리는 작업은 HTTP 요청 하나 안에서 끝나지 않습니다. 작업이 백그라운드에서 계속되고, 나중에 interaction ID나 environment ID로 결과를 이어받을 수 있어야 실제 제품에 넣기 쉽습니다. Gemini Managed Agents는 이런 상태 관리와 실행 환경을 Google이 관리하는 방향으로 제안합니다.
기술의 기본 원리
Gemini Managed Agents를 이해하려면 세 가지를 보면 됩니다. 첫째, 사용자는 목표를 던집니다. 둘째, 관리형 에이전트는 원격 환경에서 모델 호출, 파일 작업, 도구 호출, MCP 연동을 수행합니다. 셋째, 결과는 단순 텍스트가 아니라 interaction, 산출 파일, 실행 로그, 다음 작업에 이어 쓸 수 있는 상태로 남습니다.
예를 들어 개발자가 “이 저장소의 인증 플로우를 점검하고 문서화해줘”라고 요청한다고 가정하겠습니다. 관리형 에이전트는 저장소를 읽고, 필요한 명령을 실행하고, 원격 MCP로 이슈 트래커나 문서 시스템을 조회할 수 있습니다. 작업이 길어지면 배경 실행으로 넘기고, 이후 previous_interaction_id 같은 식별자를 통해 같은 맥락에서 이어갈 수 있습니다.
여기서 좋은 점은 클라이언트 코드가 모든 상태를 직접 들고 있지 않아도 된다는 점입니다. 나쁜 점은 상태가 서버에 남는다는 점입니다. 따라서 기업 사용자는 편의성만 보지 말고 데이터 보관 기간, 삭제 가능성, 감사 로그, 자격 증명 갱신 정책을 같이 확인해야 합니다. Managed Agents는 자동화 기능이면서 동시에 운영·보안 설계 대상입니다.
한 장으로 이해하는 구조
위 그림은 Gemini Managed Agents를 “작업을 맡기는 환경”으로 본 흐름입니다. 사용자는 목표를 주고, 관리형 에이전트는 원격 실행 환경 안에서 모델 호출, 파일 작업, MCP 도구 호출을 이어갑니다. 결과는 한 번의 답변으로 끝나지 않고 interaction과 산출물로 남아 다음 요청에서 다시 이어집니다.
실무자가 봐야 할 지점은 세 가지입니다. 어떤 MCP 서버를 허용했는가, 배경 실행 중인 작업을 멈추거나 재시도할 수 있는가, 자격 증명이 자동 갱신될 때 감사 로그가 남는가입니다. 이 셋이 없으면 편리한 에이전트가 아니라 권한을 가진 블랙박스가 됩니다.
한계와 체크포인트
첫 번째 한계는 권한입니다. 원격 MCP와 credential refresh는 편하지만, 잘못 열어두면 에이전트가 너무 많은 시스템에 접근할 수 있습니다. 조직별 allowlist와 테스트용 계정이 필요합니다.
두 번째는 작업 추적입니다. 배경 실행은 오래 걸리는 일을 맡기기 좋지만, 취소·재시도·결과 다운로드 경로가 불명확하면 운영자가 문제를 찾기 어렵습니다.
셋째, Managed Agents는 개발자를 없애는 기능이 아닙니다. 사람이 해야 할 일은 더 분명해집니다. 목표를 좁히고, 접근 권한을 제한하고, 산출물을 검토하는 기준을 세워야 합니다.
요약하면 Gemini Managed Agents는 “Gemini가 똑똑해졌다”보다 “Gemini가 일을 맡을 실행 환경을 얻었다”에 가깝습니다. 도입 여부는 모델 성능보다 권한 설계와 로그 품질로 판단하는 편이 안전합니다.
참고한 핵심 출처
- Google Keyword: Expanding Managed Agents in Gemini API — 2026-07-07 공식 발표. 배경 실행, 원격 MCP, custom function calling, credential refresh.
- Google AI Developers: Managed Agents Quickstart — Antigravity agent, remote environment, previous_interaction_id, environment_id, streaming, file download 설명.
- Google AI Developers: Interactions API — Interaction 리소스, server-side state, background=true, store=false 제약 및 지원 모델 설명.
댓글 없음:
댓글 쓰기