익숙한 상황입니다. 당신의 에이전트가 다단계 작업을 실행하고 있고, 당신은 HTTP 연결을 열어둔 채 로드 밸런서, 프록시 또는 클라이언트의 모바일 네트워크가 7분째에 연결을 끊지 않기를 기도하고 있습니다. 연결이 끊기면 에이전트의 모든 작업은 허공으로 사라집니다. 상태(state)가 단일 요청 내부에 존재했기 때문입니다.

2026년 7월 7일, Google은 바로 이 문제를 해결하는 Gemini API의 Managed Agents 확장을 발표했습니다. 이는 2026년 7월 7일자 Google 블로그에 언급된 내용입니다. 이제 장시간 소요되는 에이전트 작업을 비동기적으로 실행하고, 상호작용 식별자(interaction ID)를 받아온 뒤, 전체 실행 시간 동안 활성 연결을 유지하지 않고도 이를 폴링(polling)하거나 스트림(stream)을 구독할 수 있습니다. 여기에 더해, managed-аген트(managed agents)는 보호된 샌드박스(sandbox) 내에 머물면서 프라이빗 데이터베이스 및 내부 API를 위해 원격 MCP 서버에 직접 접속하는 법을 배웠습니다.

과도한 기대가 생기지 않도록 즉시 중요한 주의 사항을 말씀드립니다. 이것은 새로운 제품이 아닙니다. Google은 2026년 이전에 Managed Agents를 이미 선보였으며, 7월 7일의 업데이트는 기존 제품의 확장 기능입니다. 이제 무엇이 구체적으로 변했는지, 코드로 어떻게 구현되는지, 그리고 여전히 해결되지 않은 문제(sharp corners)는 무엇인지 부분별로 살펴보겠습니다.

7월 7일에 정확히 무엇이 변했나

핵심 사항. Google 블로그(2026-07-07)에 따르면, Managed Agents에는 두 가지 핵심 요소가 추가되었습니다: 백그라운드 실행 (Background Execution) 및 에이전트의 원격 MCP 서버 직접 연결입니다. 이 메시지의 나머지 내용은 이들을 둘러싼 맥락입니다.

사실과 제 결론을 혼동하지 않도록, 원문에서 확인된 목록을 정리해 보겠습니다:

1. Background Execution (백그라운드 실행)은 열린 HTTP 연결을 유지하지 않고 비동기적으로 장기적인 에이전트 작업을 실행하며, 이후 폴링(polling) 또는 스트리밍(streaming)을 위해 상호작용 ID를 반환합니다.
2. Managed Agents (관리형 에이전트)는 보호된 샌드박스(sandbox) 내에서 프라이빗 데이터베이스 및 내부 API에 접근하기 위해 원격 MCP 서버에 직접 연결할 수 있습니다.
3. MCP 외에도 코드 실행(code execution) 및 Google Search와 같은 내장 도구(built-in tools)를 사용할 수 있습니다.
4. 개발자는 샌드박스의 내장 도구와 함께 자신만의 함수를 추가할 수 있습니다. API는 단계 매핑(step mapping)을 사용하여 서버에서 내장 도구를 자동으로 실행합니다.
5. 자격 증명(credentials)은 새로운 네트워크 구성과 함께 현재의 environment_id를 전달하여 업데이트되며, 이때 샌드박스는 파일 시스템 상태와 설치된 패키지를 유지합니다.

이 모든 것은 별도의 서비스가 아니라 Gemini AI의 에이전트 기능 부분에 해당합니다. 이미 Managed Agents를 사용해 본 적이 있다면, 이번 업데이트는 기존 코드 위에 그대로 적용됩니다. 만약 처음이라면 아래 텍스트를 지도처럼 활용하되, 정확한 요청 스키마는 공식 문서를 통해 확인하십시오. 필드 이름은 예시 이미지와 다를 수 있습니다.

프로덕션 에이전트를 구축하면서 동일한 프롬프트에 대해 Gemini의 동작을 Claude나 GPT와 비교해야 한다면, 모든 모델에 대해 호환 가능한 엔드포인트(compatible endpoint) 하나를 곁에 두는 것만으로도 수 시간을 절약할 수 있습니다. 이 내용은 아래에서 다시 다루겠습니다 (provod.ai).

