게임 개발을 위한 Git
게임 개발을 위한 Git | Massively Fun 의 게임 개발용 Git
게임 개발을 위한 Git
2012 년 3 월 14 일
저는 수년 동안 영화 및 게임 제작을 위해 CVS, Perforce, 심지어 몇 가지 사내 도구 등 다양한 버전 관리 시스템을 사용해 왔습니다. 이러한 도구들은 항상 어색하지만 필수적인 악 necessary evil 처럼 느껴졌습니다. 대규모 프로젝트에서 작업을 추적하는 데에는 없어서는 안 될 가치 있는 도구이지만, 동시에 혼란, 병목 현상, 그리고 제작 과정의 유연성 부족을 끊임없이 야기하는 원인이기도 했죠.
Git 이 제 레이더에 처음 포착된 것은 약 6 개월 전이었습니다. 놀라울 정도로 강력하고 유연해 보였습니다. 제가 팀에 합류했을 때 Massively Fun 의 개발자들은 이미 코드 개발을 위해 Git 을 사용하고 있었습니다. 저는 이것이 아트 제작에도 적용될 수 있을지 매우 궁금했습니다. 이 포스팅은 그 과정에서 일어났던 이야기를 담고 있습니다.
배경: Git 이란 무엇인가?
Git 은 **분산 버전 관리 시스템 (distributed version control system)**입니다. 게임 개발 분야에 종사하는 대부분은 Subversion 이나 Perforce 와 같은 다른 버전 관리 시스템 중 적어도 하나쯤은 익숙할 것입니다. 이러한 다른 시스템들과 마찬가지로 Git 도 프로젝트에 포함되는 모든 파일의 수많은 버전을 추적할 수 있게 해줍니다.
하지만 Subversion 과 Perforce 는 중앙 집중식 시스템입니다. 즉, 모든 파일이 중앙 서버에 존재하는 저장소 (repository) 로 체크인 (check-in) 되거나 체크아웃 (check-out) 됩니다. Git 은 이와 다릅니다. 중앙 서버에 의존하지 않습니다. 모든 사용자는 전체 히스토리와 리비전 (revisions) 을 포함한 저장소의 완전한 사본을各自 보유하게 됩니다.
이러한 설계는 여러 중요한 함의를 가지며, 그 대부분은 긍정적인 효과입니다. 하지만 제 눈에 Git 을 특히 돋보이게 하는 것은 브랜치 (branch) 와 머지 (merge) 작업을 거의 자명할 정도로 쉽게 만든다는 점입니다. 실험적인 아이디어를 작업하기 위한 브랜치, 관련 없는 문제를 수정하기 위한 또 다른 브랜치, 새로운 기능을 위한 또 하나의 브랜치를 쉽게 생성할 수 있습니다. 이러한 다양한 브랜치 사이를 빠르게 오갈 수 있으며, 필요에 따라 다시 하나로 통합 (merge) 할 수도 있습니다. 이는 엄청나게 유용한 기능입니다.
관련 항목: — Unity 프로젝트에 바로 적용할 수 있는 기성 아트, 도구 및 템플릿.
장애물 (Stumbling Blocks)
많은 장점에도 불구하고, 시중에서 구할 수 있는 기본 Git 은 아트 제작 측면에서 두 가지 명백한 결점을 가지고 있습니다.
- 아티스트 친화적이지 않습니다. Git 의 기본 인터페이스는 명령줄 (command line) 입니다. 배워야 할 명령어와 옵션이 많을 뿐만 아니라, 다른 버전 관리 시스템과 충분히 달라 혼란을招来하는 근본적인 개념들도 이해해야 합니다. 문서화는 풍부하지만 종종 이해하기 어렵습니다. 이 모든 요소가 합쳐져 접근성이 낮고 다소 위협적으로 느껴지는 패키지가 되었습니다.
- 아티스트가 만드는 대형 바이너리 파일을 관리하도록 설계되지 않았습니다. 각 로컬 저장소가 모든 히스토리와 리비전을 포함한다는 사실은 급격히 변화하는的大量의 아트워크가 디스크 공간을 순식간에 많이 차지하게 만든다는 것을 의미합니다.
저희는 이 두 가지 문제 모두에 대한 해결책을 고안해냈습니다.
인터페이스가 중요하다
Git 에는 몇 가지 훌륭한 그래픽 인터페이스가 존재합니다. 아티스트们仍需 이해해야 할 기본적인 Git 개념들이 있지만, 잘 설계된 프론트엔드는 이를 훨씬 더 쉽게 배우고 사용할 수 있게 만들어줍니다. 저희는 Mac 기반 환경에서 Atlassian 의 SourceTree가 훌륭하게 작동한다는 것을 발견했습니다. 강력하고 직관적이며 (당분간) 무료라는 점이 열악한 스타트업에게는 중요한 고려 사항이었습니다. 또한 SourceTree 팀은 저희가 트위터로 보낸 지원 문의에 신속하게 (<12 시간) 응답해주었습니다.
쇼핑하는 경우: — 웹, 모바일 및 데스크탑으로 내보내는 브라우저 기반의 코드 없는 HTML5 엔진.
매끄러운 Git 확장 프로그램
Git-media는 대형 바이너리 파일과 관련된 Git 의 단점을 해결해줍니다. 이는 Git 외부에 파일을 저장할 수 있게 해주는 Git 확장 프로그램입니다. Git 은 여전히 파일 버전을 추적하지만, 파일 내용 자체는 저장소 외부 어딘가에 저장합니다. 저희는 대형 바이너리 파일들을 Amazon 의 S3 클라우드에 저장할 계획이었습니다.
그리 빠르게 진행되지는 않았다
하지만 SourceTree 와 Git-media 를 함께 사용하는 데에는 함정 (gotcha) 이 하나 존재했습니다. 저희 저장소와 Amazon S3 간에 파일을 전송하려면 셸 명령어를 실행해야 했습니다. 즉, 다음과 같습니다.
$ git media sync
아티스트들에게 그래픽 애플리케이션이라는 비교적 편안한 환경을 벗어나 셸 명령어를 직접 입력하도록 강요하는 워크플로는 아티스트 친화적이지 않습니다. SourceTree 도 이 명령어를 사용자 정의 동작 (custom action) 으로 실행할 방법을 제공하긴 했지만, 그것만으로는 충분하지 않았습니다. 아티스트들은 여전히 적절한 시점에 이를 실행해야 한다는 사실을 기억해야 했기 때문입니다.迟早 그들은 잊어버릴 것이고, 누군가는 무엇이 잘못되었는지 파악하고 수정하는 데 귀중한 시간을 낭비하게 될 것입니다.
그렇다면 어떻게 SourceTree 와 git-media 가 원활하게 협력하도록 만들 수 있을까요?
Git Wrap
저희는 Git 명령어 자체 전후에 선택적으로 다른 명령어들을 실행하는 범용 래퍼 스크립트 (wrapper script) 를 작성했습니다. 원격 저장소와 상호작용하는 명령어들이 실행되기 전이나 후에 상황에 맞게 자동으로 git media sync를 호출하도록 설정했습니다. 그리고 SourceTree 가 기본 제공되는 Git 대신 이 래퍼를 호출하도록 구성했습니다.
이 래퍼의 소스 코드는 Github 에서 여기 에서 확인할 수 있습니다.
모험은 계속된다
이것이 이야기의 끝이었다면 좋았을 텐데요. SourceTree 와 git-media 가 완벽하게 조화를 이루고 저희 모두가 행복하게 살았다고 말씀드리고 싶습니다. 실제로 두 도구는 어느 정도까지는 잘 작동했습니다. 하지만 안타깝게도 그것은 충분하지 않았습니다.
SourceTree 는 일반적으로 이미지 파일을 미리 보는 데 탁월한 성능을 발휘합니다. 아티스트들이 이러한 파일들의 변경 사항을 커밋하거나 머지할 때 이는 매우 중요합니다. 하지만 git-media 를 사용하면 SourceTree 의 이미지 미리 보기 기능이 깨져버렸습니다. 이미지를 Git 내에 저장하지 않고 이미지에 대한 버전 정보만 저장하게 되었기 때문입니다.
저희는 이에 대한 납득할 만한 우회 방법을 찾지 못했고, 이는 결국 거래를 무산시키는 결정적인 요인 (deal breaker) 이 되었습니다.
이 글을 작성하는 시점에서 저희는 Git 의 서브모듈 (submodule) 기능을 활용해 다시 한번 시도하고 있습니다. 아트 에셋을 서브모듈에 저장하는 것은 메인 프로젝트 저장소의 크기를 최소화하는 또 다른 방법입니다. SourceTree 는 서브모듈을 상당히 잘 이해하고 지원하며, 이미지 미리 보기 기능도 그대로 유지됩니다. 서브모듈에는 몇 가지 특이점 (idiosyncrasies) 이 있지만, 아티스트의 워크플로우를 너무 크게 방해할 것처럼 보이지는 않습니다.
추가 업데이트는 이 공간을 지켜봐 주시기 바랍니다. 결과가 어떻게 나올지 알려드리겠습니다.
블로그 댓글은 Disqus 에서 제공됩니다.
개발 데스크를 확보하세요
게임 프로그래밍 서적, 기계식 키보드, 모니터 및 개발 데스크 하드웨어