데이터 분석

Gemini Enterprise를 Snowflake 데이터에 안전하게 연결

Tue, 03 Nov 2026 19:00:00 +0000

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

엔터프라이즈 AI는 단순한 채팅 인터페이스를 넘어설 필요가 있습니다. AI 에이전트가 실질적인 가치를 제공하려면 데이터 웨어하우스에 액세스하여 활용 가능한 분석 정보를 생성하는 동시에 엄격한 보안 및 데이터 거버넌스를 유지해야 합니다.

이 가이드에서는 Google Cloud의 Gemini Enterprise와 Snowflake 간에 안전한 브리지를 구축하는 방법을 살펴봅니다. 모델 컨텍스트 프로토콜(MCP)과 Google 에이전트 개발 키트(ADK)를 사용하면 에이전트가 자연어를 이해하고, Snowflake Cortex를 통해 정확한 SQL을 생성하며, 사용자 수준 권한으로 쿼리를 실행하는 어시스턴트 역할을 하도록 지원할 수 있습니다.

적절한 통합 패턴 선택

직접 연결과 커스텀 조정 비교

이 게시물에서 설명하는 Google ADK 아키텍처는 고급/커스텀 조정 패턴을 나타냅니다. Snowflake 인사이트를 외부 엔터프라이즈 도구와 결합하는 워크플로, 커스텀 추론 루프, Gemini 에이전트 Engine의 크로스 플랫폼 상태 관리와 같이 Google Cloud에서 복잡한 멀티 에이전트 시스템을 빌드하는 개발자를 위해 설계되었습니다.

Gemini Enterprise를 Snowflake에 직접 연결하려는 표준 엔터프라이즈 기본 사용 사례의 경우 이 링크에 언급된 공동 솔루션을 사용하세요.

아키텍처 접근 방식

이 아키텍처를 사용하면 비즈니스 사용자가 "지난 분기 텍사스에서 가장 많이 판매된 상위 5개 품목은 무엇인가요?"와 같은 질문을 할 수 있습니다.

에이전트는 원시 SQL 실행을 클라이언트에 노출하는 대신, 쿼리 생성과 실행을 모두 Snowflake MCP 서버를 통해 노출되는 제어된 Snowflake Cortex 에이전트에 위임합니다.

제어된 변환: ADK 에이전트는 사용자의 자연어 질문을 Snowflake MCP 서버에 전달하고, 이 서버는 Cortex Analyst 시맨틱 뷰에서 지원하는 Cortex 에이전트(CORTEX_AGENT_RUN)를 호출합니다.
제어된 경계 내에서 직접 실행: Cortex 에이전트는 질문을 SQL로 변환하고, 인증된 사용자의 OAuth 세션 및 역할 권한을 사용하여 Snowflake 내에서 직접 실행하여 구조화된 결과를 ADK 에이전트에 반환합니다.

이 접근 방식은 기업의 시맨틱 정의에 매핑된 결정론적 텍스트-SQL 변환을 제공하고, 쿼리 실행을 Snowflake의 제어 경계 내에 유지하며, 스키마 할루시네이션 또는 검증되지 않은 SQL 실행의 위험을 줄입니다.

시스템 아키텍처 플로우

아래 다이어그램은 Gemini Enterprise 앱과 Snowflake 생태계 간의 신뢰 경계와 번호가 매겨진 실행 플로우를 보여줍니다.

상세한 실행 시퀀스

에이전트가 MCP를 통해 자연어 쿼리 변환 및 제어된 실행을 Snowflake Cortex 에이전트에 위임하는 방법을 보여주는 아래의 시퀀스 다이어그램을 참고하세요.

1단계: Snowflake 보안 통합 설정

엔터프라이즈 AI의 주요 위험 요소 중 하나는 일반 서비스 계정을 통해 모델에 광범위한 액세스 권한을 부여함으로써 사용자가 보안 제한을 우회할 수 있게 되는 것입니다. OAuth 2.0을 사용하여 사용자 가장을 수행하면 이 문제를 해결할 수 있습니다.

먼저 Snowflake에서 클라이언트 보안 비밀번호를 보호하기 위해 기밀 OAuth 클라이언트를 설정합니다. 아래 스니펫은 Snowflake 내에서 보안 통합을 구성합니다.

