대부분의 AI 에이전트들은 IDE 내부에서 놀라울 정도로 높은 능력을 갖추고 있습니다. 이들은 저장소(repository)를 이해하고, 코드를 수정하며, 테스트를 실행하고, 로그를 검사하여 소프트웨어 배포에 도움을 줄 수 있습니다.

하지만 디지털 제작 과정의 상당 부분은 IDE 이후에서 일어납니다.

게임, 영화, 애니메이션, 광고 또는 버추얼 프로덕션 파이프라인은 Maya, Blender, Houdini, ZBrush, Substance 3D, Unreal Engine, Unity, Nuke, Photoshop, Wwise, OpenUSD, 제작 추적 시스템(production tracking systems), 프로파일러(profilers) 및 내부 스튜디오 도구 등을 거치며 진행될 수 있습니다.

이러한 애플리케이션들은 이미 수년간의 제작 지식을 담고 있습니다. 부족한 부분은 에이전트가 새로운 통합을 만들거나 매번 취약한 스크립트를 재생성할 필요 없이, 그 지식을 발견하고 작동시킬 수 있는 일관된 방식입니다.

그래서 저희는 **DCC-MCP**를 구축하고 있습니다.

DCC-MCP란 무엇인가?

DCC-MCP는 Digital Content Creation Model Context Protocol의 약자입니다.

이것은 AI 에이전트, 명령줄 자동화(command-line automation), CI 작업(CI jobs), 그리고 스튜디오 애플리케이션을 공유된 계약 세트를 통해 실제 크리에이티브 소프트웨어에 연결하는 개방형 인프라입니다:

• MCP 및 REST 진입점(entry points)
• 머신 레벨 게이트웨이(Gateway)
• 타입 지정 도구와 구조화된 결과물(typed tools and structured results)
• 애플리케이션별 어댑터(application-specific adapters)
• 재사용 가능하고 버전 관리되는 스킬(reusable, versioned Skills)
• 기능 발견 및 마켓플레이스(capability discovery and a Marketplace)
• 라우팅, 정책 검사, 진단, 로그, 트레이스 및 요청 ID

Agent / CLI / CI / Studio application
                 │
            MCP or REST
...

동일한 타입의 기능(typed capability)은 AI 에이전트, CLI를 사용하는 개발자, CI 파이프라인, 또는 REST를 통한 내부 애플리케이션에 의해 호출될 수 있습니다.

왜 단순히 모델에게 스크립트를 작성하라고 요청하지 않을까요?

에이전트에게 mayapy, hython, Blender Python, MEL 또는 MaxScript 스니펫(snippet)을 생성하고 실행하도록 요청하는 것은 탐색 단계에서는 유용합니다. 또한 인상적인 데모를 만들어낼 수도 있습니다.

하지만 반복적인 프로덕션(production) 작업에서는 몇 가지 문제점이 드러납니다.

모델이 워크플로(workflow)를 계속해서 다시 구축합니다

모델이 매 턴마다 작업 로직을 다시 생성한다면, 결과는 현재의 모델, 프롬프트(prompt), 컨텍스트 윈도우(context window), 그리고 생성된 코드에 따라 달라집니다. 대화가 종료되면 그 지식은 사라집니다.

프로덕션 지식은 버전 관리(versioned)가 되어야 하고, 테스트 가능하며, 검토 가능하고, 재사용 가능해야 합니다.

DCC 애플리케이션은 호스트별 실행 규칙을 가지고 있습니다

많은 크리에이티브 애플리케이션은 작업이 메인 스레드(main thread)에서 실행될 것을 요구합니다. 이들은 시작 상태(startup states), 모달 대화 상자(modal dialogs), 활성 문서(active documents), 씬 소유권(scene ownership), 플러그인 라이프사이클(plug-in lifecycles), 그리고 특정 컨텍스트에서만 안전한 API를 가지고 있습니다.

프로세스가 성공적으로 종료되었다고 해서 의도한 씬(scene)이 올바르게 변경되었다는 것을 증명하지는 않습니다.

여러 애플리케이션이 열려 있으면 대상이 모호해집니다

워크스테이션에는 여러 개의 Maya 씬, Blender 프로세스, Unreal 프로젝트 또는 Photoshop 문서가 동시에 열려 있을 수 있습니다. 에이전트는 올바른 인스턴스(instance)를 식별해야 하며, 작업 전반에 걸쳐 해당 컨텍스트를 유지해야 합니다.

크리에이티브 작업은 종종 장시간 실행됩니다

