Snowflake Summit 2026: Cortex Sense·Horizon Context·AI Agent Identity로 에이전트 엔터프라이즈의 데이터 제어면을 다시 그은 방식

왜 지금 봐야 하나

2026년 6월 15~18일 샌프란시스코에서 열린 Snowflake Summit 2026에서 Snowflake는 AI 에이전트가 엔터프라이즈 데이터를 다루는 방식을 구조적으로 바꾸는 기능 묶음을 발표했다. 90일 이내(2026-07-28 기준으로 약 40일 전) 공개된 발표다.

단순히 SQL 보조 기능이 추가된 게 아니다. Summit의 핵심 메시지는 "AI 에이전트도 인간 사용자처럼 독립된 자격증명·권한·감사 경로를 가져야 한다"는 것이었다. Horizon Context, Cortex Sense, AI Agent Identity는 각각 독립 기능처럼 보이지만 하나의 흐름으로 읽어야 한다.

• Horizon Context는 테이블·컬럼에 비즈니스 의미를 붙인다.
• Cortex Sense는 그 의미를 런타임에 주입해서 자연어 질문의 정확도를 끌어올린다.
• AI Agent Identity는 에이전트마다 독립 자격증명과 RBAC을 부여해서 정확도가 높아진 에이전트가 과도한 권한으로 데이터를 탐색하지 못하게 막는다.

운영자 입장에서는 세 층을 함께 도입해야 Summit 발표의 실질적 가치가 나온다. 하나만 도입하면 절반짜리 효과를 본다.

Summit 2026 핵심 발표 요약

Horizon Context: 비즈니스 의미를 카탈로그 위에 얹는 새 레이어

Snowflake의 거버넌스 제품군은 기존에 Horizon Catalog였다. Horizon Catalog는 기술 메타데이터 레이어다. 테이블 스키마, 컬럼 타입, 데이터 계보(lineage), 접근 제어 정책, 분류 태그가 여기에 산다.

Summit에서 GA된 Horizon Context는 그 위에 얹히는 시맨틱 메타데이터 레이어다.

• 각 테이블·컬럼에 비즈니스 정의(예: "revenue는 신규 구독 ARR만 포함, 갱신 ARR 제외")를 붙인다.
• 테이블 간 비즈니스 관계("customers → subscriptions → invoices"의 계약 기준 조인 키)를 명시한다.
• 자주 묻는 비즈니스 질문 예시와 올바른 SQL 패턴을 함께 저장한다.
• 도메인 용어집(glossary)을 정의해서 "ARR"·"MRR"·"고객" 같은 단어가 어떤 테이블의 어떤 컬럼과 연결되는지를 기계가 읽을 수 있는 형태로 저장한다.

Horizon Context의 저장 위치는 Snowflake 오브젝트 레벨이라 기존 Role 기반 접근 제어를 그대로 쓴다. AI가 볼 수 있는 컨텍스트 범위도 GRANT/REVOKE로 제어한다.

이것이 중요한 이유는 Cortex Sense가 이 레이어를 소비하기 때문이다.

Cortex Sense: 런타임 컨텍스트 주입으로 정확도 24% → 86%

Cortex Analyst나 Cortex Search처럼 Snowflake의 AI 기능들은 자연어로 구조적 데이터에 질문을 던지는 패턴을 구현한다. 문제는 정확도였다.

Snowflake 내부 벤치마크에서 보고한 수치다.

• 컨텍스트 없이 LLM에 직접 질문: 정확도 24%
• Cortex Sense 적용 후: 86%

Cortex Sense의 작동 방식은 질문이 들어오는 시점(런타임)에 Horizon Context에서 관련 비즈니스 메타데이터를 동적으로 조회해서 LLM 프롬프트에 주입하는 것이다.

정적 시스템 프롬프트에 스키마를 통째로 넣는 방식과 다르다. Horizon Context에서 질문과 관련 있는 테이블·컬럼 정의·용어집 항목만 런타임에 선택해서 넣기 때문에 프롬프트 크기는 줄이면서 관련도는 높아진다.

운영 관점에서 중요한 것은 이 주입이 투명하게 일어난다는 점이다. Snowflake의 Query History와 Cortex Audit Log에 어떤 컨텍스트가 주입됐는지 기록된다.

아키텍처: 에이전트 질의 흐름

AI Agent Identity GA: 에이전트마다 독립 자격증명과 감사 경로

기존 Snowflake 접근 모델은 사람(human user)을 기준으로 설계됐다. AI 에이전트가 Snowflake에 접근할 때는 사람의 세션 자격증명이나 서비스 계정을 빌려 썼다. 이는 두 가지 문제를 만든다.

1. 권한 과도: 에이전트가 쿼리를 실행하면 그 쿼리는 사람의 전체 권한으로 실행된다.
2. 감사 불투명: Access History에 "사람 A가 접근했다"고 기록될 뿐, 어떤 에이전트가 어떤 판단으로 접근했는지 추적이 안 된다.

