웨어하우스가 에이전트 제어면을 얻다: Snowflake의 thinking_effort, stage_mounts, 그리고 dbt의 Agents Schema

2026년 10월 28일, Snowflake는 Cortex Agents의 agent:run API에 세 가지 새로운 제어를 출시했습니다: thinking_effort, instructions.system, stage_mounts (Snowflake 릴리스 노트). 새로 탄생한 웨어하우스 런타임은 전통적으로 에이전트 플랫폼이 자기 손에 쥐고 있던 세 가지 — 모델이 얼마나 세게 추론하는지, 런타임이 어떤 하우스 룰을 강제하는지, 에이전트가 어떤 버전의 산출물을 마운트할 수 있는지 — 를 드러냅니다. 같은 달 Fivetran과 dbt Labs는 "신뢰할 수 있는 AI 에이전트를 위한 데이터 인프라를 만들자"는 명분으로 합병을 완료했고, 합병 플랫폼은 Agents Schema를 통해 에이전트에게 임시변통의 추출이 아니라 웨어하우스 네이티브 컨텍스트를 제공합니다 (Fivetran 보도자료).

이 글은 세 가지 Snowflake 제어면, 그 옆에 도착한 컨텍스트 계층, 그리고 닫히지 않는 경계 — 승인, 도구 간 정책, 감사 기록은 웨어하우스 위의 오케스트레이션 계층에 계속 속한다는 것 — 를 정리합니다. 하나의 Snowflake 계정, 두 명의 dbt 개발자, 예약 작업을 돌리기 시작한 에이전트를 둔 린 팀에게 이것은 처음으로 웨어하우스 내부에서 직접 설정할 수 있는 노브이며, 무엇을 묶고 무엇을 묶지 않는지 가리는 것이 거버넌스와 겉치레를 가르는 길입니다.

핵심 요점

• Snowflake는 2026년 10월 28일 세 가지 에이전트 제어를 출시했다 — thinking_effort(minimal에서 xhigh까지, 모델별 값의 부분집합), instructions.system(런타임 내부에 시스템 지시를 추가), stage_mounts(버전이 지정된 스테이지 마운트)가 Cortex agent:run API에 더해졌다 (Snowflake 릴리스 노트).
• stage_mounts는 산출물을 브랜치가 아니라 버전으로 묶는다 — 노트북, Streamlit 앱, 워크스페이스, 에이전트 자체가 버전이 지정된 스테이지로 마운트되고, 쓰기 가능한 workspace_mounts는 버전 live 그대로 유지된다 (Snowflake 릴리스 노트).
• dbt와 Fivetran은 합병을 완료하며 Agents Schema를 출시했다 — 합병 플랫폼의 선언된 목적은 "신뢰할 수 있는 AI 에이전트를 위한 데이터 인프라"이며, 거버넌스된 컨텍스트 행을 에이전트가 소비하는 위치에 둔다 (Fivetran 보도자료).
• dbt × Amazon Redshift 데이터 공유(dbt는 10월 9일, AWS는 빅데이터 블로그에서 문서화)는 바이트 하나 옮기지 않고 멀티 클러스터 파이프라인을 구동한다 — 거버넌스된 공유에 SVV_* 메타데이터 API와 datasharing 구성이 더해져 추출 후 복사 방식을 대체한다 (dbt 블로그; AWS 빅데이터 블로그).
• 노브가 묶는 것은 강도·지시·마운트 — 정책이 아니다 — 웨어하우스, NetSuite, HubSpot, 그리고 에이전트가 닿는 나머지 시스템에 걸친 승인, 취소, 감사는 오케스트레이션 계층에 남는다.

10월 28일에 무엇이 출시되었고 각 제어는 어디에 놓이는가

thinking_effort는 추론 강도 노브다: minimal에서 xhigh까지의 범위에, 주어진 모델이 받아들이는 값을 제한하는 모델별 부분집합이 붙는다. 실무적으로, 이것은 모델 노력을 API 쪽 기본값에서 웨어하우스가 실행마다 기록하는 실행 단위 설정으로 옮기는 호출이다. 신선도 테이블을 읽는 예약 에이전트에 인보이스 명세를 대조하는 에이전트와 같은 노력 예산이 필요하지 않다; 10월 28일까지는 그 구분이 모델을 호출하는 하네스에 살았지만, 이제는 실행의 선언된 매개변수로 웨어하우스가 집행한다.

