Google Managed Agents 해설: 에이전트 앱은 모델보다 격리 런타임·상태 재개·도구 권한을 먼저 설계해야 하는 이유

1. 한 줄 문제 정의

핵심 요약: 에이전트 앱의 어려움은 모델 호출보다 실행 환경을 안전하게 계속 유지하는 데 있다.

2026년 5월 19일 Google은 Gemini API에 Managed Agents를 공개했다. 한 번의 API 호출로 추론하고, 도구를 쓰고, 코드를 실행하는 에이전트를 원격 Linux 환경에서 띄울 수 있게 하는 기능이다.

초보 개발자 관점에서 쉽게 말하면, Managed Agents는 “모델에게 답만 받는 API”가 아니라 “작업할 책상까지 함께 빌려주는 API”에 가깝다. 그 책상에는 파일, 실행 상태, 웹 탐색, 코드 실행 환경이 붙어 있다.

이 글의 적용 범위는 제품 안에 조사, 파일 처리, 코드 실행, 반복 작업 에이전트를 넣으려는 개발팀이다. 단순 질의응답 챗봇, 고정된 FAQ, 외부 도구 실행이 거의 없는 앱에는 과한 선택일 수 있다.

2. 먼저 결론

핵심 요약: Managed Agents는 빠른 실험에는 강하지만, 권한 설계 없이 붙이면 운영 리스크가 먼저 커진다.

Managed Agents는 “에이전트 인프라를 직접 만들지 않고 제품 기능을 빠르게 검증하고 싶은 팀”에게 맞다. 특히 긴 작업을 여러 번 이어가야 하거나, 파일 상태를 보존하면서 후속 요청을 처리해야 하는 경우에 가치가 크다.

반대로 이미 자체 샌드박스, 작업 큐, 감사 로그, 권한 분리 체계를 갖춘 팀이라면 무조건 갈아탈 이유는 약하다. Google의 관리형 환경을 쓰면 인프라 부담은 줄지만, 실행 위치와 데이터 경계에 대한 통제는 별도로 따져야 한다.

제 판단은 이렇다. 지금 도입한다면 “핵심 업무 자동화 전체”가 아니라 “실패해도 복구 가능한 내부 보조 작업”부터 붙이는 편이 맞다. 예를 들면 리서치 초안 생성, 로그 요약, 테스트용 코드 실행, 내부 문서 정리처럼 사람 검수 게이트가 있는 흐름이다.

3. 핵심 구조 분해

핵심 요약: 구조는 모델, 에이전트 하네스, 격리 환경, 도구, 상태 재개의 다섯 층으로 봐야 한다.

Google 설명에 따르면 Managed Agents는 Antigravity agent를 기반으로 한다. Antigravity는 에이전트가 계획을 세우고, 도구를 호출하고, 결과를 이어서 처리하도록 돕는 하네스다. 하네스는 자동차의 엔진 제어 장치처럼, 모델이 실제 작업으로 넘어갈 때 필요한 절차를 묶어준다.

그 위에는 Gemini 3.5 Flash가 있다. Google은 이 모델을 에이전트 작업에 맞춘 빠른 모델로 설명하며, I/O 2026 발표에서 Terminal-Bench 2.1 76.2%, GDPval-AA 1656 Elo, MCP Atlas 83.6% 같은 수치를 함께 제시했다.

실행 계층은 원격 Linux 환경이다. 에이전트가 코드를 실행하고 파일을 관리할 수 있는 곳이다. 중요한 점은 이 환경이 단순 임시 응답 버퍼가 아니라 후속 호출에서 다시 받을 수 있는 작업 공간이라는 점이다.

마지막으로 도구와 상태가 있다. 웹에서 최신 데이터를 가져오거나, 파일을 만들거나, 이전 작업 결과를 이어받는 일이 여기에 포함된다. 에이전트 제품의 품질은 이 다섯 층이 얼마나 분리되어 있고, 어디서 실패했는지 추적할 수 있느냐에 달려 있다.

4. 설계 의도 해설

