Business Ontology: 지표의 뜻에 소유자와 승인을 붙여 사람과 에이전트가 함께 쓰게 하는 Snowflake 기능

Snowflake의 Business Ontology는 매출, 활성 고객 같은 업무 용어마다 뜻, 소유자, 승인 상태를 기록하고 그 뜻을 실제로 계산하는 데이터에 연결합니다. 에이전트는 승인된 정의만 받습니다. 회사는 이렇게 하면 사람과 에이전트가 같은 질문에 같은 답을 낸다고 설명합니다(회사 발표). 따라 하려면 도구보다 먼저 핵심 용어 20~30개의 소유자와 승인 절차를 정해야 합니다.

요약

Snowflake 제품 마케팅 매니저 Nick El-Rayess, Danielle Kucera와 프린서플 PM Shinji Kim이 2026년 11월 3일 Snowflake 블로그에서 Business Ontology를 소개했습니다. Business Ontology는 Horizon Catalog 안에 있는 맥락 계층 Horizon Context의 한 기능입니다. 업무 용어(term), 엔터티, 관계, 지표를 정의하고, 각각에 소유자를 정해 승인을 받은 뒤, 그 정의를 구현하는 테이블과 Semantic View(지표 계산식·차원·조인을 묶어 둔 Snowflake 객체)에 연결합니다. 회사가 내세운 문제는 이렇습니다. 매출을 묻는 에이전트는 재무가 매출을 어떻게 정의하는지, 그 매출이 주문·고객과 어떻게 이어지는지 알아야 합니다. 그런데 이 지식은 BI 모델, dbt 프로젝트, 직원의 경험에 흩어져 있어 에이전트를 만들 때마다 다시 짜야 합니다. 블로그는 출시 상태를 퍼블릭 프리뷰 예정으로 적었고, 같은 시기 제품 문서는 일부 계정 대상 프라이빗 프리뷰로 안내합니다.

에이전트마다 다시 짜던 업무 지식을 한 번 정의하고 승인해 함께 씀

설계의 뼈대는 맥락을 세 층으로 나눈 것입니다. Cortex Sense(쿼리 기록, 대시보드, dbt 모델에서 맥락을 자동으로 추론하는 기능, 퍼블릭 프리뷰 예정)가 넓은 범위를 빠르게 덮습니다. Business Ontology는 누가 정하고 승인했는지라는 권위를 더하고, Semantic Views는 계산의 정확성을 맡습니다. 승인된 정의만 Snowflake의 에이전트 화면인 CoCo와 CoWork에 제공됩니다. 승인본이 Cortex Sense의 추론과 부딪히면 에이전트는 승인본을 쓰고 Sense는 그 정의에서 다시 배웁니다. 브랜드나 지역마다 의도적으로 다른 지표는 하나로 억지로 합치지 않고 변형(variant)마다 따로 승인해 남깁니다. 초기 사용 고객으로 dentsu가, 연동 파트너로 Omni, Sigma, ThoughtSpot이 이름을 올렸고 효과 수치는 공개하지 않았습니다. 아래에서 여섯 가지 메커니즘을 풀고, 실제로 돌릴 때 필요한 기록 설계와 6주 시범안을 붙입니다.

세 층은 순서가 아니라 역할 분담. 가장 급한 층부터 시작

핵심 메커니즘

Three-Layer Context: 추론, 승인, 계산을 나눠 맡는 세 층

무엇인가. 에이전트에 줄 업무 맥락을 Cortex Sense, Business Ontology, Semantic Views 세 층이 나눠 맡는 구조입니다.

어떻게 작동하나. Horizon Context의 메타데이터 커넥터가 Tableau, Power BI, dbt, SQL Server, Sigma, Omni, PostgreSQL 같은 곳에서 스키마, 쿼리 로그, 대시보드 정의, 사용 신호를 모읍니다. 플랫폼을 넘나드는 계보(lineage)가 원천 DB에서 변환을 거쳐 대시보드까지 이어집니다. 그 위에서 Sense는 추론으로 범위를 넓히고, Ontology는 승인으로 기준을 세우고, Semantic Views는 정해진 계산을 실행합니다.

언제 쓰나. 세 층은 순서대로 깔아야 하는 단계가 아닙니다. 회사는 용어집이 급하면 Ontology부터, 실행되는 지표가 급하면 Semantic Views부터 시작하라고 안내합니다. 대체로 출발점은 배경 작업을 많이 대신해 주는 Sense라고 봅니다.

