5/12 팀 작업 준비의 준비 프로젝트

기존 스터디 팀원들이 팀 작업 하고싶다는 요청이 있어서, 본격 팀 작업 들어가기 전에 이전 기억을 더듬을 겸 일주일간 팀 작업을 하기로 했다.

그 결과 나포함 10명.. 이 모이게 되었다.
처음에는 하나의 게임 안에 여러 미니게임이 들어가는 구조를 생각했고, 브랜치도 그 구조를 따라가면 될 거라고 봤다.

처음 구상한 형태는 main → 각 팀 게임 브랜치 → 각자 브랜치였다.
말 그대로 하나의 저장소 안에서 모든 팀이 같이 움직이고, 각 팀은 자기 게임 브랜치를 기준으로 작업하는 방식이었다.

처음 구상한 구조

처음 아이디어만 보면 이 구조는 나쁘지 않았다.
게임 전체를 하나의 프로젝트로 관리할 수 있고, 각 팀이 맡은 미니게임도 브랜치 단위로 분리된다고 생각했다.

미니게임천국처럼 여러 게임이 하나의 실행 파일 안에 들어가는 형태를 만들고 싶었기 때문에, 저장소 구조도 그 방향을 따라가려고 했다.
당시에는 프로젝트를 나누기보다 브랜치 전략으로 해결하는 쪽이 더 자연스럽게 느껴졌다.

바로 드러난 문제

실제로 저장소를 만들어서 움직여 보니 생각했던 것과는 많이 달랐다.
브랜치를 나눈다고 해도, 실제 작업에서는 어떤 브랜치에서 시작해야 하는지, 어떤 브랜치로 합쳐야 하는지부터 계속 확인이 필요했다.

10분만에 만들어진 깃 그래프

또 하나는 리소스 문제였다.
한 팀이 작업한 에셋이나 설정이 다른 팀 쪽으로 같이 따라오거나, 반대로 분리되어 있어야 할 파일이 한 저장소 안에서 계속 엮였다.
언리얼 프로젝트는 코드만 관리하면 되는 구조가 아니기 때문에, 예외 처리를 미리 많이 생각해야 했다.

결국 가장 크게 느껴진 건 관리 부담이었다.
이 구조를 먼저 제안했던 입장에서, 브랜치 전략을 설명하고 예외 상황을 정리하고, 실제 충돌이 났을 때 기준을 잡아 주는 일이 계속 내 쪽으로 몰렸다.
만들기 전에는 괜찮아 보였던 구조가, 막상 작업이 시작되니 오히려 전체 속도를 늦추는 방향으로 보이기 시작했다.

구조를 바꾼 이유

그래서 중간에 구조를 다시 정리했다.
브랜치를 더 세분화해서 버티는 쪽이 아니라, 저장소 자체를 분리하는 쪽으로 방향을 바꿨다.

팀을 4개로 나누고, 각 팀별로 별도 repository를 만들었다.
그 안에서 다시 팀원들이 자기 브랜치를 가져가는 형태로 정리했다.

아쉽게도 미니게임천국이라는 컨셉은 없어졌지만, 다른 게임 리소스가 같이 섞이는 문제는 크게 줄었고, 저장소 단위의 책임 범위도 분명해졌다.

지금 구조

지금은 각 팀이 자기 repository 안에서 움직이고 있다.
미니게임천국... 이 없어졌지만 단시간에 동안 진행되는 프로젝트니까
위험 요소를 굳이 만들필요가 없다는 결정이었다.
어차피 내가 만든건데

우리 팀 방향

우리 팀은 미니게임천국5의 무찔무찔을 구현하기로 했다.
지금 단계에서는 게임 내용을 크게 확장하기보다, 먼저 팀 저장소 안에서 안정적으로 작업을 이어 갈 수 있는 구조를 만드는 쪽이 더 중요했다.