FactStack

Snowflake MCP 서버로 Gemini Enterprise 에이전트 연결하는 방법

데이터 인프라

한마디로

AI 비서가 자연어 질문을 받으면 Snowflake가 직접 SQL을 만들고 실행해서, 사용자 권한 안에서만 데이터를 보여줘요

한눈에

Google Cloud 블로그가 Gemini Enterprise 에이전트를 Snowflake 데이터에 안전하게 붙이는 방법을 7단계로 소개했습니다. 에이전트가 자연어 질문을 Snowflake MCP 서버로 넘기면 Snowflake Cortex Agent가 SQL을 만들고 Snowflake 안에서 직접 실행하는 구조예요. OAuth 2.0 user impersonation을 쓰기 때문에 범용 서비스 계정 없이 사용자별 권한이 그대로 적용됩니다.

실무 맥락: 서비스 계정으로 붙이던 방식의 위험

원문은 엔터프라이즈 AI가 단순 채팅을 넘어 데이터 웨어하우스에 접근해야 가치가 생긴다고 짚어요. 다만 범용 서비스 계정으로 모델에 넓은 접근 권한을 주면 사용자가 보안 제한을 우회할 수 있다는 점이 큰 위험이라고 설명합니다. 마케팅 조직에서 '지난 분기 텍사스 판매 상위 5개 품목' 같은 질문을 에이전트에 던지는 장면을 원문이 예로 들었는데요, 이때 누가 물어보느냐에 따라 볼 수 있는 데이터가 달라야 한다는 게 설계의 출발점입니다.

이번 아키텍처: 번역과 실행을 Snowflake 안에 가둠

ADK 에이전트는 사용자의 자연어 질문을 Snowflake MCP 서버에 그대로 넘깁니다. MCP 서버는 CORTEX_AGENT_RUN 도구 타입으로 Cortex Agent를 호출하고, 이 에이전트는 Cortex Analyst 시맨틱 뷰를 기반으로 질문을 SQL로 바꿔 인증된 사용자의 OAuth 세션과 역할 권한으로 Snowflake 안에서 바로 실행해요. 원문은 이 방식이 사내 시맨틱 정의에 맞춘 결정적인 text-to-SQL 번역을 제공하고, 스키마 환각과 검증되지 않은 SQL 실행 위험을 줄인다고 설명합니다. SYSTEM_EXECUTE_SQL 같은 원시 실행 도구는 외부 클라이언트에 노출하지 말라고 권장하고요. 보안 표면이 불필요하게 늘고 Cortex Agent의 중앙 거버넌스를 우회하게 되기 때문이라고 합니다.

7단계 구성과 권한 설정 체크포인트

전체 흐름은 보안 통합 설정, 역할과 권한 부여, Cortex Agent 및 MCP 서버 생성, MCP 서버 URL 확인, Google ADK 에이전트 코드 작성, agents-cli 배포, Gemini Enterprise 콘솔 등록 순서입니다. 보안 통합은 클라이언트 시크릿을 보호하도록 confidential OAuth client로 만들어요. 권한 쪽에서 원문이 IMPORTANT로 강조한 항목은 다음과 같습니다.

  • 시맨틱 뷰만 열어서는 부족합니다. 시맨틱 뷰가 바라보는 물리 테이블에도 사용자 컨텍스트의 SELECT 권한이 필요하고, 빠지면 쿼리 실행 중 런타임 오류가 나요.
  • 보안 정책상 기본 테이블 직접 접근이 어렵다면 그 위에 Snowflake Secure View를 만들고 시맨틱 뷰를 얹는 방법이 있습니다. 뷰는 Owner's Rights로 실행되므로 사용자 GenAI 역할에는 Secure View와 시맨틱 뷰의 SELECT만 있으면 돼요.
  • OAuth 토큰은 인가 시점의 DEFAULT_ROLE과 DEFAULT_WAREHOUSE에 묶입니다. 기본값을 설정하기 전에 인가하면 엉뚱한 역할에 세션이 고정돼 쿼리가 실패해요. Gemini Enterprise에서 인가하기 전에 기본값을 먼저 맞추고, 인가 후에는 원래 값으로 되돌려도 됩니다.

배포와 Gemini Enterprise 등록

