데이터 분석

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

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

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

이제 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 0x7ff1448fa110>)])]>

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

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

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 0x7ff1448f8890>)])]>

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 0x7ff1448fb290>)])]>

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

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을 비롯한 엔지니어링 팀원 여러분께 진심으로 감사의 말씀을 전합니다.}

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 0x7ff144d9b450>)])]>

작업 내용 확인하기

에이전트는 프롬프트를 처리하고 관련 스킬을 호출한 다음, 데이터 쿼리를 시작할 준비를 합니다. 하지만 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 0x7ff144f34ed0>)])]>

결과를 보면 비즈니스 자체가 위축된 것이 아니라 평균값이 왜곡된 것임을 알 수 있습니다. 온라인 및 오프라인 주문은 양호한 수준을 유지했습니다(약 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 0x7ff144f47290>)])]>

에이전트가 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 0x7ff145085350>)])]>

에이전트는 단일 프롬프트에서 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 0x7ff144bb0510>)])]>

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 0x7ff1448d3c50>)])]>

이 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 0x7ff13bf5dc10>)])]>

파이프라인 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 0x7ff145084090>)])]>

파이프라인 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 0x7ff145369290>)])]>

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 0x7ff1468cd290>)])]>

이 예시의 출력 결과에는 예측 테이블의 모든 기존 열과 함께 예측된 라벨 및 확률 열(예: 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 0x7ff1448477d0>)])]>

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 0x7ff1450af350>)])]>

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

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 0x7ff1452df950>)])]>

더 빠르고 표현력이 향상된 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 0x7ff145ff0e90>)])]>

지금 시작하기

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

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

OKF와 Knowledge Catalog를 사용하여 에이전트에 컨텍스트 제공

Thu, 03 Sep 2026 21:00:00 +0000

Google은 LLM-wiki 패턴을 휴대 가능하고 상호 운용 가능한 형식으로 공식화하는 개방형 사양인 개방형 지식 형식 (OKF)을 계속해서 반복하고 있습니다. 하지만 여전히 중요한 질문이 남아 있습니다. 조직 전체에서 OKF 번들에 대한 액세스를 공유하고 관리하려면 어떻게 해야 할까요?

OKF v0.1은 컨텍스트 에이전트에 필요한 휴대용 형식(YAML 프런트매터가 있는 마크다운 파일, 필수 필드 1개, 규칙 5개)을 확립했습니다. 그런 다음 OKF v0.2는 신뢰할 수 있는 머신 작성 번들에 필요한 신뢰 신호 (출처, 검증, 최신성, 증명)를 추가하여 팀이 자체 에이전트에 대해 신뢰할 수 있는 번들을 게시할 수 있도록 했습니다.

그러나 OKF는 팀이 조직 전체에서 번들을 공유하는 방법에 대한 답을 제공하지 않습니다. 번들당 git 저장소는 이식 가능하지만 설명하는 데이터와 함께 검색할 수 없고, 동일한 조직 ID 및 규정 준수 정책을 사용하여 보호하고 관리할 수 없으며, 데이터팀이 이미 작업하고 있는 기술 메타데이터 (스키마, 계보, 소유권) 옆에 있지 않습니다. 모든 다운스트림 에이전트는 각 번들이 어디에 있는지 알아야 하며, 이는 소수의 번들 이상으로 확장되지 않습니다.

조직 전체에서 OKF 번들을 확장하려면 Google Cloud의 에이전트용 컨텍스트 엔진인 Knowledge Catalog를 사용하면 됩니다. 번들을 Knowledge Catalog의 기존 유형에 매핑하면 모든 개념을 검색하고 관리할 수 있으며 카탈로그에서 이미 읽고 있는 모든 에이전트가 개념에 도달할 수 있습니다.

Knowledge Catalog는 에이전트를 위한 컨텍스트 엔진입니다.

Knowledge Catalog를 쿼리하는 모든 에이전트는 조직이 BigQuery, Cloud Storage, 운영 데이터베이스, 애플리케이션에 이미 보유하고 있는 항목에 대해 하나의 관리되는 색인에서 읽습니다. 각 항목에는 스키마, 계보, 소유권, 태그가 포함되어 있으며 도메인별 필드를 추가하는 유형화된 측면으로 확장할 수 있습니다. 동일한 카탈로그는 검색 및 교차 프로젝트 조회를 노출하여 각 에이전트 쿼리에 대해 최적화된 컨텍스트를 검색합니다. 컨텍스트 검색은 안전하며 IAM 제어에 의거하여 관리되므로 에이전트는 IAM ID를 기반으로 액세스 권한이 있는 항목만 볼 수 있습니다.

OKF 번들을 Knowledge Catalog에 게시하려면 일회성 설정과 단일 푸시가 필요합니다. 두 가지 모두 Knowledge Catalog 저장소의 OKF 샘플 코드를 사용하며, 이 샘플 코드의 래퍼는 설정에 gcloud dataplex 를 호출하고 푸시를 kcmd (동일한 저장소의 Metadata-as-Code CLI)에 위임합니다.

이 설정은 번들을 보관할 EntryGroup, 개념을 위한 okf-bundle 이라는 이름의 EntryType, okf 라는 이름의 AspectType (샘플 코드의 okf-aspect.json 스키마에서 OKF 신호 필드를 전달함)의 세 가지 Knowledge Catalog 리소스를 등록합니다. 그러면 푸시가 개념당 하나의 okf-bundle 항목을 생성하며, 각 항목에는 두 가지 측면이 있습니다. 마크다운 본문에 대한 overview 측면과 구조화된 신호에 대한 okf 측면입니다. 표시 이름, 설명, 태그는 항목 자체에 있습니다. 번들의 index.md 탐색 파일과 루트 log.md 도 항목으로 게시됩니다. index 파일은 overview Aspect (OKF 프런트매터 없음)만 포함하고 log.md 는 okf_type: Log로 두 Aspect를 모두 포함합니다.

Knowledge Catalog가 기술 메타데이터에 대해 이미 수행하고 있는 모든 작업 (검색, IAM, 계보, 프로젝트 간 검색)은 설명하는 데이터와 함께 OKF 번들에도 동일하게 적용됩니다.

okf AspectType

샘플 코드의 okf-aspect.json 스키마는 AspectType을 정의합니다. OKF v0.2 사양을 포괄하는 13개의 필드가 포함되어 있습니다.

#	필드	유형	목적
1	`okf_type`	문자열	OKF 문서 유형 (자유 형식, 예: BigQuery 테이블, 측정항목, 증명된 컴퓨팅)
2	생성된	`{by, at}` 기록	마지막으로 의미 있는 변경이 발생한 행위자와 타임스탬프입니다.
3	소스	`{id, resource, title, author, usage_count, last_modified}` 배열	개념의 출처가 되는 자료(신뢰도 신호 포함)
4	확인됨	`{by, at}` 배열	인증 이벤트 인간: 행위자는 가장 높은 신뢰 등급을 나타냅니다.
5	상태	문자열	수명 주기 상태: `draft`, `stable` 또는 `deprecated`
6	`stale_after`	datetime	콘텐츠가 오래된 것으로 간주되는 시점 (명시적 오프셋이 있는 RFC3339)입니다.
7	`usage_window`	`{from, to}` 기록	소스 사용량 수가 측정된 기간입니다.
8	런타임	문자열	증명된 컴퓨팅이 실행되는 방식 (예: `bigquery`)
9	매개변수	`{name, type, required}` 배열	호출자가 채울 수 있는 유형이 지정된 명명된 홀입니다. 발신자가 변경할 수 있는 유일한 표면입니다.
10	계산	문자열	계산 본문을 포함하는 파일의 경로입니다.
11	실행자	record `{resource, receipt[]}`	계산이 어떻게 실행되고 어떤 증거를 반환해야 하는지
12	증명자	`{resource}` 레코드	영수증을 가져와 판결을 반환하는 결정적 코드입니다.
13	`extra`	문자열	템플릿이 모델링하지 않는 제작자 정의 프런트매터(JSON `[path, value]` 쌍) 왕복 손실이 없습니다.

모든 필드에는 표시 이름, 설명, 필수 색인이 주석 처리되어 있습니다. okf Aspect (okf_type, status, stale_after, runtime, computation, extra)의 모든 최상위 스칼라 필드는 Knowledge Catalog 검색 술어를 직접 구동할 수 있으므로 aspect:acme-analytics.us-central1.okf.okf_type=Metric 은 범위 내의 모든 OKF 측정항목을 반환합니다. 레코드 필드의 스칼라 하위 필드 (generated.by, usage_window.from, executor.resource, attester.resource)도 술어를 구동합니다. 배열 필드 (sources, verified, parameters)는 하위 필드에서 서버 측 검색이 불가능합니다. 상담사는 entries.get 을 view=ALL로 호출한 후 클라이언트 측에서 검색 범위를 좁힙니다. datetime형식 필드 (stale_after, generated.at, usage_window.from/.to)의 검색 술어에는 전체 RFC3339 타임스탬프가 아닌 날짜 (stale_after=2026-12-31) 또는 범위 비교 (stale_after>2026-01-01)를 사용해야 합니다.

번들 내보내기

kcmd push 는 git에서 OKF 번들을 읽고 각 개념을 대상 Knowledge Catalog EntryGroup의 항목으로 작성합니다. index.md 파일도 항목이 되며 각 개념은 그 위의 색인에 부모로 지정되므로 번들의 디렉터리 구조가 탐색 가능한 계층 구조로 유지됩니다.

kcmd 는 문서 레이아웃의 번들을 예상합니다. 즉, catalog/ 하위 디렉터리의 마크다운 파일과 스냅샷의 항목 및 측면 유형을 나열하는 번들 루트의 catalog.yaml 을 예상합니다. 샘플 코드의 setup.ts 는 --entry-group 플래그 (기본값 okf_demo )에서 catalog.yaml을 생성하므로, 샘플을 새 번들에 연결하는 독자는 catalog.yaml 을 수동으로 편집하는 대신 플래그를 전달합니다.

OKF v0.2 블로그에서 소개한 Acme Retail 번들의 엔드 투 엔드 워크플로는 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', '# One-time setup (if required): install bun, clone the repo, build kcmd, configure gcloud\r\ncurl -fsSL https://bun.sh/install | bash\r\nexport BUN_INSTALL="$HOME/.bun" && export PATH="$BUN_INSTALL/bin:$PATH"\r\ngit clone https://github.com/GoogleCloudPlatform/knowledge-catalog\r\ncd knowledge-catalog/toolbox/mdcode && npm install && npm run build\r\n\r\n# Authenticate, set project and enable dataplex apis\r\ngcloud auth login\r\ngcloud config set project <your-project>\r\ngcloud config set compute/region <your-location>\r\ngcloud services enable dataplex.googleapis.com\r\ngcloud auth application-default login\r\n\r\n# Push the Acme Retail bundle\r\ncd demo/okf\r\nbun run setup.ts # creates the EG (default \'okf_demo\')\r\nbun run push.ts # pushes okf/bundles/acme_retail into the EG setup created'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff144d67190>)])]>

다른 EntryGroup 이름을 선택하거나 다른 번들을 푸시하려면 --entry-group your-name 을 setup.ts 에 전달하고 --bundle path/to/your/bundle 을 push.ts에 전달합니다. 예: bun run setup.ts --entry-group acme-bundle 에 이어 bun run push.ts를 실행합니다. 이렇게 하면 매니페스트가 재생성되므로 이후의 push, pull, cleanup 은 모두 새 EG를 타겟팅합니다. 이전 EG는 gcloud dataplex entry-groups delete <name> --project <your-project> --location <your-location>를 사용하여 수동으로 삭제합니다.

Acme Retail 번들은 미국 소매업체의 BigQuery 환경을 위한 합성 OKF 번들입니다. 여기에는attesters, tables, metrics, computations, policies, skills의 6개 디렉터리에 걸쳐 9개의 리프 개념이 포함되어 있으며, 각 디렉터리에는 자체 index.md가 있고 번들 루트에는 자체 index.md 와 log.md가 있습니다. 총 17개의 항목이 푸시됩니다. Dataplex는 <eg>_entry 를 자동으로 생성하므로 gcloud dataplex entries list 는 18개의 행을 반환합니다.

푸시가 완료된 후:

모든 개념 Markdown 파일은 Knowledge Catalog 항목이며, IAM 구성에 따라 전체 프로젝트 또는 조직에서 검색을 통해 찾을 수 있습니다.
승인된 SQL, 실행기, 증명자, 검증 기록, 전체 개념 본문과 함께 revenue-ytd 증명된 계산이 콘솔에 표시됩니다.
분석가가 Knowledge Catalog에서 '수익'을 검색하면 Acme Retail의 비즈니스 정의와 이를 계산하는 BigQuery 테이블이 모두 하나의 권한 모델 아래에서 발견됩니다.
BigQuery 테이블 항목에 대해 LookupContext를 이미 호출하는 다운스트림 에이전트는 OKF 항목 이름을 resources 목록에 추가하여 번들의 컨텍스트를 검색합니다.