원문의 예. 고객, 주문, 순매출 같은 개념이 그 개념을 구현하는 테이블, Semantic View, 서비스와 연결된 그림을 듭니다.

작은 예시(가상). 유통사가 “지난 분기 반품률”을 묻는 에이전트를 만든다고 합시다. Sense는 반품 테이블과 자주 쓰는 대시보드를 찾아 줍니다. Ontology는 반품률을 품질팀이 소유하고 교환을 뺀다는 승인된 뜻을 줍니다. Semantic View는 그 계산식을 실행합니다.

세 층이 각각 추론, 승인, 계산을 맡고 소비하는 쪽은 하나의 맥락을 받음

Governed Definition: 정의, 범위, 소유자, 승인, 연결의 다섯 단계

무엇인가. 업무 용어 하나를 회사의 공식 정의로 만드는 절차입니다. 정의가 기록되고 책임자가 승인해야 에이전트가 씁니다.

어떻게 작동하나. 분석가가 정의를 새로 쓰거나 기존 용어집에서 가져옵니다. 이어서 적용 범위를 재무 같은 도메인으로 정하고, 소유자를 지정하고, 승인을 받고, 그 지표를 계산하는 Semantic View 지표에 연결합니다. 제품 문서에 따르면 정의는 draft, approved, deprecated 세 상태를 거치고 approved만 에이전트에 제공됩니다. 정의를 만들고 고치고 승인하는 권한은 Horizon Catalog의 거버넌스 통제로 나눕니다.

언제 쓰나. 부서마다 이름은 같은데 뜻이 다른 지표가 있고, 그 지표를 에이전트가 답에 쓰기 시작할 때 필요합니다. 탐색용으로 잠깐 쓰는 지표까지 승인 절차를 거치게 하면 일이 늘어납니다.

원문의 예. 순매출(net revenue)을 한 번 정의하고 범위를 재무로 정한 뒤 소유자를 지정하고 승인받아 계산 지표에 연결하는 흐름을 듭니다. 승인된 순매출 정의 하나에 동의어, 관련 개념, 변형이 붙고 두 Semantic View의 지표로 이어집니다.

작은 예시(가상). 제조사의 “납기 준수율”을 영업이 초안으로 올리고, 범위를 SCM 도메인으로 정하고, 물류기획팀장을 소유자로 지정해 승인한 뒤 출하 실적 뷰의 지표에 연결합니다.

승인(approved) 상태가 된 정의만 에이전트에 제공됨

Intentional Variants: 하나의 정의 아래 의도된 차이를 남기기

무엇인가. 같은 이름의 지표를 여러 Semantic View가 계산할 때, 이들을 하나의 공통 정의에 묶되 의도적으로 다른 계산은 변형으로 따로 승인해 두는 방식입니다.

어떻게 작동하나. 팀들이 서로 대응하는 지표를 하나의 공통 정의에 연결합니다. 구현을 하나로 강제하지는 않습니다. 브랜드나 지역마다 다른 버전은 각각 이름표와 승인을 따로 받고 자기 범위를 유지합니다. 사용자는 용어를 찾아 소유자와 승인 상태를 보고 어디서 계산되는지 따라갈 수 있습니다.

언제 쓰나. 사업부·브랜드·지역마다 계산 기준이 다른 것이 사업상 맞는 경우입니다. 차이에 이유가 없으면 변형으로 남기지 말고 정의를 하나로 합칩니다.

원문의 예. 외식 기업이 기존점 매출(same-store sales)을 브랜드마다 다르게 정의하고 버전마다 따로 승인과 이름표를 붙이는 예를 듭니다.

작은 예시(가상). 아래 그림처럼 “활성 고객”을 공통 정의로 두고 온라인몰은 90일 내 구매, 매장은 180일 내 방문으로 변형을 따로 승인합니다.

가상 예시. 공통 정의 하나에 의도된 변형을 이름표와 승인을 따로 붙여 남김

Approved over Inferred: AI 추론보다 승인된 정의가 우선

무엇인가. 자동으로 추론한 맥락과 사람이 승인한 정의가 다를 때 무엇을 따를지 정한 규칙입니다.

