three.js 급상승 배경과 AI 생성 3D 웹 장면 검수법

three.js는 웹 브라우저 안에서 3D 장면을 코드로 조립해 보여 주는 자바스크립트 라이브러리입니다. 공식 사이트가 표시하는 현재 버전은 r187이며, 문서, 예제 모음, 브라우저에서 바로 쓰는 에디터, 셰이더 작성 체계인 TSL 가이드, 개발자 도구가 한곳에 정리되어 있습니다. 별도 설치형 엔진 없이 웹 페이지를 열 수 있는 환경이면 같은 결과를 볼 수 있기 때문에, 디자이너의 인터랙티브 시안부터 영상 소스, 제품 3D 뷰어까지 쓰임새가 넓습니다.

급상승 신호는 규모가 작지만 최근 7일에 몰려 있습니다

레이더 집계에서 three.js의 신호 점수는 55.0/100, 단계는 급상승입니다. 최근 7일 언급은 4건으로 그 전 7일의 1건에서 늘었고, 30일 누적이 5건이므로 관측 대부분이 최근 한 주에 모여 있습니다. 회자 채널은 3곳, 언급한 사람·사이트는 4곳으로 그 전 7일의 1곳에서 늘었습니다. 절대량이 작아서 대중적 유행으로 보기는 어렵고, 서로 다른 실무자 층이 비슷한 시기에 three.js를 다시 꺼내 들기 시작한 초기 신호로 읽는 편이 맞습니다. 처음 포착된 시점이 2022년 4월이라 새로 등장한 도구가 주목받는 경우도 아닙니다. 오래된 기반 도구가 새로운 작업 방식과 만나면서 다시 호출되는 패턴입니다.

Muckle 분석으로 최근 언급의 결을 나눠 보면 세 갈래입니다. 하나는 스크롤로 우주의 끝까지 나아가는 장면이나 명절 소원을 함께 띄우는 공유 하늘처럼 개인이 만든 인터랙티브 데모입니다. 다른 하나는 조명, 그림자, 재질, 텍스처, 3D 텍스트를 차례로 익히는 입문 학습 기록이고, 마지막은 코드로 애니메이션 숏폼이나 영상을 만드는 AI 영상 도구 흐름 안에서 등장하는 사례입니다. 같은 시기 연구 쪽에서도 LLM이 three.js 코드로 3D 세계를 생성하고 그 결과를 평가하는 논문이 이어지고 있습니다. 이 신호를 특정 버전 출시의 효과로 읽을 근거는 없습니다. 오히려 'AI가 코드로 3D를 만든다'는 사용 방식이 퍼지면서 three.js가 그 출력 형식으로 자주 선택되는 흐름으로 보는 편이 자료와 잘 맞습니다.

장면, 카메라, 렌더러만 이해하면 구조가 읽힙니다

three.js의 기본 구조는 단순합니다. 물체를 담는 장면(Scene), 어디서 볼지 정하는 카메라, 그 결과를 화면의 캔버스에 그리는 렌더러가 세 축입니다. 물체는 형태를 정의하는 지오메트리와 표면을 정의하는 머티리얼을 묶은 메시로 만들고, 여기에 조명을 더하면 입체감이 생깁니다. 매 프레임 렌더러를 호출하는 애니메이션 루프가 돌아가면서 움직임이 만들어집니다.

외부에서 만든 모델은 glTF 계열(.glb) 로더로 불러옵니다. AI 이미지-3D 도구나 DCC 도구에서 내보낸 결과물이 보통 이 경로로 들어옵니다. 공식 문서에는 기존 WebGL 기반 렌더러와 함께 WebGPU 렌더러, 그리고 노드 방식으로 셰이더를 조합하는 TSL 항목이 있어, 그래픽 API가 바뀌는 시기에도 같은 라이브러리 안에서 코드를 이어 갈 수 있게 설계되어 있습니다. 공식 예제 페이지는 카메라 컨트롤, 후처리, 파티클, 물리 같은 패턴을 실행 가능한 코드로 제공하므로 처음 만드는 사람은 문서보다 예제를 복사해 고쳐 보는 쪽이 빠릅니다.

