5일을 돌아보며

월요일에 우리는 "제조 온톨로지"라는 단어를 처음 들었다. 금요일인 지금, 우리는 자동 진단을 하는 Q&A 시스템을 만들었다. 무엇이 바뀌었나? 그리고 무엇이 진짜 어려운가?

---

우리가 만든 것

[5일간의 산출물]

Day 1: 11개 엔티티, 12개 관계로 구성된 제조 온톨로지
Day 2: Neo4j에 50+ 노드, 80+ 관계 적재
Day 3: GraphRAG 파이프라인 + LLM 기반 엔티티 자동 추출
Day 4: 대화형 Q&A + Multi-hop 추론 + 답변 품질 평가
Day 5: 5개 시나리오를 처리하는 통합 시스템

---

KG 도입의 진짜 비용

많은 사람이 간과하는 비용:

비용	우리가 체감한 것
온톨로지 설계	가장 어려움. 도메인 전문가 협업이 필수
데이터 적재	자동 추출도 신뢰도 70% — 사람 검토 시간 ↑
쿼리 학습	Cypher가 SQL보다 직관적이지만 가변 경로는 어려움
운영	데이터 stale 방지가 영구 과제
사용자 교육	"이렇게 물어보세요" 학습이 의외로 큰 비용

---

KG로 얻은 것

[정량적 효과]
  - 진단 시간: 30분 → 3분 (Multi-hop 자동화)
  - 환각률: Vector RAG 대비 40% 감소
  - 신입 교육: 매뉴얼 수백 페이지 → 챗봇 대화로 압축

[정성적 효과]
  - "왜?" 질문에 경로로 답할 수 있음 (설명 가능 AI)
  - 데이터 자산화 (KG는 그 자체가 자산)
  - 사일로(silo) 데이터 통합 (CMMS + ERP + 매뉴얼)

---

KG로 잃은 것 (또는 못 한 것)

- 빠른 도입: Vector RAG는 1주, KG는 1개월+
- 자유 형식 검색: 매뉴얼 자체 검색은 Vector가 강함
- 단순함: 새 엔티티 타입 추가에 의사결정 필요
- 자가 학습: KG는 사람이 입력/검증해야 함

결론: KG는 만능이 아니다. Hybrid가 답이다.

---

이번 주 학습한 패턴을 다른 도메인에 적용한다면?

도메인	엔티티 후보	핵심 관계
의료	환자/질병/증상/약/의사	HAS_SYMPTOM, TREATED_BY
금융	고객/계좌/거래/위험	RELATED_TO, FLAGGED_AS
법률	사건/판례/조항/판사	CITES, PRECEDES
물류	상품/창고/경로/차량	STORED_IN, ROUTED_VIA

공통 패턴: 엔티티 식별 → 관계 정의 → 추론 시나리오 → Q&A. 도메인이 달라져도 방법론은 동일하다.

---

Week 8과의 연결

[다음 주: 멀티 에이전트 통합 프로젝트]

            ┌────────────────────────────┐
이번 주의 KG ──→ │  Diagnostic Agent (진단)  │
            ├────────────────────────────┤
            │  Maintenance Agent (정비) │
            ├────────────────────────────┤
            │  Procurement Agent (조달) │
            ├────────────────────────────┤
            │  Coordinator (조율)       │
            └────────────────────────────┘

이번 주의 KG는 다음 주 4개 에이전트의 "공유 두뇌".
에이전트들이 KG를 통해 서로 협력한다.

---

한 줄 회고 (당신의 차례)

다음 질문에 짧게 답해보세요:

1. 가장 인상적이었던 "아하 모먼트"는?
2. 가장 어려웠던 부분은? 어떻게 극복했나?
3. 실제 우리 공장에 적용한다면 가장 먼저 무엇을 할까?
4. 이번 주의 학습 중 한 가지만 동료에게 가르친다면?

---

마지막 한 마디

"좋은 KG는 데이터 + 도메인 전문가 + 시간의 합작품이다."

이번 주에 만든 KG는 작지만 진짜다. 여기서부터 시작이다. Week 8, 그리고 그 너머에서 만나자.