JOURNEY OF SKEPTICISM → TRUTH

"추론은 if + search"
로 시작한 의심이
존재론 에 닿기까지.

온톨로지라는 단어가 거품인지 정당한지 — 끝까지 의심해서 도달한 지점.
결론: 4개의 층이 있다.

STAGE 01 — 의심의 시작

"추론"을 해체하면

엄밀히 따지면 다음 세 가지로 환원된다.

Forward Chaining

룰 발동 → 새 사실 도출 → 또 다른 룰 발동

if A then B
if B then C
⟹ A then C

Backward Chaining

목표 → 그걸 만족시키는 룰 역추적

goal: C
need B
need A
⟹ search path

Subsumption

타입 계층 따라 속성 자동 상속

요양원 is-a 의료시설
의료시설 needs 구급차
⟹ 요양원 needs 구급차

결국 셋 다

= 구조화된 조건문 + 검색

STAGE 02 — 첫 차이

합성(Composition)

조건문은 같지만, 누가 조합을 작성하느냐가 다르다.

화재 대응 시나리오 — 조합 공간

건물 6종 × 층수 3등급 × 위험물 4종 = 72가지

if-else 라우팅

72개 분기를 일일이 작성

72개 — 모두 사람이 직접

룰 + 합성 엔진

13개 룰 — 시스템이 자동 합성

건물 (6)

층수 (3)

위험물 (4)

6 + 3 + 4 = 13개

↓ 합성 엔진 → 72가지 자동 도출

72개 작성 vs 13개 작성 + 자동 합성

STAGE 03 — 두 번째 차이

룰을 누가 쓸 수 있는가

계산 능력은 같다. 변경 권한이 다르다.

if-else 라우팅

소방서장 → 기획자 → 개발자 → 코드 → QA → 1~2주

온톨로지 시스템

소방서장 → 룰 편집기에서 1줄 수정 → 즉시 (30분)

STAGE 04 — 잠정 결론

"당신 직관이 맞다"

의심한 모든 지점에 정직하게 답하면 — 거의 다 맞다.

"조건문에 검색 낀 것 아닌가?"

YES

맞다. 본질적으로 그것이다.

"거창하게 왜 추론이라 부르나?"

YES

부풀려진 표현이다. "합성 자동화"가 정확하다.

"TypeDB도 그냥 시나리오 자동화 아닌가?"

YES

맞다. 시나리오가 코드 밖에 있을 뿐.

여기서 끝났다면 — 온톨로지는 마케팅 라벨이라고 결론났을 것이다.
하지만 한 가지가 더 있다.

PLOT TWIST

그런데 한 가지가 더 있다.

평탄화하면서 떨어뜨린 결정적 층.

↓

★ STAGE 05 — THE REVEAL

사실 4개의 층이 있다.

"온톨로지"라고 부르는 것은 합성 룰 그래프 + 의미 기반 + 그 위의 존재론적 엔지니어링까지 모두 포함한다.

Ontological Engineering

EPISTEMOLOGY · 인식론적 작업

"이 도메인에서 무엇이 존재하고, 어떻게 분류할 것인가"를 결정하는 작업.
아리스토텔레스의 카테고리, 콰인의 존재론적 헌신과 형식적으로 같은 종류.

↓

Composable Rule Graph

LOGIC · 의사결정 엔진

"무엇을 결정하는가"의 룰 합성 시스템.
13개 원자 룰이 72개 시나리오로 자동 합성됨.

↓

Shared Semantic Substrate

VOCABULARY · 공유 의미 기반

"무엇이 존재하는가"의 카탈로그.
여러 시스템·부서·시간을 가로질러 같은 의미를 보장.

↓

Data Sources

PROVENANCE · 데이터 출처

"어디서 오는가" — 센서, 행정 DB, 현장 보고.
위 모든 층의 재료.

대부분의 사람은 3층만 본다.

