단순 3D 뷰어를 넘어선 BIM 플랫폼: 기술 선택마다 트레이드오프가 있다

BIM 실무자가 "이 모델이 너무 무겁다"고 말하는 순간, BIM 플랫폼을 만드는 개발자는 "메모리 사용량을 분석해야지"라고 생각한다. 같은 문제를 완전히 다른 언어로 마주하는 셈이다. 플랫폼을 개발하는 입장에서 BIM 데이터를 들여다보면, 실무에서는 안 보이던 기술적 트레이드오프가 계속 튀어나온다.

"그냥 잘 만든 오픈소스 갖다 쓰면 안 되나요?"

부분적으론 맞다. 처음부터 모든 걸 새로 만들 필요는 없다. 하지만 "어떤 오픈소스를, 어떻게 조합할 것인가" 자체가 이미 설계 결정이고, 여기서부터 트레이드오프가 시작된다.

BIM 플랫폼 개발의 핵심 과제

개발자가 마주하는 4가지 벽

• 대용량 데이터: BIM 모델 하나가 수백 MB에서 수 GB에 달함
• 다양한 포맷: RVT, IFC, DWG, DGN, OBJ, glTF — 표준이라 부를 게 마땅치 않을 정도로 파편화
• 정밀도: mm 단위 정확도를 유지하면서 브라우저에서 실시간 렌더링해야 함
• 실시간 협업: 여러 사용자가 동시에 같은 모델을 보고 편집

기술적 의사결정 사례

실제로 BIM 플랫폼을 만들 때 마주치는 선택지와, 그 선택의 근거를 정리하면 다음과 같다.

"정답"이 아니라 "지금 우리 상황에 맞는 선택"이다

위 표의 선택이 절대적인 정답은 아니다. Babylon.js가 나은 상황도 있고(예: 게임엔진스러운 인터랙션이 많이 필요할 때), xbim이 나은 상황도 있다(예: .NET 스택으로 이미 통일된 조직). 중요한 건 "왜 이걸 선택했는지" 근거를 남겨두는 것이다. 반년 뒤 팀원이 "왜 Three.js를 썼어요?"라고 물었을 때 답할 수 있어야 한다.

포맷 파편화를 얕보지 마라

"IFC 하나만 지원하면 되겠지"라고 시작했다가, 실제 고객사들이 RVT·DWG·SKP를 섞어서 보내오는 현실과 마주하게 된다. 포맷 변환 파이프라인은 플랫폼의 핵심 기능이 아니라 "당연히 되어야 하는 전제 조건"으로 취급되기 쉬운데, 실제로는 개발 리소스의 상당 부분을 차지한다. 초기 설계 단계에서 이 비용을 과소평가하지 말아야 한다.

마무리

BIM 플랫폼 개발은 단순한 3D 뷰어 개발이 아니라 대용량 데이터 처리, 포맷 변환, 실시간 협업, 정밀도 유지라는 복합적인 과제를 동시에 풀어야 하는 작업이다. 각 기술적 결정에는 트레이드오프가 따르고, 정답은 팀의 상황(스택, 인력, 일정)에 따라 달라진다. 중요한 건 최고의 기술을 고르는 게 아니라, 선택의 근거를 명확히 남기고 필요할 때 뒤집을 수 있게 설계하는 것이다.