본문으로 건너뛰기

인증된 시맨틱 거버넌스로 신뢰 가능한 Snowflake AI 에이전트 구축

인증된 카탈로그·메트릭을 추출해 LLM 제약 생성과 PR 기반 승인, CI/CD로 배포하는 시맨틱 뷰 거버넌스 파이프라인의 실무적 구현이다

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

에이전트의 신뢰성 문제는 일관된 메트릭 정의와 검증된 데이터 컨텍스트가 없기 때문에 발생한다. 글은 인증된 카탈로그와 메트릭 인벤토리에서만 컨텍스트를 추출하고, LLM 출력을 엄격히 제약한 뒤 도메인 소유자 PR 검수를 거쳐 CI/CD로 배포하는 파이프라인을 제안한다. 이 흐름은 PII 제외·수식 일관성·감사 추적을 확보해 Cortex Analyst와 에이전트가 인증된 시맨틱 뷰를 근거로 결정론적 응답을 반환하도록 한다.

섹션별 상세

AI 에이전트의 품질 문제는 통제되지 않은 데이터 정의에서 비롯된다는 문제가 반복해서 관찰된다; 팀들이 속도에 밀려 거버넌스를 생략하면 동일한 지표가 여러 방식으로 재정의되고 결과가 일관되지 않게 나온다. 이 글은 시맨틱 뷰 생성을 소프트웨어 릴리스처럼 다루어 인증·검증·버전 관리와 배포 파이프라인을 결합하는 해결책을 제시한다. 실제 구현은 인증된 메트릭·카탈로그 추출→LLM 제약 생성→PR 심사(휴먼 게이트)→CI/CD 배포의 순서로 이루어져 있으며, 이 흐름이 답변의 결정론성과 감사 가능성을 확보한다.
python
cursor.execute(f"""
SELECT metric_name, description, expression, base_table
FROM GOVERNANCE_DB.SEMANTICS.METRIC_INVENTORY
WHERE certification_status = 'Certified'
  AND base_table IN ({table_list})
""")
metrics = [ {"metric_name": r[0], "description": r[1], "expression": r[2], "table": r[3]} for r in cursor.fetchall() ]

이 파이썬 코드 조각은 거버넌스 DB에서 certification_status가 'Certified'로 표시된 메트릭 정의만 선별해 가져온다. 결과는 메트릭 이름·설명·표현식·기본 테이블을 포함하는 리스트로 변환되어 이후 생성 단계의 입력으로 사용된다. 이 방식은 모델 추론이 아니라 승인된 정의만 파이프라인으로 흘러가도록 보장한다.

Semantic layer governance framework data flow 다이어그램
Diagram이 다이어그램은 인증된 소스에서 시작해 컨텍스트 추출, JSON 페이로드 생성, LLM 제약 생성, PR과 휴먼 게이트, CI/CD, 최종적으로 SEMANTIC VIEW로 배포되는 전체 파이프라인 흐름을 시각적으로 연결한다. 각 단계 사이의 입력·출력 형태(예: certified inputs, JSON payload, dbt model)가 명확하게 표시되어 파이프라인이 어떻게 결정론적 근거를 유지하는지 보여준다. 거부 루프와 승인 경로가 색으로 구분돼 있어 인증 단계의 통제 지점이 한눈에 확인된다.
Governance framework for trustworthy Snowflake AI agents 아키텍처 다이어그램
Diagram이 아키텍처 그림은 Snowflake Horizon(카탈로그)과 Metric Inventory(거버넌스 DB)를 입력으로 하는 생성 파이프라인과, 배포 후 Cortex Analyst·Agent·CoWork가 결과를 소비하는 전체 시스템을 계층별로 정리한다. 기술 스택(예: Python, dbt, GitHub Actions)과 선택적 Apache Ossie Export를 함께 배치해 운영·배포·소비의 책임 분리를 시각화한다. 조직 관점에서 누가 어디에 관여하는지와 배포 경로를 빠르게 파악할 수 있다.
데이터 카탈로그와 메트릭 인벤토리라는 두 개의 거버넌스 기둥이 핵심 입력이라는 전제가 있다; 카탈로그는 컬럼 설명·데이터 타입·PII 태그·샘플값을 보관하고 메트릭 인벤토리는 공식 수식·책임자·인증 상태를 단일 원본으로 관리한다. 파이프라인은 카탈로그의 certification_status='Certified' 태그와 인벤토리의 인증된 수식만 허용하므로 임의의 정의 반영을 차단한다. 이 방식은 조직 내 숫자 불일치와 소유권 미비를 해결해 결과의 신뢰도를 높인다.
text
SYSTEM_PROMPT = """You are an expert Data Engineer building dbt semantic models for Snowflake. You will receive a JSON context payload with: - metrics: certified metric definitions (metric_name, expression, table) - catalog: physical columns per table (table, column, data_type, description, tag) - table_descriptions: [{ table, description }] source table in Snowflake Produce ONE valid dbt model file using the Snowflake-Labs dbt_semantic_view package. Output ONLY the raw file contents. No prose, no markdown fences, no preamble. Required clauses, in this exact order, separated by newlines: {{ config(materialized='semantic_view') }} TABLES ( AS {{ source('', '') }} [ PRIMARY KEY () ] [ COMMENT = '' ] ) RELATIONSHIPS ( AS () REFERENCES ) FACTS ( . AS [ COMMENT = '...' ] [, ...] ) DIMENSIONS ( . AS [ COMMENT = '...' ] [, ...] ) METRICS ( . AS [ COMMENT = '...' ] [, ...] ) COMMENT = '' PII handling: any column whose `tag` contains 'PII' (case-insensitive) MUST be excluded from FACTS, DIMENSIONS, and METRICS."""

