3줄 요약
- npaka가 2026년 9월 15일 note에 올린 정리글이다. AI 에이전트로 Blender를 조작할 때 Blender MCP보다 Computer use 쪽이 결과가 좋았다는 보고가 X에 올라왔고, npaka는 이 게시물을 출발점으로 삼아 Computer use, Blender MCP, Blender CLI를 견주어 본다.
- npaka가 원인으로 든 것은 AI 모델의 성능 차이가 아니었다. Computer use는 화면을 보고 조작한 뒤 다시 화면을 확인하는 과정이 처음부터 작업 절차에 들어 있다. Blender MCP도 화면을 이미지로 가져올 수 있지만, 파이썬 API가 돌려주는 수치와 오브젝트 정보만으로 작업이 끝나 버리는 경우가 있다.
- 그래서 npaka의 결론은 MCP가 약하다는 말로 끝나지 않는다. 필요한 공정에서 MCP가 화면을 확인하도록 작업을 설계하면, 눈으로 문제를 찾고 파이썬 API로 한꺼번에 고치고 수치로 검증하는 순환을 만들 수 있다. 여기에 대량 처리와 렌더링을 CLI로 넘기면 세 방법의 역할이 나뉜다.
npaka가 글의 출발점으로 삼은 것은 Nano(@Dstudio_ai)가 2026년 9월 12일에 올린 다음 게시물이다.
Tripo와 GPT-6 Astra로 캐릭터 모델을 만들어 봤으니 메모! 【PR: Tripo】
엄청 중요한 부분!!!! Blender MCP를 되도록 쓰게 하지 않는다. 열 번 중 아홉 번 이상은 Computer use로 시킨다. 이게 정말이지 제일 중요하다…
언뜻 보면 Blender 내부 정보를 가져와 파이썬 API로 직접 조작하는 Blender MCP 쪽이 강해 보인다. 그런데 모델링이나 UV 전개, 텍스처 조정처럼 화면을 보면서 시행착오를 거치는 작업에서는 Computer use가 유리해질 수 있다고 npaka는 본다.
Computer use
Computer use는 Blender 전용 API를 쓰지 않는다. Blender 화면을 이미지로 가져온 뒤, 보이는 내용을 판단하며 GUI를 조작한다. 사람이 하는 것과 같은 순서를 반복한다.
화면을 본다 → 조작한다 → 결과를 본다 → 다음 조작을 정한다
볼 수 있는 화면은 3D 뷰포트에 그치지 않는다. 아웃라이너, 모디파이어, 셰이더 에디터, 지오메트리 노드, UV 에디터, 경고 대화상자까지 Blender UI 전체를 시각 정보로 쓸 수 있다는 점이 특징이다.
머티리얼을 예로 들면 이런 식이다. Roughness를 바꾸고, 보이는 모습을 확인하고, 광택이 너무 강하면 다시 조정한다. 사람과 비슷한 시행착오를 거치는 셈이다.
조작 속도는 API를 쓸 때보다 느릴 수 있다. 그 대신 화면을 기준으로 작업하기 때문에, 수치나 내부 정보만으로는 알아채기 어려운 위화감을 발견하기 쉽다.
Blender MCP
Blender MCP는 AI와 Blender를 MCP로 연결하고, Blender 파이썬 API와 전용 도구로 내부를 직접 조작하는 방법이다.
공식판과 커뮤니티판을 포함해 구현이 여럿 있지만 기본 역할은 같다. AI가 씬과 오브젝트 정보를 가져오고, 파이썬 코드를 실행해서 형상, 머티리얼, UV, 지오메트리 노드를 조작한다.
마우스로 메뉴와 버튼을 차례로 누를 필요가 없으므로 다음과 같은 작업에 맞는다.
- 오브젝트 여러 개를 한꺼번에 변경하기
- 정확한 수치를 설정하기
- 데이터 구조와 참조 관계를 조사하기
- 처리 결과를 수치로 검증하기
지금의 Blender MCP에는 뷰포트나 Blender 창을 이미지로 가져오는 구현도 있다. 그래서 조작한 뒤 화면을 가져와 확인하고, 다시 조작하는 흐름도 만들 수 있다.
화면 취득 도구를 갖췄다는 것과 AI가 그 도구를 매번 쓴다는 것은 별개다. 작업을 진행하는 방식에 따라서는, 파이썬 API에서 얻은 수치와 오브젝트 정보를 중심으로 처리하고 화면을 거의 확인하지 않은 채 끝나기도 한다.
Blender CLI
Blender에는 GUI를 열지 않고 명령줄에서 처리하는 Blender CLI도 있다. 다음 명령을 실행하면 Blender를 백그라운드로 띄우고, 지정한 .blend 파일에 파이썬 스크립트를 적용한다.
blender -b scene.blend -P script.py
AI 에이전트가 파이썬 코드를 작성해 CLI로 실행하고, 결과를 확인한 뒤 수정하는 순환을 반복할 수도 있다.
다음과 같은 용도에 특히 맞는다.
- 오브젝트를 대량으로 처리하기
- 여러 파일에 같은 변경을 적용하기
- 렌더링하기
- 파일 형식을 변환하기
- 야간에 대량 처리를 실행하기
한편 Blender CLI는 기본적으로 화면을 보면서 조작하는 구조가 아니다. 보이는 모습을 확인하려면 뷰포트 이미지나 렌더링 이미지를 출력해서 AI에게 넘겨야 한다.
셋은 어떻게 다른가
npaka가 각 방법을 한 줄로 요약한 대목을 표로 옮기면 다음과 같다.
| 방법 | 한 줄 요약 |
|---|---|
| Computer use | GUI를 보고 판단하면서 조작한다 |
| Blender MCP | 내부를 직접 조작하고, 필요에 따라 화면도 본다 |
| Blender CLI | 스크립트를 실행해서 자동 처리한다 |
Computer use는 Blender UI 전체를 보면서 사람에 가까운 방법으로 작업한다. Blender MCP는 파이썬 API와 전용 도구를 써서 내부 정보를 가져오고 정확하게 처리한다. Blender CLI는 GUI가 필요 없는 자동화와 대량 처리에 맞는다.
왜 Computer use가 더 강해 보이는가
npaka는 두 가지를 이유로 들었다.
조작 앞뒤로 화면을 확인한다
첫째는 화면을 주된 정보로 삼고, 작업 중에도 되풀이해 확인한다는 점이다. 화면을 보고 조작하고 결과를 확인하는 시각 피드백이 처음부터 작업 순서에 들어 있다.
그래서 모델링, UV 전개, 텍스처, 머티리얼, 라이팅에서 생기는 다음과 같은 문제를 발견하기 쉬워진다.
- 형태가 부자연스럽다
- 부품끼리 서로 파고들어 있다
- UV의 배치나 방향이 좋지 않다
- 텍스처에 얼룩이나 이음매가 있다
- 질감이 플라스틱처럼 보인다
- 너무 밝거나 너무 어둡다
이 문제들은 폴리곤 수, 좌표, 머티리얼 설정값을 가져오는 것만으로는 판단하기 어렵다. 사람이 마지막에 볼 이미지가 자연스러운지는 실제 화면을 확인해야 알 수 있다.
MCP에서는 화면 확인이 생략되기도 한다
둘째로 npaka는 MCP를 쓸 때 어떤 정보를 중심에 두는지에 주목했다. Blender MCP도 이미지를 가져올 수 있지만 처리의 중심은 파이썬 API와 씬 정보다. AI가 화면 확인을 건너뛰면 수치는 모두 맞는데 보이는 모습만 어긋난 결과가 나온다.
예를 들어 UV가 겹치지 않고 면적에도 문제가 없다고 검증했다고 하자. 그래도 UV 섬이 너무 잘게 나뉘었을지 모른다. 배치 효율이 나쁠 수도 있고, 베이크한 텍스처에 이음매가 두드러지기도 한다. 머티리얼 수치가 적절한 범위 안에 있어도, 조명과 조합하면 부자연스럽게 보이는 일도 있다.
npaka는 차이가 생기는 원인을 MCP의 조작 능력이 낮은 데서 찾지 않았다. 작업 중에 무엇을 보고 어떤 기준으로 다음 행동을 정하는가에 원인이 있다고 밝혔다.
MCP가 화면을 보게 되면
앞으로 Blender MCP를 쓰는 AI 에이전트가 보이는 모습을 판단해야 하는 공정에서 화면을 적극적으로 가져오도록 작업 방식을 조정하면, 이 차이는 줄어들 것이라고 npaka는 예상한다. 그가 그린 순환은 다음과 같다.
화면을 가져온다 → 보이는 문제를 판단한다 → 파이썬 API로 직접 수정한다 → 수치와 데이터 구조를 검증한다 → 다시 화면을 가져온다
이렇게 하면 Computer use의 화면을 보고 판단하는 능력과 Blender MCP의 내부를 직접 조작하는 능력을 함께 쓸 수 있다.
Computer use에서는 버튼을 찾아 클릭하고 항목에 수치를 입력해야 한다. MCP라면 파이썬 API에서 대상을 직접 변경한다. 그러므로 MCP를 쓰는 장면에서 화면을 반드시 확인하면, Computer use보다 적은 조작으로 빠르고 정확하게 작업할 가능성이 있다.
특히 화면에서 위화감을 발견하고, 파이썬 API로 한꺼번에 수정하고, 내부 정보로 수정 결과를 검증하는 조합은 보이는 모습과 구조가 둘 다 중요한 3D 제작에 어울린다.
셋을 나누어 쓰는 흐름
현시점에서는 하나만 고르기보다 작업에 따라 조합하는 방법도 유효하다고 npaka는 덧붙였다. UV 전개를 예로 들면 다음 흐름이 나온다.
- Computer use나 MCP로 화면을 가져와 UV 에디터를 확인한다
- 배치나 이음매의 문제를 발견한다
- MCP와 파이썬 API로 UV를 수정한다
- 화면에서 보이는 모습을 다시 확인한다
- MCP로 겹침과 면적을 수치로 검증한다
- CLI로 여러 모델에 같은 처리를 적용한다
역할을 정리하면 이렇다. 눈으로 보는 단계에서 문제를 판단하고, MCP로 내부를 정확하게 조작하고 검증하며, CLI로 같은 작업을 자동화해 대량 처리한다.
가장 흥미로운 지점
내가 가장 의외라고 느낀 것은 이 글이 내린 결론이었다. 출발점은 “MCP를 되도록 쓰지 말라"는 현장 보고였는데, 결론은 “MCP가 화면을 보게 되면 더 적은 조작으로 해낼 수 있다"였다. npaka가 원인을 도구의 성능에서 관측 설계로 옮겨 놓았기 때문에 이런 뒤집기가 가능했다.
npaka가 내린 진단은 Blender 밖의 다른 도구에도 그대로 옮겨 놓을 수 있다. 내부 상태를 정확히 읽을 수 있는 도구일수록 에이전트가 화면 확인을 건너뛰기 쉽다. 수치 검증이 통과하면 확인이 끝났다고 여기기 때문이다. 결과물을 마지막으로 받아 드는 사람이 있는 한, 수치만 통과한 검증은 절반에서 멈춘다. UV가 겹치지 않았다는 보고는 이음매가 눈에 띄지 않는다는 보고를 대신해 주지 못한다.
npaka는 9월 3일에 Blender CLI와 Blender MCP를 나누어 쓰는 법을 정리했고, 열이틀 만에 세 번째 방법인 Computer use를 더했다. 두 글을 나란히 놓고 보면 그가 같은 질문을 되풀이한다는 것을 알 수 있다. 에이전트에게 무엇을 만들게 할 것인가, 그리고 그 결과를 무엇으로 확인하게 할 것인가.
출처
npaka, 「Blender MCPよりComputer useの方が高性能？その理由を考える」, note, 2026년 9월 15일 원문: https://note.com/npaka/n/n2780a7f4494a
인용한 X 게시물: Nano(@Dstudio_ai), 2026년 9월 12일 https://x.com/Dstudio_ai/status/2098760566672417240
원문에는 인용할 만한 이미지가 없어 삽화로 대신했다. 삽화는 「느낌적인 느낌을 숫자로 옮기는 일」의 치비 서소영 라인아트를 참조해 gpt-image-2.5-flare의 image-to-image 기능으로 생성했다.