어떻게 작동하나. Cortex Sense는 사람들이 쿼리를 날리고 대시보드를 만들고 파이프라인을 돌리는 동안 맥락을 쌓고, 팀이 정한 주기로 스스로 갱신합니다. 팀은 업무 용도 하나로 범위를 좁히고 기존 맥락을 붙인 뒤 피드백과 평가로 다듬습니다. Sense는 서로 어긋나는 지식을 찾으면 어느 출처를 믿을지 팀에 묻고, 정의·관계·데이터 연결을 담은 Ontology 초안도 만들어 줍니다. AI 제안과 가져온 정의는 검토의 출발점일 뿐이고 공식 여부는 책임 소유자가 정합니다. 승인본과 Sense의 추론이 충돌하면 에이전트는 승인본을 쓰고 Sense는 그 결과에서 배웁니다.

언제 쓰나. 정의 작업을 빈 페이지에서 시작하기 어려운 조직에 맞습니다. 자동 초안을 승인 없이 그대로 에이전트에 열면 이 규칙의 의미가 사라집니다.

원문의 예. Sense가 초안을 만들어 팀이 처음부터 쓰지 않아도 되게 하고, 충돌 시 승인본이 이긴다고 밝힙니다.

작은 예시(가상). Sense가 쿼리 기록을 보고 “활성 고객 = 30일 내 로그인”이라고 추론했지만 승인본은 90일 내 구매입니다. 에이전트는 90일 내 구매로 답합니다.

AI 추론은 출발점, 승인된 정의가 최종 기준

Meaning vs Calculation: 뜻은 Ontology, 계산은 Semantic View

무엇인가. 지표가 무엇을 뜻하고 누가 승인했는지와, 그 지표를 어떻게 계산하는지를 서로 다른 객체가 맡게 한 분리입니다.

어떻게 작동하나. Semantic View는 한 도메인의 지표, 차원, 조인을 묶은 Snowflake 객체이고 에이전트, BI 도구, SQL이 바로 질의합니다. 에이전트는 계산을 추측하지 않고 이 관리되는 로직에서 SQL을 만듭니다. Business Ontology는 승인된 정의를 뷰에 연결만 하고 계산은 바꾸지 않습니다. 계산은 각 뷰의 소유자에게 남습니다. 제품 문서는 이 연결을 representation(정의와 구현 자산을 잇는 바인딩)이라 부르고, 테이블, 뷰, 컬럼, Semantic View의 지표·차원 같은 부분을 대상으로 삼습니다. 뷰를 다시 만들어도 정의는 남습니다.

언제 쓰나. 재무가 뜻을 정하고 데이터팀이 계산을 관리하는 것처럼 두 책임자가 다를 때 효과가 큽니다.

원문의 예. 블로그의 FAQ는 Business Ontology가 뜻, 소유, 관계를, Semantic Views가 계산을 정의한다고 구분합니다.

작은 예시(가상). “영업이익률”의 뜻과 승인은 재무기획팀이, 계산식과 조인은 데이터플랫폼팀이 관리합니다. 계산식이 바뀌어도 승인된 뜻은 그대로입니다.

뜻과 계산을 나눠 맡고, 연결은 representation 하나로

Open by Design: Apache Ossie, RDF, MCP로 밖과 주고받기

무엇인가. 정의와 지표를 Snowflake 밖의 도구와 에이전트도 쓸 수 있게 표준 형식과 프로토콜을 붙인 설계입니다.

어떻게 작동하나. Snowflake는 시맨틱 모델의 벤더 중립 공개 표준인 Apache Ossie(인큐베이팅 단계)를 함께 만들었고, Microsoft, Salesforce, dbt Labs, Qlik, ThoughtSpot 등 수십 개 조직이 참여한다고 밝힙니다. Business Ontology는 개념, 정의, 관계를 Ossie와 RDF(웹 표준 데이터 기술 형식) 같은 형식으로 가져오고 내보냅니다. Semantic Views도 Ossie 정의를 주고받습니다. Snowflake 밖의 에이전트는 MCP(Model Context Protocol)로 Semantic Views에 질의하고, 접근은 Horizon Catalog가 통제합니다.

언제 쓰나. BI 도구나 에이전트 플랫폼을 여러 개 쓰는 기업, 나중에 도구를 바꿀 가능성이 있는 기업에 맞습니다.

