공통 언어: 표준과 온톨로지

같은 것을 열두 가지로 부르는 조직

월요일 아침 품질 회의. 고객 B사에서 외관 불량 클레임이 들어왔고, 팀장이 "지난 석 달간 스크래치 불량이 몇 건이었지?"라고 묻는다. 품질팀 담당자는 QMS에서 코드 SCR로 조회해 9건이라고 답한다. 생산1팀 파트장은 고개를 갸웃한다. 자기 팀 일보에는 "긁힘"만 18건이 적혀 있기 때문이다. 검사 장비(AOI) 담당자는 장비 로그에 DEF_07이 14건이라고 덧붙인다. 해외 법인 보고서에는 현지어로, 협력사 성적서에는 "표면 손상"으로 적혀 있다. 결국 회의는 "숫자부터 맞춰 오자"로 끝나고, 누군가 사흘 동안 엑셀로 이름을 손으로 맞춘다.

이 장면은 특정 회사의 이야기가 아니다. 팀이 생기고, 시스템이 하나씩 도입되고, 협력사와 고객이 늘어날 때마다 같은 대상을 부르는 이름이 하나씩 늘어난다. 이름이 다르면 집계가 틀어지고(파레토 1위가 바뀐다), 검색이 실패하고(과거 사례를 "긁힘"으로 찾으면 "SCR" 보고서는 안 나온다), AI 학습 데이터가 오염된다(같은 불량이 서로 다른 클래스로 라벨링된다).

불량명만의 문제가 아니다. 아래 표는 한 공장 안에서 실제로 흔히 마주치는 "같은 대상, 다른 표기"의 유형이다(값은 예시).

직접 해 보기: 열두 개의 이름을 정준 코드로

아래 실습에는 여러 팀과 시스템에서 모은 불량 이름 12개와 지난 분기 발생 건수가 있다. 각 이름 옆의 단서(장비 매뉴얼, 사진 확인 결과 등)를 보고 정준 코드를 골라 보자. 매핑이 진행될수록 오른쪽 "매핑 후" 파레토가 어떻게 바뀌는지 보라. 먼저 자동 매핑(문자열 유사도) 버튼을 눌러 보면, 글자 모양만으로 맞추는 방식이 어디서 틀리는지도 확인할 수 있다.

기준정보, 용어 사전, 코드 체계, 데이터 사전

공통 언어를 만드는 도구는 네 가지가 서로 맞물려 있다. 이름이 비슷해 자주 혼동되므로 먼저 구분해 두자.

넷은 위에서 아래로 연결된다. 용어 사전이 "스크래치란 길이가 폭의 3배 이상인 선형 흠집"이라고 뜻을 정하면, 코드 체계가 그 뜻에 SCR-01이라는 값을 붙이고, 데이터 사전이 "QMS의 DEF_CD 열은 이 코드 체계를 따른다"고 위치를 기록하며, 기준정보가 그 불량이 붙는 품목·설비·고객이 누구인지를 하나로 유지한다.

코드는 "말하는 코드"보다 "조용한 코드"가 오래 간다

LOT ID나 품번에 의미를 잔뜩 넣는 방식을 흔히 스마트 코드(smart code, intelligent numbering)라 부른다. A2603-L2-0412는 "A공장, 26년 3월, 2라인, 412번째"라고 읽힌다. 사람에게는 편하지만, 라인이 재배치되거나 공장이 합쳐지거나 자리수가 모자라면 규칙이 깨진다. 그러면 예외 규칙이 생기고, 예외를 아는 사람만 데이터를 읽을 수 있게 된다.

실무에서 오래 버티는 원칙은 이렇다. ① 식별자는 유일성만 책임지고, ② 공장·라인·날짜 같은 의미는 별도의 속성(열)으로 저장하며, ③ 사람이 읽기 좋은 표시용 번호가 필요하면 식별자와 따로 둔다. 이미 스마트 코드가 깊이 박혀 있다면 당장 바꾸기보다 형식 규칙을 문서화하고 검증 규칙(정규식)으로 강제하는 것부터 시작한다. 이것만으로도 a2603l20412 같은 변형이 데이터에 들어오는 것을 막을 수 있다.

단위와 시간은 "값"의 일부다

엑셀 열 이름이 "두께"뿐이면 그 열에는 언젠가 µm와 mm가 섞인다. 측정기를 교체했거나, 다른 팀이 붙여 넣었거나, 협력사 성적서를 옮겨 적었기 때문이다. 두께 12 µm와 0.012 mm는 같은 값이지만, 숫자만 보면 1000배 차이다. 단위는 열 이름(thk_um)이나 별도 열로 명시하고, 저장 단위는 하나로 정하며(국제단위계 SI, ISO/IEC 80000 계열의 양과 단위 표기를 기준으로 삼으면 논쟁이 줄어든다), 변환은 입력 단계에서 한다. 시간도 마찬가지로, 해외 법인과 설비 로그가 섞이는 순간 시간대가 없는 타임스탬프는 해석 불가능한 숫자가 된다.

