들어가며
현장에서는 “2호기 출구 85도, 괜찮아?”처럼 짧은 질문이 들어옵니다. 숫자만 보면 단순한 범위 비교처럼 보이지만, 실제 답을 내려면 어느 설비의 어떤 센서가 언제 측정했는지, 당시 어떤 제품을 생산했고 어떤 기준이 유효했는지까지 확인해야 합니다.
이번 글에서는 1·2부에서 정리한 의미 구조를 실제 답변과 후속 업무에 연결합니다. 핵심은 온톨로지가 혼자 판단하는 데 있지 않습니다. 온톨로지가 대상과 관계, 적용 조건을 제공하면 AI와 질의·규칙 엔진이 필요한 사실과 기준을 찾고 비교합니다. 이후 조치는 권한과 승인 절차를 거쳐 업무 시스템이 수행합니다.
질문: 가열로 2호기 출구 온도 85°C는 현재 작업 기준에서 정상인가요? 판단 근거와 필요한 조치도 알려주세요.
| 항목 | 확인된 정보 |
|---|---|
| 설비·센서 | 가열로 2호기(FURNACE-02) 출구 · TS-204 |
| 측정 | 85°C · 2026-08-04 10:30 |
| 작업 | WO-260804-17 · 제품 A 가열 공정 |
| 당시 유효 기준 | 운전 기준서 Rev.3 제4.2항 · 70~90°C · 2025-11-01~2026-08-09 |
| 판정 | 정상 범위 내 |
1. 짧은 질문이 판정으로 바뀌는 과정
AI는 질문에서 설비, 위치, 측정 항목, 값, 단위와 판단 의도를 읽습니다. 질문에 없는 시점과 작업 조건은 현재 작업 화면이나 운영 데이터에서 확인합니다. 이때 확인된 대상을 온톨로지의 설비·센서·작업·기준 관계에 매핑하고, 그래프 질의 또는 검색 엔진으로 관련 정보를 가져옵니다.
그다음 규칙 엔진이나 애플리케이션 로직이 측정 시점에 유효한 기준을 선택해 값을 비교합니다. 이 사례에서는 2026년 8월 4일에 유효했던 Rev.3의 정상 범위가 70~90°C이므로 85°C는 정상 범위 안에 있습니다.
| 단계 | 담당 구성요소 | 처리 내용 |
|---|---|---|
| 질문 해석 | LLM·질의 해석기 | 대상, 값, 단위, 의도와 누락 조건 식별 |
| 의미 연결 | 온톨로지 | 설비·센서·작업·기준의 개념, 관계, 적용 조건 제공 |
| 정보 탐색 | 그래프 질의·검색 엔진 | 측정 사건, 작업 이력, 유효 기준과 원문 조회 |
| 비교·판정 | 규칙 엔진·업무 로직 | 85°C와 당시 정상 범위 비교 |
| 후속 처리 | IAM·워크플로·업무 시스템 | 권한 확인, 승인, 기록·알림·점검 요청 수행 |
이 구분은 구현 단계에서 중요합니다. 온톨로지에 개념과 관계를 정의해 두었다고 해서 판정이나 설비 제어가 자동으로 이뤄지는 것은 아닙니다. 기준 선택에는 시간 조건을 적용한 질의 로직이, 수치 비교에는 규칙 또는 업무 로직이, 후속 조치에는 권한과 승인 체계가 각각 필요합니다.
2. 같은 구조로 답해야 할 네 가지 질문
사례 1. 85°C는 왜 정상인가
TS-204의 설치 이력을 조회하면 측정 시점의 위치가 가열로 2호기 출구였음을 확인할 수 있습니다. 같은 시각에 진행 중이던 WO-260804-17은 제품 A의 가열 공정이었습니다. 이 조건에 적용되는 문서는 운전 기준서 Rev.3 제4.2항이며 정상 범위는 70~90°C입니다. 따라서 85°C는 정상 범위 내로 판정됩니다.
답변 예시: 가열로 2호기 출구 온도는 85°C로, 측정 당시 유효했던 운전 기준서 Rev.3 제4.2항의 정상 범위(70~90°C)에 포함됩니다. 따라서 해당 시점의 출구 온도는 정상 범위 내입니다. 이 판단은 해당 측정값에 한하며 설비 건전성이나 제품 품질 전체를 의미하지는 않습니다.
답변과 함께 측정 원천, 작업지시, 기준 버전과 유효기간을 남겨야 나중에 같은 결론을 재현할 수 있습니다. 측정 사실, 승인된 기준, 두 값을 비교해 얻은 판단도 서로 구분해 기록합니다.
사례 2. 91°C라면 어디까지 실행할 수 있는가
값만 91°C로 바꾸면 작업과 기준은 같고 비교 결과만 달라집니다. 상한인 90°C를 1°C 초과했으므로 결과는 정상 범위 초과입니다. 현장 답변은 초과 사실뿐 아니라 즉시 가능한 조치와 승인이 필요한 조치를 나눠 보여 주어야 합니다.
| 후속 행위 | 통제 방식 | 처리 범위 |
|---|---|---|
| 이상 알림·판정 기록 | 사전 승인된 자동 행위 | 업무 시스템에 자동 연계 가능 |
| 점검 요청 생성 | 담당자 권한과 중복 여부 확인 | 요청 초안 생성 후 확인 |
| 생산 중지·설비 제어 | 관리자 승인과 제어 권한 필요 | 승인 요청까지만 생성 |
AI가 초과를 설명했다고 해서 곧바로 설비를 멈추는 것은 아닙니다. 권한 판정은 IAM이, 승인 절차는 워크플로가, 실제 조작은 제어 시스템이 담당합니다. 온톨로지는 해당 행위에 어떤 조건과 책임이 연결되는지를 표현해 이들 시스템이 같은 의미를 참조하도록 돕습니다.
사례 3. 과거의 85°C를 다시 판정한다면
2026년 9월 12일에 8월 4일의 측정값을 다시 확인한다고 가정해 보겠습니다. 질문한 날에는 Rev.4가 유효하지만, 판정 대상이 된 측정은 Rev.3의 유효기간에 발생했습니다.
| 기준 | 유효기간 | 정상 범위 | 8월 4일 85°C |
|---|---|---|---|
| Rev.3 | 2025-11-01~2026-08-09 | 70~90°C | 정상 범위 내 |
| Rev.4 | 2026-08-10 이후 | 75~82°C | 해당 시점 미적용 |
최신 문서만 검색해 Rev.4를 적용하면 과거에는 정상이었던 값이 기준 초과로 바뀝니다. 따라서 기준 문서는 버전뿐 아니라 유효기간과 적용 대상까지 구조화해야 합니다. 과거 판정에는 당시 기준을 적용하고, 필요하다면 현재 기준으로 본 참고 결과를 별도로 제시합니다.
사례 4. 원인을 확정하지 않고 후보를 좁힌다
91°C가 발생한 원인을 묻는 질문은 단순 범위 비교보다 어렵습니다. 온톨로지와 검색 구조는 같은 시간대의 공정 변수, 설비 상태, 정비 이력과 작업 변경을 연결해 볼 수 있게 하지만 원인을 확정하지는 않습니다. AI는 근거가 있는 후보를 제시하되, 각 후보를 반박하거나 확인할 자료를 함께 요구해야 합니다.
| 연결된 사실 | 가능한 해석 | 확인·반증 자료 |
|---|---|---|
| 연료 유량이 기준 상단에 근접 | 가열 조건에 영향을 주었을 가능성 | 유량계 신뢰도, 제어 명령 |
| 배기 댐퍼 개도 저하 | 열 배출 조건이 달라졌을 가능성 | 구동부 상태, 이벤트 로그 |
| TS-204 교정기한 임박 | 실제 과열이 아닌 측정 오차 가능성 | 기준계 비교 측정 |
| 직전 작업의 레시피 변경 | 목표 온도나 제어 조건 변경 가능성 | 변경 승인, 실제 적용 시점 |
지지 근거만 모으면 AI는 쉽게 그럴듯한 원인 이야기를 만듭니다.
특히 센서 교정 이력이 빠지면 실제 과열이 아닌 측정 오류를 놓칠 수 있습니다. 원인 분석에서는 “무엇이 원인처럼 보이는가”와 함께 “어떤 자료가 나오면 이 가설을 버릴 것인가”를 묻는 편이 안전합니다.
영향 로트 추적과 점검 요청은 같은 흐름의 확장입니다
이상 구간이 2026년 8월 4일 14:05~14:18이었다면, 질의 엔진은 가열로 2호기의 작업 이력과 시간 중첩을 먼저 확인합니다. 이후 실제 투입·체류·배출 이력과 로트 추적 정보를 조회해 영향 검토 대상을 좁힙니다. 다만 시간대가 겹쳤다는 사실만으로 해당 로트를 불량으로 판정할 수는 없습니다. 최종 품질 판정에는 별도의 검사 결과와 품질 기준이 필요합니다.
점검 요청도 같은 판정 근거에서 시작하지만 실행 절차는 별개입니다. 기존 요청의 중복 여부, 적용 절차와 점검 항목, 담당자와 우선순위, 승인권자를 확인한 뒤 허용된 범위에서 요청을 생성합니다. 생성된 요청 번호와 수행 결과를 최초 이상 사건에 다시 연결하면, 판단에서 조치까지의 이력을 한 흐름으로 추적할 수 있습니다.
3. 정보가 부족할 때는 답을 늦춰야 합니다
사용자가 “85는 정상인가?”라고만 물으면 대상, 항목, 단위, 위치, 시점과 작업을 알 수 없습니다. 이때 AI가 비슷한 문서를 찾아 임의의 기준을 붙이면 안 됩니다. “어느 설비의 어떤 항목을 언제 측정한 값인가요?”라고 되물어야 합니다.
누락 정보에 따라 상태도 구분할 필요가 있습니다. 설비·항목·단위·시점은 확인됐지만 당시 제품을 모른다면 측정값의 의미는 알 수 있어도 적용 기준은 고를 수 없습니다. 이 경우에는 단순한 ‘판단 불가’보다 ‘적용 기준 확인 필요’라고 알려 주는 편이 사용자가 다음에 무엇을 보완해야 하는지 분명합니다.
4. 구현에서 자주 놓치는 선택
이 사례를 실제 시스템으로 옮길 때 가장 먼저 부딪히는 문제는 모델의 크기가 아니라 식별자와 시간입니다. 센서 이력의 설비 코드, MES의 작업 코드, 기준 문서의 공정명이 서로 다르면 같은 대상을 가리켜도 연결되지 않습니다. 센서 시각과 MES 시각의 기준이 다르면 이상 구간과 작업 이력이 어긋날 수도 있습니다.
그래서 처음부터 모든 제조 데이터를 온톨로지에 담기보다 한 공정과 몇 개의 핵심 질문부터 검증하는 방식이 현실적입니다. 예를 들어 ① 설비·센서·작업·기준의 식별자 매핑, ② 기준의 유효기간과 적용 범위, ③ 판정 결과에서 원천 데이터와 조항으로 돌아가는 근거 경로를 먼저 확인합니다. 이 세 가지가 안정된 뒤 영향 로트 추적이나 점검 요청으로 범위를 넓히는 편이 운영 리스크를 줄일 수 있습니다.
또한 시간 중첩만으로 이상 구간에 포함된 로트를 불량으로 단정해서는 안 됩니다. 중첩된 작업은 영향 검토 후보일 뿐이며, 실제 투입·체류·배출 이력과 별도의 품질 기준을 추가로 확인해야 합니다. 이처럼 각 단계의 결과를 ‘확정’, ‘후보’, ‘추가 확인 필요’로 구분해 두면 AI의 설명도 과도한 확신에서 벗어날 수 있습니다.
5. 모비젠이 지향하는 구현 원칙
이 글의 사례는 제조 온톨로지의 활용 방식을 설명하기 위한 가상 시나리오입니다. 따라서 특정 프로젝트의 구축 성과로 소개하기보다, 데이터 통합과 의미 모델, AI 활용을 하나의 업무 흐름으로 연결할 때 필요한 구현 원칙으로 보는 것이 적절합니다.
모비젠은 설비·센서·MES·작업지시·기준 문서를 연결하고, 기준의 적용 범위와 유효기간, 출처와 권한을 구조화하는 접근을 지향합니다. AI는 이 구조를 바탕으로 필요한 정보를 찾고 설명하며, 질의·규칙·워크플로 구성요소는 판정과 후속 업무를 각자의 책임 범위에서 수행합니다.
중요한 것은 거대한 모델을 한 번에 만드는 일이 아닙니다. 서로 다른 데이터가 같은 현장을 가리키는지, 판정이 승인된 기록과 실행으로 이어지는지, 문제가 생겼을 때 사용한 근거를 다시 찾을 수 있는지를 작은 범위에서 검증하고 확장해야 합니다.
맺음말
화면에 보이는 85라는 숫자는 그 자체로 정상도 이상도 아닙니다. TS-204의 측정 사건, 가열로 2호기 출구라는 위치, 제품 A의 작업지시, 당시 유효했던 Rev.3 제4.2항이 연결된 뒤에야 정상 범위 내라는 판단이 가능합니다.
제조 온톨로지의 역할은 이 의미와 관계를 일관되게 제공하는 것입니다. 실제 탐색과 판정, 승인과 실행은 별도의 엔진과 업무 시스템이 나눠 맡습니다. 이 역할 구분이 분명할수록 AI의 답변은 그럴듯한 설명을 넘어, 근거를 확인할 수 있고 현장 업무로 안전하게 이어지는 답변에 가까워집니다.