서론

Snowflake는 2026년 5월~7월에 걸쳐, 지난 분기에 '갖추었던' 기능군을 제품 및 운영 측면에서 한 단계 더 성숙시켰습니다. 방향성은 다음의 3가지 포인트입니다.

AI의 에이전트화 (Agentization): Cortex AI 함수의 통제(Q1)에서 한 걸음 나아가, **Snowflake CoWork (구 Snowflake Intelligence)**와 **CoCo (구 Cortex Code)**의 리브랜딩(6월 Summit)을 통해 에이전트 제품의 윤곽이 확정되었습니다. **Cortex AI Guardrails의 보호 대상이 Cortex Agents / CoWork로 확대(5/14 GA)**되었으며, AI 에이전트 전용인 **SERVICE_AGENT 사용자 유형(7/23 GA)**도 등장했습니다 -
오픈화의 "완성"과 동적 테이블/컴퓨트의 성숙: **Apache Iceberg v3가 Q1의 Preview에서 GA로 승격(5/7)**되었습니다. 동적 테이블(Dynamic Tables)은 adaptive refresh / frozen regions / pass-through 정책 / 레플리케이션(Replication) 등 운영 기능이 모두 갖춰졌으며, **Adaptive Compute (6/16 GA)**를 통해 웨어하우스(Warehouse)의 사이즈 관리 자체가 불필요해지기 시작했습니다 -
제로 트러스트(Zero Trust)/거버넌스의 표준화: Workload Identity Federation (아웃바운드, 7/1 GA)과 OIDC 페더레이션 인증 (7/20 Public Preview)을 통해 장기 시크릿리스(Secretless) 인증이 진전되었습니다. 분류(Q1) → 가시화(액세스 리포트) → 보호(데이터 보호 정책) → 경량 분류(메타 데이터베이스)로 이어지는 **거버넌스 파이프라인(Governance Pipeline)**이 반년 만에 완성되었습니다.

지난 Q1 총괄(2026년 1~4월)에서는 "AI 실전화·오픈화·보안 성숙"의 3대 축을 제시했습니다. 본 기사는 그 후속편이지만, 단독으로도 읽을 수 있는 구성으로 작성되었습니다.

이 기사에 대하여

이 기사에서 알 수 있는 것

• 2026년 5~7월의 주요 릴리스와 시계열
• "AI의 에이전트화·오픈화의 완성·제로 트러스트 표준화"의 3대 축 트렌드 분석
• 기능별 채택 판단 (언제, 누가, 무엇에 사용해야 하는가)
• 지난 분기(Q1) 예측에 대한 확인 및 2026년 하반기 전망

예상 독자

• Snowflake의 기본 조작은 이해하고 있으나, 최신 기능의 캐치업(Catch-up)이 되지 않은 데이터 엔지니어
• 릴리스 노트를 따라갈 시간이 없거나, 우선순위 판단에 어려움을 겪는 사람
• 2026년 하반기 데이터 기반 전략을 세우고자 하는 의사 결정자

용어의 전제

5~7월 주요 릴리스 시계열

"2026년 하반기를 향해 무엇이 제품화되었고, 무엇이 실전 사용을 전제로 하게 되었는가"를 월별로 정리합니다 (전체 조망은 그림 1).

図1: 2026年5〜7月のリリースタイムライン俯瞰図

그림 1: 2026년 5~7월의 Snowflake 주요 릴리스 타임라인. 월별로 "AI의 에이전트화", "오픈화/데이터 기반", "제로 트러스트/거버넌스"의 3대 축으로 주요 릴리스를 조망.

2026년 5월: Iceberg v3 GA + AI 함수 확충 + 데이터 보호 가시화

2026년 6월: Summit에서의 에이전트 제품화 + Adaptive Compute

2026년 7월: 키리스(Keyless) 인증의 진전 + 동적 테이블(Dynamic Table) 운영의 마무리 + 에이전트의 일상화

7월의 포인트: 인증은 WIF (아웃바운드) / OIDC / 이름 지정 키 쌍 (Named Key Pair) / SERVICE_AGENT를 통해 '키리스(Keyless)·단기(Short-lived)·ID 명시화' 방향으로 일치되었으며, 동적 테이블은 frozen region에 대한 DML / pass-through 정책으로 운영의 세부 사항이 완성되었습니다. CoWork/CoCo는 Deep Research·모바일·데스크톱 앱을 통해 일상적인 도구로의 진화가 진행되었습니다.

횡단적 트렌드 분석 (3대 축)

