데이터 분석

대규모 관리형 Apache Iceberg: Spanner가 Lakehouse 런타임 카탈로그를 지원하는 방법

Tue, 13 Oct 2026 10:00:00 +0000

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

고객이 레이크하우스 아키텍처로 현대화함에 따라 호환되는 엔진 전반에서 공유 데이터 자산을 생성하기 위해 Apache Iceberg와 같은 개방형 형식을 표준으로 채택하고 있습니다. 이를 통해 데이터를 시맨틱 지식으로 전환하고, 선제적인 조치를 취하고, 에이전트 규모로 운영되는 AI 네이티브 레이크하우스를 빌드할 수 있습니다.

레이크하우스의 핵심 구성요소 중 하나는 카탈로그이며, Apache Iceberg 환경에서는 일반적으로 Iceberg REST 카탈로그를 의미합니다. Apache Iceberg 카탈로그는 테이블 포인터를 관리하고, 원자적 커밋을 처리하며, 테이블 위치에 대한 단일 정보 소스 역할을 합니다. 하지만 대규모 엔터프라이즈 조직이 레이크하우스로 전환하며 현대화를 추진함에 따라, 레이크하우스 아키텍처의 핵심 요소로서 확장성과 가용성이 뛰어난 관리형 카탈로그가 필요하다는 사실을 깨닫기 시작했습니다. 이는 에이전트를 통해 쿼리 규모가 확장될수록 더욱 중요해집니다. 에이전트의 수많은 반복적인 소규모 쿼리를 지원하려면 원자성, 일관성, 가용성, 동시 실행을 대규모로 제공하는 관리형 카탈로그를 기반으로 시스템을 구축해야 합니다.

이 블로그에서는 에이전트 규모의 최신 클라우드 환경에서 관리형 카탈로그가 직면하는 과제를 살펴보고 Google Cloud의 서버리스 Lakehouse 런타임 카탈로그가 이러한 과제를 해결하는 데 어떻게 도움이 되는지 보여줍니다. 사실상 무제한으로 확장되는 Google Cloud의 상시 가동 데이터베이스인 Spanner를 기반으로 하며, 개방형 Apache Iceberg REST 카탈로그 사양에 맞춰 빌드된 Lakehouse 런타임 카탈로그는 에이전트 시대에 필요한 확장성과 가용성이 뛰어난 기반을 제공합니다.

레이크하우스에서 관리형 카탈로그가 해결해야 하는 과제

레이크하우스에서 대규모 프로덕션 분석을 운영하는 데이터 엔지니어 및 인프라 리드와 이야기를 나누다 보면 다음과 같은 핵심 고충 사항이 공통적으로 나타납니다. 이러한 문제는 관리형 카탈로그를 통해 반드시 해결해야 할 과제입니다.

원자적 커밋 및 동시 실행 제어: Iceberg는 낙관적 동시 실행 제어(OCC)를 통해 ACID 트랜잭션을 보장합니다. 관리형 카탈로그는 현재 메타데이터 포인터를 교체하기 위해 어떠한 오류도 허용하지 않는 완벽한 원자적 비교 및 바꾸기(CAS) 작업을 구현해야 합니다.

고가용성 및 운영 유지보수: 카탈로그가 다운되면 쿼리가 즉시 실패하므로 관리형 카탈로그는 중요한 Tier-1 서비스가 됩니다.

카탈로그를 지원하는 데이터베이스 확장: 카탈로그 설계자는 일반적으로 테이블 메타데이터와 상태를 위한 지원 데이터베이스를 선택할 때 어려운 절충점에 직면합니다. 기존의 수직 확장 관계형 데이터베이스는 SQL 및 ACID 트랜잭션을 제공하지만, 동시 읽기/쓰기 부하가 심해지면 CPU, 메모리, 스토리지, 연결 등 물리적 한계에 부딪히게 됩니다. 이를 해결하기 위해 수동으로 샤딩하면 막대한 운영 오버헤드가 발생합니다. 반면, 수평 확장 데이터베이스 시스템은 eventual consistency를 갖거나, 관리가 어렵거나, 엔터프라이즈 환경에 적합하지 않는 등의 여러 문제를 안고 있는 경우가 많습니다.

테이블 유지보수 조정: 카탈로그만으로는 데이터를 최적화할 수 없습니다. 압축, 스냅샷 만료, 매니페스트 재작성, 분리된 파일 정리를 위한 보조 파이프라인을 빌드하고 운영해야 합니다.

거버넌스 및 보안: 카탈로그는 보안 게이트키퍼 역할을 합니다. 카탈로그는 다음 사항을 구현하고 관리해야 합니다.

인증 프로토콜(예: OAuth2 토큰 교환, IAM 제휴)
네임스페이스 및 테이블 수준까지 액세스 제어
판매된 스토리지 사용자 인증 정보(예: 쿼리 엔진에 광범위하고 직접적인 스토리지 사용자 인증 정보가 필요하지 않도록 단기 토큰 생성)

Lakehouse 런타임 카탈로그

이러한 과제를 해결하기 위해 Google Cloud는 Iceberg REST 카탈로그를 지원하는 Lakehouse 런타임 카탈로그(정식 버전)를 빌드했습니다. Lakehouse 런타임 카탈로그는 Apache Iceberg와 같은 최신 개방형 테이블 형식을 지원하도록 처음부터 설계된 완전한 서버리스 기반의 고가용성 통합 메타데이터 레지스트리입니다. Lakehouse 런타임 카탈로그는 Apache Iceberg REST 카탈로그 사양을 기본적으로 구현하여 메타데이터 검색을 컴퓨팅 엔진에서 분리함으로써 여러 Iceberg 호환 엔진이 공유 데이터 자산에 액세스할 수 있도록 보장하고 워크로드를 더 빠르게 프로덕션으로 전환할 수 있도록 지원합니다. Google Cloud는 많은 고객이 관리형 카탈로그를 원활하게 마이그레이션할 수 있도록 지원해 왔습니다. 예를 들어 Etsy는 자사 카탈로그를 Lakehouse 런타임 카탈로그로 마이그레이션하여, 데이터를 이동 없이 조인함으로써 파이프라인 쿼리 속도를 60% 향상했습니다.

이 방법은 다음과 같은 여러 가지 아키텍처 이점을 제공합니다.

개방형 API: Iceberg REST 카탈로그를 지원하므로 여러 팀이 단일 통합 데이터 세트에서 각자 선호하는 분석 도구를 사용할 수 있습니다.
멀티 엔진 상호 운용성: 등록된 테이블은 표준 REST 인터페이스를 통해 Google Cloud Managed Service for Apache Spark, BigQuery, 오픈소스 엔진 전반에서 즉시 검색하고 쿼리할 수 있습니다.
Iceberg 테이블의 읽기/쓰기 상호 운용성: BigQuery, Managed Spark와 같은 Iceberg 호환 엔진을 활용하여 Lakehouse 런타임 카탈로그에 등록된 Iceberg 테이블에 데이터를 기록할 수 있습니다. 고객은 Managed Spark를 사용하여 외부 카탈로그에 있는 Iceberg 테이블에 데이터를 기록할 수도 있습니다.
엔터프라이즈급 기능을 갖춘 완전 관리형 Iceberg 스토리지: Google의 차별화된 인프라를 사용하여 Iceberg 테이블에서 성능을 갖춘 분석을 실행합니다. 이를 통해 오픈소스의 유연성뿐만 아니라 성능, 확장성, 거버넌스, 멀티모달 처리의 이점을 누릴 수 있습니다.
데이터 복사 없음: 테이블 정의가 기본 객체 스토어의 기존 데이터를 직접 가리킵니다. 기본 데이터를 이동하거나 재작성하거나 복제할 필요가 없습니다.
클라우드 전반의 양방향 카탈로그 제휴:벤딩된 사용자 인증 정보 및 OIDC 토큰 교환을 지원하여 Databricks Unity, Snowflake Horizon, AWS Glue의 데이터에 액세스합니다. 이를 통해 Google AI를 AWS 및 Azure 데이터에 직접 적용할 수 있습니다.
사용자 인증 정보 벤더 제공을 사용한 보안 액세스: 카탈로그는 여러 승인 메커니즘을 지원하므로 사용자 인증 정보 벤더 제공과 최종 사용자 인증 정보 중에서 선택할 수 있습니다. 즉, 기본 객체 스토어(Cloud Storage, AWS S3, Azure Blob Storage)의 파일에 직접 액세스할 필요 없이 사용자 인증 정보 벤더 제공 같은 최신 메커니즘을 사용하여 테이블에 액세스할 수 있습니다.
AI 기반 컨텍스트 및 거버넌스: Lakehouse 런타임 카탈로그는 Knowledge Catalog 및 Cloud IAM과 직접 통합되므로 에이전트에 대한 신뢰할 수 있는 컨텍스트를 정의하고 모든 컴퓨팅 엔진에 테이블 수준 보안을 일관되게 적용할 수 있습니다. 카탈로그에서 Iceberg 테이블에 대한 즉시 사용 가능한 검색, 계보, 인사이트를 얻을 수 있습니다.
원자적 커밋 및 동시 실행 제어, 고가용성 및 확장성: Google의 전 세계 규모 인프라와 Spanner를 기반으로 데이터와 함께 메타데이터를 확장하는 데 필요한 고가용성, 동시 실행, 확장성을 확보할 수 있습니다. Cloud Storage 이중 리전 및 멀티 리전 버킷을 지원하여 장애 조치 사용 사례를 지원합니다. 또한 서버리스와 노옵스(no-ops) 환경을 통해 TCO가 절감되고 모든 워크로드 규모에 맞게 확장할 수 있습니다.

Lakehouse 런타임 카탈로그의 원동력

Lakehouse 런타임 카탈로그는 Spanner를 기반으로 빌드되어 strong consistency가 보장되는 가용성이 높고 동시 실행 및 확장성이 뛰어난 카탈로그입니다. 수직적 단일 노드 한계에 부딪히는 기존의 수직 확장형 관계형 데이터베이스와 달리, Spanner는 완전한 관계형 SQL 시맨틱 및 멀티 테이블 ACID 트랜잭션을 NoSQL 시스템의 장점인 읽기와 쓰기 모두에 대한 수평 확장 탄력성과 결합했습니다.

Spanner는 최대 99.99%의 가용성을 제공하는 Spanner의 리전 구성을 통해 Lakehouse 런타임 카탈로그의 가용성을 높입니다. 또한 Spanner는 Lakehouse 런타임 카탈로그에 즉시 사용 가능한 확장성을 제공합니다. 수평 확장 가능한 데이터베이스인 Spanner는 수동 샤딩이 필요하지 않으며 컴퓨팅과 스토리지를 독립적이고 투명하게 확장합니다. Spanner는 데이터 볼륨과 쿼리 부하를 동적으로 모니터링하여 데이터 범위를 분할하고 노드 간에 재배포합니다. 컴퓨팅 노드는 CPU 사용률과 스토리지 기준점에 따라 동적으로 확장됩니다. Spanner는 분할 수준의 과부하를 자동으로 감지하여, 부하가 집중된 노드에서 사용량이 많은 분할을 다른 곳으로 알아서 이동해 줍니다. 또한 Spanner를 사용하면 Lakehouse 런타임 카탈로그 사용자가 관계형 일관성과 분산 확장성 간의 기존 절충점을 극복하고, Lakehouse 런타임 카탈로그의 업계 선도적인 일관성 보장 기능을 활용할 수 있습니다. Lakehouse 트랜잭션은 직렬화가 가능합니다. 데이터베이스 내 트랜잭션 순서는 클라이언트가 커밋된 트랜잭션을 관찰하는 순서와 동일합니다. 이러한 기반을 통해 Lakehouse 사용자는 에이전트 규모로 운영할 수 있습니다.

또한 에이전트 사용 사례를 더욱 강화하기 위해 Lakehouse 런타임 카탈로그는 Knowledge Catalog와 직접 통합되어 레이크하우스 Iceberg 테이블을 쉽게 검색하고 에이전트에 신뢰할 수 있는 컨텍스트를 제공합니다. Knowledge Catalog는 Spanner에서 제공하는 전체 텍스트 검색과 기본 벡터 검색의 효율적인 조합을 활용합니다. 이러한 접근 방식을 사용하면 단일 쿼리에서 어휘 키워드 검색과 시맨틱 임베딩을 페어링하여 검색 재현율을 높일 수 있습니다. 두 색인 유형 모두 동일한 기본 데이터 세트를 기반으로 빌드되므로, 기본 테이블 DML 작업과 동시에 엄격한 트랜잭션 ACID 일관성을 유지하며 업데이트됩니다. 이를 통해 동기화 파이프라인, 외부 벡터, 전체 텍스트 검색 시스템 관리와 같은 운영 오버헤드를 줄일 수 있습니다. 요약하자면, Lakehouse 런타임 카탈로그를 통해 에이전트형 사용 사례의 출시 기간(TTM)을 단축할 수 있습니다.

분석 워크로드와 운영 워크로드 결합

Apache Iceberg를 기반으로 하는 Google Cloud의 경계 없는 레이크하우스를 사용하면 분석 데이터를 운영 워크로드와 결합할 수 있습니다. 사용 사례로는 레이크하우스의 데이터 애셋을 OLTP 데이터(Spanner)와 결합하여 분석하는 것부터, Spanner와 같은 운영 데이터베이스에서 레이크하우스 애셋에 액세스할 수 있는 지연 시간이 짧은 서빙 애플리케이션, 퍼스트 파티 및 서드 파티 에이전트의 대화형 분석에 이르기까지 다양합니다.

아래 예시를 통해 Spanner와 결합된 Lakehouse 런타임 카탈로그가 실제로 어떻게 작동하는지 확인할 수 있습니다. 여기서는 Apache Iceberg를 기반으로 하는 맨해튼 택시 운행 분석 데이터와 Spanner에 저장된 택시 구역 운영 데이터를 결합하여 가장 혼잡한 교통 경로를 찾아봅니다. 또한 이 예시에서는 대화형 분석 에이전트를 사용하여 동일한 데이터에 액세스하고 2차 인사이트를 얻을 수 있음을 보여줍니다.

맨해튼에서 가장 정체가 심한 교통 경로 확인하기

경계 없는 레이크하우스로 현대화

Google Cloud의 레이크하우스로 현대화하면 분석 엔진과 에이전트 전반에서 데이터 사일로를 최소화하고, 멀티 엔진 거버넌스를 통합하고, 에이전트에 신뢰할 수 있는 컨텍스트를 제공하고, 운영 TCO를 대폭 절감할 수 있습니다. Spanner 기반 Lakehouse 런타임 카탈로그를 활용하면 에이전트 규모로 운영할 수 있도록 최신 클라우드 환경을 준비하는 데 도움이 됩니다. 자세히 알아보고 무료 체험을 시작하려면

레이크하우스 웹페이지를 방문하고 Spanner에 관한 자세한 내용은 여기에서 확인해 보세요.

분석 가속화: PayPal의 Managed Service for Apache Spark 도입 여정

Mon, 12 Oct 2026 04:00:00 +0000

데이터 중심의 세상에서 PayPal이 시의적절하고 실행 가능한 인사이트를 제공하는 능력은 경쟁에서 앞서 나가는 데 핵심적인 역할을 합니다. PayPal에서는 사기 감지부터 사용자 경험 개선에 이르기까지 다양한 영역에서 데이터를 활용하고 있습니다. 데이터는 에이전트형 솔루션과 경험의 잠재력을 발휘하는 데도 핵심적인 역할을 합니다.

하지만 시간이 지나면서 증가하는 수요를 충족하기 위해 온프레미스에 다양한 기술과 솔루션을 추가하다 보니 분석 환경이 복잡해졌습니다. 이 접근 방식은 당시의 요구사항을 충족하는 데는 효과적이었지만 점차 확장과 유지보수 측면에서 새로운 과제를 야기하기 시작했습니다.

까다로운 분석 환경의 과제 해결

빠른 성장과 여러 차례의 인수로 인해 PayPal의 데이터 분석 플랫폼은 점차 불균형하게 변했습니다. 새롭게 추가된 각 플랫폼과 통합 기능은 특정 비즈니스 요구사항을 해결했지만, 이러한 것들이 쌓이면서 운영 오버헤드가 커지고 성능 저하가 발생했습니다. 확장하기가 갈수록 어려워지고 프로세스가 복잡해지면서 인사이트 도출 시간도 늘어났습니다.

복잡한 환경이 낳은 정체

PayPal의 기존 데이터 분석 플랫폼은 매일 페타바이트 규모의 데이터를 처리할 정도로 강력했지만, 급속한 성장과 함께 점점 더 경직되었습니다. 대규모 쇼핑 이벤트나 글로벌 출시처럼 수요가 급증하는 시기에 시스템을 수직 확장을 하려면 몇 개월에 걸친 계획과 여유 있게 수동으로 진행하는 하드웨어 프로비저닝이 필요하며, 속도와 비용 사이에서 타협해야 하는 경우도 많았습니다.

PayPal은 비즈니스가 전 세계적으로 계속 확장됨에 따라 데이터 효율성을 높이고 혁신을 가속화하기 위해서는 간소화된 통합 인프라가 필요하다는 것을 인식했습니다.

솔루션: 통합된 클라우드 네이티브 분석

이러한 문제를 해결하기 위해 분석 워크로드를 기존 Hadoop 온프레미스 플랫폼에서 Google의 Managed Service for Apache Spark로 마이그레이션했습니다.

이러한 선택의 주요 이유는 다음과 같습니다.

신속한 프로비저닝 및 탄력적인 확장: Managed Spark를 통해 몇 분 만에 클러스터를 배포하고 처리 요구사항에 따라 확장할 수 있어 긴 설정 시간과 유휴 리소스로 인한 비용이 사라졌습니다.
통합 인프라: Apache Spark를 표준화하여 팀 간 일관성을 확보하는 한편, Managed Service for Apache Spark 및 기타 관리형 서비스를 활용하여 운영 복잡성을 줄였습니다.
원활한 통합: Google Cloud Storage(GCS), BigQuery, 기타 Google Cloud 서비스에 대한 기본 후크로 엔드 투 엔드 데이터 이동을 간소화했습니다.

이러한 전환을 통해 PayPal은 클라우드 네이티브 솔루션의 유연성, 확장성, 안정성을 활용하여 데이터 처리 역량을 현대화할 수 있었습니다. 여러 플랫폼에 분산되어 있던 워크플로와 일괄 작업을 하나의 클라우드 기반 분석 플랫폼으로 통합함으로써 데이터 사일로를 줄이고 더 빠르고 풍부한 인사이트를 제공하는 통합 데이터 기반을 구축했습니다.

그 결과 개발자와 애플리케이션팀은 인프라에 제약받지 않고 비즈니스 가치를 제공하는 데 집중할 수 있게 되었습니다. 중요한 것은 이러한 전환이 단순히 플랫폼을 바꾸는 것 이상의 의미를 지녔다는 점입니다. 새로운 실험 문화를 조성하여 팀이 변화하는 비즈니스 요구에 대응해 분석 워크로드를 빠르게 테스트, 조정, 배포할 수 있도록 지원했습니다.

결과: 더 빠른 인사이트, 더 낮은 오버헤드

Managed Spark를 활용하는 현대화된 Google Cloud 기반 생태계의 영향은 지대했습니다.

핵심 분석 워크로드의 처리 시간이 25% 개선되어 주요 비즈니스 운영에 대한 인사이트를 거의 실시간으로 확보할 수 있게 되었습니다.
시즌별 할인 이벤트와 같이 트래픽이 급증하는 기간에도 SLA 준수율이 30%나 크게 증가했습니다.
도구를 통합하고 수동 유지보수를 줄임으로써 운영 비용도 절감했습니다.

하지만 무엇보다 중요한 변화는 엔지니어가 문제 해결에 쏟는 시간을 줄이고 혁신에 더 많은 시간을 할애할 수 있게 되었다는 점입니다. 이제 고객과 파트너에게 가치를 제공하는 새로운 분석 기능의 프로토타입을 빠르게 제작할 수 있습니다.

파편화된 환경에서 일관된 클라우드 네이티브 플랫폼으로 전환하면서 PayPal의 분석 역량은 근본적으로 강화되었습니다. 비즈니스 요구사항이 계속 변화하는 가운데 확장 가능한 통합 데이터 기반에 투자하면 빠르고 정확하며 영향력 있는 인사이트를 확보하고, 전 세계 고객을 위한 지속적인 혁신을 주도할 수 있습니다. Managed Service for Apache Spark 도입은 이러한 현대적인 분석 기반을 구축하는 데 중요한 단계입니다.

지금 바로 Managed Service for Apache Spark와 BigQuery를 시작하여 에이전트형 데이터 클라우드를 빌드하는 방법을 자세히 알아보세요.

Google Cloud CLI 원격 MCP 서버로 에이전트 역량 강화

Sun, 11 Oct 2026 19:00:00 +0000

오늘 Google은 프리뷰 버전의 Google Cloud CLI 원격 MCP 서버를 새롭게 선보이며, 관리형 원격 MCP 서버 생태계를 확장합니다.

널리 사용되는 gcloud 및 bq(BigQuery) 명령줄 도구를 기반으로 하는 이 새로운 서버는 AI 에이전트가 Google Cloud 인프라를 관리하고 고급 BigQuery 워크플로를 안전하고 원활하게 처리할 수 있도록 명령줄 작업에 대한 즉각적이고 광범위한 액세스를 제공합니다.

AI 에이전트에 CLI가 중요한 이유

에이전트가 수행하는 클라우드 작업이 점점 더 복잡해지고 있지만, 백엔드 시스템과의 상호작용 방식을 표준화하는 일은 여전히 까다로운 과제로 남아 있습니다. Google Cloud CLI 원격 MCP 서버는 수백 개의 gcloud 및 bq 명령어의 다기능성을 하나의 MCP 서버로 패키징하여 이러한 격차를 해소합니다. 이를 통해 에이전트는 다음과 같은 두 가지 강력한 이점을 얻을 수 있습니다.

상위 수준 추상화: CLI 명령어는 다단계 API 조정을 요구하는 대신 복잡한 다단계 워크플로, 검증 확인, 상위 수준 작업을 통합 명령어로 패키징합니다.
모델 학습 활용: LLM은 공개 명령줄 문서, 문법, 사용 예시를 바탕으로 광범위하게 사전 학습되므로 모델에 대한 CLI 호출이 직관적이고 정확도가 높습니다.

원격 MCP 기반 CLI 활용의 장점

AI 에이전트로 클라우드 인프라를 관리하려면 일반적으로 에이전트 실행 환경 내에 Google Cloud CLI 바이너리를 설치하고 유지보수해야 합니다. Cloud CLI 원격 MCP 서버는 Google Cloud 인프라에 격리된 실행 샌드박스를 제공하여 CLI 기능과 MCP 이점을 연결합니다. 이를 통해 다음과 같은 주요 인프라 과제를 해결할 수 있습니다.

간소화된 종속 항목 및 런타임 관리: 커스텀 에이전트를 빌드하는 팀의 경우 개발, 테스트, 프로덕션 환경에서 로컬 CLI 버전과 종속 항목을 유지하는 데 운영 오버헤드가 발생합니다. 원격 MCP를 사용하면 로컬 설치와 런타임 유지보수의 번거로움이 사라집니다.
웹 기반 에이전트 엔드포인트에 대한 액세스: 웹 호스팅 에이전트 플랫폼 및 웹 인터페이스(예: Gemini Enterprise 및 기타 호스팅된 엔터프라이즈 에이전트 플랫폼)는 사용자가 로컬 패키지를 제어하거나 설치할 수 없는 환경에서 실행됩니다. 원격 MCP를 사용하면 이러한 인터페이스에서 Google Cloud CLI 작업에 안전하게 관리형 방식으로 직접 액세스할 수 있습니다.

엔터프라이즈급 보안 및 거버넌스

AI 에이전트를 인프라에 연결하려면 엄격한 엔터프라이즈급 보호 장치가 필요합니다. 이 원격 서버는 Google Cloud의 표준 ID 및 거버넌스 프레임워크를 활용하여 환경을 안전하게 보호합니다.

제로 앰비언트 사용자 인증 정보: 서버는 앰비언트 사용자 인증 정보가 없는 네트워크 제한 프록시 경계에서 실행을 격리합니다. 인증 및 승인은 에이전트 아이덴티티, OAuth 2.0, Identity and Access Management (IAM)를 통해 처리됩니다.
엄격한 정책 시행: 원격 MCP 서버를 통해 실행되는 모든 명령어는 인증된 호출자 ID의 권한으로 실행됩니다. 표준 IAM 권한과 조직 정책 서비스 제약조건 모두 다운스트림 대상 리소스에 엄격하게 적용됩니다.
Model Armor를 통한 고급 보호: AI 도구 호출과 관련된 위험을 최소화하기 위해 Cloud CLI 원격 MCP 서버는 Model Armor와 통합됩니다. LLM 프롬프트와 응답을 선제적으로 검사하여 프롬프트 인젝션 및 악성 입력과 같은 위험으로부터 보호할 수 있습니다.
Cloud 감사 로깅: Cloud CLI 원격 MCP 서버는 모든 도구 호출을 감사 로그(cloudcli.googleapis.com/mcp의 데이터 액세스 로그)에 기록하도록 구성할 수 있습니다. 보안팀은 민감한 명령어 페이로드나 개인 식별 정보(PII)를 노출하지 않고도 호출자 ID, OAuth 클라이언트, IAM 승인 결정(mcp.googleapis.com/tools.call)을 완벽하게 파악할 수 있습니다.

