시맨틱 뷰 모델링 모범 사례

고품질 시맨틱 뷰는 Cortex Agents 에서 정확하고 직관적이며 신뢰할 수 있는 답변의 기초입니다. 이 섹션은 시맨틱 뷰를 설계하고 모델링하는 모범 사례를 설명합니다: 범위를 어떻게 잡고, 설명하고, 반복해 Cortex Agents가 올바른 SQL을 생성하게 하는지.

이러한 권장 사항은 시맨틱 뷰를 수동으로 작성하든 Semantic View Autopilot 으로 생성하든 적용됩니다. Autopilot은 고품질 시작점을 만드는 가장 빠른 방법입니다. 시맨틱 뷰를 프로그래밍 방식으로(예: CI/CD 파이프라인에서) 구축하는 것을 선호한다면 SQL 명령으로 시맨틱 뷰 생성 및 관리 및 시맨틱 뷰 개발 및 배포 모범 사례 를 참고하세요. 이 섹션은 다음 주제를 다룹니다.

참고

이 섹션은 시맨틱 뷰 모델링 모범 사례를 다룹니다. 시맨틱 뷰를 데이터 엔지니어링 파이프라인 또는 데이터 제품의 일부로 관리, 소유권 및 접근, 배포, dbt, BI 통합에 대한 지침은 시맨틱 뷰 개발 및 배포 모범 사례 를 참고하세요.

출처: Snowflake 문서

본문

설계 원칙

데이터베이스가 아니라 최종 사용자의 관점에서 설계하세요. 시맨틱 뷰를 모델링할 때 "이 데이터를 비즈니스 이해관계자에게 설명한다면 어떻게 설명하겠는가?"라고 물어보세요. 기술적인 테이블과 열 이름 대신 비즈니스 용어를 사용하세요.

비즈니스 도메인별로 조직하세요. 시맨틱 뷰를 비즈니스 주제 또는 도메인 — 예: Sales, Marketing, Customer Support — 를 중심으로 구성하고, 데이터 구조가 아니라 사용 사례별로 나누세요. 단일 시맨틱 뷰에서 모든 것을 다루려 하지 말고 각 모델을 집중적으로 유지하세요.

좋음: Sales Performance 시맨틱 뷰, Customer Support Metrics 시맨틱 뷰, Marketing Campaign Analysis 시맨틱 뷰.
피할 것: 단일 "All CRM Tables" 시맨틱 뷰.

범위 및 조직

작게 시작하세요. Cortex Agents가 더 이상 시맨틱 뷰 크기에 대한 하드 한도를 부과하지 않지만, 디버깅을 관리 가능하게 유지하기 위해 초기 개념 증명(proof of concept)은 5–10개의 테이블로 시작하세요. 단순한 스타 스키마(중앙 팩트 테이블이 차원 테이블과 조인)가 좋은 출발점입니다. 사용 사례가 커짐에 따라 확장하세요.

시맨틱 뷰를 약 100,000 토큰 미만으로 유지하세요. 시맨틱 뷰 크기에 대한 하드 한도는 없지만, 더 큰 시맨틱 뷰는 더 많은 위험을 수반합니다. 시맨틱 뷰가 대략 100,000 토큰을 넘어 성장하면 시맨틱 뷰, 에이전트 지침, 대화 기록의 결합 크기가 LLM의 컨텍스트 창에 가까워질 가능성이 더 높습니다. 이 시점에서 Cortex Agents는 맞추기 위해 시맨틱 뷰를 프루닝(prune) 해야 할 수 있으며, 이는 지연 시간을 추가하고 답변 품질을 낮출 수 있습니다. 약 100,000 토큰 미만을 유지하면 프루닝 가능성이 최소화됩니다. 이를 고정 임계값이 아닌 지침으로 취급하세요: 유효한 한도는 대화 기록 길이, 에이전트 지침, LLM의 컨텍스트 창에 따라 달라집니다.

