LOD웹BIM개발자
Revit에선 멀쩡한데 왜 웹에선 버벅일까? 대용량 BIM 모델, 브라우저에서 안 끊기게 보여주는 법
MADE IN WORKS·2025. 8. 25.·4분 읽기
Revit에서는 아무 문제 없이 돌아가던 300MB짜리 모델을 웹 뷰어에 올리는 순간, 갑자기 스크롤이 뚝뚝 끊기고 메모리 부족 경고가 뜬다. "PC 사양 문제인가?" 싶어 그래픽카드를 바꿔봐도 크게 나아지지 않는다. 원인은 하드웨어가 아니라, 브라우저와 데스크탑 소프트웨어가 모델을 다루는 방식 자체가 다르다는 데 있다.
"그냥 좋은 그래픽카드로 보면 되는 거 아닌가요?"아니다. Revit은 파일을 한 번 열면 로컬 디스크에서 필요한 만큼만 읽어 처리하지만, 웹 뷰어는 매번 네트워크로 데이터를 전송받고, 파싱하고, GPU에 새로 올리는 과정을 거친다. 병목은 그래픽카드가 아니라 이 파이프라인 전체에 걸쳐 있다.
웹 BIM 뷰어 성능 최적화 3원칙
핵심 3원칙
- LOD (Level of Detail): 카메라와의 거리에 따라 형상의 상세도를 자동으로 조절한다
- 스트리밍: 화면에 당장 필요한 부분만 먼저 로딩하고, 나머지는 나중에 불러온다
- 메모리 관리: 화면 밖으로 나간 객체는 GPU 메모리에서 즉시 내린다
세 원칙의 공통점은 "한 번에 다 보여주려 하지 않는다"는 것이다. 사람 눈에 안 보이는 디테일과 안 보이는 객체에 리소스를 쓰지 않는 것만으로 체감 성능은 극적으로 달라진다.
실전 최적화 기법
| 기법 | 설명 | 효과 |
|---|---|---|
| LOD 단계화 | 거리 기반으로 폴리곤 수를 3~4단계로 미리 계산해둠 | 프레임 레이트 최대 3배 향상 |
| Draco 압축 | 메시 데이터를 압축해 전송 용량을 줄임 | 로딩 시간 최대 70% 단축 |
| 프러스텀 컬링 | 카메라 시야 밖 객체는 렌더링 자체를 생략 | 메모리 사용량 약 50% 감소 |
| 공간 분할 청크 로딩 | 건물을 층·구역 단위로 쪼개 필요한 청크만 로딩 | 초기 로딩 시간 최대 80% 단축 |
최적화 전에 반드시 프로파일링부터"느리다"는 감으로 최적화를 시작하면 엉뚱한 곳에 시간을 쓰기 쉽다. 브라우저 개발자도구의 성능 탭으로 네트워크 전송 시간·파싱 시간·렌더링 프레임 타임 중 어디가 병목인지 먼저 확인하자. 전송이 병목이면 Draco 압축이 정답이고, 렌더링이 병목이면 LOD·컬링이 정답이다 — 원인 진단 없이는 엉뚱한 해법을 적용하게 된다.
LOD를 너무 공격적으로 적용하면상세도를 너무 급격하게 낮추면 카메라를 살짝만 움직여도 형상이 "팝핑"하듯 갑자기 바뀌어 오히려 어색해 보인다. LOD 단계 사이를 부드럽게 전환(크로스페이드)하거나, 단계 수를 늘려 전환을 완만하게 만드는 튜닝이 필요하다.
마무리
흔히 하는 실수렌더링 쪽(LOD, 컬링)만 최적화하고 네트워크 전송 크기는 그대로 두는 경우가 많다. 아무리 LOD를 잘 짜도, 애초에 300MB를 통째로 내려받아야 한다면 첫 로딩은 여전히 느리다. 압축과 청크 로딩으로 "받는 양" 자체를 줄이는 것이 렌더링 최적화만큼 중요하다.
브라우저에서 대용량 BIM 모델을 매끄럽게 보여주는 일은 여전히 기술적으로 까다롭지만, LOD·스트리밍·메모리 관리 세 축을 조합하면 실무에서 충분히 쓸 만한 수준의 성능을 확보할 수 있다.