원문의 예. Ossie 가져오기·내보내기와 MCP 질의를 듭니다.

작은 예시(가상). 사내 고객상담 에이전트가 Snowflake 밖에서 돌아도 MCP로 “환불률” Semantic View를 질의해 같은 승인 정의로 답합니다.

정의는 표준 형식으로 옮기고, 외부 에이전트도 같은 권한 아래 질의

통념과 다른 주장

흔히 이렇게 봅니다지표는 회사 전체에 정의가 하나만 있어야 한다(single source of truth).

Snowflake는 이렇게 봅니다대응하는 지표를 공통 정의 하나에 묶되, 의도된 차이는 변형으로 남기고 따로 승인한다.

근거외식 기업이 기존점 매출을 브랜드마다 다르게 정의하고 버전마다 승인과 이름표를 붙이는 예를 들었습니다.

흔히 이렇게 봅니다시맨틱 레이어에 계산식을 잘 정의해 두면 에이전트가 뜻도 맞게 쓴다.

Snowflake는 이렇게 봅니다계산(Semantic Views)과 뜻·소유·승인(Business Ontology)은 다른 문제여서 따로 관리해야 한다.

근거세 층이 각각 범위, 권위, 계산 정확성을 맡는다고 설명하고, Ontology는 정의를 연결할 뿐 계산은 각 뷰 소유자에게 남긴다고 밝혔습니다.

흔히 이렇게 봅니다AI가 메타데이터와 사용 기록에서 맥락을 자동으로 뽑아 주면 사람의 정의 작업은 줄일 수 있다.

Snowflake는 이렇게 봅니다자동 추론은 초안이고, 공식 정의는 책임 소유자가 정하며, 충돌하면 승인본이 이긴다.

근거자사 Cortex Sense를 함께 발표하면서도 AI 제안과 가져온 정의를 검토의 출발점으로만 두고 승인본이 추론보다 우선한다고 밝혔습니다.

통념과 발표의 차이를 한 장으로

저자가 든 사례

dentsu: 여러 파트너가 같은 지표를 다르게 읽는 문제

상황	한 일	결과	연결
광고 지주사 dentsu는 Merkle 같은 계열 에이전시와 여러 파트너가 함께 일하는 환경이고, 엔지니어링 총괄은 이때 생기는 의미 어긋남(semantic drift)을 큰 위험으로 봤습니다.	초기 사용 고객으로 Business Ontology를 써서 정의마다 책임 소유자를 두고 그 정의를 구현하는 데이터에 연결했습니다.	후속 시스템마다 관리되는 답 하나를 받게 됐다고 dentsu 임원들이 말했습니다(회사 발표). 수치와 기간은 원문에서 밝히지 않음.	Governed Definition, Meaning vs Calculation

dentsu 임원 발언을 Snowflake 블로그가 인용. 효과 수치는 원문에 없음

분석 도구 파트너 세 곳

상황	한 일	결과	연결
고객이 여러 BI·분석 도구에서 같은 개념을 쓴다.	Omni는 Semantic Views와 양방향 연동하고, Sigma는 개념을 Sigma AI의 앱·대시보드·에이전트에서 재사용하게 하고, ThoughtSpot은 Spotter로 현업 지식을 모아 관리되는 맥락에 보탠다고 밝혔습니다.	파트너 발언(회사 발표). 수치는 원문에서 밝히지 않음.	Open by Design, Intentional Variants

파트너 발언 요약(회사 발표)

기술 디테일: 정의를 기록하고 에이전트에 물리는 방법

아래 필드명, 설정값, 평가 기준은 실제로 돌릴 때 필요한 것을 정리한 실행 제안입니다. 상태, 노드 종류, 권한 이름은 Snowflake 제품 문서를 따랐고 그 밖의 필드와 수치는 Snowflake가 밝힌 구현이 아닙니다.

Governed Definition을 기록하려면 노드 하나에 아래 정보를 남깁니다. 제품 문서가 밝힌 노드 종류는 Term(일반 용어, 기본값), Metric(계산·KPI), Entity(관계를 가진 업무 객체), Dimension(지역·계약 시작일 같은 속성), Policy(여러 노드에 걸치는 업무 규칙) 다섯 가지입니다. 관계(예: 주문은 주문 품목을 포함한다)와 동의어, representation도 노드에 붙습니다. Snowflake 밖에서 같은 구조를 흉내 낼 때는 아래 기록 하나를 정의의 단위로 씁니다.

