고빈도 React 데이터 처리부터 Three.js·WebGPU 실험까지 이어지는 흐름은 하나의 공통된 판단을 가리킨다. 기술 이름이 아니라 작업 부하 특성으로 렌더링 아키텍처를 선택해야 한다. React의 ring buffer와 OffscreenCanvas는 한 종류의 부하를, Three.js와 WebGPU 작업은 다른 종류를 보여 준다.

둘 다 현대적인 인터페이스가 서로 다른 주기를 가진 여러 렌더링 도메인으로 구성될 수 있음을 시사한다.

변화 주기로 UI를 분류하라

첫 번째는 이산적인 UI다. 폼, 메뉴, 텍스트, 필터, 결과처럼 의도적인 작업에 따라 바뀌는 영역이다. 이곳에서는 semantic, 유지보수성, 접근성이 핵심이므로 DOM과 UI 프레임워크가 강점을 가진다.

두 번째는 연속적인 UI다. 스트리밍 차트, 밀도 높은 타임라인, 파티클, 오디오 반응형 비주얼, 3D 장면이 여기에 속한다. 이 영역에서는 컴포넌트 모델보다 프레임당 작업량과 데이터 경로가 더 중요할 수 있다.

canvas나 GPU로 옮길 보편적인 임계값은 없다

요소 수만으로 판단할 수는 없다. 같은 수의 점도 의도적인 동작에서만 바뀌면 문제없을 수 있지만, 계속 갱신되고 resize, animation, 입력 처리와 경쟁하면 문제가 될 수 있다.

그러므로 실제 경험을 프로파일링해야 한다. 데이터가 들어오는 방식, 사용자의 상호작용, semantic HTML이 필요한 부분, 지속적인 재그리기가 필요한 부분을 확인한다.

실용적인 3계층 모델

이는 필수 아키텍처가 아니다. 연속 작업의 주기가 전체 애플리케이션에 강요되지 않도록 경계를 세우는 도구다.

팀을 위한 판단 순서

1. DOM부터 시작하고 실제 경험을 측정한다.
2. 가능하면 집계나 windowing으로 표시 데이터를 줄인다.
3. 전체 스택을 바꾸기 전에 연속 렌더링 영역을 격리한다.
4. 시각적 또는 상호작용 가치가 분명할 때만 WebGPU나 3D를 도입한다.

5분 요약

• 렌더러는 변화 주기와 사용자 요구로 선택한다.
• DOM은 semantic이 필요하고 이산적으로 갱신되는 UI에 여전히 강하다.
• 계속 다시 그리는 영역에는 canvas나 GPU가 맞는다.
• 먼저 측정하고 병목을 격리한 뒤 복잡도를 더하라.

참고 자료

• Sixty Frames for the Record: A Three.js Game, Seven Fly-Throughs, and a Wall of CRTs
• Run Rob Run: Building a Music-Reactive Goo with Three.js and WebGPU
• Relighting Images with Depth Maps and Three.js
• Creating an Interactive 3D Cluster with Three.js, TSL and Three Start
• Exploring Procedural Geometry with Three.js and WebGPU
• Garden Anomaly: A Tiny WebGPU and TSL Experiment
• High-Frequency Real-Time Data in React: From Ring Buffers to OffscreenCanvas