구글 클라우드의 8월 AI 인프라 전략: 데이터베이스 운영 자동화와 지속 실행 런타임

구글 클라우드가 AI 에이전트 인프라의 두 가지 병목을 겨냥한 기능을 내놨다. 하나는 데이터베이스를 설정하고 장애를 진단하는 데 여전히 전문 인력과 반복 작업이 필요하다는 점이고, 다른 하나는 장시간 실행되는 에이전트가 일반적인 서버리스 환경에서 곧바로 0개 인스턴스로 축소된다는 점이다.

이를 위해 구글은 Gemini Cloud Assist와 연동되는 Database Operations Agents와, 단일 워크로드를 계속 실행할 수 있는 프리뷰 기능인 Cloud Run 인스턴스를 공개했다. 두 기능은 서로 대체재가 아니라 데이터 계층과 실행 계층을 각각 보완하는 구성요소다. 231

데이터베이스 운영을 맡는 두 에이전트

Database Operations Agents는 구글 클라우드가 추진하는 ‘Agentic Data Cloud’ 전략의 일부다. 자연어 기반으로 데이터베이스의 초기 구축부터 운영 중인 장애 대응까지 지원한다. 23

• Database Onboarding Agent: 이른바 Day 0 작업을 담당한다. 요구사항에 맞는 데이터베이스 선택, 설정, 구성, 초기 배포를 안내한다.
• Database Observability Agent: Day 1과 Day 2 운영을 맡는다. 모니터링, 문제 해결, 지속적인 유지보수와 성능 진단을 지원한다. 23

기존에는 관리자가 프로비저닝 스크립트, 설정 절차, 모니터링 쿼리, 장애 분석 작업을 각각 준비해야 했다. 새 에이전트는 이런 과정을 자연어 대화형 워크플로로 묶어 데이터베이스 관리자(DBA), 개발자, 사이트 신뢰성 엔지니어(SRE), DevOps 팀의 반복적인 운영 부담을 줄이는 데 초점을 맞춘다.

지원되는 데이터베이스 서비스

Onboarding Agent는 구글 클라우드의 관리형 데이터베이스 서비스인 AlloyDB, Bigtable, Cloud SQL, Spanner를 지원하는 것으로 소개됐다. 29

다만 모든 기능이 일반 공개된 것은 아니다. 구글의 발표에 따르면 온보딩 및 관찰 기능은 프리뷰로 제공되며, Observability Agent의 일부 기능은 특정 고객과 일부 데이터베이스 서비스에 한정된다. 2934

여러 신호를 엮어 장애 원인 분석

Observability Agent의 특징은 단일 데이터베이스 지표만 보는 것이 아니라 여러 운영 신호를 함께 분석한다는 데 있다. Database Insights, Cloud Monitoring, Cloud Logging, Cloud Trace 등의 정보를 연계해 쿼리 병목, 지연 시간 증가, 잠금 경합, 리소스 부족과 같은 문제의 원인을 추정한다. 23

이후 의심되는 원인과 권장 변경 사항, 그 근거와 예상 영향을 설명한다. 지원되는 조치의 실제 실행에는 사용자의 승인이 필요하다. 구글이 예로 든 조치에는 Cloud SQL 연결 풀링 활성화와 인덱스 추가가 포함된다. 2344

이 승인 절차는 운영 환경에서 특히 중요하다. 데이터베이스 변경은 단순한 성능 개선처럼 보여도 비용, 지연 시간, 잠금, 애플리케이션 동작에 영향을 줄 수 있기 때문이다. 따라서 에이전트가 진단과 제안을 자동화하더라도, 영향이 큰 변경에는 사람의 검토 경계를 남겨둔 구조다.

콘솔 밖으로 확장되는 운영 인터페이스

Database Operations Agents는 특정 관리 화면에만 머물지 않는다. Gemini Cloud Assist 채팅, 구글 클라우드 콘솔의 데이터베이스 페이지, Database Center의 플릿 보기, 명령줄 인터페이스(CLI), 통합개발환경(IDE), 서드파티 도구 등에서 사용할 수 있도록 통합됐다. 23

Database Insights와 Database Center의 기능은 MCP(Model Context Protocol) 호환 인터페이스로도 제공될 수 있다. 구글의 관리형 MCP 서버를 이용하면 사용자가 별도로 MCP 서버 인프라를 배포하지 않고도 Gemini나 다른 MCP 클라이언트가 데이터베이스와 인프라 기능에 연결할 수 있다. 36

이 방식은 외부 개발 도구나 운영 에이전트가 그래픽 콘솔에 의존하지 않고 데이터베이스 플릿 목록, 성능 지표, 감지된 문제를 표준화된 도구 인터페이스로 조회하게 해준다.

Cloud Run 인스턴스, 0으로 줄어들지 않는 단일 런타임

Cloud Run 인스턴스는 전용 싱글턴(singleton) Cloud Run 런타임이다. 일반적인 Cloud Run 서비스처럼 트래픽에 따라 복제되지 않으며, 정확히 하나의 사본을 실행하고 자동 확장이나 0으로의 축소를 수행하지 않는다. 구글은 개인용 AI 에이전트처럼 장시간 실행되고 주로 한 사용자가 이용하는 워크로드를 주요 활용 사례로 제시했다. 1

