Snowflake AI Data Cloud: Novo가 80개국 데이터를 한곳에 모아 에이전트 약 8,000개를 돌리는 방식
Novo는 80개국 계열사가 따로 쓰던 Snowflake를 글로벌 조직 하나로 묶었습니다. 지금은 900TB가 넘는 데이터 위에서 에이전트 약 8,000개가 돌고 직원 60% 이상이 매주 AI를 씁니다. 현업에 데이터를 넘기되 가드레일·교육을 함께 깔고 모델은 갈아 끼울 수 있게 둔 구조입니다. 따라 만들 때 필요한 에이전트 등록부, 모델 평가, 12주 일정을 붙였습니다.
Novo는 나라마다 따로 쓰던 Snowflake를 글로벌 조직 하나로 묶은 뒤, 그 위에서 현업이 직접 AI 해법을 만들게 했습니다. 지금 회사 안에서 에이전트 약 8,000개가 돌고 직원 60% 이상이 매주 AI를 씁니다. 따라 하려면 데이터를 한곳에 모으는 일과 같은 시기에 가드레일·통제·교육을 깔고 특정 모델에 묶이지 않는 연결 구조를 처음부터 잡아야 합니다.
요약
diginomica의 Mark Samuels는 Novo의 Data and AI Foundation 담당 부사장 Loïc Giraud의 설명으로 이 회사의 데이터 플랫폼을 소개합니다. Giraud가 2024년에 합류했을 때 Snowflake AI Data Cloud는 이미 80개국 계열사가 영업, 마케팅, 재무, 구매에 쓰고 있었습니다. 그는 흩어져 있던 Snowflake 팀과 기술을 글로벌 조직 하나로 모았습니다. 그다음에 데이터셋을 더 붙이고 Snowflake CoCo와 Snowflake CoWork 같은 새 기능을 들였습니다. 데이터는 Snowflake로 들어와 가공된 뒤 ChatGPT나 Snowflake 서비스 같은 도구로 넘어갑니다. 사용자는 프런트엔드 화면, 표 형식 결과, 채팅 엔진 가운데 하나로 데이터에 닿습니다.
지금 Snowflake에 쌓인 데이터는 900TB가 넘고 계열사 인력 약 25,000명이 직간접으로 플랫폼을 씁니다. 회사 전체에서 에이전트 8,000개 가까이가 돌고 직원 60% 이상이 매주 AI를 씁니다. 쓰임새는 영업·마케팅 퍼널에서 환자가 빠지는 이유 분석, 가격·물량·참여도 경쟁 비교, 미국 영업 사원의 방문 준비, 계열사용 제품 정보 번역, 데이터 파이프라인 생성까지 퍼져 있습니다. Giraud가 꼽은 교훈은 세 가지입니다. 데이터를 현업 손에 쥐여 줘 스스로 해법을 만들게 할 것, 그 옆에 가드레일·통제·교육을 함께 둘 것, 플랫폼을 여러 모델에 열어 둘 것입니다. 아래에서는 이 세 원칙이 어떻게 맞물리는지 풀고 같은 구조를 국내 기업에 옮길 때 필요한 등록부, 평가, 일정을 덧붙였습니다.
핵심 메커니즘
Single Global Platform: 나라별로 쓰던 Snowflake를 글로벌 조직 하나로 묶기
계열사마다 따로 운영하던 데이터 팀과 기술을 조직 하나, 플랫폼 하나로 모으는 일입니다. 입력은 80개국 계열사의 영업·마케팅·재무·구매 데이터입니다. Snowflake가 이 데이터를 받아 가공하고 결과를 ChatGPT 같은 외부 도구나 Snowflake 서비스로 넘깁니다. 사용자 쪽 출구는 프런트엔드, 표, 채팅 세 가지입니다. 순서가 눈에 띕니다. Giraud는 먼저 팀과 기술을 한 조직으로 묶었고 데이터셋과 CoCo·CoWork 같은 기능은 그 뒤에 더했습니다. 원문이 전하는 규모는 데이터 900TB 이상, 사용자 약 25,000명입니다.
이 방식은 여러 법인이 같은 업무를 나라마다 되풀이할 때 효과가 큽니다. 영업 실적표나 구매 데이터를 나라마다 다른 이름으로 쌓고 있다면 한 번 정리한 정의를 80곳이 그대로 씁니다. 법인이 두세 곳뿐이고 데이터가 이미 ERP 하나에 모여 있다면 조직 통합보다 접근 경로를 정리하는 일이 먼저입니다. 가상 예시로, 해외 판매 법인 12곳을 둔 국내 소비재 회사라면 「월별 법인 매출」 테이블 하나를 공통 정의로 만들고 법인별 권한만 나눠 주는 데서 시작합니다.
Guardrails·Controls·Education: 현업이 에이전트를 만들게 하되 통제와 교육을 함께
Giraud는 데이터를 현업에 넘겨 스스로 해법을 만들게 하는 쪽을 택했습니다. 대신 조건을 붙였습니다. 데이터 접근은 안전해야 하고 에이전트에는 탄탄한 가드레일과 통제가 있어야 하며 직접 에이전트를 만드는 사람에게는 맞는 교육이 따라가야 한다는 것입니다. 통제를 맡는 층이 Snowflake의 agentic control plane(에이전트 통제 계층)입니다. AI 모델과 서비스를 데이터에 연결하되 그 연결을 엄격하게 관리하는 오케스트레이션 층입니다. 현재 규모는 이렇습니다. 회사 안에서 에이전트 약 8,000개가 돌고 직원 60% 이상이 매주 AI를 씁니다. 교육 프로그램의 구체 내용은 원문에서 밝히지 않았습니다.
현업이 만드는 에이전트가 수백 개를 넘으면 이 구조가 필요해집니다. 몇 개뿐일 때는 중앙 팀이 하나씩 검토해도 됩니다. 수천 개가 되면 누가 어떤 데이터를 읽는 에이전트를 만들었는지부터 기록이 남아야 합니다. 가상 예시로, 영업 사원이 만든 「주간 거래처 요약」 에이전트가 고객 연락처 테이블을 읽으려 하면 control plane이 권한을 확인하고 연락처 칸은 가린 채로만 넘깁니다.
Model-agnostic: 매달 바뀌는 모델을 갈아 끼울 수 있게 열어 두기
Giraud는 플랫폼이 “work with any model” 해야 한다고 말합니다. 프런티어 모델 회사들이 매달 새 버전을 내고 버전마다 성능이 다르기 때문입니다. 원리로 풀면 데이터와 통제는 Snowflake 쪽에 그대로 두고 그 위에서 부르는 모델만 바꾸는 구조입니다. 직원이 ChatGPT 프런트엔드로 Snowflake 데이터에 질문하는 경로도 같은 원리입니다. 모델이 바뀌어도 권한과 데이터 정의는 그대로 남습니다.
쓰임새마다 잘하는 모델이 달라지고 그 순위가 몇 달 만에 뒤집히는 업무라면 이 원칙이 맞습니다. 번역, 요약, SQL 생성처럼 품질을 점수로 잴 수 있는 일이 대표적입니다. 모델 하나로 몇 년을 버티는 조직이라면 바꿔 끼우는 장치에 드는 비용이 효과보다 커지기 쉽습니다. 가상 예시로, 제품 설명 번역은 이번 달 평가에서 점수가 높은 모델로 돌리고 데이터 파이프라인 생성은 다른 모델에 맡기는 식입니다.
통념과 다른 주장
흔히 이렇게 봅니다엔터프라이즈 AI는 중앙 IT·데이터 팀이 쓰임새를 골라 만들고 현업에 배포한다.
Novo는 이렇게 봅니다데이터를 현업 손에 쥐여 줘 스스로 해법을 만들게 하고 중앙은 플랫폼과 가드레일·통제·교육을 맡는다.
근거80개국 계열사 인력 약 25,000명이 플랫폼을 쓰고 회사 안에서 에이전트 8,000개 가까이가 돌며 직원 60% 이상이 매주 AI를 씁니다.
저자가 든 사례
| 사례 | 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|---|
| 소비자 행동 | 영업·마케팅 퍼널에서 환자가 빠짐 | 플랫폼 데이터로 이탈 이유 분석 | 원문에서 밝히지 않음 | Single Global Platform |
| 경쟁 분석 | 경쟁사 대비 위치 파악 필요 | 가격·물량·참여도 비교 | 원문에서 밝히지 않음 | Single Global Platform |
| 미국 영업 지원 | 영업 사원의 의료인·의료기관 방문 준비 | 에이전트가 준비를 돕고 CoWork로 Snowflake 데이터를 자연어로 질의 | 원문에서 밝히지 않음 | Guardrails·Controls·Education |
| 번역 | 계열사마다 다른 언어로 제품 정보 필요 | AI가 제품 정보와 다른 콘텐츠를 여러 언어로 번역 | Giraud는 대부분 자동화할 수 있다고 봄 | Single Global Platform |
| 데이터 엔지니어링 | 파이프라인 구축에 수작업이 많음 | CoCo로 파이프라인을 만드는 에이전트 구축 | 초기 탐색에서 수작업 감소 조짐, 필요한 엔지니어 수가 줄 수도 있음 | Single Global Platform |
| 전사 접근 | 직원이 데이터에 닿는 길이 여럿 | ChatGPT 프런트엔드로 Snowflake 데이터와 대화 | 엔터프라이즈 시스템 연결을 넓힐 계획 | Model-agnostic |
원문에는 처방을 받은 미국 환자 가운데 최대 80%가 약을 먹지 않는다는 추정과, 2030년까지 환자 6,000만 명에게 닿겠다는 회사 목표도 함께 실렸습니다. 생산성 업무와 R&D 업무에도 에이전트를 쓴다고 했지만 구체 사례는 나오지 않았습니다.
기술 디테일: 같은 구조를 직접 만든다면
아래 데이터 구조, 필드, 설정값은 실제로 돌릴 때 필요한 것을 정리한 실행 제안이며 Novo가 밝힌 구현이 아닙니다. 필드명과 숫자는 모두 가상 예시입니다.
Single Global Platform을 세우려면 테이블을 그냥 모으지 말고 데이터 제품(data product) 단위로 등록합니다. 데이터 제품마다 담당 부서, 계열사, 업무 영역, 갱신 주기, 개인정보 포함 여부, 읽을 수 있는 역할, 소비 경로를 적습니다. 계열사 데이터는 같은 정의의 테이블에 affiliate 칸을 두고 행 단위 권한(row access policy)으로 나눕니다. 나라마다 테이블을 따로 두면 80곳의 정의가 다시 갈라집니다. 소비 경로에 채팅 프런트엔드와 에이전트를 처음부터 넣어 두면 AI가 읽을 수 있는 데이터와 사람만 보는 데이터가 등록 단계에서 갈립니다.
{
"data_product": "affiliate_sales_monthly",
"domain": "sales",
"affiliate": "KR",
"owner_team": "global-data-ai-foundation",
"steward": "kr-sales-ops",
"refresh": "daily 05:00 local",
"contains_pii": false,
"read_roles": ["sales_analyst", "field_rep"],
"consumers": ["chat_frontend", "dashboard", "agent"],
"definition_version": "v3"
}현업이 만드는 에이전트를 통제하려면 에이전트 등록부를 둡니다. 에이전트 하나마다 만든 사람, 읽는 데이터 범위, 쓰기 동작, 부르는 모델 경로, 마스킹 여부, 검토 상태, 최근 평가 점수, 월 사용량을 남깁니다. 기본값은 읽기 전용으로 두고 메일 발송이나 시스템 기록 같은 쓰기 동작은 데이터 담당 승인을 받아야 켜지게 합니다. 60일 동안 한 번도 돌지 않은 에이전트는 담당자에게 알린 뒤 정리합니다. 수천 개 규모에서는 이 정리 규칙이 없으면 권한만 쥔 에이전트가 쌓입니다.
{
"agent_id": "us-field-visit-prep-014",
"builder": "business_user",
"owner_team": "us-sales-ops",
"data_scopes": ["visit_history:read", "territory_sales:read"],
"write_actions": [],
"model_route": "default-chat",
"pii_masking": true,
"review_status": "approved",
"last_eval_score": 4.3,
"monthly_runs": 1840,
"retire_if_unused_days": 60
}Model-agnostic을 실제로 지키려면 쓰임새마다 고정 평가 세트를 만듭니다. 번역은 문장 200개와 사람이 고른 정답 번역, SQL·파이프라인 생성은 정답이 정해진 과제 30개, 데이터 질의는 답을 아는 질문 100개 정도로 시작합니다. 새 모델이 나오면 같은 세트를 temperature 0~0.2로 세 번 돌려 평균과 편차를 봅니다. 평균이 지금 모델보다 0.2점(5점 척도) 이상 높고 세 번 사이 편차가 0.3점 이하일 때만 경로를 바꿉니다. 바꾼 날짜와 평가 결과는 등록부의 model_route 이력에 남깁니다. 에이전트는 모델 이름이 아니라 default-chat, translation 같은 경로 이름을 부르게 해야 모델을 바꿔도 에이전트를 고치지 않아도 됩니다.
번역을 대부분 자동화하려면 계열사별 용어집(제품명, 효능 표현, 금지 표현)을 번역 프롬프트에 함께 넣고 결과를 두 단계로 확인합니다. 먼저 다른 모델이 원문과 번역을 비교해 빠진 문장과 용어집 위반을 표시합니다. 그다음 계열사 검수자가 표시된 문장과 무작위 표본 10%를 봅니다. 위반 비율이 4주 연속 1% 아래로 내려가면 표본 비율을 5%로 줄입니다.
CoCo 같은 도구로 파이프라인 에이전트를 돌리려면 에이전트가 만든 파이프라인을 운영 환경에 바로 넣지 않습니다. 개발 스키마에서 행 수, 중복 키, null 비율 검사를 통과한 뒤 데이터 엔지니어가 승인해야 배포되게 합니다. 효과는 파이프라인 하나를 만드는 데 든 엔지니어 시간으로 재고 도입 전 4주 평균과 비교합니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 계열사마다 같은 지표를 다르게 정의 | 채팅 답이 나라마다 다름 | 데이터 제품 정의 버전 관리, 계열사 steward 합의 후 v 갱신 |
| 에이전트 수가 빠르게 늘어남 | 누가 무엇을 읽는지 모름 | 등록부 없이는 데이터 권한이 나가지 않게 함 |
| 새 모델로 바꾼 뒤 품질 하락 | 현업 불만, 재작업 | 경로 이름 단위로 이전 모델로 즉시 되돌림, 평가 세트 보강 |
| 번역 용어 불일치 | 계열사 검수 반려 | 용어집 갱신 주기를 월 1회로 고정, 반려 문장을 평가 세트에 추가 |
| 파이프라인 에이전트 결과가 조용히 틀림 | 하위 보고서 수치 오류 | 배포 전 자동 검사와 엔지니어 승인, 배포 후 1주 수치 대조 |
현업 실행 디테일: 누가, 언제, 무엇을
아래 역할, 일정, 판정 기준은 실제로 돌릴 때 필요한 것을 정리한 가상 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| 데이터·AI 기반 조직장 | 나라별 데이터 팀 통합안 승인, 시범 쓰임새 선정, 확대 판정 |
| 플랫폼 팀 | 공통 카탈로그, 행 단위 권한, 에이전트 등록부, 모델 경로 운영 |
| 계열사 데이터 steward | 자기 나라 데이터 정의 확인, 권한 요청 승인, 번역 검수자 지정 |
| 보안·개인정보 담당 | 마스킹 규칙, 쓰기 동작 승인 기준, 로그 보존 기준 |
| 현업 빌더(영업·마케팅 등) | 교육 이수 후 에이전트 제작, 사용 결과 보고 |
| 교육 담당 | 빌더 교육 과정 운영, 이수 기록 관리 |
준비물. 나라별 데이터 팀과 플랫폼 계약 현황, 계열사별 주요 테이블 목록과 정의, 현재 AI 도구 사용 현황(누가 어떤 모델을 쓰는지), 개인정보가 들어 있는 테이블 목록, 시범 쓰임새 두 개의 현재 처리 시간이 필요합니다. 기준선은 시작 전 4주치로 잡습니다.
12주 일정. 1~3주에는 나라별 데이터 자산과 AI 도구 사용 현황을 조사하고 쓰임새별 평가 세트를 만듭니다. 4~6주에는 공통 카탈로그와 권한 구조를 세우고 현업 빌더 교육 1기를 엽니다. 7~9주에는 에이전트 등록부를 켜고 빌더 교육 2기를 열며 시범 쓰임새 두 개(예: 영업 방문 준비, 제품 정보 번역)를 운영합니다. 후보 모델 두 개도 이때 같은 평가 세트로 비교합니다. 10~12주에는 결과를 놓고 다른 계열사로 넓힐지 판정합니다.
현업에 물을 것.
- 지금 나라나 법인마다 같은 지표를 다른 이름이나 다른 계산으로 쓰는 곳은 어디인가요?
- 현업이 이미 만들어 쓰는 AI 도구나 에이전트는 몇 개이고 그 목록은 누가 갖고 있나요?
- 에이전트가 읽으면 안 되는 데이터는 무엇이고 그 기준은 문서로 있나요?
- 지금 쓰는 모델을 바꾸면 고쳐야 하는 곳이 몇 군데인가요?
- 번역한 제품 정보는 지금 누가, 며칠 걸려 검수하나요?
진행 판정 기준(예시). 12주 끝에 다음을 채우면 다른 계열사로 넓힙니다. 시범 쓰임새 두 개 모두 처리 시간이 기준선보다 30% 이상 줄어야 합니다. 등록부에 오른 에이전트 가운데 검토 없이 쓰기 권한이 열린 것은 0개여야 하고 교육 이수자의 70% 이상이 4주 안에 에이전트를 하나 이상 만들어 써야 합니다. 모델 비교는 평가 세트 점수와 편차를 근거로 경로를 정했다는 기록이 남아야 합니다. 하나라도 못 채우면 원인을 정리해 4주를 더 봅니다.
AX 적용 제언. 해외 법인이나 계열사가 많은 국내 제약·소비재·제조 그룹이라면 AI 쓰임새를 고르기 전에 나라별 데이터 팀과 플랫폼을 한 조직으로 묶는 일부터 결정하는 편이 낫습니다. Novo도 조직을 먼저 묶고 기능을 그 뒤에 더했습니다. 현업에 데이터를 넘기는 결정은 CIO 혼자 내리기 어렵습니다. 보안 담당과 현업 리더가 함께 등록부와 교육 이수를 조건으로 내걸어야 합니다. 모델 계약은 한 회사와 길게 묶기보다 경로 이름 단위로 바꿀 수 있게 설계하고 평가 세트를 회사 자산으로 관리하면 모델이 바뀔 때마다 점수를 근거로 판단합니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | diginomica, Mark Samuels, 2026.10.30 |
| 발언자 | Loïc Giraud, Novo Data and AI Foundation 담당 부사장(2024년 합류) |
| 플랫폼 | Snowflake AI Data Cloud. 80개국 계열사가 영업·마케팅·재무·구매에 쓰던 구현을 이어받아 글로벌 조직 하나로 통합 |
| 새 기능 | Snowflake CoCo(데이터 엔지니어링·파이프라인 에이전트), Snowflake CoWork(자연어 데이터 질의) |
| 규모 | 데이터 900TB 이상, 직간접 사용자 약 25,000명, 계열사 80개국 |
| AI 사용 | 에이전트 8,000개 가까이 가동, 직원 60% 이상이 매주 AI 사용 |
| 쓰임새 | 소비자 행동, 경쟁 분석, 미국 영업 지원, 번역, 데이터 엔지니어링, 생산성·R&D 업무, ChatGPT 프런트엔드 접근 |
| 통제 | 안전한 데이터 접근, 가드레일과 통제, Snowflake agentic control plane, 현업 빌더 교육(구체 프로그램 미공개) |
| 모델 | 매달 바뀌는 프런티어 모델 사이를 오갈 수 있게 어떤 모델과도 연결되는 구조 지향 |
| 기타 수치 | 지난 4년 해마다 20% 가까운 성장, 2030년 환자 6,000만 명 목표, 처방받은 미국 환자 최대 80%가 약을 먹지 않는다는 추정 |
| 다음 계획 | ChatGPT 프런트엔드로 엔터프라이즈 시스템 연결 확대, CoCo 기반 데이터 엔지니어링 확대, Snowflake 신기능 계속 도입 |
핵심 개념
- Snowflake AI Data Cloud
- Novo가 핵심 플랫폼으로 쓰는 Snowflake 제품. 데이터를 받아 가공한 뒤 AI 도구로 넘깁니다.
- Snowflake CoCo
- 원문에서 데이터 엔지니어링에 쓰인 Snowflake 기능. Novo는 이 위에서 데이터 파이프라인을 만드는 에이전트를 시험하고 있습니다.
- Snowflake CoWork
- 원문에서 직원이 Snowflake 데이터에 자연어로 질문하게 해 주는 기능으로 소개됩니다.
- agentic control plane
- AI 모델과 서비스를 데이터에 연결하면서 그 연결을 엄격하게 관리하는 오케스트레이션 층입니다.
- affiliate
- 나라별 계열사·현지 법인. Novo에서는 80개국 계열사가 플랫폼을 씁니다.
- data product
- 담당자, 정의, 갱신 주기, 권한을 붙여 등록한 데이터 묶음. 이 노트의 기술 디테일에서 쓴 실행 용어입니다.
내 메모
TODO: 내 생각 추가
원문은 diginomica에 실린 「How Novo has built a scalable data platform for agentic AI explorations」(Mark Samuels, 2026.10.30)입니다. 원문은 회사를 “Novo”로만 표기하며 이 노트도 그 표기를 따랐습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 원문에 실린 Loïc Giraud의 설명을 AX Review가 다시 정리했으며 수치와 효과는 회사 측 설명입니다. 기술·현업 실행 디테일, JSON 예시, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전문은 원문 페이지에서 볼 수 있습니다.