리깅 파이썬: 버전 관리 — 팀 리깅 툴을 git으로 관리하기

리깅 툴은 보통 한 사람 노트북에서 태어난다. 급해서 만든 스크립트가 팀에 퍼지고, 어느 날 아무도 어느 게 진짜인지 모르게 된다. 버전 관리는 그 혼란을 막는 아주 오래된 방법이다.

파일 이름 뒤에 붙는 숫자들

이런 폴더를 본 적이 있을 것이다.

autoRig.py
autoRig_v2.py
autoRig_v2_fixed.py
autoRig_v2_fixed_민수수정.py
autoRig_final.py
autoRig_final_진짜final.py

여섯 개 파일 중 지금 써야 하는 건 하나다. 그런데 이름만 봐서는 알 수 없다. 열어서 코드를 읽어야 알고, 읽어도 확신이 안 선다. final이 v2_fixed보다 나중인지 앞인지 파일 이름은 말해주지 않는다.

버전 관리는 이 문제를 다르게 푼다. 파일은 하나만 남긴다. 대신 그 파일이 지금까지 어떻게 변해왔는지를 옆에 따로 적어둔다. 언제, 누가, 무엇을, 왜 바꿨는지가 순서대로 쌓인다.

게임 세이브 파일과 같다

게임을 하다가 보스 앞에서 세이브를 한다. 죽으면 그 지점으로 돌아간다. 다른 무기를 들고 다시 해본다. 또 죽으면 또 돌아간다.

버전 관리도 똑같다. 코드가 잘 돌아가는 순간마다 세이브를 찍는다. 이걸 커밋(commit)이라고 부른다. 뭔가 잘못되면 마지막으로 멀쩡했던 커밋으로 돌아가면 된다.

차이는 하나다. 게임 세이브는 보통 혼자 쓰지만, 버전 관리 세이브는 팀 전체가 같이 쓴다.

가지가 자라는 그림

여러 사람이 같은 툴을 동시에 고치면 어떻게 될까. 각자 자기 가지를 뻗어 나가서 작업하고, 다 끝나면 다시 하나로 합친다. 가지를 브랜치(branch), 합치는 걸 머지(merge)라고 한다.

초록색이 본줄기고 노란색이 곁가지다. 빨간 화살표는 곁가지가 본줄기로 돌아오는 자리다. 나무처럼 뻗어만 나가는 게 아니라, 뻗었다가 다시 모인다.

중요한 건 본줄기는 항상 돌아가는 상태로 둔다는 규칙이다. 실험은 곁가지에서 한다. 곁가지가 망가져도 팀은 아무 영향을 안 받는다.

리깅 팀에서 실제로 생기는 일

애니메이터가 말한다. "어제까지 잘 되던 스트레치가 오늘 안 돼요."

버전 관리가 없으면 여기서부터 추리 게임이다. 누가 뭘 만졌는지 물어보고 다니고, 기억에 의존하고, 결국 백업 폴더를 뒤진다.

버전 관리가 있으면 질문이 바뀐다. "어제 이후로 이 파일에 뭐가 들어왔지?" 목록이 나온다. 세 개다. 하나씩 되돌려보면 범인이 나온다. 5분이면 끝난다.

같은 파일을 동시에 건드리면

둘이 같은 줄을 서로 다르게 고치면 충돌(conflict)이 난다. 이건 버전 관리가 만든 문제가 아니라, 원래 있던 문제를 눈에 보이게 만든 것이다. 예전에는 나중에 저장한 사람이 앞사람 작업을 조용히 덮어썼다. 지금은 합칠 때 "여기 둘이 다르다"고 멈춰 세운다.

쓸 때 좋은 점

