티스토리 뷰
📌 시리즈 안내 — 7일 완성 온톨로지 마스터 과정
| 일차 | 주제 | 핵심 내용 |
| 1일차 | 온톨로지 기초 | 온톨로지란? 왜 필요한가? 3대 구성요소 |
| 2일차 (오늘) | 구축 프레임워크 | 5단계 프로세스, 범위 정의, 용어 수집 방법론 |
| 3일차 | 실전 설계 | 제조업 온톨로지 설계 예시 (설비관리·불량분석) |
| 4일차 | 구현 실습 | JSON-LD, 엑셀 기반 온톨로지 직접 만들기 |
| 5일차 | AI 연동 | 프롬프트 엔지니어링 × 온톨로지, RAG 연동 |
| 6일차 | 실전 시나리오 | 불량 자동분석, 사내 AI 챗봇 구축 사례 |
| 7일차 | 30일 로드맵 | 추천 도구, 기술 스택, 주차별 실행 계획 |
💡 1일차 복습: 온톨로지는 AI에게 우리 회사 업무 맥락을 알려주는 '지식 지도'이며, 클래스(분류) + 인스턴스(실물) + 속성(관계·특성)으로 구성됩니다. → 1일차 다시 보기
목차
- 온톨로지 구축, 어디서부터 시작할까?
- 구축 5단계 프로세스 전체 조감도
- 1단계: 범위 정의 — 실패의 80%를 막는 핵심
- 2단계: 용어 수집 — 현장의 '진짜 말'을 모아라
- 3단계: 구조 설계 — 개념을 연결하는 뼈대 만들기
- 4단계: 구현 — 설계를 실제 파일로 만들기
- 5단계: 검증·적용 — 현업이 인정해야 진짜
- 초보자가 반드시 피해야 할 실수 5가지
- 2일차 핵심 정리 & 3일차 예고
1. 온톨로지 구축, 어디서부터 시작할까?
1일차에서 온톨로지의 개념을 이해했습니다. 그런데 막상 "우리 회사 온톨로지를 만들어보자"고 하면, 대부분 이런 벽에 부딪힙니다:
- "범위를 어디까지 잡아야 하지?"
- "회사 업무가 너무 넓은데, 전부 다 해야 하나?"
- "전문 도구가 필요한 거 아닌가?"
결론부터 말하면, 완벽하게 만들려는 순간 실패합니다.
온톨로지 구축의 핵심 원칙은 단 하나입니다:
"작게 시작해서, 빠르게 쓰고, 점진적으로 확장한다"
대기업의 6개월짜리 프로젝트를 흉내 낼 필요가 없습니다. 중소·중견기업에 맞는 실용적 5단계 프로세스를 소개합니다.
2. 구축 5단계 프로세스 전체 조감도
먼저 전체 그림을 보겠습니다. 각 단계의 상세 내용은 아래에서 하나씩 다룹니다.
| 단계 | 활동 | 산출물 | 소요기간 | 핵심 질문 |
| 1단계 범위 정의 | 적용 업무 영역 선정 | 범위 정의서 | 3~5일 | "무엇을 해결할 것인가?" |
| 2단계 용어 수집 | 현장 인터뷰, 문서 분석 | 용어 사전(엑셀) | 1~2주 | "현장에서 뭐라고 부르는가?" |
| 3단계 구조 설계 | 클래스 계층, 관계 매핑 | 온톨로지 설계도 | 1~2주 | "개념들이 어떻게 연결되는가?" |
| 4단계 구현 | 도구로 온톨로지 코딩 | JSON-LD / OWL 파일 | 1~2주 | "AI가 읽을 수 있는가?" |
| 5단계 검증·적용 | 현업 검증, AI 연동 | 적용 보고서 | 1주 | "현업이 '맞다'고 하는가?" |
총 소요기간: 4~8주 (MVP 기준)
하지만 핵심은 시간이 아닙니다. 1단계를 얼마나 잘 하느냐가 나머지 4단계의 성패를 결정합니다.
3. 1단계: 범위 정의 — 실패의 80%를 막는 핵심
왜 범위 정의가 가장 중요한가?
온톨로지 프로젝트 실패 사례를 분석하면, 압도적인 1위 원인이 있습니다:
"처음부터 회사 전체를 다 하려고 했다"
설비도 하고, 품질도 하고, 구매도 하고, 생산계획도 하고... 이러면 용어만 500개가 넘고, 관계는 수천 개가 되고, 6개월이 지나도 완성이 안 됩니다. 결국 팀원들이 지쳐서 프로젝트가 흐지부지됩니다.
범위 정의 4가지 핵심 질문
아래 4가지 질문에 명확하게 답할 수 있어야 합니다. 한 문장으로 답할 수 없다면, 범위가 너무 넓다는 신호입니다.
질문 1: "이 온톨로지로 대답하고 싶은 질문은 무엇인가?"
❌ 나쁜 예: "회사 전체 업무를 AI로 효율화하고 싶다"
✅ 좋은 예: "CNC 설비에서 불량 발생 시, 원인을 5분 안에 파악하고 싶다"
질문 2: "누가 사용할 것인가?"
❌ 나쁜 예: "전 직원이 사용한다"
✅ 좋은 예: "품질팀 5명 + 생산팀 라인장 3명이 사용한다"
질문 3: "어떤 데이터와 연결할 것인가?"
❌ 나쁜 예: "ERP, MES, PLM 전부 다"
✅ 좋은 예: "MES의 설비 가동 데이터 + 품질 검사 데이터"
질문 4: "성공 기준은 무엇인가?"
❌ 나쁜 예: "AI가 똑똑해지면 성공"
✅ 좋은 예: "불량 원인 파악 시간을 평균 3시간 → 30분으로 단축"
추천 시작 영역 (업종별)
처음에는 난이도가 낮고 효과가 빠른 영역 1개만 선택하세요.
| 업종 | 추천 시작 영역 | 난이도 | 이유 |
| 제조업 | 설비 관리 | ★★☆ | 설비 정보가 비교적 정형화되어 있음 |
| 제조업 | 불량 분석 | ★★★ | 효과가 크지만, 변수가 약간 많음 |
| 물류업 | 배송 경로 관리 | ★★☆ | 경로-차량-거점 관계가 명확 |
| IT/SW | 장애 대응 | ★★☆ | 에러 유형-원인-해결책 패턴이 반복 |
| 건설업 | 자재 관리 | ★★☆ | 자재 분류 체계가 이미 존재 |
💡 AI 프로젝트 매니저 팁: 경영진에게 보고할 때는 "전사 온톨로지 구축"이 아니라 **"설비 관리 AI 고도화를 위한 지식 체계 구축"**이라고 표현하세요. 범위가 명확하고 성과가 측정 가능한 프로젝트가 예산을 받기 쉽습니다.
4. 2단계: 용어 수집 — 현장의 '진짜 말'을 모아라
핵심 원칙: 교과서 용어가 아닌, 현장 용어를 모은다
온톨로지의 생명력은 현장에서 실제로 사용하는 언어에 있습니다. 교과서에 나오는 정식 명칭이 아니라, 현업 담당자가 매일 쓰는 표현을 수집해야 합니다.
교과서 용어: "주축 과부하 알람 (Spindle Overload Alarm)"
현장 용어: "스핀들 빨간불", "1호기 또 삐삐거려", "주축 과열"
→ 온톨로지에는 3가지 모두 등록합니다 (정식 명칭 + 동의어)
왜냐하면, 나중에 AI 챗봇에 질문할 때 현장 직원은 "스핀들 빨간불 뭐야?"라고 물어보지, "주축 과부하 알람의 원인을 분석해주세요"라고 말하지 않기 때문입니다.
수집 방법 3가지
방법 1: 현장 인터뷰 (가장 중요)
대상: 각 부서 핵심 담당자 3~5명 (경력 5년 이상 추천)
시간: 1인당 30~40분
핵심 질문 리스트:
[업무 파악 질문]
"이 업무를 신입사원에게 설명한다면, 어떤 순서로 알려주시겠어요?"
"가장 자주 발생하는 문제 3가지는 뭔가요?"
"그 문제를 해결할 때 가장 먼저 확인하는 것은?"
[용어 파악 질문]
"이 장비/자재를 현장에서 뭐라고 부르세요?"
"같은 걸 다른 팀에서는 다르게 부르는 경우가 있나요?"
"이 코드(예: M-001)가 의미하는 게 뭔가요?"
[관계 파악 질문]
"A가 발생하면 보통 B가 원인인가요?"
"이 설비를 관리하려면 어떤 부품이 필수인가요?"
"이 공정에서 가장 중요한 파라미터는 뭔가요?"
💡 인터뷰 팁: 녹음 동의를 받고 녹음하세요. 인터뷰 중에는 용어를 놓치기 쉽습니다. 나중에 다시 들으면서 엑셀에 정리하면 훨씬 정확합니다.
방법 2: 문서 분석
기존 문서에서 핵심 용어를 자동으로 추출합니다.
| 문서 유형 | 추출 대상 | 활용 포인트 |
| 작업 표준서(SOP) | 공정명, 설비명, 파라미터명 | 공정 흐름과 관계 파악 |
| 검사 기준서 | 불량 유형, 검사 항목, 판정 기준 | 품질 온톨로지의 핵심 |
| 설비 매뉴얼 | 부품명, 에러 코드, 조치 방법 | 설비-고장-부품 관계 도출 |
| 회의록/보고서 | 자주 등장하는 키워드 | 실무에서 중요한 개념 파악 |
| ERP/MES 코드 체계 | 품목 코드, 설비 코드, 공정 코드 | 기존 분류 체계 활용 |
Python으로 문서에서 키워드를 자동 추출하는 방법은 4일차(구현 실습)에서 다룹니다.
방법 3: 시스템 데이터 추출
ERP, MES 등 기간 시스템에 이미 정리된 마스터 데이터를 활용합니다.
ERP 품목 마스터 → 원자재 클래스 계층 구조의 기초
MES 설비 마스터 → 설비 클래스 계층 구조의 기초
QMS 불량 코드 → 불량 유형 분류의 기초
이미 시스템에 분류 체계가 있다면, 그것을 온톨로지의 출발점으로 사용하세요. 바닥부터 만들 필요가 없습니다.
용어 사전 엑셀 템플릿
수집한 용어는 아래 형식의 엑셀로 정리합니다. 이 엑셀이 온톨로지의 원재료가 됩니다.
| 번호 | 용어명 | 영문명 | 정의 | 동의어/현장용어 | 사용부서 | 상위개념 | 관련시스템 |
| 001 | CNC 선반 | CNC Lathe | 컴퓨터 수치 제어 선반 가공 설비 | CNC, 씨엔씨, 선반 | 생산팀 | 가공설비 | MES |
| 002 | 스핀들 과열 | Spindle Overheat | 주축 온도 80°C 초과 상태 | 스핀들 빨간불, 주축 과열 | 생산팀, 설비팀 | 기계적 고장 | MES 알람 |
| 003 | 치수불량 | Dimensional Defect | 제품 치수가 공차 범위 초과 | 사이즈 불량, 공차 오바 | 품질팀 | 제품불량 | QMS |
| 004 | SUS304 | SUS304 | 오스테나이트계 스테인리스강 | 서스, 304, 스테인리스 | 구매팀, 생산팀 | 스테인리스강 | ERP |
| 005 | 볼스크류 | Ball Screw | CNC 이송축 구동 핵심 부품 | 볼스크류, BS | 설비팀 | 이송부품 | 설비대장 |
💡 핵심 포인트: "동의어/현장용어" 열이 매우 중요합니다. 나중에 AI 챗봇이 현장 직원의 다양한 표현을 이해하려면, 같은 개념에 대한 여러 표현을 모두 등록해야 합니다.
목표 수량: 첫 번째 온톨로지는 50~100개 용어면 충분합니다. 500개 이상 모으려 하지 마세요.
5. 3단계: 구조 설계 — 개념을 연결하는 뼈대 만들기
설계 3단계 프로세스
용어 사전이 완성되면, 이제 용어들을 구조화할 차례입니다. 3단계로 진행합니다.
5-1. 클래스 계층 구조 그리기
용어 사전에서 "상위개념" 열을 기준으로 트리 구조를 만듭니다.
[설비 관리 온톨로지 - 클래스 계층]
설비(Equipment)
├── 가공설비(Processing)
│ ├── CNC 선반
│ ├── CNC 밀링
│ ├── 프레스
│ └── 사출기
├── 검사설비(Inspection)
│ ├── CMM
│ └── 비전검사기
└── 물류설비(Logistics)
├── AGV
└── 컨베이어
고장(Failure)
├── 기계적 고장(Mechanical)
│ ├── 스핀들 과열
│ ├── 진동 이상
│ └── 부품 파손
├── 전기적 고장(Electrical)
│ ├── 센서 오류
│ └── 모터 과열
└── 소프트웨어 고장(Software)
├── PLC 오류
└── 통신 단절
부품(Part)
├── 소모품(Consumable)
│ ├── 절삭공구
│ ├── 필터
│ └── 윤활유
└── 핵심부품(Critical)
├── 스핀들
├── 볼스크류
└── 서보모터
설계 원칙:
- 계층은 3~4단계를 넘지 않는다 (너무 깊으면 관리가 어려움)
- 같은 레벨의 형제 클래스는 상호 배타적이어야 한다 (CNC는 가공설비이면서 동시에 검사설비일 수 없음)
- 모든 하위 클래스는 상위 클래스의 특성을 상속한다 ("CNC 선반"은 "가공설비"의 모든 속성을 가짐)
5-2. 관계(속성) 매핑
클래스 간, 인스턴스 간에 어떤 관계가 있는지 정의합니다. 이것이 온톨로지의 가장 핵심적인 부분입니다.
| 관계명 (한글) | 관계명 (영문) | 주어 (Domain) |
목적어 (Range) |
예시 |
| ~에 위치한다 | located_in | 설비 | 공장/라인 | CNC 1호기 → 1공장 A라인 |
| ~를 담당한다 | maintained_by | 설비 | 담당자 | CNC 1호기 → 김기술 |
| ~고장이 발생했다 | has_failure | 설비 | 고장 | CNC 1호기 → 스핀들과열 |
| ~가 원인이다 | caused_by | 고장 | 원인 | 스핀들과열 → 윤활유부족 |
| ~부품이 필요하다 | requires_part | 설비 | 부품 | CNC → 볼스크류 |
| ~로 해결한다 | resolved_by | 고장 | 조치방법 | 스핀들과열 → 윤활유 보충 |
| ~교체주기 | replacement_cycle | 부품 | 기간(일) | 볼스크류 → 365일 |
관계 설계 팁:
✅ 좋은 관계: 구체적이고 방향이 명확
"CNC 1호기 -- has_failure --> 스핀들과열"
❌ 나쁜 관계: 모호하고 방향 불명확
"CNC 1호기 -- 관련됨 --> 스핀들과열"
관계는 항상 "A는 B에 대해 [관계]이다" 형태로 읽을 수 있어야 합니다.
5-3. 제약조건(Rule) 정의
특정 조건에서 적용되는 규칙을 정의합니다. 이 부분이 AI 추론의 핵심이 됩니다.
[제약조건 예시]
규칙 1: IF 스핀들온도 > 80°C THEN 고장유형 = 스핀들과열
규칙 2: IF 진동값 > 4.5mm/s THEN 점검항목 = [볼스크류, 베어링]
규칙 3: IF 부품사용시간 > 교체주기 THEN 상태 = 교체필요
규칙 4: IF 고장유형 = 스핀들과열 AND 윤활유잔량 < 30% THEN 원인 = 윤활유부족
규칙 5: IF 불량유형 = 치수불량 AND 설비 = CNC THEN 점검순서 = [공구마모 → 척킹 → 스핀들]
이 규칙들은 대부분 베테랑 직원의 머릿속에만 존재합니다. 인터뷰 과정에서 "이런 상황이면 보통 어떻게 하세요?"라고 질문해서 추출합니다.
설계 시각화 도구
이 단계에서는 **draw.io (무료)**, **윔지컬 whimsical.com**를 추천합니다.
사용법:
1. draw.io (https://app.diagrams.net) 접속
2. 새 다이어그램 → "Entity Relationship" 템플릿 선택
3. 클래스는 사각형, 관계는 화살표로 연결
4. 팀원·현업과 공유하여 검토
draw.io로 그린 설계도는 현업 검증 때 커뮤니케이션 도구로 매우 유용합니다. 코드나 엑셀보다 그림으로 보여주면 비개발자도 즉시 이해합니다.
6. 4단계: 구현 — 설계를 실제 파일로 만들기
설계가 완료되면 AI가 읽을 수 있는 형태로 변환합니다. 기술 역량에 따라 3가지 방법 중 선택하세요.
방법별 비교
| 방법 | 난이도 | 도구 | 추천 대상 |
| 엑셀 기반 | ★☆☆ | 엑셀/구글시트 | 비개발자, 첫 시도 |
| JSON-LD 기반 | ★★☆ | VS Code + Python | 개발 경험자 |
| OWL + Protégé | ★★★ | Protégé 도구 | 온톨로지 전문가 |
엑셀 기반 구현 (가장 실용적)
프로그래밍 없이 엑셀 3개 시트로 온톨로지를 구현할 수 있습니다.
시트 1: 클래스 정의
| ID | 클래스명 | 상위클래스 | 정의 | 동의어 |
| C001 | 설비 | (최상위) | 생산에 사용되는 기계장치 | 장비, Equipment |
| C002 | 가공설비 | 설비 | 소재를 가공하는 설비 | 가공기 |
| C003 | CNC 선반 | 가공설비 | 컴퓨터 수치제어 선반 | CNC, 씨엔씨 |
시트 2: 관계 정의
| ID | 관계명 | 영문 | 주어 클래스 | 목적어 클래스 | 설명 |
| R001 | 위치 | located_in | 설비 | 공장/라인 | 설비가 위치한 장소 |
| R002 | 고장이력 | has_failure | 설비 | 고장 | 설비에서 발생한 고장 |
| R003 | 원인 | caused_by | 고장 | 원인 | 고장의 근본 원인 |
시트 3: 인스턴스(실제 데이터)
| ID | 이름 | 클래스 | 속성1 | 속성2 | 관계1 | 관계2 |
| I001 | CNC 1호기 | CNC 선반 | 도입:2020-03 | RPM:8000 | 위치:1공장A라인 | 담당:김기술 |
| I002 | CNC 2호기 | CNC 선반 | 도입:2021-06 | RPM:10000 | 위치:1공장B라인 | 담당:이설비 |
이 엑셀을 AI 프롬프트에 직접 넣거나, Python으로 JSON-LD로 변환할 수 있습니다. 4일차에서 실습합니다.
7. 5단계: 검증·적용 — 현업이 인정해야 진짜
검증이 필수인 이유
아무리 잘 만든 온톨로지도 현업 담당자가 "이거 아닌데?"라고 하면 무용지물입니다. 특히 다음 항목을 반드시 검증해야 합니다.
검증 체크리스트
[완전성 검증]
☐ 핵심 업무 용어가 빠짐없이 포함되었는가?
☐ 주요 관계(인과, 구성, 위치)가 모두 정의되었는가?
☐ 동의어/현장 용어가 충분히 등록되었는가?
[정확성 검증]
☐ 클래스 계층 구조가 현실과 일치하는가?
☐ 관계의 방향이 올바른가? (A→B가 맞는지, B→A가 맞는지)
☐ 제약조건(규칙)이 현장 경험과 일치하는가?
[실용성 검증]
☐ 실제 업무 질문 10개에 대해 올바른 추론 경로가 존재하는가?
☐ 비전문가도 구조를 이해할 수 있는가?
☐ 새로운 데이터/개념을 추가하기 쉬운 구조인가?
검증 방법: "질문 테스트"
가장 효과적인 검증 방법은 실제 업무 질문으로 테스트하는 것입니다.
테스트 질문 예시:
1. "CNC 1호기에서 치수불량이 나왔는데 원인이 뭐야?"
2. "스핀들 교체한 지 얼마나 됐어?"
3. "A라인에 있는 설비 목록 보여줘"
4. "진동값이 비정상인 설비가 있어?"
5. "이번 달 기계적 고장이 가장 많은 설비는?"
→ 각 질문에 대해 온톨로지의 관계를 따라가면 답을 찾을 수 있는지 확인
→ 답을 찾을 수 없다면, 빠진 클래스/관계/인스턴스를 추가
검증 워크숍 진행 방법
참석자: AI/DX팀 + 현업 핵심 담당자 3~5명
시간: 2시간
준비물: 온톨로지 설계도(draw.io 출력), 용어 사전 엑셀
진행 순서:
1. 온톨로지 설계도 설명 (20분)
2. 용어 사전 함께 검토 — "빠진 용어 없나요?" (30분)
3. 관계 검토 — "이 관계가 맞나요?" (30분)
4. 질문 테스트 — 실제 질문으로 추론 경로 확인 (30분)
5. 수정사항 정리 (10분)
💡 경험상 팁: 현업 담당자들은 처음에 "온톨로지가 뭔지 모르겠다"고 할 수 있습니다. 설계도를 보여주면서 "이 그림이 맞는지만 봐주세요"라고 하면 적극적으로 참여합니다. 어려운 용어를 쓰지 말고, "이 장비가 고장나면 보통 이 부품 때문인 게 맞죠?" 식으로 질문하세요.
8. 초보자가 반드시 피해야 할 실수 5가지
수많은 온톨로지 프로젝트에서 반복되는 실수를 정리했습니다. 이것만 피해도 성공 확률이 크게 올라갑니다.
실수 1: 처음부터 완벽하게 만들려 한다
❌ "모든 설비, 모든 불량 유형, 모든 원자재를 다 넣어야 해"
✅ "CNC 관련 용어 30개, 핵심 관계 10개로 시작하자"
완벽한 온톨로지는 존재하지 않습니다. 1차 버전을 빨리 만들고, 사용하면서 보완하세요.
실수 2: 현업 없이 AI/DX팀끼리만 만든다
❌ "우리가 기술을 아니까 우리끼리 만들자"
✅ "생산팀 박 과장님, 이 구조 한번 봐주실 수 있나요?"
온톨로지의 품질은 도메인 전문가(현업)의 참여도에 비례합니다.
실수 3: 도구에 집착한다
❌ "Protégé 설치부터 해야지" / "OWL 문법부터 공부해야지"
✅ "일단 엑셀로 용어 사전부터 만들자"
도구는 나중입니다. 처음에는 엑셀과 draw.io면 충분합니다.
실수 4: 너무 깊은 계층 구조를 만든다
❌ 설비 > 가공설비 > CNC > 수직형CNC > 5축CNC > 특수5축CNC > ...
✅ 설비 > 가공설비 > CNC (속성으로 "축수: 5축", "형태: 수직형" 구분)
계층이 4단계를 넘으면 관리가 어려워집니다. 세부 구분은 **속성(Property)**으로 표현하세요.
실수 5: 만들고 나서 방치한다
❌ 온톨로지 만들었다 → 보고서 제출 → 서랍 속으로
✅ 온톨로지 만들었다 → AI 시스템에 즉시 적용 → 매월 업데이트
온톨로지는 살아있는 문서입니다. 새 설비가 도입되면 추가하고, 새로운 고장 유형이 발견되면 업데이트해야 합니다. 월 1회 30분 업데이트를 루틴으로 만드세요.
9. 2일차 핵심 정리 & 3일차 예고
✅ 오늘 배운 것
- 온톨로지 구축은 5단계: 범위 정의 → 용어 수집 → 구조 설계 → 구현 → 검증
- **1단계(범위 정의)가 성패의 80%**를 결정 — 작게 시작하라
- 용어 수집은 현장 인터뷰가 핵심 — 교과서 용어가 아닌 현장 용어를 모아라
- 구조 설계는 클래스 계층 + 관계 매핑 + 제약조건 3가지
- 검증은 실제 업무 질문 테스트로 한다
- 5가지 실수(완벽주의, 현업 배제, 도구 집착, 깊은 계층, 방치)를 피하라
📌 오늘의 실습 과제
이 글을 읽었다면, 지금 당장 해볼 수 있는 것:
- 범위 정의 4가지 질문에 우리 회사 기준으로 답변 적어보기
- 가장 먼저 적용하고 싶은 업무 영역 1개 정하기
- 그 영역의 핵심 용어 10개만 엑셀에 적어보기
이 3가지만 해도, 온톨로지 구축의 20%는 완성된 것입니다.
📅 3일차 예고: 실전 설계 — 제조업 온톨로지 직접 그려보기
다음 글에서는 오늘 배운 프레임워크를 바탕으로 실제 제조업 온톨로지를 처음부터 끝까지 설계합니다:
- 설비 관리 온톨로지 전체 설계도
- 불량 분석 온톨로지 전체 설계도
- draw.io로 시각화하는 실전 방법
- 설계 시 가장 많이 하는 질문 Q&A
자주 묻는 질문 (FAQ)
Q1. 용어를 몇 개나 모아야 하나요?
첫 번째 온톨로지는 50~100개면 충분합니다. 핵심은 양이 아니라 관계의 정확성입니다. 용어 50개로도 관계가 잘 정의되어 있으면 AI가 충분히 유용한 추론을 할 수 있습니다. 300개 이상은 첫 시도로는 과합니다.
Q2. 현업 인터뷰가 어려우면 어떻게 하나요?
현업 담당자가 시간이 없다면, 대안으로 (1) 기존 SOP·작업 표준서를 분석하거나, (2) ERP/MES 마스터 데이터를 추출하거나, (3) 과거 회의록·보고서에서 용어를 추출하세요. 다만 현장 인터뷰를 완전히 생략하면 "살아있는 용어"를 놓칠 수 있으므로, 최소 핵심 담당자 1~2명과는 꼭 이야기하세요.
Q3. 온톨로지를 만드는 데 외부 컨설팅이 필요한가요?
첫 번째 MVP 수준이라면 외부 도움 없이 충분히 가능합니다. 이 시리즈의 4일차(구현 실습)까지 따라하면 직접 만들 수 있습니다. 다만 전사 수준의 대규모 온톨로지나 Knowledge Graph 구축은 전문가 자문이 도움이 됩니다.