각 인스턴스는 기본적으로 자동 재시작 정책이 설정된 상태에서 최대 7일 동안 연속 실행될 수 있다. 필요하지 않을 때 인스턴스를 중지했다가 나중에 다시 시작하는 것도 가능하다. 또한 업데이트나 재시작 이후에도 바뀌지 않는 HTTPS 주소가 인스턴스마다 부여된다. 1

이 모델이 해결하려는 문제는 다음과 같다.

• 스케일 투 제로로 인한 중단 방지: 요청이 잠시 없더라도 프로세스가 사라지지 않는다.
• 단일 인스턴스 실행: 자동 확장에 따라 여러 복사본이 만들어지지 않고 전용 프로세스 하나가 실행된다.
• 안정적인 주소: 업데이트와 재시작 이후에도 HTTPS 엔드포인트가 유지된다.
• 가상 머신보다 간소한 운영: 게스트 운영체제, 방화벽, HTTPS 엔드포인트를 직접 관리하지 않고도 지속 실행 프로세스를 운영할 수 있다. 1

구글은 이를 항상 켜진 가상 머신(VM)의 대안으로 포지셔닝한다. 다만 모든 워크로드를 VM이나 자동 확장형 Cloud Run 서비스에서 Cloud Run 인스턴스로 옮기라는 의미는 아니다.

비용과 콜드 스타트의 절충점

구글이 제시한 가격은 공유 vCPU 1개와 메모리 1GiB를 30일 내내 실행할 경우 5.70달러다. 간헐적인 계산량 급증에는 버스트 예산을 활용할 수 있어, 모든 피크 부하를 감당할 만큼 상시 리소스를 크게 설정할 필요를 줄일 수 있다. 1

프로세스가 계속 살아 있기 때문에 콜드 스타트에 노출되는 상황도 줄어든다. 한 초기 사용자는 장시간 실행 에이전트의 콜드 스타트가 88% 감소했다고 보고했다. 다만 이는 특정 고객의 결과일 뿐, 모든 환경에 적용되는 성능 보장은 아니다. 1

또한 5.70달러는 제시된 리소스 구성의 기준 사례다. 실제 청구액에는 워크로드에 따라 추가 컴퓨팅 리소스, 네트워크, 스토리지 또는 관련 서비스 비용이 더해질 수 있다.

‘지속 실행’과 ‘영구 메모리’는 다르다

Cloud Run 인스턴스가 프로세스를 계속 유지한다고 해서 메모리에만 저장된 데이터까지 모든 재시작과 런타임 종료를 견디는 것은 아니다. 구글의 아키텍처 가이드도 애플리케이션 메모리에 저장된 세션 상태와 외부 영속 상태를 구분한다. 애플리케이션이 재시작되면 메모리 안의 대화 기록은 사라질 수 있으며, 안정성과 확장성이 필요한 운영 시스템에는 외부 상태 관리가 권장된다. 19

따라서 운영용 에이전트라면 세션, 워크플로 진행 상황, 완료되지 않은 작업 등을 데이터베이스나 별도의 영속 시스템에 저장해야 한다. 구글의 장시간 실행 에이전트 가이드 역시 운영 환경에서 Cloud SQL을 포함한 데이터베이스 기반 세션 저장소를 제시한다. 21

즉 Cloud Run 인스턴스가 제공하는 ‘상태 유지’는 제한된 런타임 안에서 프로세스를 계속 실행하는 모델에 가깝다. 인스턴스의 수명보다 오래 대화 맥락과 작업을 보존해야 한다면 별도의 영속 저장소 설계가 여전히 필요하다.

구글 클라우드가 겨냥하는 에이전트 인프라의 전체 그림

두 발표를 함께 보면 구글 클라우드는 AI 에이전트 시스템의 실행 계층과 데이터 계층을 동시에 손보고 있다.

1. 에이전트를 실행한다: Cloud Run 인스턴스가 전용 프로세스와 안정적인 엔드포인트를 제공한다. 1
2. 데이터 계층을 운영한다: Database Operations Agents가 프로비저닝, 관찰, 진단, 승인된 문제 해결 작업을 자동화한다. 23
3. 도구를 여러 환경에 연결한다: MCP 통합으로 IDE, CLI, 외부 개발 도구와 다른 에이전트가 데이터베이스 기능을 활용할 수 있다. 36
4. 위험한 변경에는 사람을 남겨둔다: Observability Agent는 변경을 제안할 수 있지만, 지원되는 수정 작업의 실행에는 승인이 필요하다. 23

결국 구글이 내놓은 것은 엔지니어의 판단을 완전히 없애는 자율 인프라가 아니다. 자연어, 운영 텔레메트리, 표준화된 도구 인터페이스를 활용해 반복 작업을 줄이는 관리형 구성요소에 가깝다. 아키텍처 선택, 권한, 영속 상태, 운영 변경에 대한 통제는 여전히 개발·운영팀의 책임으로 남는다.

개인 비서, 비동기 워크플로, 다중 턴 대화형 에이전트를 만드는 팀에는 Cloud Run 인스턴스가 실행 지속성을 제공한다. 해당 에이전트가 의존하는 데이터베이스를 관리하는 팀에는 Database Operations Agents가 설정, 상태 파악, 장애 대응에 드는 반복 업무를 덜어준다. 구글 클라우드의 방향은 분명하다. 컴퓨팅과 데이터베이스 운영 모두를 자연어와 텔레메트리, 표준 도구 인터페이스를 통해 에이전트가 활용하기 쉬운 형태로 바꾸려는 것이다.