결과가 하나의 캔버스에 그려진다는 점은 작업 방식에 영향을 줍니다. 웹 페이지의 다른 요소와 달리 장면 내부의 물체는 일반 DOM 검사 도구로 보이지 않습니다. 브라우저 3D 코드를 평가하는 연구에서도 이 불투명성이 기존 자동 평가의 맹점으로 지적됩니다. 공식 사이트가 별도의 개발자 도구를 안내하는 이유도 여기에 있습니다.

디자인, 영상, 3D 작업에서 쓰는 흐름은 이렇습니다

제품 3D 뷰어와 랜딩 페이지. 제품 모델을 .glb로 내보내 로더로 불러오고, 궤도 컨트롤과 환경광을 붙인 뒤 스크롤 위치에 따라 카메라 경로를 바꾸면 인터랙티브 소개 페이지가 됩니다. 디자이너는 머티리얼 값과 카메라 동선을 정하고, 개발자는 로딩 최적화와 반응형 처리를 맡는 분업이 자연스럽습니다.

코드 기반 영상 소스. 장면을 프레임 단위로 고정 시간 간격으로 진행시키며 캔버스를 이미지로 저장하면 영상 편집 도구에 넣을 시퀀스가 됩니다. 실시간 재생에 의존하지 않고 시간을 코드로 제어하기 때문에 같은 장면을 몇 번이든 같은 결과로 다시 뽑을 수 있습니다. 숏폼 영상을 코드로 만드는 최근 흐름이 three.js와 만나는 지점이 바로 여기입니다.

AI 생성 3D 에셋의 검수와 배포. 이미지-3D 도구로 만든 모델은 폴리곤 수나 텍스처 크기가 제각각입니다. 에디터나 예제 장면에 올려 조명 아래에서 확인하고, 크기와 원점을 정리한 뒤 웹에서 가볍게 돌아가는지 본 다음 페이지에 얹는 순서로 진행하면 시행착오가 줄어듭니다.

LLM에게 장면 코드를 쓰게 하는 작업. 프롬프트로 떠 있는 섬이나 도시 같은 장면을 요청하고 결과를 고쳐 가는 방식입니다. 속도는 빠르지만 검수 기준을 따로 세워야 합니다. 다음 구획에서 연구 결과를 정리합니다.

AI가 쓴 장면 코드는 읽는 것과 실행해서 보는 것을 함께 해야 합니다

LLM이 생성한 three.js 세계를 평가하는 WorldBench 연구는 실행 중인 세계의 시계를 조작하고 궤도 회전과 탐색 에이전트로 각 구역을 살펴보면서 코드도 함께 읽는 판정기를 제안했습니다. 저자들은 다섯 개 프런티어 모델이 만든 세계에서 화면 기반 판정과 코드 기반 판정이 필수 항목의 32%에서 엇갈렸고, 불일치 대부분은 어떤 프레임에도 나타나지 않는 코드였다고 보고합니다. 기능을 일부러 제거하는 실험에서는 코드만 보는 판정이 제거된 기능 5개 중 4개에 만점을 줬습니다. 제거된 기능의 코드가 파일에 그대로 남아 있었기 때문입니다.

별도 벤치마크인 WorldCoder-Bench는 시뮬레이션, 렌더링, 애플리케이션 과제 2,026개와 샌드박스 브라우저에서 상태 전이를 확인하는 검증 방식을 제시합니다. 저자들에 따르면 아홉 개 모델 중 최고 시스템의 검증 커버리지는 Core 27.8%, Robust 19.9%였고, 실패는 장면 요소 누락보다 상태 스키마 불일치와 끊어진 상호작용 연쇄에서 주로 나왔습니다.

이 수치들은 각각의 벤치마크 설정에서 나온 저자 보고치이며 측정 대상과 지표가 달라 서로 비교하거나 three.js 자체의 성능으로 읽을 수 없습니다. 그래도 실무에 줄 수 있는 시사점은 분명합니다. 요구한 기능이 코드에 있는지 확인하고, 실제로 실행해 여러 시점과 시간대에서 화면에 나타나는지 보고, 입력 이후 상태가 바뀌어 다음 동작까지 이어지는지 확인하는 체크리스트를 두는 것입니다.

대안은 목적에 따라 나뉩니다

