SMART LAB

서로 다른 소프트웨어로 만든 BIM 모델을 열어 보면 같은 '방화문'인데도 어떤 모델은 속성 이름이 FireRating, 다른 모델은 내화등급, 또 다른 모델은 fire_resist로 적혀 있다. 사람 눈으로는 같은 뜻이지만 컴퓨터는 이 셋을 전혀 다른 데이터로 취급한다. 이렇게 속성 이름과 분류 체계가 프로젝트마다, 회사마다, 나라마다 제각각인 문제를 풀기 위해 buildingSMART가 운영하는 국제 표준 사전이 바로 bSDD(buildingSMART Data Dictionary)다. 이번 글에서는 bSDD가 무엇이고, 어떤 구조로 되어 있으며, IFC·IDS와 어떻게 맞물려 실무에 쓰이는지 정리한다. ■ bSDD란 무엇인가 bSDD는 표준화된 분류(Classification)와 속성(Property), 그리고 허용값을 온라인으로 검색·참조할 수 있게 해 주는 중앙 집중식 RESTful API 서비스다.…

LOD(Level of Development)는 BIM 모델을 구성하는 각 요소가 어느 정도까지 구체화되었고, 그 정보를 협업 상대가 어디까지 신뢰해도 되는지를 단계로 정의한 기준이다. 같은 벽이라도 기획 단계에서는 대략의 위치와 두께만 있으면 되지만, 시공 단계에서는 마감재·상세 치수·시공 정보까지 담겨야 한다. LOD는 이 차이를 100·200·300·350·400·500이라는 단계로 나눠, 모델을 주고받는 사람들이 ‘이 요소를 어디까지 믿고 써도 되는가’를 합의하게 해 준다. 핵심은 LOD가 ‘모델을 얼마나 자세히 그렸는가’가 아니라 ‘그 정보가 어느 수준의 의사결정에 쓰일 수 있는가’를 나타내는 공통 언어라는 점이다. ■ AIA가 만든 LOD, BIMForum이 채운 틈 LOD 개념은 미국건축사협회(AIA)의 계약 문서 체계(E202, 이후 G202)에서 정립됐다.…

모델 검토에서 문제를 발견하면 보통 화면을 캡처해 이메일로 보낸다. 받는 쪽은 그 그림을 보고 자기 모델에서 같은 자리를 다시 찾아야 한다. BCF(BIM Collaboration Format)는 이 왕복을 없애기 위해 만들어진 개방형 포맷이다. 이슈 하나에 제목·설명·담당자·상태 같은 정보와 함께, 그 순간의 카메라 위치·방향(뷰포인트)과 관련 요소의 GUID, 화면 스냅숏을 담는다. 받는 쪽에서 열면 뷰가 그 지점으로 이동하고 해당 요소가 선택된 상태가 된다. Tekla와 Solibri가 처음 만들었고 지금은 buildingSMART가 관리하는 표준이며, XML 기반이라 특정 회사 제품에 묶이지 않는다. Revit·ArchiCAD·Navisworks·Solibri·BIMcollab 등 주요 도구가 모두 읽고 쓴다. ■ BCF가 담는 네 가지 BCF의 핵심은 "무엇이 문제인지"를…

건물을 다 짓고 나면 설계와 시공 과정에서 쌓인 정보가 대부분 흩어진다. 어떤 펌프가 어디에 몇 대 들어갔고 보증 기간이 언제까지인지를 유지관리 담당자가 처음부터 다시 조사하는 일이 반복돼 왔다. COBie(Construction Operations Building information exchange)는 이 정보를 준공 시점에 정해진 형식으로 넘기기 위한 표준이다. 시설과 층, 공간, 요소, 유형, 시스템, 예비품, 자원, 작업, 문서, 연락처 같은 시트로 나뉜 표 구조를 갖고, 스프레드시트(xls)나 IFC 형태로 주고받는다. 핵심은 형상이 아니라 대장(臺帳)에 가깝다는 점이다. 3차원 모델을 열지 않아도 표만으로 어떤 자산이 어디에 있는지 읽을 수 있고, 유지관리(FM·CAFM) 시스템에 그대로 올릴 수 있다. 영국은 공공 발주에서…

개방형 BIM(openBIM)의 표준 교환 포맷인 IFC(Industry Foundation Classes)의 4.3 버전이 2024년 국제표준 ISO 16739-1:2024로 확정 발행됐다. 정식 명칭은 ‘Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema’다. 이번 판의 가장 큰 의미는 그동안 건축물 위주였던 IFC의 적용 범위가 도로·철도·교량·수로·항만 같은 토목 인프라 영역까지 넓어졌다는 데 있다. 특정 소프트웨어에 종속되지 않고 서로 다른 도구 사이에서 모델을 주고받는 개방형 BIM의 무대가 건물을 넘어 사회기반시설 전체로 확장된 것이다. ■ IFC와 개방형 BIM이란 IFC는 buildingSMART International이 관리하는 중립(vendor-neutral) 데이터 스키마다. A사 설계도구에서 만든 모델을…

