한 번 입력한 선박 데이터가 모든 계산서에 흐르게 하라

한 번 입력한 선박 데이터가 여러 계산서와 보고서에 흐르게 하려면 ‘중앙 DB’라는 말만으로는 부족하다. 무엇을 하나의 객체로 볼지, 어느 시스템의 값을 공식으로 인정할지, Excel의 어느 셀이 어떤 의미를 갖는지부터 정해야 한다. 기술의 핵심은 데이터 저장보다 업무 사이의 계약을 만드는 데 있다.

“한 번 입력”이라는 말의 실제 의미

데이터를 한 번만 입력하자는 말은 쉽다. 그러나 선박 프로젝트에서 같은 장비도 단계에 따라 여러 값을 갖는다. 개념설계에서는 과거선 추정 중량을 사용하고, 기본설계에서는 공급사 예비 데이터가 들어오며, 상세설계에서는 승인 도면의 확정값이 반영된다. 설치 후에는 실제 계근값이나 현장 변경까지 추가될 수 있다.

따라서 한 번 입력한다는 것은 값이 영원히 하나라는 뜻이 아니다. 각 단계의 공식 값과 그 근거를 한곳에서 관리하고, 필요한 계산서가 올바른 버전을 참조하게 한다는 뜻이다. 중량 계산서는 설계 중량을, 구매 문서는 계약 중량을, 생산 계획은 실제 운반 중량을 사용할 수 있다. 서로 다른 값을 허용하되 그 차이와 책임을 명시해야 한다.

선박 데이터 모델은 형상보다 관계에서 시작한다

중앙 선박 모델이라고 하면 흔히 3D 형상을 먼저 떠올린다. 물론 형상은 중요하다. 그러나 Excel과 업무 프로세스를 연결하려면 관계가 더 중요하다. 장비는 어느 구획에 놓이고, 어떤 시스템에 속하며, 어떤 지지 구조와 전원을 사용하고, 어느 구매 패키지와 연결되는가. 탱크는 어느 Deck과 Frame 사이에 있고, 어떤 용액을 담으며, 어떤 로딩 조건에서 사용되는가.

이 관계를 객체 그래프로 표현하면 같은 데이터가 여러 업무에 재사용된다. 구획의 면적과 체적은 도장·보온·HVAC·소방·견적 계산으로 흐를 수 있다. 장비의 중량과 위치는 중량관리, 지지 구조, 운반과 리프팅 계획에 연결된다. 배관 라인의 구경과 재질은 물량, 구매, 제작과 시험 기록으로 이어진다.

Excel과 중앙 모델 사이에는 ‘Workbook Contract’가 필요하다

Excel을 데이터 모델에 연결할 때 가장 위험한 방식은 특정 셀에 값을 밀어 넣는 스크립트를 급하게 만드는 것이다. 파일의 열이 하나 추가되거나 시트가 복사되면 연결이 깨지고, 누가 왜 그 셀을 사용했는지 설명하기 어렵다.

대신 계산서마다 Workbook Contract를 정의해야 한다. 이는 계산서가 어떤 입력을 요구하고, 어떤 결과를 내며, 어느 단위와 조건을 사용하는지 명시한 계약이다. 가능한 경우 Named Range를 사용하고, 그렇지 않다면 셀 주소와 주변 라벨, 수식 의존성을 함께 저장한다. 계약에는 필수 입력, 허용 범위, 빈 값의 의미, 공식 원본, 변환 규칙, 계산 버전이 포함되어야 한다.

모든 값을 중앙에서 소유하려 하지 말 것

중앙 데이터 계층은 데이터의 독점자가 아니라 교통정리자여야 한다. 장비의 공급사 확정 중량은 구매·Vendor Document 시스템이 책임질 수 있고, 설치 위치는 3D 모델이, 생산 상태는 MES나 현장 시스템이 책임질 수 있다. 중앙 계층은 각 속성의 책임 원본과 마지막 개정을 기억하고 필요한 곳에 전달한다.

