반갑습니다. 저는 Stein이고 생츄어리 프로젝트에 자발적으로 참여한 개발자입니다. 저는 지난 2달 간 프로젝트에 함께해왔지만, 프로그래밍 자체는 3년에 걸쳐서 경력을 쌓았죠. 저는 게임 엔진, 그리고 단순하면서도 고성능을 뽑아낼 수 있는 코드를 작성하는 것에 관심이 많은 독학 프로그래머입니다. 제 경력을 너무 상세하게 늘어놓아 보았자 재미없어질 테니, 곧바로 본론으로 들어가도록 할게요.
아마 여러분들은 개발자가 무엇이고, 그들이 뭘 하는지 궁금하실 겁니다. 사실 개발자의 정의가 모호하긴 하지만, 게임 개발에서는 주로 프로그래밍을 담당하는 사람들을 의미하죠. 우리 같은 경우에는 팀의 모든 사람을 개발자라고 부릅니다. 이 프로젝트를 만드는 데 모든 사람들이 각각 중요한 역할을 수행해주었고, 자주 여러 부분을 동시에 담당했으니까요. 코드, 사운드 효과, 미술, 내용... 무엇 하나가 빠지더라도 온전한 게임이 나올 수는 없는 법입니다.
프로젝트에서 제가 맡는 역할은 주로 프로그래밍입니다. 저는 루아, C언어, C#과 이 프로젝트가 필요로 하는 거의 모든 것을 작업하지만, 오로지 코딩만을 다루는 것은 아닙니다.
기술적인 문제
프로젝트들의 규모는 대개 크고, 여러 유동적인 부분들이 있어 복잡합니다. 그렇기에 모두가 함께 팀이 되어 일하는 것이 중요하게 작용하죠. 단순히 같이 일하는 것이 아니라, 함께 협동해서 일하는 법을 익혀야 합니다.
이렇게 일할 수 있도록, 각각의 팀 멤버들은 다른 사람들이 무엇을 하고 있는, 어떤 작업이 이루어지고 있는지, 어떤 분야에서 어느 정도의 노력을 들여야 하는지 알아야만 합니다. 제가 ‘상황 인지’ 라고 부르는 요소죠. 하지만, 프로젝트에 참가한 사람이 20여명을 넘어가기 시작하면 프로젝트에 관해 모든 것을 모든 사람이 아는 것이 어려워지게 됩니다.
또한, 팀이 지금 어느 정도에 있는지, 어느 것을 목표로 나아가고 있는지 아는 것 또한 중요합니다. 팀에게 방향성을 주는 것은 목표를 정렬하고 적절한 속도를 맞추는 것을 도우며, 그에 따라 과정이 좀 더 구체적으로 변하고 더 이상 팀의 일원들이 의문을 품어야 하는 모호한 아이디어가 아니게 되기 때문이죠.
해결책
물론 프로젝트의 구조화가 중요한 것에 대해서는 계속 이야기할 수 있겠지만, 우리 팀이 그것을 어떻게 수행할까요?
우선, 최대한 단순하고, 실용적이고, 접근이 쉽도록 하는 것이 중요합니다. 쓸데없이 복잡하거나 규모가 크다고 해서 좋은 프로젝트 구조가 나오는 건 아닙니다. 그 누구도 그걸 유지하고 싶어하지 않을 테니까요. 그래서 우리는 이미 가지고 있는 것을 사용하기로 마음먹었고, GitHub을 사용한 마일스톤과 이슈 티켓 시스템을 만들어냈습니다.
마일스톤은 과정 단계를 표시하는 역할입니다. 달성하기 전에 일정한 요구 사항이 있고, 그 모든 요구 사항을 충족했을 때만 완료한 것으로 간주됩니다. 일종의 할 일 목록이라고 할 수도 있겠지만, 저는 빵 부스러기들의 흔적이라고 생각하는 게 더 좋더군요.
우리의 MVP(최소한의 활용이 가능한 상품)이 첫 번째 마일스톤이었고, 그 결과물은 가장 기초적인 게임 엔진이었습니다. 우리가 필요로 하는 필수적인 요구 사항들에 기초를 둔 것이었죠.
우리의 마일스톤을 위해 필요로 하는 요구 사항들의 목록이 작성되고 나서, 우리는 각각의 요구 사항을 위한 이슈 티켓을 작성했습니다. 이 티켓들에는 각각의 티켓을 위해 실제로 작업하고 있는 사람들의 목록들이 포함되었고, 당신은 이 티켓들을 다양한 태그나 스티커로 표시할 수도 있습니다. 이슈 티켓은 대략적으로 이러한 모습입니다:
이런 이슈 티켓을 작성하는 것은 각각의 개발자들이 다른 팀 멤버들이 볼 수 있는 각자의 할 일 목록을 가질 수 있게 해 줍니다. 우리가 각각의 이슈의 작업을 끝내면서, 우리는 하나씩 할 일 목록에 작성된 일들을 지우고, 다른 팀원들이 굳이 진행 과정을 물어보지 않더라도 그 일이 어느 정도 진행되었는지 알 수 있게 되었습니다. webhook를 통해서 발송되는 공지 사항도 있고요.
이에 더해서, 각각의 이슈들은 Kanban 게시판을 통해 열람될 수 있습니다. 그 덕분에 프로젝트 관리자는 현재 무슨 작업이 이루어지고 있는지, 어떤 티켓이 작업 중이거나 끝난 상태인지 한 눈에 알아볼 수 있죠. Kanban 게시판은 이렇게 생겼습니다:
이제 우리의 작업 흐름이 어떻게 진행되는지 설명하기에 딱 좋은 때인 것 같군요. 위의 사진을 통해 대략적으로 짐작은 가능하시겠지만, 여러분들에게 조금 더 세부적인 설명을 드리고자 합니다.
우선, 개발자는 티켓의 우선도와 자신의 능력을 기반으로 티켓 풀에서 티켓을 선정하고 그 티켓을 “작업 중” 열에 집어넣습니다. 개발자는 그 티켓에 필요한 작업을 수행하고, 충분히 작업이 완료되었다고 생각하면, 이슈 티켓을 “QA 대기 중” 열로 옮깁니다. QA는 품질 보장으로, 우리가 각자의 작업을 살펴보고 기준에 맞는지 심사하는 곳입니다.
이 시점에서는, 어느 테스터라도 그냥 Kanban으로 가서 QA 열을 확인해 테스트해볼 티켓을 찾을 수 있습니다. 일단 테스트가 끝나면, 그들은 결과를 승인하거나, 다시 돌려보냅니다. 그들이 거절한다면, 티켓은 다시 “작업 중”열로 돌아가고 개발자들은 티켓에 있던 버그나 실수를 수정하게 됩니다. 만약 작업 결과가 승인된다면, 티켓은 “QA 승인됨” 열로 옮겨가 개발자가 주 프로젝트에 해당 내용을 합류시킬 수 있게 됩니다. 그 뒤에 티켓이 닫히고 “완료됨” 열로 옮겨지는 것이죠.
일반적으로 프로젝트 구조화와 경영에 사용되는 방식에 비하면 매우 단순하지만, 앞서 말했듯이, 단순하다는 것은 생각보다 많은 장점을 가지고 있습니다.
비교적 작고, 독립적인 팀으로서, 더 큰 회사들이 사용하는 경영 방식을 그대로 사용하는 것은 우리의 효율성을 떨어트릴 것입니다. 우리 정도의 팀이 크고 복잡한 경영 구조를 채택할 필요가 없으니. 우리에게 효율적인 방식을 채택한 셈이죠. 비슷한 결과를 낼 수 있는 방식이 하나 뿐인 건 아니지만, 이 방식은 우리가 빠르면서 신중하게 개발을 진행할 수 있도록 도와주었습니다.
이 글이 여러분들이 보기에 흥미로웠고, 만약에 여러분들이 프로젝트를 수행할 일이 생긴다면 구조를 만들고 체계화하는 데 도움이 되기를 바랍니다. 학교에서 보통 가르치는 내용은 아니지만, 생츄어리처럼 복잡한 프로젝트를 현실에서 수행할 때는 중요해지는 것들이니까요.
감사합니다, Stein.