AI용 블렌더 FX 도구 기획 (수정판)

2026-09-19 · 전제 변경: 사용자는 블렌더를 모르고, 클로드·코덱스에게 말로 시켜서 결과를 얻고 싶다

결론

만들 것은 "사람이 클릭하는 애드온"이 아니라 "AI가 호출하는 FX 도구 상자(MCP 서버)"입니다. 사용자는 감독처럼 말로 지시하고, AI가 도구를 골라 실행하고, 결과 그림을 받아 다시 지시합니다. 지오메트리 노드 기반이 아니라 파이썬 레시피 기반이 맞습니다.

1. 질문에 답: 지오메트리 노드로 하는 건가?

아니요, 주 재료가 아닙니다.

지오메트리 노드는 "레고 조립 설명서를 그림으로 그린 것"입니다. 모양을 만들거나 바꾸는 데 씁니다. 파괴·폭발·물의 물리 계산은 따로 있는 엔진이 합니다. 파괴는 리지드바디(딱딱한 물건 물리), 폭발과 물은 Mantaflow(연기·불·액체 물리)입니다.
AI가 조종하기엔 노드보다 파이썬(bpy)이 훨씬 쉽습니다. 노드는 선을 수십 개 이어야 해서 AI가 말로 만들면 자주 틀립니다. 파이썬은 "이 물건을 조각내고, 물리 켜고, 계산 저장해"를 글로 쓰면 끝입니다.
지오메트리 노드는 먼지·파편 뿌리기 같은 보조 효과에만 씁니다. 그것도 AI가 매번 만들지 않고, 미리 만들어 둔 노드 묶음을 파일에서 꺼내 붙이기만 합니다.

2. 먼저, 안 되는 부분

약점과 실패 가능성

"말 한마디에 원하는 그림"은 첫 시도엔 안 나옵니다. FX는 계산(굽기)에 몇 분 걸리고, 결과 보고 고치기를 3~10번 반복해야 봐줄 만한 게 나옵니다. 이 반복 고리를 설계하지 않으면 실패합니다.
블렌더를 모르면 AI가 낸 오류를 못 잡습니다. AI가 쓴 파이썬은 블렌더 버전 차이로 자주 깨집니다. 대응은 "AI가 매번 코드를 짜게 하지 말고, 검증된 레시피를 도구로 고정"하는 것입니다. 그래서 도구 상자가 필요합니다.
움직임은 사진 한 장으로 못 봅니다. 폭발이 "좋은지"는 시간 흐름을 봐야 압니다. 도구가 프레임 4~6장 묶음이나 짧은 영상을 돌려줘야 하고, 그걸 판단하는 건 결국 사람 눈입니다.
이미 비슷한 게 있습니다. 지금 쓰는 blender-mcp가 "아무 파이썬이나 실행"과 "화면 캡처"를 제공합니다. 차이를 못 만들면 그냥 그걸 쓰는 게 낫습니다. 차이는 아래 4번에 있습니다.
컴퓨터가 감당해야 합니다. 물 시뮬레이션은 메모리·시간을 많이 먹습니다. 미리보기 해상도를 도구가 강제로 낮춰야 합니다.

3. 어떻게 돌아가나

사용자: 3층 건물이 왼쪽 아래에서 충격 받고 무너지는 장면, 먼지 많이.

AI: fx.destroy(target="Building", impact="left-bottom", material="concrete", dust="high", preview=True) 호출 → 도구가 조각내기·물리·굽기·저해상도 렌더까지 한 번에 실행 → 프레임 5장 묶음 반환.

AI: (그림 보여주며) 조각이 큰 편입니다. 더 잘게 갈까요?

사용자: 더 잘게, 그리고 느리게.

AI: fx.destroy(..., pieces=400, time_scale=0.6) → 새 묶음 반환.

사용자: 좋아. 최종으로.

AI: fx.render(quality="final") → 영상 파일 경로.

클로드든 코덱스든 MCP를 쓰는 어떤 AI든 같은 도구를 부릅니다. 사용자는 블렌더 화면을 열 필요가 없습니다.

4. 구조와 기존 blender-mcp의 차이

구분	지금 blender-mcp	이 프로젝트
AI가 하는 일	파이썬 코드를 매번 새로 짜서 보냄	검증된 도구를 고르고 값만 넣음
도구 종류	코드 실행, 장면 정보, 화면 캡처, 에셋 다운로드	`destroy` `explode` `pour_liquid` `render_preview` `render_final`
결과 확인	화면 캡처 1장	프레임 묶음(4~6장) 또는 짧은 mp4
실패 시	오류 메시지를 AI가 해석	도구가 원인을 한글로 돌려줌("메모리 부족, 해상도 낮춤")
버전 깨짐	AI 코드가 깨짐	도구 안에서 한 번 고치면 끝

[클로드 / 코덱스]
      │  "건물 무너뜨려"
      ▼
[FX MCP 서버]  ← 이 프로젝트. 파이썬. 도구 5개로 시작
      │  레시피 스크립트 전송
      ▼
[블렌더 안 애드온]  ← 소켓으로 명령 받아 실행 (blender-mcp 방식 재사용)
      │
      ▼
[리지드바디 / Mantaflow / 미리 만든 노드 묶음]
      │
      ▼
[프레임 묶음 이미지] → AI와 사용자가 봄

블렌더 안쪽 코드는 GPL이 필수입니다. 바깥 MCP 서버는 자유롭게 정할 수 있지만, 한 저장소면 GPL로 통일하는 게 단순합니다.

5. 첫 2주: 도구 만들기 전에 레시피부터

1~3일: 지금 있는 blender-mcp로 "건물 파괴" 파이썬 레시피 1개를 AI에게 짜게 하고, 실제로 그림이 나오는지 봅니다. 서버를 새로 만들지 않습니다.
4~7일: 그 레시피가 5번 연속 오류 없이 돌 때까지 고칩니다. 값 3개(조각 수, 충격 위치, 재질)만 바꿔도 결과가 달라지게 만듭니다.
2주차: 레시피를 destroy 도구 하나로 감싸고, 프레임 묶음 반환까지 붙입니다. 클로드와 코덱스 양쪽에서 말로 시켜 봅니다.

2주 뒤 "말로 시켜서 파괴 프레임 묶음이 나온다"가 안 되면 폭발·물로 가지 않습니다. 되면 같은 방식으로 explode를 붙입니다.

6. 사용자의 역할

감독: 장면을 말로 설명하고, 결과를 보고 "더 느리게, 먼지 많이" 같은 연출 지시를 합니다. 이건 블렌더 지식이 아니라 눈이 하는 일입니다.
레시피 검수자: AI가 만든 레시피가 "봐줄 만한 그림"을 내는지 판정합니다. 오픈소스에서 가장 부족한 게 이 눈입니다.
안 해도 되는 것: 파이썬 읽기, 블렌더 화면 조작, 노드 연결.

7. 남은 결정

blender-mcp를 확장할지, 따로 만들지. 추천은 따로 만들되 소켓 방식은 그대로 빌리기. 원본은 범용이라 FX 도구가 섞이면 무거워집니다.
결과 형식: 프레임 묶음 이미지 1장으로 갈지, 짧은 mp4로 갈지. 추천은 묶음 이미지 먼저(AI가 바로 볼 수 있음), mp4는 최종용.
첫 레시피 대상: 건물 파괴. 내장 물리가 가장 안정적이고 계산이 빠릅니다.

이전 문서(blender-fx-opensource-plan.html)의 로드맵 순서(파괴 → 폭발 → 물)와 리스크 표는 그대로 유효합니다. 바뀐 건 "누가 쓰는가"(사람 → AI)와 "형태"(애드온 → MCP 도구)입니다.