현장에서 오래 일한 사람에게 Excel은 단순한 표 계산 프로그램이 아니다. 설계 기준이 들어 있고, 회사가 겪은 시행착오가 남아 있으며, 누가 어떤 순서로 무엇을 검토하는지까지 숨어 있다. 문제는 Excel이 낡아서가 아니다. 그 안의 지식이 도면, 모델, 보고서, 전문 프로그램과 연결되지 않은 채 파일마다 따로 움직인다는 데 있다.

회의실에서 가장 자주 나오는 질문

조선소의 중량 검토 회의, 건설 프로젝트의 설계조정 회의, 플랜트 프로젝트의 P&ID 리뷰에는 묘하게 닮은 장면이 있다. 화면에는 최신 모델이 떠 있고, 참석자 앞에는 서로 다른 Excel 파일이 열려 있다. 누군가는 어제 받은 PDF를 기준으로 이야기하고, 누군가는 공유 폴더의 파일을, 또 다른 누군가는 메일 첨부본을 기준으로 말한다.

논쟁은 대개 기술적인 질문으로 시작하지 않는다. “이 값이 최신인가요?”, “어느 도면에서 가져온 숫자인가요?”, “변경된 내용이 견적에도 반영됐나요?” 같은 확인부터 시작한다. 엔지니어는 계산보다 먼저 데이터의 신뢰도를 확인해야 한다. 설계가 복잡해서 생기는 문제라기보다, 정보의 연결이 끊겨 있기 때문에 생기는 비용이다.

도면·모델형상과 위치는 비교적 잘 관리되지만 계산 입력값과 승인 맥락은 빠지기 쉬움.
Excel 계산서검증된 공식과 회사 노하우가 있지만 셀 주소와 파일 버전에 의미가 갇혀 있음.
PDF 보고서기준과 가정, 시험 결과가 풍부하지만 다시 계산 가능한 데이터가 아님.
전문 해석 프로그램정교한 결과를 만들지만 다른 공종의 문서와 영향 관계가 약함.
ERP·공정 시스템원가와 일정은 관리하지만 설계 변경의 기술적 이유가 충분히 연결되지 않음.
사람의 경험예외와 판단을 보완하지만 조직이 바뀌면 추적하기 어려움.
Engineering Data Backbone출처·버전·객체·계산식·기준·변경·승인을 연결하는 공통 척추
그림 1. 산업의 정보는 이미 충분히 많다. 필요한 것은 모든 정보를 한곳에 복사하는 것이 아니라, 서로 다른 원본 사이에 신뢰할 수 있는 연결을 만드는 일이다.

Excel은 왜 쉽게 사라지지 않는가

Excel을 없애야 디지털 전환이 완성된다는 주장은 현장을 지나치게 단순하게 본다. Excel은 빠르고, 유연하며, 엔지니어가 직접 계산 과정을 확인할 수 있다. 프로젝트마다 다른 발주처 양식과 예외 조건에도 쉽게 대응한다. 무엇보다 수십 년간 검증한 계산식과 보고서 형식이 이미 들어 있다.

하나의 계산서에는 공식만 있는 것이 아니다. 어떤 값을 먼저 넣어야 하는지, 어떤 범위에서는 경고를 띄워야 하는지, 결과를 어떤 표로 보여줘야 검토자가 안심하는지까지 포함된다. 그래서 오래된 Excel 파일 하나는 종종 작은 전문 소프트웨어에 가깝다. 이를 무시한 채 새 웹 화면으로 전부 다시 만들면, 겉은 현대적이어도 현업이 신뢰하지 않는 제품이 되기 쉽다.

Excel을 버리는 것이 아니라, Excel이 혼자서 데이터베이스와 계산기와 보고서의 역할을 모두 떠맡지 않게 해야 한다.「도면과 Excel 사이」의 출발점

따라서 바꿔야 할 것은 도구가 아니라 역할이다. 공식 데이터는 통제된 데이터 계층에서 관리하고, Excel은 계산·분석·보고서 작성에 집중하도록 분리한다. 사용자는 익숙한 계산서를 계속 사용할 수 있지만, 입력값은 도면과 모델, 보고서에서 출처와 버전을 갖고 들어온다.

파일이 곧 진실인 방식

같은 입력값을 여러 계산서에 반복 입력함
메일과 공유 폴더의 복사본이 서로 다름
셀 B17이 무엇을 의미하는지 작성자만 앎
설계 변경 후 영향을 사람이 기억해 찾아감
결과는 남지만 계산 당시의 근거는 흐려짐

데이터가 흐르고 파일은 표현하는 방식

