오픈소스로 보는
온톨로지 스택

순서는 네 부분입니다. 먼저 Semantica가 무엇이고 어떻게 구성됐는지, 다음으로 제가 직접 빌드하고 실행해 본 결과, 그다음 Smart Data Models의 물 도메인 모델 40개를 구조부터 검증까지 살펴보고, 마지막으로 Palantir 온톨로지와의 개념 매핑과 적용 시나리오로 마무리합니다.

• 무엇 기업 데이터를 수집·추출해 컨텍스트 그래프 + 지식 그래프를 만들고, 그 위에서 그래프 분석·인과 추론을 수행하며 모든 결정의 계보(provenance)를 남기는 Python 라이브러리README: “Graph-Native Infrastructure for Context and Accountable AI Systems”
• 핵심 주장 대부분의 에이전트는 유사도 점수(임베딩)로 움직인다 → 구조·관계·설명이 없다. Semantica는 LLM·벡터 스토어 아래에 놓이는 의미 계층으로, KG 구축·추론·계보는 LLM 없이 결정론적으로 동작
• 누구를 위해 AI 플랫폼팀, Databricks·Snowflake 데이터 플랫폼팀, 컴플라이언스·감사, 규제 산업(금융·의료·법률·정부·국방), 자체 호스팅을 원하는 인프라 엔지니어
• 현재 상태 v0.6.7 (2026-08-28, 직전 0.6.6은 08-20 — 주 단위 릴리스) · MIT · Python ≥ 3.8 · pip install semantica · 저장소 내 테스트 파일 346개 · 서브패키지 28개

Semantica는 스스로를 AI 에이전트를 위한 오픈소스 Palantir라고 부릅니다. 기업 데이터를 그래프로 구조화하고, 그 위에서 추론하고, 모든 결정의 계보를 남기는 Python 라이브러리입니다. 특징은 그래프 구축과 추론, 계보 기록이 LLM 없이도 결정론적으로 동작한다는 점입니다. 버전은 0.6.7, MIT 라이선스이고, 저장소를 열어 보면 테스트 파일이 346개, 서브패키지가 28개 있습니다.

README가 약속하는 기능은 여덟 가지로 요약됩니다. 컨텍스트 그래프와 결정 지능이 중심이고, 그 주변에 온톨로지 거버넌스, 완전한 감사 추적, 결정론적 추론, 지식 파이프라인, 기업 데이터 플랫폼 커넥터, 그리고 여러 그래프 저장소와 에이전트 프레임워크 통합이 배치됩니다. Palantir 온톨로지 브리핑에서 본 데이터·로직·액션·보안 네 요소 중 데이터와 로직, 그리고 계보 쪽에 무게가 실려 있습니다.

• 회상 방식 임베딩 유사도·토큰 창 → 그래프 탐색 + 시맨틱 검색
• 결정 이력·계보 저장 안 됨 → 결정은 질의 가능한 1급 객체, 사실마다 PROV-O 출처
• 추론·정책 없음/블랙박스 → 전방 연쇄·Rete·Datalog·SPARQL, 규칙 엔진 + SHACL
• 충돌·중복 조용히 덮어쓰기 → 감지·플래그·해소, 블로킹 + 시맨틱 중복 제거
• 시간·멀티 에이전트 시점별 그래프 스냅샷(타임 트래블), 에이전트들이 공유하는 단일 지능 계층

POSITIONING기존 LLM·벡터 스토어·에이전트 프레임워크를 대체하지 않고 그 위에 얹는 레이어. 결정 기록·인과 추론·계보·거버넌스·감사를 추가한다는 것이 README의 요지.

README의 비교표를 그대로 가져왔습니다. 벡터 검색과 LLM 메모리는 결정 이력도, 출처도, 추론 경로도 남기지 않는 반면 Semantica는 이 모두를 그래프 구조의 속성으로 갖는다는 주장입니다. 중요한 포인트는 기존 스택을 대체하는 것이 아니라 그 위에 얹는 레이어라는 포지셔닝입니다.

저장소의 ARCHITECTURE.md는 소스 → 수집 → 파싱·정규화·분할 → 추출 → 충돌 감지 → 중복 제거 → KG 구축 → 지능 계층(온톨로지·추론·계보·컨텍스트) → 저장소 → 내보내기·시각화·서비스 순으로 전체 흐름을 그립니다.

결정 지능 수명주기: Record → Link → Query → Govern → Audit Export