ISA-95: 공장을 같은 층위로 부르는 법

공장 사람끼리도 "시스템"이라는 말을 할 때 서로 다른 층을 떠올린다. 설비 엔지니어에게 시스템은 PLC와 HMI이고, 생산관리에게는 MES이며, 경영기획에게는 ERP다. ISA-95(국제표준으로는 IEC 62264, Enterprise-control system integration)는 이 층위를 정리한 표준으로, 기업 업무 시스템과 제조 운영·제어 시스템 사이에 어떤 정보가 오가는지를 공통의 모델과 용어로 정의한다.

ISA-95에서 자주 인용되는 두 가지 그림이 있다. 하나는 기능 계층으로, Level 0(물리적 공정)부터 Level 4(사업 계획·물류)까지 "어떤 일을 어떤 시간 단위로 하는가"를 나눈다. 다른 하나는 설비 계층(역할 기반 설비 계층)으로, Enterprise–Site–Area–Work Center–Work Unit 순서로 "무엇이 무엇에 속하는가"를 나눈다. 두 그림만 공유해도 "MES 데이터"와 "설비 데이터"가 어디서 어디로 흘러야 하는지에 대한 대화가 훨씬 짧아진다.

현장에서 ISA-95가 쓸모 있는 이유는 표준 문서를 그대로 구현해서가 아니라, 이름 붙이는 기준을 주기 때문이다. 설비 ID를 "Site.Area.WorkCenter.WorkUnit"의 계층 경로로 관리하면, "2라인 3호기"와 PR-07과 EQP_L2_P03이 같은 Work Unit의 별칭이라는 것을 한곳에 기록할 수 있다. MES와 ERP 사이의 메시지를 설계할 때도 B2MML(ISA-95 모델을 XML 스키마로 옮긴 구현으로, MESA International이 배포한다) 같은 기존 구현을 참고하면 바퀴를 다시 만들지 않아도 된다.

설비가 스스로 말하게: AAS와 OPC UA 정보 모델

설비 한 대에 대한 정보는 보통 다섯 군데 이상에 흩어져 있다. 명판 사진은 설비팀 공유 폴더에, 사양서 PDF는 구매 메일 첨부에, 운전 데이터는 PLC와 SCADA에, 보전 이력은 엑셀 작업일지에, 매뉴얼은 제조사 웹사이트에 있다. 설비 ID가 통일되어 있지 않으면 이 정보들을 하나로 묶는 것조차 사람의 기억에 의존한다.

자산 관리 셸(AAS, Asset Administration Shell)은 독일 인더스트리 4.0 논의에서 나온 개념으로, 현재 IEC 63278 시리즈로 국제표준화되어 있다. 물리적 자산(설비, 부품, 제품)마다 디지털 "껍데기"를 하나 씌우고, 그 안에 명판·기술 데이터·운전 데이터·문서 같은 정보를 서브모델(submodel) 단위로 정해진 구조에 담는다. 산업 단체(IDTA 등)가 자주 쓰는 서브모델의 템플릿을 공개하고 있어, 회사마다 처음부터 설계하지 않아도 된다.

OPC UA(OPC Unified Architecture, IEC 62541)는 설비와 소프트웨어가 데이터를 주고받는 통신 표준이면서, 동시에 정보 모델을 표현하는 틀이기도 하다. 단순히 "태그 DB10.DBW4의 값 = 1532"를 보내는 것이 아니라, "프레스 객체의 누적 타수 변수, 단위는 회, 형식은 정수"처럼 의미와 구조를 함께 전달한다. OPC 재단과 여러 산업 단체가 함께 장비 종류별 컴패니언 사양(companion specification)을 만들어, 같은 종류의 장비라면 제조사가 달라도 비슷한 구조로 데이터를 노출하도록 하고 있다.

택소노미에서 온톨로지로: 개념–관계–속성

코드 체계를 만들다 보면 자연스럽게 계층이 생긴다. "외관 불량 > 표면 > 선형 > 스크래치". 이렇게 상위–하위 관계로만 분류한 체계를 택소노미(taxonomy, 분류 체계)라 한다. 택소노미는 집계와 탐색에 좋다. 하지만 현장의 질문은 대개 분류보다 관계를 묻는다. "이 스크래치가 어느 설비에서, 어떤 금형으로, 어느 원자재 LOT로 만든 제품에서 났고, 같은 원자재를 쓴 다른 고객 제품은 무엇인가?"

온톨로지(ontology)는 개념(클래스), 개념 사이의 관계, 개념의 속성, 그리고 그것들이 지켜야 할 규칙을 명시적으로 정의한 모델이다. "불량은 LOT에서 발생한다", "LOT는 설비에서 생산된다", "설비는 라인에 속한다", "8D 보고서는 불량을 다룬다"처럼 관계에 이름을 붙인다. 이 정의에 실제 데이터(인스턴스)를 채우면 지식 그래프(knowledge graph)가 된다.

