중공업에서 AI의 승부처는 도면을 많이 생성하는 능력이 아니다. 변경 요청을 정확히 이해하고, 허용된 범위 안에서 수정안을 만들며, 계산과 규칙을 통과한 뒤 사람의 승인을 받아 안전하게 반영하는 능력이다. 특히 P&ID와 제작 관련 도면은 자유로운 자동 편집보다 통제된 변경이 먼저다.

왜 자동 생성보다 변경 통제가 먼저인가

새 P&ID를 처음부터 만드는 데모는 인상적이다. 그러나 실제 프로젝트의 대부분은 이미 존재하는 도면과 데이터에 변경을 반영하는 일이다. 태그를 바꾸고, 장비 속성을 수정하며, 심볼을 교체하고, 제한된 배관 연결을 조정한다. 이때 중요한 것은 새 그림이 그럴듯한가가 아니라 기존 기준선과 규칙, 관련 문서가 일관되게 유지되는가다.

무제한 생성형 편집은 두 가지 위험을 만든다. 하나는 AI가 의도하지 않은 요소까지 건드리는 것, 다른 하나는 시각적으로는 자연스럽지만 엔지니어링 규칙을 위반하는 것이다. 따라서 첫 제품은 편집 가능 객체와 명령을 제한하고, 변경 전후를 명확히 비교하며, 승인 전에는 공식 도면을 수정하지 않는 구조가 적합하다.

자유 생성형 도면 편집

자연어 지시로 도면 전체를 직접 수정함
변경 범위 밖의 객체가 함께 움직일 수 있음
심볼은 맞아 보여도 연결·속성 규칙을 위반할 수 있음
원본과 결과의 차이, 롤백과 승인 경로가 불명확함

통제된 변경 Copilot

허용된 객체와 속성만 패치 후보로 생성함
변경 범위와 근거, 영향을 먼저 보여줌
P&ID·데이터·계산 규칙을 결정론적으로 검사함
Preview와 사람 승인 후 공식 개정으로 Commit함
그림 1. 중공업 도면 AI는 “그려주는 도구”보다 “검증된 패치를 제안하는 도구”로 시작하는 편이 안전하고 실용적이다.

변경 요청에서 공식 개정까지의 여덟 단계

사용자가 “P-2101 토출 라인의 Control Valve를 한 단계 상향하고 관련 태그를 갱신해 달라”고 요청했다고 하자. AI는 문장을 곧바로 도면 명령으로 바꾸지 않는다. 먼저 대상 객체와 요청 범위를 해석하고, 최신 기준선과 권한을 확인한다.

그다음 수정 후보를 구조화된 Patch로 만든다. 태그, 심볼 속성, 라인 관계, 관련 목록의 변경을 분리하고, 계산과 규칙을 실행한다. 통과한 결과는 도면 Overlay와 데이터 Diff로 보여주고, 담당자가 승인하면 공식 파일과 개정 이력에 반영한다. 실패하면 원본은 그대로 유지된다.

Request Parse자연어·RFI·Change Notice에서 대상·의도·제약을 구조화함.
Scope Lock최신 기준선, 편집 권한과 허용 객체·속성을 고정함.
Impact Query연결 태그, 라인, Datasheet, List와 계산 영향을 탐색함.
Patch Draft도면·속성·목록 변경을 기계가 읽는 Patch로 생성함.
Rule Validation연결성·태그·사양·공정·도면 규칙과 계산을 검사함.
Visual Preview변경 전후 Overlay, 삭제·추가·수정과 미해결 항목을 표시함.
Human Approval공종별 담당자가 승인·수정·반려하고 사유를 기록함.
Commit & Audit공식 개정 반영, 연계 작업 생성, 감사·롤백 정보를 저장함.
그림 2. 변경은 하나의 프롬프트가 아니라 Scope–Patch–Validation–Approval–Commit의 통제된 트랜잭션으로 다뤄야 한다.

P&ID·DXF 편집은 제한된 범위에서 시작한다

초기 자동 편집 범위는 명확해야 한다. 태그 문자열과 속성, 승인된 심볼 라이브러리의 교체·추가·삭제, 속성 블록 갱신, 제한된 직교 배관 연결, 목록과 도면 번호 참조 정도가 현실적이다. 자유곡선과 복잡한 레이아웃 재배치, 다중 Discipline 상세 설계는 뒤로 미루는 편이 낫다.

