Data Eng Wiki

The Semantic Layer Is Not a Layer Anymore

20 min read

The Semantic Layer Is Not a Layer Anymore

Source: Substack | Published: 2026

한 줄 요약

시맨틱 레이어는 웨어하우스와 대시보드 사이의 얇은 추상이 아니라 비즈니스 의미·실행·거버넌스·지식·성능을 함께 붙드는 semantic control plane이 되어가고 있고, 소비자가 사람에서 에이전트로 바뀌었기 때문에 지금 이 일이 벌어지고 있다.

핵심 주장/내용

  • 가장 어려운 데이터 문제는 쿼리가 아니다 — 과학·엔지니어링·기업 데이터 전반에서 어려운 부분은 답을 얻는 게 아니라 질문에 합의하는 것이다. active customer란 무엇인가? MRR은 어느 날짜로 결정되나? 환불은 원래 거래 월에 속하나 환불이 일어난 월에 속하나? 어떤 환율이 적용되나? 한 고객이 여러 제품을 쓸 때 churn은 정확히 무엇인가?
    • SQL은 보통 풀 수 있다. 조직적 모호성은 아니다. 이 결정들은 기업 인프라가 되도록 설계된 적 없는 곳에 숨어 있다 — 대시보드 필터, 재무 스프레드시트, 분석가의 쿼리, 슬라이드 덱, Slack 스레드, 3년 전 정의가 왜 바뀌었는지 기억하는 한 사람의 머릿속
  • 왜 지금인가 — 소비자가 사람에서 에이전트로 바뀌었다: 10년간 지표의 소비자는 대시보드를 보는 사람이었고, 사람은 물어봐서 모호한 숫자를 고칠 수 있다. 에이전트는 그럴 수 없다. 게다가 에이전트는 조합한다 — 쿼리가 결정을 먹이고 그 결정이 다음 쿼리를 먹인다. stale하거나 정책 밖이거나 지난 분기 정의로 만들어진 숫자는 대시보드의 틀린 셀 하나로 드러나지 않고, 추론의 사슬을 타고 전파되어 자신만만한 권고로 도착한다
    • “충분히 유능한 모델이 dbt 프로젝트·Slack 스레드·재무 스프레드시트를 읽어 정의를 스스로 알아낼 수 있다”는 반박에 대해: 종종 가능하다. 하지만 추론된 정의는 아무도 승인하지 않았고 아무도 감사할 수 없는 정의다. 대부분 맞는 것은 거버넌스 모델이 아니다. 기계 속도에서 그것은 인용을 달고 대규모로 틀리는 방법이다
  • semantic control plane이 붙들어야 하는 5가지: 비즈니스 의미(정의, 엔티티, 차원, 지표, 용어, 소유권), 실행(조인, 집계 로직, 쿼리 컴파일, federation, 엔진 선택), 거버넌스(접근, 인증, lineage, 정책, 책임, 변경 통제), 지식과 맥락(모델이 왜 이렇게 생겼는지 설명하는 결정·예시·관계), 성능(캐싱, 사전 집계, materialization, 신선도, 비용 인지 라우팅)
    • 대부분의 제품이 일부를 잘 구현하고 나머지는 시늉만 한다. 그것이 함정이다 — 하나의 control plane이 아니라 각자 단일 도구 안에서만 권위 있는 여러 개의 부분적 control plane
    • 다섯 번째는 나머지와 완전히 동등하지 않다. 성능은 의미·거버넌스·실행이 만나는 지점이라 자기 상자를 갖지 못하고 캐시 키에서, 라우터에서, materialization에서 계속 다시 나타난다
  • materialization은 어디에 있어야 하나 — 캐시 키가 무엇인가: 두 사용자가 지난 분기 세그먼트별 net revenue를 요청한다. 하나는 모든 지역을 보고 다른 하나는 스위스만 볼 수 있다. 한 대시보드는 재무 승인 정의 4.2.0을 쓰고 다른 하나는 여전히 4.1.0을 가리킨다. Iceberg 테이블이 새 스냅샷으로 전진했을 수 있다. 일별 집계가 대시보드에는 충분히 신선하지만 규제 리포트에는 아닐 수 있다. 캐시 키는 SQL 문자열도, 지표 이름도 될 수 없다
    • “Arrow인가 Iceberg인가”는 사실 세 질문이 한 벌의 옷을 입은 것 — 어떤 포맷인가, 누가 아티팩트를 소유하나, 유효성을 어떻게 결정하나
    • 포맷은 수명을 따른다 — Arrow는 비압축·랜덤 접근·CPU 네이티브 columnar로 이동 중인 데이터용이고, Parquet은 압축·인코딩되어 정지 중인 데이터용이다. 아키텍처 선호가 아니라 배치 규칙이다 — 초분 단위는 Arrow, 시간월 단위는 Parquet/Iceberg
    • Cube가 가장 명확한 worked example인데 둘 다 하기 때문이다. 스트리밍 row가 즉시 질의 가능한 인메모리 Arrow 청크로 랜딩했다가 약 1분마다 Parquet으로 compact된다. 하나의 엔진, 두 티어, 그리고 티어가 취향이 아니라 나이로 선택된다
    • 훔칠 만한 부분은 매칭 로직: 사전 집계가 쿼리 텍스트 비교가 아니라 measure·차원·granularity·additivity를 추론해서 선택된다. 뷰의 멤버가 기저 cube 멤버로 해소되어 cube에 정의된 rollup이 뷰에 대해 쓰인 쿼리를 서빙한다. materialization이 요청에 유효한 이유는 그것이 무엇을 의미하는지 때문이다
    • 그리고 불편한 부분: Cube 문서 전체를 검색해도 “iceberg”도 “delta lake”도 나오지 않는다. Cube Store가 Parquet을 쓰지만 자체 내부 metastore가 관리하고 manifest도 스냅샷도 카탈로그도 없다 — 다른 엔진이 읽을 수 있는 테이블이 아니다. 이것은 Cube 비판이 아니라 이 글의 가장 강한 증거다. 생태계에서 가장 이식성을 중시하는 시맨틱 런타임조차 사적 materialization 스토어를 발명해야 했다. 시맨틱 집계가 무엇인지에 대한 열린 표준이 없기 때문이다
    • 열린 표준은 새로 발명할 필요가 없다 — Iceberg의 View 스펙이 게시되어 있고 Materialized View 스펙이 함께 제안되어 있다(2024년 8월 개시, 여전히 논의 중, 아직 게시된 스펙의 일부가 아님). 사전 계산 결과를 담는 storage-table과 스냅샷 summary에 실린 refresh-state(리프레시가 어느 뷰 버전에 대해 돌았는지, 언제 시작했는지, 의존한 모든 소스 테이블·뷰의 상태)를 정의한다. 이 글이 요구해온 manifest의 대부분이 스토리지 레이어에서 도착하는 셈이다. 다만 시맨틱 절반 — 어느 거버넌스된 지표를, 어느 grain에서, 어느 정책 범위 하에, 언제까지 재사용 가능한지 — 은 담지 않는다. 따라서 요구는 “누군가 manifest를 설계해야 한다”보다 훨씬 작고 구체적이다 — 2년간 기다린 스펙을 확장하고 land시켜라
    • materialization이 보증을 선언한다. 요청이 요구를 선언한다. 라우터가 둘을 매칭한다
  • 그래프가 계약이지 반드시 데이터베이스는 아니다: net_revenue는 gross sales, 환불, 통화, 고객, 회계 정책, 소스 테이블, 소유자, 품질 테스트, 대시보드, 물리적 materialization과 연결된다. 평평한 지표 목록은 이것을 잘 표현할 수 없고 자연스러운 모델은 그래프다. 그래프를 요구하는 것이 하나의 그래프 DB를 요구하는 것은 아니다 — 그래프는 논리적 계약(안정적 identity, 타입된 관계, provenance, 버저닝, 기계 판독 순회)이어야 하고 그 표현은 실행 가능한 시맨틱 모델·카탈로그·정책 시스템·링크된 문서·열린 테이블에 federated된 채 남을 수 있다
    • 열린 semantic control plane에는 의미를 위한 MDM이 필요하다: 전통 MDM이 고객·제품·공급자에게 시스템 전반의 거버넌스된 identity를 주듯, semantic MDM은 net_revenue, active_customer, churn 같은 개념에 대해 같은 일을 한다 — 정의·계산·소유자·정책·맥락·materialization·다운스트림 사용을 잇는 하나의 안정적 identity. 중앙 “golden model” 하나가 필요한 게 아니다. 표현은 분산된 채 남고 권위를 갖는 것은 identity와 그 관계와 생명주기다. golden record가 golden identity가 된다
  • 열린 데이터도, 열린 SQL도 의미를 열지 않았다: Iceberg가 데이터를 열었지 의미를 열지 않았다. REST Catalog 프로토콜은 카탈로그 경계 자체를 표준화했고, Lakekeeper 같은 Apache-2.0 구현이 접근 통제·credential vending·감사를 더한다 — 열린 카탈로그가 테이블 목록만이 아니라 거버넌스도 실을 수 있다. control plane에서 이것은 정확히 물리적 상태로의 인터페이스다: 라우터가 materialization을 위치 확인하고, 그것에 대한 스코프된 credential을 얻고, 읽은 스냅샷을 pin하고, 그 전부를 receipt에 기록할 수 있다
    • 어떤 카탈로그도 semantic.net_revenue_daily가 net_revenue 버전 4.2.0을, 어느 grain에서, 누구를 위해, 언제까지 구현하는지는 말해줄 수 없다
    • 세 rung이 이미 열려 있다 — 스토리지(Iceberg), 표현식(GoogleSQL), 플랜(Substrait). 그리고 그중 어느 것도 active customer가 무엇인지, 매출이 시간에 걸쳐 additive한지, 재무가 어느 조인 경로를 승인했는지, 환불이 거래 월에 속하는지 모른다
  • missing middle — 어떻게 시작하나: 열린 semantic control plane은 모든 소비자와 모든 DB 사이에 끼워넣는 또 하나의 범용 플랫폼이 아니라 특화 시스템들이 질문에서 답까지의 하나의 거버넌스된 경로에 참여하게 하는 상호운용 가능한 계약의 집합이다. control plane인 이유는 요청이 어느 거버넌스 객체를 가리키는지, 어느 정책이 적용되는지, 어느 materialization이 유효한지, 어느 런타임이 실행해야 하는지를 결정하기 때문이고, 열린 이유는 identity·요청·관계·manifest·receipt가 제품 경계를 넘을 수 있기 때문이다 — 뒤의 resolver·optimizer·그래프 인덱스·정책 엔진이 관리형이고 프로프라이어터리여도
    • 요청의 여정: ① 소비자가 엔진이 아니라 의미를 요청한다(Athena SQL이나 Spark SQL이 아니라 거버넌스된 net_revenue identity·차원·시간 범위·서비스 요구사항) ② 레지스트리가 거버넌스된 identity를 해소 ③ control plane이 개념을 조립(실행 가능한 지표·조인 규칙 + 맥락·비즈니스 결정 링크 + 적용 가능한 소유권·승인·접근 정책) ④ 라우터가 요청이 어떻게 답해질 수 있는지 결정(차원·조인 검증, 호출자 정책 범위 평가, 신선도·비용 확인, 가용 materialization이 선언한 보증과 요구를 매칭 — 그 다음에야 런타임을 선택) ⑤ data plane이 이식 가능한 증거 제공(Iceberg 테이블·스냅샷이 소스 상태를 노출, semantic aggregate manifest가 어느 지표 버전·grain·정책 범위를 구현하는지 진술) ⑥ 결과가 receipt와 함께 반환 — 해소된 정의, 정책 결정, 소스 스냅샷, materialization, 엔진, conformance profile을 실은 Arrow 페이로드. Athena와 Spark가 불일치하면 조직이 두 SQL 문자열에서 비즈니스 정의를 재발견하는 대신 증거를 비교한다
    • 4단계가 에이전틱 워크로드에서 특히 중요해진다: 사람은 한 번에 하나를 묻지만 에이전트는 수십 개의 서브에이전트로 fan out해 각자 작고 구체적인 것을 묻는다. 사전 집계된 테이블에 대한 쿼리가 왜 분산 클러스터를 필요로 하나 — DuckDB 같은 in-process 엔진이 밀리초에 답하는데? 그 볼륨에서 클러스터 시작은 오버헤드가 아니라 레이턴시 예산 전체다. 엔진 선택이 배포 결정이 아니라 요청별 결정이 되고, 그것은 materialization 매칭과 같은 결정이다 — 올바른 버전·grain·신선도·정책 범위의 유효한 집계가 있으면 단일 노드 엔진이 서빙하고, 없으면 소스 테이블로 떨어져 더 큰 것이 필요하다. 어느 materialization과 어느 엔진은 두 질문이 아니라 하나다
    • 그래서 실행 계약이 선택 사항으로 남을 수 없다: 소수점·NULL·시간대에 대해 의견이 다른 엔진들 사이에서 자유롭게 고르는 라우터는 부하에 따라 같은 질문에 다른 답을 반환한다. conformance 없는 비용 인지 라우팅은 최적화가 아니라 예산이 붙은 비결정성이다
    • 필요한 3가지 산출물: ① golden conformance corpus와 참조 어댑터 — 의미와 실행 사이의 seam을 테스트. conformance는 net_revenue가 무엇을 의미해야 하는지 결정할 수 없다(그것은 비즈니스 결정) — 두 런타임이 같은 선언된 의미를 충실히 실행하는지 테스트할 수 있을 뿐이다. 시맨틱 언어가 orders에 대한 합은 표현할 수 있지만 회계 달력이 4-4-5이고 환불이 원래 판매 월에 귀속되고 distinct 고객 수가 근사가 아니라 정확해야 함을 진술할 수 없다면, Athena와 Spark가 모든 테스트를 통과하면서 다른 숫자를 낼 수 있다. 그건 엔진 문제만이 아니라 선언 포맷의 구멍이다. 시간대·회계 달력·NULL·소수점·distinct count·다대다 조인·semi-additive measure·늦게 도착하는 데이터·정책 의존 결과처럼 일상적으로 이식성을 깨뜨리는 케이스로 시작하라 ② Ossie 정렬 요청·결과·receipt 계약 ③ identity와 레지스트리 프로토콜
    • 아무도 시작 허락을 받을 필요가 없다. 월요일에 한 팀이 어려운 net_revenue 케이스 10개를 쓰고, 현재 모델이 허용하는 만큼 표현하고, 두 엔진에 돌리고, 결과와 미해결 모호성을 함께 게시할 수 있다. 그것이 범용 플랫폼 다이어그램 하나보다 열린 시맨틱 아키텍처에 더 기여할 것이다
  • 아키텍처의 약속: 하나의 개념, 하나의 거버넌스된 identity, 여러 표현 — 그리고 그 아래 교체 가능한 런타임. 사람은 계약이 없으면 누군가에게 물어서 우회할 수 있었다. 에이전트는 그럴 수 없고, 묻지도 않을 것이다

관련 위키

Source: 원문 보기

그래프 뷰

백링크