비즈니스 관련 열만 포함하세요. 실제로 SQL 생성에 사용될 열을 추가하세요. 리트머스 테스트를 적용하세요: "내 최종 사용자가 이걸 물어볼까?" 관련 없는 열을 제외하면 모델을 간결하게 유지하고 정확도를 개선합니다.

단일 대규모 시맨틱 뷰와 여러 시맨틱 뷰 사이에서 선택하세요. 시맨틱 뷰가 커짐에 따라 분할할지 고려하세요.

자주 조인되는 밀집하게 연결된 테이블이 있거나, 많은 관련 테이블이 있는 단일 비즈니스 도메인이거나, 프루닝이 더 큰 시맨틱 뷰를 가능하게 하는 대형 컨텍스트 창 모델을 사용한다면 단일의 더 큰 시맨틱 뷰를 선호하세요.
조인할 필요가 없는 별개의 비즈니스 도메인이 있거나, 데이터의 다른 관점이 필요한 다른 사용자 그룹이 있다면 여러 시맨틱 뷰를 선호하세요.

여러 시맨틱 뷰를 사용할 때 Cortex Agents는 각 질문에 대해 가장 관련성 높은 시맨틱 뷰를 선택합니다. 다음 사항을 염두에 두세요.

각 시맨틱 뷰에 대해 명확하고 구별되는 설명을 작성하세요. 매우 유사한 여러 설명은 선택 정확도를 떨어뜨립니다.
유사성이 아니라 사용 사례별로 나누세요 (예: Sales vs. Legal vs. Marketing).
각 시맨틱 뷰는 독립적으로 쿼리됩니다. Cortex Agents는 별도의 시맨틱 뷰를 조인하지 않습니다.
시맨틱 뷰 간 선택은 약간의 지연 시간을 추가합니다(재순위 지정에 몇 초).

고객들은 프로덕션에서 50개 이상의 시맨틱 뷰로 Cortex Agents를 성공적으로 실행했지만, 일반적으로 더 적은 수의 시맨틱 뷰가 더 잘 작동합니다.

고품질 설명 작성

설명은 정확도에 가장 중요한 단일 요소입니다. 대규모 언어 모델은 독점 용어, 약어, 비즈니스 로직을 신뢰할 수 있게 추론할 수 없으므로, 명시적이고 권위 있는 설명이 답변 품질을 직접 결정합니다.

모든 테이블과 모든 열에 대해 명확한 비즈니스 설명을 작성하세요. 독점 용어와 레거시 이름을 설명하세요.

테이블 설명:

# Good
description: "Daily sales data by product line, aligned with 'Cost of Goods Sold' (COGS) and forecasted revenue. Use this table to analyze sales trends and profit by product."

# Poor — too vague
description: "Sales table"

열 설명:

# Good
- name: csat_score
  description: "Customer Satisfaction Score (CSAT): measures customer satisfaction on a scale of 1-5, where 5 is most satisfied. Also referred to as KPI_1 in legacy systems."

# Poor — assumes knowledge
- name: csat_score
  description: "Score"

동의어(Synonyms)

현재 지침은 모델이 알 것 같지 않은 고유하거나 업계 특정 용어가 없다면 동의어를 피하는 것입니다. 프론티어 모델을 사용한 최근 평가는 동의어가 일반적으로 정확도를 거의 더하지 못하고 의미 있는 이점 없이 토큰을 소비한다는 것을 보여줍니다. 동의어를 내부 용어, 약어, 레거시 이름용으로 아껴두고, 자동 생성보다는 수동으로 추가하세요: 자동 생성된 동의어는 종종 시맨틱 뷰 품질을 떨어뜨립니다.

Semantic Studio에서 동의어를 추가하는 방법은 Semantic Studio 를 참고하세요. 동의어는 이러한 가장자리 케이스에 대해 YAML 스펙 에서 계속 사용할 수 있습니다.

