Semantic Layer·Metrics Store·Reverse ETL 완전 가이드: dbt·Cube·Looker·Hightouch·Census, 데이터 활성화 (2025)

Season 5 Ep 5 — Ep 4가 파이프라인의 엔지니어링이었다면 Ep 5는 "데이터의 의미를 한 번만 정의한다"는 오래된 약속의 2025년 버전.

• Prologue — "왜 매출이 팀마다 다르게 나오는가?"
• 1장 · Semantic Layer의 역사
  • 1.1 1세대: BI 내부 정의
  • 1.2 2세대: Looker의 LookML (2013–)
  • 1.3 3세대: Headless / Open Semantic Layer (2020–)
  • 1.4 왜 지금 다시 뜨는가
• 2장 · Semantic Layer의 구성
  • 2.1 핵심 엔티티
  • 2.2 관계와 조인
  • 2.3 필터·파라미터
  • 2.4 예시 (dbt Semantic Layer / MetricFlow)
• 3장 · dbt Semantic Layer / MetricFlow
  • 3.1 배경
  • 3.2 구조
  • 3.3 강점
  • 3.4 한계
• 4장 · Cube — "개발자용 Semantic Layer"
  • 4.1 정체성
  • 4.2 특징
  • 4.3 예시
  • 4.4 쓰는 곳
• 5장 · Looker·LookML — "엔터프라이즈의 클래식"
  • 5.1 정체성
  • 5.2 강점
  • 5.3 한계
  • 5.4 2025 전략
• 6장 · 다른 주요 도구
  • 6.1 AtScale
  • 6.2 Lightdash
  • 6.3 Transform (dbt)
  • 6.4 Metabase·Superset
  • 6.5 Thought Spot
• 7장 · Metrics Store 패턴
  • 7.1 개념
  • 7.2 구성
  • 7.3 예
  • 7.4 효과
• 8장 · Headless BI
  • 8.1 정체성
  • 8.2 장점
  • 8.3 도구
  • 8.4 한계
• 9장 · Reverse ETL — "데이터를 운영으로 되돌리기"
  • 9.1 왜 필요한가
  • 9.2 주요 도구
  • 9.3 패턴
  • 9.4 사례
  • 9.5 데이터 활성화(Data Activation)
• 10장 · AI·LLM과 Semantic Layer
  • 10.1 왜 AI가 Semantic Layer를 필요로 하는가
  • 10.2 "Text-to-SQL" vs "Text-to-Metric"
  • 10.3 사례
  • 10.4 품질 관리
  • 10.5 2025년 방향
• 11장 · Data Activation 실전 시나리오 3
  • 11.1 커머스 — 개인화 추천
  • 11.2 B2B SaaS — Product-led Sales
  • 11.3 핀테크 — Risk scoring
• 12장 · 한국 기업 성숙도
  • 12.1 현황
  • 12.2 도입 패턴
  • 12.3 고려사항
• 13장 · 안티패턴 10선
  • 13.1 Semantic Layer 없이 AI 직접 연결
  • 13.2 LookML만에 의존
  • 13.3 지표 소유자 불명
  • 13.4 Deprecation 없이 변경
  • 13.5 Reverse ETL 경로 난립
  • 13.6 Reverse ETL로 실시간 기대
  • 13.7 Metric 버전 없이 운영
  • 13.8 지표를 Superset/Metabase에만 정의
  • 13.9 자연어 BI 무결성 검증 부족
  • 13.10 팀마다 자체 SQL로 지표 계산
• 14장 · 체크리스트 — Semantic Layer·Reverse ETL 12가지
• 15장 · 다음 글 예고 — Season 5 Ep 6: "Feature Store와 Vector·Graph·시계열 DB의 융합"

Prologue — "왜 매출이 팀마다 다르게 나오는가?"

2015년 많은 회사가 겪은 고전적 혼란:

• 재무팀: "이번 달 매출 10억"
• 마케팅: "이번 달 매출 11.5억"
• 세일즈: "이번 달 매출 9.7억"

같은 데이터, 다른 숫자. 이유는:

• 환불 처리 방식
• 세금 포함 여부
• 통화 환산 기준일
• 인정 시점(주문 시 vs 입금 시)

각 팀이 자기 SQL을 직접 쓰기 때문에 정의가 갈라진다. Semantic Layer는 이 문제를 "지표 정의를 한 군데"로 모아 해결하려는 시도다.

1장 · Semantic Layer의 역사

1.1 1세대: BI 내부 정의

• Business Objects, Cognos, MicroStrategy (1990s–2000s)
• 각 BI 툴 내부에 정의 → 벤더 락인

1.2 2세대: Looker의 LookML (2013–)

