5

왜 제조 현장에 Knowledge Graph가 필요한가?

제조 온톨로지 설계

학습 목표
  • 제조 현장의 지식이 어디에 어떤 형태로 흩어져 있는지 네 곳 이상 든다
  • 매뉴얼 검색과 관계 탐색이 갈리는 지점을 알람 대응 시나리오로 설명한다
  • 설비·공정·부품·고장이 이루는 복합 관계를 그림으로 그린다
  • 도입 효과를 말할 때 어떤 값을 무엇으로 재야 하는지 지표 이름으로 답한다

왜 제조 현장에 Knowledge Graph가 필요한가?

"김 반장님, CNC 밀링머신에서 알람 E-201이 떴는데 어떻게 해요?"

월요일 오전 7시, 생산 라인에 비상이 걸렸습니다.

[상황]
- CNC 밀링머신 3호기에서 알람 E-201 (스핀들 과열) 발생
- 김 반장은 오늘 휴가
- 매뉴얼은 500페이지짜리 PDF (영어)
- 신입 기술자가 혼자 대응해야 함

[신입 기술자의 행동]
1단계: 매뉴얼 PDF 열기 → Ctrl+F "E-201" → 3개 결과 발견
2단계: 첫 번째 결과 확인 → "See Section 14.3.2" → 찾아감
3단계: "Check coolant level and bearing condition" → 냉각수? 베어링?
4단계: 냉각수 점검 방법을 다시 검색...

[경과 시간: 2시간]
[결과: 생산 라인 2시간 정지 → 일일 생산량 15% 감소]

만약 Knowledge Graph가 있었다면?

[신입 기술자의 행동 - KG 기반]
1단계: 시스템에 "알람 E-201" 입력
2단계: 즉시 표시됨:

  (알람 E-201: 스핀들 과열)
     ├── [원인 1] 냉각수 부족 (확률 45%)
     │      └── [조치] 냉각수 탱크 확인 → 보충
     │      └── [위치] 장비 후면 하단 패널
     │      └── [소요시간] 15분
     │      └── [필요공구] 없음
     ├── [원인 2] 베어링 마모 (확률 35%)
     │      └── [조치] 진동 측정 → 베어링 교체
     │      └── [위치] 스핀들 하우징 내부
     │      └── [소요시간] 4시간 (정비팀 호출)
     │      └── [필요공구] 베어링 풀러, 토크렌치
     └── [원인 3] 과절삭 (확률 20%)
            └── [조치] 절삭 조건 확인 → 이송 속도 조정
            └── [관련 파라미터] F값, S값
            └── [소요시간] 10분

3단계: 냉각수 확인 (가장 높은 확률부터) → 부족 확인 → 보충

[경과 시간: 20분]
[결과: 신속 복구, 생산 영향 최소화]

제조 현장의 지식 관리 문제

문제 1: 지식의 단절 (Knowledge Silo)

┌──────────────────────────────────────────────────────────┐
│              제조 현장의 지식 분산 현황                      │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  [설비 매뉴얼]     [정비 이력]      [품질 데이터]           │
│   PDF 500pg        Excel 파일       MES 시스템            │
│   영어/일어         개인 PC          DB 테이블              │
│       │                │                │                │
│       ▼                ▼                ▼                │
│     읽기 어려움      공유 안 됨       연결 안 됨            │
│                                                          │
│  [작업 표준서]     [숙련공 경험]     [부품 도면]            │
│   종이 문서         머릿속           CAD 파일              │
│   캐비닛 보관       퇴직 시 소실     설계팀만 접근          │
│       │                │                │                │
│       ▼                ▼                ▼                │
│     낡은 버전       전수 불가        찾기 어려움            │
│                                                          │
│  ❌ 이 모든 지식이 서로 연결되어 있지 않다!                 │
│                                                          │
└──────────────────────────────────────────────────────────┘

문제 2: 숙련공 의존 (Expert Dependency)

[실제 사례: 한국 제조업체 A사]

베테랑 기술자 박 과장 (경력 25년):
- "이 소리가 나면 베어링이야. 저번에도 그랬어."
- "겨울엔 예열 20분, 여름엔 10분이면 돼."
- "이 제품은 공차가 +-0.01인데, 습도 높으면 0.005로 잡아야 해."

→ 이 지식이 그의 머릿속에만 존재
→ 은퇴하면? 모든 지식 소실

이 자리에서 숫자를 인용하고 싶으면 사내 인사 데이터에서 직접 뽑는다.
정비 인력의 연령 분포, 향후 5년 정년 도래 인원, 신입이 단독 대응까지 걸린 개월 수를
자기 회사 값으로 채우면 그대로 도입 근거가 된다. 남의 평균은 그 자리에서 쓸 수 없다.

문제 3: 복합 원인 추적의 어려움

[실제 문제: 가공 정밀도 불량]

원인이 하나가 아니라 여러 개가 복합적으로 작용:

  (정밀도 불량)
     ├── 공구 마모 → 절삭력 변화
     │      └── 과절삭 → 이송 속도 과다
     ├── 축 진동 → 가공면 거칠기 증가
     │      └── 베어링 마모 → 윤활 부족
     │      └── 기초 볼트 풀림 → 진동 전달
     └── 열변형 → 치수 변화
            └── 냉각 불량 → 냉각수 막힘
            └── 환경 온도 변화 → 에어컨 고장

기존 방식: 어느 가지부터 볼지 사람이 정하고 하나씩 순차 점검
KG 방식: 가능한 원인 경로를 한 번에 펼쳐 놓고 확률 높은 가지부터 점검
(두 방식의 소요 시간 차이는 Day 5 프로젝트에서 자기 데이터로 재 본다)

