Markdown 원본 다운로드

3D 공간 스파이크 결과 보고서: 엔진 비교와 선택

작성일: 2026-10-04 · 테스트 기간: 2026-10-02~04 · 대상: 이 저장소의 로컬 스파이크

발표 자료: HTML · PDF 10장. HTML은 방향키로 페이지를 넘길 수 있으며, 전체 보기와 인쇄도 지원한다.

1. 검토 결과 요약

이번 테스트에서는 PlayCanvas + Ammo를 우선 후보로 추천한다. 같은 Sunnyvale 원본을 데스크톱에서 열었을 때 앱이 준비될 때까지 걸린 시간이 가장 짧았고, iPhone 11에서도 대형 원본의 준비 완료를 두 차례 확인했다. 핵심 기능은 세 구성 모두 구현하고 확인했으므로, 기능 지원 여부보다 로딩 성능의 차이가 선택에 더 큰 영향을 준다. 이번 스파이크 범위에서의 추천이며, 최종 엔진 선택이나 전체 서비스의 성능을 보장하는 결론은 아니다.

Three.js + Spark + BVH도 대안으로 남겨둘 수 있다. 축소본을 여는 데 성공했어도 iPhone에서 대형 SH3 원본을 열지 못한 문제는 남아 있다. 기존 Three.js 시스템과의 연동이 중요하고 모바일용 데이터의 축소나 SH 조정이 가능하다면 선택이 달라질 수 있다. 다만 연동의 이점과 실제 작업 비용은 이번 테스트에서 측정하지 않았다.

Rapier를 기본 구성으로 바꿔야 할 근거는 아직 부족하다. 일부 Node 테스트에서는 벽이나 계단의 처리 비용이 낮았지만, 다른 구간과 준비 비용에서는 그렇지 않았다. 현재 Rapier 구성에는 가림 처리와 디버깅에 쓰는 BVH도 남아 있어 물리 라이브러리만 따로 비교한 결과는 아니다.

2. 비교 대상과 테스트 환경

장면이나 빌드 버전, 통계 집계 범위가 다른 결과는 합산하지 않았다. 로딩 시간은 앱에 준비 완료 표시가 나올 때까지 측정했으며, GPU가 첫 화면을 그리는 시점과는 다르다. 모바일의 합성 TouchEvent 테스트는 앱의 입력 처리를 확인한 것으로, 실제 손가락 조작의 사용성을 검증한 결과는 아니다. 모든 수치는 이번 로컬 테스트 환경에서 측정한 값이다.

3. 데스크톱 로딩 시간과 전송량

Sunnyvale 원본으로 캐시 초기화(cold)와 캐시 유지(warm) 조건에서 구성별로 각각 3회, 총 18회 측정했다. 아래 표는 각 3회의 중앙값이다. cold에서는 HTTP 브라우저 캐시만 초기화했다. 프로세스·OS·DNS·GPU 캐시는 초기화하지 않았다. 요청을 가로채지 않았으며, 페이지와 워커(worker)의 HTTP 요청을 함께 집계했다.

MB는 1,000,000바이트 기준이다. localhost의 preview 빌드에서 측정했으므로 원격 CDN이나 모바일 회선의 로딩 시간을 예측하는 데 사용할 수 없다. 현재 구현 전체를 비교한 결과이며, 렌더러나 물리 라이브러리 하나의 영향만 분리한 값도 아니다.

Hall에서 시대를 연속 20왕복 전환했다. 각 방향의 첫 표본을 제외한 19회 중앙값은 다음과 같다. 클릭 요청부터 switchDone까지 측정했으며, GPU가 첫 화면을 표시할 때까지의 시간은 아니다.

근거: 로딩·메모리 비교, 로딩 원본 JSON, 시대 전환 원본 JSON.

4. 메모리, 이동 성능, 안정성

메모리 측정 범위

