학습 여정 · PATOS Learning

01 / 11 기초 문법

RDF — 세 단어 문장

RDF는 진짜 단순합니다. 세 단어 문장 모음이에요. 끝.

민수 ─좋아한다→ 사과

(누가) (어떻다) (무엇을)

여러 개를 모으면:

민수 ─좋아한다→ 사과
민수 ─다닌다→ 행복초등학교
사과 ─색깔이→ 빨강

✨ 마법

문장 ①에 "사과", 문장 ③에도 "사과" — 컴퓨터가 *같은 단어*를 보고 이어붙입니다:
"민수가 좋아하는 것의 색깔은 빨강"

왜 #B-3021 같은 이상한 이름? "민수"는 학교에 5명 있을 수 있어요. 컴퓨터가 헷갈리니까 *학번*을 줍니다. 본인 demo의 #B-3021은 무안 한옥마을 건물의 학번이에요.

RDF는 결국 — 세 단어 문장을 잔뜩 적고, 같은 단어 만나면 잇기. 그게 다.

다음: OWL — 규칙으로 자동 분류 →

02 / 11 한 층 위로

OWL — 규칙으로 자동 분류

🦉 부엉이 = 현명함의 상징. W3C가 일부러 OOL 대신 OWL로 만든 이름.

OWL은 RDF에 *규칙*을 더하는 언어입니다. RDF가 *사실*이라면, OWL은 *카테고리 규칙*이에요.

RDF (사실)

민수 ─다닌다→ 5학년
콩이 ─종류→ 진돗개

OWL (규칙)

5학년에 다니는 사람은 학생
학생은 모두 사람
진돗개는 개
개는 포유류
포유류는 동물

컴퓨터가 자동으로 알아냄:

민수 → 학생 → 사람
콩이 → 개 → 포유류 → 동물

규칙 한 번 적으면 *모든 인스턴스*에 자동 적용됨.

RDF는 사실, OWL은 규칙. 사실은 사람이 일일이, 규칙은 한 번만. 나머지는 컴퓨터.

다음: 왜 OWL을 쓰는가 →

03 / 11 가치 명료화

왜 OWL을 쓰는가 — 4가지 이득

한 줄 답: 같은 말 만 번 안 적어도 되고, 컴퓨터가 대신 이해해주니까. 게으름의 정당화.

①

한 번 적으면 전체에 적용

한옥 1만 채에 일일이 "전통건축물이야" 안 적어도 됨. 한옥 ⊑ 전통건축물 한 줄이면 끝.

②

컴퓨터가 틀린 데이터를 잡아줌

"이 한옥은 *철근콘크리트*다" 잘못 입력 → OWL이 "한옥은 목구조인데 모순!" 자동 감지. 사람이 일일이 검토 안 해도 됨.

③

검색이 똑똑해짐

"전통건축물 화재 다 보여줘" → 한옥·종가·사찰 자동 매칭. 매번 길게 적을 필요 없음.

④

시스템 간 자동 매핑

:한옥 owl:sameAs :Hanok 한 줄로, 무안소방서·국가유산청·자체 시스템 모두 자동 호환.

OWL은 "쓰는 사람의 게으름을 정당화하는 언어"입니다. 좋은 게으름 — 큰 데이터에서 사람이 신경 못 쓰는 일관성을 컴퓨터가 알아서 유지.

다음: 시나리오 vs 추론 →

04 / 11 본질의 차이

시나리오 방식 vs 자동 추론

*결과만 보면 같아 보이지만*, 변화가 닥칠 때 차이가 폭발적으로 벌어집니다.

옷장 비유

📋 시나리오

검은 운동화 → 아빠
빨간 운동화 → 아빠
흰 운동화 → 아빠
갈색 구두 → 아빠
... (30켤레 다)

🦉 추론

"남자 신발 = 아빠 것"
+ 각 신발에 [남자/여자] 태그

새 신발? 태그만 붙이면 자동.

화재 시나리오

건물 5종 × 지역 9종 × 시간 2종 = 90가지:

한옥 + 무안 + 야간 → 폼차2 + 전통팀 + 발주
한옥 + 무안 + 주간 → 폼차2 + 전통팀
한옥 + 일로 + 야간 → 폼차2 + 전통팀 + 발주
... (90가지 다 적기)

vs OWL 룰 4~6개:

한옥 ⊑ 전통건축물
전통건축물 화재 → 폼차2 + 전통팀
야간 화재 → 발주

→ 컴퓨터가 *조합해서* 90가지 자동 생성. 새 건물 추가? 한옥카페 ⊑ 한옥 한 줄. 룰 영원히 안 건드림.

새 케이스

시나리오: O(N)
추론: O(1)

명칭 변경

시나리오: 일괄 수정
추론: URI 한 곳

