Copy English

Why

They overlap in capability and differ in workflow, and the axis is reproducibility versus live state. The CLI path is generate-then-run: the AI writes Blender Python, it runs headless, it emits an output — and the script is a durable, reviewable, re-runnable artifact, which is why it suits batch processing, format conversion, and server execution. The MCP path is inspect-then-act: the AI connects to a running Blender, reads the current scene, operates, checks, adjusts — a stateful conversation. Neither is better; they optimize different things. This is exactly the CLI-vs-MCP debate constraint-was-the-product staged, on a different dimension: that card weighed auth, scale, and observability; this one weighs batch-reproducibility against interactive-statefulness. The axis has more than one dimension, and naming which one your task lives on is the whole decision.

The reproducibility half is the underrated one, and it is the same value as agent-ask-not-write. The CLI produces a Python artifact you can read, keep, diff, and re-run deterministically — the non-deterministic AI writes it once, the deterministic script runs it forever. The MCP, by contrast, holds its result in a running process: its power is that it can see the scene, which is the live-state-reading tool of a-boolean-hides-a-state-machine and rpc-view-not-consensus; its cost is that a conversation is not a reproducible artifact — replay it and the scene may not come back the same. So the CLI is stateless-and-reproducible and the MCP is stateful-and-live, and that is the same trade behind REST-vs-session and batch-vs-REPL — one more face of the a-boolean-hides-a-state-machine cluster, seen in a 3D tool.

The mature workflow is not either/or — it is CLI -> MCP -> CLI, and the extra instruction is how to check. Generate and batch with the CLI, refine interactively with the MCP, output and verify with the CLI. And because the agent does not see the scene the way you do, "what to build" is only half the instruction; "how to confirm it" is the other half — a fixed-camera render for comparable before/after, or the live viewport for immediacy. That is simulate-before-sign's "verify, do not assume" applied to 3D, and it generalizes: for any agent driving a tool through a keyhole, the stable instruction shape is the task plus its verification. Related: mcp-three-sides (the protocol), constraint-was-the-product (the same CLI-vs-MCP axis, other dimensions), agent-ask-not-write (the reviewable deterministic artifact), a-boolean-hides-a-state-machine (stateful vs stateless), simulate-before-sign (build plus verify).

How it works

Same capability, different workflow

The combined pipeline

Tell it how to verify, not just what to build

Related cards

mcp-three-sides (the protocol underneath), constraint-was-the-product (the same CLI-vs-MCP axis, weighed on auth/scale instead), agent-ask-not-write (the deterministic reviewable artifact the CLI leaves), a-boolean-hides-a-state-machine (stateful vs stateless, live vs reproducible), simulate-before-sign ("what to build" plus "how to verify").

Where it lands in Jayverse

• gitboard: route agent-driven updates as CLI-then-MCP-then-CLI. Any Claude/agent change to gitboard should generate a reviewable, re-runnable script first (the CLI half), use interactive tool calls only to inspect live state and adjust, then re-run the batch step to output and verify — never leave the change living only in a conversation.
• CI: keep CI on the reproducible/batch side only. Frozen-lockfile builds, contract deploys and gitboard data jobs belong in the CLI/batch bucket — durable, diffable, re-runnable; reserve interactive, stateful tool use for local exploration and keep it out of the CI path entirely.
• Number: separate research scripts from research exploration in the repo. Indicator-generation and reading pipelines are the CLI/batch side (durable, re-runnable); ad hoc data exploration during research is the MCP-style stateful side — keep the two in visibly different places so a reading's provenance script is always the reviewable artifact.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

CLI 는 산출물을 남기고, MCP 는 대화를 이어간다

Codex 나 Claude Code 로 Blender 를 다루는 두 방법: CLI 는 Blender Python 을 생성해 헤드리스로 실행해 결과물을 내고, MCP 는 실행 중인 Blender 에 접속해 단계 사이 현재 씬을 읽으며 대화형으로 조작합니다. 할 수 있는 일은 겹치지만 — 둘 다 큐브를 추가할 수 있습니다 — 작업 방식이 한 축에서 다릅니다: CLI 는 다시 돌릴 수 있고 검토 가능한 스크립트를 남기고(배치·재현성·서버 실행), MCP 는 살아있는 프로세스와 상태 있는 대화를 이어갑니다(확인·조정·검증·반복). 성숙한 방식은 둘 다입니다 — CLI 로 생성·일괄 출력하고, MCP 로 중간에 다듬기.

아직 범위 미정 — 빌드가 아니라 워크플로 분해입니다. 실제 작업 하나("교실 씬을 만들고 GLB 로 내보내기")를 둘로 라우팅합니다: CLI 로 기본 씬을 Python 스크립트로 생성(내구성·검토 가능·재실행 가능 — 바닥·벽·책상·칠판·조명을 한 번에), MCP 로 살아있는 씬을 보며 대화형 조정("책상 줄여", "칠판 크게", "창에서 빛 들어오게"), 그다음 다시 CLI 로 일괄 출력(다중 카메라 렌더, GLB export, 폴리곤 수 확인). 글이 짚는 규율은 챙길 만합니다 — AI 에게 무엇을 만들지 뿐 아니라 어떻게 확인할지도 지시할 것: 고정 카메라 렌더는 전후를 비교 가능하게 하고(CLI 의 재현 가능한 확인), 라이브 뷰포트는 즉각적이게 합니다(MCP 의 상태 있는 확인). 산출물: 작업 속성(배치? 재현성? 상태? 대화형?)을 CLI 대 MCP 로 매핑하는 결정표, 그리고 둘 다 필요한 작업을 위한 CLI -> MCP -> CLI 파이프라인. 출처: npaka(note.com), "AIでBlenderを操作する方法 — CLIとMCPの使い分け", 2026-09-03 — 실무 how-to; Blender 는 예시이고 CLI 대 MCP 축이 옮겨 쓸 부분.