발주처가 요구한 속성이 BIM 모델에 제대로 들어갔는지 확인하는 일은 지금까지 사람이 눈으로 훑거나 회사마다 다른 체크 스크립트에 기대 왔다. buildingSMART는 ‘요구사항 자체를 기계가 읽고 검증할 수 있는 형식으로 적어 두자’는 취지로 IDS(Information Delivery Specification)를 만들었고, 2024년 6월 1.0이 정식 표준으로 승인됐다. 그 전의 0.9.x 계열은 모두 베타였다. IDS는 ‘IFC 모델이 무엇을 담아야 하는가’라는 정보 요구사항을 서술형 문장이 아니라 컴퓨터가 해석 가능한 규칙으로 표현해, 검수를 자동화하는 것을 목표로 한다. ■ 정보 요구사항을 기계가 검증한다는 것 기존 발주 문서의 요구사항은 ‘모든 외벽에는 내화 성능 속성을 기입할 것’ 같은 자연어 문장이었다. 사람은 이해하지만…

BIM 협업에서 서로 다른 소프트웨어를 쓰는 참여자끼리 모델을 주고받을 때는 IFC(Industry Foundation Classes) 표준 포맷을 사용한다. IFC는 buildingSMART가 관리하는 개방형 표준으로, 특정 프로그램에 종속되지 않고 형상·속성·관계 정보를 함께 담는다. 건축은 Revit, 구조는 Tekla, 협업 검토는 ArchiCAD처럼 도구가 갈라져 있어도, 각자 IFC로 내보내면 하나의 통합 모델(federated model)로 겹쳐 볼 수 있다. 다만 원본의 파라메트릭 편집 기능은 그대로 유지되지 않으므로, IFC는 조율·검토·정보 교환용으로 쓰고 실제 설계 수정은 원본 저작 도구에서 하는 것이 원칙이다. 이 글은 IFC 교환에서 실무자가 반드시 확인해야 할 설정과, 자주 깨지는 항목을 정리한다. ■ 내보내기 전에 정하는 것 —…

프로젝트가 커질수록 Revit 파일(.rvt)이 무거워져 열기·저장·동기화 속도가 급격히 느려진다. 원인의 상당 부분은 프로젝트에 로드된 패밀리(Family) 하나하나가 품고 있는 불필요한 지오메트리와 중복 재질이다. 패밀리 500개짜리 프로젝트에서 패밀리당 평균 200KB를 덜어내면 그것만으로 100MB가 빠진다. 이 글은 패밀리가 비대해지는 원인, 정리해야 할 항목, 상세수준(Detail Level)을 활용한 가시성 최적화, 안전한 클린 절차, 라이브러리 관리까지 실무 기준으로 정리한다. ■ 패밀리는 왜 비대해지는가 가볍게 만들 수 있는 패밀리가 수 MB로 부푸는 데는 정형화된 원인들이 있다. 정리 대상을 항목별로 구분해야 무엇을 지울지 판단이 선다. 비대 원인발생 경위영향처리 과도한 형상(High-poly)제조사 제공 모델의 나사·라운드까지 3D로 표현화면·용량 부하 급증먼 시야에…

Revit이나 ArchiCAD에서 만든 모델을 IFC로 내보내 Navisworks·Solibri 같은 통합검토 도구에서 열면, 모델이 원점에서 수 킬로미터 떨어진 허공에 뜨거나 여러 공종 모델이 서로 어긋나는 일이 자주 벌어진다. 원인은 거의 항상 좌표계 설정, 그 중에서도 공유좌표(Shared Coordinates)의 이해 부족이다. 이 글은 Revit의 세 가지 좌표 기준을 명확히 구분하고, 공유좌표의 Acquire/Publish 동작, 진북(True North)과 회전, IFC 내보내기 좌표 옵션, 그리고 어긋남이 발생했을 때의 점검 절차까지 순서대로 정리한다. ■ Revit의 세 좌표 기준 — 반드시 구분한다 Revit에는 성격이 다른 세 개의 좌표 기준점이 있다. 이 셋을 혼동하는 것이 좌표 사고의 근본 원인이다. 기준점정체역할이동 여부…

BIM 프로젝트는 건축·구조·설비(MEP) 팀이 Revit, Tekla, MagiCAD, ArchiCAD 같은 서로 다른 저작 도구로 동시에 모델을 만든다. 이 구조에서 가장 자주, 가장 비싸게 터지는 사고가 "누가 최신본을 가지고 있는지 모르는" 파일 버전 충돌이다. 어긋난 버전 위에서 며칠을 작업한 뒤에야 발견되면, 그 사이의 도면·수량·간섭검토 결과가 통째로 무효가 된다. 이 글은 버전 충돌이 생기는 근본 원인부터 파일 명명규칙, 공통데이터환경(CDE), 체크인·체크아웃과 잠금, 실무 운영 규칙까지 현장에서 바로 쓸 수 있는 수준으로 정리한다. ■ 버전 충돌은 왜 생기는가 — 세 가지 근본 원인 현장에서 관찰되는 충돌은 대부분 다음 세 가지 중 하나로 수렴한다. 원인을 구분해야…