{
  "node_id": "fin.net_revenue",
  "kind": "Metric",
  "domain": "finance",
  "name": "순매출",
  "definition": "총매출에서 반품, 리베이트, 매출 할인을 뺀 금액. 청구일 기준 인식",
  "synonyms": ["넷 매출", "net revenue"],
  "owner": "재무기획팀장",
  "status": "approved",
  "version": 3,
  "approved_at": "2026-11-20",
  "variants": [{"scope": "brand_A", "note": "가맹점 수수료 차감", "status": "approved"}],
  "relationships": [{"type": "derived_from", "target": "fin.gross_revenue"}],
  "representations": ["SV_FINANCE.net_revenue", "SV_SALES.net_revenue"]
}

제품 문서 기준 상태. approved만 에이전트에 제공

승인 흐름을 돌리려면 제품 문서의 도메인별 권한 네 가지를 역할에 대응시킵니다. READ는 정의를 읽는 사람과 에이전트, SUGGEST는 변경을 제안하는 분석가, MODIFY는 검토하고 승인하는 소유자, OWNERSHIP은 도메인을 지울 수 있는 거버넌스 담당입니다. 기존 용어집은 파일로 가져와 Cortex에게 도메인, 용어, 관계, 자산 연결 후보를 뽑게 하고, 신뢰도가 높은 제안은 한꺼번에 받아들이고 나머지는 고치거나 버린 뒤 draft에서 approved로 올립니다. 한꺼번에 받아들인 묶음도 소유자가 10건 중 1건꼴로 무작위 표본을 보고, 표본에서 2건 이상 틀리면 그 묶음 전체를 하나씩 다시 봅니다. 문서에 따르면 작성 기능 전체는 CoCo의 business-ontology 스킬에서 쓰고 Snowsight 화면에서는 목록·그래프 조회와 용어 생성 정도만 됩니다.

에이전트가 승인 정의를 쓰게 하려면 에이전트 도구를 두 단계로 나눕니다. resolve_concept(term, scope)가 동의어를 거쳐 approved 노드만 찾아 정의, 소유자, 변형 목록, representation을 돌려주고, query_metric(node_id, scope, filters, period)가 연결된 Semantic View로 계산합니다. 변형이 둘 이상인데 질문에 범위가 없으면 계산하지 말고 사용자에게 되묻게 합니다. 답변 JSON에는 node_id, version, semantic_view를 필수로 두고 비어 있으면 게시하지 않습니다. SQL 생성 단계는 temperature 0으로 둡니다.

실행 제안. 답에는 쓴 정의와 계산 위치를 남김

효과를 재려면 연결 전과 후에 같은 질문 세트를 돌립니다. 한 도메인에서 소유자가 기대값을 정한 질문 30개를 만들고 각 질문을 3회씩 실행합니다. 세 번 모두 같은 숫자가 나온 비율, 기대값과 0.5% 안에서 맞은 비율, 근거 필드가 채워진 비율, 변형이 있는 질문에서 되물은 비율을 셉니다. 이 수치는 회사가 발표한 효과를 우리 데이터로 확인하는 기준선이 됩니다.

실행 제안. 연결 전후로 같은 질문 세트를 돌려 비교

연결이 끊기지 않게 하려면 representation을 매일 점검합니다. 제품 문서는 대상 테이블이나 뷰가 지워지거나 이름이 바뀌어도 representation이 다시 검증되지 않고 유효한 것처럼 보인다고 밝힙니다. 그러니 representation 대상 목록을 카탈로그의 현재 객체 목록과 매일 비교하고, 사라진 대상은 소유자에게 알리고 그 노드를 에이전트 답변에서 잠시 뺍니다. 문서는 Semantic View 계산식이 바뀔 때 다시 맞추는 드리프트 감지는 아직 없다고 적었으므로 뷰 변경도 같은 점검에 넣습니다.

Cortex Sense의 충돌 질문을 처리하려면 Sense가 어느 출처를 믿을지 물어 온 건을 소유자별 대기열로 모으고 5영업일 안에 답하게 합니다. 답한 결과는 승인본으로 남기고, 답하지 못한 건은 에이전트가 그 용어를 쓸 때 “정의 확정 전”이라고 밝히게 합니다.

