Cesium.js 도입 결정

한 줄 요약

메모리 누수, 고객사의 Mesh 시각화 요구, 기존 뷰어의 구조적 한계가 겹치면서, 1인 마이그레이션이라는 리소스 제약 속에서 비용·커스텀 자유도·데이터 보안·대용량 Mesh 지원을 기준으로 세 가지 선택지를 비교한 끝에 "자체 서버 Builder + Cesium.js"를 선택했다.

왜 전환이 필요했는가

이 결정의 출발점은 하나의 기술 문제가 아니라, 동시에 닥친 여러 압력이었다.

메모리 문제: FBXLoader의 메모리 누수를 dispose()로 완화했지만, 메모리 변동폭 자체는 개선되지 않았다. 구조적 한계였다.

비즈니스 요구: 계약 가능성이 높은 고객사들이 Point Cloud 뿐만 아니라 Mesh 모델 시각화를 필수 기능으로 요구하고 있었다. 이는 계약 성사를 위해 반드시 충족해야 하는 조건이었다.

사용자 선호도: Point Cloud는 점과 점 사이에 빈 공간이 있어 현실감이 떨어진다. Mesh는 세 점을 연결한 면에 실제 이미지를 입혀 현실적인 시각화를 제공한다. 사용자들은 명확하게 Mesh를 선호했다.

경쟁 환경: 동일 도메인의 경쟁 서비스들이 이미 Mesh 시각화를 제공하고 있었다.

기존 뷰어의 구조적 한계: 새로운 웹 최적화 데이터 형식 도입이 불가능했고, 커스텀 기능 개발과 커스텀 디자인 적용이 어려웠으며, 건설 업계에서 사용하는 다양한 파일 포맷 지원도 부족했다.

이 다섯 가지 압력이 동시에 존재하는 상황에서, 부분적 개선이 아닌 3D 뷰어 시스템의 전면 교체가 필요하다는 결론에 도달했다.

기술 조사: Cesium의 입력 포맷에서 역산하기

조사는 "우리 데이터팀이 현재 뭘 뽑고 있는가"가 아니라, "Cesium.js가 받아들일 수 있는 입력 포맷을 우리 데이터팀이 뽑아낼 수 있는가"에서 출발했다.

Cesium.js가 지원하는 입력 포맷(glb, obj, ifc, geoJSON 등)을 먼저 확인한 뒤, 데이터팀이 기존 워크플로우에서 이 포맷들을 출력할 수 있는지 검증했다. 그 위에서 웹에 가장 최적화된 포맷과 3D Tiles 변환의 중간 단계로 뽑아내기 좋은 포맷을 중심으로 2주간 조사를 진행했다.

이 역산적 접근이 중요했던 이유는, 단순히 기존 포맷을 Cesium에 끼워맞추는 것이 아니라, 최종 출력(웹에서의 3D Tiles 렌더링)에서 거꾸로 올라가며 최적의 데이터 흐름을 설계할 수 있었기 때문이다.

세 가지 선택지 비교

선택지 1: 외부 API 기반 렌더링

외부 API를 활용하는 방식. 도입이 빠를 수 있지만, 클라우드/API 비용이 지속적으로 발생하고, API 의존도가 높아 커스텀 자유도가 떨어진다. 데이터가 외부 서버를 거치므로 보안 측면에서도 불리했다.

선택지 2: 클라우드 빌더 + Cesium.js

Cesium의 클라우드 서비스로 3D Tiles를 빌드하고, 프론트엔드에서 Cesium.js로 렌더링하는 방식. 빌드 과정이 간편하지만, 서비스 비용이 발생하고, 빌드 과정에 대한 통제권이 없다. 대용량 드론 데이터를 올릴 때 비용이 크게 증가할 수 있었다.

선택지 3: 자체 파이프라인 + Cesium.js (최종 선택)

3D Tiles 변환 파이프라인을 자체적으로 구축하고, 프론트엔드에서 Cesium.js로 렌더링하는 방식. 초기 구축 비용이 가장 크지만, 비용 통제·커스텀 자유도·데이터 보안 모두에서 우세했다.

왜 선택지 3이었는가

결정적 요인은 대용량 드론 이미지 기반 Mesh 모델을 3D Tiles로 변환하여 웹에 올릴 수 있어야 한다는 핵심 요구사항이었다. 수천 장의 드론 사진으로 만든 대용량 Mesh를 웹에서 끊김 없이 볼 수 있으려면, 3D Tiles의 LOD(레벨 오브 디테일) 구조가 필수였다. 변환 과정을 직접 통제할 수 있어야 최적화의 여지가 생긴다.