속성별 책임을 나누면 데이터 충돌도 더 정확히 다룰 수 있다. 3D 모델의 장비 중량과 공급사 데이터시트의 중량이 다를 때 시스템이 임의로 하나를 선택해서는 안 된다. “모델 값은 12.6톤, Vendor 값은 13.1톤이며 구매팀이 책임 원본”이라고 보여주고, 모델 갱신 또는 예외 승인 절차를 제안해야 한다.

펌프 중량 변경이 흐르는 실제 경로

앞선 펌프 사례를 연결된 구조에서 다시 보자. 공급사 데이터시트 Rev.03이 승인되면 문서 파서가 장비 태그와 중량, 무게중심 후보를 읽는다. 시스템은 기존 공식 값과 차이를 계산하고 구매 담당자에게 확인을 요청한다. 담당자가 승인하면 `Equipment P-2101`의 계약 중량과 근거 문서가 갱신된다.

그다음 영향 그래프가 움직인다. 중량 관리 계산서의 입력 셀, 장비 기초 검토서, 리프팅 계획과 경하중량 보고서가 영향 후보로 표시된다. 각 계산은 자동으로 샌드박스에서 다시 실행되지만 공식 결과를 바로 덮어쓰지 않는다. 이전 개정과의 차이, 허용 마진, 오류와 경고를 검토자에게 보여준 후 승인된 결과만 프로젝트 기준선에 반영한다.

API보다 먼저 필요한 것은 단위와 상태의 표준화다

연동 프로젝트가 기술적으로 실패하는 이유는 API가 없어서가 아니라 의미가 맞지 않아서인 경우가 많다. 같은 중량도 Estimated, Design, Vendor, Installed Weight가 다르고, 좌표 기준과 부호가 다르며, 상태 값의 정의도 부서마다 다르다. 이 차이를 해결하지 않은 채 API를 연결하면 오류가 더 빠르게 이동할 뿐이다.

첫 스키마는 작아야 한다. 객체 ID, 이름, 분류, 단위, 값의 종류, 책임 원본, 개정, 유효 시점, 신뢰 상태 정도로 시작할 수 있다. 모든 속성을 처음부터 표준화하려 하지 말고, 선택한 업무 흐름에서 실제로 필요한 값만 정의한다. 프로젝트가 늘어나면서 용어 사전과 매핑 규칙을 축적하는 편이 현실적이다.

웹 기반 계산 워크벤치가 가져야 할 화면

사용자 화면도 데이터 구조를 그대로 반영해야 한다. 왼쪽에는 선박 객체와 도면을, 가운데에는 기존 Excel과 동일한 계산 흐름을, 오른쪽에는 출처·변경·검토 상태를 보여주는 구성이 적합하다. 사용자는 계산식을 수정할 수 있지만, 변경은 버전으로 남고 기준 케이스와 자동 비교된다.

중요한 기능은 AI 채팅창이 아니라 “이 셀의 값은 어디서 왔는가”, “이 결과가 이전 개정과 왜 달라졌는가”, “승인하면 어떤 문서가 영향을 받는가”를 한두 번의 클릭으로 확인하는 것이다. AI는 이 질문을 자연어로 받아 연결된 데이터를 탐색하고, 사용자가 직접 근거 영역과 계산 경로를 열어볼 수 있게 해야 한다.

중앙 모델은 데이터 저장소가 아니라 신뢰의 경로다

선박 데이터와 Excel을 연결하는 일은 단순한 자동 입력 프로젝트가 아니다. 객체의 의미, 값의 단계, 책임 원본, 계산 계약과 승인 절차를 함께 설계해야 한다. 이 구조가 갖춰지면 조선소가 오랫동안 축적한 Excel은 더 이상 고립된 파일이 아니라 재사용 가능한 계산 서비스가 된다.

다음 글에서는 이 위에 AI를 올릴 때 무엇을 맡기고 무엇을 맡기지 말아야 하는지 살펴본다. AI가 선박을 대신 설계한다고 과장하는 대신, 계산의 근거를 연결하고 변경의 영향을 놓치지 않게 만드는 현실적인 역할을 다룬다.