관계 정의

Cortex Agents는 관계가 시맨틱 뷰에서 명시적으로 정의되지 않으면 테이블을 조인하지 않습니다. 질문이 요구하는 모든 관계를 정의하세요. 관계 구문은 YAML 스펙 또는 SQL 명령으로 시맨틱 뷰 생성 및 관리 를 참고하세요.

다대다(many-to-many) 관계는 직접 지원되지 않습니다. 해결 방법으로 공유 차원(bridge) 테이블을 도입해 두 개의 일대다(one-to-many) 관계가 다대다 동작을 시뮬레이션하게 하세요.

지표 및 필터 정의

지표와 필터는 종종 과소 사용되지만 정확도와 일관성에 중요합니다. 가능한 곳이면 정의하세요. 워크플로우에서 Get more suggestions(종종 고품질 검증된 쿼리에 의해 구동됨)을 제공한다면 이를 사용해 추가 지표와 필터를 발견하세요.

지표는 사전 정의된 계산입니다.

metrics:
  - name: total_revenue
    description: "Sum of all order revenue, calculated as unit price × quantity"
    expr: SUM(unit_price * quantity)
  - name: average_order_value
    description: "Average revenue per order"
    expr: SUM(revenue) / COUNT(DISTINCT order_id)

필터는 재사용 가능한 WHERE-절 로직을 설명합니다.

filters:
  - name: active_customers
    description: "Customers with purchases in the last year"
    expr: last_purchase_date >= DATEADD(year, -1, CURRENT_DATE())

필터 정의 및 사용에 대한 자세한 내용은 시맨틱 뷰에서 논리 테이블용 필터 정의 를 참고하세요. 전체 지표 및 필터 구문은 YAML 스펙 을 참고하세요.

초기 설정 후 정확도 높이기

기본 구조가 갖춰지면 다음 기능이 작동하는 개념 증명과 신뢰할 수 있는 프로덕션 모델을 구분합니다. 각각 전용 주제가 있습니다. 아래 요약을 사용해 무엇을 적용할지 결정한 다음 상세 지침에 대한 링크를 따르세요.

검증된 쿼리(Verified queries)

검증된 쿼리는 검증된 "gold" SQL과 쌍을 이룬 질문의 예시입니다. 유사한 질문에 대한 정확도를 개선하고, 지연 시간을 줄일 수 있으며, Cortex Agents가 이를 일반화해 필터, 지표, 설명을 제안하게 합니다.

테이블, 열, 설명이 견고해진 후 검증된 쿼리를 추가하세요 — 지연 시간을 최적화하고 특수 케이스를 커버하는 데 사용하되, 불완전한 모델을 보완하는 데 사용하지 마세요. 가장 일반적인 질문부터 시작하고 시간이 지남에 따라 실제 사용량에 기반해 더 추가하세요. 자세한 내용은 검증된 쿼리 저장소 및 검증된 쿼리로 기존 시맨틱 뷰 또는 모델 최적화 를 참고하세요.

커스텀 지침(Custom instructions)

커스텀 지침을 사용하면 자연어로 SQL 생성과 질문 처리를 제어할 수 있습니다. 두 가지 범주가 있으며 가장 흔한 실수는 그것을 혼동하는 것입니다.

SQL 생성 지침은 모든 쿼리에 대한 SQL 생성 중에 적용됩니다 — 예: 비즈니스 특정 로직, 기본 필터, 회계연도 정의, 데이터 특이성.
질문 분류(Question categorization) 지침은 질문 이해에만 적용됩니다 — 예: 질문을 거부하거나 명확화 질문을 할 때.

구체적으로 말하세요("모든 쿼리를 지난 해로 필터링"보다는 "날짜 필터가 제공되지 않으면 지난 해에 대한 필터를 적용하세요"), 그리고 지침을 추가한 후 항상 테스트하세요. 자세한 내용과 예시는 커스텀 지침 을 참고하세요.