기존 방식도 작동했는데 왜 백그라운드 실행이 필요한가

핵심 요약. 에이전트가 작동하는 내내 연결을 열어두는 것은 단일 장애점(single point of failure)이 되며 실행 시간에 엄격한 제한을 둡니다. Background Execution은 이 연결을 끊어줍니다. 작업은 Google 서버에서 계속 실행되며, 클라이언트는 작업 ID만 받아 상태를 폴링(polling)하기만 하면 됩니다.

이전의 전형적인 에이전트 호출은 하나의 긴 동기식(synchronous) 요청 형태였습니다. 에이전트가 생각하고, 도구를 호출하고, 다시 생각하는 동안 당신은 소켓(socket)을 계속 유지해야 했습니다. 이로 인해 다음과 같은 전형적인 오류들이 발생했습니다:

• API 게이트웨이(API gateway), 리버스 프록시(reverse proxy) 또는 서버리스 플랫폼(serverless platform) 측의 타임아웃 (많은 플랫폼이 요청 지속 시간에 엄격한 제한을 두고 있습니다).
• 모바일 클라이언트 및 불안정한 네트워크에서의 연결 끊김.
• 긴 에이전트 호출(agent calls)이 유지되는 동안 서비스를 안정적으로 재시작하거나 배포(deploy)를 진행할 수 없음.
• 계산 작업은 하지 않고 단순히 응답을 기다리며 대기하는 비용이 많이 드는 유휴 워커(idle workers).

Google의 설명에 따르면, 백그라운드 모드는 이러한 연결을 유지해야 할 필요성을 제거합니다. 작업을 보내고 상호작용 ID(interaction ID)를 받은 다음, 타이머를 통해 상태를 폴링(polling)할지 또는 이벤트 스트림(event stream)을 구독할지를 직접 결정하면 됩니다. 클라이언트가 종료되었다가 다시 실행되어도 작업은 계속 유지됩니다.

개념적으로는 다음과 같습니다 (2026-07-07 Google 블로그의 설명을 바탕으로 한 의사코드이며, 정확한 필드는 문서(documentation)를 참조하십시오):

