Hunyuan3D-WorldClaw

「글 한 줄만 쓰면 3D 게임 세계가 통째로 만들어진다」고 주장하는 연구입니다. 그런데 정작 받아서 돌려볼 수 있는 프로그램이 없습니다.

만든 곳은 텐센트라는 큰 회사의 연구팀입니다. 주장은 이렇습니다 — 「눈 덮인 산맥에 작은 마을」처럼 문장 하나를 넣으면, AI가 알아서 땅을 깔고 그 위에 집과 나무를 놓아 게임에 바로 쓸 수 있는 3차원 지도를 만들어 준다는 것입니다.

이 주장이 왜 대단한 건지부터

기존에도 「문장으로 그림을 만든다」는 건 많았습니다. 이건 그보다 한 칸 더 갑니다.

	보통 나오는 것	이 연구가 주장하는 것
결과물	사진 같은 그림 한 장	게임 안에 들어가는 실제 3차원 물체들
고칠 수 있나	못 고침 (그림이라서)	나무 한 그루만 따로 집어서 옮길 수 있음

「고칠 수 있다」가 핵심입니다. 게임을 만드는 사람에게 못 고치는 결과물은 쓸모가 거의 없기 때문입니다. 예쁜 그림 한 장보다, 못생겨도 집어서 옮길 수 있는 나무가 낫습니다.

그런데 창고를 열어 보니 사진첩이었습니다

연구 발표에는 보통 누구나 받아서 돌려볼 수 있는 프로그램 창고 주소가 같이 붙습니다. 그 주소를 열어 봤습니다.

들어 있던 것은 이렇습니다.

• 설명문 한 장 (1,333글자 — 이 문단보다 조금 긴 정도)
• 사진 폴더
• 프로그램 파일 0개

창고 용량이 180MB나 되는데, 그게 전부 사진 무게였습니다. 즉 「프로그램을 공개했다」가 아니라 「프로그램 사진을 공개했다」에 가깝습니다.

별 481개는 「물건이 있다」는 뜻이 아니었습니다

그 창고에는 「좋아요」 표시가 481개 붙어 있었습니다. 보통 이 숫자가 높으면 「검증된 물건이구나」 싶은데, 여기서 제가 값을 치르고 배운 게 이겁니다.

481개는 만들어진 지 5일 만에 붙은 숫자였습니다. 5일 안에 481명이 프로그램을 받아서 돌려 보고 좋다고 했을 리가 없습니다 — 애초에 받을 프로그램이 없으니까요.

그러면 그 481명은 무엇을 보고 눌렀을까요. 창고 설정에 흔적이 남아 있었습니다. 보통 검색으로 찾아오는 창고는 검색에 걸리라고 설명과 태그를 채워 두는데, 이 창고는 그게 전부 비어 있고 홈페이지 주소만 걸려 있었습니다. 검색으로 온 사람이 아니라 논문과 SNS를 보고 곧장 온 사람들이라는 뜻입니다.

→ 배운 것: 인기 숫자는 「사람이 많이 봤다」는 뜻이지 「물건이 실제로 있다」는 뜻이 아닙니다.

설계 자체는 좋습니다 — 그리고 그게 제가 가져온 전부입니다

물건이 없다고 글이 다 쓸모없는 건 아니었습니다. 논문에 적힌 만드는 순서가 잘 짜여 있었고, 거기서 두 가지를 가져왔습니다.

첫째, 큰 것부터 정하고 작은 것으로 내려간다. 나무 한 그루를 어디 놓을지 정하기 전에 「여기는 숲, 저기는 마을」처럼 넓은 구역과 땅 모양을 먼저 확정합니다. 그러면 구역 경계에서 어색하게 튀는 일이 안 생기고, 나중 단계가 앞 단계를 망가뜨리지 못합니다.

둘째, 중간 결과를 사람이 열어 볼 수 있는 형태로 남긴다. AI가 머릿속에서 다 처리하고 결과만 뱉으면 틀렸을 때 어디서 틀렸는지 알 수가 없습니다. 중간에 「이렇게 이해했습니다」를 글로 남기면 틀린 자리를 짚어서 고칠 수 있습니다.

이 둘은 3D와 아무 상관이 없어서 제 작업에도 그대로 씁니다.

「대규모」라고 써 놓고 숫자가 하나도 없습니다

논문 제목에 「대규모로」라는 말이 들어 있습니다. 그런데 논문 전체에 숫자 표가 하나도 없었습니다.

이게 왜 문제냐면, 「대규모」는 비교하는 말이기 때문입니다. 무엇보다 크다는 건지, 얼마나 빠르다는 건지가 있어야 말이 됩니다. 그 자리가 비어 있으면 읽는 사람은 확인할 방법이 없습니다.

더 정확히 말하면 이건 제 비판이 아니라 인용입니다. 기각의 근거를 논문 저자들이 자기 한계 절에 직접 적어 두었습니다.

그래서 제 판정

무엇	판정
이 도구를 쓸 것인가	안 씀 — 받을 물건이 없습니다
만드는 순서 두 가지	가져옴 — 3D와 상관없이 쓸 수 있습니다
논문의 숫자를 인용할 것인가	안 함 — 인용할 숫자 자체가 없습니다
다시 볼 조건	프로그램이 실제로 올라오고, 특정 회사 서비스 없이도 돌아갈 때

여기부터는 자세한 기록입니다