Knowledge Graph의 해결책

Knowledge Graph란?

[정의]
실세계의 엔티티(사물, 개념)와 그들 간의 관계를
그래프 구조로 표현한 지식 베이스

[핵심 구성 요소]
노드 (Node)  : 엔티티 (장비, 부품, 작업자, 알람, 조치...)
엣지 (Edge)  : 관계 (포함, 원인, 담당, 생산, 공급...)
속성 (Property): 노드/엣지의 특성 (이름, 날짜, 수치...)

[트리플 (Triple)]
(주어) --[관계]--> (목적어)

예시:
(CNC선반1호기) --[포함]--> (스핀들)
(스핀들)      --[발생가능]--> (과열알람)
(과열알람)    --[원인]--> (냉각수부족)
(냉각수부족)  --[조치]--> (냉각수보충)
(냉각수보충)  --[필요공구]--> (없음)
(냉각수보충)  --[소요시간]--> (15분)
온톨로지(설계도)와 지식그래프(실체)의 관계

온톨로지는 설계도(타입), 지식그래프는 그 설계도로 찍어낸 실체(인스턴스)다. 같은 온톨로지 하나로 수천 개의 일관된 지식그래프를 찍어낼 수 있다.

제조 KG가 만드는 가치

기존 방식KG 기반 방식무엇이 달라지는가무엇으로 재는가
매뉴얼 PDF 검색관계 기반 탐색검색어가 아니라 관계를 따라간다알람 접수부터 첫 조치까지 걸린 시간
숙련공에게 물어봄지식 그래프 조회담당자 부재와 무관하게 답이 나온다문의 후 대기 시간, 야간·휴일 대응 비율
엑셀 정비 이력연결된 정비 이력같은 설비의 반복 고장이 한 화면에 모인다동일 알람 재발 간격
단일 원인 추정복합 원인 추적확률 순으로 점검 순서를 정한다첫 시도로 해결된 비율

효과의 크기는 공장마다 다르므로 이 표에 미리 퍼센트를 적어 두지 않는다. Day 5 프로젝트에서 위 오른쪽 열의 지표를 실제로 재고, 그 값을 사내 보고서에 쓴다.

제조에서 KG가 실제로 쓰이는 자리

특정 회사의 도입 효과를 숫자로 옮겨 적는 대신, 어떤 문제에 이 구조가 맞는지로 정리한다. 아래 넷은 제조 KG 연구와 벤더 사례에서 되풀이해 나오는 유형이다.

[1] 설비 고장 진단
    알람 - 원인 - 조치 - 필요 스킬을 이어 두고 확률 순으로 점검 순서를 낸다.
    이번 주 프로젝트가 이것이다.

[2] 부품 구성(BOM)과 설계 변경 영향 분석
    부품 하나를 바꾸면 어느 제품, 어느 공정, 어느 금형까지 영향이 가는지를
    표를 뒤지지 않고 그래프 탐색으로 본다.

[3] 공정 계보 추적(genealogy)
    불량 로트에서 거꾸로 설비, 작업자, 자재 로트, 검사 이력까지 따라 올라간다.
    리콜 범위를 좁히는 일이 곧 비용이다.

[4] 공급망 리스크
    협력사 - 자재 - 부품 - 제품을 이어 두면 한 협력사가 멈출 때
    영향받는 완제품 목록이 조회 한 번으로 나온다.

도입 사례의 수치를 사내 보고서에 인용할 때는 원 출처를 직접 확인하세요. 벤더 자료의 개선율은 대개 측정 조건이 함께 적혀 있지 않고, 조건이 다르면 재현되지 않습니다.


이번 주 학습 로드맵

Day 1: 제조 온톨로지 설계
  └── "어떤 지식을 어떻게 구조화할까?"

Day 2: Neo4j & Cypher
  └── "그래프 데이터베이스에 지식을 넣자"

Day 3: GraphRAG 통합
  └── "LLM이 그래프를 이해하게 만들자"

Day 4: KG 기반 Q&A
  └── "자연어로 그래프에 질문하자"

Day 5: 설비-공정 Knowledge Graph 구축
  └── "실전 프로젝트: 제조 KG 시스템 완성"

이번 주가 끝나면: "알람 E-201이 떴는데 뭐부터 확인하나요?"라는 질문에 AI가 KG를 탐색해서 단계별 조치 방법을 자동으로 안내하는 시스템을 만들 수 있습니다.

AI로 학습하기 — 꿀팁
KG 도입 제조 문제 해결 사례화AI 학습 팁

제조 현장의 지식 관리 문제를 KG로 해결한 구체적 사례를 AI에게 요청해 학습 동기를 높이세요.

반도체 또는 자동차 부품 제조 공장에서 Knowledge Graph 도입 전후를 비교해줘. 도입 전 문제(설비 매뉴얼이 PDF로 분산, 고장 원인 추적에 며칠 소요, 전문가 은퇴 시 지식 소실)가 KG 도입 후 어떻게 개선되었는지 구체적인 수치나 시나리오로 설명해줘.
이 팁이 도움이 됐나요?
핵심 포인트
  • 제조 현장의 지식은 매뉴얼·숙련공·시스템에 분산되어 있다
  • Knowledge Graph는 엔티티와 관계를 그래프로 연결하여 복합 원인을 추적한다
  • 도입 효과는 미리 적힌 퍼센트가 아니라 대응 시간·재발 간격 같은 지표를 직접 재서 말한다
  • 제조 KG가 잘 맞는 자리는 고장 진단, 설계 변경 영향 분석, 공정 계보 추적, 공급망 리스크다
용어