언리얼 엔진으로 플레이팹 서버를 다루는 포스팅을 시작하기 전...
잠깐 일지삼아 내가 이번 4학년 졸업 프로젝트에서 팀원들과 어떻게 협업하는지,
언리얼 엔진은 깃허브에서 어떻게 협업하는지에 대한 방식을 일기처럼 주절주절 작성해보겠다.
Team Organizations
우리 팀은 따로 메인 리포지토리를 누군가 개인 소장하는게 아닌,
팀 오거나이제이션을 생성하여 여기서 프로젝트를 관리하기로 했다.
오거나이제이션 하나에서 다루는 범위가 굉장히 넓기에,
앞으로도 쭉 게임을 여러개 만들 팀에서 사용하기 적합하다.
사실 졸업 프로젝트 팀은 일시적인 팀이기에 프로젝트가 끝나면 사용될 일이 없겠지만,
그래도 앞으로 많은 오거나이제이션을 사용하기 전 연습으로 너무 좋은 경험이 되었다.
가장 메인으로 다루는 UNDEADER 리포지토리가 언리얼 프로젝트가 담긴 리포지토리이고,
나머지 두 개는 각각 유니티 에셋을 사용해 맵을 만드는 리포지토리와, 플레이팹 서버 프로토타입 리포지토리이다.
이슈 작성
팀원들과 디스코드로 회의 후에,
작성해둔 게임 기획서와 개발 로드맵을 본다.
이후 팀원들과 회의하여 나온, 앞으로 개발해야 할 기능들 중
가장 우선순위가 높은 개발사항을 선택하여 이슈를 작성한다.
이 때 미리 만들어둔 이슈 템플릿덕분에 간단하게 작성이 가능하다.
이슈 템플릿과 PR 템플릿을 작성하는 방법이 궁금하다면, 아래 포스팅으로!
PR Template와 Issue Template 설정하기
게임을 개발하던, 웹을 개발하던,Github을 통해 여러 명이서 협업을 하다 보면 당연히 Branch를 많이 쓰게 된다. Branch를 쓰고, 협업 인원이 많으면 많을 수록당연히 PR과 Issue를 자주 작성하게 되는
suldangoo.tistory.com
브랜치 생성 및 개발
이제 해당 이슈에 작성한 기능을 개발할 브랜치를 만든다.
브랜치는 깃허브 사이트에서 직접 만들기도 하고,
Git Desktop에서 로컬 브랜치를 만든 후 Push하기도 한다.
그때그때 손에 잡히는 방법으로 브랜치를 만드는 편.
팀원이 많고 큰 조직에서 협업을 할수록 Branch의 개수가 많아지고,
실제로 서비스하는 게임이나 어플리케이션일 경우 더더욱 Branch의 개수가 많아지는 편인데,
이번 프로젝트는 나를 포함해 핵심 개발 인원이 3명인 작은 프로젝트라
가장 주축이 되는 main 브랜치와 각자 기능을 개발하는 브랜치를 그때그때 생성해 사용하고 있다.
브랜치를 만들었으면, 해당 브랜치로 checkout 후 열심히 개발한다.
이 때 중요한건, 자신이 맡은 영역 외 모듈은 웬만하면 건드리지 않는 것이다.
내가 만약 WBP를 개발하기로 했다면 WBP 외 모듈은 건드리지 않고,
Map Design을 하기로 했다면 Level 외 모듈은 건드리지 않는다.
그 이유가, 언리얼 엔진에서 BP로 개발하고 깃허브에 푸쉬를 하게 되면
블루프린트는 코드가 아니기 때문에 바이너리 파일로 처리하게 되고,
결국 PR을 올릴 때 다른 사람과 같은 영역을 편집했다면 100% 확률로 컨플릭트가 터진다!!
괜히 깃허브로 언리얼 프로젝트 협업 잘 안하는게 아니다...
Pull Request & Code Review
해당 브랜치에서 개발해야 할 기능을 모두 개발했다면,
임시로 테스트 모듈을 만들어서 내가 개발한 기능이 잘 동작하는지 테스트를 거친다.
테스트 결과가 괜찮고, 버그가 없다고 생각된다면
이제 main 브랜치로 PR을 작성하면 된다.
항상 PR을 올리고 다른 사람들에게 개발한 기능을 소개할 때의 마음가짐.
다른 이들은 내가 개발한게 뭔지 하나도 모른다고 생각해야 한다.
여러가지 이벤트와 메서드를 작성하고, 내부 변수들을 새로 정의하지만,
어디까지나 다른 팀원들이 사용할 퍼블릭 메서드만 꺼내놓고 나머지는 캡슐화하기 때문에
다른 팀원들에게 굳이 어렵게 내가 만든 로직의 전부를 설명할 필요는 없다.
다른 사람들이 사용할 퍼블릭 메서드만 어떤 모듈에서 어떻게 작동하는지,
인풋으로 무엇을 넣으면 아웃풋으로 무엇이 나오는지 간단하게 작성해준다.
그리고 PR문서에만 적으면 나중에 찾아보기 어려우니,
앞으로 개발하면서 자주 만지게 될 부분은 (특히 유지보수나 밸런싱에 필요한 수치들)
꼭 노션의 별도 유지보수 페이지에 작성하는 편이다.
아무튼 PR을 올리게 되면, 팀원들이 코드리뷰를 남기게 된다.
사실, 언리얼 프로젝트를, 특히 블루프린트로 개발하는 프로젝트는
깃허브에서 코드가 보이지 않는다. 전부 바이너리 파일이라며 보여주지 않는다.
그래서 이런식의 코드는 어떤가요? 하는 등의 Suggest 리뷰는 거의 달리지 않고,
버그 등의 이슈 있어요, 제가 생각한 부분과 달라요, 예외 처리 부탁드려요 등의 리뷰가 대부분이다.
특히 위에서도 몇 번이나 얘기했듯, 언리얼 프로젝트가 merge에 내성이 거의 없는 편이어서
툭 치면 Conflic나 컴파일 에러가 터진다.
한 번은 모듈 폴더명이 잘못되어서 폴더명을 수정했는데,
다른 사람의 커밋이 Merge되면서 폴더명을 추적하는 환경변수가 바뀌었는지 컴파일이 되지 않았다.
때문에 아예 커밋이력을 지워버리고, 다시 PR을 올리는 사태도 발생했,,,었다.
DnD로 비주얼 코딩을 하는 모든 프레임워크가 으레 그렇듯
텍스트로 작성하는 소스코드가 아닌 이상 깃허브가 깔끔하게 해당 사항을 지원해주지 않는다.
이거 참 더러워서 BP 안쓰고만다
아무튼 개발한 기능에 문제가 없고, 컨플릭트도 나지 않는다면,
다른 팀원들이 Approve를 해준다.
이후 main 브랜치에 Squash and Merge를 해주면 끝!
Squash하는 이유는 당연하겠지만, main 브랜치에 커밋 이력이 너무 많이 쌓여버리면
특정 모듈에 생긴 문제를 나중에 알았을 때 추적하기가 너무너무너무 어렵다.
또한 Conflict가 자주 일어나는 언리얼 프로젝트 특성상
이전 커밋 이력에서 몇몇 모듈만 Discard 해야하는 일이 비일비재하게 생기는데,
이 때 커밋 이력이 너무 쌓여있으면 정말 복구하기 어려워진다...
이후 개발에 사용한 브랜치는 그때그때 바로 Delete해주는 편이다.
결론
이렇게 해서 팀 프로젝트 때 깃을 이용해 언리얼 프로젝트를 협업하는 방식을 둘러보았다.
이번 포스팅에서 계속 언급한 문제가,
블루프린트 파일(.uasset)이 이진 파일로 처리되는
Git과 같은 버전 관리 시스템에서 흔히 발생하는 이슈인데,
이런 이슈를 해결하기 위해 주로 언리얼 엔진 협업은
퍼포스(Perforce)라는 VCS를 주로 사용한다.
바이너리 파일을 사용하는 언리얼 엔진 특성상
아무래도 대용량의 바이너리 파일을 사용하려면 Git LFS를 필연적으로 쓰게 되는데,
이는 파일 충돌 문제 자체는 해결해주지 않을 뿐더러
Git LFS data quota가 넘어서는 오류도 일어나게 된다.
그러나 퍼포스를 사용하게 되면 파일 락킹 기능을 기본으로 제공하며
Multi-User Editing에서 파일을 추가/수정/삭제 시
연결되어있는 다른 클라이언트에도 변경사항이 실시간으로 적용된다.
다른 사람이 블루프린트를 만들면, 내 클라이언트에서도 실시간으로 블루프린트가 생기는 것이다.
이번 협업은 인원이 적고, Git을 사용하는 방법에 대해서도 공부하기 위해 Git을 썼지만,
다음에도 Unreal로 협업을 하는 기회가 생긴다면 꼭 퍼포스를 사용하려고 한다.
'Git' 카테고리의 다른 글
| PR Template와 Issue Template 설정하기 (0) | 2024.06.06 |
|---|