Gemini Enterprise Agent Platform: Agent Registry·Gateway·A2A로 완성한 에이전트 수명주기 관리

Google Cloud Next '26에서 구글은 Vertex AI를 사실상 계승하는 통합 플랫폼인 Gemini Enterprise Agent Platform을 GA(일반 공급) 발표하며 엔터프라이즈 에이전트 시장에 본격 진입했다. 이 플랫폼은 Agent Studio, A2A(Agent-to-Agent) 오케스트레이션, Agent Registry, Agent Gateway 등 에이전트 빌드·배포·운영·거버넌스의 전 주기를 단일 플랫폼에서 처리하도록 설계됐으며, Anthropic Claude를 포함한 200개 이상의 모델을 기본 지원한다.

모델 서빙 플랫폼이 에이전트 운영 플랫폼으로 넘어간 이유

Vertex AI는 지난 수년간 구글의 엔터프라이즈 ML 플랫폼으로서 모델 학습, 파인튜닝, 배포, MLOps 파이프라인을 담당해 왔다. 그러나 AI 패러다임이 단순 모델 추론에서 에이전트 기반 자율 실행으로 이동하면서 Vertex AI의 아키텍처는 새로운 요구 사항을 소화하는 데 한계를 드러내기 시작했다. 에이전트는 단일 추론 결과를 반환하는 것이 아니라 도구를 호출하고, 여러 스텝에 걸쳐 계획을 수행하고, 다른 에이전트와 협력하며, 장기 컨텍스트를 유지해야 한다. 이를 위한 인프라는 전통적인 ML 파이프라인과 본질적으로 다르다.

Gemini Enterprise Agent Platform은 이 간극을 메우기 위해 설계된 차세대 플랫폼이다. Vertex AI가 제공하던 모델 관리, 데이터 커넥터, MLOps 기능을 흡수하면서 에이전트 특화 인프라인 Agent Registry, Agent Gateway, A2A 오케스트레이션 레이어를 추가했다. 기존 Vertex AI 기반 워크로드는 마이그레이션 없이 새 플랫폼에서 계속 실행되며, 신규 에이전트 워크로드는 강화된 에이전트 인프라 위에서 구동된다. 이 플랫폼에 "Gemini"라는 이름이 붙은 것은 단순한 브랜딩이 아니다 — Gemini 모델 패밀리가 플랫폼의 기본 오케스트레이터 역할을 하고, 다른 모델들은 이 프레임워크 안에서 특화 태스크를 수행하는 전문 에이전트로 위치한다. 구글이 멀티 모델 에이전트 시장에서 오케스트레이션 레이어를 장악하려는 전략으로 읽힌다.

⤢✕

각 구성 요소는 독립적으로 사용할 수도 있지만, 함께 사용할 때 엔터프라이즈 에이전트 운영의 전 주기를 커버하는 통합 인프라가 완성된다. 개발자는 Agent Studio에서 에이전트를 설계하고, Agent Registry에 등록하며, Agent Gateway로 보안 정책을 적용하고, A2A 오케스트레이션으로 복잡한 멀티 에이전트 워크플로우를 실행한다.

카탈로그와 게이트웨이가 잡는 수명주기

엔터프라이즈에서 에이전트 수가 수십 개를 넘어서면 가장 먼저 부딪히는 문제는 에이전트 발견(discovery)과 버전 관리다. 어떤 에이전트가 존재하는지, 무엇을 할 수 있는지, 현재 어떤 버전이 프로덕션에 배포되어 있는지를 파악하기 어려워진다. Agent Registry는 이 문제를 풀기 위한 조직 전체 에이전트 카탈로그다.

Agent Registry는 각 에이전트의 기능 설명, 입출력 스키마, 지원 모델, 의존성, 소유 팀, 배포 환경, SLA 요건을 체계적으로 저장한다. 이 메타데이터는 사람이 에이전트를 검색하고 재사용 가능한 에이전트를 발견하는 데, 그리고 오케스트레이터 에이전트가 특정 태스크에 적합한 하위 에이전트를 자동으로 선택하는 데 쓰인다. 버전 관리 측면에서는 Git과 유사한 에이전트 버전 이력을 관리한다. 각 버전은 불변(immutable) 스냅샷으로 저장되며, 프로덕션 배포 버전과 개발 중인 버전이 명확히 구분되고, 배포 검토와 롤백을 위한 버전 비교 기능도 제공되어 업데이트 시 이전 버전과의 동작 차이를 확인할 수 있다. 거버넌스 관점에서는 에이전트의 승인 상태를 추적해, 조직이 사용 승인한 에이전트만 프로덕션 환경에서 실행 가능하도록 정책을 설정할 수 있으며 승인되지 않은 에이전트 사용 시도는 자동으로 차단되고 감사 로그에 기록된다 — 조직이 인지하지 못하는 AI 에이전트 사용, 즉 그림자 AI(shadow AI) 문제를 막는 핵심 메커니즘이다.

