Data Eng Wiki

Knowledge Spine

11 min read

Knowledge Spine

정지 상태의 온톨로지는 매우 엄밀한 의견일 뿐이다

핵심 개념

AI 에이전트를 배포하려는 모든 기업이 같은 벽을 만난다. 모델은 훌륭하지만 당신의 비즈니스가 “customer”, “exposure”, “active contract”를 무슨 뜻으로 쓰는지 모른다. 환각하는 이유는 고장나서가 아니라 아키텍처의 어느 것도 무엇이 참인지 말해주지 않기 때문이다.

말해줄 수 있는 온톨로지는 이미 있다. 문제는 그것들이 사는 곳이다 — PowerPoint 덱, PDF 용어집, 아무도 질의하지 않는 모델링 도구. 의미를 기술할 뿐 전달하지는 못한다.

Knowledge Spine = 기업 온톨로지의 운영화. 시맨틱 플랫폼 위에 인스턴스화되고, 쿼리 시점에 기업의 실제 데이터를 가진 도메인 지식 그래프·레이크하우스·비정형 소스에 능동적으로 연결되어, 모든 소비자(사람이든 기계든)가 하나의 거버넌스된 backbone을 통해 의미를 해소하게 하는 것.

정의의 세 단어가 무게를 진다.

  • Operationalized — 문서가 아니다. 배포되고 버전되고 쿼리 가능한 인프라. 프로덕션에서 쿼리를 돌릴 수 없으면 knowledge diagram이지 knowledge spine이 아니다
  • Connected — 데이터를 자기 안으로 복사하지 않고 개념을 소스에 바인딩한다. 온톨로지의 “Customer”가 레이크하우스의 row, 도메인 그래프의 노드, 계약서에서 추출된 엔티티로 해소된다 — 마이그레이션이 아니라 매핑을 통해
  • Backbone — 생물학적 척추처럼 사고하지도 않고 몸의 질량을 저장하지도 않는다. 머리(AI·분석·애플리케이션)와 사지(데이터 소스)를 연결하고 신호를 안정적으로 전달한다. 제거해도 모든 게 그대로 있지만 조율된 행동을 할 수 없게 된다

왜 “layer”가 아니라 “spine”인가

시맨틱 레이어는 이미 있고 중요하다. 하지만 “layer”는 수동적이고 평평한 것 — 유리판 — 을 시사한다. spine은 구조적이고 하중을 견딘다(load-bearing).

함의의미
수직성BI 도구와 테이블 사이만이 아니라 원시 소스부터 AI 에이전트까지 스택 전체를 관통
분산을 동반한 중심성하나의 spine, 여러 연결된 사지. 도메인 팀은 자기 그래프를 유지하고 spine이 페더레이트
결과성틀리면 다운스트림 전체가 틀린다. 그것이 정확히 기업 시맨틱이 받아야 할 진지함의 수준

7가지 원칙

  1. 온톨로지 먼저, 인스턴스화 나중 — 클래스·관계·제약을 비즈니스와 함께 OWL/RDF/SHACL 같은 표준으로 설계. 도구는 의미 다음에 온다
  2. 기본은 가상화, 예외적으로 materialize — 레이크하우스·DB에 가상 매핑으로 연결해 데이터가 거버넌스되는 곳에 머물게 한다. 성능이나 추론이 진짜로 요구할 때만 그래프로 materialize
  3. 도메인 지식 그래프를 흡수하지 말고 페더레이트하라 — 도메인 팀이 자기 그래프(리스크, 제품, 공급망)를 소유하고 spine이 공유 상위 개념·식별자로 연결. 시맨틱에 적용된 data mesh 사고 — 도메인 소유권, 중앙 상호운용성
  4. 비정형 소스를 1급 시민으로 — 계약서·리포트·이메일·위키가 기업 지식의 대부분을 담는다. 추출 파이프라인의 출력이 온톨로지의 용어로 랜딩되어야 PDF의 조항과 테이블의 row가 같은 “Obligation”을 기술한다
  5. spine을 AI의 grounding 레이어로 — 모든 에이전트·코파일럿·RAG 파이프라인이 자기만의 사적 비즈니스 개념을 임베딩하지 말고 spine을 통해 엔티티를 해소하고 관계를 순회해야 한다. 그래야 답이 단지 유창한 게 아니라 설명 가능하고 감사 가능해진다
  6. 코드처럼 버전·거버넌스 — 온톨로지 변경이 리뷰·테스트·릴리스를 거친다. lineage, 접근 통제, definition-of-record가 spine과 함께 살아 의미가 해소되는 지점에서 거버넌스가 강제된다
  7. 척추뼈 하나씩 키워라 — 도메인 하나, 현재 스택이 답할 수 없는 고가치 질문 하나로 시작. 증명하고 확장