아키텍처는 전형적인 지식 파이프라인 위에 지능 계층을 얹은 구조입니다. 파일, 웹, 데이터베이스, 스트림에서 수집한 데이터를 파싱하고 나눈 뒤 엔티티와 관계를 추출하고, 충돌과 중복을 정리해 지식 그래프를 만듭니다. 그 위에서 온톨로지, 추론, 계보, 결정 컨텍스트 네 모듈이 동작하고, 결과는 그래프 저장소와 벡터 저장소에 담겨 REST, MCP, CLI, Explorer로 나갑니다.

# README · Quick Start (원문)
from semantica.context import ContextGraph

graph = ContextGraph(advanced_analytics=True)

# Every agent decision becomes a queryable, auditable knowledge node
decision_id = graph.record_decision(
    category="vendor_selection",
    scenario="Choose cloud provider for HIPAA workload",
    reasoning="AWS offers BAA, mature HIPAA tooling, and existing team expertise",
    outcome="selected_aws",
    confidence=0.93,
)

# Ask "why did this happen?" and get a real, structured answer
chain     = graph.trace_decision_chain(decision_id)        # full causal ancestry
similar   = graph.find_similar_decisions("cloud vendor", max_results=5)  # precedents
impact    = graph.analyze_decision_impact(decision_id)     # downstream influence map
compliant = graph.check_decision_rules({"category": "vendor_selection"})  # policy gate

코드로 보면 개념이 분명해집니다. 결정 하나를 record_decision으로 기록하면 노드가 되고, 인과 관계로 다른 결정과 연결됩니다. 이후 왜 이 결정이 나왔는지 인과 조상을 되짚고, 비슷한 선례를 찾고, 하류 영향을 분석하고, 정책 규칙을 검사할 수 있습니다. 마지막에는 PROV-O 형식으로 감사 추적을 내보냅니다.

• OWL 생성·검증 OntologyGenerator·OntologyValidator — 데이터에서 온톨로지를 만들고 검증
• SHACL 제약 그래프가 지켜야 할 형태(shape)를 선언 → 정책·컴플라이언스 규칙으로 집행
• SKOS 어휘 통제 어휘 관리 + 비주얼 편집기 — 용어의 의미를 임베딩이 아닌 명시적 정의로
• 충돌 감지 서로 모순되는 사실을 조용히 덮어쓰지 않고 감지·플래그·해소(ConflictDetector·SourceTracker)
• 계보·시간 모든 사실에 W3C PROV-O 출처, BiTemporalFact·TemporalGraphQuery로 시점별 스냅샷

README의 표현“결정 계보와 감사 추적은 제품이 아니라 구조에서 따라 나오는 속성” — 규제기관의 “왜?”에 구조가 답한다는 주장.

거버넌스는 W3C 표준 위에 서 있습니다. OWL로 온톨로지를 만들고 검증하고, SHACL로 그래프가 지켜야 할 형태를 선언해 정책으로 집행하고, SKOS로 어휘를 관리합니다. 모순되는 사실은 덮어쓰지 않고 감지해서 플래그를 세우고, 모든 사실에는 PROV-O 출처가 붙습니다. 시점별 스냅샷도 지원해 특정 시각의 그래프를 되돌아볼 수 있습니다.

추론 엔진은 네 종류를 제공하고 모두 설명 가능한 결정론적 엔진입니다. 저장소는 라벨 프로퍼티 그래프와 RDF 트리플 스토어, 벡터 스토어를 코드 변경 없이 바꿔 끼울 수 있게 추상화했습니다. 인터페이스는 REST, MCP, CLI, 그리고 LangChain·CrewAI·Agno 통합까지 넓습니다. README가 말하는 CLI 50개 이상은 저장소에서 데코레이터 89개로 확인됩니다.

• 화면 구성 좌측 사이드바 Knowledge Explorer · Analyze · Decisions · Enrich · Manage · Ontology Hub; README 데모는 632 nodes · 1,069 relationships. 위 화면은 제가 빌드한 번들에 저장소 테스트 픽스처(12 nodes · 7 edges)를 주입해 띄운 것(Python 백엔드 없이 요청 가로채기)
• 기능 명령·노드·개념 검색, 거리 기반 탐색(“Distance reasoning”), 엔티티 도시에(계보·정합성 지표), 시간 축(Temporal evidence), 결정 컨텍스트
• 구현 explorer/ — Vite 6 + React 19 + TypeScript; npm run build가 semantica/static으로 번들(2.2 MB)을 내보내 Python 패키지에 포함. Python 측 FastAPI 앱(semantica.explorer, 기본 포트 8000)이 /api·/ws로 그래프·결정·온톨로지 데이터를 서빙
• 역할 Palantir의 Object Explorer·Vertex에 해당하는 탐색 UI — 단, 앱 빌더(Workshop)나 액션 실행 UI는 없음

