명세서, SQL, 로그까지 모두 컨텍스트로: Snowflake Cortex Agents에 대한 컨텍스트 연동 선택지

서론

안녕하세요! Nowcast의 데이터 엔지니어 케빈입니다.

최근 '명세서, SQL, 로그까지 모두 컨텍스트로: Cortex Agent에 대한 컨텍스트 연동 선택지'라는 제목으로 Snowflake World Tour Tokyo 2026에서 발표했습니다.

본 기사에서는 발표 내용을 블로그 형식으로 정리합니다.

Snowflake 외부의 컨텍스트

데이터 기반을 Snowflake로 구축한 분들이 많으실 겁니다. Nowcast 역시 Snowflake × dbt × Terraform으로 사내 데이터 기반을 구축 및 운영하고 있으며, BI에도 연결하고 있습니다.

하지만 막상 AI 에이전트에게 질문을 던져보면 제대로 답하지 못하는 경우가 있습니다. 예를 들어 POS 데이터에 대해 다음과 같은 질문을 생각해 보겠습니다.

질문	답변이 있는 곳
'이 매출은 세금 포함인가요?'	GitHub에 있는 dbt 모델의 코드
...

이 경우, 테이블 내용만 보고는 답할 수 없으며, Snowflake 외부에 흩어져 있는 컨텍스트가 필요한 질문입니다. 에이전트가 좋은 답변을 하도록 하려면, 이러한 컨텍스트를 어떻게 연결하는지가 중요합니다.

본 기사에서는 이 세 가지 종류의 컨텍스트(GitHub / Google Drive / AWS 로그)를 가능한 한 Snowflake Native 방식으로 Cortex Agents나 Snowflake Cowork에 전달하는 방법을 검토합니다. 선택지는 크게 다음과 같은 2가지입니다.

MCP로 가져오기 - MCP Connector
MCP Gateway

테이블에 넣어두기 (테이블화)

MCP를 이용하는 방법

MCP Connector

MCP 서버를 이용하여 외부 시스템에서 컨텍스트를 가져오는 것은 가장 정석적인 접근 방식입니다. Snowflake에는 MCP Connector가 있으며, Cortex Agents나 Cowork에서 외부의 MCP 서버를 사용할 수 있습니다.

MCP Connector에는 다음 2가지 종류가 있습니다.

Supported MCP Connector: Atlassian, GitHub, Glean, Linear, Salesforce는 Snowsight에서 프로바이더를 선택하는 것만으로 설정할 수 있습니다.
Custom MCP Connector: 위 외의 MCP 서버는 OAuth 설정을 직접 지정하여 연결합니다.

설정 절차는 공식 문서의 Set up supported MCP connectors와 Custom MCP connectors에 정리되어 있습니다.

이번 케이스를 간단히 생각해보면, 다음 3가지 MCP Connector를 준비하면 필요한 컨텍스트를 가져올 수 있을 것 같습니다.

GitHub: dbt 모델의 코드나 그 주변 파일 -
Google Drive: 데이터 정의서나 기타 문서 -
AWS: CloudWatch Logs에 있는 실행 로그 등

MCP Connector의 실체

MCP Connector가 내부적으로 무엇을 하는지, GitHub를 예로 들어 살펴보겠습니다. MCP의 인증은 OAuth를 기반으로 하므로, OAuth의 등장인물에 비유하여 정리하면 이해하기 쉽습니다.

OAuth에서의 역할	실체	설명
권한 서버 (GitHub)	GitHub App	권한 서버 내 클라이언트 설정에 해당합니다.
...
GitHub の MCP Connector における OAuth の登場人物

Snowsight 화면에서 필요 사항을 기입하면, 다음과 같은 DDL이 실행되어 실제로 API Integration과 External MCP Server가 생성됩니다.

CREATE API INTEGRATION github_mcp_integration
API_PROVIDER = external_mcp
API_ALLOWED_PREFIXES = ('https://api.githubcopilot.com')
...

즉, GUI로 설정할 수 있다고는 하지만, Snowflake 상의 오브젝트로는 API Integration과 External MCP Server 두 가지가 실체입니다. Terraform 등으로 관리하거나 Custom MCP Connector를 만드는 경우에도 이 두 개의 오브젝트를 생성하고 관리합니다.

MCP Connector의 과제

