구글 클라우드가 AI 에이전트를 위한 인프라의 빈틈을 두 방향에서 메우고 있다. 하나는 어떤 데이터베이스를 선택하고 운영할지에 필요한 수작업이고, 다른 하나는 일반적인 웹 요청이 없어도 계속 실행돼야 하는 에이전트를 어디에서 호스팅할지에 관한 문제다.

2026년 8월 구글 클라우드는 Gemini Cloud Assist에 통합된 Database Operations Agents를 선보였다. 이어 8월 28일에는 장시간 실행되는 상태 저장형 워크로드를 위한 Cloud Run instances를 프리뷰로 공개했다. 데이터 계층과 컴퓨팅 계층을 동시에 에이전트 중심으로 바꾸려는 움직임이다. 2411

데이터베이스 운영 에이전트, 구축부터 유지보수까지

Database Operations Agents는 구글 클라우드의 Agentic Data Cloud 전략 아래 소개됐다. 역할은 비교적 명확하다. Database Onboarding Agent는 배포 전 단계인 ‘Day 0’를, Database Observability Agent는 배포 후 ‘Day 1·Day 2’ 운영을 담당한다. 2

Database Onboarding Agent: 요구사항을 데이터베이스 배포로

Database Onboarding Agent는 팀이 설명한 워크로드 요구사항을 해석하고, 적합한 관리형 데이터베이스를 추천한 뒤 설정과 배포 과정을 안내한다. 개발자나 플랫폼 팀이 애플리케이션의 처리 특성과 운영 조건은 알고 있지만, 구글 클라우드의 어떤 데이터베이스가 가장 적합한지 판단하기 어려울 때 활용할 수 있는 방식이다.

지원 대상은 AlloyDB, Bigtable, Cloud SQL, Spanner다. 2 기존에는 아키텍처 선택, 구성값 결정, 프로비저닝 명령 작성 등을 사람이 각각 검토해야 했다면, 이 에이전트는 자연어로 전달된 요구사항을 출발점으로 삼아 초기 설계와 배포 과정을 줄이는 데 초점을 맞춘다.

Database Observability Agent: 여러 신호를 엮어 원인과 대응을 제시

배포 이후의 운영은 Database Observability Agent가 맡는다. 구글은 데이터베이스 자산 전체에 대한 모니터링, 이상 징후 탐지, 진단, 문제 해결, 최적화, 유지보수 기능을 제시했다.

이 에이전트는 Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, Memorystore를 지원한다. 224 단일 대시보드의 알림만 확인하는 것이 아니라, 다음 정보를 함께 분석한다.

• Database Insights와 Database Center의 텔레메트리
• Cloud Monitoring의 지표
• Cloud Logging의 로그
• Cloud Trace의 추적 데이터
• 쿼리 정보, 인벤토리, 이슈 관련 데이터 2

이처럼 여러 신호를 결합해 잠재적인 근본 원인을 파악하고, 문제 설명과 대응 방안을 제시하는 것이 목표다. 단순히 “이상 현상이 발생했다”고 알려주는 수준을 넘어, 다단계 해결 절차를 지원한다.

예를 들어 Cloud SQL 연결 풀링을 활성화하거나 인덱스를 추가하는 작업을 제안할 수 있다. 다만 운영 환경에 영향을 줄 수 있는 수정은 사람이 승인해야 에이전트가 검증된 해결 작업을 실행한다. 조사 및 수정 기능은 일부 고객을 대상으로 한 프리뷰 기능으로 제공됐다. 224

어디에서 사용할 수 있나

두 에이전트는 Gemini Cloud Assist에 통합돼 Gemini 채팅과 Cloud Console의 관련 데이터베이스 화면에서 사용할 수 있다. 구글은 명령줄 도구, MCP 서버와 도구, 서드파티 도구, 통합개발환경(IDE)을 통한 접근도 설명했다. 2

이는 데이터베이스 지원 기능이 하나의 운영 대시보드에만 묶이지 않는다는 의미다. 개발자는 개발 환경에서, 운영 담당자는 콘솔이나 명령줄에서, 각자의 업무 흐름을 벗어나지 않고 자연어 기반으로 인프라를 조사하고 구성할 수 있다.

Cloud Run instances, 상시 실행이 필요한 에이전트를 겨냥

8월 28일 프리뷰로 공개된 Cloud Run instances는 일반적인 자동 확장형 Cloud Run 서비스와 다른 실행 단위다. 하나의 인스턴스만 유지하는 싱글턴(singleton) 런타임이며, 자동 확장을 사용하지 않는다. 구글은 이를 개인용 AI 에이전트처럼 오래 실행되고 상태를 유지해야 하는 워크로드에 적합한 환경으로 소개했다. 4

