로컬 모델이 3D 슈퍼카를 코드로 만들 수 있을까? Flash Next는 100분 만에 차 모양까지 갔고, 다음 수정에서 반사를 잃었습니다
약 12GiB로 제한한 A100에서 Qwen3.8-Flash-Next에 Three.js 슈퍼카를 시켰습니다. OpenMausBot에서는 43분 동안 파일이 나오지 않았고, 직접 호출에서는 약 100분 만에 차 모양이 나왔지만 반사가 불완전했으며 다음 라운드에서 반사가 사라졌습니다.

로컬 모델이 3D 슈퍼카를 코드로 만들 수 있을까? Flash Next는 100분 만에 차 모양까지 갔고, 다음 수정에서 반사를 잃었습니다
SNS에서 Fable 5.5가 Three.js로 3D 슈퍼카를 만드는 영상을 소개한 글을 봤습니다. 차체와 도장, 조명, 바닥 반사까지 코드로 만들었다는 내용입니다. 그래서 저희 GPU에서 돌아가는 모델로 비슷한 일을 시키면 어디까지 되는지 시험했습니다.
그 영상과 프롬프트, 시도 횟수는 찾지 못했습니다. 따라서 Fable 5.5와는 비교하지 않고, Qwen3.8-Flash-Next의 결과만 전합니다.
아래가 가장 잘 나온 차입니다. 사람이 코드를 고치지 않았고, 파일은 3D 모델이나 텍스처를 불러오지 않습니다. A100에서 라운드 세 번(스크린샷 자동 피드백 두 번)에 약 100분이 걸렸습니다. 실패한 첫 번째 방법은 뺀 시간이고, 다른 카드에 그대로 적용되지는 않습니다.

