2부. 질문에서 구조로 — 85°C를 설계하다

2부에서는 85를 판단하는 데 필요한 맥락을 온톨로지 구조로 옮깁니다. 설계의 시작점은 클래스 목록이나 DB 스키마가 아니라 현장에서 답해야 할 질문입니다.

가열로 2호기 출구 온도 85°C는 현재 작업 기준에서 정상인가요? 판단 근거와 필요한 조치도 알려주세요.

사례에서 사용할 결과는 여섯 가지입니다. 비교가 가능하면 정상 범위 내, 정상 범위 미만, 정상 범위 초과 가운데 하나를 냅니다. 정보가 모자라거나 기준이 충돌하면 억지로 결론을 만들지 않고 판단 불가, 적용 기준 확인 필요, 전문가 검토 필요로 남깁니다.

1. 답해야 할 질문을 먼저 고정합니다

현장의 질문을 그대로 모델 이름으로 옮기면 가열로 2호기, TS-204, 제품 A에만 맞는 구조가 되기 쉽습니다. 다른 설비와 공정에도 같은 방식을 쓰려면 질문이 요구하는 조건을 한 단계 일반화해야 합니다. 이때 사용하는 것이 역량 질문(Competency Question, CQ)입니다.

기본 CQ: 특정 설비의 특정 위치에서 측정된 값이 측정 당시의 제품·공정·작업 조건에 적용되는 정상 범위에 포함되는지 판단하고, 적용 기준과 원천 근거 및 필요한 후속 조치를 제시할 수 있는가?

이 CQ를 풀어 보면 온톨로지에 필요한 범위가 드러납니다. 측정값과 센서만 있어서는 부족합니다. 센서의 설치 위치, 측정 시점의 작업, 제품과 공정, 그 조건에 유효한 기준, 판정 뒤에 허용되는 조치가 함께 있어야 합니다. 조직별 시스템 경계가 아니라 질문에 답하는 데 필요한 경로를 따라 범위를 잡는 방식입니다.

결과 형식도 이 단계에서 정해 둡니다. 정상 범위 내라는 판정만 반환할지, 적용한 조항과 측정 원천, 판단 범위, 후속 조치까지 보여 줄지에 따라 필요한 구조가 달라지기 때문입니다. 품질이나 안전과 관련된 질문이라면 판정 자체보다 근거를 다시 확인할 수 있는지가 더 중요할 때도 많습니다.

업무 판정: 정상 범위 내
판단 값: 85°C
적용 범위: 제품 A · 가열 공정 · 가열로 출구
적용 기준: 70°C 이상 90°C 이하
근거: 운전 기준서 Rev.3 제4.2항 (유효 2025-11-01 ~ 2026-08-09)
원천: TS-204, 2026-08-04 10:30
후속 조치: 운전 이력 기록

위 항목이 CQ가 요구하는 최소 출력입니다. 우선 이 답을 일관되게 만들 수 있는지 확인한 뒤 범위를 넓혀야 합니다. 85°C의 정상 여부를 보여 주는 모델과 판정·알림·점검·조치 결과까지 기록하는 모델은 필요한 개념과 책임 범위가 다릅니다. CQ에는 조회 항목과 업무의 종료 지점을 함께 담습니다.

2. 85를 클래스로 만들지 않는 이유

자료를 읽다 보면 제품명, 설비명, 센서명, 온도, 기준, 점검, 승인처럼 수많은 명사가 나옵니다. 이를 모두 클래스로 만들면 모델은 금세 커집니다. 하지만 커진 만큼 설명력이 좋아지는 것은 아닙니다. 먼저 각 표현이 업무 대상인지, 측정의 속성인지, 사건인지, 기준인지, 행위인지를 나눠야 합니다.

이 구분에 따르면 85는 클래스가 될 이유가 없습니다. TS-204가 10시 30분에 수행한 온도 측정이 하나의 사건이고, 85는 그 사건에서 나온 결과값입니다. 가열로, 센서, 제품, 공정, 기준 문서는 다른 측정과 작업에서도 계속 참조되므로 각각 식별 가능한 대상으로 둡니다.

공통 사례의 최소 의미 구조

공통 사례는 세 묶음으로 구성됩니다. 현장 사실에는 TS-204가 2026-08-04 10:30에 85°C를 측정했다는 사건과 당시 센서가 가열로 2호기 출구에 설치돼 있었다는 이력이 들어갑니다. 작업 맥락에서는 같은 시점의 작업지시 WO-260804-17을 찾아 제품 A, 가열 공정, 사용 설비를 확인합니다. 적용 기준과 판단에서는 이 제품·공정·위치·시점에 맞는 Rev.3 제4.2항을 선택하고, 측정값을 70°C 이상 90°C 이하의 범위와 비교합니다.

