Google Cloud에서 배포하고 운영하기

실험 코드 다음에 오는 문제

앞 장에서 우리는 첫 A2A 에이전트를 작게 구현했다. Agent Card를 공개하고, Message를 받고, 필요하면 Task와 Artifact를 돌려주는 구조였다. 이 단계까지는 노트북, 로컬 서버, 간단한 샘플 코드만으로도 충분하다.

하지만 기업 환경에서는 질문이 곧바로 바뀐다.

이 에이전트를 누가 호출할 수 있는가. 어느 URL에서 발견되는가. Task 상태는 서버 재시작 후에도 남는가. 사용자가 늘어나면 자동으로 확장되는가. 장애가 났을 때 어디에서 로그와 추적 정보를 볼 수 있는가. 사내 사용자가 이 에이전트를 어디에서 찾아 쓸 수 있는가. 외부 고객에게 판매하려면 어떤 경로가 있는가.

Google Cloud가 제시한 A2A 도구 체계는 이 간격을 줄이기 위한 것이다. 핵심은 단순하다. A2A 프로토콜 자체는 특정 클라우드에 묶이지 않는 개방형 표준이지만, Google Cloud는 이를 실제 서비스로 만들기 위한 빌드, 배포, 운영, 배포 후 노출 경로를 한 묶음으로 제공한다. Google Cloud는 이 흐름을 ADK로 만들고, Cloud Run·Agent Engine·GKE로 배포하며, Agentspace와 Gemini Enterprise에서 사용자에게 제공하고, AI Agent Marketplace에서 발견과 판매로 연결하는 구조로 설명한다.¹

AI 생성 이미지

ADK: 기존 에이전트를 발견 가능한 A2A 에이전트로 만들기

Agent Development Kit, 줄여서 ADK는 에이전트를 만들기 위한 개발 도구다. 모델 호출, 도구 연결, 세션 처리, 에이전트 로직 구성을 개발자가 더 일관된 방식으로 다룰 수 있게 돕는다. A2A 관점에서 중요한 변화는 ADK가 A2A를 네이티브로 지원한다는 점이다. 즉, ADK로 만든 에이전트를 A2A Agent Card를 가진 원격 에이전트로 노출하거나, 다른 A2A 에이전트를 하위 에이전트처럼 사용할 수 있다.¹

이 말은 기존 에이전트의 내부 구조를 모두 바꾸라는 뜻이 아니다. 이미 ADK로 만든 고객지원 에이전트가 있다고 하자. 내부에는 Gemini 호출, CRM 조회, 정책 문서 검색, 답변 생성 로직이 들어 있을 수 있다. A2A를 적용할 때 바뀌는 핵심은 외부 계약이다.

• 이 에이전트가 어떤 일을 할 수 있는지 Agent Card로 설명한다.

• 외부 요청을 A2A Message 또는 Task로 받는다.

• 처리 중 상태를 Task 상태로 표현한다.

• 결과를 Artifact로 반환한다.

내부 추론 방식, 프롬프트, 도구 체인, 메모리 구조는 여전히 에이전트 안에 남는다. A2A는 그 내부를 표준화하지 않는다. 대신 다른 에이전트가 이 ADK 에이전트를 "발견하고 호출할 수 있는 원격 협업 주체"로 보게 만든다.

실무에서는 이 단계에서 Agent Card를 가장 먼저 점검해야 한다. 이름과 설명은 사람이 읽기 쉬워야 하고, skills는 호출자가 업무 적합성을 판단할 수 있을 만큼 구체적이어야 한다. url은 실제 배포 후 접근 가능한 엔드포인트와 일치해야 한다. 인증이 필요하다면 Agent Card에 보안 요구사항을 명확히 드러내야 한다.

Cloud Run: 컨테이너화된 A2A 서버를 서버리스로 배포하기

작게 시작하는 A2A 서버에는 Cloud Run이 잘 맞는다. Cloud Run은 컨테이너를 서버리스 방식으로 실행한다. 개발자는 애플리케이션을 컨테이너로 만들고 배포하면 되고, 인스턴스 수 조정, HTTPS 엔드포인트, 요청 기반 확장 같은 운영 부담은 플랫폼이 맡는다.