Summit에서 GA된 AI Agent Identity는 에이전트 인스턴스를 Snowflake의 1급 신원(principal)으로 만든다.

• 암호화 바인딩 자격증명: 각 에이전트 인스턴스가 고유한 암호화 키에 바인딩된 신원을 가진다. 세션 토큰을 훔쳐도 다른 에이전트 신원으로 사용할 수 없다.
• per-agent RBAC: 에이전트마다 독립 롤을 부여한다. 에이전트 A에게는 sales_data_reader 롤, 에이전트 B에게는 inventory_reader 롤처럼 최소 권한 원칙을 에이전트 단위로 적용한다.
• Access History 에이전트 열: Snowflake의 Access History 뷰에 agent_name·agent_version 컬럼이 추가된다. 어떤 에이전트가 어떤 테이블·컬럼을 읽었는지 행 단위로 감사할 수 있다.
• 감사 비교: 인간 사용자의 접근과 에이전트의 접근이 Access History에서 명확히 구분된다.

운영 함의: AI Agent Identity를 도입하면 에이전트 롤 설계가 새로운 운영 과제가 된다. 에이전트 롤은 일반 서비스 계정처럼 광범위하게 줘서는 안 된다. 에이전트가 실제로 필요한 테이블·뷰·함수만 GRANT해야 한다.

Apache Iceberg v3 GA: Snowflake 관리 오픈 포맷

Summit에서 Snowflake는 Apache Iceberg v3를 Snowflake 관리 테이블에서 GA로 지원한다고 발표했다.

Iceberg v3의 주요 신기능(Snowflake 지원 범위):

• Deletion Vectors GA: 기존 Parquet 파일을 재작성하지 않고 별도 삭제 벡터 파일에 삭제 마킹만 기록한다. UPDATE/DELETE 워크로드에서 쓰기 증폭이 줄고 파일 병합(compaction) 빈도가 낮아진다.
• Row Lineage: 각 행이 어느 오퍼레이션으로 생성됐는지 추적하는 메타데이터. CDC 기반 증분 처리에 유용하다.
• Snowflake-managed Iceberg storage: Snowflake가 Iceberg 메타데이터뿐 아니라 오브젝트 스토리지도 관리한다. 외부 S3/GCS 버킷을 직접 관리할 필요 없이 Snowflake가 스토리지 레이아웃을 최적화한다. 단, 열람은 표준 Iceberg REST Catalog API로 외부 엔진(Spark, Trino, Flink 등)에서도 가능하다.
• 크로스엔진 쓰기: Databricks Unity Catalog Managed Iceberg와 유사하게, Snowflake 관리 Iceberg 테이블에 외부 엔진이 쓸 수 있는 경로를 열었다(Iceberg REST Catalog를 통한 credential vending).

Snowflake Intelligence와 Cortex Code GA

Snowflake Intelligence는 Snowflake 내부 개발 코드명 CoWork로 알려진 멀티에이전트 오케스트레이션 기능의 GA 이름이다.

• 여러 특화 에이전트(예: 매출 분석 에이전트, 인벤토리 에이전트, 고객 CS 에이전트)를 하나의 워크플로로 연결한다.
• 에이전트 간 핸드오프, 병렬 실행, 결과 집계가 Snowflake 내부에서 일어난다.
• AI Agent Identity와 통합되어 각 에이전트 스텝이 독립 감사 경로를 갖는다.

Cortex Code는 내부 코드명 CoCo로 개발된 SQL·Python 코드 생성 어시스턴트다.

• Snowsight(Snowflake 웹 UI)에 통합된다.
• 자연어로 분석 요구를 설명하면 SQL 또는 Python 코드를 생성한다.
• Horizon Context를 참조해서 테이블·컬럼 이름을 정확하게 생성한다.
• 생성된 코드는 실행 전에 사람이 검토하는 "코파일럿" 방식이다.

Cortex Training: Snowflake 경계 내 파인튜닝

Cortex Training은 Summit에서 Preview로 공개됐다.

기존 Cortex AI 기능들은 외부 LLM(GPT-4o, Claude, Mistral 등)을 API로 호출하거나 Snowflake 관리 모델을 그대로 사용했다. Cortex Training은 Snowflake에 저장된 데이터로 파운데이션 모델을 파인튜닝해서 사용자 Snowflake 계정 내에 두는 기능이다.

핵심 제약: 파인튜닝 데이터가 Snowflake 보안 경계를 벗어나지 않는다. 이는 의료·금융처럼 데이터 이동이 규제되는 업종에서 중요하다.

지원 베이스 모델은 오픈소스 계열(Llama 패밀리 등)로 시작한다. 독점 외부 모델 파인튜닝은 지원 범위 밖이다.

Natoma 인수와 MCP 거버넌스

Summit 직전 Snowflake는 MCP(Model Context Protocol) 거버넌스 스타트업 Natoma를 인수했다고 발표했다.

