Gemini API 관리형 에이전트의 4가지 핵심 업데이트

AI 에이전트에게 복잡한 코딩 작업이나 대규모 데이터 분석을 시키면 응답이 올 때까지 화면이 멈추거나 HTTP 연결이 끊기는 일이 잦다. 사용자는 작업 진행 여부를 알 수 없어 새로고침을 누르거나 앱을 강제 종료해야 하며, 이는 서비스 이탈로 이어진다. Google은 이러한 문제를 해결하기 위해 Gemini API의 관리형 에이전트 기능을 확장했다. 이번 업데이트는 백그라운드 실행, 원격 MCP 서버 통합, 커스텀 함수 호출, 자격 증명 갱신 기능을 통해 서비스 중단 가능성을 낮추는 데 집중했다.

관리형 에이전트는 단일 엔드포인트 호출만으로 추론부터 실행까지의 전 과정을 처리한다. 모델이 스스로 논리적 단계를 설계하고 코드를 작성해 실행하며, 필요한 소프트웨어 패키지를 설치하고 파일을 관리한다. 이 모든 과정은 외부 공격으로부터 시스템을 보호하고 세션별 일관성을 보장하는 격리된 클라우드 샌드박스(독립된 가상 실행 환경) 내에서 처리된다. 여기에 웹 정보 검색 기능이 통합되어 최신 외부 데이터를 수집하고 이를 샌드박스 내의 코드 실행 결과와 조합해 최종 답안을 도출한다. 개발자는 별도의 서버 인프라 구축 없이 API 호출만으로 완전한 실행 환경을 갖춘 에이전트를 운용할 수 있다.

코딩 에이전트를 구축하려는 개발자는 Interactions API 스킬을 설치해 해당 기능들을 즉시 적용할 수 있다. 샌드박스 내에서 직접 패키지를 설치하고 파일을 제어하는 환경 구축 단계가 간소화되어 구현 속도가 빨라졌다.

bash
npx skills add google-gemini/gemini-skills --skill gemini-interactions-api

이 명령어를 통해 Gemini API의 관리형 에이전트 환경을 설정하면 클라이언트의 응답 대기 시간을 없애고 서버가 작업을 완수할 때까지 상태를 추적하는 구조로 전환할 수 있다. 결과적으로 개발자는 애플리케이션의 메인 루프를 차단하지 않고도 실제 개발 환경 내에서 작동하는 고성능 비동기 에이전트를 서비스에 통합할 수 있다.

background: true로 구현하는 비동기 작업과 커스텀 함수

일반적으로 API 호출 시 서버의 응답이 올 때까지 연결을 유지하는 방식은 작업 시간이 길어질수록 네트워크 타임아웃이나 프록시 서버의 연결 끊김 현상에 취약하다. Google은 이를 해결하기 위해 `background: true` 옵션을 통한 서버 측 비동기 실행 구조를 도입했다. 이 옵션을 설정해 요청을 보내면 서버는 작업을 즉시 백그라운드 큐로 전환하고 호출자에게 작업 식별을 위한 고유 ID를 반환한다. 클라이언트는 이 ID를 사용해 작업 상태를 주기적으로 확인하는 폴링(Polling)을 수행하거나 진행 상황을 실시간 스트리밍으로 수신해 사용자에게 진행률을 보여줄 수 있다. 네트워크 문제로 연결이 끊기더라도 ID만 보존하고 있다면 나중에 다시 접속해 샌드박스에서 완료된 최종 결과물을 가져올 수 있다.

서버 내장 도구만으로는 접근할 수 없는 기업 내부의 비공개 데이터베이스나 특정 로컬 시스템 로직을 실행하기 위해 커스텀 함수 기능이 함께 제공된다. API는 서버에서 처리할 일과 클라이언트에서 처리할 일을 구분하는 단계 매칭(Step Matching) 메커니즘을 적용했다. 코드 실행이나 웹 정보 검색 같은 내장 도구는 서버의 샌드박스 환경에서 자동으로 수행된다. 반면 개발자가 정의한 커스텀 함수가 호출되어야 하는 시점이 되면 API는 상호작용 상태를 `requires_action`으로 전환하여 클라이언트에 통보한다. 신호를 받은 클라이언트는 로컬 환경에서 정의된 비즈니스 로직을 직접 실행하고 그 결과값을 다시 API로 전송한다. 이를 통해 보안상 민감한 로컬 자원 접근 권한을 개발자가 직접 제어할 수 있다.

이러한 비동기 제어와 커스텀 함수 호출 구조는 `@google/genai` JavaScript SDK를 통해 구현된다. 개발자는 SDK를 활용해 `background: true` 옵션과 커스텀 함수 정의를 포함한 상호작용 요청을 구성한다. 서버에서 즉시 반환되는 ID를 기반으로 상태 관리 로직을 설계하면 앱의 메인 UI 스레드를 차단하지 않고도 수 분에서 수 시간까지 걸리는 복잡한 추론과 실행 과정을 관리할 수 있다. 특히 `requires_action` 상태를 처리하는 이벤트 루프를 구현함으로써 서버의 자동화된 도구 실행 흐름 속에 클라이언트의 수동 제어 로직을 삽입하는 워크플로우를 구축할 수 있다.

MCP 서버 연결을 통한 외부 데이터 접근 방식의 변화

AI 모델이 외부 데이터에 접근하기 위해 개발자가 직접 구축해야 했던 프록시 미들웨어는 인증 처리와 데이터 필터링을 위해 필수적이었으나 유지보수 비용이 높았다. Google은 이를 해결하기 위해 Gemini API 관리형 에이전트에 MCP(Model Context Protocol) 서버 연결 기능을 추가했다. MCP는 AI 모델이 다양한 외부 데이터 소스나 도구에 표준화된 방식으로 접근할 수 있도록 정의한 규격이다. 이제 개발자는 복잡한 중계 서버를 직접 설계하지 않고도 표준 규격에 맞춘 서버를 통해 내부 데이터에 접근할 수 있다.