막히는 경우	증상	대응
소유자가 정해지지 않은 용어	draft에 머물러 에이전트가 못 씀	도메인 책임자가 2주 안에 지정, 지정 전에는 에이전트가 “정의 없음”으로 답함
변형이 계속 늘어남	같은 지표에 버전 5개 이상	변형마다 사업상 이유 한 줄을 받고 이유 없는 변형은 공통 정의로 합침
가져온 용어집의 중복	같은 뜻의 노드가 여러 개	생성 시 중복·충돌 표시(문서상 CoCo 기능)를 켜고 동의어로 합침
대상 테이블 이름 변경	에이전트 답이 틀리거나 실패	매일 representation 점검, 끊긴 노드는 답변에서 제외
외부 에이전트가 권한 밖 지표를 질의	접근 거부 또는 일부 결과	MCP 경유 질의도 Horizon Catalog 권한으로 통제, 거부 사유를 답에 표시

현업 실행 디테일: 누가, 언제, 무엇을

역할	맡는 일
데이터 거버넌스 담당(CDO 조직)	도메인 개설, 권한(READ·SUGGEST·MODIFY·OWNERSHIP) 배정, 승인 회의 운영
지표 소유자(재무기획·영업기획 등 도메인 책임자)	핵심 용어 20~30개 정의 승인, 변형 허용 여부 결정, 충돌 질문 답변
분석가 2~3명	기존 용어집·대시보드에서 정의 초안 작성, 변경 제안
데이터 엔지니어	Semantic View 정비, representation 연결, 매일 연결 점검
AI·에이전트 개발자	`resolve_concept`·`query_metric` 도구 연결, 질문 30개 평가 실행
현업 스폰서(시범 도메인 임원)	시범 범위 승인, 6주 차 확대 판정

준비물. 경영 회의와 주간 보고에 가장 자주 나오는 지표 목록, 기존 용어집이나 지표 정의서, dbt·BI 도구의 지표 계산식, 부서끼리 숫자가 달라 다툰 최근 사례 3~5건, 지표별로 지금 누가 계산식을 고치는지에 대한 목록이 필요합니다.

기간	할 일	산출물
1주	시범 도메인 하나를 고르고 핵심 용어 20~30개 수집	용어 목록, 소유자 후보
2주	용어집 가져오기와 자동 초안 생성	draft 노드, 중복·충돌 목록
3주	충돌 정리, 변형 허용 여부 결정	변형 목록과 사업상 이유
4주	승인 회의, draft를 approved로	승인된 정의 v1
5주	representation 연결, 에이전트 도구를 승인 정의 경유로 전환	연결 표, 매일 점검 작업
6주	질문 30개 × 3회 평가, 전후 비교	판정 보고서, 다음 도메인 후보

실행 제안. 한 도메인, 핵심 용어 20~30개 기준

현업에 물을 것.

회의에서 “그 숫자 어디서 나왔냐”는 말이 가장 자주 나오는 지표는 무엇인가요?
이름은 같은데 부서나 브랜드마다 계산이 다른 지표는 무엇이고, 그 차이에 사업상 이유가 있나요?
그 지표의 뜻을 바꿀 때 지금은 누가 승인하고, 기록은 어디에 남나요?
지표 계산식을 고치는 사람과 뜻을 정하는 사람이 같은 사람인가요?
에이전트가 이 지표로 틀린 답을 냈을 때 누구에게 알려야 하나요?

진행 판정 기준(예시). 6주 차에 세 번 모두 같은 답을 낸 비율이 90% 이상, 기대값 일치가 연결 전보다 15%p 이상 오르고, 근거 필드 누락이 5% 아래이며, 승인 대상 용어의 80% 이상이 approved이면 다음 도메인으로 넓힙니다. 승인률이 낮으면 도구 문제가 아니라 소유자 지정 문제이므로 거버넌스 담당이 소유자부터 다시 정하고 2주를 더 봅니다.