MCP가 확산되면서 에이전트가 사용할 수 있는 외부 도구(MCP 서버)가 폭발적으로 늘었다. 문제는 어떤 에이전트가 어떤 MCP 서버에 접근할 수 있는지, MCP 도구 호출이 어떻게 감사되는지에 대한 제어가 없다는 점이었다.

Natoma 기술을 통합하면:

• Snowflake 관리자가 에이전트별로 허용 MCP 서버 목록을 정책으로 설정할 수 있다.
• 에이전트의 MCP 도구 호출이 Snowflake Access History에 기록된다.
• MCP 서버 응답에 포함된 데이터도 Snowflake 데이터 분류 정책의 적용 범위로 들어온다.

통합 완료 시점은 공개되지 않았다(통합 진행 중).

Adaptive Compute: 동적 웨어하우스 크기 조정

GA된 Adaptive Compute는 웨어하우스 크기를 쿼리 복잡도에 따라 런타임에 자동 조정한다.

기존 모델은 XS/S/M/L/XL처럼 사전 정의 크기(고정 credit/hour)로 웨어하우스를 선택한다. Adaptive Compute는 쿼리 시작 전에 예상 복잡도를 평가하고 실제 필요한 노드 수만 할당한다.

• 단순 집계 쿼리: 소규모 리소스 → credit 소모 감소
• 복잡한 조인·윈도우 함수: 필요한 만큼 확장

운영 관점에서 이 기능은 웨어하우스 크기 선택 실수(너무 크게 설정해서 credit 낭비)를 줄인다. 단, 예측 실패 시 쿼리 중간에 리소스가 부족해질 수 있는 경우도 있으므로 SLA가 엄격한 워크로드에서는 수동 크기 지정을 유지하는 것이 안전하다.

운영 관점 체크리스트

Horizon Context 도입 순서

1. 핵심 비즈니스 테이블(ARR·매출·고객 정의가 자주 혼동되는 테이블)부터 비즈니스 정의를 작성한다.
2. 용어집(glossary)을 먼저 만들고 테이블 정의에서 용어집 항목을 참조한다.
3. Horizon Context GRANT를 에이전트 롤 단위로 설정한다. 에이전트가 볼 수 있는 비즈니스 정의 범위가 실제 데이터 접근 권한과 일치해야 한다.

AI Agent Identity 전환 체크리스트

• 기존 서비스 계정으로 동작하는 에이전트를 목록으로 만든다.
• 각 에이전트가 실제로 접근하는 테이블·뷰·함수를 Access History로 확인한다.
• 최소 권한으로 에이전트 전용 롤을 만든다.
• AI Agent Identity로 전환 후 기존 서비스 계정의 불필요한 권한을 회수한다.

Iceberg v3 + Deletion Vector 도입 주의사항

• Deletion Vector를 쓰는 테이블을 읽는 외부 엔진이 Iceberg v3를 지원하는지 먼저 확인한다.
• Spark 3.5+, Trino 471+, Flink 1.20+은 Iceberg v3 읽기를 지원한다(쓰기 지원 수준은 엔진별로 다름).
• 삭제 벡터 파일이 쌓이면 읽기 때 Merge-on-Read 비용이 생긴다. 주기적 compaction이 여전히 필요하다.

Cortex Sense 정확도 검증 방법

Snowflake는 내부 벤치마크 24%→86%를 제시하지만, 실제 조직의 수치는 다르다. Cortex Sense 도입 후 다음으로 검증한다.

• 반복적으로 틀리는 자연어 질문 패턴 10~20개를 수집한다.
• 같은 질문을 Cortex Sense 켬/끔으로 A/B 비교한다.
• 틀린 경우 Horizon Context의 어느 정의가 누락됐는지 분석하고 추가한다.

Open question

• Cortex Training의 비용 모델이 공개되지 않았다. 파인튜닝 컴퓨팅을 credit으로 청구하는지, 별도 요금제인지 확인이 필요하다.
• Streaming Feature Views의 레이턴시 SLA 수치가 공개 자료에 없다. Kafka/Kinesis 소스에서 실제 e2e 레이턴시를 Preview 기간에 측정해야 한다.
• AI_COMPLETE 오디오·비디오 지원이 Preview로 공개됐으나 지원 포맷(코덱·최대 파일 크기) 문서가 부족하다.
• Natoma 통합 일정이 미공개다. MCP 거버넌스 정책 API가 언제 안정화될지 Snowflake 공식 릴리스 노트를 추적해야 한다.

References

• Snowflake Summit 2026 Keynote Recap
• Cortex Sense 공식 문서 (Snowflake Docs)
• Horizon Context 개요 (Snowflake Docs)
• AI Agent Identity (Snowflake Docs)
• Apache Iceberg v3 on Snowflake (Snowflake Blog, June 2026)
• Snowflake acquires Natoma for MCP governance (TechCrunch, June 2026)
• Adaptive Compute GA Announcement (Snowflake Blog)