Agent Gateway는 에이전트에 대한 모든 요청과 에이전트에서 발생하는 모든 호출이 통과하는 단일 제어 포인트다. API 게이트웨이가 마이크로서비스 아키텍처에서 맡는 역할을 에이전트 아키텍처에서 Agent Gateway가 담당한다. 보안 측면에서는 어떤 사용자·시스템이 어떤 에이전트를 호출할 수 있는지 정의한 정책을 적용하며 OAuth 2.0, OIDC, API 키 등 다양한 인증 메커니즘을 지원한다. 에이전트가 외부 도구·API를 호출할 때도 Gateway가 자격증명 관리를 대행해, 에이전트 코드에 직접 시크릿을 포함시킬 필요가 없다. 정책 적용 측면에서는 프롬프트 필터링, 출력 스크리닝, 콘텐츠 안전 정책을 실시간으로 적용하며, PII·기밀 데이터 유출을 막는 DLP 규칙을 에이전트 레벨이 아닌 Gateway 레벨에서 일괄 적용해 각 에이전트가 개별적으로 보안 로직을 구현해야 하는 분산 보안 모델의 일관성 문제를 해결한다. 라우팅·부하 분산 측면에서는 요청 패턴, 에이전트 부하, 지리적 위치, 비용 최적화 목표에 따라 요청을 적절한 에이전트 인스턴스로 라우팅하고, 트래픽 급증 시 자동 스케일링과 연계해 에이전트 풀을 동적으로 조정하며 응답 불가 상태인 에이전트는 대체 에이전트로 자동 장애 조치한다.

Agent Card로 능력을 알리고 Task API로 진행을 추적하는 A2A

A2A(Agent-to-Agent) 프로토콜은 구글이 개발한 에이전트 간 통신 표준으로, 서로 다른 프레임워크로 만들어진 에이전트가 상호 운용될 수 있도록 설계됐다. HTTP/HTTPS 기반의 JSON-RPC 형식으로 동작하며, 에이전트의 기능을 기술하는 Agent Card 스펙과 태스크 생명주기를 관리하는 Task API로 구성된다.

Agent Card는 에이전트의 자기 기술(self-description) 문서다. 에이전트가 지원하는 작업의 종류, 입력 스키마, 출력 형식, 인증 요건, 스트리밍 지원 여부가 표준화된 JSON 형식으로 기술된다. 오케스트레이터 에이전트는 하위 에이전트의 Agent Card를 읽어 해당 에이전트에게 태스크를 위임할 수 있는지, 어떤 형식으로 요청해야 하는지를 동적으로 판단한다. 사전에 모든 에이전트 인터페이스를 하드코딩할 필요 없이 런타임에 에이전트 능력을 발견하고 활용할 수 있다는 뜻이다.

Task API는 에이전트에게 작업을 요청하고 진행 상황을 추적하며 결과를 수신하는 표준 인터페이스다. 태스크는 submitted → working → completed 또는 failed 상태를 거치며, 중간 진행 상황을 스트리밍으로 수신하거나 완료 시 콜백을 받을 수 있다. 장기 실행 태스크는 폴링(polling) 방식으로 상태를 확인할 수 있어, 오케스트레이터가 여러 하위 에이전트의 태스크를 병렬로 관리하는 것이 구조적으로 자연스럽다.

⤢✕

멀티 에이전트 시스템에서 가장 중요한 설계 결정 중 하나는 컨텍스트를 어떻게 공유하느냐다. 모든 에이전트가 전체 컨텍스트를 보유하면 토큰 비용이 급증하고, 컨텍스트를 과도하게 분할하면 필요한 정보를 갖지 못해 품질이 떨어진다. A2A는 이 문제를 두 가지 메커니즘으로 접근한다. 구조화된 아티팩트 공유는 에이전트가 대화 히스토리 전체를 다음 에이전트에게 전달하는 대신, 태스크 수행에 필요한 핵심 정보를 구조화된 아티팩트(JSON, 표, 코드 등)로 추출해 전달하는 방식이다. 공유 컨텍스트 저장소는 복잡한 멀티 스텝 워크플로우에서 여러 에이전트가 공통 참조 공간을 쓸 수 있도록 세션 단위 저장소를 지원해, 에이전트 간 직접 전달이 아닌 중앙 저장소를 통해 관리하므로 에이전트 간 의존성이 낮아지고 병렬 실행이 쉬워진다. 결과 집계는 오케스트레이터 에이전트의 핵심 역할로, 병렬 실행된 여러 하위 에이전트의 결과를 수집하고 결과 간 충돌을 해결하며 최종 응답을 합성한다.