조합 폭발

시나리오: N×M×K
추론: N+M+K

시나리오는 계산 결과를 미리 저장한 테이블. 추론은 그때그때 계산하는 함수. 결과가 같아 보여도, 변화 비용이 다르다.

→ 변화 비교 데모 보기 다음: 묶기 3종 →

05 / 11 한계의 발견

묶기 3종 — OWL이 못 하는 것

OWL의 핵심은 포함관계로 묶기. 그런데 *기억·관계·경험으로도 묶을 수 있나?* 답: 세 종류가 있고, OWL은 2개만 잘합니다.

①

분류로 묶기 (Taxonomic)

OWL ✓

한옥 ⊂ 전통건축물 ⊂ 건물

"X는 Y의 일종" — OWL의 본업

②

관계로 묶기 (Relational)

OWL ✓

B-3021 ─인접→ B-3019
B-3021 ─소속→ CL-01

"X는 Y와 어떻게 연결됐나" — ObjectProperty

③

시간·경험으로 묶기

OWL ✗

· "2023년에 일어난 모든 화재" — 시간
· "B-3019와 비슷한 패턴의 사례들" — 유사성
· "베테랑 소방관이 직감적으로 위험하다고 본 건물들" — 경험

OWL은 흑백 논리. "비슷하다"·"느낌"이라는 *정도(degree)*를 표현 못 함. 경험은 주관적·문맥적.

한계마다 *다른 도구*가 들어옴

분류·관계	OWL
시간	OWL Time (W3C 확장)
유사성	벡터 임베딩 · KGE
경험·기억	Provenance + Event ontology + 사람의 주석
현상학적	형식화 거의 불가. LLM 해석.

다음: 뉴로심볼릭 →

06 / 11 전체 그림

뉴로심볼릭 — 두 엔진의 자리

OWL의 한계가 곧 *왜 LLM과 같이 써야 하는가*의 답입니다. 처음 본인이 학습한 3층 뇌 모델로 회귀하면 모든 게 맞아떨어져요.

🧠

시맨틱 (좌뇌)

OWL · RDF · 룰엔진

분류·관계·결정성·감사·무한 스케일

💭

신세틱 (우뇌)

LLM · 임베딩

유사성·경험·자연어·유추·뉘앙스

🦾

키네틱 (몸)

API · 트리거

외부 행동 실행 (SMS·dispatch·알림)

OWL과 LLM은 *경쟁이 아니라 각자 자리*예요. 두 엔진이 따로 그려져 있던 첫 PNG가 이미 정답이었어요.

다음: 현존재 차원의 정직 →

07 / 11 철학적 정직

현존재 차원 — ontology의 정직한 한계

가장 중요한 깨달음입니다. ontology 마케팅의 가장 큰 거짓말이기도 하고요.

Ontology는 세상의 관계의미망을 드러내지 않습니다. 이미 누군가가 가진 해석을 부호화할 뿐이에요.

실제로 일어나는 일:

1. 누군가가 이미 해석을 가짐 — 소방관은 "한옥엔 화학소방차 쓰면 안 된다"는 *세계 이해*를 ontology 만들기 *전에* 가지고 있어요
2. ontology는 그 해석을 *기록* — 클래스·관계·룰이 모두 *인간의 결정*
3. 그래서 ontology는 *드러내는 게 아니라 투사하는* 것 — 발견(theoria)이 아니라 commitment(thesis)

Heidegger 식으로

ontology가 잡는 건 vorhanden (present-at-hand) — 사물을 *속성 가진 객체*로 굳혀서 보는 차원. 의미는 zuhanden (ready-to-hand) — *engagement* 차원에서 일어나요. 소방관이 한옥에 다가갈 때 그건 "builtYear 1923인 객체"가 아니라 *지켜야 할 것·불타고 있는 것·안에 사람 있는 것*으로 engaged됩니다.

:Building/B-3021 a :Hanok 트리플은 이 engagement를 *옮기지 못합니다*. 박제할 뿐.

옮기는 과정에서 *반드시 손실*:

· "한옥"의 문화적 두께 — `rdfs:subClassOf`로 못 들어감
· 소방관의 직관적 위험감지 — `fireRisk = 0.85`로 환원 안 됨
· 보존회장의 애착 — `:contactRole`로 표현 안 됨

이 손실분이 ontology의 비용이에요. 그리고 이 비용은 *피할 수 없습니다*. ontology의 가치는 *발견*이 아니라 명시화에 있어요. 숨겨진 합의를 표면 위로 끌어올려, 토론·감사·수정 가능하게 만드는 것 — 그게 전부입니다. 그게 적은 일은 아니지만, *의미의 발견*은 아닙니다.

다음: 4가지 설계 원칙 →

08 / 11 정직한 설계

4가지 설계 원칙