저희의 소프트웨어 WebGL 렌더에서는 차라는 것을 알아볼 수 있지만, 완성된 슈퍼카라고 부르기는 어렵습니다. 차체는 창문이 거의 드러나지 않는 낮은 쐐기 하나이고, 바퀴는 차체 밖으로 튀어나왔으며, 빨간 브레이크 캘리퍼가 타이어 위에 올라가 있습니다. 반사도 불완전합니다. 다음 라운드에서는 차체가 조금 나아진 대신 반사가 아예 사라졌습니다.
그 전에 시도한 첫 번째 방법은 아무것도 남기지 못했습니다. OpenMausBot에서 43분을 썼는데 파일은 0개였고, 작업은 완료로 표시됐습니다. OpenMausBot이 무엇인지는 소개 글에 있습니다.
무엇을 시켰고 어떻게 확인했나
프롬프트는 아래처럼 고정했습니다.
Build a 3D supercar showroom in one HTML file using Three.js loaded from a CDN. Do not load any external 3D model or texture. Build the car entirely in code. It needs a sculpted body, four wheels with rims and brake discs, a glossy painted finish, studio lighting, and a dark reflective floor that shows the car's reflection. I should be able to drag to orbit around the car.
저희 브라우저 실행에서 아래 네 가지를 모두 만족한 파일만 통과로 셌습니다.
- 파일을 열었을 때 콘솔 오류가 없습니다.
- 드래그하면 시점이 바뀝니다.
- 코드와 페이지 요청에 모델이나 텍스처 파일이 없습니다.
- 렌더 화면에 차체, 림과 디스크가 있는 바퀴 4개, 바닥 반사가 보입니다.
예쁜지는 채점하지 않았습니다. 그림을 보고 직접 판단해 주세요.
엔진은 Strata이고, 설정은 OpenMausBot 글과 같습니다. Qwen3.8-Flash-Next IQ2_XS를 CONTEXT=128k, PARALLEL=2로 띄웠고, A100 80GB를 약 12GiB로 제한했습니다. 방법마다 한 번씩 실행한 결과이고, 실제 12GB 카드 시험이 아닙니다. 직접 호출 때 Strata 프로세스의 GPU 메모리는 8,524 + 1,530 MiB(합계 10,054 MiB)였고, 컨테이너의 시스템 메모리는 docker stats 기준 최대 49.83GiB였습니다.
첫 번째 방법: 28분 생각하고 파일은 없었습니다
처음에는 OpenMausBot의 봇에 Local VM을 붙여 맡겼습니다. 프롬프트 끝에는 브라우저에서 시험하고, 스크린샷을 보고, 문제를 고치라는 문장을 덧붙였습니다.
첫 요청의 프롬프트는 50,150토큰이었습니다. 모델은 도구를 한 번도 호출하기 전, 이 첫 단계에 1,703.7초(약 28분)를 썼고 대부분 추론이었습니다. 출력은 60,766토큰입니다.
이 첫 작업에서 실제로 호출한 도구는 조회용인 computer_get_guide와 computer_list_apps뿐이었습니다. 그 뒤 VM에서 명령을 실행해야 할 자리에서는 호출을 하지 않고 평문으로 적었습니다. 이름도 틀렸습니다. 앱의 도구는 agents_vm_exec인데 vm_exec라고 썼습니다. 그래서 그 명령은 실행되지 않았습니다. 그런데도 작업은 "completed"로 끝났고, 빨간 오류도 MausBot의 재시도도 없었습니다.
호출이 평문으로 나왔고 파일도 없다고 후속 메시지를 한 번 보냈습니다. 모델은 약 507초를 더 쓰면서 computer_list_apps를 한 번 더 호출했고, 또 평문으로 vm_exec를 적었습니다. 합계는 메시지 2건, 작업 시간 약 43분, 파일 0개입니다. VM의 홈 폴더는 두 메시지 시간 전체를, /tmp는 후속 메시지 구간을 찾아봤지만 HTML은 없었고, 로그에도 파일을 쓸 수 있는 도구 호출은 없었습니다.
두 번째 방법: 도구를 빼고 스크린샷을 보내 줬습니다
다음에는 같은 서버 설정으로 Strata를 직접 호출했습니다. 도구가 없어 모델이 브라우저를 열 수 없으므로 스크립트가 대신 열었습니다. 프롬프트 마지막 문장은 "Reply with the complete HTML file in one code block. I will open it and send you back screenshots and any console errors."로 했습니다.
스크립트는 답으로 온 파일을 headless Chromium으로 열어 드래그 전후 스크린샷 두 장을 찍었습니다. 그리고 콘솔 출력과 함께 매번 같은 문장을 보냈습니다.
Here are screenshots of your file from two angles and its console output. Fix what looks wrong and reply with the complete updated file.
최대 5라운드, 20시 30분까지로 정했습니다. 5라운드는 약 20분 만에 이 시간 제한에 걸려 파일을 내지 못했습니다.
| 라운드 | 시간 | 출력 토큰(추론 포함) | 파일 크기 | 콘솔 | 확인 결과 |
|---|---|---|---|---|---|
| 1 | 35분 | 81,700 | 21,987 B | 스크립트 오류 | 1, 2, 4 실패 |
| 2 | 26분 | 58,267 | 23,532 B | 깨끗함 | 1, 2, 3 통과, 4 부분 통과 |
| 3 | 37분 | 83,730 | 27,565 B | 깨끗함 | 1, 2, 3 통과, 4 부분 통과 |
| 4 | 41분 | 84,072 | 29,372 B | 셰이더 오류 | 1, 4 실패 |
시간은 대부분 답이 나오기 전에 쓰였습니다. 네 라운드 모두 답의 첫 글자가 라운드 시간의 90-93%가 지난 뒤에 나왔습니다. 출력 토큰을 라운드 시간(초)으로 나누면 초당 34-39토큰입니다. A100에서 낸 속도이고, 3라운드와 4라운드의 일부 구간에는 다른 작업이 GPU를 함께 썼으니 대략적인 값으로 봐 주세요.

1라운드: 검은 화면

파일은 Cannot read properties of undefined (reading 'set') 오류로 멈췄습니다. 코드가 mirror.material.layers.set(0)을 호출하는데, 이 파일이 불러온 three@0.160.1의 material에는 layers 속성이 없고 object에만 있습니다. 모델은 2라운드 추론에서 여러 후보를 따져 본 뒤 material.layers가 undefined일 가능성이 높다고 봤습니다. 다음 파일은 object에만 layers를 설정했고 실행됐습니다.
2라운드: 바퀴 달린 납작한 판

