중공업 프로젝트의 가장 큰 위험은 데이터가 없다는 데 있지 않다. 오히려 같은 장비와 라인이 P&ID, 장비 목록, 데이터시트, 견적 Excel, 제작도면에서 조금씩 다르게 존재한다는 데 있다. 문서는 많고 검토도 반복하지만, 어느 표현이 같은 객체를 가리키는지 연결되지 않으면 불일치는 조달과 제작, 시운전 단계까지 이동한다.
P&ID에는 P-2101, 장비 목록에는 P-2011
프로세스 설계가 진행되는 동안 냉각수 펌프의 태그가 P-2011에서 P-2101로 변경되었다고 하자. P&ID와 최신 데이터시트에는 새 태그가 반영됐지만, 장비 목록의 일부 행과 견적 Excel, 모터 데이터시트에는 이전 태그가 남아 있다. 사람은 명칭과 용량, 연결 라인을 보고 같은 장비라고 추정하지만 시스템은 서로 다른 항목으로 인식할 수 있다.
이런 불일치는 단순 오탈자가 아니다. 장비가 중복 발주되거나, 검사 기록이 잘못된 태그에 연결되고, 시운전 체크리스트에서 누락될 수 있다. 더 위험한 경우는 태그는 같지만 용량, 재질, 설계압력, Hazardous Area 등급 같은 핵심 속성이 다른 경우다.
파일별로 장비를 대조함
객체 중심으로 문서를 비교함
문서는 객체의 여러 뷰다
P&ID는 프로세스 기능과 연결을 표현한다. Equipment List는 프로젝트 관리와 설계 속성을 표로 정리한다. Datasheet는 구매와 공급사 협의를 위한 상세 사양을 담고, GA와 배치도는 위치와 유지보수 공간을 보여준다. 제작도면과 검사기록은 실제 생산과 품질 상태를 담는다.
이 문서들은 서로 경쟁하는 파일이 아니라 하나의 장비를 다른 목적에서 표현하는 뷰다. 따라서 중앙 데이터 계층이 모든 문서를 대체할 필요는 없다. 대신 장비 객체를 중심으로 각 문서의 근거 영역과 속성을 연결해야 한다. 문서마다 책임 있는 속성도 다르게 지정할 수 있다.
불일치는 다섯 가지로 나누어야 한다
모든 차이를 같은 오류로 처리하면 검토자가 경고에 지친다. 첫째는 식별자 불일치다. 태그, 라인 번호, 문서 번호가 다르다. 둘째는 속성 불일치다. 용량, 재질, 압력, 전원과 등급이 다르다. 셋째는 관계 불일치다. 연결 라인이나 밸브, 계기와의 관계가 다르다. 넷째는 상태 불일치다. 한 문서는 Approved인데 다른 문서는 Draft다. 다섯째는 개정 불일치다. 값은 같아 보여도 서로 다른 기준선을 사용한다.
각 유형은 해결 방법이 다르다. 태그 불일치는 매핑과 개정 이력으로 해결할 수 있지만, 설계압력 차이는 프로세스·배관·기계 담당자의 판단이 필요하다. 상태 불일치는 문서관리와 발행 절차 문제일 수 있다. AI는 차이를 찾는 데 도움을 줄 수 있지만, 업무 위험에 따라 적절한 책임자에게 보내야 한다.
AI는 문서를 읽되, 객체 매칭은 증거를 남겨야 한다
P&ID와 데이터시트, 표준 목록은 형식이 다양해 규칙만으로 파싱하기 어렵다. VLM과 문서 AI는 태그와 심볼, 표의 헤더와 값을 추출하고 문서 간 후보를 찾는 데 유용하다. 특히 OCR이 어려운 스캔 도면, 공급사별로 다른 데이터시트, 약어와 표기 차이를 다루는 데 장점이 있다.
하지만 “같은 장비일 확률 96%”라는 점수만으로 자동 병합해서는 안 된다. 시스템은 태그 유사도, 공정 라인 연결, 용량, 위치, 문서 참조와 개정 이력을 근거로 보여줘야 한다. 확정된 매핑은 프로젝트 용어 사전과 Rename History에 남고, 다음 문서 처리에서 재사용된다.
어느 문서가 맞는지 시스템이 임의로 정하면 안 된다
사양 충돌을 발견한 뒤 가장 어려운 질문은 어느 값이 맞는가다. 일반적으로 P&ID가 프로세스 연결의 원본이고, Datasheet가 장비 사양의 원본이며, 구매 계약은 상업적 기준선이 될 수 있다. 그러나 프로젝트와 단계에 따라 책임이 달라진다.
따라서 속성별 Source of Record 매트릭스가 필요하다. 예를 들어 Design Flow는 Process Datasheet, Nozzle Size는 Mechanical Datasheet, Actual Delivery Date는 ERP, Installed Location은 3D 모델과 현장 As-built가 책임질 수 있다. 중앙 시스템은 이 규칙에 따라 충돌 해결 순서를 제안하되, 계약 변경이나 안전 판단은 담당자가 승인해야 한다.
불일치의 비용은 뒤로 갈수록 커진다
설계 단계에서 발견한 태그 불일치는 몇 분의 수정으로 끝날 수 있다. 구매 발주 후 발견하면 Vendor 문서와 PO 변경이 필요하고, 제작 이후에는 재작업과 납기 지연이 생긴다. 현장 설치 후라면 시운전과 안전 검토까지 영향을 받을 수 있다.
따라서 검토 시스템은 불일치의 기술적 심각도와 함께 프로젝트 상태를 고려해야 한다. 같은 재질 변경이라도 발주 전과 제작 완료 후의 위험은 다르다. 객체의 Lifecycle State와 Effective Date를 연결하면 설계 변경이 실제 비용과 일정에 미치는 영향을 더 정확히 판단할 수 있다.
첫 실증은 P&ID–Equipment List–Datasheet 삼각형이 적합하다
중공업 전체 Digital Thread를 한 번에 구현하기보다, P&ID와 Equipment List, Datasheet의 정합성 검토부터 시작하는 것이 좋다. 태그와 주요 속성이 명확하고, 오류의 업무 가치도 설명하기 쉽다. 실제 프로젝트의 과거 개정과 검토 이력을 이용해 골든셋을 만들 수 있다.
PoC에서는 문서 파싱 정확도만 보지 말고, 객체 매칭 정확도, 속성별 충돌 탐지, 오탐 경고 수, 책임 원본 추천의 적절성, 검토 시간과 누락 감소를 함께 측정해야 한다. 특히 수정 전후 문서와 승인 기록을 사용하면 실제 업무에서 유효한지 검증할 수 있다.
중공업 문서는 파일이 아니라 객체의 증거다
P&ID, 장비 목록과 데이터시트가 서로 다른 진실을 말하는 이유는 문서가 부족해서가 아니다. 같은 장비를 연결하는 식별자와 속성 책임, 개정 관계가 약하기 때문이다. 문서를 객체의 증거로 재구성하면 불일치가 어디서 시작됐고 누가 해결해야 하는지 보이기 시작한다.
다음 글에서는 이 객체가 설계에서 구매, 제작, 검사와 시운전까지 어떻게 이어지는지 살펴본다. Digital Twin이라는 거대한 모델보다 먼저 필요한 것은 끊기지 않는 Digital Thread다.
doAZ Point of View
중공업 문서 AI의 첫 차별화는 OCR이 아니라 Tag-centric Object Graph, Attribute-level Source of Record, Revision-aware Reconciliation을 결합해 실제 불일치를 해결 가능한 작업으로 전환하는 능력임.