핵심 요약: Google의 의도는 모델 API를 “응답 생성기”에서 “작업 실행 런타임”으로 확장하는 것이다.

기존 LLM API의 기본 단위는 대체로 요청과 응답이었다. 사용자가 묻고, 모델이 답하고, 애플리케이션이 나머지를 처리했다. 에이전트 앱에서는 이 방식이 금방 막힌다. 모델이 작업을 여러 단계로 나누고, 중간 파일을 만들고, 외부 데이터를 확인하고, 실패 지점에서 다시 시작해야 하기 때문이다.

Managed Agents의 설계는 이 병목을 줄이려는 방향이다. 개발자가 직접 컨테이너를 띄우고, 작업 상태 저장소를 만들고, 파일 격리를 설계하고, 도구 호출 흐름을 구성하는 부담을 Google이 일부 가져간다.

하지만 이 선택에는 대가가 있다. 자체 인프라보다 빠르게 시작할 수 있는 대신, 실행 환경의 세부 정책과 데이터 위치를 Google의 제품 계약 안에서 해석해야 한다. 에이전트가 고객 데이터를 다루거나 내부 코드를 실행한다면 이 부분은 단순 기능 비교보다 더 중요하다.

그래서 이 기술을 볼 때 “Gemini가 얼마나 똑똑한가”보다 “우리 제품에서 어떤 작업을 맡겨도 되는가”를 먼저 물어야 한다.

5. 근거 및 비교

핵심 요약: 경쟁 상대는 챗봇 API가 아니라 자체 샌드박스, 브라우저 자동화, 코딩 에이전트 플랫폼이다.

접근	맞는 상황	얻는 것	포기하거나 점검할 것
Gemini Managed Agents	빠르게 관리형 에이전트 기능을 제품에 붙일 때	격리 Linux 환경, 파일 상태, 도구 실행, 후속 호출 재개	데이터 경계, 권한 정책, 비용 예측, 프리뷰 기능 안정성
일반 LLM API + 자체 도구 호출	작업이 짧고 실행 환경이 필요 없을 때	단순한 구조, 높은 통제력, 낮은 초기 복잡도	상태 관리와 샌드박스는 직접 구현해야 함
자체 컨테이너 샌드박스	보안·감사·데이터 위치 통제가 강하게 필요할 때	실행 경계와 로그 정책을 직접 설계 가능	인프라 운영 비용과 장애 대응 부담 증가
IDE/CLI형 코딩 에이전트	개발자 개인이나 팀의 코드 작업 자동화	로컬 워크플로와 잘 맞고 리뷰 흐름을 만들기 쉬움	최종 사용자 제품 안에 내장하기는 어렵거나 별도 설계 필요

Google 공식 블로그의 핵심 문장은 “single call”과 “isolated Linux environment”다. 이 두 표현은 단순 편의 기능이 아니다. 에이전트 제품에서 가장 귀찮은 두 영역, 즉 실행 환경 준비와 작업 상태 관리를 제품화했다는 뜻이다.

또 하나의 근거는 Google I/O 2026 개발자 발표다. Google은 Antigravity 2.0, Antigravity CLI, SDK, Gemini Enterprise Agent Platform, Managed Agents를 한 묶음으로 발표했다. 이는 단일 기능 출시라기보다 에이전트 개발 플랫폼으로 묶으려는 전략에 가깝다.

6. 실제 동작 흐름과 단계별 실행 방법

핵심 요약: 처음부터 고객 업무를 맡기지 말고, 입력·권한·출력 검수 단계를 고정한 작은 작업으로 시작해야 한다.

실제 도입 흐름은 다음처럼 잡는 편이 안전하다.