프로덕션 멀티 에이전트 시스템에서 개별 에이전트의 실패는 예외가 아닌 일상이다. 네트워크 타임아웃, 모델 오류, 도구 호출 실패, 예상치 못한 출력 형식 등 다양한 원인으로 에이전트 태스크가 실패할 수 있고, 내결함성 설계는 이런 실패를 시스템 전체의 실패로 전파하지 않도록 격리하고 복구하는 것이 목표다. A2A는 태스크 레벨의 재시도 정책을 기본 지원해, 각 태스크에 대해 최대 재시도 횟수·재시도 간격(지수 백오프)·재시도 가능한 에러 유형을 명시적으로 지정할 수 있다. 재시도가 모두 소진되면 태스크는 failed 상태로 전환되고 오케스트레이터는 대체 에이전트를 쓰거나 사람에게 에스컬레이션하는 대응 전략을 실행한다. 부분 실패 처리도 중요한 설계 고려 사항이다 — 병렬 실행 중인 10개의 하위 에이전트 중 2개가 실패했을 때 시스템 전체를 실패 처리할지 8개의 성공 결과로 부분 응답을 반환할지를 오케스트레이터가 제어할 수 있어, 완전한 정보 대신 신속한 응답을 선택할 수 있는 유연성을 준다.

200개 이상 모델을 벤더 중립으로 굴리는 방식

Gemini Enterprise Agent Platform이 200개 이상의 모델을 지원한다는 것은 여러 모델에 API를 연결한다는 의미가 아니다. 플랫폼 수준에서 모델 선택, 폴백(fallback), 비용 최적화, 성능 모니터링이 통합 관리된다는 뜻이다.

⤢✕

모델 선택 로직은 태스크 특성(추론 복잡도, 컨텍스트 길이, 응답 시간 요건), 비용 예산, 규제 요건(데이터 거주지 제한, 특정 모델 사용 의무)을 고려해 동작한다. 개발자는 에이전트 코드에서 특정 모델을 하드코딩하는 대신, 플랫폼의 모델 라우팅 정책에 태스크 요건을 기술하고 최적 모델 선택을 플랫폼에 위임할 수 있다. 이 아키텍처의 핵심 이점은 모델 전환 비용의 최소화다 — 특정 모델이 성능 저하·비용 급등·서비스 중단 상황에 처했을 때, 에이전트 코드 수정 없이 플랫폼 정책 변경만으로 대체 모델로 전환할 수 있다. 단일 모델 벤더에 대한 의존성은 협상력 약화, 서비스 중단 리스크, 비용 통제 불가 같은 문제를 유발하는데, 멀티 모델 아키텍처는 이런 벤더 락인(vendor lock-in) 리스크를 구조적으로 완화한다.

구글이 자사 모델 외에 Anthropic Claude, Meta Llama, Mistral을 기본 지원 모델로 포함한 것은 눈여겨볼 전략적 결정이다. 이는 플랫폼의 주된 가치가 특정 모델이 아니라 에이전트 인프라와 오케스트레이션에 있다는 포지셔닝을 명확히 한다. Claude 모델은 특히 장문 문서 분석, 코드 리뷰, 복잡한 추론이 필요한 태스크에서 Gemini 모델을 보완하는 역할로 자리잡는다. Claude 3.7 Sonnet과 Claude Opus 4의 200K 토큰 컨텍스트 윈도우는 대용량 문서 처리 에이전트에서 강점을 발휘하며, 이 플랫폼에서 Claude 모델은 Vertex AI에서 이미 제공하던 Model Garden을 통해 통합되고 API 호출 방식과 인증 관리가 Gemini 모델과 동일한 방식으로 처리된다. Llama 모델은 온프레미스 또는 전용 클라우드 환경 배포 요건이 있는 고객을 위한 선택지다. 금융, 의료, 국방 분야에서는 특정 데이터가 외부 모델 API로 전송되는 것을 규정상 허용하지 않는 경우가 있는데, 이런 환경에서는 Llama 모델을 자체 인프라에 배포하고 플랫폼의 오케스트레이션 레이어만 쓰는 하이브리드 구성이 가능하다. Mistral 모델은 유럽 데이터 주권 요건을 충족해야 하는 고객에게 적합하다. GDPR 및 EU AI Act 준수 요건을 가진 유럽 기업들은 데이터 처리 위치와 모델 제공사의 법적 소재지에 민감한데, 프랑스 기반의 Mistral은 이 요건을 충족하는 대안을 제공한다.