Google Cloud의 A2A on Cloud Run 구조에서 Cloud Run은 에이전트의 서비스 계층이자 오케스트레이션 계층이다. 이 계층은 Gemini나 Vertex AI 같은 모델, AlloyDB 같은 저장소, A2A TaskStore, 외부 API와 연결된다. 클라이언트는 이 Cloud Run 엔드포인트에 Agent Card 조회, Message 전송, Task 업데이트 수신 같은 요청을 보낸다.²

배포 흐름은 보통 다음 순서로 잡는다.

1. A2A 서버 코드를 준비한다.

2. 컨테이너가 8080 같은 포트에서 요청을 받을 수 있게 한다.

3. Google Cloud 프로젝트, 리전, 서비스 계정을 정한다.

4. TaskStore를 선택한다. 로컬 테스트는 인메모리로 충분하지만 운영 환경에서는 영속 저장소가 필요하다.

5. Cloud Run에 배포한다.

6. 배포된 외부 URL을 Agent Card의 url 또는 애플리케이션 설정값에 반영한다.

Cloud Run 배포 문서에서는 예를 들어 gcloud run deploy에 --source=".", --region, --project, --memory=1Gi, --service-account 같은 옵션을 사용한다. Vertex AI 기반 Gemini 사용을 위해 GOOGLE_GENAI_USE_VERTEXAI=true, 프로젝트와 리전 환경변수, 그리고 애플리케이션의 공개 주소를 나타내는 APP_URL을 설정하는 예도 제시한다.³

여기서 자주 생기는 실수는 Agent Card URL이다. 로컬에서는 http://localhost:8080으로 동작했더라도, Cloud Run 배포 후에는 https://...run.app 형태의 실제 서비스 주소가 생긴다. Agent Card가 여전히 로컬 주소를 가리키면 다른 에이전트는 이 서비스를 발견해도 호출할 수 없다. 배포 자동화에는 "Cloud Run 서비스 URL을 가져와 Agent Card 또는 APP_URL에 반영하는 단계"가 포함되어야 한다.

인증 방식도 배포 전에 결정해야 한다. 내부 Google Cloud 클라이언트나 Agentspace 같은 내부 사용자를 대상으로 한다면 Cloud Run IAM 인증을 사용하고, 호출자에게 roles/run.invoker 권한을 줄 수 있다. 이 경우 배포 시 공개 접근을 허용하지 않는 방식이 적합하다. 반대로 공개 A2A 서버로 운영한다면 Cloud Run 자체는 공개 접근을 허용하되, 에이전트 계층에서 OAuth2, API 키, 토큰 검증 같은 인증·인가를 처리하고 Agent Card의 securitySchemes와 security에 그 요구사항을 표현해야 한다.³

TaskStore도 운영 품질을 좌우한다. 인메모리 TaskStore는 샘플과 로컬 테스트에는 좋지만, 컨테이너 재시작이나 인스턴스 교체가 일어나면 상태가 사라진다. 장기 Task, 재조회, 감사 로그가 필요하다면 AlloyDB for PostgreSQL 같은 영속 저장소를 사용해야 한다. 특히 A2A는 비동기 협업을 전제로 하므로 "요청을 처리했다"보다 "요청 상태를 복구할 수 있다"가 더 중요하다.

Agent Engine: 에이전트 실행 환경을 운영층으로 끌어올리기

Cloud Run이 범용 컨테이너 실행 환경이라면, Vertex AI Agent Engine은 에이전트 운영에 더 초점을 둔 관리형 실행 환경으로 볼 수 있다. Google은 Agent Engine을 에이전트를 프로덕션에 배포하고, 관리하고, 확장하기 위한 환경으로 설명한다. 또한 Google Cloud 콘솔의 Agent Engine UI를 통해 배포된 에이전트, 세션, 추적 정보, 디버깅 정보, 메트릭을 중앙에서 볼 수 있도록 한다.⁴

A2A 관점에서 Agent Engine의 가치는 운영 단순화다. 에이전트는 단순 웹 API와 다르다. 한 요청 안에서 여러 모델 호출, 도구 호출, 메모리 조회, 정책 판단, 중간 상태 업데이트가 일어난다. 실패 원인도 "HTTP 500" 하나로 설명하기 어렵다. 어느 도구 호출이 실패했는지, 어떤 세션에서 문제가 반복되는지, 응답 지연이 모델 때문인지 외부 API 때문인지 확인할 수 있어야 한다.

