BCF로 이슈 주고받기 – 소프트웨어가 달라도 통하는 협업 포맷

업데이트 2026년 10월 15일읽는 시간 약 4분

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

■ BCF가 담는 네 가지

BCF의 핵심은 “무엇이 문제인지”를 말로만 전하지 않고, 보는 사람이 같은 화면·같은 요소를 그대로 재현하도록 구조화해 담는다는 점이다.

구성 요소	내용	역할
마크업(markup.bcf)	제목·설명·상태·우선순위·담당자·기한·코멘트 이력	이슈의 대장. 누가 언제 무엇을 지적하고 조치했는지
뷰포인트(viewpoint.bcfv)	카메라 위치·방향·화각, 절단면, 요소 가시성	열면 그 시점으로 화면이 이동
스냅숏(snapshot.png)	이슈 발견 시점의 화면 캡처 이미지	모델을 못 열어도 무엇을 말하는지 확인
요소 참조(GUID)	관련 요소의 IFC GUID 목록	해당 요소를 자동 선택·강조

■ BCF-XML(.bcfzip) vs BCF-API

BCF를 주고받는 방법은 두 가지다. 파일로 오가는 BCF-XML과, 서버에 직접 연결하는 BCF-API다. 소규모 협업이나 도구 간 일회성 교환에는 파일이 간편하고, 다수가 실시간으로 이슈를 공유해야 하면 API 서버 방식이 맞다.

구분	BCF-XML	BCF-API
형태	.bcfzip 압축 파일(수동 전달)	REST 서버 연결(자동 동기화)
구조	이슈별 폴더 안에 markup.bcf, viewpoint.bcfv, snapshot.png	서버가 이슈·코멘트·뷰포인트를 엔드포인트로 제공
적합	도구 간 일회성 교환, 소규모	여러 명이 실시간 협업, 이력 중앙 관리
단점	버전 충돌·중복 관리 부담	서버 구축·연동 필요

버전은 2.0과 2.1을 거쳐 3.0까지 나와 있다. 2.1이 현재 가장 널리 쓰이고, 3.0은 서버 연동 강화와 함께 문서(Documents) 폴더 등 부속 자료 기능이 추가됐다. 도구마다 지원 버전이 달라, 주고받기 전에 버전을 맞춰 두는 편이 안전하다.

보와 배관의 충돌 지점과 저장된 시점(카메라)을 표현한 일러스트 — AI로 만든 예시 이미지

■ 이슈 워크플로 — 발견에서 닫기까지

BCF는 형식일 뿐이고 그 안에서 돌아가는 것은 결국 이슈 관리 절차다. 상태 값을 제대로 쓰지 않으면 이슈 목록이 쌓이기만 하고 무엇이 처리됐는지 아무도 모르게 된다.

단계	상태(Status)	하는 일
1. 발견	Open	검토자가 충돌·오류를 찾아 뷰포인트·스냅숏과 함께 이슈 생성
2. 할당	Assigned	담당자와 기한을 지정. 관련 요소 GUID를 참조
3. 해결	Resolved	담당자가 모델을 수정하고 코멘트로 조치 내용 기록
4. 확인·닫기	Closed	검토자가 반영을 확인하면 닫음. 반영 미흡하면 다시 Open

지원 도구로는 Solibri(규칙 기반 충돌·품질 검사), Navisworks(간섭 체크와 이슈 내보내기), BIMcollab·Catenda 같은 이슈 관리 플랫폼, 그리고 Revit·ArchiCAD의 BCF 플러그인이 있다. 서로 다른 소프트웨어를 쓰는 팀이라도 BCF를 공통 언어로 삼으면 지적과 조치가 같은 형식으로 축적된다.

시공 중인 천장의 덕트·배관 교차 지점을 태블릿과 대조하는 현장 기술자 — AI로 만든 예시 이미지

■ IFC와 BCF의 관계

두 표준은 짝을 이룬다. IFC가 “무엇이 어디에 있는가”라는 모델 자체를 실어 나른다면, BCF는 “그 모델의 어디에 무슨 문제가 있는가”라는 소통을 실어 나른다. 그래서 BCF의 요소 참조는 IFC GUID를 그대로 사용한다. 협업 판을 정리하면, 참여자는 각자 IFC로 통합 모델을 만들어 겹쳐 보고, 검토에서 나온 지적은 BCF로 오간다. 모델 교환과 이슈 교환을 분리해 두면, 모델은 무겁게 통째로 다시 보내지 않아도 이슈만 가볍게 주고받을 수 있다. 다만 이 구조가 성립하려면 양쪽이 참조하는 IFC 모델의 버전과 GUID가 같아야 한다는 전제가 붙는다.

■ 이슈 상태와 참조 모델 버전

BCF를 도입하고도 효과가 없는 팀은 대개 이슈 상태를 관리하지 않는다. 열림과 닫힘만 쓰고 담당자와 기한을 비워 두면 목록이 쌓이기만 한다. 도구를 바꾸기 전에 누가 언제까지 답하는지부터 정한다.

BCF에는 모델이 들어 있지 않고 이슈와 시점 정보만 담긴다. 받는 쪽이 같은 모델을 갖고 있어야 해당 위치가 열리고, 모델 버전이 다르면 카메라는 맞아도 요소 선택이 어긋날 수 있다. 요소는 GUID로 참조되므로 모델을 새로 만들어 GUID가 바뀌면 연결이 끊긴다. 교환 전에 참조 모델 버전을 맞춘다.