데이터 거버넌스에서 시맨틱 레이어의 역할

Source: Dev.to

대부분의 조직은 데이터 거버넌스 정책을 가지고 있습니다. 그 정책은 Confluence 페이지에 보관되어 있으며, 누가 어떤 데이터를 소유하고, 용어는 무엇을 의미하며, 누가 접근 권한을 가져야 하는지를 정의합니다. 하지만 실제 쿼리가 실행되는 곳에서는 이 정책이 적용되지 않기 때문에 거의 아무도 따르지 않습니다.

semantic layer는 이러한 상황을 바꿉니다. 거버넌스를 문서에서 쿼리 경로로 옮겨, 모든 규칙이 자동으로, 모든 사용자에게, 모든 도구를 통해 적용되도록 합니다.

서면 거버넌스 vs. 실제 거버넌스

Data governance fails when it depends on people doing the right thing manually.

• A policy says “Revenue means completed orders minus refunds.”
• An analyst writes a slightly different formula.
• A dashboard uses the wrong table.
• An AI agent invents its own definition.

The governance policy exists, but nobody follows it, and the organization makes decisions on inconsistent data.

The root cause isn’t carelessness; it’s that governance is separated from the systems people actually use to query data. Enforcement happens in a side channel — documentation, review processes, audit logs — not in the query itself.

중앙 집중식 정의가 상충되는 메트릭을 제거한다

시맨틱 레이어는 거버넌스 정책을 코드로 전환함으로써 정의 문제를 해결합니다.

CREATE VIEW business.revenue AS
SELECT
    OrderDate,
    Region,
    SUM(OrderTotal) AS Revenue
FROM silver.orders_enriched
WHERE Status = 'completed' AND Refunded = FALSE
GROUP BY OrderDate, Region;

Revenue가 필요한 모든 대시보드, 노트북, AI 에이전트는 이 뷰를 쿼리합니다. 사용할 대체 공식이 없습니다. 시맨틱 레이어는 이 메트릭에 대한 거버넌스 그 자체입니다.

정의가 변경될 때(예: 새로운 환불 카테고리가 추가되는 경우) 뷰를 한 번만 업데이트하면 모든 사용자가 자동으로 새로운 로직을 적용받습니다—별도의 롤아웃, 마이그레이션, “모두가 대시보드를 업데이트했는지?” 확인이 필요 없습니다.

쿼리 시점에 적용되는 접근 정책

두 번째 거버넌스 격차는 접근 제어입니다. 대부분의 조직은 BI‑툴 수준(예: Tableau, Power BI 등)에서 보안을 적용합니다. 누군가 SQL 클라이언트를 열어 기본 테이블을 직접 조회하면 이러한 필터가 적용되지 않습니다.

시맨틱 레이어는 정책을 더 낮은 수준에서 강제하므로 모든 쿼리 경로에 적용됩니다:

Dremio는 세분화된 접근 제어(Fine‑Grained Access Control, FGAC) 를 통해 이를 구현합니다: 정책은 UDF 형태로 정의되어 조회하는 사용자의 역할에 따라 행을 필터링하고 열을 마스킹합니다. 이러한 정책은 가상 데이터셋(뷰) 수준에서 적용됩니다.

예시: 지역 관리자가 business.revenue 를 조회하면 자신의 지역 데이터만 볼 수 있고, 데이터 엔지니어는 모든 지역 데이터를 볼 수 있습니다. 동일한 뷰, 동일한 SQL이지만 신원에 따라 결과가 달라집니다.

이렇게 하면 사용자가 BI 툴을 우회할 때 발생하는 “보안 격차”가 사라집니다. 데이터에 대한 모든 접근 경로가 시맨틱 레이어를 통과하고 정책을 상속받게 됩니다.

뷰를 통한 라인리지와 책임성

시맨틱 레이어가 사용하는 계층형 뷰 아키텍처(Bronze → Silver → Gold)는 본질적으로 추적 가능합니다. 모든 Gold 메트릭은 해당 Silver 비즈니스 로직으로, 그 로직은 Bronze 소스 매핑으로, 그리고 최종적으로 원시 데이터로 거슬러 올라갑니다.