콘솔은 깨끗했지만 차라고 부르기 어려운 모양이었습니다. 부품이 있어서 확인 결과는 부분 통과입니다. 그래서 표만 싣지 않고 그림을 함께 보여 드립니다.
3라운드: 글 첫머리의 그 차

자동 메시지에는 차 모양에 관한 말이 없었습니다. 그런데 모델의 추론에는 "User screenshots show car not looking like supercar, extruded cabin appears as open box?"라는 문장이 있었고, 차체를 지금의 쐐기 모양으로 다시 만들었습니다. 모델이 스크린샷을 활용했다는 가장 뚜렷한 흔적입니다. 다만 한 번의 실행이라 이런 일이 얼마나 자주 되는지는 알 수 없습니다.
4라운드: 반사를 없앤 수정
4라운드에서 모델은 바닥에 집중했습니다. 반사가 "weirdly offset, only lower parts"라고 적은 뒤, Three.js Reflector의 fragment shader를 직접 쓴 코드로 바꿨습니다. 코드는 이렇게 시작합니다.
#include <common>
#include <colorspace_fragment>
uniform sampler2D tMap;둘째 줄이 문제입니다. three@0.160.1에서 이 include는 gl_FragColor = linearToOutputTexel( gl_FragColor );로 펼쳐지는데, 이 문장은 main() 안에 있어야 합니다. 파일 맨 위에 두면 문법 오류가 납니다. 그래서 셰이더가 컴파일되지 않았고, 바닥에 반사가 보이지 않게 됐습니다.

이 콘솔 오류는 5라운드 요청으로 모델에 전달됐지만, 5라운드는 답이 나오기 전에 시간 제한으로 끝났습니다. 그래서 모델이 이 셰이더를 고쳤을지는 알 수 없습니다.
이번 실행으로 알 수 있는 것과 없는 것
네 가지를 모두 통과한 파일은 없었습니다. 가장 가까운 직접 호출의 3라운드는 사람이 코드를 고치지 않은 채 세 가지를 통과했고 네 번째는 부분 통과였습니다. 실행 한 번, 프롬프트 하나, 모델 하나의 결과입니다.
두 방법을 공평하게 겨룬 것이 아닙니다. 첫 번째 방법은 50,150토큰 프롬프트로 시작했고 도구가 있었습니다. 두 번째 방법은 163토큰으로 시작했고 브라우저 일을 저희 스크립트가 맡았습니다. 첫 번째 방법에는 메시지 2건과 43분을, 두 번째 방법에는 최대 5라운드와 165분을 줬고 파일은 4개 나왔습니다. 한 번씩 시도한 결과로 직접 호출이 OpenMausBot보다 낫다고 말할 수는 없습니다.
"completed"가 파일이 있다는 뜻은 아니었습니다. 앱은 작업을 완료로 표시했습니다. 저희가 VM의 작업 폴더를 직접 찾아봤을 때 이 작업에서 나온 HTML 파일은 없었습니다.
마지막 라운드가 가장 좋은 라운드는 아니었습니다. 마지막 파일만 남겼다면 반사가 없는 파일이 남았을 것입니다. 이런 반복을 돌린다면 라운드마다 파일을 저장해 두세요.
한계도 있습니다. 렌더는 모두 CPU의 소프트웨어 WebGL로 했습니다. 그래서 프레임 속도는 재지 않았고, 실제 GPU에서 어떻게 보이는지도 확인하지 않았습니다. 직접 열면 다르게 보일 수 있습니다. 메모리를 약 6초 간격으로 기록한 1,589회 중 55회는 18시 50분부터 20시 24분 사이에 다른 프로세스가 같은 GPU를 쓰고 있었고, 이때 GPU 전체 사용량은 최대 18,613MiB였습니다. 두 번째 시도는 하지 않았으니 모델이 얼마나 자주 여기까지 오는지는 말할 수 없습니다. 호스팅 모델과 시간을 비교하지도 않았습니다.
같은 설정에서 OpenMausBot의 다른 작업이 어떻게 됐는지는 OpenMausBot 글에 있습니다.