• 지우는 게 안 무섭다. 쓸모없어 보이는 함수를 지울 때 주석 처리하지 않고 그냥 지운다. 필요하면 언제든 꺼낼 수 있으니까. 파일에 시체가 안 쌓인다.
• "왜 이렇게 짰지?"에 답이 남는다. 이상하게 생긴 코드 한 줄에 커서를 대면 그걸 쓴 사람과 그때 남긴 메모가 나온다. 대개 "마야 2024에서 이거 안 하면 죽어서"처럼 이유가 붙어 있다.
• 쇼 단위로 갈라 쓸 수 있다. A쇼는 지금 버전으로 고정하고, B쇼는 새 기능을 받는다. 폴더를 복사해서 두 벌 관리하지 않아도 된다.
• 내 노트북이 죽어도 작업이 안 죽는다. 올려둔 것까지는 다른 사람 컴퓨터에도 다 있다.

쓸 때 힘든 점

• 처음 2주가 진짜 짜증난다. 커밋, 푸시, 풀, 브랜치… 용어부터 낯설고, 손이 익기 전엔 저장 한 번 하는 데 세 단계를 거치는 느낌이다. 이 구간을 못 넘고 포기하는 팀이 많다.
• 충돌 해결은 요령이 필요하다. 처음 충돌을 만나면 화면에 <<<<<<< 같은 기호가 박혀서 파일이 망가진 것처럼 보인다. 안 망가졌지만, 그렇게 안 보인다. 옆에서 한 번 알려주는 사람이 있어야 한다.
• 마야 씬 파일이랑은 궁합이 나쁘다. git은 텍스트를 잘 다룬다. .py는 완벽하다. .ma는 그럭저럭이다. .mb는 그냥 덩어리로 취급해서 용량만 불어나고, 무엇이 바뀌었는지 보여주지 못한다. 리깅 툴 코드는 git으로, 무거운 씬 파일은 다른 방식으로 나눠야 한다.
• 규칙을 안 정하면 금방 지저분해진다. 커밋 메시지에 "수정", "ㅇㅇ", "asdf"만 쌓이면 히스토리가 있으나 마나다. 도구가 규율을 대신해주지는 않는다.

커밋 메시지는 미래의 나에게 쓰는 쪽지

버전 관리에서 실력 차이가 가장 크게 나는 곳은 명령어가 아니라 메시지다.

좋은 메시지는 무엇을 했는지가 아니라 왜 했는지를 담는다. 무엇을 했는지는 코드를 보면 알 수 있다. 왜 했는지는 쓴 사람 머릿속에만 있다.

리깅 팀이 시작할 때의 최소 조건

거창하게 시작할 필요는 없다. 세 가지만 지켜도 절반은 온다.

1. 툴 폴더 하나를 정한다

흩어진 스크립트를 한 폴더로 모은다. 그 폴더 하나만 버전 관리에 올린다. 여기 없는 스크립트는 팀 자산이 아니라고 정한다.

2. 무거운 파일은 빼둔다

씬 파일, 텍스처, 캐시, 알렘빅은 넣지 않는다. 넣는 순간 저장소가 수 기가로 부풀고 아무도 안 쓰게 된다. 넣는 건 .py, .mel, .json 같은 가벼운 텍스트뿐이다.

3. 하루 한 번은 올린다

일주일치를 한꺼번에 올리면 커밋 하나에 스무 가지 변경이 섞인다. 나중에 그중 하나만 되돌리고 싶어도 되돌릴 수가 없다. 작게 자주 올릴수록 나중에 쓸 수 있는 기록이 된다.

스크립트가 팀 자산이 되는 순간

혼자 쓰는 스크립트와 팀 자산의 차이는 코드 품질이 아니다. 만든 사람이 자리에 없어도 굴러가는가이다.

버전 관리는 그 조건을 만들어준다. 어디에 있는지 정해져 있고, 어떻게 여기까지 왔는지 남아 있고, 잘못되면 되돌릴 수 있다. 그러면 그 스크립트는 더 이상 누구의 개인 물건이 아니다.

리깅 툴은 결국 남이 쓰라고 만드는 것이다. 남이 쓸 수 있는 상태로 두는 데는, 도구 하나와 약속 세 개면 충분하다.