Three.js를 쓰면 안 좋은 경우

Three.js는 강력하지만 모든 editor에 맞는 답은 아닙니다. Figma-like 2D editor를 만들 때는 Three.js가 줄여주는 복잡도와 새로 만드는 복잡도를 같이 봐야 합니다.

요구사항으로 backend를 고르는 코드

Three.js 사용 여부는 감이 아니라 renderer 요구사항으로 결정합니다.

function chooseRendererBackend(requirements: {
  nodeCount: number;
  needs3D: boolean;
  customBatchingCritical: boolean;
  heavyTextEditing: boolean;
  strictAccessibilityLayer: boolean;
}) {
  if (requirements.needs3D) return "three-webgl";

  if (
    requirements.nodeCount > 20000 ||
    requirements.customBatchingCritical ||
    requirements.heavyTextEditing ||
    requirements.strictAccessibilityLayer
  ) {
    return "custom-webgl-webgpu";
  }

  return "three-webgl";
}

처음 prototype은 Three.js로 빠르게 만들고, 병목이 “2D batching과 text/editor overlay 통제”로 확정되면 전용 renderer로 분리하는 전략도 가능합니다.

Three.js가 좋은 경우

2D와 3D가 섞인다
prototype 속도가 중요하다
camera/material/texture 기능을 빠르게 쓰고 싶다

복잡한 WebGL boilerplate를 줄이고 editor 구조를 먼저 검증할 수 있습니다.

전용 renderer가 나은 경우

수만 개 2D primitive batching
정밀한 텍스트 편집
DOM accessibility와 깊은 통합
완전히 통제된 shader/buffer layout

이 경우 Three.js abstraction을 우회하는 코드가 많아지고, 차라리 전용 WebGL/WebGPU renderer가 단순해질 수 있습니다.

오늘의 핵심

Three.js를 쓸지 말지는 취향 문제가 아닙니다. editor 요구사항, 성능 병목, 팀의 유지보수 능력으로 결정해야 합니다.