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

■ bSDD란 무엇인가

bSDD는 표준화된 분류(Classification)와 속성(Property), 그리고 허용값을 온라인으로 검색·참조할 수 있게 해 주는 중앙 집중식 RESTful API 서비스다. 하나의 사전(dictionary, 곧 class system)은 특정 조직이 소유·관리하는 객체 정의·속성·재료의 표준 묶음을 뜻한다. 예를 들어 buildingSMART가 발행하는 IFC 사전, 전기·설비 분야의 ETIM, 각국 정부·협회가 올린 분류 체계가 모두 bSDD 안에 나란히 존재한다. 핵심은 이 정의들을 IFC 모델과 IDS(정보요구사항 명세)에서 그대로 참조할 수 있다는 점이다. 즉 모델 안의 속성 하나하나를 '전 세계가 합의한 사전의 그 항목'에 못 박아 연결할 수 있다. 또 하나 중요한 사실은 bSDD가 콘텐츠를 검색하는 것도, 공개 콘텐츠를 발행하는 것도 무료라는 점이다.

■ 왜 '표준 사전'이 필요한가 — 속성 이름의 혼란

개방형 BIM의 목표는 소프트웨어가 달라도 정보가 손실 없이 오가는 것이다. 그런데 형상(geometry)은 IFC로 잘 교환되어도, 정작 그 객체가 '무엇이며 어떤 성능을 갖는지'를 서술하는 속성은 이름이 통일돼 있지 않으면 자동 검증이 불가능하다. 발주처가 "모든 방화문의 내화등급을 확인하겠다"고 해도, 설계·시공·제조사가 각기 다른 속성 이름을 쓰면 시스템은 무엇을 읽어야 할지 알 수 없다. bSDD는 각 항목에 언어와 무관한 고유 식별자(bSDD-GUID)를 부여해, 이름 표기가 어떻든 전 세계에서 동일한 객체와 속성을 하나로 식별하게 만든다. 라벨은 한국어·영어·독일어로 달라도, 가리키는 실체(GUID)는 하나다. 이것이 '기계가 읽는 합의'의 출발점이다.

■ bSDD의 데이터 구조

bSDD는 BIM에서 쓰이는 객체 개념(분류), 그 속성과 허용값을 담은 계층형 사전이다. 원래 근거 표준인 ISO 12006-3의 상속 구조(Root→Object→Concept→Subject/Property)는 상당히 복잡하지만, bSDD는 이를 실무가 다루기 쉽게 Class와 Property 두 단계로 단순화했다. 주요 구성 요소를 표로 정리하면 다음과 같다.

■ 근거가 되는 국제 표준

bSDD는 임의로 만든 사전이 아니라 세 개의 ISO 표준 위에 서 있다. 첫째, ISO 12006-3(2022)은 객체지향 정보의 프레임워크로, 사전을 언어 독립적으로 구축하는 데이터 모델을 정의한다. 둘째, ISO 23386은 속성을 기술·관리하는 방법론을, 셋째 ISO 23387은 건설 객체의 데이터 템플릿(속성 묶음의 구조)을 규정한다. 이 세 표준을 근거로 삼기 때문에 bSDD에 올라온 정의는 특정 벤더나 특정 소프트웨어에 종속되지 않는다. 표준에 기반한다는 점이 곧 '오래 신뢰할 수 있는 참조'라는 뜻이다.

■ IFC·IDS와 어떻게 연결되는가

bSDD의 진짜 가치는 홀로 존재할 때가 아니라 IFC·IDS와 물릴 때 나온다. IFC 모델에서는 객체의 분류나 속성을 bSDD의 특정 Class/Property GUID에 연결(reference)할 수 있다. 그러면 그 속성은 '이 프로젝트에서만 통하는 이름'이 아니라 '사전에 등록된 그 항목'이 된다. IDS(Information Delivery Specification)는 "이런 객체는 이런 속성을 반드시 가져야 한다"는 정보요구사항을 기계가 검증 가능한 형태로 적는 표준인데, 이때 요구하는 속성을 bSDD로 지정하면 검증 규칙 자체가 국제 표준 사전을 근거로 서게 된다. 정리하면 IDS가 '무엇을 요구하는가'를, bSDD가 '그 무엇의 표준 정의'를, IFC가 '실제 담긴 값'을 담당하는 삼각 구조다. 이 셋이 맞물릴 때 비로소 사람이 일일이 열어보지 않아도 정보 교환과 검증이 자동으로 돌아간다.

■ API 활용 워크플로

bSDD는 JSON과 RDF를 반환하는 REST API, 그리고 GraphQL API를 함께 제공한다. 전형적인 사용 흐름은 세 단계다. ① 사용할 수 있는 Dictionary 목록을 조회하고, ② 그 안에서 필요한 Class를 검색한 뒤, ③ 해당 Class의 상세 정보와 Property를 요청한다. 이 흐름을 BIM 저작 도구의 플러그인이나 검수 서버가 내부적으로 호출하면, 모델러가 속성을 입력할 때 표준 후보를 자동으로 제시하거나, 준공 모델을 검수할 때 속성이 표준 정의와 일치하는지 자동으로 대조할 수 있다. GUID 기반이므로 다국어 환경에서도 매핑이 흔들리지 않는다.

■ 분류 체계(Uniclass·OmniClass)와는 어떻게 다른가