Visionary 저자들은 동일한 3DGS 자산에서 기존 웹 뷰어보다 렌더링 효율이 높다고 보고하지만, 비교 대상과 기기, 수치는 공개된 설명에서 확인되지 않습니다. 기존 three.js 앱에 가우시안 스플랫 장면을 얹으려는 팀은 후보로 볼 수 있으나, 지원하는 three.js 버전과 브라우저·GPU 조건을 먼저 확인해야 합니다. 이는 three.js 자체의 신규 기능이 아니라 별도 프로젝트의 연동 사례입니다.

한계와 주의점은 성능, 유지보수, 권리 문제입니다

코드가 필요합니다. 에디터가 있지만 실사용 수준의 결과물은 자바스크립트나 TypeScript로 다듬어야 합니다. 비개발자가 단독으로 끝내는 도구가 아닙니다.

성능은 대상 기기가 좌우합니다. 폴리곤 수, 텍스처 크기, 조명과 그림자 수, 후처리 단계가 늘수록 모바일과 저사양 노트북에서 먼저 한계가 옵니다. 데스크톱에서 매끄럽다는 사실이 배포 기준을 대신하지 못하므로 목표 기기를 정해 두고 측정하는 습관이 필요합니다.

버전 관리가 필요합니다. three.js는 r187처럼 리비전 번호로 자주 갱신됩니다. 업그레이드 때 API가 바뀔 수 있으니 공식 문서의 변경 안내를 확인하고 버전을 고정해 쓰는 편이 안전합니다. AI가 생성한 코드가 오래된 API를 쓰는 경우도 흔합니다.

라이선스와 비용. three.js는 MIT 라이선스로 배포되어 상업 프로젝트에도 쓸 수 있고 라이브러리 사용료는 없습니다. 다만 함께 쓰는 3D 모델, 텍스처, 폰트, 플러그인은 각자 라이선스가 따로 있습니다. AI로 만든 에셋은 해당 도구의 약관과 상업 이용 조건을 확인해야 합니다.

접근성과 윤리. 캔버스 안의 내용은 보조기술에 전달되지 않으므로, 핵심 정보는 텍스트로 제공하고 키보드 조작 경로를 별도로 두는 설계가 필요합니다. 실존 인물을 스캔하거나 닮게 만든 아바타를 쓸 때는 당사자 동의 범위를 분명히 해야 합니다.

검수 비용. 위에서 본 연구 결과처럼 생성된 장면 코드는 겉보기와 실제 동작이 다를 수 있습니다. 생성 속도가 빨라진 만큼 검수 시간을 일정에 넣어 두어야 합니다.

시작하는 방법은 예제 복사에서 출발하는 것이 빠릅니다

1. 공식 예제에서 만들고 싶은 결과에 가까운 장면을 골라 코드를 복사해 실행합니다.
2. 패키지 매니저로 three를 설치하고 번들러가 있는 프로젝트에 옮기면 버전을 고정한 채 작업할 수 있습니다.
3. 모르는 클래스는 공식 문서에서 속성을 확인하며 값을 바꿔 봅니다. 카메라 위치, 조명 세기, 머티리얼 색처럼 눈에 보이는 값부터 건드리면 구조가 빨리 잡힙니다.
4. 외부 모델은 공식 에디터에 올려 크기와 조명 반응을 확인한 뒤 코드로 불러옵니다.
5. AI에게 장면 코드를 맡길 때는 사용할 three.js 버전을 프롬프트에 명시하고, 결과를 실행해 시점을 바꿔 보며 요구 기능이 실제로 보이는지, 입력 후 상태가 이어지는지 점검합니다.

입문 단계에서는 지오메트리, 머티리얼, 텍스처, 조명, 그림자 순서로 한 가지씩 바꿔 보는 학습 경로가 시행착오를 줄입니다. 공식 사이트는 별도의 학습 자료와 공식 커뮤니티 채널도 안내하고 있습니다.

Muckle의 판단

코드를 읽고 고칠 수 있는 크리에이터와 개발자에게 three.js는 지금도 가장 무난한 출발점입니다. 급상승 신호는 규모가 작으므로 유행을 좇는 근거로 삼기보다, AI가 만든 3D 장면을 웹에 올리는 작업이 늘고 있다는 방향 확인용으로 쓰는 편이 정확합니다. 도입한다면 버전 고정, 목표 기기 성능 측정, 생성 코드의 실행 기반 검수 세 가지를 처음부터 작업 규칙에 넣어 두시기 바랍니다.