Snowflake CoCo 확장, 카탈로그와 RBAC를 읽는 코딩 에이전트
Snowflake가 CoCo를 Desktop, CLI, SDK, Claude Code 플러그인으로 확장했습니다. 데이터 권한을 아는 코딩 에이전트 경쟁입니다.
- 무슨 일: Snowflake가 2026년 6월 2일 Summit 26에서
CoCo확장과 Datastream을 발표했습니다.- CoCo는 Cortex Code의 새 이름이며 Desktop, CLI, Snowsight, VS Code, Excel, Claude Code, SDK, MCP로 넓어집니다.
- 차별점: 일반 IDE 에이전트가 아니라 catalog, lineage, RBAC, compute, pipeline dependency를 읽는 데이터 에이전트입니다.
- 실무 영향: 비교 기준은 모델 이름보다 권한 경계, SQL 실행, 감사 로그, 실시간 데이터 freshness로 이동합니다.
- Agent SDK는 Python·TypeScript에서 파일, shell, code edit, SQL, MCP, hooks, approvals를 같은 agent loop로 엮습니다.
Snowflake가 2026년 6월 2일 Snowflake Summit 26에서 CoCo의 새 기능과 Snowflake Datastream을 발표했습니다. CoCo는 기존 Cortex Code의 새 이름입니다. Snowflake는 이를 데이터 엔지니어링, 분석, ML 파이프라인, 앱, 에이전트를 만드는 data-native AI coding agent로 설명합니다. 발표의 표면은 Desktop 앱과 확장 프로그램이지만, 개발팀이 봐야 할 변화는 agent가 Snowflake catalog, lineage, RBAC policy, compute, pipeline dependency를 읽고 작업한다는 점입니다.
CoCo는 이제 Snowflake 안팎의 여러 작업 표면으로 퍼집니다. Snowflake 발표문은 native desktop app, mobile app experience, Slackbot, VS Code Extension, Microsoft Excel Extension, Claude Code plugin을 언급했습니다. Snowsight에서 시작한 작업을 cloud에서 계속 실행하는 Cloud Agents, recurring·event-driven workflow를 위한 Automations, Python과 TypeScript용 Agent SDK도 같은 묶음에 들어갑니다. 이 목록은 CoCo가 단순한 SQL assistant가 아니라 데이터 플랫폼 위에서 agent loop를 운영하려는 제품이라는 신호입니다.
최근 AI 코딩 도구 뉴스는 GitHub Copilot 앱, Claude Code, Cursor, Windsurf, Google Antigravity처럼 IDE와 repository 표면에 집중돼 있었습니다. Snowflake CoCo는 같은 경쟁에 들어오지만 시작점이 다릅니다. 범용 coding agent는 repository, issue, terminal, browser, pull request를 중심으로 움직입니다. CoCo는 warehouse, table, notebook, dbt project, Airflow job, SQL query, RBAC, lineage, streaming data를 작업 단위로 삼습니다. 데이터팀의 병목은 "코드를 작성한다"보다 "어떤 table을 읽을 수 있고, 어떤 lineage를 건드리며, 어떤 권한으로 실행되는가"에 가까운 경우가 많습니다.
Cortex Code가 CoCo로 바뀐 이유
Snowflake 제품 페이지의 FAQ는 CoCo가 Cortex Code와 같은 제품이며 기능과 architecture가 유지된다고 설명합니다. 이름 변경은 Snowflake 내부에서 AI-powered development를 더 넓게 잡기 위한 리브랜딩입니다. 같은 페이지는 CoCo와 Snowflake CoWork가 함께 agentic control plane을 이룬다고 적습니다. CoCo가 build 쪽 에이전트라면, CoWork는 업무 분석과 개인 agent 경험 쪽에 가까운 이름입니다.
이 리브랜딩에서 중요한 부분은 "coding"의 범위입니다. Snowflake 제품 페이지는 CoCo가 data pipelines, analytics, ML models, apps, AI agents를 자연어 대화로 만들 수 있다고 설명합니다. 예시에는 dbt, Apache Airflow, Postgres, Spark, AWS Glue가 들어갑니다. 기존 SQL worksheet 자동완성이나 BI assistant보다 범위가 넓습니다. CoCo는 Snowflake 안의 SQL만 쓰는 도구가 아니라, 데이터 stack 주변의 pipeline과 app delivery까지 다루는 agent로 자리 잡으려 합니다.
Snowflake가 내세우는 차별점은 context입니다. 제품 페이지는 CoCo가 catalog, lineage, RBAC policies를 읽어 실제 object와 권한을 참조한 코드를 만들 수 있다고 설명합니다. 또 semantic catalog search, data diffing, sandboxed runtimes 같은 Snowflake-specialized tooling을 언급합니다. 일반 coding agent가 repository 파일을 읽고 shell을 실행한다면, CoCo는 데이터 플랫폼의 metadata와 permission model을 작업 재료로 삼습니다.
어디서 실행되는가가 제품 전략입니다
이번 발표에서 CoCo의 실행 표면은 네 갈래입니다. 첫째는 Desktop입니다. Snowflake는 CoCo Desktop을 data stack 전반을 빌드하는 governed surface로 설명합니다. 둘째는 CLI입니다. 제품 페이지에는 Mac/Linux용 install script와 Windows용 PowerShell 명령이 공개돼 있고, CLI는 local development environment를 Snowflake data stack에 연결하는 terminal-native AI coding agent로 소개됩니다.
셋째는 Snowsight입니다. CoCo in Snowsight는 Snowflake Workspaces, Notebooks, 다른 Snowsight UI workflows 안에서 유지되는 persistent coding agent입니다. 데이터팀이 이미 worksheet와 notebook을 쓰는 화면에 agent를 넣는 방식입니다. 넷째는 existing tools입니다. Snowflake는 VS Code, Excel, Claude Code, Agent Client Protocol, 30개 이상 editor 지원을 언급했습니다. 개발자가 Snowflake 화면으로만 들어오기를 기다리지 않고, 이미 쓰는 도구에서 CoCo를 호출하게 만들겠다는 방향입니다.
| 표면 | Snowflake 설명 | 팀이 확인할 경계 |
|---|---|---|
| Desktop | 데이터 stack을 빌드하는 native IDE | 로컬 파일 접근, sandbox, 계정 연결 |
| CLI | terminal-native AI coding agent | CI 사용 여부, shell 권한, Snowflake connection |
| Snowsight | worksheet와 notebook 안의 persistent agent | role, warehouse, query history, audit trail |
| Extensions | VS Code, Excel, Claude Code, ACP 연동 | IDE context와 warehouse 권한의 결합 범위 |
이 표면 확장은 GitHub Copilot 앱이 issue, PR, Actions, branch protection을 묶는 방식과 다른 답입니다. GitHub는 code host 안에 에이전트 작업장을 만듭니다. Snowflake는 data cloud 안에 에이전트 작업장을 만듭니다. 두 제품 모두 "AI가 코드를 써준다"를 넘어 작업 상태, 권한, 실행 로그를 자신의 플랫폼 객체에 붙입니다. 차이는 GitHub의 기본 객체가 repository와 pull request이고, Snowflake의 기본 객체가 table, warehouse, query, policy, lineage라는 점입니다.
Cloud Agents와 Automations가 붙으면 승인선이 바뀝니다
Snowflake 발표문은 Cloud Agents가 Snowsight에서 시작한 작업을 cloud에서 계속 실행하게 한다고 설명합니다. 사용자가 laptop에서 session을 계속 열어둘 필요 없이 agent가 background에서 일을 진행하고 결과를 돌려주는 구조입니다. 이 기능은 편의 기능처럼 보이지만, 실제 운영에서는 승인선과 감사 로그가 먼저 보입니다. agent가 긴 data pipeline 수정, validation, notebook 생성, app deployment를 cloud에서 계속한다면 누가 시작했고 어떤 role로 실행됐는지가 결과 품질만큼 중요합니다.
Automations도 같은 문제를 만듭니다. Snowflake는 Automations가 recurring, event-driven workflow를 실행하고 RBAC와 audit trail로 보호된다고 밝혔습니다. 반복 validation, ongoing monitoring, operational process를 agent에게 맡기면 prompt가 아니라 policy가 제품의 중심이 됩니다. 예를 들어 매일 새 Kafka stream을 검사하고 table schema drift를 고치는 automation은 편리하지만, ALTER 권한, warehouse 비용, failure notification, rollback 기준을 함께 설계해야 합니다.
Snowflake가 새 secured local sandbox를 언급한 이유도 이 지점과 맞닿아 있습니다. local coding agent는 filesystem과 shell을 만질 수 있습니다. data agent는 여기에 warehouse query와 table mutation까지 더할 수 있습니다. local sandbox, Cloud Agents, Snowsight role, audit trail이 분리된 기능처럼 보이지만, 모두 "agent가 어디서 무엇을 실행할 수 있는가"라는 한 질문으로 이어집니다.
Agent SDK는 CoCo를 제품 안으로 넣는 통로입니다
Snowflake 문서의 Cortex Code Agent SDK는 아직 preview로 표시돼 있습니다. 문서는 Python과 TypeScript로 agentic AI applications를 만들 수 있고, 같은 tool과 agent loop가 Cortex Code를 구동한다고 설명합니다. 기본 도구에는 file read, write, edit, shell command, code search, SQL execution이 들어갑니다. 사용자는 별도 tool execution layer를 직접 만들지 않아도 agent가 파일과 Snowflake SQL을 함께 다루는 앱을 만들 수 있습니다.
SDK 예시는 query 함수로 agent를 호출하고 streaming message를 받는 구조입니다. TypeScript는 cortex-code-agent-sdk, Python은 cortex_code_agent_sdk 패키지를 씁니다. prerequisites에는 Cortex Code CLI, Snowflake CLI connection, Node.js 18 이상 또는 Python 3.10 이상이 적혀 있습니다. connection은 ~/.snowflake/connections.toml 또는 기존 Snowflake CLI config를 통해 설정합니다. 이 구조는 CoCo가 standalone SaaS assistant가 아니라 Snowflake 계정과 CLI 설정을 전제로 하는 개발 런타임이라는 점을 보여줍니다.
문서의 기능 목록은 범용 agent framework와 닮아 있습니다. multi-turn sessions, previous session continue, fork session, MCP servers, hooks, structured output, session control이 들어갑니다. hook event에는 PreToolUse, PostToolUse, Stop, UserPromptSubmit이 포함됩니다. session option에는 max turns, effort, abort controller, env, additional directories, plugins, system prompt, setting sources가 있습니다. Snowflake는 CoCo를 제품 UI뿐 아니라 개발자가 자기 workflow에 넣는 agent SDK로 확장하려 합니다.
여기서 실무 질문은 SDK가 얼마나 강력한가보다 승인 모델입니다. 문서는 approvals와 user input을 다루는 항목을 따로 둡니다. agent가 SQL을 실행하고 file edit과 shell까지 수행한다면, 기업용 앱에서는 "어떤 tool은 자동 허용하고 어떤 tool은 승인받을 것인가"를 먼저 정해야 합니다. 특히 data warehouse에서는 SELECT와 INSERT, CREATE TABLE, ALTER TASK, external access integration 호출이 모두 다른 위험을 가집니다.
Datastream은 CoCo의 입력 freshness 문제를 겨냥합니다
같은 발표에서 Snowflake는 Datastream도 공개했습니다. Datastream은 Apache Kafka-compatible managed streaming service로, 기존 Kafka app과 streaming system에서 Snowflake로 data를 직접 streaming하게 한다는 설명이 붙었습니다. Snowflake는 별도 broker, connector, 추가 streaming infrastructure를 줄이고, streamed data가 Snowflake governance, access controls, masking, lineage를 상속한다고 말합니다.
CoCo와 Datastream을 같이 발표한 이유는 agent가 최신 데이터 없이는 쓸모가 줄기 때문입니다. AI app이나 agent가 warehouse에 있는 낡은 batch table만 읽으면 추천과 자동화가 실무 상태를 따라가지 못합니다. Snowflake 발표문은 Datastream을 real-time engine, CoCo를 그 위에 앱과 pipeline을 만드는 AI coding agent로 묶었습니다. 개발자는 prompt로 real-time pipeline을 만들고, 그 데이터가 Snowflake table과 governance 안에 들어오는 그림입니다.
이 주장은 아직 실제 운영 비용과 제약을 봐야 합니다. Kafka compatibility가 기존 connector 운영을 얼마나 줄이는지, masking과 lineage가 stream ingestion 이후 어떤 수준으로 유지되는지, high-volume stream에서 warehouse 비용이 어떻게 잡히는지는 각 계정 조건에 따라 달라집니다. 그래도 제품 방향은 분명합니다. Snowflake는 agent를 코딩 보조 도구로만 팔지 않고, fresh data와 governed execution을 한 플랫폼 안에서 묶으려 합니다.
고객 사례는 속도보다 데이터 기반을 말합니다
Snowflake 발표문은 Fanatics, Thomson Reuters, WHOOP를 CoCo 사용 사례로 언급했습니다. Fanatics는 pipeline issue와 data modeling 문제를 days에서 hours로 줄인다는 취지의 사례를 제시했습니다. Thomson Reuters는 Snowflake 위에 37,500개 이상 governed tables와 350개 data sources로 단일 진실 공급원을 만들었다고 밝혔습니다. 그 위에서 legacy system modernization, AI pipeline scaling, insight delivery를 days instead of weeks로 앞당긴다는 설명도 붙였습니다. WHOOP은 CoCo를 data team뿐 아니라 organization 전체에 roll out한다고 설명했습니다.
이 사례에서 읽을 부분은 속도 수치보다 전제 조건입니다. CoCo의 강점은 데이터가 이미 Snowflake governance 안에 들어와 있을 때 커집니다. catalog가 정리돼 있고, role이 맞고, lineage와 table dependency가 의미 있게 남아 있어야 agent가 "실제 환경을 아는" 도구가 됩니다. 반대로 warehouse 안의 object naming, ownership, masking policy, dbt project, Airflow DAG가 어지럽다면 agent는 그 혼란을 더 빠르게 증폭할 수 있습니다.
CRN은 Snowflake Summit 2026 보도에서 CoCo와 CoWork가 partner ecosystem을 넓히는 역할을 한다고 봤습니다. TechTarget은 Snowflake가 Data Cloud에서 Agentic AI Platform으로 올라가려는 전략적 의도를 짚었습니다. 두 보도 모두 제품 발표문보다 한 발 떨어진 해석입니다. Snowflake가 하고 싶은 일은 warehouse vendor에 머무는 것이 아니라, 기업의 AI app과 agent가 돌아가는 control plane이 되는 것입니다.
경쟁 기준은 IDE UX가 아니라 권한과 lineage입니다
CoCo를 GitHub Copilot, Claude Code, Cursor와 직접 비교하면 겉으로는 불리해 보일 수 있습니다. 범용 coding agent는 language support, IDE polish, repository understanding, PR workflow, model performance에서 빠르게 경쟁합니다. Snowflake CoCo의 비교 지점은 다릅니다. 이 도구는 Snowflake account, warehouse, Snowflake CLI connection, role, SQL execution, catalog metadata를 전제로 합니다. 개발자가 React component를 고치는 데 쓰는 agent가 아니라, governed data stack을 바꾸는 agent입니다.
따라서 구매나 도입 판단도 다르게 해야 합니다. "어떤 모델을 쓰는가"만 물으면 부족합니다. 제품 페이지는 Claude Opus 4.7, Claude Sonnet 4.7, GPT 5.4 같은 모델 선택을 언급하지만, data agent에서 더 중요한 질문은 tool boundary입니다. agent가 어떤 database와 schema를 볼 수 있는지, write operation은 언제 막히는지, query cost는 어떻게 제한되는지 확인해야 합니다. audit log에 prompt, SQL, file diff가 어떻게 남는지와 MCP server가 어떤 third-party system까지 연결하는지도 봐야 합니다.
Databricks와 Microsoft Fabric도 같은 지점에서 경쟁합니다. Databricks는 Unity Catalog와 Lakehouse context를 갖고 있고, Microsoft는 Fabric과 Purview, GitHub Copilot, Rayfin을 함께 묶을 수 있습니다. Snowflake는 Snowflake-native governance와 customer data footprint를 무기로 삼습니다. 세 플랫폼 모두 agent를 "데이터 옆에 배치한다"는 방향으로 갑니다. 차이는 각 플랫폼이 기존 권한 모델을 agent action으로 얼마나 안정적으로 변환하는지에서 생깁니다.
팀이 지금 확인할 질문
첫째, CoCo를 어디서 쓸지 정해야 합니다. Desktop, CLI, Snowsight, VS Code, Excel, Claude Code plugin은 같은 CoCo 이름을 쓰지만 위험 경계가 다릅니다. Snowsight 안에서 제한된 role로 SQL을 생성하는 것과, local CLI가 repository file을 고치고 shell과 SQL을 모두 실행하는 것은 다른 도입 단계입니다. PoC는 read-only role과 작은 dbt project, isolated warehouse에서 시작하는 편이 맞습니다.
둘째, approval policy를 tool 단위로 쪼개야 합니다. file read, code edit, shell, SELECT, CREATE TABLE, INSERT, task scheduling, external MCP call은 같은 "agent action"이 아닙니다. SDK와 Automations를 쓰려면 action별 allowlist와 human approval 기준을 문서화해야 합니다. Snowflake가 RBAC와 audit trail을 제공하더라도, 어떤 role을 agent에게 줄지는 조직 결정입니다.
셋째, metadata 품질을 먼저 봐야 합니다. CoCo는 catalog, lineage, RBAC를 아는 agent라는 점을 내세웁니다. 그렇다면 catalog가 낡았거나 lineage가 끊긴 환경에서는 장점이 줄어듭니다. table owner, masking policy, dbt model description, Airflow dependency, data freshness SLA가 정리돼 있어야 agent가 안전한 제안을 할 수 있습니다.
넷째, Datastream과 CoCo를 같이 볼 경우 비용 모델을 분리해야 합니다. Streaming ingestion, warehouse compute, agent token consumption, SDK 호출, automation runtime은 서로 다른 비용 항목입니다. 제품 페이지 FAQ는 CoCo가 token consumption 기반으로 청구되고 trial credit이 있다고 설명합니다. data pipeline 자동화가 성공할수록 실행 빈도와 query cost가 늘 수 있으므로, cost control은 PoC 초기부터 넣어야 합니다.
Snowflake CoCo 발표는 또 하나의 AI 코딩 도구가 나왔다는 소식으로 끝나지 않습니다. 이 발표는 데이터 플랫폼이 agent runtime을 자기 안으로 끌어들이는 장면입니다. repository를 읽는 coding agent가 아니라 catalog와 RBAC와 SQL 실행을 읽는 coding agent가 등장하면, 개발팀의 비교표도 달라집니다. 모델 점수와 IDE UX 옆에 warehouse 권한, lineage 신뢰도, audit trail, streaming freshness, approval policy가 들어와야 합니다. Snowflake는 CoCo라는 이름으로 그 비교표를 데이터팀 쪽에서 다시 쓰려 합니다.