한편, MCP Connector를 단순히 3개 나열하는 구성에는 몇 가지 과제가 있습니다.

거버넌스 측면 - 공식적인 원격 MCP 서버는 사용자 권한이 그대로 전달되는 형태가 많습니다.
따라서 에이전트에게 필요한 범위를 넘어 권한이 과도하게 부여되기 쉽습니다 (과잉 공유 문제).
관리 측면 - Snowflake 외의 AI 툴에서 연결되는 MCP 서버와는 관리가 분리되어, 조직 전체에서 어떤 MCP 서버가 사용되고 있는지 파악하기 어렵습니다 (소위 '떠돌아다니는(野良) MCP').
세분화 정도(Granularity) - Google Drive 같은 외부 MCP 서버를 에이전트에 추가하면 해당 서버의 툴이 모두 로드됩니다 (Tool discovery and invocation).
따라서 Snowflake 측에서 툴 단위로 사용을 제한할 수 없습니다.

이러한 과제들에 대한 해결책 중 하나가 MCP Gateway입니다.

MCP Gateway

MCP Gateway는 여러 MCP 서버를 뒤에서 묶어주는 단일 연결 통로입니다. MCP Gateway를 거치면 다음과 같은 아키텍처가 됩니다.

Snowflake 측에 등록하는 MCP Connector는 게이트웨이(Gateway)가 하나뿐입니다.
허용된 MCP 서버만 게이트웨이에 등록하고, Snowflake를 포함한 각 클라이언트는 게이트웨이를 통해 사용합니다.
어떤 MCP 서버의 어떤 툴을 사용할지 게이트웨이 측에서 제어할 수 있습니다.
뒤쪽 MCP 서버 구현도 고안함으로써 권한 과잉에도 대응할 수 있습니다.

연결 대상을 일원적으로 관리할 수 있고, 툴 단위의 제어도 가능해지므로 앞서 언급된 세 가지 과제를 모두 해결할 수 있습니다.

Naucast / Finatext에서는 자체 개발한 MCPass를 MCP Gateway로 운영하고 있으며, Snowflake에 국한되지 않고 각종 툴과의 MCP 연결은 기본적으로 모두 MCPass를 통해 이루어지고 있습니다. MCPass에 대해서는 아래 슬라이드도 참고해 주십시오.

MCPass에서는 과잉 권한 대응으로 다음과 같은 노력을 하고 있습니다. OAuth로 사용자의 모든 권한을 부여하는 것이 아니라, 서비스별로 필요한 최소한의 권한을 가진 인증 정보를 개별적으로 발행하고 있습니다.

서비스	대응 방법
GitHub	개인 PAT를 발급받아 PAT의 권한을 최소화하도록 요청
...
Google Drive와 Slack에 대한 자세한 내용은 각각 아래 기사에서 소개하고 있습니다.

Cortex AI Gateway

이 영역에 대해서는 Snowflake 측에서도 Cortex AI Gateway가 발표되었습니다.

2026년 5월, Snowflake가 인수 의향을 밝힌 Natoma의 MCP Gateway를 기반으로 합니다.
2026년 7월 Black Hat USA 2026에서 발표됩니다.
2026년 9월에 Cortex AI Gateway 자체는 Public Preview가 되었으나, 2026년 10월 시점에서는 MCP의 거버넌스 기능이 아직 포함되어 있지 않습니다.

앞서 언급된 MCP Connector 기반의 세 가지 과제는 모두 Cortex AI Gateway에서 커버될 것으로 예상됩니다.

과제	Cortex AI Gateway에서의 대응
거버넌스	인증 및 세밀한 권한 부여(Authorization)
...
데이터의 거버넌스와 같은 장소에서 AI의 거버넌스도 적용할 수 있다는 점에 기대를 걸고 있으며, 정식으로 사용 가능해지는 것이 기대됩니다.

테이블화하는 방법

테이블화에 대한 생각

여기까지 소개된 MCP는 ' 에이전트가 컨텍스트를 가져간다'는 발상이었습니다. 또 다른 방식은 ' 미리 테이블로 넣어둔다'는 것입니다.

예를 들어 GitHub (dbt) / Google Drive / AWS (CloudWatch Logs)의 정보도 모두 Snowflake의 테이블에 가져다 놓을 수 있습니다. 에이전트 입장에서는 구조화된 데이터는 테이블로, 문서 같은 비구조적인 데이터는 Cortex Search를 통해 참조하는 이미지입니다.