아키텍처 5부 (플랫폼 무관)

① 온톨로지 · 거버넌스 코어    소프트웨어처럼 버전 · 릴리스되는 형식 온톨로지
② 시맨틱 플랫폼               인스턴스화 · 추론 · 검증 · 소스 간 쿼리
③ 연결 fabric                 레이크하우스로의 가상 매핑
                              도메인 그래프 페더레이션 링크
                              비정형 콘텐츠 추출 파이프라인
④ 소비 plane                  SPARQL/GraphQL/SQL 엔드포인트 (앱 · BI)
                              검색 · grounding API (LLM · 에이전트)
⑤ 피드백 루프                 사용 분석 + steward 워크플로 → 온톨로지로 수정 환류

소스는 그 자리에 머물고, 의미는 중앙에서 해소되며, 소비자는 다시는 물리 스키마에 바인딩하지 않는다.

구체적 인스턴스 (벤더는 교체 가능)

Stardog + Databricks 조합의 예:

  • 구조화 데이터는 Databricks 레이크하우스에 남고 virtual graph가 Delta 테이블을 온톨로지 개념에 매핑 → “Customer”에 대한 SPARQL이 쿼리 시점에 SQL로 번역되어 푸시다운. 복사 없음, drift 없음, Unity Catalog 거버넌스가 소스에서 여전히 적용
  • 비정형은 온톨로지를 준수하는 RDF를 뱉는 추출 파이프라인으로 랜딩
  • 분석가는 그래프 개념을 테이블로 노출하는 BI/SQL 엔드포인트로, 에이전트는 모델 가중치가 아니라 그래프에 grounded된 답을 lineage와 함께 주는 자연어 인터페이스로 접근

Stardog 대신 다른 시맨틱 플랫폼, Databricks 대신 Snowflake로 바꿔도 패턴은 유지된다. spine은 아키텍처이지 벤더가 아니다.

Semantic Layer · SSOT와의 관계

Knowledge Spine은 SSOT 이니셔티브가 실패하는 이유에 대한 구조적 답이기도 하다. SSOT 실패의 근본 원인은 데이터가 여러 곳에 산다는 것이 아니라 여러 팀이 같은 지표를 다르게 정의한다는 것이고, 테이블은 그것을 풀 수 없다. spine은 그 정의를 쿼리 시점에 강제되는 인프라로 만든다.

다만 spine이 조직적 합의를 대체하지는 않는다. 여전히 비즈니스가 정의를 소유하고 엔지니어링이 구현해야 하며, 무엇이 공식 정의인지 누군가 결정해야 한다. spine은 그 결정을 실행 가능하게 만드는 것이지 결정을 대신하지 않는다.

Bottom line

기업에는 데이터 부족이 아니라 의미 부족(meaning shortage) 이 있다. 온톨로지는 언제나 답이었지만 정지 상태의 온톨로지는 매우 엄밀한 의견일 뿐이다. 운영화하면 backbone이 된다.

만드는 조직은 AI 이니셔티브가 복리로 쌓이고, 안 만드는 조직은 hallucination tax를 계속 낸다.

연관 개념

Source: The Knowledge Spine, Why Most Single Source of Truth Initiatives Fail

그래프 뷰

백링크