ThreeUI 220개 three.js 컴포넌트, AI 에이전트로 수정해 쓰는 방법
three.js로 3D 화면을 만들 때 가장 오래 걸리는 구간은 아이디어가 아니라 첫 화면이 제대로 도는 상태까지 가는 과정입니다. 카메라 위치, 조명, 재질, 애니메이션 루프가 서로 얽혀 있어서 하나를 건드리면 다른 하나가 틀어지기 때문입니다. ThreeUI는 이 출발점을 건너뛰게 해 주는 리소스입니다. 이 글에서는 ThreeUI가 무엇을 제공하는지, 왜 처음부터 생성하는 것보다 기존 컴포넌트를 고치는 편이 안정적인지, 그리고 실제 작업을 어떤 순서로 나눠야 하는지 정리합니다.
ThreeUI가 제공하는 것
ThreeUI는 three.js로 만든 3D UI 컴포넌트 220개를 한꺼번에 제공하는 오픈 리소스입니다. Design+Code의 멘토가 만든 프로젝트로, 컴포넌트의 소스 코드뿐 아니라 에이전트에게 전달할 수 있는 프롬프트 형태도 함께 활용할 수 있습니다. 다운로드는 threeui.com에서 진행합니다.
여기서 중요한 점은 단순히 완성된 3D 예제를 모아 둔 라이브러리라는 데 있지 않습니다. 각 컴포넌트를 사람이 직접 조립하는 대신, 프롬프트나 코드를 AI 에이전트에게 넘기고 원하는 방향으로 수정하는 작업 흐름을 전제로 합니다. 예를 들어 “현재 테마를 어두운 색상으로 바꾸고, 조명을 더 부드럽게 조정하며, 마우스 이동에 반응하는 모션을 줄여 달라”는 식으로 지시할 수 있습니다.
즉, ThreeUI는 3D 화면을 처음부터 생성하는 도구라기보다 이미 만들어진 결과물을 재료로 삼아 빠르게 변형하는 출발점에 가깝습니다.
처음부터 생성하는 것보다 컴포넌트 수정이 유리한 이유
three.js 작업을 AI에게 처음부터 맡기면 화면에 무언가 나타나는 데까지는 빠를 수 있습니다. 하지만 카메라 제어, 조명 계산, 재질 설정, 애니메이션 루프, 반응형 처리처럼 서로 연결된 부분이 많아질수록 코드 품질이 쉽게 흔들립니다. 겉보기에는 작동하더라도 프레임 속도가 떨어지거나, 특정 화면 크기에서 레이아웃이 깨지거나, 수정 한 번에 기존 동작이 사라지는 일이 생길 수 있습니다.
검증된 컴포넌트를 에이전트가 고치는 방식은 처음부터 코드를 생성하는 것보다 결과가 안정적입니다. 이 방식의 핵심은 에이전트가 빈 화면에서 모든 결정을 내리지 않도록 하는 것입니다. 기본 구조와 동작이 이미 갖춰져 있으면 에이전트는 변경 범위가 비교적 명확한 작업에 집중할 수 있습니다.
| 구분 | 빈 화면에서 생성 | 기존 컴포넌트 수정 |
|---|---|---|
| 에이전트가 정하는 것 | 카메라·조명·재질·루프 전부 | 테마·조명·모션·레이아웃 |
| 첫 화면까지 | 빠름 | 이미 도는 상태에서 시작 |
| 수정할 때 위험 | 기존 동작이 함께 사라짐 | 변경 범위가 좁아 되돌리기 쉬움 |
| 주된 확인 지점 | 구조 자체가 맞는지 | 합쳤을 때의 GPU 부하 |
물론 ‘검증된 컴포넌트’라는 표현이 모든 프로젝트에서 동일한 품질을 보장한다는 뜻은 아닙니다. 실제 배포 전에는 사용 중인 three.js 버전, 렌더러 설정, 모바일 성능, 라이선스 조건을 별도로 확인해야 합니다. 특히 여러 컴포넌트를 한 화면에 합치면 개별 예제에서는 보이지 않던 GPU 부하가 나타날 수 있습니다.
프롬프트와 소스를 에이전트에 넘기는 작업 순서
ThreeUI를 활용하는 과정은 복잡한 3D 모델링보다 코드 재구성에 가깝습니다. 먼저 원하는 컴포넌트의 프롬프트 또는 소스를 가져와 현재 프로젝트의 기술 스택과 함께 에이전트에게 제공합니다. 이때 단순히 “예쁘게 바꿔 달라”고 요청하기보다 수정 범위를 나누는 편이 안전합니다.
예를 들어 다음과 같은 순서가 현실적입니다.
- 기본 컴포넌트를 그대로 실행해 카메라, 조명, 인터랙션이 정상인지 확인합니다.
- 색상과 재질 같은 시각 요소만 먼저 변경합니다.
- 조명과 애니메이션 속도를 조정합니다.
- 마지막으로 화면 배치와 반응형 동작을 손봅니다.
- 데스크톱과 모바일에서 프레임 저하, 입력 지연, 콘솔 오류를 확인합니다.
한 번에 테마와 구조, 모션을 모두 바꾸라고 하면 에이전트가 어느 부분을 우선해야 하는지 판단하기 어려워집니다. 변경 전후의 코드를 나누어 저장하고, 한 단계가 끝날 때마다 실행 결과를 확인하는 방식이 수정 실패를 줄입니다.
특히 에이전트가 기존 컴포넌트의 핵심 초기화 코드를 삭제하지 않도록 조건을 명시하는 것이 좋습니다. “기존 인터랙션은 유지하고 조명만 변경하라”, “파티클 수는 늘리지 말고 색상과 속도만 바꿔라”처럼 보존해야 할 요소를 함께 적어야 합니다.
스킬로 재사용하는 three.js 패턴
ThreeUI의 흥미로운 부분은 컴포넌트를 에이전트 스킬로 묶어 반복 사용할 수 있다는 점입니다. 이런 스킬은 특정 화면 하나를 복사하는 것과 다릅니다. 재사용 가능한 동작 단위를 에이전트가 이해하기 쉬운 형태로 저장하는 개념입니다.
threejs-pointer-orbit
포인터를 따라 카메라나 오브젝트가 회전하는 패턴입니다. 마우스 이동량을 회전 각도로 바꾸는 부분이라 반응 범위를 프로젝트마다 다시 잡아야 합니다.
wireframe-scan-reveal
와이어프레임이 스캔되듯 나타나는 효과입니다. 등장 연출에 쓰이므로 재생 시간과 카메라 거리가 함께 맞아야 의도한 인상이 나옵니다.
gpu-particle-spray
GPU 기반 파티클 분사입니다. 세 가지 중 성능 영향이 가장 크기 때문에 파티클 수를 늘릴 때는 저사양 기기부터 확인하는 편이 안전합니다.
여러 랜딩 페이지에서 비슷한 인터랙션을 사용한다면 매번 긴 프롬프트를 새로 작성하는 대신 해당 스킬을 불러오고, 색상·속도·반응 범위만 프로젝트에 맞게 조정할 수 있습니다. 다만 스킬을 재사용할 때도 화면마다 캔버스 크기, 카메라 거리, 오브젝트 수가 다르므로 그대로 붙여 넣는 것만으로 끝나지는 않습니다. 이름은 같아도 프로젝트의 렌더링 구조에 맞춰 매개변수와 이벤트 처리를 확인해야 합니다.
Sylva 사례가 보여주는 성능 문제
같은 흐름의 사례로 Sylva가 있습니다. Sylva는 3D 풍경을 보여주는 오픈소스 사이트로, 잔디 블레이드 13만 개를 1MB 미만으로 실행합니다. 에이전트가 약 2시간 동안 자체 검증하며 만들었습니다.
이 사례에서 눈여겨볼 부분은 잔디 개수 자체보다 데이터 표현 방식입니다. 13만 개의 잔디를 각각 무거운 3D 오브젝트로 관리했다면 브라우저에서 처리 부담이 커질 가능성이 높습니다. 많은 반복 요소를 다룰 때는 인스턴싱, GPU 파티클, 텍스처 활용처럼 동일한 데이터를 효율적으로 렌더링하는 구조가 중요합니다. 다만 공개된 설명만으로 Sylva의 구체적인 구현 방식이나 모든 기기에서의 성능까지 확인할 수는 없습니다.
따라서 “1MB 아래”라는 수치를 곧바로 “어떤 환경에서도 빠르다”로 해석하면 안 됩니다. 파일 크기와 실행 중 메모리 사용량, GPU 부하, 초기 로딩 시간은 서로 다른 지표입니다.
| 지표 | 무엇을 말하는가 | 언제 확인하나 |
|---|---|---|
| 파일 크기 | 네트워크로 내려받는 양 | 초기 접속, 느린 회선 |
| 초기 로딩 시간 | 화면이 처음 뜨기까지 | 첫 방문자 이탈 구간 |
| GPU 부하 | 매 프레임 그리는 비용 | 스크롤·인터랙션 중 |
| 메모리 사용량 | 실행 중 점유량 | 장시간 체류, 저사양 기기 |
실제 프로젝트에 적용할 때는 네트워크 전송량뿐 아니라 저사양 모바일 기기에서의 프레임 속도와 발열까지 따로 확인해야 합니다.
에이전트용 디자인 시스템으로 볼 때의 의미
ThreeUI와 Sylva 사례가 공통으로 보여주는 방향은 에이전트가 활용할 수 있는 디자인 시스템이 만들어지고 있다는 점입니다. 기존 디자인 시스템이 색상 토큰, 버튼, 입력창, 레이아웃 규칙을 정리했다면, 에이전트용 디자인 시스템은 여기에 프롬프트 가능한 템플릿과 재사용 스킬을 더합니다.
이 구조에서는 사람이 모든 코드를 직접 작성하는 능력만큼, 원하는 결과를 컴포넌트 단위로 설명하고 수정 범위를 통제하는 능력이 중요해집니다. 어떤 효과를 원하는지뿐 아니라 무엇을 유지해야 하는지, 성능 한도를 어디에 둘 것인지, 모바일에서 어떤 동작을 줄일 것인지까지 지시해야 하기 때문입니다.
배포 전 확인 항목
무료로 소스를 받는 것과 실제 서비스에 바로 사용할 수 있는 것은 다릅니다. 적용 전에 다음을 확인하세요.
- 컴포넌트별 라이선스와 상업적 이용 가능 여부
- 외부 에셋(모델·텍스처·폰트)의 사용 조건
- 프로젝트의 three.js 버전과 의존성 충돌
- 에이전트가 남긴 미사용 라이브러리와 중복 애니메이션 루프
- 저사양 모바일 기기에서의 프레임 속도와 발열
ThreeUI를 시험한다면 먼저 한 개의 컴포넌트를 기존 프로젝트에 넣어 보는 편이 낫습니다. 실행이 확인된 뒤 같은 패턴을 스킬로 정리하고, 마지막에 여러 효과를 조합하는 순서가 안전합니다. 3D 화면을 빠르게 만드는 데는 큰 도움이 될 수 있지만, 최종 품질은 프롬프트보다도 컴포넌트 선택, 성능 검증, 코드 정리에 달려 있습니다.