레포에 코드가 없고 논문에 수치가 없습니다. 텍스트 프롬프트 한 줄을 구역·지형·에셋·재질의 구조화 스펙으로 번역한 뒤, 에이전트가 3D 도구를 직접 조작해 지형을 깔고 그 위에 오브젝트를 앉히는 시스템입니다. 결과물이 파노라마나 점구름이 아니라 인스턴스 단위로 편집 가능한 메시라는 게 주장의 축입니다. 그런데 레포에서 실제로 받을 수 있는 건 README 1,333바이트와 이미지뿐이고, 제목에 “at Scale” 을 걸어 놓고 논문 전체에 수치 표가 하나도 없습니다.

무엇을 하는 물건인가 — 레포부터 보면

루트에 파일이 셋입니다. .gitignore(10바이트), README.md(1,333바이트), 이미지 폴더. 파이썬 파일 0개, 요구사항 파일 0개, 라이선스 파일 0개. 커밋 2개. 레포 용량 180MB가 전부 티저와 파이프라인 이미지입니다.

README에 설치·사용·로드맵·라이선스 절이 전부 없습니다. 있는 건 소식·방법론 이미지 한 장·인용 서식뿐입니다. “곧 공개” 문구조차 없습니다 — 공개 약속 자체가 없는 상태입니다.

이슈가 한 건 있습니다 — “코드를 커밋 안 했다. 재현할 수 없다.” 메인테이너 응답 0, 라벨 0, 담당자 0.

⚠ 라이선스 파일이 없다는 건 「자유롭게 쓰라」가 아니라 「전권을 저자가 보유」한다는 뜻입니다. 이미지 에셋까지 포함해서입니다.

대표 기법 — 설계는 잘돼 있다

세 단계로 좁혀 들어갑니다. 인스턴스 디테일에 들어가기 전에 의미와 지형이라는 공유 제약을 먼저 확정합니다. 그래서 구역 간 경계가 튀지 않고, 뒤 단계가 앞 단계를 못 깹니다.

중간 표현이 전부 사람이 열어볼 수 있는 형태입니다. 색으로 인코딩한 배치도, 에셋 원형 이미지, 구조화 스펙. 중간에서 검사하고 고칠 수 있다는 것이 블랙박스 한 방 생성과 갈리는 지점입니다.

높이장을 이름 붙은 변수의 합으로 만듭니다 — 구역 마스크 × (기준 고도 + 노이즈 + 지형 연산자). 연산자는 봉우리·사구·계단·침식입니다. 파라미터가 이름 있는 변수라서 에이전트가 되돌려 고칠 수 있습니다.

재질은 두 경로를 병행합니다 — 생성 텍스처와 절차적 노드 그래프. 지형처럼 스케일이 큰 면에서는 생성 텍스처만으로 반복이 드러나기 때문입니다.

그리고 각 단계마다 렌더-점검-수정 루프가 붙습니다. 부유·관통·불안정 지지를 검출해서 지지 영역만 국소 변형합니다.

깨본 결과

제목에 규모를 걸어 놓고 정량 평가가 0건입니다. 수치 표도, 사용자 스터디도, 생성 시간도, 에셋 개수도, 씬 면적도 없습니다. “대규모” 라고 주장하려면 무엇이 얼마나 큰지를 대야 하는데 그 자리가 비어 있습니다.

그리고 저자들이 직접 적은 한계가 결정적입니다 — “오픈소스 모델로 대체하면 절차적 지형·재질 생성이 실패한다.” 즉 코드가 공개돼도 폐쇄 API 세 종에 묶여 있습니다. 기각 근거가 제 성능 비판이 아니라 논문 자신의 한계 절입니다.

⚠ 공정하게 덧붙이면, 논문과 레포는 다른 물건입니다. 논문은 아이디어를 발표하는 것이고 코드 공개 의무가 있는 건 아닙니다. 다만 레포를 만들어 놓고 「재현 불가」 이슈에 답을 안 하는 것은 별개 문제입니다.

내 환경에 대봤다

도입할 게 없습니다 — 받을 코드가 없습니다.

설계에서 둘을 가져옵니다.

하나, 중간 표현을 사람이 열어볼 수 있게 둔다. 제 생성 파이프라인도 중간 산출물을 파일로 남기는데, 그게 검사 가능한 형태냐는 따로 봐야 합니다. 색으로 인코딩한 배치도처럼 한눈에 틀린 게 보이는 형태로 만들면 사후 교정이 훨씬 싸집니다.

둘, 파라미터를 이름 있는 변수의 합으로 만든다. 높이장을 “기준 + 노이즈 + 연산자들” 의 가중합으로 두면 에이전트가 어느 항을 얼마나 바꿀지 말할 수 있습니다. 결과만 뱉는 함수는 되돌려 고칠 수가 없습니다.

판정

무엇	판정
도구 도입	⛔ 기각. 받을 코드가 없다
중간 표현을 검사 가능한 형태로	채택. 파일로 남기는 것과 열어볼 수 있는 것은 다르다
이름 있는 변수의 합으로 파라미터화	채택. 되돌려 고칠 수 있는 형태
논문 수치 인용	⛔ 금지. 인용할 수치 자체가 없다
재개 조건	코드가 실제로 커밋되고, 폐쇄 API 의존이 풀렸을 때

이 편에서 값을 치른 교훈은 이겁니다 — 별 481개가 코드의 존재를 보증하지 않습니다. 생성 5일 만의 숫자였고, 유입이 검색이 아니라 논문과 SNS였다는 정황이 레포 설정에 남아 있습니다(설명도 주제 태그도 비어 있고 홈페이지만 걸려 있습니다).

그리고 ⚠ 기각할 때 제 판단보다 저자의 한계 절이 더 강한 근거입니다. “제가 보기엔 안 될 것 같다” 보다 “저자들이 오픈소스로는 실패한다고 적었다” 가 훨씬 단단하고, 나중에 재개 조건을 쓸 때도 그 문장이 그대로 조건이 됩니다.