주요 특징은 다음과 같다.

• 최대 7일 동안 연속 실행
• 기본적으로 자동 재시작 정책 적용
• 업데이트와 재시작 이후에도 바뀌지 않는 HTTPS 주소
• 사용하지 않을 때 중지하고 나중에 다시 재개 가능
• 요청량에 따라 늘어나는 서버 집합이 아니라 하나의 전용 런타임으로 동작 4

이 구조는 한 명의 사용자를 위한 에이전트가 상태, 사용자 정체성, 백그라운드 작업을 유지해야 할 때 특히 잘 맞는다. 반면 갑작스러운 동시 요청 증가를 처리해야 하는 전형적인 무상태 웹 엔드포인트에는 기존 자동 확장형 서비스가 더 자연스러운 선택일 수 있다.

구글이 제시한 비용

구글은 1 vCPU와 1GiB 메모리 구성에서 공유 vCPU와 버스트 예산을 사용하는 경우, 30일 연속 운영 비용으로 5.70달러를 제시했다. 4

구글이 강조하는 장점은 가격뿐 아니라 운영 부담의 감소다. 전용 가상머신을 직접 관리할 때 필요한 가상머신과 운영체제 유지보수, 방화벽 관리, HTTPS 엔드포인트 구축 등을 별도로 처리하지 않아도 된다는 설명이다.

다만 5.70달러는 구글이 공개한 프리뷰 기준의 제품 소개 수치다. 실제 비용은 구성, 사용량, 리전, 과금 방식에 따라 달라질 수 있으므로 전용 VM과의 보편적인 비용 비교로 받아들여서는 안 된다. 43031

구글은 OffDeal 고객의 사례로 콜드 스타트가 88% 감소했다는 발언도 인용했다. 이는 특정 고객이 보고한 결과이며, 모든 환경에 적용되는 구글의 성능 보장이나 독립적인 벤치마크는 아니다. 4

AI 에이전트 시대에 맞춰 데이터와 컴퓨팅을 함께 바꾼다

기존 클라우드 애플리케이션은 대체로 무상태 요청 처리 계층과 영속적인 데이터 저장소를 분리했다. 하지만 AI 에이전트는 이 구분만으로 설명하기 어렵다. 에이전트는 지속적인 정체성과 엔드포인트, 메모리와 상태, 장시간 실행되는 백그라운드 작업, 각종 도구와 운영 데이터에 대한 접근을 동시에 필요로 할 수 있다.

이번 발표는 이 요구사항을 두 계층에서 나눠 해결한다.

1. 데이터베이스 계층의 자율성을 높인다. Onboarding Agent는 데이터베이스 선택과 프로비저닝을 돕고, Observability Agent는 데이터베이스 전체를 모니터링하며 문제를 조사하고 승인된 수정 작업을 실행할 수 있다. 2
2. 컴퓨팅 계층에 지속 실행 옵션을 추가한다. Cloud Run instances는 요청이 들어올 때만 실행되거나 트래픽에 맞춰 확장되는 모델 대신, 안정적인 주소를 가진 단일 런타임을 제공한다. 4

이는 데이터와 AI 모델, 운영 데이터베이스를 하나의 ‘행동을 실행하는 시스템(System of Action)’으로 통합하려는 구글 클라우드의 Agentic Data Cloud 구상과 맞닿아 있다. 11 중요한 점은 자동화를 확대하면서도, 운영 데이터베이스를 실제로 변경하는 단계에서는 사람의 승인을 남겨뒀다는 것이다. 2

실무적으로 무엇이 달라지나

이번 발표가 모든 AI 에이전트를 위한 단일 플랫폼을 내놓았다는 뜻은 아니다. 구글 클라우드는 두 가지 구체적인 문제를 겨냥한 구성 요소를 추가했다.

• 데이터베이스 선택, 프로비저닝, 전체 자산의 가시성, 장애 분석이 병목이라면 Database Operations Agents를 검토할 수 있다.
• 한 명의 사용자나 특정 작업을 위해 에이전트가 계속 실행돼야 하고, 일반적인 스케일 투 제로 서버리스 모델과 맞지 않는다면 Cloud Run instances를 고려할 수 있다.

두 제품 모두 프리뷰 성격이 강하다. 실제 도입 전에는 사용 가능 지역과 대상, 지원 구성, 권한 모델, 가격, 자동 수정 기능의 범위를 확인해야 한다. 그럼에도 방향성은 분명하다. 구글 클라우드는 AI 에이전트를 단순한 요청 처리 애플리케이션이 아니라, 더 자율적인 운영과 더 오래 지속되는 실행 환경이 필요한 새로운 클라우드 워크로드로 다루기 시작했다.

구글 클라우드가 AI 에이전트를 위한 인프라의 빈틈을 두 방향에서 메우고 있다. 하나는 어떤 데이터베이스를 선택하고 운영할지에 필요한 수작업이고, 다른 하나는 일반적인 웹 요청이 없어도 계속 실행돼야 하는 에이전트를 어디에서 호스팅할지에 관한 문제다.

2026년 8월 구글 클라우드는 Gemini Cloud Assist에 통합된 Database Operations Agents를 선보였다. 이어 8월 28일에는 장시간 실행되는 상태 저장형 워크로드를 위한 Cloud Run instances를 프리뷰로 공개했다. 데이터 계층과 컴퓨팅 계층을 동시에 에이전트 중심으로 바꾸려는 움직임이다. 2411

데이터베이스 운영 에이전트, 구축부터 유지보수까지

Database Operations Agents는 구글 클라우드의 Agentic Data Cloud 전략 아래 소개됐다. 역할은 비교적 명확하다. Database Onboarding Agent는 배포 전 단계인 ‘Day 0’를, Database Observability Agent는 배포 후 ‘Day 1·Day 2’ 운영을 담당한다. 2

Database Onboarding Agent: 요구사항을 데이터베이스 배포로

Database Onboarding Agent는 팀이 설명한 워크로드 요구사항을 해석하고, 적합한 관리형 데이터베이스를 추천한 뒤 설정과 배포 과정을 안내한다. 개발자나 플랫폼 팀이 애플리케이션의 처리 특성과 운영 조건은 알고 있지만, 구글 클라우드의 어떤 데이터베이스가 가장 적합한지 판단하기 어려울 때 활용할 수 있는 방식이다.

지원 대상은 AlloyDB, Bigtable, Cloud SQL, Spanner다. 2 기존에는 아키텍처 선택, 구성값 결정, 프로비저닝 명령 작성 등을 사람이 각각 검토해야 했다면, 이 에이전트는 자연어로 전달된 요구사항을 출발점으로 삼아 초기 설계와 배포 과정을 줄이는 데 초점을 맞춘다.

Database Observability Agent: 여러 신호를 엮어 원인과 대응을 제시

배포 이후의 운영은 Database Observability Agent가 맡는다. 구글은 데이터베이스 자산 전체에 대한 모니터링, 이상 징후 탐지, 진단, 문제 해결, 최적화, 유지보수 기능을 제시했다.

이 에이전트는 Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, Memorystore를 지원한다. 224 단일 대시보드의 알림만 확인하는 것이 아니라, 다음 정보를 함께 분석한다.

• Database Insights와 Database Center의 텔레메트리
• Cloud Monitoring의 지표
• Cloud Logging의 로그
• Cloud Trace의 추적 데이터
• 쿼리 정보, 인벤토리, 이슈 관련 데이터 2

이처럼 여러 신호를 결합해 잠재적인 근본 원인을 파악하고, 문제 설명과 대응 방안을 제시하는 것이 목표다. 단순히 “이상 현상이 발생했다”고 알려주는 수준을 넘어, 다단계 해결 절차를 지원한다.

예를 들어 Cloud SQL 연결 풀링을 활성화하거나 인덱스를 추가하는 작업을 제안할 수 있다. 다만 운영 환경에 영향을 줄 수 있는 수정은 사람이 승인해야 에이전트가 검증된 해결 작업을 실행한다. 조사 및 수정 기능은 일부 고객을 대상으로 한 프리뷰 기능으로 제공됐다. 224

어디에서 사용할 수 있나

두 에이전트는 Gemini Cloud Assist에 통합돼 Gemini 채팅과 Cloud Console의 관련 데이터베이스 화면에서 사용할 수 있다. 구글은 명령줄 도구, MCP 서버와 도구, 서드파티 도구, 통합개발환경(IDE)을 통한 접근도 설명했다. 2

이는 데이터베이스 지원 기능이 하나의 운영 대시보드에만 묶이지 않는다는 의미다. 개발자는 개발 환경에서, 운영 담당자는 콘솔이나 명령줄에서, 각자의 업무 흐름을 벗어나지 않고 자연어 기반으로 인프라를 조사하고 구성할 수 있다.

Cloud Run instances, 상시 실행이 필요한 에이전트를 겨냥

8월 28일 프리뷰로 공개된 Cloud Run instances는 일반적인 자동 확장형 Cloud Run 서비스와 다른 실행 단위다. 하나의 인스턴스만 유지하는 싱글턴(singleton) 런타임이며, 자동 확장을 사용하지 않는다. 구글은 이를 개인용 AI 에이전트처럼 오래 실행되고 상태를 유지해야 하는 워크로드에 적합한 환경으로 소개했다. 4

주요 특징은 다음과 같다.

• 최대 7일 동안 연속 실행
• 기본적으로 자동 재시작 정책 적용
• 업데이트와 재시작 이후에도 바뀌지 않는 HTTPS 주소
• 사용하지 않을 때 중지하고 나중에 다시 재개 가능
• 요청량에 따라 늘어나는 서버 집합이 아니라 하나의 전용 런타임으로 동작 4

이 구조는 한 명의 사용자를 위한 에이전트가 상태, 사용자 정체성, 백그라운드 작업을 유지해야 할 때 특히 잘 맞는다. 반면 갑작스러운 동시 요청 증가를 처리해야 하는 전형적인 무상태 웹 엔드포인트에는 기존 자동 확장형 서비스가 더 자연스러운 선택일 수 있다.

구글이 제시한 비용

구글은 1 vCPU와 1GiB 메모리 구성에서 공유 vCPU와 버스트 예산을 사용하는 경우, 30일 연속 운영 비용으로 5.70달러를 제시했다. 4

구글이 강조하는 장점은 가격뿐 아니라 운영 부담의 감소다. 전용 가상머신을 직접 관리할 때 필요한 가상머신과 운영체제 유지보수, 방화벽 관리, HTTPS 엔드포인트 구축 등을 별도로 처리하지 않아도 된다는 설명이다.

다만 5.70달러는 구글이 공개한 프리뷰 기준의 제품 소개 수치다. 실제 비용은 구성, 사용량, 리전, 과금 방식에 따라 달라질 수 있으므로 전용 VM과의 보편적인 비용 비교로 받아들여서는 안 된다. 43031

구글은 OffDeal 고객의 사례로 콜드 스타트가 88% 감소했다는 발언도 인용했다. 이는 특정 고객이 보고한 결과이며, 모든 환경에 적용되는 구글의 성능 보장이나 독립적인 벤치마크는 아니다. 4

AI 에이전트 시대에 맞춰 데이터와 컴퓨팅을 함께 바꾼다

기존 클라우드 애플리케이션은 대체로 무상태 요청 처리 계층과 영속적인 데이터 저장소를 분리했다. 하지만 AI 에이전트는 이 구분만으로 설명하기 어렵다. 에이전트는 지속적인 정체성과 엔드포인트, 메모리와 상태, 장시간 실행되는 백그라운드 작업, 각종 도구와 운영 데이터에 대한 접근을 동시에 필요로 할 수 있다.

이번 발표는 이 요구사항을 두 계층에서 나눠 해결한다.

1. 데이터베이스 계층의 자율성을 높인다. Onboarding Agent는 데이터베이스 선택과 프로비저닝을 돕고, Observability Agent는 데이터베이스 전체를 모니터링하며 문제를 조사하고 승인된 수정 작업을 실행할 수 있다. 2
2. 컴퓨팅 계층에 지속 실행 옵션을 추가한다. Cloud Run instances는 요청이 들어올 때만 실행되거나 트래픽에 맞춰 확장되는 모델 대신, 안정적인 주소를 가진 단일 런타임을 제공한다. 4

이는 데이터와 AI 모델, 운영 데이터베이스를 하나의 ‘행동을 실행하는 시스템(System of Action)’으로 통합하려는 구글 클라우드의 Agentic Data Cloud 구상과 맞닿아 있다. 11 중요한 점은 자동화를 확대하면서도, 운영 데이터베이스를 실제로 변경하는 단계에서는 사람의 승인을 남겨뒀다는 것이다. 2

실무적으로 무엇이 달라지나

이번 발표가 모든 AI 에이전트를 위한 단일 플랫폼을 내놓았다는 뜻은 아니다. 구글 클라우드는 두 가지 구체적인 문제를 겨냥한 구성 요소를 추가했다.

• 데이터베이스 선택, 프로비저닝, 전체 자산의 가시성, 장애 분석이 병목이라면 Database Operations Agents를 검토할 수 있다.
• 한 명의 사용자나 특정 작업을 위해 에이전트가 계속 실행돼야 하고, 일반적인 스케일 투 제로 서버리스 모델과 맞지 않는다면 Cloud Run instances를 고려할 수 있다.

두 제품 모두 프리뷰 성격이 강하다. 실제 도입 전에는 사용 가능 지역과 대상, 지원 구성, 권한 모델, 가격, 자동 수정 기능의 범위를 확인해야 한다. 그럼에도 방향성은 분명하다. 구글 클라우드는 AI 에이전트를 단순한 요청 처리 애플리케이션이 아니라, 더 자율적인 운영과 더 오래 지속되는 실행 환경이 필요한 새로운 클라우드 워크로드로 다루기 시작했다.