실제 구현 단계에서는 상호작용 시 `mcp_server` 도구를 전달하는 방식으로 작동한다. 관리형 에이전트는 샌드박스 내에서 외부 엔드포인트와 직접 통신한다. 개발자가 `mcp_server` 설정을 통해 대상 서버의 주소와 통신 규약을 지정하면, 에이전트는 추론 과정에서 필요한 데이터를 가져오기 위해 해당 서버에 요청을 보낸다. 데이터는 샌드박스라는 안전한 경계 내에서 처리되므로 로컬 환경에 복잡한 네트워크 설정을 추가하거나 보안 취약점을 노출할 위험을 줄일 수 있으며, 데이터 접근 경로가 단순해져 시스템 지연 시간이 감소한다.

원격 MCP 도구는 Gemini API가 기본으로 제공하는 내장 샌드박스 기능과 혼합하여 사용할 수 있다. 예를 들어 에이전트에게 Google 검색 기능, 코드 실행 도구, 기업 내부 DB에 연결된 MCP 서버를 동시에 제공하면, 에이전트는 내부 DB에서 매출 데이터를 가져오고 이를 코드 실행 도구로 분석한 뒤 Google 검색으로 업계 평균 수치와 비교하는 작업을 단일 워크플로우 내에서 수행한다. 서로 다른 출처의 도구들이 하나의 샌드박스 환경에서 유기적으로 결합되어 작동하므로, 개발자는 도구 간 데이터 전달을 위한 별도의 파이프라인을 설계할 필요가 없다.

결과적으로 개발자는 내부 DB 연결을 위해 매번 API 서버를 구축하고 인증 로직을 구현하는 대신, MCP 표준을 따르는 서버 하나로 여러 에이전트가 공유하게 만드는 구조를 취할 수 있다. 클라이언트 측에서 데이터 접근 권한을 일일이 제어하던 방식에서 벗어나, MCP 서버 단에서 권한을 관리하고 에이전트는 표준 인터페이스를 통해 결과값만 받는 구조로 전환이 가능하다.

운영 환경의 제약을 없앤 '비동기 워커'로의 진화

AI 에이전트가 수 시간 동안 코드를 수정하거나 대규모 데이터를 분석하는 장기 과업을 수행할 때 발생하는 주요 장애 지점은 인증 토큰의 만료다. Gemini API 관리형 에이전트는 기존 `environment_id`(환경 식별자)와 새로운 네트워크 설정을 함께 전달하여 만료된 액세스 토큰이나 API 키를 교체하는 자격 증명 갱신 기능을 지원한다. 새로운 네트워크 규칙을 전달하는 즉시 기존 설정을 대체하므로, 외부 API 통신 도중 인증 오류로 프로세스가 중단되는 현상을 방지한다. 개발자는 세션을 초기화하지 않고 필요한 인증 정보만 실시간으로 업데이트하며 작업의 연속성을 확보할 수 있다.

자격 증명을 갱신하는 과정에서 샌드박스 내부의 물리적 상태는 그대로 보존된다. 키를 교체한 이후에도 파일 시스템에 저장된 데이터, 설치 완료된 패키지, 외부에서 클론된 저장소(Repository)의 모든 내용이 유지된다. 예를 들어 에이전트가 수십 개의 라이브러리를 설치하고 소스 코드를 분석하던 중 API 키를 갱신하더라도, 다시 패키지를 설치하거나 저장소를 복제할 필요 없이 즉시 다음 단계의 코드를 실행할 수 있다. 에이전트가 샌드박스 내 파일과 패키지 상태를 유지하며 작업 맥락을 보존하기 때문에 복잡한 의존성을 가진 실제 개발 환경에서도 중단 없는 작업 흐름을 구성할 수 있다.

이러한 자격 증명 갱신과 상태 보존의 조합은 관리형 에이전트를 단순한 챗봇에서 비동기 워커(Asynchronous Worker)로 진화시킨다. 기존 챗봇 방식은 즉각적인 응답을 위해 HTTP 연결을 유지해야 했으나, 이제는 실제 개발 환경 내부에서 독립적으로 작동하는 백엔드 프로세스로 운용이 가능하다. 애플리케이션의 메인 인터페이스를 차단하지 않고도 서버 측에서 장시간의 빌드, 테스트, 배포 작업을 수행하는 에이전트를 배치할 수 있다. 이를 통해 클라이언트의 응답성을 해치지 않으면서도 백그라운드에서 복잡한 엔지니어링 과업을 완수하는 에이전트 기반의 워크플로우 구축이 가능해진다.

AI 에이전트에게 복잡한 코딩이나 대규모 데이터 분석을 시켰을 때 화면이 멈추거나 HTTP 연결이 끊기던 불편함은 이제 기술적 선택의 영역으로 옮겨갔다. background: true 옵션을 통한 비동기 폴링 방식과 mcp_server 도구의 외부 엔드포인트 연결 구조를 조합하면, 클라이언트의 응답성을 해치지 않고 내부 DB에 직접 접근하는 환경을 만들 수 있다.

개발자는 이제 프록시 미들웨어의 유지보수 비용을 감당할 것인지, 아니면 MCP 표준을 도입해 직접 연결 구조를 취할 것인지에 따라 에이전트 구현 전략을 결정하면 된다. 결국 AI 에이전트는 단순한 대화형 인터페이스를 넘어 백그라운드에서 독립적으로 과업을 완수하는 비동기 워커로 진화한다.