이 시스템 프롬프트는 LLM 출력 형식을 엄격히 고정해 dbt_semantic_view 문법으로만 결과를 생성하도록 만든다. 프롬프트에 PII 태그 처리 규칙이 포함되어 있어 입력 컨텍스트에 PII가 있으면 해당 컬럼을 메트릭·팩트·차원에서 배제한다. 덕분에 생성물은 검토자가 예측 가능한 형식으로 비교·검증할 수 있는 구조로 나온다.

근거
  • LLM 기반 생성으로 생성물은 수작업보다 약 95%의 초안 정확도를 내는 경우가 많다. 본문의 'probably 95% accurate' 언급; Constrained Generation 섹션의 시스템 프롬프트와 입력 제약을 근거로 삼음.
  • PII 태그가 포함된 컬럼은 생성된 시맨틱 뷰의 FACTS/DIMENSIONS/METRICS에서 반드시 제외된다. 시스템 프롬프트 내 'PII handling' 규칙과 카탈로그에서의 태그 추출 예제.
LLM을 활용한 생성 단계는 완전 자동화가 아니라 제약된 생성으로 설계되어 출력 형식과 필드 매핑을 강제한다; 시스템 프롬프트는 dbt_semantic_view 문법을 정확한 순서로 요구하고 PII 태그가 붙은 컬럼은 메트릭·팩트·차원에서 제외하도록 지시한다. 입력 컨텍스트가 인증된 메트릭과 카탈로그에 한정되므로 모델이 새로운 컬럼이나 수식을 발명할 여지가 줄어든다. 글에서는 이 접근이 수작업을 대부분 대체해 일관된 초안(대략 95% 정확도)을 생성한다고 기술했다.
python
def open_pr_for_file(owner, repo, file_path, content, commit_message, pr_title, pr_body, branch, base="master", token="", draft=False) -> str:
    if not token:
        raise ValueError("GITHUB_TOKEN is required")
    base_sha = get_default_branch_sha(owner, repo, token, base=base)
    create_branch(owner, repo, base_sha, branch, token)
    put_file(owner, repo, file_path, content, commit_message, branch, token)
    return create_pr(owner, repo, pr_title, pr_body, branch, base, token, draft=draft)

이 함수는 자동화된 워크플로에서 생성된 시맨틱 모델 파일을 새로운 브랜치에 커밋하고 PR을 여는 일련의 동작을 감싼다. 각 단계는 단일 책임으로 구현되어 PR 이력과 변경사항 비교가 명확하게 남는다. 도메인 소유자가 PR을 승인해야만 CI가 배포 흐름을 계속 진행할 수 있도록 설계되었다.

근거
  • 생성된 정의는 자동 병합되지 않고 PR을 통해 도메인 소유자의 승인 없이 배포되지 않는다. Human Certification Gate와 GitHub API 흐름 코드, CI 규칙 설명.