ADK 코드에서는 에이전트가 사용자 자격증명을 꺼낼 때 쓰는 AUTH_ID(예: snowflake_oauth_conn)를 정의합니다. 원문 파이썬 예제는 바닐라 버전이라서 오류 처리, 구조화된 스키마, 커스텀 프롬프트 같은 보강은 각자 해야 해요. 배포는 init.py, .env, requirements.txt로 디렉터리를 구성한 뒤 공식 Google Agents CLI(agents-cli)로 진행하고, 완료되면 projects/PROJECT_ID/locations/LOCATION/reasoningEngines/RESOURCE_ID 형태의 리소스 경로가 출력됩니다. 등록 단계에서는 Gemini Enterprise 콘솔의 Agents에서 Custom agent via Agent Platform을 추가하고 Authorizations를 설정해요. Authorization name은 코드의 AUTH_ID와 정확히 같아야 하고, Client ID와 Client secret은 SYSTEM$SHOW_OAUTH_CLIENT_SECRETS 결과를, Token URI와 Authorization URI는 DESCRIBE SECURITY INTEGRATION 결과를 씁니다. Authorization URI 끝에는 response_type=code 파라미터를 붙여야 합니다.

실무 적용 포인트

  • 기본 사용 사례라면 이 ADK 방식 대신 Gemini Enterprise와 Snowflake를 바로 잇는 공동 솔루션이 원문에서 안내돼요. ADK 오케스트레이션은 Snowflake 인사이트를 외부 엔터프라이즈 도구와 결합하는 복잡한 멀티 에이전트 워크플로에 맞는 고급 패턴입니다.
  • 시맨틱 뷰 설계가 곧 분석 정확도예요. 사내 지표 정의를 시맨틱 뷰에 담아야 에이전트가 같은 기준으로 답합니다.
  • 사용자별 DEFAULT_ROLE과 DEFAULT_WAREHOUSE를 인가 전에 점검하는 절차를 온보딩 체크리스트에 넣어 두세요.
  • 원시 SQL 실행 도구는 MCP 서버에서 외부로 열지 않는다는 원칙을 보안 리뷰 항목으로 고정하면 좋습니다.

자주 묻는 질문

MCP 란 무엇인가요?

Model Context Protocol의 약자로, AI 에이전트가 외부 시스템의 도구와 데이터에 접근하는 연결 규약이에요. 이번 글에서는 Snowflake가 관리하는 MCP 서버가 CORTEX_AGENT_RUN 도구를 노출하고, ADK 에이전트가 이 서버를 호출하는 형태로 쓰입니다.

Gemini Enterprise 에이전트가 Snowflake 사용자 권한을 어떻게 지키나요?

범용 서비스 계정 대신 OAuth 2.0으로 사용자를 대리해요. 쿼리는 인증된 사용자의 OAuth 세션과 역할 권한으로 Snowflake 안에서 실행되므로, 사용자가 볼 수 없는 데이터는 에이전트도 볼 수 없습니다.

Snowflake MCP 서버에서 SYSTEM_EXECUTE_SQL을 열어도 되나요?

원문은 권장하지 않아요. 원시 실행 도구를 외부 클라이언트에 노출하면 보안 표면이 늘고 Cortex Agent의 중앙 거버넌스를 우회하게 됩니다. 질의 생성과 실행은 CORTEX_AGENT_RUN으로 Snowflake 경계 안에 두라고 안내합니다.

시맨틱 뷰만 권한을 주면 쿼리가 실행되나요?

실행되지 않고 런타임 오류가 나요. 시맨틱 뷰를 뒷받침하는 물리 테이블에도 SELECT 권한이 필요합니다. 직접 접근이 어렵다면 Secure View 위에 시맨틱 뷰를 만들어 Owner's Rights로 처리하는 방법이 있습니다.

에디터 노트

에이전트 도입에서 자주 막히는 지점이 권한 모델인데, 사용자 대리 OAuth와 쿼리 실행의 Snowflake 내부 격리를 구현 기준으로 제시한 점이 쓸모 있습니다. 다만 인가 시점에 DEFAULT_ROLE이 고정되는 동작과 물리 테이블 SELECT 요건은 막상 붙여 보면 가장 먼저 부딪히는 함정이라 사전 점검이 필수예요. 원문 예제도 바닐라 수준이어서 운영 투입 전에 오류 처리와 프롬프트 보강이 따로 필요합니다.

참고 출처 | 원문 보기

태그

용어 풀이
Snowflake
클라우드 데이터 웨어하우스 플랫폼
MCP
AI 에이전트와 외부 도구를 잇는 모델 컨텍스트 프로토콜
Gemini Enterprise
구글 클라우드의 기업용 AI 에이전트 플랫폼
Cortex Agent
Snowflake 안에서 SQL 생성과 실행을 맡는 거버넌스 에이전트
공유

관련 마테크