Data Eng Wiki

Semantic and Ontology Stack

17 min read

Semantic and Ontology Stack

“스키마 호환성이 시맨틱 호환성을 보장하지 않는다. 두 도메인이 customerId가 string이라는 데 완벽히 동의하면서 customer가 무엇인지에 대해서는 완전히 불일치할 수 있다.”

개요

“시맨틱 레이어”라는 단어 하나에 서로 다른 다섯 가지가 뭉쳐 있다 — 지표 정의, 엔티티 모델, 온톨로지, 지식 그래프, 그리고 에이전트가 할 수 있는 행동의 목록. 각각 다른 질문에 답하고, 다른 소비자를 가지며, 다른 실패 모드를 갖는다.

이 토픽은 그 다섯을 구분하고, 왜 2026년에 이것이 갑자기 C-suite 대화가 되었는지, 그리고 어디까지 만들고 어디서 멈춰야 하는지를 정리한다.

핵심 명제 하나:

AI는 스토리지·처리·통합의 가치를 높이지 않는다. 의미·계약·거버넌스의 가치를 극적으로 높인다.

1. 다섯 가지 아티팩트 — 무엇이 무엇인가

아티팩트답하는 질문실행되는가대표 구현주 소비자
semantic model (지표 레이어)숫자가 어떻게 계산되는가✅ SQL로 컴파일dbt MetricFlow, Cube, Snowflake Semantic ViewBI, text-to-SQL
domain model무엇이 존재하는가 (엔티티·관계·의미 규칙)❌ 참조될 뿐 실행되지 않는다개념 모델, canonical 정의계획 수립, 요청 해석
capability model에이전트가 무엇을 해도 되는가✅ 라이브 시스템에 작용MCP Tools, 사내 capability 카탈로그행동하는 에이전트
ontology의미가 어떻게 형식화되는가 (TBox/ABox)보통 ❌Apache Ossie, OWL/RDF, 사내 온톨로지추론, 시스템 간 정렬
knowledge graph어떻게 순회하는가✅ 쿼리 가능JanusGraph, Neo4j, GraphRAG, Graphiti깊이를 모르는 관계 탐색

왜 이 구분이 실무적으로 중요한가

① domain model을 semantic model 안에 접어 넣으면 안 되는 이유

dbt semantic model도 엔티티를 선언하는데 왜 굳이 분리하는가:

지표 레이어 안에 선언된 엔티티는 지표에 스코프되어 있고, capability model은 semantic model과 같은 어휘로 쓰이지 않으면 둘이 어긋난다. 환불은 revenue 수치가 세는 것과 같은 고객에 작용한다. 아래에 하나의 어휘를 두거나, 두 개를 갖게 되거나.

② knowledge graph는 네 번째로 만들 것이 아니라 domain model의 스토리지 선택

semantic model이 잘하는 것 — “지역별 revenue” 같은 정형 지표 쿼리. flat 테이블이 못 하는 것 — 쿼리를 쓸 때 깊이를 모르는 순회. “Product X를 사고 가격 변경 후 이탈한 고객” 처럼 hop 수가 고정이면 그냥 조인이다. 그래프가 필요한 것은 찾을 때까지 관계 사슬을 따라가야 할 때다.

③ 셋을 묶는 것은 “다 의미에 관한 것”이라서가 아니다

capability model은 명백히 의미에 관한 것이 아니다. 셋을 묶는 것은 각각이 요청마다 모델이 새로 알아내는 대신 버전 관리에서 한 번 보증이 선언되는 자리라는 점이다. 정의가 곧 레이어이고, 인터페이스는 — 오늘날 MCP는 — 그저 문일 뿐이다.

→ AI-Ready Data, Semantic Layer, Ontology-Backed Knowledge Graphs, Knowledge Graph Infrastructure, MCP (Model Context Protocol)

2. 온톨로지의 네 단계 진화

Formal Semantics → Knowledge Graphs → Decisions → AI Agents (= Meaning → Traversal → Reasoning → Action)

각 단계가 앞 단계를 대체하지 않고 다른 요구를 얹는다. 그래서 결론이 나온다:

하나의 온톨로지가 더 이상 모든 워크로드에 맞지 않는다.

핵심 설계 딜레마는 시맨틱 충실도(semantic fidelity) vs 순회 유용성(traversal utility) 이다. 충실하게 모델링할수록 순회가 비싸지고, 순회에 최적화할수록 의미가 뭉개진다. 해법은 하나를 고르는 게 아니라 온톨로지 / 규칙 / 인과 모델 / 의사결정 모델을 분리하는 것.