Agent Engine을 사용하면 이런 운영 관심사를 에이전트 실행 환경의 일부로 다룰 수 있다. 특히 A2A 지원이 더해지면 특정 프레임워크로 작성된 에이전트만이 아니라 다양한 방식으로 만든 에이전트를 A2A 에이전트로 운영하는 경로가 열린다.¹ 다만 이것이 모든 설계를 대신해 준다는 뜻은 아니다. 권한 모델, Agent Card 품질, Task 상태 설계, 데이터 보존 정책은 여전히 개발 조직이 결정해야 한다.

GKE: 대규모 A2A 시스템에 필요한 제어권

모든 A2A 시스템이 서버리스만으로 충분한 것은 아니다. 수십 개의 전문 에이전트가 있고, 각 에이전트가 별도 배포 주기와 리소스 요구사항을 가지며, 네트워크 정책과 서비스 메시, 전용 노드풀, GPU 스케줄링, 커스텀 오토스케일링이 필요한 경우가 있다. 이런 환경에서는 Google Kubernetes Engine, 즉 GKE가 적합하다.

GKE 기반 패턴은 A2A 에이전트를 각각 독립 서비스로 배포하는 방식이다. 예를 들어 견적 에이전트, 계약 검토 에이전트, 재고 확인 에이전트, 결제 위험 평가 에이전트를 별도 Kubernetes Deployment로 운영한다. 각 서비스는 자신의 Agent Card 엔드포인트를 제공하고, 내부 호출은 Kubernetes 서비스 이름이나 내부 로드밸런서를 통해 처리한다. 외부 공개가 필요한 에이전트만 Gateway나 Ingress 뒤에 둔다.

이 구조의 장점은 제어권이다. 팀별 네임스페이스를 나누고, Network Policy로 에이전트 간 호출 범위를 제한하고, Workload Identity로 Google Cloud 리소스 접근 권한을 세분화할 수 있다. 또한 서비스 메시를 사용하면 mTLS, 트래픽 분할, 재시도 정책, 회로 차단 같은 네트워크 운영 정책을 더 정교하게 적용할 수 있다.

대신 복잡도도 함께 올라간다. A2A 프로토콜을 쓴다고 해서 Kubernetes 운영 문제가 사라지지는 않는다. 배포 전략, 이미지 보안, 롤백, 리소스 요청량, 클러스터 업그레이드, 관측 가능성은 별도로 설계해야 한다. 따라서 시작은 Cloud Run으로 하고, 조직이 더 강한 제어권과 대규모 멀티서비스 운영을 필요로 할 때 GKE로 확장하는 접근이 현실적이다. Google Cloud도 A2A 에이전트 배포 선택지로 Cloud Run, Agent Engine, GKE를 함께 제시한다.¹

Agentspace와 Gemini Enterprise: 사용자가 에이전트를 만나는 자리

배포는 끝이 아니다. 에이전트는 사용자가 발견하고 사용할 수 있어야 가치가 생긴다. Google Cloud의 설명에서 Agentspace는 "에이전트가 최종 사용자와 만나는 장소"에 가깝다. 현재 Agentspace는 Gemini Enterprise의 일부로 설명되며, 기업은 A2A 에이전트를 이 환경에 연결해 사용자가 웹 앱에서 사용할 수 있게 할 수 있다.¹

Gemini Enterprise 문서의 등록 흐름은 이 점을 구체적으로 보여 준다. 관리자는 Google Cloud 콘솔의 Gemini Enterprise 앱에서 Agents 메뉴로 들어가 "Custom agent through A2A"를 선택하고 Agent Card JSON을 입력한다. Agent Card에는 protocolVersion, name, description, url, version, capabilities, skills, defaultInputModes, defaultOutputModes 같은 정보가 들어간다. 등록이 끝나면 해당 A2A 에이전트는 Gemini Enterprise 웹 앱 사용자에게 제공될 수 있다.⁵

인증도 여기서 다시 중요해진다. 에이전트가 사용자 대신 Google Cloud 리소스에 접근해야 한다면 OAuth 2.0 클라이언트 정보, 인증 URI, 토큰 URI, 범위 설정이 필요할 수 있다. 반면 Cloud Run에서 IAM 기반 접근 제어를 사용하는 경우에는 별도의 OAuth 2.0 설정이 필요하지 않을 수 있다.⁵

