TL;DR
에이전트의 신뢰성 문제는 일관된 메트릭 정의와 검증된 데이터 컨텍스트가 없기 때문에 발생한다. 글은 인증된 카탈로그와 메트릭 인벤토리에서만 컨텍스트를 추출하고, LLM 출력을 엄격히 제약한 뒤 도메인 소유자 PR 검수를 거쳐 CI/CD로 배포하는 파이프라인을 제안한다. 이 흐름은 PII 제외·수식 일관성·감사 추적을 확보해 Cortex Analyst와 에이전트가 인증된 시맨틱 뷰를 근거로 결정론적 응답을 반환하도록 한다.
섹션별 상세
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'로 표시된 메트릭 정의만 선별해 가져온다. 결과는 메트릭 이름·설명·표현식·기본 테이블을 포함하는 리스트로 변환되어 이후 생성 단계의 입력으로 사용된다. 이 방식은 모델 추론이 아니라 승인된 정의만 파이프라인으로 흘러가도록 보장한다.


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' 규칙과 카탈로그에서의 태그 추출 예제.
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 규칙 설명.
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를 차례로 수행해 빌드 실패 시 자동으로 배포를 중단한다. 이 구조로 인해 머지된 커밋 하나가 언제 어떻게 프로덕션 뷰로 변환되었는지 추적 가능하다.




- 머지 후 GitHub Actions가 dbt build를 실행해 SEMANTIC VIEW 객체를 Snowflake에 배포한다. — Component 5에 포함된 GitHub Actions 예시 워크플로우 YAML.
- 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 Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