DXF 같은 벡터 형식에서는 각 엔티티의 Layer, Block, Attribute, Handle과 연결 관계를 보존해야 한다. 편집 엔진은 AI가 직접 좌표를 무작위 생성하는 방식이 아니라, 규칙 기반 Geometry Operation과 승인된 심볼 템플릿을 사용해야 한다. AI는 “무엇을 바꿀지”를 제안하고, 실제 도형 수정은 결정론적 엔진이 수행한다.

Geometry·Rule Engine

같은 입력이면 같은 결과를 내고, 기준과 단위를 명시적으로 통제함.

DXF Block·Attribute·Layer를 안정적으로 읽고 제한된 엔티티를 수정함직교 배관, 최소 간격, 연결점과 심볼 Anchor 규칙을 적용함태그 중복, Line Class, 방향·연결성과 필수 속성을 검사함Patch 적용 전후 파일 무결성과 렌더링 결과를 회귀 비교함원본 Handle·개정·Checksum을 보존해 롤백을 보장함

AI Change Planner

문서와 도면의 맥락을 읽고, 근거와 변경 영향을 사람이 이해할 수 있게 연결함.

변경 요청에서 대상 객체와 의도, 제약조건을 해석함연결된 장비·라인·계기·문서의 영향 후보를 탐색함허용된 Patch 명령과 검토 의견 초안을 생성함규칙 실패 원인과 해결 선택지를 자연어로 설명함승인자가 놓친 관련 목록·데이터시트 갱신을 제안함
그림 3. 도형 편집은 결정론적 엔진이, 변경 의도와 영향 설명은 AI가 담당해야 파일 무결성과 업무 유연성을 함께 확보할 수 있다.

Patch를 공식 언어로 만들 것

AI의 출력이 곧바로 수정된 파일이어서는 안 된다. 먼저 사람이 읽고 시스템이 검증할 수 있는 변경 Patch가 있어야 한다. Patch에는 대상 객체, 현재값, 제안값, 변경 이유, 관련 객체, 필요한 규칙, 예상 문서 영향과 승인 역할이 포함된다.

예를 들어 `ReplaceSymbol`, `UpdateAttribute`, `ReconnectLine`, `CreateTag`, `RetireTag`, `UpdateListRow` 같은 제한된 명령을 정의할 수 있다. 각 명령은 사전조건과 사후조건을 갖는다. 현재 개정과 객체 Handle이 일치하지 않으면 적용하지 않고, 적용 후에는 연결성과 태그 유일성을 검사한다.

Controlled Patch CP-2026-118P-2101 Discharge Control Valve 변경 예시
Target BaselineP&ID P-101 Rev.12 · Checksum 8fa…
ScopeLine L-2101-D · Valve CV-2103 · Instrument Loop
Patch CommandsReplaceSymbol · UpdateAttribute · ReconnectLine
Preconditions객체 Handle·태그·개정 일치 · 편집 권한 유효
Engineering RulesLine Class · Flow Direction · Fail Position · Tag Uniqueness
Linked UpdatesValve List · Instrument Index · Datasheet · Cause & Effect
Risk LevelHigh · Process Control / Procurement Impact
Approval RouteProcess → Instrument → Piping → Document Control
그림 4. Patch는 AI의 제안을 감사 가능한 엔지니어링 변경 언어로 바꾼다. 파일 수정은 Patch가 모든 사전조건과 검증을 통과한 뒤에만 수행한다.

검증은 도면 규칙과 공학 의미를 함께 봐야 한다

도면 편집 검증은 선이 연결됐는지만 확인해서는 부족하다. 태그가 프로젝트 명명 규칙을 따르는지, 장비와 라인의 사양이 호환되는지, 밸브 방향과 Fail Position이 공정 의도와 맞는지, Instrument Index와 Cause & Effect에 반영됐는지 봐야 한다.

규칙은 층별로 나눌 수 있다. 파일 무결성 규칙, 그래픽 규칙, 객체 관계 규칙, Discipline 규칙, 프로젝트 기준, 계약·승인 규칙이다. 각 규칙은 Pass, Fail, Review Required로 결과를 내고, 고위험 Fail이 하나라도 있으면 Commit을 막는다.

01File IntegrityDXF 구조, Block·Layer·Attribute와 참조 무결성을 검사함.
02Graphic Rule심볼 방향, 직교 연결, 겹침, 최소 간격과 가독성을 검사함.
03Object Rule태그 유일성, 장비–라인–계기 관계와 필수 속성을 검사함.
04Engineering RuleLine Class, 압력·재질·밸브·계장 로직의 적합성을 검사함.
05Project Rule사내 표준, 프로젝트 명명, 발행·개정 규칙을 적용함.
06Approval Gate위험도별 필수 검토자와 미해결 이슈를 확인함.
그림 5. 검증 계층이 분리되어야 오류가 그래픽 문제인지 공학 사양 문제인지 명확히 설명할 수 있다.