트렌드 1: AI의 에이전트화 ("함수를 통제하는 것"에서 "에이전트를 운영 환경에서 실행하는 것"으로)

무엇이 변했는가

Q1(14월)에 Cortex AI 함수군이 GA되어, Guardrails / Budgets / AI_FUNCTIONS_USER를 통한 "통제" 레이어가 갖춰졌습니다. Q2(57월)는 그 위에서 에이전트가 제품으로서 전면에 등장한 분기입니다 (진화 흐름은 그림 2 참조).

図2: AI機能の進化 — 関数GA(Q1)→統制(Q1)→エージェント製品化・専用ID(Q2)

그림 2: AI 기능의 진화 축. Q1에서 함수의 GA와 통제(Guardrails/Budgets/RBAC)가 갖춰졌고, Q2에서 에이전트 제품(CoWork/CoCo)의 브랜드 확정·Guardrails 확대·전용 ID(SERVICE_AGENT) 단계에 도달.

에이전트 제품의 리브랜딩 (6월 Summit, 6/1~4): **Snowflake CoWork (구 Snowflake Intelligence)**가 분석 에이전트, **CoCo (구 Cortex Code)**가 코딩 에이전트라는 역할 분담이 명확해졌습니다 -
에이전트의 운영(Production) 기능: CoWork의 Deep Research (7/7 GA, 여러 에이전트 병렬 실행 + 인용 포함 보고서), Artifacts (6/17 GA, 대화 내 파일 생성), iOS 모바일 (7/13 GA), CoCo Desktop (7/21 GA) 등 일상적으로 사용하는 경로가 갖춰졌습니다 -
통제의 확대: Cortex AI Guardrails가 Cortex Agents / CoWork로 확대 (5/14 GA). 4월 GA 시점에는 CoCo (구 Cortex Code)에 한정되었던 보호 기능이 에이전트 전반으로 확장되었습니다. CORTEX_AI_GUARDRAILS_USAGE_HISTORY

뷰(6/16)에서 이용 상황 감사도 가능해짐 -
전용 ID와 세밀한 권한: **SERVICE_AGENT 사용자 유형(7/23 GA)**을 통해 AI 에이전트에 인간 사용자와 분리된 전용 ID를 부여. **per-function 권한(5/13 GA)**으로 AI 함수별로 액세스 제어 -
AI 함수의 확충: AI_EXTRACT의 추출 스코어(5/22 GA), AI_CLASSIFY의 문서 분류(5/13 PuPr), Batch Cortex Search(5/18 GA), AI Function Studio(5/20 PuPr), Gemini 3.5 Flash 지원(5/28 GA), SHOW CORTEX BASE MODELS (7/23 GA)

실무 설계 포인트

AI 에이전트에는 SERVICE_AGENT로 전용 ID를 부여한다-
인간 사용자의 계정을 에이전트에 유용하지 않는다. SERVICE_AGENT를 사용하면 권한 및 감사 로그를 에이전트 단위로 분리할 수 있으며, 이는 제로 트러스트 (Zero Trust) 설계와도 일치한다.

Guardrails는 계정 수준에서 일괄 활성화한다-
AI_SETTINGS 파라미터로 CoWork / Cortex Agents를 포함하여 일괄 제어할 수 있다. 사내의 프롬프트 운영 규칙은 별도로 필요하다.

CoWork와 CoCo를 혼동하지 않는다-
CoWork = 분석 (자연어 → 거버넌스가 적용된 답변/액션), CoCo = 코딩. 도입 상담 및 권한 설계 시 이름을 혼동하지 않도록 주의할 것.

SHOW CORTEX BASE MODELS로 모델 현황 파악을 습관화한다-
사용 가능한 기반 모델(Foundation Model)과 라이프사이클 (lifecycle: GA / preview / legacy / EOL 등)을 목록으로 확인할 수 있다. 모델의 EOL에 대비하여 정기적으로 확인하는 운영 방식이 현실적이다.

• 모델 목록은 매일 자동으로 업데이트됩니다. 새로 추가된 모델을 즉시 반영하고 싶은 경우에만, ACCOUNTADMIN이 CALL SNOWFLAKE.MODELS.CORTEX_BASE_MODELS_REFRESH();를 온디맨드(on-demand)로 실행할 수 있습니다 (구문의 세부 사항은 공식 SQL Reference에서 최신 정보를 확인하십시오).

트렌드 2: 오픈화의 "완성"과 동적 테이블(Dynamic Tables)/컴퓨트(Compute)의 성숙

무엇이 바뀌었나