Knowledge Explorer는 브라우저에서 그래프와 결정, 계보를 탐색하는 UI입니다. 데모 화면에는 632개 노드와 천여 개 관계가 로드되어 있고, 사이드바에 결정과 온톨로지 허브 메뉴가 있습니다. Palantir로 치면 Object Explorer와 Vertex를 합친 탐색 도구에 가깝고, 앱 빌더나 액션 실행 화면은 아직 없습니다.

# 실행 로그 (2026-09-02, Windows 11 · Node 24 · JDK 17)
$ git clone --depth 1 https://github.com/semantica-agi/semantica
   → 46 MB · 28 subpackages · 346 test files

$ cd explorer && npm install
   → added 263 packages

$ npm run build
   → EXIT 0 · tsc -b + vite build 12 s · 2,535 modules → semantica/static 2.2 MB (45 assets)

$ npm test
   → node --test 105/105 통과 (graph-store 1 · graph-workspace 81 · plugin-registry 7 · temporal guards 16)

$ npx vite preview --port 4173  +  puppeteer 요청 가로채기로 /api 픽스처 주입
   → 12 nodes · 7 edges 렌더 · 화면 4장 캡처 (Playwright e2e만 미실행)
   → 발견: /api 응답 형태가 어긋나면 Explore 뷰가 ErrorBoundary로 붕괴 (GraphWorkspace.tsx)

$ python --version
   → (없음) Windows Store 스텁 · 코어 미실행
$ grep -c "torch\|transformers\|spacy" pyproject.toml
   → 필수 의존성에 포함 → 수 GB 설치 필요

직접 해본 결과를 숨김 없이 정리합니다. 저장소는 얕은 클론으로 46메가바이트, 안에는 서브패키지 28개와 테스트 파일 346개가 있습니다. Explorer 프론트엔드는 Node로 빌드해 확인했습니다. 반면 코어 라이브러리는 torch와 transformers 같은 무거운 의존성이 필수여서, Python이 없는 이 환경에서는 코드와 문서, 쿡북으로 파악했습니다. 실제 도입 시에는 Docker 이미지나 별도 Python 환경이 정석입니다.

• 누가 FIWARE Foundation · TM Forum · IUDX · OASC(Open & Agile Smart Cities)가 이끄는 글로벌 프로그램 — 오픈 라이선스(CC BY 4.0)
• 무엇 도시·물·에너지·농식품 등 도메인별 공통 데이터 모델: JSON Schema + NGSI-LD @context + 예제 페이로드 + 자동 생성 스펙
• 규모 공식 목록(official_list_data_models.json, 2026-09-02) 기준 13 도메인 · 82 subjects · 1,118 data models; Smart Water는 7 subjects · 40 models
• 확장 경로 Incubated → Candidates(기존 표준·온톨로지를 SDM 형태로 번역) → 정식. 최근 UNTP 디지털 제품 패스포트, CityJSON(33), Gaia-X 온톨로지(165), ERA 철도(74) 후보 추가

Smart Data Models는 FIWARE 재단과 TM Forum, IUDX, OASC가 함께 이끄는 표준 데이터 모델 프로그램입니다. 오늘 기준 공식 목록에는 13개 도메인, 82개 subject, 1,118개 데이터 모델이 등록되어 있고, 각 모델은 JSON 스키마와 NGSI-LD 컨텍스트, 예제, 자동 생성 문서로 구성됩니다. 기존 표준을 번역해 들여오는 Candidates 저장소가 최근 활발합니다.

# dataModel.WaterQuality/WaterQualityObserved/  (저장소 실물)
WaterQualityObserved/
├─ schema.json          JSON Schema · $schemaVersion 0.0.6
│                          allOf → GSMA-Commons + Location-Commons
├─ model.yaml           속성·설명·태그 — 문서 자동 생성의 원본
├─ examples/            10개 변형
│   ├─ example.json               NGSI-v2 keyvalues
│   ├─ example.jsonld             NGSI-LD keyvalues (+@context)
│   ├─ example-normalized.json    NGSI-v2 normalized
│   ├─ example-normalized.jsonld  NGSI-LD normalized
│   └─ …geojson 변형
├─ doc/spec.md          자동 생성 스펙 (다국어 spec_*.md)
├─ schema.sql           관계형 DDL 내보내기
├─ schemaDTDL.json      Azure Digital Twins DTDL
├─ swagger.yaml         OpenAPI 정의
├─ ADOPTERS.yaml · notes.yaml · README.md