웹 표준 쪽에는 이를 표현하는 형식이 이미 있다. W3C의 RDF(트리플로 사실을 표현), OWL(온톨로지 정의 언어), SKOS(용어 체계·시소러스 표현)가 대표적이다. 하지만 처음부터 형식에 매달릴 필요는 없다. 화이트보드에 핵심 개념 10여 개와 그 사이의 관계를 그리고, 각 관계가 어느 시스템의 어떤 키로 연결되는지 적는 것만으로도 온톨로지 작업의 절반은 끝난다. 이 그래프는 6장에서 다루는 GraphRAG의 뼈대가 된다.

정준 데이터 모델: 매핑의 수학

시스템이 셋일 때는 서로 직접 변환표를 만드는 것이 빠르다. MES와 QMS 사이에 하나, QMS와 ERP 사이에 하나, MES와 ERP 사이에 하나. 그런데 시스템과 팀이 늘어나면 변환표의 수는 빠르게 불어난다. 모든 쌍이 직접 연결되는 점대점(point-to-point) 방식에서 필요한 매핑(양방향 변환표)의 수는 다음과 같다.

\(n=5\)일 때는 둘 다 10개로 같다. \(n=10\)이면 점대점 45개 대 허브 20개, \(n=20\)이면 190개 대 40개다. 그리고 더 중요한 차이는 변경 비용이다. 한 시스템의 코드 체계가 바뀌면 점대점에서는 그 시스템과 연결된 \(n-1\)개의 변환표를 모두 고쳐야 하지만, 허브에서는 그 시스템의 변환 두 개만 고치면 된다.

정준 모델이 만능은 아니다. 모든 시스템의 모든 필드를 담는 "거대한 전사 모델"을 먼저 설계하려다 몇 년을 쓰는 실패가 흔하다. 실무에서는 자주 오가는 핵심 개체(품목, 설비, LOT, 불량, 고객, 작업 지시)만 정준 모델로 정의하고, 나머지는 필요할 때 늘린다. ISA-95의 객체 모델이나 업계 표준 스키마를 출발점으로 삼으면 설계 논쟁을 줄일 수 있다.

공통 언어를 운영하는 법

용어 사전은 만드는 것보다 살려 두는 것이 어렵다. 처음 만들 때는 TF가 꾸려지고 엑셀 파일이 공유되지만, 6개월 뒤 신규 장비가 들어오고 새 고객이 붙으면 아무도 사전을 고치지 않는다. 그러면 사람들은 다시 자기 팀 이름으로 돌아간다. 살아 있는 공통 언어에는 다음이 필요하다.

1. 오너와 스튜어드 지정용어마다 정의의 최종 결정권자(오너, 보통 해당 업무 부서장)와 일상 관리자(스튜어드)를 정한다. "모두의 용어"는 누구의 용어도 아니다.
2. 요청–검토–승인 흐름새 용어·동의어·코드 추가 요청을 받는 창구(양식 하나면 된다)와 검토 주기(예: 격주)를 정한다. 메일로 "이거 추가해 주세요"가 오가면 이력이 사라진다.
3. 시스템에 박아 넣기입력 화면의 드롭다운, 데이터 적재 시 검증 규칙, 검색 동의어 사전이 모두 같은 원본을 바라보게 한다. 사전이 문서로만 존재하면 반드시 낡는다.
4. 버전과 변경 공지코드를 합치거나 쪼갤 때(예: 스크래치를 길이별로 둘로 나눔) 과거 데이터를 어떻게 다시 매핑할지까지 함께 결정하고 공지한다.
5. 사용 지표 보기"기타" 코드 비율, 미매핑 이름 수, 자유 입력 비율을 월별로 본다. "기타"가 늘고 있다면 사전이 현장을 못 따라가고 있다는 신호다.

시작 체크리스트

• 회의에서 숫자가 가장 자주 안 맞는 항목 10개를 골랐다.
• 각 항목의 용어 오너와 스튜어드가 이름으로 정해져 있다.
• 항목마다 정의 한 문장, 정준 코드, 동의어 목록, 헷갈리는 이웃 용어가 적혀 있다.
• 날짜(ISO 8601)·시간대·단위의 저장 규칙이 한 쪽짜리 문서로 공지되었다.
• LOT ID·설비 ID·품번에 형식 검증 규칙(정규식 등)이 있고, 적재 단계에서 검사한다.
• 설비 ID가 ISA-95 설비 계층(Site–Area–Work Center–Work Unit) 경로와 연결되어 있다.
• 신규 설비 구매 사양에 OPC UA 지원과 데이터 항목 정의 제출이 들어가 있다.
• "기타" 코드 비율과 미매핑 이름 수를 매달 본다.