테이블화의 장점과 단점은 다음과 같습니다.

장점 - 권한 관리는 Snowflake의 RBAC을 그대로 사용할 수 있음
SQL로 JOIN 및 집계가 가능하여, 교차적인 질문에 강함
단점 - 파이프라인 구축 및 유지보수가 필요함

컨텍스트 가져오기 방법

테이블화는 파이프라인을 구성하는 것만으로 구현할 수 있지만, 가져올 내용에 따라 방식이 다릅니다.

dbt 관련 정보 - Elementary를 사용하면 모델의 SQL 문자열이나 manifest / run results 내용을 테이블화할 수 있습니다.
manifest.json을 stage에 업로드하고, 이를 직접 참조하여 사용하기 편리하도록 테이블을 직접 만드는 것도 쉽게 구현할 수 있습니다.
이러한 정보는 에이전트 외의 용도로도 유용합니다.
AWS (CloudWatch Logs) / Google Drive - 자체 파이프라인이나 Openflow 등으로 가져옵니다.
테이블이나 Cortex Search Service에 보관해 두고, 에이전트가 참조하게 합니다.

Agents Schema

이 '테이블화'의 발상을 표준화하려는 움직임도 있습니다. dbt Labs에서 공개한 Agents Schema입니다.

생각하는 방식은 다음과 같습니다.

웨어하우스 내 1개의 스키마를 에이전트용 공유 컨텍스트 레이어로 사용합니다.
provider가 컨텍스트를 publish하고, 에이전트는 AGENTS.ROOT에서 discovery 합니다. - 에이전트가 읽는 것을 전제로 하므로, 반구조화 데이터여도 괜찮다는 타협입니다.

에이전트에게 전달할 컨텍스트의 위치를 규약으로 통일해 놓으면, 개별적으로 Connector를 만들어 넣지 않아도 discovery 할 수 있게 된다는 방향성은 흥미롭다고 느낍니다.

MCP와 테이블화의 사용처 비교

지금까지의 내용을 바탕으로, MCP로 가져갈 경우와 테이블에 넣어둘 경우를 비교하면 다음과 같습니다.

MCP로 가져가기	테이블에 넣어두기
초기 비용	연결만 하면 됨	파이프라인 구축/운영 필요
운영 부하	초기 설정 후 비교적 낮음	파이프라인에 따라 무거움
권한 관리	외부 시스템의 권한 모델에 의존	Snowflake의 RBAC이 그대로 적용됨
교차적인 집계	어려움 (순차적 툴 호출)	좋음 (SQL로 JOIN 및 집계)
최신성 (Freshness)	항상 최신	동기화 주기에 의존
대상 데이터량	필요한 만큼만 가져올 수 있음	전부 넣으면 스토리지 비용 발생
감사(Audit)	외부 시스템 측의 로그 / Gateway라면 그곳에 쌓임	`ACCESS_HISTORY`에서 추적 가능

이번 세 가지 종류의 컨텍스트에 대해, 저는 다음과 같이 생각합니다.

dbt 관련 정보: Elementary가 있으므로 테이블화하기 쉽고, manifest.json도 활용하기 쉬움 →테이블화 -
Google Drive: 문서는 MCP를 통해 가져오는 것이 유연해서 궁합이 좋음 →MCP -
AWS 로그: 단순한 로그라면 테이블화도 가능하지만, 내용에 따라 다름

요약

에이전트에게 전달하고 싶은 명세서·SQL·로그 같은 컨텍스트는 Snowflake 외부에 흩어져 있습니다. 컨텍스트를 전달하는 방식은 크게 ' MCP로 가져가기' 또는 ' 테이블에 넣어두기' 두 가지입니다. MCP Connector는 손쉽게 연결할 수 있는 반면 권한이나 관리에 과제가 있고, MCP Gateway나 Cortex AI Gateway로 묶어주는 것이 하나의 해결책이 됩니다. 테이블화는 파이프라인의 노력이 필요하지만, Snowflake의 RBAC이 그대로 적용되고 교차적인 질문에 강합니다.

둘 중 어느 한쪽에 고정하지 않고, 업데이트 주기·데이터량·권한 요건·교차 집계의 필요성 같은 컨텍스트의 성질에 따라 사용처를 구분합시다!