또 하나의 현실적 주의점은 프로토콜 버전이다. Gemini Enterprise 문서는 A2A v0.3 스트리밍 지원과, A2A v1.0.0 이상을 사용할 때 호환 패키지를 고려해야 하는 상황을 언급한다.⁵ 운영자는 "우리 에이전트가 최신 명세를 구현했다"는 사실만 확인해서는 부족하다. 연결하려는 플랫폼이 어느 A2A 버전과 어떤 스트리밍 방식을 지원하는지 확인해야 한다.

Marketplace와 평가: 배포 이후의 경로

사내 업무용 에이전트라면 Gemini Enterprise나 Agentspace 등록이 자연스러운 다음 단계다. 외부 고객에게 제공하려는 에이전트라면 AI Agent Marketplace가 또 다른 경로가 된다. Google Cloud는 AI Agent Marketplace를 통해 고객이 독립 소프트웨어 벤더, 글로벌 시스템 통합사, 기술 제공자의 에이전트를 발견하고 구매할 수 있게 하겠다고 설명한다.¹

여기서 중요한 것은 판매 채널보다 운영 기준이다. 고객이 구매하는 것은 데모가 아니라 서비스다. Agent Card는 정확해야 하고, 인증과 권한은 명확해야 하며, 장애 대응과 지원 체계가 있어야 한다. Task 실패율, 응답 지연, 사용자 만족도, 보안 감사 로그도 관리되어야 한다.

Google Cloud는 Vertex GenAI Evaluation Service를 A2A 에이전트 평가로 확장하는 흐름도 제시한다.¹ 평가는 다음 장에서 더 자세히 다루겠지만, 여기서는 한 가지만 기억하면 된다. A2A 에이전트의 품질은 모델 답변만으로 평가할 수 없다. 올바른 에이전트를 선택했는지, Task 상태를 정확히 갱신했는지, input-required를 적절히 요청했는지, Artifact가 재사용 가능한 형태인지까지 함께 봐야 한다.

운영 전환 체크리스트

A2A 에이전트를 Google Cloud에 올릴 때는 다음 질문을 배포 기준으로 삼는 것이 좋다.

• Agent Card의 url이 실제 배포 엔드포인트와 일치하는가?

• 내부용이면 Cloud Run IAM 같은 플랫폼 인증을 쓸 것인가, 공개용이면 에이전트 계층 인증을 쓸 것인가?

• Task 상태가 컨테이너 재시작 후에도 복구되는가?

• 장기 작업의 스트리밍, 재조회, 취소, 실패 사유가 일관되게 처리되는가?

• Agent Engine, Cloud Run, GKE 중 현재 운영 복잡도에 맞는 배포 대상은 무엇인가?

• 사용자는 이 에이전트를 어디에서 발견하는가? Gemini Enterprise, Agentspace, 내부 포털, Marketplace 중 어느 경로인가?

• 평가와 관측 가능성 지표를 배포 전에 정의했는가?

Google Cloud의 A2A 툴킷은 프로토콜을 대신하지 않는다. 좋은 Agent Card, 안전한 권한 설계, 명확한 Task 생명주기는 여전히 필요하다. 다만 이 툴킷은 A2A 에이전트를 실험 코드에서 운영 가능한 서비스로 옮기는 데 필요한 길을 제공한다. 개발자는 ADK로 만들고, Cloud Run이나 Agent Engine 또는 GKE에 배포하고, Gemini Enterprise와 Agentspace에서 사용자에게 열고, 필요하면 Marketplace로 상용화할 수 있다.

이 흐름을 이해하면 A2A는 더 이상 명세 문서 속 객체 모델에 머물지 않는다. 실제 사용자와 다른 에이전트가 호출할 수 있고, 상태를 추적할 수 있으며, 조직의 운영 기준 안에서 관리되는 서비스가 된다.

참고

¹Announcing a complete developer toolkit for scaling A2A agents on Google Cloud

²Cloud Run의 A2A 에이전트 개요

³Cloud Run에 A2A 에이전트 배포

⁴What's new with Agents: ADK, Agent Engine, and A2A Enhancements

⁵A2A 에이전트 등록 및 관리