리깅 파이썬: 실행 취소와 명령 패턴 — DCC에서 undo가 되게 만들기

3D 애니메이션 툴을 만들다 보면 아티스트한테 제일 많이 듣는 말이 있다. "이거 되돌리기가 안 되는데요?"

버튼 하나 눌렀는데 뼈대가 이상하게 움직였다. Ctrl+Z를 눌렀다. 그런데 원래대로 안 돌아온다. 아니면 더 나쁘게, 엉뚱한 게 되돌아간다. 아티스트는 그날 작업한 걸 통째로 날린다.

이 문제를 푸는 방법이 명령 패턴(Command Pattern)이다. 이름은 어렵지만 생각은 아주 단순하다.

영수증을 남긴다는 생각

식당에서 밥을 먹는다고 하자. 주문을 말로만 하면 어떻게 될까.

"저 김치찌개 시켰는데요." "네? 언제요?" 아무도 기억을 못 한다. 취소도 못 한다.

그래서 식당은 주문서를 쓴다. 종이 한 장에 이렇게 적힌다.

• 무엇을: 김치찌개
• 몇 개: 2인분
• 누구 테이블: 3번

이 종이 한 장이면 나중에 취소도 되고, 다시 시키기도 된다. 종이가 남아 있으니까.

명령 패턴이 바로 이거다. "뭔가를 한다"를 종이 한 장에 적어서 남기는 것. 코드에서는 그 종이를 "명령 객체(Command)"라고 부른다.

그냥 하는 것과 적어두고 하는 것

보통 코드는 이렇게 생겼다.

손목뼈.위치 = (10, 5, 0)

바로 바꿔버린다. 빠르다. 그런데 끝이다. 뭐가 바뀌었는지 아무도 모른다. 되돌릴 수가 없다.

명령 패턴은 한 단계를 더 둔다.

주문서 = 위치바꾸기(손목뼈, 이전위치=(0,0,0), 새위치=(10,5,0))
주문서.실행()

이제 이 주문서에는 돌아갈 곳이 적혀 있다. 이전 위치 (0,0,0). Ctrl+Z를 누르면 주문서를 꺼내서 거꾸로 실행하면 된다.

교과서에 나오는 그림

이 생각은 소프트웨어 세계에서 꽤 오래된 정석이다. 아래는 그걸 그림으로 정리한 것이다.

복잡해 보이지만 등장인물은 넷뿐이다.

• 부르는 쪽 — 버튼, 메뉴, 단축키. "실행해" 라고만 말한다.
• 주문서 — 무엇을 어떻게 할지 적힌 물건.
• 실제로 일하는 쪽 — 뼈대, 컨트롤러 같은 진짜 대상.
• 주문서를 모아두는 곳 — 실행한 순서대로 쌓아두는 통. 되돌리기는 여기서 꺼낸다.

여기서 중요한 건, 버튼은 자기가 뭘 하는지 몰라도 된다는 점이다. 버튼은 그냥 "이 주문서를 실행해" 만 안다. 그래서 같은 버튼에 다른 주문서를 끼워 넣을 수도 있다.

쌓아두는 통 — 왜 순서가 중요한가

주문서는 그냥 모아두면 안 된다. 쌓은 순서대로 꺼내야 한다.

접시를 생각하면 쉽다. 접시를 위로 쌓았으면 꺼낼 때도 맨 위부터 꺼낸다. 밑에서 빼면 다 무너진다.

되돌리기도 똑같다. 마지막에 한 일을 제일 먼저 되돌린다. 순서를 지키지 않으면 이런 일이 생긴다.

1. 뼈 이름을 바꿨다
2. 그 뼈에 컨트롤러를 붙였다

여기서 1번을 먼저 되돌리면? 이름이 바뀌어서 2번이 붙였던 컨트롤러가 자기 뼈를 못 찾는다. 씬이 깨진다.

리깅 툴에서 진짜로 조심할 것

여기부터가 DCC 툴(마야, 블렌더 같은 것)에서 실제로 사람을 울리는 부분이다.

