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

모델 검토에서 문제를 발견하면 보통 화면을 캡처해 이메일로 보낸다. 받는 쪽은 그 그림을 보고 자기 모델에서 같은 자리를 다시 찾아야 한다. 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) 폴더 등 부속 자료 기능이 추가됐다. 도구마다 지원 버전이 달라, 주고받기 전에 버전을 맞춰 두는 편이 안전하다.

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

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

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

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

■ IFC와 BCF의 관계

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

■ 눈여겨볼 것

BCF를 도입해도 효과가 나지 않는 팀에는 공통점이 있다. 이슈의 상태 값을 관리하지 않는 것이다. 열림과 닫힘만 쓰고 담당자와 기한을 비워 두면, 목록이 쌓이기만 한다. 도구를 바꾸기 전에 누가 언제까지 답하는지를 먼저 정해야 한다. 또한 요소 GUID가 참조되므로, 모델을 다시 만들어 GUID가 바뀌면 링크가 끊긴다는 점도 알아 둘 필요가 있다.

■ 이런 분께 도움이 됩니다