에이전트가 실제로 필요로 하는 것 — operational semantic contract

정적 정의만으로는 부족하고, 행동하는 에이전트에게는 여덟 가지가 필요하다:

개념 + 관계 + authoritative 데이터 + capability
     + precondition + policy + evidence + effect

앞 셋은 전통적 온톨로지가 주지만, 뒤 다섯(무엇을 할 수 있고, 언제 허용되고, 왜 그렇게 판단했고, 무슨 일이 일어나는가)은 온톨로지 문헌이 다루지 않던 영역이다.

→ Ontology-Backed Knowledge Graphs, Semantic Control Plane, Knowledge Representation

3. “레이어”에서 “control plane”으로

시맨틱을 파이프라인 위에 얹는 얇은 층으로 보는 관점의 한계:

레이어 관점control plane 관점
BI 도구 앞에 놓인다모든 소비 경로가 통과한다 (BI, 에이전트, API, 역ETL)
정의를 제공한다정의를 강제하고 접근을 거버넌스한다
조회된다무엇을 물을 수 있고 무엇을 할 수 있는지를 제약한다
실패 = 틀린 숫자실패 = 틀린 행동

에이전트는 기저 데이터에 직접 닿지 않고 context layer를 지나며, 그 레이어가 무엇을 물을 수 있고 무엇을 할 수 있는지를 둘 다 제약하고 거버넌스한다.

→ Semantic Control Plane, Knowledge Spine

4. 왜 지금 C-suite 대화가 되었나

두 가지 이유가 겹쳤다.

① 데이터 팀 없는 회사들이 ETL·모델링을 건너뛴다

압도적 다수의 회사가 에이전트를 벤더에 직접 꽂는 것으로 AI 여정을 시작한다. 개인은 빠르게 일하지만 조직 전체에서 아무것도 일관되지 않은 재현성 위기가 온다. 거의 모든 Applied AI 솔루션 피치의 첫 단계가 forward-deployed 팀이 시맨틱 레이어를 만드는 것인 이유다.

② intelligence exhaust가 어디에 쌓이는가

모든 “이거 이상한데”, 모든 지표 명료화가 학습 신호다.

컨텍스트는 당신의 네 벽 안에서 복리로 쌓이거나, 남의 벽 안에서 쌓인다.

시맨틱 레이어 없이 agentic 벤더를 raw 데이터에 직접 연결하는 것에 대한 최고의 반론: 답이 틀릴 수 있다는 것만이 아니라, 모든 수정이 당신의 스택을 고치는 대신 벤더에게 당신의 비즈니스를 가르치는 데 간다는 것.

측정 가능한 근거: AtScale text-to-SQL 벤치마크에서 동일 모델로 raw 스키마 20% 미만 → 시맨틱 레이어 92.5% 초과. “컨텍스트가 더 큰 모델보다 정확도를 더 멀리 움직인다.”

→ Consensus Engineering, AI Self-Serve Analytics

5. ⚠️ 얼마나 만들 것인가 — 이 스택의 중심 트레이드오프

이 토픽에서 가장 실무적인 부분이다. 양쪽 끝이 모두 실패한다.

모델링을 너무 적게 하면 AI가 틀린 지표·grain·조인으로 설득력 있는 답을 낸다. 사전에 너무 많이 하면 모든 새 질문이 데이터 엔지니어링 프로젝트가 된다.

축과소 모델링과대 모델링
증상그럴듯하고 틀린 답질문마다 티켓
비용잘못된 의사결정 (조용함)속도 (눈에 보임)
발견 시점사후, 종종 안 발견됨즉시

작동하는 운영 원칙 — “Model the core. Curate the context. Evaluate continuously.”

  1. 핵심만 모델링 — 일관성이 유지되어야만 하는 지표·엔티티·관계만 명시적으로
  2. 나머지는 큐레이션된 context layer로 — 리니지, 정의, 비즈니스 지식, 분석 가이드
  3. 컨텍스트를 엄격히 관리 — 무엇이 속하는지, 어떤 소스가 authoritative한지, 누가 소유하는지, 어떻게 최신으로 유지되는지
  4. 오프라인 eval (전담 인력)
  5. 온라인 eval — 실제 출력을 리뷰해 실패 모드를 컨텍스트·모델·평가 케이스로 환류

시작점 선택: 비즈니스 전체를 모델링하려는 유혹에 저항하고 충돌하는 지표 정의부터. revenue가 고전이다(gross vs net, 반품 포함 여부). 그 충돌이 최대의 에이전트 리스크이자 가장 빠른 승리다.