시뮬레이션(simulation), 베이킹(baking), 렌더링(rendering), 임포트(importing), 리메싱(remeshing), 퍼블리싱(publishing), 에셋 생성(asset generation) 등은 진행 상황 보고(progress reporting), 취소(cancellation), 체크포인트(checkpoints), 재시도(retries), 그리고 아티팩트 전달(artifact hand-off)이 필요할 수 있습니다.

단순한 요청/응답(request/response) 함수만으로는 항상 충분하지 않습니다.

실패에는 증거가 필요합니다

무언가 실패했을 때, 팀에는 단순한 에러 메시지 이상의 것이 필요합니다. 입력된 타입(typed input), 선택된 인스턴스(selected instance), 요청 ID(request ID), 로그(logs), 트레이스(traces), 관찰된 상태(observed state), 그리고 문제가 Core, 어댑터(adapter), Skill, 또는 호스트 애플리케이션(host application) 중 어디에 속하는지에 대한 명확한 표시가 필요합니다.

DCC-MCP는 이러한 반복적인 엔지니어링 과제들을 모든 어댑터와 생성된 모든 스크립트가 매번 다시 해결하도록 강요하는 대신, 공유 인프라(shared infrastructure)로 이동시킵니다.

더 자세한 설계 근거는 Why DCC-MCP exists에서 읽어보실 수 있습니다.

거대한 도구 목록 대신 작은 에이전트 인터페이스를 사용

크리에이티브 애플리케이션은 수백 또는 수천 개의 작업을 노출할 수 있습니다. 모든 스키마(schema)를 에이전트에게 한꺼번에 보내는 것은 컨텍스트(context)를 낭비하며 도구 선택(tool selection)의 신뢰성을 떨어뜨립니다.

DCC-MCP는 점진적 발견(progressive discovery) 방식을 사용합니다:

list → search → load/describe → call

MCP 레이어에서 게이트웨이(Gateway)는 다음과 같은 표준 작업(canonical operations)만을 포함하여 의도적으로 작게 유지될 수 있습니다:

search
load_skill
describe
...

에이전트는 작업에 필요한 기능을 검색하고, 관련 있는 Skill만 로드하거나 검사하며, 인자(arguments)를 검증한 다음 선택된 도구를 호출합니다.

이것이 중요한 이유는 목표가 모델에게 전체 DCC API를 암기시키는 것이 아니기 때문입니다. 목표는 모델이 필요한 순간에 가장 작고 정확한 프로덕션 기능(production capability)을 찾을 수 있도록 돕는 것입니다.

Skill은 워크플로우 지식을 보존합니다

연결성(Connectivity)만으로는 충분하지 않습니다.

스튜디오 워크플로우에는 다음과 같은 관례(conventions)가 포함됩니다:

• 명명 규칙 및 디렉토리 규칙 (naming and directory rules)
• 씬 및 문서 체크 (scene and document checks)
• 에셋 준비 (asset preparation)
• 내보내기 설정 (export settings)
• 퍼블리시 게이트 (publish gates)
• 검증 기준 (validation criteria)
• 리뷰 핸드오프 (review hand-offs)
• 복구 및 정리 단계 (recovery and cleanup steps)

DCC-MCP에서 이러한 지식은 Skill로 패키징될 수 있습니다. 즉, 검증된 입력값, 안전 메타데이터(safety metadata), 예시, 그리고 구현 스크립트를 갖춘 버전 관리되고 타입이 지정된 배포 가능한 기능입니다.

이를 통해 유용한 소유권 경계(ownership boundary)가 생성됩니다:

• **Core 및 어댑터 (adapters)**는 연결성(connectivity), 호스트 안전성(host safety), 라우팅(routing), 라이프사이클(lifecycle), 정책(policy) 및 관찰성(observability)을 소유합니다.
• **TDs, TAs 및 파이프라인 팀 (pipeline teams)**은 프로젝트별 프로덕션 로직을 소유합니다.
• **에이전트 (Agents)**는 전체 워크플로우를 다시 발명하는 대신, 문서화된 기능(capability)을 선택하고 검증된 인자(arguments)를 제공합니다.

스킬(Skills)은 Python, MEL, MaxScript, Bash, PowerShell 및 기타 호스트에 적합한 구현 방식을 사용할 수 있습니다. 지원되는 워크플로우의 경우, SKILL.md와 스크립트를 통해 별도의 Python 등록 글루(glue) 레이어를 작성하지 않고도 기능을 노출할 수 있습니다.