그래서 *"그냥 룰 엔진"* 으로 환원해버린다.
진짜 무게는 4층의 작업이 2층의 기반을 만들 때 생긴다.

★ STAGE 06 — 진짜 작업

"한옥마을 추가" 한 줄에
담긴 존재론

단순한 룰 한 줄 추가가 아니다.
다음과 같은 존재론적 판단들이 필요하다.

DECISION 01

카테고리

한옥마을은 건물인가 지역인가? 제3의 무엇인가?

DECISION 02

상위 추상

문화재 + 주거 + 군집 — 어떤 카테고리에 묶을 것인가?

DECISION 03

본질 vs 우연

무엇이 한옥마을을 한옥마을이게 하는가? 한 채만 남으면?

DECISION 04

동일성 기준

절반 개축 후에도 같은 한옥마을인가? 소유주 변경 후에는?

DECISION 05

부분-전체 관계

한옥 한 채는 한옥마을의 부분인가 인스턴스인가?

존재론적 결정

단 한 카테고리 추가에

SAME WORK, DIFFERENT METHOD

같은 종류의 작업, 다른 방법.

PHILOSOPHY · BC 350 ~

아리스토텔레스 → 콰인

• "무엇이 존재하는가"의 카테고리
• 본질 vs 우연
• 보편자 vs 개별자
• 동일성 기준
• 부분-전체 (mereology)

방법: 사색 · 논증 · 개념 분석

CS ONTOLOGY · 1990 ~

Gruber → Palantir

• 도메인 카테고리 명세
• 정의 속성 vs 파생 속성
• 타입 vs 인스턴스
• 엔티티 해상도
• 부분-전체 관계 모델링

방법: 도메인 인터뷰 · 형식 명세 · 시스템 검증

CS가 단어를 차용한 게 아니다 — 같은 종류의 작업이 두 분야에서 일어나는 것이다.

★ STAGE 07 — 진짜 작동 모습

무안 한옥마을에 화재 임계치가 넘는 순간

룰 데이터가 어떻게 설정돼 있고 → 어떻게 작동하고 → 시스템 상태가 어떻게 변하는가.

대상 건물

무안 한옥마을 #B-3021

전남 무안군 / 17세대 / TraditionalCluster

현재 화재위험도

0.85

임계치 0.70 — 초과

관할

무안소방서

FS-MUAN-01 / 차량 12대 가용

CONFIG · 설정

룰 데이터는 이렇게 쓰여 있다

코드가 아니라 데이터. 도메인 전문가가 직접 작성·수정 가능.

RULE-001 · 화재 트리거

활성

when: Building.fireRisk > 0.70
then: emit_trigger(severity=HIGH)
create Incident(building, time)

RULE-002 · 한옥마을 자원 매칭

활성

when: type == TraditionalCluster
match: requires = [폼차×2, 전통건축팀]
exclude: 화학소방차 # 목재 손상

RULE-003 · 인접 건물 알림

활성

when: severity == HIGH
collect: nearby = adjacentTo
where distance < 100m
then: notify(nearby, "선제대피 권고")

RULE-004 · 통보 체인

활성

when: type == TraditionalCluster
notify: [관할소방서,
문화재청, 보존회장]

설정의 핵심: 4개 룰은 모두 타입과 관계에 대해 쓰여 있다. #B-3021 처럼 인스턴스를 직접 가리키지 않는다 → 다른 한옥마을이 추가돼도 룰 그대로 작동.

TRIGGER · 임계치 초과 순간

15:14 — 임계치를 넘는다

14:00

0.32

정상

14:30

0.51

관찰

15:00

0.65

경계

15:14

0.85

⚠ 트리거

→

대응