생성된 정의는 자동 머지가 아니라 새로운 브랜치로 커밋한 뒤 PR로 올려 도메인 소유자 또는 데이터 스튜어드가 인증 루브릭에 따라 검토·승인해야 한다는 점이 하드 게이트로 작동한다; CI는 승인 없는 병합 시 배포를 차단한다. 검증 루브릭에는 소스 추적, 개인정보 보호 확인, 수식 정확성, 라벨·이름 명확화, 실데이터 테스트, 공식 승인 항목이 포함된다. 이 절차를 통해 누가 언제 어떤 정의를 승인했는지에 대한 감사 증적을 남길 수 있다.
머지 후 GitHub Actions가 dbt build를 실행해 native Snowflake SEMANTIC VIEW 객체를 생성하면 Cortex Analyst·Cortex Agent·Snowflake CoWork가 해당 객체를 직접 쿼리해 자연어 질문에 대해 인증된 메트릭으로 구성된 grounded SQL과 결과를 반환한다. 이 런타임 체인은 각 단계가 동일한 인증된 정의를 참조하므로 어느 단계도 자체적으로 새로운 논리를 유도하지 않는다. 결과적으로 대화형 BI와 에이전트 응답은 원천적으로 검증된 수치에 기반한 결정론적 답변을 제공한다.
yaml
on: push:
  branches: [master]
  paths: ['semantic_models/models/semantic_views/**']
jobs:
  deploy-dbt-models:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: '3.10' }
      - run: pip install -r requirements.txt
      - run: dbt deps
      - run: dbt debug
      - run: dbt build --select semantic_views

이 GitHub Actions 워크플로는 master 브랜치로 병합될 때 dbt를 실행해 인증된 시맨틱 모델을 Snowflake SEMANTIC VIEW 객체로 컴파일·배포한다. 워크플로는 체크아웃, 의존성 설치, dbt debug와 build를 차례로 수행해 빌드 실패 시 자동으로 배포를 중단한다. 이 구조로 인해 머지된 커밋 하나가 언제 어떻게 프로덕션 뷰로 변환되었는지 추적 가능하다.

Cortex Analyst 인터페이스 스크린샷(semantic view 구성 및 질의 예제)
Screenshot스크린샷 왼쪽은 SAAS_BILLING 시맨틱 뷰의 논리 테이블·차원·설명 필드를 보여주고 오른쪽은 자연어 쿼리 입력에 대해 Cortex Analyst가 생성한 테이블 결과와 사용된 SQL을 표시한다. 실제 UI 예시는 런타임에서 사용자가 직접 인증된 시맨틱 뷰를 조회해 grounded SQL과 결과를 받는 흐름을 확인시킨다. 이 이미지는 텍스트-투-SQL이 인증된 메트릭을 어떻게 재사용하는지에 대한 실무적 증거 역할을 한다.
Finance agent 도구 설정 화면 스크린샷
Screenshot이 화면은 에이전트 구성에서 'Query structured data' 도구로 SAAS_BILLING 시맨틱 뷰가 연결된 예를 보여준다. 각 에이전트가 어떤 시맨틱 뷰를 도구로 사용할지 명시하고 설명을 붙이는 방식으로 운영 정책과 사용 범위를 함께 기록하는 모습을 확인할 수 있다. 운영자가 에이전트에게 어느 뷰를 언제 쓰게 할지 정책 수준에서 통제하는 지점이 드러난다.
Snowflake CoWork 대화형 인터페이스 스크린샷
Screenshot대화형 채팅 UI는 사용자가 자연어로 질문을 던지고 에이전트(예: FINANCE_AGENT)를 선택해 응답을 받는 흐름을 보여준다. UI 예시는 최종 소비자가 인증된 시맨틱 뷰 기반 에이전트를 통해 즉시 비즈니스 질문에 답변을 받는 사용자 경험을 입증한다. 이는 앞선 빌드·검증 절차가 실제 비즈니스 상호작용에서 어떻게 결과로 이어지는지 연결한다.
Runtime Query Flow 다이어그램
Diagram런타임 시퀀스 다이어그램은 사용자가 질문을 입력한 뒤 Snowflake CoWork→Cortex Agent→Cortex Analyst→SEMANTIC VIEW 순으로 질의가 라우팅되어 최종적으로 인증된 결과 행이 반환되는 과정을 단계별로 표시한다. 다이어그램 하단의 주석은 각 홉이 동일한 인증된 메트릭 정의를 참조한다고 명시해 런타임에서 재유도되는 논리가 없음을 강조한다. 이 그림은 배포된 시맨틱 뷰가 실시간 응답 체인에서 결정론적 근거로 작동함을 시각적으로 뒷받침한다.
근거
  • 머지 후 GitHub Actions가 dbt build를 실행해 SEMANTIC VIEW 객체를 Snowflake에 배포한다. Component 5에 포함된 GitHub Actions 예시 워크플로우 YAML.