또한 metrics/revenue.md 는 두 가지 측면을 가진 항목이 됩니다. 전체 entries.get 응답 ( view=ALL)은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "name": "projects/acme-analytics/locations/us-central1/entryGroups/acme-retail/entries/metrics/revenue",\r\n "entryType": "projects/acme-analytics/locations/us-central1/entryTypes/okf-bundle",\r\n "createTime": "2026-08-15T00:48:39.123456Z",\r\n "updateTime": "2026-08-15T00:48:57.234567Z",\r\n "parentEntry": "projects/acme-analytics/locations/us-central1/entryGroups/acme-retail/entries/metrics/index",\r\n "entrySource": {\r\n "displayName": "Revenue",\r\n "description": "Recognized revenue for a period, per Acme\'s FY2026 revenue-recognition policy. Backed by an Attested Computation.",\r\n "labels": {\r\n "finance": "true",\r\n "revenue": "true",\r\n "headline-metric": "true"\r\n },\r\n "location": "us-central1"\r\n },\r\n "aspects": {\r\n "dataplex-types.global.overview": {\r\n "aspectType": "projects/dataplex-types/locations/global/aspectTypes/overview",\r\n "createTime": "2026-08-15T00:48:57.111111Z",\r\n "updateTime": "2026-08-15T00:48:57.111111Z",\r\n "aspectSource": {},\r\n "data": {\r\n "content": "# Definition\\n\\nRevenue for a fiscal year is the sum of `net_amount` over orders that (a) reached `order_status = \'delivered\'`, (b) completed the 30-day return window, and (c) fall in the fiscal year by `order_ts`. Multi-currency orders are converted to USD at the `order_ts` daily reference rate. [^revenue-policy]\\n\\nThe sanctioned computation is [`computations/revenue-ytd.md`](../computations/revenue-ytd.md). Consumers MUST run and attest that computation rather than composing their own SUM. The attester rejects any receipt whose executed SQL does not match the sanctioned form.\\n\\n# Reporting cuts\\n\\n- **By fiscal year:** the sanctioned computation takes `year` as its sole parameter.\\n- **By channel or category:** these are approved narrations, not new metrics. Join the receipt\'s row-level result to `orders.channel` or to `order_lines` × `products.category` client-side. Do NOT rewrite the sanctioned SQL.\\n\\n# Trust and freshness\\n\\n- **Verified:** VP Finance sign-off on 2026-07-01, against the FY2026 policy.\\n- **Stale after 2026-12-31:** Finance re-issues the revenue recognition policy each January. Consumers of this concept after 2027-01-01 MUST re-verify the definition against the new policy before serving.\\n\\n[^revenue-policy]: Revenue Recognition Policy (FY2026)",\r\n "contentType": "MARKDOWN"\r\n }\r\n },\r\n "acme-analytics.us-central1.okf": {\r\n "aspectType": "projects/acme-analytics/locations/us-central1/aspectTypes/okf",\r\n "createTime": "2026-08-15T00:48:57.222222Z",\r\n "updateTime": "2026-08-15T00:48:57.222222Z",\r\n "aspectSource": {},\r\n "data": {\r\n "okf_type": "Metric",\r\n "generated": { "by": "reference_agent/gemini-2.5-pro", "at": "2026-06-30T14:00:00Z" },\r\n "verified": [ { "by": "human:jsmith@acme", "at": "2026-07-01T09:00:00Z" } ],\r\n "status": "stable",\r\n "stale_after": "2026-12-31T00:00:00Z",\r\n "sources": [\r\n {\r\n "id": "revenue-policy",\r\n "resource": "policies/revenue-recognition.md",\r\n "title": "Revenue Recognition Policy (FY2026)",\r\n "author": "human:jsmith@acme",\r\n "last_modified": "2026-06-15T00:00:00Z"\r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff146c0d010>)])]>

개요 관점은 revenue.md의 전체 본문을 보유합니다. okf 관점은 구조화된 신호 필드를 전달하므로 에이전트는 마크다운을 파싱하는 대신 직접 필터링할 수 있는 형식으로 출처, 소스, OKF 유형을 가져옵니다. 최상위 스칼라 필드와 레코드 필드의 스칼라 하위 필드에 대한 서버 측 searchEntries 필터, 항목 후 클라이언트 측에서 배열 요소 하위 필드에 대한 에이전트 추가 축소(entries.get) (Aspects 및 EntryTypes는 실제 API 응답 및 검색 술어에서 프로젝트 번호로 키가 지정됩니다. acme-analytics 프로젝트 ID는 가독성을 위해 전체적으로 표시됩니다.)

OKF를 Knowledge Catalog로 푸시하면 어떤 이점이 있나요?

번들이 Knowledge Catalog에 있으면 카탈로그에서 읽는 모든 에이전트에 두 가지 기능을 제공합니다.

조직 전반의 검색 가능성 에이전트는 이미 카탈로그화된 데이터에 사용 중인 동일한 searchEntries 및 LookupContext API를 통해 번들 개념을 찾으므로 OKF 번들은 일치하는 모든 쿼리에서 BigQuery 테이블 및 기타 리소스와 함께 표시됩니다.
거버넌스. 번들 항목은 EntryGroup에서 IAM을 상속하므로 단일 에이전트 호출은 호출자가 읽을 수 있는 권한이 있는 항목만 반환하며 유지관리할 병렬 권한 모델이 없습니다.

조직 전반의 검색 가능성OKF 번들 항목은 BigQuery 테이블 및 기타 카탈로그화된 리소스와 함께 검색 항목 결과에 표시되므로 카탈로그를 이미 쿼리 중인 에이전트가 새 번들을 자동으로 선택합니다. 일치 항목에서 개념의 본문, 신뢰 신호 또는 연결된 개념을 검색하기 위해 에이전트는 LookupContext로 이동하여 entries.get을 호출합니다.

LookupContext 호출은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'POST https://dataplex.googleapis.com/v1/projects/acme-analytics/locations/us-central1:lookupContext\r\n{\r\n "resources": [\r\n "projects/acme-analytics/locations/us-central1/entryGroups/acme-retail/entries/metrics/revenue"\r\n ],\r\n "options": { "format": "yaml", "context_budget": "8000" }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff146c0f550>)])]>

응답은 사전 형식화된 YAML 블록이 포함된 단일 context 필드입니다. 이 블록에는 항목의 catalogEntry, 유형, 설명, 라벨로 사용되는 태그, 개요(신뢰도 및 최신 상태 섹션을 포함한 개념의 전체 마크다운 본문)가 포함됩니다. LookupContext는 커스텀 Aspect를 렌더링하지 않으므로 구조화된 OKF 신호 필드 (okf_type, generated, sources, 기타 10개)가 필요한 에이전트는 LookupContext 호출과 함께 entries.get 및 view=ALL 을 사용하여 이를 읽습니다.

저장소 클론, 수동 Aspect 병합, 프런트매터 재파싱이 없습니다. 에이전트는 이미 Knowledge Catalog 클라이언트가 수행하는 것과 동일한 API 호출을 사용합니다.

OKF 번들을 순회하는 에이전트는 일반적으로 3단계 흐름을 따릅니다. 필요한 특정 항목 이름을 이미 알고 있는 에이전트는 1단계를 건너뜁니다. 대상 EntryGroup을 이미 알고 있고 번들을 철저히 열거하려는 에이전트는 entryGroups.entries.list 를 1단계로 대체합니다.

searchEntries는 후보 항목 이름과 설명을 반환합니다. 범위 는 프로젝트 또는 조직을 허용하며, 이 범위 내에서 좁히기는 aspect:acme-analytics.us-central1.okf.okf_type=Metric과 같은 측면 술어를 포함한 쿼리어를 통해 이루어집니다.
상위 몇 개의 항목 이름 (호출당 최대 10개)에 대한 LookupContext는 사전 형식화된 YAML로 전체 개념 본문을 반환합니다. context_budget 은 응답 크기를 제한합니다.
entries.get 에 view=ALL 을 지정하면 모든 항목에 대해 구조화된 OKF 신호 (okf_type, generated, sources, 기타 10개)가 직접 반환되므로 에이전트가 이를 필터링하거나 증명할 수 있습니다.

개념의 sources[] 가 경로를 통해 다른 개념을 참조하는 경우 에이전트는 해당 항목 이름에 대해 LookupContext를 호출하여 참조를 탐색합니다.

수익 항목에 대한 전체 응답:

code_block: <ListValue: [StructValue([('code', "resources:\r\n -\r\n catalogEntry: projects/acme-analytics/locations/us-central1/entryGroups/acme-retail/entries/metrics/revenue\r\n type: OKF Document\r\n description: Recognized revenue for a period, per Acme's FY2026 revenue-recognition\r\n policy. Backed by an Attested Computation.\r\n overview: |-\r\n # Definition\r\n\r\n Revenue for a fiscal year is the sum of `net_amount` over orders that (a) reached `order_status = 'delivered'`, (b) completed the 30-day return window, and (c) fall in the fiscal year by `order_ts`. Multi-currency orders are converted to USD at the `order_ts` daily reference rate. [^revenue-policy]\r\n\r\n The sanctioned computation is [`computations/revenue-ytd.md`](../computations/revenue-ytd.md). Consumers MUST run and attest that computation rather than composing their own SUM. The attester rejects any receipt whose executed SQL does not match the sanctioned form.\r\n\r\n # Reporting cuts\r\n\r\n - **By fiscal year:** the sanctioned computation takes `year` as its sole parameter.\r\n - **By channel or category:** these are approved narrations, not new metrics. Join the receipt's row-level result to `orders.channel` or to `order_lines` × `products.category` client-side. Do NOT rewrite the sanctioned SQL.\r\n\r\n # Trust and freshness\r\n\r\n - **Verified:** VP Finance sign-off on 2026-07-01, against the FY2026 policy.\r\n - **Stale after 2026-12-31:** Finance re-issues the revenue recognition policy each January. Consumers of this concept after 2027-01-01 MUST re-verify the definition against the new policy before serving.\r\n\r\n [^revenue-policy]: Revenue Recognition Policy (FY2026)\r\n labels:\r\n finance: 'true'\r\n revenue: 'true'\r\n headline-metric: 'true'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff146c0f6d0>)])]>

거버넌스

EntryGroup에 대한 권한은 표준 Knowledge Catalog IAM을 사용합니다. 하나의 호출에서 번들 개념과 BigQuery 테이블을 모두 지정하는 에이전트는 각각 자체 액세스 제어 목록 (ACL)의 적용을 받으므로 호출자가 이미 읽을 수 있는 권한이 있는 항목만 응답에 포함됩니다. 유지관리할 병렬 권한 모델이 없습니다.

읽기 에이전트는 roles/dataplex.catalogViewer를 사용하며, 이 역할은 entries.get, LookupContext, searchEntries의 읽기 경로를 부여합니다. kcmd push 를 실행하는 ID는 roles/dataplex.catalogEditor를 사용하며, 이 역할은 entries.create 및 entries.patch쓰기 경로를 부여합니다. 번들을 소유한 팀당 하나의 EntryGroup이 있는 멀티팀 패턴이며, EntryGroup의 IAM이 항목으로 캐스케이드됩니다.

LookupContext는 호출당 최대 10개의 항목 이름을 단일 위치 내에서 확인합니다. 개념 본문에서 링크를 따라가지 않으므로 참조된 개념을 원하는 에이전트는 명시적으로 이름을 지정해야 합니다. 번들의 EntryGroup을 설명하는 데이터와 동일한 위치에 배치하여 한 번의 호출로 둘 다 가져옵니다.

수명 주기

kcmd push 는 멱등적인 upsert입니다. 다시 실행해도 안전하지만 (중복 없음, 오류 없음) 푸시할 때마다 모든 항목이 작성됩니다. 개념 삭제에는 항목에 대한 명시적인 kcmd delete 또는 cleanup.ts 가 필요하며, cleanup.ts 는 EntryGroup과 항목만 삭제하므로 공유된 okf AspectType과 okf-bundle EntryType은 이를 참조하는 다른 번들에 그대로 유지됩니다. For continuous ingestion in production, wire a CI job to kcmd push on every commit to the bundle repository, using a service-account credential with roles/dataplex.catalogEditor on the target EntryGroup.

Google Cloud의 Lakehouse 런타임 카탈로그를 사용하여 Apache Hive를 현대화하는 방법

Thu, 03 Sep 2026 21:00:00 +0000

10년 넘게 Apache Hive Metastore (HMS)는 빅데이터 분석의 사실상 메타데이터 권한으로 사용되어 왔습니다. Hadoop 클러스터에 배포되었든 MySQL 또는 PostgreSQL을 기반으로 하는 자체 관리형 Compute Engine VM에 배포되었든 HMS는 Apache Spark, Presto, Hive가 원시 .parquet 및 .orc 파일을 쿼리할 수 있도록 하는 중앙 스키마 레지스트리를 제공했습니다.

그러나 엔터프라이즈 데이터 아키텍처가 페타바이트 규모로 확장되고 Google Cloud Managed Service for Apache Spark, BigQuery, Trino와 같은 여러 쿼리 엔진에 걸쳐 확장됨에 따라 기존 Hive Metastore는 종종 중요한 운영 병목 현상이 됩니다.

이 블로그에서는 기존 metastore가 에이전트 규모의 최신 클라우드 환경에서 어려움을 겪는 이유를 살펴보고, Google Cloud Lakehouse 서버리스 런타임 카탈로그가 어떻게 도움이 되는지 보여줍니다. 이 카탈로그는 작년에 소개되었으며, 개방형 Apache Iceberg REST 카탈로그 사양을 기반으로 빌드되어 실행 가능한 제로 데이터 복사 마이그레이션 솔루션으로, 프로덕션 Hive 테이블을 몇 분 만에 전환할 수 있도록 도와줍니다.

기존 Hive Metastore의 문제점

대규모 프로덕션 분석을 실행하는 데이터 엔지니어 및 인프라 리더와 대화할 때마다 독립형 Hive 메타스토어에서 다음과 같은 세 가지 핵심적인 문제점이 지속적으로 나타납니다.

아키텍처 및 확장 병목 현상

독립형 HMS 배포는 테이블 스키마, 파티션, 스토리지 위치를 추적하기 위해 관계형 데이터베이스 백엔드 (예: MySQL 또는 Postgres)에 의존합니다. 데이터 레이크가 수십만 개의 파티션을 나눈 테이블로 확장됨에 따라 파티션 가지치기 및 대량 나열 작업으로 인해 관계형 데이터베이스의 핵심 성능 병목 현상이 발생합니다. 파티션 메타데이터를 요청하는 복잡한 Spark 작업은 메타스토어 CPU를 100%까지 급증시켜 클러스터 전체의 쿼리 지연 또는 메모리 부족 (OOM) 오류를 유발할 수 있습니다.

사일로화된 ID 및 보안 거버넌스

기존 메타스토어는 경계 기반 Hadoop 보안 모델을 중심으로 설계되었습니다. Apache Spark 컴퓨팅 작업과 BigQuery와 같은 엔터프라이즈 SQL 엔진 모두에서 테이블 수준 ACL (액세스 제어 목록)과 같은 세분화된 최신 데이터 거버넌스를 적용하려면 두 개의 서로 다른 제어 평면에서 분산되고 중복된 보안 정책을 유지해야 합니다.

운영 오버헤드 및 총소유비용 (TCO)

고가용성 MySQL/Postgres 인스턴스 관리, HMS 데몬 패치, JDBC 연결 풀 조정, 유휴 인스턴스 기반 메타스토어 서버 비용 지불은 데이터 플랫폼팀에 불필요한 운영 부담을 야기하며, 이 팀은 에이전트를 위한 고효율 데이터 제품을 빌드하는 데 시간을 할애하는 것이 더 좋습니다.

해결책: Lakehouse 런타임 카탈로그

데이터 엔지니어가 페타바이트 규모의 기존 스토리지 페이로드를 다시 작성하지 않고도 이러한 아키텍처 병목 현상을 해결할 수 있도록 Iceberg REST 카탈로그와 Hive 카탈로그를 지원하는 Lakehouse 런타임 카탈로그를 빌드했습니다.

Lakehouse 런타임 카탈로그는 완전한 서버리스, 고가용성, 통합 메타데이터 레지스트리로, 기존 Hive/Parquet 테이블과 Apache Iceberg 같은 최신 개방형 테이블 형식을 모두 지원하도록 처음부터 설계되었습니다. Lakehouse 런타임 카탈로그는 Apache Iceberg REST 카탈로그 사양을 기본적으로 구현하여 메타데이터 검색을 컴퓨팅 엔진에서 분리합니다. 카탈로그와 컴퓨팅 엔진의 이러한 분리를 통해 여러 Iceberg 호환 엔진이 동일한 데이터에 제로 카피 방식으로 액세스할 수 있으므로 고객이 데이터의 여러 사본을 유지할 필요성이 줄어들고 워크로드를 더 빨리 프로덕션에 적용할 수 있습니다.

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

다중 엔진 상호 운용성: 등록된 테이블은 표준 REST 인터페이스를 통해 Google Cloud Managed Spark, BigQuery, 오픈소스 엔진에서 즉시 검색하고 쿼리할 수 있습니다.
개방형 API: Iceberg Rest Catalog와 Hive Catalog를 지원하므로 여러 팀이 단일 통합 데이터 세트에서 선호하는 분석 도구를 사용할 수 있습니다.
데이터 복사 없음: 테이블 정의가 Google Cloud Storage의 기존 데이터를 직접 가리킵니다. 기본 데이터를 이동, 재작성 또는 복제하지 않습니다.
AI 기반 거버넌스, 보안, 신뢰할 수 있는 컨텍스트: Lakehouse 런타임 카탈로그는 Knowledge Catalog 및 Cloud IAM과 직접 통합되므로 모든 컴퓨팅 엔진에 일관되게 적용되는 에이전트 및 테이블 수준 보안에 대한 신뢰할 수 있는 컨텍스트를 정의할 수 있습니다. 또한 사용자 인증 정보 제공과 같은 주요 승인 메커니즘을 지원합니다. 즉, 기본 Cloud Storage 버킷의 파일에 직접 액세스할 필요 없이 테이블에 액세스할 수 있습니다.
엔터프라이즈 지원, 확장성, TCO 절감: Google의 전 세계 규모 인프라와 Spanner를 기반으로 메타데이터를 데이터에 맞게 확장할 수 있습니다. Cloud Storage 이중 리전 및 멀티 리전 버킷을 지원하여 장애 조치 사용 사례를 지원합니다. 또한 서버리스 및 노옵스(no-ops) 환경으로 인해 TCO가 절감되고 모든 워크로드 규모에 맞게 확장할 수 있습니다.

기존 Hive Metastore에서 제로 카피 마이그레이션 실행

실제로 얼마나 원활하게 전환되는지 보여드리기 위해 기존의 자체 관리형 Hive Metastore를 Google Cloud Lakehouse로 현대화할 수 있는 기능을 제공합니다. 이 기능을 사용하면 기존 Hive Metastore에 직접 연결하여 외부 테이블 정의와 파티션 맵을 추출하고 서버리스 Lakehouse 카탈로그에 깔끔하게 등록한 다음 Google Managed Spark, BigQuery, Gemini 기반 대화형 분석 에이전트에서 데이터를 사용할 수 있습니다.

레이크하우스로 현대화하고 주요 에이전트 여정에서 즉시 데이터 활용

데이터 아키텍처를 현대화할 준비가 되셨나요?

기존 Hive 메타스토어에서 Google Cloud의 레이크하우스로 현대화하면 분석 엔진과 에이전트 전반에서 데이터 사일로를 최소화하고, 멀티 엔진 거버넌스를 통합하며, 에이전트에 신뢰할 수 있는 컨텍스트를 제공하고, 운영 TCO를 절감할 수 있습니다. 즉, 최신 클라우드 환경이 에이전트 규모로 운영될 수 있도록 준비하는 데 도움이 됩니다.

지금 바로 시작하여 Apache Hive Metastore 테이블을 Google Cloud로 마이그레이션하고 에이전트형 시대에 대비하세요. Google Cloud Lakehouse에 대해 여기에서 자세히 알아보세요.

개방형 지식 형식 소개

Wed, 02 Sep 2026 20:00:00 +0000

파운데이션 모델이 계속 개선됨에 따라 관련 컨텍스트의 부족은 특히 에이전트 시스템을 빌드하는 데 사용될 때 모델이 수행할 수 있는 작업을 제한하는 경우가 많습니다. 이러한 모델은 코드를 작성하거나, 문서를 요약하거나, 데이터 세트를 분석하는 데 도움이 될 수 있지만, 정확하고 실행 가능한 결과를 생성하려면 여전히 올바른 정보가 필요합니다.

따라서 오늘 LLM-위키 패턴을 휴대 가능하고 상호 운용 가능한 형식으로 공식화하는 개방형 사양인 Open Knowledge Format (OKF)을 소개합니다. 이는 최신 AI 시스템에 필요한 메타데이터, 컨텍스트, 선별된 지식을 표현하기 위한 에이전트 및 인간 친화적인 벤더 중립 표준입니다.

발표된 바와 같이 OKF v0.1은 YAML 프런트매터가 있는 Markdown 파일의 디렉터리로 지식을 나타내며, 서로 다른 제작자가 작성한 위키를 서로 다른 에이전트가 번역 없이 사용할 수 있도록 하는 합의된 규칙이 소량 포함되어 있습니다.

이상입니다. 복잡한 압축 방식, 새로운 런타임, 필수 SDK가 필요하지 않습니다. OKF 문서 번들은 다음과 같습니다.

단순 마크다운 — 모든 편집기에서 읽을 수 있고, GitHub에서 렌더링할 수 있으며, 모든 검색 도구에서 색인화할 수 있습니다.
파일만 — tarball로 배포 가능, 모든 git 저장소에서 호스팅 가능, 모든 파일 시스템에 마운트 가능
YAML 프런트매터만 사용 — 쿼리할 수 있어야 하는 작은 구조화된 필드 집합(유형, 제목, 설명, 리소스, 태그, 타임스탬프)

Obsidian, Notion, Hugo 또는 지난 1년 동안 등장한 LLM 위키 패턴을 사용해 본 적이 있다면 이 형태가 익숙할 것입니다. OKF는 이러한 패턴을 상호 운용 가능하게 만드는 데 필요한 작은 규칙 집합을 공식화합니다.

이제 OKF가 조직의 문제를 어떻게 해결하는지, 어떻게 작동하는지, 어떻게 시작하는지, 다음 단계는 무엇인지 살펴보겠습니다.

분산된 컨텍스트 환경

대부분의 조직에서 파운데이션 모델이 사용하는 정보는 압도적으로 내부 지식입니다. 테이블의 스키마, 비즈니스의 측정항목 의미, 사고에 대한 런북, 두 시스템 간의 조인 경로, 이전 API에 대한 지원 중단 공지 등이 그 예입니다.

오늘날 이러한 지식의 원자는 매우 세분화된 다양한 시스템에 존재합니다.

자체 API가 있는 메타데이터 카탈로그
위키, 서드 파티 시스템 또는 공유 드라이브
코드 주석, 독스트링 또는 노트북 셀
몇몇 선임 엔지니어의 머리

AI 에이전트가 "이벤트 스트림에서 주간 활성 사용자 수를 어떻게 계산해야 해?"라는 질문에 답해야 할 때, 흩어져 있고 서로 호환되지 않는 이러한 표면에서 답을 모아야 합니다. 모든 공급업체는 자체 카탈로그, 자체 SDK, 자체 기술 그래프 스키마를 제공하며, 이러한 기술은 제품이나 조직 간에 쉽게 이전할 수 없습니다.

그 결과, 모든 에이전트 빌더가 동일한 컨텍스트 어셈블리 문제를 처음부터 해결하고, 모든 카탈로그 공급업체가 동일한 데이터 모델을 재창조하며, 지식 자체가 지식을 생성한 표면 뒤에 잠겨 있습니다.

살아있는 위키로서의 지식

개발자팀은 AI 에이전트를 빌드하는 방식을 바꾸고 있습니다. 모델을 사용하여 동일한 문서에서 동일한 사실을 반복해서 검색하는 대신, 에이전트에게 시간이 지날수록 유용해지는 공유 마크다운 라이브러리를 제공할 수 있습니다. 이를 통해 에이전트는 자체 파일을 읽고 업데이트하는 지루한 작업을 수행할 수 있으며, 팀은 콘텐츠를 선별하고 코드처럼 관리할 수 있습니다.

저명한 AI 연구자이자 교육자인 Andrej Karpathy는 LLM Wiki gist에서 이 아이디어를 가장 명확하게 설명합니다. "LLM은 지루해하지 않고, 교차 참조를 업데이트하는 것을 잊지 않으며, 한 번에 15개의 파일을 처리할 수 있습니다."라고 그는 말합니다. 인간이 개인 위키를 포기하게 만드는 바로 그 장부가 LLM이 잘하는 일입니다.

이와 유사한 위키 기반 지식 패턴은 코딩 에이전트에 연결된 Obsidian 보관함, AGENTS.md / CLAUDE.md 계열의 규칙 파일, 에이전트가 실제 작업을 수행하기 전에 참조하는 index.md 및 log.md 아티팩트로 가득한 저장소, 데이터팀 내의 '코드로서의 메타데이터' 저장소 등 다양한 이름으로 계속해서 등장하고 있습니다.

이 패턴은 강력하고 설득력이 있지만 각 인스턴스는 맞춤형입니다. Karpathy의 위키, 팀의 위키, 공급업체의 카탈로그 내보내기는 모두 비슷해 보일 수 있지만 (마크다운, 프런트매터, 교차 링크) 협업을 위해 의도적으로 설계된 것은 아닙니다. 모든 문서에 어떤 필드가 있어야 하는지 또는 파일 이름이 무엇을 의미하는지에 대해 합의된 답은 없습니다. 그 결과 위키에 인코딩된 지식이 원래 팀 내에만 사일로화되어 새로운 에이전트를 빌드할 때마다 중복된 노력이 발생합니다.

필요한 것은 또 다른 서비스가 아니라 형식입니다.

이 문제의 해결책은 또 다른 지식 서비스가 아닙니다. 형식, 즉 다음과 같은 지식을 표현하는 방법이 필요합니다.

SDK 없이 누구나 제작 가능
통합 없이 누구나 소비 가능
시스템, 조직, 도구 간 이동 시에도 유지됨
설명하는 코드와 함께 버전 제어에 저장됨
사람이 읽을 수 있고 에이전트가 파싱할 수 있음: 동일한 파일, 번역 레이어 없음

OKF는 이러한 형식을 따르도록 설계되었습니다.

OKF 작동 방식: 한 화면에 담긴 디자인

OKF 번들은 개념 을 나타내는 Markdown 파일의 디렉터리입니다. 여기에는 테이블, 데이터 세트, 측정항목, 플레이북, 런북, API 등 캡처하려는 모든 것이 포함됩니다. 각 개념은 하나의 파일입니다. 파일 경로는 개념의 ID입니다.

code_block: <ListValue: [StructValue([('code', 'sales/\r\n├── index.md\r\n├── datasets/\r\n│ ├── index.md\r\n│ └── orders_db.md\r\n├── tables/\r\n│ ├── index.md\r\n│ ├── orders.md\r\n│ └── customers.md\r\n└── metrics/\r\n│ ├── index.md\r\n └── weekly_active_users.md'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff1452dfad0>)])]>

각 개념 문서에는 구조화된 필드를 위한 작은 YAML 프런트매터 블록과 그 외 모든 것을 위한 마크다운 본문이 있습니다.

code_block: <ListValue: [StructValue([('code', '---\r\ntype: BigQuery Table\r\ntitle: Orders\r\ndescription: One row per completed customer order.\r\nresource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders\r\ntags: [sales, revenue]\r\ntimestamp: 2026-05-28T14:30:00Z\r\n---\r\n\r\n# Schema\r\n\r\n| Column | Type | Description |\r\n|---------------|-----------|------------------------------------------|\r\n| `order_id` | STRING | Globally unique order identifier. |\r\n| `customer_id` | STRING | FK to [customers](/tables/customers.md). |\r\n\r\n# Joins\r\n\r\nJoined with [customers](/tables/customers.md) on `customer_id`.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff1451a8bd0>)])]>

개념은 일반적인 Markdown 링크로 서로 연결되어 디렉터리를 파일 시스템에서 암시하는 상위/하위 링크보다 풍부한 관계의 그래프로 전환합니다. 번들에는 선택적으로 index.md 파일 (에이전트가 계층 구조를 탐색할 때 점진적 공개용)과 log.md 파일 (변경사항의 시간순 기록용)이 포함될 수 있습니다.

전체 v0.1 사양 (적합성 기준, 상호 링크 규칙, 소수의 예약된 파일 이름 포함)은 단일 페이지에 맞습니다.

설계의 3가지 원칙

1. 최소한의 의견만 제시합니다. OKF는 모든 개념에 대해 유형 필드라는 단 한 가지를 요구합니다. 다른 모든 것 (예: 어떤 유형이 있는지, 어떤 다른 필드를 포함할지, 본문에 어떤 섹션이 있는지)은 제작자에게 맡겨져 있습니다. 사양은 콘텐츠 모델이 아닌 상호 운용성 표면을 정의합니다.

2. 생산자/소비자 독립성 OKF는 지식을 작성하는 사람과 지식을 소비하는 사람을 명확하게 분리합니다. 사람이 직접 작성한 번들을 AI 에이전트가 사용할 수 있습니다. 메타데이터 내보내기 파이프라인에서 생성된 번들은 시각화 도구에서 탐색할 수 있습니다. 하나의 LLM이 합성한 번들을 다른 LLM이 쿼리할 수 있습니다. 형식은 계약이며, 각 끝의 도구는 독립적으로 교체할 수 있습니다.

3. 플랫폼이 아닌 형식 OKF는 특정 클라우드, 데이터베이스, 모델 제공업체 또는 에이전트 프레임워크에 종속되지 않습니다. 읽기, 쓰기 또는 제공을 위해 독점 계정이나 SDK를 요구하지 않습니다. 지식 형식의 가치는 소유자가 누구인지가 아니라 얼마나 많은 당사자가 이를 사용하는지에 달려 있기 때문에 개방형 표준으로 게시하고 있습니다.

사양과 함께 제공되는 기능

형식을 구체화하기 위해 생산자와 소비자 모두를 위한 참조 구현을 게시하고 있습니다.

BigQuery 데이터 세트를 탐색하고, 모든 테이블과 뷰에 대한 OKF 개념 문서를 작성한 다음, 신뢰할 수 있는 문서를 크롤링하고 인용, 스키마, 조인 경로로 각 개념을 보강하는 두 번째 LLM 패스를 실행하는 보강 에이전트
모든 OKF 번들을 단일 독립형 파일의 대화형 그래프 뷰로 전환하는 정적 HTML 시각화 도구입니다. 백엔드, 뷰어 측 설치, 페이지에서 데이터 유출이 없습니다.
3개의 탐색 가능한 샘플 번들: Google 애널리틱스 4 이커머스, Stack Overflow, Bitcoin 공개 데이터 세트는 참조 에이전트가 생성하고 저장소에 커밋한 것으로, 규정을 준수하는 OKF의 실제 예시입니다.

이러한 예시는 의도적으로 개념 증명에 초점을 맞추고 있습니다. 에이전트는 OKF를 생성하는 한 가지 방법을 보여줍니다. 형식에 관해서는 특정 에이전트 프레임워크나 LLM이 필요하지 않습니다. 시각화 도구는 이를 소비하는 한 가지 방법을 보여줍니다. 형식에 HTML이나 그래프 뷰가 필요한 것은 아닙니다. Google은 생산자와 소비자로 이루어진 생태계가 Google이 제공한 것보다 훨씬 더 크게 성장할 것으로 기대하며, 그렇게 되기를 바랍니다.

앞으로 나아갈 길

OKF v0.1은 시작점이며 완성된 표준이 아닙니다. 더 많은 생산자와 소비자가 등장하고 에이전트가 실제로 필요로 하는 지식 표현이 무엇인지 집단적으로 학습함에 따라 형식은 진화할 것입니다.

지식 카탈로그, 보강 파이프라인, AI 에이전트에 맞게 조정된 위키 또는 AI 지식 도메인의 그 어떤 것을 빌드하든, 지식 형식은 처음부터 공개적으로 게시해야만 그 이름에 걸맞은 역할을 할 수 있습니다.

여기에서 다음 작업을 수행하는 것이 좋습니다.

사양 읽기 (짧습니다!)
소스 시스템, 데이터베이스, 문서 사이트에 대한 프로듀서 작성
소비자 작성: 뷰어, 검색 색인, 번들에 대해 추론하는 에이전트
자체 데이터에 대해 참조 구현을 사용해 보세요
문제 제기, PR 전송 또는 확장 프로그램 제안: 사양은 버전이 지정되어 있으며 이전 버전과 호환되는 성장을 위해 명시적으로 설계되었습니다.

저장소, 사양, 샘플 번들은 GitHub에서 확인할 수 있습니다. 또한 Google Cloud의 Knowledge Catalog를 업데이트하여 개방형 지식 형식을 수집하고 에이전트에 제공할 수 있게 되었습니다. 관련 코드와 예는 여기에서 확인할 수 있습니다.

형식 자체가 기여입니다. Google이 출시한 도구는 이러한 기능을 실제로 구현하고 사용해 보는 데 드는 비용을 낮추기 위해 존재합니다. 오늘날 지식이 어떤 형태를 띠든 OKF는 내일 교환할 수 있는 공용어가 되도록 설계되었습니다.

_{Google Cloud 데이터 클라우드팀에서 게시 Open Knowledge Format은 개방형 사양이며, Google 제품 이외의 기여, 대체 구현, 채택을 모두 명시적으로 환영합니다.}

_{이 백서는 저자 외에도 Google의 많은 분들이 제공해 주신 핵심 아이디어를 바탕으로 작성되었습니다. 이 자리를 빌려 도움을 주신 모든 분께 감사의 말씀을 전합니다.}

데이터 클라우드 애셋의 새로운 홈으로 돌아온 데이터 스튜디오

Wed, 02 Sep 2026 20:00:00 +0000

오늘날의 데이터 풍부한 환경에서 조직은 방대한 양의 정보를 보유하고 있습니다. 하지만 이러한 데이터와 매일 정보에 입각한 결정을 내려야 하는 사용자 사이의 격차를 해소하는 것은 여전히 과제입니다. 사용자는 비즈니스에 영향을 미치는 다양한 소스의 데이터를 매일 큐레이팅하고 분석할 수 있는 단일 공간이 필요합니다.

이러한 과제를 해결하기 위한 다음 단계로, 데이터 스튜디오 (이전 명칭: Looker Studio)라는 친숙한 이름을 다시 도입합니다.

강력한 데이터 시각화 기능 외에도 데이터 스튜디오는 Google 데이터 클라우드 콘텐츠를 제공하는 AI 시대에 중요한 역할을 하고 있습니다. 데이터 스튜디오를 사용하면 데이터 스튜디오 보고서부터 BigQuery 대화형 에이전트, Colab 노트북에서 빌드된 데이터 앱에 이르기까지 다양한 Google 데이터 소스와 애셋을 한곳에서 탐색하고 상호작용할 수 있습니다.

데이터 스튜디오: 보고서, 데이터 앱, 대화형 에이전트를 한곳에서

AI 시대의 분석에 대한 비전 확장

5년 전 데이터 스튜디오가 Google Cloud 제품군에 합류한 이후 고객은 데이터 애셋을 시각화하고 공유하는 공간으로 데이터 스튜디오를 활용하여 지속적으로 혁신을 이루어 왔습니다. 한편 AI가 사실상 모든 비즈니스의 핵심 구성요소가 되면서 고객들은 데이터 애셋을 저장, 정리, 탐색할 수 있는 단일 공간이 필요하다고 말합니다.

이러한 재도입의 일환으로 Google Cloud는 Looker를 엔터프라이즈 비즈니스 인텔리전스 플랫폼으로 삼아 데이터 스튜디오를 Looker 플랫폼을 보완하는 독립적인 제품으로 발전시키고 있습니다. Google Cloud는 데이터 스튜디오를 재설계하면서 최근 Looker의 셀프서비스 및 시각화 제품에 대대적인 투자를 진행했습니다. 여기에는 중앙 시맨틱 모델을 기반으로 신뢰할 수 있는 관리형 데이터를 요구하는 사용 사례를 위한 에이전트 기능이 포함됩니다.

새로운 데이터 스튜디오는 개인 데이터 탐색에 이상적인 선택입니다. 즉, 임시 보고서를 작성하고 BigQuery에서 Google Sheets, Ads에 이르기까지 Google 생태계 전반의 데이터를 빠르게 시각화할 수 있는 공간입니다. 이러한 전략적 차별화를 통해 고객은 작업에 적합한 도구를 사용할 수 있습니다.

두 가지 버전: 데이터 스튜디오와 데이터 스튜디오 Pro

새로운 데이터 스튜디오 환경은 두 가지 버전으로 제공됩니다.

데이터 스튜디오는 강력한 무료 개인 분석 및 시각화 기능을 계속 제공하며, 임시 보고서를 만들고 공유하는 데 사용되는 온램프 역할을 하여 몇 분 만에 데이터를 대화형 대시보드로 변환합니다.
데이터 스튜디오 Pro는 AI 기능과 Google Cloud와의 긴밀한 통합을 통해 엔터프라이즈급 보안, 관리, 규정 준수 기능을 제공하여 민첩성과 제어력이 더 많이 필요한 팀과 조직의 확장을 지원하도록 설계되었습니다. Pro 라이선스는 Google Cloud 콘솔 또는 Google Workspace 관리 콘솔에서 직접 구매할 수 있습니다.

일상 업무에서 이 제품을 사용하는 많은 사용자에게 새로운 데이터 스튜디오로의 업그레이드는 대부분 투명하게 진행됩니다. 기존 보고서, 데이터 소스, 애셋, 사용자는 별도의 조치 없이 새로운 환경으로 전환됩니다. 이번 달 말에 열리는 Google Cloud Next ‘26에서 Data Studio의 새로운 기능과 데이터 클라우드 및 분석에 대한 Google Cloud의 비전을 자세히 알아보세요.

에이전트를 통한 혁신의 가속화: 소프트웨어 정의 차량(SDV)의 보안 확보

Mon, 06 Jul 2026 16:00:00 +0000

해당 블로그의 원문은 2026년 7월 7일 Google Cloud 블로그(영문)에 게재되었습니다.

자동차 산업은 새로운 기술을 채택하기 위해 가속 페달을 밟으며 중대한 전환점에 서 있습니다. 전통적인 커넥티드 차량의 시대는 소프트웨어 정의 차량(SDV)의 시대로 전환되었으며, 이는 무선 업데이트(OTA)를 통해 제공되는 수많은 새로운 기능들과 급격한 혁신이 돋보이는 시대입니다.

AI와 에이전트를 통합함으로써, 차세대 SDV는 미가공 텔레메트리(원격 진단 데이터)를 실시간으로 실행 가능한 통찰력으로 전환하여, 차량이 주변 환경 및 사용자들과 상호 작용하는 방식을 근본적으로 재고할 수 있게 될 것입니다. SDV를 보다 효과적으로 지원하고 보호하기 위해, 구글 클라우드(Google Cloud)와 발텍(Valtech)은 구글 클라우드 상에 구축된 확장성이 뛰어난 AI 지원 커넥티드 차량 플랫폼인 넥서스 SDV(Nexus SDV)를 공동 개발하기 위한 파트너십을 체결했습니다. 이 모듈식이며 개발자 친화적인 오픈소스 솔루션은 최대 1억 개의 장치를 관리할 수 있도록 설계되었으며, 데이터 흐름과 차량 내 경험을 간소화하기 위해 안드로이드 오토모티브 OS(Android Automotive OS, AAOS)와 깊이 있게 통합되어 있습니다.

우리는 Arm 기반 컴퓨팅과 Bigtable을 통해 총소유비용(TCO)을 절감하는 동시에 차세대 자동차 인텔리전스를 구축하기 위한 AI 네이티브 환경을 제공하는 넥서스 SDV(Nexus SDV) 오픈소스 코어의 첫 번째 출시를 발표하게 되어 자랑스럽게 생각합니다.

넥서스 SDV가 이끄는 AI 기반 경험

Nexus AI는 플랫폼의 지능형 엔진 역할을 수행하며, 차량을 수동적인 데이터 소스에서 능동적이고 자율적인 파트너로 변화시킵니다. 제미나이(Gemini) 모델과 제미나이 엔터프라이즈 에이전트 플랫폼(Gemini Enterprise Agent Platform)을 활용하여, Nexus AI는 복잡한 텔레메트리를 실시간으로 분석해 자율적인 의사결정과 초개인화된 운전자 보조를 위한 정보를 제공하며, 사용자의 요구를 예측하는 지능형 에이전트로서 효과적으로 작동합니다.

결정적으로, 이 고도화된 인텔리전스는 총소유비용(TCO)의 획기적인 절감에 초점을 맞추고 있습니다. 고효율 Arm 기반 컴퓨팅과 Bigtable 최적화 데이터 스토리지를 활용함으로써, 플랫폼은 방대한 데이터 볼륨을 처리하는 데 수반되는 운영 비용을 대폭 낮춰줍니다. 이 모듈식이며 AI 네이티브한 아키텍처는 제조업체가 차세대 차량 소프트웨어 도입 시 전통적으로 동반되는 과도한 클라우드 및 개발 비용 부담 없이, 자사 차량 플릿의 인텔리전스를 신속하게 확장할 수 있도록 보장합니다.

클라우드 네이티브 아키텍처

넥서스 SDV의 아키텍처는 차량 엣지와 데이터 센터 간의 격차를 해소하도록 설계된 모듈식의 클라우드 네이티브 토대 위에 구축되었습니다. AAOS와의 깊은 호환성은 클라우드와 차량 간의 긴밀한 통합을 위한 핵심 초석이며, 고정밀 텔레메트리 데이터를 실시간으로 인입하고 동기화할 수 있도록 지원합니다. 이 견고한 데이터 루프를 통해 Nexus AI는 지능형 업데이트와 서비스를 차량으로 빠르게 되돌려 보낼 수 있습니다.

개발자 친화적인 개방형 프레임워크를 제공함으로써, 넥서스 SDV는 제조업체가 구글 클라우드 생태계의 확장성과 신뢰성을 바탕으로 SDV의 전체 라이프사이클을 완벽하게 관리할 수 있도록 지원합니다.

넥서스 SDV(Nexus SDV) 아키텍처

구글 클라우드 보안 제어를 활용한 심층 방어

기본 설계부터 안전한(secure-by-design) 구조 및 제로 트러스트(Zero Trust) 아키텍처를 포함한 구글의 안전한 기반 위에 구축된 넥서스 SDV(Nexus SDV)는 규제 준수 및 위협 방어라는 까다로운 과제를 수월하게 해결할 수 있도록 지원합니다. 이를 달성하기 위해, 넥서스 SDV 아키텍처는 다음과 같은 6가지 핵심 요소를 바탕으로 포괄적인 심층 방어(defense-in-depth) 보안 모델을 구현합니다.

상호 TLS(mTLS) 및 공개키 기반구조(PKI)

넥서스 SDV는 어떠한 데이터 전송도 일어나기 전에 차량을 먼저 인증하기 위해 암호학적 신뢰 체인에 의존합니다. 이 인프라는 고가용성의 안전한 신뢰 기준점(root of trust)을 보장하기 위해 Google Cloud Certificate Authority Service(CAS)를 사용하여 고유한 CA 풀(서버, 공장 및 등록 CA)을 관리합니다.

구체적으로, 등록 서버는 초기 TLS 핸드셰이크 중에 클라이언트가 유효한 "공장 발행(factory-issued)" 인증서를 제시하도록 강제함으로써 등록 프로세스를 실행하며, 연결 스트림에서 직접 인증서를 추출 및 파싱하여 차량의 신원을 명확하게 증명합니다. 등록 과정에서 서버는 차량이 새로운 운영 인증서를 발급받기 전에 전송한 인증서 서명 요청(CSR)에 대한 검증을 수행합니다.

ID 및 액세스 관리(IAM)

이 시스템은 Keycloak이 중앙 OpenID Connect(OIDC) ID 제공업체로 배포되는 ID 브로커링(identity brokering) 방식을 사용합니다. 차량은 mTLS를 통해 자신의 운영 인증서를 사용하여 Keycloak에 인증하고, 수명이 짧은 JWT(JSON Web Token)를 발급받습니다.

미세 조정된 액세스 제어를 위해, 커스텀 NATS Auth Callout 서비스가 동적인 서브젝트 권한을 제공합니다. 이 서비스는 모든 메시징 브로커 연결 시도를 가로채고, 공개 JWK 키를 사용해 Keycloak JWT를 검증하며, 차량의 역할을 특정 NATS 서브젝트에 프로그램 방식으로 매핑합니다.

안전한 서비스 간 통신을 위해 Workload Identity Federation을 활용하므로, 파이프라인은 정적 자격 증명을 제거하기 위해 GitHub OIDC 토큰을 일시적인 구글 클라우드 액세스 권한으로 교환합니다. 한편, GKE Workload Identity를 통해 Kubernetes 서비스 계정을 구글 서비스 계정에 바인딩함으로써 Kubernetes Pod가 Bigtable과 같은 백엔드 서비스에 안전하게 액세스할 수 있도록 지원합니다.

보안은 제한된 IAM 범위(restricted IAM scopes)를 통해 한층 더 강화되어, 전용 서비스 계정이 최소한의 권한으로 프로비저닝되도록 보장합니다(예: 데이터 API가 Bigtable에서 데이터를 읽는 작업으로만 제한됨). 배포 컨텍스트에서 VPC-SC, 조직 정책 제약 조건(Organization policy constraints) 및 Private Service Connect(PSC)를 활용하는 것 또한 안전한 기반을 달성하는 데 도움이 됩니다.

비밀 관리

넥서스 SDV는 민감한 정보를 보호하기 위해 중앙 집중식 비밀 관리에 의존합니다. 모든 민감한 설정, 데이터베이스 비밀번호, 암호학적 서명 키는 Terraform 인프라 프로비저닝 중에 동적으로 생성되며 Google Cloud Secret Manager 내부에 안전하게 잠깁니다.

배포 중 애플리케이션 코드나 컨테이너 이미지에 비밀 정보가 하드코딩되는 것을 방지하기 위해 비밀 페칭(secret fetching) 방식이 사용됩니다. 대신, 서비스들은 서명 키와 자격 증명을 런타임 시점에만 메모리로 직접 가져오므로, 미사용 시(at rest) 및 전송 시(in transit) 노출 위험을 최소화합니다.

네트워크 격리

네트워크 격리를 시행하기 위해 기반 컴퓨팅 인프라는 강력하게 보호됩니다. 넥서스 SDV는 워커 노드에 퍼블릭 IP 주소가 없어 인터넷에 직접 노출되지 않는 프라이빗 GKE 클러스터에서 실행됩니다. 또한, Keycloak PostgreSQL 데이터베이스는 정적 데이터베이스 비밀번호에 의존하거나 IP 허용 목록을 관리하는 대신, Cloud SQL Proxy가 IAM 역할을 사용하여 안전하게 연결할 수 있도록 지원하는 Cloud SQL IAM 인증(Cloud SQL IAM Authentication)을 사용합니다.

안전한 AI 프레임워크(Secure AI Framework)

구글 클라우드는 Secure AI Framework(SAIF)의 지침에 따라 데이터 프라이버시, 모델 거버넌스 및 안전한 실행을 최우선으로 하는 포괄적인 엔터프라이즈급 프레임워크를 통해 이러한 고급 AI 기능을 안전하게 보호합니다. 제미나이 엔터프라이즈 에이전트 플랫폼(Gemini Enterprise Agent Platform)을 사용하면 전용 설명 가능성(Explainability) 및 안전성 제어, 지속적인 평가 및 모니터링, 안전한 모델 레지스트리 등의 기능을 통해 보안 및 거버넌스가 머신러닝 라이프사이클에 네이티브하게 임베딩됩니다.

구글이 AI를 보안하는 방법에 대해 여기에서 자세히 알아보실 수 있습니다.

데이터 API (Data API)

하운스트림 애플리케이션 및 외부 클라이언트가 Bigtable과 같은 데이터 저장소에 직접 액세스하도록 허용하는 대신, 넥서스 SDV는 커스텀 데이터 API를 통해 데이터 검색을 라우팅합니다. 이 마이크로서비스는 특정 차량 ID, 센서 데이터 유형 및 사전 정의된 시간 창을 쿼리하는 것과 같은 엄격한 요청을 고도로 제한된 Bigtable 행 범위 스캔 및 열 필터로 변환하는 안전한 추상화 레이어 역할을 수행합니다.

이를 통해 구조화된 데이터 액세스 패턴을 시행하는 안전한 게이트웨이 역할을 합니다.

넥서스 SDV와 함께 여정을 시작해 보세요

넥서스 SDV는 오픈소스 프레임워크 내에서 제조사가 AI의 모든 성능을 활용할 수 있도록 지원하는 자율적이고 안전하며 비용 효율적인 플랫폼을 제공함으로써 자동차 인텔리전스의 새 시대를 열어갑니다. 구글이 소프트웨어 정의 차량을 재정의하는 방법에 대해 여기에서 자세히 알아보실 수 있습니다.

에이전틱 데이터 클라우드의 새로운 소식: 실행 시스템 구축

Tue, 28 Apr 2026 01:00:00 +0000

* 본 아티클의 원문은 2026년 4월 23일 Google Cloud 블로그(영문)에 게재되었습니다.

기업들은 단순히 질문에 답하는 생성형 AI를 넘어, 기업을 대신해 인지하고 추론하며 행동하는 자율형 에이전트로 전환하고 있습니다. 이러한 에이전트를 기존의 레거시 스택에서 확장하려고 시도하면 거버넌스 파편화, 지속적인 신뢰 격차, 추론 루프의 단절과 같은 구조적 실패에 노출될 뿐만 아니라 비용 폭증을 초래할 수 있습니다.

이를 해결하기 위해 우리는 에이전틱 데이터 클라우드(Agentic Data Cloud)를 소개합니다. 이는 기업의 데이터 플랫폼을 정적인 저장소에서 동적인 추론 엔진으로 진화시킨 AI 네이티브 아키텍처입니다. 이 시스템은 '생각'과 '실행' 사이의 간극을 좁혀, AI 에이전트가 비즈니스 데이터와 맥락을 바탕으로 직접 행동할 수 있게 합니다. 지난 세대의 지능형 시스템(Systems of Intelligence)이 인간의 규모에 맞춰 설계되었다면, 에이전틱 데이터 클라우드는 에이전트의 규모에 맞춰 구축된 실행 시스템(System of Action)입니다.

선도적인 기업들은 이미 에이전틱 데이터 클라우드를 사용하여 가시적인 가치를 창출하고 있습니다.

Vodafone: 고객에게 중단 없는 서비스를 제공하기 위해 수백 개의 에이전트를 출시했으며, 이를 통해 매년 수백만 유로를 절감할 것으로 기대하고 있습니다.
American Express: 핵심 온프레미스 데이터 웨어하우스와 수백 개의 프로덕션 애플리케이션을 BigQuery로 이전하여, 신뢰할 수 있는 대규모 에이전틱 커머스를 구현하고 있습니다.
Virgin Voyages: 1,000개 이상의 전문 AI 에이전트를 사용하고 있으며, 그중 하나는 대규모 여정 재예약 시간을 6시간에서 단 11분으로 단축했습니다.

오늘 우리는 에이전틱 데이터 클라우드를 뒷받침하는 세 가지 새로운 혁신 분야를 발표합니다.

에이전트에게 신뢰할 수 있는 비즈니스 맥락을 제공하여 정확도를 높이는 유니버설 컨텍스트 엔진(Universal Context Engine).
데이터 전문가와 개발자의 역할을 에이전트 오케스트레이터로 진화시키는 에이전틱 우선의 실무자 경험(Agentic-first practitioner experiences).
전체 데이터 자산을 연결하여 데이터 사일로를 제거하는 AI 네이티브 멀티 클라우드 레이크하우스(Cross-cloud lakehouse).

유니버설 컨텍스트 엔진으로 에이전트 역량 강화

AI의 지능은 그 기반이 되는 '맥락(Context)'에 달려 있습니다. 만약 에이전트가 여러분이 정의한 '마진(Margin)'의 의미나 공급망의 복잡한 관계를 이해하지 못한다면 추측에 의존할 수밖에 없습니다. 에이전틱 엔터프라이즈 시대에는 데이터만으로는 부족하며, 과거의 거버넌스 모델 역시 불충분합니다. 이것이 우리가 Dataplex Universal Catalog를 Knowledge Catalog로 진화시킨 이유입니다. 이 카탈로그는 집계, 지속적인 강화, 검색이라는 엄격한 프레임워크를 사용하여 전체 데이터 자산에 걸쳐 비즈니스적 의미를 매핑하고 추론합니다.

동작 방식은 다음과 같습니다.

집계(Aggregation): 진정한 맥락을 구축하려면 모든 곳에서 데이터를 모아야 합니다. 우리는 Google Cloud와 파트너 데이터 플랫폼 전반에서 네이티브 맥락을 집계하고 있습니다. 여기에는 Palantir, Salesforce Data360, SAP, ServiceNow, Workday(프리뷰)와 같은 서드파티 카탈로그, 애플리케이션, 운영 체제 및 AI 플랫폼이 포함됩니다. 레이크하우스를 사용하면 서드파티 데이터 자산이 Knowledge Catalog에 자동으로 매핑됩니다. Google Cloud 소스의 경우, 전략 문서에서 시맨틱을 자율적으로 생성하는 새로운 LookML Agent(프리뷰)와 플랫폼에 비즈니스 로직을 네이티브하게 내장하는 BigQuery measures(프리뷰)를 통해 비즈니스 로직을 자동화하고 있습니다.
지속적인 강화(Continuous enrichment): Knowledge Catalog는 조직 전반의 사용 로그를 분석하고 백그라운드에서 데이터를 프로파일링하여 지속적인 강화를 수행합니다. 이는 데이터가 무엇인지뿐만 아니라, 기업이 데이터를 실제로 어떻게 사용하는지 학습합니다. 이는 비정형 데이터까지 확장됩니다. 파일이 Google Cloud Storage에 저장되는 즉시, Smart Storage(프리뷰)가 이미지와 PDF 객체(예정)를 즉시 태깅하고 강화합니다. 또한 유용한 비정형 데이터 컬렉션을 식별하고 Gemini를 사용하여 누락된 스키마를 자동으로 생성하며 복잡한 관계를 매핑하므로 AI가 더 이상 '맹목적으로' 작동하지 않게 됩니다.
검색 및 검색(Search and retrieval): 방대한 맥락 레이어를 만드는 것도 중요하지만, 에이전틱 시대에 검색은 새로운 쿼리 경로로 진화했습니다. 엔터프라이즈 규모에서 가장 어려운 문제는 속도, 관련성, 글로벌 도달 범위 및 보안입니다. 이를 해결하기 위해 Knowledge Catalog는 Google 검색의 혁신을 바탕으로 구축된 정교한 하이브리드 검색 스택을 사용합니다. 관련성을 높이기 위해 시맨틱 및 렉시컬 매칭을 지능형 머신러닝 기반 재순위화(re-ranking)와 결합합니다. 신뢰를 보장하기 위해 액세스 제어 인식 검색을 통해 보안 권한을 네이티브하게 적용하므로, 에이전트는 승인된 자산에만 액세스하고 조치를 취할 수 있습니다.

Knowledge Catalog는 현재 Deep Research Agent(프리뷰)를 구동하고 있습니다. Gemini Enterprise에서 제공되는 이 에이전트는 BigQuery와 같은 데이터 플랫폼은 물론 내부 문서와 웹 자산 전반에서 다단계 추론을 수행하여, 과거에 수주간의 수동 작업이 필요했던 복잡한 질문에 대해 인용구와 정밀도를 갖춘 답변을 제공합니다.

에이전틱 우선의 실무자 경험

새로운 아키텍처로 이동함에 따라 데이터 실무자의 역할은 수동으로 파이프라인을 작성하는 것에서 의도 중심의 엔지니어링을 조율하는 것으로 바뀝니다.

우리는 Google Cloud Data Agent Kit(프리뷰)를 통해 이러한 전환을 가속화하고 있습니다. 새로운 인터페이스를 도입하는 대신, 개발자들이 선호하는 환경(VS Code, Gemini CLI, Codex, Claude Code 등)에 바로 적용할 수 있는 도구, 확장 프로그램 및 플러그인 세트를 출시합니다. 이를 통해 IDE나 터미널을 네이티브 데이터 환경으로 변환하여, 시스템이 자율적으로 프레임워크(dbt, Apache Spark, Apache Airflow 등)를 선택하고 Google의 표준에 맞춘 프로덕션용 코드를 생성하도록 합니다.

이 키트는 단순히 도구를 연결하는 데 그치지 않고, 데이터를 이동시키지 않고도 페타바이트 규모까지 확장 가능한 고성능 기능을 개발자의 흐름에 직접 주입합니다. Data Agent Kit에는 다음과 같은 Google의 기본 에이전트들을 구동하는 것과 동일한 도구들이 포함되어 있습니다.

Data Engineering Agent (정식 출시): 처음부터 복잡한 파이프라인 변환을 구축하고 거버넌스 규칙을 적용하여 잘못된 데이터가 프로덕션에 유입되는 것을 방지합니다.
Data Science Agent (정식 출시): 데이터 랭글링부터 학습까지 모델 라이프사이클을 자동화하며, BigQuery Dataframes 및 서버리스 Apache Spark 전반으로 확장합니다.
Database Observability Agent (프리뷰): 인프라의 24/7 파수꾼 역할을 하며 근본 원인을 진단하고 데이터베이스 복구 조치를 실행합니다.

또한 에이전트의 원활한 실행을 돕기 위해 Google Cloud는 Model Context Protocol(MCP)을 전면 수용했습니다. 이는 에이전트가 BigQuery, Spanner(프리뷰), AlloyDB, Cloud SQL(정식 출시), Looker(프리뷰) 등 핵심 엔진 전반에서 데이터 자산을 검색하고 사용할 수 있게 해주는 보안 유니버설 인터페이스를 제공합니다.

비즈니스 사용자를 위한 경험도 재구상했습니다. 이제 BigQuery, Cloud SQL, Spanner, AlloyDB(프리뷰), Looker(정식 출시) 전반에서 Conversational Analytics(대화형 분석)가 지원됩니다. 조직은 이러한 맞춤형 분석 에이전트를 Gemini Enterprise에 게시하여, 직원들이 익숙한 인터페이스에서 실시간 데이터와 대화할 수 있게 함으로써 수동 보고서를 기다리는 시간을 없앨 수 있습니다.

에이전틱 규모를 위해 구축된 멀티 클라우드 토대

에이전트가 행동하기 위해서는 근본적으로 개방된 토대가 필요합니다. 만약 에이전트가 클라우드 간 지연 시간에 가로막히거나 특정 업체의 폐쇄적인 환경에 갇혀 있다면 자율성은 무너집니다. 이에 우리는 다음과 같은 기능을 통해 진정한 경계 없는 멀티 클라우드 레이크하우스(Cross-cloud Lakehouse)를 선보입니다.

분석 자산 연결: Cross-Cloud Interconnect(CCI)를 데이터 플레인에 직접 통합합니다. CCI의 전용 고속 프라이빗 네트워킹과 Apache Iceberg REST Catalog를 결합하여 지연 시간을 낮추고 막대한 이그레스(Egress) 비용을 제거합니다. 결과적으로 에이전트는 AWS와 Azure에 있는 데이터를 마치 Google Cloud에 있는 것처럼 원활하게 사용할 수 있습니다.
독점적 사일로 종식: 양방향 페더레이션(Bi-directional federation, 프리뷰)을 출시하여 독점 카탈로그 시대를 끝내고자 합니다. 엔진은 이제 Amazon S3의 Databricks Unity Catalog(프리뷰), Snowflake Polaris(프리뷰), Amazon S3의 AWS Glue Data Catalog(프리뷰)에서 직접 데이터를 읽을 수 있습니다. 이는 강화된 Lakehouse Governance(프리뷰)를 통해 보안 정책이 멀티 클라우드 환경 전반에 즉시 적용되도록 뒷받침됩니다.
운영 데이터의 해방: 세계에서 가장 확장성이 뛰어나고 글로벌 일관성을 갖춘 데이터베이스인 Spanner Omni(프리뷰)를 발표합니다. 이제 처음으로 클라우드, 온프레미스, 혹은 노트북 등 어디에서나 Google을 구동하는 것과 동일한 역량으로 Spanner 엔진을 실행할 수 있습니다.
인사이트와 실행 사이의 간극 해소: 대부분의 '통합' 데이터 플랫폼은 복잡한 ETL 파이프라인 구축을 강요하여 에이전트의 실시간 데이터 접근을 가로막습니다. AlloyDB용 레이크하우스 제휴(프리뷰)을 통해 프로토콜 수준의 제로-ETL 동기화를 제공함으로써, 에이전트가 운영 트랜잭션 내에서 낮은 지연 시간으로 깊이 있는 분석 이력에 접근할 수 있게 합니다.

미래를 자동화하다

에이전트 규모로 이동하면 워크로드가 수천 배 더 많아집니다. 이를 지원하기 위한 네 가지 주요 성능 혁신을 발표합니다.

Apache Spark용 Lightning Engine: 독점적인 시장 대안 대비 최대 2배의 가성비를 제공합니다.
Managed Lustre: 까다로운 모델에 데이터를 충분히 빠르게 공급할 수 있도록 최대 10TB/s의 처리량을 제공합니다.
Bigtable 인메모리 티어: 실시간 애플리케이션을 위해 1밀리초 미만의 읽기 지연 시간을 제공합니다. 이제 별도의 캐싱 레이어를 둘 필요가 없습니다.
BigQuery 유동적 확장(Fluid scaling): 오토스케일링 워크로드의 비용을 평균 최대 34% 절감하며, 에이전트가 행동할 때 리소스를 즉시 늘리고 사용하지 않을 때 줄여줍니다.

실행 시스템(System of Action) 위에서 성공을 구축하세요

수동적인 관찰의 시대는 끝났습니다. 미래는 Google의 에이전틱 데이터 클라우드가 가능케 하는 실행 시스템(System of Action)의 것입니다.

에이전틱 데이터 클라우드가 여러분의 비즈니스를 위해 무엇을 할 수 있는지 확인해 볼 준비가 되셨습니까? 실행 시스템을 통해 자율형 에이전트에게 데이터를 공급할 준비를 하는 방법에 대한 전략 워크숍을 지금 신청하세요.

에이전틱 데이터 클라우드에 대해 더 자세히 알고 싶으신가요? 수동적인 데이터를 능동적인 실행으로 전환하기 위한 당사의 청사진을 확인해 보시기 바랍니다.

BigQuery의 새로운 소식: 에이전틱 시대를 가속화하다

Tue, 28 Apr 2026 01:00:00 +0000

* 본 아티클의 원문은 2026년 4월 23일 Google Cloud 블로그(영문)에 게재되었습니다.

에이전틱(Agentic) 시대에 성공하려면 데이터 전략의 대대적인 전환이 필요합니다. 즉, 인간 중심의 워크로드에서 에이전트 우선의 워크로드로, 수동적인 지능에서 능동적인 실행으로, 그리고 단순한 원시 데이터에서 에이전트가 정확하게 추론할 수 있는 시맨틱 지식으로 진화해야 합니다.

지난 10여 년간 BigQuery는 지속적인 혁신을 통해 수만 개의 조직이 확장 가능한 데이터 및 AI 기반을 구축하고 기술적 변곡점을 헤쳐 나갈 수 있도록 지원해 왔습니다. BigQuery는 이제 자율형 '데이터 투 AI(Data-to-AI)' 플랫폼으로 진화했습니다. Gemini를 통한 데이터 처리량은 30배 이상, 비정형 데이터를 처리하는 AI 함수는 25배, 그리고 모델 컨텍스트 프로토콜(MCP)을 활용한 에이전트 구축 도구는 20배나 성장했습니다.

Definity와 같은 고객들은 고객 경험을 개선하고 백오피스 운영 효율을 높이며, 데이터 팀의 생산성을 증대시키기 위해 데이터 플랫폼을 구축하고 있습니다.

"우리는 Google Cloud에 데이터 플랫폼을 구축하고 10개월 만에 모든 핵심 보험 데이터를 수집했습니다. 이는 업계 평균 소요 시간의 절반 수준입니다. 대량의 데이터를 매우 빠르게 처리하는 BigQuery의 기술은 실무자와 엔지니어들에게 고급 도구를 제공하며, AI와 ML이 내장된 플랫폼을 선사했습니다. 우리는 매우 짧은 기간 내에 사용자 수를 두 배로 늘렸습니다." — Tatjana Lalkovic, Definity CTO

오늘 우리는 업계 선도적인 가성비와 엔터프라이즈급 안정성을 바탕으로 레이크하우스, 내장형 AI 처리 및 추론, 그리고 에이전틱 경험 전반에 걸친 BigQuery의 새로운 기능들을 발표합니다.

개방형 멀티 클라우드 레이크하우스(Open, Cross-cloud Lakehouse)

기업의 데이터는 종종 여러 애플리케이션, 다양한 클라우드 환경 및 온프레미스에 흩어져 있습니다. 초기 레이크하우스 솔루션이 데이터 중복을 줄여주었다면, 에이전틱 시대에는 네이티브 멀티모달, 멀티 클라우드 및 AI 지원이 가능한 기반이 필요합니다. 우리의 접근 방식은 Apache Iceberg의 상호 운용성과 Google의 차별화된 인프라를 결합하여 다음과 같은 새로운 기능을 제공합니다.

레이크하우스 내 관리형 Iceberg 테이블 (정식 출시, 기존 BigLake): 자동 테이블 관리, Iceberg 파티셔닝, 멀티 테이블 트랜잭션, 변경 데이터 캡처(CDC), 강화된 벡터화 및 이력 기반 최적화를 포함한 고급 BigQuery 기능과 Iceberg의 개방성을 결합합니다.
Iceberg REST 카탈로그 (프리뷰): BigQuery, Spark, 기타 오픈 소스 및 서드파티 엔진 간의 Iceberg 테이블 읽기/쓰기 상호 운용성을 지원하므로, 복잡하게 엔진 간의 장단점을 타협할 필요가 없습니다.
멀티 클라우드 레이크하우스 (프리뷰): AWS와 Azure를 시작으로 BigQuery AI 및 분석 기능을 다른 클라우드로 확장합니다. Iceberg REST 카탈로그와 같은 개방형 표준, Cross-Cloud Interconnect를 통한 고대역폭 네트워크, 투명한 캐싱 기술을 사용하여 네이티브 웨어하우스와 대등한 성능 및 TCO를 구현하며 기업을 위한 진정한 멀티 클라우드 환경을 제공합니다.
카탈로그 제휴 (프리뷰): AWS Glue, Databricks, SAP, Salesforce, Snowflake 및 Confluent Tableflow(올해 말 출시 예정) 전반에서 데이터를 쉽게 검색, 분석하고 제로 카피(Zero-copy) 방식으로 공유할 수 있습니다.
실시간 데이터 복제: Spanner, AlloyDB 및 Cloud SQL의 데이터를 BigQuery 테이블(정식 출시) 및 Iceberg(프리뷰)로 즉시 복제할 수 있도록 하여, 원시 데이터와 운영 실행 사이의 간극을 메워줍니다.

SQL 또는 자연어를 사용하여 BigQuery와 AWS 기반 Iceberg 테이블 전반의 데이터 분석

최신 레이크하우스 혁신 기술에 대한 자세한 내용은 이 블로그를 참조하세요.

엔터프라이즈 에이전트를 위한 그래프 기반 추론

AI가 진정으로 복잡하고 여러 단계(multi-hop)를 거치는 운영상의 문제를 해결하려면, 비즈니스 로직이 데이터 플랫폼 계층까지 깊숙이 확장되어야 합니다. 이 계층에서 로직을 정의하면 데이터 수집부터 소비까지 모든 정의가 일관되게 유지되고 거버넌스 하에 관리될 수 있습니다. BigQuery Graph (프리뷰)는 이러한 맥락을 활성화하는 토대를 제공하여, 데이터 실무자가 데이터 플랫폼 내에서 엔터티(객체), 관계 및 비즈니스 로직을 직접 매핑할 수 있게 합니다. 이를 통해 AI 에이전트는 거버넌스가 확보된 현실 데이터에 기반을 두고, 일관된 정확도로 복잡한 과제를 대규모로 해결할 수 있습니다.

오늘 우리는 AI 추론 능력을 강화하기 위한 새로운 그래프 기능을 발표합니다.

BigQuery Graph 내 메저(Measures) 네이티브 지원 (프리뷰): 분석 지표와 관계를 거버넌스가 적용된 단일 엔터티로 통합할 수 있습니다. 이는 데이터를 멀티 홉 구조 추론을 위한 '비즈니스 지도'로 변환하여, 에이전트가 단순한 검색을 넘어 비즈니스 이벤트의 파급 효과를 추적할 수 있도록 돕습니다.
BigQuery 대화형 분석(Conversational Analytics)의 그래프 지원 (프리뷰): 대화형 분석 에이전트가 가공되지 않은 테이블 대신 확정적인 '비즈니스 지도'를 탐색하게 함으로써 더 높은 정확도로 답변을 제공합니다. 그래프는 이중 추론을 가능하게 합니다. 즉, 에이전트는 메저를 사용하여 정확한 KPI를 즉시 계산하는 동시에, 복잡한 관계를 탐색하여 수치 뒤에 숨겨진 '이유'를 찾아낼 수 있습니다.
BigQuery Graph와 Looker 통합 (프리뷰): 그래프를 Looker 뷰로 노출함으로써 BigQuery에서 정의한 메저를 전체 데이터 스택에서 재사용할 수 있습니다. 또한 소스 제어 및 검증 기능이 포함된 Looker를 사용하여 BigQuery Graph를 정의할 수도 있습니다. 이러한 상호 운용성은 '이탈률(Churn Rate)'과 같은 지표가 대시보드와 AI 에이전트 모두에서 동일하게 유지되도록 보장합니다.
BigQuery Studio의 시각적 모델링 경험 (프리뷰): 에이전틱 컨텍스트(Agentic context)의 동력이 되는 엔터티, 관계 및 비즈니스 로직을 쉽게 구축하고 관리할 수 있는 직관적인 인터페이스를 제공합니다.

BigQuery Graph와 대화형 분석 에이전트를 사용하여 자연어로 데이터 분석

구조화 및 비정형 데이터의 가치를 깨우는 네이티브 AI 처리

데이터는 더 이상 행과 열에만 갇혀 있지 않습니다. 에이전트에게는 데이터 복사나 이동 없이도 정형 데이터와 비정형 데이터를 대규모로 처리할 수 있는 플랫폼이 필요합니다. BigQuery AI는 170개 이상의 파운데이션 모델에 대한 내장 액세스를 제공하여 예측 머신러닝 작업(예측, 이상 탐지, 추천 등)과 생성형 AI 작업(이미지 및 텍스트에서의 엔터티 추출, 콘텐츠 생성, 데이터 강화 등)을 쉽게 수행할 수 있게 해줍니다. BigQuery AI의 새로운 기능은 다음과 같습니다.

AI.PARSE_DOCUMENT (프리뷰): 단일 SQL 함수로 광학 문자 인식(OCR), 레이아웃 분석, 청킹(Chunking)을 자동화하여 복잡한 문서 처리 워크플로를 단순화합니다.
TabularFM 모델 (프리뷰): 광범위한 피처 선택, 튜닝, 학습 또는 모델 관리 없이도 고품질의 회귀 및 분류 기능을 BigQuery에 제공합니다.
ObjectRef (정식 출시): SQL과 Python을 사용하여 정형 데이터와 함께 비정형 데이터를 처리할 수 있습니다. 이는 지식 카탈로그(Knowledge Catalog)에서 풍부한 멀티모달 컨텍스트를 직접 구축하기 위한 토대를 마련합니다.
SQL 우선 AI 공동 처리 관리형 함수용 최적화 모드 (프리뷰): AI.CLASSIFY 및 AI.IF와 같은 함수를 위해 즉석에서 작업별 모델을 학습시켜, 행별(row-by-row) 생성형 AI 처리와 비교해 토큰 소비를 230배 절감합니다.
BigQuery 네이티브 Gemma 임베딩 (프리뷰): 표준 CPU에서 대규모로 고품질 임베딩을 생성할 수 있습니다.
자율 임베딩 생성 (정식 출시): 비정형 데이터를 위한 파이프라인을 완전히 자동으로 관리하며, 새로운 데이터가 수집될 때마다 벡터 인덱스를 동기화 상태로 유지합니다.
BigQuery 하이브리드 검색 (프리뷰): 시맨틱 검색과 전체 텍스트 검색을 단일 함수로 통합하여 검색을 일원화하고, RAG(검색 증강 생성) 및 복잡한 탐색에서 탁월한 정밀도를 제공합니다.
Python UDF (정식 출시): 완전 관리형 Python 스칼라 함수로 데이터를 강화, 변환 또는 정제할 수 있습니다. 자체 코드나 라이브러리를 가져올 수 있으며, 서버리스 및 스케일 아웃 실행을 통해 수백만 행까지 자동 확장됩니다. 이 기능은 향후 몇 주에 걸쳐 단계적으로 출시될 예정입니다.
Connected Sheets: BigQuery의 규모를 익숙한 Google Sheets 인터페이스로 가져오며, 이제 TimesFM 모델을 통한 예측(정식 출시) 및 이상 탐지(프리뷰)를 지원합니다.
지구 통계 분석(Geospatial analytics) 데이터 세트 (프리뷰): 인프라 자산이나 도로 관리 인사이트와 같은 위치 정보 데이터를 BigQuery에서 직접 액세스할 수 있습니다. 복잡한 수동 데이터 전처리 없이 기업 데이터와 결합하여 더 깊이 있는 분석이 가능합니다.

BigQuery에서 비정형 데이터의 액세스, 처리 및 활성화

에이전틱 경험(Agentic experiences)

AI는 지루하고 시간이 많이 걸리는 작업들을 대신 처리함으로써, 숙련된 데이터 팀이 영향력이 큰 전략적 이니셔티브에 집중할 수 있도록 돕습니다. 우리는 Google의 기초 연구, 우수한 모델, 그리고 특화된 도구들을 BigQuery에 직접 통합하여 데이터 라이프사이클의 모든 단계에서 자동화와 지원을 제공함으로써 이 분야를 선도하고 있습니다. BigQuery의 새로운 에이전틱 경험은 다음과 같습니다.

BigQuery 대화형 분석 (정식 출시): 팀원들이 자연어를 사용하여 복잡한 데이터 세트를 쿼리할 수 있게 해줍니다. 구조화된 데이터와 비정형 데이터 전전반에 걸친 예측 분석 및 추론과 같은 고급 기능을 지원하는 동시에, 인사이트를 얻기 위한 안전하고 투명한 경로를 제공합니다. BigQuery Studio 외에도, BigQuery 대화형 분석 에이전트를 Data Studio(프리뷰), Gemini Enterprise(프리뷰)에 게시하여 활용하거나 커스텀 애플리케이션을 위한 API(정식 출시)를 통해 사용할 수 있습니다.

BigQuery 대화형 분석(Conversational Analytics)을 통해 자연어로 데이터에서 인사이트 확보

능동적 에이전틱 워크플로 (프리뷰): 단순한 질의응답을 넘어 지표의 변화를 감지하고, 왜 그런 변화가 일어났는지 설명하기 위해 근본 원인 분석(Root-cause analysis)을 수행하며, 정기적인 리서치 브리핑을 사용자의 받은 편지함으로 직접 전달합니다.

BigQuery의 능동적 에이전틱 워크플로 (Proactive agentic workflows)

BigQuery 에이전트 분석(Agent Analytics)은 ADK(정식 출시) 및 LangGraph(프리뷰) 프레임워크용 플러그인을 제공하여, 에이전트 활동을 BigQuery에 기록하고 이를 트러블슈팅, 최적화 및 에이전트 평가를 위해 분석할 수 있도록 지원합니다.
BigQuery Studio에 새로운 생산성 도구들이 추가되었습니다. 리소스 검색 및 트러블슈팅을 위한 문맥 인식 어시스턴트(Contextually aware assistant, 프리뷰), SQL과 데이터프레임을 혼합할 수 있는 SQL Cells (정식 출시), 노트북 내에서 직접 시각화 자료를 만드는 Visualization Cells (정식 출시) 등이 포함됩니다. Files Explorer (정식 출시)를 통해 개발자는 코드 자산을 폴더별로 정리, 공유 및 관리할 수 있습니다. 또한, BigQuery 노트북에 Git 통합 및 워크플로(프리뷰)를 도입하여 GitHub, GitLab, Bitbucket 및 Azure DevOps 전반에 걸쳐 데이터 과학 워크플로를 위한 완벽한 소스 코드 관리(SCM) 범위를 제공합니다.
데이터 과학 에이전트 (정식 출시)는 BigQuery 노트북 내에서 단순히 목표를 평이한 영어로 서술하는 것만으로도 BigQuery ML, 데이터프레임 또는 Spark를 사용하여 데이터를 로드, 정제 및 시각화하는 계획을 자동으로 실행합니다.
데이터 엔지니어링 에이전트 (정식 출시)는 BigQuery 내 데이터 파이프라인의 개발, 관리, 마이그레이션 및 트러블슈팅을 돕습니다. 사용자의 지침(Instruction)과 지식 카탈로그(Knowledge Catalog) 통합을 통해 커스텀 컨텍스트를 활용하며, BigQuery 파이프라인 및 Dataform에서 사용할 수 있습니다.
Colab Data Apps (프리뷰)는 노트북 분석 결과물을 비즈니스 팀이 Data Studio에서 액세스할 수 있는 공유 가능한 완전 관리형 대화형 Python 애플리케이션으로 변환함으로써 분석과 실행 사이의 간극을 메워줍니다.
BigQuery 원격 MCP 서버 (정식 출시) 및 BigQuery ADK 툴셋 (정식 출시)은 에이전트를 위한 수동 데이터베이스 커넥터의 필요성을 줄여줍니다.
Google Cloud 데이터 에이전트 키트 (프리뷰)는 이식 가능한 기술 스위트, 모델 컨텍스트 프로토콜(MCP) 도구, 환경별 확장 프로그램 및 네이티브 플러그인을 제공합니다. VS Code, Gemini CLI, Codex, Claude Code 등 사용자가 구축 중인 환경에 직접 찾아가는 데이터 에이전트 키트는 IDE, 노트북 또는 터미널을 네이티브 데이터 환경으로 변환합니다. 이를 통해 사용자의 환경은 광범위한 데이터 워크플로를 오케스트레이션하고, BigQuery, dbt, Apache Spark 또는 Apache Airflow와 같은 최적의 프레임워크를 자동으로 선택하며 프로덕션 환경에 바로 적용 가능한 코드를 생성할 수 있습니다.

타의 추종을 불허하는 성능과 규모

현대의 분석 워크로드는 갈수록 예측 불가능해지고 분산되고 있습니다. 우리는 환경 내에서 데이터가 증가하더라도 비용과 운영 오버헤드는 늘어나지 않도록 BigQuery 핵심 엔진을 강화하는 데 지속적으로 투자하고 있습니다.

유동적 확장 (Fluid scaling, 정식 출시): 비용과 성능 사이의 타협이 필요 없는 프리미어 자동 확장 모델을 통해 변동성이 큰 워크로드를 효율적으로 실행할 수 있습니다. BigQuery의 유동적 확장은 진정한 초 단위 과금을 가능케 하여 최대 34%의 비용 절감 효과를 제공합니다.
고급 런타임, 소규모 쿼리 및 이력 기반 최적화 (정식 출시): 코드나 스키마 변경 없이 네이티브 및 Iceberg 워크로드를 가속화합니다. BigQuery는 전년 대비 쿼리 속도를 35% 향상시키는 동시에 쿼리 처리 비용을 40% 절감했습니다.
새로운 워크로드 관리 기능: 예약 그룹 (Reservation groups, 정식 출시), 유연한 동적 할당(프리뷰), 프로젝트 수준 슬롯 및 동시성 제어 (프리뷰) 등이 포함되며, 이를 통해 상세한 비용 할당과 가격 대비 성능 제어가 가능합니다. 이 모든 과정은 선언적 규칙 기반 워크로드 관리(프리뷰)를 통해 단순화되었습니다.
강화된 관측성(Observability, 정식 출시) 및 교차 라우팅(Intersection routing, 프리뷰)은 미션 크리티컬한 워크로드를 위해 유연한 재해 복구 역량을 제공합니다. 즉각적인 트러블슈팅을 위한 에이전트 기반 관측성(Agent-powered observability, 프리뷰)은 운영을 더욱 단순화하며, 에이전트 대응 보안 센터(Agent-ready security center, 프리뷰)는 통합된 세밀한 액세스 제어 경험을 제공합니다.

예측 불가능한 워크로드를 위한 BigQuery 유동적 확장(Fluid scaling)

에이전틱(Agentic) 시대의 BigQuery는 단순히 데이터가 머무르는 곳이 아닙니다. 이제 BigQuery는 데이터가 스스로 생각하고, 추론하며, 행동하는 공간입니다. 미래는 이미 시작되었으며, 그 어느 때보다 개방적이고 자율적이며 강력해졌습니다.

BigQuery 데이터 마이그레이션 혜택을 활용하여 여러분의 데이터 및 AI 여정을 지금 시작해 보세요. 여러분이 데이터를 통해 만들어갈 혁신적인 이야기들을 기대하겠습니다.

단일 SQL로 분산 데이터를 탐색하는 새로운 Big Query 글로벌 쿼리

Tue, 17 Feb 2026 17:00:00 +0000

* 본 아티클의 원문은 2026년 02월 18일 Google Cloud 블로그(영문)에 게재되었습니다.

글로벌 경제 환경에서 데이터는 전 세계 곳곳에서 생성되고 저장됩니다. 다국적 기업의 경우 고객 데이터는 미국 본사에 두고, 트랜잭션 로그는 유럽과 아시아에 분산 저장하는 경우가 많습니다. 이는 성능 최적화, 규정 준수, 데이터 주권 요구사항을 충족하는 데 도움이 됩니다. 하지만 이러한 방식은 '데이터가 여러 대륙에 분산되어 있는데, 어떻게 비즈니스 전체를 아우르는 단일 통합 뷰를 확보할 것인가?'라는 새로운 과제를 안겨줍니다.

과거에는 이 문제를 해결하기 위해 분석 전 데이터를 복사하고 중앙 집중하하기 위해 복잡하고 시간이 오래 걸리며 비용이 많이 드는 ETL 파이프라인이 필요했습니다. 이로 인해 지연이 발생하고 복잡성이 가중되며 팀이 적시에 임시 분석을 수행하는 데 방해가 되었습니다.

오늘 소개하는 Big Query의 글로벌 쿼리가 이러한 판도를 바꿉니다. 이제 ETL 없이도 단일 표준 SQL 쿼리만으로 서로 다른 지리적 위치에 저장된 데이터를 쿼리할 수 있습니다. 글로벌 쿼리는 현재 프리뷰 버전으로 이용 가능합니다.

글로벌 쿼리란 무엇인가요?

글로벌 쿼리는 여러 지역에 분산된 데이터 세트 간의 장벽을 허물어 줍니다. 이제 이 다국적 기업은 Big Query 콘솔에서 직접 단일 쿼리를 실행하여 모든 데이터를 조인, 통합, 분석할 수 있습니다.

백그라운드에서 Big Query가 쿼리를 실행하는 데 필요한 데이터 이동을 자동으로 처리하여 다중 지역 분석을 위한 원활한 제로 ETL 환경을 제공합니다. Big Query는 서로 다른 리전에서 실행되어야 하는 쿼리의 여러 부분을 식별하고 그에 따라 실행합니다. 다음으로, 각 부분의 쿼리 결과는 기본 쿼리가 실행될 때 선택한 위치로 전송됩니다. 이때 전송 크기를 최소화하기 위한 최적화 작업이 병행됩니다. 마지막으로 모든 데이터가 결합되고 최종 쿼리 결과가 반환됩니다.

BigQuery 사용자 Essilor Luxottica는 글로벌 쿼리를 조기에 도입하여 큰 성과를 거두었습니다.

“EssilorLuxottica는 데이터 보안과 규정 준수를 최우선으로 생각합니다. 이것이 바로 데이터가 발생한 해당 리전에 항상 저장되어야 하는 이유입니다. Big Query의 글로벌 쿼리를 사용하면 이렇게 분산된 데이터를 원활하게 통합할 수 있습니다. 이를 통해 규정 준수를 타협하지 않으면서도 교차 리전의 집계된 분석을 수행할 수 있습니다. 보안을 유지하면서도 데이터 기반의 의사 결정을 내릴 수 있는 강력한 방법입니다.” - 루벤스 발라비오, EssilorLuxottica 고객 데이터 플랫폼 관리자

이와 동시에, 리전 간 데이터 전송은 추가 비용이 발생하며, 다양한 규제들로 인해 개인 식별 정보(PII)가 원래 위치를 벗어나서는 안 되는 경우가 많습니다. 이러한 이유로 Google Cloud는 지리적 경계를 넘어 데이터를 전송하는 과정에 강력한 거버넌스가 필요하다는 것을 인지하고 있습니다. 따라서 글로벌 쿼리는 보안과 사용자 제어를 최우선으로 두고 설계되었습니다. 구체적인 방법은 다음과 같습니다.

명시적 활성화 필수: 실수로 인한 의도치 않은 데이터 전송이나 비용 발생을 방지하기 위해 글로벌 쿼리 기능은 기본적으로 비활성화되어 있습니다. 이 기능을 사용하려면 관리자가 프로젝트에 글로벌 쿼리를 명시적으로 활성화해야 하며, 실행하는 사용자 또는 서비스 계정별로 특별 권한이 필요합니다.
위치 제어권 보유: 글로벌 쿼리가 실행되는 위치를 사용자가 직접 지정할 수 있습니다. 이를 통해 데이터가 처리되는 위치를 통제하고 데이터 상주 및 규정 준수 요구사항을 준수할 수 있습니다.
거버넌스 제어 준수: 글로벌 쿼리는 VPC 서비스 제어를 포함한 기존 보안 설정을 준수하므로 설정된 보안 정책을 위반하는 방식으로는 데이터가 이동하지 않습니다.

글로벌 쿼리 실제 작동 예시

실제 작동 예시로 단일 쿼리로 생성된 글로벌 매출 통합 보고서를 살펴보겠습니다. 이전에는 이러한 보고서를 만들이 위해 별도의 데이터 엔지니어링 프로젝트가 필요했습니다. 하지만 이제 권한이 있는 분석가라면 누구나 단일 쿼리로 몇 초 만에 답을 얻을 수 있습니다.

code_block: <ListValue: [StructValue([('code', "-- Set the location where the final query will be executed, can also be set in the Console.\r\nSET @@location = 'US';\r\n\r\n-- Combine transactions from both European and Asian datasets\r\nWITH transactions AS (\r\n SELECT customer_id, transaction_amount FROM `eu_transactions.sales_2024`\r\n UNION ALL\r\n SELECT customer_id, transaction_amount FROM `asia_transactions.sales_2024`\r\n)\r\n\r\nSELECT\r\n c.customer_name,\r\n SUM(t.transaction_amount) AS total_sales\r\nFROM\r\n hq_customers.customer_list AS c\r\n LEFT JOIN transactions AS t\r\n ON c.id = t.customer_id\r\nGROUP BY\r\n c.customer_name\r\nORDER BY\r\n total_sales DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff144478d10>)])]>

보시는 것처럼 이 모든 과정은 표준 SQL로 이루어집니다. 유럽 및 아시아 데이터 세트에 저장된 모든 트랜잭션을 가져와 미국에 보관된 고객 데이터와 결합합니다. 이전과 다른 점은 이제 Big Query가 수천 마일 떨어진 데이터 세트에서 이 작업을 직접 수행한다는 것입니다. 이를 통해 아키텍처를 획기적으로 간소화할 뿐만 아니라, 인사이트를 얻기까지의 시간 역시 대폭 단축해 줍니다.

지금 바로 글로벌 쿼리를 시작해 보세요

글로벌 쿼리를 사용하면 분산된 데이터 전반에서 새로운 인사이트를 도출하고, 팀원들이 진정한 온디맨드 글로벌 분석 역량을 갖추도록 지원할 수 있습니다.

기능 활성화 및 사용 방법에 대한 자세한 내용은 official documentation를 참고하시기 바랍니다. Google Cloud는 정식 버전 출시를 목표로 기능을 지속적으로 발전시켜 나가고 있으며 여러분의 소중한 의견을 기다리고 있습니다.

BigQuery 내부 구조 심층 분석: Google이 분석에 임베딩을 도입한 방법

Tue, 11 Nov 2025 17:00:00 +0000

* 본 아티클의 원문은 2025년 11월 12일 Google Cloud 블로그(영문)에 게재되었습니다.

임베딩은 데이터와 AI의 교차점에서 핵심적인 역할을 하는 구성요소입니다. 데이터 구조로서의 임베딩은 데이터가 가진 고유한 의미를 인코딩하며, 이들은 비교될 때 그 중요성이 분명해집니다. 벡터 검색은 공유 공간 내에서 임베딩 간의 거리를 평가하여 임베딩의 상대적 의미를 밝히는 기법입니다.

2024년 초 Google Cloud는 BigQuery 데이터 플랫폼에 벡터 검색 기능을 출시하여 모든 BigQuery 사용자가 이 강력한 기능을 이용할 수 있도록 했습니다. 이를 통해 특수 데이터베이스나 복잡한 AI 워크플로를 구축할 필요가 없어졌습니다. 벡터 검색을 범용화하기 위한 Google Cloud의 지속적인 노력은 BigQuery 사용자가 기대하는 규모, 간편함, 비용 효율성을 갖춘 고유한 접근방식으로 이어졌습니다. 이 글에서는 지난 2년간의 여정을 되돌아보며 제품 개발과 고객 상호작용을 통해 얻은 인사이트를 공유하고자 합니다.

과거의 방식: 어렵고 복잡했던 벡터 검색 구축

BigQuery에 벡터 검색에 대한 기본 지원이 추가되기 전에는 확장 가능한 벡터 검색 솔루션을 빌드하는 것이 복잡하고 여러 단계를 거쳐야 하는 프로세스였습니다. 데이터 전문가는 다음 작업을 수행해야 했습니다.

데이터 웨어하우스에서 데이터 추출
특수한 머신러닝 인프라를 사용하여 임베딩 생성
생성된 임베딩을 전용 벡터 데이터베이스에 로드
서버 프로비저닝, 확장, 색인 관리를 포함한 추가 인프라 유지보수
벡터 검색 결과를 핵심 비즈니스 데이터와 다시 연결하는 커스텀 파이프라인 개발
운영 시스템의 치명적 문제인 인덱스 재빌드 중 발생하는 다운타임 처리

이처럼 분산되고 비용이 많이 들며 유지보수 부담이 큰 아키텍처는 많은 팀의 진입 장벽이었습니다.

초기 단계: 간편함에 집중하다

Google Cloud는 시장에서 가장 간단한 벡터 데이터베이스를 만드는 것을 목표로 BigQuery 벡터 검색을 시작했습니다. 이 프레임워크는 다음과 같은 몇 가지 핵심 설계 요구사항을 충족하기 위해 빌드되었습니다.

완전한 서버리스: Google Cloud는 모든 BigQuery 고객에게 벡터 검색을 제공하는 가장 좋은 방법이 서버리스라는 것을 일찍이 깨달았습니다. 먼저 BigQuery 내에서 클러스터링과 인덱싱의 장점을 결합한 IVF 색인(Index)을 BigQuery 내부에 빌드했습니다. 따라서 BigQuery에서 벡터 검색을 사용하기 위해 새 서버를 프로비저닝할 필요가 전혀 없습니다. 즉, 벡터 데이터베이스의 기본 인프라를 관리할 필요가 없으므로 팀은 가장 중요한 데이터에만 집중할 수 있습니다. BigQuery는 확장, 유지보수, 안정성을 자동으로 처리하며 수십억 개의 임베딩을 처리할 수 있도록 쉽게 확장되므로 비즈니스 성장에 따라 솔루션을 확장할 수 있습니다.
최대한 간편한 색인 유지 보수: BigQuery의 벡터 색인은 이러한 간소화의 핵심 요소입니다. 간단한 CREATE VECTOR INDEX SQL 문으로 색인을 생성하면 BigQuery가 나머지를 처리합니다. 새로운 데이터가 수집되면 색인이 자동으로 비동기식으로 새로고침되어 변경사항을 반영합니다. 데이터 수집으로 인해 데이터 분포가 변경되어 검색 정확도가 떨어지더라도 문제없습니다. 모델 재빌드 기능을 사용하면 색인 다운타임 없이 단 하나의 SQL 문으로 색인을 완전히 재빌드할 수 있습니다.
GoogleSQL 및 Python과의 통합: 간단한 VECTOR_SEARCH 함수를 사용하여 기존 SQL 워크플로 내에서 직접 벡터 검색을 수행할 수 있습니다. 따라서 시맨틱 검색을 기존 쿼리 및 조인과 쉽게 결합할 수 있습니다. 데이터 과학자에게는 Python 및 LangChain, BigQuery DataFrames와 같은 도구와의 통합이 고급 머신러닝 애플리케이션을 빌드하는 데 자연스럽게 적합합니다.
보장된 일관성: 새로운 데이터는 수집 즉시 VECTOR_SEARCH 함수를 통해 검색할 수 있으므로 검색 결과의 정확성과 일관성이 보장됩니다.
사용한 만큼만 지불: BigQuery 벡터 검색 가격 책정 모델은 유연성을 고려하여 설계되었습니다. 이 '종량제(pay as you go)' 모델은 임시 분석과 가격 대비 성능이 뛰어난 배치 쿼리 모두에 적합합니다. 이 모델은 막대한 초기 투자 없이도 기능을 쉽게 사용해 볼 수 있다는 장점이 있습니다.
보안은 기본: BigQuery의 보안 인프라는 행 수준 보안(RLS) 및 열 수준 보안(CLS)을 통해 강력한 데이터 액세스 제어를 제공합니다. 이러한 다층적 접근방식은 사용자가 승인된 데이터에만 액세스할 수 있도록 보장하여 보호를 강화하고 규정 준수를 보장합니다.

성장기: 고객과 함께 발전하다

초기 프로젝트에서 성공을 거둔 고객들이 더 많은 데이터를 BigQuery로 이전하면서 새로운 임베딩 기반 접근방식을 사용하기 위해 '업데이트'하고 있는 다양한 데이터 과학 워크플로에 대해 알려주었습니다. 벡터 검색으로 개선할 수 있는 다양한 애플리케이션의 몇 가지 예는 다음과 같습니다.

검색 증강 생성(RAG)을 사용하는 LLM 애플리케이션: 벡터 검색은 관련 비즈니스 데이터를 제공하여 대규모 언어 모델(LLM)의 정확하고 그라운딩된 응답을 보장하는 데 도움이 됩니다.
비즈니스 데이터에 대한 시맨틱 검색: 내부 및 외부 사용자 모두를 위한 강력한 자연어 검색 기능을 지원합니다. 예를 들어 마케팅팀은 'Jane과 비슷한 구매 내역을 가진 고객'을 검색하여 의미상 유사한 고객 프로필 목록을 받을 수 있습니다.
Customer 360 및 중복 제거: 임베딩을 사용하여 이름이나 주소와 같은 세부정보가 약간 다르더라도 유사한 고객 레코드를 식별합니다. 이는 데이터를 정리하고 통합하여 고객에 대한 정확한 단일 뷰(Single view)를 확보하는 효과적인 방법입니다.
로그 분석 및 이상 징후 탐지: 로그 데이터를 임베딩으로 수집하고 벡터 검색을 사용하여 텍스트가 정확히 일치하지 않더라도 유사한 로그 항목을 빠르게 찾습니다. 이를 통해 보안팀은 잠재적인 위협과 이상 징후를 훨씬 더 빠르게 식별할 수 있습니다.
제품 추천 강화: 시각적으로나 텍스트로 유사한 항목(예: 의류) 또는 의미상 관련된 보완 제품을 추천합니다.

현재: 규모 및 비용 효율성 개선

고객 사용량이 증가함에 따라 Google Cloud는 RAG 및 생성형 AI 워크로드를 넘어 배치 처리에 대한 상당한 수요를 관찰하면서 제품을 개선했습니다. 기존 벡터 데이터베이스와 달리 BigQuery의 향상된 배치 벡터 검색은 대규모 데이터 세트에 대한 고처리량 분석적 유사성 검색에 탁월합니다. 이를 통해 데이터 과학자는 기존 데이터 환경 내에서 수십억 개의 레코드를 동시에 분석하여 이전에는 불가능했던 다음과 같은 대규모 작업을 수행할 수 있습니다.

대규모 클러스터링: 행동 임베딩을 기반으로 데이터베이스의 모든 고객을 그룹화
포괄적인 이상 징후 탐지: 금융 원장의 모든 계정에 대해 가장 비정상적인 거래를 찾기
대량 항목 분류: 수백만 개의 텍스트 문서 또는 제품 이미지를 동시에 분류

개발의 두 번째 단계에서는 벡터 검색 환경을 더욱 개선하기 위해 다음과 같은 새로운 가능을 출시했습니다.

ScaNN 색인을 사용하여 빌드된 TreeAH는 가격/성능 면에서 상당한 제품 차별화를 제공합니다. 고객의 데이터 과학팀은 더 많은 추천, 클러스터링, 데이터 파이프라인을 벡터 검색에 전환하고 있습니다. TreeAH를 사용한 결과 큰 개선이 있었습니다.
학습 및 색인 성능과 사용성을 높이기 위한 다양한 내부 개선사항이 적용되었습니다. 예를 들어 대규모 색인 학습 작업을 백그라운드로 이동시켜 사용성과 확장성을 높이는 비동기 색인 학습을 추가했습니다. 또한 사용자에게 추가 비용을 부과하지 않으면서 인덱싱 성능을 개선하고 지연 시간을 줄이는 다양한 내부 최적화를 수행했습니다.
저장된 컬럼을 통해 벡터 검색 성능을 개선할 수 있습니다.

사용자는 벡터 검색 쿼리에서 저장된 컬럼에 사전 필터(Prefilters)를 적용하여 검색 정확도를 저하시키지 않으면서 검색 성능을 크게 최적화할 수 있습니다.
사용자가 벡터 검색 쿼리에서 저장된 컬럼만 쿼리하는 경우 기본 테이블과의 비용이 많이 드는 조인을 피하여 검색 성능을 더욱 향상시킬 수 있습니다.

파티션된 색인을 사용해 관련 없는 파티션을 건너뛰어 I/O 비용을 획기적으로 줄이고 쿼리 성능을 가속화합니다. 이는 날짜나 리전과 같은 파티션 컬럼을 자주 필터링하는 고객에게 특히 유용합니다.
인덱스 모델 재빌드를 통해 시간이 지나도 벡터 검색 결과가 정확하고 관련성을 유지하도록 지원합니다. 기본 데이터가 진화함에 따라 이제 모델 드리프트를 선제적으로 수정하여 색인 다운타임 없이 벡터 검색 애플리케이션의 높은 성능을 유지할 수 있습니다.

미래를 향하여: 모든 것의 인덱싱

에이전트형 AI를 도입하려는 기업이 늘면서 데이터 플랫폼의 중요성이 그 어느 때보다 커졌습니다. 모든 비즈니스에 생산성을 위한 자체 AI 모드를 보유하는 세상을 상상하며, 관련 데이터를 검색(Retreiving)하는 것이 생산성의 핵심입니다. 여기에는 정형 및 비정형의 모든 관련 엔터프라이즈 데이터의 지능형 인덱싱이 포함되어 AI와 분석을 자동화합니다. 인덱싱과 검색은 Google의 핵심입니다. 앞으로도 관련 기술 혁신을 공유해 드리겠습니다.

데이터 분석 역량 강화: 이제 데이터 사이언스 에이전트가 BigQuery ML, DataFrames, Spark를 지원합니다

Tue, 16 Sep 2025 16:00:00 +0000

* 본 아티클의 원문은 2025년 09월 17일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud는 데이터 과학 및 분석 워크플로를 간소화하고 혁신하는 데 도움이 되는 BigQuery 및 Vertex AI를 위한 AI 중심 Colab Enterprise 노트북 환경을 최근 발표했습니다. Colab Enterprise 노트북에는 데이터 사이언스 에이전트가 기본 제공되어 데이터 탐색, 변환, 머신러닝 모델링을 용이하게 하는 에이전트 기능을 통해 데이터 사이언스 개발을 가속화할 수 있습니다. 에이전트는 간단한 프롬프트만으로 데이터 로드 및 정리부터 모델 학습 및 평가에 이르는 워크플로에 대한 상세한 계획을 생성합니다.

오늘은 특히 대규모 개방형 형식 데이터 세트의 분석 여정을 더욱 간소화하고 확장할 수 있는 데이터 사이언스 에이전트의 강력한 새로운 기능을 소개합니다.

BigQuery ML, BigQuery DataFrames, Spark 생성

이제 데이터 사이언스 에이전트 내에서 직접 대규모 데이터 처리를 위해 BigQuery 머신러닝(ML), BigQuery DataFrames(BigFrames), Spark의 기능을 활용할 수 있습니다. BigQuery ML과 BigQuery DataFrames를 사용하면 BigQuery에서 직접 데이터 변환, 모델 학습, 추론을 실행하여 확장할 수 있습니다. 또한 Apache Spark용 서버리스를 사용하면 대규모 데이터 세트에 대해 분산 데이터 처리를 수행할 수 있으므로 단일 머신의 메모리에 맞지 않는 대규모 데이터도 처리할 수 있습니다.

이러한 도구를 호출하려면 프롬프트에 다음 키워드를 포함하기만 하면 됩니다.

BigQuery ML: 'BigQuery ML', 'BQML' 또는 'SQL' 사용
BigQuery DataFrames: 'BigQuery DataFrames' 또는 'BigFrames' 지정
PySpark: 'Spark' 또는 'PySpark' 포함

향후에는 데이터 사이언스 에이전트가 선택한 데이터 세트의 크기나 노트북의 콘텐츠를 기반으로 사용 사례에 맞는 관련 프레임워크를 선택할 수 있게 될 것입니다.

시작하는 데 도움이 될 몇 가지 프롬프트 예시를 소개합니다.

“ project_id.dataset_id.table_id에서 BigQuery SQL을 사용하여 고품질 예측 모델을 빌드하여 재고 수요를 예측해. 모델의 평가 측정항목을 제시하고 95% 신뢰 구간으로 예측을 시각화해 줘.”
“BigQuery DataFrames를 사용하여 경사 부스팅 트리 모델을 학습시키고 평가하여 project_id.dataset_id.table_id테이블에서 주택 가격을 예측해 줘. 학습 전에 neighborhood 열을 원-핫 인코딩해 줘."
"타겟팅된 마케팅 캠페인을 위해 유사한 고객을 그룹화하고 싶은데, 먼저 PCA 모델을 사용해서 차원 축소를 진행해야 돼. Spark를 사용하여 project_id.dataset_id.table_id테이블에서 이 작업을 수행해 줘.”

제한사항: 현재 데이터 사이언스 에이전트는 Spark 4.0 코드를 생성합니다. 에이전트는 코드를 Spark 4.0으로 업그레이드하는 데 도움이 될 수 있습니다. 하지만 이전 버전의 Spark를 사용해야 하는 경우 지금은 PySpark용 데이터 사이언스 에이전트를 사용하지 않는 것이 좋습니다.

컨텍스트 및 @ 멘션을 사용하여 데이터 추가

또한 대화에 데이터를 더 쉽게 가져올 수 있도록 지원합니다. 이제 데이터 사이언스 에이전트가 BigQuery 테이블의 메타데이터와 테이블을 자동으로 검색할 수 있습니다. 즉, 프롬프트에서 테이블을 직접 설명하고 데이터 사이언스 에이전트가 사용자를 대신하여 가장 관련성 높은 테이블을 검색하도록 할 수 있습니다.

또한 이제 @ 멘션을 사용하여 현재 프로젝트 내에서 BigQuery 테이블을 검색할 수 있습니다. 업계 표준의 친숙한 메커니즘을 통해 키보드에서 손을 떼지 않고도 관련 컨텍스트를 사용하여 프롬프트를 작성할 수 있습니다.

제한사항: 현재 @ 멘션은 현재 프로젝트의 BigQuery 테이블만 검색합니다. 프로젝트 전반에 걸쳐 더 광범위하게 검색하거나 세션 스토리지 및 로컬 업로드에서 파일을 추가하려면 '+' 버튼을 계속 사용하세요.

지금 바로 데이터 사이언스 에이전트 사용해 보기

또한 첫 번째 메시지 이후에 더 빠르게 시작되도록 데이터 사이언스 에이전트를 최적화했습니다. 기다리는 시간은 줄어들고 인사이트는 더 빠르게 얻을 수 있습니다. Vertex AI의 Colab Enterprise에 대한 유사한 개선사항도 곧 제공될 예정입니다.

Google Cloud는 AI 기반 데이터 사이언스 환경을 발전시키기 위해 최선을 다하고 있으며, 앞으로 어떤 기능을 빌드할지 기대하셔도 좋습니다. 시작하려면 아래 참조를 확인하세요.

액세스:

BigQuery: Google Cloud 콘솔 > BigQuery > 노트북으로 이동합니다.
Vertex AI: Google Cloud 콘솔 > Vertex AI > Colab Enterprise로 이동합니다. (참고: 여기에 언급된 BigQuery ML, BigQuery Dataframes, Spark 개선사항은 아직 Vertex AI에서 사용할 수 없지만 곧 제공될 예정입니다.)

문서:

의견 및 지원: 여러분의 의견을 기다립니다. 궁금한 점이 있거나 문제가 발생하는 경우 문의해 주세요.

Gemini 및 OSS 텍스트 임베딩이 이제 Big Query ML에 포함됩니다

Tue, 16 Sep 2025 16:00:00 +0000

* 본 아티클의 원문은 2025년 09월 17일 Google Cloud 블로그(영문)에 게재되었습니다.

고품질 텍스트 임베딩은 시맨틱 검색, 분류, 검색 증강 생성(RAG)과 같은 최신 AI 애플리케이션의 엔진입니다. 하지만 이러한 임베딩을 생성할 모델을 선택할 때, 한 가지 솔루션으로 모든 기준을 만족시킬 수는 없습니다. 일부 사용 사례에서는 최첨단 품질을 요구하는 반면, 다른 사용 사례에서는 비용, 속도 또는 오픈소스 생태계와의 호환성가 중요할 수 있습니다.

선택의 폭을 넓히기 위해 BigQuery ML의 텍스트 임베딩 기능을 대폭 확장했습니다. 기존의 text-embedding-004/005 및 text-multilingual-embedding-OO2 모델 외에도 이제 BigQuery 내에서 직접 Google의 강력한 Gemini 임베딩 모델과 13,000개 이상의 오픈소스(OSS) 모델을 사용할 수 있습니다. 데이터가 있는 곳에서 작업에 적합한 모델을 사용하여 간단한 SQL 명령어로 임베딩을 생성할 수 있습니다.

요구사항에 따라 임베딩 모델 선택

Gemini와 다양한 OSS 모델이 추가됨에 따라 BigQuery는 이제 포괄적인 텍스트 임베딩 옵션 목록을 제공합니다. 모델 품질, 비용, 확장성 등 필요에 따라 적절한 모델을 선택할 수 있습니다. 결정하는 데 도움이 되도록 각 유형을 자세히 살펴보겠습니다.

모델 카테고리	모델 품질	비용	확장성	결제
text-embedding-005 및 text-multilingual-embedding-002	매우 높음	보통 비용	메우 높은 확장성: 6시간당 O(1억)	1,000자당 $0.00002
[New] Gemini 텍스트 임베딩	최첨단	더 높은 비용	높은 확장성: 6시간당 O(1,000만)	토큰 1,000개당 $0.00012
[New] OSS 텍스트 임베딩	SOTA 서드 파티 모델부터 품질보다 효율성을 우선시하는 소형 모델까지	모델 크기 및 하드웨어와 관련이 있으며, 소형 모델은 비용 효율성이 높음	더 많은 머신을 예약하여 최고의 확장성을 달성할 수 있음: 6시간당 O(B)	머신 시간당

모델 카테고리

모델 품질

비용

확장성

결제

text-embedding-005 및 text-multilingual-embedding-002

매우 높음

보통 비용

메우 높은 확장성:

6시간당 O(1억)

1,000자당 $0.00002

[New] Gemini 텍스트 임베딩

최첨단

더 높은 비용

높은 확장성:

6시간당 O(1,000만)

토큰 1,000개당 $0.00012

[New] OSS 텍스트 임베딩

SOTA 서드 파티 모델부터 품질보다 효율성을 우선시하는 소형 모델까지

모델 크기 및 하드웨어와 관련이 있으며, 소형 모델은 비용 효율성이 높음

더 많은 머신을 예약하여 최고의 확장성을 달성할 수 있음:

6시간당 O(B)

머신 시간당

BigQuery ML의 Gemini 임베딩 모델

Gemini 임베딩 모델은 업계 최고의 텍스트 임베딩 벤치마크인 Massive Text Embedding Benchmark(MTEB) 리더보드에서 지속적으로 1위를 차지한 최첨단 텍스트 임베딩 모델입니다. MTEB 리더보드에서 1위를 차지한 이 모델은 고품질 임베딩을 직접적으로 보여줍니다.

BigQuery에서 새로운 Gemini 임베딩 모델을 사용하는 방법은 다음과 같습니다.

1. BigQuery에서 Gemini 임베딩 모델 만들기

다음 SQL 문을 사용하여 BigQuery에서 Gemini 임베딩 모델을 만듭니다. 엔드포인트를 `gemini-embedding-001`로 지정합니다.

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE MODEL bqml_tutorial.gemini_embedding_model\r\nREMOTE WITH CONNECTION DEFAULT\r\nOPTIONS(endpoint='gemini-embedding-001');"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7ff1452dd850>)])]>

2. 일괄 임베딩 생성

이제 BigQuery에서 직접 gemini-embedding 모델을 사용하여 임베딩을 생성할 수 있습니다. 다음 예시는 bigquery-public-data.hacker_news.full 데이터 세트에 텍스트를 임베딩합니다.

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n *\r\nFROM\r\n ML.GENERATE_EMBEDDING( \r\n MODEL bqml_tutorial.gemini_embedding_model,\r\n (\r\n SELECT\r\n text AS content\r\n FROM\r\n bigquery-public-data.hacker_news.full\r\n WHERE\r\n text IS NOT NULL\r\n LIMIT 10000\r\n )\r\n );'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7ff144a852d0>)])]>

Gemini 임베딩 모델은 분당 토큰 수(TPM)라는 새로운 할당량 제어 방법을 활용합니다. 평판 점수가 높은 프로젝트의 경우 기본 TPM 값은 500만 개입니다. 고객이 수동 승인 없이 설정할 수 있는 최대 TPM은 2,000만 개입니다.

작업이 처리할 수 있는 총 행 수는 행당 토큰 수에 따라 달라집니다. 예를 들어 행당 300개의 토큰이 있는 테이블을 처리하는 작업은 단일 작업으로 최대 1,200만 개의 행을 처리할 수 있습니다.

BigQuery ML의 OSS 임베딩 모델

OSS 커뮤니티는 텍스트 임베딩 모델 환경을 빠르게 발전시키고 있으며, 모든 요구사항에 맞는 다양한 선택지를 제공하고 있습니다. 최근 출시된 Qwen3-Embedding 및 EmbeddingGemma와 같은 최고 순위 모델부터 multilingual-e5-small과 같은 작고 효율적이며 비용 효율적인 소규모 모델까지 다양한 제품을 제공합니다.

이제 BigQuery ML에서 Vertex AI Model Garden에 배포된 모든 Hugging Face 텍스트 임베딩 모델(13,000개 이상의 옵션)을 사용할 수 있습니다. 이 기능을 보여주기 위해 이 예시에서는 multilingual-e5-small을 사용합니다. 이 모델은 대규모로 확장 가능하고 비용 효율적이면서도 상당한 성능을 제공하여 대규모 분석 작업에 적합합니다.

오픈소스 텍스트 임베딩 모델을 사용하려면 다음 단계를 따르세요.

1. Vertex 엔드포인트에서 모델 호스팅

먼저 Hugging Face에서 텍스트 임베딩 모델을 선택합니다. 이 경우 위에서 언급한 multilingual-e5-small을 선택합니다. 그런 다음 Vertex AI Model Garden > Hugging Face에서 배포로 이동합니다. 모델 URL을 입력하고 엔드포인트 액세스를 '공개(공유 엔드포인트)'로 설정합니다. 요구사항에 맞게 엔드포인트 이름, 리전, 머신 사양을 맞춤설정할 수도 있습니다. 기본 설정은 아래에 지정된 머신 유형의 단일 복제본을 프로비저닝합니다.

또는 BigQuery 노트북(튜토리얼 노트북 예시 참고)이나 공개 문서에 언급된 다른 방법을 사용하여 이 단계를 프로그래매틱 방식으로 수행할 수 있습니다.

2. BigQuery에서 원격 모델 만들기

모델 배포를 배포하는 데 몇 분 정도 걸릴 수 있습니다. 완료되면 다음 SQL 문을 사용하여 BigQuery에서 해당 원격 모델을 만듭니다.

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE MODEL bqml_tutorial.multilingual_e5_small\r\nREMOTE WITH CONNECTION DEFAULT\r\nOPTIONS\r\n(endpoint='https://<region>-aiplatform.googleapis.com/v1/projects/<project_name>/locations/<region>/endpoints/<endpoint_id>'\r\n);"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7ff144a86750>)])]>

위 코드 샘플의 자리표시자 엔드포인트를 엔드포인트 URL로 바꿉니다. endpoint_id에 대한 정보는 Vertex AI > 온라인 예측> 엔드포인트> 샘플 요청을 통해 콘솔에서 가져올 수 있습니다.

3. 일괄 임베딩 생성

이제 BigQuery에서 직접 OSS multilingual-e5-small 모델을 사용하여 임베딩을 생성할 수 있습니다. bigquery-public-data.hacker_news.full 데이터 세트에 텍스트를 임베딩하는 다음 예시를 참고하세요.

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n *\r\nFROM\r\n ML.GENERATE_EMBEDDING( \r\n MODEL bqml_tutorial.multilingual_e5_small,\r\n (\r\n SELECT\r\n text AS content\r\n FROM\r\n bigquery-public-data.hacker_news.full\r\n WHERE\r\n text IS NOT NULL\r\n LIMIT 10000\r\n )\r\n );'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7ff144a85510>)])]>

모델 배포를 위한 기본 리소스를 선택하면 쿼리가 hacker_news 데이터 세트의 3,800만 개 행을 약 2시간 10분 만에 처리할 수 있습니다. 이는 단일 모델 복제본으로 달성한 기준 처리량입니다.

더 많은 컴퓨팅 리소스를 프로비저닝하거나 엔드포인트 자동 확장을 사용 설정하여 워크로드를 확장할 수 있습니다. 예를 들어 복제본 10개를 선택하면 쿼리가 10배 빨라지고 6시간 쿼리 작업당 수십억 개의 행을 처리할 수 있습니다.

4. 모델 배포 취소

Vertex AI 엔드포인트는 머신이 유휴 상태일 때도 활성 상태인 동안에는 비용이 발생합니다. 일괄 작업이 완료되고 예상치 못한 비용이 발생하지 않도록 하려면 일괄 추론 후 모델을 '배포 취소'해야 합니다. Google Cloud 콘솔(Vertex AI > 엔드포인트 > 나의 엔드포인트 > 엔드포인트에서 모델 배포 취소)을 사용하거나 예시 Colab 스크립트를 사용하여 이 작업을 수행할 수 있습니다.

일괄 워크로드의 경우 배포, 추론, 배포 취소를 연속적인 워크플로로 취급하여 유휴 상태의 비용을 최소화하는 것이 가장 비용 효율적인 패턴입니다. 이를 위한 한 가지 방법은 샘플 Colab을 순차적으로 실행하는 것입니다. 결과는 놀라웠습니다. 3,800만 개의 행을 모두 처리하는 데 드는 비용은 약 2~3달러에 불과했습니다.

지금 시작하기

다음 AI 애플리케이션을 빌드할 준비가 되셨나요? 지금 바로 BigQuery에서 Gemini 또는 즐겨 사용하는 오픈소스 모델로 임베딩을 생성해 보세요. 문서를 자세히 살펴보거나 단계별 Colab 튜토리얼을 따라해 보면서 실제로 작동하는 모습을 확인하세요.

새로운 Dataproc 멀티 테넌트 클러스터로 데이터 과학 가속화

Wed, 10 Sep 2025 01:00:00 +0000

* 본 아티클의 원문은 2025년 09월 10일 Google Cloud 블로그(영문)에 게재되었습니다.

AI/ML이 빠르게 성장하면서 데이터 과학팀은 혁신을 주도하기 위해 업무의 중요성과 수요 증가에 부응할 수 있는 더 나은 노트북 환경이 필요합니다. 또한 데이터 과학 워크로드를 확장하면 인프라 관리에 새로운 과제가 발생합니다. 사용자별로 컴퓨팅 리소스를 할당하면 강력한 격리(워크로드, 프로세스, 데이터의 기술적 분리)가 가능하지만, 리소스가 사일로화되어 비효율이 발생할 수 있습니다. 공유 컴퓨팅 리소스는 효율성을 높일 수 있는 더 많은 기회를 제공하지만 격리 측면에서는 손해를 봅니다. 한쪽의 이점은 다른 쪽의 손실로 이어집니다. 이점만 얻을 수 있는 방법은 없을까요?

새로운 Dataproc 기능인 멀티 테넌트 클러스터를 소개합니다. 이 새로운 기능은 노트북 워크로드를 동시에 실행하는 많은 데이터 과학자에게 적합한 Dataproc 클러스터 배포 모델을 제공합니다. 공유 클러스터 모델을 사용하면 인프라 관리자가 Google Cloud Storage(GCS) 버킷과 같은 데이터 리소스에 대해 사용자별 세분화된 승인을 포기하지 않고도 컴퓨팅 리소스 효율성과 비용 최적화를 개선할 수 있습니다.

이는 단순히 인프라를 최적화하는 것이 아니라 비즈니스가 의존하는 혁신 주기를 가속화하는 것입니다. 데이터 과학 플랫폼이 원활하게 작동하면 팀은 가설에서 인사이트, 프로덕션으로 더 빠르게 진행할 수 있습니다. 이를 통해 조직은 중요한 비즈니스 질문에 더 빠르게 답하고, 머신러닝 모델을 더 자주 반복하며, 궁극적으로 경쟁사보다 먼저 고객에게 데이터 기반 기능과 개선된 경험을 제공할 수 있습니다. 데이터 플랫폼을 필수 비용 센터에서 성장을 위한 전략적 엔진으로 발전시키는 데 도움이 됩니다.

aside_block: <ListValue: [StructValue([('title', '$300 상당의 무료 크레딧으로 Google Cloud 데이터 분석을 사용해 보세요'), ('body', <wagtail.rich_text.RichText object at 0x7ff145082a50>), ('btn_text', ''), ('href', ''), ('image', None)])]>

작동 방식

이 새로운 기능은 Dataproc의 기존 서비스 계정 멀티테넌시를 기반으로 합니다. 이 구성의 클러스터에서는 관리자가 선언한 제한된 사용자 집합만 워크로드를 제출할 수 있습니다. 관리자는 사용자와 서비스 계정 간의 매핑도 선언합니다. 사용자가 워크로드를 실행하면 Google Cloud 리소스에 대한 모든 액세스는 특정 매핑된 서비스 계정으로만 인증됩니다. 관리자는 Identity Access Management(IAM)에서 승인을 제어합니다. 예를 들어 하나의 서비스 계정에 Cloud Storage 버킷 세트에 대한 액세스 권한을 부여하고 다른 서비스 계정에 다른 버킷 세트에 대한 액세스 권한을 부여할 수 있습니다.

이번 출시의 일환으로 서비스 계정 멀티 테넌시에 몇 가지 주요 사용성 개선사항을 적용했습니다. 이전에는 사용자-서비스 계정 매핑이 클러스터 생성 시에 설정되었으며 수정할 수 없었습니다. 이제 실행 중인 클러스터에서 매핑을 변경할 수 있으므로 관리자가 변화하는 조직 요구사항에 더 빠르게 적응할 수 있습니다. 또한 대규모 사용자층을 더 쉽게 관리할 수 있도록 매핑을 YAML 파일로 외부화하는 기능도 추가했습니다.

Jupyter 노트북은 Jupyter Kernel Gateway를 통해 클러스터에 연결됩니다. 게이트웨이는 클러스터의 워커 노드에 분산된 각 사용자의 Jupyter 커널을 실행합니다. 관리자는 워커 노드 수를 수동으로 조정하거나 자동 확장 정책을 사용하여 최종 사용자 요구사항을 충족하도록 워커 노드를 수평 확장할 수 있습니다.

노트북 사용자는 완전 관리형 Google Cloud 환경을 위해 Vertex AI Workbench를 선택하거나 자체 서드 파티 JupyterLab 배포를 가져올 수 있습니다. 두 모델 모두에서 BigQuery JupyterLab 확장 프로그램은 Dataproc 클러스터 리소스와 통합됩니다. Vertex AI Workbench 인스턴스는 확장 프로그램을 자동으로 배포할 수 있으며, 사용자는 서드 파티 JupyterLab 배포에서 수동으로 설치할 수도 있습니다.

자세히 들여다보기

Dataproc 멀티 테넌트 클러스터는 독립적인 사용자 워크로드를 격리하기 위해 추가적인 강화로 자동 구성됩니다.

YARN에서 실행되는 모든 컨테이너는 인증된 Google Cloud 사용자와 일치하는 전용 운영체제 사용자로 실행됩니다.
또한 각 OS 사용자에게는 YARN과 같은 Hadoop 기반 리모트 프로시저 콜(RPC) 서비스에 대한 인증을 위해 전용 Kerberos 주 구성원이 있습니다.
각 OS 사용자는 매핑된 서비스 계정의 Google Cloud 사용자 인증 정보에만 액세스할 수 있습니다. 클러스터의 컴퓨팅 서비스 계정 사용자 인증 정보는 최종 사용자 노트북 워크로드에 액세스할 수 없습니다.
관리자는 IAM 정책을 사용하여 매핑된 각 서비스 계정에 대한 최소 권한 액세스 승인을 정의합니다.

사용 방법

1단계: 서비스 계정 멀티테넌시 매핑 만들기 | 사용자 서비스 계정 매핑이 포함된 YAML 파일을 준비하고 Cloud Storage 버킷에 저장합니다. 예를 들면 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'user_service_account_mapping:\r\n bob@my-company.com: service-account-for-bob@iam.gserviceaccount.com\r\n alice@my-company.com: service-account-for-alice@iam.gserviceaccount.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff14517e650>)])]>

2단계: Dataproc 멀티 테넌트 클러스터 만들기 | 사용자 매핑 파일과 새로운 JUPYTER_KERNEL_GATEWAY 선택적 구성요소를 사용하여 새로운 멀티 테넌트 Dataproc 클러스터를 만듭니다.

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters create my-cluster \\\r\n --identity-config-file=gs://bucket/path/to/identity-config-file \\\r\n --service-account=cluster-service-account@iam.gserviceaccount.com \\\r\n --region=region \\\r\n --optional-components=JUPYTER_KERNEL_GATEWAY \\\r\n other args ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff146d21f90>)])]>

나중에 사용자 서비스 계정 매핑을 변경해야 하는 경우 클러스터를 업데이트하여 변경할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud dataproc clusters update my-cluster \\\r\n --identity-config-file=gs://bucket/path/to/identity-config-file \\\r\n --region=region'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7ff144985250>)])]>

3단계: Dataproc 커널이 사용 설정된 Vertex AI Workbench 인스턴스 만들기 | Vertex AI Workbench 사용자는 Dataproc 커널이 사용 설정된 인스턴스를 만들어야 합니다. 이렇게 하면 BigQuery JupyterLab 확장 프로그램이 자동으로 설치됩니다.

4단계: 서드 파티 배포에 BigQuery JupyterLab 확장 프로그램 설치 | 로컬 노트북에서 실행하는 등 서드 파티 JupyterLab 배포를 사용하는 사용자는 BigQuery JupyterLab 확장 프로그램을 수동으로 설치해야 합니다.

5단계: Dataproc 클러스터에서 커널 실행 | Vertex AI Workbench 인스턴스 또는 로컬 머신에서 JupyterLab 애플리케이션을 엽니다.

JupyterLab 런처 페이지가 브라우저에 열립니다. Jupyter 선택적 구성요소 또는 Jupyter Kernel Gateway 구성요소가 있는 Dataproc 클러스터에 액세스할 수 있는 경우 Dataproc 클러스터 노트북 섹션이 표시됩니다.

리전 및 프로젝트를 변경하려면 다음을 수행하세요.

설정 > Cloud Dataproc 설정을 선택합니다.
설정 구성 탭의 프로젝트 정보에서 프로젝트 ID 및 리전을 변경한 후 저장을 클릭합니다.
변경사항을 적용하려면 JupyterLab을 다시 시작합니다.

멀티 테넌트 클러스터에 해당하는 커널 사양을 선택합니다. 커널 사양이 선택되면 커널이 실행되며 커널이 초기화 상태에서 유휴 상태로 전환되는 데 약 30~50초가 걸립니다. 커널이 유휴 상태가 되면 실행할 준비가 된 것입니다.

멀티 테넌트 클러스터 시작하기

보안과 효율성 사이에서 고민하지 마세요. Dataproc의 새로운 멀티 테넌트 클러스터를 사용하면 중앙 집중식 제어를 유지하고 비용을 최적화하면서 데이터 과학팀에 빠르고 협업적인 환경을 제공할 수 있습니다. 이 새로운 기능은 단순한 인프라 업데이트 이상으로, 혁신 수명 주기를 가속화하는 방법입니다.

이 기능은 현재 공개 프리뷰 버전으로 제공됩니다. 지금 바로 기술 문서를 살펴보고 첫 번째 멀티 테넌트 클러스터를 만들어 보세요. 플랫폼을 지속적으로 발전시켜 나가기 위해서는 여러분의 의견이 매우 중요합니다. dataproc-feedback@google.com으로 의견을 공유해 주세요.

Google Cloud DSPM으로 기본 데이터 보안을 넘어: 중요 데이터 보호를 위한 새로운 접근법

Wed, 20 Aug 2025 16:00:00 +0000

해당 블로그의 원문은 2025년 8월 21일 Google Cloud 블로그(영문)에 게재되었습니다.

데이터 민주화와 생성형 AI 시대에 조직이 데이터를 다루는 방식은 극적으로 변화했습니다. 이러한 진화는 새로운 기회를 창출함과 동시에 보안 위험을 야기합니다. 이제 보안팀이 직면한 과제는 단순히 데이터를 보호하는 것에 그치지 않고, 이러한 새로운 현실에 맞춰 보안 및 규정 준수 기능을 확장하는 것입니다.

기존의 보안 제어가 위험 완화에 필수적인 것은 맞지만, 많은 데이터 보안 태세 관리(DSPM) 솔루션은 오늘날의 조직에 필요한 역량을 갖추지 못하고 있습니다. 예를 들어, AI 워크로드를 운영하는 조직은 민감한 데이터가 학습 환경으로 유출되지 않도록 해야 하며, 모델이나 가중치와 같은 지적 재산이 외부로 유출되지 않도록 보호하고, 모든 모델이 "규정 준수 설명 가능성"을 지원하는지 확인해야 합니다.

강력한 데이터 보안을 위해 조직이 이해해야 할 네 가지 핵심 고려 사항은 다음과 같습니다: 민감한 데이터가 어디에 있는지, 어떻게 사용되는지, 어떤 제어를 통해 데이터를 보호할 수 있는지, 그리고 규정 준수 증거를 제공하는 데 사용할 수 있는 모니터링 도구는 무엇인지입니다. 현재 미리 보기로 제공되는 새로운 DSPM(Data Security Posture Management)은 데이터 보안, 개인 정보 보호, 그리고 규정 준수를 위한 종단간(end-to-end) 거버넌스를 제공합니다.

DSPM 기능에는 보안, 개인 정보 보호 및 규정 준수 요구 사항을 충족하고 비즈니스 요구에 부합하는 고급 데이터 제어 기능이 포함됩니다. Security Command Center의 일부로 제공되는 이 Google Cloud 네이티브 솔루션은 도구의 복잡성을 줄이고 네이티브 플랫폼 경험을 제공합니다.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 보안 제품을 경험해 볼 수 있는 $300의 무료 크레딧을 드립니다.'), ('body', <wagtail.rich_text.RichText object at 0x7ff144a31e50>), ('btn_text', ''), ('href', ''), ('image', None)])]>

DSPM은 Google Cloud 환경 전반의 데이터에 대한 전체적인 시야를 제공하는 데이터 맵을 구축하여, 데이터의 민감도 수준과 기본 보안 태세를 한눈에 파악할 수 있게 합니다. 이 검색 기능을 통해 정책을 적용하여 데이터를 모니터링하고 보호할 수 있으며, 선별된 제어 기능을 민감한 데이터 요구사항에 맞춰 적용할 수 있습니다.

Google Cloud DSPM을 통해 보안 및 규정 준수팀은 다음과 같은 이점을 얻을 수 있습니다.

데이터 검색: DSPM은 데이터 자산에 대한 포괄적인 가시성을 제공합니다. Google Cloud 환경 전반에 걸쳐 데이터 자산을 자동으로 검색하고, Sensitive Data Protection의 민감도 라벨을 활용하여 어떤 데이터가 어디에 있는지 파악하도록 돕습니다
위험 평가: DSPM은 현재의 데이터 보안 태세를 Google Cloud가 권장하는 모범 사례와 비교하여 평가하고, 잠재적인 취약점과 잘못된 구성을 식별하도록 돕습니다.
데이터 보호: DSPM은 보안 및 규정 준수 요구 사항을 제어 정책과 연결함으로써 데이터 보안 프레임워크를 배포하고, 이를 실시간에 가깝게 모니터링할 수 있도록 지원합니다.
규정 준수 간소화: DSPM은 관련 규정 준수 프레임워크에 맞춰 데이터를 감사하고, 격차를 정확히 찾아내며, 증거 기반의 상세 규정 준수 보고서를 생성할 수 있도록 돕습니다. 또한 HIPAA, GDPR, PCI DSS 준수 여부를 평가하는 데도 도움을 줄 수 있습니다.

Google Cloud의 데이터 보안 태세 관리(DSPM) 솔루션에 대한 시각적 개요

고급 DSPM 제어 기능이 보안 및 규정 준수 요구 사항에 어떻게 도움이 되는지

보안팀은 조직의 Google Cloud 환경에서 민감한 데이터를 식별하고, 원하는 보안 및 규정 준수 결과를 특정 데이터 제어와 연결하는 것부터 시작할 수 있습니다. 이 과정을 더 쉽게 만들기 위해 DSPM은 보안 및 규정 준수 결과를 충족하기 위한 데이터 접근 거버넌스, 흐름 거버넌스, 데이터 보호, 그리고 데이터 삭제 제어와 같은 고급 제어 기능을 제공합니다.

현재 이러한 제어 기능은 조직, 폴더, 프로젝트를 포함한 데이터 경계에서 탐지 모드로 적용될 수 있습니다. 또한 Google Cloud Sensitive Data Protection(SDP)을 사용하여 특정 유형의 민감한 데이터를 스캔할 수도 있습니다.

고급 데이터 제어 기능을 적용하여 데이터 보호하기

데이터 접근 거버넌스

데이터 접근 거버넌스 제어를 사용하면 민감한 데이터에 대한 접근을 관리하고, 승인된 주체에 대한 접근을 탐지 모드로 제한할 수 있습니다.

예를 들어, 고객 결제 데이터에 대한 거버넌스가 필요한 조직은 오직 사기 탐지팀만 민감한 고객 결제 정보에 접근하도록 허용하는 정책을 만들고, 이 제어 정책을 민감한 데이터 전반에 적용할 수 있습니다. 일단 적용되면, 정책은 데이터를 추적하며 규정을 준수하지 않는 모든 접근 이벤트를 표면화합니다.

흐름(Flow) 거버넌스

데이터 흐름 제어를 사용하면 데이터가 국가 경계를 넘어 이동하는 방식을 탐지 모드로 제한하여 민감한 고객 데이터가 국가 경계 밖으로 이동하지 않도록 할 수 있습니다. 예를 들어, 특정 국가 내에서 운영하며 고객 데이터를 해당 국가의 지리적 경계 밖으로 이동하지 않아야 하는 규정 준수 요건이 있는 조직을 생각해 봅시다. 데이터 흐름 거버넌스를 사용하면, 조직은 해당 국가 내에서만 데이터 흐름을 허용하는 정책을 만들고 이를 민감한 데이터에 적용할 수 있습니다. 일단 적용되면, 이 제어는 허용된 지리적 경계 외부로부터의 모든 규정 미준수 읽기 작업을 표면화합니다.

데이터 보호

데이터 보호 제어는 CMEK(고객 관리형 암호화 키)를 강제하는 것과 같은 암호화 키 구성을 관리하는 데 도움이 될 수 있습니다. 민감한 데이터를 보호하는 키에 CMEK를 정책으로 강제하는 정책을 생성할 수 있습니다.

데이터 삭제

데이터 삭제 제어를 사용하면 데이터가 보관되는 최대 기간을 관리할 수 있습니다. 허용된 최대 보관 기간을 설정하는 정책을 생성하고 이를 민감한 데이터에 적용할 수 있습니다.

데이터 보안의 미래를 만들어가는 데 동참하세요.

Google Cloud는 보안 및 규정 준수팀을 초대하여 Google Cloud DSPM의 강력한 기능을 가장 먼저 경험해 볼 수 있는 기회를 제공합니다. DSPM 미리 보기에 참여하는 조직은 다음을 할 수 있습니다.

DSPM을 활성화하고 특정 비즈니스 요구에 대한 기능을 평가하기 시작합니다. 자세한 가이드는 사용자 가이드를 참조하십시오.
기술 자문 위원회(Technical Advisory Council) 및 고객 디자인 패널(Customer Design Panels)에 참여하여 DSPM 개발에 영향을 줄 수 있는 귀중한 피드백을 제공합니다.
Google Cloud 전문가와 협력하여 데이터 보안 전략을 최적화하고 성공적인 구현을 보장합니다.

추가 문의사항은 Google Cloud 계정팀에 문의하거나 dspm-pm@google.com으로 피드백을 보내주시기 바랍니다.