BIM만으로 건설 데이터 문제는 해결되지 않는다

BIM은 건설 산업의 중요한 진전이었다. 공간과 부재를 객체로 다루고, 여러 공종을 한 모델에서 조정할 수 있게 했다. 그러나 프로젝트의 공식 계산, 지반 가정, 공사비, 공정, 승인과 현장 변경까지 모두 BIM 안에 들어오지는 않는다. 그래서 모델이 최신이어도 Excel 계산서와 보고서, 내역서는 서로 다른 진실을 말할 수 있다.

BIM 조정회의가 끝난 뒤에도 남는 일

설계조정 회의에서 지하층 레벨과 구조 부재가 수정되었다고 하자. BIM 모델은 업데이트되고 간섭 검토도 다시 실행된다. 화면에서는 충돌이 사라졌지만, 지반 설계정수와 흙막이 계산서, 구조 검토용 Excel, 터파기 물량, 공사비 내역과 공정표가 함께 바뀌었다는 보장은 없다.

각 문서는 서로 다른 조직과 계약 범위에서 관리된다. 지반조사 보고서는 전문업체가, 구조해석 모델은 구조설계사가, 공사비 내역은 견적팀이, 공정표는 현장과 공정 담당자가 관리한다. BIM은 이들을 연결하는 강력한 축이지만 모든 데이터의 유일한 원본이 되기는 어렵다.

BIM이 잘하는 것과 하지 않는 것

BIM은 공간과 형상을 구조화하고, 부재와 설비의 관계를 시각적으로 이해하게 하는 데 탁월하다. 수량 산출과 간섭 검토, 설계 변경의 형상 반영에도 큰 장점이 있다. 그러나 모든 공학 계산을 모델 안에서 완결할 필요도, 그렇게 할 수 있는 것도 아니다.

지반의 내부마찰각과 점착력은 하나의 객체 속성처럼 보이지만 실제로는 시험 결과, 지층 구분, 설계자의 판단, 적용 기준과 안전측 가정이 결합된 값이다. 구조 부재의 단면도 BIM에 있지만 설계하중과 조합, 비선형 해석 조건은 별도 해석 모델에 있다. 마감재 이름은 모델에 들어가도 바탕면 상태, 시공 두께, 폐기율, 현장 생산성과 승인 샘플은 다른 시스템에서 관리되는 경우가 많다.

따라서 “모든 정보를 BIM에 넣자”는 목표는 시간이 지날수록 모델을 무겁게 하고 책임을 모호하게 할 수 있다. 더 필요한 것은 BIM을 포함한 여러 원본을 연결하는 의미 계층이다.

지하수위 0.8미터가 바뀌면

AEC 데이터 단절을 가장 잘 보여주는 사례가 지하수위다. 보링 로그와 지반조사 보고서에는 조사 당시 수위가 있고, 설계자는 계절 변동과 주변 조건을 고려해 설계지하수위를 정한다. 흙막이 단면도, 기초 계산서, 양압 검토, 배수 계획에 서로 다른 표기가 들어갈 수 있다.

설계지하수위가 EL. 12.5미터에서 EL. 11.7미터로 내려갔다고 하자. 숫자 하나가 바뀌었지만 영향은 단순하지 않다. 유효응력과 토압, 굴착 안정성, 양압과 부상, 직접기초 지지력과 침하, 액상화 평가, 배수량, 차수 공법, 토공 물량과 공정이 다시 검토될 수 있다. 어떤 항목은 더 안전해지고, 어떤 항목은 더 불리해질 수 있다.

‘하나의 진실’보다 ‘책임 있는 진실들’

건설 프로젝트에서 Single Source of Truth라는 표현은 매력적이지만 오해를 만들 수 있다. 구조 부재의 형상은 BIM이 공식일 수 있고, 부재력은 해석 모델이, 철근 배근은 구조도와 상세 모델이, 발주 수량은 계약 내역이 공식일 수 있다. 하나의 객체에도 속성마다 책임 원본이 다르다.

연합형 데이터 백본은 이 차이를 인정한다. 각 속성에 책임 시스템과 소유 조직, 유효 개정, 갱신 주기를 지정한다. 불일치가 생기면 중앙에서 임의로 하나를 선택하지 않고 차이를 이슈로 만들고 해결 과정을 기록한다. 이 구조가 있어야 협업이 “누가 맞는가”의 논쟁에서 “어떤 속성의 책임 원본이 무엇인가”라는 명확한 질문으로 바뀐다.

자주 실패하는 세 가지 접근

첫째는 모든 파일을 문서 검색 시스템에 넣고 AI에게 물어보는 방식이다. 검색 속도는 빨라지지만 어느 값이 공식인지, 계산이 다시 실행되어야 하는지는 해결되지 않는다. 둘째는 모든 데이터를 BIM 속성으로 옮기는 방식이다. 관계가 단순한 물량에는 효과가 있지만 전문 계산과 승인 맥락을 모두 담기에는 무리가 있다. 셋째는 기존 Excel을 새 웹 계산기로 한꺼번에 재개발하는 방식이다. 현업의 예외와 검토 습관이 빠지면서 신뢰를 잃기 쉽다.

대안은 단계적 연결이다. 먼저 파일과 객체를 식별하고, 입력·출력과 근거를 구조화한다. 다음으로 기존 계산서를 그대로 실행하면서 중앙 데이터에서 값을 공급한다. 그 후 변경 영향과 검토 이력을 쌓고, 반복성이 높은 계산부터 웹 네이티브 모듈로 전환한다.

AEC Engineering Data Backbone의 최소 구성

공통 계층에는 거창한 스키마보다 몇 가지 기본 개념이 필요하다. Project와 Document, Revision, Object, Property, Unit, Formula, Rule, Evidence, Issue, Approval, Change Event다. 이 공통 커널 위에 지반, 구조, 철골, 마감, 인테리어, MEP, 원가와 공정의 Domain Pack을 얹는다.

기술적으로는 BIM·CAD·PDF·Excel·해석 결과를 파싱하는 커넥터, 객체와 문서를 연결하는 그래프, 수식과 규칙을 실행하는 계산 계층, 검색과 설명을 담당하는 AI 계층, 버전·권한·감사를 관리하는 통제 계층이 필요하다. 하지만 첫 실증은 기술 스택보다 한 개의 업무 흐름을 끝까지 연결하는 데 집중해야 한다.

BIM 이후의 질문은 ‘무엇과 연결되는가’다

BIM의 도입은 건설 데이터를 객체로 바라보게 만들었다. 다음 과제는 그 객체가 계산서와 기준, 원가와 공정, 승인 이력에 어떻게 연결되는지 정의하는 일이다. 형상만 일치한다고 프로젝트의 판단이 일치하는 것은 아니다.

다음 글에서는 지반, 구조, 철골, 마감과 인테리어처럼 서로 멀어 보이는 공종이 실제로 어떤 공통 데이터 철학을 공유하는지 살펴본다. 공통 커널과 공종별 Domain Pack을 구분하면 범용 플랫폼과 전문성을 함께 확보할 수 있다.