#10. BIM 도입 전, 읽어야 할 글
"BIM을 안다"와 "BIM을 한다"는 전혀 다른 이야기
"BIM을 안다"는 것과 "BIM을 한다"는 것은 전혀 다른 이야기입니다. BIM을 한다는 것은 이론과 현실의 괴리 속에서 허들을 넘고 환경을 극복하며 작은 일에도 일희일비하며 하루하루 존재를 증명해가야만 하는 챌린지 한 여정이기 때문입니다. 이론과는 다른 BIM 시스템 도입에 대해 얘기해보려 합니다.
[영화'매트릭스'中 모피어스의 대사]BIM시스템 구축은 단순한 모델링 도입이 아닌, 일의 정의를 다시 세우고, 협업의 방식을 설계하며, 데이터를 남기는 방식까지 고려해야 하는 전략적인 일입니다.
많은 기업들이 BIM 시스템을 처음 도입할 때 하는 실수는 추상적인 계획과 너무 이른 투자, 그리고 과도한 기대 속에 지쳐간다는 점입니다. 이 글에서는 '작은 실효에서 출발해 점진적으로 확장해 가는 BIM 시스템 구축 과정'에 대해, 직접 경험한 고민과 사례를 바탕으로 풀어보고자 합니다. 당장의 거대한 구조보다는 한 걸음씩 쌓아 올릴 수 있는 실질적인 기준과 우선순위를 세우고 "무엇을 위해, 누구와 함께, 어디서부터 시작할 것인가"라는 질문에 답을 찾고 싶은 분들께 이 글이 작은 나침반이 되기를 바랍니다.
일의 정의
BIM 시스템으로 무엇을 하려는지를 명확히 정의하는 것부터가 출발점입니다. 목적을 어디에 둘 것인가? (물량을 산출할 것인가? 단가도 산정할 것인가? 아니면 시각화와 도면 관리가 주목적인가?) 또한 어떤 공종에 집중할 것인가? (토공사?, 골조공사?, 마감공사?, MEP공사?) 등 선택의 폭은 넓습니다.
만약 물량산출이 목적이라면, 어느 공종에 집중할 것인지 선택해야 합니다. 이때 마감공사부터 시작하면 실패할 확률이 높습니다. 아니 지치기 쉽습니다. 마감공사는 내역이 방대하고 복잡하여 실효가 바로 나타나기 어렵기 때문입니다. 오히려 경영진의 기대만 높이고, 시스템이 완성되지 못한 채 중단되기 십상입니다. 따라서 실효가 가장 빠르게 나타날 수 있는 골조공사부터 시작하는 것이 바람직합니다.
골조공사부터 시작하기로 했다면, 그다음은 코드는 무엇으로 설정할지를 고민해야 합니다. WBS코드, OBS코드, CBS코드 중에서 선택을 해야 하는데 결론적으로 무조건 CBS코드여야 합니다. BIM의 핵심이 코스트 BIM이라면 원가 체계와의 정합성이 가장 중요합니다. 전사 ERP와의 연계를 고려하더라도 CBS 기반 체계는 필수입니다. 혹시라도 3개 코드 체계를 모두 통합할 계획이시라면 말리고 싶습니다. 출발은 해도 길을 잃고 말 거니까요. 이상입니다.
다음으로 BIM 직접산출 내역과 간접 산출 내역을 구분해야 합니다. 철근, 콘크리트, 거푸집은 BIM으로 직접 산출하되, 가설재나 단열재, 기타 연관내역들은 2D기반으로 산출하는 것이 산출 속도와 산출 비용적으로 현실적입니다. 그러므로 BIM 산출 데이터와 2D 산출 데이터의 통합을 고려한 시스템의 설계가 필요합니다.
사용할 프로그램도 중요합니다. 레빗(Revit), 테클라(Tekla), 빌더허브(BuilderHub) 중에서 선택하게 됩니다. 골조공사에서 철근까지 산출해야 한다면 레빗보다는 테클라나 빌더허브가 적합합니다. 주요 사업 모델이 아파트라면 빌더허브가 적합하고, 비정형 고난도 사업이 중심이라면 파워풀한 디테일과 자유도가 높은 테클라가 더 적합합니다. 단, 테클라는 협력사 생태계가 상대적으로 빈약하여 비용이 높고 운용 난이도도 높다는 점은 고려해야 합니다.
웹뷰어(Viewer)의 운영방식도 고민해야 합니다. 오토데스크의 포지(Forge)는 오픈소스로서 제품 자체는 우수하지만, 속도가 상대적 느리고 측정기능이나 물량 테이블 기능이 부족한 면이 있습니다. 빌더허브의 IDC는 성능이 아직 상대적으로 약하고 느리고 아직 안정화되지 않은 듯합니다. 트림블커넥트(Trimble Connect)는 약간의 비용으로도 강력한 뷰잉 기능을 제공하는 거 같습니다. 물량테이블, 측정기능, 편안한 UI/UX 등 현장에서 활용하기 용이합니다. 저는 마감공사는 포지 기반 뷰어를, 골조공사는 트림블커넥트를 기본으로 적용하고 있습니다.
결국 BIM 시스템을 구축해 무엇을 하려는지 그 목적을 명확히 하면, 시스템의 방향과 구성은 자연스럽게 풀려나가게 되어 있는 것 같습니다.
누가 하지?
보통 BIM을 하겠다고 하면 실무 조직과 거리가 있는 R&D조직이나 TFT 조직 등에서 주도하면서 현업에 자문을 구하는 방식으로 진행됩니다, 이런 경우 백이면 백 실패합니다. 현업과 괴리된 시스템은 엑셀(EXCEL) 보다 불편하고, 일회용 홍보성 도구로 전락하기 마련입니다. BIM의 목적에 부합하는 현업 조직이 시스템을 주도해야 합니다.
물량 산출이 목적이라면 견적 조직, 도면 검토라면 설계 조직, 공법 검토라면 기술 조직이 중심이 되어야 합니다. 그러나 현실은 녹록지 않습니다. 대부분 실무 조직은 현업에 치여 BIM 같은 R&D성 업무에 관심 갖기 어려울뿐더러, BIM은 건설사에서 마이너 영역으로 취급되어 해당 조직에 배치되는 것 자체를 경력의 손해로 여기기도 합니다.
그 결과, 건설업 프로세스를 모르고 현장경험이 없는 BIM전문가들이 기간제 직원로 채용되어 BIM시스템을 개발하고 운영하는 비효율적인 구조가 생깁니다. 저도 초기에는 현업 전문가(견적, 기술, 설계) 없이 BIM 전문가 위주로 조직된 팀에서 꽤 오랜 시간 실효를 만들어내지 못했습니다. 이후 경영진의 강력한 의지에 힘입어 견적, 시공, 설계 조직의 전문가들을 수혈하고 지금과 같은 성공적인 체계를 만들어 낼 수 있었습니다. BIM은 일개 한 조직에서 하고 싶다고 할 수 있는 그런 단순한 영역은 아닌 거 같습니다. 결국 경영진의 강력한 의지가 핵심인 듯합니다.
Small Success
많은 조직이 BIM시스템을 구축할 때, 대동소이한 BIM 개발사로부터 견적을 받고 수십억 원의 투자부터 시작합니다. 그러다 2년쯤 지나면 후회를 넘어 환멸의 단계에 이르게 됩니다. BIM시스템 구축은 매우 복잡하며 많은 리소스가 투입되어야 합니다. 오랜 시간 성과 없이 R&D성으로 진행되면 큰 현타와 부담으로 '조직 내 힘이 아닌 짐'이 되는 경우가 많습니다.
그래서 처음에는 작은 실효부터 쌓아가는 전략이 필요합니다. 빠른 실효(그래도 3년입니다. 최초결의부터 정산까지 해야 하니까요)가 빨리 발생할 수 있는 영역을 선택한 후 엑셀과 매크로, 파이썬을 활용해 엑셀기반 시스템을 만들어 실효를 증명하고, 이게 성공적일 때 개발사를 통해 시스템을 구축해도 늦지 않습니다.
IT 개발사에 너무 의지해 BIM시스템을 시작하는 것은 결국 서로에게 비극을 초래합니다. IT는 건설을 모르고, 건설은 IT를 모릅니다. 같은 한국어를 사용하지만 생각을 전달하고 표현하는 방법이 너무 다릅니다. 결국 현업에서 문제를 정의하고, 원인을 분석하고, 해법을 모색하는 과정에서 도출된 로직이 실제적으로 완성된 후 그 로직을 기반으로 BIM개발자에게 주문하는 방식이어야 합니다.
이런 점에서 골조공사와 토공사는 매우 적합하다 볼 수 있습니다. 우선 내역의 개수가 많지 않습니다. 마감공사처럼 3,000개가 아닌 50~100여 개 수준으로 비교적 단순하며 모델링도 난이도도 높지 않아 추출 물량을 바탕으로 엑셀기반 내역화 구조를 만들기가 상대적으로 용이합니다. 마감공사는 골조공사와 토공사가 실효를 쌓고 난 후 시작하기를 권장드립니다. 골조사와 토공사는 노력 대비 성과의 발현이 정비례 그래프라면, 마감은 지루한 계단식 그래프 양상을 보입니다. 많은 노력과 정교한 설계가 요구되는 부분입니다. 이러한 마감공사 관련한 이야기는 딥(DEEP)한 부분이라 기회가 되면 다음에 다뤄 볼 예정입니다.
건설회사 업의 본질
건설회사는 건축물을 잘 짖는 게 업의 본질입니다. BIM을 잘하는 게 본질이 아닙니다. BIM이 없어도 많은 부분 충분히 잘해왔습니다. 단지 BIM은 '업의 본질'을 잘 이룰 수 있도록 돕는 보조체계일 뿐입니다. 이는 BIM 시스템 구축이 대단한 기술의 성취나 도입이 아니라, 건설 프로세스 내 협업 체계의 일부여야 함을 뜻합니다.
본사 유관팀, 현장, 협력사 별 역할과 소통 방식을 정립해야 합니다. 전사의 ERP 프레임워크나 업데이트 로드맵과도 궤를 같이해야 하며, 오토데스크, 트림블 등 설루션의 버전 업데이트에도 대응할 수 있어야 합니다. 심지어 윈도 업데이트도 고려 대상이 됩니다. 타이밍을 놓치면 시스템 개선과 운영에 추가 비용이 발생합니다. 모든 시스템이 BIM을 위해 돌아가는 게 아닌 만큼 BIM이 맞추어야 합니다.
BIM은 IT 업계에서 마이너 중에서도 마이너 영역입니다. 건설회사 내 디지털 부서에 BIM 전문인력이 없는 경우가 대다수입니다. 결국 사내에서 직접 운영할 수 있는 경우는 극히 드물다는 것이죠. 개별 S/W의 오류와 개선항목 등도 디지털부서의 도움보다는 BIM팀이 수시로 체크하고 협력사와 조율해야 합니다.
BIM 시스템에서 카카오톡, 쿠팡, 배달의민족 앱처럼 완성도 높은 UI/UX를 기대하기 어렵습니다. 저렴한 비용으로 건설회사의 소수 조직이 사용하기 위해 개발된 구조이기 때문입니다. 결국 UI/UX의 개선은 한계가 있으므로 현장과 본사에 대한 BIM교육을 통해 이를 극복해야 합니다.
무엇보다도 중요한 것은, 기존의 현업의 업무 프로세스와 유관팀과의 협업방식에 대해 구조적으로 명확히 정의되어야 한다는 점이다. 이러한 정의가 없으면 "실효와 가치를 쌓아가기는커녕, 효과가 미미한 영역에 양적인 노력만을 반복하며 리소스만 소모하는 씁쓸한 일이 발생할 수도 있습니다. 협업의 구조는 단지 사람 간의 연결이 아니라, 가치 있는 영역에 양적 반복을 설계하는 효율적 구조로 설계되어야 합니다
초창기 현장에 BIM 시스템 교육을 가면 현장관리자 대부분 관심도 없고, 들었다 해도 금세 잊어버립니다. 그래서 교육 방식을 바꿨습니다. 해당의 현장의 내역 교육을 메인으로 하고 BIM 시스템 교육을 곁가지로 하는 방식을 적용하여 확실한 실효를 느낄 수 있었습니다.
웹뷰어는 현장과 본사 유관팀 모두가 사용하게 됩니다. 이들의 계정 관리 및 사용자 피드백 수렴은 쉽지 않지만 반드시 필요한 운영 요소입니다. 이 모든 게 BIM조직이 현업에 녹아들기 위해 짊어지고 가야 하는 일입니다.
BIM 개발사 의존도 줄이기 : 도메인 날리지 중심
BIM 시스템은 BIM 개발사 중심이 아니라 현업 전문가 중심으로 설계되어야 합니다. BIM개발자는 현업의 의지와 논리를 구현하는 기술적 조력자여야 합니다. 형식적으로 취재된 현업 전문가의 조언으로 만들어진 비전문가 중심의 BIM시스템 개발은 현업 수용성과 사용자 사용성, 유지관리 측면에서 실패할 확률이 높습니다.
한편 도메인이 중심이 되려면 IT 소양을 겸비한 인력이 필요합니다. 솔직히 산삼만큼 구하기 어려운 게 현실이지만 저의 조직에는 건축학과 출신이면서 개발사 기획 경력이 있는 팀원이 시스템 관리의 메인 역할을 맡고 있습니다. 그 직원이 없었다면 시스템은 완성되지 못했을 것이며. 운영되지도 못했을 것입니다. 이는 전문 BIM개발사를 무시하는 것이 아니라, 외주 의존도를 최소화해야 한다는 뜻입니다. 최소한 시스템에 문제가 발생했을 때 그 원인이 사용자의 입력 잘못인지 시스템의 오류인지 정도는 아는 지식이 필요합니다.
데이터 디자인과 확장 전략
우리가 만든 BIM모델과 물량 데이터는 단순 출력물이 아닙디다. 향후 공사비를 예측하고, 품질 리스크를 분석하며, 미래 스마트건설 플랫폼과의 연동되어야 합니다. 그러기 위해선 데이터를 표준화하고 구조화하는 작업이 선행되어야 합니다. BIM 데이터는 매트릭스 형태로 정리되고 축적되어야 합니다. 그렇다고 해서 모든 BIM 로우 데이터를 시스템에 다 업로드하는 것은 비효율적입니다. 방대한 용량은 시스템을 느리게 하고, 사용성을 떨어뜨립니다. 따라서 정제된 데이터만 시스템에 업로드하고, 로우 데이터는 별도의 서버에 보관하는 구조로 설계되어야 합니다. 이렇게 해야 시스템은 경량화되고, 운영과 유지보수도 용이해집니다. 이러한 전략을 통해 저의 조직은 실제로 성공적인 시스템을 구축했고, 실효를 확보해가고 있다.
지속 가능한 길
BIM 시스템 구축은 단순한 프로그램 도입이 아닙니다. 그것은 우리 업무를 어떻게 정의하고, 어떻게 협업하며, 어떤 데이터를 남길지를 결정하는 전략적 선택입니다. 크고 복잡한 그림에서 출발하지 말고 실효가 있는 작은 성공에서 시작해, 시스템으로 확장해가야 합니다, 그것이 현실적이고, 지속 가능한 BIM 시스템 구축의 길일 것입니다.