여기에 결정적 제약이 하나 더 있었다: 마이그레이션 담당자가 1명(본인)이었다. 리소스가 극도로 제한된 상황에서, 직접 3D 뷰어를 처음부터 설계하는 것은 불가능했다. Cesium.js가 제공하는 지구본, 카메라 조작, 3D Tiles 로딩 같은 기반 기능 위에서 필요한 기능만 직접 구현하는 전략이 유일하게 실현 가능한 방법이었다.

또한 Three.js도 대안으로 검토했으나, 당시 기준으로 대용량 모델 렌더링에 부적합하다고 판단했다. (최근에는 Three.js 생태계가 개선되어 상황이 다를 수 있다.)

실제로 만들어진 두 가지 3D Tiles 경로

선택지 3을 기반으로 실제 서비스에 적용된 3D Tiles 변환은 두 가지 경로로 나뉜다:

경로 1: 드론 이미지 → 3D Tiles

드론으로 촬영한 수천 장의 이미지를 Mesh 기반 3D Tiles로 변환하는 과정. 이 변환은 혼자서 구축할 수 없는 규모의 기술이었기 때문에, 기존에도 Point Cloud 생성에 사용하던 상용 포토그래메트리 도구를 그대로 활용했다. 뷰어 전환 이전에도 이 도구로 Point Cloud를 뽑아 올리고 있었으므로, 데이터팀의 워크플로우 변경을 최소화할 수 있었다.

경로 2: IFC → 3D Tiles

건설 BIM 데이터(IFC)를 3D Tiles로 변환하는 과정. 이 경로는 자체 파이프라인을 직접 설계하고 구축했다. IFC 요소 추출, 하이브리드 타일링, LOD 생성, 좌표 정합, Draco 압축의 5단계 자동화 파이프라인으로, 이 노드의 상세 내용은 "IFC→3D Tiles 자동 변환 파이프라인" 노드에서 다룬다.

설득 과정

이 결정은 혼자 내린 것이 아니다. 문제 분석부터 기술 비교, 일정 산정까지 체계적인 문서를 작성하고 전체 팀원을 모아 논의했다:

• 기존 문제 원인 분석 (메모리 누수 데이터)
• 기존 뷰어 vs Cesium 성능 비교 (벤치마크 결과)
• 3D Tiles 모델 형식 분석 (기술 타당성)
• 예상 작업 및 개발 기간 산정 (실현 가능성)
• 기능 개선 개발 보고서 요약 (전체 그림)

자신의 판단에 대해 피드백을 받고 설득하는 과정을 거쳤으며, 팀 전체가 동의하는 분위기였고 강하게 서포트해주었다.

PoC: "기뻤지만, 좌표계가 문제였다"

Cesium.js를 실제 dev 환경에 올려보고, 기존에 Point Cloud로만 표현했던 모델들을 Mesh로 업로드 테스트를 진행했다.

처음에는 기뻤다. 모델이 화면에 바로 나타났고, 흰 화면 크래시가 발생하지 않았다. FBXLoader에서 겪었던 메모리 누적 문제가 사라진 것이다.

하지만 좌표계가 문제였다. 기존 뷰어는 단순히 (0, 0, 0)을 원점으로 모델을 배치했고, 모델들은 EPSG 5186(한국 중부 좌표계)으로 이루어져 있어서 좌표 문제가 자연스럽게 해결됐다. 그러나 Cesium은 EPSG 4978(지심 직교 좌표계, ECEF)을 사용한다. 기존 모델들의 좌표를 Cesium이 이해할 수 있는 체계로 변환하는 과정이 필요했고, 이 과정에서 많은 어려움이 있었다.

이 좌표 변환 문제가 이후 좌표계 변환(EPSG→WGS84→ECEF), 지오이드고 보정, 자오선 수차 보정 노드로 이어진다.

이 경험에서 추출한 원칙

1. 기술 선택은 기술적 우월성만으로 결정되지 않는다. 비용, 보안, 팀 리소스, 비즈니스 요구사항을 함께 놓고 봐야 한다. 당시 상황에서 "실현 가능한 최선"을 찾는 것이 핵심이었다.

2. 설득은 구두가 아니라 문서로 한다. 문제 분석, 벤치마크, 기술 비교, 일정 산정까지 체계적인 문서를 준비하고 팀 전체와 논의한 것이 합의를 이끌어낸 핵심이었다.

3. PoC는 "되는지 확인"이 아니라 "어디서 막히는지 발견"이다. Mesh가 화면에 나타나는 것을 확인한 건 시작에 불과했다. 진짜 어려운 문제(좌표계 변환)는 PoC 이후에 드러났다.

4. 역산적 조사가 효율적이다. "현재 가진 것에서 출발"이 아니라, "최종 목표(Cesium 렌더링)에서 거꾸로 올라가며" 필요한 데이터 흐름을 설계하면, 불필요한 탐색을 줄일 수 있다.