아무도 부탁 안 한 등불 3,500개 — 블렌더 에이전트와 미명세 벤치마크

목적: **둘 다 똑똑하면, 벤치마크는 여백을 다루는 방식으로 옮겨 갑니다.** "밤 풍경을 만들어 줘"는 거의 모든 것을 미결정으로 남깁니다 — 개수, 분위기, 멈출 시점. 등불 3,500개는 버그가 아닙니다: **모든 열린 작업이 조용히 던지는 질문 — *명세되지 않은 공간을 내가 얼마나 소유하는가?* — 에 대한 하나의 답**입니다. 한 기질은 여백을 주도권으로 채우고(인상적, 비싸고, 가끔은 정확히 원하던 것), 다른 기질은 첫 공개까지의 시간을 최적화하며 여백을 피드백 기회로 되돌려 줍니다. 어느 쪽도 틀리지 않지만 — 어울리는 일이 다르고, **최종 렌더만 채점하는 벤치마크는 그 차이를 영영 못 봅니다.** **대화형 작업에서는 조기 공개가 대개 이기고, 이유는 루프입니다.** 2분 만의 첫 렌더는 사람을 명세의 빠진 부분으로 전환합니다: 흘낏 본 뒤의 "등불 줄이고 빛은 따뜻하게"가 어떤 무단 정교화보다 낫습니다 — **에이전트의 의도 모델은 명세가 침묵한 바로 그 지점에서 가장 약하니까.** 이것은 `demonstration-is-not-a-specification` 의 역방향 실행입니다 — 모호한 요청을 시연 면허로 취급하는 에이전트는 주어진 적 없는 명세를 제조하는 중입니다. 그리고 과잉 이행에는 청구서가 있습니다: 부탁하지 않은 수천 오브젝트는 수천 번의 유료 도구 루프 — 캐시 읽기 가격 인하가 겨냥한 바로 그 비용 구조입니다. **블렌더는 보기보다 좋은 에이전트 실험실입니다.** 완전한 Python 표면(`bpy`)을 가진 프로 도구라, 에이전트가 픽셀을 클릭하는 게 아니라(`agents-computer-use` 의 하드 모드) **검증 가능한 결과가 남는 진짜 API 명령**을 내립니다 — 오브젝트 수, 렌더 시간, 단언할 수 있는 씬 그래프. 그래서 기질이 *측정 가능*해집니다: 같은 열린 프롬프트, 숫자 넷, 루브릭 하나. `the-harness-not-the-model` 이 차별화는 하네스에 산다고 했는데, 이 카드는 하룻저녁에 누구나 돌릴 수 있는 값싼 하네스 실험이고 — SNS 후기의 결론("둘 다 훌륭!")이 정확히 이 루브릭이 대체하는 비측정입니다.

동작 방식: ### 배선 선택지 | 경로 | 동작 | 맞는 곳 | | --- | --- | --- | | blender-mcp | MCP 서버 + 블렌더 애드온 소켓 → 라이브 `bpy` 명령 | 대화형 에이전트 세션, 전체 루프 | | 헤드리스 스크립트 | 에이전트가 `bpy` 스크립트 작성 → `blender --background --python` | CI 가능, 결정적, 라이브 피드백 없음 | | 스크린샷 조작 | 렌더를 읽고 UI 클릭 | `agents-computer-use` 하드 모드 — 그게 목적이 아니면 피할 것 | ### 관찰된 두 기질 | | 과잉 이행형 (등불 3,500개) | 조기 공개형 | | --- | --- | --- | | 여백을 채우는 것 | 주도권과 정교화 | 리뷰 가능한 초안 | | 첫 가시 결과 | 늦고 화려함 | 몇 분, 소박함 | | 비용 프로필 | 수천 번의 유료 루프 | 피드백 전까지 작음 | | 실패하는 때 | 명세의 통제권을 원했을 때 | 놀라움을 원했을 때 | | 맞는 일 | 밤샘 배치 아트, 탐색 | 대화형 협업 — 대부분의 실무 | ### 런마다 기록할 숫자 넷 1. 사람이 반응할 수 있는 첫 렌더까지의 시간. 2. 부탁하지 않은 요소 수 (등불 숫자). 3. 태운 토큰과 도구 루프 횟수. 4. 피드백 한 번에 대한 반응 품질 — 수정이 부수적 재작업 없이 착지하는가? ### 블렌더가 가능하게 하는 단언들 | 검사 | 수단 | | --- | --- | | 오브젝트 수가 의도와 일치 | `len(bpy.data.objects)` | | 예산 안의 렌더 | 렌더 시간 로그 | | 피드백의 최소 적용 | 반복 간 씬 그래프 diff | | 폭주 루프 없음 | 턴당 명령 수 |