Sunnyvale을 캐시 유지(warm) 상태에서 3회 실행한 결과의 중앙값이다. 안정화 시간을 두고 GC를 실행한 뒤 측정했으며, 메인 스레드와 워커를 나눠 기록했다.

공유 버퍼가 중복으로 집계될 수 있으므로 backing storage를 합산한 값을 실제 RAM 사용량으로 볼 수 없다. GPU/VRAM, 전체 프로세스 RAM, iPhone 메모리도 측정하지 않아 전체 메모리 사용량의 우열은 판단을 보류한다.

이동 처리 비용과 프레임 간격

데스크톱 브라우저에서 정지 상태와 외벽을 향해 전진하는 상태를 각각 30초씩 3회 측정했다. 세 구성의 총 실행 횟수는 18회다. 계측한 처리 시간의 p95를 반복별로 구한 뒤 중앙값을 계산하면 0.1~0.6ms 범위였다. Three.js는 앱의 보행 step, PlayCanvas는 엔진의 rigidbody system을 측정한다. 측정 범위와 벽에 닿는 위치가 달라 물리 엔진의 순위를 매길 수는 없다.

같은 테스트에서 측정한 전체 프레임 간격은 아래와 같다. 30초 구간마다 구한 p95의 3회 중앙값이며, 렌더링·물리·앱 실행이 모두 포함된다.

이번 조건에서는 PlayCanvas의 프레임 간격이 더 일정했다. 카메라와 접촉 위치, 처리 범위가 같지 않고 CPU와 GPU의 실행 시간을 나눠 분석하지 않아 차이의 원인은 확인하지 못했다. 작은 Hall 장면의 안정성 테스트 수치와는 따로 해석해야 한다.

별도 Node 60Hz 테스트의 p95 중앙값은 BVH/Rapier 각각 시작점(spawn) 0.0072/0.0393ms, 외벽 0.2963/0.1876ms, 계단 0.3140/0.1121ms였다. 구간에 따라 더 빠른 구성이 달랐다. 렌더링과 네트워크를 제외한 계산 테스트이므로 모바일 성능을 예측하는 데 사용할 수 없다.

추가로 현관 마루의 바닥을 보정한 뒤에는 세 구성 모두 왕복 이동, 정지, 난간 충돌 테스트를 통과했다. 원본 충돌 데이터에서 비어 있던 부분을 작은 공통 바닥으로 채운 결과다. Rapier의 계단 이동 차이는 남아 있으며, 분할·시대 장면에서 Rapier와 iPhone을 다시 검증한 결과는 아니다. 이전 문서에 기록한 벤치 왕복 이동 실패와 이 추가 테스트의 결과를 구분해야 한다.

약 10분간의 안정성 테스트

Hall에서 구성별로 1회씩, 20×30초 구간 동안 시대 전환과 패널·충돌 표시 조작을 테스트했다. 세 구성 모두 앱 예외, unhandled rejection, 앱 진단 오류, WebGL context lost가 확인되지 않았다. 프레임 간격 p95는 세 구성 모두 17.4ms였다. PlayCanvas에는 favicon 404 메시지가 별도로 있어 콘솔 메시지가 전혀 없었다고 볼 수는 없다.

이 결과는 작은 Hall 장면에 한정된다. Sunnyvale 대형 원본이나 모바일의 장시간 안정성, 강제로 WebGL 컨텍스트를 잃은 뒤의 복구, 메모리 누수 여부는 검증하지 않았다.

근거: 이동 처리 비용, Node 원본, 현관 바닥 보정, 안정성 비교, 안정성 원본.

5. iPhone 테스트 결과

대형 원본과 비교용 데이터

PlayCanvas의 두 실행에서 앱 준비 완료 표시는 약 14.97초와 19.11초에 나왔다. 캐시와 실행 조건을 맞춘 반복 비교가 아니므로 BVH의 비교용 데이터와 몇 배 빠른지 계산하지 않는다. 첫 실행의 탐색 프레임 기록에는 약 1.57초 지연도 있었다. 로딩 성공만으로 탐색이 부드럽다고 판단할 수는 없다.

