티스토리 뷰
반응형
📌 시리즈 안내 — 7일 완성 온톨로지 마스터 과정
| 일차 | 주제 | 핵심 내용 |
| 1일차 | 온톨로지 기초 | 온톨로지란? 왜 필요한가? 3대 구성요소 |
| 2일차 | 구축 프레임워크 | 5단계 프로세스, 범위 정의, 용어 수집 방법론 |
| 3일차 (오늘) | 실전 설계 | 설비관리·불량분석 온톨로지 전체 설계 실습 |
| 4일차 | 구현 실습 | JSON-LD, 엑셀 기반 온톨로지 직접 만들기 |
| 5일차 | AI 연동 | 프롬프트 엔지니어링 × 온톨로지, RAG 연동 |
| 6일차 | 실전 시나리오 | 불량 자동분석, 사내 AI 챗봇 구축 사례 |
| 7일차 | 30일 로드맵 | 추천 도구, 기술 스택, 주차별 실행 계획 |
💡 2일차 복습:
온톨로지 구축 5단계(범위 정의 → 용어 수집 → 구조 설계 → 구현 → 검증) 중 1단계 범위 정의가
성패의 80%를 결정합니다. 작게 시작하고, 용어 50~100개로 MVP를 만드세요. → 2일차 다시 보기
목차
- 오늘의 목표: 종이 위에 온톨로지 완성하기
- 설계 실습 ①: 설비 관리 온톨로지
- 설계 실습 ②: 불량 분석 온톨로지
- 두 온톨로지를 연결하기 — 크로스 도메인 설계
- draw.io로 시각화하는 실전 방법
- 설계 품질 자가 진단 체크리스트
- 설계할 때 가장 많이 하는 질문 Q&A
- 3일차 핵심 정리 & 4일차 예고
1. 오늘의 목표: 종이 위에 온톨로지 완성하기
2일차에서 프레임워크를 배웠으니, 오늘은 실제로 온톨로지를 설계합니다.
오늘이 끝나면 여러분 손에는 다음 산출물이 있어야 합니다:
✅ 산출물 1: 설비 관리 온톨로지 설계도 (클래스 + 관계 + 규칙)
✅ 산출물 2: 불량 분석 온톨로지 설계도 (클래스 + 관계 + 규칙)
✅ 산출물 3: 두 온톨로지의 연결 구조
✅ 산출물 4: draw.io 시각화 파일
코딩은 하지 않습니다. 오늘은 **"설계"**에만 집중합니다. 4일차에서 이 설계를 실제 코드/엑셀로 구현합니다.
설계 전 마인드셋
설계할 때 가장 중요한 원칙 3가지를 먼저 새기고 시작합니다.
원칙 1: "쓸 사람" 관점에서 설계하라
→ 이 온톨로지로 AI에게 어떤 질문을 할 것인지를 먼저 정한다
원칙 2: "80/20 법칙"을 적용하라
→ 업무의 80%를 커버하는 핵심 20%만 먼저 설계한다
원칙 3: "추론 경로"가 존재하는지 확인하라
→ 질문 → 관계 → 관계 → 답변으로 이어지는 길이 있어야 한다
2. 설계 실습 ①: 설비 관리 온톨로지
Step 1: 목표 질문 정의
설계는 항상 **"이 온톨로지로 대답할 질문"**에서 시작합니다. 설비 관리에서 현업이 가장 자주 하는 질문 10개를 먼저 뽑습니다.
[설비 관리 핵심 질문 10개]
Q1. "CNC 1호기 최근 고장 이력 보여줘"
Q2. "스핀들 과열이면 원인이 뭐야?"
Q3. "A라인에 있는 설비 전체 목록은?"
Q4. "볼스크류 교체 시기가 된 설비가 있어?"
Q5. "이번 달 가장 고장이 많은 설비는?"
Q6. "CNC 1호기 담당자가 누구야?"
Q7. "진동값이 비정상인 설비 알려줘"
Q8. "200톤 프레스에 필요한 소모품 목록은?"
Q9. "지난 분기 설비별 가동률 비교해줘"
Q10. "기계적 고장과 전기적 고장 비율은?"
이 10개 질문에 AI가 답변할 수 있으면, 설비 관리 온톨로지의 1차 버전은 성공입니다.
Step 2: 클래스 설계
질문에서 등장하는 **핵심 개념(명사)**을 추출하여 클래스로 만듭니다.
질문에서 추출한 핵심 개념:
CNC, 프레스, 설비, 고장, 스핀들 과열, A라인,
볼스크류, 담당자, 진동, 소모품, 가동률
→ 이것들을 분류하면 클래스가 됩니다
설비 관리 온톨로지 — 전체 클래스 계층 구조
📦 설비(Equipment)
├── 📂 가공설비(Processing Equipment)
│ ├── CNC 선반(CNC Lathe)
│ ├── CNC 밀링(CNC Milling)
│ ├── 프레스(Press)
│ └── 사출기(Injection Molding)
├── 📂 검사설비(Inspection Equipment)
│ ├── CMM(3차원 측정기)
│ ├── 비전검사기(Vision Inspector)
│ └── 경도계(Hardness Tester)
└── 📂 물류설비(Logistics Equipment)
├── AGV(무인운반차)
└── 컨베이어(Conveyor)
⚠️ 고장(Failure)
├── 📂 기계적 고장(Mechanical Failure)
│ ├── 스핀들 과열(Spindle Overheat)
│ ├── 진동 이상(Abnormal Vibration)
│ ├── 부품 파손(Part Breakage)
│ └── 마모(Wear)
├── 📂 전기적 고장(Electrical Failure)
│ ├── 센서 오류(Sensor Error)
│ ├── 모터 과열(Motor Overheat)
│ └── 전원 불안정(Power Instability)
└── 📂 소프트웨어 고장(Software Failure)
├── PLC 오류(PLC Error)
└── 통신 단절(Communication Loss)
🔧 부품(Part)
├── 📂 소모품(Consumable)
│ ├── 절삭공구(Cutting Tool)
│ ├── 필터(Filter)
│ └── 윤활유(Lubricant)
└── 📂 핵심부품(Critical Part)
├── 스핀들(Spindle)
├── 볼스크류(Ball Screw)
├── 서보모터(Servo Motor)
└── 베어링(Bearing)
📍 위치(Location)
├── 공장(Plant)
└── 라인(Line)
👤 담당자(Person)
├── 설비담당(Maintenance Staff)
└── 라인장(Line Manager)
📊 센서데이터(Sensor Data)
├── 온도(Temperature)
├── 진동(Vibration)
└── 전류(Current)
설계 포인트 해설:
- 6개 최상위 클래스: 설비, 고장, 부품, 위치, 담당자, 센서데이터. 이 6가지가 설비 관리의 핵심 축입니다
- 깊이는 3단계: "설비 > 가공설비 > CNC 선반"까지. 4단계 이상은 속성으로 구분합니다 (예: CNC의 축수는 속성으로 처리)
- 센서데이터 클래스 추가: Q7(진동값 비정상)같은 질문에 답하려면, 센서 데이터와 설비를 연결하는 구조가 필요합니다
Step 3: 속성(관계) 설계
클래스를 만들었으니, 이제 클래스 사이를 **관계(Property)**로 연결합니다. 이 단계가 온톨로지의 핵심입니다.
객체 속성 (Object Property) — 개체 간 관계
| ID | 관계명(한글) | 관계명(영문) | 주어(Domain) | 목적어(Range) | 역관계 | 대응 질문 |
| R01 | ~에 위치한다 | located_in | 설비 | 위치 | has_equipment | Q3 |
| R02 | ~를 담당한다 | maintained_by | 설비 | 담당자 | manages | Q6 |
| R03 | ~고장이 발생 | has_failure | 설비 | 고장 | occurred_at | Q1, Q5 |
| R04 | ~가 원인 | caused_by | 고장 | 원인카테고리 | causes | Q2 |
| R05 | ~부품이 필요 | requires_part | 설비 | 부품 | used_in | Q8 |
| R06 | ~로 해결 | resolved_by | 고장 | 조치방법 | resolves | Q2 |
| R07 | ~센서가 연결 | has_sensor | 설비 | 센서데이터 | monitors | Q7 |
| R08 | ~와 관련 부품 | related_part | 고장 | 부품 | has_failure_risk | Q4 |
데이터 속성 (Data Property) — 수치/문자 특성
| 대상 클래스 | 속성명 | 데이터 타입 | 예시 | 대응 질문 |
| 설비 | 도입일(install_date) | 날짜 | 2020-03-15 | - |
| 설비 | 누적가동시간(total_hours) | 숫자(시간) | 12,500 | Q9 |
| 설비 | 상태(status) | 선택(가동/정지/점검) | 가동중 | Q9 |
| 고장 | 발생일시(occurred_at) | 날짜시간 | 2024-12-01 14:30 | Q1, Q5 |
| 고장 | 심각도(severity) | 선택(경미/보통/심각) | 심각 | Q10 |
| 고장 | 해결시간(resolution_hours) | 숫자(시간) | 4.5 | - |
| 부품 | 교체주기(replacement_cycle) | 숫자(일) | 365 | Q4 |
| 부품 | 최종교체일(last_replaced) | 날짜 | 2024-06-15 | Q4 |
| 센서데이터 | 현재값(current_value) | 숫자 | 78.5 | Q7 |
| 센서데이터 | 정상범위상한(upper_limit) | 숫자 | 80.0 | Q7 |
| 센서데이터 | 정상범위하한(lower_limit) | 숫자 | 20.0 | Q7 |
Step 4: 추론 규칙 설계
관계만으로는 부족합니다. **"이런 조건이면 이렇게 판단해라"**는 규칙이 필요합니다.
[설비 관리 추론 규칙]
규칙 R-EQ-01: 교체 알림
IF 부품.최종교체일 + 부품.교체주기 < 오늘
THEN 해당 설비에 "부품 교체 필요" 경고
→ Q4 대응: "볼스크류 교체 시기가 된 설비가 있어?"
규칙 R-EQ-02: 센서 이상 감지
IF 센서데이터.현재값 > 센서데이터.정상범위상한
OR 센서데이터.현재값 < 센서데이터.정상범위하한
THEN 해당 설비에 "센서 이상" 경고
→ Q7 대응: "진동값이 비정상인 설비 알려줘"
규칙 R-EQ-03: 고장 원인 추론 (스핀들 과열)
IF 고장유형 = "스핀들 과열"
THEN 점검순서 = [
1순위: 윤활유 잔량 확인 (caused_by: 윤활부족, 확률 40%)
2순위: 베어링 상태 확인 (caused_by: 베어링마모, 확률 30%)
3순위: 가공 부하 확인 (caused_by: 과부하운전, 확률 20%)
4순위: 냉각 시스템 확인 (caused_by: 냉각불량, 확률 10%)
]
→ Q2 대응: "스핀들 과열이면 원인이 뭐야?"
규칙 R-EQ-04: 고장 원인 추론 (진동 이상)
IF 고장유형 = "진동 이상"
THEN 점검순서 = [
1순위: 볼스크류 마모 확인 (확률 35%)
2순위: 베어링 손상 확인 (확률 30%)
3순위: 체결 불량 확인 (확률 20%)
4순위: 기초 불량 확인 (확률 15%)
]
규칙 R-EQ-05: 고장 빈도 기반 설비 등급
IF 설비.최근3개월_고장횟수 >= 5 THEN 등급 = "위험"
IF 설비.최근3개월_고장횟수 >= 3 THEN 등급 = "주의"
IF 설비.최근3개월_고장횟수 < 3 THEN 등급 = "정상"
→ Q5 대응: "이번 달 가장 고장이 많은 설비는?"
Step 5: 추론 경로 검증
설계가 완료되면, 목표 질문 10개에 대해 관계를 따라가면 답이 나오는지 검증합니다.
[검증 예시: Q2 "스핀들 과열이면 원인이 뭐야?"]
추론 경로:
"스핀들 과열"
→ (is_a) → 기계적 고장
→ (caused_by) → [윤활부족, 베어링마모, 과부하운전, 냉각불량]
→ (resolved_by) → [윤활유 보충, 베어링 교체, 부하 조정, 냉각계통 점검]
→ 규칙 R-EQ-03 적용 → 점검 순서와 확률 제공
✅ 경로 존재 → 설계 OK
[검증 예시: Q4 "볼스크류 교체 시기가 된 설비가 있어?"]
추론 경로:
"볼스크류"
→ (used_in) → [CNC 1호기, CNC 2호기, CNC 3호기...]
→ 각 설비에서 (requires_part) → 볼스크류 인스턴스
→ 볼스크류.최종교체일 + 볼스크류.교체주기 vs 오늘 날짜 비교
→ 규칙 R-EQ-01 적용 → 교체 필요 설비 목록
✅ 경로 존재 → 설계 OK
💡 경로가 끊기면? 클래스나 관계가 빠진 것입니다. 예를 들어 Q9("설비별 가동률")에 답하려면 설비와 가동 이력을 연결하는 관계가 필요합니다. 이때 "가동이력(OperationLog)" 클래스와 "has_operation_log" 관계를 추가합니다.
3. 설계 실습 ②: 불량 분석 온톨로지
설비 관리와 함께 제조업에서 가장 효과가 큰 불량 분석 온톨로지를 설계합니다.
Step 1: 목표 질문 정의
[불량 분석 핵심 질문 10개]
Q1. "오늘 발생한 불량 목록 보여줘"
Q2. "치수불량의 주요 원인 3가지는?"
Q3. "이번 주 불량률이 가장 높은 공정은?"
Q4. "외관불량 중 스크래치가 가장 많이 나는 설비는?"
Q5. "이 불량 유형의 과거 조치 이력 보여줘"
Q6. "원자재 Lot별 불량률 비교해줘"
Q7. "특정 작업자의 불량 발생 패턴은?"
Q8. "온도 조건 변경 후 불량률이 변했어?"
Q9. "A 제품과 B 제품의 주요 불량 유형 차이는?"
Q10. "불량 비용이 가장 높은 유형은?"
Step 2: 클래스 설계
🔴 불량(Defect)
├── 📂 외관불량(Appearance Defect)
│ ├── 스크래치(Scratch)
│ ├── 찍힘(Dent)
│ ├── 변색(Discoloration)
│ └── 버(Burr)
├── 📂 치수불량(Dimensional Defect)
│ ├── 공차초과(Out of Tolerance)
│ ├── 편심(Eccentricity)
│ └── 진원도불량(Roundness Error)
└── 📂 기능불량(Functional Defect)
├── 누유(Leakage)
├── 소음(Noise)
└── 동작불량(Malfunction)
🔍 원인(Root Cause)
├── 📂 설비 원인(Equipment Cause)
│ ├── 공구 마모(Tool Wear)
│ ├── 설비 정밀도 저하(Precision Loss)
│ └── 셋업 불량(Setup Error)
├── 📂 자재 원인(Material Cause)
│ ├── 원자재 불량(Raw Material Defect)
│ ├── 경도 불균일(Hardness Variation)
│ └── 혼입(Contamination)
├── 📂 공정 원인(Process Cause)
│ ├── 온도 이탈(Temperature Deviation)
│ ├── 압력 이상(Pressure Abnormality)
│ └── 속도 부적정(Speed Inadequacy)
└── 📂 인적 원인(Human Cause)
├── 작업 미숙(Skill Deficiency)
├── 절차 미준수(Procedure Violation)
└── 검사 누락(Inspection Omission)
📦 제품(Product)
├── 완제품(Finished Product)
└── 반제품(Semi-finished Product)
🏭 공정(Process)
├── 가공(Machining)
├── 열처리(Heat Treatment)
├── 표면처리(Surface Treatment)
└── 조립(Assembly)
🧪 원자재(Raw Material)
├── 철강(Steel)
│ ├── 탄소강(Carbon Steel)
│ └── 스테인리스강(Stainless Steel)
├── 비철금속(Non-ferrous Metal)
└── 수지(Resin)
👤 작업자(Operator)
📋 조치이력(Corrective Action)
├── 즉시조치(Immediate Action)
└── 영구대책(Permanent Action)
📏 검사(Inspection)
├── 초품검사(First Article Inspection)
├── 공정검사(In-process Inspection)
└── 최종검사(Final Inspection)
Step 3: 관계(속성) 설계
불량 분석의 관계는 설비 관리보다 복잡합니다. **인과관계(왜 발생했는가)**가 핵심이기 때문입니다.
핵심 객체 속성
| ID | 관계명 | 영문 | 주어 | 목적어 | 설명 |
| D01 | ~에서 발생 | occurred_in | 불량 | 공정 | 어느 공정에서 발생했나 |
| D02 | ~제품의 불량 | defect_of | 불량 | 제품 | 어느 제품의 불량인가 |
| D03 | ~가 원인 | caused_by | 불량 | 원인 | 불량의 근본 원인 |
| D04 | ~설비에서 발생 | detected_at | 불량 | 설비 | 어느 설비에서 발생했나 |
| D05 | ~로 조치 | resolved_by | 불량 | 조치이력 | 어떻게 해결했나 |
| D06 | ~자재 사용 | used_material | 공정 | 원자재 | 투입 원자재 |
| D07 | ~가 검출 | detected_by | 불량 | 검사 | 어느 검사에서 발견했나 |
| D08 | ~작업자 | operated_by | 공정 | 작업자 | 누가 작업했나 |
| D09 | ~조건에서 | under_condition | 불량 | 공정파라미터 | 발생 시점 공정 조건 |
핵심 데이터 속성
| 대상 | 속성명 | 타입 | 예시 |
| 불량 | 발생일시 | 날짜시간 | 2024-12-01 09:15 |
| 불량 | 수량 | 숫자 | 15개 |
| 불량 | 비용 | 숫자(원) | 450,000 |
| 불량 | 심각도 | 선택(경미/보통/심각/치명) | 보통 |
| 조치이력 | 조치내용 | 텍스트 | 공구 교체 후 정상 확인 |
| 조치이력 | 소요시간 | 숫자(분) | 120 |
| 조치이력 | 효과 | 선택(해결/미해결/재발) | 해결 |
| 원자재 | Lot번호 | 텍스트 | LOT-20241201-A |
| 원자재 | 공급업체 | 텍스트 | (주)한국특수강 |
Step 4: 추론 규칙
[불량 분석 추론 규칙]
규칙 R-QA-01: 불량 유형별 원인 추론 (치수불량)
IF 불량유형 = "치수불량(공차초과)"
AND 설비유형 = "CNC"
THEN 점검순서 = [
1순위: 공구 마모도 확인 (확률 35%)
2순위: 척킹 상태 확인 (확률 25%)
3순위: 스핀들 정밀도 확인 (확률 20%)
4순위: 프로그램 확인 (확률 10%)
5순위: 소재 경도 확인 (확률 10%)
]
규칙 R-QA-02: 자재 Lot 연관 분석
IF 특정Lot.불량률 > 전체평균불량률 × 2
THEN 해당 Lot "자재 이상 의심" 경고
AND 동일Lot 사용 제품 전수검사 권고
규칙 R-QA-03: 공정 파라미터 변화 감지
IF 공정파라미터 변경 시점 이후 불량률 > 변경 전 불량률 × 1.5
THEN "파라미터 변경이 불량 원인일 가능성" 경고
→ Q8 대응
규칙 R-QA-04: 작업자 패턴 분석
IF 특정작업자.불량률 > 팀평균 × 2
AND 특정불량유형 집중 발생
THEN "추가 교육 필요" 제안 + 해당 불량유형 교육자료 연결
→ Q7 대응
규칙 R-QA-05: 비용 기반 우선순위
IF 불량유형.월간비용 > 100만원
THEN 우선개선 대상으로 등록
→ Q10 대응
Step 5: 추론 경로 검증
[검증: Q2 "치수불량의 주요 원인 3가지는?"]
경로:
"치수불량"
→ (is_a) → 불량
→ (caused_by) → [공구마모, 설비정밀도저하, 셋업불량, 원자재불량, ...]
→ 과거 조치이력에서 (resolved_by) 빈도 집계
→ 빈도 상위 3개 = 주요 원인
✅ 경로 존재
[검증: Q4 "외관불량 중 스크래치가 가장 많이 나는 설비는?"]
경로:
"스크래치"
→ (is_a) → 외관불량 → 불량
→ (detected_at) → [CNC 1호기: 12건, CNC 2호기: 3건, 프레스 A: 8건...]
→ 건수 기준 정렬 → 최다 설비
✅ 경로 존재
[검증: Q6 "원자재 Lot별 불량률 비교해줘"]
경로:
원자재(Lot번호)
→ (used_material 역방향) → 공정
→ 해당 공정의 (occurred_in 역방향) → 불량 목록
→ Lot별 불량 수 / Lot별 생산 수 = 불량률
✅ 경로 존재
4. 두 온톨로지를 연결하기 — 크로스 도메인 설계
설비 관리와 불량 분석, 두 온톨로지를 따로따로 만들었습니다. 하지만 실제 현장에서는 이 두 영역이 밀접하게 연결되어 있습니다.
"CNC 1호기에서 치수불량이 발생했다"는 상황은 설비 관리와 불량 분석 양쪽 모두에 걸칩니다.
연결 포인트 3가지
연결 1: 설비 ←→ 불량
불량.detected_at → 설비
"어느 설비에서 불량이 발생했는가?"
연결 2: 고장 ←→ 불량
설비.has_failure → 고장 → (시간적 연관) → 불량
"설비 고장과 불량 발생 간의 상관관계는?"
연결 3: 부품 ←→ 원인
부품.마모 → 고장 → caused_by → 불량원인
"부품 상태가 불량의 원인이 되었는가?"
통합 추론 시나리오
두 온톨로지가 연결되면, 단일 온톨로지로는 불가능했던 고차원 질문에 답할 수 있습니다.
질문: "최근 CNC 1호기 치수불량이 늘었는데, 설비 문제인가 자재 문제인가?"
통합 추론 경로:
1. 불량 온톨로지에서 CNC 1호기의 최근 치수불량 목록 추출
2. 각 불량의 원자재 Lot 확인 → Lot별 불량률 비교
→ 특정 Lot에 집중? → 자재 원인 가능성 ↑
3. 설비 온톨로지에서 CNC 1호기의 센서 데이터 확인
→ 진동값 이상? → 설비 원인 가능성 ↑
4. 설비 온톨로지에서 CNC 1호기의 부품 교체 이력 확인
→ 볼스크류 교체주기 초과? → 설비 원인 확정
AI 답변: "CNC 1호기의 볼스크류 교체주기가 2개월 초과되었고,
진동값이 정상범위를 벗어났습니다.
동일 Lot의 다른 설비에서는 불량이 없으므로
자재가 아닌 설비 원인으로 판단됩니다.
볼스크류 교체를 권장합니다."
이것이 온톨로지의 진정한 가치입니다. 단순 데이터 조회가 아닌, 복수의 지식 영역을 넘나드는 추론이 가능해집니다.
5. draw.io로 시각화하는 실전 방법
설계한 온톨로지를 팀원과 현업에게 공유하려면 시각화가 필수입니다. draw.io(무료) (https://app.diagrams.net/) 또는 whimsical(https://whimsical.com/)로 만드는 실전 방법을 안내합니다.
기본 표현 규칙
온톨로지 다이어그램에는 암묵적인 표현 규칙이 있습니다. 이 규칙을 따르면 누구나 읽을 수 있습니다.
| 요소 | 모양 | 색상 | 예시 |
| 클래스 | 모서리 둥근 사각형 | 파란 계열 | 설비, 고장, 부품 |
| 인스턴스 | 사각형 | 초록 계열 | CNC 1호기, 스핀들과열 |
| 관계 | 화살표 + 라벨 | 검정/회색 | →has_failure→ |
| is_a 관계 | 빈 삼각형 화살표 | 검정 | CNC ──▷ 가공설비 |
| 데이터 속성 | 클래스 안에 텍스트 | - | 도입일, 가동시간 |
| 규칙 | 마름모 또는 점선 박스 | 노란 계열 | IF 온도 > 80℃... |
draw.io 실전 작업 순서
1단계: draw.io 접속 (https://app.diagrams.net)
→ "새 다이어그램" → 빈 다이어그램 선택
2단계: 최상위 클래스 배치 (가운데에서 시작)
→ 설비, 고장, 부품을 수평으로 배치
→ 모서리 둥근 사각형, 파란색 배경
3단계: 하위 클래스 추가 (아래쪽으로 확장)
→ 가공설비, 검사설비, 물류설비
→ is_a 관계를 빈 삼각형 화살표로 연결
4단계: 관계 연결 (수평 또는 대각선 화살표)
→ has_failure, caused_by, requires_part
→ 화살표 위에 관계명 라벨 추가
5단계: 인스턴스 몇 개 추가 (예시용)
→ CNC 1호기, 스핀들과열 등
→ 초록색 사각형으로 구분
6단계: 정리 및 레이아웃
→ "서식 > 레이아웃 > 트리" 자동 정렬 활용
→ 관련 요소끼리 그룹핑
시각화 팁
✅ 좋은 시각화:
- 한 화면에 최상위 클래스 + 핵심 관계만 표시 (전체 조감도)
- 상세 내용은 별도 페이지로 분리 (영역별 상세도)
- 색상으로 영역 구분 (설비=파랑, 불량=빨강, 부품=초록)
❌ 나쁜 시각화:
- 모든 클래스, 모든 관계를 한 화면에 다 넣기
- 화살표가 교차하여 스파게티처럼 엉킨 구조
- 텍스트가 너무 작아서 읽을 수 없음
💡 현업 검증 때 팁: 전체 조감도 1장 + 영역별 상세도 2~3장을 A3로 출력해서 테이블 위에 놓고 워크숍을 진행하세요. 화면으로 보는 것보다 종이 위에서 빨간펜으로 수정하는 게 현업 참여도가 훨씬 높습니다.
6. 설계 품질 자가 진단 체크리스트
설계를 완료했다면, 아래 체크리스트로 품질을 자가 진단하세요. 20개 항목 중 15개 이상 통과하면 좋은 설계입니다.
구조 품질 (7개)
☐ 1. 최상위 클래스가 5~8개 이내인가?
☐ 2. 계층 깊이가 4단계를 넘지 않는가?
☐ 3. 같은 레벨의 형제 클래스가 상호 배타적인가?
☐ 4. 모든 클래스에 명확한 정의(Definition)가 있는가?
☐ 5. 동의어/현장용어가 3개 이상 등록된 클래스가 50% 이상인가?
☐ 6. 관계의 방향(주어→목적어)이 모두 명확한가?
☐ 7. 역관계(inverse)가 필요한 곳에 정의되어 있는가?
추론 품질 (7개)
☐ 8. 목표 질문 10개 중 8개 이상 추론 경로가 존재하는가?
☐ 9. 인과관계(caused_by)가 최소 5개 이상 정의되어 있는가?
☐ 10. 추론 규칙이 최소 3개 이상 정의되어 있는가?
☐ 11. 규칙의 조건(IF)과 결론(THEN)이 검증 가능한가?
☐ 12. 2단계 이상의 추론(A→B→C)이 가능한 경로가 있는가?
☐ 13. 시간 기반 추론(교체주기, 이력 비교)이 가능한가?
☐ 14. 집계 기반 추론(빈도, 비율, 순위)이 가능한가?
실용 품질 (6개)
☐ 15. 현업 담당자 1명 이상이 검토했는가?
☐ 16. 새 개념을 추가할 때 기존 구조를 깨지 않는가?
☐ 17. draw.io 등으로 시각화가 되어 있는가?
☐ 18. 인스턴스를 3개 이상 채워서 테스트했는가?
☐ 19. 기존 시스템(ERP/MES) 데이터와 매핑이 가능한가?
☐ 20. 용어 사전 엑셀이 최신 상태로 유지되고 있는가?
7. 설계할 때 가장 많이 하는 질문 Q&A
Q1. 클래스와 인스턴스 구분이 헷갈립니다
가장 흔한 질문입니다. 판단 기준은 **"그 아래에 더 구체적인 '유형'이 있는가?"**입니다.
"CNC"는 클래스인가, 인스턴스인가?
→ "CNC 선반", "CNC 밀링"이라는 하위 유형이 있다 → 클래스
"CNC 1호기"는 클래스인가, 인스턴스인가?
→ 실제 존재하는 특정 장비, 하위 유형 없음 → 인스턴스
쉬운 기준: "우리 회사에 이것이 2개 이상 있는가?"를 물어보세요.
- "CNC 선반이 2대 이상이다" → CNC 선반은 클래스, 각 호기는 인스턴스
- "CMM이 1대뿐이다" → 그래도 CMM은 클래스, "CMM 1호기"는 인스턴스 (나중에 2대가 될 수 있으므로)
Q2. 관계를 얼마나 세분화해야 하나요?
목표 질문에 답변할 수 있는 수준이면 충분합니다.
❌ 과도한 세분화:
has_minor_failure, has_major_failure, has_critical_failure
✅ 적절한 수준:
has_failure (관계 1개) + severity 속성 (경미/보통/심각/치명)
관계는 **동사(verb)**로, 세부 구분은 **속성(property)**으로 표현하는 것이 원칙입니다.
Q3. 다른 회사의 온톨로지를 참고할 수 있나요?
물론입니다. 제조업에서 참고할 만한 표준 온톨로지가 있습니다.
| 표준 온톨로지 | 분야 | 활용 포인트 |
| IOF (Industrial Ontology Foundry) | 제조 전반 | 설비, 공정, 제품 클래스 참고 |
| SSN (Semantic Sensor Network) | IoT/센서 | 센서 데이터 모델링 참고 |
| FMEA 체계 | 품질/신뢰성 | 고장 모드, 원인, 영향 구조 참고 |
| ISA-95 | 생산관리 | 설비 계층, 공정 흐름 구조 참고 |
다만, 이런 표준을 그대로 가져다 쓰면 안 됩니다. 우리 회사 현장 용어와 맞지 않는 부분이 반드시 있습니다. "구조는 참고하되, 용어와 관계는 우리 것으로"가 원칙입니다.
Q4. 설비 관리와 불량 분석, 어느 것부터 만들어야 하나요?
회사 상황에 따라 다릅니다.
설비 관리를 먼저 하면 좋은 경우:
- 설비 고장이 잦아서 생산성 손실이 큰 경우
- 예방정비 체계를 만들고 싶은 경우
- MES 데이터가 잘 갖춰져 있는 경우
불량 분석을 먼저 하면 좋은 경우:
- 불량률이 높아서 품질 비용이 큰 경우
- 경영진이 품질 개선에 관심이 높은 경우
- QMS(품질관리 시스템) 데이터가 잘 갖춰져 있는 경우
확신이 없다면 설비 관리를 먼저 추천합니다. 설비 정보가 상대적으로 정형화되어 있어 첫 시도로 적합합니다.
8. 3일차 핵심 정리 & 4일차 예고
✅ 오늘 배운 것
- 온톨로지 설계는 "목표 질문 정의"에서 시작한다
- 질문에서 명사를 추출하면 클래스가, 동사를 추출하면 관계가 된다
- 추론 규칙(IF→THEN)이 있어야 AI가 판단을 할 수 있다
- 설계 완료 후 반드시 추론 경로 검증(질문→관계→관계→답)을 한다
- 두 온톨로지를 연결하면 크로스 도메인 추론이 가능해진다
- draw.io / whimsical로 시각화하여 현업 검증의 소통 도구로 활용한다
📌 오늘의 실습 과제
과제 1: 우리 회사 업무에 맞는 "목표 질문" 10개 작성하기
과제 2: 질문에서 핵심 개념(명사) 추출하여 클래스 초안 만들기
과제 3: 개념 사이의 관계(동사) 최소 5개 정의하기
과제 4: 추론 규칙 1개 이상 작성하기 (IF → THEN)
과제 5: (선택) draw.io에서 클래스 5개 + 관계 3개 시각화하기
이 5가지를 완료하면, 여러분의 첫 번째 온톨로지 설계 초안이 완성됩니다.
📅 4일차 예고: 구현 실습 — 설계를 코드로 만들기
다음 글에서는 오늘 만든 설계를 실제로 동작하는 온톨로지로 구현합니다:
- 엑셀 3시트 온톨로지 완성본 (다운로드 가능)
- JSON-LD로 변환하는 Python 코드
- 인스턴스(실제 데이터) 입력 실습
- 구현 시 자주 발생하는 오류와 해결법
자주 묻는 질문 (FAQ)
Q1. 설계에 정답이 있나요?
없습니다. 같은 공장이라도 설계자에 따라 다른 온톨로지가 나올 수 있습니다. 중요한 것은 "목표 질문에 답할 수 있는가?"입니다. 답할 수 있다면 좋은 설계이고, 답할 수 없다면 수정이 필요한 설계입니다. 정답보다 목적 적합성이 기준입니다.
Q2. 처음부터 두 개 영역(설비+불량)을 같이 해야 하나요?
아닙니다. 하나만 먼저 완성하고, 성과를 확인한 뒤에 두 번째를 추가하세요. 오늘 두 영역을 함께 다룬 것은 "연결 가능성"을 보여주기 위한 것입니다. 실제 구축은 반드시 하나씩 진행하세요.
Q3. 클래스가 50개가 넘어가는데, 너무 많은 건가요?
첫 번째 버전으로는 많습니다. 핵심 클래스 15~25개 + 인스턴스 30~50개가 MVP의 적정 규모입니다. 나머지는 2차, 3차 버전에서 점진적으로 추가하세요.
반응형
반응형