# 긴 동기식 호출(synchronous call) 대신 백그라운드에서 작업 실행
resp = client.agents.run(
    agent="managed-agent",
...

그 후 두 가지 경로가 있습니다. 타이머를 이용한 폴링:

import time

while True:
...

또는 실시간 진행 상황이 필요한 경우 스트림 구독:

for event in client.agents.stream(interaction_id):
    print(event.type, event.data)

주의하십시오: 여기에 사용된 메서드(method)와 필드(field)의 이름은 예시일 뿐입니다. 원문에서 확실하게 알려진 사실은 단 하나입니다. 즉, 모드는 비동기(asynchronous) 방식이며, ID가 반환되고, 해당 ID를 통해 폴링과 스트리밍이 가능하다는 점입니다. 그 외의 모든 사항은 프로덕션(production)에 적용하기 전에 반드시 문서를 통해 확인하십시오.

managed-agent가 원격 MCP 서버에 접속하는 방식 및 액세스 권한 업데이트 방법

핵심 사항. 두 번째 주요 변경 사항은 Gemini 샌드박스(sandbox) 내부의 에이전트가 사용자의 원격 MCP 서버에 연결하여, 이를 통해 프라이빗 데이터베이스 및 내부 API로부터 데이터를 가져올 수 있다는 점입니다. 액세스 권한 업데이트는 새로운 네트워크 구성과 함께 현재의 environment_id를 전달하는 방식으로 이루어지며, 이 과정에서 샌드박스의 파일 시스템과 설치된 패키지는 그대로 유지됩니다.

MCP (Model Context Protocol)는 모델에 도구 및 데이터에 대한 표준화된 인터페이스를 제공하는 방식입니다. 업데이트 이전에는 사용자의 측면에 MCP 클라이언트가 있는 방식이 일반적이었습니다. 즉, 에이전트가 도구를 요청하면 사용자가 직접 MCP에 접속하여 결과를 컨텍스트(context)로 반환하는 구조였습니다. 하지만 Google 블로그에 따르면, 이제 managed-agent가 샌드박스에서 원격 MCP 서버로 직접 연결됩니다. 이를 통해 모델과 사용자의 내부 시스템 사이의 불필요한 중개 계층을 제거할 수 있습니다.

프라이빗 데이터에 대한 실질적인 의미는 다음과 같습니다. 에이전트가 사용자의 데이터베이스나 내부 API에 접근할 때, 사용자가 직접 공용 인터넷을 통해 수행하는 것이 아니라 사용자가 설정한 구성을 통해 보호된 환경에서 접근하게 됩니다. 여기서 자격 증명(credentials) 로테이션 메커니즘이 필요하게 됩니다.

소스의 6번 항목을 바탕으로 액세스 권한 업데이트를 살펴보겠습니다. 아이디어는 다음과 같습니다. 샌드박스에는 environment_id가 있습니다. 자격 증명이나 네트워크 구성을 변경해야 할 때(예: MCP 서버 토큰 로테이션), 현재의 environment_id를 새로운 네트워크 구성과 함께 전달합니다. 그러면 샌드박스는 새로운 권한으로 전환되지만, 상태(state)를 잃지 않습니다. 즉, 파일과 이미 설치된 패키지는 그대로 유지됩니다.

# 샌드박스 상태를 유지하며 자격 증명 로테이션 수행
# (2026-07-07 Google 설명 기준; 정확한 스키마는 문서 참조)
updated = client.agents.update_environment(
...

⚠️ MCP 서버 토큰 및 프라이빗 데이터베이스에 대한 모든 자격 증명은 비밀 정보(secrets)입니다. 코드에 하드코딩하거나 git에 올리지 마세요. 비밀 관리자(secret manager)에 보관하고 환경 구성에 실시간으로 주입하여 사용하십시오. 상태를 유지하면서 수행하는 로테이션은 바로 이러한 값들을 정기적이고 저렴하게 변경하기 위해 존재합니다.

내장 도구(Built-in tools)에 대해 별도로 설명하겠습니다. 소스에 따르면 에이전트는 서버에서 직접 코드 실행(Code execution) 및 Google 검색(Google Search)을 수행할 수 있으며, 사용자 정의 함수(Custom functions)는 이들과 함께 존재합니다. API는 단계 매핑(Step mapping)을 사용하여 내장 도구를 자동으로 실행합니다. 실질적인 결과는 다음과 같습니다. 사용자가 함수를 정의하면, 에이전트의 단계에서 필요할 때 코드 러너(Code-runner) 호출이나 API 검색을 시스템이 알아서 처리합니다. 즉, 사용자 측면에서의 수동 오케스트레이션(Manual orchestration)이 줄어듭니다.

에이전트용 모델 선택 방법 및 비용 관련 사항

핵심 사항. 7월 7일 Google의 발표에는 가격이나 새로운 제한 사항(Limits)이 포함되어 있지 않으며, 오직 기능(Functionality)에 대해서만 다루고 있습니다. 따라서 모델과 예산에 대한 결정은 발표된 약속이 아니라, 자신의 작업에 대한 직접적인 측정값을 바탕으로 내려야 합니다.

소스에 명시되지 않은 부분에 대해 솔직히 말씀드리자면, 구체적인 요금제, 백그라운드 실행(Background execution) 할당량(Quotas), 또는 동시 에이전트 수에 대한 제한은 언급되지 않았습니다. 이와 관련된 수치를 임의로 추측하지 않겠습니다. 현재 확인 가능한 것은 기능의 집합입니다. 즉, 에이전트 비용은 에이전트가 수행하는 단계의 수, 내장 도구 및 MCP를 호출하는 빈도, 그리고 작업에 따라 어떤 Gemini 제품군 모델을 선택하느냐에 따라 결정됩니다.

선택을 위한 실무적인 프레임워크는 다음과 같습니다:

마지막 줄은 프로덕션(Production)에 적용하기 전에 눈대중으로 추정하지 말고, 파일럿을 실행하여 실제 소비량을 측정해야 한다는 점을 강조합니다.

이곳에는 러시아 시장을 위한 정직한 통합 방식도 있습니다. Gemini AI는 당신이 에이전트(Agent)에 적용해 볼 유일한 모델이 아닐 가능성이 높습니다. 종종 동일한 작업을 Gemini, Claude, GPT, DeepSeek 및 Qwen이 어떻게 해결하는지 비교해야 하며, 그 후에 모델 제품군(Families) 간에 요청을 라우팅(Routing)해야 할 때가 있습니다. 러시아 플랫폼인 provod.ai는 이러한 모델들을 하나의 채팅에 모으고 OpenAI 및 Anthropic SDK와 호환되는 단일 API를 제공합니다. 즉, 키(Key)와 base_url만 변경하면 익숙한 클라이언트를 통해 다양한 모델을 사용할 수 있습니다. 결제 방식 또한 루블화로 균형을 맞추어, VPN이나 해외 카드 없이 러시아 카드, SBP(Fast Payment System) 또는 계좌 이체를 통해 결제할 수 있습니다. 응답을 비교하고 모델 제품군 간에 라우팅을 수행하는 데 있어, 이는 각 벤더(Vendor)별로 별도의 통합을 구축하는 것보다 훨씬 빠릅니다.

오해를 방지하기 위한 중요한 경계선이 있습니다. 관리형 에이전트(Managed Agents), 백그라운드 실행 및 샌드박스(Sandbox)에서의 MCP 직접 연결은 Google의 Gemini API 자체 기능입니다. 서드파티(Third-party) 호환 API는 단일 클라이언트를 통해 모델을 비교하고 제품군 간에 호출을 라우팅해야 하는 경우에 도움을 줍니다. 이는 Google의 관리형 에이전트를 대체하는 것이 아니며, GigaChat을 제공하는 것도 아닙니다.

호환 엔드포인트(Compatible Endpoint)로 클라이언트를 전환하는 모습의 미니 예시 (OpenAI SDK):

from openai import OpenAI

client = OpenAI(
...

빈번한 오류와 n8n과 연동하여 이를 포착하는 방법

핵심. 백그라운드 모드는 연결 끊김을 제거하지만, 고유한 오류 클래스를 추가합니다: 유실된 ID, 멈춘 상태(Status), 만료된 MCP 자격 증명(Credentials) 등입니다. 이러한 오류들은 사전에 처리 로직에 반영되어야 합니다.

전형적인 실수 사례와 그에 대한 대처법을 정리했습니다:

• interaction_id 분실. 작업(task)은 서버에서 실행 중인데 ID가 유일한 접근 키라면, ID를 잃는 순간 결과에 대한 접근 권한도 잃게 됩니다. 다른 로직을 수행하기 전, 실행 직후 즉시 ID를 데이터베이스(DB)에 저장하세요.
• 영원히 지속되는 running 상태. 시간 제한이 없는 폴링(Polling)은 무한 루프가 됩니다. 최대 데드라인(deadline)을 설정하고, 해당 시간에 도달했을 때의 동작을 정의하세요.
• 너무 빈번한 폴링. 공격적인 폴링은 API 할당량(limits)과 비용에 타격을 줍니다. 합리적인 간격으로 시작하여, 작업 시간이 경과함에 따라 간격을 늘려가세요.
• 작업 도중 MCP 토큰 만료. 이를 위해 environment_id를 통한 로테이션(rotation)이 존재합니다. 자격 증명(credentials)을 업데이트하더라도, Google의 설명에 따라 샌드박스(sandbox) 상태(파일 및 패키지)는 유지됩니다.
• 코드 내 사실과 추측의 혼재. 기술 블로그 등에 나온 예시용 필드 이름에 의존하지 마세요. 프로덕션(production) 환경에 적용하기 전, 반드시 공식 문서(official documentation)를 통해 스키마(schema)를 확인하세요.