대형 원본이 열리지 않은 원인은 아직 확인하지 못했다. 고차 SH 처리와 메모리 할당이 조사 대상이지만, 메모리 부족(OOM)이나 특정 SDK의 결함으로 단정할 수는 없다. 다운로드가 끝났어도 데이터 디코딩과 앱 준비까지 끝난 것은 아니다. 추가 테스트에서 900,000점 단일 축소본의 준비 완료를 확인한 시각은 48.501초였지만, 정확히 그때 준비됐다는 뜻은 아니므로 로딩 시간으로 사용하지 않는다.

작은 Hall 장면에서 정지 상태의 프레임 간격

온도·배터리·실행 순서·캐시를 통제하지 않았고 hasFocus=false였다. 이번 조건에서는 PlayCanvas의 정지 상태 프레임 간격이 짧았다. 초기 이동 테스트는 바닥 밖으로 떨어지거나 구성별 복구 방식이 달라 정상 보행 성능 비교에서 제외했다. 이후 데스크톱에서 확인한 복구 기능의 결과를 iPhone 성능 재측정 결과와 섞지 않는다.

근거: 모바일 비교, 원본, 로딩 기록, 디코딩 비교 테스트, 비교 테스트 원본.

6. 핵심 기능과 장면 분할 로딩

Sunnyvale을 900,000점 SH0로 다시 인코딩한 뒤 X축 방향으로 6개 구역으로 나눴다. 원본 3,999,361점 SH3와는 시각 품질이 다르다.

• 시작 시 불러오는 데이터는 8.72MB, 축소·분할한 전체 데이터는 18.39MB다. 약 52.6% 감소는 같은 축소·분할 데이터 전체를 기준으로 계산했다. 58.07MB 원본과 같은 품질을 유지하면서 줄인 수치가 아니다.
• 테스트한 경로에서는 상세 구역을 최대 2개 유지했고, 원거리 표현을 포함한 논리적 상주 점 수는 최대 448,028점이었다. 원거리 표현 30,003점은 화면에서 숨긴 구역도 메모리에 남는다. 시작 시 실제 표시 점 수는 434,093점이다. 이 점 수를 RAM 절감량으로 환산하지 않는다.
• 충돌 데이터를 나누면서 원본 면은 유지했다. 경계에서 중복된 면 때문에 삼각형은 337,680→344,098개로 약 1.90% 늘었으며, 새 바닥을 추가한 것은 아니다.
• 정상 동작과 오류 상황을 테스트한 9개 원본 기록은 모두 passed:true다. iPhone에서는 합성 이벤트로 입력했으며, 프레임 p95나 실제 RAM 사용량, 장시간 탐색 성능을 측정한 결과는 아니다.
• 추가 데스크톱 연동 테스트에서 PlayCanvas의 1 splats lost due to sortKey overflow 경고가 7회 있었다. 시각 품질에 영향을 줄 가능성이 있어 확인이 필요한 항목으로 남긴다.

과거 장면은 현재 촬영한 SOG에서 가상 벽과 설명을 바꿔 테스트했다. 실제 과거 건물이나 시대별 바닥, 역사 자료를 제작하고 검증한 결과는 아니다.

근거: 핵심 기능, 화면·충돌 데이터 함께 분할하기, 9개 원본 기록 (원본 저장소 파일), Sunnyvale 시대 전환·설명 연동.

7. 벽 비침: 두 렌더러에서 확인한 품질 문제

두 앱에서 카메라 위치와 방향을 같게 맞췄을 때, 원본 SOG의 벽 뒤에 둔 불투명 주황색 표시가 벽을 통해 보였다. 선택한 픽셀의 시선 방향에서 충돌 벽까지의 거리는 1.644~1.809m로, 카메라의 근거리 표시 한계(near)인 0.05m보다 충분히 멀었다. 이 조건에서 나타난 현상을 단순히 카메라 근접 영역이 잘린 결과로 설명하기는 어렵다.

