buildingSMART IDS 1.0 — BIM 정보요구사항을 기계가 검증하는 표준

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

■ 정보 요구사항을 기계가 검증한다는 것

기존 발주 문서의 요구사항은 ‘모든 외벽에는 내화 성능 속성을 기입할 것’ 같은 자연어 문장이었다. 사람은 이해하지만 프로그램은 해석하지 못하므로, 검수는 결국 수작업이 됐다. IDS는 같은 요구를 ‘외벽(IfcWall, 외부)이라는 조건에 해당하는 요소는 Pset_WallCommon의 FireRating 속성을 반드시 가져야 한다’처럼 구조화된 규칙으로 바꾼다. 이렇게 적어 두면 설계사는 납품 전에 스스로 IFC 모델을 IDS에 돌려 자가 검증하고, 발주처는 같은 IDS 파일로 동일하게 검사한다. 요구하는 쪽과 제출하는 쪽이 하나의 ‘정답지’를 공유하는 셈이다.

■ IDS의 구조: Specification / Applicability / Requirements

IDS 파일은 하나 이상의 명세(specification)로 이뤄지며, 각 명세는 두 축으로 나뉜다.

구성	역할	예시
Applicability (적용 대상)	이 규칙을 어떤 요소에 적용할지 걸러내는 조건	‘외부에 면한 IfcWall’
Requirements (요구 조건)	걸러진 요소가 만족해야 할 조건	‘FireRating 속성을 가질 것’

즉 ‘누구에게(Applicability)’와 ‘무엇을 요구하는가(Requirements)’를 분리해 적는 구조다. 이 덕분에 ‘해당하지 않는 요소’는 애초에 검사 대상에서 빠지고, 해당하는 요소만 조건을 따진다. 각 요구에는 카디널리티(cardinality)를 지정해 required(필수) / optional(선택) / prohibited(금지) 중 하나로 ‘반드시 있어야/있어도 되고/있으면 안 되는’ 성격을 규정할 수 있다.

■ 여섯 가지 Facet

Applicability와 Requirements를 적을 때 쓰는 기본 단위가 ‘facet(패싯)’이다. IDS 1.0은 여섯 종류의 facet을 제공한다.

Facet	검사 대상	예시
Entity	IFC 클래스(요소 종류)와 predefined type	IfcWall, IfcDoor
Attribute	IFC 요소의 기본 속성(스키마 고정)	Name, Description 값 존재
Property	속성집합(Pset) 안의 사용자·표준 속성	Pset_WallCommon.FireRating
Classification	분류체계 코드 부여 여부	Uniclass, OmniClass 코드
Material	재료 지정 여부·재료명	Concrete, Steel
PartOf	다른 요소와의 관계·소속	특정 층·시스템에 속함

facet은 값의 ‘정확히 일치’뿐 아니라 정규식·범위·enum 같은 제약으로도 지정할 수 있어, 예컨대 ‘FireRating 값이 30/60/90 중 하나’ 같은 조건까지 기계 검증이 가능하다.

■ IDS-XML과 IFC 자동검증 워크플로

IDS는 XML 기반이며 XSD(XML Schema Definition)로 형식이 고정돼 있어, 어떤 도구가 만든 IDS든 다른 도구가 동일하게 해석한다. 실무 흐름은 대체로 다음 순서를 따른다.

단계	내용
1. 요구 정의	발주·BIM 지침의 정보 요구사항을 IDS(.ids)로 작성
2. 배포	설계·시공사에 IDS 파일을 ‘검증 규칙’으로 함께 전달
3. 자가 검증	제출자가 납품 전 IFC 모델을 IDS로 검사(IfcTester 등)
4. 접수 검증	발주처가 같은 IDS로 제출본을 재검사, 결과 리포트 생성
5. 피드백	미충족 항목만 반려·보완, 재제출

대표적인 오픈소스 도구로 IfcOpenShell 계열의 IfcTester가 여섯 facet을 모두 지원해 IDS 작성과 IFC 검증을 함께 처리하며, buildingSMART도 IDS 파일 자체의 유효성을 점검하는 감사 도구(IDS Audit Tool)를 제공한다. 검증 결과는 요소별 통과/실패로 리포트되므로, 어떤 요소의 어떤 요구가 왜 실패했는지 추적할 수 있다.

■ 눈여겨볼 것

IDS의 진짜 효과는 ‘검사를 자동화한다’를 넘어 ‘요구사항을 명확하게 만든다’는 데 있다. 서술형 요구는 사람마다 해석이 갈리지만, IDS로 옮기려면 ‘어떤 요소에, 어떤 속성을, 어떤 값 범위로’를 끝까지 확정해야 하므로 요구 자체의 모호함이 드러나고 정리된다. 다만 IDS는 ‘정보가 있는가’를 검증할 뿐 ‘그 값이 사실인가’를 보장하지는 않는다. FireRating 칸이 채워졌는지는 확인해도 그 성능이 실제로 맞는지는 별개이므로, IDS는 형식 검수의 강력한 도구이되 설계 검토를 대체하지는 않는다.

■ 이런 분께 도움이 됩니다

BIM 발주·검수 담당자 — 정보 요구사항을 IDS로 표준화해 제출본을 자동·일관되게 검수하고 반려 근거를 남길 수 있다
설계·시공 BIM 실무자 — 납품 전 자가 검증으로 누락 속성을 미리 잡아 재제출을 줄일 수 있다
BIM 지침·표준 담당자 — 국내 지침의 속성 항목을 IDS로 정리해 배포하면 참여사 간 해석 차이를 없앨 수 있다

■ 참고

IDS 1.0은 buildingSMART가 GitHub에 스키마(XSD)와 문서를 공개하고 있으며, 관련 도구도 대부분 오픈소스로 내려받아 쓸 수 있다. 실무 적용 시에는 국내 BIM 지침이 요구하는 속성 항목을 IDS로 옮기되, 사용하는 저작도구가 해당 속성을 어떤 Pset 이름과 데이터형으로 내보내는지 먼저 확인해야 한다. facet의 속성집합명·속성명이 실제 IFC 내보내기 결과와 어긋나면, 모델에 값이 있어도 검증에서 ‘누락’으로 잡히기 때문이다.