• LookML로 코드화된 지표 정의
• Git 관리, 재사용
• 단점: Looker 전용

1.3 3세대: Headless / Open Semantic Layer (2020–)

• BI와 독립된 별도 계층
• dbt Semantic Layer / MetricFlow (2022)
• Cube (2019–)
• Transform(2021, → dbt 인수 2022)
• AtScale(엔터프라이즈)

1.4 왜 지금 다시 뜨는가

• 데이터 스택 분절화 → 지표 중복 심화
• AI·챗봇이 데이터 쿼리 → 자연어→지표 매핑 필요
• Headless BI의 부상

2장 · Semantic Layer의 구성

2.1 핵심 엔티티

• Entity: 비즈니스 개체(주문·고객·제품)
• Dimension: 속성(나라·카테고리·날짜)
• Measure: 원시 수치(금액·수량)
• Metric: 측정 가능 지표(매출·유저수·전환율)

2.2 관계와 조인

• 엔티티 간 관계 선언
• 조인 경로 자동 생성
• 지표 조회 시 내부적으로 적절한 조인 실행

2.3 필터·파라미터

• 기간·국가·제품 등 필터 표준화
• 사용자별 권한(Row-level security)
• 비교(YoY, MoM) 계산 내장

2.4 예시 (dbt Semantic Layer / MetricFlow)

semantic_models:
  - name: orders
    model: ref('fact_orders')
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    measures:
      - name: total_amount
        agg: sum
        expr: amount_krw
    dimensions:
      - name: order_date
        type: time
        type_params: {time_granularity: day}

metrics:
  - name: gross_revenue
    type: simple
    type_params:
      measure: total_amount

→ API 호출: metric('gross_revenue', filters=..., group_by=['order_date'])

3장 · dbt Semantic Layer / MetricFlow

3.1 배경

• 2021 Transform 창업 (Nick Handel, 전 Airbnb 실험 팀)
• 2022 dbt가 Transform 인수
• MetricFlow가 dbt Semantic Layer의 쿼리 엔진

3.2 구조

• dbt 모델 위에 semantic model·metrics 정의
• dbt Cloud가 API 서비스 제공
• BI·노트북·AI가 API 호출로 지표 조회

3.3 강점

• dbt 친화, 기존 프로젝트 확장
• 오픈 표준(GraphQL·JDBC)
• 2024–2025 주요 BI 통합(Tableau·Hex·Mode 등)

3.4 한계

• dbt Cloud 의존(셀프 호스팅 옵션 성숙 중)
• 복잡 조인·측정은 SQL 직접이 아직 유리

4장 · Cube — "개발자용 Semantic Layer"

4.1 정체성

• 2019 Cube Dev
• 오픈소스 + Cube Cloud
• 데이터 앱·Headless BI용 API

4.2 특징

• YAML/JS/Python으로 데이터 모델 정의
• REST/GraphQL/SQL API
• 대시보드 직접 만드는 개발자·프로덕트에 적합

4.3 예시

cube(`Orders`, {
  sql: `SELECT * FROM fact_orders`,
  measures: {
    revenue: { sql: 'amount_krw', type: 'sum' },
    count: { type: 'count' }
  },
  dimensions: {
    orderDate: { sql: 'order_date', type: 'time' },
    country: { sql: 'country', type: 'string' }
  }
});

4.4 쓰는 곳

• 임베디드 분석(고객에게 대시보드 제공)
• 커스텀 데이터 앱
• AI 챗봇의 지표 조회 백엔드

5장 · Looker·LookML — "엔터프라이즈의 클래식"

5.1 정체성

• 2013 Looker → 2019 Google 인수
• LookML: 지표 정의 DSL
• Google Cloud 통합, Looker Studio와 결합

5.2 강점

• 업계 가장 검증된 LookML
• 거대한 기업 레퍼런스
• 2024–2025 Gemini 통합으로 자연어 쿼리

5.3 한계

• Looker 밖에서 LookML 재사용 어려움
• 비용·락인

5.4 2025 전략

• dbt Semantic Layer와 LookML 병행
• BigQuery 중심 기업은 Looker + Gemini가 기본값

6장 · 다른 주요 도구

6.1 AtScale

• 엔터프라이즈 Semantic Layer 전문
• 대규모 MDX/XMLA(Excel·Power BI) 호환
• 금융·보험 대기업 강점

6.2 Lightdash

• 오픈소스 Headless BI + dbt Semantic
• Looker 대안으로 주목
• 2024–2025 급성장

6.3 Transform (dbt)

• 인수 후 dbt Semantic Layer로 흡수

6.4 Metabase·Superset

• BI 툴 자체에 일부 Semantic Layer 기능 내장
• dbt Semantic Layer 연동 확대