사용자가 처음 본 빨간 박스와 위치 JSON은 남아 있지 않다. 당시 화면을 정확히 재현했는지, 어두운 형태가 실제 가구인지 판단하지 않는다. 두 앱에서 같은 현상이 보였다는 사실만으로 SOG 원본의 문제인지, 특정 렌더러의 문제인지 단정할 수도 없다.

벽 일부에 불투명 GLB 면을 덧댄 테스트에서는 고정된 4시점×2엔진의 시험용 표시 영역 차이가 0이었다. 해당 영역을 가릴 수 있음을 확인한 것이다. 이어 이동·시대 전환·근접 시점의 화면 76장을 저장했다. 벽 가까이에서 아래를 보면 보정 면의 범위와 질감 경계가 드러났고, 표시로 향하는 시선이 보정 면의 위쪽을 벗어났다. 부분 보정은 가능했지만 완성된 보정 데이터로 보기는 어렵다.

벽을 제대로 가리는지는 두 렌더러 모두 확인해야 할 품질 문제다. 엔진 선택과 별도로 촬영 데이터와 보정 면을 제작하고 검수해야 한다. 이번 보고서에서는 여기까지 확인한 결과로 판단하며, 추가 보정을 완료 조건으로 삼지 않는다.

근거: 벽 비침 조사, 고정 시점 원본 (원본 저장소 파일), 이동·시대 전환·근접 시점 기록, 이미지 갤러리.

8. 제작·변경 작업과 비용

Sunnyvale 데이터 18개를 생성하는 데 걸린 80.325초는 프로그램의 변환 시간이다. 사람이 제작하거나 검수한 시간이 아니다. 실행 중 필요한 데이터만 불러오면 요청량은 줄지만, 현재 배포 방식에서 저장 용량까지 줄어드는 것은 아니다. 이번 구현에서는 PlayCanvas Editor를 사용하지 않으므로 Editor 사용료를 필수 비용으로 포함하지 않는다.

근거: 제작·변경 작업과 의존성.

9. 엔진 선택에 반영할 사항

1. 대형 원본을 모바일에서도 열고 초기 로딩 시간을 줄이는 것이 중요하다면 PlayCanvas + Ammo를 우선 검토한다. 이번 테스트에서 가장 직접적으로 확인한 장점이다.
2. 기존 Three.js 시스템과의 연동이 중요하고 데이터 축소나 SH 조정이 가능하다면 Three.js + BVH를 대안으로 검토한다. 원본 SH3의 모바일 로딩 문제와 시각 품질 변화도 함께 고려해야 한다.
3. 현재 결과만으로 Rapier를 기본 구성으로 채택하지는 않는다. 특정 이동 기능이 필요할 때 검토할 후보로 남겨둔다.
4. 벽 비침, 실제 시대별 데이터, 모바일 사용성, 제작 시간은 공통으로 남은 검토 항목이다. 스파이크에서 모든 문제를 수정하지 않아도 후보 선택은 가능하다.

이 자료는 후보를 고르는 데 사용한다. 전체 RAM·GPU 메모리, 실제 손가락 조작, Android, 대형 장면의 모바일 장시간 안정성, 전체 제작·운영비는 아직 판단할 수 없다. 해당 항목을 검증 완료로 표시하거나 가중 점수로 환산하지 않는다.

10. 근거 자료와 빌드 버전

아래 짧은 식별자는 모두 local-4d5905679d2e- 뒤의 값이다. 빌드 버전이 다른 수치를 같은 빌드에서 측정한 결과처럼 합산하지 않았다.

이 보고서와 발표 자료는 기존 테스트 기록을 정리한 것이다. 작성 과정에서 앱 소스를 수정하거나 성능을 다시 측정하지 않았다.