하나로 묶기

버튼 하나를 눌렀는데 안에서 스무 가지 일이 벌어진다고 하자. 뼈 만들고, 이름 붙이고, 붙이고, 색칠하고.

이걸 그대로 두면 아티스트가 Ctrl+Z를 스무 번 눌러야 한다. 그러다 열두 번쯤에서 손을 놓으면? 반쯤 만들어진 이상한 리그가 남는다.

그래서 스무 개 주문서를 봉투 하나에 담는다. 봉투 자체가 다시 하나의 주문서가 된다. Ctrl+Z 한 번에 스무 개가 통째로 되돌아간다. 마야에서는 이걸 "청크(chunk)"라고 부른다.

안 적히는 일이 있다

제일 골치 아픈 함정이다. 어떤 작업은 주문서에 아예 안 적힌다.

파일을 쓰는 것. 밖에 있는 프로그램을 부르는 것. 툴 자체의 설정을 바꾸는 것. 이런 건 씬 안에서 벌어지는 일이 아니라서 툴의 되돌리기 통이 알지 못한다.

이걸 모르고 만들면, Ctrl+Z를 눌렀을 때 절반만 되돌아간다. 뼈는 사라졌는데 파일은 남아 있다. 이게 제일 찾기 어려운 버그다.

되돌리기 통이 무겁다

주문서를 남기려면 "바꾸기 전 값"을 들고 있어야 한다. 뼈 위치 하나면 작다. 그런데 메시 전체를 통째로 저장하면? 클릭 한 번에 수백 메가가 쌓인다.

그래서 통 크기에 한계를 둔다. 오래된 주문서는 버린다.

쓸 때 좋은 점

• 아티스트가 겁 없이 시도한다. 되돌릴 수 있다는 걸 알면 사람은 과감해진다. 이게 제일 큰 이득이다.
• 같은 주문서를 다시 쓴다. 캐릭터 A에 쓴 주문서 묶음을 그대로 B에 실행하면 자동화가 된다.
• 버그를 잡기 쉽다. "어떤 순서로 뭘 했는지"가 통 안에 남아 있다. 재현이 쉽다.
• 버튼과 기능이 분리된다. 메뉴에서든 단축키에서든 스크립트에서든, 같은 주문서를 부르면 똑같이 동작한다.

쓸 때 힘든 점

• 코드가 눈에 띄게 길어진다. 한 줄이면 끝날 일을 클래스 하나로 감싸야 한다. 기능 열 개면 클래스 열 개다. 처음엔 "이걸 왜 이렇게까지" 싶다.
• "되돌리기"를 직접 짜야 한다. 이게 진짜 일이다. 실행은 쉬운데, 정확히 원래대로 돌려놓는 코드는 매번 다시 생각해야 한다. 그리고 여기서 틀리면 되돌리기가 오히려 씬을 망가뜨린다. 없느니만 못한 상태가 된다.
• 빠뜨린 것이 조용히 숨는다. 주문서에 안 적은 작업 하나가, 몇 주 뒤 아티스트 씬에서 터진다. 그때는 원인을 찾기 아주 어렵다.
• 테스트가 두 배다. "실행이 되나" 만으로 부족하다. "되돌리면 원래랑 똑같나"까지 봐야 한다. 게다가 실행→취소→다시실행을 여러 번 반복해도 멀쩡한지도 확인해야 한다.

정리

명령 패턴의 생각은 한 줄이다.

"한다"를 그냥 하지 말고, 종이에 적어서 남긴 다음에 해라.

종이가 남으면 되돌릴 수 있고, 다시 할 수 있고, 나중에 실행할 수도 있다.

리깅 툴을 만드는 사람에게 이건 선택이 아니다. 아티스트는 하루에 Ctrl+Z를 수백 번 누른다. 그 수백 번 중 한 번이라도 씬을 깨뜨리면, 그 툴은 다시는 안 쓰인다.

기능이 하나 더 있는 툴보다, 되돌리기가 확실한 툴이 현장에서 오래 산다.