중공업에서 AI의 승부처는 도면을 많이 생성하는 능력이 아니다. 변경 요청을 정확히 이해하고, 허용된 범위 안에서 수정안을 만들며, 계산과 규칙을 통과한 뒤 사람의 승인을 받아 안전하게 반영하는 능력이다. 특히 P&ID와 제작 관련 도면은 자유로운 자동 편집보다 통제된 변경이 먼저다.
왜 자동 생성보다 변경 통제가 먼저인가
새 P&ID를 처음부터 만드는 데모는 인상적이다. 그러나 실제 프로젝트의 대부분은 이미 존재하는 도면과 데이터에 변경을 반영하는 일이다. 태그를 바꾸고, 장비 속성을 수정하며, 심볼을 교체하고, 제한된 배관 연결을 조정한다. 이때 중요한 것은 새 그림이 그럴듯한가가 아니라 기존 기준선과 규칙, 관련 문서가 일관되게 유지되는가다.
무제한 생성형 편집은 두 가지 위험을 만든다. 하나는 AI가 의도하지 않은 요소까지 건드리는 것, 다른 하나는 시각적으로는 자연스럽지만 엔지니어링 규칙을 위반하는 것이다. 따라서 첫 제품은 편집 가능 객체와 명령을 제한하고, 변경 전후를 명확히 비교하며, 승인 전에는 공식 도면을 수정하지 않는 구조가 적합하다.
자유 생성형 도면 편집
통제된 변경 Copilot
변경 요청에서 공식 개정까지의 여덟 단계
사용자가 “P-2101 토출 라인의 Control Valve를 한 단계 상향하고 관련 태그를 갱신해 달라”고 요청했다고 하자. AI는 문장을 곧바로 도면 명령으로 바꾸지 않는다. 먼저 대상 객체와 요청 범위를 해석하고, 최신 기준선과 권한을 확인한다.
그다음 수정 후보를 구조화된 Patch로 만든다. 태그, 심볼 속성, 라인 관계, 관련 목록의 변경을 분리하고, 계산과 규칙을 실행한다. 통과한 결과는 도면 Overlay와 데이터 Diff로 보여주고, 담당자가 승인하면 공식 파일과 개정 이력에 반영한다. 실패하면 원본은 그대로 유지된다.
P&ID·DXF 편집은 제한된 범위에서 시작한다
초기 자동 편집 범위는 명확해야 한다. 태그 문자열과 속성, 승인된 심볼 라이브러리의 교체·추가·삭제, 속성 블록 갱신, 제한된 직교 배관 연결, 목록과 도면 번호 참조 정도가 현실적이다. 자유곡선과 복잡한 레이아웃 재배치, 다중 Discipline 상세 설계는 뒤로 미루는 편이 낫다.
DXF 같은 벡터 형식에서는 각 엔티티의 Layer, Block, Attribute, Handle과 연결 관계를 보존해야 한다. 편집 엔진은 AI가 직접 좌표를 무작위 생성하는 방식이 아니라, 규칙 기반 Geometry Operation과 승인된 심볼 템플릿을 사용해야 한다. AI는 “무엇을 바꿀지”를 제안하고, 실제 도형 수정은 결정론적 엔진이 수행한다.
Geometry·Rule Engine
같은 입력이면 같은 결과를 내고, 기준과 단위를 명시적으로 통제함.
AI Change Planner
문서와 도면의 맥락을 읽고, 근거와 변경 영향을 사람이 이해할 수 있게 연결함.
Patch를 공식 언어로 만들 것
AI의 출력이 곧바로 수정된 파일이어서는 안 된다. 먼저 사람이 읽고 시스템이 검증할 수 있는 변경 Patch가 있어야 한다. Patch에는 대상 객체, 현재값, 제안값, 변경 이유, 관련 객체, 필요한 규칙, 예상 문서 영향과 승인 역할이 포함된다.
예를 들어 `ReplaceSymbol`, `UpdateAttribute`, `ReconnectLine`, `CreateTag`, `RetireTag`, `UpdateListRow` 같은 제한된 명령을 정의할 수 있다. 각 명령은 사전조건과 사후조건을 갖는다. 현재 개정과 객체 Handle이 일치하지 않으면 적용하지 않고, 적용 후에는 연결성과 태그 유일성을 검사한다.
검증은 도면 규칙과 공학 의미를 함께 봐야 한다
도면 편집 검증은 선이 연결됐는지만 확인해서는 부족하다. 태그가 프로젝트 명명 규칙을 따르는지, 장비와 라인의 사양이 호환되는지, 밸브 방향과 Fail Position이 공정 의도와 맞는지, Instrument Index와 Cause & Effect에 반영됐는지 봐야 한다.
규칙은 층별로 나눌 수 있다. 파일 무결성 규칙, 그래픽 규칙, 객체 관계 규칙, Discipline 규칙, 프로젝트 기준, 계약·승인 규칙이다. 각 규칙은 Pass, Fail, Review Required로 결과를 내고, 고위험 Fail이 하나라도 있으면 Commit을 막는다.
Preview는 단순한 빨간색 마크업이 아니다
좋은 Preview는 무엇이 추가·삭제·이동·수정되었는지 시각적으로 보여주는 동시에 데이터 차이를 제공한다. 도면 Overlay에는 변경 객체를 하이라이트하고, 오른쪽 패널에는 속성 Before/After, 관련 문서와 규칙 결과를 표시한다. 사용자는 변경 항목별로 승인하거나 수정할 수 있어야 한다.
특히 자동 Layout이 발생했다면 주변 객체가 왜 이동했는지 설명해야 한다. AI가 제안한 배치와 엔진이 실제 적용한 좌표를 구분하고, 원본과의 차이를 수치로 남겨야 한다. Preview 자체도 공식 변경 패키지의 증거가 된다.
이 Patch를 Commit해도 되는가?
폐쇄망과 권한, 감사가 제품 기능이어야 한다
중공업 도면과 사양은 민감한 프로젝트 자산이다. 배포 구조는 온프레미스, VPC, 폐쇄망을 고려해야 하고 외부 모델 전송 범위를 고객이 통제할 수 있어야 한다. 문서와 객체, 속성별 권한도 필요하다. 모든 사용자가 P&ID를 볼 수 있어도 구매 가격이나 Vendor 편차까지 볼 수 있는 것은 아니다.
AI 요청과 응답, 사용한 모델과 프롬프트 정책, 검색한 근거, 생성한 Patch, 규칙 결과, 승인과 Commit은 감사 로그로 남아야 한다. 모델 버전이 바뀌어도 과거 변경을 재현할 수 있어야 한다. 이 통제 계층이 별도 부가기능이 아니라 제품의 중심이어야 한다.
자동화 수준은 객체와 위험별로 다르게
모든 변경을 같은 승인 절차로 처리하면 자동화 효과가 낮고, 모두 자동 반영하면 위험하다. 저위험 표기 수정과 문서 참조 갱신은 규칙 통과 후 간소 승인할 수 있다. 태그 Rename은 관련 문서 영향이 넓으므로 복수 검토가 필요하다. Line Class와 설계압력, 제어 로직 변경은 고위험으로 분류해 사람의 판단을 강제해야 한다.
AI가 바꿀 것은 도면보다 변경의 방식이다
중공업에서 AI가 신뢰를 얻으려면 무엇이든 그릴 수 있다는 능력보다 무엇을 바꾸지 않았는지 증명할 수 있어야 한다. 변경 범위를 잠그고, 구조화된 Patch를 만들고, 공학 규칙을 통과하고, 사람이 승인한 뒤 공식 개정에 반영하는 절차가 핵심이다.
이 구조가 자리 잡으면 AI는 단순 도면 편집기를 넘어 변경 요청, 영향 분석, 계산과 규칙 검증, 문서 동기화와 감사 이력을 연결하는 Engineering Change Control Plane이 된다. 자동화의 마지막은 생성이 아니라 통제다.
doAZ Point of View
중공업 AI의 방어력은 모델보다 Patch DSL, DXF·도면 엔진, Rule-as-Code, Preview UX, Risk-based Approval, Audit·Rollback의 결합에서 만들어짐. 제한된 편집부터 시작하는 것이 느린 길이 아니라 실제 제품화의 가장 빠른 길임.