세 묶음은 비교 단계에서 만납니다. 측정 사실이 작업지시를 거쳐 기준값으로 변하는 일렬 구조가 아닙니다. 한쪽에서는 무엇을 얼마로 측정했는지를 가져오고, 다른 쪽에서는 작업 맥락을 이용해 적용할 기준을 고릅니다. 두 근거를 비교한 결과가 정상 범위 내 판정입니다.

이 구조에서는 측정값이 사건에서 떨어져 떠다니지 않고, 기준 조항도 PDF 속 문장으로만 남지 않습니다. 조항에는 어떤 제품과 공정, 위치, 기간에 적용되는지가 붙습니다. 설비나 제품이 바뀌어도 같은 경로를 다시 사용할 수 있는 이유가 여기에 있습니다.

관계 이름도 구체적으로 적습니다. 관련 있음으로 연결하면 사람이 보기에는 그럴듯해도 시스템은 어떤 방향으로 탐색해야 할지 알 수 없습니다. TS-204는 가열로 2호기 출구에 설치됨, Rev.3 제4.2항은 제품 A의 가열 공정과 출구 위치에 적용됨 정도로 관계의 뜻이 드러나야 합니다.

문서 역시 파일인 동시에 지식의 근거입니다. 운전 기준서 Rev.3은 단순한 PDF 파일로만 취급되는 것이 아니라, 제품 A·가열 공정·가열로 출구에 적용되는 승인된 지식의 근거로 연결됩니다. 제4.2항은 70°C 이상 90°C 이하 판단의 직접 근거입니다.

3. 각 시스템의 기록을 의미 구조에 연결합니다

각 원천 레코드를 온톨로지 개념에 대응시킵니다. 데이터를 한 저장소로 복사하는 일이 아니라, 원천의 레코드가 온톨로지에서 무엇을 뜻하는지 정하는 작업입니다.

매핑에서는 코드만 맞춰 보지 않습니다. 같은 코드가 공장마다 중복될 수도 있고, 시스템 개편으로 하나의 설비가 여러 코드를 가질 수도 있습니다. TS-204도 현재 출구에 설치돼 있다는 정보만으로는 과거 측정을 설명할 수 없습니다. 측정이 발생한 시점에 그 위치에 있었는지를 설치 이력으로 확인해야 합니다.

원천 정보는 연결 과정에서 지우지 않습니다. 어느 시스템에서 왔는지, 언제 갱신됐는지, 누가 관리하는지를 남겨야 충돌이 생겼을 때 되짚을 수 있습니다. 여러 원천을 하나처럼 보이게 만드는 것보다, 차이를 유지한 채 같은 업무 관점에서 조회할 수 있게 하는 편이 안전합니다.

모든 시스템의 저장 방식을 바꿀 필요도 없습니다. 사용자가 질문했을 때 같은 의미 경로를 따라갈 수 있으면 됩니다. 다만 정상적으로 잘 채워진 한 건만으로 매핑을 검증하면 실제 문제를 놓칩니다. 단위가 빠진 값, 제품을 알 수 없는 작업, 센서 교체 이력이 끊긴 기간, 동시에 유효해 보이는 두 기준처럼 불완전한 사례를 일부러 넣어 봐야 구조의 약점이 드러납니다.

4. 의미·제약·판단·실행을 나눕니다

기준서에서 조건문을 찾았다고 곧바로 추론 규칙으로 바꾸면 안 됩니다. 문장 안에는 값의 의미, 입력 데이터가 갖춰야 할 조건, 판정 기준, 가능한 행위, 실행 권한이 섞여 있을 수 있습니다. 공통 사례에서는 이를 다음 다섯 층으로 나눴습니다.

의미: 85는 가열로 2호기 출구의 온도 측정값이다.
데이터 제약: 측정값에는 단위·시점·센서·측정 위치가 있어야 한다.
판단 규칙: 제품 A 가열 공정에서 온도가 70°C 이상 90°C 이하이면 정상 범위 내이다.
행위 정의: 기록, 알림, 점검 요청, 승인 요청을 수행 가능한 행위로 정의한다.
실행 정책: 정상 판정은 사전 승인된 운영 규칙에 따라 자동 기록하고, 기준 초과 시 알림은 실행 시스템에 자동 연계하되 점검·중지·제어는 승인 조건을 확인한다.

예를 들어 단위가 빠진 측정은 데이터 제약 위반입니다. 이를 정상 범위 초과 같은 업무 판정으로 처리해서는 안 됩니다. 마찬가지로 초과를 판정하는 규칙과 설비를 중지하는 권한도 한 규칙에 묶을 수 없습니다.

정상 범위에도 적용 조건을 붙입니다. 70°C 이상 90°C 이하만 저장하면 다른 제품이나 위치에도 같은 기준이 적용될 수 있습니다. 이 범위가 제품 A의 가열 공정, 가열로 출구, 해당 기간에 유효하다는 정보가 함께 있어야 합니다.

