- **Semantic Layer(시맨틱 레이어)**는 복잡한 기술적 데이터 구조를 비즈니스 용어로 번역하는 business-facing 추상화 계층
- 데이터 웨어하우스와 소비 도구(BI·대시보드·AI copilot) 사이에 위치하는 중간 계층
- metric·dimension·entity·join·access policy를 한 번만 정의해 모든 소비자가 같은 숫자를 받게 하는 단일 진실 공급원(single source of truth)
쉽게 이해하기
“이번 달 매출 얼마야?”라는 한 질문에 영업팀·회계팀·대시보드가 서로 다른 숫자를 말한다면? 누구는 부가세 포함, 누구는 환불 제외… 정의가 제각각이기 때문이다.
학점(GPA)으로 비유하면 더 쉽다. 교수마다 점수 환산법이 다르면 같은 학생의 GPA가 들쭉날쭉할 것이다. 그래서 학교는 단 하나의 공식 환산표를 정해 둔다 — 누가 계산하든 같은 GPA가 나온다. 시맨틱 레이어가 바로 이 “공식 환산표”다. “매출”, “활성 사용자” 같은 지표의 계산법을 한 곳에 한 번만 정의해두면, BI 도구든 대시보드든 AI 비서든 모두 같은 숫자를 본다.
해당 개념이 필요한 이유
- 같은 지표(매출, 활성 사용자)를 도구마다 따로 정의 → 도구별로 숫자가 어긋나는 문제
- 비개발자가 SQL·스키마 지식 없이 데이터에 접근하려면 기술 용어 → 비즈니스 용어 매핑 필요
- BI·대시보드·AI copilot·서드파티가 각자 metric을 재구현하는 중복 비용
AS-IS — 도구마다 metric 재정의
flowchart LR DW[(Data Warehouse)] --> BI[BI 도구<br/>revenue 정의 A] DW --> DASH[제품 대시보드<br/>revenue 정의 B] DW --> AI[AI copilot<br/>revenue 정의 C] BI -. 숫자 불일치 .-> X((??)) DASH -. 숫자 불일치 .-> X AI -. 숫자 불일치 .-> X
TO-BE — 시맨틱 레이어로 단일 정의
flowchart LR DW[(Data Warehouse)] --> SL[Semantic Layer<br/>metric·dimension·join 1회 정의] SL --> BI[BI 도구] SL --> DASH[제품 대시보드] SL --> AI[AI copilot] SL --> TP[서드파티]
시맨틱 레이어 vs 메트릭 레이어
거의 동의어로 쓰인다. 메트릭 레이어는 metric 정의(revenue, active users)에 초점을 두고, 시맨틱 레이어는 거기에 더해 dimension·entity·join·access policy까지 더 넓게 포괄한다. 둘 다 “한 번 정의해 모두가 같은 숫자를 본다”는 목표는 같다.
Headless BI
시각화·정의 로직이 BI 도구 안에 묶여 있던 것을, 정의 계층만 떼어내 데이터 스택의 중앙에 두는 아키텍처다. 그 결과 BI 도구·제품 대시보드·AI copilot·서드파티가 metric을 각자 다시 짜지 않고 동시에 같은 시맨틱 백본을 질의할 수 있다.
주요 구현 비교
| 구현 | 특징 | lock-in |
|---|---|---|
| dbt Semantic Layer (MetricFlow) | dbt 프로젝트 안에서 metric 정의, Semantic Layer API로 질의 | dbt 생태계 내에서 표준화에 강함 |
| LookML (Looker) | BI 플랫폼에 내장된 시맨틱 모델링 언어 | Looker를 떠나면 metric 정의도 함께 잃음 (강한 lock-in) |
| Cube | headless 방식. 1개 정의 → SQL/REST/GraphQL/MDX 4개 API, 오픈소스 코어 | self-host 가능, 벤더 중립적 |
OKF와의 관계
OKF (Open Knowledge Format)도 metric·join·테이블 의미를 markdown 문서로 표현할 수 있어 시맨틱 레이어와 문제 영역이 겹친다. 다만 결정적 차이가 있다 — 시맨틱 레이어는 실행 가능한 쿼리 엔진/계층이고, OKF는 사람·에이전트가 교환하는 지식 표현 포맷이다. OKF는 “이 metric이 무엇을 의미하는지”를 문서로 전달하지, 직접 숫자를 계산해 주지는 않는다.
실제 적용 사례
① 다국적 소매기업의 “매출” 정의 통일 (dbt Semantic Layer)
가장 전형적인 적용은 지표 정의 통일이다. 한 다국적 소매기업의 사례가 구체적이다.
- Before — 유럽 법인은 매출에 VAT를 포함, 북미 팀은 제외. 환불을 어디선 음(−)의 매출로, 어디선 비용으로 처리. 분기 리뷰에서 같은 “매출”이 팀마다 다섯 가지 숫자로 나왔다.
- 적용 방식 — 매출 지표를 dbt YAML에 단 한 번 정의한다 (
판매액 합계, 세금 제외, 환불은 음의 매출로). MetricFlow가 이 정의로 최적화된 SQL을 자동 생성하고, Power BI(본사 재무)·Tableau(지역 분석)가 로컬에서 따로 계산하지 않고 API로 같은 지표를 질의한다. - 결과 — CEO의 모든 발표 자료에 단일 매출 숫자가 떴다.
이점(수치 포함) — 리포트 대조에 쓰던 시간이 급감해 분석가가 숫자 검증에 쓰던 시간의 약 50%를 절약한 것으로 추정된다. “누구 리포트가 맞냐”를 두고 벌이던 논쟁이 0이 됐고(“we now spend zero time debating whose report is correct”), 외부 감사인도 dbt에서 정의와 생성된 SQL을 그대로 추적할 수 있어 규제 신뢰성까지 올라갔다.
② AtScale — 20TB+ 큐브로 수백 명 Excel 사용자에게 거버넌스된 지표
대형 홈임프루브먼트 소매업체는 AtScale 위에 20TB+ 규모의 시맨틱 큐브를 올려, 매일 수백 명의 Excel 사용자가 동일하게 거버넌스된 지표를 피벗테이블로 조회한다.
이점 — 비개발자(Excel 사용자)가 SQL 없이도 항상 같은 정의의 지표를 쓰고, BI 도구를 바꿔도 지표 정의는 큐브 한 곳에 남는다. “현업의 셀프서비스”와 “거버넌스”가 충돌하지 않게 만든 사례다.
③ Cube — 챗봇 일관성에서 출발한 headless 사례
Cube는 2018년 “Slack 챗봇이 항상 같은 답을 내놓게” 만들려던 사이드 프로젝트에서 출발했다. 그래서 처음부터 대시보드가 아니라 앱·AI 에이전트에 지표를 서빙하도록 설계됐고, 1개 정의 → SQL/REST/GraphQL/MDX 4개 API로 노출한다.
이점 — 대시보드뿐 아니라 AI copilot·제품 기능·서드파티가 같은 지표 백본을 동시에 질의할 수 있다. AI 에이전트 시대에 “에이전트가 직접 숫자를 재계산하다 틀리는” 문제를 차단한다.
④ LookML(Looker) — 강력하지만 lock-in의 교훈
LookML은 가장 널리 쓰인 시맨틱 모델이지만 정의가 Looker 안에 묶여, Looker를 떠나면 지표 정의도 함께 잃는다.
교훈 — “Format, not Platform”을 강조하는 OKF·headless 진영이 반면교사로 드는 사례다. 같은 시맨틱 자산이라도 어디에 묶이느냐가 이식성을 좌우한다는 점을 보여준다.