웹 3D 프로젝트에서 라이브러리 이름부터 고르면 중요한 조건을 놓치기 쉽습니다. 제품 configurator, 건축 시뮬레이션, 지도와 게임은 모두 브라우저에서 3D를 보여주지만 데이터와 조작 방식이 다릅니다.
기술 선택에는 다음 항목이 먼저 필요합니다.
- 어떤 3D 파일을 받고 얼마나 자주 바꾸는가
- 모바일과 저사양 기기를 지원하는가
- 단순 관람인지 편집·계산·충돌 판정까지 필요한가
- GIS·BIM·상품·설비 데이터와 연결하는가
- 한 화면에 몇 개의 객체와 재질을 표시하는가
- 정확도와 프레임 속도 중 무엇을 우선하는가
브라우저와 라이브러리 지원 상태는 착수 시점에 다시 확인해야 합니다.
WebGL과 WebGPU의 역할
WebGL은 브라우저에서 GPU를 이용해 2D·3D 그래픽을 그리는 기반 API입니다. Three.js와 Babylon.js 같은 엔진은 WebGL의 셰이더, 버퍼와 렌더링 상태를 직접 다루는 부담을 줄입니다.
WebGPU는 더 현대적인 GPU API와 계산 기능을 웹에 제공합니다. 새 프로젝트에서 관심을 가질 만하지만, WebGPU를 선택한다고 기존 3D 자산과 기능이 자동으로 빨라지는 것은 아닙니다. 지원 브라우저와 장치, 사용하는 엔진의 렌더러 구현, 셰이더와 후처리 호환성을 확인해야 합니다. 현재 지원 범위는 MDN WebGPU 문서에서 확인할 수 있습니다.
WebGL을 당장 버리기보다 실제 병목이 렌더링, 데이터 변환, 네트워크, 메모리 중 어디인지 먼저 측정합니다.
Three.js
Three.js는 장면, 카메라, 재질, 조명, 애니메이션과 파일 로더를 제공하는 JavaScript 3D 라이브러리입니다.
잘 맞는 경우
- 제품 3D 뷰어와 configurator
- 프로모션과 인터랙티브 콘텐츠
- GLTF 기반 모델 뷰어
- 제품 요구에 맞춘 조작과 렌더링 파이프라인
- 기존 웹 애플리케이션에 3D 캔버스를 직접 통합
자유도가 높은 만큼 장면 구조, 상태 관리, 리소스 해제와 이벤트 연결을 직접 설계해야 합니다. 라이브러리 목록보다 Three.js 공식 예제에서 비슷한 기능이 어떤 방식으로 구현됐는지 확인하는 편이 빠릅니다.
React Three Fiber
React Three Fiber는 Three.js 장면을 React 컴포넌트와 상태 흐름으로 구성할 수 있게 합니다.
React 애플리케이션에서 상품 옵션이나 사용자 상태가 3D 장면과 함께 바뀌는 경우 잘 맞습니다. 컴포넌트 재사용과 화면 상태 연결이 편하지만, Three.js의 렌더링과 메모리 개념이 사라지는 것은 아닙니다.
프레임마다 바뀌는 값까지 일반 React 상태로 처리하거나, 큰 객체를 불필요하게 다시 만들면 성능 문제가 생길 수 있습니다. 복잡한 프로젝트에서는 선언형 UI와 렌더 루프의 경계를 정해야 합니다.
Babylon.js
Babylon.js는 장면 렌더링 외에도 물리, GUI, 검사 도구와 여러 기능을 통합한 웹 3D 엔진입니다.
잘 맞는 경우
- 게임에 가까운 상호작용
- 물리와 애니메이션이 많은 시뮬레이션
- 엔진의 편집·검사 도구를 활용하려는 프로젝트
- WebXR과 여러 렌더링 기능을 한 생태계에서 관리할 때
기능이 많다고 항상 개발이 쉬운 것은 아닙니다. 필요한 기능과 번들, 프로젝트 구조, 팀 경험을 비교해야 합니다.
CesiumJS
CesiumJS는 지구 좌표, 3D Tiles, 지형과 대규모 지리 데이터를 다루는 데 초점이 있습니다.
도시, 항공, 위성, 시설물과 GIS 데이터를 실제 좌표에 배치해야 한다면 일반 장면 엔진보다 적합할 수 있습니다. 반대로 작은 제품 한 개를 돌려보는 configurator에는 좌표·타일 체계가 불필요한 부담이 될 수 있습니다.
CesiumJS를 검토할 때는 3D Tiles 생성 과정, 좌표계, 지형·영상 데이터 공급자와 라이선스까지 확인합니다. 기술 범위는 CesiumJS 문서에서 볼 수 있습니다.
Unity Web 빌드
기존 Unity 프로젝트나 게임 자산이 있고 브라우저 배포가 추가 요구라면 Unity의 웹 빌드를 검토할 수 있습니다.
Unity는 게임 제작 도구와 에셋 파이프라인을 활용할 수 있지만, 초기 다운로드 크기, 메모리, 모바일 브라우저 지원과 웹 페이지 통합을 시험해야 합니다. 일반 웹 UI와 3D 화면 사이의 데이터 교환도 별도로 설계합니다.
웹 전용 제품을 처음부터 만든다면 Three.js나 Babylon.js와 비교 검증한 뒤 결정하는 편이 좋습니다.
파일 형식보다 자산 파이프라인이 중요하다
FBX, OBJ, STL, GLTF 같은 파일 이름만 적어서는 요구사항이 되지 않습니다. 원본이 어떻게 만들어지고 어떤 데이터를 보존해야 하는지 확인해야 합니다.
GLTF·GLB
웹 전송과 실시간 렌더링에 적합한 형식입니다. 재질, 애니메이션과 장면 구조를 담을 수 있습니다. 하지만 모델링 원본의 모든 기능과 메타데이터가 그대로 보존되는 것은 아닙니다.
STL
3D 프린팅에서 흔히 사용되며 주로 표면 형상을 담습니다. 단위, 색상, 재질과 부품 관계가 별도 정보로 필요할 수 있습니다.
BIM·CAD 데이터
정밀한 형상과 속성, 계층을 포함할 수 있지만 브라우저에서 원본을 그대로 렌더링하기 어렵습니다. 서버나 전처리 도구에서 메시를 단순화하고, 속성 데이터와 렌더링 데이터를 분리하는 과정이 필요할 수 있습니다.
자산 파이프라인에서는 다음을 정합니다.
- 원본 파일과 버전 관리 방식
- 단위·축·좌표계
- 메시 단순화와 LOD
- 텍스처 크기와 압축
- 부품 ID와 업무 데이터 연결
- 변환 실패와 품질 검사
서버와 데이터베이스는 3D 밖에서 결정된다
3D 화면이 있다고 특별한 백엔드가 항상 필요한 것은 아닙니다. 사용자, 권한, 프로젝트와 상품 데이터는 일반 웹 서비스처럼 설계할 수 있습니다.
공간 검색과 좌표 연산이 필요하면 PostgreSQL과 PostGIS를 검토할 수 있습니다. 대용량 타일과 모델 파일은 객체 스토리지와 CDN에 두고, 변환 작업은 백그라운드 작업으로 분리할 수 있습니다.
대규모이므로 특정 데이터베이스를 사용한다는 식으로 고르지 않습니다. 조회 패턴, 일관성, 공간 연산과 운영 경험을 기준으로 정합니다.
성능은 대표 데이터로 측정한다
웹 3D 견적에서 폴리곤 수 하나만 묻는 것으로는 부족합니다. 다음을 대표 장치에서 함께 측정합니다.
- 처음 화면이 보일 때까지 걸리는 시간
- 다운로드 용량
- GPU 메모리와 브라우저 메모리
- 프레임 속도와 입력 지연
- 동시에 보이는 객체와 드로우콜
- 투명 재질, 그림자와 후처리 비용
- 모델 교체 뒤 리소스가 해제되는지
- 저사양 모바일에서 브라우저가 종료되지 않는지
측정 결과에 따라 LOD, 인스턴싱, 텍스처 압축, 지연 로딩과 서버 전처리를 적용합니다.
작은 기술 검증판에서 확인할 것
전체 UI를 만들기 전에 가장 까다로운 실제 모델 하나로 검증합니다.
- 원본 파일을 웹용으로 변환합니다.
- 부품 ID와 업무 데이터를 연결합니다.
- 선택, 이동, 교체와 계산 중 핵심 상호작용을 구현합니다.
- 지원 대상 중 가장 낮은 기기에서 실행합니다.
- 로딩과 프레임, 메모리를 측정합니다.
- 새 모델을 추가하는 운영 절차를 실행합니다.
프로모션 데모는 한 번 잘 보이면 되지만 제품 configurator와 설계 도구는 데이터가 바뀌어도 같은 품질로 운영돼야 합니다. 검증판도 운영 과정을 포함해야 합니다.
선택 예시
- 상품 옵션에 따라 색상과 부품을 바꾸는 React 쇼핑몰은 Three.js 또는 React Three Fiber를 먼저 검토합니다.
- 물리와 게임형 상호작용이 많은 교육 시뮬레이션은 Babylon.js나 Unity를 비교합니다.
- 지형과 도시 데이터를 좌표 기반으로 보여주면 CesiumJS와 3D Tiles 파이프라인을 검토합니다.
- BIM·제조 데이터를 편집하는 도구는 렌더러보다 변환, 속성 데이터와 정밀도 요구를 먼저 검증합니다.
프레임워크는 이 판단 뒤에 따라오는 구현 선택입니다.
웹 3D 프로젝트의 대표 데이터와 기기 조건으로 기술 검증이 필요하다면 프로젝트 문의에 원본 파일 형식, 지원 기기와 필요한 조작을 알려주세요. 자산 변환, 렌더링과 서버 기능을 나눠 답하겠습니다.