BIM 데이터를 하나의 DB에 다 넣으려 하지 마라: 형상·속성·관계 저장 전략

BIM 플랫폼을 처음 개발하는 사람이 흔히 저지르는 실수가 있다. "BIM 데이터니까 하나의 DB에 다 넣으면 되겠지"라는 생각이다. 실제로 붙어보면 BIM 데이터는 3D 모델이 아니라 형상, 속성, 이력, 관계가 뒤엉킨 그래프 구조라는 걸 금방 깨닫게 된다. 이걸 관계형 DB 하나로 욱여넣으려다 보면 조인 지옥에 빠지거나, 반대로 스키마리스 DB에 다 넣었다가 무결성이 무너진다.

"그냥 PostgreSQL 하나로 다 처리하면 안 되나요?"

안 되는 건 아니지만 비효율적이다. 벽과 방의 "포함 관계", 파이프와 펌프의 "연결 관계"처럼 관계 자체가 데이터의 핵심인 정보를 관계형 DB의 조인으로 표현하면 쿼리가 기하급수적으로 복잡해진다. BIM 데이터의 종류마다 잘 맞는 저장 방식이 다르다.

BIM 데이터의 4가지 특성

BIM 데이터가 까다로운 이유

• 계층 구조: 프로젝트 → 분야 → 시스템 → 객체 → 속성으로 이어지는 다단계 트리
• 관계: 공간 관계(벽이 방에 포함됨)와 시스템 관계(파이프가 펌프에 연결됨)가 동시에 존재
• 버전 관리: 모든 객체가 변경 이력을 가짐 — "지난주엔 이 값이었는데 지금은 다르다"를 추적해야 함
• 대용량 형상: 폴리곤 메시 데이터는 일반 DB 레코드로 다루기엔 너무 무거움

데이터베이스 선택 기준

"이 데이터가 자주 바뀌는가, 자주 탐색되는가"로 나눠라

저장소를 고를 때 가장 실용적인 질문은 이거다 — 이 데이터를 얼마나 자주 갱신하고, 얼마나 자주 관계를 따라 탐색하는가. 자주 갱신되고 정확성이 중요한 속성 데이터는 관계형 DB, 관계 탐색이 잦은 시스템 연결 정보는 그래프 DB, 거의 안 바뀌는 형상 데이터는 오브젝트 스토리지 — 이렇게 특성별로 나누면 각 DB의 강점만 취할 수 있다.

실전 아키텍처 예시

객체 메타데이터 (이름, 카테고리, 층, 소유자)     → PostgreSQL
객체 속성 (재질, 크기, 화재 등급 등 파라미터)     → PostgreSQL (JSONB 컬럼 활용)
변경 이력 (누가 언제 무엇을 바꿨는지)             → MongoDB
공간·시스템 관계 (포함, 연결, 인접)               → Neo4j
폴리곤 메시·원본 IFC/RVT 파일                    → S3 등 오브젝트 스토리지

처음부터 4개 DB를 다 쓰려고 하지 마라

이 구조는 "이상적인 최종 형태"이지, 첫날부터 4개의 데이터베이스를 운영하라는 뜻이 아니다. 초기엔 PostgreSQL 하나로 시작하고(JSONB로 유연한 속성까지 커버 가능), 관계 탐색 쿼리가 실제로 느려지거나 복잡해지는 시점에 그래프 DB를 추가하는 식으로 점진적으로 확장하는 게 현실적이다. 처음부터 풀 스택을 갖추려다 인프라 관리 비용만 커진다.

마무리

BIM 데이터베이스는 단일 DB로 모든 것을 해결하려 하기보다 혼합(Hybrid) 접근이 가장 효과적이다. 객체 메타데이터는 관계형 DB, 형상 데이터는 별도 오브젝트 스토리지, 이력은 문서형 DB, 관계는 그래프 DB로 분산 저장하는 식이다. 중요한 건 처음부터 완벽한 아키텍처를 짜는 게 아니라, 어떤 데이터가 어떤 방식으로 자주 쓰이는지 관찰하면서 필요한 저장소를 하나씩 추가해나가는 것이다.