Potree에서 Cesium으로: 3D 뷰어 마이그레이션 전략
한 줄 요약
Cesium 도입을 결정한 후, 1인 프론트엔드 개발자가 기존 서비스를 운영하면서 3D 뷰어 엔진을 교체했다. PoC 3주 만에 핵심 기능을 검증하고, 기능 커버리지를 28개에서 43개로 확장하면서 메모리 누적 문제를 해소했다.
1인 개발자가 뷰어 엔진을 교체해야 했다
cesium-adoption 노드에서 Cesium.js 도입을 결정했다. 그러나 결정과 실행 사이에는 큰 간극이 있었다.
기존 Potree 기반 뷰어에는 28개의 기능이 구현되어 있었다. 이 기능들을 모두 Cesium에서 재구현해야 했고, 좌표계 변환 등 Potree에서는 겪지 않았던 새로운 기술 과제도 존재했다. 동시에 기존 서비스의 운영과 유지보수를 멈출 수 없었다.
마이그레이션 담당자는 1명(본인)이었다.
마이그레이션 전략 비교
| 전략 | 장점 | 단점 | 우리 상황에서의 판단 |
|---|---|---|---|
| Big Bang (전면 교체) | 깔끔한 전환 | 전환 실패 시 전체 서비스 위험 | 1인 개발에서 리스크 과도 |
| Strangler Fig (점진적 교체) | 리스크 분산 | 두 뷰어 동시 유지, 복잡도 2배 | 유지보수 부담 과중 |
| PoC 선행 + 단계적 구현 | 핵심 기능 먼저 검증, 리스크 관리 가능 | PoC 기간 동안 이중 작업 | 최종 선택 |
Big Bang은 매력적이지만, 전환 과정에서 발견되는 문제(좌표계 변환 같은)를 예측할 수 없다. 1인 개발에서 전면 교체에 실패하면 복구할 수 있는 백업 인력이 없다.
Strangler Fig은 이론적으로는 안전하지만, Potree와 Cesium의 렌더링 모델이 근본적으로 다르다. 같은 화면에 두 뷰어를 공존시키는 것은 기술적으로 복잡하고, 두 코드베이스를 동시에 유지하는 것은 1인 개발에서 현실적으로 불가능했다.
PoC 선행 + 단계적 구현을 선택했다. PoC 3주 동안 핵심 기능(3D 모델 로드, 카메라 조작, 기본 측정)이 Cesium에서 동작하는지 검증하고, 검증된 후에 기능별로 순차 구현하는 전략이다.
PoC 3주: 무엇을 검증했는가
PoC에서 검증한 핵심 항목:
- 대용량 3D Tiles 로드: 수천 개 타일이 브라우저에서 안정적으로 렌더링되는지
- 메모리 안정성: FBXLoader에서 겪었던 메모리 누적이 발생하지 않는지
- 기본 인터랙션: 카메라 조작, 모델 클릭, 엔티티 생성이 가능한지
PoC 결과는 긍정적이었다. 3D 모델이 화면에 즉시 나타났고, 메모리 누적 없이 안정적으로 동작했다. 하지만 좌표계 문제가 발견됐다. 기존 모델들은 EPSG 5186(한국 중부 좌표계)으로 구축되어 있었고, Cesium은 ECEF 좌표계를 사용한다. 이 좌표 변환 문제가 coordinate-transform, geoid-correction, meridian-convergence 노드로 이어지는 일련의 도전을 만들어냈다.
전환 결과
| 지표 | 전환 전 (Potree) | 전환 후 (Cesium) | 변화 |
|---|---|---|---|
| 기능 수 | 28개 | 43개 | +15개 신규 |
| Mesh 시각화 | 불가 | 가능 | 신규 |
| 2D/3D 지도 전환 | 불가 | 가능 | 신규 |
| 실시간 모델 편집 | 불가 | 가능 | 신규 |
| 메모리 안정성 | 170MB 이상 누적 | 안정 범위 유지 | 해소 |
| PoC 기간 | - | 3주 | - |
| 전체 개발 기간 | - | 약 15주 (3~4개월) | - |
기존 28개 기능을 모두 재구현하면서 15개의 신규 기능을 추가했다. 기존에 불가능했던 Mesh 시각화, 2D/3D 지도 전환, 실시간 모델 편집이 가능해졌다.
마이그레이션에서 가장 어려웠던 것
기술적으로 가장 어려운 부분은 기능 재구현이 아니었다. 좌표계 변환이었다.
Potree는 로컬 좌표 공간에서 동작하므로 좌표 문제가 존재하지 않았다. Cesium은 지구본 기반이므로, 모든 모델을 ECEF 좌표계로 변환해야 한다. 이 과정에서 EPSG→WGS84→ECEF 변환, 지오이드고 보정(2030m 높이 차이), 자오선 수차 보정(0.51도 회전 오차)이라는 세 가지 추가 과제가 발생했다.
이 좌표 관련 문제들은 PoC에서는 드러나지 않았다. 실제 운영 데이터를 올리고 나서야 "모델이 지면 아래에 가라앉는다", "건물 끝단이 수 미터 틀어진다" 같은 증상이 나타났다.
이 경험에서 추출한 원칙
-
마이그레이션의 진짜 어려움은 "알려진 기능의 재구현"이 아니라 "모르는 문제의 발견"이다. 28개 기능을 재구현하는 것은 시간 문제다. 좌표계 변환처럼 기존 시스템에서는 존재하지 않았던 문제를 발견하고 해결하는 것이 진짜 도전이다.
-
PoC의 목적은 "성공 확인"이 아니라 "실패 지점 발견"이다. PoC에서 "된다"는 것을 확인하는 것은 절반이다. 나머지 절반은 "어디서 막히는지"를 발견하는 것이다.
-
1인 마이그레이션에서는 전략의 선택이 기술력보다 중요하다. Big Bang으로 갔다면 좌표계 문제에서 멈춰서 전체 일정이 밀렸을 것이다. PoC로 미리 발견했기 때문에 나머지 기능 구현과 병행하여 해결할 수 있었다.
대규모 마이그레이션을 앞두고 있다면, 기존 기능 목록을 먼저 작성하고 PoC에서 가장 리스크가 높은 기능 3개를 먼저 검증하라.
Potree에서 Cesium으로: 3D 뷰어 마이그레이션 전략
문제 발견과 결정