1. 서 론
1.1 연구의 배경 및 목적
1.2 연구의 범위 및 방법
1.3 문헌조사
2. BIM 품질검사규칙 프레임웍 설계
2.1 룰셋 구조
2.2 데이터 처리 구조 설계
2.3 조건 문법 정의
2.4 LLM 추론 기반 품질검사 조건
4. 구현 및 실험
4.1 시스템 구현 환경
4.2 테스트
4.3 테스트 결과
5. 토 론
6. 결 론
1. 서 론
1.1 연구의 배경 및 목적
건설 산업에서는 BIM (Building Information Modeling)의 도입으로 인해 다양한 포맷의 디지털 자산이 생성되고 있다. 대표적으로 IFC는 건축 및 구조 모델을 표현하고, COBie는 자산 정보와 유지관리 데이터를 표준화된 스프레드시트 형식으로 제공한다. 이러한 BIM 데이터들은 서로 다른 형식, 작성 도구에 의해 생성되며, 동일한 프로젝트 내에서도 다양한 포맷이 동시에 사용된다. 그러나 BIM 데이터의 품질을 관리하고 검증하기 위한 기존의 품질검사 도구들은 대부분 특정 포맷이나 특정 BIM 저작 도구에 종속되어 있다. IFC 모델은 Solibri, Revit 등과 연계한 전용 검사 도구로 품질을 확인하지만, COBie, LandXML 등의 경우 별도 스크립트나 수작업 기반의 검토 방식이 일반적이다.
이처럼 포맷마다 별도의 검사 방식과 규칙을 적용해야 하는 구조는 품질검사의 일관성과 확장성, 유지보수성을 저해하는 주요 원인이 된다. 이런 문제는 하나의 데이터 품질 규칙 기준을 다양한 포맷에 걸쳐 반복 정의하도록 한다.
건설 프로젝트에서의 BIM 데이터 품질관리는 단순히 형식 오류를 넘어서, 속성값의 정합성, 코드 일관성, 규격 기준 충족 여부, 충돌(clash) 여부까지 다양한 검사 항목을 포함한다. 이를 체계적으로 자동화하기 위해서는 각 포맷에 독립적이면서도 유연한 규칙 정의 체계가 필요하다. BIM 프로젝트는 단계에 따라 데이터의 상세 수준이 다르고, 모델링 방식이 상이하다는 점에서, 품질검사 룰셋은 유연성과 재사용성을 함께 갖춰야 한다. 데이터 품질 검사를 중립적 표현 형식으로 정의하는 규칙 문법은 이러한 필요에 대응할 수 있다. 또한, 품질 검사규칙 문법에 대규모 언어모델(LLM, Large Language Model)을 적용할 수 있다면, 일부 모호한 검사 대상 데이터에 대한 검사 방법 추론 및 평가가 가능하다. 이를 통해, 명확한 수치 조건 외에도 모호한 형식의 데이터 기반의 조건까지 평가할 수 있는 가능성이 생기고 있다.
본 연구는 다양한 BIM 데이터 품질 관리를 위한 정형문법 기반 품질검사 규칙 프레임워크를 제안하고, 이를 실험적으로 구현 및 평가한다. 본 연구는 다양한 BIM 데이터 형식에 공통적 적용가능한 Key-Value 기반의 규칙 체계를 제시하며, LLM은 이 문법 내에서 특정 유형의 복잡하거나 비정형적인 검사 조건을 자동화하기 위한 보조적인 기술으로 범위를 한정한다.
1.2 연구의 범위 및 방법
본 연구는 다양한 BIM 관련 데이터 포맷에 독립적인 BIM 품질검사 규칙 문법을 정의하고, 해당 문법 기반으로 BIM 데이터의 정합성, 누락, 충돌 여부를 자동으로 검사할 수 있는 프레임웍을 개발하는 것을 목적으로 한다. 본 연구는 목표로 한다.
∙ 다양한 포맷의 BIM 데이터를 단일 품질 규칙 구조로 검사가능한 Key-Value 형식의 문법 정의
∙ BIM 데이터 모델(IFC, COBie)와 검사 규칙의 분리
∙ 비정형 데이터에 대한 LLM 기반 검사 규칙 설계
Figure 1은 본 연구 방법을 정의한 흐름도이다.
연구 프로세스(Figure 1) 중 프레임웍 설계 부분은 다음 단계로 정의된다.
1.2.1 BIM 검사 룰셋 구조 정의
품질검사 규칙의 계층 구조, 규칙 그룹화 방식을 설계한다. 이를 통해, 파일 포맷 독립적이며, 다양한 조건을 통합적으로 관리할 수 있는 기반을 마련한다.
1.2.2 BIM 데이터 처리 설계
BIM 데이터의 추출, 변환, 매핑 과정을 정의하며, 포맷에 따라 상이한 데이터 구조를 중간 표현으로 통일하는 데이터 처리 파이프라인을 설계한다.
1.2.3 조건 형식 정의
품질검사 규칙을 Key-Value 기반으로 표현할 수 있는 형식 문법을 정의한다. 규칙 문법은 사용자 친화적이며 포맷 독립적으로 작성 가능하도록 설계된다. 데이터 검사 조건을 range, list, equation, code, script로 유형화하고, 각 유형에 따라 처리 로직과 해석 방법을 정의한다.
1.2.4 LLM 추론 기반 조건 형식 정의
검사할 데이터에 대한 추론 및 해석이 필요한 경우는 LLM 기반 추론 기능으로 처리할 수 있도록 설계한다.
설계된 프레임워크를 기반으로 품질검사 시스템의 프로토타입을 구현하고, IFC 및 COBie 파일을 대상으로 실제 검사를 수행하여 기능과 정합성을 검증한다. 실험 결과를 기반으로 프레임워크의 효용성, LLM의 적용 가능성, 포맷 독립성의 범위, 확장성 등에 대해 논의하며, 향후 개선 방향과 한계점을 제시한다.
1.3 문헌조사
기존 연구는 대부분 IFC 중심의 품질검사에 국한되어 있으며, 룰셋의 정의 방식이 비표준적이거나 특정 포맷에 종속된 경우가 많다. 최근 buildingSMART의 IDS(Information Delivery Specification) 등 형식화된 요구사항 정의 기술이 제안되고 있으나, IFC 외의 포맷에는 적용이 어렵다. 한편, LLM을 활용한 규정 해석 및 조건 평가 연구도 시작되고 있으나, 정형 데이터와의 연계 측면에서는 초기 단계이다. 본 연구는 이러한 한계를 보완하고 포맷 독립적 품질검사 문법의 실용적 구현 사례를 제시한다.
BIM과 IFC 데이터를 AI 모델과 통합하기 위한 전처리의 중요성을 분석한 연구가 있었다(Du et al., 2024). 이 연구는 AI 통합을 위한 IFC 데이터 정규화 기준을 제시하고, BIM 속성의 데이터 완성도를 평가하는 기준을 정립하고자 하였다.
LLM을 활용해 BIM 모델의 자재 정보를 외부 데이터베이스와 매칭하는 방식을 제안한 연구가 있었다(Forth et al., 2024). 도메인 특화 데이터를 기반으로 LLM을 파인튜닝하고, IFC 속성의 불명확한 설명을 자동 해석하여 시멘틱 품질을 개선하는 데 초점을 맞추고 있다.
PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) 접근법을 통해 디지털 트윈과 BIM의 통합을 분석한 연구가 있었다(Afzal et al., 2023). 해당 연구는 품질검사 및 모델 신뢰성을 확보하기 위한 구조화된 BIM 정보의 중요성을 강조하였다.
기하학적 특징과 관계 기반 정보를 동시에 처리하는 딥러닝 프레임워크를 제안하여, BIM 객체의 분류 정확도를 향상시킨 연구가 있었다(Luo et al., 2022). 이는 객체 사전 분류 단계의 자동화를 가능할 수 있다.
유지관리 중심의 BIM 데이터 품질 향상을 위한 품질검사 도구를 개발한 연구가 있었다(Leygonie et al., 2022). 이 연구는 사용자 피드백 기반 반복 개선 체계를 설계하고 Dynamo 스크립트를 통해 IFC 속성의 누락 및 오기재 문제를 해결하고자한다.
디지털 트윈 기반 이상 탐지 프레임워크에서 BIM 데이터를 활용하여 시설 관리 효율을 향상시킨 연구가 있었다(Xie et al., 2020). 이 연구는 IFC 속성과 센서 데이터의 정합성이 이상 탐지 성능에 큰 영향을 준다고 언급하였다.
이러한 선행 연구들은 BIM 데이터를 효과적으로 활용하기 위한 정규화, 딥러닝 기반 객체 분류, LLM 활용 가능성 연구를 통해, 데이터 품질 관리 방법을 개선할 수 있는 방안들을 보여주고 있다. 본 연구는 이런 연구를 기반으로, BIM 데이터 품질검사를 위한 정형 규칙과 LLM 추론 방식을 융합한 BIM 품질검사규칙 프레임웍을 설계하고, 프로토타입 개발을 통해 효과를 분석한다.
2. BIM 품질검사규칙 프레임웍 설계
2.1 룰셋 구조
BIM 데이터의 품질검사를 효과적으로 수행하기 위해서는, 데이터가 표현되는 형식에 구애받지 않고 공통적으로 적용 가능한 규칙 정의 방식이 필요하다. 그러나 현재 산업에서 사용되는 대표적인 BIM 데이터 형식들, 예컨대 IFC와 COBie는 구조적 특성이 서로 상이하다.
IFC는 객체지향 구조를 기반으로 하며, 각 객체(Entity)는 고유의 속성과 관계를 포함한 계층적 구조를 가진다. COBie는 스프레드시트 기반의 테이블 구조로, 시트(Sheet)는 객체 유형에 대응하고 각 행(Row)은 개별 객체 인스턴스를, 열(Column)은 속성을 나타낸다.
이러한 차이에도 불구하고, BIM 데이터는 대부분 다음과 같은 공통 구성 요소를 포함한다:
1. 객체(Entity): 공간, 문, 설비와 같은 의미론적 단위
2. 속성(Attribute): 객체의 상태나 특성 (예: 이름, 유형, 치수)
3. 속성값(Value): 속성에 저장된 실제 데이터
4. 관계(Relationship, 선택적): 객체 간의 연계 정보 (예: 포함 관계, 참조 관계)
이와 같은 구조적 유사성은 데이터 표현 방식이 달라도 동일한 데이터 검사 항목을 일반화와 정형화된 검사 규칙으로 표현할 수 있는 가능성을 제시한다. 따라서, 다양한 포맷 간 호환성과 재사용성을 고려한, BIM 파일 포맷에 독립적인 일반화된 규칙문법 정의가 가능하다.
이러한 규칙 요소는 다음과 같은 기본 구성으로 모델링될 수 있다:
∙ entity: 검사 대상 객체 유형
∙ attribute: 검사 대상 속성
∙ condition: 속성값에 적용할 검사 조건
각 BIM 포맷에서 entity와 attribute를 어떻게 매핑할지, 포맷 정보를 어떻게 지정할지(file_format) 등은 실행 단계에서 해당 파일 포맷을 파싱해 내부적으로 처리될 수 있다. 파일 포맷의 다양함에 관계 없이 데이터 품질검사 논리의 표현과 실행이 포맷 구조로부터 분리되도록 하여, 데이터 품질검사의 논리를 재활용하고 확장할 수 있다.
각 요소는 품질검사 대상 모델의 표현 방식과 무관하게 일관된 규칙 표현이 가능하도록 설계되었으며, 이를 기반으로 구조화된 Key-Value 형식의 규칙 기술 문법을 구성할 수 있다. 참고로, Key-Value 형식은 사전처럼 지식을 표현한 것으로 Value를 다시 Key-Value로 정의함으로써 계층적인 지식 표현이 가능하다.
품질검사 규칙은 상위 수준에서 project(프로젝트)와 validation_rules(검사 규칙)로 구성된다. project는 검사 프로젝트의 이름, 설명, 버전, 작성자 등의 메타정보를 포함하고 있으며, 이는 프로젝트 단위의 품질검사를 체계적으로 관리하기 위한 정보 구조로 기능한다. validation_rules는 실제 검사 수행에 사용되는 rule(규칙) 집합이며, 각각은 하나의 entity 유형에 대해 독립적으로 정의된다.
각 검사 규칙 집합은 entity, file_format (파일형식), classification_system (분류체계), notify (검사결과 통보정보) 등의 메타 정보와 함께 하나 이상의 checks (검사목록)을 포함한다. 여기서 entity는 검사 대상 객체 유형을 의미하며, IFC의 IfcDoor, IfcSpace, 또는 COBie의 Space, Component 등의 데이터 단위가 해당된다. file_format은 본 규칙이 적용 가능한 파일 확장자를 명시함으로써, 하나의 룰셋이 다양한 포맷 구조에 대해 재사용될 수 있다.
각 check 항목은 하나의 속성 단위 품질검사 정의를 의미한다. name (검사규칙명)과 description (기술)은 검사의 의미적 정의를 설명하며, attribute는 검사 대상 속성명을 지정한다. 속성은 BIM 모델 내 실제 데이터 필드와 연결되며, 포맷에 따라 IFC의 속성명 또는 COBie의 열 이름으로 매핑된다.
핵심적으로 condition (검사조건) 요소는 속성값에 적용되는 검사 조건을 정의하며, 그 구조는 조건의 type(유형)에 따라 세분화된다. type은 정형적 수치 비교부터 비정형적 의미 해석까지 다양한 조건 유형을 지원하며,
이와 같이 구성된 품질검사 규칙 문법은 포맷의 구조적 차이를 일반화하고, entity, attribute, condition이라는 공통 요소 기반으로 검사규칙을 정규화한다. 각 조건은 모듈화되어 시스템 내 파서에 의해 처리될 수 있도록 모델형식 해석모듈(validate_ifc, validate_cobie)과 연동되어 실제 BIM 모델 데이터에 적용된다.
앞의 요구사항은 Key-Value 형식 규칙문법으로 다음과 같은 JSON (JavaScript Object Notation) 구조로 정의될 수 있다.
{
"validation_rules": [
{
"name": "COBie data check",
"entity": "Space",
"file_format": [".xlsx", ".csv"],
"checks": [
{
"name": "Area Check",
"attribute": "GrossArea",
"condition": {...}
},
]
}
}
Figure 2는 앞에서 기술된 요구사항을 설계한 UML 클래스 다이어그램으로, BIM 품질검사 모듈 간 역할과 상호작용을 나타낸다. validate 모듈을 중심으로, 검사 규칙의 해석, 조건 평가 등 전체 BIM 데이터 품질검사 흐름의 구조를 정의한다. Table 1은 클래스 각 멤버의 역할을 기술한다.
Table 1.
BIM data quality check rule framework class definition
2.2 데이터 처리 구조 설계
앞서 정의된 검사규칙 프레임웍을 이용해 BIM 데이터를 처리하기 위한 구조는 다음과 같다.
S1.규칙 파일 로딩 및 파싱: 시스템은 입력된 JSON 규칙 파일을 파싱하여 project, validation_rules 등 최상위 구조를 읽어들인다. 이후 검사 대상 BIM 파일에 대응되는 file_format에 해당하는 규칙만을 필터링하여 적용 대상 집합으로 구성한다.
S2.파일 포맷 판별 및 포맷별 객체 추출: 검사 대상 BIM 데이터 파일의 포맷을 확장자 또는 내부 마크업을 기반으로 식별하며, 각 포맷별로 설계된 파서 모듈을 통해 해당 entity 유형의 객체 목록을 추출한다. 이 과정은 포맷 특화 함수로 위임된다.
S3.속성값 추출 및 조건 평가: 각 객체에 대해 지정된 속성값을 추출하고, 조건 유형에 따라 적절한 평가 함수를 선택하여 검사 결과를 산출한다. 조건은 정형(logic- based) 조건(range, list, equation)과 비정형(semantic- based) 조건(LLM)으로 나뉘며, 조건의 type 필드에 따라 분기 처리된다.
S4.검사 결과 기록: 각 검사 수행 결과는 객체 식별자, 규칙 이름, 검사 항목, 조건 평가 결과(pass/fail)로 구성되며, 내부 기록 구조에 저장된다. 사용자가 지정한 알림 대상(notify) 또는 후속 자동처리를 위한 메타정보도 병렬적으로 처리된다.
S5.결과 출력: 최종적으로 검사 결과는 설정에 따라 PDF, Excel, 또는 BCF 등의 형식으로 출력되며, report_ generator 모듈에서 렌더링 및 저장이 수행된다.
다음은 데이터 처리 구조를 의사코드로 기술한 것이다.
Procedure QualityCheck(Rules, DataFileBIM)
ruleset ← ParseRule(Rules)
fileFormat ← DetectFileFormat(DataFileBIM)
For each rule in ruleset.validation_rules do
If fileFormat ∈ rule.file_format then
entityType ← rule.entity
checks ← rule.checks
entities ← ExtractEntities(DataFileBIM, entityType)
For each entity in entities do
For each check in checks do
attr ← check.attribute
value ← GetAttribute(entity, attr)
condition ← check.condition
result ← evaluate(entity.id, entity, condition)
RecordResult(entity.id, check.name, result)
End for
End for
End if
End for
ExportReport()
End Procedure
2.3 조건 문법 정의
BIM 데이터의 품질을 정량적이고 체계적으로 검증하기 위해서는, 파일 형식과 무관하게 적용 가능한 일반화된 데이터 품질 요구사항의 식별이 선행되어야 한다. 이를 위해 설계, 시공, 유지관리 단계에서 빈번히 요구되는 데이터 검증 유형을 분석하였고, 그 결과 다음과 같은 핵심 품질검사 요구 범주가 도출되었다.
C1. 허용값 범위 검증
특정 속성이 물리적 또는 논리적으로 허용되는 수치 범위 내에 있어야 함
C2. 목록 값 검증
속성값이 미리 정의된 허용값 목록 중 하나에 포함되어야 함. 예) 공간용도는 {Office,Toilet,Corridor} 중 하나이다.
C3. 속성 간 관계식 검증
두 개 이상의 속성 간 수치적 관계 또는 수식을 만족해야 함. 예) 순면적 = 총면적 - 공용면적
C4. 속성의 존재 유무 또는 형식 규칙 검증
속성이 누락되지 않아야 하며, 형식이나 규칙(코드 형식, 접두사 등)을 따라야 함. 예) 자산 번호는 'EQP-'로 시작해야 한다.
C5. 복합 조건 또는 외부 로직 검증
여러 조건이 조합되거나 외부 정의된 계산 로직이 필요함. 예) 스크립트를 통해 사용자 정의 조건 실행
C6. 간섭 체크 검증
각 유형의 형상 간 기하학적 간섭이 체크될 수 있어야 함. 예) 벽체와 다른 구조물
C7. 비정형 규정의 해석 및 의미기반 판단
명확한 수식이 아닌 텍스트 기반 규정을 해석해 판단해야 함
검사 조건은 다양하게 확장가능하며, 특히 LLM 타입을 통해 고정된 논리식을 넘는 유연한 조건 검사가 가능하다. 본 연구의 품질검사 룰셋은 조건(condition)에 따라 검사의 논리를 정의하며, JSON 기반 설정으로 구성된다. 조건 유형별로 요구되는 필드와 사용 예시를 Table 2에 정의하였다.
Table 2.
Condition grammar definition
2.4 LLM 추론 기반 품질검사 조건
규칙 기반 검사는 속성의 값이 명확한 수치나 정해진 목록일 때에는 유효하지만, 텍스트 속성이 복잡하거나 의미 해석이 필요한 경우에는 한계가 있다. 예를 들어 "출입구는 900 mm 이상의 유효 폭을 가져야 함"과 같은 조건은 수치와 문맥 해석이 동시에 요구되며, 기존 룰로 처리하기 어렵다.
LLM 기반 검사는 다음과 같이 구성된다.
attribute: 검사 대상 속성 (예: Element.Name)
condition.type: 'LLM'
condition.prompt: 조건에 대한 자연어 기술 (예: "Check whether the value meets minimum door clearance standards.")
LLM은 프롬프트를 기반으로 해당 속성이 조건에 부합하는지 판단하고, 내부적으로 결과를 True/False로 반환한다.
4. 구현 및 실험
4.1 시스템 구현 환경
본 연구에서 제안한 BIM 품질검사 프레임워크는 Python 3.10을 기반으로 개발되었으며, 다양한 BIM 파일 포맷을 처리하고 JSON 기반의 품질검사 규칙을 해석 및 실행하기 위한 통합적 환경에서 구현되었다(Figure 3).
전체 시스템은 사용자의 입력과 데이터 처리, 결과 출력 및 시각화까지의 전 과정을 자동화하는 구조로 구성되며, 웹 기반 사용자 인터페이스, BIM 데이터 파서, 검사 로직 모듈, 시각화 및 리포트 출력 모듈로 구성된다.
사용자 인터페이스는 IFC 또는 COBie 파일과 JSON 형식의 품질검사 룰셋을 입력받고 검사 결과를 시각적으로 출력할 수 있도록 한다. BIM 데이터의 구조적 파싱을 위해 IfcOpenShell 라이브러리를 사용하였다. COBie 파일은 Pandas를 활용하여 Excel 기반의 시트 데이터를 계층적으로 파싱하였다.
BIM 데이터 검사 로직은 Python 내부 모듈인 rule_checker, rule_condition등을 통해 구성되었으며, JSON 기반 룰셋 파일을 파싱하여 해당 조건을 각 객체 속성에 적용한 뒤 검사 결과를 반환한다. rule_condition 모듈은 조건 유형에 따라 range, list, equation, code, script, LLM 등으로 분기 처리하며, 특히 LLM 유형의 경우 외부 API 호출(예. OpenAI GPT-4o 등)을 통해 조건 해석 및 판별을 수행한다.
검사 결과는 report_generator 모듈을 통해 자동으로 정리되며, PDF, Excel, BCF 등의 포맷으로 결과 리포트를 생성한다. PDF와 Excel은 품질검사 결과를 테이블 형태로 시각화하며, BCF (BIM Collaboration Format)는 BIM 협업에서 발생하는 이슈를 관리하는 데 사용된다. 간섭체크는 IFC 객체 간의 기하학적 충돌 여부를 IfcOpenShell과 Numpy 연산을 기반으로 분석하고 시각적으로 결과를 생성한다.
전체 시스템은 웹 기반 앱으로 설계되었으며, 특정 플랫폼이나 소프트웨어에 종속되지 않기 때문에 다양한 환경에서의 적용이 가능하다.
4.2 테스트
우선, 본 연구에서 제안하는 포맷 독립적인 BIM 데이터 품질검사규칙 프레임워크의 유효성을 테스트하기 위해, 복층 규모의 오피스 건물 모델(“Duplex_A_20110907.ifc”)과 연구소 시설물 관리 데이터셋인 COBie 파일(“COBie_KICT.xlsx”)을 테스트 데이터로 활용하였다. 이들 파일은 각각 BIM 설계 모델과 자산정보 모델을 대표하며, 파일 형식의 차이에도 불구하고 동일한 개념적 품질검사 규칙을 적용할 수 있는지 검증하는 데 목적이 있다(Figure 4).
이를 위해 개발된 JSON 기반의 규칙정의 파일(“bim-check- config.json”)에 명시된 검사 대상 entity, attribute, condition을 기반으로, 포맷 추상화 계층을 통한 통합 검사 수행 절차를 정의하였다.
정의된 검사항목은 총 7개의 규칙 집합(validation_rules)으로 구성되어 있으며, 그 중 COBie 파일에 대해서는 entity가 “Space”로 설정된 항목이 하나 존재하고, 나머지 항목은 IFC 형식에 대해 “IfcSpace”, “IfcDoorStyle”, “IfcZone”, “IfcSystem” 등 다양한 엔티티를 대상으로 한다. COBie 엔티티 "Space"는 Excel 파일 내의 Component 시트에서 Name, Category, CreatedBy, CreatedOn 등 속성과 함께 정의되어 있으며, JSON 규칙에서는 이 중 GrossArea, Category, Classification 속성이 검사 대상 속성으로 명시되어 있다. 마찬가지로 IFC 모델에서는 IfcSpace 엔티티가 동일한 검사 목적을 위해 사용되며, 속성은 IFC property set (PSet_Revit_Dimensions, PSet_Revit_Identity Data) 내부에서 추출된다.
속성 검사 조건은 JSON 규칙의 condition 항목에 정의되며, 주요 검사 유형은 range, equation, list, code, script, LLM 등으로 분류된다. 실험에서는 range 조건을 통해 공간의 면적 속성이 300~320㎡ 범위에 존재하는지, 또는 오차를 포함해 허용 범위를 만족하는지를 검증하고, list 조건은 공간 분류 코드가 특정 규칙식(정규표현식)을 만족하는지를 확인한다. code와 script 조건은 내부적으로 파이썬 코드를 해석하거나 외부 파일을 실행함으로써 복잡한 규칙을 평가한다. 특히 IFC 파일에 대해서는 classification 속성이 OmniClass 코드 체계에 맞는지 여부를 검사하며, script_file을 호출하여 모델 전체의 구조적 일관성을 확인하는 루틴도 포함된다.
실험 수행 절차는 다음과 같다. 우선, 시스템은 JSON 규칙 파일을 로딩하고, 대상 파일의 포맷을 판별한다. 이후, 포맷에 따라 COBie 또는 IFC 파서를 호출하여 해당 entity를 추출하고, 각 객체별로 규칙에 명시된 attribute 값을 수집한다. 수집된 값은 정의된 condition의 유형에 따라 조건 평가 함수로 전달되며, 그 결과는 내부 저장소에 기록된다.
다음은 테스트를 위해 정의한 주요 BIM데이터 품질검사문법 구조를 보여준다.
{
"validation_rules": [{
"name": "COBie Area Range Check",
"entity": "Space",
"file_format": [".xlsx"],
"checks": [{
"attribute": "GrossArea",
"condition": {
"type": "range",
"min": 300,
"max": 320,
"units": "m2"
}}]},
{
"name": "IFC Classification Code Check",
"entity": "IfcSpace",
"file_format": [".ifc"],
"checks": [{
"attribute": "Classification",
"condition": {
"type": "code",
"code":
"print(value)\n
self.add_result_in_check(object_id, check, 'manual code check', False)"
}}]},
{
"name": "IFC clash check",
"entity": "IfcBuildingElementProxy",
"file_format": [".ifc"],
"classification_system": "uniclass(2015), omniclass",
"notify": "BIM-coordinator@gmail.com",
"checks": [{
"name": "Clash detection check in IFC",
"description": "Ensure there are no clashes between walls and other elements",
"clash_check_file": "walls.ifc",
"condition": {
"type": "collision",
"option": "each_file",
"entity": "IfcWall"
}}]},
{
"name": "IFC Door Clearance Check by LLM",
"entity": "IfcDoorStyle",
"file_format": [".ifc"],
"checks": [{
"attribute": "Element.Name",
"condition": {
"type": "LLM",
"model": "gpt-4o",
"prompt": "Verify the value which has learance width of at least 900mm and height of 2100mm."
}}]}
]}
4.3 테스트 결과
제안된 BIM 품질검사규칙 프레임워크를 실증적으로 평가하기 위하여, 본 연구는 IFC 및 COBie 형식의 BIM 데이터를 대상으로 JSON 기반 품질검사 규칙을 적용하고, 자동화된 검사 결과를 분석하였다. 검사는 총 34건의 조건에 대해 수행되었으며, 이 중 4건이 통과(Pass)되고 30건이 실패(Fail)하였다(Figure 5). 본 절에서는 우선 통과한 사례를 중심으로 분석하고, 이어서 데이터 품질상의 결함을 보인 사례들을 항목별로 기술한다.
검사에 통과한 항목은 IFC 파일 내 'IfcSpace' 엔티티에 대한 'Functional Category Validation' 검사로, 공간의 분류코드가 미리 정의된 규칙 목록과 일치할 경우 성공으로 판정되었다. 검사에 사용된 기준은 OmniClass Table 13의 코드 '13-51 24 11'이며, 이는 일반 주거 공간(General Residential Space)에 해당한다. GUID가 '0BTBFw6f90Nfh9rP1dlXrr', '0BTBFw6f90Nfh9rP1dlXri', '0BTBFw6f90Nfh9rP1dl_3Q', '0BTBFw6f90Nfh9rP1dl_3G'인 공간 객체들이 해당 기준을 만족하여 통과한 것으로 기록되었다. 이 결과는 JSON 규칙 파일의 리스트 기반 검사 조건이 IFC 모델 내 속성값과 정확히 일치할 경우 유효하게 작동함을 보여준다(Figure 6).
반면, 전체 검사 항목 중 다수를 차지한 실패 사례들은 주로 다음과 같은 세 가지 유형의 데이터 품질 결함에서 기인하였다.
첫째, 속성값의 자료형 오류 및 비정상적 값 처리 문제
둘째, 분류 체계 불일치 및 목록 외 코드 사용
셋째, 모델 구조 내 객체 미존재, 식별자 불일치 문제
예를 들어, COBie 형식에 대한 “COBie data check” 검사에서는 'Space' 엔티티의 'GrossArea' 속성에서 수치형 범위 조건 및 수식 기반 조건('value > 100')이 동시에 적용되었으나, 해당 속성의 값이 문자열로 처리되어 'is not a number' 및 '>’ not supported between instances of 'str' and 'int'와 같은 오류가 발생하였다. 이는 COBie 엑셀 시트 내 입력값이 비정형적으로 기록되어 있어, 데이터 타입 정합성이 확보되지 않았음을 의미하며, 사전 파싱 시 타입 강제 변환 또는 정규화가 필요함을 시사한다. 또한 동일 엔티티의 'Category' 속성은 규칙에 정의된 분류 리스트('SL_25_10_14', 'SL_20_15_59')와 일치하지 않아 불일치로 평가되었으며, 'Classification'에 대해서도 코드 기반 검사가 실패하였다.
LLM 기반의 의미 해석 검사는 'IfcDoorStyle' 엔티티의 'Element.Name' 속성에 적용되었다. LLM을 이용한 프롬프트 기반 조건에서는 문 너비가 900 mm 이상, 높이가 2100 mm 이상일 것을 요구하였으나, 전체 6개 객체가 해당 조건을 충족하지 못하였다. 예를 들어, '28VDfyq51BtxN68z6Brpvs'는 1250 mm × 2010 mm, '2S67XPaW1CHg1jrMmPps_z'는 762 mm × 2032 mm로 각각 높이나 너비 조건을 위배하였다. 이러한 결과는 규격 기반 공간 조건이 설계 도면 내에서 일관되게 지켜지지 않음을 의미하며, 규정기반 검사 외에도 의미 기반 평가가 실질적인 품질검사 요소로 활용될 수 있음을 보여준다.
IFC의 'IfcSpace'에 대한 분류 검사에서는 총 20건 이상의 객체가 실패하였다. 이들은 대부분 “13-51 24 11: Residential Space”, '13-85 21 11: Stairway', '13-81 31: Service Distribution Spaces', '13-11 19 11 11: Kitchen' 등의 OmniClass 코드 값을 갖고 있었으나, JSON 규칙에 정의된 허용 목록에 포함되지 않아 조건을 만족하지 못했다(Figure 7). 이는 설계에서 사용된 분류코드와 품질검사 기준 간의 체계 정합성 부재를 반영한다.
또한, 다수의 규칙('IFC clash check', 'IFC zone data check', 'IFC system data check')에서는 “No objects found”라는 오류 메시지가 출력되었으며, 이는 검사 대상 파일 내에서 해당 엔티티 인스턴스를 찾을 수 없음을 의미한다. 이와 같은 실패는 설계 모델과 규칙 정의 간의 데이터 범위 불일치 또는 잘못된 엔티티 매핑 설정에서 발생하며, 실제 데이터 검출 단계에서의 사전 유효성 검사가 요구된다.
검사 결과를 종합하면, 본 프레임워크는 다양한 BIM 포맷(IFC, COBie)에 대해 JSON 기반의 정형화된 규칙을 일관성 있게 적용하고, 다양한 검사 조건 유형에 대해 효과적으로 대응할 수 있음을 확인할 수 있었다. 특히 LLM, 리스트, 코드 기반 조건 등 다양한 방식의 조건 해석이 포함됨으로써, 단순한 수치 검증을 넘어서 설계 논리와 의미 기반 기준을 아우를 수 있는 유연성을 확보하였다. 그러나 실험 결과는 동시에 현재의 BIM 데이터가 다수의 속성 오류, 분류 불일치, 구조적 결함을 포함하고 있음을 명확히 보여준다.
품질검사 결과는 BCF (Figure 8), PDF, spreadsheet 형식 보고서로 출력된다.
5. 토 론
본 연구에서 제안한 품질규칙 문법은 IFC, COBie 등 다양한 BIM 포맷에 걸쳐 공통적으로 적용 가능함을 테스트를 통해 검증하였다. 각 포맷의 데이터 구조에 종속되지 않도록 데이터 검사 로직과 데이터 소스를 명확히 분리함으로써, 재활용 측면에서 확장성과 유연성을 확보할 수 있다.
LLM은 기존 규칙 기반 검사로 처리하기 어려운 조건, 예를 들면, 자연어 설명 기반의 건축 규정 해석, 불명확한 텍스트 속성 검토 등에 대해 의미 있는 성능을 보여준다. 다만, 프롬프트의 설계 방식에 따라 결과의 신뢰도와 일관성이 달라질 수 있으므로, 적절한 LLM이 적절한 품질검사 함수호출을 생성하는 것이 향후 활용도를 높이는 핵심 전략이 될 것이다.
LLM은 외부 API 호출을 기반으로 하므로 대용량 데이터에 대해 처리 지연이 발생하였다. 이를 개선하기 위해 프롬프트의 간소화, LLM의 로컬 추론 환경 도입이 필요한 것으로 보인다. LLM 호출은 API 비용과 데이터 보안 이슈를 수반하므로, 장기적으로는 자체 구축된 LLM 모델 등이 고려될 필요가 있다.
6. 결 론
본 연구는 다양한 BIM 데이터 포맷에 종속되지 않는 정형문법 기반 품질검사규칙 프레임워크를 제안하고, JSON 기반 품질규칙 문법과 LLM 기반 보조 검사 기능을 결합한 자동화 도구를 설계, 구현하였다. 제안된 시스템은 다음과 같은 주요 특징이 있다.
1. 포맷 독립적인 품질검사 규칙 구조를 정의하고, 공통 규칙을 IFC, COBie 등 다양한 데이터에 적용 가능하다.
2. 검사 조건 유형별로 range, list, equation, LLM 등의 다채로운 조건을 체계화하여, 수치형, 분류형, 추론형 속성까지 포괄할 수 있는 유연한 검사 방식을 지원한다.
3. LLM은 기존 방식으로 처리할 수 없었던 자연어 기반의 규정 해석, 추론 등의 기능을 BIM 데이터품질검사에 적용할 수 있다.
단, 본 연구는 한정적인 BIM 데이터셋을 사용해 테스트한 한계가 있다. 향후, 다양한 BIM 데이터셋에 대해 테스트하고, BIM 속성 자동 분류 및 조건 매칭을 위한 RAG (Retrieval Augmented Generation) 및 에이전트 기반 프롬프트 컨텐츠 생성 기술, 프로젝트 요구사항 기반 시나리오 검사 기술 등을 연구할 계획이다.