6.5 Thought Spot

• 자연어 검색 BI
• 2024–2025 LLM·AI 통합 선두

7장 · Metrics Store 패턴

7.1 개념

• 회사 지표의 단일 저장소
• 정의·버전·소유자·연관 대시보드
• "지표 카탈로그"

7.2 구성

• Metric catalog: 이름·설명·공식
• Governance: 승인·변경·deprecation
• API: BI·노트북·AI가 조회
• Lineage: 지표가 어느 데이터에서 왔는가

7.3 예

• Airbnb Minerva (내부 시스템, 공개 논문)
• Uber uMetric
• LinkedIn Datahub metrics
• dbt Semantic Layer를 외부 표준화

7.4 효과

• 팀 간 지표 일치
• 감사·규제 대응
• AI 자연어 질의의 정확성 상승

8장 · Headless BI

8.1 정체성

• 쿼리·지표 엔진 ↔ 프론트엔드 UI 분리
• 프론트는 앱·대시보드·AI 채널이 자유롭게
• Semantic Layer가 API로 제공

8.2 장점

• 멀티 UI(웹·모바일·Slack·음성)
• 기존 BI 마이그레이션 쉬움
• AI 통합 용이

8.3 도구

• dbt Semantic Layer + Hex/Mode/Tableau
• Cube + 커스텀 웹
• Lightdash + dbt
• Metabase + dbt Semantic Layer

8.4 한계

• UX 커스텀 비용
• 유지보수 분산

9장 · Reverse ETL — "데이터를 운영으로 되돌리기"

9.1 왜 필요한가

• Warehouse에 귀중한 고객·행동 데이터
• Salesforce/HubSpot/Marketo에 없음
• 엔지니어가 API 연결 → 시간·비용·신뢰성 문제

→ Reverse ETL: Warehouse → 운영 SaaS로 데이터 동기화

9.2 주요 도구

• Hightouch: 2020, 업계 선도
• Census: 2018, 또 다른 선도
• Grouparoo(지금 Airbyte 일부)
• RudderStack(CDP + Reverse ETL)
• Workato(일반 iPaaS + 데이터)

9.3 패턴

1. dbt로 고객 세그먼트 모델 구축
2. Reverse ETL이 Warehouse에서 읽어 Salesforce/HubSpot/Intercom으로 푸시
3. 세일즈·마케팅이 즉시 세그먼트 활용

9.4 사례

• Intercom에 고객 LTV 주입 → 대화 우선순위
• Salesforce에 Health score 주입 → Churn 대응
• Marketo에 사용량 기반 세그먼트 → 캠페인

9.5 데이터 활성화(Data Activation)

• 분석에 머물지 않고 운영 액션을 트리거
• CDP(Customer Data Platform)와 부분 경쟁·부분 보완
• 2025년 모던 데이터 스택의 완성 조각

10장 · AI·LLM과 Semantic Layer

10.1 왜 AI가 Semantic Layer를 필요로 하는가

• LLM이 자연어 질문을 SQL로 바꾸려 할 때 지표 정의가 필요
• "우리 매출은?"의 답은 회사마다 다름
• LLM이 직접 raw 테이블에 접근하면 환각·오류 위험

10.2 "Text-to-SQL" vs "Text-to-Metric"

• Text-to-SQL: 회사 스키마 기반 SQL 생성 → 지표 불일치 위험
• Text-to-Metric: Semantic Layer API 호출 → 정의된 지표만 반환 → 안전

10.3 사례

• dbt Semantic Layer + GPT/Claude/Gemini로 자연어 BI
• Cube + 커스텀 챗봇
• ThoughtSpot AI·Looker Gemini 네이티브

10.4 품질 관리

• 지표 정의 표준화 필수
• 권한·감사 Semantic Layer에서 중앙 관리
• AI가 직접 SQL 못 짜게 막는 게 안전

10.5 2025년 방향

• Headless BI + AI = "모든 팀이 자연어로 데이터 대화"
• Semantic Layer가 AI의 안전한 데이터 접근 계층

11장 · Data Activation 실전 시나리오 3

11.1 커머스 — 개인화 추천

• Warehouse: 고객 행동·구매 이력 → ML 모델로 추천 스코어
• Reverse ETL: 스코어 → Braze/Iterable/Salesforce Marketing Cloud
• 결과: 개인화 푸시/이메일 자동화

11.2 B2B SaaS — Product-led Sales

• Warehouse: 제품 사용량·기능 adoption 지표
• Reverse ETL: 지표 → Salesforce
• AE는 "내 고객 중 업그레이드 가능성 높은 사람" 즉시 확인

11.3 핀테크 — Risk scoring