15:14:23 — RULE-001 발동: Building[#B-3021].fireRisk = 0.85 > 0.70 ✓

EXECUTION · 룰 작동 흐름

200ms — 룰 4개가 자동 합성된다

15:14:23.001

RULE-001 평가 → 트리거 발생

Building[#B-3021].fireRisk(0.85) > 0.70 → emit(severity=HIGH) → Incident #INC-882 생성

↓

15:14:23.045

건물 정보 그래프 순회

type=TraditionalCluster · housesResidents=[일반,노약자×2] · adjacentTo=[#B-3019, #B-3022, #B-3025]

↓

15:14:23.078

RULE-002 매칭 → 자원 합성

required = [폼차×2, 전통건축팀, 구급차×1(노약자룰), 지휘차] · exclude=[화학소방차]

↓

15:14:23.112

RULE-003 매칭 → 인접 건물 알림

nearby=[#B-3019(45m), #B-3022(67m), #B-3025(89m)] → 선제대피 권고 발송

↓

15:14:23.156

RULE-004 매칭 → 통보 체인

notify → 무안소방서 · 문화재청(전남지소) · 무안한옥마을 보존회장

↓

15:14:23.201

자원 디스패치 (closest_available)

VEH-117(폼차, 4분), VEH-203(폼차, 6분), TEAM-T1(전통건축, 8분), AMB-09(2분), CMD-01(5분)

총 200ms. 4개 룰이 자동 합성되어 5개 자원 디스패치 + 3개 인접 건물 알림 + 3개 외부 기관 통보까지 실행.

STATUS · 시스템 상태 변화

한 트리거 후 — 시스템이 이렇게 변한다

15:14:22 · BEFORE

Building #B-3021 status NORMAL

활성 사건0건

디스패치된 자원0대

인접 건물 알림없음

외부 통보없음

15:14:23 · AFTER · 200ms

Building #B-3021 status CRITICAL

활성 사건1건 (#INC-882)

디스패치된 자원5대

인접 건물 알림3건

외부 통보3건

활성 자원 디스패치 — 실시간 상태판

자원 ID	유형	출발	예상 도착	상태
VEH-117	폼차	15:14:24	15:18:30	EN ROUTE
VEH-203	폼차	15:14:24	15:20:15	EN ROUTE
TEAM-T1	전통건축팀	15:14:24	15:22:00	DISPATCHING
AMB-09	구급차	15:14:24	15:16:50	EN ROUTE
CMD-01	지휘차	15:14:24	15:19:10	EN ROUTE

한 줄 요약

4개의 룰 데이터가 0.85 임계치 초과 한 번으로
5대 자원 디스패치 + 6개 알림을 200ms 안에 자동 생성한다.

코드 한 줄 수정 없이. 도메인 전문가가 룰만 편집하면 끝.

★ STAGE 08 — 최종 포지션

이름의 무게가 정당한 이유

1차

"온톨로지는 거품 1.5배. 그냥 if + search"

2차

"의미 기반까지 인정하면 1.0배 정확"

최종

"온톨로지 시스템은 그 자체로 존재론적 엔지니어링의 산물이다.
이름이 차용된 게 아니라, 같은 종류의 작업이라서 같은 이름이 붙었다."

평가자에게 줄 한 마디

"우리가 하는 건 단순한 룰 엔진 구축이 아닙니다.

전라남도 화재 도메인의 존재론적 카테고리를 결정하고,
그 위에 의미 기반을 깔고,
그 위에 합성 가능한 룰을 얹는 작업입니다.

'온톨로지'라는 단어는 마케팅이 아니라,
이 작업이 정말로 존재론(ontology)이기 때문에 붙은 이름입니다."

JOURNEY COMPLETE

거품을 의심한 사람만이 거품 너머의 진짜를 본다.
처음부터 받아들인 사람은 깊이를 못 본다.

어떻게 작동하나 — 무안 한옥마을 사례 →

← 왜 온톨로지인가 — 4층 구조

RuleData · 온톨로지 4층 구조의 정직한 해체 · GitHub

"추론은 if + search" 로 시작한 의심이 존재론 에 닿기까지.