code_block: <ListValue: [StructValue([('code', "USE ROLE ACCOUNTADMIN; \r\nCREATE OR REPLACE SECURITY INTEGRATION <SECURITY_INTEGRATION_NAME> \r\nTYPE = OAUTH \r\nENABLED = TRUE \r\nOAUTH_CLIENT = CUSTOM \r\nOAUTH_CLIENT_TYPE = 'CONFIDENTIAL' \r\n-- Google Cloud's official handshake receiver address: \r\nOAUTH_REDIRECT_URI = 'https://vertexaisearch.cloud.google.com/oauth-redirect' \r\nOAUTH_ISSUE_REFRESH_TOKENS = TRUE \r\n-- Let the connection stay alive for 90 days (max Snowflake allowed limit) \r\nOAUTH_REFRESH_TOKEN_VALIDITY = 7776000;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb0a02d0>)])]>

Google Cloud 구성에 필요한 생성된 클라이언트 사용자 인증 정보를 검색하려면 Snowflake에서 다음 명령어를 실행합니다.

code_block: <ListValue: [StructValue([('code', "-- Retrieve OAuth Client ID and Client Secret\r\nSELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('<SECURITY_INTEGRATION_NAME>');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eaeaf310>)])]>

2단계: 데이터 거버넌스 및 액세스 제어

Snowflake 내에서 에이전트를 위한 전용 역할을 만들어 최소 권한의 원칙을 적용합니다.

code_block: <ListValue: [StructValue([('code', 'USE ROLE SECURITYADMIN;\r\n-- 1. Create a dedicated role\r\nCREATE ROLE IF NOT EXISTS <GENAI_ROLE_NAME>;\r\nGRANT ROLE <GENAI_ROLE_NAME> TO USER <BUSINESS_USER_NAME>; \r\nUSE ROLE SYSADMIN;\r\n-- 2. Grant structural access\r\nGRANT USAGE ON DATABASE <DATABASE_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\nGRANT USAGE ON SCHEMA <DATABASE_NAME>.<SCHEMA_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 3. Grant compute access\r\nGRANT USAGE ON WAREHOUSE <WAREHOUSE_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 4 .Grant access to the semantic layer\r\nGRANT SELECT, REFERENCES ON SEMANTIC VIEW <DATABASE_NAME>.<SCHEMA_NAME>.<SEMANTIC_VIEW_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 5. Grant select privileges on underlying raw data tables\r\nGRANT SELECT ON ALL TABLES IN SCHEMA <DATABASE_NAME>.<SCHEMA_NAME> TO ROLE <GENAI_ROLE_NAME>;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eaeac590>)])]>

중요

사용자 컨텍스트에는 시맨틱 뷰를 지원하는 물리적 테이블에 대한 SELECT 권한이 있어야 합니다. 시맨틱 뷰에만 액세스 권한을 부여하면 쿼리 실행 중에 런타임 오류가 발생합니다.
보안 정책에 따라 기본 테이블에 대한 직접 액세스 권한을 부여할 수 없는 경우, 물리적 테이블 위에 Snowflake 보안 뷰를 배치하고 그 위에 시맨틱 뷰를 빌드합니다. Snowflake 뷰는 소유자 권한으로 실행되므로 사용자의 GenAI 역할에는 원시 테이블이 아닌 보안 뷰 및 시맨틱 뷰에 대한 SELECT 권한만 필요합니다.
Snowflake OAuth 토큰은 승인이 이루어지는 정확한 시점에 사용자의 DEFAULT_ROLE 및 DEFAULT_WAREHOUSE를 캡처하고 바인딩합니다. 이러한 기본값이 구성되기 전에 사용자가 연결을 승인하면 세션이 잘못된 역할(당시 사용 가능한 역할)로 고정되고, 의도한 역할에 필요한 권한이 없으면 쿼리 실행이 실패합니다.
- Gemini Enterprise에서 승인하기 전에 기본값을 설정(아래 참고)합니다.
- 연결 승인: 사용자가 Gemini Enterprise에서 일회성 OAuth 승인을 수행하도록 합니다.
- (선택사항) 기본값 되돌리기: 승인되면 사용자는 Snowflake에서 기본 역할과 웨어하우스를 표준 운영 환경설정으로 안전하게 되돌릴 수 있습니다.

code_block: <ListValue: [StructValue([('code', "ALTER USER <BUSINESS_USER_NAME> SET DEFAULT_ROLE = '<GENAI_ROLE_NAME>';\r\nALTER USER <BUSINESS_USER_NAME> SET DEFAULT_WAREHOUSE = '<WAREHOUSE_NAME>';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f813ebd0>)])]>

3단계: Snowflake 내에서 Cortex 에이전트 및 MCP 서버 프로비저닝

다음으로, 시맨틱 뷰를 사용하여 Snowflake에서 제어되는 Cortex 에이전트를 만든 다음 CORTEX_AGENT_RUN 도구 유형을 통해 에이전트를 노출하는 MCP 서버를 프로비저닝합니다. 이 접근 방식은 SQL 생성과 쿼리 실행을 모두 Snowflake에 위임하는 동시에 호출자의 OAuth ID 및 역할 권한을 적용합니다.

code_block: <ListValue: [StructValue([('code', 'USE DATABASE <DATABASE_NAME>;\r\nUSE SCHEMA <SCHEMA_NAME>;\r\nUSE ROLE SYSADMIN;\r\n\r\n-- 1. Create the Cortex Agent over your semantic view\r\nCREATE OR REPLACE AGENT <AGENT_NAME>\r\n COMMENT = \'Governed data assistant for business queries\'\r\n PROFILE = \'{"cortex_analyst": {"semantic_models": ["<DATABASE_NAME>.<SCHEMA_NAME>.<SEMANTIC_VIEW_NAME>"]}}\';\r\n\r\n-- 2. Provision the MCP Server exposing the Cortex Agent\r\nCREATE OR REPLACE MCP SERVER <SERVER_NAME>\r\nFROM SPECIFICATION $$\r\ntools:\r\n - name: "run_cortex_agent"\r\n type: "CORTEX_AGENT_RUN"\r\n identifier: "<DATABASE_NAME>.<SCHEMA_NAME>.<AGENT_NAME>"\r\n title: "Cortex Agent Assistant"\r\n description: "Converts natural language questions into SQL and executes them directly within Snowflake using the caller\'s OAuth session permissions."\r\n$$;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f813f5d0>)])]>

격리 및 거버넌스 참고사항: CORTEX_AGENT_RUN을 사용하면 쿼리 생성 및 실행이 Snowflake의 제어된 보안 경계 내에 완전히 격리됩니다. SYSTEM_EXECUTE_SQL과 같은 원시 실행 도구를 외부 클라이언트에 노출하지 마세요. 불필요한 보안 노출 영역이 생기고 중앙 집중식 Cortex 에이전트 거버넌스를 우회하게 됩니다.

4단계: MCP 서버 URL 찾기 및 구성

ADK 코드에는 Snowflake 관리 MCP 서버의 엔드포인트 URL이 필요합니다. 이제 서버가 프로비저닝되었으므로 먼저 서버에 대한 액세스 권한을 부여한 다음 Snowflake 워크시트에서 다음 쿼리를 사용하여 정확한 엔드포인트 URL을 검색할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '-- 1. Grant access to the Cortex Agent and the MCP server\r\nUSE ROLE SECURITYADMIN;\r\nGRANT USAGE ON AGENT <DATABASE_NAME>.<SCHEMA_NAME>.<AGENT_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\nGRANT USAGE ON MCP SERVER <DATABASE_NAME>.<SCHEMA_NAME>.<SERVER_NAME> TO ROLE <GENAI_ROLE_NAME>;\r\n-- 2. View the MCP URL\r\nDESCRIBE MCP SERVER <DATABASE_NAME>.<SCHEMA_NAME>.<SERVER_NAME>;\r\n-- Or:\r\nDESC MCP SERVER <DATABASE_NAME>.<SCHEMA_NAME>.<SERVER_NAME>;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26ead0>)])]>

명령어 출력에서 메타데이터 속성을 검사하여 엔드포인트 링크를 찾습니다. URL은 다음과 같이 구성됩니다.

code_block: <ListValue: [StructValue([('code', 'https://<org_name>-<account_name>.snowflakecomputing.com/api/v2/databases/<database_name>/schemas/<schema_name>/mcp-servers/<server_name>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26dc90>)])]>

5단계: Google ADK를 통해 연결

MCP 서버를 만들고 URL을 확인했으니 이제 Google 에이전트 개발 키트(ADK)를 사용하여 에이전트 코드를 작성합니다. Python 코드에서 에이전트가 사용자 인증 정보를 추출하는 데 사용할 고유 식별자 AUTH_ID(예: snowflake_oauth_conn)를 정의합니다.

code_block: <ListValue: [StructValue([('code', 'import os\r\nimport re\r\nfrom typing import Optional\r\nfrom google.adk.agents.llm_agent import LlmAgent\r\nfrom google.adk.tools.mcp_tool.mcp_toolset import McpToolset\r\nfrom google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams\r\nfrom google.adk.tools.tool_context import ToolContext\r\n\r\n# Define the Auth ID first in your code. \r\n# You will use this exact name when registering the agent in the Google Cloud Console.\r\n# Gemini Enterprise maps the authorization token to this identifier in the ToolContext.\r\nAUTH_ID = "snowflake_oauth_conn" \r\n\r\n# 1. OAuth Header Extraction:\r\n# Define a callback to dynamically extract the user\'s OAuth token injected by Gemini Enterprise \r\n# and generate the Authorization headers required to authenticate with the Snowflake MCP.\r\ndef get_auth_headers(tool_context: Optional[ToolContext] = None) -> dict: \r\n """ \r\n OAuth Handling Callback: Dynamically extracts the user\'s OAuth token injected by Gemini Enterprise and generates the headers required to authenticate with the Snowflake MCP. \r\n """ \r\n token = None \r\n if tool_context and hasattr(tool_context, "state"): \r\n try: \r\n # Parse the state dictionary injected by Gemini Enterprise containing authorization states \r\n state_dict = tool_context.state.to_dict() if hasattr(tool_context.state, \'to_dict\') else tool_context.state \r\n pattern = re.compile(fr".*{re.escape(AUTH_ID)}.*", re.IGNORECASE) \r\n # Find the active token matching our Auth ID (snowflake_oauth_conn)\r\n matching_keys = [k for k in state_dict.keys() if pattern.match(k)] \r\n if matching_keys: \r\n token = state_dict.get(matching_keys[0]) \r\n except Exception as e: \r\n print(f"Warning: Failed to read ToolContext OAuth state: {e}") \r\n # Return authorization headers. If token is None, requests to MCP will fail.\r\n return { \r\n "Authorization": f"Bearer {token}", \r\n "Content-Type": "application/json", \r\n "Accept": "application/json, text/event-stream", \r\n } \r\n\r\n# 2. MCP Initialization:\r\n# Define the Snowflake MCP URL retrieved from \'DESCRIBE MCP SERVER\' directly in the code:\r\nMCP_SERVER_URL = "<YOUR_MCP_SERVER_URL>" # Replace with the URL retrieved from \'DESCRIBE MCP SERVER\' \r\n\r\n# Initialize the Snowflake MCP Toolset using this URL.\r\nsnowflake_mcp = McpToolset( \r\n connection_params=StreamableHTTPConnectionParams( \r\n url=MCP_SERVER_URL \r\n ), \r\n header_provider=get_auth_headers\r\n) \r\n\r\n# 3. Build the Agent:\r\n# Construct the LlmAgent using the Gemini 2.5 Flash model and attach the Snowflake MCP Toolset.\r\nroot_agent = LlmAgent( \r\n model="gemini-2.5-flash", \r\n name="enterprise_data_analyst", \r\n instruction=( \r\n "You are an enterprise data analyst. Use the `enterprise_data_agent` tool " \r\n "on the Snowflake MCP server to answer business questions. Pass the user\'s " \r\n "natural language question to the tool, which translates it into SQL and " \r\n "executes it directly within Snowflake\'s governed boundary, then present " \r\n "the results clearly to the user." \r\n ), \r\n tools=[snowflake_mcp]\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26ee50>)])]>

참고: 위의 Python 스니펫은 에이전트 설정의 일반/바닐라 버전을 나타냅니다. 조직의 구체적인 요구사항에 따라 이 템플릿을 기반으로 견고함을 강화해야 합니다(예: 커스텀 오류 처리, 정형 스키마, 커스텀 프롬프트, 구성, 추가 도구 래퍼).

6단계: 프로젝트 구조 및 배포

ADK 에이전트를 Agent Platform의 Agent Runtime에 배포하려면 다음 디렉터리 레이아웃으로 파일을 구성합니다.

code_block: <ListValue: [StructValue([('code', 'snowflake_agent/\r\n├── agent.py # The agent definition and MCP connection code (from Step 5)\r\n├── __init__.py # Package initializer exposing the agent\r\n├── .env # Environment configurations (Google Cloud Project, etc.)\r\n└── requirements.txt # List of project dependencies (google-adk, etc.)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26ef90>)])]>

1. 파일 세부정보

__init__.py: root_agent 객체를 배포 CLI에 노출합니다.

code_block: <ListValue: [StructValue([('code', '# Snowflake ADK Agent package\r\nfrom .agent import root_agent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26f210>)])]>

.env: 환경 구성을 선언합니다.

code_block: <ListValue: [StructValue([('code', 'GOOGLE_CLOUD_PROJECT="<YOUR_GCP_PROJECT_ID>"\r\nGOOGLE_CLOUD_LOCATION="<LOCATION>"\r\nGOOGLE_GENAI_USE_VERTEXAI="TRUE"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26fe10>)])]>

requirements.txt: 종속 항목을 지정합니다.

code_block: <ListValue: [StructValue([('code', 'google-adk[mcp]==2.3.0\r\ngoogle-genai==2.10.0\r\npydantic-settings==2.14.2\r\ngoogle-cloud-aiplatform[agent_engines]>=1.50.0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26e650>)])]>

2. CLI를 통한 배포

복잡한 커스텀 Python 스크립트를 실행하거나 수동으로 컨테이너를 빌드하는 대신 공식 Google Agents CLI(agents-cli)를 사용하여 배포할 수 있습니다. 이 CLI는 코드를 패키징하고, 서버를 설정하며, 배포 파이프라인을 처리합니다.

code_block: <ListValue: [StructValue([('code', '# Deploy the agent to the Google Cloud Agent Runtime\r\nagents-cli deploy --deployment-target agent_runtime'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26e250>)])]>

이 CLI는 배포 수명 주기를 자동으로 처리합니다. 완료되면 다음 단계에서 에이전트를 등록하는 데 사용할 고유한 프로젝트 리소스 경로(예: projects/PROJECT_ID/locations/LOCATION/reasoningEngines/RESOURCE_ID)를 출력합니다.

팁: ADK 에이전트 배포에 대한 자세한 내용과 고급 구성 옵션은 다음을 참고하세요.

7단계: Gemini Enterprise에 커스텀 에이전트 등록하기

에이전트 코드가 준비되고 배포되면 Google Cloud 콘솔에 에이전트를 등록합니다. 여기에서 에이전트 구성을 연결하고 Snowflake 보안 통합에서 검색된 OAuth 파라미터를 매핑합니다.

1. Snowflake에서 OAuth 엔드포인트 추출

Snowflake에서 이 쿼리를 실행하여 정확한 토큰 및 승인 엔드포인트를 추출합니다.

code_block: <ListValue: [StructValue([('code', 'DESCRIBE SECURITY INTEGRATION <SECURITY_INTEGRATION_NAME>;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26fdd0>)])]>

결과에서 다음 속성의 값을 찾습니다.

OAUTH_AUTHORIZATION_ENDPOINT: Snowflake 승인 URI입니다.
OAUTH_TOKEN_ENDPOINT: Snowflake 토큰 URI입니다.

2. Google Cloud 콘솔에서의 등록 단계

콘솔에서 Gemini Enterprise 페이지로 이동합니다.
에이전트를 등록할 애플리케이션을 선택합니다.
왼쪽 탐색 메뉴에서 에이전트를 클릭한 다음 + 에이전트 추가를 클릭합니다.
Agent Platform을 통한 커스텀 에이전트에서 추가를 선택합니다. 승인 설정이 표시됩니다.
Snowflake OAuth 연결을 설정합니다.
- 승인 추가를 클릭합니다.
- 승인 이름: ADK 코드에 정의한 정확한 ID를 입력합니다(예: snowflake_oauth_conn). 이렇게 하면 사용자 인증 정보가 코드의 AUTH_ID에 올바르게 매핑됩니다.
- 클라이언트 ID 및 클라이언트 보안 비밀번호: SYSTEM$SHOW_OAUTH_CLIENT_SECRETS 쿼리를 사용하여 Snowflake에서 검색한 사용자 인증 정보를 입력합니다.
- 토큰 URI: DESCRIBE SECURITY INTEGRATION에서 추출한 정확한 토큰 엔드포인트 값을 입력합니다.
- 승인 URI: DESCRIBE SECURITY INTEGRATION에서 추출한 승인 엔드포인트 값을 가져와 끝에 ?response_type=code를 추가합니다(예: 클라이언트 ID 및 범위 쿼리 매개변수와 함께).

code_block: <ListValue: [StructValue([('code', 'https://<org_name>-<account_name>.snowflakecomputing.com/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=https%3A%2F%2Fvertexaisearch.cloud.google.com%2Foauth-redirect&scope=session%3Arole-any&response_type=code'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb26fa90>)])]>

중요

승인 URI가 &response_type=code로 끝나는지 확인합니다(다른 매개변수가 없는 경우 ?response_type=code). 이 매개변수는 Google Cloud에서 OAuth 2.0 승인 코드 플로우를 트리거하는 데 필요합니다.

완료를 클릭한 후 다음을 클릭합니다.

6. 에이전트 속성을 구성합니다.

7. 만들기를 클릭하여 등록을 완료합니다.

식별자 정렬 이해하기

ADK 코드 AUTH_ID <==> Google Cloud 승인 이름: Python 스크립트의 AUTH_ID는 콘솔 등록 시 입력한 승인 이름/ID와 정확히 일치해야 합니다. 코드를 먼저 작성하므로 등록할 때 코드에 정의된 식별자를 재사용합니다.
Snowflake 보안 통합 이름(예: <SECURITY_INTEGRATION_NAME>): 단지 Snowflake 측 데이터베이스 객체 이름입니다. Google Cloud 승인 이름 또는 ADK Python 코드의 AUTH_ID와 일치할 필요는 없습니다.

시작하기

Gemini 모델의 추론 기능, ADK의 조정, Snowflake의 제어된 데이터 레이어를 결합하면 데이터에 AI를 안전하게 적용할 수 있습니다. 이 아키텍처는 보안 경계를 준수하면서 비즈니스 가치를 제공하는 에이전트형 어시스턴트를 제공합니다.

BigQuery ObjectRef 정식 버전 출시: SQL만으로 대화형 분석을 위한 멀티모달 데이터 플랫폼 빌드

Thu, 29 Oct 2026 19:00:00 +0000

데이터 과학, 데이터 엔지니어링, 머신러닝팀의 경우 이미지, 동영상, 오디오, 문서와 같은 비정형 데이터의 가치를 활용하려면 정형 데이터와 비정형 데이터, 분석 및 AI/ML 사용 사례를 위한 사일로화된 데이터 파이프라인을 관리해야 했습니다. 파일이 Cloud Storage에 남아 있는 경우에도 추론을 실행하려면 팀에서 외부 머신러닝 워크로드를 조정해야 하며, 이러한 정형 추론 출력을 분석을 위해 데이터 웨어하우스에 다시 연결하는 복잡하고 취약한 과제에 직면하게 됩니다. 이러한 사후 데이터 결합 방식은 상당한 운영 오버헤드와 데이터베이스 불일치를 초래합니다.

BigQuery의 ObjectRef 및 멀티모달 데이터 분석 기능이 정식 버전(GA)으로 출시됨에 따라, BigQuery는 포괄적인 멀티모달 에이전트형 데이터 플랫폼으로서의 입지를 굳히게 되었습니다.

ObjectRef를 사용하면 BigQuery가 Cloud Storage와 분석 엔진 간의 격차를 기본적으로 해소합니다. 비정형 데이터를 기존 관계형 열과 함께 기본 ObjectRef 열로 직접 표현할 수 있습니다. 이를 통해 대화형 분석을 사용하여 단일 SQL 쿼리 또는 자연어 쿼리로 Gemini 모델에 멀티모달, 다중 열 입력을 직접 전달할 수 있으므로 독립형 모델 API에 비해 엄청난 이점을 얻을 수 있습니다. BigQuery AI, BigQuery의 대화형 분석, Gemini Enterprise와 ObjectRef를 통합하면 Cloud Storage 파일을 풍부하고 정형화된 데이터베이스 컨텍스트, 메타데이터, 타임스탬프, 커스텀 에이전트 요청 사항과 쉽게 결합할 수 있습니다.

이제 BigQuery의 핵심 강점(완전 서버리스 컴퓨팅, 낮은 총소유비용, 기본 제공되는 대규모 추론)을 활용하여 별도의 컴퓨팅 클러스터 없이도 강력한 비정형-정형, 비정형-비정형, 완전한 멀티모달-멀티모달 파이프라인을 빌드, 실행, 제어할 수 있습니다. 특히 중요한 점은 동일한 행에 ObjectRef를 저장함으로써, 추출된 특성 및 주석을 비정형 객체 자체와 직접 결합할 수 있다는 것입니다. 이 결합된 데이터를 대화형 분석 및 AI 에이전트에 직접 활용하면, 비정형 파일을 단순히 정형 형식으로 변환할 때 흔히 발생하는 데이터의 미묘한 뉘앙스와 컨텍스트의 손실을 방지할 수 있습니다. 고객은 이미 이 접근 방식을 사용하여 멀티모달 벡터 검색을 위한 임베딩을 생성하고, 생성형 AI를 사용하여 대규모 분류를 수행하며, 방대한 문서 및 미디어 아카이브에서 정확한 데이터 및 특성 추출 작업을 실행하고 있습니다. 이 모든 작업은 표준 SQL을 통해 이루어집니다.

code_block: <ListValue: [StructValue([('code', 'SELECT\r\nAI.AGG(image_ref, "Summarize the major categories of pictures")\r\nFROM\r\n`bigquery-public-data.cymbal_pets.products`;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa5a0450>)])]>

비정형 데이터에 구조를 부여하는 ObjectRef

ObjectRef는 BigQuery 외부의 객체를 가리키는 사전 정의된 기본 제공 STRUCT 데이터 유형입니다.

code_block: <ListValue: [StructValue([('code', '-- ObjectRef is a special STRUCT in BigQuery \r\nSTRUCT<\r\n uri STRING,\r\n version STRING,\r\n authorizer STRING,\r\n details JSON'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa5a0d50>)])]>

BigQuery는 이러한 포인터를 기존 열과 함께 표준 BigQuery 테이블에 기본적으로 저장함으로써 비정형 파일을 일급 데이터 시민으로 취급합니다. 또한 이 아키텍처는 독립적인 데이터 수명 주기를 지원하므로, GCS 데이터와 BigQuery 테이블이 서로의 시스템에 있는 기본 데이터에 영향을 주지 않고 독립적으로 변경될 수 있습니다.

이 접근 방식은 다음과 같은 강력한 이점을 제공하여 여러 데이터 페르소나를 지원합니다.

제로 카피 아키텍처: 대용량 미디어 파일을 Cloud Storage에 안전하게 보관하고 BigQuery에서 즉시 쿼리하여 데이터 중력 특성을 고려하고 비용이 많이 드는 데이터 중복을 방지합니다.
SQL 및 Python 상호 운용성: 표준 SQL 또는 BigQuery DataFrames를 사용하여 비정형 데이터를 쿼리할 수 있습니다. 중요한 점은 ObjectRef를 BigQuery Python UDF에 전달할 수 있으므로 OpenCV와 같은 오픈소스 Python 라이브러리를 데이터로 직접 가져와 데이터를 이동하지 않고도 커스텀 로직을 실행할 수 있다는 것입니다.
독립적인 수명 주기 및 버전 관리: ObjectRef는 특정 GCS 세대 번호를 추적하여 재현 가능한 추론을 보장합니다. 기본 GCS 파일이 변경되더라도 쿼리는 행이 작성되었을 때 존재했던 파일의 정확한 버전을 계속 참조할 수 있습니다.
통합 거버넌스: BigQuery의 기존 보안 정책과 IAM 제어 기능을 활용하여 정형 열과 관련 비정형 파일 모두에 대한 액세스를 안전하게 보호하고 감사하고 공유할 수 있습니다.

SQL로 충실도 높은 ETL 만들기

ObjectRef를 프리뷰로 출시한 이후 사용자들 사이에서 강력하고 매우 효과적인 패턴이 등장했습니다. 바로 SQL만으로 충실도 높은 ETL 파이프라인을 빌드하는 것입니다.

아래 다이어그램은 BigQuery AI로 비정형 데이터를 처리하고 AI 에이전트로 멀티모달 데이터를 추가로 쿼리하기 위해 ObjectRef를 가져오는 4가지 방법을 보여줍니다.

팀은 BigQuery의 서버리스 아키텍처를 활용하여 AI/ML을 데이터 환경에 직접 통합함으로써 데이터 이동과 추론을 처리하기 위한 별도의 컴퓨팅 클러스터를 운영할 필요가 없어졌습니다. GCS의 비정형 데이터를 표준 BigQuery 열로 관리하면 사용자가 멱등성 파이프라인 빌드, 재현성 보장, 원활한 백필 실행과 같은 핵심 데이터 엔지니어링 권장사항을 이미지, 동영상, 오디오, 문서에 직접 적용할 수 있습니다.

탄탄하게 준비된 데이터를 바탕으로, 이제 팀은 BigQuery 내에서 Gemini를 활용해 충실도 높은 ETL을 실행할 수 있습니다. 특성을 추출하고 비정형 데이터에 주석을 추가하는 동시에 원래 ObjectRef를 동일한 행에 고정하여 이중 레이어 분석을 지원합니다. 정형 출력 데이터는 신속한 필터링, 보고서 작성, BI 대시보드 운영에 활용되며, 이와 연결된 비정형 객체는 심층적이고 컨텍스트가 풍부한 추론을 위해 언제든 활용할 수 있습니다. 예를 들어 고객 통화 녹음 보관 파일에서 감정 점수와 주제 태그를 추출하여 BI 대시보드(정형 레이어)에서 위험 계정을 빠르게 표시할 수 있습니다. 동시에 에스컬레이션 프로세스를 평가하는 대화형 분석 에이전트는 원본 오디오 파일로 원활하게 폴백하여 발신자와 고객 서비스 담당자 간의 상호작용을 분석할 수 있으므로, 비정형 데이터를 정형 데이터로 변환하는 ETL 파이프라인에서 일반적으로 발생하는 중요한 뉘앙스의 손실을 방지할 수 있습니다.

업계 리더의 검증된 사용 사례

“Snap은 커뮤니티의 안전을 최우선 과제로 삼고 있으며, 사용자가 커뮤니티 가이드를 위반하는 콘텐츠에 노출되지 않도록 최선을 다하고 있습니다. 공개 게시물의 샘플을 정기적으로 검토하고 있으며, BigQuery AI와 함께 ObjectRef를 활용하여 단순 무작위 샘플링에서 사후 계층화 샘플링으로 전환했습니다. 이러한 전환을 통해 사람의 검토 프로세스의 효율성이 향상되었으며, 확보된 역량을 새롭게 확장된 워크플로에 재투자하여 잠재적으로 유해한 콘텐츠를 감지하고 해결하는 능력을 더욱 강화할 수 있었습니다.” - Carlos Ortiz, Snap 데이터 과학자

프리뷰 단계에서 이미 다양한 핵심 워크로드에 도입되어 활용되고 있습니다. 고객은 이러한 실험적 파이프라인을 프로덕션으로 성공적으로 전환하여 비정형 데이터를 실행 가능하고 정형화된 인사이트로 변환하고 있습니다.

콘텐츠 검토: 온라인 플랫폼은 BigQuery를 활용하여 멀티미디어 애셋을 표준 원격 분석 데이터와 단일 파이프라인에 통합함으로써 검토 및 안전 관리 성과를 근본적으로 개선합니다.
선제적 위협 감지: 엔터프라이즈 보안팀은 BigQuery를 사용하여 시각적 및 구조적 웹 구성요소를 네트워크 로그와 함께 분석함으로써 선제적 위협 식별을 크게 개선합니다.
인벤토리 규정 준수: 온라인 소매업체는 방대한 이미지 저장소에서 텍스트와 컨텍스트를 직접 추출하여 규제 또는 브랜드 규정 준수 위반 사항을 대규모로 자동 신고합니다.
고객 경험: 서비스 지향 기업은 BigQuery AI를 활용해 지원 담당자와 고객 간의 오디오 상호작용을 분석함으로써 고객 감정을 평가하고 서비스 품질을 개선합니다.

정식 버전의 새로운 기능

Google은 정식 버전 출시를 위해 개발자 환경을 간소화하고 다양한 고객 사용 사례를 지원하는 데 중점을 두었습니다.

유연해진 인증 방식:
- 정식 버전에서는 ObjectRefs에 대한 최종 사용자 인증 정보(EUC) 지원 기능이 추가되었습니다. 이제 사용자는 개인 IAM ID를 직접 사용하여 임시 분석에 필요한 비정형 데이터를 빠르게 쿼리하고 탐색할 수 있습니다.
- 프리뷰 버전에서는 비정형 파일을 쿼리하기 위해 ObjectRef용 BigQuery 연결을 명시적으로 설정해야 했습니다. 이러한 연결 방식은 여전히 완전히 지원되며 안정적인 서비스 계정 기반 프로덕션 파이프라인을 위한 권장사항이기도 하지만, 추가 설정이 필요하다는 점을 충분히 인지하고 있습니다.
Cloud Storage 메타데이터에 대한 통합 지원: 비정형 데이터의 메타데이터는 Google Cloud의 다양한 위치에 존재하며, 이제 ObjectRef가 이 모든 위치를 지원합니다.
- 이미 테이블에 있는 경우: 메타데이터가 현재 BigQuery 객체 테이블, Cloud Storage Insights 데이터 세트에 있든, 아니면 단순히 표준 BigQuery 테이블 내에 원시 문자열 URI로 있든 상관없이 ObjectRef를 원활하게 생성하고 관리하여 기본 데이터를 분석할 수 있습니다.
- 테이블에 없는 경우: 새로운 OBJ.LIST 함수는 Cloud Storage 경로에서 직접 파일을 나열하고 각 파일에 대해 ObjectRef 를 반환하므로 테이블을 먼저 만들 필요가 없습니다.
비교 분석을 위한 배열 지원: 배열에 포함된 ObjectRef를 처리하기 위한 기본 지원 기능이 추가되었습니다. 이를 통해 여러 문서를 서로 비교하거나, 이미지 시퀀스를 분석하거나, 단일 시맨틱 호출에서 항목을 일괄 처리하는 등 완전히 새로운 유형의 워크로드를 처리할 수 있습니다.

실제 사례 보기: 엔드 투 엔드 멀티모달 분석

이러한 정식 버전 업데이트의 강력한 기능을 확인해 보실 수 있도록, 간소화된 SQL 연산자를 사용하여 실제 멀티모달 파이프라인을 빌드하는 방법을 살펴보겠습니다.

1. 충실도 높은 ETL: 콜 센터 오디오 분석

고객 서비스 통화 기록을 분석하려면 오디오 파일을 전문 스크립트 작성 및 자연어 처리 클러스터로 이동해야 했습니다. ObjectRef를 사용하면 오디오 파일을 파싱하여 정형화된 비즈니스 인텔리전스를 추출하고, 이를 표준 관계형 열로 직접 추가할 수 있습니다.

정식 버전으로 제공되는 OBJ.MAKE_REF() 함수를 사용하여 원시 문자열 URI에서 오디오 형식을 자동으로 감지하고, 잘 알려진 사용 사례에 BigQuery의 관리형 AI 함수를 사용합니다. 예를 들어 AI.CLASSIFY()를 사용하여 고객 통화 유형을 분류할 수 있습니다. 기본적으로 BigQuery는 토큰 소비량을 줄이기 위해 AI 함수용 최적화 모드를 사용합니다.

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE TABLE call_center.annotated_call_logs AS\r\nSELECT \r\n customer_id,\r\n call_date,\r\n OBJ.MAKE_REF(audio_uri) as ref,\r\n AI.CLASSIFY(\r\n OBJ.MAKE_REF(audio_uri), [\r\n "Lost or stolen card", \r\n "Declined card payment", \r\n "Activate my card",\r\n "Order physical card",\r\n "Cancel transfer",\r\n "Password or pin forgotten",\r\n "Virtual card not working",\r\n "Card swallowed by ATM",\r\n "Balance not updated after bank transfer",\r\n "Balance not updated after check or cash deposit",\r\n "Extra charge on statement",\r\n "Transfer fee charged"\r\n ]\r\n ) AS customer_issue_type,\r\n FROM \r\n call_center.raw_call_logs;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa5a3dd0>)])]>

이 테이블은 BigQuery 대화형 분석 에이전트를 위한 멀티모달 데이터 소스로 활용될 수 있습니다. 에이전트는 추가 정보가 필요할 때 BigQuery AI 함수를 사용하여 자연어 쿼리를 SQL로 변환하여 오디오 파일을 분석합니다.

BigQuery의 '에이전트(Agents)' 탭으로 이동하여 대화형 분석 에이전트를 생성하고, 멀티모달 테이블을 소스로 선택하세요.

2. 대규모 생성형 AI 필터링: 제품 규정 준수

데이터 엔지니어는 이미지나 문서의 내용을 바탕으로 대규모 데이터 세트를 필터링해야 하는 경우가 많습니다. 이제 리소스를 많이 소모하는 생성형 쿼리를 실행하고 텍스트 출력을 파싱할 필요 없이, WHERE 절에서 표준 SQL과 함께 선언적 AI.IF() 연산자를 기본적으로 사용할 수 있습니다. 기본 최적화 모드는 소비되는 토큰 수를 줄여 워크로드를 더욱 최적화합니다.

code_block: <ListValue: [StructValue([('code', 'SELECT \r\n product_id,\r\n seller_id,\r\nFROM \r\n ecommerce.vendor_uploads\r\nWHERE \r\n upload_date >= CURRENT_DATE() - 1 AND\r\n AI.IF(("Does this product image contain a restricted item or policy violation?", OBJ.MAKE_REF(image_uri)))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa5a0dd0>)])]>

3. 임시 탐색: 제품 카탈로그 보강

위의 예시는 이미 파일 URI를 보유한 테이블에서 시작합니다. 아직 없는 경우 OBJ.LIST는 Cloud Storage 경로를 쿼리 가능한 행으로 변환하며, 각 행의 ref 열에는 ObjectRef가 포함됩니다. 따라서 파일을 나열하고 Gemini로 전송한 후 단일 쿼리에서 유형이 지정된 열을 다시 가져올 수 있습니다. 공개 샘플 버킷에서 사용해 보세요.

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n uri,\r\n size,\r\n updated,\r\n result.animal_type,\r\n result.item_color\r\nFROM (\r\n SELECT\r\n uri,\r\n size,\r\n updated,\r\n AI.GENERATE(\r\n ("What type of animal is this pet product for, and what is its primary color?", ref),\r\n output_schema => \'animal_type STRING, item_color STRING\'\r\n ) AS result\r\n FROM\r\n OBJ.LIST(\'gs://cloud-samples-data/bigquery/tutorials/cymbal-pets/images/*.png\')\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa5a2350>)])]>

4. 다중 객체 추론: 선제적 위협 감지

정식 버전에 네이티브 재열 지원이 추가됨에 따라, 이제 단일 Gemini 호출에 ObjectRef 배열을 전달하여 Gemini를 사용해 여러 파일을 동시에 분석할 수 있습니다.

이를 통해 SQL에서 직접 복잡한 비교 로직을 구현할 수 있습니다. 예를 들어 보안팀은 공식 로그인 페이지의 스크린샷과 새로 발견된 의심스러운 웹페이지의 스크린샷을 Gemini에 동시에 전달하여 피싱 시도를 대규모로 감지할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'SELECT \r\n log_id,\r\n suspect_domain,\r\n assessment.is_phishing,\r\n assessment.visual_discrepancies\r\nFROM (\r\n SELECT \r\n log_id,\r\n suspect_domain,\r\n AI.GENERATE(\r\n (\r\n "Compare these two web UI screenshots. The first is our official, trusted login page. The second is a suspected spoofed page. Identify any visual discrepancies, missing logos, or fake elements, and determine if it is a phishing attempt.", \r\n [OBJ.MAKE_REF(trusted_ui_uri),OBJ.MAKE_REF(suspect_ui_uri)]\r\n ),\r\n output_schema => \'is_phishing BOOLEAN, visual_discrepancies STRING\'\r\n ) AS assessment\r\n FROM \r\n cybersecurity.network_ui_logs\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa5a3a90>)])]>

지금 바로 분석 시작하기

BigQuery ObjectRef가 이제 모든 BigQuery 버전 및 주문형 가격 등급에서 정식 버전으로 제공됩니다.

Cloud Storage 파일에서 머신러닝 추론을 수행하기 위해 복잡하고 파편화된 인프라를 관리하고 계신다면 이제 하나로 통합할 때입니다. 스토리지에 AI를 직접 적용하세요. 기존 데이터 엔지니어링 관행을 활용하여 BigQuery 내에서 직접 강력하고 확장 가능하며 안전한 멀티모달 분석 파이프라인을 빌드해 보세요.

ObjectRef 및 멀티모달 분석을 시작하려면 다음 리소스를 확인하세요.

실무형 튜토리얼을 통해 합성 데이터를 사용하여 이미지 캡션을 생성하고 제품 카테고리를 할당하는 방법을 알아보세요.
Cloud Next에서 비정형 데이터와 정형 데이터 통합, LLM을 사용한 텍스트 생성 및 벡터 검색 수행에 관한 라이브 데모를 시청해 보세요.

Knowledge Catalog의 새로운 자체 학습 컨텍스트 보강 기능 소개

Thu, 29 Oct 2026 19:00:00 +0000

오늘 Google Cloud는 에이전트를 위한 컨텍스트 엔진인 Knowledge Catalog에서 자체 학습 컨텍스트 보강(프리뷰) 기능과 새롭게 단장한 Knowledge Studio 환경(프리뷰)을 출시합니다. Knowledge Catalog의 기존 Gemini 기반 보강 기능을 토대로 발전시킨 자체 학습 보강 기능은 에이전트와 사용자 간 상호작용을 분석합니다. 이를 통해 정보의 공백을 찾아내고, 변화하는 비즈니스 컨텍스트를 정확하게 최신 상태로 유지해 줍니다. Knowledge Studio는 컨텍스트 엔지니어와 데이터 관리자가 대화하듯 데이터 자산을 탐색할 수 있는 새로운 지휘 센터입니다. 이곳에서 시각화된 컨텍스트 그래프를 자유롭게 살펴보고, 제안된 변경 사항이 사용자나 에이전트에게 게시되기 전에 미리 꼼꼼하게 검토할 수 있습니다.

에이전트의 성능은 추론에 활용할 수 있는 조직 전반의 정의, 규칙, 관계, 즉 컨텍스트에 따라 달라집니다. 이것이 바로 컨텍스트 큐레이션이 엔터프라이즈 에이전트 기능에서 가장 중요한 분야 중 하나로 꼽히는 이유입니다. 오늘날 이러한 작업의 대부분은 수작업으로 이루어집니다. 컨텍스트 엔지니어는 에이전트마다 일일이 프롬프트와 매핑을 작성하고, 데이터 관리자는 수천 개의 애셋에 걸쳐 정의를 수동으로 최신 상태로 유지하려 노력합니다. 하지만 에이전트 수가 소수에서 수천 개, 나아가 수백만 개로 늘어나면 이러한 방식은 더 이상 통하지 않게 됩니다.

Knowledge Catalog의 Gemini 기반 자체 학습 보강 기능은 이러한 수동 유지보수를 지속적인 피드백 루프로 전환합니다. 에이전트와 사용자 간의 상호작용을 분석하여 누락되었거나 오래된 컨텍스트를 집어내고, 플레이북, 코드 저장소, 비즈니스 문서에서 검증된 정의를 추출하여 거버넌스가 적용된 재사용 가능한 컨텍스트 세트로 구성합니다. 그런 다음 최적화된 검색을 통해 모든 에이전트는 비대해진 프롬프트와 원시 스키마를 추론하는 대신, 필요한 정확한 컨텍스트를 얻고 조직 전체에 축적된 학습 성과를 같이 누릴 수 있습니다. 내부 벤치마크에 따르면 Knowledge Catalog는 AI 에이전트의 정확성을 약 4배 높이고 지연 시간을 최대 33% 줄이며 토큰 사용량을 최대 75% 줄입니다.

Gemini 기반의 자체 학습 보강 기능으로 컨텍스트를 최신 상태로 유지하세요

Gemini 에이전트에게 "지난 분기 EMEA 지역의 순매출은 얼마였나요?"라며 간단한 질문을 던지는 상황을 떠올려 보세요. 이 질문에 정확하게 답하려면 회사가 순매출을 어떻게 정의하는지, 어떤 테이블에 예약이 포함되어 있는지, 어떻게 조인하는지 알아야 하지만, 이러한 정보는 일반적으로 Google Docs의 재무 플레이북, GitHub의 데이터 모델, Confluence 페이지에 흩어져 있습니다. 정적 카탈로그 방식에서는 에이전트가 적절한 데이터를 효과적으로 쿼리할 수 있도록, 주제별 전문가가 비즈니스 정의, 측정항목 및 기타 컨텍스트를 사전에 수동으로 캡처하고 업데이트해야 합니다. 하지만 현실적으로 전문가가 모든 자산을 문서화할 시간적 여유가 있는 경우는 드뭅니다. 또한 재무팀이 다음 분기에 파트너 크레딧 처리 방식을 수정하는 순간, 기존의 정적 정의는 시대에 뒤처지게 되고 하드코딩된 수식을 사용하는 모든 에이전트가 잘못된 답변을 내놓기 시작합니다.

Knowledge Catalog의 보강 기능은 팀의 모든 문서, 저장소, 테이블 등 비즈니스 지식이 이미 보관되어 있는 곳에서 작동합니다. 퍼스트 파티 및 서드 파티 소스의 정형 데이터와 Cloud Storage, Google Workspace, GitHub, Confluence, SharePoint의 비정형 데이터에 연결됩니다. 이 기능은 사용자를 대신해 비즈니스 지식을 찾아내고 추출, 조합 및 유지 관리합니다. 또한 플레이북이나 위키와 같은 비정형 소스와 그 컨텍스트를 테이블 및 스키마와 같은 Knowledge Catalog의 정형 메타데이터에 연결함으로써, 정형 데이터의 발견 가능성과 활용도를 획기적으로 높여 줍니다. 주문형 또는 일정에 따라 비즈니스 정의, 테이블 및 열 설명, 조인 관계, 표준 쿼리, 작업별 에이전트 요청 사항을 제안하며, 각 제안에는 소스 인용과 신뢰도 점수가 포함됩니다. 실행할 때마다 소스에서 변경된 사항을 감지하고, 오래된 정의를 폐기하고, 검토가 필요한 충돌을 표시합니다.

사용자와 에이전트의 상호작용을 모두 학습합니다. Gemini 에이전트, BigQuery의 대화형 분석 또는 커스텀 에이전트의 상호작용 추적을 분석하도록 보강 기능을 설정할 수 있습니다. 이 과정에서 개인 식별 정보(PII)가 수정되며, 모호한 열 조회, 근거 없는 측정항목, 누락된 정의 또는 사용자가 같은 질문을 반복하는 등 에이전트가 어려움을 겪는 지점을 정확하게 찾아낼 수 있습니다. 그런 다음 신뢰할 수 있는 답변을 찾아 수정안을 마련함으로써, 동일한 실수가 반복되지 않도록 합니다. 컨텍스트 엔지니어링은 이와 같은 방식으로 수백만 건의 에이전트 상호작용에 대응하며, 전문가가 변경 사항을 처음부터 직접 작성할 필요 없이 변경 사항을 검토하는 데 집중할 수 있도록 지원합니다.

연결된 소스, 평가, 자체 학습을 통한 보강 작업 설정하기

자동화가 곧 제어권 포기를 의미하진 않습니다. 언제든지 자동 게시 기능을 켜거나 끌 수 있으며, 제안된 변경사항이 자동으로 승인되는 기준이 될 정확한 신뢰도 점수(예: 85%)를 직접 설정할 수 있습니다. 설정한 기준점 미만의 모든 항목과 삭제와 같은 민감한 업데이트는 데이터 관리자가 승인, 수정 또는 거부할 수 있도록 변경 요청으로 전환됩니다. 또한 직접 만든 평가 세트를 활용하여 제안된 업데이트를 엔드 투 엔드로 테스트할 수도 있습니다. 모든 변경사항은 전체 출처와 함께 기록되며, 이전 상태로 되돌릴 수 있습니다. 물론 Google은 모델 학습에 고객 데이터를 사용하지 않습니다.

게시 전 보강 제안, 신뢰도 점수, 변경사항 차이 검토하기

컨텍스트 세트로 각 대상에 적합한 컨텍스트를 설정하세요

엔터프라이즈 컨텍스트 그래프는 설계 특성상 그 범위가 매우 방대하지만, 에이전트와 사용자가 특정 작업을 수행할 때는 대개 그래프 전체가 아닌 신뢰할 수 있는 적절한 세그먼트만 있으면 됩니다. Knowledge Catalog는 컨텍스트 세트를 통해 이를 달성합니다. 컨텍스트 세트는 특정 도메인, 팀, 에이전트 또는 최종 사용자 그룹에 대한 정의, 측정항목, 조인 로직, 표준 쿼리를 포함하는 컨텍스트 그래프 중 선별되어 관리되는 하위 집합입니다. 예를 들어 영업 에이전트는 영업 컨텍스트 세트에 연결하고, 재무 분석가의 어시스턴트는 재무 컨텍스트 세트에 연결하여 사용할 수 있습니다. '순매출'은 그룹마다 충분히 다른 의미로 정의될 수 있으므로, 모든 도메인은 동일한 카탈로그 내에서 각자 고유한 정의를 유지합니다. 하지만 에이전트가 단일 세트에만 국한될 필요는 없습니다. Knowledge Catalog의 검색 기능을 활용하면 에이전트가 수행 중인 작업에 가장 적합한 컨텍스트 세트를 동적으로 찾아낼 수 있습니다.

컨텍스트 세트는 기본 제공되는 데이터 거버넌스와 세분화된 액세스 제어도 제공합니다. 각 컨텍스트 세트에 대한 액세스는 IAM으로 관리되므로, 관리자가 어떤 에이전트와 사용자가 이를 읽고 사용하거나 편집할 수 있는지 결정합니다. 에이전트는 사용 권한이 있는 세트에서만 컨텍스트를 검색하며, 기본 데이터에 대한 액세스는 기존 권한을 계속 따릅니다. 모든 업데이트는 추적 및 되돌리기가 가능합니다. 또한 컨텍스트 세트는 Open Knowledge Format(OKF)을 기반으로 하므로, OKF 번들을 가져와 컨텍스트 세트로 변환하거나 다시 OKF로 내보낼 수 있어 컨텍스트의 이식성이 유지됩니다.

Approved enrichments published to a governed context set

Knowledge Studio에서 탐색하고 제어하세요

이러한 모든 기능은 에이전트를 위한 컨텍스트를 선별하고 관리하는 컨텍스트 엔지니어와 데이터 관리자를 위해 새롭게 빌드된 Knowledge Catalog 환경에 통합되어 있습니다.

Knowledge Studio에서 컨텍스트 그래프를 시각적으로 탐색하기

새로운 Knowledge Studio는 Knowledge Catalog를 정적인 인벤토리 저장소에서 대화형 지휘 센터로 전환해 다음과 같은 기능을 제공합니다.

한눈에 확인하는 컨텍스트 범위: 운영 데이터베이스와 웨어하우스부터 시맨틱 모델, 컨텍스트 세트, 문서까지 크로스 클라우드 데이터 자산의 시각적 맵을 탐색할 수 있습니다.
대화하듯 탐색하는 컨텍스트: 자연어로 비즈니스 질문을 던지고, 엔터프라이즈 컨텍스트 그래프 전반에 걸쳐 관계를 넘나들며, 에이전트가 메타데이터를 분석하고 추론하는 방식을 확인합니다.
한곳에서 검토하고 검증하는 보강: 제안된 각 변경사항과 소스 인용, 신뢰도 점수를 꼼꼼하게 확인합니다. 실제 질문을 바탕으로 컨텍스트 세트를 테스트하고, 소프트웨어 방식의 버전 제어 기능으로 변경 요청을 승인, 수정 또는 롤백할 수 있습니다.
보강 실행 모니터링: 각 보강 작업의 일정, 결과, 토큰 사용량, 실행 시간을 추적하고 실행이 완료되면 이메일로 알림을 받습니다.

시작하기

데모 보기: Knowledge Catalog의 자체 학습 보강이 에이전트를 그라운딩하는 방법

이러한 기능은 앞으로 몇 주에 걸쳐 고객에게 출시될 예정입니다. 지금 가입하여 즉시 액세스 권한을 요청하고, 문서에서 단계별 안내를 확인하세요.

Python UDF 로깅을 활용하여 파이프라인 모니터링 가능성을 확보하는 방법

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

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

BigQuery의 Python 사용자 정의 함수(UDF)에서 새롭게 사용할 수 있는 로깅 기능을 소개합니다. 이제 개발자는 BigQuery UDF 내에서 Python의 표준 로깅 라이브러리를 직접 사용하여 구조화된 로그를 Cloud Logging으로 원활하게 내보낼 수 있습니다. 별도의 외부 플러그인이나 커스텀 커넥터는 필요하지 않습니다.

UDF 로깅은 광범위한 운영 모니터링 및 디버깅 워크플로를 지원하지만, 본 문서에서는 이 기능을 활용하여 내결함성과 복원력이 뛰어난 데이터 파이프라인을 구축하는 사례를 보여드리겠습니다. 아래 예시에서는 쿼리 실행 중에 행 단위로 진단 원격 분석 데이터를 캡처합니다. 이를 통해 팀은 전체 워크로드를 중단하지 않고도 SQL을 통해 문제가 발생한 레코드를 쉽게 찾아내고, 실시간 알림을 트리거하며, 문제를 분류할 수 있습니다.

본 게시물에서는 Python UDF 로깅을 시작하는 방법을 알아보고, 이커머스 이벤트 수집 파이프라인을 실질적인 엔드 투 엔드 예시로 살펴보겠습니다.

아키텍처 개요

워크플로는 세 단계로 구성됩니다.

인라인 검증: Python UDF가 수신되는 JSON 페이로드를 파싱합니다. 유효한 레코드는 대상 테이블로 전달되고, 손상되었거나 규정을 준수하지 않는 행은 logging.error()를 트리거하고 NULL을 반환하여 쿼리 실패를 방지합니다.
실시간 알림: 오류율이 SLA 기준점을 초과하면 Cloud Monitoring 로그 기반 측정항목을 통해 팀에 알림이 전송됩니다.
SQL 분류 및 재처리: 데이터 엔지니어는 연결된 _AllLogs 뷰를 통해 BigQuery에서 표준 SQL로 격리된 페이로드를 쿼리하고, 근본 원인을 진단한 후에 복구된 데이터를 다시 수집합니다.

본 시연에서는 데이터 검증 및 변환에 Python을 사용하지만, SQL 기반 변환을 수행하는 파이프라인에도 Python 기반 로깅 및 검증을 원활하게 통합할 수 있습니다.

빠른 시작 둘러보기: 단계별 안내

1단계: 일반 Python UDF 만들기

이 UDF는 JSON을 파싱하고 필수 필드가 있는지 확인합니다. 파싱에 실패하거나 필수 키가 누락된 경우 구조화된 진단 JSON을 로깅하고 NULL을 반환합니다.

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE FUNCTION `YOUR_PROJECT.YOUR_DATASET.safe_parse_json`(\r\n raw_payload STRING,\r\n required_key STRING\r\n)\r\nRETURNS STRING\r\nLANGUAGE python\r\nOPTIONS (entry_point=\'safe_parse_json\', runtime_version=\'python-3.11\')\r\nAS r\'\'\'\r\nimport json\r\nimport logging\r\n\r\ndef safe_parse_json(raw_payload, required_key):\r\n if not raw_payload or raw_payload.strip() == "":\r\n logging.warning(json.dumps({"error_type": "EMPTY_PAYLOAD"}))\r\n return None\r\n\r\n try:\r\n data = json.loads(raw_payload)\r\n if required_key and (required_key not in data or data[required_key] is None):\r\n logging.error(json.dumps({\r\n "error_type": "MISSING_REQUIRED_KEY",\r\n "missing_key": required_key,\r\n "raw_payload": raw_payload[:200]\r\n }))\r\n return None\r\n return json.dumps(data)\r\n\r\n except Exception as e:\r\n logging.error(json.dumps({\r\n "error_type": "JSON_SYNTAX_ERROR",\r\n "error_message": str(e),\r\n "raw_payload": raw_payload[:200]\r\n }))\r\n return None\r\n\'\'\';'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb0be7d0>)])]>

2단계: 로깅을 사용 설정한 상태로 수집 실행하기

이 예시에서는 수신되는 사용자 작업(클릭, 조회, 결제)을 처리하는 이커머스 이벤트 수집 파이프라인을 시뮬레이션합니다. 목표는 유효한 이벤트를 추출하여 정제된 분석 테이블에 저장하는 동시에 손상되거나 스키마가 누락된 페이로드를 적절하게 격리하는 것입니다.

SET @@udf.properties를 사용하여 세션에서 로깅을 사용 설정하세요.

code_block: <ListValue: [StructValue([('code', 'SET @@udf.properties = JSON \'{"enableDebugOutput": true}\';\r\n\r\nCREATE OR REPLACE TABLE `YOUR_PROJECT.YOUR_DATASET.clean_events` AS\r\nWITH sample_events AS (\r\n SELECT \'evt_001\' AS event_id, \'{"user_id": "usr_101", "event": "click", "amount": 25.5}\' AS raw_data UNION ALL\r\n SELECT \'evt_002\' AS event_id, \'corrupted_json{\' AS raw_data UNION ALL -- Syntax error\r\n SELECT \'evt_003\' AS event_id, \'{"event": "view"}\' AS raw_data UNION ALL -- Missing required user_id\r\n SELECT \'evt_004\' AS event_id, \'{"user_id": "usr_102", "event": "checkout", "amount": 99.0}\' AS raw_data\r\n),\r\nparsed_events AS (\r\n SELECT\r\n event_id,\r\n `YOUR_PROJECT.YOUR_DATASET.safe_parse_json`(raw_data, \'user_id\') AS validated_json\r\n FROM sample_events\r\n)\r\nSELECT\r\n event_id,\r\n JSON_VALUE(validated_json, \'$.user_id\') AS user_id,\r\n JSON_VALUE(validated_json, \'$.event\') AS event_name,\r\n \'VALID\' AS status\r\nFROM parsed_events\r\nWHERE validated_json IS NOT NULL;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb0bffd0>)])]>

수집 결과

event_id	user_id	event_name	상태
`evt_001`	`usr_101`	`클릭`	`유효함`
`evt_004`	`usr_102`	`결제`	`유효함`

쿼리는 중단 없이 원활하게 실행되며 문제가 있는 행(2 및 3)은 Cloud Logging으로 라우팅됩니다.

3단계: Cloud Logging에서 실시간 알림 설정하기

잘못된 형식의 페이로드가 허용 가능한 기준점을 초과하는 즉시 사고 긴급 대응팀에 알리도록 알림을 구성할 수 있습니다.

Google Cloud 콘솔에서 설정(원클릭)

Google Cloud 콘솔에서 로그 탐색기를 엽니다.
UDF 루틴에 대한 로그 필터를 붙여넣습니다.

code_block: <ListValue: [StructValue([('code', 'resource.type="bigquery.googleapis.com/ManagedRoutineInvocation"\r\nseverity>=ERROR'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb0bf710>)])]>

3. 상단 작업 모음에서 알림 만들기를 클릭합니다.

4. 알림 채널(예: Slack, PagerDuty, 이메일)을 설정하고 정책을 저장합니다.

4단계: BigQuery 로그 분석으로 문제가 있는 행 분류하기

"참고: BigQuery SQL을 통해 로그를 쿼리하려면 Cloud Logging 버킷에서 BigQuery 로그 분석을 사용 설정하고 연결된 데이터 세트를 만들어야 합니다."

연결된 _AllLogs 뷰를 통해 BigQuery SQL을 사용하여 격리된 페이로드를 쿼리하세요.

code_block: <ListValue: [StructValue([('code', "SELECT\r\n timestamp,\r\n severity,\r\n JSON_VALUE(json_payload.error_type) AS error_type,\r\n JSON_VALUE(json_payload.missing_key) AS missing_key,\r\n JSON_VALUE(json_payload.raw_payload) AS raw_payload\r\nFROM `YOUR_PROJECT.YOUR_LOGS_LINKED_DATASET._AllLogs`\r\nWHERE log_name LIKE '%managed_routine_output%'\r\nORDER BY timestamp DESC\r\nLIMIT 10;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb0bdc90>)])]>

로그 분석 출력

타임스탬프	심각도	error_type	missing_key	raw_payload
`2026-09-17 18:35:50`	`오류`	`MISSING_REQUIRED_KEY`	`user_id`	`{"event": "view"}`
`2026-09-17 18:35:50`	`오류`	`JSON_SYNTAX_ERROR`	null	`corrupted_json{`

데이터 복구

전체 원시 페이로드가 Cloud Logging에 보존되므로 업스트림 데이터가 수정되면 SQL을 사용하여 격리된 레코드를 직접 복구할 수 있습니다.

code_block: <ListValue: [StructValue([('code', "-- 1. Replay and recover quarantined rows from Cloud Logging sink table\r\nINSERT INTO `YOUR_PROJECT.YOUR_DATASET.clean_events` (event_id, user_id, event_name, status)\r\nSELECT\r\n 'evt_003_recovered' AS event_id,\r\n 'default_user' AS user_id, -- Apply fallback default for the missing field\r\n JSON_VALUE(JSON_VALUE(json_payload.raw_payload), '$.event') AS event_name,\r\n 'RECOVERED' AS status\r\nFROM `YOUR_PROJECT.YOUR_LOGS_LINKED_DATASET._AllLogs`\r\nWHERE JSON_VALUE(json_payload.error_type) = 'MISSING_REQUIRED_KEY'\r\n\r\n-- 2. Inspect the final clean destination table\r\nSELECT event_id, user_id, event_name, status\r\nFROM `YOUR_PROJECT.YOUR_DATASET.clean_events`\r\nORDER BY event_id;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb0bcb50>)])]>

최종 `clean_events` 테이블 결과:

event_id	user_id	event_name	상태
`evt_001`	`usr_101`	`클릭`	`유효함`
`evt_004`	`usr_102`	`결제`	`유효함`
evt_003_recovered	default_user	조회	복구됨

이제 모든 유효한 데이터와 복구된 데이터가 데이터 손실 없이 프로덕션 테이블에 통합됩니다.

기타 사용 사례

섀도 실행 및 안전한 마이그레이션: UDF에서 기존 비즈니스 로직과 새로운 비즈니스 로직을 나란히 실행합니다. 기존 결과를 프로덕션 환경에 반환하는 동시에 계산 결과 차이를 Cloud Logging에 로깅합니다.
개인 식별 정보 수정 감사: BigQuery에 기록하기 전에 민감한 토큰(예: 사회보장번호(SSN) 또는 계좌 번호)을 마스킹하고 익명화된 감사 이벤트를 Cloud Logging으로 내보냅니다.
ML 추론 드리프트: 내장된 점수 로직에서 어휘에 없는 입력 또는 낮은 모델 신뢰도가 발견되면 경고를 로깅합니다.

권장사항

디버그 출력 사용 설정: 로그를 캡처하려는 세션에 SET @@udf.properties = JSON '{"enableDebugOutput": true}';를 포함하세요.
로그에 민감한 정보 포함 금지: Cloud Logging은 로깅 뷰어 권한이 있는 사용자에게 표시됩니다. 로그인 사용자 인증 정보나 보안 비밀은 로깅하지 마세요.
비용 관리: 처리량이 많은 파이프라인에서는 선택적으로 로깅하여 로깅 수집 볼륨을 관리하세요. 예를 들어, 오류가 발생한 경우에만 로깅하거나 샘플링을 적용할 수 있습니다.

시작하기

Gemini를 위한 혁신적인 기능으로 에이전트 시대에 맞는 경계 없는 Lakehouse 도입

Thu, 22 Oct 2026 08:00:00 +0000

기업이 AI 사용을 실험적인 챗봇에서 자율형 에이전트로 전환함에 따라, 기업의 각 팀은 여러 클라우드, SaaS 플랫폼, 온프레미스 시스템에 분산된 데이터에 액세스하고 이를 바탕으로 추론하는 과정에서 심각한 병목 현상을 겪고 있습니다. AI 에이전트를 진정한 작업 시스템으로 전환하려면 조직은 데이터 이동으로 인한 보안 위험 없이 페타바이트 규모의 추론을 처리할 수 있는 기반이 필요합니다. 지난주에 열린 Gemini at Work 이벤트에서 Google은 Gemini가 비즈니스 워크플로를 완전히 바꾸는 데 어떤 도움이 되는지 발표하는 시간을 가졌습니다. 기업에서 보유한 데이터를 활용해 에이전트의 역량을 강화할 수 있도록, Gemini와 경계 없는 Lakehouse의 통합이라는 새로운 기능을 자세히 알아보겠습니다. 이러한 통합을 통해 데이터 환경 전반에서 가동되는 에이전트를 빌드하고, 보호하고, 확장할 수 있습니다.

Gemini를 통해 Google Cloud 외부에 있는 데이터에 액세스하기

경계 없는 Lakehouse의 진정한 가치는 조직의 업무 방식을 완전히 바꿀 에이전트를 빌드하여 실현되며, 이 과정에서 Gemini가 진입점 역할을 합니다. Gemini 통합 기능이 새롭게 지원되므로, 사전 구성되거나 경계 없는 Lakehouse에 저장된 데이터가 이제 Gemini에 직접 통합됩니다. 현재 프리뷰 버전으로 제공되는 이 기능을 사용하면 Gemini에서 바로 Lakehouse 카탈로그 제휴를 통해 Databricks Unity Catalog 또는 Snowflake Horizon과 같은 새로운 데이터 소스에 대한 액세스 권한을 설정할 수 있습니다.

이제 비즈니스 사용자는 자연어를 사용해 여러 클라우드에 있는 레코드를 쿼리할 수 있으며, AI 에이전트는 동일한 데이터를 기반으로 추론하고 코드를 작성할 수 있습니다. 그리고 이 모든 작업이 데이터를 이동하지 않고도 이루어집니다. 경계 없는 Lakehouse 전반에서 AI 에이전트를 직접 컨텍스트화하면 조직의 AI 도입을 가속화하는 동시에 중요한 정보에 대한 액세스 절차를 간소화할 수 있습니다.

비즈니스 사용자가 호출한 Gemini 에이전트는 BigQuery 및 Databricks Unity Catalog에 있는 데이터에 액세스하여 포괄적인 보고를 제공하고 자연어를 사용해 유용한 정보를 얻을 수 있습니다.

경계 없는 Lakehouse의 고급 기능

이번에 선보이는 새로운 기능인 Gemini와의 기본 통합 외에도, 올해 초에 도입된 다음과 같은 여러 기능이 이제 정식 버전으로 제공된다는 소식을 전해드립니다. 이를 통해 경계 없는 Lakehouse로 데이터 기반을 강화할 수 있습니다.

AWS 및 Azure용 Cross-Cloud Interconnect 및 크로스 클라우드 캐싱 지원
Apache Iceberg V3 사양에 대한 BigQuery 지원
BigQuery 및 Managed Service for Apache Spark 모두에 지원되는 Apache Iceberg 테이블의 읽기-쓰기 상호 운용성
Lakehouse 런타임 제휴를 사용한 AWS Glue, Databricks Unity Catalog, Snowflake Horizon Catalog와의 양방향 캐싱
Knowledge Catalog와의 통합
Salesforce, SAP, Workday, 그리고 이제 Confluent Tableflow와의 제로 카피 데이터 통합
Dataflow를 사용하여 Lakehouse 콘솔을 통해 Databricks Delta Lake 자산 동기화

지금부터 자세히 살펴보겠습니다.

페타바이트 규모의 성능과 추론

에이전트 컨텍스트 윈도우는 일반적으로 한 번에 수백 킬로바이트를 수집하는 것으로 제한되지만, 엔터프라이즈 워크플로는 간혹 클라우드 전반에서 페타바이트 규모의 데이터를 조인하는 경우가 있습니다. 제품 및 고객 데이터와 같은 여러 소스의 데이터를 CRM 클라우드 및 웨어하우스 원격 분석에 결합해야 하는 에이전트 네이티브 데이터 플랫폼은 대규모 데이터를 처리할 수 있어야 합니다. MCP를 통해 이 작업을 수행하면 컨텍스트 윈도우와 페이로드 크기로 인해 메가바이트 규모로 제한됩니다. 데이터 및 AI 스택의 모든 레이어에서 통합되는 경계 없는 Lakehouse는 엔터프라이즈급 확장성을 제공하여, 에이전트가 페타바이트 규모의 데이터를 로컬에 저장된 것과 유사한 성능으로 추론할 수 있도록 합니다.

네트워킹 계층에서 Cross-Cloud Interconnect와 크로스 클라우드 캐싱은 AWS 및 Azure로 연결되는 처리량이 높고 지연 시간이 짧은 경로를 제공하여 가변적인 이그레스 비용을 없앱니다. 에이전트가 Amazon Azure Data Lake Storage의 Iceberg 테이블을 BigQuery의 데이터와 조인할 경우, 캐시되지 않은 모든 바이트를 스캔할 때마다 클라우드 경계를 넘나들기 때문에 결국 네트워크가 작업 처리 속도를 좌우하게 됩니다. Cross-Cloud Interconnect는 Google Cloud와 AWS 또는 Azure 간의 전용 비공개 연결을 Lakehouse에 제공하며, 연결당 10Gbps 또는 100Gbps의 속도를 지원합니다. Lakehouse 쿼리는 공개 인터넷이 아닌 이 연결을 통해 이동하므로 지연 시간이 짧고 예측 가능합니다. 크로스 클라우드 캐싱은 Google Cloud 내부에서 반복 읽기를 지원하므로 에이전트는 다른 클라우드의 데이터를 마이그레이션하지 않고도 쿼리할 수 있습니다.

경계 없는 Lakehouse에는 Iceberg 메타데이터를 쿼리 엔진 내에 통합하기 위한 몇 가지 주요 최적화 기능이 포함되어 있습니다. 이제 BigQuery에서 바이너리 삭제 벡터 및 정렬 순서를 비롯한 Apache Iceberg V3 사양을 지원합니다. 이러한 기능을 통해 엔진은 전체 데이터 파일을 다시 작성할 필요 없이 행 수준 업데이트와 삭제를 더 효율적으로 처리할 수 있습니다. 또한 새로운 FlatBuffers 기반 Parquet 리더와 병렬화된 I/O로 BigQuery의 실행 엔진을 업그레이드하여 CPU 오버헤드와 직렬화 병목 현상을 줄이고, 개방형 형식과 기본 스토리지 간의 성능 격차를 좁혔습니다.

이러한 기능은 에이전트 워크로드를 지원하도록 설계된 쿼리 엔진의 최근 성능 혁신을 기반으로 합니다. 에이전트 워크로드는 종종 대량으로 발생하며 작은 쿼리를 빠르고 비용 효율적으로 처리해야 합니다. BigQuery의 유연한 확장 및 기록 기반 최적화를 사용하면 Apache Iceberg와의 개방성을 유지하면서 확장 가능하고 효율적인 에이전트 워크로드를 실행할 수 있습니다.

한편, BigQuery와 Managed Service for Apache Spark 양쪽 모두에서 Apache Iceberg 테이블에 대한 읽기-쓰기 상호 운용성을 지원하므로 모든 데이터팀이 Google Cloud Storage에서 동일한 Iceberg 테이블을 쉽게 사용할 수 있습니다. 이렇게 수직적으로 최적화된 스택은 BigQuery와 Lightning Engine의 강력한 기능을 활용하여 데이터를 이동하지 않고도 데이터를 활성화하므로 에이전트를 더 빠르고 비용 효율적으로 사용할 수 있습니다. Lakehouse에서 더 심층적으로 분석하고자 할 경우 BigQuery의 Iceberg에 대한 그래프 지원을 활용하면 관계 네트워크(예: 공급망)를 개방형 테이블 데이터 세트에서 직접 분석할 수 있습니다.

에이전트를 위한 포괄적인 컨텍스트와 데이터 액세스

액세스할 수 있는 컨텍스트가 있어야 AI 에이전트도 스마트한 기능을 발휘할 수 있습니다. 경계 없는 Lakehouse는 할루시네이션을 방지하고 메타데이터 레이어의 정확성을 개선하기 위해 Lakehouse 런타임 카탈로그를 사용하여 엔터프라이즈 데이터를 통합합니다. Apache Iceberg REST 카탈로그를 기반으로 AWS Glue, Databricks Unity Catalog, Snowflake Horizon Catalog와 양방향 카탈로그 제휴를 제공합니다. Lakehouse 런타임 카탈로그에는 새로운 표준 Hive Metastore 호환 엔드포인트도 포함되어 있으므로 Apache Spark, Trino, Presto와 같은 엔진이 아키텍처 변경 없이 메타데이터를 검색할 수 있습니다.

경계 없는 Lakehouse는 분산된 데이터 자산의 색인을 자동으로 생성하는 Knowledge Catalog와도 직접 통합됩니다. 따라서 에이전트가 Cloud Storage의 비정형 데이터를 비롯한 전체 엔터프라이즈 코퍼스를 추론하는 데 필요한 정확한 비즈니스 메타데이터와 시맨틱 정의를 제공합니다. 이를 통해 에이전트는 토큰 비용을 제어하면서 정확성을 유지하는 데 필요한 만큼의 컨텍스트를 확보할 수 있으므로 작업자가 지능적이고 지속 가능한 에이전트 전략을 개발하는 데 도움이 됩니다.

경계 없는 Lakehouse는 Salesforce, SAP, Workday와 같은 SaaS 애플리케이션과 제로 카피 데이터 통합을 제공하고 대형 파트너 생태계와 통합하여 Knowledge Catalog에서 엔터프라이즈 데이터를 캡처하고 에이전트를 위한 단일 컨텍스트 엔진 역할을 합니다. 현재 Google Cloud는 이제 정식 버전으로 제공되는 Confluent Tableflow의 새로운 통합을 통해 파트너 생태계를 확장하고 있습니다. 이 통합은 Lakehouse 런타임 카탈로그와 동기화되므로 생성되는 Iceberg 테이블이 복사나 추가 ETL 없이 BigQuery에 직접 표시됩니다.

마지막으로, Databricks 중심 저장소를 사용하는 조직은 이제 Dataflow를 사용하여 Lakehouse 콘솔을 통해 Delta Lake 자산을 Lakehouse로 쉽게 가져오고, 변환하고, 동기화할 수 있습니다.

손쉬운 현대화

2025년 초부터 Apache Iceberg를 사용하는 고객이 3배 이상 증가했으며, Google Cloud의 경계 없는 Lakehouse를 활용하여 데이터 사용 환경을 빌드하는 기업은 다음과 같은 상당한 효과를 보고 있습니다.

Etsy는 경계 없는 Lakehouse로 3페타바이트를 통합하여 데이터를 이동 없이 조인함으로써 파이프라인 쿼리 속도를 60% 향상했습니다.
Commerzbank는 분산된 원시 데이터 환경을 거버넌스가 적용되고 에이전트가 바로 활용 가능한 데이터 액세스 환경으로 전환했습니다.
Hightouch는 경계 없는 Lakehouse와 직접 통합하여 각 팀이 개방형 Iceberg Lakehouse에서 바로 마케팅 업무 역량을 강화하고 Google Cloud 생태계 전반에서 이러한 데이터를 활성화할 수 있게 되었습니다.
Roundel은 경계 없는 Lakehouse를 통해 Target Product Ads 기술 스택을 처음부터 끝까지 철저히 현대화하여 데이터 수집, 처리, 측정 파이프라인을 완전히 재구축했습니다.

Borderless Lakehouse로 전환할 준비가 된 조직이라면 어렵지 않게 시작할 수 있습니다. 현재 기존 Dataproc Metastore를 사용 중인 조직을 위해, 이제 서버리스 Lakehouse 런타임 카탈로그로 자동 마이그레이션하는 경로를 제공하며 다운타임이 발생하지 않습니다. 이렇게 하면 기존 스키마와 계보를 보존하면서 경계 없는 Lakehouse의 AI 지원 기능을 활용할 수 있으므로 인프라 관리를 멈추고 에이전트를 활성화할 수 있습니다.

지금 바로 Borderless Lakehouse 빌드 Codelab을 시작하거나 Google 웹사이트를 방문하여 자세히 알아보세요.

개방형 표준으로 간편해지는 크로스 클라우드 대화형 분석

Thu, 22 Oct 2026 02:00:00 +0000

대부분의 조직에서 데이터는 어디에나 존재합니다. 엔지니어링팀이 규모를 키우고 워크로드에 특화된 플랫폼을 도입함에 따라 엔터프라이즈 데이터는 자연스럽게 여러 클라우드와 운영 시스템으로 분산됩니다. 분석 및 AI 이니셔티브에 조직 전체의 컨텍스트가 필요한 경우, 관련 팀은 일반적으로 복잡한 추출 파이프라인을 빌드하여 데이터를 중앙 저장소에 복사하거나 데이터가 파편화된 상태로 보고되는 상황을 감수해야 하는 어려운 선택의 기로에 직면합니다.

기존 아키텍처는 원격 데이터 세트를 중앙 스테이징 웨어하우스에 복사하는 예약된 추출 파이프라인을 통해 이러한 데이터 파편화 문제를 해결합니다. 이러한 방식은 동기화 지연을 유발하고, 지속적인 스토리지 비용을 발생시키며, 가변적인 네트워크 이그레스 수수료를 초래합니다. 업스트림에서 스키마가 변경되면 파이프라인이 중단되고, 팀은 동기화되지 않은 대시보드에서 측정항목을 조정하는 데 몇 시간을 허비하게 됩니다.

BigQuery와 Google Cloud의 경계 없는 Lakehouse는 개방형 Apache Iceberg REST 카탈로그 사양을 기반으로 이러한 문제를 해결할 수 있는 간소화된 방법을 제공합니다. 데이터를 컴퓨팅 엔진으로 이동하는 대신 Google Cloud 컴퓨팅과 생성형 AI를 데이터에 직접 적용하여 Databricks, Snowflake, AWS Glue에서 데이터를 인플레이스로 쿼리할 수 있습니다.

이 게시물에서는 BigQuery 페더레이션을 위해 Databricks Unity Catalog를 구성하는 방법(AWS Glue 및 Snowflake 설정 부록 참조), 세 개의 외부 카탈로그 모두에서 데이터를 조인하는 단일 쿼리를 실행하는 방법, BigQuery의 대화형 분석을 사용하여 자연어로 통합 데이터를 탐색하는 방법을 단계별로 살펴봅니다.

그림 1: BigQuery는 Lakehouse를 통해 외부 Apache Iceberg REST 카탈로그 전반의 메타데이터를 통합하여, 데이터 마이그레이션 없이도 즉시 대화형 분석을 수행할 수 있게 해줍니다.

경계 없는 레이크하우스 아키텍처

이 솔루션은 Lakehouse 런타임 카탈로그를 사용하여 다른 클라우드 제공업체의 메타데이터를 동기화하므로 데이터를 마이그레이션하지 않고도 Apache Iceberg REST 카탈로그 엔드포인트를 통해 BigQuery 또는 외부 오픈소스 엔진으로 데이터를 쿼리할 수 있습니다. Databricks Unity Catalog, Snowflake Horizon Catalog, AWS Glue Data Catalog는 개방형 Apache Iceberg REST 카탈로그 사양을 지원하므로 세 플랫폼 모두에 일관된 연결 패턴을 적용할 수 있습니다.

페더레이션 쿼리를 실행하면 Lakehouse 런타임 카탈로그가 메타데이터 동기화를 스토리지 액세스와 분리합니다.

메타데이터 동기화: Lakehouse 런타임 카탈로그는 정의된 새로고침 일정에 따라 원격 카탈로그에서 스키마, 스냅샷 포인터, 테이블 정의를 주기적으로 동기화합니다.
직접 스토리지 액세스: 쿼리 런타임 중에 호환되는 엔진은 원격 플랫폼에서 발급한 임시 사용자 인증 정보를 사용하여 Amazon S3와 같은 원격 객체 스토리지에서 직접 Parquet 데이터 파일을 읽습니다.

모든 쿼리 처리는 BigQuery 또는 Apache Spark용 관리형 서비스와 같은 Google Cloud 컴퓨팅 내에서 실행됩니다. 실행 중에는 원격 Databricks 클러스터, Snowflake 가상 웨어하우스, AWS 컴퓨팅 인스턴스가 호출되지 않습니다.

인증은 명확한 3단계 배포 패턴을 따릅니다. 먼저 Google Cloud에서 페더레이션 카탈로그를 생성하고, 설정을 확인하여 자동으로 생성된 서비스 계정을 가져온 다음, 원격 플랫폼에서 액세스 권한을 부여합니다.

AI를 사용하여 샘플 데이터를 생성할 수 있습니다. 테이블의 스키마 세부정보는 아래와 같습니다.

Databricks Unity Catalog 구성

먼저 Databricks에서 카탈로그와 테이블을 준비합니다. Unity Catalog에서 페더레이션 액세스를 사용하려면 대상 스키마가 Databricks에 등록된 외부 위치와 연결되어 있어야 합니다.

code_block: <ListValue: [StructValue([('code', "-- Run inside Databricks SQL workspace\r\nCREATE CATALOG IF NOT EXISTS dbx_retail_db;\r\n\r\n-- Declare the managed target location at the schema level\r\nCREATE SCHEMA IF NOT EXISTS dbx_retail_db.dbx_core \r\n MANAGED LOCATION 's3://my-databricks-bucket/retail/data/';\r\n\r\n-- Create the Iceberg dimension table\r\nCREATE TABLE IF NOT EXISTS dbx_retail_db.dbx_core.dim_products (\r\n product_key INT,\r\n product_id STRING,\r\n product_name STRING,\r\n category STRING,\r\n subcategory STRING,\r\n brand STRING,\r\n price DOUBLE,\r\n cost DOUBLE\r\n)\r\nUSING iceberg;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eae13ad0>)])]>

AI를 사용하여 샘플 데이터를 생성할 수 있습니다. 각 섹션에서 테이블의 스키마 세부정보를 확인할 수 있습니다.

외부 엔진이 이 테이블을 읽으려면 먼저 Databricks metastore 관리자가 metastore 세부정보 탭에서 외부 데이터 액세스를 사용 설정해야 합니다.

Databricks 관리자 계정으로 이동하여 사용자 관리 메뉴에서 Databricks 서비스 보안 주체를 만들고, 해당 UUID '6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx'를 별도로 기록해 둡니다.

BigQuery에 Databricks 연결

다음으로 gcloud 명령줄 도구를 사용하여 Google Cloud 내에 페더레이션 카탈로그를 만듭니다. Databricks 작업공간 URL과 Databricks 서비스 보안 주체의 애플리케이션 ID가 필요합니다.

code_block: <ListValue: [StructValue([('code', 'export GCP_PROJECT_ID="my-lakehouse-project"\r\nexport GCP_REGION="us-central1"\r\n\r\ngcloud alpha biglake iceberg catalogs create dbx_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --primary-location="$GCP_REGION" \\\r\n --catalog-type="federated" \\\r\n --federated-catalog-type="unity" \\\r\n --unity-instance-name="dbc-xxxxxxxx-xxxx.cloud.databricks.com" \\\r\n --unity-catalog-name="dbx_retail_db" \\\r\n --unity-service-principal-application-id="6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx" \\\r\n --refresh-interval="300s"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8b951d0>)])]>

카탈로그가 생성되면 카탈로그 정보를 조회하여 할당된 서비스 계정을 확인합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud alpha biglake iceberg catalogs describe dbx_retail_db \\\r\n --project="$GCP_PROJECT_ID"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8b97b90>)])]>

Databricks로 돌아가 서비스 보안 주체에 권한을 할당합니다.

code_block: <ListValue: [StructValue([('code', '-- Grant catalog traversal permission\r\nGRANT USE CATALOG ON CATALOG dbx_retail_db \r\n TO `6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx`;\r\n\r\n-- Grant schema and read permissions\r\nGRANT USE SCHEMA,EXTERNAL USE SCHEMA, SELECT ON SCHEMA dbx_retail_db.dbx_core \r\n TO `6ea7b861-c5a5-xxxx-xxxx-xxxxxxxxxxxx`;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eaeaed10>)])]>

외부 데이터 액세스를 위한 사용자 인증 정보 벤더 제공을 사용 설정하려면 대상 스키마 또는 카탈로그에서 Databricks 서비스 보안 주체에 EXTERNAL USE SCHEMA 권한을 부여해야 합니다.

마지막으로 연결을 완료하려면 다음 세부정보를 사용하여 Databricks 서비스 보안 주체에 페더레이션 정책을 설정합니다.

발급기관 URL* - https://accounts.google.com
소유자* - 카탈로그 describe 명령어에서 반환된 숫자 소유자 ID(예: 1124251400450xxxxxxxx)
대상 - https://accounts.cloud.databricks.com

3개의 클라우드에서 단일 쿼리 실행

페더레이션된 Iceberg 테이블은 project.catalog.namespace.table과 같이 4단계로 구성된 경로를 통해 BigQuery에서 호출할 수 있습니다.

이 환경에서 판매 트랜잭션은 BigQuery에 기본적으로 저장되어 있습니다.

code_block: <ListValue: [StructValue([('code', 'CREATE SCHEMA IF NOT EXISTS local_retail_dataset\r\nOPTIONS(location="us-central1");\r\n\r\nCREATE OR REPLACE TABLE `my-lakehouse-project.local_retail_dataset.fact_sales` (\r\n sale_id STRING,\r\n sale_date DATE,\r\n customer_key INT64,\r\n product_key INT64,\r\n store_key INT64,\r\n quantity INT64,\r\n unit_price NUMERIC,\r\n discount NUMERIC,\r\n total_revenue NUMERIC,\r\n total_cost NUMERIC,\r\n margin NUMERIC\r\n)\r\nPARTITION BY sale_date\r\nCLUSTER BY store_key, product_key;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eaa6fc10>)])]>

이제 단일 SQL 쿼리를 실행하여 기본 판매 트랜잭션을 Snowflake의 고객 레코드, Databricks의 제품 라인, AWS Glue의 매장 위치와 조인할 수 있습니다.

code_block: <ListValue: [StructValue([('code', "SELECT \r\n c.first_name || ' ' || c.last_name AS customer_name, -- From Snowflake Iceberg\r\n p.product_name, -- From Databricks Iceberg\r\n s.store_name, -- From AWS S3 Iceberg\r\n SUM(f.quantity) AS total_units_sold, -- From BigQuery native fact\r\n SUM(f.total_revenue) AS total_sales_revenue -- From BigQuery native fact\r\nFROM `my-lakehouse-project.local_retail_dataset.fact_sales` f\r\nINNER JOIN `my-lakehouse-project.sf_retail_db.CORE.DIM_CUSTOMERS` c \r\n ON f.customer_key = c.customer_key\r\nINNER JOIN `my-lakehouse-project.dbx_retail_db.dbx_core.dim_products` p \r\n ON f.product_key = p.product_key\r\nINNER JOIN `my-lakehouse-project.glue_retail_db.glue_retail_db.dim_stores` s \r\n ON f.store_key = s.store_key\r\nGROUP BY 1, 2, 3\r\nORDER BY total_sales_revenue DESC\r\nLIMIT 10;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58eb90>)])]>

BigQuery는 조인을 즉시 처리합니다. Snowflake 식별자는 대문자(CORE.DIM_CUSTOMERS)로 표시되는 반면 Databricks와 AWS Glue는 소문자 테이블 경로를 유지합니다.

그림 2 - Snowflake, Databricks, AWS Glue의 데이터를 통합한 쿼리 결과

자연어로 크로스 클라우드 데이터 탐색

페더레이션된 Iceberg 테이블은 BigQuery 내에서 네이티브 테이블처럼 작동하므로 다운스트림 분석 기능이 액세스 권한을 직접 상속합니다. BigQuery의 대화형 분석을 이러한 통합 스키마에 연결하면 팀원들이 자연어 프롬프트를 사용하여 크로스 클라우드 데이터를 탐색할 수 있습니다.

대화형 분석에 필요한 모든 운영 컨텍스트를 제공하기 위해, 페더레이션 조인을 논리적 뷰로 저장합니다.

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE VIEW `my-lakehouse-project.local_retail_dataset.v_omnichannel_sales_pulse` AS\r\nSELECT \r\n f.sale_id,\r\n f.sale_date,\r\n c.first_name || ' ' || c.last_name AS customer_name,\r\n c.country AS customer_country,\r\n p.product_name,\r\n p.category AS product_category,\r\n p.brand AS product_brand,\r\n s.store_name,\r\n s.city AS store_city,\r\n s.region AS store_region,\r\n f.quantity,\r\n f.total_revenue,\r\n f.margin\r\nFROM `my-lakehouse-project.local_retail_dataset.fact_sales` f\r\nINNER JOIN `my-lakehouse-project.sf_retail_db.CORE.DIM_CUSTOMERS` c \r\n ON f.customer_key = c.customer_key\r\nINNER JOIN `my-lakehouse-project.dbx_retail_db.dbx_core.dim_products` p \r\n ON f.product_key = p.product_key\r\nINNER JOIN `my-lakehouse-project.glue_retail_db.glue_retail_db.dim_stores` s \r\n ON f.store_key = s.store_key;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58ccd0>)])]>

자연어로 매출 실적 분석

BigQuery의 대화형 분석에 질문할 때:

"총 판매 수익을 기준으로 상위 고객은 누구이며, 어떤 제품을 구매했고, 어떤 매장에서 쇼핑했어?"

대화형 분석은 세 가지 원격 카탈로그 모두에서 스키마를 평가하고, SQL 문을 생성하고, 쿼리를 실행하고, 응답을 표시합니다.

그림 3: BigQuery의 대화형 분석은 일반 언어 프롬프트를 Snowflake, Databricks, AWS Glue 전반의 페더레이션 쿼리로 변환합니다.

캐싱 및 데이터 레지던시 계획

프로덕션에 페더레이션 카탈로그를 배포하기 전에 다음 운영 동작을 고려하세요.

백그라운드 새로고침 주기: --refresh-interval 플래그는 메타데이터 동기화를 제어합니다. 최소 간격은 300초입니다. 수백 개의 테이블이 포함된 대규모 카탈로그의 경우 메타데이터 검색에 더 오랜 시간이 걸릴 수 있습니다. 동기화 주기가 지연되어 실행 시간이 초과되면, BigQuery는 태스크 큐가 쌓이는 것을 방지하기 위해 다음 예약된 실행을 건너뜁니다.
자동 쿼리 캐싱: BigQuery는 검색된 크로스 클라우드 데이터 블록을 페더레이션 카탈로그가 있는 리전(예: us-central1)에 캐시합니다. 이렇게 하면 반복되는 쿼리에서 네트워크 전송을 줄일 수 있습니다. 캐시된 블록은 해당 리전의 Google Cloud Storage 내에 상주하므로 조직의 데이터 레지던시 정책에 부합하는지 확인하세요.
암호화 설정: 크로스 클라우드 캐시 블록은 Google 관리 암호화 키를 사용합니다. 조직에서 constraints/gcp.restrictNonCmekServices 정책 제약 조건을 시행하는 경우, BigQuery는 캐시를 거치지 않고 모든 쿼리에 대해 원격 스토리지에서 데이터를 직접 읽어옵니다.
액세스 측정항목 모니터링: 쿼리 실행 계획에서 캐시 사용률을 평가할 수 있습니다. BigQuery 작업 통계의 objectStorageStats 섹션을 확인하여 cacheBytesRead를 objectStorageBytesRead와 비교합니다.

다음 단계

요약하자면, Google Cloud의 경계 없는 Lakehouse를 사용하면 비용이 많이 드는 마이그레이션이나 추가 데이터 파이프라인 빌드 없이도 데이터가 어디에 있든 상관없이 데이터를 바로 활용할 수 있습니다. 지금 바로 경계 없는 Lakehouse 아키텍처 문서를 확인하여 지원되는 리전과 사용자 인증 정보 구성에 대해 자세히 알아보세요. 경계 없는 Lakehouse Codelab을 통해 외부 카탈로그를 단계별로 페더레이션하는 방법을 연습할 수 있습니다. 마지막으로 Google Cloud 계정팀 또는 고객 엔지니어에게 문의하여 특정 데이터 플랫폼이나 업종에 맞는 경계 없는 Lakehouse 패턴을 검토해 보세요.

부록

Snowflake 및 AWS Glue 크로스 클라우드 데이터 액세스 설정

Snowflake와 BigQuery 연결

Snowflake Horizon Catalog 구성

먼저 Snowflake에서 데이터베이스, 스키마, Iceberg 테이블을 만듭니다. Snowflake Horizon에서 관리형 Iceberg 테이블은 개방형 Apache Iceberg REST 카탈로그 인터페이스를 자동으로 노출합니다.

code_block: <ListValue: [StructValue([('code', "-- Run inside Snowflake SQL worksheet\r\nCREATE DATABASE IF NOT EXISTS sf_retail_db;\r\nCREATE SCHEMA IF NOT EXISTS sf_retail_db.core;\r\n\r\n-- Create the Iceberg dimension table\r\nCREATE OR REPLACE ICEBERG TABLE sf_retail_db.core.dim_customers (\r\n customer_key INTEGER,\r\n customer_id VARCHAR,\r\n first_name VARCHAR,\r\n last_name VARCHAR,\r\n email VARCHAR,\r\n gender VARCHAR,\r\n country VARCHAR,\r\n signup_date DATE\r\n\r\n)\r\nCATALOG = 'SNOWFLAKE'\r\nEXTERNAL_VOLUME = 'SNOWFLAKE_MANAGED';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58c250>)])]>

외부 엔진이 이 카탈로그를 읽을 수 있도록 전용 리더 역할을 설정하고 데이터베이스, 스키마, 테이블 전체에 대한 순회 권한을 부여하세요.

SQL

code_block: <ListValue: [StructValue([('code', '-- Create a dedicated reader role\r\nCREATE ROLE IF NOT EXISTS gcp_lakehouse_reader_role;\r\n\r\n-- Grant database and schema traversal permissions\r\nGRANT USAGE ON DATABASE sf_retail_db TO ROLE gcp_lakehouse_reader_role;\r\nGRANT USAGE ON SCHEMA sf_retail_db.core TO ROLE gcp_lakehouse_reader_role;\r\n\r\n-- Grant read access on the target table\r\nGRANT SELECT ON TABLE sf_retail_db.core.dim_customers TO ROLE gcp_lakehouse_reader_role;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58d190>)])]>

다음으로 gcloud 명령줄 도구를 사용하여 Google Cloud 내에 페더레이션 카탈로그를 만듭니다. Snowflake 계정 식별자, 리더 역할, 루트 Iceberg 데이터베이스 이름이 필요합니다.

bash

code_block: <ListValue: [StructValue([('code', 'export GCP_PROJECT_ID="my-lakehouse-project"\r\nexport GCP_REGION="us-central1"\r\n\r\ngcloud alpha biglake iceberg catalogs create sf_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --primary-location="$GCP_REGION" \\\r\n --catalog-type="federated" \\\r\n --federated-catalog-type="snowflake" \\\r\n --snowflake-account-identifier="xy12345-ab67890" \\\r\n --snowflake-warehouse="SF_RETAIL_DB" \\\r\n --snowflake-role="gcp_lakehouse_reader_role" \\\r\n --refresh-interval="300s"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58d450>)])]>

Apache Iceberg REST 사양에서 --snowflake-warehouse는 가상 컴퓨팅 웨어하우스가 아니라 카탈로그 루트 데이터베이스 이름(SF_RETAIL_DB)을 참조합니다.

카탈로그가 생성되면 카탈로그 정보를 조회하여 할당된 숫자 서비스 계정 ID를 확인합니다.

bash

code_block: <ListValue: [StructValue([('code', 'gcloud alpha biglake iceberg catalogs describe sf_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --format=\'value(biglake-service-account-id)\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58ca90>)])]>

Snowflake로 돌아가 워크로드 아이덴티티 제휴(WIF)를 통해 Google Cloud의 숫자 ID를 비밀번호 없는 서비스 사용자에게 연결합니다.

SQL

code_block: <ListValue: [StructValue([('code', "-- Run inside Snowflake SQL worksheet\r\nUSE ROLE ACCOUNTADMIN;\r\n\r\n-- Bind Google Cloud's numeric identity to a passwordless service user\r\nCREATE OR REPLACE USER snowflake_service_user\r\n TYPE = SERVICE\r\n WORKLOAD_IDENTITY = (\r\n TYPE = GCP\r\n SUBJECT = '102669xxxxxxxxxxxxxxxxx' -- Numeric subject ID returned by gcloud describe\r\n )\r\n DEFAULT_ROLE = gcp_lakehouse_reader_role\r\n COMMENT = 'Service user for Lakehouse catalog federation over WIF';\r\n\r\n-- Grant the reader role to this service user\r\nGRANT ROLE gcp_lakehouse_reader_role TO USER snowflake_service_user;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58f0d0>)])]>

이 과정을 통해 OpenID Connect 기반의 비밀번호 없는 인증이 설정되며, BigQuery는 Snowflake Horizon에서 직접 테이블 메타데이터를 탐색하고 쿼리 실행 시에만 유효한 임시 사용자 인증 정보를 발급받을 수 있게 됩니다.

AWS Glue Data Catalog 구성

AWS에서 IAM ID를 준비하고, AWS Glue와 Amazon S3 전반에 액세스 권한을 설정하고, Iceberg 테이블을 등록하는 과정부터 시작합니다.

먼저 trust_policy.json이라는 이름의 플레이스홀더 신뢰 정책을 만듭니다. 이렇게 하면 Google Cloud에서 고유한 카탈로그 서비스 에이전트를 할당하기 전에 AWS IAM 역할을 프로비저닝할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "Version": "2012-10-17",\r\n "Statement": [\r\n {\r\n "Effect": "Allow",\r\n "Principal": {\r\n "Federated": "accounts.google.com"\r\n },\r\n "Action": "sts:AssumeRoleWithWebIdentity",\r\n "Condition": {\r\n "StringEquals": {\r\n "accounts.google.com:aud": ["PLACEHOLDER_VALUE"],\r\n "accounts.google.com:sub": ["PLACEHOLDER_VALUE"]\r\n }\r\n }\r\n }\r\n ]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58f290>)])]>

AWS CLI를 사용하여 IAM 역할을 만듭니다. 세션 시간을 12시간(43200초)으로 설정하면 장기 실행 분석 쿼리 중에 사용자 인증 정보가 만료되는 것을 방지할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'export AWS_ROLE_NAME="lakehouse_glue_federation_role"\r\n\r\naws iam create-role \\\r\n --role-name "$AWS_ROLE_NAME" \\\r\n --assume-role-policy-document file://trust_policy.json \\\r\n --max-session-duration 43200'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58ecd0>)])]>

다음으로 permissions_policy.json이라는 이름의 파일에 권한 정책을 정의합니다. 이 정책은 BigQuery에 AWS Glue 카탈로그 메타데이터를 읽고 Amazon S3에 있는 기본 Parquet 데이터 파일에 액세스할 수 있는 권한을 부여합니다.

code_block: <ListValue: [StructValue([('code', '{\r\n "Version": "2012-10-17",\r\n "Statement": [\r\n {\r\n "Sid": "GlueCatalogRead",\r\n "Effect": "Allow",\r\n "Action": [\r\n "glue:GetCatalog",\r\n "glue:GetDatabase",\r\n "glue:GetDatabases",\r\n "glue:GetTable",\r\n "glue:GetTables"\r\n ],\r\n "Resource": "arn:aws:glue:us-east-2:123456789012:*"\r\n },\r\n {\r\n "Sid": "S3BucketAndObjectRead",\r\n "Effect": "Allow",\r\n "Action": [\r\n "s3:ListBucket",\r\n "s3:GetObject"\r\n ],\r\n "Resource": [\r\n "arn:aws:s3:::my-glue-iceberg-bucket",\r\n "arn:aws:s3:::my-glue-iceberg-bucket/*"\r\n ]\r\n }\r\n ]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58c410>)])]>

새로 만든 역할에 이 권한 정책을 연결합니다.

code_block: <ListValue: [StructValue([('code', 'aws iam put-role-policy \\\r\n --role-name "$AWS_ROLE_NAME" \\\r\n --policy-name "lakehouse_glue_federation_policy" \\\r\n --policy-document file://permissions_policy.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58da10>)])]>

중요 (AWS Lake Formation): AWS 환경에서 AWS Lake Formation을 사용하는 경우 IAMAllowedPrincipals 그룹에 대상 데이터베이스 및 테이블에 대한 액세스 권한이 있는지 확인합니다(또는 버킷이 AWS Lake Formation에 등록된 경우 lakehouse_glue_federation_role에 명시적 Lake Formation 권한을 부여합니다). 이 설정이 없으면 Lake Formation 보안 설정이 IAM 역할의 카탈로그 메타데이터 액세스를 차단합니다.

권한 설정이 완료되면 Amazon Athena를 사용하여 AWS Glue에 데이터베이스와 Iceberg 테이블을 만듭니다.

code_block: <ListValue: [StructValue([('code', "-- Run inside Amazon Athena\r\nCREATE DATABASE IF NOT EXISTS glue_retail_db;\r\n\r\nCREATE TABLE IF NOT EXISTS glue_retail_db.dim_stores (\r\n store_key INT,\r\n store_id STRING,\r\n store_name STRING,\r\n city STRING,\r\n state STRING,\r\n region STRING,\r\n manager STRING,\r\n opened_date DATE\r\n\r\n)\r\nLOCATION 's3://my-glue-iceberg-bucket/retail/dim_stores/'\r\nTBLPROPERTIES (\r\n 'table_type'='ICEBERG', \r\n 'format'='parquet', \r\n 'write_compression'='zstd' \r\n\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58e290>)])]>

AWS Glue를 BigQuery에 연결

다음으로 gcloud 명령줄 도구를 사용하여 Google Cloud 내에 페더레이션 카탈로그를 등록합니다. 12자리 AWS 계정 ID, AWS 리전, 위에서 만든 역할 ARN이 필요합니다.

code_block: <ListValue: [StructValue([('code', 'export GCP_PROJECT_ID="my-lakehouse-project"\r\nexport GCP_REGION="us-central1"\r\nexport AWS_REGION="us-east-2"\r\nexport AWS_ACCOUNT_ID="123456789012"\r\n\r\ngcloud alpha biglake iceberg catalogs create glue_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --primary-location="$GCP_REGION" \\\r\n --catalog-type="federated" \\\r\n --federated-catalog-type="glue" \\\r\n --glue-warehouse="$AWS_ACCOUNT_ID" \\\r\n --glue-aws-region="$AWS_REGION" \\\r\n --glue-aws-role-arn="arn:aws:iam::${AWS_ACCOUNT_ID}:role/lakehouse_glue_federation_role"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58e4d0>)])]>

AWS 신뢰 정책이 전파되는 동안 백그라운드 새로고침이 너무 일찍 실행되어 실패하는 것을 방지하려면, 새로고침 일정을 설정하지 않은 상태로 카탈로그를 초기 설정하세요.

다음으로 Google Cloud에서 카탈로그에 할당한 고유한 숫자 소유자 ID를 추출합니다.

code_block: <ListValue: [StructValue([('code', 'export LAKEHOUSE_SA_ID=$(gcloud alpha biglake iceberg catalogs describe glue_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --format="value(biglake-service-account-id)")\r\n\r\necho "Assigned Lakehouse Service Account ID: $LAKEHOUSE_SA_ID"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58e690>)])]>

AWS CLI로 돌아가서 IAM 역할의 신뢰 정책을 업데이트하고 플레이스홀더를 확인된 Google Cloud ID로 바꿉니다.

code_block: <ListValue: [StructValue([('code', 'cat > trust_policy_final.json << EOF\r\n{\r\n "Version": "2012-10-17",\r\n "Statement": [\r\n {\r\n "Effect": "Allow",\r\n "Principal": {\r\n "Federated": "accounts.google.com"\r\n },\r\n "Action": "sts:AssumeRoleWithWebIdentity",\r\n "Condition": {\r\n "StringEquals": {\r\n "accounts.google.com:aud": [\r\n "$LAKEHOUSE_SA_ID"\r\n ],\r\n "accounts.google.com:sub": [\r\n "$LAKEHOUSE_SA_ID"\r\n ]\r\n }\r\n }\r\n }\r\n ]\r\n}\r\nEOF\r\n\r\naws iam update-assume-role-policy \\\r\n --role-name "$AWS_ROLE_NAME" \\\r\n --policy-document file://trust_policy_final.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58cb10>)])]>

5. 메타데이터 동기화 사용 설정 및 확인

bash

code_block: <ListValue: [StructValue([('code', 'gcloud alpha biglake iceberg catalogs update glue_retail_db \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --refresh-interval="300s"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9fa58ef90>)])]>

네임스페이스가 검색되고 동기화되었는지 확인합니다.

bash

code_block: <ListValue: [StructValue([('code', '# Verify namespaces synchronized from AWS Glue\r\ngcloud alpha biglake iceberg namespaces list \\\r\n --project="$GCP_PROJECT_ID" \\\r\n --catalog="glue_retail_db"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb0da0d0>)])]>

예측 가능한 BigQuery AI 비용: 생성형 AI 함수의 비용 관리 기능 출시

Wed, 21 Oct 2026 17:00:00 +0000

BigQuery의 생성형 AI 함수(AI.GENERATE, AI.IF, AI.CLASSIFY, AI.SCORE 등)를 사용하면 대규모 언어 모델(LLM)을 SQL에 직접 가져올 수 있어 하나의 쿼리로 수백만 건의 고객 지원 티켓을 분류하거나 각 제품 리뷰의 감정을 점수화할 수 있습니다. 하지만 이러한 함수는 토큰 사용량에 따라 요금이 청구되므로 대규모 데이터 세트에 적용할 때는 예산을 사전에 관리하는 것이 중요합니다.

Google Cloud는 최근 BigQuery 생성형 AI 함수를 위한 토큰 기반 비용 관리 기능을 정식 버전(GA)으로 출시했습니다. 이 기능을 사용하면 관리자가 일일 할당량을 통해 AI 토큰 소비량에 대한 셀프서비스 가드레일을 설정할 수 있으므로 팀은 정해진 예산 범위 내에서 혁신을 추진할 수 있습니다. 이 블로그에서는 BigQuery 생성형 AI 함수의 비용 관리 기능을 개괄적으로 살펴보고 몇 가지 실용적인 예시와 함께 시작하는 데 도움이 되는 리소스를 소개합니다. 그럼 자세히 살펴보겠습니다.

비용 관리를 위한 할당량 설정

Google Cloud Identity and Access Management(IAM) 할당량 시스템을 통해 관리되는 4가지 일일 할당량을 사용하면 프로젝트와 사용자별로 토큰 소비량을 제어할 수 있습니다. 사용자별 한도는 조직 전체가 아니라 각 프로젝트 내의 개별 사용자에게 적용됩니다.

할당량 이름	측정항목	범위	기본값
일일 AI 입력 토큰	LLM이 사용한 입력 토큰	프로젝트당, 일일	2,000억 개
사용자당 일일 AI 입력 토큰	LLM이 사용한 입력 토큰	사용자당, 프로젝트당, 일일	1,500억 개
일일 AI 출력 토큰	LLM에서 사용되는 출력 및 사고 토큰	프로젝트당, 일일	200억 개
사용자당 일일 AI 출력 토큰	LLM에서 사용되는 출력 및 사고 토큰	사용자당, 프로젝트당, 일일	150억 개

주요 세부정보:

할당량은 전역에 적용됩니다. 모든 리전의 사용량이 합산되므로 모니터링하지 않는 리전에서 예상치 못한 비용이 누적되는 것을 방지할 수 있습니다.
출력 할당량에는 '사고' 토큰이 포함됩니다. 추론 토큰은 Gemini 플랫폼 요금 체계와 동일하게 출력 토큰 할당량에 합산됩니다.

어떤 함수에 적용되나요?

할당량은 LLM 기반의 생성 작업을 수행하는 다음 BigQuery 함수에 적용됩니다.

AI.GENERATE
AI.GENERATE_TABLE
AI.GENERATE_TEXT(별칭: ML.GENERATE_TEXT)
AI.CLASSIFY
AI.IF
AI.SCORE
AI.AGG

적용되지 않는 함수: AI.GENERATE_EMBEDDING(ML.GENERATE_EMBEDDING으로도 사용 가능) 및 AI.EMBED와 같은 임베딩 함수는 비용이 훨씬 저렴한 다른 모델에서 실행되기 때문에 이러한 할당량이 적용되지 않습니다.

할당량 관리

관리자는 별도의 지원 케이스를 제출하지 않고도 워크로드의 변화에 따라 Google Cloud 콘솔에서 직접 할당량을 확인하고 조정할 수 있습니다.

IAM 및 관리자 → 할당량 및 시스템 한도로 이동합니다.
서비스별로 필터링하고 BigQuery API를 선택합니다.
이름 열을 기준으로 정렬하여 4개의 AI 할당량을 목록 상단에 표시합니다

'IAM 및 관리자' → '할당량 및 시스템 한도'에서 확인할 수 있는 생성형 AI 토큰 할당량

4. 변경할 할당량(예: 일일 AI 입력 토큰)을 찾습니다.

5. 점 3개로 된 메뉴를 열고 할당량 수정을 선택합니다.

여기에서 다음 작업을 수행할 수 있습니다.

비용을 더 엄격하게 통제하려면 할당량을 낮춥니다. 이 변경사항은 승인 없이 즉시 적용됩니다.
사용량을 늘리려면 동일한 페이지에서 할당량 상향을 요청합니다. 많은 요청이 자동으로 승인되지만 큰 폭의 상향 요청은 간단한 검토 절차를 거칠 수 있습니다.

'IAM 및 관리자' → '할당량 및 시스템 한도'에서 생성형 AI 토큰 할당량 수정

할당량을 관리하려면 소유자, 편집자, 할당량 관리자(roles/servicemanagement.quotaAdmin), 서비스 사용량 관리자(roles/serviceusage.serviceUsageAdmin) 중 하나의 역할이 필요합니다.

자동화를 선호하는 경우 Cloud Quotas API, gcloud CLI, Terraform을 통해 이러한 할당량을 프로그래매틱 방식으로 관리하여 여러 프로젝트에 일관된 가드레일을 적용할 수 있습니다.

사용량 모니터링

할당량 및 시스템 한도 페이지에서는 한도를 설정하는 것 외에도 과거 토큰 소비량을 확인할 수 있으므로 사용량 급증을 빠르게 감지하고 예산을 적정 수준으로 조정할 수 있습니다. 이러한 추세를 분석하면 새로운 생성형 AI 워크로드와 데이터 파이프라인이 전체 토큰 사용량에 어떤 영향을 미치는지 파악할 수 있습니다.

'IAM 및 관리자' → '할당량 및 시스템 한도'에서 확인할 수 있는 생성형 AI 토큰 할당량의 프로젝트별 일일 토큰 사용량

7일, 14일, 30일, 맞춤 기간을 선택할 수 있는 장기 사용량 그래프

단계별 안내는 토큰 할당량으로 비용 관리에 대한 BigQuery 문서를 참조하세요.

토큰 할당량과 결제 지출 한도 비교

토큰 할당량이 Google Cloud의 유일한 비용 관리 수단은 아닙니다.

토큰 할당량(여기에서 소개된 기능)은 AI에 특화된 사전 예방적 관리 수단입니다. BigQuery는 쿼리 실행 중 토큰 사용량을 추적하고 각각 설정된 프로젝트별 한도와 사용자별 한도에 가까워지면 작업을 중단합니다.
Cloud Billing 지출 한도는 달러 단위로 프로젝트 및 서비스 기준으로 적용되며 설정한 기준 금액에 도달하면 사용을 자동으로 차단할 수 있습니다. 지출 한도는 정확한 사용량 제어보다는 전반적인 재무적 안전장치로 작동하며, 제한 조치가 즉시 적용되지는 않으므로 일부 초과 비용이 발생할 수 있습니다.

AI 비용 관리를 위한 1차 방어 수단으로 토큰 할당량을 사용하고 프로젝트 전반에 대한 안전장치로 지출 한도를 활용하는 것이 좋습니다.

할당량 적용 방식

할당량은 쿼리가 한도를 초과하여 계속 실행되도록 허용하는 대신 작업을 중단하는 방식으로 적용됩니다. 쿼리에 필요한 할당량이 이미 소진된 경우에만 쿼리가 사전에 거부되면서 QuotaExceeded 오류가 발생합니다. 그렇지 않으면 쿼리가 실행되며, 실행 도중 할당량이 소진되면 BigQuery는 새로운 LLM 호출 전송을 중단합니다.

max_error_ratio를 지원하는 함수(예: AI.IF)는 처리되지 않은 행의 비율이 한도 내로 유지되면 부분 결과를 반환하고, 그렇지 않으면 실패합니다.
범용 함수(예: AI.GENERATE) 쿼리는 계속 성공합니다. 건너뛴 행에는 생성된 값이 표시되지 않으며 status 필드에 할당량 초과 오류가 표시됩니다.

자세한 내용은 문서의 할당량 적용 동작을 참조하세요.

`AI.COUNT_TOKENS를 사용한` 입력 데이터 크기 측정

적절한 할당량 값을 선택하려면 워크로드가 모델에 얼마나 많은 텍스트를 전송하는지 파악하는 것이 좋습니다. 이때 AI.COUNT_TOKENS 함수가 도움이 됩니다.

AI.COUNT_TOKENS는 요금이 청구되는 생성 호출을 수행하지 않고 모델의 토크나이저가 텍스트 문자열에서 생성하는 토큰 개수를 반환합니다. 이 함수를 열에 실행하면 입력 데이터의 토큰 수를 측정할 수 있습니다.

code_block: <ListValue: [StructValue([('code', "-- Count the input text tokens for each product review\r\nSELECT\r\n SUM(\r\n AI.COUNT_TOKENS(\r\n CONCAT('Classify the sentiment of this review as positive, negative, or neutral: ', review_text),\r\n\r\n endpoint => 'gemini-3.1-flash-lite').result) AS total_input_tokens\r\nFROM\r\n `my_project.my_dataset.product_reviews`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9ebdba450>)])]>

이 수치는 입력 토큰 사용량의 최소 기준선이며 출력 토큰이나 사고 토큰, 각 AI 함수가 입력 데이터에 추가하는 요청 사항, 텍스트가 아닌 입력(이미지 등)은 포함되지 않습니다. 이 값은 다음과 같은 용도로 사용할 수 있습니다.

워크로드를 실행하기 전에 입력 데이터의 토큰 사용량을 추정합니다.
실제 입력 및 출력 사용량을 측정하는 소규모 샘플 실행과 함께 할당량을 적절하게 조정합니다.
모델에 대해 게시된 Gemini 플랫폼 가격 책정을 사용하여 토큰 사용량을 비용(달러)으로 환산합니다.

토큰 사용량을 예산으로 환산하는 계산 예시

Gemini 3.1 Flash-Lite 모델을 사용하면서 프로젝트의 일일 AI 지출을 $100 정도로 유지하려고 한다고 가정해 보겠습니다. 현재 공개된 가격은 다음과 같습니다(BigQuery는 배치 방식으로 처리하므로 50% 할인이 적용됨).

입력 토큰: 토큰 100만 개당 $0.125
출력 토큰(응답+추론): 토큰 100만 개당 $0.75

소규모 샘플 실행 결과 입력 토큰(I)과 출력 토큰(O)의 평균 비율이 100:1이라면 다음과 같이 일일 예산을 계산할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'Cost: 0.125 × I + 0.75 × O = 100 (I, O in millions of tokens)\r\nRatio: I = 100 × O'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eb1c7810>)])]>

이 식을 풀면 하루에 약 7억 5,400만 개의 입력 토큰과 754만 개의 출력 토큰을 사용할 수 있는 셈입니다. 일일 AI 입력 토큰과 일일 AI 출력 토큰을 이 값으로 설정하면 프로젝트의 일일 지출을 약 100달러 수준으로 유지할 수 있습니다. 프로젝트에서 가격이 서로 다른 여러 모델을 사용하는 경우에는 모델별로 예산을 책정하거나 요율을 혼합해 계산해야 합니다.

AI 비용 관리를 위한 권장사항

사용자당 할당량부터 시작하세요. 한 명의 사용자 또는 제어할 수 없는 실험으로 인해 프로젝트 예산이 소진되는 것을 방지할 수 있습니다.
확장하기 전에 사용량을 측정하세요. AI.COUNT_TOKENS로 입력 데이터 크기를 측정하세요. 그런 다음 소규모 샘플을 실행하고 사용량 그래프를 확인한 후 한도를 설정하세요.
출력 토큰에도 주의하세요. 출력 토큰은 비용이 더 많이 듭니다. 함수에서 max_output_tokens를 지원한다면 이를 설정하여 생성 길이를 제한하세요.
모니터링하고 반복 수정하세요. 실제 사용량과 예산의 변화에 따라 한도를 조정하세요.

시작하기

지금 토큰 기반 비용 관리 기능을 사용할 수 있습니다. 시작하려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 IAM 및 관리자 → 할당량 및 시스템 한도를 열고 BigQuery API로 필터링합니다.
4가지 AI 관련 토큰 할당량을 검토하고 예산에 맞게 한도를 설정합니다.
AI.COUNT_TOKENS를 사용하여 입력 데이터의 크기를 측정합니다.

자세한 내용은 생성형 AI 비용 관리에 관한 문서를 참조하세요.

토큰 기반 가드레일을 설정하면 조직에서 요구하는 수준의 비용 예측 가능성을 확보하면서 BigQuery의 생성형 AI 기능을 활용할 수 있습니다.

BigQuery에서 다변량 시계열 예측을 지원하는 TimesFM 3.0 소개

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

개요

BigQuery에서 AI.FORECAST를 사용한 제로샷 시계열 예측을 도입한 이후(처음에는 TimesFM 2.0으로 구동되었고 이후 TimesFM 2.5로 업그레이드됨) 커스텀 모델을 학습시키거나 관리할 필요 없이 SQL에서 직접 예측을 생성할 수 있게 되었습니다. 하지만 TimesFM 2.5 이전까지 이러한 파운데이션 모델은 단일 시계열의 기록만으로 미래 값을 예측하는 단변량 예측으로 제한되었습니다. 실제로 대다수의 현실적인 예측 문제는 다변량적 특성을 가집니다. 즉, 관련 타겟과 날씨, 프로모션, 휴일과 같은 외부 요인이 복합적으로 작용하여 미래의 결과를 결정하게 됩니다.

오늘 BigQuery에서 TimesFM 3.0의 프리뷰 버전을 발표하게 되어 기쁩니다. Google 연구팀에서 개발한 TimesFM 3.0은 3억 3천만 개의 파라미터를 갖춘 현존 최고 수준의 파운데이션 모델로, BigQuery SQL 내에서 직접 네이티브 다변량 시계열 예측을 수행할 수 있도록 설계되었습니다. TimesFM 3.0은 GIFT-Eval, FEV-Bench, TIME 등 3대 주요 공개 시계열 리더보드에서 모두 1위를 차지했으며, 공변량 및 다변량 예측 태스크 모두에서 기존 파운데이션 모델 대비 최고의 제로샷 정확도를 달성했습니다.

새로운 다변량 기능과 더불어 TimesFM 3.0은 AI.FORECAST를 통한 단변량 예측과 AI.DETECT_ANOMALIES를 통한 이상 감지를 위한 드롭인 업그레이드 기능도 제공합니다. 기존 워크플로는 model => 'TimesFM 3.0'을 지정하기만 하면 더 높은 벤치마크 정확성의 이점을 즉시 누릴 수 있습니다.

새로운 기능: 다변량 파운데이션 모델링

TimesFM 3.0을 통해 BigQuery는 AI.FORECAST를 사용하여 익숙한 SQL 워크플로에 엔터프라이즈급 다변량 모델링 기능을 제공합니다.

기능	TimesFM 2.0 / 2.5	TimesFM 3.0
예측 범위	단변량만	단변량 및 다변량
타겟 열	단일 타겟	단일 또는 다중 타겟
과거 전용 값이 있는 공변량 열	지원되지 않음	지원됨
과거 및 미래 값이 있는 공변량 열	지원되지 않음	지원됨

BigQuery SQL을 사용한 다변량 예측

이러한 기능이 어떻게 함께 작동하는지 알아보기 위해 NYC Citi Bike 공개 데이터 세트(bigquery-public-data.new_york.citibike_trips)를 사용하여 향후 7일간의 일일 통근자(subscriber_trips) 및 여가용(casual_trips) 자전거 이용 건수를 예측해 보겠습니다.

BigQuery는 두 개의 행 집합을 결합하는 다변량 예측에 단일 테이블 입력 형식을 사용합니다.

과거 관측 데이터 행: 시작 시간(2016-01-01)과 예측 기준일(2016-06-01) 사이의 타임스탬프로, 타겟 측정항목, 과거 공변량, 알려진 미래 공변량 데이터가 모두 포함되어 있습니다.
미래 예측 기간 행: 7일간의 예측 기간(2016-06-01~2016-06-07)에 해당하는 타임스탬프로, 알려진 미래 공변량 데이터로 채워지는 한편 타겟 열과 과거 전용 공변량은 NULL로 설정됩니다.

code_block: <ListValue: [StructValue([('code', "WITH data AS (\r\n SELECT\r\n DATE(starttime) AS date,\r\n IF(MIN(starttime) < '2016-06-01', COUNTIF(usertype = 'Subscriber'), NULL) AS subscriber_trips,\r\n IF(MIN(starttime) < '2016-06-01', COUNTIF(usertype = 'Customer'), NULL) AS casual_trips,\r\n IF(MIN(starttime) < '2016-06-01', AVG(tripduration / 60.0), NULL) AS avg_duration_min,\r\n IF(EXTRACT(DAYOFWEEK FROM MIN(starttime)) IN (1, 7), 1.0, 0.0) AS is_weekend\r\n FROM `bigquery-public-data.new_york.citibike_trips`\r\n WHERE starttime >= '2016-01-01' AND starttime < '2016-06-08'\r\n GROUP BY date\r\n)\r\nSELECT\r\n *\r\nFROM\r\n AI.FORECAST(\r\n TABLE data,\r\n MODEL => 'TimesFM 3.0',\r\n TIMESTAMP_COL => 'date',\r\n TARGET_COLS => ['subscriber_trips', 'casual_trips'],\r\n PAST_COVARIATE_COLS => ['avg_duration_min'],\r\n FUTURE_COVARIATE_COLS => ['is_weekend']\r\n );"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8be8710>)])]>

이 쿼리는 TimesFM 3.0에서 지원되는 세 가지 다변량 측정기준을 보여줍니다.

상관관계가 있는 타겟 예측(target_cols) 각 라이더 세그먼트에 대해 별도의 모델을 실행하는 대신 TARGET_COLS => ['subscriber_trips', 'casual_trips']를 전달하면 한 번의 호출로 두 측정항목을 공동으로 예측할 수 있습니다. TimesFM 3.0은 통근자와 일반 이용자라는 서로 다른 시계열 간의 역학 관계를 정교하게 포착합니다. 예를 들어, 두 그룹이 공통적으로 날씨에 민감하게 반응하는 양상이나 주말 이용 패턴이 상반되게 나타나는 특징 등을 정확하게 파악해 냅니다.
과거 공변량 활용(past_covariate_cols) 평균 주행 시간(avg_duration_min), 오프라인 매장 방문수, 예기치 못한 서비스 중단과 같이 과거의 기록으로만 확인 가능하며 사전에 알 수 없는 신호들이 있습니다. PAST_COVARIATE_COLS => ['avg_duration_min']을 전달하면(미래 예측 기간 행은 NULL로 설정) 모델이 과거의 맥락을 파악할 수 있습니다. 이를 통해 해당 특성의 미래 값 없이도 일시적인 충격과 근본적인 추세를 명확히 구분해 냅니다.
미래 공변량 활용(future_covariate_cols) 주말(is_weekend), 공휴일, 예정된 프로모션과 같은 외부 요인은 과거 시점뿐만 아니라 미래의 예측 기간에 대해서도 미리 알 수 있는 정보입니다. FUTURE_COVARIATE_COLS => ['is_weekend'](2016-06-07까지 모든 행에 데이터가 채워짐)를 전달하면, TimesFM 3.0이 다가오는 캘린더 일정에 맞춰 7일간의 예측을 직접 조정할 수 있습니다.

출력 이해하기

이 함수는 target_cols에 지정된 각 타겟 열에 대해 구조화된 예측 결과를 반환합니다. target_cols의 각 열에 대해 AI.FORECAST는 포인트 예측(값)과 하한 및 상한 예측 구간 경계를 포함하는 구조체를 반환합니다.

날짜	subscriber_trips.value	subscriber_trips.prediction_ interval_lower_bound	subscriber_trips.prediction_ interval_upper_bound	casual_trips.value	casual_trips.prediction_ interval_lower_bound	casual_trips.prediction_ interval_upper_bound	time_series_type	confidence_level	ai_forecast_status
2016-06-01 00:00:00 UTC	44699.64	32590.76	55723.44	4581.32	1727.91	9189.31	예측	0.95
2016-06-02 00:00:00 UTC	44611.75	30413.05	57209.19	4647.17	1466.23	10273.55	예측	0.95
2016-06-03 00:00:00 UTC	41379.15	26218.65	54940.09	5341.36	1568.23	11805.86	예측	0.95
2016-06-04 00:00:00 UTC	30164.34	14266.43	45075.92	9097.74	2558.27	18452.52	예측	0.95
2016-06-05 00:00:00 UTC	26727.27	10101.44	42239.33	8398.50	1692.15	17768.99	예측	0.95
2016-06-06 00:00:00 UTC	36713.84	19493.00	52679.59	4723.08	400.08	11710.73	예측	0.95
2016-06-07 00:00:00 UTC	39749.97	22157.42	56119.86	4180.97	95.70	10845.74	예측	0.95

BigQuery 대화형 분석에서 활용하는 TimesFM 3.0

BigQuery 대화형 분석에서 자연어를 사용하여 다변량 예측을 실행할 수도 있습니다. 동일한 bigquery-public-data.new_york.citibike_trips 데이터 세트에서 "2개월간의 과거 데이터를 사용하여 2016년 6월 1~7일의 일일 정기 이용권 사용자와 일반 사용자의 이동을 예측해 줘. 평균 이동 시간은 과거 공변량으로, 주말 지표는 미래 공변량으로 사용해 줘."라고 요청하면 됩니다. 대화형 분석은 TimesFM 3.0을 사용하여 기본 AI.FORECAST 쿼리를 자동으로 생성하고 실행하여 결과 요약, 각 타겟의 예측 구간이 포함된 대화형 예측 차트, 주요 예측 인사이트를 제공합니다.

BigQuery 대화형 분석에서 TimesFM 3.0을 사용한 다변량 예측을 통해 자연어 프롬프트만으로 7일간의 예측 결과, 대화형 차트, 인사이트를 생성할 수 있습니다.

요약 및 다음 단계

TimesFM 3.0의 기본 다변량 지원을 통해 BigQuery는 데이터 이동, 커스텀 특성 추출 파이프라인 또는 전용 모델 호스팅 인프라 없이도 복잡하고 상호 연결된 엔터프라이즈 데이터 세트에 현존 최고 수준의 파운데이션 모델 예측을 제공합니다.

BigQuery에서 TimesFM 3.0을 사용하여 예측을 시작하는 방법은 다음과 같습니다.

TimesFM 3.0 모델 아키텍처와 기능에 대해 자세히 알아보려면 Google 연구팀 블로그 게시물을 참고하세요.
BigQuery TimesFM 문서를 살펴보세요.
단계별 다변량 예측 튜토리얼을 따릅니다.
BigQuery Studio SQL 작업공간에서 직접 `model => 'TimesFM 3.0'` 과 함께 AI.FORECAST를 사용해 보세요.
BigQuery에서 단변량 시계열 이상 감지를 위해 `model => 'TimesFM 3.0'`과 함께 AI.DETECT_ANOMALIES를 사용해 보세요.
BigQuery에서 단변량 시계열 평가를 위해 `model => 'TimesFM 3.0'`과 함께 AI.EVALUATE를 사용해 보세요.

Data Agent Kit를 사용한 에이전트형 데이터 과학

Mon, 19 Oct 2026 19:00:00 +0000

규정 준수팀에서 결제 승인이 예상보다 오래 걸리고 있다는 점을 파악했다고 가정해 보겠습니다. 팀에서 사기를 의심하는 상황에서 데이터 과학자는 어떤 거래를 우선적으로 조사해야 할지 파악하는 역할을 맡게 됩니다. 이러한 관심 목록을 작성하려면 원시 트랜잭션 로그를 수집 및 정리하고, 과거 사기 사례를 기반으로 모델을 학습시키고, 새 레코드에 점수를 매기고, 파이프라인이 매일 실행되도록 예약하는 과정이 필요합니다. Antigravity IDE 내에서 Data Agent Kit를 사용하여 에이전트로 엔드 투 엔드 워크플로를 빌드하는 방법을 살펴보겠습니다.

Data Agent Kit 소개

Data Agent Kit는 코딩 에이전트용 플러그인 또는 Visual Studio Code 기반 IDE용 확장 프로그램을 통해 Google Cloud 데이터를 원활하게 활용할 수 있도록 지원합니다. 워크플로에는 다음과 같은 두 가지 중요한 기능을 더해 줍니다.

에이전트 지원: MCP 도구는 에이전트를 데이터 서비스에 연결합니다. 스킬은 데이터 스택 활용을 위한 안내 및 권장사항을 제공하는 마크다운 파일입니다.
IDE의 도구: 편집기를 벗어나지 않고도 데이터베이스 쿼리부터 Airflow 파이프라인 배포까지 Google의 에이전트형 데이터 클라우드를 활용할 수 있습니다.

데이터 로드하기

먼저 Google Cloud Storage의 원시 트랜잭션 로그부터 살펴보겠습니다. 에이전트에게 Spark를 사용하여 데이터를 BigQuery로 로드하는 노트북을 생성해 달라고 요청할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'Create a PySpark notebook to ingest JSON transaction logs from gs://financials-clearing-raw/ into the BigQuery table transactions.raw_transactions.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8ba4d50>)])]>

에이전트는 JSON 로그를 raw_transactions라는 BigQuery 테이블에 로드하는 Jupyter 노트북을 생성합니다. 노트북을 열고 코드를 검토한 후 IDE에서 사전 구성된 Spark 서버리스 런타임을 사용하여 실행할 수 있습니다.

생성된 PySpark 노트북 실행

노트북이 실행된 후 Data Agent Kit를 사용하여 raw_transactions 테이블을 열 수 있습니다. 이 확장 프로그램을 사용하면 IDE에서 바로 테이블을 탐색하고 메타데이터를 검사할 수 있습니다.

IDE에서 BigQuery 테이블 검사

이제 레코드가 BigQuery에 저장되었지만, 아직 모델 학습에 바로 사용할 수 있는 상태는 아닙니다. 먼저 중복되거나 누락된 레코드를 정리한 다음, 남은 레코드를 각 결제의 발신자 및 수신자 정보와 조인합니다.

데이터 정리하기

정리 로직을 dbt 프로젝트에 넣어 새로운 데이터 배치마다 실행할 수 있도록 하겠습니다. 각 트랜잭션이 한 번만 나타나는지도 테스트할 것입니다. 에이전트에 다음 프롬프트를 입력합니다.

code_block: <ListValue: [StructValue([('code', 'Create a dbt project in dbt_project/ for the BigQuery dataset transactions.\r\n\r\nDeduplicate raw_transactions by transaction_id in staging. Separate records with null IDs into invalid_transactions. Join valid records with dim_payers and dim_payees to create enriched_transactions, preserving the is_fraud label. Add a transaction uniqueness test.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8ba67d0>)])]>

에이전트는 데이터 정리 및 보강을 위한 SQL 모델이 포함된 dbt 프로젝트를 생성합니다. 생성된 코드를 살펴보고 중복을 처리하는 방식과 참조 테이블을 조인하는 방법을 확인하세요. 그런 다음 터미널에서 dbt 빌드를 실행합니다. 이 과정을 통해 BigQuery에 스테이징 및 보강된 테이블이 생성되며, 트랜잭션 ID가 누락된 레코드를 위한 별도의 테이블도 함께 빌드됩니다. 또한 dbt는 고유성 테스트도 수행합니다.

통합 터미널에서 dbt 모델 검증

또한 과거 거래가 허위였는지 여부를 나타내는 is_fraud 열도 유지합니다. 라벨이 지정된 데이터를 기반으로 모델을 학습시키고, 이를 활용해 사기 발생 여부가 아직 확인되지 않은 새로운 트랜잭션의 점수를 매깁니다.

검토 대기열 빌드하기

데이터가 준비되었으니 에이전트에게 Spark Serverless에서 실행되는 랜덤 포레스트 분류기를 사용하여 학습 노트북을 만들어 달라고 요청해 보겠습니다.

code_block: <ListValue: [StructValue([('code', 'Create a PySpark notebook to train a RandomForestClassifier\r\non table transactions.enriched_transactions.\r\n\r\nPredict is_fraud, training only on records where the label\r\nis not null. Encode categorical features, scale amounts,\r\nand evaluate the model using ROC AUC. Save the evaluated model to gs://models/fraud_model.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8ba7b90>)])]>

노트북을 검토하고 실행한 다음 평가 출력을 확인하여 모델이 사기 거래와 합법적인 거래를 얼마나 잘 구분하는지 확인합니다. Data Agent Kit 확장 프로그램을 사용하여 학습된 모델 아티팩트가 Google Cloud Storage에 저장되었는지 확인할 수도 있습니다.

Google Cloud Storage에서 학습된 모델 아티팩트 확인

이제 저장된 모델을 사용하여 아직 is_fraud 값이 없는 거래의 점수를 매길 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'Create a batch inference notebook that loads the saved model from gs://my_models/fraud_model and scores records in transactions.enriched_transactions where is_fraud is null.\r\n\r\nWrite transactions with a fraud probability score >= 0.50 to the Spanner table SparkEvalFraudReviewQueue, in the instance cymbal-fraud, database fraud-db.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8ba49d0>)])]>

이 예시에서 추론 노트북은 BigQuery에서 라벨이 지정되지 않은 트랜잭션의 점수를 매기고 사기 가능성이 50% 이상으로 추정되는 트랜잭션을 Spanner 검토 대기열로 전송합니다. 플래그가 지정된 레코드는 팀이 조사 대상을 결정하는 데 도움이 되지만, 실제 사기 발생 여부는 여전히 직접 판단해야 합니다.

추론 노트북이 플래그가 지정된 레코드를 어떻게 필터링하고 기록하는지 살펴본 후 실행하세요. 완료되면 IDE에서 Spanner 테이블을 쿼리하여 결과를 확인해 보세요.

Spanner 테이블에서 플래그가 지정된 트랜잭션 쿼리

이 테이블이 바로 우리가 빌드하고자 했던 목록입니다. 이제 규정 준수팀은 트랜잭션 검토를 시작할 수 있으며, 원시 로그에서 레코드를 가져와 대기열에 추가하는 워크플로가 마련되었습니다.

지금까지는 각 단계를 직접 시작했습니다. 이제 워크플로가 매일 자동으로 실행되도록 연결할 수 있습니다.

내일 다시 실행하기

매일 최신 로그를 로드하고, dbt 변환을 적용하고, 저장된 모델을 사용하여 라벨이 지정되지 않은 트랜잭션의 점수를 매깁니다. Managed Service for Apache Airflow를 사용하여 이러한 단계를 순서대로 실행합니다. 에이전트에 다음과 같이 질문합니다.

code_block: <ListValue: [StructValue([('code', 'Create an orchestration pipeline named fraud_analysis_pipeline that runs ingestion, the dbt project, and batch inference in that order.\r\n\r\nSchedule it daily at midnight. Use Spark Serverless for the notebooks, including the Spanner connector for inference, and gs://YOUR_ARTIFACT_BUCKET for artifact storage.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8ba4d90>)])]>

에이전트가 YAML 파이프라인 정의와 배포 구성을 생성합니다. 파이프라인 정의는 단계 간의 일정과 종속 항목을 설정합니다. 한편 배포 구성은 실행될 Airflow 환경을 지정합니다.

그러면 Data Agent Kit가 정의를 Airflow DAG로 변환하며, 이를 IDE에서 대화형 그래프로 탐색할 수 있습니다. '오케스트레이션 파이프라인'에서 파이프라인을 열고 태스크를 클릭하여 검사합니다. 노트북 태스크의 경우 링크를 따라 코드로 바로 돌아갈 수 있습니다.

데이터 파이프라인 검사

Airflow 환경이 구성되면 캔버스에서 '파이프라인 실행'을 클릭합니다. Data Agent Kit는 노트북과 dbt 프로젝트를 패키징하고, DAG를 배포하고, 실행을 트리거합니다. 파이프라인의 실행 기록을 열어 진행 상황을 확인합니다. 개별 태스크를 선택하여 상태, 기간, 로그를 검사할 수도 있습니다.

Airflow DAG 시작 및 로그 검사

Airflow는 매일 파이프라인을 실행하여 원시 로그에서 새로운 데이터 배치를 가져와 검토 대기열로 보냅니다. 이제 규정 준수팀은 플래그가 지정된 트랜잭션에만 집중할 수 있으며, 이러한 레코드를 팀에 전달하는 작업이 자동화되었습니다.

체험해 보기

직접 사용해 볼 준비가 되셨다면 이 워크플로를 빌드하고 실행할 수 있도록 전체 설정을 안내하는 Codelab을 참고하세요. 문서를 읽거나 GitHub의 오픈소스 저장소에서 스킬과 도구를 확인할 수도 있습니다 .

비정형 데이터 워크플로 현대화: Alteryx Live Query와 Google Cloud BigQuery의 만남

Mon, 19 Oct 2026 19:00:00 +0000

Alteryx One Live Query와 Google Cloud BigQuery는 연결되지 않은 도구에 대한 의존도를 줄이고, 데이터 이동을 최소화하며, 웨어하우스 네이티브 실행을 지원함으로써 기업이 복잡한 비정형 데이터를 대규모로 처리하는 방식을 재정의합니다.

Live Query는 비즈니스 사용자가 코드 한 줄 작성하지 않고도 정교한 데이터 파이프라인을 빌드할 수 있는 직관적인 브라우저 기반 환경을 제공합니다. BigQuery의 확장성과 성능이 결합된 이 솔루션은 안전한 SQL 푸시다운을 지원합니다. 즉, 데이터 변환 로직이 네트워크를 통해 이동하는 대신 웨어하우스 내에서 직접 실행됩니다. 이러한 시너지 효과는 문서가 많은 워크플로에서 특히 강력합니다. Live Query는 Gemini와 같은 Google의 고급 AI 및 머신러닝 모델을 조정하여 BigQuery 환경의 엄격한 데이터 거버넌스와 보안을 유지하면서 PDF와 이미지에서 인텔리전스를 추출할 수 있습니다.

인보이스 PDF 처리부터 Live Query를 통한 BigQuery 예외 보고 관리까지

재무 및 운영팀은 산더미처럼 쌓인 공급업체 인보이스에 파묻혀 고군분투하는 경우가 많습니다. 이러한 문서는 데이터가 일관되지 않고 인보이스 번호 형식도 제각각인 PDF 형태로 제공되므로, 수작업 시 오류가 발생할 위험이 매우 큽니다. 기존에는 데이터팀이 수동으로 데이터를 추출하거나 여러 단편화된 도구를 조합해 데이터를 웨어하우스로 이동해야 했습니다. 하지만 이 방식은 시간이 많이 소요될 뿐만 아니라 데이터 중복이나 금액 불일치가 발생하기 쉽다는 단점이 있습니다.

BigQuery용 Live Query를 통합하면 이제 인보이스의 전체 수명 주기를 자동화할 수 있습니다. 데이터팀은 BigQuery 생태계 내에서 직접 PDF를 처리하고, 주요 필드를 추출하고, 결과를 표준화함으로써 문서 내의 이상치나 데이터 문제와 같은 예외를 더 빠르게 식별할 수 있습니다. 동시에 BigQuery의 세분화된 액세스 정책을 통해 구성된 제어된 엔터프라이즈 데이터가 웨어하우스를 벗어나지 않도록 보장할 수 있습니다.

솔루션 개요: 추출, 분류, 검증, 라우팅, 게시

Live Query 솔루션의 작동 방식을 자세히 살펴보겠습니다. 인보이스 PDF는 Google Cloud Storage에 비정형 문서 형태로 저장됩니다. Live Query 워크플로에서 문서 추출 도구는 Gemini 또는 Document AI와 같이 사용자가 선택한 모델을 사용하여 정형 필드를 추출합니다. 추출된 결과는 정확한 매칭을 위해 표준화 과정을 거치며, BigQuery에 이미 안전하게 저장되어 관리되고 있는 기존 인보이스 레코드와 비교됩니다.

이 자동화된 워크플로는 수동 개입을 최소화하여 문서 처리부터 의사 결정까지 전 과정을 매끄럽게 연결하도록 설계되었습니다. 엔터프라이즈 규모에서 이 패턴은 단순히 몇 개의 PDF를 처리하는 것이 아니라, 수백만 개의 비정형 문서에 대한 분석과 AI를 지원하면서 조정 로직을 BigQuery와 일치시키는 것입니다.

이 솔루션은 AI 기반 추출과 BigQuery 네이티브 실행을 결합하여 다음과 같은 이점을 제공합니다.

더 높은 직접 전송 처리율: 수동 처리를 줄이고 더 많은 인보이스를 자동으로 처리할 수 있습니다.
더 빠른 데이터 조정 및 수동 예외 처리 감소: 프로세스 초기 단계에서 추출된 인보이스를 BigQuery 데이터와 비교함으로써, 팀에서 중복이나 불일치 항목을 더 빠르게 식별하고 수동 검토가 필요한 인보이스 수를 줄일 수 있습니다.
감사 가능성 강화: 소스부터 운영 결과물에 이르기까지 데이터의 흐름을 명확하게 추적하고 관리합니다.
데이터 이동 최소화: 데이터를 BigQuery 내에 유지하면서 기본 제공 기능을 활용해 보안, 거버넌스, 제어 기능을 강화합니다.

아키텍처: Google Cloud 클라우드 네이티브 패턴

전체적인 프로세스를 살펴보면, 인보이스 PDF는 Cloud Storage에 스테이징된 후 브라우저의 Live Query 워크플로를 통해 처리됩니다. 이후 BigQuery에 이미 저장되어 관리되고 있는 인보이스 내역과 대조를 거쳐, 재무팀에서 즉시 활용할 수 있는 운영 결과물로 기록됩니다. 이 아키텍처 패턴의 핵심적인 장점은 워크플로 작성이 브라우저에서 이루어지는 반면, 변환 및 조정 로직은 제어되는 데이터 환경에 대해 플랫폼 서비스를 통해 실행된다는 것입니다.

Live Query 아키텍처는 웨어하우스급 대규모 처리와 거버넌스 기반의 실행을 실현하기 위해 설계되었습니다. 안전한 SQL 푸시다운을 사용하여 BigQuery에서 직접 변환 및 조정 로직을 실행하고, Gemini와 통합하여 문서 추출, 분류, 요약과 같은 고급 AI 기능을 제공합니다.

Live Query(브라우저): 사용자가 브라우저에서 시각적으로 워크플로를 작성하고 문서 추출, 분류, 정리, 검증, 라우팅 로직을 구성합니다.
Alteryx One Platform Services: Transformation Service는 브라우저 워크플로와 고객 데이터 환경 간의 요청 처리, 실행 계획, 결과 검색을 조정합니다. 또한 이 서비스는 워크플로 실행 전반에 걸쳐 추적 가능성과 관측 가능성을 추가하여 운영 모니터링과 감사 가능성을 모두 강화합니다.
고객 Google Cloud: 인보이스 PDF는 Google Cloud Storage(GCS)에 스테이징되고, 이전 인보이스 데이터는 BigQuery에서 계속 관리되며, AI 기반 추출은 해당 환경에서 실행되고, 워크플로 결과물이 BigQuery에 다시 기록됩니다.

이 패턴에서 브라우저는 작성 레이어이고, Alteryx One Platform Services는 조정 레이어이며, Google Cloud는 거버넌스 기반이 데이터 및 실행 레이어 역할을 합니다. 이를 통해 Live Query에서 워크플로 로직을 시각적으로 작성할 수 있으며, 실행은 BigQuery의 거버넌스가 적용된 데이터 및 웨어하우스 규모의 처리 성능에 맞춰 이뤄집니다.

Live Query 워크플로 둘러보기: PDF에서 인사이트 도출까지

인보이스를 예로 들어 Live Query 워크플로가 비정형 PDF를 어떻게 처리하는지 자세히 살펴보겠습니다.

인보이스 PDF 수집

워크플로는 원시 PDF 파일이 저장된 Google Cloud Storage의 디렉터리 입력을 가리키는 것으로 시작됩니다. 실제로 이 단계는 단순히 폴더를 지정하는 수준에 그치지 않습니다. PDF의 위치를 나열하고 파일의 절대 경로, 크기, 생성/수정 타임스탬프 같은 파일 수준의 메타데이터를 반환하여, 워크플로가 후속 추출 단계에 정확한 문서 세트를 안정적으로 전달할 수 있도록 돕습니다.

주요 필드 추출

Alteryx의 Document Extract 도구를 사용하면 워크플로가 Google Cloud Storage에 저장된 PDF 인보이스를 처리하여 정형 또는 반정형 결과를 BigQuery로 직접 추출합니다. 추출 단계에서는 워크플로 구성에 따라 Document AI 또는 Gemini AI 중 사용자가 선택한 모델을 활용합니다. 이 도구는 내부적으로 입력 문서 URI를 기반으로 임시 외부 객체 테이블을 생성한 후, Document AI 모델의 경우 ML.PROCESS_DOCUMENT를, Gemini AI 모델의 경우 AI.GENERATE를 호출하여 적절한 함수를 실행합니다. 이 워크플로에서는 Gemini 경로가 사용되며, AI.GENERATE가 요청된 인보이스 필드를 추출하여 후속 Live Query 워크플로로 반환합니다.

대화형 설계 단계에서 Live Query는 미리보기를 위해 문서 URI 중 일부만 선별하여 처리하는 반면, 실제 런타임 실행 시에는 인보이스 PDF 전체 집합을 처리합니다.

code_block: <ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *\r\nFROM AI.GENERATE(\r\n MODEL project.dataset.gemini_model,\r\n (\r\n SELECT\r\n uri,\r\n 'Extract invoice_number, invoice_amount, vendor_name, net_amount, tax_amount, and line_items.' AS prompt\r\n FROM project.dataset.temp_invoice_object_table\r\n )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9f8f1cb90>)])]>

추출된 콘텐츠 분류

추출 후 워크플로는 Alteryx의 Classify(분류) 도구를 사용하여 추출된 인보이스 텍스트에 제로샷 분류를 적용합니다. 이 사용 사례에서는 BigQuery의 AI.CLASSIFY를 사용하여 항목 콘텐츠를 산업용품 또는 사무용품과 같은 사전 정의된 비즈니스 카테고리로 분류합니다. 이 과정을 통해 다운스트림 워크플로에 새로운 예측 라벨 열이 추가됩니다. 이렇게 추가된 비즈니스 컨텍스트 덕분에 추출된 데이터는 다운스트림 조정, 예외 처리, 보고 단계에서 더 유용하게 활용될 수 있습니다.

code_block: <ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *,\r\n AI.CLASSIFY(line_item_text, categories => ['industrial', 'office']) AS line_item_classify\r\nFROM upstream"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa9eaca30d0>)])]>

데이터 정규화

추출된 인보이스 번호를 정리하고 표준화하여 공백이나 일관되지 않은 형식과 같은 사소한 차이 때문에 조정 과정에서 중복 항목이 누락되지 않도록 합니다.

이전 데이터와 비교

워크플로는 정규화된 현재 인보이스 레코드를 BigQuery에 이미 상주하는 이전 인보이스 데이터와 조인합니다. 이 조정 단계에서는 기존 내역에 이미 존재하는 인보이스 번호와 일치하는 레코드를 식별하여 중복 가능성이 있는 항목으로 플래그를 지정합니다.

예외 플래그 지정

그런 다음 수식 단계에서 나머지 레코드에 비즈니스 규칙 로직을 적용합니다. 이러한 규칙은 워크플로마다 다를 수 있으며 금액 불일치, 필수 필드 누락, 잘못된 합계 또는 기타 재무 관련 예외 사항에 대한 검토 항목을 포함할 수 있습니다. 이 예시에서는 하나의 규칙이 invoice_amount가 net_amount + tax_amount와 일치하는지 확인하고 불일치하는 경우 검토를 위해 플래그를 지정합니다.

운영 결과물 생성

워크플로는 두 가지 운영 결과물을 생성합니다. 하나는 과거 레코드와 일치하고 잠재적인 중복으로 플래그가 지정된 인보이스이고, 다른 하나는 검증되고 필요한 경우 예외 라벨이 지정되고 미지급 인보이스 처리를 위해 준비된 일치하지 않는 현재 인보이스입니다.

그 결과, 단순히 데이터를 추출하는 데 그치지 않고 재무팀이 즉시 검토하고 조치를 취할 수 있는 거버넌스 기반의 운영 결과물을 얻을 수 있습니다.

요약: 거버넌스가 적용된 문서 기반 의사 결정 워크플로

두 회사의 공동 고객은 비즈니스 프로세스를 개선하는 데 도움이 되는 이러한 새로운 기능에 대해 큰 기대를 하고 있습니다.

“Alteryx One: Google 에디션에서 가장 인상 깊었던 점은 Google Cloud 환경에 자연스럽게 녹아든다는 것이었습니다. 비즈니스 사용자가 직관적이고 제어 가능한 환경을 통해 BigQuery 데이터를 활용할 수 있게 함으로써, 분석에 대한 접근성을 높일 수 있는 기회를 갖게 되어 기쁩니다.” - Michael Wyant, Papa Johns 엔터프라이즈 데이터 및 기업 솔루션 부문 부사장

이 사용 사례는 단순한 추출 도구를 넘어, 비정형 문서를 실행 가능한 운영 결과물로 변환하는 강력한 Google Cloud 네이티브 패턴을 제시합니다. 웨어하우스 데이터를 별도의 준비 도구로 이동할 필요 없이, 워크플로 내에서 스토리지, 추출, 조정 및 출력 생성의 전 과정을 BigQuery에 이미 저장된 거버넌스 기반 엔터프라이즈 데이터와 일관되게 유지할 수 있습니다. Alteryx One Live Query의 직관적인 설계와 BigQuery의 확장성 및 AI 기능을 결합하면 재무팀은 수작업을 줄이고 예외 처리를 가속화하며 더 가치 있는 전략적 이니셔티브에 집중할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

Lakehouse 런타임 카탈로그

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

복잡한 환경이 낳은 정체

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

원격 MCP 기반 CLI 활용의 장점

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

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

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

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

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

Google Cloud CLI 원격 MCP 서버에 연결

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

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

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

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

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

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

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

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

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

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

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

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

가격 책정 및 가용성

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

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

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

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

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

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

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

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

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

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

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

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

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

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

빠른 시작 예시

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

1. 자연어로 코드 생성

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

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

2. 복잡한 코드 설명

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

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

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

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

4. 쿼리 최적화

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

2단계로 시작하기

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

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

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

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

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

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

용량 부족에 대한 이해

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

가변형 VM

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

주요 특징

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

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

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

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

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

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

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

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

Hyperdisk Balanced 활용

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

장단점 및 주요 고려사항

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

1. 리소스 할당량

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

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

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

3. 성능 특성

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

추가 권장사항

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

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

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

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

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

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

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

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

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

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

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

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

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

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

컨텍스트 부족 극복

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

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

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

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

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

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

데이터에 신뢰와 지식 제공

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

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

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

앞으로의 방향

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

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

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

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

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

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

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

성장을 위한 선제적 현대화

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

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

고급 MLOps 조정

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

사용 가능한 리전

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

시작하기

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

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

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

성장하는 레스토랑의 예

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

성장의 마찰

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

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

디지털 트윈

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

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

BigQuery 그래프를 사용한 모델링

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

1. 시맨틱 계층 정의

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

쿼리 언어:

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

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

실무에서의 정밀도

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

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

2. 검색 실행

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

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

Graph Query Language

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

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

미래를 위한 기반 구축

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

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

결론

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

지금 시작하기

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

초기 실행: 콜드 열 검색

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

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

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

후속 탐색: 측정기준 추가

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

데이터 분석

Gemini Enterprise를 Snowflake 데이터에 안전하게 연결

적절한 통합 패턴 선택

아키텍처 접근 방식

시스템 아키텍처 플로우

상세한 실행 시퀀스

1단계: Snowflake 보안 통합 설정

2단계: 데이터 거버넌스 및 액세스 제어

3단계: Snowflake 내에서 Cortex 에이전트 및 MCP 서버 프로비저닝

4단계: MCP 서버 URL 찾기 및 구성

5단계: Google ADK를 통해 연결

6단계: 프로젝트 구조 및 배포

7단계: Gemini Enterprise에 커스텀 에이전트 등록하기

중요

식별자 정렬 이해하기

시작하기

BigQuery ObjectRef 정식 버전 출시: SQL만으로 대화형 분석을 위한 멀티모달 데이터 플랫폼 빌드

비정형 데이터에 구조를 부여하는 ObjectRef

SQL로 충실도 높은 ETL 만들기

업계 리더의 검증된 사용 사례

정식 버전의 새로운 기능

실제 사례 보기: 엔드 투 엔드 멀티모달 분석

1. 충실도 높은 ETL: 콜 센터 오디오 분석

2. 대규모 생성형 AI 필터링: 제품 규정 준수

3. 임시 탐색: 제품 카탈로그 보강

4. 다중 객체 추론: 선제적 위협 감지

지금 바로 분석 시작하기

Knowledge Catalog의 새로운 자체 학습 컨텍스트 보강 기능 소개

Gemini 기반의 자체 학습 보강 기능으로 컨텍스트를 최신 상태로 유지하세요

컨텍스트 세트로 각 대상에 적합한 컨텍스트를 설정하세요

Knowledge Studio에서 탐색하고 제어하세요

시작하기

데모 보기: Knowledge Catalog의 자체 학습 보강이 에이전트를 그라운딩하는 방법

Python UDF 로깅을 활용하여 파이프라인 모니터링 가능성을 확보하는 방법

아키텍처 개요

빠른 시작 둘러보기: 단계별 안내

1단계: 일반 Python UDF 만들기

2단계: 로깅을 사용 설정한 상태로 수집 실행하기

수집 결과

3단계: Cloud Logging에서 실시간 알림 설정하기

Google Cloud 콘솔에서 설정(원클릭)

4단계: BigQuery 로그 분석으로 문제가 있는 행 분류하기

로그 분석 출력

데이터 복구

최종 clean_events 테이블 결과:

기타 사용 사례

권장사항

시작하기

Gemini를 위한 혁신적인 기능으로 에이전트 시대에 맞는 경계 없는 Lakehouse 도입

Gemini를 통해 Google Cloud 외부에 있는 데이터에 액세스하기

경계 없는 Lakehouse의 고급 기능

페타바이트 규모의 성능과 추론

에이전트를 위한 포괄적인 컨텍스트와 데이터 액세스

손쉬운 현대화

개방형 표준으로 간편해지는 크로스 클라우드 대화형 분석

경계 없는 레이크하우스 아키텍처

Databricks Unity Catalog 구성

BigQuery에 Databricks 연결

3개의 클라우드에서 단일 쿼리 실행

자연어로 크로스 클라우드 데이터 탐색

자연어로 매출 실적 분석

캐싱 및 데이터 레지던시 계획

다음 단계

부록

Snowflake와 BigQuery 연결

Snowflake Horizon Catalog 구성

AWS Glue Data Catalog 구성

AWS Glue를 BigQuery에 연결

5. 메타데이터 동기화 사용 설정 및 확인

예측 가능한 BigQuery AI 비용: 생성형 AI 함수의 비용 관리 기능 출시

비용 관리를 위한 할당량 설정

어떤 함수에 적용되나요?

할당량 관리

사용량 모니터링

토큰 할당량과 결제 지출 한도 비교

할당량 적용 방식

AI.COUNT_TOKENS를 사용한 입력 데이터 크기 측정

토큰 사용량을 예산으로 환산하는 계산 예시

AI 비용 관리를 위한 권장사항

시작하기

최종 `clean_events` 테이블 결과:

`AI.COUNT_TOKENS를 사용한` 입력 데이터 크기 측정