Q1에서 Preview 단계였던 Iceberg v3가 **GA(5/7)**가 됨에 따라, Snowflake에서의 Iceberg는 "검증 대상"에서 "운영 환경의 선택지"로 바뀌었습니다. 동시에, 동적 테이블과 컴퓨트의 운영 기능이 완성되었습니다.

Iceberg (오픈 포맷의 운영 환경 적용):

동적 테이블 (선언적 파이프라인의 운영 기능 완비):

컴퓨트 (Compute):

Adaptive Compute (6/16 GA): 웨어하우스(Warehouse)의 크기, 멀티 클러스터(Multi-cluster) 설정, 성능 튜닝을 수동으로 관리하지 않고, Snowflake가 리소스 할당, 쿼리 라우팅(Query Routing), 스케일링(Scaling)을 자동으로 판단합니다. 모든 작업을 계정 수준의 공유 컴퓨트(Shared Compute)로 풀링(Pooling)합니다.

실무 설계 포인트

Iceberg를 「PoC」에서 「신규 테이블의 선택지」로 격상하여 검토할 것

• v3가 GA(General Availability)가 됨에 따라, 신규 테이블 생성 시 「Snowflake 네이티브인가 Iceberg인가」를 선택하는 판단이 현실적이 되었습니다.

• 단, 외부 엔진으로부터의 **v3 쓰기(Write)**는 미지원 등 제약 사항이 남아 있으므로, 요구사항(어떤 엔진에서 읽고 쓸 것인지)을 먼저 확정해야 합니다.

동적 테이블(Dynamic Table)은 REFRESH_MODE = ADAPTIVE를 평가할 것

• 차분 업데이트(Incremental Update)와 전체 재초기화(Full Re-initialization)의 전환을 자동화할 수 있습니다. 재초기화 시에만 큰 웨어하우스를 할당하는 INITIALIZATION_WAREHOUSE와 병용하면 비용과 데이터 신선도(Freshness) 사이의 균형을 맞추기 쉽습니다.

Adaptive Compute는 「웨어하우스 튜닝으로부터의 졸업」을 위한 첫걸음으로 검증할 것

• 사이즈 선정이나 멀티 클러스터 설정에 시간을 많이 할애해 온 환경일수록 효과를 보기 쉽습니다. 우선 제공되는 리전을 확인하고, 비프로덕션(Non-production) 워크로드에서 동작을 파악하십시오.

트렌드 3: 제로 트러스트/거버넌스의 표준화 (키리스 인증 + 분류 → 보호 파이프라인)

무엇이 변했는가

인증은 「장기 키/패스워드를 보관하지 않는」 방향으로, 거버넌스는 「분류하고 끝내는 것」에서 「보호까지 자동으로 연결하는」 방향으로 각각 표준화가 진행되었습니다.

인증 (키리스·단기·ID 명시화):

Workload Identity Federation (아웃바운드, 7/1 GA): Snowflake 자체가 OIDC 프로바이더(Provider)가 되어, Snowflake 내부의 워크로드가 외부 서비스로 키리스 인증(CREATE SECRET ... TYPE = WORKLOAD_IDENTITY_FEDERATION)을 수행합니다. 기존의 「외부 → Snowflake」 방식인 인바운드 WIF와 합쳐져 양방향으로 시크릿리스(Secretless) 환경을 구현합니다.

• OIDC 페더레이션 인증 (7/20 PuPr): 인간 사용자의 SSO를 OIDC로 수용합니다. SAML 중심이었던 페더레이션에 업계 표준 선택지가 추가되었습니다.
• JWT를 통한 AWS Workload Identity (5/12 GA) / 이름 있는 키 페어(Named Key Pair) 관리 (7/15 GA) / SERVICE_AGENT (7/23 GA): 키의 수명을 단축하고 ID를 명시화하는 흐름입니다.

거버넌스 (분류 → 가시화 → 보호 → 경량 분류):

• Q1이 「기밀 데이터를 찾는」 단계(분류 기능의 확장)였다면, 5~7월에는 그 위에 3개의 레이어가 쌓였습니다.
• 가시화 (리포트): Sensitive Data Entitlement 리포트 (5/13 PuPr, 누가 「액세스할 수 있는가」) 및 Access 리포트 (5/28 PuPr, 누가 「액세스했는가」)
• 보호의 일원화 (정책): Snowsight의 데이터 보호 정책 (5/27 PuPr, 마스킹/행/열/집계/조인 일원 관리) 및 태그 기반 버전 (7/21 PuPr)
• 분류의 경량화: 메타데이터베이스 기밀 분류 (7/2 PuPr, 실제 데이터를 스캔하지 않고 컬럼명 등으로 「기밀을 포함할 가능성이 있는 DB」를 추천)