선택적 Apache Ossie 내보내기는 인증 아티팩트를 공급자 중립 포맷으로 직렬화해 다른 툴에서 변환 비용을 낮추는 보완 수단이다; expression.dialects 구조를 사용해 엔진별 표현식을 함께 기록하되 포맷 자체가 즉시 모든 환경에서 실행 가능성을 보장하지는 않는다. 본문은 Ossie를 AI 컨텍스트 필드(ai_context)로 보강해 에이전트가 적절한 메트릭을 선택하도록 돕되, 소유권·인증 증거·승인 이력은 권위 있는 거버넌스 시스템에 유지할 것을 권고했다. 이 접근은 장기적 상호운용성 비용을 줄일 수 있다는 이점을 제공한다.
근거
  • Apache Ossie는 인증 아티팩트를 엔진별 표현식을 포함해 공급자 중립 형식으로 직렬화할 수 있다. Ossie 예시 스니펫의 expression.dialects 구조와 ai_context 필드 사용.

용어 해설

시맨틱 뷰(Semantic View)
시맨틱 뷰는 데이터 웨어하우스에 저장되는 스키마 수준의 객체로, 비즈니스 용어·측정식·차원·관계를 하나의 정형화된 정의로 묶는다. 쿼리 소비자는 시맨틱 뷰를 통해 동일한 집계 논리와 필터를 재사용하므로 숫자 불일치와 재정의가 사라진다. 본문에서는 dbt를 통해 빌드된 SEMANTIC VIEW 객체를 CI/CD로 배포하는 방식을 예로 들었다.
데이터 카탈로그(거버넌스)(Data Catalog)
데이터 카탈로그는 테이블·컬럼의 설명, 데이터 타입, 샘플값, 민감도 태그(PII/PHI)와 인증 상태를 단일 출처로 기록하는 저장소이다. 파이프라인은 카탈로그의 certified 태그를 기준으로만 시맨틱 뷰 필드와 메트릭을 허용하므로 무단 추론이나 비준인 항목 반영을 방지한다. 예시 구현에서는 Snowflake Horizon을 카탈로그로 사용해 컬럼 단위 태깅과 동적 마스킹을 연동했다.
메트릭 인벤토리(거버넌스 DB)(Metric Inventory)
메트릭 인벤토리는 각 메트릭의 공식 수식, 책임자, 출처 테이블, 도메인, 민감도 분류와 인증 상태를 보관하는 단일 진실의 원천이다. 메트릭은 한 번 정의되면 재사용되며, 배포 전 도메인 소유자의 서명이 있어야 'Certified'로 간주된다. 이를 통해 조직 전체에서 동일한 메트릭 정의를 일관되게 조회하고 감사 가능하게 만든다.
제약된 생성(LLM 제어)(Constrained Generation)
제약된 생성은 LLM에 고정된 출력 형식·필드 매핑 규칙·PII 제외 규칙을 강제하는 시스템 프롬프트를 적용해 코드를 생성하게 하는 기법이다. 입력은 오직 인증된 메트릭과 카탈로그 컨텍스트만 허용하므로 모델이 임의로 컬럼이나 수식을 발명할 여지를 줄인다. 본문에서는 dbt_semantic_view 문법으로만 출력하도록 시스템 프롬프트를 고정한 예제를 제시했다.
CI/CD와 감사 추적(CI/CD + Audit)
시맨틱 뷰 정의를 코드 아티팩트로 버전 관리하고 PR·머지·배포 이력을 남기는 파이프라인은 감사 가능성과 롤백을 보장한다. 승인 없는 병합이나 자동 배포를 차단하는 CI 규칙은 데이터 정의의 무단 변경을 방지한다. 글에서는 GitHub Actions로 dbt build를 실행해 최종 SEMANTIC VIEW 객체를 생성하는 흐름을 사용했다.

기술

  • Snowflake
  • dbt
  • dbt_semantic_view
  • GitHub Actions
  • Cortex Analyst
  • Cortex Agent
  • Snowflake CoWork
  • Claude
  • GPT
  • Qwen
  • GLM
  • Apache Ossie

활용 사례

  • 자격 증명된 메트릭을 기반으로 하는 자연어 질문 응답과 Text-to-SQL 서비스 제공
  • 대시보드·스프레드시트·에이전트를 통합하는 단일화된 메트릭 출처 유지
  • 민감 정보(PII)를 자동으로 배제하면서 에이전트 응답의 프라이버시 규정 준수 보장
  • 버전·감사 추적이 가능한 시맨틱 정의를 통해 규제 준수 및 내부 감사 지원
AI 분석 전체 내용 보기

AI 요약 · 북마크 · 개인 피드 설정 — 무료

출처 · 인용 안내

원문 발행 2026. 08. 08.수집 2026. 08. 08.출처 타입 RSS

인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.