1. 작업 범위를 한 문장으로 제한한다. 예: “제품 로그 파일을 읽고 장애 후보를 표로 정리한다.”
2. 에이전트가 접근할 수 있는 파일과 도구를 최소화한다. 고객 원본 데이터, 결제 정보, 비밀 키는 첫 실험에서 제외한다.
3. AGENTS.md 또는 SKILL.md 형태의 지시문을 만든다. Google은 Managed Agents에서 markdown 기반 instructions와 skills를 언급한다. 즉 프롬프트 하나가 아니라 작업 매뉴얼을 등록하는 방식으로 보는 편이 맞다.
4. 첫 호출에서 환경을 만들고 작업을 실행한다. 이 단계에서는 결과보다 실행 로그와 파일 생성 위치를 확인한다.
5. 후속 호출에서 같은 환경을 이어받아 재개 가능성을 검증한다. 상태 재개가 안 되면 관리형 에이전트의 장점이 크게 줄어든다.
6. 사람 검수 게이트를 통과한 출력만 제품 화면에 반영한다. 프리뷰 단계에서는 자동 반영보다 승인 후 반영이 맞다.

간단한 작업 계약 예시는 아래처럼 쓸 수 있다.

{
  "task": "지난 24시간의 에러 로그를 원인 후보, 근거 로그, 재현 가능성, 다음 조치로 분류한다.",
  "allowed_files": ["logs/app-2026-05-22.txt"],
  "blocked_actions": ["외부 배포", "고객 데이터 삭제", "비밀 키 출력"],
  "definition_of_done": "표 형태 요약과 재현 명령어 초안을 만들고, 확실하지 않은 항목은 추정이라고 표시한다."
}

이 예시의 핵심은 에이전트를 똑똑하게 만드는 문장이 아니다. 무엇을 해도 되고, 무엇은 안 되고, 완료 기준이 무엇인지 먼저 고정하는 것이다.

7. 실수와 함정

핵심 요약: 실패는 모델 답변보다 권한, 상태, 비용, 검수 흐름에서 먼저 발생한다.

첫 번째 함정은 권한을 넓게 주는 것이다. 에이전트가 코드를 실행할 수 있다면 편하지만, 그만큼 잘못된 파일 수정이나 외부 호출도 가능해진다. 예방책은 읽기 전용 데이터부터 시작하고, 쓰기 권한은 작업별로 따로 여는 것이다. 문제가 생기면 해당 환경을 폐기하고 입력 파일만 다시 연결하는 복구 절차가 필요하다.

두 번째 함정은 상태 재개를 무조건 신뢰하는 것이다. 후속 호출에서 파일과 상태가 이어진다는 점은 장점이지만, 오래된 중간 결과가 다음 판단을 오염시킬 수 있다. 예방책은 각 작업마다 “이번 실행에서 유효한 파일”과 “참고만 할 파일”을 구분하는 것이다.

세 번째 함정은 비용을 채팅 API처럼 계산하는 것이다. 관리형 에이전트는 모델 토큰뿐 아니라 실행 시간, 도구 호출, 웹 탐색, 파일 작업이 함께 비용 구조에 영향을 줄 수 있다. 예방책은 작업당 최대 단계 수, 최대 실행 시간, 재시도 횟수를 먼저 정하는 것이다.

네 번째 함정은 결과를 곧바로 사용자에게 보여주는 것이다. 에이전트가 웹을 탐색하고 코드를 실행해도 사실 검증이 자동으로 끝나는 것은 아니다. 출처가 있는 주장, 실행 가능한 명령, 실패한 가정은 별도 표시해야 한다.

8. 강점과 한계

핵심 요약: 강점은 시작 속도이고, 한계는 운영 통제와 프리뷰 안정성이다.

가장 큰 강점은 인프라 시작 비용이다. 에이전트용 원격 Linux 환경, 파일 상태, 도구 실행, 후속 재개를 직접 만들려면 작은 팀에는 부담이 크다. Managed Agents는 이 부담을 줄여 제품 실험 속도를 높인다.

두 번째 강점은 Google 생태계와의 연결이다. I/O 발표에서 Google은 AI Studio, Android, Firebase, Workspace, Enterprise Agent Platform과의 연계를 강조했다. Google Cloud와 Android 앱 개발 흐름에 이미 들어가 있는 팀에는 도입 마찰이 낮을 수 있다.