정보 부족과 부적합은 다릅니다

판단과 실행 사이에는 통제가 필요합니다

91°C를 정상 범위 초과로 판정하는 것과 그 판정으로 생산을 멈추는 것은 책임의 크기가 다릅니다. 이 경계를 모델에서부터 분명히 해 둘 필요가 있습니다.

온톨로지는 어떤 행위가 어떤 조건에서 누구의 승인을 필요로 하는지를 정의하고, 실제 인증·인가와 실행은 IAM·워크플로·제어 시스템이 담당합니다. 온톨로지는 권한 정책이 참조할 조건을 제공할 뿐, 집행을 대신하지 않습니다.

정상 범위 내 판정은 사전 승인된 범위에서 이력 기록으로 연결할 수 있습니다. 반면 91°C처럼 정상 범위 초과인 경우에도 알림은 사전에 승인된 범위에서 실행 시스템에 자동 연계할 수 있지만, 생산 중지나 설비 제어는 별도의 승인 규칙을 따라야 합니다.

제조 현장에서는 평균 정확도가 높다는 이유만으로 모든 실행을 자동화하기 어렵습니다. 드물게 발생한 오판 한 건이 품질 손실이나 설비 정지, 안전 문제로 이어질 수 있기 때문입니다. 자동화 범위는 모델 성능만으로 정할 것이 아니라 판단 근거, 승인 조건, 실패 시 중단 기준을 함께 보고 정해야 합니다.

5. 정상 사례보다 예외로 검증합니다

CQ는 정상값뿐 아니라 경계값, 정보 누락, 기준 충돌로 검증해야 합니다. 공통 사례의 기본 시험은 다음과 같습니다.

아래 후속 조치는 설명을 위해 설정한 예시이며, 실제 적용 시에는 승인된 기준서와 절차서에 정의된 조치를 사용해야 합니다.

70과 90을 시험값에 넣은 이유는 경계의 포함 여부를 확인하기 위해서입니다. 기준 문서에 이상, 이하가 명확하지 않다면 모델이 임의로 보완해서는 안 됩니다. 이 경우에는 현업이 기준 문서를 먼저 정리해야 합니다.

검증 결과가 모델 수정으로 이어지는 과정도 반복됩니다. 질문을 정의할 때는 업무 목적을, 개념을 설계할 때는 용어의 뜻을, 데이터를 연결할 때는 대상의 동일성과 출처를 확인합니다. 구조적으로 모순이 없더라도 현업 기준에 맞는다는 보장은 없으므로 업무 담당자의 확인은 별도로 필요합니다.

6. 기준과 설비가 바뀐 뒤에도 재현하려면

운영이 시작되면 기준과 설비는 계속 바뀝니다. 정상 범위가 70~90°C에서 75~82°C로 개정될 수도 있고, TS-204가 다른 센서로 교체될 수도 있습니다. 그 뒤에도 과거의 85°C를 당시 조건으로 다시 판정하려면 변경 전 정보가 남아 있어야 합니다.

버전은 파일 이름 뒤에 Rev. 번호를 붙이는 수준으로 관리해서는 부족합니다. 과거 판정에 사용한 조항과 센서 설치 상태를 다시 구성할 수 있어야 합니다. 1부에서 나눈 시간축을 데이터 모델에 실제로 반영해야 하는 이유입니다.

측정 시점은 측정 사건에, 기준 유효기간은 기준 조항에 붙습니다. 여기에 시스템이 해당 정보를 언제 입력하거나 수정했는지도 따로 기록하면, 뒤늦게 입력된 데이터와 소급해 바뀐 기준을 구분할 수 있습니다. 업무상 유효시간과 시스템 기록시간을 함께 관리하는 이중 시간(bitemporal) 모델입니다. 품질 감사에서 과거 판정을 재현하려면 이 차이가 실제로 필요합니다.

처음부터 전 공장을 범위로 잡으면 이런 변경과 책임 관계를 한꺼번에 풀어야 합니다. 공정 하나를 골라 데이터 연결, 판정, 실행, 기록이 실제로 이어지는지 확인하고 유사 공정으로 복제하는 편이 현실적입니다. 첫 공정에서 확인한 예외와 운영 규칙은 다음 공정의 설계 자산으로 쓸 수 있습니다.

맺음말

설계의 완성도는 클래스 수가 아니라 CQ에 대한 답으로 평가합니다. 정상값과 경계값, 누락 데이터, 기준 충돌을 입력했을 때 예상한 방식으로 답하거나 판단을 유보해야 합니다.

3부에서는 AI가 이 온톨로지를 이용해 판정하고 후속 업무로 연결하는 과정을 다룹니다.