벤더 중립 거버넌스는 특정 모델 벤더의 정책 변화, 가격 인상, 서비스 중단이 기업의 에이전트 운영에 미치는 영향을 최소화하는 것이 목표다. 플랫폼의 거버넌스 레이어는 모델을 추상화해, 정책이 모델 특정적이 아닌 태스크·에이전트 특정적으로 정의되도록 한다. 구체적으로 에이전트 정책은 "Gemini 2.5 Pro를 사용하라"가 아니라 "추론 복잡도 높음, 최대 지연 5초, 월 예산 500달러 이하 모델을 사용하라"의 형태로 정의되며, 이 요건을 충족하는 모델이 변경되거나 더 나은 모델이 등장해도 에이전트 정책은 변경할 필요가 없다. 비용 거버넌스 측면에서 플랫폼은 에이전트별·팀별·프로젝트별 모델 사용 비용을 실시간으로 추적하고, 예산 한도 초과 시 자동으로 더 저렴한 모델로 전환하거나 에이전트 실행을 제한하는 정책을 지원한다 — 에이전트 AI 도입에서 흔히 발생하는 예상치 못한 비용 급증 문제를 사전에 통제할 수 있다.

도입 전에 확인할 것들

Gemini Enterprise Agent Platform의 도입을 검토하는 조직이 직면하는 첫 질문은 기존 Vertex AI 워크로드의 마이그레이션 부담이다. 구글은 신규 플랫폼이 Vertex AI를 계승하므로 기존 워크로드를 마이그레이션 없이 그대로 실행할 수 있다고 발표했지만, 새로운 Agent Registry·Agent Gateway·A2A 오케스트레이션의 이점을 활용하려면 기존 에이전트 아키텍처를 부분적으로 재구성해야 하는 경우가 생길 수 있다.

비용 구조에 대한 이해도 중요하다. 플랫폼은 에이전트 실행에 따른 기본 모델 비용 외에 Agent Registry, Agent Gateway, 오케스트레이션 레이어 사용에 대한 추가 비용이 발생한다. 에이전트 수가 적고 호출 빈도가 낮은 초기 단계에서는 이 추가 비용이 상대적으로 크게 느껴질 수 있으며, 에이전트 수가 증가하고 거버넌스·운영 자동화의 가치가 실현되는 규모에서 비용 효율성이 높아지는 구조다.

데이터 거주지 요건을 가진 조직은 특정 에이전트 구성 요소가 어느 지역(region)에서 실행되는지 검토해야 한다. Agent Gateway와 Agent Registry가 특정 지역에 배포될 수 있는지, A2A 오케스트레이션 중 컨텍스트 데이터가 지역 경계를 넘어 전송되는지를 구글 Cloud 공식 문서와 계약 조건으로 확인해야 한다. 보안팀 관점에서는 Agent Gateway의 정책 설정을 조직의 기존 보안 정책과 통합하는 작업이 필요하다. 기존 IAM(Identity and Access Management) 체계와 Agent Gateway의 에이전트별 접근 제어를 연계하고, SIEM(Security Information and Event Management) 시스템에 에이전트 감사 로그를 통합하는 것이 프로덕션 배포 전에 설계되어야 한다.

Gemini Enterprise Agent Platform은 에이전트 빌드 도구를 넘어 에이전트 인프라 자체를 표준화하려는 구글의 야심 찬 시도다. Agent Registry와 Agent Gateway가 제공하는 중앙화된 에이전트 거버넌스, A2A 프로토콜이 가능하게 하는 에이전트 간 표준 통신, 200개 이상 모델을 아우르는 벤더 중립 전략은 엔터프라이즈 AI 에이전트 운영의 고질적 문제들을 플랫폼 수준에서 풀려는 시도로 읽힌다. GA 출시 이후 실제 엔터프라이즈 워크로드에서의 성능과 비용 효율성 검증이 이 플랫폼의 성패를 가를 것이며, 특히 A2A 프로토콜이 업계 표준으로 자리 잡을 수 있을지가 장기적인 생태계 확장의 핵심 변수가 될 것이다.