img2threejs는 사진 한 장을 주면 그 물체를 Three.js 코드로 다시 짜주는 오픈소스 스킬이다. 결과물은 3D 파일이 아니라 부품 이름이 붙은 TypeScript 소스이고, 각 단계마다 사진과 렌더를 겹쳐 점수를 매기는 검사가 붙는다. 다만 문서에 적힌 순서를 그대로 따라가면 첫 단계에서 멈추며, 그 이유를 만든 사람이 이미 저장소 안에 적어뒀다. 이 글은 다섯 종류의 물건을 실제로 돌려본 기록을 근거로 “지금 이 도구를 써도 되는가”에 답한다.
목차
img2threejs가 뭔가요?
참조 이미지에 있는 물체를 코드로 다시 만드는 도구다. 사진에서 3D 모양을 떠내는 방식(포토그래메트리)이나 메시 파일을 뽑아내는 방식이 아니라, 상자·원통·도넛 같은 기본 도형을 조립하는 TypeScript 파일을 쓴다. 저장소 설명 원문이 그 경계를 못 박는다. “reconstruction-by-code, not photogrammetry, mesh extraction, or downloaded art packs.”
저장소는 img2threejs/img2threejs, 라이선스는 Apache-2.0, 주 언어는 Python이다. 2026년 7월 15일에 만들어졌고 한 달 만에 릴리스가 네 번 나왔다. 2026년 8월 18일 조회 기준 별 12,065개, 포크 954개다. 별과 포크는 시간마다 변하는 값이라 이 글의 숫자는 그날의 스냅샷이다.
도구가 파이썬인데 결과물이 TypeScript인 이유는 구조 때문이다. 파이썬 스크립트는 검사와 차단만 하고, 실제 조형은 에이전트가 한다. 저장소가 이 원칙을 한 줄로 압축해 놓았다. “Scripts enforce, the model judges.”
실제로 그렇다. 사물 재구성 경로에는 필수 단계가 21개 걸리는데, 그중 파이썬 스크립트가 실행하는 것은 13개이고 나머지 8개는 에이전트가 판단해야 하는 항목이다. 상태 관리 스크립트를 초기화하면 “다음 명령”으로 알려주는 것이 명령어가 아니라 문장이다.
STATE status=active step=image-analysis pass=none loop=0/3 total=0/6
next command: Read grimoire/intake/image_analysis.md and analyze refs/moon-jar.png즉 이건 프로그램이 아니라 절차다. “이미지를 넣으면 3D가 나오는 프로그램”으로 기대하고 들어오면 어긋난다.
왜 써야 하나요?
같은 물건을 에이전트에게 그냥 “Three.js로 만들어줘”라고 시켜도 코드는 나온다. 차이는 결과물이 아니라 결과물에 붙는 정보에 있다.
첫째, 숫자에 출처가 생긴다. 스킬 없이 선풍기 가드를 짜면 0.1 + i * 0.026 같은 식이 된다. 눈으로 정한 값이고 맞는지 확인할 방법이 없다. 실제 시연에서는 가드 중심선의 밝기 극대점을 검출하고 좌우를 대조해 링 14개의 반지름을 픽셀 단위로 얻었다. “15개쯤”이 아니라 “14개, 이 반지름”이 된다.
98 · 108 · 116 · 145 · 172 · 199 · 226 · 253 · 278 · 301 · 320 · 336 · 351 · 365 px둘째, 틀렸다는 사실을 알 수 있다. 스킬 없이 만들면 정면에서 그럴듯한 순간이 완성이다. 안 맞는다는 사실이 드러날 자리가 없다. 검사가 붙으면 못 넘은 항목과 그 수치가 남는다.
셋째, 내가 지표를 맞추고 있는지 알 수 있다. 이 검증을 하면서 실제로 겪은 일이다. 검사를 통과시키려고 손을 세 군데 댔다. 도구가 계산한 광택 값을 덮어쓰는 후처리 스크립트, 링 반지름 보정계수 RING_FIT = 1.0235, 그리고 잔차를 맞추려 다시 조정한 모델 위치다. 전부 걷어내고 다시 쟀다.
| 상태 | 사진과 겹치는 정도 |
|---|---|
| 보정 세 개를 넣은 상태 | 0.6423 |
| 전부 걷어낸 상태 | 0.5973 |
차이 0.045가 전부 사족이 만든 것이었다. 검증 도구의 값은 “잘 만들기”보다 “내가 속고 있는지 알기”에 쓸모가 있다.
넷째, 그림이 아니라 부품이 나온다. 이게 이 도구를 쓸 실질적인 이유다. 탁상 선풍기 시연의 최종 산출물은 부품 89개, 재질 5종, 그리고 스펙에 선언된 동작 8종이다. 헤드 틸트, 목 좌우 회전, 로터 허브, 날개 4장 개별 회전, 속도 노브가 각각 회전축과 함께 적혀 있다.
.ts 파일 하나가 나오고, 부품을 떼어내는 것부터 다시 작업해야 한다.부품이 따로 잡히면 그다음이 가능해진다. 이 선풍기 모델을 그대로 리모션(Remotion)에 넣어 3초짜리 영상을 뽑았다. 1920×1080, 30fps, 90프레임, 6.4MB. 영상 만들어주는 AI는 쓰지 않았다.
[0,0,1])을 읽어서 썼다.영상 도구에서 중요한 건 같은 프레임을 몇 번 렌더해도 같은 그림이 나와야 한다는 점이다. 37번 프레임을 두 번 렌더해 파일 해시를 비교했더니 일치했다. 우연이 아니다. 생성된 코드에 Math.random(), Date.now(), performance.now(), 자체 애니메이션 루프가 각각 0건이고, 반복 배치에 쓰는 난수는 고정된 시드로 만든다. 재생성했을 때 같은 결과가 나오게 하려는 설계인데, 그게 영상 도구의 요구와 맞아떨어진다.
어떻게 쓰나요?
설치 경로는 하나뿐이다. 원클릭 패키지도, 패키지 매니저 배포도, Docker도, 클라우드 노트북도 없다. 릴리스 첨부 파일이 0개라 내려받을 배포물 자체가 없다. README가 안내하는 것은 스킬 디렉터리에 클론하는 한 줄이다.
git clone https://github.com/img2threejs/img2threejs.git ~/.claude/skills/img2threejs윈도우 11에서 이 명령을 그대로 실행했고 그대로 됐다. ~/ 경로가 C:/Users/…/.claude/skills/img2threejs로 정상 해석되고, 관리자 권한이 필요 없고, 종료 코드 0이었다. 클론 직후 Claude Code가 세션을 다시 켜지 않고 스킬을 인식했다.
호출도 에이전트 안에서 한다.
/img2threejs Rebuild this object as a Three.js model, keep the proportions, angles, and colours.README는 이 뒤에 이렇게 덧붙인다. “That is enough: the skill classifies the subject, runs the detail inventory, and gates every pass on its own.”
스크립트를 직접 부르는 수동 경로도 문서에 있다. 파이썬 3.10 이상만 있으면 되고 따로 설치할 것이 없다는 주장은 사실이다. 의심할 만한 근거가 있었다. 저장소 코드가 PIL, numpy, mediapipe, torch, trimesh를 import하기 때문이다. 전수 확인 결과 그 import는 전부 선택 기능 폴더(integrations/) 안에만 있고, 파이프라인 본체는 표준 라이브러리만 쓴다. 이미지 크기를 읽는 스크립트는 PNG 헤더를 직접 파싱해 PIL 없이 값을 뽑는다.
python3 forge/stage1_intake/probe_image.py <image>
python3 forge/stage2_spec/new_pre_spec_assessment.py "Name" --image <image> --out assessment.json
python3 forge/stage2_spec/new_sculpt_spec.py "Name" --image <image> --assessment assessment.json --out spec.json
python3 forge/stage2_spec/validate_sculpt_spec.py spec.json --strict-quality
python3 forge/stage3_build/generate_threejs_factory.py spec.json --out src/createObjectModel.ts네 번째 줄의 --strict-quality가 이 도구의 핵심 장치다. 스캐폴딩이 만든 빈 골격을 그대로 넣으면 에러 15건으로 막히고 종료 코드 1이 뜬다.
FAIL
error: strict quality failure: preSpecAssessment.objectClass.primaryType is unassessed
error: strict quality failure: macroComponents below qualityContract minimum (1 < 2)
error: strict quality failure: detailInventory has 0 details but targetMinDetails is 6
error: strict quality failure: material 'base' needs usable referencePbr extracted from source pixels
warning: only one component found; this is likely still blockout quality막는 항목이 전부 “이미지를 실제로 봐야만 채울 수 있는 것”이다. 한 번에 끝내는 걸 금지한다는 말은 홍보 문구가 아니라 실행되는 코드다. 세 번 고쳐 쓴 끝에 통과했고, 그 스펙으로 1,327줄짜리 TypeScript 파일이 나왔다.
중요한 건 이 도구가 요구하는 브라우저와 Node.js가 “설치할 것 없음”에 포함되지 않는다는 점이다. 파이프라인 중간에 “브라우저에서 현재 단계를 렌더하고 검수 시점의 스크린샷을 찍어라”는 단계가 있다. 생성된 코드를 띄울 Three.js 프로젝트가 따로 있어야 한다는 뜻이다.
기존 방식과 뭐가 다른가요?
결과물의 형태부터 다르다. 메시 파일은 수 메가바이트짜리 이진 데이터라 열어봐도 무엇이 바뀌었는지 알 수 없다. 코드는 줄 단위로 비교되고 버전 관리에 들어간다. 저장소가 내세우는 문장이 그것이다. “The result is diffable TypeScript plus a JSON spec — small, reviewable, and version-controllable, instead of multi-megabyte mesh files.”
영상 작업에서는 차이가 더 직접적이다. 메시 파일은 로더가 비동기라 프레임마다 로딩 완료를 기다려야 한다. 코드로 만든 모델은 함수 한 줄로 즉시 생긴다. 그리고 회전축 같은 값을 우리가 정할 필요가 없다. 설계도에 적혀 있는 걸 읽어 쓴다.
const axis = node.userData.actionProfile.pivot.axis; // 설계도가 선언한 축
const spin = interpolate(frame, [0, durationInFrames], [0, Math.PI * 4]);
node.quaternion.setFromAxisAngle(new THREE.Vector3(...axis), spin);다만 같은 이유로 파일이 크다. 선풍기 모델은 1.17MB인데 그중 86%가 부품 설명용 데이터다. 빌드할 때 털어내면 165KB가 된다.
색을 바꾸는 방법도 다르다. 처음에 “조명이 코드에 박혀 있어 룩을 못 바꾼다”고 적었다가 틀린 것으로 확인했다. 재질이 금속이라 조명 방향이 아니라 주변에 무엇이 비치는지가 색을 정한다. 주변 풍경을 담은 텍스처만 갈아끼우면 같은 모델이 은색도 되고 황동색도 된다. 모델을 다시 만들 필요가 없다.
주의할 점
여기부터가 이 글의 본론이다. 검색해서 들어온 사람이 알아야 할 것은 대부분 이쪽에 있다.
문서대로만 가면 첫 단계에서 멈춘다
이 편에서 유일하게 문서 순서를 처음부터 끝까지 지킨 실행분이 있다. 상태 초기화부터 새로, 매 단계 다음 명령을 물어가며, 우회 플래그 0개, 보정계수 0개로 갔다. 21단계 중 대부분을 완료했고 검증도 경고 0으로 통과했다. 그리고 첫 번째 조형 단계(blockout)에서 멈췄다.
silhouetteIoU 0.7454 임계 0.85 FAIL
scaleDelta 0.2382 임계 0.08 FAIL
aspectRatioDelta 0.0048 pass
bilateralSymmetryError 0.0191 pass
+ "blockout requires --map-stripped-render evidence"형태 자체는 문제가 없었다. 여러 각도에서 본 검사는 통과했고, 가로세로 비율은 0.7% 안에서 맞는다. 막힌 것은 화면 안에서 물체가 차지하는 크기다. 렌더가 프레임의 47%를 채우는데 참조 사진은 35%를 채운다.
막은 것이 두 가지인데 둘 다 문서 밖의 결정을 요구한다.
하나는 텍스처를 벗긴 렌더를 증거로 요구하는 검사다. 그 렌더를 만들라고 문서가 지목하는 명령이 이것이다.
node runtime/scripts/export_mesh_geometry.mjs --url <preview> --out meshes.json그런데 runtime/ 디렉터리가 이 체크아웃에 없다. 우연한 누락이 아닐 가능성이 크다. 저장소 자신의 .gitignore가 runtime/을 통째로 제외하고 있다. 열린 이슈 #90이 같은 것을 보고했고, 확인 시점에 달린 코멘트는 자동 분류 봇의 한 줄뿐이었다. 대체 경로도 잠겨 있다. 참고로 이 파일이 없다고 사물 재구성이 막히지는 않는다. 필수 21단계와 상태 관리 스크립트 어디에도 이 경로가 나오지 않는다. 막히는 것은 캐릭터 감사 스크립트와 GLB 중개 경로, 그리고 위의 증거 요구다.
다른 하나가 더 중요하다. 실패한 두 검사의 처방이 화면 안 크기를 맞추라는 것인데, 그 값은 실패 수치를 본 뒤에 손으로 맞추는 값이다. 즉 통과시키는 방법이 문서가 “하지 마라”고 적은 그 행위다.
만든 사람이 이미 알고 있다
저장소 안 grimoire/review/self_correction.md 86행에 이렇게 적혀 있다.
Divine Eye caveat — photo-vs-procedural reconstruction (must read)
참조가 사진이고 렌더가 코드로 만든 재구성일 때, 픽셀 정렬 신호와 실루엣 겹침 검사는 충실도가 아니라 화면 구도·배경·크기·조명 차이에 지배된다. 두 물체에서 확인됨. 충실하게 만든 BMX 자전거가 reject / 0.53, 선명한 M9 총검이 reject / 0.165(흰 배경 사진 대 어두운 렌더). 이 모드에서는 점수를 좇지 마라 — 최적화하면 사진에 픽셀을 맞추려다 모델이 더 나빠진다.
여기서 세 가지가 나온다.
- 만든 사람 스스로 이 검사가 품질을 재지 않는다고 적었다. 우리가 다섯 물건을 돌려가며 측정해 도달한 결론과 같다.
- 공개 갤러리의 대표작인 BMX 자전거가 자기 검사에서 0.53으로 거부됐다. 우리 선풍기가 0.663으로 못 넘은 것이 예외적인 일이 아니라는 뜻이다.
- 고칠 방법도 알고 있다. 문서가 제대로 된 해법으로 지목하는 것은 별도의 재구성 전용 판정 모드인데, 그건 아직 만들어지지 않았다(deferred).
덧붙일 것이 하나 있다. 우리는 이 파일을 늦게 읽었다. 검증 마지막 날에야 열었고, 그전까지 실측으로 재발견한 것 상당수가 이미 문서 안에 있던 내용이었다. 이건 도구의 문제가 아니라 우리 쪽 절차의 문제다. 다만 재발견 자체에 남는 값은 있다. 만든 사람은 두 물체로 말했고, 우리는 다섯 물체와 검사 점수의 상한 계산까지 붙였다.
점수와 닮음은 다른 것이다
레트로 카메라를 배경 지운 참조 이미지로 다시 만들었을 때 겹침 점수 0.9234가 나왔다. 이 편에서 낸 것 중 가장 높은 값이고 검사도 전부 통과했다. 그런데 그림이 나빠졌다.
고칠 수 있었는데 고치지 않았다. 도구가 “이 크롭은 쓸 만하다(신뢰도 0.8)”고 판정한 것을 “못 쓴다”로 뒤집으면 색은 해결된다. 그건 도구의 측정을 사람 눈짐작으로 덮어쓰는 일이라 하지 않았다. 손을 댔으면 그림은 좋아졌을 것이고, 그건 시연이 아니었을 것이다.
점수는 사진이 정한다
같은 카메라, 같은 지시문, 배경만 바꿔서 검사 점수의 상한을 재봤다. 도구 자신의 전경 분리 함수로 참조 이미지를 오려낸 뒤, 구멍을 메워보고 원본과 비교한 값이다.
| 참조 이미지 배경 | 구멍 픽셀 | 점수 상한 | 무엇이 뚫렸나 |
|---|---|---|---|
| 어두운 회색 | 27,519 | 0.9259 | 검은 가죽 |
| 밝은 흰색 | 13,573 | 0.9564 | 크림색 상판 |
| 채도 있는 청록 | 0 | 측정 불가 | 전경 100%로 붕괴 |
| 배경 지운 PNG | 870 | 0.9964 | 거의 없음 |
모델은 손대지 않았다. 배경만 바꿨는데 도달 가능한 최고점이 0.9259에서 0.9964로 올라갔다. 이유는 규칙 한 줄이다. 전경 분리가 배경색과의 색 거리로 이뤄지기 때문에, 어두운 배경은 물체의 어두운 면을, 밝은 배경은 밝은 면을 잃는다. 크림색과 검정을 함께 가진 물건은 어떤 단색 배경으로도 양쪽을 다 살릴 수 없다.
실무 지침으로 옮기면 이렇다. 참조 이미지는 배경을 지운 PNG로 준비한다. 배경색을 무엇으로 할지는 애초에 틀린 질문이다. 단색을 써야 한다면 무채색이어야 한다. 채도 있는 배경은 오려내기 자체를 무너뜨린다. 이 지침은 원문 워크플로에도 스킬 문서에도 없다.
여기서 따라오는 결론이 하나 더 있다. 점수는 물건끼리 비교할 수 있는 값이 아니다. 전자레인지는 첫 렌더에서 0.9567, 달항아리는 0.9515가 나왔다. 매끈한 면이라 오려내기가 안 뚫린다. 반면 철망 가드가 있는 선풍기는 통과선 0.85가 “동심원 28개를 2픽셀 이내로 재현하라”는 뜻이 된다. 참조 마스크를 자기 자신과 비교하면서 평행이동만 시켜봤다.
1px 이동 -> 0.9162
2px 이동 -> 0.8600
3px 이동 -> 0.8132 ← 이미 통과선 미달같은 상수 0.85가 고체 상자에서는 “대충 맞다”이고 철망에서는 도달 불가다.
검사가 통과시키는 것
빈 골격을 에러 15건으로 막던 그 검사가, 부품 하나가 통째로 다른 물건이 되는 것은 통과시킨다.
달항아리 어깨 부품을 “돌려 깎은 모양”으로 선언하고 그 단면 좌표를 빠뜨렸더니, 생성기가 조용히 기본값을 넣었다. 그 기본값은 허리가 잘록한 모래시계 형태다. 달항아리 어깨와 아무 관계가 없다. 그리고 --strict-quality는 통과했다.
같은 구멍이 넷이다. 돌려 깎기, 관, 곡선 스윕, 날 갈기 네 가지 도형의 기본값 상수를 검증기가 한 번도 언급하지 않는다. 대조적으로 다른 한 방식에는 같은 검사가 걸려 있다. 즉 이 저장소는 “선언과 실제가 어긋나는 것”을 막는 법을 알고 있고, 나머지 네 경로에만 적용하지 않았다.
저장소 문서가 이 한계를 스스로 밝힌 대목도 있다. 부품 대조 검사에 대해 이렇게 적었다. 이 검사는 “당신이 명세한 것을 만들었다”를 증명할 뿐 “충분히 명세했다”는 증명하지 못한다.
그 밖에
- 한국어 이름을 넣으면 함수 이름이 사라진다. 이름을 식별자로 바꾸는 함수가 알파벳과 숫자만 남기고 나머지를 버린다.
달항아리를 넣으면 진입점이createObjectModel이 된다. 크래시는 없고 설계도 안의 한글 데이터도 그대로 살아남는다. 문제는 경고가 아무 데도 없다는 것이다. - 버전 표기가 문서마다 다르다. 우리가 받은 커밋의 git 태그는
v1.5-beta인데 같은 커밋의 스킬 문서 상단에는1.4.4가 적혀 있다. 에이전트가 읽는 값과 사람이 보는 값이 다르다. - 약속된 측정 자료가 아직 없다. 토큰 비용 문서가 스스로 “engineering estimates, not a measured benchmark”라고 밝히면서 실측 벤치마크는 v1.5에 온다고 적었다. 우리가 받은 것이 바로 그
v1.5-beta태그 커밋인데 벤치마크 산출물이 없고, 로드맵의 v1.5 정의는 캐릭터 업데이트다. - 검색용 자료의 40%가 베트남어다. 로컬 스펙 검색이 쓰는 데이터를 전수 집계하니 문자 기준 40.4%가 영어-베트남어 병기의 번역문이었다. 결함은 아니다. 관리자와 커밋 타임존과 일치하는 제작 배경이다. 다만 검색할 때마다 결과에 번역문이 딸려 오므로 토큰 효율을 내건 도구에서는 세는 구멍이고, 한국어 항목은 없다.
- 테스트가 다 통과해도 결과 코드가 컴파일된다는 보장은 아니다. 저장소 자신의 안내 문서가 “a green run has not proven the emitted Three.js compiles”라고 경고한다. 자동 테스트도 우분투 단일 러너에 파이썬 3.10 하나만 돈다. 윈도우와 맥은 자동 검증되지 않는다.
자주 묻는 질문
무료인가요?
도구 자체는 Apache-2.0 오픈소스이고 자체 API 키를 요구하지 않는다. 파이프라인 코드 전체를 훑어 API 키나 모델 호출이 없음을 확인했다. 다만 판단과 코드 작성은 전부 호스트 에이전트가 하므로 모델 사용료는 사용자 부담이다. 필수 21단계 중 8단계가 에이전트가 판단해야 하는 항목이고 그 부분이 곧 토큰이다. README와 스킬 문서와 토큰 비용 문서 어디에도 “모델 사용료는 사용자 부담”이라고 적힌 문장은 없다. 문서가 제시하는 추정치는 물체 하나에 약 8만~18만 토큰이며, 문서 스스로 이 값이 측정치가 아니라 보물상자 한 건에 기댄 어림값이라고 밝힌다. 우리 쪽 실측은 하지 못했다. 검증 세션이 다른 작업과 섞여 있어 깨끗한 값이 나오지 않았고, 추정으로 채우지 않았다.
윈도우에서 되나요?
된다. README의 클론 명령 한 줄을 그대로 실행해 관리자 권한 없이 종료 코드 0으로 끝났고, 문서의 모든 예제가 쓰는 python3 명령도 윈도우에서 정상 동작했다. 마이크로소프트 스토어 별칭 문제는 이 환경에서 발생하지 않았다. 걸리는 곳은 하나뿐이다. 호스트를 둘 이상 쓸 때 문서가 안내하는 심볼릭 링크가 관리자 권한을 요구한다(Administrator privilege required for this operation.). 정션(New-Item -ItemType Junction)으로 만들면 권한 없이 같은 결과가 나온다. Claude Code 하나만 쓴다면 위 클론 한 줄로 끝난다. 참고로 저장소의 자동 테스트에 윈도우 러너는 없다.
참조 이미지는 뭘 넣어야 하나요?
배경을 지운 PNG가 가장 낫다. 같은 물건, 같은 지시문으로 배경만 바꿔 재보니 도달 가능한 점수 상한이 어두운 회색 배경 0.9259에서 배경 지운 PNG 0.9964로 올라갔다. 배경색을 고르는 것보다 지우는 쪽이 낫다는 뜻이다. 단색을 써야 한다면 무채색이어야 한다. 채도 있는 배경은 오려내기를 통째로 무너뜨린다. 그리고 사진보다 로우폴리 렌더 이미지가 통과하기 쉽다. 원문 저자가 제시한 워크플로 자체가 이미지 생성으로 로우폴리 참조를 먼저 만든 뒤 이 도구에 넣는 순서다.
검사를 통과하면 잘 만든 건가요?
아니다. 통과는 “안 망가졌다”이지 “맞다”가 아니다. 같은 편 안에서 두 소재로 확인했다. 겹침 점수 0.9234로 통과한 카메라가 0.663으로 미달한 선풍기보다 참조 사진과 덜 닮았다. 만든 사람도 저장소 문서에 같은 내용을 적어뒀다. 사진 참조와 코드 재구성을 비교할 때 이 점수는 충실도가 아니라 구도·배경·크기·조명 차이에 지배되며, 이 모드에서 점수를 좇으면 모델이 더 나빠진다는 것이다. 자기 갤러리 대표작인 BMX 자전거가 같은 검사에서 0.53으로 거부됐다.
지금 써도 되나요?
목표에 달렸다. 그림 한 장이 목표면 쓰지 않는 편이 빠르다. 검사를 통과시키려고 재고 다시 굽는 반복이 길고, 화면 안 크기 하나 맞추는 데도 세 번을 돌았다. 문서 순서를 그대로 따르면 첫 단계에서 멈춘다.
부품이 붙은 에셋이 필요하면 값이 있다. 부품 89개와 회전축이 선언된 동작 8종이 나오고, 그대로 영상 파이프라인에 넣어 렌더했으며 같은 프레임을 두 번 렌더해 결과가 일치했다. 다른 사람이나 다른 에이전트가 이어받아야 할 때, “이 값 왜 이래?”에 답해야 할 때, 여러 시도를 같은 기준으로 비교해야 할 때도 마찬가지다.
중요한 건 이 도구가 만들어지는 중이라는 점이다. 저장소가 만들어진 지 한 달이고, 한계는 만든 사람이 문서에 적어뒀으며, 고칠 방법도 적어놓고 미뤄뒀다. “쓰레기다”가 아니라 “지금은 여기까지고 왜 그런지 안다”에 가깝다.
마무리
저장소는 github.com/img2threejs/img2threejs에 있고, 코드가 실제로 도는 갤러리는 img2threejs.github.io/img2threejs-showcase에 있다. 처음 써본다면 순서는 이렇다.
- 스킬 디렉터리에 클론한다. 윈도우에서도 명령 한 줄이면 된다.
- 참조 이미지의 배경을 지운다. 이걸 먼저 하면 나중에 검사 점수 때문에 헤맬 일이 크게 줄어든다.
- 에이전트에서
/img2threejs로 호출한다. - 점수를 좇지 않는다. 첫 단계에서 겹침 점수가 통과선에 못 미치면, 그건 대개 모델이 아니라 사진과 화면 구도의 문제다. 도구를 만든 사람이 그렇게 적어뒀다.
마지막으로, 이 글의 신뢰도에 관해 한 줄 적어둔다. 우리가 다섯 물건을 돌려가며 실측으로 발견한 것 중 상당수는 이미 저장소 문서에 적혀 있던 내용이었다. 그 파일을 마지막 날에야 열었기 때문이다. 도구를 평가하기 전에 도구의 문서를 다 읽는 것, 그게 우리가 이번에 배운 것이다.
같은 방식으로 끝까지 돌려본 다른 도구들: