목록만 훑고 넘겼던 발표
올해 4월 라스베이거스에서 Google Cloud Next '26이 열렸습니다. 구글이 낸 공식 리캡 제목은 "260 things we announced"였습니다. 숫자부터 부담스럽습니다.
솔직히 그때는 목록을 한 번 훑고 창을 닫았습니다. 대부분 "에이전트"라는 단어가 붙어 있었고, 그게 다 그 말 같았거든요.
반년이 지나 다시 꺼내 본 계기는 사소했습니다. 사내 위키 문서를 BigQuery로 옮기고 LLM 요약을 붙이던 Cloud Run 배치를 손볼 일이 생긴 겁니다. 이 파이프라인을 옆에 두고 발표를 다시 읽으니, 이번에는 꽤 많은 항목이 구체적인 고민과 연결됐습니다.
이 글은 그렇게 다시 읽으면서 고른 것들의 지도입니다. 세부 내용은 이어지는 글에서 하나씩 파고듭니다.
Vertex AI라는 이름이 사라졌다
가장 눈에 띄는 변화는 이름이었습니다. Vertex AI가 Gemini Enterprise Agent Platform으로 바뀌었고, 작년의 Agentspace는 Gemini Enterprise라는 앱으로 흡수됐습니다.
처음엔 흔한 리브랜딩이라고 생각했습니다. 그런데 플랫폼 안에 들어간 구성 요소를 펼쳐 보니 성격이 달랐습니다.
- 만들기: Agent Development Kit(ADK), 저코드 빌더인 Agent Studio
- 돌리기: Agent Runtime, Agent Sandbox, Memory Bank, Sessions
- 통제하기: Agent Identity, Agent Registry, Agent Gateway
- 개선하기: Agent Simulation, Evaluation & Observability, Agent Optimizer
모델을 고르고 호출하는 곳이었던 Vertex AI가, 에이전트를 운영하는 곳으로 무게중심을 옮긴 셈입니다. 모델 쪽에서는 Gemini 3.1 Pro와 함께 Anthropic의 Claude Opus 4.7도 같은 플랫폼에서 쓸 수 있다고 밝혔습니다.
이름보다 중요한 건 운영 계층이 따로 생겼다는 점이었습니다. 에이전트마다 신원을 주고, 승인된 도구만 쓰게 하고, 실패한 대화를 모아 다시 고치는 일. 지금까지 각 팀이 Cloud Run과 서비스 계정, 로그 쿼리로 대충 이어 붙이던 일들입니다.
데이터 쪽 키워드는 '에이전트가 읽을 수 있는 데이터'
데이터 발표는 Agentic Data Cloud라는 이름으로 묶였습니다. 리캡 기준으로 60개 가까운 항목이 여기에 들어갑니다.
훑어보면 방향은 하나입니다. 사람이 대시보드로 보던 데이터를, 에이전트도 맥락을 이해한 채로 읽고 쓰게 만들겠다는 것입니다.
| 영역 | 주요 발표 | 이 시리즈에서 다룰 질문 |
|---|---|---|
| 의미(시맨틱) | Knowledge Catalog, BigQuery measures, LookML Agent | 에이전트가 '매출'을 우리와 같은 뜻으로 계산할 수 있나 |
| 저장소 | Cross-cloud Lakehouse(구 BigLake), Iceberg REST Catalog | S3 데이터를 복사 없이 읽을 수 있나 |
| SQL 안의 AI | AI.CLASSIFY·AI.IF 최적화 모드, AI.PARSE_DOCUMENT | 행마다 LLM을 부르는 비용을 줄일 수 있나 |
| 실무 도구 | Data Engineering Agent, Data Agent Kit | 말로 만든 파이프라인을 어떻게 리뷰하나 |
| 데이터베이스 | 관리형 원격 MCP 서버, Spanner Columnar Engine | 에이전트에게 DB를 어디까지 열어주나 |
운영 DB와 분석 DB 사이를 잇는 발표도 꽤 있었습니다. Spanner에 컬럼 지향 엔진을 붙여 운영 데이터 위에서 분석 쿼리를 최대 200배 빠르게 돌린다는 것, BigQuery 결과를 AlloyDB나 Spanner로 되돌려 보내는 Reverse ETL이 대표적입니다.
분석 결과가 다시 운영 시스템으로 흘러가야 에이전트가 '행동'할 수 있다는 그림입니다. 그림은 그럴듯합니다. 다만 운영 DB에 쓰기 경로가 하나 늘어난다는 뜻이기도 해서, 이건 신중하게 보고 있습니다.
인프라 발표에서 건진 것
TPU 8세대는 학습용 8t와 추론용 8i로 나뉘었습니다. 구글은 8i가 에이전트 워크로드와 MoE 모델에서 달러당 성능을 최대 80% 끌어올린다고 발표했습니다.
우리 규모에서 TPU를 직접 잡을 일은 당분간 없습니다. 오히려 반가웠던 건 Cloud Run 쪽 소식이었습니다.
- 장시간 백그라운드 작업 지원
- 완전 관리형 원격 MCP 서버(GA)
- 요금 상한(billing caps) 기능 예고
앞선 글에서 Cloud Run의 실행 시간 제한을 피하려고 8분짜리 이어달리기를 만들었습니다. 장시간 작업이 정식으로 지원되면 그 꼼수는 걷어낼 수 있습니다.
요금 상한도 마찬가지입니다. 외부 API가 멈췄을 때 컨테이너가 공회전하며 비용을 태울까 봐 타임아웃을 짧게 잡았던 건데, 상한이 생기면 그 불안을 플랫폼에 맡길 수 있습니다. 물론 어느 기능이 지금 정식 출시 상태인지는 문서에서 다시 확인해야 합니다.
이 시리즈를 읽는 방법
이어지는 아홉 편은 각각 하나의 질문에서 출발합니다.
- Knowledge Catalog: 에이전트에게 비즈니스 맥락을 주는 법
- Cross-cloud Lakehouse와 Iceberg: 데이터를 옮기지 않고 읽는 법
- BigQuery AI 함수: 행 단위 LLM 호출 비용 줄이기
- Data Engineering Agent: 말로 만든 파이프라인 리뷰하기
- ADK 그래프 워크플로: 순서까지 LLM에게 맡기지 않기
- Agent Identity와 Gateway: 에이전트 권한 나누기
- 평가와 관측: 에이전트 로그를 BigQuery에 쌓기
- 관리형 MCP 서버: 에이전트에게 DB를 열어줄 때
- 고객 사례: 숫자 뒤의 아키텍처 패턴
하나만 미리 말해 두겠습니다. 키노트의 성능 수치는 모두 구글이 발표한 값입니다. 그리고 4월에 발표된 기능 상당수는 프리뷰로 시작했습니다.
그래서 각 글에서는 "이게 된다"보다 "우리 파이프라인에 넣는다면 무엇부터 확인할까"에 더 많은 분량을 썼습니다. 발표 영상보다 릴리스 노트가 더 정직하다는 건, 반년이 지난 지금 다시 읽으며 새삼 느낀 점입니다.