감사자가 “수익 수치는 어디서 나왔나요?”라고 물으면, 대시보드나 노트북을 뒤져볼 필요 없이 뷰 체인을 따라가면 됩니다:

gold.monthly_revenue_by_region
    → references silver.orders_enriched
silver.orders_enriched
    → joins bronze.orders_raw with bronze.customers_raw
bronze.orders_raw
    → maps to production.public.orders in PostgreSQL

각 단계가 문서화되어 있고, 모든 변환이 눈에 보입니다. 라인리지는 사후에 재구성되는 것이 아니라 구조 자체에 내재되어 있습니다.

거버넌스 도구로서의 문서화

거버넌스는 발견 가능성과도 관련이 있습니다. 누군가가 다섯 사람에게 메시지를 보내지 않고도 올바른 데이터셋을 찾을 수 있을까요? 뷰가 프로덕션에 적합한지, 실험용인지 판단할 수 있을까요?

시맨틱 레이어에서 이를 처리하는 두 가지 메커니즘:

1. 위키 – 테이블, 컬럼, 뷰에 사람과 AI가 읽을 수 있는 설명을 첨부합니다.
2. 태그 / 라벨 – 자산을 PII, financial, experimental 등으로 분류하여 사용자와 자동화 도구가 필터링하거나 추가 정책을 적용할 수 있게 합니다.

이 두 요소가 결합되어 데이터 카탈로그를 정적인 문서가 아니라 살아있는 거버넌스의 일부로 만들어 줍니다.

데이터가 나타내는 내용, 출처 및 주의사항 설명

cltv라는 열에 설명이 제공됩니다:

고객 평생 가치 (Customer Lifetime Value), 최초 구매부터 현재까지의 총 매출을 환불을 제외하고 계산한 값.

라벨

라벨은 데이터 거버넌스 워크플로우를 위해 데이터를 분류합니다.

• PII – 자동 열 마스킹을 트리거합니다.
• Certified – 해당 뷰가 검토되어 프로덕션 사용이 승인되었음을 나타냅니다.
• Deprecated – 사용자가 대체 항목으로 마이그레이션하도록 경고합니다.

수천 개의 데이터셋을 보유한 조직에서는 수동 문서화가 비현실적입니다. Dremio의 생성 AI는 테이블 데이터를 샘플링하여 위키 설명을 자동으로 생성하고, 열 내용에 기반해 라벨을 제안합니다. 이를 통해 문서화가 자동으로 약 70 % 수준까지 부트스트랩됩니다; 이후 데이터 팀이 AI가 놓친 부분을 보완합니다.

인증 및 변경 관리

모든 뷰가 동일한 것은 아닙니다. 의미 계층은 실험 중인 뷰, 검토 중인 뷰, 그리고 프로덕션 준비가 된 뷰를 구분해야 합니다.

실용적인 인증 워크플로

• 각 Certified 뷰에는 정확성과 최신성을 책임지는 소유자가 문서화되어 있어야 합니다.
• 비즈니스 요구사항이 변경될 경우, 소유자는 뷰 및 해당 문서를 함께 업데이트합니다.
• 라벨이 Certified 로 다시 적용되기 전에 변경 사항이 검토됩니다.

이 워크플로는 고급 도구를 필요로 하지 않습니다. 라벨, 위키, 그리고 프로세스에 대한 팀 합의만으로 충분합니다. 중요한 것은 거버넌스가 의미 계층 내부에 가시적으로 존재한다는 점이며, 별도의 시스템에서 추적될 필요는 없습니다.

다음에 할 일

1. 상위 10개 비즈니스 지표를 감사하세요.
2. 각 지표마다 세 가지 질문을 하세요:
   • 공식이 한 곳에 정의되어 있나요?
   • 액세스 제어가 쿼리 수준에서 적용되고 있나요 (BI 도구만이 아니라)?
   • 해당 수치를 60 초 이내에 원시 소스로 추적할 수 있나요?

‘아니오’가 하나라도 나오면 시맨틱 레이어가 메울 수 있는 거버넌스 격차가 드러납니다.

---

Try Dremio Cloud free for 30 days