Google Cloud CLI 원격 MCP 서버에 연결

클라우드 관리를 에이전트에 통합할 때 더 이상 Google Cloud CLI 바이너리를 패키징하거나, 로컬 실행 런타임을 관리하거나, 에이전트 컨테이너 이미지 내에서 종속 항목을 유지할 필요가 없습니다. Google Cloud CLI 원격 MCP 서버는 표준 모델 컨텍스트 프로토콜을 구현하므로 MCP 호환 에이전트 플랫폼 또는 조정 런타임은 표준 구성을 통해 즉시 연결할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "mcpServers": {\r\n "google-cloud-cli": {\r\n "uri": "https://cloudcli.googleapis.com/mcp",\r\n ...\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccd6a1b50>)])]>

에이전트는 네트워크가 격리된 안전한 클라우드 샌드박스에서 gcloud 및 bq 명령어를 실행할 수 있는 액세스 권한을 즉시 얻습니다.

인증은 호스팅된 Google Cloud 플랫폼의 경우 키 없는 에이전트 아이덴티티를 통해 처리되고, 외부 런타임의 경우 표준 OAuth 2.0을 통해 처리됩니다. 인증 옵션은 MCP 인증 가이드를 참고하세요.

에이전트에 인프라 관리 기능 제공

Cloud CLI 원격 MCP 서버는 두 가지 강력한 도구인 run_gcloud_command와 run_bq_command를 노출하여 AI 에이전트가 자연어를 통해 Google Cloud 작업에 광범위하고 즉각적으로 액세스할 수 있도록 합니다.

run_gcloud_command를 사용하여 클라우드 인프라 관리

run_gcloud_command를 사용하면 에이전트가 광범위한 gcloud 작업을 실행하여 Google Cloud 환경을 관리하고, 진단하고, 보호할 수 있습니다. 예시는 다음과 같습니다.

모니터링 가능성 및 사고 진단: 에이전트는 명령어 실행을 자동화하고 도구 간 컨텍스트 전환을 줄여 사고 진단을 간소화합니다.

run_bq_command 도구를 사용한 BigQuery 작업 확장

BigQuery MCP 서버는 이미 AI 에이전트를 통한 데이터 분석 및 탐색을 지원하고 있습니다. 여기에 run_bq_command가 도입되면서, 이제 에이전트는 bq CLI의 모든 기능을 활용해 리소스 할당, 작업 모니터링, 작업 예약과 같은 고급 BigQuery 작업을 수행할 수 있게 되었습니다. 주요 기능은 다음과 같습니다.

예약된 쿼리 자동화: 에이전트가 BigQuery Data Transfer Service 구성을 사용하여 쿼리 예약 작업을 자동으로 수행합니다.
작업 및 리소스 관리: 처리된 데이터 볼륨, 슬롯 사용량, 실행 계획을 포함한 쿼리 실행 세부정보에 대한 심층적인 인사이트를 얻고 예약을 관리합니다.
액세스 및 권한 제어: 데이터 관리자와 소유자는 에이전트를 통해 직접 테이블 권한을 검사하고 업데이트할 수 있습니다.

가격 책정 및 가용성

Google Cloud CLI MCP 서버를 오늘부터 공개 프리뷰로 만나보실 수 있습니다. MCP 서버 자체를 사용하는 데는 추가 요금이 부과되지 않습니다. 직접 생성한 GCP 리소스와 해당하는 데이터 전송 비용에 대해서만 비용을 지불하면 됩니다.

시작하려면 Google Cloud 프로젝트에서 Cloud CLI Execution API (`cloudcli.googleapis.com`)를 사용 설정하고, 에이전트 또는 사용자 ID에 필요한 MCP 도구 사용자 (`roles/mcp.toolUser`) IAM 역할을 부여하고, MCP 클라이언트가 `cloudcli.googleapis.com/mcp`에 연결되도록 구성합니다.

지리 공간 코딩을 가속화하는 새로운 Google Earth Engine 기능인 Ask 소개

Tue, 06 Oct 2026 19:00:00 +0000

전 세계 산림 면적을 매핑하거나, 건조 환경의 변화를 감지하거나, 농업 수확량을 모니터링하는 등 어떤 작업을 하든 Google Earth Engine에서 스크립트를 작성하면 이러한 인사이트를 발전시키는 데 큰 도움이 됩니다. 이 플랫폼은 지구 정보를 실제 활용 가능한 인텔리전스로 변환하는 데 도움이 되도록 설계된 지리 공간 모델 및 데이터 세트 모음인 Google Earth AI의 일부입니다. 그리고 Google은 이러한 지구 인텔리전스에 더욱 쉽게 액세스할 수 있는 새로운 기능인 Ask를 출시했습니다.

복잡한 지리 공간 로직을 코드로 변환하는 데는 시간이 걸리며, 특정 Google Earth Engine API 함수를 기억하고, 문서를 검색하고, 문법 또는 메모리 오류를 디버깅하는 과정에서 흐름이 끊길 수 있습니다. Ask는 Gemini 기능을 Google Earth Engine 코드 편집기에 직접 통합하여 실제 활용 가능한 인사이트를 더 빠르게 얻을 수 있도록 설계되었습니다.

오늘부터 사용자는 자체 Gemini API 키를 사용하여 코드 편집기를 벗어나지 않고도 지리 공간 쿼리를 작성, 디버그, 이해, 최적화할 수 있습니다.

그림 1: 새로운 Ask 패널은 코드 편집기의 오른쪽에 있으며, 활성 스크립트에 맞춤화된 채팅 기반 AI 지원을 제공합니다.

작동 방식: 컨텍스트 인식 지원

코드 편집기에서 바로 질문하고, 다음과 같은 작업공간의 컨텍스트를 기반으로 답변을 받을 수 있습니다.

활성 스크립트의 전체 텍스트
가져온 애셋 및 도형
활성 세션 채팅 기록

Google Earth Engine의 Gemini 기능은 사용자의 작업을 자동으로 파악하므로 코드를 추가하거나 데이터 세트를 설명할 필요가 없습니다. Gemini가 이미 이러한 세부정보를 알고 있으므로 더 관련성 있고 유용한 답변을 제공할 수 있습니다. 또한 차이점을 자동으로 확인하고 스크립트에 병합할 수 있기 때문에 더 이상 복사하여 붙여넣을 필요가 없습니다.

Ask를 맞춤설정하여 대답을 더 포괄적이고 필요에 맞게 만들 수도 있습니다.

최신 Gemini 모델에 액세스: 필요에 맞는 Gemini 모델을 선택하세요. 출시 시점에 사용 가능한 모델은 Gemini 3 Flash 프리뷰, Gemini 3.1 Pro 프리뷰, Gemini 3.5 Flash입니다.
문서 검색: AI를 사용하여 공식 문서에서 최신 문법과 함수를 검색합니다.
데이터 세트 검색: AI가 Earth Engine Data Catalog를 검색하여 필요한 정확한 데이터 세트를 찾고 참조할 수 있도록 합니다.
Google 검색: 'Google 검색을 사용한 그라운딩'으로 최신 공개 웹 검색 결과를 바탕으로 대답을 제공합니다(문서 검색 및 데이터 세트 검색과 동시 사용 불가).

빠른 시작 예시

어떻게 시작해야 할지 막막하신가요? 워크플로에서 다음과 같은 네 가지 방법으로 Ask를 사용할 수 있습니다.

1. 자연어로 코드 생성

NDVI(정규화 식생 지수)를 계산하거나, 구름 마스크를 적용하거나, 차트를 빌드해야 하는데 정확한 문법이 기억나지 않으시나요? 질문만 하면 Earth Engine이 JavaScript 코드를 생성해 줍니다. 채팅에서 직접 코드를 검토하고 삽입을 클릭하여 스크립트에 추가하거나 클립보드에 복사할 수 있습니다. 편집기가 비어 있지 않은 상태에서 코드를 삽입하면 나란히 비교하는 차이 보기가 표시되므로 변경사항을 수락하기 전에 검토할 수 있습니다.

프롬프트 예시: "콜로라도주 볼더 지역의 2025년 Sentinel-2 영상을 로드하고, 구름 마스크를 적용하고, NDVI를 계산하고, 중앙값 합성 이미지를 지도에 추가하는 스크립트를 작성해 줘."

2. 복잡한 코드 설명

동료가 작성한 스크립트를 사용하거나 커뮤니티의 예시를 조정하는 경우 Gemini 기능을 사용하여 설명할 수 있습니다. "이 스크립트가 무슨 작업을 하는지 설명해 줘"라고 요청하기만 하면 사용 중인 로직과 Earth Engine 함수를 단계별로 분석해 줍니다.

3. 원클릭 문제 해결 및 디버깅 수행

디버깅은 코딩에서 피할 수 없는 과정입니다. Google Earth Engine에서 스크립트가 오류를 발생시키면 콘솔에 오류 메시지가 표시됩니다. 이제 이러한 메시지에 '문제 해결' 버튼이 포함됩니다. 이 버튼을 클릭하면 오류 메시지와 함께 문제를 진단하고 해결 방법을 제안해 달라는 요청이 포함된 프롬프트가 Ask 패널에 자동으로 채워집니다.

그림 2: 콘솔의 '문제 해결' 버튼을 사용하면 오류를 빠르고 원활하게 디버깅할 수 있습니다.

4. 쿼리 최적화

예를 들어 스크립트가 느리게 실행되거나, 리소스를 비효율적으로 사용하거나, '계산 시간 초과' 또는 '동시 집계가 너무 많음' 오류가 발생하는 경우 최적화 팁을 요청해 보세요. Gemini 기능으로 조기 필터링, 계산 단계 축소, 클라이언트 측 루프를 서버 측 작업으로 변환하는 등의 권장사항을 제안할 수 있습니다.

2단계로 시작하기

Ask는 현재 전 세계에서 이용 가능합니다. 시작하려면 Gemini API 키만 있으면 됩니다.

API 키 가져오기: 아직 Gemini API 키가 없다면 Google AI Studio로 이동하여 키를 만드세요. 무료 옵션도 있으며, 유료 등급 API 키를 선택하면 사용량에 따라 요금이 청구됩니다. Gemini API 약관에 대해 자세히 알아보세요.
GEE에 API 키 추가: Google Earth Engine 코드 편집기를 엽니다. 오른쪽 패널에서 Ask 패널을 클릭합니다. 왼쪽 하단에 있는 키 아이콘을 클릭하고 API 키를 입력합니다.

여러분의 의견을 들려주세요. 코드 편집기 의견 버튼을 사용하여 의견을 공유하여 사용자 환경을 개선하는 데 도움을 주세요.

Apache Spark 가용성 극대화: 컴퓨팅 용량 부족 문제 해결을 위한 가변형 VM 및 기타 권장사항

Mon, 05 Oct 2026 22:00:00 +0000

AI 개발이 급증하면서 컴퓨팅 용량에 대한 수요가 전 세계적으로 전례 없이 증가하고 있습니다. 이러한 상황은 Apache Spark를 활용한 데이터 처리 및 파이프라인에 부정적인 영향을 미칠 수 있으며 자체 Spark 인프라를 관리하거나 관리형 서비스를 사용할 때 가용성 제약에 직면할 수 있습니다. 하지만 Google의 Managed Service for Apache Spark를 사용하면 가변형 VM이라는 큰 이점을 누릴 수 있습니다. 가변형 VM은 동적이고 특정 리소스에 구애받지 않는 접근방식을 구현하는 특화된 메커니즘으로서 리전이나 영역에 용량이 부족한 상황에서도 파이프라인을 계속 운영할 수 있도록 지원합니다.

용량 부족에 대한 이해

대상 영역이나 리전에서 특정 머신 계열(예: N2 또는 N2D)에 대한 수요가 사용 가능한 용량을 초과하면 용량 부족이 발생합니다. 적시 처리가 중요한 분석 파이프라인에서 특정 VM 유형만 사용하도록 제한하면 일반 프로비저닝 과정 자체가 단일 장애점이 되어 클러스터 생성 지연이나 실행 장애로 이어질 수 있으며, 비즈니스 SLA에 영향을 미칠 가능성도 있습니다.

가변형 VM

가변형 VM은 Managed Spark 클러스터가 컴퓨팅 리소스를 요청하는 방식을 근본적으로 바꿉니다. 가변형 VM을 사용하면 클러스터를 하나의 고정된 인스턴스 유형에 결합하는 대신, 마스터 노드, 기본 워커 노드, 보조 워커 노드에 사용할 수 있는 머신 계열의 우선순위 목록을 설정할 수 있습니다.

주요 특징

다중 머신 계열 혼합: 하나의 구성에 2세대 계열(N2, N2D 등)과 4세대 계열(N4, C4 등)처럼 서로 다른 머신 유형과 세대의 노드를 조합할 수 있습니다.
혼합 스토리지 지원: 기본 호스트 계열에서 지원하는 디스크 유형에 맞게 스토리지 옵션을 동적으로 조정하여 사용 가능한 용량 풀을 확대할 수 있습니다.
포괄적인 클러스터 적용 범위: 기본 워커, 보조(선점형/스팟) 워커, 마스터 노드에 가변형 규칙을 적용하여 엔드 투 엔드로 클러스터 프로비저닝을 보장합니다.

순위 기반 구성: 성공적인 구현을 위한 전략

가변형 VM을 성공적으로 구현하려면 전략적인 순위 지정이 필요합니다. 옵션의 명확한 우선순위 체계를 정의하면 Managed Spark 클러스터가 자동으로 프로비저닝을 시도하여 수동 개입 없이 체계적으로 용량 부족 위험을 해소합니다. 적합한 VM의 가용성을 개선하려면 우선순위가 가장 높은(0순위) 가변형 VM 목록에 머신 계열을 2개 이상 지정하는 것이 좋습니다.

예를 들어 n2d-standard-16 형태를 표준으로 사용하는 프로덕션 파이프라인의 경우, 다음과 같은 계층화 전략을 통해 용량 부족 상황에서도 높은 복원력을 확보할 수 있습니다.

순위	머신 계열 예시	권장 스토리지
0순위(기본)	n2d-standard-16, n2-standard-16	표준 로컬 SSD 또는 PD
1순위	n4-standard-16, n4d-standard-16	Hyperdisk Balanced
2순위	c4-standard-16, c3-standard-22	Hyperdisk Balanced
3순위	e2-standard-16	표준 PD

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create $CLUSTER_NAME \\\r\n--num-workers=10 \\\r\n--zone="" \\\r\n--region=us-east1 \\\r\n--worker-instance-selection=\'{"machineTypes":["n2d-standard-16","n2-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"pd-standard","bootDiskSizeGb":400}}\' \\\r\n--worker-instance-selection=\'{"machineTypes":["n4-standard-16","n4d-standard-16"],"rank":1,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":400}}\' \\\r\n--worker-instance-selection=\'{"machineTypes":["c4-standard-16","c3-standard-22"],"rank":2,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":400}}\' \\\r\n--worker-instance-selection=\'{"machineTypes":["e2-standard-16"],"rank":3, "diskConfig":{"bootDiskType":"pd-ssd","bootDiskSizeGb":400}}\' \\\r\n--master-instance-selection=\'{"machineTypes":["n4-standard-16","n4d-standard-16"],"rank":0,"diskConfig":{"bootDiskType":"hyperdisk-balanced","bootDiskSizeGb":400}}\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8cc3e8c4d0>)])]>

기존 n1-standard-16 형태를 표준으로 사용하는 파이프라인의 경우, 다음 계층화 전략을 사용하면 운영 안정성을 유지하면서 워크로드를 가용성이 높은 최신 아키텍처로 전환할 수 있습니다.

순위	머신 계열 예시	권장 스토리지
0순위(기본)	n1-standard-16 n2-standard-16	표준 로컬 SSD 또는 PD
1순위	n2d-standard-16	표준 로컬 SSD 또는 PD
2순위	n4-standard-16 n4d-standard-16	Hyperdisk Balanced
3순위	e2-standard-16	표준 PD

Hyperdisk Balanced 활용

가변형 VM으로 가용성을 극대화하려면 Hyperdisk Balanced와 같은 최신 스토리지 아키텍처를 도입해야 하는 경우가 많습니다. 최신 인스턴스 계열(N4 및 C4 포함)은 Hyperdisk를 사용하여 다양한 VM 크기에서 예측 가능한 성능을 제공합니다. 일반적으로 기본 IOPS 및 처리량 설정만으로도 대부분의 분산 Spark 작업을 안정적으로 수행할 수 있는 기준이 됩니다.

장단점 및 주요 고려사항

가변형 VM은 클러스터 프로비저닝 성공률을 크게 향상시키지만, 이를 엔터프라이즈 요구사항에 맞추려면 다음과 같은 몇 가지 아키텍처 및 재무 요소를 평가해야 합니다.

1. 리소스 할당량

이제 특정 머신(예: N2)의 할당량을 확보하는 것만으로는 충분하지 않습니다. 가변형 VM 목록에 정의된 모든 머신 유형 및 디스크(Hyperdisk 포함)에 컴퓨팅 및 디스크 할당량이 충분히 확보되어 있는지 확인해야 합니다.

2. Compute 가변형 약정 사용 할인(CUD)

기존의 리소스 기반 약정 사용 할인(CUD)은 특정 머신 계열에 연결되어 있어 유연성이 제한됩니다. 여러 VM 계열과 리전에 걸쳐 비용을 절감할 수 있도록 Compute 가변형 약정 사용 할인(CUD)을 활용해 보세요.

3. 성능 특성

머신 세대에 따라 성능이 달라질 수 있으며, Local SSD와 Hyperdisk 간에도 성능 차이가 발생할 수 있습니다. Managed Spark팀에서 이러한 차이를 비교할 수 있는 내부 벤치마크를 제공하지만 실제 결과는 워크로드에 따라 달라집니다. 따라서 이러한 머신 계열에서 사용하는 Spark 작업을 직접 테스트하여 SLA에 미치는 영향을 파악하는 것이 중요합니다.

추가 권장사항

가변형 VM을 구현하는 것 외에도 리소스 가용성과 워크로드 안정성을 높이는 데 도움이 되는 몇 가지 주요 아키텍처 및 일정 관리 전략이 있습니다.

AutoZone: 현재 용량을 기반으로 Managed Spark가 작업 실행에 가장 적합한 영역을 자동으로 선택할 수 있도록 AutoZone 라우팅을 도입하세요.
더 작은 머신 형태: 높은 수요가 발생하는 대규모 코어 구성을 피하세요. 4, 8, 16개 코어처럼 더 작은 머신 형태를 활용하는 워크로드와 YARN 컨테이너를 설계하세요. 이러한 소규모 구성은 사용 가능한 GCE 온디맨드 풀에서 용량을 확보하기가 훨씬 쉽습니다.
자동 확장: 적절한 maxInstances를 지정하여 클러스터 자동 확장을 배포하세요. 이를 통해 대규모 리소스를 처음부터 고정적으로 프로비저닝하지 않고도 갑작스럽게 증가하거나 예측하기 어려운 워크로드에 필요한 용량을 효과적으로 관리할 수 있습니다.
부분 클러스터 생성: 허용 가능한 최소 기본 워커 수를 구성하세요. 이렇게 하면 리소스가 부족한 상황에서도 클러스터를 가동하여 작업을 실행할 수 있으며, 이후에 리소스를 사용할 수 있게 되면 자동 확장을 통해 나머지 워커를 동적으로 추가할 수 있습니다.
리전 대체 설정: us-central1과 같은 일부 리전에서는 높은 수요가 발생할 수 있습니다. 다른 리전을 대체 옵션으로 설정하면 용량 부족 위험을 줄일 수 있습니다.

가변형 VM으로 Spark 작업을 중단 없이 실행하세요

자체 Apache Spark 인프라를 직접 관리하는 일은 매우 까다로울 수 있습니다. 특히 리소스 용량 부족으로 데이터 처리가 중단되는 상황이 발생하면 더욱 그렇습니다. Managed Service for Apache Spark와 같은 관리형 서비스를 활용하면 플랫폼에 기본 제공되는 복원력과 가변형 VM 사용 등 고유한 이점을 얻을 수 있습니다. 가변형 VM과 함께 우선순위 기반 대체 전략을 도입하면 리전의 하드웨어 부족으로부터 워크로드를 보호하고 중요한 파이프라인을 지속적으로 실행할 수 있습니다.

Spark 워크로드의 복원력을 높일 준비가 되셨나요? 지금 바로 Managed Spark 클러스터에 가변형 VM을 구성해 보세요.

AI 에이전트가 준비되었습니다. 그렇다면 데이터는 어떤가요?

Thu, 01 Oct 2026 21:00:00 +0000

조직이 AI 이니셔티브를 확장하는 데 있어 가장 큰 병목 현상 중 하나는 무엇일까요? 오늘날 모델의 기능이 아니라 비즈니스 컨텍스트와 시맨틱 의미에 대한 액세스 권한이 문제입니다.

에이전트 시대에 기업은 단순히 데이터를 저장하는 것을 넘어 신뢰할 수 있는 컨텍스트로 데이터를 활성화하여 수동적인 기록 시스템에서 선제적인 행동 시스템으로 전환해야 합니다.

하지만 AI 에이전트는 비선형 속도로 작동합니다. 예를 들어 단일 프롬프트로 에이전트가 여러 시스템에서 독립적으로 탐색, 쿼리, 실행을 수행하도록 트리거할 수 있어 기본 인프라에 부담을 줄 수 있습니다. 컴퓨팅, 네트워킹, 스토리지 레이어가 에이전트 AI에 최적화되어 있지 않으면 그 위에 있는 데이터 플랫폼이 제대로 작동하지 않습니다.

Google Cloud의 인프라 현황 보고서 에 따르면 조직의 83% 가 프로덕션급 에이전트 AI 시스템을 지원하려면 인프라를 업그레이드해야 한다고 생각하는 것은 당연한 일입니다.

이 문제를 해결하기 위해 Google Cloud는 2026년 Google Cloud Next에서 데이터, AI 모델, 운영 데이터베이스를 단일 작업 시스템으로 통합하는 에이전트형 데이터 클라우드를 도입했습니다. 에이전트형 데이터 클라우드가 작동하려면 칩에서 모델에 이르기까지 AI 네이티브여야 합니다. 기본 인프라는 에이전트 부하를 수용할 수 있어야 합니다.

Google의 에이전트형 데이터 클라우드

적절한 인프라 기반이 에이전트형 데이터 클라우드에 어떤 힘을 실어주어 오늘날 조직이 직면한 가장 큰 데이터 문제를 해결할 수 있는지 살펴보겠습니다.

컨텍스트 부족 극복

에이전트형 시스템이 효과적으로 작동하려면 분산된 데이터 시스템과 기존 아키텍처에서 자주 발견되는 컨텍스트에 액세스할 수 있어야 합니다. 이로 인해 에이전트가 이러한 컨텍스트를 파악하기 어려워 불완전하고 부정확한 결과가 나올 수 있습니다. 실제로 Google Cloud 보고서에 따르면 IT 리더의 43% 가 '레거시 API 및 데이터 소스와의 통합이 어려움'을 에이전트 AI 인프라의 가장 큰 허점으로 꼽았습니다.

하지만 조직은 복잡성과 비용을 늘리지 않고는 대규모 데이터 세트를 이동하여 AI에 연결할 수 없습니다.

Google의 에이전트형 데이터 클라우드는 개방적이고 유연한 인프라에서 실행되는 경계 없는 레이크하우스 를 활용하여 이 문제를 해결합니다. 에이전트는 개방형 표준 (Apache Spark, Apache Iceberg)을 통해 BigQuery 및 Spanner와 같은 강력한 기본 엔진에 액세스하여 마치 로컬 데이터인 것처럼 환경 전반에서 데이터를 읽고, 추론하고, 활성화할 수 있으므로 기존 설정의 지연 시간과 비용을 우회할 수 있습니다.

불필요한 수동 작업에서 벗어나기

연결되지 않은 시스템의 패치워크에서 에이전트를 확장하면 상당한 병목 현상이 발생할 수 있습니다. Google Cloud의 연구에 따르면 리더의 81% 가 AI를 확장할 때 예상치 못한 비용이 발생하는 주요 원인으로 운영 복잡성과 엔지니어링 오버헤드를 꼽았습니다 . 서로 다른 시스템 전반에 걸쳐 AI 에이전트를 연결하기 위해 엔지니어가 수동으로 작업하는 데 드는 시간을 그 이유로 들었습니다.

생각에서 행동으로 옮기려면 에이전트는 분석 소스와 운영 소스 모두에서 실시간 데이터를 연결할 수 있어야 합니다. 이를 위해서는 수직적 통합이 필요합니다. 모델, 데이터 시스템, 기본 가속기가 공동 설계된 AI 네이티브 인프라를 기반으로 에이전트형 데이터 클라우드를 빌드하면 네트워크 홉이 줄어들고 도구가 더 잘 통합됩니다. 이 통합 시스템을 사용하면 에이전트가 일반적인 엔지니어링 오버헤드 없이도 인사이트에 도달하고 안전한 트랜잭션을 트리거할 수 있습니다.

데이터에 신뢰와 지식 제공

에이전트가 데이터를 발견하고 쿼리하는 것만으로는 충분하지 않습니다. 안전하고 정확한 조치를 취하려면 에이전트에게 풍부한 컨텍스트와 비즈니스 로직도 필요합니다. 그러나 AI 모델 그라운딩에 사용되는 특화된 고처리량 벡터 데이터베이스가 부족하다는 점을 주요 인프라 격차로 꼽은 리더가 36% 에 달하며, 이는 에이전트에게 컨텍스트를 제공하는 능력을 저해하는 요인으로 작용합니다.

