시맨틱 레이어(Semantic Layer)

1. 시맨틱 레이어 (Semantic Layer)란 무엇인가

시맨틱 레이어, Semantic Layer는 데이터 웨어하우스·레이크하우스 위에 위치하여 물리적 테이블, 컬럼, SQL 조인, 집계 로직을 비즈니스 의미 단위로 추상화하는 계층이다.

“매출, 고객, 주문, 활성 사용자, 전환율 같은 비즈니스 개념을 누가 조회하든 동일한 정의와 동일한 계산 방식으로 사용할 수 있게 하려면
데이터 플랫폼 어디에 그 의미를 정의해야 하는가?”

 

탄생 배경

예를 들어 주문 데이터가 있다고 하자. 

문제는 조직이 커질수록 동일한 개념이 여러 방식으로 계산된다는 점이다.

예를 들어 “매출”이라는 지표 하나만 보더라도 팀마다 정의가 달라질 수 있다.

영업팀 매출:
  SUM(order_amount)

재무팀 매출:
  SUM(order_amount - discount_amount)

마케팅팀 매출:
  SUM(order_amount - discount_amount)
  WHERE order_status = 'completed'

프로덕트팀 매출:
  SUM(order_amount - discount_amount)
  WHERE order_status IN ('completed', 'shipped')

 

각 팀의 대시보드에서는 모두 “Revenue”라고 표시되지만 실제 계산식은 다르다.

이 상태에서는 데이터가 틀린 것이 아니라 의미 정의가 분산되어 있는 것이다.

 

즉, 문제의 본질은 다음과 같다.

테이블은 중앙화되어 있지만, 비즈니스 의미는 중앙화되어 있지 않다.

 

데이터 웨어하우스는 데이터를 저장하고 처리하는 계층이다.

하지만

“이 컬럼이 실제 비즈니스에서 무엇을 의미하는가”,

“이 지표는 어떤 필터와 집계 규칙을 따라야 하는가”,

“이 지표는 어떤 차원으로만 쪼갤 수 있는가”까지 자동으로 보장하지는 않는다.

이 간극을 메우기 위해 등장한 것이 시맨틱 레이어다.

 

시맨틱 레이어의 정의

사용자 관점:
  "월별 활성 고객 수를 보고 싶다."

시멘틱 레이어 관점:
  metric: active_customers
  dimension: month
  entity: customer
  time dimension: event_date
  filter: activity_type in valid_activity_set

물리 DW 관점:
  SELECT DATE_TRUNC('month', event_date), COUNT(DISTINCT customer_id)
  FROM fact_user_events
  WHERE ...
  GROUP BY 1

 

즉, 사용자는 fact 테이블명, 컬럼명, 조인 조건, 집계 방식, 필터 조건을 직접 알 필요가 없다.

대신 “활성 고객 수”, “월”, “지역”, “상품 카테고리” 같은 비즈니스 개념으로 데이터를 조회한다.

시맨틱 레이어는 다음 역할을 한다.

 

1. 비즈니스 지표 정의
   - revenue
   - active_users
   - conversion_rate
   - churn_rate

2. 차원 정의
   - date
   - region
   - product_category
   - customer_segment

3. 엔티티 정의
   - customer
   - order
   - product
   - subscription

4. 조인 관계 정의
   - customer_id 기준으로 fact_orders와 dim_customers 연결
   - product_id 기준으로 fact_orders와 dim_products 연결

5. 집계 규칙 정의
   - SUM
   - COUNT DISTINCT
   - AVG
   - Ratio
   - Window aggregation

6. 권한 및 거버넌스
   - 특정 사용자는 원천 컬럼 접근 불가
   - 특정 조직만 민감 지표 조회 가능
   - row-level security 적용

 

핵심 구성 요소

 

아키텍처 상의 위치

시맨틱 레이어는 일반적으로 정제된 데이터 모델 위에 올라간다.

시맨틱 레이어는 “의미 정의”를 담당하는 계층이지, 원천 데이터의 품질 문제를 모두 해결하는 계층이 아니다.

null 처리, 중복 제거, 타입 정규화, CDC 정합성 보정, 상태값 표준화 같은 작업은 여전히 ETL/ELT 모델링 계층에서 처리하는 것이 맞다.

 

현대 데이터 스택에서 시맨틱 계층의 이점

- 데이터 접근성 및 일관성 향상: 메트릭 정의가 중앙 집중화되면 대시보드부터 자연어 쿼리 인터페이스에 이르기까지 동일한 거버넌스 논리를 가진다.

- 거버넌스 및 규정 준수 강화: 데이터 거버넌스가 절차가 아닌 구조가 된다. 모든 쿼리는 감사 가능하며 모든 정의 변경은 추적 가능하다.

- 규모에 따른 데이터 리터러시 활성화: 기술 스키마를 비즈니스 언어로 번역하여 데이터를 민주화한다.

 

LLM 이 시맨틱 레이어가 필요한 이유

대규모 언어 모델은 언어 및 추론에 강력하지만 비즈니스 어휘에 대한 고유한 이해는 없다.

시맨틱 계층이 없으면 데이터 웨어하우스를 쿼리하는 LLM은 "ARR"이 무엇을 의미하는지, 어떤 테이블에 포함되어 있는지, 어떤 필터가 적용되는지, 