DCC-MCP Marketplace는 모든 확장 기능을 새로운 런타임(runtime)으로 만들지 않고도, 집중된 스킬(Skills), 에셋 제공자(asset providers), 스튜디오 통합(studio integrations) 및 공유 인프라를 배포하도록 설계되었습니다.

크리에이티브 애플리케이션 전반을 아우르는 하나의 생태계

이 글을 쓰는 시점을 기준으로, 공식 사이트에는 **20개의 출시된 어댑터 식별자(adapter identifiers)**와 공개 Wwise 어댑터 및 쇼케이스가 나열되어 있습니다. 더 넓은 프로젝트 디렉토리에는 50개 이상의 공개 프로젝트가 포함되어 있습니다.

생태계는 다음과 같은 영역을 다룹니다:

3D 및 DCC 애플리케이션

Maya, Blender, Houdini, 3ds Max, ZBrush, Marmoset Toolbag, MotionBuilder, Katana, Substance 3D Designer 및 Substance 3D Painter.

게임 엔진 및 저작 도구 (authoring tools)

Unreal Engine, Unity, Godot, Wwise, Tiled 및 기타 콘텐츠 저작 도구.

2D, 합성 (compositing) 및 편집

Photoshop, After Effects, Premiere Pro, Nuke, GIMP, Krita 및 관련 크리에이티브 워크플로우.

파이프라인, 인터체인지 (interchange) 및 진단 (diagnostics)

OpenUSD, MaterialX, Autodesk Flow Production Tracking, 퍼블리싱 워크플로우(publishing workflows), 텍스처 파이프라인(texture pipelines), RenderDoc, Tracy, 캐시 검사(cache inspection) 및 내부 독립형 서비스(standalone services).

생성 및 에셋 제공자

Hunyuan 3D, Tripo 3D, 이미지 생성, 지리 공간 데이터(geospatial data), Poly Haven, ambientCG, Kenney, NASA 3D, Smithsonian 3D, Objaverse 및 출처(provenance)와 라이선스 정보를 보존할 수 있는 기타 소스들.

어댑터가 진화함에 따라 프로젝트 가용성이 변경될 수 있으므로, dcc-mcp-cli dcc-types와 ecosystem directory가 현재의 신뢰할 수 있는 최신 정보원(source of truth)으로 유지됩니다.

에이전트가 실제로 이를 통해 무엇을 할 수 있을까요?

DCC-MCP Showcase에는 다음과 같은 워크플로우(workflows)에 대한 프롬프트(prompts), 출력물, 소스 리포지토리(source repositories) 및 검증 기록이 포함되어 있습니다:

• Blender에서 절차적(procedural) 나선형 은하 구축
• Houdini에서 편집 가능한 에너지 포털 생성
• Marmoset Toolbag에서 CC0 PBR 에셋 임포트 및 검증
• Wwise에서 인터랙티브 오디오 생성 및 정리
• Hunyuan 3D를 통해 3D 에셋을 생성하고 선택된 DCC로 임포트
• 라이선스를 보유한 에셋 제공업체로부터 플레이 가능한 장면(scene) 조립
• ZBrush에서 500만 개의 면(face)을 가진 모델을 처리하고 Maya에서 리메쉬(remeshed)된 결과 확인
• DCC 내보내기(exports), OpenUSD, 렌더 팜(render farms) 및 제작 추적(production tracking)을 연결하는 퍼블리시 매니페스트(publish manifests) 생성

중요한 점은 단순히 이미지나 장면이 생성되었다는 것만이 아닙니다. 제작 지향적인 결과물은 무엇이 호출되었는지, 어떤 인스턴스(instance)가 대상이었는지, 어떤 파일이 생성되었는지, 어떤 체크(checks)를 통과했는지, 그리고 무언가 실패했을 때 어떤 증거가 남는지도 보고해야 합니다.

네이티브 API 우선, UI 자동화는 필요한 경우에만

일부 크리에이티브 애플리케이션은 강력한 Python, C++, HTTP, command-port, UXP, WAAPI 또는 벤더(vendor)별 전용 API를 제공합니다. 반면, 일부는 부분적인 자동화 인터페이스만을 제공하기도 합니다.

DCC-MCP는 네이티브(native) 및 타입이 지정된(typed) API가 존재하는 경우 이를 우선적으로 사용합니다.

