현장에서 오래 일한 사람에게 Excel은 단순한 표 계산 프로그램이 아니다. 설계 기준이 들어 있고, 회사가 겪은 시행착오가 남아 있으며, 누가 어떤 순서로 무엇을 검토하는지까지 숨어 있다. 문제는 Excel이 낡아서가 아니다. 그 안의 지식이 도면, 모델, 보고서, 전문 프로그램과 연결되지 않은 채 파일마다 따로 움직인다는 데 있다.
회의실에서 가장 자주 나오는 질문
조선소의 중량 검토 회의, 건설 프로젝트의 설계조정 회의, 플랜트 프로젝트의 P&ID 리뷰에는 묘하게 닮은 장면이 있다. 화면에는 최신 모델이 떠 있고, 참석자 앞에는 서로 다른 Excel 파일이 열려 있다. 누군가는 어제 받은 PDF를 기준으로 이야기하고, 누군가는 공유 폴더의 파일을, 또 다른 누군가는 메일 첨부본을 기준으로 말한다.
논쟁은 대개 기술적인 질문으로 시작하지 않는다. “이 값이 최신인가요?”, “어느 도면에서 가져온 숫자인가요?”, “변경된 내용이 견적에도 반영됐나요?” 같은 확인부터 시작한다. 엔지니어는 계산보다 먼저 데이터의 신뢰도를 확인해야 한다. 설계가 복잡해서 생기는 문제라기보다, 정보의 연결이 끊겨 있기 때문에 생기는 비용이다.
Excel은 왜 쉽게 사라지지 않는가
Excel을 없애야 디지털 전환이 완성된다는 주장은 현장을 지나치게 단순하게 본다. Excel은 빠르고, 유연하며, 엔지니어가 직접 계산 과정을 확인할 수 있다. 프로젝트마다 다른 발주처 양식과 예외 조건에도 쉽게 대응한다. 무엇보다 수십 년간 검증한 계산식과 보고서 형식이 이미 들어 있다.
하나의 계산서에는 공식만 있는 것이 아니다. 어떤 값을 먼저 넣어야 하는지, 어떤 범위에서는 경고를 띄워야 하는지, 결과를 어떤 표로 보여줘야 검토자가 안심하는지까지 포함된다. 그래서 오래된 Excel 파일 하나는 종종 작은 전문 소프트웨어에 가깝다. 이를 무시한 채 새 웹 화면으로 전부 다시 만들면, 겉은 현대적이어도 현업이 신뢰하지 않는 제품이 되기 쉽다.
따라서 바꿔야 할 것은 도구가 아니라 역할이다. 공식 데이터는 통제된 데이터 계층에서 관리하고, Excel은 계산·분석·보고서 작성에 집중하도록 분리한다. 사용자는 익숙한 계산서를 계속 사용할 수 있지만, 입력값은 도면과 모델, 보고서에서 출처와 버전을 갖고 들어온다.
파일이 곧 진실인 방식
데이터가 흐르고 파일은 표현하는 방식
하나의 거대한 데이터베이스가 답은 아니다
조선과 건설, 중공업은 사용하는 시스템도 다르고 데이터의 책임자도 다르다. 선박 형상은 3D CAD에, 구조해석 결과는 전문 프로그램에, 지반 정수는 조사보고서에, 장비 구매 상태는 ERP에 있다. 모든 데이터를 한 시스템으로 강제로 옮기면 이론적으로는 깔끔해 보이지만, 실제 프로젝트에서는 원본의 책임과 갱신 주기가 더 불분명해질 수 있다.
더 현실적인 구조는 연합형 엔지니어링 데이터 백본이다. 각 시스템은 자신이 잘하는 일을 계속한다. 대신 객체 ID, 속성의 의미, 단위, 출처 문서, 개정 번호, 계산 의존성, 승인 상태를 공통 계층에서 연결한다. 중요한 것은 “어디에 저장했는가”보다 “이 숫자가 무엇이며, 어디에서 왔고, 무엇에 쓰였는가”다.
AI에게 계산을 맡길 것인가, 연결을 맡길 것인가
생성형 AI가 등장한 뒤 많은 제품이 “자연어로 설계하고 자동으로 계산한다”는 약속을 내놓았다. 그러나 엔지니어링에서 중요한 것은 그럴듯한 답이 아니라 재현 가능한 답이다. 같은 입력에 따라 결과가 달라지거나, 단위와 적용 기준이 숨겨진 계산은 업무 속도를 높이는 대신 새로운 위험을 만든다.
따라서 실제 수치 계산은 검증된 Excel 수식, Python 모듈, 해석 프로그램, Rule-as-Code가 담당하는 편이 안전하다. LLM과 VLM은 다른 곳에서 훨씬 큰 가치를 낸다. 도면과 PDF에서 입력 후보를 찾고, 서로 다른 명칭을 같은 객체로 묶고, 계산식의 의미와 적용 기준을 설명하며, 변경된 값이 어디까지 번지는지 보여주는 역할이다.
결정론적 계산·규칙 엔진
같은 입력이면 같은 결과를 내고, 기준과 단위를 명시적으로 통제함.
LLM·VLM 계층
문서와 도면의 맥락을 읽고, 근거와 변경 영향을 사람이 이해할 수 있게 연결함.
한 개의 숫자가 바뀔 때 산업은 어떻게 움직이는가
이 철학의 가치는 검색 화면보다 변경 상황에서 분명해진다. 선박 펌프의 중량이 바뀌면 장비 목록과 경하중량, 무게중심, 구매 사양, 생산 계획이 영향을 받는다. 건설 현장의 지하수위가 달라지면 토압, 양압, 기초 지지력, 액상화, 배수계획과 공사비가 다시 검토되어야 한다. 플랜트 P&ID의 장비 태그가 변경되면 장비 목록, 데이터시트, 구매문서, 제작도면, 검사기록까지 확인해야 한다.
지금은 숙련자가 경험으로 이 연결을 기억한다. 다음 단계의 시스템은 변경을 하나의 사건으로 기록하고, 객체 관계와 계산 의존성을 따라 영향 범위를 찾아야 한다. 모든 항목을 자동 수정하는 것이 목적은 아니다. 무엇을 다시 봐야 하는지 놓치지 않는 것이 먼저다.
제품보다 먼저 확정해야 할 일곱 가지 원칙
이 개념을 실제 제품으로 만들 때 화려한 AI 데모보다 먼저 지켜야 할 원칙이 있다. 첫째, 기존 Excel과 전문 프로그램을 적으로 만들지 않는다. 둘째, 모든 값에 의미와 단위를 부여한다. 셋째, 원본과 복제본을 구분한다. 넷째, 계산은 동일 조건에서 재현되어야 한다. 다섯째, 변경의 영향을 추적한다. 여섯째, AI의 근거와 불확실성을 숨기지 않는다. 마지막으로 자동화의 끝에는 항상 책임 있는 사람의 승인 지점이 있어야 한다.
이 원칙을 따르면 제품의 모습도 달라진다. 챗봇이 중심이 아니라 객체와 계산의 연결이 중심이 된다. 멋진 대시보드보다 입력값의 출처와 버전이 중요해진다. 자동 생성보다 차이 비교와 롤백이 먼저 설계된다. 그리고 “정확도 99%” 같은 하나의 숫자보다 어떤 항목을 자동 승인할 수 있고, 어떤 항목은 반드시 사람이 봐야 하는지 구분하는 체계가 중요해진다.
도구의 미래보다 지식의 흐름을 설계해야 한다
엔지니어링 산업은 이미 충분히 많은 소프트웨어를 갖고 있다. 부족한 것은 또 하나의 화면이 아니다. 도면의 형상, Excel의 계산, 보고서의 가정, 기준의 문장, 현장의 변경을 서로 이해할 수 있게 만드는 공통 언어가 부족하다.
이 시리즈는 그 공통 언어를 조선, 건설, 중공업으로 나누어 살펴본다. 첫 번째 조선 편에서는 조선소가 왜 여전히 Excel로 움직이는지부터 시작한다. Excel을 낡은 유산으로 취급하지 않고, 선박 설계 지식을 담은 실행 가능한 자산으로 다시 보는 일이다.
doAZ Point of View
도면을 읽어주는 AI를 넘어, 도면에서 나온 값이 어떤 계산서와 기준을 거쳐 어떤 결정으로 이어졌는지 설명하는 시스템이 필요함. 두아즈가 지향하는 것은 범용 챗봇이 아니라 검증 가능한 엔지니어링 데이터와 계산의 운영 체계임.