프로그래밍에 관심 있는 리거를 위한 Maya C++ 플러그인 입문
C++ 문법, Maya API, DevKit, 스크립트, 플러그인을 서로 다른 층위로 분리해서 이해하도록 돕는 입문 가이드.
이 문서는 "리깅은 해봤고, 스크립트에도 관심이 생겼고, 이제는 Maya C++ 플러그인까지 가보고 싶다"는 사람을 위한 입문 가이드다.
많은 입문자가 C++ 플러그인을 배우려다 초반에 크게 막힌다.
보통은 "속도가 필요하니 C++를 배워야겠다"라고 생각하고 들어가지만, 막상 C++ 공부를 시작하면 언어 자체의 분량이 너무 크고, Maya 플러그인 개발과 직접 연결되는 느낌도 잘 오지 않는다.
이 답답함은 자연스럽다.
Maya C++ 플러그인 입문은 사실 하나의 공부가 아니라, 서로 다른 여러 범주를 분리해서 이해해야 하는 공부이기 때문이다.
핵심은 다음 한 문장으로 요약할 수 있다.
Maya C++ 플러그인 입문은 "C++를 배우는 일"이 아니라, "Maya가 어떤 구조로 동작하는지 이해하고 그 구조에 접근하는 API를 배우는 일"에 더 가깝다.
먼저 구분해야 하는 다섯 가지¶
입문자들이 가장 많이 섞어서 생각하는 개념은 아래 다섯 가지다.
| 범주 | 이것은 무엇인가 | 대표 예시 |
|---|---|---|
| 프로그래밍 언어 | 코드를 쓰는 문법 그 자체 | Python, C++, MEL |
| API | Maya 내부 데이터와 기능에 접근하기 위한 개발자용 인터페이스 | OpenMaya, MFn*, MPx*, MGlobal |
| SDK / DevKit | API를 실제로 빌드하고 링크할 수 있게 Autodesk가 제공하는 개발 키트 | Maya DevKit, 헤더, 라이브러리, 예제 |
| 스크립트 | Maya가 이미 알고 있는 기능과 명령을 조합해 실행하는 것 | Python 스크립트, MEL 스크립트 |
| 플러그인 | Maya에 원래 없던 명령, 노드, 드로우, 컨텍스트 같은 기능 자체를 등록하는 것 | MPxCommand, MPxNode, Viewport 2.0 확장 |
이 다섯 가지는 서로 연결되어 있지만, 같은 것이 아니다.
예를 들어 Python은 언어다.
Python API는 Maya가 Python으로 노드와 장면 데이터에 접근할 수 있게 열어둔 인터페이스다.
Python 스크립트는 그 인터페이스와 기존 명령을 호출하는 코드다.
Python 플러그인은 Maya가 로드하는 엔트리 포인트를 가진 확장 모듈이다.
C++도 마찬가지다.
C++는 언어이고, Maya C++ API는 그 언어로 Maya 내부 시스템에 접근하는 인터페이스이며, C++ 플러그인은 그 인터페이스를 이용해 Maya에 새로운 기능을 등록하는 결과물이다.
이 구분이 안 되면 "C++를 배웠는데 왜 플러그인을 못 만들지?"라는 상태에 빠지기 쉽다.
왜 C++를 배워도 Maya 플러그인이 바로 안 만들어지는가¶
이유는 간단하다.
C++ 문법을 아는 것과 Maya의 내부 구조를 이해하는 것은 다른 문제이기 때문이다.
리깅으로 비유해보자.
- Maya 사용법을 안다고 해서 곧바로 좋은 리거가 되는 것은 아니다.
- 오토리깅 툴을 쓸 줄 안다고 해서 리그 구조를 설계할 수 있는 것도 아니다.
- 리깅이라는 개념 자체를 이해해야 실제로 설계와 디버깅이 가능하다.
Maya 플러그인도 같다.
- C++ 문법을 안다고 해서 Maya의 DG/DAG를 자동으로 이해하게 되지는 않는다.
- Maya API 클래스 이름을 외운다고 해서 노드 평가와 dirty propagation을 이해하게 되지는 않는다.
- 빌드에 성공했다고 해서 Maya 내부 시스템과 잘 맞는 플러그인이 되는 것도 아니다.
그래서 C++ 입문보다 더 먼저 중요한 질문은 이것이다.
- Maya는 어떤 데이터를 어떤 구조로 관리하는가?
- 어떤 것은 스크립트로 충분하고, 어떤 것은 플러그인으로 가야 하는가?
- 내가 만들고 싶은 기능은 Maya의 기존 명령 조합으로 가능한가, 아니면 새로운 노드/커맨드/드로우가 필요한가?
스크립트와 플러그인은 어떻게 구분해야 할까¶
입문자가 제일 먼저 정리해야 할 부분이 바로 이것이다.
스크립트¶
스크립트는 Maya가 이미 제공하고 있는 명령, UI, 노드, 데이터 접근 방식을 호출하고 조합하는 쪽에 가깝다.
보통 이런 상황이면 스크립트 쪽이다.
- 반복 작업 자동화
- 버튼을 눌렀을 때 기존 명령을 묶어서 실행
- 파일 이름 규칙 검사
- 리그 생성 과정을 단계별로 호출
- 씬 정리, 검증, 배치 처리
즉, 이미 Maya가 이해하는 기능을 잘 호출하고 연결하는 것이 스크립트의 중심이다.
플러그인¶
플러그인은 Maya에 원래 없던 기능을 Maya 내부 시스템에 등록하는 쪽에 가깝다.
보통 이런 상황이면 플러그인 검토가 필요하다.
- 새로운 커맨드를 만들고 싶다
- 새로운 DG 노드 타입이 필요하다
- 새로운 DAG 형태나 커스텀 드로우가 필요하다
- undo/redo, selection, evaluation, viewport, manipulator 같은 Maya 내부 흐름과 직접 붙어야 한다
- 실시간 반응이나 대량 연산에서 Python만으로는 성능이 부족하다
즉, Maya가 원래 모르던 규칙과 기능을 Maya가 이해하는 방식으로 등록하는 것이 플러그인의 중심이다.
실무에서는 둘을 섞는다¶
현실의 툴은 대개 하나만 쓰지 않는다.
- 무거운 계산이나 내부 통합은 C++ 플러그인으로 만든다.
- 사용자 호출, 파이프라인 연결, UI, 실행 진입점은 Python이나 MEL로 감싼다.
- 최종 배포물은 사용자에게 "하나의 툴"처럼 보이지만, 내부는 스크립트와 플러그인이 함께 동작한다.
이 점을 이해하면 "스크립트냐 플러그인이냐"를 이분법으로 보지 않게 된다.
대부분의 실전 툴은 둘 중 하나가 아니라 둘의 조합이다.
Maya API는 무엇인가¶
API는 Application Programming Interface의 약자다.
쉽게 말하면, Maya가 개발자에게 열어둔 공식 인터페이스다.
이 인터페이스를 통해 개발자는 다음 같은 것에 접근한다.
- 현재 선택 상태
- 노드 타입과 노드 객체
- 속성과 플러그 연결
- DG/DAG 구조
- 메시, 커브, 트랜스폼 같은 장면 데이터
- 뷰포트 드로우와 선택 처리
- 커스텀 노드, 커맨드, 컨텍스트 등록
스크립트 에디터에서도 Python API를 통해 Maya 내부 데이터에 접근할 수 있다.
하지만 Maya 내부에서 새 타입을 등록하거나, 평가 시스템에 참여하거나, 플러그인으로 빌드해서 배포 가능한 형태로 묶으려면 API를 더 깊게 이해해야 한다.
Autodesk 공식 문서도 Maya API를 "Maya 내부 모델 객체와 장면 그래프에 접근하는 개발자용 계층"으로 설명한다.
읽기 시작점은 Maya API Basics 와 MObject and function sets 가 가장 좋다.
SDK와 Maya DevKit은 무엇인가¶
SDK는 Software Development Kit의 약자다.
Maya 맥락에서는 보통 Maya DevKit을 뜻한다고 생각해도 큰 무리는 없다.
DevKit에는 대체로 다음이 포함된다.
- C++ 헤더 파일
- 빌드에 필요한 라이브러리
- CMake 설정 예제
- 샘플 플러그인
- API 가이드와 레퍼런스
즉, API가 "개발자용 통로"라면, DevKit은 "그 통로를 실제 코드로 연결하고 빌드하기 위한 공구 상자"에 가깝다.
공식 시작점은 Maya Developer Help Center 와 Maya API | Autodesk Platform Services 다.
Windows 기준 설정은 Setting up the Maya devkit on Windows 문서가 가장 직접적이다.
Python과 C++의 차이는 어떻게 이해하면 좋을까¶
입문 단계에서는 둘을 "무조건 하나를 선택해야 하는 경쟁 언어"로 보기보다, 용도가 다른 도구로 보는 편이 정확하다.
Python의 장점¶
- 문법이 빠르게 읽히고 쓰기 쉽다
- Maya 스크립트 에디터에서 즉시 실험하기 좋다
- 프로토타이핑 속도가 빠르다
- 파이프라인 툴, UI, 파일 처리, 자동화와 궁합이 좋다
- Maya Python API 2.0은 입문자가 접근하기 비교적 편하다
C++의 장점¶
- 성능 병목 구간을 더 직접적으로 다룰 수 있다
- Maya 내부 시스템과 더 깊게 붙는 확장이 가능하다
- 커스텀 노드, 뷰포트, 매니퓰레이터, 저수준 연산 쪽에서 강하다
- 대량 데이터 처리나 실시간 상호작용에서 유리한 경우가 많다
중요한 현실 감각¶
대부분의 팀은 처음부터 모든 것을 C++로 만들지 않는다.
보통은 이렇게 간다.
- Python으로 프로토타입을 만든다.
- 병목이 실제로 관측되는지 확인한다.
- 정말 필요한 부분만 C++로 내린다.
- 다시 Python에서 그 기능을 호출하도록 연결한다.
이 흐름이 흔한 이유는, C++가 어렵기 때문만이 아니라 문제를 가장 싼 비용으로 검증하는 순서이기 때문이다.
왜 Maya C++ API를 쓰는가¶
속도 때문이다, 라는 답도 맞다.
하지만 그것만으로는 부족하다.
C++ API를 쓰는 더 정확한 이유는 다음과 같다.
- 성능이 중요한 기능을 Maya 내부 흐름에 가깝게 붙이고 싶어서
- 새로운 노드, 커맨드, 드로우, 컨텍스트처럼 "기능 자체"를 등록하고 싶어서
- DG/DAG, evaluation, viewport, undo/redo와 더 깊게 연결하고 싶어서
- Maya가 내부적으로 C++ 중심 구조를 가지고 있기 때문에 더 직접적인 확장이 필요한 경우가 있어서
특히 리거 관점에서는 이런 지점에서 의미가 커진다.
- 커스텀 솔버
- 고비용 포즈 계산
- 커스텀 노드 기반의 데이터 흐름 제어
- 뷰포트 상호작용 도구
- 커스텀 manipulator나 draw override
Viewport 쪽이 목표라면 Overview of the Viewport 2.0 API 와 Maya Viewport 2.0 API Guide 를 초기에 같이 보는 편이 좋다.
반대로 Python API는 왜 여전히 중요한가¶
C++를 배운 뒤에도 Python API의 가치는 사라지지 않는다.
오히려 입문자에게는 Python API가 Maya 구조를 이해하는 가장 좋은 실험실이 된다.
- 선택된 노드를 가져와 보기
- DAG를 순회해 보기
- 속성과 플러그 연결을 조사해 보기
- 간단한 노드 생성 실험을 해 보기
- 스크립트 에디터에서 바로 결과를 확인해 보기
이 과정이 중요한 이유는, Maya API 개념 자체는 언어보다 먼저 존재하기 때문이다.
예를 들어 다음 개념은 Python으로 먼저 배워도 된다.
MObjectMSelectionListMFn*function set- 노드와 속성
- DG와 DAG
- dirty / evaluation
즉, API 개념은 언어와 독립적이고, 문법은 그 개념을 표현하는 표면이라고 생각하면 된다.
리거에게 특히 중요한 오해 정리¶
오해 1. "스크립트 에디터에서 함수 정의가 되니까 플러그인과 큰 차이 없는 것 아닌가?"¶
아니다.
스크립트 에디터에서 함수를 정의할 수 있다는 것은 "코드를 실행할 수 있다"는 뜻이지, 그 기능이 Maya 내부 시스템에 정식 타입으로 등록되었다는 뜻은 아니다.
플러그인으로 가야 하는 순간은 보통 이런 지점이다.
- 새 노드 타입이 필요하다
- Maya undo/redo와 정식으로 맞물려야 한다
- DG/DAG 평가 흐름에 참여해야 한다
- 뷰포트 선택/드로우/매니퓰레이터를 확장해야 한다
오해 2. "C++만 열심히 공부하면 Maya 플러그인은 자연스럽게 된다"¶
아니다.
입문 단계에서 더 중요한 것은 아래 순서다.
- Maya 장면 구조를 이해한다.
- Maya API가 어떤 층위를 열어주는지 이해한다.
- 그다음에 그 API를 Python으로 먼저 실험한다.
- 마지막에 C++로 옮길 필요가 있는지 판단한다.
오해 3. "성능이 필요하면 무조건 전부 C++로 가야 한다"¶
아니다.
병목은 일부 구간에만 존재하는 경우가 많다.
전체 도구를 모두 C++로 재작성하는 것보다, 병목 구간만 C++ 플러그인으로 내리고 나머지는 Python으로 유지하는 편이 더 현실적인 경우가 많다.
입문자에게 추천하는 공부 순서¶
이 문서가 가장 강조하고 싶은 부분이다.
1. 먼저 Maya를 구조로 이해한다¶
처음에는 문법보다 구조가 더 중요하다.
- DG와 DAG가 무엇인지
- 노드와 속성이 어떻게 연결되는지
- dirty propagation이 왜 생기는지
- Maya가 데이터를 언제 계산하는지
- transform, shape, dependency node가 어떻게 다른지
이 단계에서 읽기 좋은 공식 문서:
2. Python API로 Maya 객체를 만져본다¶
스크립트 에디터에서 아주 작은 실험을 반복하는 것이 좋다.
- 현재 선택 가져오기
- 노드 타입 확인하기
- DAG 순회하기
- 속성 읽고 쓰기
- 간단한 장면 조작 만들기
이 단계의 목적은 "툴 만들기"가 아니라 "Maya가 데이터를 어떻게 보여주는지 익숙해지기"다.
3. 첫 C++ 플러그인은 명령 플러그인으로 시작한다¶
처음부터 커스텀 노드나 뷰포트 드로우로 가면 너무 많은 개념이 한 번에 겹친다.
추천 시작점:
- A C++ Hello World example
- A C++ Hello World example explained
- Command plug-in basic classes and functions
여기서 익혀야 하는 핵심은 문법보다 아래다.
initializePlugin()uninitializePlugin()MFnPluginMPxCommanddoIt(),redoIt(),undoIt()- Maya가 플러그인을 로드하고 언로드하는 방식
4. 그다음에 커스텀 노드로 간다¶
명령 플러그인이 "한 번 실행되는 기능"에 가깝다면, 노드 플러그인은 "Maya 장면 구조 안에 들어가는 기능"에 가깝다.
여기서부터 Maya스럽다는 느낌이 훨씬 강해진다.
MPxNode- 속성 선언
MDataBlock,MDataHandlecompute()- dirty / evaluation
관련 시작점:
5. Viewport, Manipulator, Context는 더 뒤로 미룬다¶
이 영역은 리거에게 매력적이지만, 입문 단계에서는 훨씬 어렵다.
- Viewport 2.0
- custom draw override
- manipulator
- custom context
- selection 처리
관련 문서:
이 주제는 노드와 커맨드를 어느 정도 다룬 뒤에 들어가는 것이 낫다.
Windows에서 C++ 플러그인 입문자가 가장 먼저 해야 할 일¶
환경 세팅을 너무 늦게 보면 안 된다.
플러그인 개발은 "코드 작성"과 "빌드 환경 구성"이 처음부터 같이 간다.
기본 체크리스트는 다음과 같다.
- Maya 버전을 먼저 고정한다.
- 그 버전에 맞는 DevKit을 받는다.
- Visual Studio와 CMake를 맞춘다.
MAYA_LOCATION,DEVKIT_LOCATION,MAYA_PLUG_IN_PATH같은 경로를 정리한다.- 가장 작은 예제부터 빌드한다.
- Maya에서 직접 로드/언로드를 반복한다.
공식 문서:
특히 플러그인은 빌드한 Maya 버전과 로드하는 Maya 버전이 맞아야 한다는 점을 초기에 꼭 체감해두는 것이 좋다.
이 문서를 한 문장으로 다시 요약하면¶
리거가 Maya C++ 플러그인에 입문할 때 가장 먼저 해야 할 일은 C++ 문법을 끝없이 파는 것이 아니라, 아래 개념을 분리해서 이해하는 것이다.
- 스크립트와 플러그인은 다르다
- 언어와 API는 다르다
- API와 SDK는 다르다
- Maya 사용법과 Maya 아키텍처 이해는 다르다
그리고 실전의 흐름은 보통 이렇다.
- Maya 구조를 이해한다
- Python API로 실험한다
- 가장 작은 C++ 명령 플러그인을 만든다
- 커스텀 노드로 확장한다
- 정말 필요할 때 Viewport와 Manipulator로 간다
결국 중요한 것은 "C++를 배웠다"가 아니라, Maya가 어떤 시스템이고, 내가 만들고 싶은 기능이 그 시스템 어디에 걸쳐 있는지 설명할 수 있게 되는 것이다.