공식 입력값은 객체와 속성으로 관리함
Excel은 검증된 계산 로직과 서식을 유지함
셀과 엔지니어링 의미를 명시적으로 연결함
변경 이벤트가 영향받는 계산·도면을 찾음
모든 결과에 출처·기준·버전·승인을 남김
그림 2. 목표는 Excel을 제거하는 것이 아니라, Excel 안에 갇힌 지식을 더 넓은 엔지니어링 흐름에 연결하는 것이다.

하나의 거대한 데이터베이스가 답은 아니다

조선과 건설, 중공업은 사용하는 시스템도 다르고 데이터의 책임자도 다르다. 선박 형상은 3D CAD에, 구조해석 결과는 전문 프로그램에, 지반 정수는 조사보고서에, 장비 구매 상태는 ERP에 있다. 모든 데이터를 한 시스템으로 강제로 옮기면 이론적으로는 깔끔해 보이지만, 실제 프로젝트에서는 원본의 책임과 갱신 주기가 더 불분명해질 수 있다.

더 현실적인 구조는 연합형 엔지니어링 데이터 백본이다. 각 시스템은 자신이 잘하는 일을 계속한다. 대신 객체 ID, 속성의 의미, 단위, 출처 문서, 개정 번호, 계산 의존성, 승인 상태를 공통 계층에서 연결한다. 중요한 것은 “어디에 저장했는가”보다 “이 숫자가 무엇이며, 어디에서 왔고, 무엇에 쓰였는가”다.

01원본을 존중함CAD·BIM·해석 프로그램·Excel·ERP가 가진 권위와 책임 범위를 유지함.
02의미를 부여함셀과 도면 요소를 선박 장비, 구조 부재, 지층, 배관 태그 같은 객체로 매핑함.
03계산을 재현함입력값·수식·단위·기준 버전을 고정해 같은 조건에서 같은 결과를 다시 만듦.
04변경을 추적함하나의 변경이 계산서, 도면, 물량, 원가, 공정에 미치는 영향을 그래프로 탐색함.
05사람이 승인함AI의 제안과 근거를 검토한 뒤 권한 있는 엔지니어가 최종 반영함.
그림 3. 연합형 데이터 백본의 다섯 단계. 통합의 목적은 데이터를 독점하는 것이 아니라 신뢰의 경로를 만드는 것이다.

AI에게 계산을 맡길 것인가, 연결을 맡길 것인가

생성형 AI가 등장한 뒤 많은 제품이 “자연어로 설계하고 자동으로 계산한다”는 약속을 내놓았다. 그러나 엔지니어링에서 중요한 것은 그럴듯한 답이 아니라 재현 가능한 답이다. 같은 입력에 따라 결과가 달라지거나, 단위와 적용 기준이 숨겨진 계산은 업무 속도를 높이는 대신 새로운 위험을 만든다.

따라서 실제 수치 계산은 검증된 Excel 수식, Python 모듈, 해석 프로그램, Rule-as-Code가 담당하는 편이 안전하다. LLM과 VLM은 다른 곳에서 훨씬 큰 가치를 낸다. 도면과 PDF에서 입력 후보를 찾고, 서로 다른 명칭을 같은 객체로 묶고, 계산식의 의미와 적용 기준을 설명하며, 변경된 값이 어디까지 번지는지 보여주는 역할이다.

결정론적 계산·규칙 엔진

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

Excel 수식과 공학 계산 모듈을 동일 조건으로 반복 실행함단위 변환, 허용범위, 필수 입력, 설계 기준을 명시적으로 검사함결과를 원본 Excel 및 기준 예제와 회귀 비교함오류가 확인되면 자동 반영하지 않고 중단함

LLM·VLM 계층

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

도면·보고서·표에서 입력값과 근거 영역을 탐색함B17 같은 셀 주소를 설계정수·부재치수·장비중량 같은 의미로 연결함변경 전후의 차이와 영향받는 계산서를 자연어로 설명함판단이 불확실할 때 확신을 꾸미지 않고 검토가 필요한 이유를 제시함
그림 4. AI와 계산 엔진의 역할을 분리하면 자동화의 범위를 넓히면서도 결과의 재현성과 책임 구조를 유지할 수 있다.

한 개의 숫자가 바뀔 때 산업은 어떻게 움직이는가

이 철학의 가치는 검색 화면보다 변경 상황에서 분명해진다. 선박 펌프의 중량이 바뀌면 장비 목록과 경하중량, 무게중심, 구매 사양, 생산 계획이 영향을 받는다. 건설 현장의 지하수위가 달라지면 토압, 양압, 기초 지지력, 액상화, 배수계획과 공사비가 다시 검토되어야 한다. 플랜트 P&ID의 장비 태그가 변경되면 장비 목록, 데이터시트, 구매문서, 제작도면, 검사기록까지 확인해야 한다.