실무 설계 포인트

장기 키를 WIF / OIDC로 이행하는 계획을 세울 것

• 패스워드, API 키, 장기 키 페어는 WIF(서비스 간)와 OIDC(사용자 SSO)로 대체할 수 있는 영역이 늘어났습니다. 현황을 파악하여 「아직 장기 키에 의존하고 있는 부분」을 식별하십시오.

AI 에이전트는 SERVICE_AGENT, 사람은 OIDC/WIF로

• 증가하는 에이전트에 인간 사용자의 권한을 유용하지 않고, 전용 ID를 부여함으로써 감사(Audit)와 권한 관리를 명확히 합니다.

「분류 → 태그 → 정책 자동 적용」을 하나의 설계로 구축할 것

• 분류 결과를 태그로 반영하고, 태그 기반 데이터 보호 정책(7/21 PuPr)으로 자동 적용하는 흐름을 설계하십시오. 메타데이터베이스 분류(7/2 PuPr)는 대규모 환경에서 분류 대상을 좁혀가는 전 단계로 활용하십시오.

실무 임팩트 평가 (채택 판단 기준)

2026년 5~7월의 주요 기능에 대해 「언제」 「누가」 「무엇에」 사용해야 하는지를 정리합니다 (지난 호는 검증/스테이징/운영의 3단계였으나, 이번 호는 검증·운영의 2단계로 간략화하였습니다).

Q1 → Q2의 연결: 「정렬된」 것이 「제품·운영」이 되었다

지난 Q1 총괄에서 제시한 3대 축이 5~7월에 어떻게 진화했는지 정리합니다.

이전 예측에 대한 정답을 확인해 보면, **"Iceberg가 기본 테이블 포맷에 가까워진다"**는 v3 GA(5/7)를 통해 한 걸음 전진했으며, **"AI의 SRE 프랙티스 (예산·감사·권한) 표준화"**는 Guardrails 확대, SERVICE_AGENT, 함수별 (per-function) 권한을 통해 구체화되었습니다.

2026년 하반기 트렌드 예측

예측 1: 에이전트 (CoWork/CoCo)가 일상적인 도구가 되고, 통제도 표준화될 것이다

• Deep Research·모바일·데스크톱 앱에서 에이전트가 "가끔 사용하는 것"에서 "일상의 입구"가 될 전망
• SERVICE_AGENT를 통한 전용 ID, Guardrails의 계정 일괄 제어, 이용 이력 뷰를 통해, **"에이전트의 SRE 프랙티스"**가 표준 규칙으로 정비되는 방향

예측 2: Iceberg + Adaptive Compute를 통해 "포맷도 컴퓨팅도 의식하지 않는" 방향으로

• Iceberg v3 GA와 Adaptive Compute GA에 의해, "테이블 형식"이나 "웨어하우스 크기"를 사람이 세세하게 결정해야 하는 부담이 줄어듦
• 신규 설계 시 "우선 Iceberg / 우선 Adaptive Compute"를 검토하는 흐름이 늘어날 것으로 예상됨 (제공 리전 및 제약 사항 확인은 계속 필요)

예측 3: 제로 트러스트 (키리스) + 분류 → 보호 자동화가 기본값이 될 것이다

• WIF (양방향)・OIDC・이름 지정 키 쌍 (Named Key Pair)・SERVICE_AGENT를 통해 "장기 시크릿을 보유하지 않는" 구성이 표준에 가까워짐
• 분류 → 태그 → 데이터 보호 정책 자동 적용 파이프라인이 거버넌스의 기본 구축 방식이 됨

요약

• 2026년 5~7월은 Snowflake가 AI의 에이전트화·오픈화의 완성·제로 트러스트 표준화를 선명히 한 기간
• 5월: Iceberg v3 GA. AI 함수의 확충과 데이터 보호의 가시화 (Entitlement/Access 리포트)
• 6월: Summit (6/1~4)에서 CoWork / CoCo로 리브랜딩. Adaptive Compute GA
• 7월: 키리스 인증 (WIF/OIDC/이름 지정 키 쌍/SERVICE_AGENT)과 동적 테이블 운영의 마무리, 에이전트의 일상화 (Deep Research/모바일/데스크톱)

Q1에서 "정렬한" 기능이 5~7월에 "제품·운영"으로서 성숙했습니다. 계속해서 정기적으로 Snowflake의 진화를 추적해 나가겠습니다.

참고 링크

공식 릴리스 노트 (AI의 에이전트화)