Preview는 단순한 빨간색 마크업이 아니다

좋은 Preview는 무엇이 추가·삭제·이동·수정되었는지 시각적으로 보여주는 동시에 데이터 차이를 제공한다. 도면 Overlay에는 변경 객체를 하이라이트하고, 오른쪽 패널에는 속성 Before/After, 관련 문서와 규칙 결과를 표시한다. 사용자는 변경 항목별로 승인하거나 수정할 수 있어야 한다.

특히 자동 Layout이 발생했다면 주변 객체가 왜 이동했는지 설명해야 한다. AI가 제안한 배치와 엔진이 실제 적용한 좌표를 구분하고, 원본과의 차이를 수치로 남겨야 한다. Preview 자체도 공식 변경 패키지의 증거가 된다.

이 Patch를 Commit해도 되는가?

도면 연결성과 태그 유일성은 통과했음. 그러나 Valve List의 Body Material이 기존 CS로 남아 있으며 신규 Line Class는 SS316을 요구함. Instrument Index와 Cause & Effect 갱신안은 준비되었으나 Piping 담당자의 재질 확인 전에는 Commit이 차단됨.
P&ID Diff3 objects modified · 1 reconnect
Valve List RuleMaterial conflict · FAIL
Instrument IndexUpdate candidate ready
Approval GatePiping review pending
그림 6. Preview는 시각적 차이, 속성 충돌, 규칙 결과와 남은 승인자를 함께 보여줘야 한다.

폐쇄망과 권한, 감사가 제품 기능이어야 한다

중공업 도면과 사양은 민감한 프로젝트 자산이다. 배포 구조는 온프레미스, VPC, 폐쇄망을 고려해야 하고 외부 모델 전송 범위를 고객이 통제할 수 있어야 한다. 문서와 객체, 속성별 권한도 필요하다. 모든 사용자가 P&ID를 볼 수 있어도 구매 가격이나 Vendor 편차까지 볼 수 있는 것은 아니다.

AI 요청과 응답, 사용한 모델과 프롬프트 정책, 검색한 근거, 생성한 Patch, 규칙 결과, 승인과 Commit은 감사 로그로 남아야 한다. 모델 버전이 바뀌어도 과거 변경을 재현할 수 있어야 한다. 이 통제 계층이 별도 부가기능이 아니라 제품의 중심이어야 한다.

자동화 수준은 객체와 위험별로 다르게

모든 변경을 같은 승인 절차로 처리하면 자동화 효과가 낮고, 모두 자동 반영하면 위험하다. 저위험 표기 수정과 문서 참조 갱신은 규칙 통과 후 간소 승인할 수 있다. 태그 Rename은 관련 문서 영향이 넓으므로 복수 검토가 필요하다. Line Class와 설계압력, 제어 로직 변경은 고위험으로 분류해 사람의 판단을 강제해야 한다.

0Review-onlyAI가 차이와 수정안을 제시하지만 파일은 수정하지 않음.
1Low-risk Patch태그 표기·속성·문서 참조를 승인 후 자동 반영함.
2Symbol Operation승인된 라이브러리 내 심볼 추가·교체·삭제를 지원함.
3Limited Connectivity제한된 직교 배관 연결과 주변 Layout을 규칙 기반으로 수행함.
4Cross-document Commit관련 List·Datasheet·Index의 변경 작업을 동기화함.
5Lifecycle Controlled Change구매·제작·현장 상태까지 고려한 변경과 롤백을 운영함.
그림 7. 도면 AI는 검토 전용에서 저위험 Patch, 제한적 형상 편집과 생애주기 변경으로 단계적으로 확장해야 한다.

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의 결합에서 만들어짐. 제한된 편집부터 시작하는 것이 느린 길이 아니라 실제 제품화의 가장 빠른 길임.

YT
김영태 · CEO · doAZ

건설·엔지니어링 현장과 연구개발, 산업 AI 사업을 오가며 도면과 문서, 계산서에 흩어진 지식을 연결하는 방법을 고민하고 있음. 이 시리즈는 doAZ가 지향하는 제품 철학과 실증 방향을 공개적으로 정리한 기록임.