instructions.system은 런타임 내부에 시스템 지시를 덧붙인다. 이것이 하우스 정책의 슬롯이다: 모든 에이전트 실행에 붙여 두고 싶은 조직의 규칙 — 무엇을 요약할 수 있는지, 무엇을 사람에게 플래그해야 하는지, 빠진 컨텍스트를 어떻게 다뤄야 하는지 — 는 에이전트를 만든 이의 프롬프트 템플릿에 방치되는 대신 호출과 함께 이동한다. 정직하게 짚어 둘 지점이 있다: 추가된 지시는 퍼미션 시스템이 아니다. 런타임 내부의 행동을 깎는다; 무엇도 박탈하지 않는다.

stage_mounts는 산출물 경계다. agent:run API가 이제 버전이 지정된 스테이지 마운트 — 노트북, Streamlit 앱, 워크스페이스, 그리고 에이전트 자체 — 를 받아들이고, 쓰기 가능한 workspace_mounts는 버전 live 그대로다. 버전이 지정된 스테이지에 묶인 에이전트가 보는 것은 브랜치의 지금 이 순간이 아니라 핀박된 산출물 집합이다. 이것은 파이프라인 피닝과 매니페스트 피닝이라는 에이전트 스택 다른 곳의 직감이, 산출물이 실제로 사는 웨어하우스 경계에서 표현된 것이다.

아래 다이어그램은 세 가지 제어면을 그 위아래 계층 — 정책이 머무는 오케스트레이션 계층, 도착 중인 컨텍스트와 데이터 이동 계층 — 에 대비해 펼쳐 보인 것이다.

컨텍스트 계층이 먼저 도착했다

제어는 비교 대상이 있어야 의미가 있는데, 그 대상은 먼저 컨텍스트 쪽에 도착했다. Fivetran과 dbt Labs는 합병을 완료하며 명확한 논제를 내놓았다: 합병 회사의 존재 목적은 "신뢰할 수 있는 AI 에이전트를 위한 데이터 인프라를 만드는 것"이다 (Fivetran 보도자료). Agents Schema는 이 논제를 웨어하우스로 가져온다 — SQL 엔드포인트를 향해 손으로 헤매며 에이전트가 조립하는 임시 추출이 아니라, 대시보드가 메트릭 테이블을 소비하듯 에이전트가 소비하는 거버넌스된, 모델링된 행이다.

데이터 이동의 문제도 같은 대접을 받았다. dbt는 이제 Amazon Redshift 데이터 공유를 지원하고, AWS 빅데이터 블로그가 멀티 클러스터 패턴 — SVV_* 메타데이터 API와 datasharing 구성으로 바이트 하나 복사하지 않고 멀티 클러스터 파이프라인을 짓는 — 을 문서화했다 (dbt 블로그; AWS 빅데이터 블로그). 에이전트에게 이것은 환경이 거버넌스된 공유 — 리니지와 접근 규칙이 유지되는 곳 — 로 조립되는 것과 추출 — 모든 복사본이 새 접근 질문 — 으로 조립되는 것의 차이다. Dagster가 같은 논제를 중심으로 스스로를 다시 정위하는 것("Data your team trusts. AI that runs on it.")은 울타리의 오케스트레이터 쪽에서 같은 말을 하는 것이다 (Dagster).

세 개의 면을 함께 읽으면 하나의 패턴이 나온다: 컨텍스트는 모델링되는 곳에서 거버넌스되고, 이동은 공유되는 곳에서 거버넌스되며, 강도·지시·마운트는 실행이 일어나는 곳에서 거버넌스된다. 에이전트 플랫폼이 지금까지 제각기 전용 코드로 답해 온 질문에 대한 웨어하우스 우선의 답이다.

노브가 막지 못하고 남겨 둔 것