모델 하나는 폴더 하나입니다. 저장소에서 WaterQualityObserved 폴더를 열어 보면 JSON 스키마, 모델 정의 YAML, 열 가지 예제 변형, 자동 생성 스펙 문서, 그리고 SQL과 DTDL, OpenAPI 내보내기가 한 세트로 들어 있습니다. 모든 모델은 공통 스키마의 GSMA-Commons와 Location-Commons를 상속해 id, type, 위치 같은 기본 속성을 통일합니다.

Subject (저장소)	엔티티	대표 엔티티 · 관계
WaterQuality	3	WaterQualityObserved(61 props) · WaterQualityPredicted · SludgeQualityObserved → refPointOfInterest 관계
WaterDistribution	1	WaterDistributionNetwork(21) — 도시 상수도망 요약
WaterConsumption	1	WaterConsumptionObserved(13) — 스마트 미터 소비·누수 알람·유량
WasteWater	7	WasteWaterPlant · WasteWaterTank · Blower · OffGasStack · WaterProcess … → startsAt / endsAt
OpenChannelManagement	10	OpenChannel · Junction · SluiceGate · Spillway · RegulationStructure … → upstreamNode / downstreamNode
WaterDistributionManagementEPANET	11	Junction · Pipe · Pump · Tank · Valve · Reservoir · Curve · Pattern · WaterNetwork · SimulationScenario(45) · Result
SatelliteImagery	7	EOProduct · EOSatelliteImagery · EOInstrument · EOAnalysis … → observedBy / isAnalysisOf

Smart Water 도메인은 SmartWater 저장소가 7개 서브모듈을 가리키는 구조라, 실제 모델은 7개 저장소를 따로 받아야 합니다. 모두 받아 집계하면 40개 엔티티입니다. 수질 관측, 상수도망, 소비량, 하수처리, 개수로 관리, EPANET 관망 시뮬레이션, 위성 영상까지 물 관리의 데이터 계층을 넓게 덮습니다.

# examples/example.json — NGSI-v2 keyvalues (세비야 D1 지점, 발췌)
{
  "id": "waterqualityobserved:Sevilla:D1",
  "type": "WaterQualityObserved",
  "dateObserved": "2017-01-31T06:45:00Z",
  "location": { "type": "Point", "coordinates": [ -5.993307, 37.362882 ] },
  "measurand": [ "NO3, 0.01, M1, Concentration of Nitrates" ],
  "temperature": 24.4,
  "conductivity": 0.005,
  "pH": 7.4,
  "NO3": 0.01,
  "flow": 127.53,
  "alkalinity": 0.1,
  "sulphate": 143.3,
  "Pb": 0.0,  "Hg": 0.0,  "Cd": 0.001,
  "total-surfactants": 0.3,
  "refPointOfInterest": "…:PointOfInterest:Sevilla:D1"
}

대표 모델인 WaterQualityObserved를 해부해 보면, 수질 관측 한 건을 61개 속성으로 표현합니다. 필수는 아이디, 타입, 관측 시각, 위치 넷뿐이고, 나머지는 온도, 전기전도도, 산도부터 질산염, 중금속, 대장균까지 선택 속성입니다. 정의되지 않은 측정 항목은 measurand 배열로 넣을 수 있고, 관측 지점은 관계로 연결됩니다.

# example.jsonld — keyvalues (사람이 읽기 쉬운 형태)
{
  "id": "urn:ngsi-ld:WaterQualityObserved:…:Sevilla:D1",
  "type": "WaterQualityObserved",
  "dateObserved": "2017-01-31T06:45:00Z",
  "location": { "type": "Point", "coordinates": [ -5.99, 37.36 ] },
  "pH": 7.4,
  "temperature": 24.4,
  "refPointOfInterest": "urn:ngsi-ld:PointOfInterest:…",
  "@context": [
    "https://smartdatamodels.org/context.jsonld"
  ]
}

# example-normalized.jsonld — NGSI-LD normalized (브로커 저장 형태)
{
  "id": "urn:ngsi-ld:WaterQualityObserved:…:Sevilla:D1",
  "type": "WaterQualityObserved",
  "dateObserved": { "type": "Property",
    "value": { "@type": "DateTime", "@value": "2017-01-31T06:45:00Z" } },
  "location": { "type": "GeoProperty",
    "value": { "type": "Point", "coordinates": [ -5.99, 37.36 ] } },
  "pH": { "type": "Property", "value": 7.4 },
  "temperature": { "type": "Property", "value": 24.4 },
  "refPointOfInterest": { "type": "Relationship",
    "object": "urn:ngsi-ld:PointOfInterest:…" },
  "@context": [ "https://smartdatamodels.org/context.jsonld" ]
}