Cortex Search 서비스

Cortex Search 서비스는 사용자 입력이 데이터와 정확히 일치하지 않을 텍스트 열 — 예: 제품 이름("iPhone 13" vs. "Apple iPhone 13 - 128GB Blue"), 고객 이름, 회사 이름 — 에 대한 퍼지 매칭을 가능하게 합니다. 일반적으로 고카디널리티(약 10개 이상의 고유 값) 텍스트 열에 대해 Cortex Search 서비스를 구성하고, 저카디널리티 차원에는 대표적인 샘플 값을 제공하세요.

숫자 또는 날짜 열, 또는 메모, 설명, 코멘트 같은 문단 스타일 텍스트 필드에는 검색 서비스를 사용하지 마세요. 설정 지침과 카디널리티 지침 전체는 리터럴 검색 가이드 를 참고하세요.

테스트 및 반복

모델링을 일회성 설정이 아니라 반복 루프로 취급하세요.

평가 세트 생성. 비즈니스 사용자, 기존 대시보드, 실제 사용량에서 얻은 약 10개의 대표적인 벤치마크 질문으로 시작하세요. 다양한 복잡성 수준과 사용 사례를 커버하세요.
정확도 측정. Snowflake에서 네이티브 평가 를 실행해 검증된 쿼리와 대비해 SQL 정확도를 점수화하세요.
루프 닫기. 제안 패널과 피드백 데이터를 사용해 실제 사용량에서 검증된 쿼리를 추가한 다음, 사용자가 실제로 질문하는 방식과 일치하도록 지표, 필터, 커스텀 지침, 설명을 다듬으세요. 시맨틱 모델 및 뷰 제안 및 검증된 쿼리로 기존 시맨틱 뷰 또는 모델 최적화 를 참고하세요.

피해야 할 일반적인 함정

범위 미정의. 이해관계자가 개념 증명에 "딱 하나 더" 계속 추가합니다. 명확한 경계로 선명한 성공 기준을 미리 정의하세요.
너무 크게 시작. 첫날부터 전체 엔터프라이즈 데이터 웨어하우스를 모델링하려고 합니다. 5–10개의 테이블, 하나의 비즈니스 도메인, 특정 사용 사례로 시작하세요.
검증된 쿼리 과의존. 약한 모델을 패치하기 위해 많은 검증된 쿼리를 추가합니다. 먼저 테이블, 열, 설명을 올바르게 만든 다음 지연 시간을 최적화하고 특수 케이스를 커버하기 위해 검증된 쿼리를 추가하세요.
잘못된 초기 사용 사례. 거의 100%의 정확도가 필요한 Finance 또는 Legal 같은 도메인에서 시작합니다. Sales 또는 Marketing 같은 더 저위험 도메인에서 시작하세요.

프로덕션 준비 체크리스트

기반(Foundation):

모든 테이블이 명확한 비즈니스 설명을 가집니다.
모든 열이 명확한 설명을 가집니다.
독점 용어와 약어가 설명됩니다.

핵심 기능(Critical features):

검증된 쿼리가 일반적인 질문과 알려진 가장자리 케이스를 커버합니다.
커스텀 지침이 비즈니스 특정 로직을 포착합니다.
고카디널리티 텍스트 열에 대해 Cortex Search 서비스가 구성됩니다.
재사용 가능한 계산에 대해 지표가 정의됩니다.
일반적인 조건에 대해 필터가 정의됩니다.

테스트(권장, 배포 전):

평가 세트가 생성되었습니다.
평가 도구로 SQL 정확도가 측정되었습니다.

지속적 최적화(Ongoing optimization):

제안과 피드백 데이터가 정기적인 주기(예: 매주)로 검토됩니다.
새 검증된 쿼리와 관련 제안을 추가하는 프로세스가 마련되어 있습니다.

시맨틱 뷰 모델링 모범 사례