지금은 숙련자가 경험으로 이 연결을 기억한다. 다음 단계의 시스템은 변경을 하나의 사건으로 기록하고, 객체 관계와 계산 의존성을 따라 영향 범위를 찾아야 한다. 모든 항목을 자동 수정하는 것이 목적은 아니다. 무엇을 다시 봐야 하는지 놓치지 않는 것이 먼저다.

도면·모델형상과 표기, 상세 연결의 갱신 여부
공학 계산입력값과 수식 의존성, 재계산 필요 여부
기술 기준적용 조항과 사내 규칙의 재검토 여부
한 개의 변경값·형상·사양·상태의 개정
물량·원가수량, 단가, 할증률, 견적의 변동
공정·조달발주 리드타임과 제작·시공 순서의 영향
검사·승인재승인, 샘플, 선급·감리 검토의 필요성
보고서표와 본문, 결론의 정합성
운영 이력누가 언제 어떤 근거로 승인했는지
그림 5. Engineering Change Intelligence는 자동 수정 기능이 아니라, 변경의 반경을 먼저 보여주는 통제 장치다.

제품보다 먼저 확정해야 할 일곱 가지 원칙

이 개념을 실제 제품으로 만들 때 화려한 AI 데모보다 먼저 지켜야 할 원칙이 있다. 첫째, 기존 Excel과 전문 프로그램을 적으로 만들지 않는다. 둘째, 모든 값에 의미와 단위를 부여한다. 셋째, 원본과 복제본을 구분한다. 넷째, 계산은 동일 조건에서 재현되어야 한다. 다섯째, 변경의 영향을 추적한다. 여섯째, AI의 근거와 불확실성을 숨기지 않는다. 마지막으로 자동화의 끝에는 항상 책임 있는 사람의 승인 지점이 있어야 한다.

이 원칙을 따르면 제품의 모습도 달라진다. 챗봇이 중심이 아니라 객체와 계산의 연결이 중심이 된다. 멋진 대시보드보다 입력값의 출처와 버전이 중요해진다. 자동 생성보다 차이 비교와 롤백이 먼저 설계된다. 그리고 “정확도 99%” 같은 하나의 숫자보다 어떤 항목을 자동 승인할 수 있고, 어떤 항목은 반드시 사람이 봐야 하는지 구분하는 체계가 중요해진다.

0파일 검색문서와 계산서를 빠르게 찾지만 값과 계산의 관계는 여전히 사람이 해석함.
1구조화 추출표·도면·셀에서 입력과 결과를 추출하고 단위와 형식을 정리함.
2의미 연결객체, 속성, 셀, 기준 조항, 원본 영역을 하나의 관계망으로 묶음.
3재현 가능한 계산웹과 Excel에서 같은 입력과 수식으로 결과를 반복 검증함.
4변경 영향 분석개정이 계산·도면·원가·공정에 미치는 범위를 자동 제안함.
5통제된 실행검증과 승인 후 제한된 변경을 반영하고 전체 이력을 남김.
그림 6. 실제 개발은 검색에서 통제된 실행으로 단계적으로 올라가야 한다. 중간 단계를 건너뛰면 AI가 빨라질수록 오류도 더 빨리 확산될 수 있다.

도구의 미래보다 지식의 흐름을 설계해야 한다

엔지니어링 산업은 이미 충분히 많은 소프트웨어를 갖고 있다. 부족한 것은 또 하나의 화면이 아니다. 도면의 형상, Excel의 계산, 보고서의 가정, 기준의 문장, 현장의 변경을 서로 이해할 수 있게 만드는 공통 언어가 부족하다.

이 시리즈는 그 공통 언어를 조선, 건설, 중공업으로 나누어 살펴본다. 첫 번째 조선 편에서는 조선소가 왜 여전히 Excel로 움직이는지부터 시작한다. Excel을 낡은 유산으로 취급하지 않고, 선박 설계 지식을 담은 실행 가능한 자산으로 다시 보는 일이다.

doAZ Point of View

도면을 읽어주는 AI를 넘어, 도면에서 나온 값이 어떤 계산서와 기준을 거쳐 어떤 결정으로 이어졌는지 설명하는 시스템이 필요함. 두아즈가 지향하는 것은 범용 챗봇이 아니라 검증 가능한 엔지니어링 데이터와 계산의 운영 체계임.

YT
김영태 · CEO · doAZ

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