에이전트가 잠재력을 최대한 발휘하려면 기존 ERP와 서드 파티 CRM을 포함한 데이터 시스템을 실시간으로 읽고 쓸 수 있도록 빌드된 기반이 필요합니다. 또한 3주 전에 사용자가 설정한 선호도를 기억한 상태로 현재 복잡한 작업을 수행할 수 있는 장기 기억 능력이 필요합니다. 이러한 실시간 자동화가 없으면 에이전트는 모든 쿼리에 대해 데이터를 다시 처리해야 합니다.

AI에 컨텍스트를 제공하기 위해 조직은 Knowledge Catalog를 사용하여 데이터 레이크의 데이터를 집계하고 보강하며 에이전트형 검색을 지원하고 있습니다. 비정형 데이터에서 의미를 추출하고 시맨틱스를 자동으로 생성하는 카탈로그는 활성 추론 레이어 역할을 합니다. 에이전트가 올바른 컨텍스트를 검색할 수 있도록 이 카탈로그는 처리량이 높은 인프라로 뒷받침되어야 합니다.

앞으로의 방향

AI를 진정한 경쟁 우위로 전환하려면 연결된 활성 데이터 생태계를 구축해야 합니다. 파일럿에서 프로덕션으로 전환하려면 에이전트가 모든 데이터에 원활하게 액세스할 수 있어야 하며, 이를 위해서는 에이전트 시대의 요구사항을 처리할 수 있는 인프라가 지원되어야 합니다. 2026년 이후의 승자는 반드시 가장 스마트한 에이전트를 보유한 기업이 아닐 것입니다. 이들은 에이전트에 적절한 지식을 안전하고 비용 효율적으로 대규모로 제공할 수 있는 사람들입니다. 데이터는 에이전트 시대에 맞게 준비되어 있나요?

에이전트 AI 시대의 인프라 현황 보고서에서 리더들이 AI에 최적화된 아키텍처 접근방식을 어떻게 취하고 있는지 확인해 보세요.

조정의 미래: Google Cloud에서 Airflow 3로 전환한 Pine59의 여정

Wed, 30 Sep 2026 13:00:00 +0000

대규모 데이터 파이프라인을 운영하려면 워크로드가 커짐에 따라 원활하게 확장되는 조정 레이어가 필요합니다. 파이프라인에서 매일 수백만 개의 복잡한 데이터 포인트를 처리하여 예측 모델에 공급하는 경우 기술 스택을 최신 상태로 유지하는 기술은 전략적 필수 요소입니다.

Pine59에서는 시간, 분기 등 다양한 주기로 분석 측정항목을 생성하는 데이터 파이프라인을 통해 위치 인텔리전스 데이터를 제공합니다. 이 기업의 데이터 집약적인 측정항목 중 하나인 일일 오프라인 매장 방문수의 경우 단일 작업으로 최대 1,400만 개의 고유 위치에 대한 데이터를 계산합니다. 이 방대한 양을 처리하기 위해 Pine59는 시스템을 전적으로 Google Cloud에서 실행합니다. 번거로운 작업은 BigQuery에 맡기고 Apache Airflow 3을 실행하는 Managed Service for Apache Airflow(이전 명칭: Cloud Composer)에서 모든 작업을 조정합니다.

기업의 데이터 볼륨과 머신러닝 워크로드 수가 증가함에 따라 Pine59는 수백 개의 방향성 비순환 그래프(DAG)가 포함된 모노레포를 현대화하기로 결정했습니다. 이 같은 전환을 통해 Pine59의 MLOps 기능, 개발자 워크플로, 파이프라인 속도가 어떻게 개선되었는지 살펴보겠습니다.

성장을 위한 선제적 현대화

Pine59는 오랫동안 여러 프로젝트의 코드와 도구가 포함된 공유 모노레포를 사용하여 측정항목 프로덕션 파이프라인을 실행해 왔습니다. 이 기업에서는 인프라의 미래를 고려하여 데이터 파이프라인의 실행 속도와 안정성을 높이고자 했습니다.

그래서 Airflow 3를 실행하는 새로운 Managed Airflow(3세대) 아키텍처를 대상으로 프로덕션 워크로드의 스트레스 테스트를 수행하기로 결정했습니다. 초기 결과는 명확했습니다. 3세대 환경은 즉각적이고 상당한 처리 속도, 작업 스케줄링, 전반적인 안정성의 개선을 가져왔습니다. 성능 향상의 가능성을 확인한 Pine59는 새로운 환경으로의 전면적인 전환을 시작했습니다.

고급 MLOps 조정

Pine59의 파이프라인은 데이터를 이동하는 데 그치지 않고 복잡한 ML 모델까지 구동합니다. 따라서 마이그레이션의 핵심은 ML 추론 워크로드의 조정을 최적화하는 것이었습니다.

이전에는 이러한 작업에 표준 Kubernetes 연산자를 사용했습니다. 이 기업의 엔지니어링팀은 고도로 최적화되고 추상화된 인프라 레이어를 특징으로 하는 Managed Airflow(3세대)로 전환하여 MLOps 아키텍처를 개선했습니다. 이를 위해 모델 추론에 특히 최적화된 전용 Google Kubernetes Engine(GKE) 클러스터를 설정하여 Pine59 파이프라인에 통합했습니다.

조정과 대규모 ML 실행 컴퓨팅을 명확하게 분리함으로써 데이터 처리와 모델 추론을 효율적으로 실행할 수 있게 되었습니다. 이는 Managed Airflow가 엔터프라이즈 MLOps를 위한 복원력과 확장성을 갖춘 기반임을 보여주는 사례입니다.

커스텀 확장성을 통한 개발자 지원

인프라가 개선되었음은 물론 Airflow 3의 크게 개선된 개발자 워크플로와 사용자 인터페이스도 즉시 활용할 수 있었습니다. 실제로 수백 개의 상호 연결된 DAG를 관리하려면 뛰어난 모니터링 가능성이 필요한데, Pine59는 Airflow 3의 플러그인 작성 시스템이 사용하기 매우 쉽다는 것을 알게 된 후

내부 개발자 속도를 개선하기 위해 새로운 Airflow UI에 직접 통합되는 여러 커스텀 플러그인을 빠르게 빌드했습니다.

BigQuery 자동 링크화: Airflow 로그 및 XCom 탭 내에서 내부 BigQuery 테이블 참조를 자동으로 감지하고 BigQuery Studio에 대한 직접 링크를 동적으로 생성하여 더 빠르게 디버깅할 수 있는 도구입니다(공개 GitHub gist로 제공).
DAG 실행 구성 검색: DAG 개요 페이지에 바로 추가되는 커스텀 검색 양식입니다. 이를 사용하면 Pine59 엔지니어가 DAG 실행 페이로드(구성) 내에서 특정 키-값 쌍을 쿼리하고 일치하는 실행을 즉시 표시할 수 있어 문제 해결 시간이 대폭 단축됩니다.

또한 모노레포 내에 호환성 Shim 레이어도 배포했습니다. 이 'compat' 모듈은 Airflow 버전 간의 로직을 동적으로 추상화하여 버전 간 연산자 마이그레이션을 간소화합니다.

더 빠르고 안정적인 파이프라인

Pine59는 Airflow 3를 사용하는 Managed Airflow(3세대)로 마이그레이션하여 정량화할 수 있는 명확한 결과를 얻었습니다.

가장 중요한 개선사항은 DAG 실행 속도였습니다. 이전 설정에서는 처리량이 급증할 때 작업이 큐에 추가된 상태로 멈추는 경우가 많았습니다. 3세대에서는 큐 지연 시간이 크게 줄어들어 작업 실행이 거의 즉시 시작됩니다.

아래에서 Airflow 2.11을 사용하는 Managed Airflow(2세대)와 Airflow 3.1을 사용하는 Managed Airflow(3세대)에서 동일한 DAG를 300회 이상 실행하여 합산한 '큐에 추가됨' 및 '실행 중'의 총 시간을 비교해 보세요. 큐에 추가됨 시간의 차이가 상당함을 알 수 있습니다.

전환 과정에서 내부 DAG 최적화까지 실행한 결과 성능도 크게 향상되었습니다. 예를 들어 이전에는 일일 오프라인 매장 방문수 파이프라인을 완료하는 데 거의 38분이 걸렸습니다. 새 인스턴스에서는 동일한 워크로드를 처리하는 데 26분도 채 걸리지 않아 처리 시간이 약 32% 단축됩니다.

현재 Pine59는 새로운 Managed Airflow(3세대) 인스턴스에서 모든 프로덕션 워크로드를 처리하고 있습니다. 차세대 조정으로 전환함으로써 이 기업은 MLOps 기능을 개선하고 개발자에게 더 나은 도구를 제공하며 미래의 워크로드를 위한 더 빠르고 복원력 있는 기반을 구축했습니다.

엔지니어링팀이 가치를 제공하기보다 인프라 관리에 더 많은 시간을 할애하고 있다면 전환을 고려해 보시기 바랍니다. 오늘 바로 이러한 전환이 서버 유지보수에서 벗어나 데이터 및 AI 파이프라인의 미래를 구축하는 데 어떤 도움이 되는지 알아보세요.

^{이 게시물을 작성하는 데 도움을 주신 Alexandre Crespo-Perez에게 감사의 말을 전합니다.}

BigQuery용 SAP Business Data Cloud Connect 정식 버전 출시

Tue, 29 Sep 2026 04:00:00 +0000

기존 데이터 복제 기술은 최신 워크플로에 필요한 데이터 최신성을 제공하는 데 어려움을 겪는 경우가 많습니다. 조직이 이러한 과제를 극복할 수 있도록 SAP와 Google Cloud는 SAP Business Data Cloud Connect for BigQuery가 정식 버전으로 출시되었음을 발표합니다.

오랜 파트너십 의 다음 단계인 BigQuery용 SAP BDC 연결을 사용하면 SAP Business Data Cloud와 BigQuery 전반의 데이터 제품에 제로 카피로 액세스할 수 있어 사일로를 줄이고, 중요한 비즈니스 컨텍스트를 보존하며, 분석과 AI를 가속화할 수 있습니다. 이를 통해 현재의 풍부한 시맨틱 데이터를 두 환경 모두에서 사용할 수 있으므로 AI 에이전트가 복잡한 비즈니스 작업을 실행하는 동안 팀은 제어권을 유지할 수 있습니다.

AI 프로젝트를 위한 데이터 복사 중단

제로 카피 아키텍처를 지원하도록 빌드된 BigQuery용 SAP BDC Connect는 SAP Business Data Cloud와 Google의 데이터 및 AI 생태계 간에 안전한 양방향 연결을 설정합니다. BigQuery 및 Knowledge Catalog (이전 명칭: Dataplex)에서 SAP 테이블, 메타데이터, 비즈니스 시맨틱에 직접 액세스하고 그 반대 방향으로도 액세스할 수 있습니다. AI 에이전트의 기반을 원시적이고 격리된 데이터베이스 필드가 아닌 운영 현실에 두세요. BigQuery용 SAP BDC Connect를 사용하면 조직에서 다음을 수행할 수 있습니다.

신뢰할 수 있는 데이터 기반 AI 확장: SAP Business Data Cloud와 BigQuery 전반의 데이터 제품에 대한 실시간 제로 카피 액세스를 통해 시맨틱이 풍부한 데이터 기반을 바탕으로 관리되고 신뢰할 수 있는 AI를 빌드합니다.
멀티 에이전트 워크플로 배포: Gemini Enterprise Agent Platform과 SAP Joule을 사용하여 SAP와 Google 전반에서 지능형 에이전트로 워크플로를 조정합니다.
더 심층적인 패턴 발견: 미션 크리티컬한 SAP 데이터를 Google 트렌드, Google 지도 지리 공간 데이터와 같은 고유한 데이터 세트와 결합하여 더 나은 비즈니스 컨텍스트를 만듭니다. 그런 다음 이 보강된 데이터를 SAP에 직접 다시 게시할 수 있습니다.
비즈니스 분석 개선: Gemini Enterprise 또는 Joule을 사용하여 자연어로 개방형 비즈니스 질문을 할 수 있도록 직원 역량을 강화하고 SAP 및 Google Cloud 데이터에 기반한 즉각적인 컨텍스트 인식 답변을 받을 수 있습니다.

비용을 늘리지 않고 데이터 가치 확장

BigQuery용 SAP BDC Connect의 제로 카피 아키텍처는 데이터의 중복 사본을 복제, 저장, 유지관리할 필요성을 최소화하여 대체 데이터 플랫폼에 비해 총소유비용 (TCO)을 절감하는 데 도움이 됩니다. 데이터를 제자리에서 쿼리할 수 있으므로 데이터 공유 수수료가 발생하지 않습니다. 이를 통해 예측 가능한 결제 모델을 만들어 조직이 예상치 못한 요금으로부터 보호됩니다.

고객이 공유된 데이터를 행동으로 전환하는 방법

BigQuery용 SAP BDC Connect 프리뷰 액세스 권한이 있는 조직은 이미 제로 카피 아키텍처를 사용하여 더 복잡한 운영 문제를 해결하고 있습니다. 데이터 파이프라인을 가속화함으로써 얼리 어답터는 글로벌 데이터 사일로를 해체하고, 공급망 중단을 예측하며, 변동하는 고객 수요에 더 빠르게 대응하고 있습니다. 데이터 연결에 몇 주가 걸려 엔터프라이즈 AI 이니셔티브가 지연되는 기존 데이터 관행과는 대조적입니다. 팀은 SAP 및 Google 데이터와 직접 상호작용하여 기능 프로토타입을 빠르게 빌드하고 AI 투자 수익을 가속화할 수 있습니다.

ElringKlinger 는 복잡한 다국적 제조 및 공급망 데이터를 관리하는 글로벌 자동차 공급업체로, 제로 카피를 사용하여 데이터 사일로를 허물고 있습니다. 회사는 ERP 데이터를 복제할 필요 없이 실시간으로 쿼리하여 데이터 인프라의 복잡성을 줄이는 동시에 현지화된 재고 보고를 통해 신속한 생산 분석을 지원하고자 합니다.

"글로벌 자동차 기업을 운영한다는 것은 방대하고 복잡한 공급망과 생산 데이터를 관리해야 한다는 의미입니다. 오늘날 대부분의 데이터는 SAP의 기존 보고 백본인 SAP BW/4HANA에 저장되어 있습니다. BigQuery용 SAP BDC Connect를 테스트한 결과, 강력한 새로운 경로가 있음을 알게 되었습니다. 즉, 데이터 복사나 마이그레이션 없이 기존 BW/4HANA 애셋 위에 분석 레이어로 BigQuery를 사용하면 이전 투자를 완전히 보존하면서 AI 기반 대화형 분석을 활용할 수 있습니다. 또한 공급망 프로세스를 자동화하는 에이전트 사용 사례의 기반을 마련하여 팀이 전 세계 제조 신호를 실시간으로 파악할 수 있도록 지원합니다." - 클리브 뱅크스턴, 프로젝트 관리자, ElringKlinger IT 아키텍처 부문 책임자 디르크 브뤼머

데이터를 통합하여 파트너와 함께 스마트 워크플로 빌드

SAP와 Google Cloud의 글로벌 파트너 네트워크는 BigQuery용 SAP BDC Connect를 사용한 사용 사례를 적극적으로 구축하고 있습니다. 이러한 도구를 사용하면 단발성 AI 실험에서 벗어나 수동으로 관리하기 어려운 매우 다양한 작업을 처리하는 팀의 역량을 강화할 수 있습니다. 이를 위해 Google Cloud 파트너는 신뢰할 수 있는 SAP 데이터와 더 광범위한 소스를 결합하여 에이전틱 AI와 자율 운영을 배포할 수 있도록 지원합니다. 이러한 통합 접근방식을 사용하면 팀에서 서로 다른 시스템을 연결하고, 거버넌스를 유지하며, 수익에 영향을 미치는 운영을 추진할 수 있습니다.

"기업이 재창조 어젠다를 가속화함에 따라 비즈니스 시스템 전반에서 데이터를 통합하는 능력은 에이전트 AI를 확장하는 데 있어 기본이 됩니다. 이때 SAP Business 데이터 클라우드 Connect for BigQuery가 매우 강력한 기능을 발휘합니다. 기업은 신뢰할 수 있는 재무, 운영, 지속 가능성 데이터에 실시간으로 액세스할 수 있어 기존의 데이터 사일로를 없앨 수 있습니다. 이러한 조합은 Gemini Enterprise와 Accenture의 심도 있는 업계 전문성을 결합하여 조직이 지능형 에이전트를 빌드하고, 자율 운영을 추진하며, 디지털 핵심을 더 빠르게 현대화하는 동시에 새로운 수준의 비즈니스 가치를 실현할 수 있도록 지원합니다." – Chetna Sehgal, Accenture Google Business Group 글로벌 실무 책임자

“조직은 데이터 과학 프로젝트가 아니라 운전 자본 개선, 운영 비용 절감과 같은 구체적인 비즈니스 성과를 원합니다. 이러한 제로 카피 통합을 활용하여 고객을 위한 자율 조달 에이전트를 빌드했습니다. 에이전트는 BigQuery 내에서 실시간 SAP 인벤토리 수준과 시장 데이터를 동시에 읽기 때문에 최근 공급업체 전환 중에 주문을 자율적으로 재라우팅하여 잠재적인 다운타임으로 인한 수백만 달러의 손실을 막고 실시간 데이터에 연결된 에이전트 AI가 수익에 영향을 미칠 수 있음을 입증했습니다." - Piyush Bhandari, Deloitte Consulting LLP 전무이사

“KPMG 회원사의 에너지 고객을 대상으로 최근 평가 및 프로토타입 제작 경험을 바탕으로 SAP BDC Connect for BigQuery가 조직의 엔터프라이즈 계획, 분석, 데이터 통합을 확장 가능한 기반으로 현대화하는 데 큰 잠재력이 있다고 생각합니다. KPMG 기업의 평가에 따르면 이 통합은 엔터프라이즈 규모에서 더 많은 양의 분석 워크로드를 지원하여 미래의 AI 및 에이전트 사용 사례를 탐색할 수 있는 중요한 데이터 기반을 제공하는 데 도움이 될 수 있습니다. 모든 혁신이 그렇듯, 비즈니스 가치를 최대한 실현하려면 구현 접근방식, 데이터 품질, 조직의 준비 상태에 따라 달라질 수 있습니다." - Mark Shank, KPMG 미국 지사 Google 자문, 은행, 기술 및 데이터 엔지니어링 부문 책임자

"고객은 더 많은 정보를 찾는 것이 아니라 더 나은 비즈니스 의사 결정을 내리기를 원합니다. PwC는 조직이 Google Cloud 내에서 SAP 비즈니스 데이터를 더 광범위한 엔터프라이즈 데이터 소스와 통합하도록 지원하고 있습니다. 이를 통해 분석을 강화하고, 강력한 거버넌스와 규정 준수를 지원하며, 엔터프라이즈 전반에서 지능형 워크플로를 추진하는 AI를 위한 단일의 신뢰할 수 있는 기반을 만들 수 있습니다. 이러한 통합 접근방식을 통해 조직은 고립된 AI 실험에서 벗어나 진정한 전사적 비즈니스 혁신을 이룰 수 있습니다.” - 패트릭 퓨, PwC 미국 지사 글로벌 및 미국 제휴 및 생태계 리더

에이전트 데이터의 힘: SAP 및 Google Cloud의 관점

"모든 기업은 비즈니스 운영의 핵심에 인텔리전스와 자동화를 도입하기 위해 노력하고 있습니다. SAP Business Data Cloud를 BigQuery 및 Gemini와 통합함으로써 엔터프라이즈 데이터의 가장 큰 장벽 중 하나를 허물고 있습니다. Google Cloud는 데이터 공유 비용 없이 플랫폼 전반에서 풍부한 시맨틱 메타데이터와 에이전트 컨텍스트를 적극적으로 공유하여 원시 데이터 액세스를 훨씬 뛰어넘는 수준을 제공합니다. 이를 통해 공동 고객은 완전한 실시간 비즈니스 인식을 바탕으로 작동하는 자율 AI 에이전트를 배포하여 복잡한 공급망 및 재무 프로세스를 절대적인 정밀도로 실행할 수 있습니다." - 앤디 구트만스, Google Cloud 에이전트 데이터 클라우드 부문 부사장 겸 총괄 책임자

"SAP Business Data Cloud Connect for Google BigQuery는 SAP의 미션 크리티컬 데이터를 Google BigQuery로 가져와 Google Gemini 및 Gemini Enterprise Agent Platform에서 액세스할 수 있도록 하는 실시간 양방향 제로 카피 데이터 공유를 제공합니다. SAP BDC Connect를 사용하면 복잡한 추출이나 커스텀 API 없이도 SAP 데이터와 비 SAP 데이터를 통합하여 데이터 복잡성을 줄이고, 거버넌스를 강화하며, 신뢰할 수 있는 AI 기반 비즈니스 성과를 가속화할 수 있습니다." - Irfan Khan, SAP 데이터 및 분석 부문 사장 겸 최고 제품 책임자

사용 가능한 리전

SAP Business Data Cloud: 현재 오스트레일리아 (시드니), 브라질 (상파울루), 인도 (뭄바이), 이스라엘 (텔아비브), 독일 (프랑크푸르트), 일본 (오사카), 사우디아라비아 (담맘), 미국 (아이오와)의 Google Cloud 리전에서 제공됩니다.
BigQuery용 SAP BDC Connect: 모든 Google Cloud 고객을 대상으로 전 세계에서 정식 버전으로 제공됩니다.
교차 클라우드 지원: BigQuery용 SAP BDC Connect는 Google Cloud 및 AWS에서 호스팅되는 SAP Business Data Cloud 인스턴스를 지원하며, Microsoft Azure에서 호스팅되는 SAP Business Data Cloud 인스턴스에 대한 지원도 곧 제공될 예정입니다.

시작하기

자세히 알아보려면 웹사이트를 방문하거나 Google Cloud 계정 담당자에게 문의하세요. BigQuery용 SAP BDC Connect 시작에 관한 자세한 내용은 문서 페이지를 방문하여 지금 바로 제로 카피 연결을 시작하세요.

BigQuery 그래프를 사용한 식품 공급망의 디지털 트윈 모델링

Mon, 28 Sep 2026 20:00:00 +0000

성장하는 레스토랑의 예

식당 체인을 운영한다고 가정해 보겠습니다. 비즈니스가 어떻게 운영되는지 알기 위해 직접 만져보고 느낄 수 없기 때문입니다. 비즈니스의 상태를 감지할 수 있는 도구와 비즈니스의 디지털 복제본이 필요합니다.

성장의 마찰

성장으로 인해 스프레드시트로는 해결할 수 없는 고유한 종류의 마찰이 발생합니다.

채찍 효과: 다운스트림의 작은 수요 변화가 업스트림의 인벤토리 파도로 증폭됩니다.
SOP 이탈: 표준 준비 작업에서 약간만 벗어나도 결국 전체 브랜드 분위기가 훼손됩니다.
식품 안전 영향 범위: 오염된 재료 하나가 네트워크 전반에 걸쳐 복잡하고 지저분한 위험 지도를 만듭니다.
무단 지출: 현지 관리자가 계약 외 식재료를 구매하여 발생한 '백만 달러의 누수'

디지털 트윈

디지털 모델을 사용하면 세상에 대해 더 통찰력 있는 질문을 던질 수 있지만, 데이터를 구성하는 방식에 대해 중요한 선택을 해야 합니다. 기존의 관계형 테이블이 표준이었지만, 여전히 모든 작업에 적합한 도구인지 물어봐야 합니다. 세상은 본질적으로 상호 연결되어 있으므로 그래프 기반 모델로 전환하는 것이 현실을 포착하기 위한 자연스러운 진화일 수 있습니다.

수천 개의 애셋, 복잡한 공급망 또는 글로벌 물류 네트워크를 관리할 때 기존의 관계형 데이터베이스는 종속 항목을 추적하기 위해 리소스 집약적인 대규모 SQL 조인이 필요합니다. 이 아키텍처는 물리적 이벤트와 운영 인식 사이에 지연 시간 격차를 만듭니다.

BigQuery 그래프를 사용한 모델링

BigQuery 그래프를 사용하면 기존 데이터 플랫폼 내에서 전체 공급망의 디지털 트윈을 빌드할 수 있습니다. 물리적 세계(항목, 레시피, 위치)를 노드와 엣지로 이루어진 검색 가능한 맵으로 전환하면 새로운 차원의 명확성을 얻을 수 있습니다.

1. 시맨틱 계층 정의

데이터를 새 데이터베이스로 이동하는 대신 기존 테이블 위에 그래프 뷰를 만듭니다. 이렇게 하면 BigQuery에서 테이블이 서로 어떻게 관련되어 있는지 정확히 알 수 있습니다.

쿼리 언어:

code_block: <ListValue: [StructValue([('code', '# Build the Graph Nodes & Edges\r\nCREATE or REPLACE PROPERTY GRAPH `restaurant.bombod`\r\nNODE TABLES (\r\n `restaurant.item` label item properties all columns,\r\n `restaurant.location` label location properties all columns,\r\n `restaurant.itemlocation` label itemlocation properties all columns\r\n)\r\nEDGE TABLES (\r\n `restaurant.bom`\r\n KEY(bomKey)\r\n SOURCE KEY (childItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n DESTINATION KEY (parentItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n LABEL consists_of properties all columns\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccdb589d0>)])]>

BigQuery 그래프를 사용하여 모델링한 가상의 레스토랑 공급망 이미지

실무에서의 정밀도

이러한 변화는 일상 업무에 어떤 영향을 미치나요? 비즈니스를 혼란에서 정밀함으로 전환합니다.

수술 리콜: 공급업체가 리스테리아 발생을 보고하면 그래프를 앞으로 이동하여 어떤 특정 레스토랑의 어떤 메뉴 항목이 영향을 받았는지 정확히 파악합니다.
날씨 위험 분석: 허리케인이 유통 센터를 위협할 때 매장 목록이 아닌 영향 범위가 표시됩니다. 해당 허브에 크게 의존하는 위치를 파악하고 보급품을 다른 경로로 재전송합니다.

2. 검색 실행

그래프 쿼리는 모델러와 데이터 과학자가 데이터를 쿼리할 수 있는 새로운 도구입니다. 복잡한 다중 도메인 데이터 개념을 단순화하고 쿼리를 간소화하며 데이터 분석을 문제 표현의 더 단순하고 자연스러운 표현으로 만듭니다. 예를 들어 닭고기를 취급하는 모든 위치를 알고 싶다면 아래와 같이 그래프 쿼리를 실행할 수 있습니다.

특정 불만사항이나 위험을 조사하기 위해 그래프 쿼리 언어를 사용하여 모델에 대한 검색을 실행합니다.

Graph Query Language

code_block: <ListValue: [StructValue([('code', "# Navigate to the source of a specific ingredient issue\r\nGraph restaurant.bombod\r\nMATCH (a:itemlocation)-[c:consists_of]->(b:itemlocation) \r\nWHERE b.itemKey LIKE '%Chicken%'\r\nRETURN to_json([to_json(a),to_json(c),to_json(b)]) as result"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc1ea710>)])]>

악취의 근원 - 그래프로 모델링

미래를 위한 기반 구축

디지털 트윈을 최대한 활용하려면 다음 원칙을 따르세요.

구조에 집중: 그래프를 사용하여 관계와 종속 항목을 파악하고, 일일 매출 합계를 관계형 테이블에 보관합니다.
키 정리: 데이터 엔지니어링에 시간을 투자하세요. 그래프는 연결만큼 강력합니다.
에지 속성 캡처: 리드 타임이나 배송비와 같은 메타데이터를 에지에 직접 저장하여 모델의 유용성을 높입니다.

결론

레스토랑 업계는 비즈니스 데이터를 목록으로만 취급하는 관계형 방식을 벗어났습니다. BigQuery 그래프를 사용해 디지털 트윈으로 도메인 간 관계를 빌드하면 반응적인 문제 해결에서 선제적인 모델링으로 전환할 수 있습니다. 이제 목록으로 네트워크를 관리하는 대신 몇 초 만에 연결을 확인할 수 있습니다.

지금 시작하기

여기 에서 튜토리얼을 확인하세요.
BigQuery 문서를 방문하여 개요 와 빠른 시작 가이드를 확인하세요.
의견 공유: 커뮤니티에 참여하고 bq-graph-preview-support@google.com을 통해 질문에 대한 답변을 받아보세요.
관련 블로그: BigQuery 그래프 소개

경계 없는 Lakehouse 가속화: 크로스 클라우드 캐싱 프리뷰 발표

Mon, 28 Sep 2026 20:00:00 +0000

오늘 Google Cloud는 데이터 엔지니어, 데이터 과학자, 그리고 점점 더 많이 사용되고 있는 AI 에이전트가 관리되는 데이터를 저장된 위치에서 직접 쿼리할 수 있는 방법을 제시하는 경계 없는 레이크하우스의 개선사항을 발표하게 되어 기쁩니다.

정확하게 추론하고 복잡한 엔터프라이즈 워크플로를 자동화하려면 모든 유형의 에이전트와 데이터 소비자가 조직의 전체 데이터 자산에 빠르고 통합된 방식으로 액세스하여 클라우드 전반에서 고객 기록, 트랜잭션 로그, 운영 텔레메트리를 결합해야 합니다. 그러나 최신 엔터프라이즈 데이터는 단일 위치에 국한되는 경우가 거의 없습니다. 데이터 자산은 Amazon S3, Azure Data Lake Storage (ADLS), Google Cloud Storage, 운영 데이터베이스, Salesforce, SAP, Workday와 같은 SaaS 플랫폼에 걸쳐 있는 경우가 많습니다. 과거에는 이러한 분산된 데이터 세트를 통합하려면 취약한 ETL 파이프라인, 중복된 스토리지, 과도한 크로스 클라우드 데이터 전송 비용이 필요했습니다.

올해 초 Google은 조직이 클라우드 전반에서 데이터를 쿼리하고 활성화할 수 있도록 경계 없는 레이크하우스를 도입했습니다. Apache Iceberg REST 카탈로그 사양을 채택하여 Databricks Unity Catalog, AWS Glue, Snowflake Horizon과 같은 카탈로그에 직접 제휴합니다. 또한 다른 클라우드 제공업체에 대한 고대역폭의 비공개 링크를 설정하여 공용 인터넷에 비해 기가바이트당 전송 비용을 낮추는 Partner Cross-Cloud Interconnect 도 도입했습니다.

오늘날에는 얼마나 많은 데이터를 처음부터 전송해야 하는지 최적화하여 멀티 클라우드 효율성을 한 단계 더 끌어올리고 있습니다.

크로스 클라우드 데이터 쿼리 비용을 더욱 절감할 수 있는 두 가지 새로운 기능을 발표하게 되어 기쁩니다. 첫째, Lakehouse의 교차 클라우드 캐싱 프리뷰는 BigQuery에서 교차 클라우드 쿼리를 투명하게 가속화하고 Google Cloud에 자주 액세스하는 데이터를 로컬로 캐싱하여 원격 전송 비용을 절감합니다. 표준 Iceberg 열 형식 압축과 크로스 클라우드 캐싱을 결합하면 클라우드 전반에서 처리하는 데이터의 5% 미만만 전송하면 되는 경우가 많습니다. 이는 총소유비용 (TCO)을 낮추어 엔터프라이즈 규모의 크로스 클라우드 분석 및 AI를 실현하는 데 도움이 됩니다. 또한 BigQuery 크로스 클라우드 연결도 프리뷰로 제공되어 다른 클라우드의 비 Iceberg 데이터를 쿼리하고 워크로드를 가속화할 수 있습니다.

크로스 클라우드 캐싱의 작동 방식

크로스 클라우드 캐싱은 기업의 성능 및 보안 요구사항을 충족하며, 쿼리 속도를 높이기 위해 조정하거나 관리해야 하는 스토리지도 없습니다. 내부적으로 사용되는 메커니즘은 다음과 같습니다.

하위 파일 블록 세분성: 쿼리가 몇 개의 열만 건드리는 경우 전체 멀티 기가바이트 파일을 클라우드 간에 전송하는 대신, 크로스 클라우드 캐싱은 Apache Parquet와 같은 열 형식에 대해 하위 파일 블록 수준에서 작동합니다. BigQuery는 쿼리에서 프로젝션된 특정 열 청크와 사전 페이지만 캐싱합니다. 캐시 미스 시 BigQuery는 쿼리에 답하기 위해 원격 클라우드에서 필요한 데이터를 가져오고, 향후 쿼리를 위해 캐시에 로컬 사본을 저장하여 반복되는 워크로드의 네트워크 전송과 지연 시간을 대폭 줄입니다.
기본 저장 데이터 암호화: 캐시된 데이터 블록은 기본적으로 Google 관리 암호화 키 (GMEK)를 사용하여 저장 데이터 암호화되므로 임시 캐시 스토리지는 추가 오버헤드 없이 네이티브 BigQuery 스토리지와 동일한 엔터프라이즈급 보안 상황을 유지합니다.
테넌트 및 리전 격리: 캐시 항목은 프로젝트 및 카탈로그 경계에 따라 엄격하게 파티셔닝되어 테넌트 간 데이터 노출을 방지합니다. Lakehouse는 로컬 캐시와 쿼리 실행을 구성된 Google Cloud 리전 (예: us-east4)에 엄격하게 고정하여 원격 클라우드를 쿼리할 때 지역 데이터 상주 요구사항을 준수하도록 지원합니다.
최신 상태 확인: 멀티 클라우드 캐싱은 종종 속도와 최신 상태 간의 절충을 강요합니다. BigQuery는 오래된 읽기를 방지하기 위해 캐시된 데이터를 사용하기 전에 원격 객체 메타데이터를 가져와 데이터가 변경되지 않았고 사용자에게 여전히 액세스 권한이 있는지 확인합니다. 업스트림 테이블이 수정되면 BigQuery가 새 파일을 가져오고, 참조되지 않은 캐시된 블록은 자동으로 만료되므로 단일 소스 저장소의 정확성을 유지하면서 로컬 쿼리 속도를 제공합니다.

캐싱 메커니즘, 통계 카운터, 리전 고려사항에 대한 자세한 내용은 Lakehouse 인텔리전트 캐싱 문서를 참조하세요.

크로스 클라우드 캐싱의 실제 작동 방식

그렇다면 일상적인 운영에서는 어떻게 작동할까요? Databricks Unity Catalog에서 Lakehouse로 페더레이션된 Amazon S3의 10TiB Iceberg 판매 테이블 (aws_lakehouse_catalog.sales.web_sales)을 쿼리하는 e-commerce팀을 생각해 보겠습니다. 저녁 프로모션 시간 (오후 8시~9시) 동안 분석가는 과거 거래를 쿼리하여 의도가 높은 인구통계에서 가장 많은 거래량과 수익을 창출하는 매장을 식별합니다.

code_block: <ListValue: [StructValue([('code', 'SELECT w.web_name, hd.hd_buy_potential, COUNT(*) AS total_transactions, ROUND(SUM(ws.ws_sales_price), 2) AS total_sales\r\nFROM `aws_lakehouse_catalog.sales.web_sales` ws\r\n-- Joins household_demographics, time_dim (8:00-9:00 PM), and web_site.\r\nGROUP BY w.web_name, hd.hd_buy_potential;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc0e6f50>)])]>

초기 실행: 콜드 열 검색

이 초기 콜드 실행에서는 로컬 캐시가 비어 있습니다 (cacheBytesRead: "0"). BigQuery는 파트너 교차 클라우드 상호 연결을 통해 Amazon S3에서 필요한 Parquet 바이트 범위만 전송하기 위해 파티션 가지치기 및 열 프로젝션을 적용합니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "totalBytesProcessed": "230343464114",\r\n "objectStorageStats": [\r\n{"cloudProvider": "AWS", \r\n"objectStorageBytesRead": "25834740486", \r\n"cacheBytesRead": "0"}]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc45cd50>)])]>

처리된 논리적 데이터: BigQuery는 10TiB 데이터 세트에서 214.5GiB를 처리합니다.
표준 Iceberg 압축 효율성: BigQuery는 Zstandard (zstd)를 사용한 표준 Iceberg 열 형식 압축 덕분에 S3에서 24.1GiB를 읽습니다. 이는 8.9:1의 압축률입니다. 이러한 하위 파일 Parquet 블록이 Google Cloud에 도착하면 BigQuery가 리전 캐시를 채웁니다.

후속 탐색: 측정기준 추가

실제로 분석가와 에이전트는 정확히 동일한 쿼리를 연속으로 두 번 실행하는 경우가 거의 없습니다. 분석가는 배송 방법 측정기준 (sm.sm_type)을 추가하여 쿼리를 수정하여 주문 처리 방법을 자세히 살펴봅니다.

code_block: <ListValue: [StructValue([('code', 'SELECT w.web_name, sm.sm_type, hd.hd_buy_potential, COUNT(*) AS total_transactions, ROUND(SUM(ws.ws_sales_price), 2) AS total_sales\r\nFROM `aws_lakehouse_catalog.sales.web_sales` ws\r\nJOIN `aws_lakehouse_catalog.sales.ship_mode` sm ON ws.ws_ship_mode_sk = sm.sm_ship_mode_sk\r\n-- Reuses existing joins on household_demographics, time_dim, and web_site.\r\nGROUP BY w.web_name, sm.sm_type, hd.hd_buy_potential;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc45c650>)])]>

이 후속 쿼리의 작업 통계는 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "totalBytesProcessed": "287928766472",\r\n "objectStorageStats": [\r\n{"cloudProvider": "AWS", \r\n"objectStorageBytesRead": "1426587648", \r\n"cacheBytesRead": "25834740486"}]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc54b010>)])]>

94.8% 캐시 적중률: BigQuery는 이전에 쿼리한 열의 24.1GiB를 로컬 캐시에서 직접 제공합니다.
세분화된 원격 검색: BigQuery는 새 ws_ship_mode_sk 열과 ship_mode 테이블에 대해 S3에서 1.33GiB만 전송합니다.
하위 파일 유연성: 쿼리를 수정하면 캐시된 열 청크가 재사용되고 새로 필요한 바이트만 전송됩니다.

엔터프라이즈 규모의 효율성 증대

크로스 클라우드 쿼리의 TCO를 고려할 때 가장 중요한 두 가지 요소는 다음과 같습니다.

압축률: Iceberg에서 기본 압축 알고리즘 (Zstandard/zstd)을 사용하면 열 형식 데이터의 압축률이 높습니다. 데이터가 8:1의 압축률을 달성한다고 가정하면 처리된 논리적 데이터 1TiB마다 네트워크를 통해 이동하는 데 ~128GiB의 데이터만 필요합니다.
캐시 적중률: 최근에 액세스한 데이터가 네트워크를 통해 가져오는 대신 캐시에서 가져오면 네트워크 전송을 피할 수 있습니다. 데이터의 80% 가 캐시 적중을 발생시킨다고 가정하면 액세스한 실제 데이터 100GiB당 20GiB만 네트워크를 통해 이동합니다.

두 가지 요소와 가정을 모두 고려하면 조직에서 처리하는 데이터 1TiB당 네트워크를 통해 전송해야 하는 데이터는 ~26GiB (총 처리 데이터의 3% 미만)에 불과합니다. 이러한 절감 효과를 Partner Cross-Cloud Interconnect와 결합하면 TCO가 충분히 낮아져 페타바이트 규모의 크로스 클라우드 분석 및 AI를 비용 효율적으로 사용할 수 있습니다.

BigQuery 크로스 클라우드 연결이 프리뷰로 제공됩니다.

크로스 클라우드 캐싱과 함께 BigQuery 크로스 클라우드 연결의 프리뷰를 통해 조직은 BigQuery를 Amazon S3 및 Azure Storage의 개방형 형식 데이터에 직접 연결할 수 있습니다.

카탈로그 페더레이션과 교차 클라우드 연결을 언제 사용해야 하는지 이해하는 것은 간단합니다.

BigQuery 교차 클라우드 연결 (원시 파일용): Iceberg 카탈로그가 없는 독립형 파일 (CSV, JSON, 임시 Parquet)의 경우 교차 클라우드 연결을 통해 원격 버킷 경로를 직접 참조하는 BigQuery 외부 테이블을 만들 수 있습니다.
레이크하우스 카탈로그 제휴 (Iceberg용): Databricks Unity, AWS Glue, Snowflake Horizon과 같은 카탈로그에서 관리하는 Iceberg 데이터의 경우 레이크하우스가 스키마와 테이블 스냅샷을 자동으로 동기화하여 사용자 경험을 간소화하고 사용자가 항상 최신 데이터를 쿼리하도록 보장합니다.

크로스 클라우드 연결은 다른 클라우드의 컴퓨팅 작업자가 아닌 Google Cloud 리전의 표준 BigQuery 컴퓨팅 작업자를 사용하여 최신 아키텍처 진화의 역할을 합니다. 이 접근방식은 전 세계 지역에서 사용 가능하도록 지원하며 원격 파일의 BigQuery AI 및 Gemini를 포함한 완전한 BigQuery 기능 패리티 를 제공합니다.

레이크하우스의 교차 클라우드 캐싱 기능은 BigQuery 교차 클라우드 연결과 레이크하우스 카탈로그 통합에서 쿼리된 데이터에 적용됩니다. 연결을 만들고 외부 버킷 경로를 쿼리하는 방법을 알아보려면 BigQuery 크로스 클라우드 연결 설정 문서를 참조하세요.

Cortex Framework v7 정식 버전 출시: SAP 운영 중단 없이 에이전트형 워크플로 빌드

Mon, 28 Sep 2026 10:00:00 +0000

비즈니스는 미션 크리티컬 ERP 시스템을 중단하지 않고도 AI 에이전트를 신속하고 안전하게 배포하여 수익을 창출하고, 위험을 완화하며, 자본을 최적화하기를 원합니다. AI 에이전트를 구동하려면 원시 데이터 이상의 것이 필요합니다. 즉, 단일한 재사용 가능한 정보 소스 역할을 하며, 암호화된 소스 시스템 레코드를 명확한 비즈니스 용어로 전환하는 상호 운용 가능한 데이터 제품이 필요합니다.

오늘 Google은 Google Cloud Cortex Framework 버전 7의 정식 버전 출시를 발표합니다. 이 출시 버전은 에이전트 준비를 위해 데이터 아키텍처를 현대화하여 강력한 데이터 제품을 신속하게 배포, 맞춤설정, 확장하는 동시에 조정 작업을 간소화하고 기존 접근방식의 인프라 오버헤드를 줄이는 데 도움이 됩니다.

ERP 시스템은 풍부한 기본 데이터를 보유하고 있지만, 이러한 트랜잭션 기록을 AI 지원 데이터 제품으로 전환하기는 어렵습니다. 특히 핵심 운영 속도를 늦추지 않고 전환하기는 더욱 어렵습니다. Cortex Framework v7은 SAP용으로 특별히 제작된 데이터 제품 가속기를 통해 이 문제를 해결합니다. BigQuery와 Knowledge Catalog에 직접 배포된 이러한 데이터 제품은 Gemini Enterprise Agent Platform에 정확한 비즈니스 컨텍스트를 제공하여 AI 에이전트가 높은 충실도로 실행할 수 있도록 합니다. 또한 데이터팀이 BigQuery에서 워크플로를 빌드, 버전 제어, 조정하는 데 도움이 되는 엔드 투 엔드 환경인 Dataform을 기반으로 하는 모듈식 확장 가능한 배포 아키텍처를 사용하여 데이터 조정을 간소화합니다.

Cortex Framework v7에서 무엇을 찾을 수 있는지, 최근 출시된 SAP Business Data Cloud Connect for BigQuery와 어떻게 통합되는지, 고객의 의견은 무엇인지, 시작 방법은 무엇인지 자세히 알아보려면 계속 읽어보세요.

Cortex Framework v7의 새로운 기능

1. 에이전트 지원 데이터 제품 제공

기존의 비즈니스 인텔리전스 (BI) 대시보드는 지난 분기에 무슨 일이 있었는지 알려주지만, 최신 AI 모델과 에이전트는 실시간으로 조치를 취할 수 있도록 도와줍니다. 이러한 전환을 지원하기 위해 Cortex Framework v7은 엔터프라이즈 데이터를 AI 친화적인 메타데이터를 포함하는 의미적으로 풍부한 데이터 제품으로 패키징합니다. 이를 통해 에이전트는 영향력이 큰 워크플로를 추론, 조정, 실행할 수 있습니다.

원시 SAP 테이블을 명확한 비즈니스 용어로 변환하고, 커스텀 필드를 동적으로 수집하며, SAP TCURX 통화 소수점 이동과 같은 고급 로직을 기본적으로 처리함으로써 프레임워크는 대규모 언어 모델(LLM) 상호작용 및 엔터프라이즈 분석에 필요한 높은 데이터 충실도를 유지합니다.

필드 이름과 설명에 대한 기본 제공 설명 메타데이터를 포함하여 BigQuery 내 SAP ERP에 배포된 Cortex Framework v7 데이터 제품을 보여주는 이미지

SAP ERP 및 SAP Business 데이터 클라우드를 위해 목적에 맞게 빌드된 데이터 제품 가속기는 BigQuery에 직접 배포됩니다. 배포가 완료되면 Knowledge Catalog에 자동 등록을 트리거하여 데이터를 쉽게 찾고 AI 에이전트에 연결할 수 있습니다.

설명과 라벨에 대한 기본 제공 메타데이터를 사용하여 Knowledge Catalog에 등록된 Cortex Framework v7 데이터 제품을 보여주는 이미지

또한 이 출시 버전에는 커스텀 AI 프로젝트를 가속화하기 위해 데이터 및 기술 엔지니어가 자연어를 사용하여 커스텀 데이터 제품을 생성하는 데 도움이 되는 에이전트형 데이터 제품 빌더를 위한 에이전트 스킬도 포함되어 있습니다. AI 에이전트는 프레임워크에서 제공하는 콘텐츠를 사용하여 특정 소스 데이터 요구사항 및 맞춤설정에 맞게 조정하는 것을 포함한 빌드 프로세스를 자동으로 처리할 수 있습니다.

GIF는 Cortex Framework v7이 Gemini를 사용한 Google Antigravity를 통해 자연어 프롬프트를 사용하여 새로운 데이터 제품의 빌드 및 배포를 자동화하는 에이전트 데이터 제품 빌더 기술을 제공하는 모습을 보여줍니다.

또한 v7을 사용하면 Cortex Framework를 확장하여 Cortex Framework에서 제공하는 콘텐츠와 커스텀 모델을 명확하게 분리할 수 있습니다. 이를 통해 커스텀 작업에 영향을 주지 않고 최신 코드 업데이트를 적용할 수 있습니다.

2. 모듈식 배포로 더 빠르게 빌드

Dataform은 버전 제어된 SQL과 기본 종속 항목 관리를 제공하여 Cortex Framework v7의 현대화된 데이터 파이프라인을 지원합니다. 배포를 위해 패키지화된 데이터 제품을 선택하면 Cortex Framework가 필요한 테이블만 검색하고 처리합니다. 종속 항목 해결은 작업 순서를 자동으로 처리하고 효율적인 처리를 위한 종속 항목 그래프를 생성합니다. 표준 모델을 중단하지 않고도 커스텀 필드나 로직을 추가할 수 있습니다.

데이터 애셋 및 테이블 종속 항목과 자연어 태그와 같은 기본 제공 메타데이터를 보여주는 자동화된 종속 항목 그래프가 있는 Dataform의 Cortex Framework v7 데이터 제품을 보여주는 이미지

이 모듈식 접근방식은 복잡한 멀티 시스템 SAP 환경으로 기본적으로 확장됩니다. Dataform은 기본 제공 논리 차별화를 사용하여 SAP ECC, SAP S/4HANA, SAP BDC 소스 시스템용 Cortex Framework 데이터 제품을 병렬로 컴파일하고 배포하는 동시에 동적 스키마 검색을 통해 Z 필드와 같은 커스텀 SAP 필드를 자동으로 수집하고 처리합니다. 이러한 기능을 함께 사용하면 여러 시스템에서 동시에 데이터를 가져올 수 있으므로 파이프라인을 수동으로 리팩터링할 필요가 줄어듭니다.

3. 유연한 처리로 비용 효율적으로 확장

이제 Cortex Framework는 기본적으로 BigQuery 증분 로드 및 비파괴적 스키마 업데이트를 사용해 새 데이터 또는 수정된 데이터만 처리합니다. 이 접근방식은 컴퓨팅 시간을 최소화하고 운영 비용을 크게 절감합니다. 조정은 Dataform의 서버리스 BigQuery 네이티브 실행에 의존하기 때문에 추가 인프라 오버헤드 없이 데이터 처리를 확장할 수 있습니다.

Bring-Your-Own (BYO) 변경 데이터 캡처 (CDC) 접근방식을 사용할 수도 있습니다. 이 접근방식을 사용하면 기본 제공 CDC 데이터 처리를 우회하고 기존 CDC 처리 파이프라인을 직접 연결할 수 있습니다.

SAP 데이터 클라우드와의 상호 운용성

최근 BigQuery용 SAP Business Data Cloud Connect가 정식 버전으로 출시됨에 따라 Cortex Framework v7은 이제 SAP BDC 표준 및 커스텀 데이터 제품을 기본적으로 지원합니다. Cortex Framework에서 제공하는 데이터 제품과 SAP BDC 데이터 제품을 결합하여 새로운 비즈니스 기회를 발굴할 수 있습니다. 이를 가속화하기 위해 v7에는 SAP BDC와 SAP ERP 데이터 전반에 걸쳐 솔루션 샘플이 포함되어 있어 판매 파이프라인의 상태를 평가하거나 조달 비효율성을 식별하는 등 광범위한 중요한 질문에 빠르게 답할 수 있습니다.

SAP Business Data Cloud Connect for BigQuery 통합을 통해 SAP BDC 소스 데이터 제품에 배포된 Cortex Framework v7 소비 데이터 제품 솔루션 샘플을 보여주는 이미지입니다.

업계 리더와의 공동 혁신

Google Cloud는 전문 서비스 조직 및 업계 리더와 긴밀히 협력하여 이러한 새로운 기능을 테스트했습니다. 이러한 조직은 Google Cloud의 선도 고객으로서 엔터프라이즈 규모의 민첩성과 AI 준비를 위해 구축된 프레임워크를 만드는 데 도움이 되는 귀중한 의견을 제공했습니다.

“Cortex Framework의 기존 고객으로서 최신 v7 출시 버전에서 도입된 기능에 큰 기대를 걸고 있습니다. 복잡한 SAP ECC 및 S/4 환경을 Google Cloud의 AI 기능과 연결하려면 정확한 비즈니스 컨텍스트를 갖춘 신뢰할 수 있는 데이터 기반이 필요합니다. 에이전트형 데이터 제품 빌더를 포함한 Cortex Framework v7에 대해 발표된 기능을 바탕으로 분석 및 에이전트형 AI 사용 사례를 위한 엔터프라이즈 데이터 제품의 생성 속도를 높이고 규모를 확장할 수 있는 상당한 잠재력을 확인했습니다. 이 플랫폼의 방향은 SAP 데이터에 더 쉽게 액세스하고, 의미론적으로 더 의미 있게 만들고, 향후 보고 및 AI 이니셔티브를 지원할 준비를 갖추려는 조직에 특히 유망합니다.” - Jwan Ibrahim 박사, SLB 데이터 및 분석 부문 이사

시작하기

Cortex Framework v7은 기업이 AI 에이전트를 위해 가장 중요한 데이터를 운영하는 방식을 바꿉니다. Google Cloud는 서버리스 실행, AI 지원 시맨틱스, 기본 SAP 통합을 결합하여 복잡한 엔터프라이즈 데이터를 전략적 애셋으로 전환할 수 있도록 지원합니다. 시작하려면 다음 리소스를 확인하세요.

배포 실행: 사전 정의된 샘플 데이터 세트로 Cortex Framework 데모 배포를 시도하여 첫 번째 v7 데이터 제품을 살펴보세요.
자세히 알아보기: 프로덕션 배포 단계, 구성, 확장성, 소스 시스템 통합, 패키지 데이터 제품을 자세히 알아보려면 포괄적인 Cortex Framework v7 기술 문서를 읽어보세요.
전문가와 상담: Google Cloud 계정팀에 문의하여 Cortex Framework v7이 특정 데이터-AI 여정을 어떻게 가속화할 수 있는지 알아보세요.

통신 업계 자율성 확대: 분산 그래프 흐름(Distributed GraphFlow)으로 GNN 활용

Sun, 27 Sep 2026 22:00:00 +0000

전자통신 업계는 현재 기존의 수동적인 인간 중심 운영에서 완전한 자율 네트워크 운영으로 전환되는 패러다임 변화를 겪고 있습니다. 최신 네트워크는 점점 더 복잡하고 이질적이며 대규모로 성장하고 있어 수작업 규칙 기반 방법과 기존 머신러닝(ML) 접근 방식만으로는 네트워크 운영을 자동화하기에 충분하지 않습니다. ML 메서드는 대량의 정형 데이터에서 미묘한 패턴을 식별하고 정밀한 예측을 수행할 수 있지만, 데이터와 데이터가 나타내는 시스템을 이해하고 추론하며 궁극적으로 인간 운영자가 내릴 법한 결정을 내리는 능력은 부족합니다.

AI 에이전트의 성장과 추론 능력은 이러한 한계를 해결할 수 있는 유망한 솔루션입니다. 그러나 인간 운영자가 대규모 네트워크에서 생성된 수십억 개의 데이터 포인트에 분산된 통계 정보를 직접 수집할 수 없는 것과 마찬가지로, AI 에이전트도 이러한 규모로 작동할 수 있는 능력이 부족합니다. 이러한 문제를 해결하기 위해 통신 기업들은 방대한 시간 및 관계형 데이터에서 네이티브로 작동하도록 설계된 최신 형태의 머신러닝인 그래프 신경망(GNN)을 도입하고 있습니다. GNN을 AI 에이전트와 통합하면 운영자는 근본 원인 분석, 용량 계획, 트래픽 예측, 가상 시나리오 시뮬레이션, 실시간 이상 감지와 같은 고급 진단 기능을 이러한 인사이트를 해석하고 합당한 조치를 실행하는 데 필요한 추론 능력과 결합할 수 있습니다. 이 강력한 조합을 통해 네트워크는 시스템이 자율적으로 작동하는, TM Forum에서 정의한 레벨 5 자율성으로 안전하게 전환할 수 있습니다.

이 게시물에서는 Google Cloud의 자율 네트워크 운영 프레임워크를 지원하는 세 가지 구성요소(데이터, ML, AI)를 소개합니다.

Google 자율 네트워크 운영 프레임워크 아키텍처

기반: Spanner Graph의 디지털 트윈

Google Cloud의 자율 네트워크 운영 프레임워크의 핵심은 네트워크 디지털 트윈입니다. 이는 실제 통신 네트워크를 지속적으로 실시간 미러링하는 매우 상세한 가상 복제본입니다. 이 디지털 트윈은 정적 모델이 아니라 시간 경과에 따라 구성요소의 진화하는 상태와 관계를 포착하는 동적, 시간적 네트워크 그래프로 표현됩니다. 이러한 아키텍처 접근 방식을 통해 운영자는 마치 과거로 돌아간 것처럼 이전 데이터로 ML 모델을 학습시키고 평가할 수 있으며, AI 에이전트에게 레벨 5 자율성을 달성하는 데 필요한 기본적인 운영 지식을 제공할 수 있습니다. 디지털 트윈은 이 디지털 환경 내에서 제안된 네트워크 변경의 영향을 시뮬레이션함으로써 중요한 신뢰 계층을 구축하여 AI 에이전트가 미래 상태를 자신 있게 설계하고 네트워크 문제를 자동으로 해결할 수 있도록 합니다.

Google Cloud의 Spanner Graph는 이 디지털 트윈을 호스팅하는 데 특히 적합합니다.

확장성 및 가용성: Spanner Graph는 최신 애플리케이션을 위한 타협 없는 기반을 제공하며, 네트워크가 성장함에 따라 사실상 무제한으로 확장할 수 있고, 0-RPO/0-RTO 및 99.999%의 가용성을 제공합니다.
멀티 모델 지원: 단일 플랫폼에서 여러 데이터 모델(관계형, 그래프, 벡터, 전체 텍스트 검색)을 지원하므로 개발자가 최근접 이웃 벡터 검색과 결합된 그래프 횡단과 같은 복잡한 구성을 빌드할 수 있습니다.
전역 일관성: Spanner는 네트워크에 대한 전역적으로 일관된 뷰를 제공하여 시스템 개발을 간소화합니다.

다음 그림은 라우터, 인터페이스(물리적 포트), VPN(L3VPN 서비스 인스턴스), 흐름(활성 트래픽 세션)이라는 네 가지 노드 유형으로 구성된 네트워크 토폴로지를 보여줍니다. 이들은 전체 네트워크 스택을 캡처하는 방향성 에지 유형으로 연결됩니다. 물리적 포함(라우터-인터페이스), 물리적 링크(인터페이스-인터페이스), 컨트롤 플레인 피어링(OSPF/iBGP를 통한 라우터-라우터), 서비스 멤버십(라우터-VPN), 트래픽 앵커링(흐름-인터페이스, 흐름-VPN)이 여기에 해당합니다.

상위 수준 네트워크 토폴로지

ML 레이어: 분산 그래프 흐름(DGF)

네트워크가 어떻게 작동하고 반응할지 예측하기 위해 디지털 트윈은 분산 그래프 흐름(DGF)으로 구동되는 ML 레이어를 활용합니다. 이 레이어는 Spanner Graph 내에 호스팅된 방대한 양의 과거 정형 데이터를 학습하여 중요한 예측 인사이트를 도출하고, 이를 통해 인간 운영자와 AI 에이전트가 사후 대응이 아닌 선제적으로 네트워크를 관리할 수 있도록 지원합니다.

DGF는 최근 오픈소스로 공개된 Python 라이브러리로, GNN 모델링의 전체 엔드 투 엔드 수명 주기를 관리하도록 설계되었습니다. Google CoreML과 Google 연구팀이 개발한 이 제품은 지난 10년간 Google 내부에서 축적된 대규모 도구와 전문성을 Google Cloud 엔터프라이즈 고객에게 직접 제공합니다. 이 라이브러리는 다양한 엔지니어링 요구사항을 충족하기 위해 숙련된 팀을 위한 고성능의 구성 가능한 하위 수준 프리미티브와 함께 사전 GNN 전문 지식이 필요 없는 빠른 개발을 위한 간단한 API를 제공합니다.

예를 들어 GraphFlow에서 상위 수준 API를 사용하여 GNN 모델을 학습시키고 평가하는 작업은 코드 5줄로도 충분할 만큼 간단합니다.

code_block: <ListValue: [StructValue([('code', 'import dgf\r\n\r\n# Fetch the data from Spanner Graph\r\ngraph, schema = dgf.io.read_spanner_graph(...)\r\n\r\n# Train a node attribute prediction model\r\nmodel = dgf.learning.train_node_model(graph, schema, target_column="risk_score")\r\n\r\n# Evaluate the model\r\nmodel.evaluate()\r\n# Make predictions\r\nmodel.predict(graph, seed_node_idxs=[0, 1, 2])\r\n\r\n# Save the model for later\r\nmodel.save("/tmp/model")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccd57da10>)])]>

DGF는 자율 네트워크 운영 요구사항에 직접 매핑되는 상위 수준 개념을 제공합니다.

사용 사례

통신사는 DGF와 GNN을 활용하여 다음과 같은 여러 고급 사용 사례를 통해 사후 대응적 유지보수에서 선제적 예방으로 전환할 수 있습니다.

이상 감지: GNN은 과거 패턴과 현재 상태를 캡슐화하는 노드 및 에지 임베딩을 생성합니다. 비정상적인 임베딩은 서비스 성능 저하로 이어지기 전에 검토를 위해 플래그가 지정됩니다.
근본 원인 분석(RCA): DGF는 특정 우편번호 지역의 '연결 실패'와 같이, 사고와 관련된 네트워크 인스턴스만 포함하는 특정 하위 그래프를 출력할 수 있습니다. 이를 통해 문제 해결 에이전트는 전체 글로벌 네트워크를 스캔하지 않고도 고속 분석을 수행할 수 있습니다.
예측 유지보수: 시스템이 빠르게 움직이는 장비의 '핸드오버 실패'와 같은 기기 장애 또는 에지 중단 가능성을 예측하여 선제적인 부하 분산 또는 경로 재지정이 가능합니다. 또한 에이전트를 결합하면 '휴먼온더루프/휴먼인더루프' 방식을 도입하여 문제 해결 조치를 자동화할 수 있습니다.
가상 시나리오 분석: GNN을 사용하면 통신사가 광케이블 단선, 트래픽 급증, 기기 구성 변경과 같은 시나리오를 시뮬레이션할 수 있습니다. 토폴로지적 종속 항목을 모델링함으로써 GNN은 이러한 국지적 변화가 전체 네트워크에 어떻게 전파되는지 예측할 수 있으며, 이를 통해 엔지니어는 위험이 없는 디지털 환경에서 복원력을 테스트하고 완화 전략을 평가할 수 있습니다.

시나리오: GNN 및 DGF를 사용한 근본 원인 분석

디지털 트윈(예시 코드)을 만들고 나면 간단한 5단계 프로세스를 통해 GNN과 DGF를 활용한 근본 원인 분석(RCA) 탐지를 구현할 수 있습니다.

디지털 트윈에 연결: DGF Spanner Graph 커넥터(dgf.io.read_spanner_graph)를 사용하여 Spanner Graph의 디지털 트윈에서 DGF 환경으로 네트워크 토폴로지를 직접 로드합니다.
지도 노드(또는 에지) 예측 모델 학습: 학습 데이터와 목표에 따라 지도 노드 예측 모델을 학습시켜 타겟 노드 특성을 예측하거나, 에지 예측 모델을 학습시켜 근본 원인 항목 노드와 영향을 받는 항목 노드 간의 에지를 예측합니다. 제공된 샘플 데이터에 대해 상위 수준 dgf.learning.train_node_model API를 사용하여 지도 노드 예측 모델을 학습시킵니다.
노드 예측 모델을 사용하여 근본 원인 노드 예측: 노드 예측 모델을 직접 사용하여 이상이 있는 노드에 대한 영향 점수를 예측할 수 있습니다. 예측된 영향 점수가 가장 높은, 즉 이상치의 영향을 받는 항목 노드가 근본 원인의 주요 후보가 됩니다.
Gemini Enterprise Agent Platform(이전 명칭: Vertex AI)에 배포: 모델을 내보내고 Gemini Enterprise 엔드포인트에서 호스팅하여 확장 가능하고 지연 시간이 짧은 예측을 지원합니다.
실시간 추론: 이상치 날짜를 입력으로 사용하여 추론 엔드포인트에 예측 호출을 수행합니다. 엔드포인트는 예측된 근본 원인 항목 노드를 반환합니다.

지금 시작하세요

분산 그래프 흐름(Distributed Graph Flow)을 사용한 GNN을 네트워크 운영에 통합하는 것은 단순한 기술 업그레이드를 넘어 통신 업계의 중대한 진화입니다. GNN 기반 자율 프레임워크로 전환하면 운영자는 서비스 중단 시간을 크게 단축하고, 실시간으로 용량을 최적화하며, 궁극적으로 운영 효율성 개선을 통해 우수한 고객 경험을 제공할 수 있습니다.

나만의 지능형 네트워크 애플리케이션을 빌드하려면 확장 가능한 GNN 학습 및 추론을 위한 필수 프리미티브를 제공하는 Distributed GraphFlow(DGF) 라이브러리를 확인하세요. 직접 체험해 보려면 단계별 코드 샘플을 따라 해보세요. 또한 비즈니스 인식 GNN 복구 네트워크와 관련하여 최근 수상 경력에 빛나는 문샷 프로젝트를 살펴보고 이 백서를 검토하여 자체 최적화 자율 네트워크에 대한 Google의 접근 방식을 더 자세히 알아볼 수 있습니다.

에이전트 지원 분석: BigQuery 증강 분석으로 인사이트 확보

Tue, 22 Sep 2026 12:00:00 +0000

이제 BigQuery에서는 대규모의 복잡한 데이터 분석을 자동화하도록 설계된 증강 분석 테이블 값 함수(TVF) 제품군을 제공합니다. 증강 분석은 AI, ML, 통계적 방법을 결합하여 인사이트 발견과 패턴 설명을 자동화합니다. 이러한 함수를 사용하면 측정항목이 변경된 이유를 진단하고, 데이터 전반의 기본 추세와 관계를 파악하며, 비즈니스 결정의 실제 영향을 분리하여 확인할 수 있습니다.

이러한 TVF는 데이터가 저장된 위치에서 직접 실행되므로 분석 속도를 높이고 데이터를 외부 도구로 내보낼 필요성이 줄어듭니다. 또한 이러한 함수는 간결하고 구조화된 SQL 출력을 생성하므로 AI 에이전트의 스킬로 쉽게 통합할 수 있으며, 이를 통해 자동화된 대화형 데이터 조사 워크플로를 간편하게 구현할 수 있습니다.

BigQuery에 새롭게 도입되는 6가지 증강 분석 함수는 각각 특정 분석 과제를 해결하도록 설계되었습니다.

TVF 함수	파악할 수 있는 정보	답변을 얻을 수 있는 질문
AI.KEY_DRIVERS	두 기간 또는 그룹 간에 측정항목이 증가하거나 감소하는 주요 요인을 식별합니다.	지난 분기에 비해 이번 분기에 수익이 급증한 이유는 무엇인가요?
AI.CAUSAL_EFFECT	관찰된 결과를 예상 기준과 비교하여 작업 또는 이벤트의 영향을 정량화합니다.	자연적인 성장 외에 가격 변경으로 인한 수익 증가는 얼마나 되나요?
ML.CORRELATION	두 개의 수치 측정항목 간 관계 방향과 강도를 평가합니다.	사용자 세션 시간이 늘어나면 고객 평생 가치가 높아지는 것이 상관관계가 있나요?
ML.DETECT_CHANGE_POINTS	주변 패턴과 비교하여 측정항목이 변화한 특정 날짜 또는 구간을 식별합니다.	플랫폼 지연 시간에 지속적이고 구조적인 변화가 발생한 기간은 언제인가요?
ML.TREND	단기적인 변동이나 노이즈에서 기본적인 성장 또는 감소 추세를 분리합니다.	일시적으로 급증하거나 급감한 이상치를 제외하고 지난 1년간 매출의 기본 추세는 어떠한가요?
ML.SEASONALITY	시간, 일, 주, 월 또는 분기별로 예측 가능한 반복 주기를 발견합니다.	일주일 중 서버 부하가 지속적으로 가장 높은 요일은 언제인가요?

다음 섹션에서 살펴보겠지만 이러한 함수는 쉽게 연결할 수 있습니다. 감지된 시간대와 같은 한 함수의 출력을 다음 분석 단계의 파라미터로 직접 사용할 수 있습니다.

인사이트를 연결하는 단계별 예시

측정항목에 변화가 발생하여 근본 원인을 진단하고 비즈니스 성과를 측정해야 하는 경우를 생각해 보겠습니다.

진단을 위해 오스틴 자전거 공유 샘플 데이터 세트(bigquery-public-data.austin_bikeshare.bikeshare_trips)를 사용하여 ML.DETECT_CHANGE_POINTS, AI.KEY_DRIVERS, AI.CAUSAL_EFFECT를 연결해볼 수 있습니다. 이 데이터 세트에는 오스틴시의 자전거 공유 프로그램에 대한 과거 이용량 및 인구통계 데이터가 포함되어 있습니다.

1단계: 변경점 감지

ML.DETECT_CHANGE_POINTS는 시계열 데이터에서 통계적으로 유의미한 구조적 변화 또는 수준 변화를 자동으로 식별합니다. 이 예시에서는 단일 집계 측정항목의 분석을 보여주지만, 이 함수는 확장성이 뛰어나 수백만 개의 개별 시계열에서 실행할 수 있습니다.

이러한 변화를 찾기 위해 일일 기준에 따라 다음 쿼리를 실행합니다.

code_block: <ListValue: [StructValue([('code', "WITH daily_trips AS (\r\n SELECT\r\n TIMESTAMP_TRUNC(start_time, DAY) AS trip_day,\r\n COUNT(*) AS total_trips\r\n FROM `bigquery-public-data.austin_bikeshare.bikeshare_trips`\r\n GROUP BY 1\r\n)\r\nSELECT\r\n begin_timestamp,\r\n end_timestamp,\r\n metrics.avg AS avg_daily_trips,\r\n metrics.min AS min_daily_trips,\r\n metrics.max AS max_daily_trips,\r\n metrics.count AS duration_days\r\nFROM ML.DETECT_CHANGE_POINTS(\r\n (SELECT * FROM daily_trips),\r\n data_col => 'total_trips',\r\n timestamp_col => 'trip_day'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc217e10>)])]>

출력에서는 과거 데이터에서 기준이 변경된 정확한 시간 간격을 파악할 수 있습니다.

원시 일일 세션 수를 살펴보면 이러한 결과가 시간 경과에 따른 변화와 일치하는 것을 확인할 수 있습니다. 아래에서는 기간이 가장 긴 두 개의 변경점을 강조해서 보여줍니다.

2018년 2월의 변화는 오스틴 시의회가 대중교통 생태계를 혁신하기 위해 공유 전동 킥보드와 자전거를 대중교통 체계에 통합하는 '도크리스 모빌리티 파일럿 프로그램(Dockless Mobility Pilot Program)'을 통과시킨 날짜와 일치합니다.

2단계: 주요 요인 기여도 분석

2018년 2월 슬라이스를 AI.KEY_DRIVERS에 직접 입력하여 급증을 유발한 특정 요인(예: bike_type, subscriber_type 등)을 확인할 수 있습니다. AI.KEY_DRIVERS는 수백만 행의 다차원 데이터를 몇 초 만에 탐색할 수 있습니다.

변화가 발생한 이후의 슬라이스를 관심 그룹으로 정의하고, 발생하기 이전의 슬라이스를 참조 그룹으로 정의하여 비교합니다.

code_block: <ListValue: [StructValue([('code', "WITH daily_segments AS (\r\n SELECT \r\n start_station_name,\r\n end_station_name,\r\n subscriber_type,\r\n bike_type,\r\n 1 AS trip_count,\r\n -- We use the precise breakpoint identified by Change Points\r\n IF(EXTRACT(DATE FROM start_time) >= '2018-02-11', TRUE, FALSE) AS after_shift\r\n FROM `bigquery-public-data.austin_bikeshare.bikeshare_trips`\r\n -- Equidistant ~30 day window around the event\r\n WHERE start_time BETWEEN '2018-01-12' AND '2018-03-13'\r\n)\r\nSELECT \r\n drivers,\r\n metric_interest,\r\n metric_reference,\r\n difference,\r\n relative_difference,\r\n unexpected_difference,\r\n contribution\r\nFROM AI.KEY_DRIVERS(\r\n (SELECT * FROM daily_segments),\r\n metric_col => 'trip_count',\r\n interest_label_col => 'after_shift',\r\n dimension_cols => ['start_station_name', \r\n 'end_station_name', \r\n 'subscriber_type', \r\n 'bike_type'],\r\n top_k => 10\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccd66dfd0>)])]>

AI.KEY_DRIVERS는 가장 큰 영향을 미치는 측정기준 값을 분리합니다. 각 행에는 세그먼트가 포함되며, 이는 특정 측정기준 값의 조합으로 식별되는 데이터 슬라이스를 나타냅니다(예: subscriber_type = 'UT Student' 및 bike_type = 'classic').

분석 결과, 참조 기간과 관심 기간 사이에 전체 이용 건수가 374.7%(40,159건) 증가한 것으로 나타났습니다. 이러한 큰 폭의 증가는 U.T. 학생 멤버십(7,167.1% 증가)과 21st & Speedway @PCL 정류장에서 끝나는 이용 건수(20,739.1% 증가)에 압도적으로 집중되었습니다.

이는 도크리스 모빌리티 파일럿 프로그램에 대한 오스틴 자전거 공유의 대응과 일치합니다. 2월 초, 이 자전거 공유 프로그램은 텍사스 대학교와 대규모 프로모션 파트너십을 시작하여 모든 UT 학생에게 연간 멤버십을 무료로 제공했습니다.

3단계: 인과 효과

급증의 원인과 시작 시점을 파악했으니, 이제 자연적으로 예상되는 증가분과 분리하여 실제 투자수익을 파악해야 합니다. AI.CAUSAL_EFFECT는 ARIMA_PLUS 반사실을 구성하여 프로그램이 출시되지 않았을 경우의 이용량을 측정할 수 있습니다.

code_block: <ListValue: [StructValue([('code', "WITH daily_trips AS (\r\n SELECT \r\n TIMESTAMP_TRUNC(start_time, DAY) AS trip_day, \r\n COUNT(*) AS total_trips\r\n FROM `bigquery-public-data.austin_bikeshare.bikeshare_trips`\r\n -- Training on the 6-month baseline leading up to the intervention\r\n WHERE start_time BETWEEN '2017-08-11' AND '2018-04-11'\r\n GROUP BY 1\r\n)\r\nSELECT \r\n *\r\nFROM AI.CAUSAL_EFFECT(\r\n (SELECT * FROM daily_trips),\r\n data_col => 'total_trips',\r\n timestamp_col => 'trip_day',\r\n -- We inject the breakpoint found in Step 1 as our intervention\r\n intervention_timestamp => '2018-02-11 00:00:00',\r\n output_time_series => TRUE\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccd66c710>)])]>

예측된 일별 이용 건수와 실제 이용 건수를 그래프로 나타내면 반사실과 비교하여 이용량이 얼마나 급증했는지 확인할 수 있습니다.

output_time_series => FALSE를 설정하면 증가 효과의 요약 정보를 확인할 수 있습니다.

AI.CAUSAL_EFFECT에 따르면 이 프로그램으로 인해 이용량이 자연적인 기준 예측치보다 358% 높았으며, 이에 따라 약 89,775건의 추가 이용이 발생한 것으로 추정됩니다(인과 효과 확률 99.9%).

증강 분석을 대화형 분석에 연결

대화형 분석을 사용하면 자연어로 에이전트와 데이터에 관해 채팅할 수 있습니다. 이제 대화형 분석에서 새로운 BigQuery 증강 분석 함수를 모두 사용할 수 있습니다. 이러한 TVF는 BigQuery 규모의 복잡한 분석을 몇 초 만에 실행할 수 있으므로 대화형 분석은 주어진 프롬프트를 기반으로 여러 단계로 이루어진 조사 워크플로를 조정할 수 있습니다. 아래에서 두 가지 예시를 살펴보겠습니다.

예시 1: 시카고 택시 운행

다음은 시카고 택시 운행 데이터 세트(`bigquery-public-data.chicago_taxi_trips.taxi_trips`)를 사용하는 예시입니다.

프롬프트: 운전기사가 팁을 받는 것과 가장 상관관계가 높은 측정항목이 뭐야? 그리고 기여 분석을 실행하여 위치 및 결제 방식과 같은 범주형 측정기준 중 어떤 항목이 해당 측정항목에 과도한 영향을 미치는지 알려줘.

여기서는 ML.CORRELATION을 AI.KEY_DRIVERS와 함께 사용했습니다.

신용카드 결제는 이동 거리를 늘리는 주요 긍정적 요인으로, 장거리 이동 경로와 자동화된 디지털 팁 추적의 영향으로 165만 마일이 추가되었습니다. 오헤어 국제공항(커뮤니티 지역 76)에서 출발하는 운행 역시 주요 긍정적 요인으로, 팁을 지불한 신용카드 결제 운행에서 110만 마일을 추가로 기여했습니다. 반면 현금 거래는 상당한 부정적 요인(-652.960마일)으로 나타났습니다. 이는 현금이 장거리 공항 이동보다는 주로 단거리 이동에 사용된다는 점을 보여줍니다.

예시 2: 아이오와주 주류 데이터 세트

다음은 ML.TREND와 ML.SEASONALITY를 함께 사용하여 아이오와주 주류 데이터 세트(`bigquery-public-data.iowa_liquor_sales.sales`)를 분석하는 예시입니다.

프롬프트: 판매된 병 수의 과거 추세를 찾아 줘. 그런 다음 연간 계절성 패턴을 설명해 줘.

결과를 보면 아이오와주의 주류 판매량은 장기적으로 꾸준한 성장세를 보여 2012년 130만~150만 병에서 증가한 후 최근 몇 년 동안 약 260만 병으로 안정화되었습니다. 특히 10월부터 12월, 5월부터 6월에 판매량이 늘어나는 계절성을 보이며 1월과 2월에는 판매량이 감소합니다.

이러한 TVF의 스킬은 이제 Google Skills GitHub 저장소에서 사용할 수 있습니다. BQ AI/ML 스킬은 여기에서 확인할 수 있습니다.

다음 단계 수행

문서:

대화형 분석의 BigQuery AI/ML 지원

_{이 연구에 의견을 제공하고 기여해 주신 Katelin Amann, Shirley Fu, Chaoyi Shen, Haiyang Qi, Zheng Zhang, Xi Cheng을 비롯한 엔지니어링 팀원 여러분께 진심으로 감사의 말씀을 전합니다.}

Dataflow의 일시중지/재개 기능 및 NVIDIA RTX PRO 6000 Blackwell GPU 지원 발표

Sun, 20 Sep 2026 13:00:00 +0000

개요

기업은 AI 및 에이전트형 워크플로를 확장함에 따라 모델 학습, 평가, 추론을 위한 데이터 준비를 쉽고 효율적으로 수행할 수 있는 서버리스 플랫폼이 필요합니다. Dataflow는 Google Cloud AI 스택의 핵심 구성요소입니다. Google Cloud 고객은 Dataflow를 사용해 다양한 분석 과 AI 사용 사례를 지원하는 일괄 및 스트리밍 파이프라인을 만들 수 있습니다.

오늘 Google Cloud는 장기 실행 일괄 작업의 컴퓨팅 효율성을 극대화하고 가장 까다로운 AI 워크로드에 추가적인 추론 성능을 제공하는 등의 주요 과제를 곧바로 해결해 주는 Dataflow의 대대적인 개선 사항을 발표합니다. Dataflow 일괄 작업의 일시중지/재개 기능과 NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU로 구동되는 G4 VM 지원이 정식 출시되었습니다. 이러한 기능을 통해 AI 개발 수명 주기를 가속화하고 비용을 최적화할 수 있습니다.

Dataflow 일괄 작업 일시중지/재개 기능으로 낭비되는 컴퓨팅 리소스를 복구하고 개발자 생산성 향상Dataflow 고객은 며칠씩 소요되곤 하는 대규모 일괄 워크로드를 자주 실행합니다. 이러한 작업이 실패하면 현재로서는 Dataflow 사용자가 작업 실패 전에 이미 처리된 데이터에 액세스할 수 없습니다. 대신 전체 작업을 다시 시도해야 하므로 컴퓨팅 리소스가 낭비되고 엔지니어링 생산성이 저하됩니다.

대규모 작업의 실패를 해결하는 것 외에도, AI 워크로드를 사용하는 Dataflow 고객은 GPU 및 TPU 같은 가속화된 컴퓨팅 리소스를 이미 실행 중인 낮은 우선순위의 Dataflow 일괄 작업에서 특성 추출 및 AI 추론 등의 우선순위가 높은 워크로드로 동적으로 재할당하여 사용률을 높이고자 하는 경우가 있습니다.

이러한 사용 사례를 더 효과적으로 지원하기 위해 Dataflow 일괄 작업의 일시중지/재개 기능이 정식 버전으로 출시됩니다. Google 내부 혁신 기술을 기반으로 하는 이 기능을 통해 Dataflow 고객은 실패한 장기 실행 작업을 처음부터 새롭게 시작하는 대신 이어서 실행할 수 있습니다. 또한 고객은 각자의 비즈니스 요구사항에 따라 Dataflow 일괄 작업을 일시중지하고 재개할 수 있습니다.

자세한 내용은 Dataflow 작업 수동 일시중지를 참조하세요.

NVIDIA RTX PRO 6000 GPU로 AI 추론 워크로드 가속화

Dataflow에서 이미 AI 추론 워크로드를 가속화하기 위해 다양한 GPU와 TPU를 지원하고 있지만, Google Cloud는 여기에서 한 단계 더 나아가 NVIDIA RTX PRO 6000 Blackwell GPU 기반 G4 VM을 추가로 지원합니다.

NVIDIA RTX PRO 6000 Blackwell GPU는 NVIDIA L4 GPU에 비해 성능이 크게 향상되어 96GB vGPU 메모리와 1.6TB/s의 대역폭을 제공합니다. 즉, 최대 700억 개 이상의 파라미터 모델을 사용하여 Dataflow 작업 내에서 바로 AI 추론을 수행할 수 있습니다. 이와 동시에 RunInference, 적합 맞춤, GPU 지원 자동 확장과 같은 기본 Dataflow ML 기능을 계속 활용할 수 있습니다. 이러한 기능을 사용하면 기본 인프라를 관리하거나 조정 및 자동 확장과 같은 어려운 문제를 수동으로 처리할 필요 없이 AI 추론 작업을 쉽게 온보딩하고 확장할 수 있습니다.

다음 단계로 나아가기일시중지/재개 기능과 RTX PRO 6000 Blackwell GPU를 함께 사용하면 까다로운 AI 워크로드를 실행하면서 일괄 작업 비용을 최적화할 수 있습니다. Dataflow의 기능과 이를 통해 고객 여러분이 실현하게 될 가능성에 기대가 큽니다. 지금 바로 Dataflow를 시작하고 이러한 기능을 사용하여 가장 어려운 AI 과제를 해결해 보세요. 여러분이 빌드할 멋진 결과물을 기대하겠습니다.

Data Agent Kit를 사용한 에이전트 분석

Tue, 15 Sep 2026 18:00:00 +0000

월요일 아침, 담당 디렉터로부터 이런 채팅 메시지를 받았다고 상상해 보세요. 1월 평균 주문 금액이 7% 하락했는데 총매출은 그대로네요. 이유가 뭘까요?

데이터 실무자라면 이런 유형의 질문이 왜 까다로운지 아실 겁니다. 질문하고 있는 내용이 광범위하고 막연하기 때문입니다. 근본 원인을 한눈에 보여주는 대시보드가 따로 있는 것도 아닙니다. 웹 로그에 오류가 있었을까요? 프로모션 코드 구성이 잘못됐을까요? 직접 파헤쳐 보기 전까지는 알 수 없고, 한 곳에서만 답을 찾는 경우도 거의 없습니다.

답을 이루고 있는 조각들은 환경 곳곳에 흩어져 있습니다.

판매 내역(주문 및 품목)은 데이터 웨어하우스에 있습니다.
실시간 고객 레코드는 프로덕션 PostgreSQL 인스턴스에 있습니다.
마케팅 캠페인 규칙은 객체 스토어의 원시 JSON 파일로 저장되어 있습니다.

이러한 쿼리 중 하나를 작성하는 것은 쉽습니다. 다만 같은 쿼리를 수십 번 다시 작성하면서 WHERE 절을 손보거나 하위 쿼리를 추가해 가며 답을 찾아야 합니다. 그리고 다음 시스템으로 이동하여 다른 언어로 처음부터 시작해야 합니다. 그러다 보면 어느새 브라우저 탭 열 개를 띄워 놓고 오후 시간을 통째로 써버리게 됩니다. 질문 하나에 답하기 위해서 말이죠.

Data Agent Kit

Data Agent Kit는 바로 이러한 문제를 해결하기 위해 만들어졌습니다. 이는 데이터 개발자가 IDE에서 데이터 워크플로를 실행할 수 있도록 돕는 MCP 서버 및 에이전트 스킬 모음입니다. VS Code 포크(Antigravity IDE, Cursor)용 확장 프로그램과 기타 도구(Antigravity 2.0, Antigravity CLI, Claude Code, Codex)용 플러그인 형태로 모두 제공되므로, IDE를 벗어나지 않고도 답을 찾을 수 있습니다.

Data Agent Kit는 두 가지 핵심 메커니즘을 기반으로 합니다.

모델 컨텍스트 프로토콜(MCP): 에이전트를 도구, 데이터베이스, 원격 클라우드 인프라에 연결하는 개방형 표준입니다.
스킬: 에이전트의 지식을 보강하고, 사용자의 특정 스택과 상호작용하는 방법을 가르치는 마크다운 파일입니다.

Data Agent Kit를 사용하면, SQL 스니펫을 생성해 콘솔에 복사하여 붙여넣는 대신 에이전트가 사용자를 대신해 쿼리를 실행하고 결과를 읽을 수 있습니다.

앞서 살펴본 평균 주문 금액 시나리오에 적용하면 실제로 어떤 모습인지 살펴보겠습니다. 이 설정에서 데이터 웨어하우스는 BigQuery이고 Postgres 인스턴스는 Cloud SQL이며, 캠페인 규칙은 Cloud Storage에 있습니다.

Data Agent Kit 샘플 아키텍처

상황 파악하기

조사는 IDE의 채팅 창에서 시작합니다. 먼저 다음과 같은 자연어 프롬프트로 기준 수치를 확인합니다.

code_block: <ListValue: [StructValue([('code', 'BigQuery의 주문 및 주문 항목 테이블을 사용하여 2025년 8월부터 2026년 1월까지의 월별 평균 주문 금액을 계산해 줘.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8cccc05690>)])]>

작업 내용 확인하기

에이전트는 프롬프트를 처리하고 관련 스킬을 호출한 다음, 데이터 쿼리를 시작할 준비를 합니다. 하지만 IDE는 실행하기 전에 잠시 멈추고 필요한 MCP 도구(예: execute_sql_readonly)를 사용할 수 있는 권한을 요청합니다. 감사를 위해 한 번만 허용하거나 '항상 허용'을 선택하여 워크플로를 계속 진행할 수 있습니다. 승인이 완료되면 에이전트가 쿼리를 전송합니다.

채팅에서 스킬 및 BigQuery MCP 호출하기

에이전트형 IDE를 사용하면 실행 추적을 검사하여 각 MCP 도구 호출이나 BigQuery로 전송된 원시 SQL과 같은 항목을 확인할 수 있습니다. 생성된 코드를 눈여겨보는 것이 중요하지만, 익숙하지 않은 스키마를 대상으로 쿼리를 직접 작성하는 것보다는 읽는 편이 훨씬 시간이 적게 듭니다.

수치 분석하기

수치를 보니 평균 주문 금액은 8월부터 12월까지 약 110달러를 유지하다가 1월에 103달러로 떨어졌습니다. 그 이유를 파악하기 위해 에이전트에게 세부 분석을 요청해 보세요.

code_block: <ListValue: [StructValue([('code', '1월 평균 주문 금액(AOV)을 주문 유형별로 분류하여 자세한 상황을 공유해 줘.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc646190>)])]>

결과를 보면 비즈니스 자체가 위축된 것이 아니라 평균값이 왜곡된 것임을 알 수 있습니다. 온라인 및 오프라인 주문은 양호한 수준을 유지했습니다(약 110달러). 다만 1월에 B2B-Wholesale이라는 새로운 채널이 등장했지만, 이 채널의 AOV는 약 75달러에 불과했습니다. 감소한 항목은 없고 제품 조합이 변경되었을 뿐입니다.

Cloud SQL로 전환하기

이제 AOV가 낮아진 원인을 파악했습니다. 다음으로 도매 구매자가 누구인지 알아내야 합니다. 고객 레코드는 Cloud SQL Postgres 운영 데이터베이스에 저장되어 있으며, 동일한 채팅 대화목록에서 이어서 진행할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '이 B2B 고객은 누구야? Cloud SQL 데이터베이스에서 계정 세부정보와 생성 날짜를 확인해 줘.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8cc3fc2610>)])]>

에이전트가 Cloud SQL MCP로 전환해 customers 테이블을 검사합니다. 100개의 도매 계정은 모두 지난 30일 이내에 생성된 새로운 비즈니스 법인입니다. 12월에는 이 중 어느 것도 존재하지 않았습니다.

Cloud SQL에서 운영 고객 레코드 쿼리하기

터미널로 들어가기

BigQuery에서 B2B 주문을 간단히 살펴보면, 92%가 promo_code = BIGORDER25를 적용한 것을 알 수 있습니다. 이제 에이전트에게 이 코드를 캠페인 파일까지 추적해 달라고 요청하면, Google Cloud Storage MCP 서버를 사용해 해당 파일에 접근합니다.

마케팅 캠페인에 따르면 25% 할인 코드로 인해 저렴한 도매 주문이 대량으로 발생하여 통합 AOV가 감소한 반면 총매출은 변동이 없었습니다.

에이전트는 한 번의 채팅 세션에서 분석 데이터(BigQuery), 운영 레코드(Cloud SQL), 비정형 메타데이터(Cloud Storage)를 모두 쿼리하여 근본 원인을 찾아냈습니다.

디렉터에게 보고하기

이제 에이전트에게 디렉터를 위한 간단한 핵심 요약 보고서를 작성해 달라고 요청하면 됩니다.

에이전트가 생성한 핵심 요약

모두 끝났습니다. IDE에서 자연어 프롬프트 몇 개만으로 디렉터가 던진 광범위하고도 막연한 질문에 대한 답을 찾아냈습니다.

근본 원인 분석은 업무의 일부일 뿐입니다. 다음에 같은 문제가 발생했을 때 똑같은 과정을 반복하고 싶지는 않으실 겁니다. 대신 이번 조사 과정을 재현 가능한 데이터 모델로 전환할 수 있습니다.

재현 가능한 파이프라인 빌드하기

에이전트에게 일회성 분석을 지속적으로 사용할 수 있는 dbt 프로젝트로 전환해 달라고 요청합니다.

code_block: <ListValue: [StructValue([('code', 'BigQuery 스테이징 모델을 Cloud SQL 고객 및 반려동물 프로필 속성과 조인하는 dbt 프로젝트를 빌드해 줘. order_id에 고유성 테스트를 추가하고 dbt 빌드를 실행해 줘.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccd66eb90>)])]>

에이전트는 단일 프롬프트에서 dbt-bigquery를 사용하여 가상 Python 환경을 만들고 프로젝트 모델과 테스트를 작성합니다. 하지만 dbt 빌드가 실패합니다. 고유성 테스트가 order_id의 중복을 포착해 낸 것입니다.

이는 바로 고객이 반려동물을 두 마리 이상 키울 수 있기 때문입니다. 모델의 첫 번째 버전은 해당 프로필을 각 주문에 직접 연결했기 때문에 반려동물이 세 마리인 가구의 주문 하나가 세 개의 행으로 늘어나면서 고유성이 깨졌습니다.

에이전트는 자신의 터미널 출력을 읽고 실패 결과를 인식합니다. 그런 다음 dbt 로직을 다시 작성하고 빌드가 통과할 때까지 다시 실행합니다.

여기서 에이전트형 워크플로에 관한 중요한 사항을 소개합니다. 에이전트는 방대한 양의 코드를 작성할 수 있지만, 파이프라인에 대한 데이터 품질 검사는 여전히 사용자가 직접 적용해야 합니다. 다행히 이 검증 코드도 에이전트가 작성할 수 있습니다.

다음번에 경영진이 평균 주문 금액이 변동된 이유를 물어보면 dbt 모델을 통해 답변할 수 있습니다.

마무리

에이전트형 IDE를 사용하면 웨어하우스, 데이터베이스, 객체 스토어, 터미널 사이를 오갈 필요가 없습니다.

Data Agent Kit는 MCP와 같은 개방형 표준과 모듈식(및 편집 가능한) 에이전트 스킬을 결합하여 질문과 답변 사이의 마찰을 제거합니다. 익숙하지 않은 스키마를 살펴보고, 서로 다른 언어 사이를 오가며 변환하고, 수백 번 작성해 본 조인을 다시 작성하는 일은 이제 에이전트의 몫입니다. 여러분은 조사의 방향을 정하는 데 집중하면 됩니다.

체험해 보기

Data Agent Kit는 프리뷰 버전으로 제공되며 Antigravity(2.0, CLI, IDE), Claude Code, Codex, Cursor, 기타 인기 도구에서 기본적으로 작동합니다.

시나리오 사용해 보기: Data Agent Kit 및 Antigravity IDE를 사용한 분석 Codelab에서 전체 설정 과정을 살펴보세요.
문서 읽기: Google Cloud Data Agent Kit 확장 프로그램 문서에서 자세히 알아보세요.
플러그인 살펴보기: GitHub의 오픈소스 저장소에서 해당 스킬과 도구를 확인하세요.

Yahoo에서 Managed Service for Apache Spark의 가변형 VM으로 리소스를 최적화한 방법

Sun, 13 Sep 2026 18:00:00 +0000

수억 명의 사용자를 금융, 스포츠, 엔터테인먼트 플랫폼에 연결하는 글로벌 미디어 및 기술 기업인 Yahoo는 분석 워크로드를 지속적으로 빠르게 실행해야 하는 대규모 데이터 인프라를 운영하고 있습니다. 시간적 제약이 따르는 데이터 환경에서 고정된 가상 머신(VM) 구성에 의존하면 시스템의 유연성이 떨어집니다. 특정 머신 유형이 리전 내 용량 제한 문제에 직면하면 Managed Service for Apache Spark(이전 명칭: Dataproc)의 클러스터 프로비저닝이 지연되면서 중요한 데이터 파이프라인이 중단될 수 있습니다.

Yahoo는 Managed Service for Apache Spark 클러스터의 가변형 VM을 활용하여 허용 가능한 VM 유형의 우선순위 목록을 정의하는 방식으로 이러한 리소스 변동에 자동으로 대응합니다. 따라서 시스템은 리전 내 여러 영역을 동적으로 검색하고 수동 개입 없이 파이프라인 실행을 유지할 수 있습니다. 리전 전체에서 용량을 검색하려면 자동 영역 배치도 사용 설정해야 합니다.

이러한 최적화가 가능한 것은 온프레미스 Hadoop 및 빅데이터 환경을 바로 Google Cloud로 마이그레이션한 Yahoo의 광범위한 데이터 현대화 여정 덕분이었습니다. Yahoo는 레거시 워크로드를 이전하여 동적인 리소스 유연성을 갖추고 대규모 배치 및 스트리밍 분석을 실행할 수 있는 클라우드 기반을 구축했습니다.

이 게시물에서는 Managed Service for Apache Spark에서 가변형 VM 인스턴스의 우선순위를 구성하여 용량 제약을 자동으로 관리하고 파이프라인 실행을 유지하는 방법을 기술적인 관점에서 자세히 설명합니다.

정적 구성의 운영상 절충점

특정 영역에서 단일 고정 머신 유형으로 클러스터를 구성하면 리전 내 영역별 용량이 변동할 때 제약이 발생하여 클러스터 프로비저닝에 영향을 줄 수 있습니다. 가변형 구성을 사용하면 이처럼 용량 변동이 발생할 때 커스텀 재시도 로직이나 수동 개입으로 대응할 필요 없이 인프라가 자동으로 조정됩니다. 가변형 구성은 다양한 VM 유형을 수용하고 선택한 리전 내 여러 영역을 검색하여 프로비저닝을 간소화하며, 이를 통해 대규모 분석 워크로드를 더욱 효과적으로 지원합니다.

가변형 클러스터 구성을 위한 규칙

가변형 구성을 배포하려면 다음과 같이 서로 연결된 여러 설계 요소를 적절히 조정해야 합니다.

자동 영역 배치 사용 설정: Managed Spark가 전체 리전에서 사용 가능한 용량을 검색할 수 있도록 리전(--region=${REGION})이나 빈 영역 문자열(--zone="")을 전달해야 합니다.
코어 및 메모리 균형 유지: Managed Spark 클러스터에서 자동 확장을 사용하는 경우 가변형 목록에 포함된 모든 머신 유형은 서로 다른 VM 제품군에 속하더라도 코어 수와 메모리 크기가 비슷해야 합니다. 기본 작업자와 보조 작업자 간에 CPU 대 메모리 비율을 균일하게 유지하면 성능 저하를 방지할 수 있습니다. 가장 낮은 비율을 기준으로 실질적인 컨테이너 크기가 결정되기 때문입니다.
구성요소 속성 조정: Managed Spark는 VM 코어와 메모리를 기준으로 시스템 속성을 계산합니다. 서로 다른 머신 유형을 함께 사용하는 경우 예상되는 작업자 동작에 맞춰 YARN 및 Spark 리소스 할당을 유지하려면 속성을 명시적으로 재정의해야 할 수 있습니다.

가변형 VM이 대규모 워크로드를 지원하는 두 가지 방법

대규모 데이터 환경의 가변형 구성은 두 가지 방식으로 운영을 지원합니다.

클러스터 생성 성공률 개선: 선호하는 VM 유형의 가용 용량이 없더라도 Managed Spark가 우선순위 목록에서 다른 유형을 선택하므로 클러스터 생성에 실패하지 않고 프로비저닝을 중단 없이 지속합니다.
리전 리소스 활용도 향상: 자동 영역 배치는 리전 전체에서 가용 용량을 검색하므로 수요가 급증하는 시기에도 프로비저닝을 더욱 원활하게 처리할 수 있습니다.

gcloud 예시

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create analytics-cluster \\\r\n --region=us-central1 \\\r\n --zone="" \\\r\n --num-workers=10 \\\r\n --master-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --master-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["e2-standard-8"],"rank":0}\' \\\r\n --worker-instance-selection=\'{"machineTypes":["n2-standard-8"],"rank":1}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8cc3fc1ad0>)])]>

API 예시

`Dataproc` API의 `instanceFlexibilityPolicy` 필드를 사용하면 이 용량 정책을 자동화된 파이프라인이나 Managed Service for Apache Airflow DAG에 적용할 수도 있습니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "projectId": "PROJECT_ID",\r\n "clusterName": "analytics-cluster",\r\n "config": {\r\n "gceClusterConfig": {\r\n "zoneUri": ""\r\n },\r\n "secondaryWorkerConfig": {\r\n "numInstances": 8,\r\n "instanceFlexibilityPolicy": {\r\n "instanceSelectionList": [\r\n {\r\n "machineTypes": ["n2-standard-8"],\r\n "rank": 0\r\n },\r\n {\r\n "machineTypes": ["e2-standard-8", "t2d-standard-8"],\r\n "rank": 1\r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccde65c90>)])]>

이 API 정책은 동일한 목표를 달성합니다. 즉, 선호하는 유형을 설정하고 유효한 대체 수단을 명시하며 Managed Spark가 자동화 스크립트를 중단하지 않고 리소스 제약 조건을 해결할 수 있도록 만드는 것입니다.

인프라 정책 수립

이처럼 대규모로 데이터를 관리하려면 하나의 고정된 머신 유형에 의존하기보다 명확한 리소스 정책을 표준화해야 합니다. 구성 표준에는 다음 사항을 포함하는 것이 좋습니다.

보조 작업자에 사용할 기본 및 대체 VM 제품군
가변형 프로비저닝을 지원하기 위한 기본 자동 영역 배치
자동 확장 사용 시 동일한 코어 및 메모리 구성
예측 가능한 컨테이너 크기 유지를 위한 모든 작업자 그룹의 일관된 CPU 대 메모리 비율
서로 다른 머신 계열에서도 일관된 런타임 동작을 보장하기 위한 명시적인 YARN 또는 Spark 속성 재정의
Spot 또는 탄력성이 높은 용량에서 실행되는 Spark 워크로드를 위한 셔플 안정성 보장 패턴

가변형 구성을 도입하면 인프라 리소스가 부족한 상황에서도 예측 가능한 대체 계획에 따라 대응하여 중요한 데이터 파이프라인을 계속 실행할 수 있습니다.

Yahoo의 도입 효과 및 성과

Yahoo는 Managed Service for Apache Spark에 가변형 VM을 구현하여 리전 내 용량 부족으로 발생하는 클러스터 프로비저닝 실패를 85% 줄였습니다. 이러한 가변형 구성을 통해 데이터 인프라가 용량 제약에 자동으로 대응하고 수동 개입 없이 리소스를 성공적으로 프로비저닝할 수 있습니다. 그 결과 Yahoo는 대규모 데이터 파이프라인 전반에서 워크로드를 지속적으로 실행하고 다운스트림 처리 지연을 방지할 수 있게 되었습니다.

"Yahoo의 대규모 데이터 분석을 관리하려면 복원력이 뛰어난 자동화된 인프라가 필요합니다. Managed Service for Apache Spark의 가변형 VM으로 전환하면서 접근방식이 완전히 바뀌었습니다. 이제 특정 머신 유형에 용량 제약이 발생하더라도 클러스터가 중단되는 대신 우선순위가 지정된 대체 옵션으로 자동 전환됩니다. 덕분에 프로비저닝 실패를 85% 줄이고 전 세계 미디어 플랫폼을 원활하게 운영하는 데 필수적인 안정성까지 확보하게 되었습니다." - 악샤이 자인, Yahoo! 선임 소프트웨어 개발 엔지니어

가변형 인프라의 전략적 이점

가변형 컴퓨팅 스택을 도입하면 운영 요구사항에 따라 적응하는 동적인 리소스 풀로 환경을 전환할 수 있습니다. 경직된 단일 머신 유형 구성에서 벗어나면 공급 상황이 변하더라도 워크로드에 필요한 컴퓨팅 리소스를 안정적으로 확보할 수 있습니다. 이러한 전환은 워크로드 가용성과 안정성을 극대화할 뿐만 아니라, 최신 VM 세대를 우선적으로 활용하면서도 구형 유형을 안정적인 대체 옵션으로 유지할 수 있게 하여 원활한 하드웨어 현대화를 지원합니다.

복원력이 뛰어난 데이터 파이프라인 구축

유동적인 컴퓨팅 전략으로 전환하면 리전별 리소스 상황이 변하더라도 중요한 분석 워크로드를 계속 실행할 수 있습니다. 다음과 같은 방법으로 지금 바로 인프라 최적화를 시작할 수 있습니다.

워크로드 점검: 특정 VM 제품군이나 영역에 밀접하게 결합된 애플리케이션을 파악하고 사용할 수 있는 대체 하드웨어 유형을 정리하세요.
리소스 정책 표준화: Managed Spark 가변형 VM 문서를 살펴보고 선호하는 VM 제품군과 대체 VM 제품군을 설정하세요.
재무 전략 조정: 워크로드가 대체 머신 유형으로 동적으로 전환될 때 가변형 약정 사용 할인(Flex CUD)을 활용하여 비용 예측 가능성을 유지하세요.
크레딧 신청: 신규 고객에게는 Managed Service for Apache Spark 및 기타 Google Cloud 제품을 무료로 사용해 볼 수 있는 $300의 크레딧이 제공됩니다.

몇 주에서 몇 분으로: 데이터 파이프라인에 도래한 에이전트 시대

Mon, 07 Sep 2026 22:00:00 +0000

데이터 파이프라인은 현대 기업의 중추이지만, 이를 조정하는 데 진입 장벽이 존재하여 많은 데이터 전문가가 이 중요한 기능을 사용할 수 없는 형국입니다. Google Cloud는 Google Cloud NEXT 2026에서 오케스트레이션 파이프라인 프레임워크를 소개한 데 이어, 이러한 상황을 근본적으로 변화시키고 있습니다.

Google Cloud는 실무자가 이 강력한 프레임워크를 편리하게 사용할 수 있도록, 선호하는 IDE 또는 CLI(예: VS Code, Claude Code, Codex)에 바로 통합되는 데이터 엔지니어링 및 데이터 과학 도구로 구성된 무료 오픈소스 통합 컬렉션인 Data Agent Kit를 제공합니다.

Data Agent Kit는 두 가지 방식으로 오케스트레이션 파이프라인 프레임워크를 워크플로에 자연스럽게 끼워 넣습니다. 첫째, 포괄적인 파이프라인 관리를 위한 전용 데이터 엔지니어링 탭을 제공합니다. 둘째, 자연어를 사용하여 프로덕션급 Apache Airflow® DAG를 작성 및 배포하고 관련 문제를 해결하도록 설계된 전문화된 에이전트형 스킬이 포함되어 있습니다.

이러한 특화된 에이전트 스킬을 선언적 YAML DSL과 결합하면 분석가부터 머신러닝 엔지니어에 이르는 모든 데이터 담당자가 복잡한 Python Airflow 상용구를 우회할 수 있습니다. 이 프레임워크는 상위 수준의 조정 로직을 기본 컴퓨팅 실행에서 분리하여 데이터 조직 전체가 강력한 MLOps 기능에 쉽게 접근할 수 있게 해 줍니다.

이 게시물에서는 모범적인 MLOps 사용 사례를 통해 이를 얼마나 쉽게 달성할 수 있는지 살펴봅니다.

환경 설정하기

첫 번째 조정 파이프라인을 작성하기 전에, 먼저 로컬 개발 환경을 설정해야 합니다. 시작하는 데 2분도 걸리지 않습니다.

1. 확장 프로그램 설치 및 구성

VS Code, VS Code 포크, Antigravity, Claude Code, Antigravity CLI, Codex 등 원하는 IDE 또는 CLI에 확장 프로그램을 설치합니다. Google Cloud 계정으로 인증하려면 공식 문서의 단계별 설정 가이드인 Google Cloud Data Agent Kit 설치 가이드를 참고하세요.

2. 조정 파이프라인 스킬 확인

설치가 완료되면 필요한 에이전트 스킬이 활성화되어 있는지 확인합니다.

VS Code 작업 표시줄에서 'Google Cloud Data Agent Kit' 패널을 엽니다.
'설정(Settings)'으로 이동한 다음 '스킬(Skills)'을 선택합니다.
‘gcp-pipelines-orchestration’ 스킬이 사용 설정되어 있는지 확인합니다.

이 스킬은 에이전트에게 파이프라인 문법, 변수 대체, 보안 비밀 관리, Airflow 실행에 대한 자동화된 사고 진단과 관련된 심층적인 컨텍스트 지식을 제공합니다.

3. 첫 번째 파이프라인 빌드

자연어 프롬프트를 사용하여 VS Code 호환 IDE 내에서 바로 조정 파이프라인을 작성, 빌드, 검증하려면 공식 빌드 가이드인 파이프라인 빌드 가이드를 참고하세요.

비즈니스 문제 예시: 선제적인 공급망 관리

비즈니스 문제의 예시를 살펴보겠습니다. 물류 및 소매 부문에서 고객 만족도는 정확한 배송 예상 시간에 달려 있습니다. 주문이 예고 없이 지연되면 고객 이탈이 급증하고 지원 비용이 증가할 수 있습니다.

이를 해결하기 위해 Google Cloud는 창고 위치, 고객 위치, 주문 특징을 기반으로 정확한 배송 기간(일 단위)을 예측하는 엔드 투 엔드 MLOps 아키텍처를 구축하고 있습니다. 배송 전에 이러한 지연을 예측함으로써 운영팀은 서비스수준계약(SLA) 위반이 발생하기 전에 고객에게 선제적으로 상황을 알리거나 배송 등급을 자동으로 업그레이드할 수 있습니다.

Google Cloud는 이 아키텍처를 완전히 재현할 수 있도록 BigQuery의 공개 데이터 세트인 bigquery-public-data.thelook_ecommerce를 사용합니다. 데모를 위해 이 정적 데이터 세트를 학습 세트와 추론 세트로 분할했습니다. 실제 시나리오에서는 새로 들어오는 데이터에 대해 추론이 수행됩니다. 이 데이터 세트는 실제 운영상의 복잡성을 보여줍니다.

지리정보 데이터: 고객 주소(users)와 유통 센터(distribution_centers)의 위도 및 경도
시계열 데이터: 세분화된 주문 수명 주기 타임스탬프(created_at, shipped_at, delivered_at)
주문 속성: 제품 카테고리, 가격, 처리 상태(orders, order_items)

이 데이터 세트를 BigQuery, Managed Service for Apache Spark 서버리스, Gemini Enterprise Agent Platform, dbt와 결합하여 학습, 일일 배치 추론, 모델 드리프트 평가를 처리하는 자동화된 자가 복구 MLOps 루프를 빌드하는 방법을 보여드리겠습니다.

에이전트형 워크플로: 프롬프트에서 파이프라인까지 몇 분 만에 완료

확장 프로그램을 구성하면 DAG 작성을 위한 상용구 Python을 완전히 우회할 수 있습니다. VS Code 내에서 Data Agent Kit 채팅을 열고 지속적인 MLOps 피드백 루프를 정의하는 단일 자연어 프롬프트를 제공했습니다.

참고: 이 블로그 게시물을 위해 특별히 반복성을 염두에 둔 상세한 프롬프트를 작성했습니다. 실제 시나리오에서는 파이프라인별로, 더 자연스러운 대화 방식을 사용해 동일한 결과를 얻을 수 있습니다. 전체 프롬프트와 생성된 모든 파일은 Orchestration-pipelines GitHub 저장소에서 확인할 수 있습니다.

참고: 오케스트레이션 파이프라인 스킬을 갖춘 프런티어 모델은 하나의 단계만으로도 전체 워크플로를 스캐폴딩할 수 있지만, LLM 응답은 모델 버전, 작업공간 컨텍스트, 토큰 깊이에 따라 자연스럽게 달라집니다. 1차 시도에서 특정 파라미터, 데이터 세트 경로 또는 종속 항목이 누락된 경우, 간단한 후속 프롬프트를 제공하면 됩니다.

몇 분 만에 Data Agent Kit가 기본 PySpark 스크립트, dbt 구성, 세 가지 선언적 YAML 파이프라인을 생성했습니다.

아래에 생성된 YAML 파이프라인과 시각적 다이어그램이 나와 있습니다. 이 파이프라인은 오케스트레이션 파이프라인 기능을 보여주기 위해 설계된 간소화된 예시입니다. 실제로 권장되는 프로덕션 MLOps 설정은 특정 사용 사례와 운영 요구사항에 따라 달라집니다.

파이프라인 1: 학습 엔진

이 파이프라인은 고성능 컴퓨팅 엔진 역할을 합니다. 에이전트는 BigQuery를 먼저 쿼리하여 완료된 과거 주문을 추출하는 YAML 정의를 생성했습니다. 그런 다음 Managed Spark 서버리스 클러스터를 동적으로 프로비저닝하여 지리적 거리를 계산하고 프로덕션용 모델을 학습시킵니다. 마지막으로, 학습된 모델을 Gemini Enterprise Agent Platform Model Registry에 푸시합니다.

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "training-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_training_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.training_dataset"\r\n query:\r\n path: "blogpostdemo/training_query.sql"\r\n\r\n - pyspark:\r\n name: "train_model_dataproc"\r\n dependsOn:\r\n - "extract_training_data"\r\n engine:\r\n dataprocServerless:\r\n location: "us-central1"\r\n resourceProfile:\r\n inline:\r\n runtimeConfig:\r\n version: "2.3"\r\n properties:\r\n "spark.dataproc.driverEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n "spark.executorEnv.PYTHONPATH": "./libs/lib/python3.11/site-packages"\r\n mainFilePath: "blogpostdemo/train_model.py"\r\n environment:\r\n requirements:\r\n inline:\r\n list:\r\n - "tensorflow==2.14.1"\r\n - "numpy<2.0.0"\r\n - "protobuf<5.0.0dev"\r\n - "google-cloud-storage"\r\n\r\n - ai:\r\n name: "upload_model_vertex"\r\n dependsOn:\r\n - "train_model_dataproc"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n modelUpload:\r\n modelName: "transit_days_predictor"\r\n modelArtifactUri: "gs://your-bucket-name/models/tf_transit_days_model"\r\n servingContainerImageUri: "us-docker.pkg.dev/vertex-ai/prediction/tf2-cpu.2-14:latest"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccde83990>)])]>

파이프라인 2: 일일 추론

일상적인 운영 워크플로를 위한 이 경량 파이프라인은 학습된 모델을 현재 배송 중인 모든 주문 건에 적용합니다. BigQuery 작업을 통해 데이터 세트를 쿼리하고, Gemini Enterprise Agent Platform을 통해 추론 작업을 실행하고, 결과를 BigQuery 테이블에 다시 작성하여 고객 지원팀에 SLA 위반 가능성이 있는 주문 건을 알려줍니다.

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "inference-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - sql:\r\n name: "extract_inference_data"\r\n engine:\r\n bigquery:\r\n location: "US"\r\n destinationTable: "your-project-id.mlops.inference_dataset"\r\n query:\r\n path: "blogpostdemo/inference_query.sql"\r\n\r\n - ai:\r\n name: "run_vertex_batch_prediction"\r\n dependsOn:\r\n - "extract_inference_data"\r\n agentPlatform:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n batchInference:\r\n jobDisplayName: "inference_job"\r\n modelName: "projects/your-project-id/locations/us-central1/models/your-model-id"\r\n bigquerySource: "bq://your-project-id.mlops.inference_dataset"\r\n bigqueryDestinationPrefix: "bq://your-project-id.mlops"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8cccc26450>)])]>

파이프라인 3: 자동 평가 및 브랜칭

일일 평가 파이프라인은 자동화된 품질 게이트 역할을 합니다. dbt 모델을 트리거하여 예측 데이터와 실제 배송 타임스탬프를 조인한 다음, 절대 오차와 SLA 위반 건수를 산출합니다.

파이프라인은 기본 로직을 사용하여 이러한 측정항목을 자동으로 평가합니다. 모델의 오류율이 허용 가능한 기준점을 초과하면 조건부로 'training-pipeline'을 트리거하여 새로운 모델을 생성합니다.

code_block: <ListValue: [StructValue([('code', 'modelVersion: "1.0"\r\npipelineId: "evaluation-pipeline"\r\nrunner: airflow\r\nowner: "mlops"\r\ntags:\r\n - "job:datacloud:antigravity"\r\ndefaults:\r\n projectId: "your-project-id"\r\n location: "us-central1"\r\n executionConfig:\r\n retries: 0\r\n\r\nactions:\r\n - pipeline:\r\n name: "run_dbt_models"\r\n framework:\r\n dbt:\r\n airflowWorker:\r\n projectDirectoryPath: "blogpostdemo/dbt_project"\r\n\r\n - python:\r\n name: "check_retraining_condition"\r\n dependsOn:\r\n - "run_dbt_models"\r\n mainFilePath: "blogpostdemo/evaluate_drift.py"\r\n pythonCallable: "check_drift"\r\n engine:\r\n local: {}\r\n\r\n - orchestrationPipeline:\r\n name: "trigger_retraining_pipeline"\r\n dependsOn:\r\n - "check_retraining_condition"\r\n pipelineId: "training-pipeline"\r\n bundleId: "my-first-bundle"\r\n waitForCompletion: false'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8cccc64cd0>)])]>

Managed Service for Apache Airflow에 자동 배포

파이프라인 로직을 작성하는 것은 절반의 성공에 불과합니다. 이를 프로덕션에 안전하게, 그리고 확실하게 배포하는 과정에서 데이터팀은 많은 시간을 허비해 왔습니다.

오케스트레이션 파이프라인을 사용하면 표준 CI/CD 방식을 통해 배포가 간소화됩니다. Data Agent Kit는 배포 스크립트를 수동으로 작성하거나 복잡한 환경 경계를 구성하는 대신 작업공간에 필요한 지속적 통합 워크플로(예: GitHub Actions)를 자동으로 생성합니다.

즉, 커밋을 클릭하기만 하면 프레임워크가 오케스트레이션 파이프라인 번들을 원활하게 패키징하고 Managed Airflow 환경에 바로 배포합니다.

이러한 자동화된 워크플로를 기존 CI/CD 파이프라인에 통합하는 방법에 대한 포괄적인 가이드는 공식 가이드인 오케스트레이션 파이프라인 배포를 참고하세요.

2일 차 운영: 모니터링 및 에이전트형 문제 해결

이러한 파이프라인을 유지관리하는 것은 빌드 과정만큼이나 직관적입니다. Data Agent Kit는 조정 컨트롤 플레인을 IDE에 바로 가져오는 방식으로, 브라우저 탭 간에 지속적으로 컨텍스트를 전환할 필요 없이 Managed Airflow 실행을 실시간으로 모니터링할 수 있도록 지원합니다.

Data Agent Kit는 IDE 내에서 직접 Managed Airflow 실행을 실시간으로 모니터링할 수 있는 기능을 제공합니다.

Data Agent Kit는 생성된 파이프라인을 시각화합니다.

인프라 문제나 데이터 문제는 필연적으로 발생합니다. 예를 들어, 계절적 데이터 급증으로 인해 Managed Spark 클러스터에서 메모리 부족 예외가 발생하거나 BigQuery 할당량에 도달할 수 있습니다. 이러한 문제를 해결하기 위해 더 이상 수천 줄의 원시 실행 로그를 뒤질 필요가 없습니다.

파이프라인이 실패하면 Data Agent Kit가 즉시 사용 가능한 에이전트형 문제 해결 기능을 제공합니다. IDE에서 '문제 해결' 버튼을 클릭하면 데이터 엔지니어링 에이전트가 실패 컨텍스트를 분석합니다. 에이전트가 인프라 할당량 한도와 코드 수준 버그를 정확하게 구분하여 근본 원인 요약을 즉시 제공하고 인라인 수정(예: 컴퓨팅 템플릿 수직 확장)을 제안해 줍니다.

에이전트형 문제 해결 기능은 파이프라인 장애를 즉시 진단하고, 인프라 병목 현상을 식별하며, 인라인 수정 사항을 제안합니다.

요약: 가치 실현 시간 단축

과거 데이터 추출, dbt 변환 실행, Managed Spark ML 컴퓨팅 프로비저닝, 모델 레지스트리 및 추론을 위한 Gemini Enterprise Agent Platform 통합, 교차 DAG 조건부 트리거 구성까지, 복원력이 우수한 MLOps 아키텍처를 빌드하기 위해서는 플랫폼 엔지니어링팀이 몇 주에 걸쳐 복잡한 Python Operator 로직을 작성해야 했습니다.

오케스트레이션 파이프라인과 Data Agent Kit를 사용하면 이 전체 수명 주기를 단 몇 분 만에 작성하고, 배포하고, 유지보수할 수 있습니다. Google Cloud는 상용구 인프라 코드를 선언적인 에이전트 지원 표준으로 대체하여, 데이터 조직이 파이프라인을 조정하는 데 드는 시간을 줄이고 실질적인 비즈니스 가치를 창출하는 데 더 많은 시간을 투자할 수 있도록 지원합니다.

지금 시작해 보세요.

오케스트레이션 파이프라인 문서를 살펴보세요.
원하는 IDE 또는 CLI에 Data Agent Kit를 설치하고 작업공간을 구성하세요.
Google Cloud의 최근 블로그 게시물인 Data Agent Kit를 통해 IDE 또는 CLI에 데이터 스킬과 도구 도입에서 더 광범위한 생태계에 대해 자세히 알아보세요.
Data Agent Kit 문서에서 참조 아키텍처를 살펴보세요.

BigQuery의 TabFM 소개: 완전히 새로워진 예측 분석

Mon, 07 Sep 2026 22:00:00 +0000

기존에는 이탈 가능성, 구매 의도 예측, 사기 위험 점수 산정과 같은 엔터프라이즈 예측 분석 작업을 수행하려면 XGBoost, Random Forest, 심층 신경망(DNN) 등의 라이브러리를 활용해 커스텀 모델을 구축해야 했습니다. 기존의 학습-조정-배포-재학습 주기는 효과적이긴 하지만 복잡하고 시간이 많이 걸릴 수 있습니다. 또한 수동 특성 추출, 하이퍼파라미터 조정, 장시간이 소요되고 비용이 많이 드는 학습, 전문 데이터 과학 기술의 필요성으로 인한 오버헤드 때문에 기업이 의사 결정 과정에서 예측 모델을 충분히 활용하지 못하는 경우가 있습니다.

오늘은 BigQuery의 새로운 TabFM 모델 출시 소식을 전해드립니다. Google 연구팀에서 개발한 TabFM은 테이블 형식 데이터의 회귀 및 분류를 위한 최첨단 사전 학습 파운데이션 모델입니다. TabFM은 컨텍스트 내 학습(ICL)을 활용해 별도의 학습이나 배포 과정 없이 단일 SQL 문만으로 테이블 형식 데이터 세트에서 즉각적이고 정확한 예측 결과를 도출합니다. BigQuery용 TabFM은 현재 프리뷰 단계이며

BigQuery 분석에 다음과 같은 기능을 제공합니다.

제로샷 예측: 모델 학습, 조정, 아티팩트 배포 과정을 건너뛸 수 있습니다. 라벨이 지정된 과거 데이터와 새 예측 테이블을 단일 SQL 함수에 전달하기만 하면 즉시 고품질 예측 결과를 얻을 수 있습니다.
에이전트형 애플리케이션을 위한 예측 ML: 비즈니스 용도의 에이전트를 구축하고 있나요? TabFM과 BigQuery MCP 서버를 함께 사용하여 예측 기능을 추가하세요. 별도의 런타임이나 인프라를 관리할 필요 없이 데이터를 입력하는 즉시 예측 결과가 출력됩니다.
현존 최고 수준(SOTA)의 정확도: 복잡한 데이터 세트에서 학습한 기존의 커스텀 학습 모델이나 기성 모델을 능가하는 성능을 발휘하며 업계 벤치마킹에서 우수한 정확도 점수를 기록합니다.
간편한 개발자 환경: BigQuery에서 기본적으로 실행되며 간단한 SQL 문법을 통해 액세스할 수 있습니다. 결측값 처리, 범주형 인코딩과 같은 특성화 작업을 자동으로 처리하므로 복잡한 특성 추출 파이프라인을 직접 관리할 필요가 없습니다.
확장성: BigQuery의 분산 추론 아키텍처를 사용하여 수백만 행 규모의 대규모 추론 테이블도 몇 분 만에 처리합니다.

테이블 형식 예측을 위한 선도적인 모델

Google의 TabFM은 다양한 테이블 형식 데이터에서 업계 최고 수준의 정확도를 제공합니다. TabArena 벤치마크 평가에서 TabFM은 기존 머신러닝 모델과 다른 테이블 형식 파운데이션 모델을 모두 지속적으로 능가했습니다.

TabArena 분류(위) 및 회귀(아래) 상위 10개 모델의 ELO 평점(↑) (D) = 기본값, (T+E) = 조정 + 앙상블. 점수가 높을수록 성능이 우수합니다.

여기에서 TabFM 모델에 대해 자세히 알아보세요.

BigQuery에서 TabFM 시작하기

TabFM은 간단하게 사용할 수 있습니다. 이 기능은 새로운 기본 제공 SQL 함수인 AI.PREDICT와 AI.EVALUATE를 통해 직접 사용할 수 있습니다.

1. AI.PREDICT로 즉각적인 예측 결과 얻기예측을 수행하려면 학습 데이터와 예측 데이터를 전달하는 단일 쿼리를 작성하면 됩니다. 모델은 타겟 라벨의 데이터 유형을 기준으로 해당 작업이 분류 문제인지 회귀 문제인지 자동으로 추론합니다.

code_block: <ListValue: [StructValue([('code', "-- Classifying transactions as fraudulent or not\r\nSELECT *\r\nFROM AI.PREDICT(\r\n TABLE `my_project.my_dataset.historical_transactions`, -- Training data (in-context examples)\r\n TABLE `my_project.my_dataset.new_transactions`, -- Prediction data\r\n label_col => 'is_fraud'-- Target column to predict\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc4789d0>)])]>

이 예시의 출력 결과에는 예측 테이블의 모든 기존 열과 함께 예측된 라벨 및 확률 열(예: predicted_is_fraud)이 포함됩니다. 별도의 수동 특성 추출이나 모델 생성 과정이 전혀 필요하지 않았습니다.

2. AI.EVALUATE로 모델 평가하기

AI.EVALUATE 함수를 사용하여 테스트 세트에 대한 예측 성능을 신속하게 확인할 수 있습니다. 이를 통해 표준 평가 측정항목을 한 단계로 생성할 수 있습니다.

code_block: <ListValue: [StructValue([('code', "-- Regression Evaluation for Customer Lifetime Value (LTV)\r\nSELECT *\r\nFROM AI.EVALUATE(\r\n TABLE `my_project.my_dataset.historical_customer_ltv`,\r\n TABLE `my_project.my_dataset.test_customer_ltv`,\r\n label_col => 'ltv'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccd8dd590>)])]>

AI.EVALUATE는 회귀 문제의 경우 r2_score, mean_absolute_error 등의 다양한 측정항목을 반환하고, 분류 문제의 경우 precision, recall, f1과 같은 측정항목을 반환합니다.

BigQuery의 TabFM 내부 작동 방식

기존 머신러닝 방식에서는 학습 데이터 세트에 모델 파라미터를 맞추는 과정이 필요합니다. 반면 TabFM은 컨텍스트 내 학습을 사용합니다. 대규모 언어 모델(LLM)이 프롬프트의 퓨샷 예시를 통해 작업을 학습하는 방식과 유사하게 TabFM은 학습 테이블을 컨텍스트 내 예시로 읽어 한 번의 정방향 전달만으로 타겟 테이블에 대한 예측을 생성합니다.

테이블 형식 파운데이션 모델의 연산 복잡성과 메모리 사용량을 처리하기 위해 BigQuery는 데이터에 대해 분산 병렬 추론을 수행합니다. 또한 성능과 리소스 활용을 최적화하기 위해 지능형 학습 데이터 샘플링과 분산 실행을 사용합니다. 이를 통해 BigQuery는 대량의 학습 데이터 입력 행을 처리하면서도 수백만 행 규모의 추론 데이터에 대해 빠르고 효율적으로 예측을 실행할 수 있습니다.

작업에 적합한 도구 선택하기

TabFM은 BigQuery에 획기적인 제로샷 기능을 추가하며 XGBoost 모델과 같은 기존 기능을 보완합니다. TabFM과 다른 모델 중 어떤 것을 선택할지는 다음 기준을 참고하세요.

머신러닝 전문 지식 없이 신속하게 고품질 예측 인사이트를 얻고 싶을 때, 과거 데이터 세트가 중소 규모이거나 데이터가 자주 변경되는 경우, 그리고 정확도 유지를 위해 모델을 빈번하게 재학습해야 할 때 TabFM을 사용하세요. 필요할 때마다 예측 분석을 수행해야 하는 대화형 워크플로 또는 에이전트형 워크플로에도 적합합니다.
과거 데이터 세트가 매우 방대하거나, 커스텀 하이퍼파라미터 조정에 대한 완전한 제어권이 필요할 때, 또는 특성 수가 TabFM의 현재 제한을 초과하거나, 어떤 입력 특성이 예측에 가장 크게 기여했는지 파악하는 특성 중요도 기반의 설명 가능성이 필요한 경우에는 XGBoost와 같은 기존 모델을 사용하세요.

더 간편해진 예측 머신러닝

TabFM이 BigQuery에 기본 통합되면서 이제 일반적인 SELECT 쿼리를 실행하는 것만큼이나 쉽게 예측 ML을 활용할 수 있게 되었습니다. 모델 학습, 조정, 관리에 따르는 번거로운 수동 오버헤드를 제거한 TabFM 덕분에 개발자와 데이터 과학자, 분석가는 몇 초 만에 원시 데이터에서 풍부한 예측 인사이트를 도출할 수 있습니다.

지금 시작하려면 공개 문서를 참조하세요. 궁금한 점이나 의견은 bqml_feedback@google.com으로 Google팀에 문의해 주세요. 여러분이 만들어나갈 멋진 결과물을 기대하고 있겠습니다.

BigQuery 그래프 정식 버전 출시: 에이전트 시대를 위한 지식 기반

Mon, 07 Sep 2026 13:00:00 +0000

엔터프라이즈 데이터에서 중요한 질문 중 상당수는 개별 행에 관한 것이 아니라 데이터가 서로 어떻게 연결되는지에 관한 것입니다. 두 계정이 어떻게 연결되는지, 결제가 어떤 경로를 거쳤는지, AI 에이전트의 답변이 어떤 컨텍스트에 기반하는지 등이 이에 해당합니다. 그래프는 바로 이러한 문제를 해결하기 위해 만들어졌습니다. 과거에는 이러한 인사이트를 얻으려면 데이터를 독립형 그래프 데이터베이스로 추출해야 했기 때문에 사일로와 운영 오버헤드가 발생했습니다. 이러한 장벽을 제거하기 위해 Google Cloud는 데이터 웨어하우스에 직접 네이티브 그래프 기능을 도입했습니다. 오늘 Google은 BigQuery 그래프의 정식 버전을 발표합니다.

Google Cloud는 그래프 분석과 관계형 분석을 통합하기 위해 BigQuery 그래프를 프리뷰 버전으로 처음 선보였습니다. ISO 표준 Graph Query Language(GQL)는 SQL과 함께 사용되고, 순회는 기본적으로 실행되며, ETL은 필요하지 않습니다. BigQuery를 기반으로 빌드된 BigQuery 그래프는 BigQuery의 기능을 그대로 사용하고 이를 더욱 확장합니다. 수직 확장 데이터베이스의 메모리 병목 현상 없이 페타바이트 규모까지 도달하고, 기존 행 및 열 수준 보안에서 실행되며, 동일한 쿼리에서 BigQuery ML 및 AI 함수를 호출합니다. 하나의 엔진으로 대규모 그래프 분석과 AI 에이전트를 위한 연결된 컨텍스트라는 두 가지 작업을 수행합니다.

"BigQuery 그래프는 위협 감지 파이프라인의 판도를 바꾸어 놓았으며, 이를 통해 단순하고 사일로화된 알림을 넘어설 수 있었습니다. 보안 신호 데이터를 속성 그래프로 모델링함으로써 이전에는 컴퓨팅 성능의 한계로 인해 불가능했던 복잡한 멀티홉 순회를 몇 초 만에 수행할 수 있게 되었습니다. 이러한 그래프 중심 접근 방식은 이상치를 일관된 공격 스토리로 자동 클러스터링하며, Gemini 모델의 원활한 통합과 결합되어 실행 가능한 위협 내러티브를 생성하는 데 도움이 됩니다. 앞으로 네이티브 BigQuery 그래프 알고리즘을 통합하여 워크플로를 더욱 간소화할 수 있기를 기대합니다." - Pete Rubio, Thales Cybersecurity Products 글로벌 엔지니어링 부문 부사장

프리뷰 이후 다양한 업계의 데이터팀이 분석 및 에이전트 워크플로에 BigQuery 그래프를 도입했습니다.

위협 및 사기 감지: 보안 및 금융 기관은 이벤트 로그 전반의 신호를 상호 연관시켜 멀티홉 공격 경로, 사기 네트워크, 의심스러운 거래 루프를 찾아냅니다.
공급망 디지털 트윈: 제조 및 물류 조직은 공급업체, 부품, 유통 경로 전반의 종속성을 매핑하여 중단 상황을 시뮬레이션하고 주문 처리를 최적화합니다.
ID 확인 및 Customer 360: 광고 기술 및 소매 플랫폼은 여러 채널에 분산된 사용자 식별자와 행동 터치 포인트를 연결하여 통합 고객 프로필을 구축합니다.
지식 그래프 및 AI 에이전트 그라운딩: 엔터프라이즈 AI팀은 비정형 문서에서 정형 지식 그래프를 빌드하여 Gemini 모델과 GraphRAG 워크플로를 그라운딩하기 위한 도메인 컨텍스트를 제공합니다.
네트워크 계보 및 인프라 관리: 통신 및 엔터프라이즈 IT팀은 멀티홉 경로 전반에서 복잡한 네트워크 토폴로지, 서비스 종속성, 데이터 계보를 추적합니다.

BigQuery 그래프의 새로운 기능

정식 버전 출시는 단순히 안정성 측면에서 중요한 이정표를 달성했다는 의미를 넘어섭니다. 관련 작업은 크게 두 가지 방향으로 진행되었습니다. 하나는 그래프 엔진 자체를 더 빠르고 광범위하게 만드는 것이고, 다른 하나는 이를 중심으로 에이전트 생태계를 구축하는 것이었습니다. 이를 통해 에이전트는 그래프를 빌드하고, 그래프와 채팅하고, 감사 가능한 메모리를 그래프에 유지할 수 있습니다. 다음 기능 중 일부는 현재 정식 버전으로 제공되고 있으며, 일부는 프리뷰로 제공되거나 앞으로 몇 주에 걸쳐 순차적으로 출시될 예정입니다.

더 빠르고 광범위한 그래프 엔진

“광고 업계는 수십 년 동안 개별 이벤트를 최적화하는 데 집중해 왔습니다. 하지만 에이전트 시대에는 이벤트 간의 관계를 최적화하게 될 것입니다. Yahoo에서는 BigQuery 그래프를 통해 AI 에이전트에 캠페인, 잠재고객, 노출, 결과를 아우르는 연결된 컨텍스트를 제공합니다. 별도의 그래프 엔진이나 데이터 이동 없이 수익 창출 데이터가 이미 저장된 바로 그곳에서 표준 GQL을 사용해 이러한 데이터를 탐색할 수 있습니다. 에이전트는 단순히 그래프를 읽는 데 그치지 않고, 그래프를 기반으로 추론하고 그 결론을 새로운 관계로 다시 작성합니다. 이것이 바로 수익 창출이 자동화를 넘어 신뢰할 수 있는 자율 시스템으로 발전하는 방식입니다.” - Mikul Bhatt, Yahoo 수익 창출 플랫폼 엔지니어링 부문 이사

경계 없는 그래프 레이크하우스

에이전트의 성능은 추론에 활용할 수 있는 컨텍스트에 따라 달라지며, 이러한 컨텍스트는 한곳에 있는 경우는 드뭅니다. 경계 없는 레이크하우스를 사용하면 하나의 BigQuery 그래프가 네이티브 BigQuery 테이블은 물론, Databricks Unity Catalog, AWS Glue 또는 Snowflake를 통해 다른 클라우드에 있는 개방형 Iceberg 테이블까지 아우를 수 있습니다. 데이터를 복사하거나 ETL 파이프라인을 빌드하지 않고도 데이터가 있는 위치에서 그대로 순회할 수 있습니다.

고객 지원 담당자가 "이 고객의 주문 지연과 관련된 제품을 공급하는 업체는 어디이며, 어디에 기반을 두고 있나요?"라는 질문에 답해야 한다고 가정해 보겠습니다. 고객 데이터는 Google Cloud의 Iceberg 레이크하우스에 있고, 제품 및 공급업체 레코드는 AWS의 Databricks 카탈로그에 있습니다. 에이전트는 요청이 있을 때마다 소스를 끼워 맞추는 대신, 이미 소스가 연결되어 있는 하나의 가상 지식 그래프를 순회하여 이동하지 않은 데이터를 탐색합니다.

그림 1: 데이터 이동 없이 Google Cloud(파란색 노드), AWS(노란색 노드), 기타 클라우드(녹색 노드)에 걸쳐 구성된 가상 지식 그래프를 보여주는 다이어그램

다음 DDL 문은 두 클라우드 환경에서 노드 및 에지 테이블을 직접 매핑하여 이 가상 그래프를 정의하는 방법을 보여줍니다.

code_block: <ListValue: [StructValue([('code', '-- A virtual knowledge graph spanning two clouds - no data movement\r\nCREATE OR REPLACE PROPERTY GRAPH `my_project.retail.virtual_kg`\r\n NODE TABLES (\r\n -- Google Cloud\r\n `my_project.gcs_lake.retail.customers` AS Customer KEY (customer_id),\r\n -- AWS\r\n `my_project.dbx_fed_catalog.retail.products` AS Product KEY (product_id),\r\n `my_project.dbx_fed_catalog.retail.suppliers` AS Supplier KEY (supplier_id)\r\n )\r\n EDGE TABLES (\r\n `my_project.gcs_lake.retail.purchases` AS Bought KEY (purchase_id)\r\n SOURCE KEY (customer_id) REFERENCES Customer (customer_id)\r\n DESTINATION KEY (product_id) REFERENCES Product (product_id),\r\n `my_project.dbx_fed_catalog.retail.products` AS Supplied_By KEY (product_id)\r\n SOURCE KEY (product_id) REFERENCES Product (product_id)\r\n DESTINATION KEY (supplier_id) REFERENCES Supplier (supplier_id)\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccdca5150>)])]>

이를 통해 에이전트는 한 번의 순회에서 두 클라우드에 걸쳐 조합하여 그라운딩된 멀티홉 답변을 얻습니다.

code_block: <ListValue: [StructValue([('code', "-- Agent grounding: trace a customer to the supplier behind their product, across clouds\r\nGRAPH `my_project.retail.virtual_kg`\r\nMATCH (c:Customer {customer_id: 'C1'})-[:Bought]->\r\n (:Product)-[:Supplied_By]->(s:Supplier)\r\nRETURN s.name AS supplier, s.country AS supplier_country"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8ccc478410>)])]>

더 빠르고 표현력이 향상된 GQL

BigQuery 그래프는 연결에 관한 질문을 처리하기 위해 빌드되었습니다. 두 계정이 어떻게 연결되어 있는지, 결제가 어떤 경로를 거쳤는지, 플래그가 지정된 항목에서 몇 홉 이내에 어떤 항목이 있는지 등을 파악할 수 있습니다. 이러한 질문은 SQL 조인으로 표현하기 까다로우며, 바로 이 부분에서 그래프 엔진의 진가가 발휘됩니다. 정식 버전에서는 실행 속도가 더 빨라지고 작성하기가 더 쉬워졌습니다.

더 빠른 실행. 정식 버전에서는 비순환 및 무방향 순회를 위한 경로 탐색 기능을 최적화했습니다. 공개 벤치마크에 따르면 GQL은 프리뷰 이후 2배 더 빨라지고 무방향 순회는 100배 더 빨라졌으며, ACYCLIC 및 TRAIL 경로 모드에서 더 빠르고 리소스 효율적인 순환 감지를 제공합니다. 쿼리 지연 시간이 단축되어 에이전트의 답변을 그라운딩하는 주변 및 경로 조회를 빈번한 대화형 액세스 환경에서도 빠르게 처리할 수 있습니다.
표현력이 향상된 쿼리. 새로운 CALL 문 과 확장된 서브 쿼리 지원을 통해 결과의 각 항목에 대해 그래프 서브 쿼리를 실행하거나 재사용 가능한 이름이 지정된 함수를 호출할 수 있습니다. 따라서 복잡한 질문을 하나의 방대한 패턴이 아닌 여러 부분으로 나눌 수 있습니다. 분석가가 작성하는 동일한 함수를 에이전트가 도구로 호출하는 구성요소로 활용할 수도 있습니다.

에이전트 시대를 위한 설계

“기업에는 인력 데이터가 풍부하지만 직원이 무엇을 할 수 있고 어디에 적합한지에 대한 공통된 이해는 매우 부족합니다. BigQuery 그래프를 사용하면 이렇게 흩어져 있는 정보를 재사용 가능한 속성 그래프로 변환하고 사람, 역할, 역량, 근거 전반의 연결 관계를 대규모로 탐색할 수 있습니다. 따라서 의사 결정을 내릴 때마다 인력 컨텍스트를 새로 만드는 대신, 동일하게 연결된 인력 컨텍스트를 수천 건의 의사 결정에 활용할 수 있습니다. 덕분에 AI는 업무를 어떻게 처리해야 하는지에 대한 훨씬 더 어려운 질문에 답할 수 있는 탄탄한 기반을 갖추게 됩니다.” - Heiko Roth, Workerbee 설립자 겸 CEO

그래프와 대화하기

그래프를 탐색하기 위해 GQL을 작성할 필요는 없습니다. BigQuery 대화형 분석을 사용하면 자연어로 직접 그래프와 대화할 수 있습니다. 대화형 분석은 스키마의 관계를 읽어 질문을 SQL 또는 GQL로 변환하고 경로 기반 답변의 순회를 시각화합니다. 에이전트는 설명 및 동의어와 같은 그래프 메타데이터를 활용하여 결과를 그라운딩합니다. 그래프를 그래프답게 만드는 이러한 관계는 자유 형식의 자연어 쿼리를 방해하는 모호성과 할루시네이션을 줄이는 데 특히 효과적입니다. 또한 MCP 서버를 통해 Gemini Enterprise를 BigQuery Graph에 연결하거나 대화형 데이터 에이전트를 직접 게시할 수도 있습니다.

에이전트로 그래프 빌드

테이블을 노드와 에지로 모델링한 다음 이에 대해 GQL을 작성하는 그래프 구축 작업은 이미 사용 중인 데이터 에이전트에 맡길 수 있습니다. Google Cloud는 BigQuery 그래프 전문 지식을 에이전트 스킬로 패키징하여 에이전트가 그래프를 능숙하게 다룰 수 있도록 했습니다. 여기에는 GQL 패턴 일치, 그래프와 SQL의 혼합, Google Cloud의 권장사항을 따르는 스키마 설계가 포함됩니다. 이러한 기능은 Google Cloud Data Agent Kit 확장 프로그램을 통해 Antigravity, Visual Studio Code, Claude Code, Codex 등 선호하는 에이전트형 코딩 도구에서 즉시 사용할 수 있습니다.

이 스킬은 단순히 조언하는 데 그치지 않고 직접 작성하는 방법도 학습하고 있으며, 이 기능은 곧 출시될 예정입니다. 데이터 세트, 모델 문서 또는 ER 다이어그램을 지정하면 노드와 에지를 제안한 다음, 그래프를 빌드하기 전에 데이터와 대조하여 각각의 관계를 검증하고 일치율을 보여줍니다. 예를 들어 한 관계는 98%, 다른 관계는 56%가 일치하는 식입니다. 따라서 처음부터 신뢰할 수 있는 그래프를 얻을 수 있습니다.

에이전트에 감사 가능한 메모리 제공

에이전트를 그라운딩하는 것은 작업의 절반에 불과하며, 나머지 절반은 에이전트가 수행한 작업을 기억하는 것입니다. 에이전트의 역할이 조언에서 직접 행동하는 것으로 발전함에 따라 모든 결정은 사후에 설명할 수 있어야 합니다. 어떤 옵션이 선택되었는지, 어떤 정책이 적용되었는지, 어떤 대안이 거부되었는지 등을 파악할 수 있어야 합니다. BigQuery Agent Analytics의 컨텍스트 그래프를 사용하면 에이전트가 수행하는 각 작업을 캡처하여 컨텍스트 그래프로 구성할 수 있습니다. 컨텍스트 그래프는 에이전트의 추론에 대한 유형화되고 쿼리 가능한 trace로, BigQuery 그래프에 바로 저장됩니다. trace 자체가 그래프이므로 '에이전트가 왜 이런 행동을 했을까?'라는 질문에 한 번의 순회로 답을 찾을 수 있으며, 이러한 의사 결정에 다시 연결한 결과는 다음 의사 결정을 개선하는 데이터가 됩니다.

지금 BigQuery 그래프 시작하기

BigQuery 그래프는 그래프 분석을 실행하고 여러 클라우드에서 데이터에 AI 에이전트를 그라운딩합니다. 시작하려면 개요 및 데이터 모델을 확인하여 GQL, 노드 테이블, 에지 테이블이 어떻게 연동되는지 알아본 다음 팀의 일반적인 패턴에 적용해 보세요. 사기 감지 Codelab에서 의심스러운 자금 이동과 합성 ID를 추적하고, ID 확인 Codelab에서 파편화된 이메일, 기기, 쿠키 정보를 하나의 고객으로 연결할 수 있습니다. 또한 공급망을 디지털 트윈으로 모델링하여 공급망에 문제가 발생했을 때 숨겨진 종속성을 쿼리할 수도 있습니다.

그런 다음 에이전트로 확장합니다. 에이전트 컨텍스트 그래프 Codelab은 원시 이벤트 로그를 그래프로 변환하여 자율 에이전트가 실제로 수행한 작업을 감사, 설명, 추적합니다. 즉, 신뢰할 수 있는 시스템을 뒷받침하는 연결된 메모리를 구축할 수 있습니다. 워크로드가 실시간 운영 트랜잭션과 대규모 분석을 모두 포괄하는 경우 통합 그래프 솔루션을 살펴보고 Spanner Graph와 BigQuery 그래프가 어떻게 함께 작동하는지 확인해 보세요. 더 자세히 알아볼 준비가 되었다면 eBook에서 전체 여정을 살펴볼 수 있습니다.

새로운 BigQuery ID 열을 활용한 파이프라인 간소화

Sun, 06 Sep 2026 19:00:00 +0000

고객의 데이터 여정에 도움이 되고자 BigQuery에 ID 열을 출시한다는 반가운 소식을 전해 드립니다. 이 새로운 기능을 사용하면 순차적인 64비트 정수 값을 자동으로 생성하는 열을 정의하여 테이블 내에서 고유 식별자를 더욱 간단하게 관리할 수 있습니다.

데이터 엔지니어들은 항상 데이터 수집을 더 원활하고 안정적으로 수행할 수 있는 방법을 모색합니다. BigQuery ID 열은 테이블의 고유한 숫자 값을 자동으로 생성하는 강력한 메커니즘을 기본 제공합니다. ID 생성을 BigQuery에게 맡기면 데이터 파이프라인의 복잡성을 크게 줄이고 인사이트를 제공하는 데 집중할 수 있습니다.

데이터 파이프라인의 주요 이점

ID 열을 구현하면 데이터 아키텍처의 개발 및 유지보수를 간소화하는 데 도움이 되는 여러 이점이 있습니다.

수집 간소화: 애플리케이션 로직이나 ETL 도구에서 고유 키를 미리 계산할 필요 없이 데이터를 수집할 수 있습니다.
상용구 감소: 자동 생성된 시퀀스를 사용하면 데이터베이스에서 기본적으로 키 관리를 처리하므로 SQL 코드가 더 깔끔해지고 유지보수가 쉬워집니다.
통합 자동화: ID 열이 표준 DML 작업과 원활하게 연동되어 새로운 모든 행에 고유 식별자가 자동으로 제공됩니다.
유연한 통합: INSERT 또는 MERGE 문을 사용하는 경우 ID 열이 기존 워크플로에 맞게 조정됩니다.

ID 열을 구현하는 방법

ID 열 설정은 간단하며 CREATE TABLE 문 내에서 직접 설정할 수 있습니다. 값이 처리되는 방식을 정의하는 방법에는 기본적으로 두 가지가 있습니다.

정의 옵션

절	설명
`GENERATED ALWAYS AS IDENTITY`	BigQuery가 값의 고유성을 자동으로 관리하고 보장합니다.
`GENERATED BY DEFAULT AS IDENTITY`	자동 값을 제공하지만 필요한 경우 수동 재정의를 허용합니다.

사용 예시다음 SQL 문은 ID를 자동으로 증가시키는 테이블을 만드는 방법을 보여줍니다. ID는 1부터 시작하여 새 항목이 추가될 때마다 1씩 증가합니다.

code_block: <ListValue: [StructValue([('code', "CREATE TABLE my_project.my_dataset.orders (\r\n order_id INT64 GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1),\r\n customer_name STRING,\r\n order_date DATE\r\n);\r\n\r\n-- Ingesting data is now simpler:\r\nINSERT INTO my_project.my_dataset.orders (customer_name, order_date)\r\nVALUES ('Joe Doe', CURRENT_DATE());"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f8cccbe9a10>)])]>

지금 시작하기

ID 열은 유연하고 성능이 뛰어나며 표준을 준수하는 데이터 플랫폼을 제공하기 위한 Google의 지속적인 노력을 보여주는 결과물입니다. 서로게이트 키 생성을 자동화함으로써 확장 및 유지보수 가능한 데이터 아키텍처를 더 쉽게 빌드할 수 있도록 지원합니다.

프로젝트에 이 기능을 구현하는 방법을 자세히 알아보려면 BigQuery ID 열 문서를 참고하세요.

데이터 분석

대규모 관리형 Apache Iceberg: Spanner가 Lakehouse 런타임 카탈로그를 지원하는 방법

레이크하우스에서 관리형 카탈로그가 해결해야 하는 과제

Lakehouse 런타임 카탈로그

Lakehouse 런타임 카탈로그의 원동력

분석 워크로드와 운영 워크로드 결합

경계 없는 레이크하우스로 현대화

분석 가속화: PayPal의 Managed Service for Apache Spark 도입 여정

까다로운 분석 환경의 과제 해결

복잡한 환경이 낳은 정체

솔루션: 통합된 클라우드 네이티브 분석

결과: 더 빠른 인사이트, 더 낮은 오버헤드

Google Cloud CLI 원격 MCP 서버로 에이전트 역량 강화

AI 에이전트에 CLI가 중요한 이유

원격 MCP 기반 CLI 활용의 장점

엔터프라이즈급 보안 및 거버넌스

Google Cloud CLI 원격 MCP 서버에 연결

에이전트에 인프라 관리 기능 제공

run_bq_command 도구를 사용한 BigQuery 작업 확장

가격 책정 및 가용성

지리 공간 코딩을 가속화하는 새로운 Google Earth Engine 기능인 Ask 소개

작동 방식: 컨텍스트 인식 지원

빠른 시작 예시

1. 자연어로 코드 생성

2. 복잡한 코드 설명

3. 원클릭 문제 해결 및 디버깅 수행

4. 쿼리 최적화

2단계로 시작하기

Apache Spark 가용성 극대화: 컴퓨팅 용량 부족 문제 해결을 위한 가변형 VM 및 기타 권장사항

용량 부족에 대한 이해

가변형 VM

주요 특징

순위 기반 구성: 성공적인 구현을 위한 전략

Hyperdisk Balanced 활용

장단점 및 주요 고려사항

1. 리소스 할당량

2. Compute 가변형 약정 사용 할인(CUD)

3. 성능 특성

추가 권장사항

AI 에이전트가 준비되었습니다. 그렇다면 데이터는 어떤가요?

컨텍스트 부족 극복

불필요한 수동 작업에서 벗어나기

데이터에 신뢰와 지식 제공

앞으로의 방향

보고서: 조직의 83%가 에이전트 AI를 지원하려면 인프라를 업그레이드해야 함

조정의 미래: Google Cloud에서 Airflow 3로 전환한 Pine59의 여정

성장을 위한 선제적 현대화

고급 MLOps 조정

커스텀 확장성을 통한 개발자 지원

더 빠르고 안정적인 파이프라인

BigQuery용 SAP Business Data Cloud Connect 정식 버전 출시

AI 프로젝트를 위한 데이터 복사 중단

비용을 늘리지 않고 데이터 가치 확장

고객이 공유된 데이터를 행동으로 전환하는 방법

사용 가능한 리전

시작하기

BigQuery 그래프를 사용한 식품 공급망의 디지털 트윈 모델링

성장하는 레스토랑의 예

성장의 마찰

디지털 트윈

BigQuery 그래프를 사용한 모델링

1. 시맨틱 계층 정의

실무에서의 정밀도

2. 검색 실행

미래를 위한 기반 구축

결론

지금 시작하기

경계 없는 Lakehouse 가속화: 크로스 클라우드 캐싱 프리뷰 발표

크로스 클라우드 캐싱의 작동 방식

크로스 클라우드 캐싱의 실제 작동 방식

초기 실행: 콜드 열 검색

후속 탐색: 측정기준 추가

엔터프라이즈 규모의 효율성 증대

BigQuery 크로스 클라우드 연결이 프리뷰로 제공됩니다.

Cortex Framework v7 정식 버전 출시: SAP 운영 중단 없이 에이전트형 워크플로 빌드

Cortex Framework v7의 새로운 기능

SAP 데이터 클라우드와의 상호 운용성

업계 리더와의 공동 혁신

시작하기

통신 업계 자율성 확대: 분산 그래프 흐름(Distributed GraphFlow)으로 GNN 활용