현장에서 자주 나오는 오해가 "bSDD는 또 하나의 분류 코드 아니냐"는 것이다. 그렇지 않다. Uniclass, OmniClass 같은 분류 체계는 '이 객체를 어떤 범주로 코딩할 것인가'에 초점을 맞춘다. 반면 bSDD는 이런 여러 분류 체계와 속성 정의를 한자리에 담아 두는 상위 '그릇'에 가깝다. 실제로 bSDD 안에는 IFC 사전뿐 아니라 여러 국가·기관의 분류 체계가 각각의 Dictionary로 올라와 있어서, 서로 다른 분류 코드를 같은 GUID 기반 구조로 참조하고 매핑할 수 있다. 즉 bSDD는 분류 체계를 대체하는 것이 아니라, 흩어진 분류·속성을 표준 형식으로 담고 서로 연결해 주는 중립 지대다. 이 점을 이해해야 "우리가 쓰던 분류 코드를 버려야 하나?"라는 불필요한 걱정에서 벗어날 수 있다.

■ 실제 시나리오로 보는 bSDD

구체적인 상황을 그려 보자. 발주처가 준공 모델에 대해 "모든 외벽에 열관류율(U-value) 값이 표준 정의대로 들어가 있어야 한다"고 요구한다. 과거라면 발주처·설계·시공사가 회의를 열어 "속성 이름을 U_Value로 통일하자, 단위는 W/m²K로 쓰자"고 약속하고, 그 약속을 문서로 관리해야 했다. 그러나 사람이 손으로 맞춘 규칙은 담당자가 바뀌거나 소프트웨어가 달라지면 금세 어긋난다. bSDD 방식에서는 발주처가 요구하는 '열관류율' 속성을 bSDD 사전의 특정 Property GUID로 지정하고, 이를 IDS 규칙에 담아 배포한다. 그러면 설계사가 어떤 저작 도구를 쓰든, 검수 서버가 IDS를 돌릴 때 그 GUID를 기준으로 값의 존재·형식·단위를 자동 대조한다. 말싸움이 될 '이름'을 기계가 읽는 '식별자'로 바꾸는 순간, 협의는 검증으로 바뀐다.

■ 국내 도입 현황과 한계

국내에서도 buildingSMART Korea를 중심으로 개방형 BIM 표준 확산이 이어지면서 IFC·IDS와 함께 bSDD에 대한 관심이 커지고 있다. 다만 아직은 한계도 분명하다. 첫째, 국내 실무에서 쓰는 속성·재료 명칭이 표준 사전에 충분히 등재돼 있지 않아, 필요한 항목을 직접 발행하거나 매핑해야 하는 초기 비용이 든다. 둘째, 사전에 항목이 있어도 저작 도구가 bSDD 참조를 매끄럽게 지원하지 않으면 실무 적용이 번거롭다. 셋째, 다국어 라벨 관리와 버전 관리에 대한 사내 규칙이 없으면 오히려 혼란이 생길 수 있다. 그럼에도 방향은 분명하다. 정보요구사항을 사람이 문서로 관리하는 시대에서, 기계가 표준 사전을 근거로 자동 검증하는 시대로 넘어가는 흐름에서 bSDD는 그 사전의 자리를 맡는다.

■ 실무 도입 팁

처음부터 사내 모든 속성을 bSDD에 맞추려 하면 부담이 크다. 현실적인 순서는 (1) 발주처·프로젝트가 요구하는 핵심 속성(내화등급, 강도, 열관류율 등)부터 bSDD의 IFC 사전 항목에 매핑하고, (2) 그 매핑을 IDS 규칙에 반영해 자동 검증 파이프라인에 얹은 다음, (3) 반복되는 사내 표준을 별도 Dictionary로 발행해 재사용하는 것이다. 속성 이름을 손으로 통일하려는 시도는 프로젝트가 끝날 때마다 다시 무너지지만, GUID로 사전에 못 박아 두면 다음 프로젝트에서도 그대로 재사용된다. bSDD는 화려한 기능이 아니라 '전 세계가 같은 단어를 같은 뜻으로 쓰게 만드는' 조용한 기반 시설이며, 개방형 BIM이 형상 교환을 넘어 정보 교환으로 나아가는 열쇠다.

■ 정리 — 왜 지금 bSDD를 알아야 하는가

BIM의 무게 중심은 형상에서 정보로 옮겨 가고 있다. 발주처는 예쁜 3차원 모델이 아니라 유지관리·자산관리에 바로 쓸 수 있는 '믿을 수 있는 데이터'를 요구하기 시작했고, 그 데이터가 표준을 따르는지 기계가 검증하기를 원한다. IDS가 요구사항을 기계 언어로 적고, IFC가 값을 담고, 그 사이에서 '무엇이 표준인가'를 정의하는 사전이 bSDD다. 이 세 축을 모르고 개방형 BIM을 논하면, 결국 속성 이름을 회의로 맞추던 옛 방식으로 되돌아가게 된다. 반대로 이 구조를 이해하고 핵심 속성부터 사전에 못 박아 두는 팀은, 프로젝트가 바뀌고 담당자가 바뀌어도 흔들리지 않는 정보 기반을 갖게 된다. 지금 bSDD를 익혀 두는 것은 다가올 정보 중심 BIM 시대의 문법을 미리 익히는 일이다.