1. 서 론
2. 관련 연구 및 배경
2.1 IFC와 Revit의 표현 차이
2.2 Revit 내장 IFC 가져오기
2.3 관련 연구: 전통적 상호운용성과 LLM 기반 접근
3. 재구성 방법
3.1 파이프라인 개요
3.2 Stage 1: IFC 파싱
3.3 Stage 2: IronPython 스크립트 생성
3.4 Stage 3: Revit 실행
3.5 Stage 4: 검증
4. 실험 및 결과
4.1 실험 설정
4.2 재구성 결과
4.3 버전 간 재현성(cross-version)
4.4 주목 사례
4.5 내장 IFC 가져오기와의 비교
4.6 레벨별 분해(L1·L2·L3)
5. 논 의
5.1 문제의 비자명성과 실무 가치
5.2 방호시설에의 적용
5.3 한계
6. 결 론
1. 서 론
IFC(Industry Foundation Classes)는 buildingSMART가 제정한 개방형 BIM 데이터 교환 표준 ISO 16739-1(ISO, 2024)으로, 이종 저작도구 간 상호운용성의 근간을 이룬다. 주요 BIM 저작도구는 모두 IFC 내보내기를 지원하며, 이 정방향, 즉 저작도구에서 IFC로 내보내는 경로는 수년간의 표준화·인증을 거쳐 발전해 왔다.
그러나 그 역방향, 즉 IFC를 다시 편집 가능한 네이티브 객체로 되돌리는 경로는 불완전하다. ArchiCAD 등 타 저작도구의 IFC를 Revit으로 가져오면 결과가 한 모델 안에서도 일관되지 않는다. 일부 부재는 파라메트릭 네이티브 객체로 재구성되지만, 일부는 카테고리만 부여된 일반 인스턴스로 들어오며, 타입·레이어·재료 같은 의미 속성과 원본 좌표 배치도 온전히 보존되지 않는다. 수신자는 어떤 부재가 어느 쪽으로 갈지를 사전에 예측하거나 가져오기 설정으로 제어할 수 없다. Revit이 제공하는 클래스 매핑은 IFC 클래스를 Revit 카테고리에 대응시키지만, 그 부재가 파라메트릭 네이티브로 재구성될지는 결정하지 못한다. 결과는 소스 IFC의 형상 표현·객체 유형·원본 저작도구·비공개 내부 변환 로직이 좌우하며, 처리 내역이 보고되지 않아 수신자는 개별 요소를 확인·수정해야 한다. 형상은 보이되 온전한 네이티브로 신뢰해 다룰 수 없는 상태가 된다.
이 단절은 여러 실무 시나리오에서 직접적 손실을 초래한다. 대표적으로 이종 저작도구 협업, 즉 ArchiCAD로 설계한 결과를 Revit에서 시공·상세 설계로 이어받는 경우에 IFC를 전달할 때 후속 엔지니어는 신뢰할 수 없는 형상을 받아 모델을 다시 구축해야 한다. 또한 Revit이 상위 버전 파일을 하위 버전에서 열 수 없어 IFC를 경유하는 버전 간 이전(cross-version), 레거시 IFC 자산의 편집 복구, 발주 성과물 재활용에서도 같은 문제가 반복된다. 특히 지하 대피소나 군사 기반시설과 같은 특수 방호시설은 시설물의 생애주기가 길고 높은 데이터 보안성과 무결성이 요구된다. 국내에서도 IFC 기반 이종 BIM 교환의 정보 손실이 보고되었고(Kim and Ock, 2009), 국방·군사시설 분야에서는 BIM 도입의 제약요인과 단계적 활성화 방안이 과제로 제기되었으며(Gong, 2017), 대피·방호 성격의 시설에서 정밀 BIM 정보모델이 시설 배치 결정의 근거로 활용된 바 있다(Kim et al., 2018). 따라서 특정 상용 소프트웨어에 종속되지 않는 개방형 BIM(IFC) 기반의 상호운용성 검증 기술이 이러한 시설에 요구된다.
이러한 정보 교환의 단절 문제를 해결하기 위한 일부 상용 도구에서의 부분적 시도도 있었으나, 구조 부재 등 특정 카테고리에 대하여 객체를 IFC에서 네이티브로 복원하는데 한정된다. 또한, 최근 대규모 언어모델(large language model, LLM)을 BIM 저작에 접목하는 연구가 늘고 있으나 대개 자연어 기반 생성·조회에 초점을 두었고, 서로 다른 저작도구가 만든 IFC를 하나의 방법으로 편집 가능한 네이티브에 되돌리는 문제, 즉 이종 저작도구 간(cross-tool) 재구성은 다루지 않았다.
본 연구는 이 공백을 다루기 위해 IFC를 편집 가능한 Revit 네이티브 객체로 재구성하는 4단계 결정론적 파이프라인을 제안한다. 파이프라인은 (1) IFC를 파싱해 요소·관계·좌표를 구조화 인벤토리로 추출하고(Parse), (2) 카테고리별 템플릿으로 Revit 생성 스크립트(IronPython)를 만들며(Generate), (3) 이를 Revit 내부에서 실행해 네이티브 객체를 생성하고(Execute), (4) 결과를 다단계 기준으로 검증한다(Verify). 변환·검증 경로 전 과정이 결정론적이어서 동일 입력에 동일 출력이 보장되며 환각·비결정성이 개입하지 않는다. 본 연구의 핵심 기여는 서로 다른 저작도구의 IFC를 단일 파이프라인으로 재구성하는 이종 저작도구 간 재구성하는 것이며, 동일 도구의 서로 다른 버전 간 변환도 가능하다는 것이다. LLM과 MCP(Model Context Protocol)는 Revit 모델 상태를 조회·점검하는 인터랙티브 레이어로 활용되었으며, 파이프라인 개발과 결과 검토를 위한 연구 수단으로 기능하였다.
2. 관련 연구 및 배경
2.1 IFC와 Revit의 표현 차이
IFC와 Revit은 건물 표현 방식이 다르다. IFC는 건물을 유형이 부여된 엔티티(IfcWall, IfcSlab, IfcColumn 등)와 이들을 잇는 관계(공간 포함, 개구부 호스팅, 부분–전체 분해)로 구성된 벤더 중립 그래프로 표현한다. 반면 Revit은 Family·Type·Instance 파라메트릭 계층으로 구성한다. Family는 부류의 파라메트릭 정의, Type은 그 특정 파라미터 조합(예: 두께 200 mm 콘크리트 벽), Instance는 위치·호스트·파라미터와 함께 배치된 실체다. IFC는 요소와 그 연결 관계를 기술하는 반면, Revit 객체는 파라메트릭 생성 규칙을 전제로 정의된다.
이 차이가 역방향 변환을 단순 형식 변환이 아니라 ‘재구성’ 문제로 만든다. 정방향은 이미 파라메트릭하게 정의된 객체를 중립 그래프로 변환하면 되지만, 역방향은 중립 형상으로부터 파라메트릭 생성 규칙을 복원해야 한다. 하나의 IfcWall을 편집 가능한 Revit Wall로 되돌리려면 형상 이동을 넘어 타입 선택·구성, 위치선 복원, 소속 레벨 결정, 개구부의 호스팅 Instance 재부착을 함께 수행해야 한다. 이 생성 맥락은 IFC 그래프에 명시되어 있지 않으므로, 임의의 IFC 기하로부터 이를 추론·복원하는 과정이 재구성 문제의 핵심이다. 내장 가져오기는 중립 스키마에서 파라메트릭 저작 트리로 가는 일반적 역함수가 없어 안전한 기본값을 택하며, 이로 인해 일부 요소를 파라메트릭 편집 정보 없이 가져오기도 한다.
2.2 Revit 내장 IFC 가져오기
IFC를 Revit으로 직접 가져오는 가장 보편적 경로는 내장 IFC 가져오기이며, 새 모델로 변환하는 ‘Open IFC’와 읽기전용 참조인 ‘Link IFC’로 나뉜다. 네이티브 재구성을 시도하는 경로는 Open이나, 1장과 같이 그 결과는 한 모델 안에서도 일관되지 않았고 타입·재료·배치가 온전히 보존되지 않았다(4.5절). 내장 가져오기는 가장 직접적·보편적 경로이므로 본 연구의 기준선이자 직접 비교 대상이 된다.
이 기준선의 한계는 다섯 축에서 구조적으로 드러난다. (1) 투명성: 어떤 요소가 네이티브로 재구성되고 어떤 요소가 일반 객체로 처리됐는지, 의미가 얼마나 보존됐는지 보고가 없어 요소별 확인 없이는 감사할 수 없다. (2) 예측성: 네이티브/일반 객체의 경계가 사전에 선언되지 않고 소스 IFC에 따라 달라진다. (3) 타입·속성 보존: IFC의 타입명·재질·두께가 Revit 네이티브 Type으로 이어지지 않는다. (4) 벤더 간 일관성: 같은 건물이라도 내보낸 저작도구에 따라 결과가 달라진다. (5) 다운스트림 지원: 제외된 요소 보고나 카테고리 오용 검토 같은, 받은 모델을 편집·활용하는 데 필요한 정보가 없다. 본 연구는 범위 확대가 아니라 정의된 카테고리 안에서 이 다섯 축의 결손 해소를 목표로 한다(범위·한계는 3·5장).
2.3 관련 연구: 전통적 상호운용성과 LLM 기반 접근
IFC 상호운용성의 한계는 오래전부터 정량 기록되어 왔다. Pazlar and Turk(2008)는 세 IFC 호환 소프트웨어 간 왕복 교환에서 IFC를 맹목적으로 신뢰할 수 없음을 처음 정량화했고, Muller et al.(2017)는 5년 간격 반복 실험에서도 구조 부재 중첩 등 핵심 문제가 지속됨을 확인하였다. Noardo et al.(2021)의 GeoBIM Benchmark는 동일 IFC를 Revit·ArchiCAD·Tekla로 처리했을 때 기하·의미·좌표계 결과가 소프트웨어마다 다름을 실증하여 구현체 간 불일치가 표준의 구조적 문제임을 보였다. 이는 본 연구 4.5절의 내장 가져오기 불균일 관찰과 부합한다. Pauwels et al.(2017)는 IfcOpenShell 기반 기하 표현·파싱 방법론을 정립했으나 기하 추출·검증에 초점을 두었고 네이티브 재구성은 다루지 않았다. Scan-to-BIM에서 Bassier and Vergauwen(2020)은 점군으로부터 Revit 네이티브 벽을 재구성했으나 입력이 센서 점군이며 IFC 의미 정보를 사용하지 않았다. 상용으로 CYPE의 Open BIM–Revit 플러그인이 구조 IFC에 한정해 네이티브 변환을 지원하나(CYPE Software, 2024), 임의의 건축 IFC 범용 재구성은 학술적으로 제시된 바 없다. buildingSMART도 IFC를 PDF에 비유하며 교환 포맷임을 공식화하였다(buildingSMART International, 2023).
LLM을 BIM 저작에 접목하는 연구는 자연어 기반 모델 생성(BIMgent(Deng et al., 2025), AI BIM Coordinator(Dong et al., 2025)과 IFC 직접 편집(MCP4IFC(Nithyanantham et al., 2025))으로 나뉜다. 그러나 이들은 입력이 자연어이거나 IFC를 입출력 양쪽으로 유지하여, 이종 저작도구 IFC를 단일 파이프라인으로 받아 Revit 네이티브로 재구성하는 문제는 대상이 아니다. 또한 생성·편집 경로에 LLM을 두어 출력이 확률적이며, 정확성·재현·감사가 중요한 재구성에는 결정론적 접근이 더 적합하다. 인접 연구인 Graph-DT-GPT(Pan et al., 2026)·IFC-Agent(Gao et al., 2026)는 그래프 디지털 트윈·IFC 스키마 조회·추론을 다루나 재구성과 목적이 다르며, 특히 Graph-DT-GPT의 LLM 출력을 구조화 데이터에 결속해 환각을 억제하는 방향은 변환 경로에서 LLM을 분리하는 본 연구와 문제의식을 공유한다.
종합하면 정방향이 발전해 온 반면 역방향은 미해결로 남아 있다. 문헌 조사 범위에서는 (a) 이종 저작도구 IFC를 변환 코어 재작성 없이 재구성하는 이종 저작도구 간 일반화, (b) 버전 간 이전 지원, (c) 동일 입력에 동일 출력을 보장하는 결정론적·재현 가능 변환을 동시에 만족하는 역방향 재구성 시스템은 제시되지 않았다. 본 연구는 이러한 연구 공백을 다룬다.
3. 재구성 방법
3.1 파이프라인 개요
제안 파이프라인은 IFC를 입력받아 Revit 네이티브 모델을 생성하는 네 단계로 구성된다. Stage 1(Parse)은 IFC를 파싱해 요소·관계·좌표를 카테고리별 구조화 인벤토리(JSON)로 추출하고, Stage 2(Generate)는 카테고리별 생성기가 이 인벤토리로부터 Revit 생성 코드(IronPython)를 만들며, Stage 3(Execute)는 그 코드를 Revit 내부에서 실행해 네이티브 객체를 생성하고, Stage 4(Verify)는 결과를 기준 모델과 다단계로 대조해 채점한다. Stage 1·2는 Revit 밖 CPython에서, Stage 3은 Revit 내부 IronPython(pyRevit)에서, Stage 4는 다시 외부 채점기에서 동작한다(Fig. 1). 변환 경로(Stage 1~3)는 전 과정 결정론적이다. 생성 코드는 카테고리별 템플릿에 인벤토리 값을 채워 만들어져 언어모델이 개입하지 않으므로 동일 입력은 동일 출력을 산출하고, 같은 구성이 서로 다른 저작도구의 IFC에 그대로 적용된다(4장).
3.2 Stage 1: IFC 파싱
Stage 1은 IfcOpenShell(IfcOpenShell Contributors, 2026)로 IFC를 순회하며 모든 건물 요소를 11개 생성 카테고리(벽·기둥·보·기초·슬래브·천장·문·창·커튼월·지붕·계단)로 분류해 구조화 인벤토리로 추출한다. IfcWall은 벽으로, IfcSlab은 PredefinedType에 따라 슬래브·기초·천장으로, IfcCovering은 천장, IfcStair는 계단으로 매핑되며, 각 요소의 기하 파라미터(위치·치수)와 타입·재질·속성을 함께 기록해 카테고리별 JSON으로 출력한다.
분류에 더해 Stage 1은 네이티브 재구성에 필요한 요소 간 관계도 복원한다. 즉 공간 포함(층 소속), 개구부 호스팅(문·창이 채우는 벽), 분해 관계(상위 요소 형상이 하위 부품에 나뉜 경우)를 추적한다. 일부 저작도구는 기둥을 내보낼 때 객체 자체에는 형상을 비우고 하위 부품에만 담는데, 이때 분해 관계를 따라 내려가야 형상을 복원할 수 있고 이를 놓치면 빈 객체가 되어 재구성에 실패한다(4장의 ArchiCAD 사례). 좌표는 요소 배치 정보와 형상 자체 위치를 합성해 산출한다.
3.3 Stage 2: IronPython 스크립트 생성
Stage 2는 인벤토리를 Revit 실행 코드(IronPython; IronLanguages, 2022)로 변환한다. 생성은 템플릿 기반이며 결정론적이다. 카테고리마다 하나의 생성기가 인벤토리의 기하·타입 값을 템플릿에 채울 뿐 언어모델이 개입하지 않으므로 동일 인벤토리는 동일 코드를 산출한다. 벽·기둥·보·슬래브처럼 수가 많은 카테고리는 한 스크립트당 수십 개 단위 배치로 나눈다. 생성 순서는 매니페스트 파일에 3단계로 정의된다. 전역 단계(레벨·패밀리·타입 등 문서 상태 준비), 층별 단계(각 층에서 벽·기둥·보·기초·슬래브·천장·문·창을 순서대로 생성), 후처리 단계(지붕·커튼월·계단처럼 다른 요소와의 결합 때문에 미뤄야 하는 카테고리)로 이루어진다. 예를들어, 커튼월은 호스트 벽과의 결합을 깨지 않도록 모든 벽·지붕 처리 후 삽입된다. 이 순서는 실행 순서 파일로 기록되어 Stage 3이 그대로 따른다.
3.4 Stage 3: Revit 실행
Stage 3은 실행 순서 파일을 읽어 각 스크립트를 구동 중인 Revit 세션에서 차례로 실행하며, 그 결과 네이티브 객체가 문서에 생성된다. 각 배치는 하나의 트랜잭션으로 묶이고, 처리 중 Revit이 경고(warning) 수준으로 분류한 비치명적 메시지와 무인 실행을 멈추는 대화상자만 자동 처리하며 오류(error) 수준 실패는 넘기지 않는다. 오류 처리는 건너뛰고 기록는 방식으로 진행된다. 즉 요소 생성이 오류로 실패하면 해당 트랜잭션을 롤백하고 그 요소만 건너뛰어 실패로 집계한 뒤 나머지를 계속 생성한다. 따라서 부분 결과가 보존되고 실패 요소는 Stage 4의 카테고리별 개수 검증에서 누락으로 드러난다. 문·창은 호스트 벽이 먼저 존재해야 하므로, 벽 생성 시 각 벽의 식별 정보를 기록해 두었다가 문·창 생성 시 해당 호스트를 찾아 연결한다.
3.5 Stage 4: 검증
Stage 4는 재구성 모델 품질을 정량 측정한다. 카테고리별로 요소를 추출해 기준 모델과 대조하여 다단계 루브릭으로 채점하며, 기준 모델은 두 종류를 쓴다. 첫째 원본 네이티브 대비(vs-native)는 재구성이 원저작 모델을 얼마나 복원했는지 측정하는 왕복 충실도로, Revit에서 저작 후 IFC로 내보내진 모델에 그 원본 Revit 모델을 기준으로 삼는다. 둘째 IFC 입력 대비(vs-IFC)는 재구성이 입력 IFC 내용을 얼마나 충실히 구현했는지 측정하는 입력 충실도로, 모든 대상에 동일 적용되며 특히 대응 Revit 원본이 없는 이종 저작도구 간(ArchiCAD) 사례에서는 유일하게 평가 가능한 기준이다. 두 평가를 함께 제시해 재구성 자체의 충실도와 IFC가 원본을 보존한 정도를 분리한다. 요소 상태 추출·조회는 pyRevit(Iran-Nejad, 2025) 확장으로 구현된 MCP(Model Context Protocol; Anthropic, 2024)를 통해 Revit에서 프로그램적으로 수행된다.
루브릭은 재구성 품질을 세 층위로 정량화한다. 기하학적 충실도(L1), 의미론적 충실도(L2), 편집 가능성(L3), 총 90점(Table 1)이다. L1·L2는 재구성·기준 모델을 자동 대조해 채점하고, L3는 기준과 무관하게 재구성 모델 자체에 실제 편집을 시도해 판정한다.
Table 1
Reconstruction quality assessment rubric (L1–L3, 90 points)
합계 지수에서 한 레벨 안의 지표는 완전히 독립적이지 않으나(요소 수량과 타입 매칭은 함께 변동함), L1(기하)·L2(의미)·L3(편집성)은 서로 다른 개념 축을 측정해 상보적이다. 형상은 정확하되 의미가 소실될 수 있고(4.5절의 내장 가져오기) 그 역도 가능하다. 합산은 세 축에 우선순위(기하 40 ≥ 의미 35 > 편집성 15)를 부여한 선언적 가중 모형이며 보상적이므로, 합계를 요약 지수로 보고하되 4.6절에서 레벨별 분해로 차이의 소재를 진단한다.
해당 배점이 모델 간 순위를 좌우하지 않음을 민감도 분석으로 확인하였다. 여덟 하위 지표를 정규화한 뒤 가중치를 ±30 % 범위에서 1,000회 무작위 교란해도 상대 순위는 강건했고(Spearman ρ 평균 0.99, 전 교란 ρ ≥ 0.93; 균등 가중에서도 ρ ≈ 1.00), 결론이 특정 배점에 과도 의존하지 않음을 확인할 수 있다. 다만 단일 층위(기하·의미)만의 순위는 종합과 ρ 0.65~0.81로, 각 층위가 종합으로 대체되지 않는 정보를 더한다.
L1은 카테고리별 개수 비율·좌표/치수 편차 등급화(예: 좌표 편차 50 mm 이하 만점)·요소에 부여된 레벨명이 원본 레벨 집합에 속하는지로 채점한다. L2에서 타입 매칭은 벽 타입 분포·기둥 구분·슬래브/천장 타입을, 관계 보존은 문·창의 호스트 벽 연결과 요소에 레벨이 부여되었는지를 대조한다. 속성 보존은 재료 의미를 레이어 기능(layer function)의 보존으로 평가한다. 재료명 문자열은 저작도구·로케일에 따라 달라 강건하지 못해 제외하고 표준 열거형인 레이어 기능을 대리 지표로 쓰며, 같은 이유로 명명 규칙·계단 타입명의 문자열 대조도 제외하였다.
L3는 다섯 편집(벽 파라미터·기둥 타입·슬래브 오프셋·레벨 표고 변경, 문 방향 전환; 각 3점)을 프로그램으로 시도해 판정한다. 각 편집은 시험 후 되돌려 모델을 변형하지 않는다. 이 속성들은 네이티브 요소에만 존재하므로 형상뿐인 플레이스홀더는 모두 실패한다. 즉 L3 성공은 편집 가능한 네이티브임을 자동 실증한다. 대상에 해당 카테고리가 없으면 실패가 아니라 적용 불가(N/A)로 처리하고 적용 가능한 편집 수를 분모로 표기한다(예: 5개 중 4개 적용, 12점). 다섯 항목은 서로 다른 편집 유형—인스턴스 파라미터 변경(벽), 타입 교체(기둥), 오프셋 변경(슬래브), 표고 변경(레벨), 방향 전환(문)—을 각각 대표하도록 선정되었으며, 재구성 대상 11개 카테고리 전부에 대한 편집 시험은 아니다.
평가 지표는 전 카테고리에 균일 적용된다. 기하 지표는 전 카테고리, 타입은 기준선에 해당 카테고리가 있을 때, 관계(호스팅)는 문·창처럼 성립하는 부재에 적용한다(Table 2). 부재 특성상 성립하지 않는 항목만 정당한 N/A로 제외·재정규화하며, 재정규화는 L1·L2에, L3는 적용 가능 편집 수 분모 표기를 쓴다.
Table 2
Evaluation metrics applied by category (✓ = applied, N/A = not applicable by member type)
4. 실험 및 결과
4.1 실험 설정
제안 파이프라인을 서로 다른 출처의 IFC 12개 모델에 적용해 재구성 품질을 측정하였다. 대상 IFC는 모두 IFC2X3 스키마이며(STEP 헤더 FILE_SCHEMA로 확인), IFC4 등 타 스키마 검증은 향후 과제다. 대상에는 Revit 계열 동일 저작도구 내(in-domain) 모델(RAC, 교육용 Lecture07, Pacific Continental Residence 등)과 이종 저작도구 간 모델(ArchiCAD Villa Patio), 다양한 공개 소스 건축 모델이 포함되었다. 각 IFC를 3장의 파이프라인으로 재구성했으며, 동일 코드를 Revit 2024·2027 두 버전에서 각각 독립 실행하였다(총 24회 빌드). 원본 Revit 모델이 있는 11종은 vs-native·vs-IFC 양쪽, 대응 원본이 없는 Villa Patio는 vs-IFC로 채점하였다(루브릭 L1~L3, 90점). 대상 모델의 제원·출처는 Table 3에 정리하였다.
규모는 39~1,326 요소·2~11층으로 소형 데모부터 대규모 다층까지 포괄한다. 저작도구 열은 IFC를 내보낸 도구를 가리킨다. 원본은 여러 Revit 버전에서 저작되었으며(Newsstand 2014, Smith House 2021 등) 처리를 위해 Revit 2024(Pacific은 Revit 2027)로 업그레이드해 IFC2X3로 내보냈다.
Table 3
Test models (12 models)
| Model | Authoring tool | Storeys | Elements | Main composition and characteristics | Source |
| Lecture07 | Revit | 11 | 1,326 |
Walls, columns, beam frames + curtain walls, stairs; largest (textbook example) | Jang (2020) |
| BIMobject | Revit | 9 | 912 | Many doors/windows (170/182), curtain walls; large public demo | BIMobject (2026) |
| Villa Patio | ArchiCAD | 3 | 666 | Many beams (174), slabs (107), B-rep geometry; only cross-tool case | Graphisoft (2024) |
| 3H House | Revit | 6 | 486 | Columns (112), beams (83) structural frame; medium-large residential | BIMobject (2026) |
| Pacific | Revit | 3 | 218 | Many roofs/ceilings; cross-version source (2027 export), IFC-loss case | Autodesk (2027) |
| Smith House | Revit | 5 | 192 | Walls (108), windows (36); residential | BIMobject (2026) |
| GEALAN | Revit | 5 | 149 | Door/window-intensive (41 each); window manufacturer example | GEALAN (2026) |
| RAC | Revit | 6 | 132 |
Curtain walls (9), circular columns, varied; Autodesk official sample (reference model) | Autodesk (2024) |
| Coffee Shop | Revit | 3 | 99 | Column/beam frame; small commercial | BIMobject (2026) |
| Newsstand | Revit | 3 | 54 | Minimal composition; small newsstand | BIMobject (2026) |
| Model Demo | Revit | 2 | 41 | Small demo with curtain walls and roof | BIMobject (2026) |
| Apartment2 | Revit | 2 | 39 | Wall-dominant (30); minimal scale | BIMobject (2026) |
4.2 재구성 결과
Fig. 2는 세 방식의 재구성 결과를 비교한다. 세 뷰는 육안으로는 거의 동일했으나, 받은 즉시 실무에 활용 가능한 네이티브 충실도에서 차이가 있었다. (b) 내장 가져오기는 형상은 들어오되 타입·재료·분류 등 의미가 상당 부분 소실되었고, (c) 제안 파이프라인은 이를 보존한 활용 가능한 네이티브로 복원하였다. 육안으로 구분되지 않는 이 차이를 속성 항목 단위로 Table 4에 정리하였다. 격차는 타입 축에서 가장 뚜렷했고, 내장 가져오기는 벽 타입 분포·기초 타입·천장 재현에서 0 %로 원본의 타입 정보를 잇지 못하였다. 반면 관계 축(문·창 호스팅, 레벨 지정)은 두 방법이 유사했고, 재료는 3.5절과 같이 레이어 기능으로 대리 평가하여 이 모델에서는 동일하였다. RAC에서는 레이어 기능 84.4 % 대 25.0 %, 문–벽 호스팅 100 % 대 37.5 %로 두 축의 격차가 더 컸다. 즉 차이는 부재를 벽·문으로 인식하는지가 아니라, 그 부재가 어떤 타입에서 비롯되었는지를 보존하는지에 있다. 네 구성(제안 파이프라인·내장 Open IFC × vs-native·vs-IFC)의 모델별 총점을 Table 5에, 레벨별 평균을 Table 6에 정리하였다. 두 Revit 버전의 점수는 전 모델에서 동일했으므로(4.3절) 대표값 하나로 제시한다.
Table 4
Item-level attribute preservation (Lecture07, vs-native, %)
Table 5
Per-model reconstruction scores — pipeline vs. built-in Open IFC, under vs-native and vs-IFC (Total/90 (%))
| Model | Pipeline vs-native | Pipeline vs-IFC | Open IFC vs-native | Open IFC vs-IFC |
| Apartment2 | 84.5 (93.9) | 66.9 (74.3) | 80.0 (88.9) | 60.2 (66.9) |
| Newsstand | 82.4 (91.6) | 67.3 (74.8) | 64.9 (72.1) | 51.5 (57.2) |
| RAC | 81.1 (90.1) | 66.5 (73.8) | 44.3 (49.3) | 40.3 (44.8) |
| Lecture07 | 79.6 (88.4) | 74.1 (82.3) | 57.0 (63.3) | 54.5 (60.5) |
| GEALAN | 74.9 (83.2) | 58.7 (65.2) | 32.6 (36.3) | 27.8 (30.9) |
| Smith House | 74.6 (82.9) | 64.8 (71.9) | 71.6 (79.5) | 56.8 (63.1) |
| Model Demo | 73.6 (81.8) | 67.6 (75.1) | 65.7 (73.0) | 54.7 (60.8) |
| Coffee Shop | 73.2 (81.4) | 67.6 (75.1) | 56.7 (63.0) | 49.1 (54.6) |
| BIMobject | 71.1 (79.0) | 62.9 (69.8) | 62.5 (69.4) | 52.3 (58.1) |
| 3H House | 70.8 (78.7) | 67.5 (75.0) | 42.5 (47.2) | 38.7 (43.0) |
| Pacific | 48.9 (54.4) | 52.8 (58.6) | 33.0 (36.6) | 37.7 (41.8) |
| Villa Patio | – | 67.7 (75.2) | – | N/A |
| Mean | 74.07 (82.3) | 65.34 (72.6) | 55.53 (61.7) | 47.59 (52.9) ‡ |
Note: vs-native mean over 11 models (Villa Patio has no native original); vs-IFC over 12 (pipeline) / 11 (Open IFC). ‡ Villa Patio’s built-in Open IFC L3 was invalidated (harness exception — N/A) and excluded from the Open IFC mean. Excluding the IFC-export-loss outlier Pacific (Section 4.4), the pipeline vs-native mean is 76.58/90 (85.1 %).
Table 6
Mean scores by level (L1/L2/L3) — pipeline vs. built-in Open IFC
해당 결과에서 첫째, 기하학적 충실도(L1)가 높았다. vs-native에서 Pacific 제외 전 모델이 40점 만점에 31.2~40.0점으로 좌표·수량·치수가 원본에 근접하였다. 둘째, 편집 가능성(L3)에서 적용 가능한 편집이 전부 성공하였다(기둥 없는 모델은 해당 시험만 N/A로 12점, 그 외 15점). 재구성 결과가 형상 플레이스홀더가 아닌 편집 가능한 네이티브임을 뜻한다(내장 가져오기와의 정량 대조는 4.5절). 셋째, 동일한 11개 모델을 기준으로 vs-native가 vs-IFC보다 높았다(82.3 % 대 72.4 %). 재구성 결과가 중립 IFC 인벤토리보다 원본 Revit에 더 부합함을 보이나, vs-IFC의 낮은 값에는 IFC 기준 자체가 중립 스키마로 표현 가능한 정보만 담는 한계도 포함되므로 vs-IFC는 보수적 하한으로 해석한다.
4.3 버전 간 재현성(cross-version)
동일 파이프라인 코드를 Revit 2024·2027에서 각각 독립 실행한 결과, 12개 모델 전부에서 두 버전 점수가 완전히 동일하였다(L1·L2·L3 모든 하위 지표 일치, 벽 좌표 평균절대오차(mean absolute error, MAE) 0.0 mm). 이는 상위 버전 파일을 하위로 변환한 것이 아니라 각 버전이 동일 IFC로부터 독립 재구성한 결과가 일치했음을 뜻한다. 따라서 재구성은 결정론적이며 Revit 버전에 의존하지 않아, 버전 간 이전 시나리오를 직접 뒷받침한다.
4.4 주목 사례
Villa Patio(이종 저작도구 간 재구성) 유일하게 Revit이 아닌 ArchiCAD에서 저작된 모델로(ArchiCAD의 IFC 교환은 Graphisoft SE(2026)), 대응 Revit 원본이 없어 vs-IFC로만 평가되었다. vs-IFC 67.7점으로 Revit 유래 모델과 견주어 상위권이었고 편집 가능성(L3) 15점을 받아, ArchiCAD IFC로부터 편집 가능한 Revit 네이티브를 재구성함을 보였다. 이는 이종 저작도구 간 재구성을 실증하는 대표 사례이다.
Pacific(두 기준의 역전과 상류 export 손실) 12개 중 Pacific만 vs-IFC(52.8)가 vs-native(48.9)보다 높았다(다른 모델은 모두 vs-native가 높았고 평균 +8.9점). 원인은 재구성 실패가 아니라 원본 네이티브 모델을 IFC로 내보내는 과정에서 발생한 손실이다. 원본 Revit 모델에는 벽 186개, 천장 52개, 지붕 23개가 있었으나 내보내진 IFC에는 벽 104개, 천장 31개, 지붕 8개만 남았다(벽 −44 %, 지붕 −65 %). 파이프라인은 IFC의 벽 104개 중 100개(96 %)를 재구성해 IFC 기준 점수는 높았으나, 원본 기준으로는 IFC에 없는 82개 벽을 복원할 수 없어 낮아졌다. 손실이 파이프라인이 아니라 상류 export에서 발생했음을 두 기준 분리로 국소화할 수 있다. 다만 Pacific은 복잡한 경계표현(boundary representation, B-rep) 표본이자 전 모델 최저 점수(천장 1/52)라 export 손실과 형상 난도가 겹친 극단값이다.
RAC(평가의 진단 기능) vs-native 81.1점(L2 31.8로 상위권)을 받았으나 초기 재구성에서 커튼월 배치·원형 기둥·벽 조인의 세 경계 사례 결함이 있었고, 평가 프레임워크가 이를 정량적으로 드러내어 파이프라인 수정으로 이어졌다. 평가가 품질 관리(QA) 도구로도 기능함을 시사한다.
4.5 내장 IFC 가져오기와의 비교
2.2절의 기준선을 정량 대조하고자 동일 12개 IFC를 Revit 2024의 Open IFC로 가져와 같은 L1~L3로 채점하였다(Table 5의 Open IFC 열). 그 결과 내장 가져오기는 앞서 제시한 다섯 축 한계를 실측으로 드러냈다. 한 모델 안에서도 결과가 예측 불가하게 혼재해, 벽은 일부가 네이티브·일부가 일반 인스턴스로 들어왔고(네이티브 비율 21 %~100 %로 분포), 천장(IfcCovering)은 Ceiling 카테고리로 분류되지 못하고 일반 모델(Generic Model)로 들어와 네이티브 천장으로 활용할 수 없었다. 또한 모델 전체가 원본 프로젝트 좌표계와 다른 위치(예: Lecture07 수직 약 30 m 이동)에 배치되었고, 처리 보고가 없어 사용자는 이 불균일한 결과를 요소 단위로 확인·수정해야 한다.
정량적으로 파이프라인은 전 모델에서 내장 가져오기를 앞섰다(vs-native 74.1 대 55.5; vs-IFC 65.3 대 47.6; Fig. 3). 격차의 핵심은 의미론적 충실도(L2, vs-native 26.2 대 15.8)로, 내장 가져오기는 타입·레이어·재료·호스팅 관계를 상당 부분 잃은 반면 파이프라인은 이를 보존하였다. 기하(L1)에서 내장 점수는 모델별 편차가 컸는데(40점 만점에 11~40), 앞의 배치 오프셋 때문에 좌표 점수가 0에 가까운 모델이 있었고 원점을 강체 정합하면 형상은 원본에 근접하였다. 즉 내장의 기하 실패는 형상 왜곡이 아니라 배치에서 비롯한다. 편집성(L3)은 내장도 상당수 통과했으며(평균 12.5/15) 편집 가능 여부 자체는 두 방법을 가르는 핵심이 아니다.
우위가 특정 기준에 의존하지 않는지 보고자 두 기준별 점수차(Δ = 파이프라인 − Open IFC)를 비교한 결과 두 값이 강하게 일치하였다(Pearson r = 0.961, Spearman 0.964; 평균 Δ 18.5 대 17.5점). 즉 파이프라인의 우위는 기준(native·IFC) 선택과 무관한 방법 자체의 성질이며, 우위가 큰 모델(GEALAN·RAC)에서 Δvs-native가 대체로 컸다. 종합하면 내장 가져오기와의 차이는 편집 가능 여부가 아니라 예측 가능성·완전성·의미 보존·올바른 배치·처리 투명성에 있으며, 파이프라인은 정의된 카테고리 범위 안에서 이들을 결정론적으로 제공한다.
4.6 레벨별 분해(L1·L2·L3)
합계 점수는 모델·구성 간 순위를 보여주지만 재구성이 어느 축에서 갈리는지는 나타내지 못하므로, 네 구성의 점수를 레벨별로 분해하였다(Table 6).
내장 Open IFC의 결손은 L1(기하)보다 L2(의미)에서 컸다. 파이프라인 대비 상대 격차는 L2에서 30 %p로 L1 격차(18 %p)의 약 1.7배였고 L3 격차(5 %p)를 크게 웃돌았다. 기하가 파이프라인에 근접하는 모델에서도 의미 격차는 지속되어, 파이프라인 우위가 기하보다 의미 보존에서 비롯됨을 시사한다. 합계 값만으로는 이 구조가 드러나지 않으며, 이는 2.2절에서 정성적으로 지적한 Open IFC의 의미 소실을 정량적으로 뒷받침한다.
반면 L3(편집성)은 재구성된 객체 자체를 시험하므로 기준에 사실상 불변이며, 평균의 근소한 차이(13.4 대 13.5)는 대상 모델 수 차이에서 비롯한다. 따라서 두 기준의 차이는 전적으로 L1 + L2에서 발생한다. 파이프라인의 L3는 만점에 근접해(vs-native 평균 89 %) 구성 간 변별도 대부분 L1·L2에서 나타났다.
5. 논 의
5.1 문제의 비자명성과 실무 가치
이 재구성은 동일 저작도구에서 만든 IFC를 다시 그 도구로 되돌리는 동일 저작도구 내(in-domain) 경우에도 자명하지 않다. 2.2절·4.5절에서 보았듯 내장 가져오기는 동일 도구 유래 모델에서도 결과가 혼재하고 의미·좌표 배치를 상당 부분 잃는다. 즉 문제는 형식 변환이 아니라 중립 형상으로부터 파라메트릭 저작 의도(타입·위치선·호스트·레벨)의 예측 가능·완전한 복원이며, 내장 경로는 이를 신뢰성 있게 수행하지 못한다. 나아가 동일 파이프라인이 변환 코어 재작성 없이 이종 저작도구 간(ArchiCAD)으로 확장됨을 4.4절에서 보였다. 역방향 재구성의 실무 가치는 1장에서 든 시나리오 전반에 걸치며, 이 모두에서 형상 표시 수준과 편집 가능한 네이티브 수준의 차이가 손실을 좌우한다.
5.2 방호시설에의 적용
방호시설은 데이터 무결성이 특히 요구되며, 참여 주체가 서로 다른 저작도구를 쓰는 환경에서는 개방형 포맷을 경유한 모델 인계가 이루어진다. 이때 부재의 타입·단면 구성·호스트 관계가 소실되면 어떤 벽이 방호벽이고 어떤 문이 어느 벽에 부착되어 구획을 이루는지를 모델만으로 판별할 수 없다.
국내 소규모 지하대피시설의 계획 기준은 외벽 0.3~0.5 m 이상, 천장 0.5 m 이상으로 정리된 바 있다(Yoo and Lee, 2020). 본 파이프라인은 IFC 재료층 집합의 두께를 상한 없이 사용해 복합 단면의 각 층을 재현하며, Coffee Shop의 523 mm 복합 외벽 16개는 두께·타입명과 층 수(6개)·층별 두께가 원본과 일치하게 재구성되었다(슬래브는 1,000·1,219 mm 포함). 두께와 층 구성은 L1 치수 정확도로 검증되나 층별 기능 표기는 완전히 복원되지 않으며, 이들 부재의 용도는 단열·구조이고 방호 목적 단면은 대상에 없었다.
전실은 별도 부재 유형이 아니라 벽·문·슬래브의 배치로 성립하므로, 복원 여부는 벽의 위치·수량 정확도와 각 문의 호스트 벽 부착에 달려 있다. 본 파이프라인은 개구부 호스팅을 명시적으로 복원하며, 문–벽 호스팅 보존율은 원본 대비 모델별 평균 82.6 %로 내장 가져오기의 65.9 %를 상회했고 11개 모델 중 5개에서 100 %였다(L1 좌표·수량, L2 호스팅).
내화·방폭 등급이나 설계 폭압처럼 방호 성능과 직결되는 정보는 IFC에서 속성집합(property set)으로 표현된다. 본 파이프라인은 IFC 속성집합을 추출해 그중 하중 지지 여부를 벽·기둥의 구조·비구조 분류에 반영하므로(3.2절), 속성값이 재구성 결과에 반영되는 경로 자체는 이미 작동하며 방호 성능 속성으로의 확장은 이를 Revit 파라미터로 기록하는 단계를 더하는 문제다. 방호구획은 IFC 공간·영역 요소로 표현되나 현재 재구성 대상이 아니고 방호 기계·설비는 MEP 공종이므로(5.3절), 속성집합의 파라미터 기록·공간 구획 재구성·설비 확장이 방호시설 적용의 선결 과제다.
5.3 한계
본 연구의 핵심 기여가 이종 저작도구 간 일반화이나 12개 중 비-Revit 저작은 ArchiCAD Villa Patio 1종이며 나머지 11종은 Revit 유래다. 따라서 이종 저작도구 간 재구성은 현재까지 단일 타 도구에서 실증되었으며 추가 저작도구 확장은 향후 과제에서 다루기로 한다. 한계 및 향후 연구 과제는 다음과 같이 6개로 정리하였다.
첫째, 파이프라인은 벽·기둥·보·기초·슬래브·천장·문·창·커튼월·지붕·계단의 건축/구조 요소를 대상으로 하며 MEP·난간·가구·공간·주석 등은 재구성하지 않는다. 즉 전 공종이 아니라 건축/구조 요소의 재구성이다.
둘째, 재구성 상한은 소스 도구의 IFC 내보내기가 담은 내용에 제약된다. Pacific(4.4절)처럼 내보내기에서 요소가 누락되면 vs-native가 그만큼 낮아진다. vs-IFC 기준의 IFC 인벤토리 자체도 재구성된 근사 기준이므로 vs-IFC는 보수적 하한으로 해석해야 한다.
셋째, 향후 파이프라인 개선점으로는 (i) 재료의 정확한 명칭 복원으로, 현재는 이종 저작도구 간 강건성을 위해 레이어 기능으로 평가하며 명칭 완전 복원은 미완이다. (ii) 미지의 IFC 표현 패턴 대응으로, 결정론적·무-LLM 설계의 특성상 새 표현(원형 프로파일 기둥, 특정 도구의 스윕 표현 등)은 자동 적응 대신 템플릿·파서의 표적 확장을 요한다. 이 밖에 지하층 기둥 기준면 오프셋, 지붕 호스팅 개구부, 복수 계단 통합·배치 이상 등 소수 경계 사례가 잔존한다.
넷째, L3는 벽·기둥·슬래브·레벨·문의 다섯 편집으로 판정하므로, 재구성 대상에 포함된 보·천장·창·커튼월·지붕·계단·기초의 편집 가능성은 직접 검증되지 않았다. 편집 시험의 카테고리 확장은 향후 과제다.
다섯째, 지표는 전 카테고리에 균일 적용되나 부재 특성상 성립하지 않는 소수 항목은 N/A로 처리·재정규화된다(3.5절). 커버리지 공백이 아니라 지표 적용 가능성에 기인한다. 또한 루브릭은 저자 설계이며 커뮤니티 표준이 아니므로, 3.5절의 민감도 분석으로 배점 선택의 영향을 점검하였다.
여섯째, 본 연구에서 확립한 IFC 상호운용성 검증 파이프라인은 향후 데이터 무결성과 신뢰성이 최우선으로 요구되는 방호시설 및 지하 특수 구조물 프로젝트로 적용 범위를 확대하여 실증 연구를 수행할 예정이다.
6. 결 론
본 연구는 이종 BIM 저작도구에서 생성된 IFC를 편집 가능한 Revit 네이티브 객체로 재구성하는 4단계 결정론적 파이프라인(Parse–Generate–Execute–Verify)을 제안하고, 원본 대비(vs-native)와 입력 대비(vs-IFC) 두 기준에서 L1~L3 루브릭으로 품질을 정량 검증하였다. 주요 기여는 둘이며 이를 뒷받침하는 설계 원칙이 하나다. 첫째, 동일 파이프라인이 변환 코어 재작성 없이 Revit 유래 모델과 ArchiCAD 유래 모델을 함께 재구성했고, 결과는 편집 가능한 네이티브이면서 내장 가져오기 대비 의미 충실도·완전성·올바른 배치에서 앞섰다(vs-native 평균 74.07/90, 82.3 %; 4.5절). 다만 비-Revit 저작 사례는 ArchiCAD 1종이므로, 이는 이종 저작도구 전반에 대한 일반화가 아니라 단일 타 도구에서의 실증이다. 둘째, 동일 IFC를 Revit 2024·2027에서 독립 재구성한 결과는 전 모델에서 완전히 동일했고 버전 간 이전을 결정론적으로 뒷받침한다. 설계 원칙상 변환 자체는 언어모델이 개입하지 않는 결정론적 과정이며, LLM·MCP는 파이프라인 개발과 부재 단위 조회·검증 도구로 활용되었다. 이 분리가 환각·비결정성 없는 재현 가능 변환의 바탕이 된다.
향후 연구 방향으로, 첫째, 현재 ArchiCAD 한 가지에 국한된 이종 저작도구 검증을 다른 저작도구로 넓혀 재구성 범위를 확장할 필요가 있다. 둘째, 재료명 정확 복원, 지붕·기초·계단 기하의 균일 평가, 미지의 IFC 표현 패턴 대응, MEP 등 공종 확장을 통해 재구성 충실도·커버리지를 높이고자 한다.