한계도 분명하다. 첫째, Managed Agents는 발표 시점 기준 preview 성격이 강하다. 핵심 업무를 바로 맡기기보다 내부 워크플로에서 검증해야 한다. 둘째, 데이터 주권과 감사 로그가 중요한 산업에서는 관리형 실행 환경이 오히려 검토 항목을 늘릴 수 있다. 셋째, 에이전트가 할 수 있는 일이 많아질수록 제품 책임은 더 선명해야 한다. 사용자는 “Google 에이전트가 했다”가 아니라 “우리 서비스가 했다”고 받아들이기 때문이다.

따라서 금융, 의료, 법률, 고객 개인정보 처리처럼 규제가 강한 업무는 자체 샌드박스나 엔터프라이즈 계약 조건을 먼저 확인해야 한다. 반대로 내부 생산성 도구, 개발 보조, 리서치 자동화는 좋은 실험 후보가 될 수 있다.

9. 더 깊게 공부할 포인트

핵심 요약: 모델 문서보다 에이전트 계약, 도구 권한, 상태 관리 문서를 먼저 읽어야 한다.

초보 개발자는 먼저 “에이전트가 무엇을 기억하고 무엇을 실행하는가”를 구분해야 한다. 기억은 컨텍스트와 파일 상태이고, 실행은 도구 호출과 코드 실행이다. 둘을 섞어 이해하면 권한 설계가 흐려진다.

다음으로 볼 것은 Antigravity 계열 문서다. Antigravity는 Google이 에이전트 개발 환경 전체를 묶는 이름으로 쓰고 있다. Managed Agents만 따로 보지 말고, AI Studio, CLI, SDK, Enterprise Platform과 어떻게 연결되는지 함께 봐야 한다.

마지막으로 WebMCP 같은 웹 표준 흐름도 관찰할 필요가 있다. 웹사이트가 에이전트에게 구조화된 도구를 제공하는 방향으로 가면, 관리형 에이전트는 더 많은 외부 작업을 맡게 된다. 그때 중요한 것은 “연결할 수 있느냐”가 아니라 “승인과 철회가 가능한가”다.

10. 실행 체크리스트와 작성자 관점

핵심 요약: 도입 기준은 모델 성능표가 아니라 실패했을 때 멈출 수 있는 구조다.

• 이 작업이 실패했을 때 고객 피해 없이 되돌릴 수 있는가?
• 에이전트가 읽을 수 있는 파일과 쓸 수 있는 파일이 분리되어 있는가?
• 후속 호출에서 이어받을 상태와 버릴 상태를 구분했는가?
• 외부 웹 탐색 결과에 출처와 날짜를 남기는가?
• 최대 실행 시간, 최대 재시도 횟수, 최대 도구 호출 수를 정했는가?
• 사용자에게 보여주기 전 사람 또는 별도 검증 로직이 있는가?
• 비밀 키, 개인정보, 결제 정보가 실행 환경에 들어가지 않도록 막았는가?

Definition of Done: Managed Agents 실험은 “정답처럼 보이는 결과”가 아니라 “입력, 권한, 실행 로그, 출력 검수, 복구 절차가 한 번의 작업 기록으로 남을 때” 완료된 것으로 본다.

제 추천은 명확하다. Google Cloud나 AI Studio 흐름을 이미 쓰는 팀은 Managed Agents를 내부 자동화 파일럿으로 바로 테스트할 가치가 있다. 다만 고객 데이터가 들어가는 핵심 업무에는 아직 보수적으로 접근해야 한다. 에이전트 앱의 품질은 모델 이름보다 작업 경계의 선명도에서 갈린다.

참고자료

• Google Blog: Introducing Managed Agents in the Gemini API (2026-05-19)
• Google Blog: Building the agentic future, Developer highlights from I/O 2026 (2026-05-19)
• Google Blog: 100 things we announced at I/O 2026 (2026-05-20)
• Google AI for Developers: Gemini API Agents Overview
• Google AI for Developers: Interactions API documentation