들어가며
현장 화면에 85라는 값이 떠 있습니다. 이 값이 정상인지 묻는 순간, 숫자만으로는 답할 수 없다는 사실이 드러납니다. 온도인지 압력인지, 어느 설비의 어느 위치에서 측정했는지, 그때 어떤 제품을 생산하고 있었는지부터 확인해야 합니다. 정상 범위를 적어 둔 기준서와 그 버전도 찾아야 합니다.
제조기업에는 이미 이런 정보가 충분히 쌓여 있습니다. 문제는 양이 아닙니다. 센서 이력, 설비 마스터, 생산 실적, 작업지시, 기준 문서가 서로 다른 방식으로 같은 현장을 기록하고 있다는 데 있습니다.
이 연재의 설비명·식별자·수치·기준서는 온톨로지의 작동 방식을 설명하기 위한 가상 사례입니다.
이 연재는 다음 질문을 세 편에 걸쳐 다룹니다.
가열로 2호기 출구 온도 85°C는 현재 작업 기준에서 정상인가요? 판단 근거와 필요한 조치도 알려주세요.
| 편 | 제목 | 다루는 것 |
|---|---|---|
| 1부 | 값 하나가 판단이 되려면 무엇이 필요한가 | 85가 판단 가능한 데이터가 되기 위한 조건 |
| 2부 | 질문에서 구조로 — 85°C를 설계하다 | 온톨로지 설계와 실제 데이터·기준 연결 |
| 3부 | 판단에서 실행으로 — AI가 85°C에 답하는 방식 | AI의 답변과 통제된 후속 업무 |
1. 85만으로는 판단할 수 없습니다
85에 온도라는 항목과 °C라는 단위를 붙이면 측정값이 됩니다. 여기에 가열로 2호기 출구, TS-204, 2026년 8월 4일 10시 30분이라는 정보가 붙으면 하나의 측정 사건을 설명할 수 있습니다. 그래도 정상 여부는 아직 알 수 없습니다. 당시 생산하던 제품과 공정, 작업지시, 그 조건에 유효했던 기준까지 이어져야 비로소 판단할 수 있습니다.
공통 사례의 맥락은 다음과 같습니다.
| 구성 요소 | 값 |
|---|---|
| 업무 대상 | 가열로 2호기 (설비 마스터 FURNACE-02) |
| 측정 위치·항목 | 가열로 출구 온도 |
| 측정값·단위 | 85°C |
| 측정 시점 | 2026-08-04 10:30 |
| 센서·원천 | TS-204 (사내 센서 식별자) |
| 작업 맥락 | 제품 A 가열 공정 (WO-260804-17) |
| 적용 기준 | 운전 기준서 Rev.3 제4.2항 (유효 2025-11-01 ~ 2026-08-09) |
| 정상 범위 | 70°C 이상 90°C 이하 |
| 기대 판정 | 정상 범위 내 |
같은 85°C라도 제품과 공정, 측정 위치, 적용 시점이 달라지면 판정도 달라질 수 있습니다.
같은 값도 어느 시점의 기준을 쓰느냐에 따라 달라집니다
| 시간축 | 의미 | 공통 사례 |
|---|---|---|
| 사건 발생 시점 | 현실에서 그 일이 일어난 때 | 측정 2026-08-04 10:30 |
| 기준 유효기간 | 그 기준이 효력을 갖는 기간 | Rev.3 유효 2025-11-01 ~ 2026-08-09 |
| 기록 시점 | 시스템에 입력·수정된 때 | 적재 10:30:07 |
판정에는 세 가지 시간이 관여합니다. 측정이 발생한 시점, 기준서가 효력을 갖는 기간, 데이터가 시스템에 기록된 시점은 서로 다릅니다. 이 셋을 한 날짜로 다루면 “지금 기준으로 다시 보면 어떤가”와 “당시 기준으로 올바르게 처리했는가”가 뒤섞입니다. 기준서가 개정된 뒤 과거 데이터를 조회할 때 특히 문제가 됩니다.
시스템은 같은 사건을 각자의 언어로 기록합니다
센서 이력 DB는 TS-204가 85°C를 측정했다고 기록하고, 설비 마스터는 FURNACE-02가 가열로 2호기다라고 식별합니다. MES는 당시 제품 A의 가열 공정이 진행 중이었다는 사실을, 작업지시는 그 작업이 WO-260804-17이었다는 맥락을, 문서 시스템은 운전 기준서 Rev.3 제4.2항이 해당 조건에 적용된다는 근거를 보유합니다.
문제는 이 기록들이 한곳에 있지 않다는 데 있습니다. 센서값만 조회하면 작업을 알 수 없고, 작업지시만 봐서는 실제 측정값을 알 수 없습니다. 기준서에는 정상 범위가 적혀 있지만 어느 측정 사건에 적용해야 하는지는 시스템이 스스로 판단하지 못합니다.
온톨로지는 이 사이에 경로를 만듭니다. TS-204의 측정 사건에서 출발해 측정 당시의 설치 위치를 찾고, 같은 시점에 진행 중이던 작업과 제품·공정을 확인한 뒤, 그 조건에 유효한 기준으로 이어지는 경로입니다. 사람이 조회할 때마다 머릿속으로 조립하던 관계를 시스템이 따라갈 수 있는 형태로 드러내는 것입니다.
제조 온톨로지는 제조기업의 핵심 대상, 상태, 사건, 관계, 기준과 근거를 일관된 언어로 정의하고 실제 데이터와 연결하는 공통 의미 체계입니다.
이 관점은 기존 표준의 개념 구조와 연결할 수 있습니다
| 이 연재의 개념 | 참고할 수 있는 표준 개념 |
|---|---|
| 제품·공정·설비·작업의 계층 | ISA-95 / IEC 62264 |
| 센서·측정 사건·관측값 | W3C SOSA/SSN |
| 출처·근거·생성 이력 | W3C PROV-O |
| 유효 시점·기간 | OWL-Time |
| 설비 자산의 디지털 표현 | Asset Administration Shell (IEC 63278) |
참고 표준
- ISA-95는 제품·설비·공정·작업처럼 제조 운영에서 관리해야 할 대상을 구조화할 때 참고할 수 있는 국제표준입니다.
- SOSA/SSN은 센서, 관측 대상, 관측 행위, 결과와 시간을 표현하는 W3C·OGC 온톨로지입니다.
hasSimpleResult는85와 같은 단순 값을,resultTime과phenomenonTime은 각각 결과가 생성된 시점과 관측 현상이 적용되는 시간을 나타냅니다.- PROV-O는 데이터와 판단이 어떤 활동·자료에서 생성되거나 파생되었는지를 기록하는 W3C 출처 이력 모델입니다. 이 사례에서는 측정 기록, 점검·승인 활동, 판단 근거를 추적하는 데 활용할 수 있습니다.
- OWL 2의 오브젝트 프로퍼티는 설비와 공정처럼 개체 사이의 관계를 표현합니다. 측정값·문자열·시각과 같은 리터럴 값은 데이터 프로퍼티로 구분합니다.
이 표준들을 그대로 가져오는 것이 목적은 아닙니다. 필요한 개념과 관계만 선택해 제조 업무의 용어·규칙·권한 모델과 연결하는 방식으로 사용합니다.
이 사례에서 85를 독립된 개념으로 두지 않고 TS-204가 수행한 측정의 결과로 다루는 방식은 SOSA/SSN의 관측 모델과 맞닿아 있습니다. 이런 대응 관계를 미리 밝혀 두면 다른 시스템이나 협력사 데이터와 연결할 때 같은 개념을 다시 해석하는 일을 줄일 수 있습니다. 다만 표준의 개념을 참고했다는 것과 해당 표준을 준수한다는 것은 별개의 문제입니다.
2. 데이터는 있는데 왜 답은 바로 나오지 않을까
현장에서 필요한 데이터는 대개 이미 존재합니다. 그런데도 질문 하나에 답하려면 여러 담당자가 자료를 모아야 합니다. 시스템마다 대상을 나누고 식별하는 기준이 다르기 때문입니다.
설계 시스템은 제품과 도면을 중심으로 보고, 생산 시스템은 작업지시와 실적을 중심으로 봅니다. 품질 시스템에는 검사와 불량이, 설비 시스템에는 자산과 정비 이력이 쌓입니다. 각 시스템의 기록은 자기 업무 안에서는 맞습니다. 다만 TS-204=85, FURNACE-02, 제품 A 가열 작업, Rev.3이 같은 상황을 설명한다는 연결은 어디에도 온전히 적혀 있지 않습니다.
이름도 믿을 수 있는 연결 키가 아닙니다. 같은 이름의 설비가 여러 공장에 있을 수 있고, 하나의 설비가 시스템마다 다른 코드와 명칭으로 기록되기도 합니다. 필요한 것은 문자열 일치가 아니라 두 레코드가 현실의 같은 대상을 가리키는지 확인하는 일입니다. 이 확인이 빠지면 설비 이상, 정비 이력, 생산 작업, 품질 결과를 한 사건으로 묶을 근거도 사라집니다.
DB와 문서의 역할도 다릅니다. DB에는 대개 무엇이 발생했는지가 남고, 문서에는 어떻게 판단하고 조치해야 하는지가 적혀 있습니다. 센서 이력에서 85°C를 찾았다고 해서 정상 여부까지 알 수 없는 이유입니다. 70°C 이상 90°C 이하라는 범위와 후속 조치는 승인된 기준서에서 찾아야 하고, 그 기준서가 당시 작업에 적용됐다는 사실도 확인해야 합니다.
여러 원천이 충돌하면 어느 기록을 따를지도 정해야 합니다. 최신 정보가 언제나 우선하는 것은 아닙니다. 설계 승인본, 현장 실적, 품질 판정, 임시 작업지시는 각기 다른 책임과 권위를 가집니다. 시스템이 우선순위를 결정할 근거가 없다면 결과는 전문가 검토 필요로 남겨야 합니다.
저장소를 하나로 합치는 것만으로는 충분하지 않습니다. 같은 장소에 모인 데이터도 무엇을 가리키는지, 서로 어떤 관계인지 합의돼 있지 않으면 함께 쓸 수 없습니다. 온톨로지는 이 의미 관계를 정의합니다.
3. AI는 어디까지 맡을 수 있을까
AI는 문서와 데이터에서 용어와 관계 후보를 추출할 수 있습니다. 그렇다면 온톨로지도 자동으로 만들 수 있을까요? 후보 추출이 가능한 범위는 넓지만, 그 후보를 기업의 공식 의미로 확정하는 일은 다른 문제입니다.
| 구분 | 내용 |
|---|---|
| AI가 잘하는 일 | 반복되는 업무 용어와 표현 찾기 |
| 동의어·약어·문맥 차이의 후보 제시 | |
| 제품·공정·설비·문서 사이의 관계 후보 발견 | |
| 기존 온톨로지와 신규 자료의 변경점 비교 | |
| 검증 질문과 예외 사례의 후보 생성 | |
| 전문가가 결정할 일 | 어떤 대상을 독립적인 업무 개념으로 볼 것인가 |
| 서로 다른 시스템의 기록을 동일한 대상으로 볼 수 있는가 | |
| 상충하는 기준 중 무엇이 우선하는가 | |
| 판단과 실행의 책임은 누구에게 있는가 | |
| 어떤 수준의 불확실성을 업무에서 허용할 것인가 |
예를 들어 AI는 센서 명세와 작업표준을 읽고 TS-204, 가열로 출구 온도, 70°C 이상 90°C 이하, 제품 A를 찾아낼 수 있습니다. 반복되는 표현을 묶고 관계 후보도 제안할 수 있습니다. 하지만 FURNACE-02와 가열로 2호기를 같은 설비로 확정하거나, 충돌하는 두 문서 가운데 하나를 우선 기준으로 삼는 결정에는 업무 책임이 따릅니다. 이 결정은 문장 유사도만으로 내릴 수 없습니다.
AI가 만든 후보에는 원천과 해석 이유, 신뢰 수준, 검토 상태가 함께 남아야 합니다. 그래야 전문가는 처음부터 자료를 다시 읽지 않고도 무엇을 확인해야 하는지 판단할 수 있습니다. 검토를 통과하지 않은 후보가 공식 온톨로지에 섞이지 않도록 관리하는 절차도 필요합니다.
맺음말
센서값의 정상 여부를 판정하려면 설비, 위치, 작업, 제품, 기준, 시점이 함께 연결돼야 합니다. 제조기업에는 이 데이터가 이미 있지만, 같은 현장을 설명하는 하나의 맥락으로 연결되어 있지 않습니다.
AI는 흩어진 용어와 관계 후보를 빠르게 찾을 수 있습니다. 그 후보를 회사가 믿고 사용할 수 있는 의미로 확정하는 일은 현장을 아는 전문가의 몫으로 남습니다.
2부에서는 이 연결 관계를 온톨로지 구조로 설계합니다.