결과가 활성 계약에만 해당되는지 아니면 전체 기간에 해당하는지 추론해야 한다.

 

AI를 위한 시맨틱 계층은 이러한 격차를 해소하는 구조화된 컨텍스트를 제공한다.

비즈니스 친화적인 이름과 설명, 구어체 용어를 표준 필드에 매핑하는 동의어 및 약어, 내장된 필터 및 조인이 있는 메트릭 정의, 

어떤 정의가 신뢰할 수 있는지 나타내는 인증 신호, 제한된 데이터 노출을 방지한다.

 

 

2.실제 동작 원리

사용자의 질의가 SQL이 되기까지

예를 들어 사용자가 BI 도구에서 다음을 선택했다고 하자. 시멘틱 레이어 내부에서는 대략 다음 단계가 수행된다.

 

Metric:
  net_revenue

Dimensions:
  order_month
  customer_region

Filter:
  order_month >= 2026-01

 

Step 1: Semantic Query 생성

 

BI 도구나 API는 물리 SQL을 직접 만들지 않고, 의미 기반 질의를 생성한다.

{
  "metrics": ["net_revenue"],
  "dimensions": ["order_month", "customer_region"],
  "filters": [
    {

      "field": "order_month",
      "operator": ">=",
      "value": "2026-01-01"
    }
  ]
}

 

Step 2: Metric 정의 해석

 

시맨틱 레이어는 net_revenue 정의를 찾는다. 그리고 measure 정의를 확인한다.

```yaml
metric: net_revenue
type: simple
measure: net_order_amount
filter:
  order_status: completed

measure: net_order_amount
source: fct_orders
expression: order_amount - discount_amount
aggregation: sum

```

 

Step 3: Dimension 소스 해석

```yaml
-- order_month는 fct_orders의 ordered_at에서 만들 수 있다.
dimension: order_month
source: fct_orders
expression: DATE_TRUNC('month', ordered_at)

-- customer_region은 dim_customers에 있다.
dimension: customer_region
source: dim_customers
expression: region
entity: customer

-- 따라서 fct_orders와 dim_customers를 조인해야 한다.
```

3. 데이터 마트와의 차이

시멘틱 레이어를 이해할 때 가장 많이 혼동하는 것이 데이터마트다.

 

결론부터 말하면, 시멘틱 레이어는 데이터마트를 완전히 대체하지 않는다.

오히려 잘 설계된 데이터마트 위에서 가장 효과적으로 동작한다.

 

데이터마트는 특정 분석 목적에 맞게 물리적으로 가공된 테이블 집합이다.

이 방식은 빠르고 직관적이다.

하지만 지표가 늘어나고 차원이 많아지면 데이터마트가 폭발적으로 증가한다.

 

시멘틱 레이어는 물리 테이블을 계속 늘리는 대신, 의미 정의를 재사용한다.

사용자가 어떤 조합으로 조회하든 시맨틱 레이어가 적절한 SQL을 생성한다.

이 방식은 물리 테이블 수를 줄이고 지표 정의를 중앙화한다.

 

하지만 모든 것을 동적으로 계산하면 성능 문제가 생길 수 있다.

따라서 실무에서는 보통 다음과 같은 하이브리드 구조를 사용한다.

 

Data Mart

- 정제된 fact / dimension

- 자주 쓰는 사전 집계 테이블

- 성능 최적화된 wide table 일부

 

Semantic Layer

- metric 정의

- dimension 정의

- entity 관계

- join rule

- access policy

- query compilation

 

 

4. 시맨틱 레이어의 한계

물리 모델 

시맨틱 레이어는 데이터 모델링 문제를 숨길 수는 있어도 해결할 수는 없다.

예를 들어 fact 테이블의 grain이 불명확하거나 중복 row가 많으면 metric은 계속 틀린다.

따라서 시멘틱 레이어 도입 전에는 다음을 점검해야 한다.

• fact 테이블 grain 명확성
• primary key / uniqueness 테스트
• foreign key 관계
• null 정책
• 상태값 표준화
• time zone 처리
• late arriving data 처리
• SCD 정책

성능문제 

성능 문제가 생길 수 있다. 동적 SQL 생성은 유연하지만 비용이 높을 수 있다. 특히 다음 질의는 비싸다. 

• 대용량 fact에서 COUNT DISTINCT
• 고카디널리티 dimension group by
• 복잡한 many-to-many join
• 긴 기간의 event-level scan
• 다수 dashboard 동시 조회

시맨틱 레이어 설계는 논리 모델링과 물리 최적화를 함께 고려해야 한다.

5. 설계 포인트

• Metric Owner를 반드시 지정한다
• Grain 테스트를 자동화한다
• Metric 테스트를 만든다
• Time Zone 정책을 명확히 한다
• SCD 처리와 시멘틱 레이어의 관계를 명확히 한다

---

 

참고 : 

https://www.databricks.com/kr/blog/semantic-layer-architecture-components-design-patterns-and-ai-integration

https://joyhong.tistory.com/197

https://community.heartcount.io/ko/analytics-agent-semantic-layer/

https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl?version=1.10