UI 자동화는 사용 가능한 프로그래밍 인터페이스가 없는 작업에 대해 제한된 범위 내의 폴백(fallback) 방식으로 취급됩니다. 의도된 패턴은 에이전트에게 제한 없는 데스크톱 제어권을 부여하고 올바른 것을 클릭하기를 바라는 방식보다는, 다음과 같은 방식에 가깝습니다:

스냅샷(snapshot) → 찾기(find) → 실행(act) → 대기(wait) → 검증(verify)

이러한 구분은 안전성, 재현성(reproducibility) 및 디버깅(debugging) 측면에서 매우 중요합니다.

워크플로우 살펴보기

유지 관리되는 공개 Agent Skill에는 현재의 운영 절차와 안전 규칙이 포함되어 있습니다. 전형적인 로컬 워크플로우는 다음과 같습니다:

# OpenClaw에 유지 관리되는 운영 Skill을 설치합니다.
openclaw skills install @loonghao/dcc-mcp

...

도구(tool) 이름을 추측하거나 백엔드 카탈로그 전체를 맹목적으로 로드하지 마세요. 먼저 검색하고 시스템이 반환하는 next_step을 따르십시오.

설치, 지원되는 에이전트 호스트(agent hosts), 동의 규칙 및 진단에 대해서는 현재의 Agent guide를 참조하십시오.

AI 에이전트 없이도 유용합니다

MCP가 에이전트 진입점(entry point)을 제공하지만, DCC-MCP는 대화형 사용에만 국한되지 않습니다.

동일한 기능을 다음과 같은 방식으로 사용할 수 있습니다:

• 아티스트, TD(Technical Director), 개발자 및 운영자를 위한 dcc-mcp-cli
• 내부 애플리케이션 및 스마트 워크플로우 캔버스(workflow canvases)에서의 REST
• 생성된 OpenAPI 클라이언트
• CI 작업 및 검증 파이프라인(validation pipelines)
• 커스텀 스튜디오 오케스트레이션(orchestration)

기존의 OpenAPI 서비스는 일반적인 REST 서비스로 유지하면서 에이전트가 접근 가능한 도구로 마운트(mount)할 수도 있습니다. 팀은 모든 내부 시스템을 AI 중심으로 재구축할 필요가 없습니다.

어댑터, 서비스 또는 Skill 구축하기

DCC-MCP는 네 가지 일반적인 개발 경로를 분리합니다:

1. 애플리케이션 어댑터(adapter)를 구축하거나 개선하여 크리에이티브 호스트(creative host)를 연결합니다.
2. 내부 API, CLI, 에셋 데이터베이스, 렌더 팜(render farm) 또는 리뷰 시스템을 프라이빗 독립형 서비스로 **노출(expose)**합니다.
3. 기존 어댑터나 서비스에 특정 워크플로우를 Skill로 추가합니다.
4. Core에서 게이트웨이(Gateway) 라우팅, CLI, 프로토콜 지원, 정책, 진단 또는 관찰성(observability)과 같은 공유 동작을 개선합니다.

프라이빗 스튜디오 서비스는 공개 GitHub 저장소나 공개 카탈로그 항목이 필요하지 않습니다. 기존의 보안 및 배포 경계 내에서 동일한 런타임(runtime)과 타입화된 계약(typed contracts)을 재사용할 수 있습니다.

Developer guide에는 공개 어댑터, 프라이빗 서비스, Skill, 검증, 로컬 MCP Inspector 테스트 및 프로덕션 배포를 위한 스타터 경로가 포함되어 있습니다.

정직한 경계

DCC-MCP는 모든 크리에이티브 애플리케이션을 동일하게 만드는 것을 목표로 하지 않습니다.

• UI 자동화 (UI automation)보다는 네이티브 API (Native APIs)와 검증된 스킬 (Skills)을 사용하는 것이 권장됩니다.
• 호스트별 호환성 (Host-specific compatibility)은 각 어댑터 (adapter)의 책임으로 남습니다.
• 애플리케이션이 트랜잭션 모델 (transaction model)을 제공하지 않을 경우, 안전한 롤백 (Safe rollback)을 보장할 수 없습니다.
• 인프라 (Infrastructure)는 반복 가능한 작업을 표준화할 수 있지만, 아트 디렉션 (art direction), 구도 (composition), 타이밍 (timing), 취향 (taste) 또는 인간의 판단 (human judgment)을 대체하지는 않습니다.
• 이 프로젝트는 에이전트 (agents)를 위한 인프라를 제공할 뿐, 팀이 어떤 모델 (model)이나 에이전트 (agent)를 사용해야 하는지 규정하지 않습니다.