AX 적용 제언. 이 발표에서 옮겨 올 것은 제품보다 운영 방식입니다. 정의마다 소유자, 승인 상태, 계산 위치를 붙이는 방식은 Snowflake를 쓰지 않는 회사도 용어집과 시맨틱 레이어로 흉내 낼 수 있습니다. 첫 적용처는 브랜드나 계열사가 여럿이어서 같은 지표를 다르게 세는 그룹사입니다. 변형을 따로 승인하는 구조가 바로 쓰입니다. dentsu처럼 여러 파트너와 데이터를 주고받는 조직도 맞습니다. 순서는 경영 보고에 쓰는 지표 20~30개의 소유자를 먼저 정하고, 에이전트는 그 정의를 거쳐서만 답하게 바꾸고, 마지막에 자동 추론으로 범위를 넓히는 것입니다. 블로그 기준 기능은 아직 프리뷰 단계이므로 운영 시스템 전면 적용보다 한 도메인 시범으로 시작하는 편이 안전합니다.

원문 사례

항목	내용
발행	Snowflake 블로그(Product and Technology), 2026.11.03, Nick El-Rayess·Danielle Kucera(제품 마케팅)·Shinji Kim(프린서플 PM)
발표 대상	Business Ontology. Horizon Catalog 안 Horizon Context의 기능, 블로그 기준 퍼블릭 프리뷰 예정(제품 문서는 프라이빗 프리뷰로 안내)
함께 소개	Cortex Sense(맥락 자동 추론, 퍼블릭 프리뷰 예정), Semantic Views(계산 실행)
정의 절차	정의 또는 가져오기, 범위 지정, 소유자 지정, 승인, Semantic View 지표에 연결
예시	순매출 정의 흐름, 외식 기업의 브랜드별 기존점 매출 변형
우선순위	승인 정의가 Cortex Sense 추론보다 우선, approved만 CoCo·CoWork 에이전트에 제공
커넥터	Tableau, Power BI, dbt, SQL Server, Sigma, Omni, PostgreSQL
개방성	Apache Ossie(인큐베이팅), RDF 가져오기·내보내기, 외부 에이전트의 MCP 질의
고객·파트너	dentsu(초기 사용, Merkle 언급), Omni, Sigma, ThoughtSpot
효과	사람과 에이전트가 같은 정의를 쓰고 같은 답을 낸다는 회사 발표. 수치 없음

핵심 개념

Horizon Catalog: Snowflake의 데이터 카탈로그·거버넌스 영역입니다. 정의를 만들고 승인하는 권한도 여기서 통제합니다.
Horizon Context: Horizon Catalog 안에서 AI, BI, 앱에 업무 맥락을 제공하는 계층입니다. Business Ontology가 여기에 속합니다.
Cortex Sense: 쿼리 기록, 대시보드, dbt 모델 같은 메타데이터와 사용 패턴에서 맥락을 자동으로 추론하는 Snowflake 기능입니다.
CoCo · CoWork: 승인된 정의를 받아 쓰는 Snowflake의 AI 에이전트 화면입니다. 제품 문서상 Ontology 작성도 CoCo에서 합니다.
synonym: 사람과 AI가 같은 승인 노드로 연결하는 다른 이름입니다.
Policy node: 여러 노드에 걸쳐 정의나 처리 방식을 정하는 업무 규칙입니다. 한 노드에만 해당하면 그 노드 설명에 씁니다.
semantic drift: 같은 용어를 시스템이나 조직마다 조금씩 다르게 해석해 뜻이 벌어지는 현상입니다.
RDF: Resource Description Framework. 개념과 관계를 주어·술어·목적어 묶음으로 기술하는 웹 표준 형식입니다.

내 메모

TODO: 내 생각 추가

원문은 Snowflake 블로그의 「Business Ontology Governs Business Concepts and Metrics for AI and Analytics」(Nick El-Rayess, Danielle Kucera, Shinji Kim, 2026.11.03)입니다. 벤더의 제품 발표이므로 효과에 관한 내용은 회사 발표로 표시했고 독립 검증된 수치는 없습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 사례, 원문 사례 표는 원문을 AX Review가 다시 정리했습니다. 노드 종류, draft·approved·deprecated 상태, 도메인 권한, representation 점검 관련 내용은 Snowflake 제품 문서 「Business Ontology」(docs.snowflake.com, 프라이빗 프리뷰 문서)로 보강했습니다. 작은 예시, 기술·현업 실행 디테일, JSON 예시, 평가 기준, 막히는 경우 표, 일정과 판정 기준, 인포그래픽은 새로 작성한 실행 제안입니다. 전체 내용은 원문에서 볼 수 있습니다.