대게 게임 개발자들은 근무 시간이나 강도가 높은 편인데, 정작 자기 코드를 돌아보고 개선할 수 있는 시간이 거의 없어 늘 비슷한 수준의 코드만 반복해서 작성하는 경우가 있습니다. 코드 재활용이 잘 이루어지지 않다 보니 엇비슷한 프로젝트를 수행하면서 같은 코드를 반복해서 짜는 일도 많습니다.

게임은 요구 사항 변경이 잦은 편이다 보니 쉽게 엔트로피가 높아져서 유지보수가 힘든 코드가 되는 경우가 많이 있습니다. 또한 시간에 쫓기면서 작업하다 보니 일단 돌아가게만 해놓고 나중에 제대로 고쳐야겠다고 생각만 하고 넘어가는 경우가 많기도 합니다.

리팩토링은 코드 동작은 유지하면서 내부 구조를 이해하기 쉽고, 유지보수가 쉽게 바꾸는 활동을 의미합니다. 게임팀을 맡아 새로 만든 프로세스 중 하나는 “리팩토링 회의”입니다. 매일 정오에 30-40분 가량 사내 모든 개발자들이 모여서 리팩토링 혹은 코드 개선을 위한 기술 세미나를 진행했습니다. Design Pattern, Refactoring, Test Driven Development, Effective C# 등 기술 서적의 내용을 발표하기도 했고, 실제로 게임팀에서 작성한 코드를 놓고 무엇이 문제인지, 어떻게 개선할 것인지 토론도 진행하였습니다.

이런 활동을 통해 배운 가장 큰 교훈은 개발자들이 잘 작성한 코드란 무엇인지 감을 잡기 시작했다는 점입니다. 내가 짠 코드가 어떤 문제가 있는지 다른 개발자들의 의견을 들어볼 기회가 없으면 문제점을 모르기 때문에 개선도 할 수가 없습니다. 리팩토링 회의를 통해서 개발 능력이 갑자기 향상될 수는 없지만, 최소한 문제점을 인식하기 시작하면 개선하기 위한 노력이 가능해집니다.

최근 사내 개발자들의 능력이 정체되어 있다고 생각한다면 이런 “리팩토링 회의”와 같은 활동을 시작해 볼 것을 추천합니다.

작년 초에 게임팀에 와서 가장 먼저 한 일은 당시 게임팀이 사용하고 있던 버전 관리 시스템을 Unity Asset Server에서 Git으로 바꾼 것입니다. Unity Asset Server의 Unity Editor에서 편리하게 사용할 수 있다는 장점이 있지만, Subversion, Git 등이 제공하는 브랜치(branch)를 따는 기능을 제공하지 않기 때문에 문제라고 생각하였습니다. 구체적으로 무엇이 문제일까요?

브랜치를 딸 수 없으면 모든 개발자가 항상 마스터(master)에 작업물을 반영해야 합니다. 예를 들어, 제품을 출시한 이후 개발자들이 다음 업데이트를 위한 작업물을 마스터에 반영하고 있다고 가정해 봅시다. 만약 출시한 릴리즈에 버그가 있어서 수정해야 하는 상황이면 어떻게 될까요?

출시 버전 기준으로 해당 버그만 고쳐서 다시 릴리즈를 해야 하는데, 이미 마스터에는 아직 작업 중인 다음 업데이트 내용이 반영되어 있게 됩니다. 새로운 기능이 보이지 않게 끄고, 안정성에 문제가 없는지 테스트하기 시작하면 더 이상 간단한 패치 수정이 아니라 사실상 새로운 릴리즈를 하는 상황이 됩니다. 출시 시점에 브랜치를 따두었다면, 마스터에 반영된 추가 작업과 별개로 출시 브랜치에 버그 수정만 반영하고 곧 바로 릴리즈를 할 수 있었을 겁니다.

릴리즈에 대한 버그 수정과 다음 릴리즈 작업을 동시에 준비하기 위해 브랜치를 만드는 방법은 이미 수많은 소프트웨어 개발에 사용되고 있는 일반적인 프로세스인데 Unity Asset Server가 이런 기본적인 버전 관리 기능을 제공하지 않는다는 사실이 이상하게 느껴졌던 부분입니다.