• Warehouse: 거래 패턴·위험 스코어
• Reverse ETL: 스코어 → 고객 지원 툴(Zendesk/Intercom)
• CS 담당이 VIP·위험 고객 응대 시 맥락 확보

12장 · 한국 기업 성숙도

12.1 현황

• 대기업·IT: Looker·Tableau·Superset 혼재, Semantic Layer 도입 초기
• 스타트업: dbt + Metabase/Superset 조합 흔함
• 토스·쿠팡·당근·카카오: 내부 Metrics Store 구축 사례
• Reverse ETL: Hightouch·Census 2024 급격 확대

12.2 도입 패턴

1. dbt + 표준 지표 문서화
2. Metabase/Superset에서 지표 노출
3. dbt Semantic Layer / Cube 실험
4. 특정 팀부터 Reverse ETL로 운영 연동
5. 전사 Metrics Store + AI 연결

12.3 고려사항

• 한국어 비즈니스 용어 정의
• 세금·환율·회계 정책의 커스텀
• 보안·권한 체계(직급·부서 기반)
• 감사·규제 요구 반영

13장 · 안티패턴 10선

13.1 Semantic Layer 없이 AI 직접 연결

지표 환각·일관성 붕괴.

13.2 LookML만에 의존

다른 BI·AI 채널과 단절.

13.3 지표 소유자 불명

변경 책임 공백.

13.4 Deprecation 없이 변경

소비자 대시보드 깨짐.

13.5 Reverse ETL 경로 난립

Warehouse에서 수십 개 동기화 파이프라인, 관리 불능.

13.6 Reverse ETL로 실시간 기대

대부분 분–시간 단위, "실시간" 아님.

13.7 Metric 버전 없이 운영

과거 리포트 재현 불가.

13.8 지표를 Superset/Metabase에만 정의

Semantic Layer 독립 없음 → 다른 툴과 분절.

13.9 자연어 BI 무결성 검증 부족

AI 답변을 그대로 신뢰 → 잘못된 의사결정.

13.10 팀마다 자체 SQL로 지표 계산

원점 회귀.

14장 · 체크리스트 — Semantic Layer·Reverse ETL 12가지

• 핵심 지표 카탈로그 문서화(소유자·정의·SLA)
• Semantic Layer 도입 후보(dbt/Cube/Looker) 평가
• BI·AI 채널 통합 계획
• 지표 버전·deprecation 프로세스
• 권한·Row-level security
• 계보(Lineage)와 감사
• Reverse ETL 도구 선정과 파이프라인 카탈로그
• 운영 시스템(Salesforce·HubSpot 등) 매핑
• 데이터 활성화 ROI 측정
• AI/LLM 자연어 접근 통제
• 실패·경보 대응 체계
• 사용자 교육·온보딩

15장 · 다음 글 예고 — Season 5 Ep 6: "Feature Store와 Vector·Graph·시계열 DB의 융합"

Semantic Layer가 BI의 언어층이라면, Feature Store는 ML의 언어층. 그리고 2025년 데이터 DB는 벡터·그래프·시계열이 융합되는 중.

• Feature Store의 재정의 (Feast/Tecton)
• Online-Offline skew 관리
• 실시간 Feature Pipeline
• Vector DB 지형(Pinecone/Weaviate/Milvus/Chroma/LanceDB)
• 멀티 모달 임베딩 저장
• Graph DB(Neo4j/NebulaGraph/Dgraph)와 지식 그래프
• 시계열 DB(InfluxDB/TimescaleDB/VictoriaMetrics)
• 2025년 "Unified DB"의 등장
• AI·ML 워크로드가 DB 지형에 준 충격
• 한국 기업의 선택

"모델보다 데이터, 데이터보다 피처"가 2025년 ML의 지혜.

다음 글에서 만나자.

요약: Semantic Layer는 "지표 정의 한 번, 모든 채널에서 재사용"이라는 오래된 약속의 2025년 버전. dbt Semantic Layer·Cube·Looker·Lightdash·AtScale이 각기 포지션을 잡고, Reverse ETL(Hightouch·Census)이 Warehouse 데이터를 운영 툴로 되돌려 Data Activation을 완성한다. AI·LLM 시대에는 Semantic Layer가 안전한 데이터 접근 계층으로 격상되며, Text-to-SQL 대신 Text-to-Metric이 권장된다. 한국 기업은 dbt + Metabase/Superset + Hightouch/Census 조합으로 빠르게 따라잡는 중이고, 토스·쿠팡·카카오처럼 내부 Metrics Store를 구축한 사례가 확산. "데이터의 의미를 말하는 층"은 더 이상 사치가 아니라 AI 시대의 인프라다.