개요
3D 공간 개발은 LLM의 대표적 약점. 코드는 잘 짜도 “눈”이 없어 결과가 맞는지 스스로 판단 못 함. Dave Snider가 Three.js 프로젝트에서 도달한 해법: Claude가 직접 카메라 조작·스크린샷 캡처·결과 검증을 반복하는 자기 검증 루프. 3D를 넘어 UI·데이터 시각화·게임 등 “눈으로 봐야 하는” 모든 영역에 확장 가능.
- 출처: Dave Snider (Table Slayer, Counter Slayer 개발자)
- HN 토론: 2026-03-18 화제
- 핵심: 프롬프트 엔지니어링 ❌ → 피드백 루프 설계 ✅
문제: LLM은 3D를 “볼” 수 없다
2D 작업 (CSS·디자인): Claude 추론 가능 ✅
3D 공간 분석: 매번 실패 ❌
STL 파일 읽기: "읽었다"고 거짓말, 실제로는 바이너리 지어냄 ❌
기존 방식의 한계:
- 사람이 직접 스크린샷 찍어서 “이거 봐, 틀렸어” 피드백 → 수동 작업에 몇 시간 소모
- Python 라이브러리로 STL 파싱 → CAD 시스템 자체의 3D 구성 디버깅엔 부족
스크린샷 루프 구조
[Claude의 자율 루프]
1. 코드 변경
↓
2. STL/3D 모델 재생성
↓
3. Playwright로 다양한 각도 렌더링 캡처
↓
4. 레이아웃 데이터와 대조
↓
5. 문제 있으면 → 1번으로 돌아가기
문제 없으면 → 사용자에게 알림
⚠️ 핵심: 매 단계마다 사용자 확인 요청 ❌ (자율 실행)
CLAUDE.md 워크플로우 정의 예시
## 3D 작업 워크플로우
코드 변경 시 다음을 반드시 수행:
1. STL 재생성 스크립트 실행
2. Playwright로 iso, top, front, left 4개 각도 캡처
3. 캡처된 이미지를 검토하여 의도와 일치 확인
4. 불일치 시 코드 수정 후 1번부터 반복
5. 모든 각도가 만족스러우면 사용자에게 보고카메라 제어 스크립트 설계
| 기능 | 설명 |
|---|---|
| 프리셋 앵글 | iso, top, front, left, right, bottom, back |
| 줌 레벨 | min/mid/max 3단계 |
| 커스텀 포지션 | x, y, z 좌표 직접 지정 |
| 오브젝트 타겟팅 | 특정 ID 기반 자동 프레이밍 |
| 디버그 마커 | 빨간 구체 같은 시각적 표시 배치 |
→ Claude가 “여기를 더 자세히 보겠다” 판단 시 스스로 줌인·각도 변경
핵심 원칙: “공유 언어” 먼저 구축하라
Snider의 가장 중요한 통찰: “Claude에게 요청을 잘 설명하려고 애쓰는 대신, 프로젝트를 함께 논의할 수 있는 ‘공유 언어’를 먼저 만들라”
| 작업 영역 | 공유 언어 (Claude의 “읽을 수 있는 출력”) |
|---|---|
| 일반 웹 | 테스트 코드 |
| 3D / 비주얼 | 스크린샷 루프 |
| 디자인 탐색 | 임시 로깅 (좌표·포지션 값 출력) |
| CAD (부울 연산) | 스크린샷 + 좌표 로그 (둘 다 필요) |
HN 커뮤니티 사례
GrandpaCAD (3D 모델링)
- 동일 패턴 이미 구현
- 비용 4배 증가 → 비활성화 상태
- 가격 내려가면 즉시 재활성 예정
- → 효과 입증, 경제성이 걸림돌
Unity 게임 개발
- 아이소메트릭 + 퍼스펙티브 모드
- 게임 오브젝트 ID 리스트 포커싱 카메라
- VLM을 도구 호출 내부의 중첩 연산으로 실행
- 사용자 컨텍스트 ❌ → 별도 호출 ✅
- 토큰 예산 초과 없이 다수 이미지 분석
- GPT-5.4가 “주관적으로 흥미로운” 카메라 위치에 도달하면 멈추는 행동 관찰
- → 모델이 어느 정도 3D 공간 감각 보유 시사
Onshape FeatureScript (Codex GPT-5.4)
- Chrome DevTools MCP + Playwright로 브라우저 제어
- 텍스트 + 비주얼 오버레이 디버깅 출력
- 직교 뷰 스크린샷: 모델이 상당 부분 이해
FreeCAD 교회 탑 모델링
- 정사각형 기초 → 팔각형 상부 로프트
- GUI로 만들면 엉뚱한 결과
- Claude가 첫 시도에 완벽한 Python 코드 생성
- 단점: 영어로 정확히 표현하기 어렵고, 잘못된 방향 빠지면 빠져나오기 힘듦
Revit (Windows 건축 CAD)
- CLI 인터페이스 노출
- 동일한 “코드 작성 → 스크린샷 → 반복” 루프 구현
개발자별 “신뢰 경계” (Trust Boundaries)
Snider 입장 (장인 정신)
- 직접 작성: CSS, 디자인, 초기 아키텍처
- Claude에게 위임: 나머지
- → “가장 신경 쓰는 부분은 내가 통제”
반대 의견 (효율성)
- LLM에게 위임: CSS, 디자인 (학습 데이터 풍부)
- 직접 작성: 민감한 백엔드, 자주 업데이트되는 프레임워크
- → “LLM이 잘하는 곳에 맡기고 리스크 큰 곳에 에너지 집중”
→ 둘 다 틀리지 않음 — 프로젝트 성격·개발자 강점에 따라 달라짐
메타 패턴: “도구를 만드는 도구”
이전 시대:
"코드를 짜달라" 요청
현재 (LLM 시대):
"LLM이 스스로 검증·반복할 수 있는 인프라" 구축
↓
Playwright 스크린샷
+ 커스텀 카메라 제어
+ CLAUDE.md 워크플로우
+ (도메인별 도구)
“모델이 사용할 수 있는 간단한 도구를 만들면, 그것 자체가 문제를 매우 유용한 방식으로 프레이밍해준다.” — HN 사용자
적용 가능 영역
| 영역 | 공유 언어 |
|---|---|
| 3D 모델링 | 스크린샷 루프 (다각도) |
| UI 디자인 | 스크린샷 + 컴포넌트 트리 |
| 데이터 시각화 | 차트 렌더링 + 데이터 검증 |
| 게임 개발 | 게임 상태 스크린샷 + 액션 로그 |
| 모바일 앱 UI | 시뮬레이터 스크린샷 |
| PDF/문서 생성 | PDF 렌더링 + 텍스트 추출 |
| 로봇/IoT | 센서 데이터 + 시뮬레이션 시각화 |
결론
LLM 생산성의 핵심 변화:
❌ 프롬프트 엔지니어링
✅ 피드백 루프 설계
텍스트 코딩 → 테스트가 루프
3D/비주얼 → 스크린샷이 루프
피드백 루프를 잘 설계할수록 Claude의 자율성이 올라가고, 사용자 개입 없이 문제를 해결.