왜

할 수 있는 일은 겹치고 작업 방식이 다르며, 축은 재현성 대 살아있는 상태입니다. CLI 경로는 생성-후-실행입니다: AI 가 Blender Python 을 쓰고, 헤드리스로 돌고, 결과물을 냅니다 — 그리고 그 스크립트는 내구성 있고 검토 가능하며 다시 돌릴 수 있는 산출물이라, 배치 처리·형식 변환·서버 실행에 맞습니다. MCP 경로는 확인-후-행동입니다: AI 가 실행 중인 Blender 에 접속해, 현재 씬을 읽고, 조작하고, 확인하고, 조정합니다 — 상태 있는 대화. 어느 쪽이 낫지 않고, 다른 것을 최적화합니다. 이것은 constraint-was-the-product 가 벌인 바로 그 CLI 대 MCP 논쟁을 다른 차원에서 본 것입니다 — 그 카드는 인증·규모·관측성을 저울질했고, 이 카드는 배치-재현성 대 대화형-상태성을 저울질합니다. 축에는 차원이 여럿이고, 당신 작업이 어느 차원에 사는지 이름 붙이는 게 결정의 전부입니다.

재현성 절반이 과소평가된 쪽이고, agent-ask-not-write 와 같은 가치입니다. CLI 는 읽고, 보관하고, diff 하고, 결정적으로 다시 돌릴 수 있는 Python 산출물을 냅니다 — 비결정적 AI 가 한 번 쓰고, 결정적 스크립트가 영원히 실행합니다. 반면 MCP 는 결과를 실행 중인 프로세스에 담습니다: 그 힘은 씬을 볼 수 있다는 것이고(이는 a-boolean-hides-a-state-machine·rpc-view-not-consensus 의 살아있는 상태를 읽는 도구), 그 비용은 대화가 재현 가능한 산출물이 아니라는 것 — 다시 돌려도 씬이 똑같이 돌아오지 않을 수 있습니다. 그래서 CLI 는 무상태-재현가능이고 MCP 는 상태있음-라이브이며, 이것은 REST 대 세션, 배치 대 REPL 뒤의 그 교환과 같습니다 — 3D 도구에서 본 a-boolean-hides-a-state-machine 클러스터의 또 한 얼굴.

성숙한 워크플로는 양자택일이 아니라 CLI -> MCP -> CLI 이고, 추가 지시는 어떻게 확인하느냐입니다. CLI 로 생성·배치하고, MCP 로 대화형 다듬고, CLI 로 출력·검증합니다. 그리고 에이전트는 당신처럼 씬을 보지 못하므로 "무엇을 만들지"는 지시의 절반일 뿐이고 "어떻게 확인할지"가 나머지 절반입니다 — 비교 가능한 전후를 위한 고정 카메라 렌더, 또는 즉각성을 위한 라이브 뷰포트. 이는 simulate-before-sign 의 "가정 말고 검증"을 3D 에 적용한 것이고, 일반화됩니다 — 열쇠구멍으로 도구를 모는 모든 에이전트에게 안정적인 지시 형태는 작업 + 그 검증입니다. 관련: mcp-three-sides(프로토콜), constraint-was-the-product(같은 CLI 대 MCP 축, 다른 차원), agent-ask-not-write(검토 가능한 결정적 산출물), a-boolean-hides-a-state-machine(상태 대 무상태), simulate-before-sign(제작 + 검증).

동작 방식

같은 능력, 다른 작업 방식

결합 파이프라인

무엇을 만들지 뿐 아니라 어떻게 확인할지 지시

관련 카드

mcp-three-sides(아래의 프로토콜), constraint-was-the-product(같은 CLI 대 MCP 축, 인증/규모로 저울질), agent-ask-not-write(CLI 가 남기는 결정적 검토 가능 산출물), a-boolean-hides-a-state-machine(상태 대 무상태, 라이브 대 재현), simulate-before-sign("무엇을 만들지" + "어떻게 검증할지").

Jayverse에서의 위치

• gitboard: 에이전트가 만든 변경은 CLI→MCP→CLI 순서로 처리한다. Claude나 에이전트가 gitboard를 바꿀 때는 먼저 검토 가능하고 재실행 가능한 스크립트(CLI 쪽)를 생성하고, 대화형 도구 호출은 실시간 상태를 확인하고 조정하는 데만 쓰고, 다시 배치 단계를 돌려 출력하고 검증한다. 변경이 대화 안에만 남아 있게 두지 않는다.
• CI: CI는 재현 가능한 배치 쪽만 담당한다. 락파일 고정 빌드, 컨트랙트 배포, gitboard 데이터 작업은 CLI/배치 범주에 속한다 — 영속적이고 diff 가능하고 재실행 가능해야 한다. 대화형·상태 유지 도구 사용은 로컬 탐색용으로만 두고 CI 경로에서 완전히 배제한다.
• Number: 리서치 스크립트와 리서치 탐색을 저장소에서 분리한다. 지표 생성과 읽기 파이프라인은 CLI/배치 쪽(영속적, 재실행 가능)이고, 리서치 중 즉흥적인 데이터 탐색은 MCP식 상태 유지 쪽이다. 읽기 자료의 출처 스크립트가 항상 검토 가능한 산출물로 남도록 둘을 눈에 띄게 다른 위치에 둔다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