같은 관측 데이터를 두 가지로 표현합니다. 왼쪽 keyvalues는 사람이 읽기 쉬운 평평한 형태, 오른쪽 normalized는 속성마다 Property, Relationship, GeoProperty 타입을 명시한 브로커 저장 형태입니다. 맨 아래 컨텍스트 URL이 각 속성명의 의미를 전역적으로 고정합니다. Palantir에서 Ontology Manager가 속성을 정의하는 역할을 여기서는 JSON-LD 컨텍스트가 맡는 셈입니다.

• 노드 Junction(12 props) · Reservoir(14, headPattern · hasInlet/hasOutlet) · Tank(22, volumeCurve)
• 링크 Pipe(16) · Pump(18, headCurve · pumpPattern · efficCurve · energyPattern) · Valve(16, valveCurve) — 모두 startsAt / endsAt으로 노드에 연결
• 보조 데이터 Curve(펌프·밸브·체적 곡선) · Pattern(시간대별 수요 패턴)
• 시나리오 WaterNetwork(isComposedOf · hasSubNetwork) → SimulationScenario(45 props, hasInputNetwork · hasSimulationResult) → SimulationResult
• 의미 EPANET .inp의 섹션(JUNCTIONS · PIPES · PUMPS · TANKS · PATTERNS · CURVES …)을 NGSI-LD 엔티티와 관계로 옮긴 것 — 관망을 그래프로 저장·질의 가능

연결 고리관망은 본질적으로 노드-링크 그래프. 이 모델을 Semantica의 그래프 저장소에 넣으면 “이 밸브를 닫으면 어느 수용가가 영향받나” 같은 경로 질의가 자연스럽습니다.

EPANET 서브젯은 미국 EPA의 관망 수리 시뮬레이터 입력을 그대로 엔티티로 옮긴 것입니다. 접합점, 저수지, 탱크가 노드이고 관, 펌프, 밸브가 링크로서 시작 노드와 끝 노드 관계를 갖습니다. 시간대별 수요 패턴과 곡선, 그리고 시나리오와 결과 엔티티까지 있어 관망 전체를 그래프로 저장하고 질의할 수 있습니다.

# validate2.js — 핵심 (Node 24, ajv + ajv-formats)
const refs = collectRemoteRefs(allSchemas)   // $ref 루트 URL 7개
await fetchAll(refs)                          // 한 번만 가져와 캐시
const ajv = new Ajv({ strict: false }); addFormats(ajv)
for (const [url, s] of remote) ajv.addSchema(strip(s), url)
for (const e of entities) {                  // 40개
  const validate = ajv.compile(strip(e.schema))
  validate(e.example_json)   // → true ×40
  validate(e.example_jsonld) // → true ×40
}

두 번째로 직접 해본 것은 스키마 검증입니다. 40개 모델의 예제 페이로드를 각 JSON 스키마로 검증했고, 키밸류 형태와 JSON-LD 형태 모두 40개 전부 통과했습니다. 첫 시도는 원격 스키마를 반복해서 불러오다 메모리를 다 써 실패했는데, 원격 스키마 7개를 한 번만 받아 단일 인스턴스에 등록하자 1.4초에 끝났습니다. 표준 모델의 예제와 스키마가 서로 맞는다는 확인입니다.

이제 셋을 한 표에 놓습니다. 타입 정의는 Palantir가 Ontology Manager, Semantica가 OWL과 SHACL, Smart Data Models가 JSON 스키마와 컨텍스트로 합니다. 큰 차이는 액션과 앱입니다. Palantir만 원천 시스템에 되쓰는 액션과 앱 빌더를 갖고 있고, Semantica는 결정을 기록하고 추론하는 데, Smart Data Models는 어휘를 통일하는 데 집중합니다. 경쟁 관계보다 층이 다른 구성 요소로 보는 것이 맞습니다.

마지막으로 물 사업자에 적용한다면 이런 순서입니다. 센서와 관망, 검침 데이터를 Smart Data Models로 표준화해 컨텍스트 브로커에 담고, Semantica로 그래프로 잇고 결정을 기록합니다. 현업 화면과 원천 시스템 되쓰기, 권한은 오픈소스 스택의 빈 자리라 자체 구축이나 상용 플랫폼이 필요합니다. 공공 상호운용성은 표준 모델로, 설명 가능한 AI 파일럿은 Semantica로, 전사 운영은 상용 플랫폼으로 조합하는 것이 현실적입니다. 출처는 화면의 링크에 정리했습니다. 감사합니다.