적대적으로 테스트하라: 모든 환각이 빠진 정의를 가리킨다. 프롬프트가 아니라 정의를 고쳐라.

6. ⚠️ 병목은 사라지지 않고 이동한다

시맨틱 레이어 도입의 가장 흔한 오해:

엔지니어가 정적 대시보드 만드는 시간은 줄지만 시맨틱 정의를 지속적으로 유지·확장하는 새 부담을 진다. 대시보드 부채가 시맨틱 레이어 부채가 된다. 엔지니어링 병목은 제거되는 게 아니라 상류로 옮겨진다.

그리고 아무도 소유하지 않으면 전부 표류한다:

  • 오너 없는 “revenue” 정의 → 방금 통합한 세 개의 충돌 버전으로 재분기
  • 오너 없는 contract → 소스와 어긋나 표류
  • 오너 없는 접근 스코프 → 조용히 넓어져 다시 상시 서비스 계정

거버넌스 형태 비교:

방식예시강점약점
Git-flow + 2인 승인Booking.com (dbt + GitLab, semantic view·verified query 변경마다 MR)감사 가능, 인적 오류 방어선처리량이 리뷰어에 묶임
hard validation gate발행 시점 canonical 정의 강제표류 원천 차단도메인 자율성 침해
사후 조정 레이어로컬 정의를 canonical에 매핑도메인이 빠르게 움직임매핑 자체가 부채가 됨
crowdsource 검증Crowdsourced Graph Verification규모 확장품질 관리 장치 필요

→ Data Governance, Data Contracts, Analytics Engineering

7. 검증된 신뢰 장치

시맨틱 레이어 위에 에이전트를 얹을 때 반복해서 등장하는 패턴들.

  • verified queries — 전문가가 승인한 SQL 템플릿으로 답하면 출력에 배지를 단다. 결과가 결정적이고 신뢰할 만함을 증명해 AI 생성 코드에 흔히 따르는 회의론을 최소화
  • playground — public으로 만들기 전에 semantic view를 테스트
  • suggestions — AI가 개선을 제안하되 오너가 수락/거절
  • quality scoreboard — view 완전성을 점수화하고 사용자 피드백을 실시간 추적해 엣지 케이스를 조기 플래그하고 신뢰 수준을 이해관계자에게 전달
  • ⚠️ silent hallucination이 남은 위험: verified query 범위 밖 질문에서 문법적으로 맞지만 의미적으로 틀린 SQL이 나온다. 임원이 미묘한 엣지 케이스를 조용히 오해한, 자신 있고 잘 포맷된 답을 받는다

→ Silent Failures and Data Integrity, LLM Evaluation

8. 타임라인

시점사건
~2020시맨틱 레이어 = BI 도구 기능 (LookML 등)
2023~2024headless BI / metrics layer 논쟁, dbt MetricFlow
2026 상반기경제적 필수화 — text-to-SQL 정확도의 전제 조건으로 재발견
2026-08Apache Ossie(Open Semantic Interchange 개명) — 벤더 간 시맨틱 교환 표준화 시도
2026-08”The Semantic Layer Is Not a Layer Anymore” — control plane 프레이밍
2026-08온톨로지 4단계 진화론, operational semantic contract
2026-09”Model the core, curate the context, evaluate continuously” — 과소/과대 모델링 딜레마의 운영 원칙

공통 교훈

  1. 다섯 아티팩트를 구분하라. 하나의 “시맨틱 레이어”로 뭉치면 domain model이 지표에 스코프되고 capability model이 어긋난다
  2. 하나의 어휘를 아래에 두거나, 두 개를 갖게 되거나 — 환불은 revenue가 세는 것과 같은 고객에 작용한다
  3. 정의가 레이어이고 인터페이스(MCP)는 문일 뿐 — 프로토콜이 아니라 추상화가 요점
  4. 핵심만 모델링하고 나머지는 컨텍스트로 — 과소/과대 양쪽 끝이 실패한다
  5. 환각은 프롬프트 문제가 아니라 빠진 정의 — 프롬프트가 아니라 정의를 고쳐라
  6. 병목은 상류로 이동할 뿐 사라지지 않는다 — 오너십이 없으면 통합한 정의가 다시 갈라진다
  7. 컨텍스트는 당신 안에서 복리가 되거나 벤더 안에서 복리가 된다
  8. 스키마 ≠ 의미 — 계약은 의미·구조·행동·기대를 함께 담은 것

관련 위키

관련 토픽

관련 이슈: DEW #266, #275, #279, #280, #281, #282, #284, #285, #286

그래프 뷰

백링크