제어가 묶지 않는 것은 시스템 간 정책이다. 웨어하우스의 가격 모델을 읽고, BigCommerce 재고를 확인하고, 승인된 견적을 NetSuite에 써 넣는 에이전트는 세 개의 벤더 경계와 하나의 프로토콜 경계를 넘는다. Snowflake 매개변수가 거버넌스하는 것은 그중 정확히 하나의 경계다; 릴리스 노트 어디에도 BigCommerce 토큰을 박탈하는 것은 없고, instructions.system이 NetSuite 안에 감사 레코드를 만들지도 않는다. 승인, 취소, 그리고 하나의 도구 간 감사 기록은 오케스트레이션 계층 — 각 시스템을 각자의 인증과 로깅을 지닌 타입화된 도구로 감싸는 모듈 패턴 — 에 살아야 한다 (MCP 모듈 코드 표준).

정직하게 하지 않으면 안 될 한계가 있다: 릴리스 노트가 문서화한 것은 매개변수이지 보증이 아니다. agent:run 호출의 감사 행동 — 무엇이 기록되고, 보존되고, 질의 가능한지 — 는 우리가 검토했던 노트에 규정되어 있지 않고, 모델별 부분집합 지원은 어떤 팀의 xhigh가 다른 팀에는 불가능한 설정이라는 뜻이다. 세 가지 제어를 선언된 입력으로 다루고, 자기 계정에서 감사 기록을 검증하고, 킬 스위치는 웨어하우스 위에 두자 (AI 거버넌스 체크리스트).

린 팀의 관점

웨어하우스를 향해 첫 예약 에이전트를 돌리기 시작한 중견 팀에게 10월 28일은 시작 대화를 다섯 곳에서 바꾼다. 어떤 에이전트가 웨어하우스에 접촉하는지 실사하라 — 예약된 것부터. thinking_effort를 워크로드별로 의식적으로 설정하라: 신선도 확인은 minimal, 대조는 더 높은 강도로, 어떤 작업이 어떤 예산을 받았는지 기록하라 — 이 대응표가 곧 단위당 비용 이야기다. 하우스 정책은 instructions.system에 한 번 넣어 둬라, 프롬프트 템플릿마다 따로 관리하지 말고. 예약 에이전트는 버전이 지정된 스테이지 마운트에 묶어라, 에이전트가 읽는 Streamlit 대시보드가 누군가 테스트한 그 버전이 되도록 — 오늘 아침 바뀐 버전이 아니라. 그리고 승인과 취소는 오케스트레이터의 매니페스트에 남겨라 — 웨어하우스가 제어하는 것은 실행이 어떻게 보이는지이고, 오케스트레이터가 제어하는 것은 실행에 무엇이 허용되고 무엇을 남기는지다.

함께 읽기

• 에이전트 오케스트레이션 데이터 파이프라인: Dagster + dbt + MCP 스택 구축하기 — 빌드 쪽의 짝: Dagster, dbt, Snowflake를 에이전트가 호출하는 타입화된 도구로 감싸기
• 계단식으로 번지는 파이프라인 장애: 에이전트가 온콜 디버깅을 75% 줄이는 방법 — 이 제어들이 먹이를 주는 모니터링 계층, 8시간에서 2시간으로 온콜 기록 포함
• MCP 모듈 코드 표준 — 인증, 로깅, 정책을 오케스트레이터와 함께 모든 시스템에 유지하는 구조 패턴

---

Snowflake 계정 하나와 dbt 개발자 두 명을 둔 400명 규모 설비 유통업체가, 웨어하우스가 거버넌스하는 가격 모델을 읽는 견적 에이전트를 연결하고 있었다. 오케스트레이터 모듈이 세 가지 Snowflake 제어 — 워크로드별로 예산화된 추론 강도, 실행마다 덧붙여지는 하우스 정책, 에이전트가 읽는 산출물을 위한 버전이 지정된 스테이지 마운트 — 를 선언했고, 승인, 취소, 도구 간 감사 기록은 웨어하우스 위의 매니페스트에 남았다. 견적 에이전트의 비용은 작업 단위로 귀속 가능해졌고, 데이터 환경은 브랜치와 함께 표류하지 않게 되었다.

스코프 지정 구축 요청

1주일 디스커버리. 우리와 함께 구축하든 그렇지 않든, 시스템 인벤토리, 워크플로 지도, 고정 스코프를 얻게 된다.