현존재 차원의 한계를 *부정하지 말고 설계 원칙으로 흡수*하는 게 정공법입니다.

1

"의미를 드러낸다" 카피 금지

데모·문서에서 이 표현 쓰지 마세요. 거짓말입니다. 대신: "공동체가 합의한 해석을 명시화·공유 가능하게 만든다"

2

못 잡는 것 명시

rdfs:comment로 "이 클래스로는 못 잡는 것" 적기. 예: :Hanok엔 *문화적 두께*가 빠졌다고 명시.

3

Provenance 의무화

"누가 이 분류를 결정했나"를 매번 추적. 의미는 권위의 결정이지 데이터의 자명한 모양이 아니라는 걸 항상 가시화.

4

주기적 재해석 절차

1~2년마다 도메인 전문가 다시 모여 "여전히 이 분류가 맞나" 재검토. 정적인 ontology는 죽은 의미.

이 네 원칙이 들어간 ontology 데모는 드물어요. 대부분 1번을 어기고 시작합니다 — "ontology로 의미를 드러내자!"는 슬로건. 본인 데모가 그걸 안 한다면, 그 정직함 자체가 차별점입니다.

다음: 본 데모의 한계 →

09 / 11 자기 진단

본 데모의 한계 — 정직한 진단

"OWL이 준비된 상태이지 살려쓰는 상태는 아닙니다." 학습자에게 이 정직함이 가르침의 일부예요.

현 데모 진단

OWL 어휘 사용	✅ 사용 중
OWL reasoner 적극 활용	❌ 시연만
rules.yaml 조건	문자열 매치 (OWL 우회)
신세틱 (LLM·임베딩)	❌ 미통합

왜 이 정도만? 학습 목적엔 이게 적정선이에요:

① OWL 어휘는 반드시 가르쳐야 함 — ontology 기본기
② OWL reasoner는 생략해도 됨 — 학습자가 손으로 따라가면 결과가 보이니까
③ 룰 엔진을 강조 — 화재 도메인의 *임계·시간·트리거*는 OWL DL로 표현 자체가 불가

다음에 갈 만한 곳

· 실제 OWL reasoner 통합 (HermiT·Pellet) — production 시연
· SHACL constraints 추가 — 검증 게이트
· R2RML 변환 — yaml DSL → W3C 표준
· LLM 통합 — 신세틱 레이어를 살리는 단계

다음: LLM이 OWL을 대체할까? →

10 / 11 2024 시대 질문

JSON + LLM이 OWL을 대체할까?

"Claude에게 JSON으로 룰 적시하면 OWL이랑 똑같지 않아?" 본인 직감이 정확해요. 학습 demo 규모에선 거의 동일. 차이는 production scale에서만 본격 드러납니다.

✅ 같은 효과 (작은 규모)

· 클래스 분류 자동 도출
· 룰 기반 트리거
· 모순 검출
· LLM이 *더 나은 점*: 자연어 룰 해석, 컨텍스트 이해, OWL DL 못 하는 추론

❌ OWL이 여전히 이기는 영역

항목	OWL/룰엔진	LLM
속도	<1ms	1~10초
비용	0	호출당 $$
결정성	보장	확률적
감사	가능	블랙박스
스케일	수백만	수백만 비쌈
환각	없음	가능

결정적 사례 — ruledata #how 200ms

15:14:23.001  RULE-001 fires
15:14:23.078  RULE-002 match
15:14:23.112  RULE-003 match
15:14:23.156  RULE-004 match
15:14:23.201  dispatch

200ms 안에 5룰 발동·연쇄. LLM은 1~5초 → 화재 대응엔 부적합.

OWL과 LLM은 경쟁이 아니라 각자 자리예요. 본인의 첫 PNG가 정답이었어요 — 두 엔진이 따로 그려져 있었죠.

다음: 학습 여정의 정답 →

11 / 11 마무리

학습 여정의 정답

본인이 11단계 동안 도달한 곳 — 한 줄로 요약하면:

Ontology는 의미를 드러내지 않습니다. 합의를 명시화할 뿐입니다.
OWL은 분류와 관계를 잘 묶지만, 경험·시간·유사성은 못 잡아요.
그래서 LLM이 그 옆에 필요합니다 — 두 엔진은 경쟁이 아니라 각자 자리.

처음 학습한 PNG의 3층 뇌 모델이 이미 이 모든 답을 그려놨어요. 11단계는 그 그림을 왜 그렇게 그려야 하는지 깨닫는 과정이었습니다.

실제로 보고 싶다면:

여기까지 온 학습자의 다음 자리는 — 이 데모를 *자기 도메인*에 옮겨보는 것. 보험·물류·의료·국방 어디든. 위 11단계가 그대로 적용됩니다.

← Hub로 돌아가기