1. 유니티 협업 프로젝트 만들기
어제자에서도 유니티를 깃에 연결하는 방법에 대해 알아봤으나, 다른 방법으로도 깃허브를 생성하는 방법을 알아보면서 팀 프로젝트 세팅하는 방법을 알아보고자 한다.
1.1 유니티 프로젝트를 생성한다.
유니티를 원하는 위치에 생성한다. 해당 프로젝트를 열고 잘 열리는지 확인을 마치고서 다음 작업을
1.2 새로운 깃 레포지토리를 생성한다.
생성한 프로젝트의 이름과 동일하게 레포지토리를 생성한다. 여기서 유의해야 할 점은 폴더 위치를 유니티 프로젝트가 생성된 위치까지만으로 만드는 것이다.
내부에 파일들이 있지만 그 안까지 들어가지 말고 딱 동일한 위치까지만으로 경로를 설정하면, 그 내부에 있는 파일 위치에 자동으로 깃허브가 생성된다.
1.3 내부에 아무 폴더나 생성해서 깃허브가 잘 작동하는지 확인해본다
의미 없는 파일을 만들어보고 깃허브에 반영되는지 확인해보자.
잘 작동되는 것이 확인되며 이후에 프로젝트 세팅을 진행한다.
1.4 Imports 폴더 만들기, 기본 세팅하기
에셋을 분리하기 위한 Imports 폴더의 생성 및 ignore 설정 방법에 대한 건 이전 글에 설명해 놓았으니 생략하도록 하고, 프로젝트에 정해진 룰에 따라 기본적인 파일 세팅 등을 하고 커밋을 한 다음, 상황에 따라 public 아니면 private으로 publish한다.
1.5 팀원들을 초대하기
이제 깃허브 웹사이트로 들어가서 해당 프로젝트에서 참여자를 초대할 수 있다.
여기에서 각 팀원의 주소를 받아 초대를 하고, 초대를 받은 팀원은 메일을 통해서 해당 초대 내역을 확인할 수 있다.
이와 같이 작업하여 팀 프로젝트를 시작해 보자.
2. 팀원으로서 초대를 받았을 경우
팀원으로서 초대를 받았을 경우 어떻게 작업해야 할까? 팀원은 우선 메일로 자신이 초대받은 단계부터 시작한다.
이와 같이 누군가가 나를 초대했을 경우 메일이 오게 되며, 해당 메일에서 수락 시 협업 레포지토리에서의 권한을 얻을 수 있다.
수락을 누른 다음 화면을 아래와 같이 초대자의 깃허브로 이동하게 된다.
깃허브를 데스크탑으로 열도록 해 본다.
정상적으로 권한을 받은 상태라면 이렇게 URL로 깃허브 레포지토리를 생성할 수 있게 된다. 여기서 파일을 원하는 경로로 세팅한 후 복사하도록 한다.
이와 같이 레포지토리가 생성되고, History로 다른 사람이 한 작업물도 볼 수 있게 된다.
하지만 이 상태로는 유니티를 실행할 수 없다.
해당 초대자가 Unity Ignore을 한 상태이기 때문에 에셋과 패키지 및 초기 설정 등 기본적인 것만 온 것일 뿐, 유니티 기본 프로그램은 전부 없는 상태이다. 그래서 이렇게 레포지토리를 받은 후 이걸 다시 Unity 프로젝트로 등록해야 한다.
이와 같이 해서 프로젝트를 등록한 후 열어보자.
초기 프로그램을 다시 설치해야 하기 때문에 조금 시간이 걸릴 수 있다.
하지만 이 프로그램을 열어보면 팀장이 초기 작업했던 내용 그대로의 유니티 파일을 확인할 수 있다.
이제 여기서 branch 등을 만들고 작업을 시작하면 된다.
3. 깃허브 협업을 위한 추가적인 룰 세팅
룰셋의 기능을 알아보고자 한다.
초기 상태이면 룰셋이 없다고 뜰 것이다. 이 룰셋을 추가하여 팀 프로젝트에서의 규칙을 정해보자.
역할이나 target branch에 관해서 세팅을 할 수도 있고 하단에 다양한 기능들이 모여있다.
여러가지 기능 중 필요한 기능을 쓰면 될 것으로 보이며, 여기에서 특별히 유용히 보이는 기능으로는 Require a pull request before merging 정도로 보인다.
해당 기능은 프로젝트에 병합 전에 pull request를 받아야지만 합칠 수 있도록 설정하는 기능으로, 몇 명 이상의 동의를 받아야지만 통과가 가능한지 등도 세팅이 가능한다.
이와 같이 룰셋과 관련하여 필요한 세팅을 해 두면 더욱 원활한 팀 프로젝트 활동이 가능할 것이다.
4. Issue 세팅
Issue라는 기능이 있다. 이것은 커밋과는 다르게 팀원들이 무슨 기능을 업데이트 했고, 무슨 버그가 터졌는지 등을 기록할 수 있게 하는 영역이다.
팀장은 이 Issue에 대한 초기 설정을 해 줄 수 있다.
4.1 Issue templates 설정
Setting의 General 하단에 보면 Issue template 에 대한 초기 설정이 가능하다.
초기에는 이와 같이 비어 있는 것을 확인할 수 있으며, 여기서 초기 템플릿을 추가하면 된다.
상황에 따라 다양한 템플릿을 만들 수 있으며, 우선은 Feature request와 Bug report만 추가해주자.
템플릿을 생성하면 위와 같이 기본적으로 내용이 작성되어 있는 템플릿이 만들어지며, 해당 영역을 더블클릭하면 내용을 수정할 수 있다.
정해진 양식에 따라 초기 템플릿을 설정해주면, 팀원이 Issue를 명확히 작성하는 데에 도움을 줄 수 있다.
4.2 Labels
이제 이슈를 작성할 때에도, Label을 달 수 있다.
어떤 라벨들이 있는지 확인해보자.
기본적으로 제공되는 라벨도 다양하며 새로운 라벨도 만들 수 있다.
이와 같이 새 라벨을 추가하고 이슈 작성 시에 활용할 수 있다.
라벨로 해당 이슈가 어떤 이슈인지 표기하고, 중요도 등을 가시화하는 데 도움을 줄 수 있다.
5. Project
프로젝트에 대해서 알아보자.
프로젝트는 해당 유니티 프로젝트의 제작 일정이나 진척도, 이슈 등을 한 눈에 볼 수 있게 정리할 수 있는 기능이다.
권한이 있는 모든 협업자들은 이 프로젝트를 열람할 수 있으며 필요한 일정 등을 기록하거나, 기간 등을 설정할 수도 있다.
<예시 이미지-Kanban형>
6. 프로그래밍 작업 절차(UML 다이어그램)
6.1 프로그래밍 과정 5단계
프로그래밍을 시작하기에 앞서 설계를 하는 단계는 매우 중요하다. 무작정 코드만 적어내려가며 생각나는 기능을 그때그때 만들면 난잡하고 복잡한 코드가 되어버리기 때문이다.
따라서 프로젝트 시작 단계에서 설계를 하고 가는 과정은 중요하며, 귀찮지만 공들여야 할 부분이라 할 수 있다.
그러면 이런 설계 단계가 어떻게 이루어지는지 알아보자.
1. 인지
구현해야 할 프로그램의 요구사항을 정확하게 인지하고 나열한다.
예를 들어, 플레이어 캐릭터를 구현하라는 과제를 받게 되면, 먼저 플레이어가 가져야 할 기능에 집중해 보도록 한다. 이동이 필요한지, 공격을 해야 하는지 등의 전체적인 기능과 동작에 대해 나열해 본다.
2. 분석
인지 단계에서 나열된 정보들에 대한 세부내용을 정리한다.
문제의 입력과 출력, 데이터 형식을 식별하고 해결을 위해 필요하다면 추가 요구사항이나 제약사항을 고려해야 한다.
3. 설계
이전 단계를 통해 도출된 데이터를 기반으로 '기능의 절차를 단계적'으로 기술한다.
이는 '알고리즘'을 작성한다고 표현하며, 흔히 상향식 설계 방식에 따라 작성하는 것이 선호되고 있다.
4. 구현
이전 단계에서 설계한 알고리즘을 '프로그래밍 언어로 기술'한다.
이 과정을 코딩, 혹은 구현이라고 표현하며, 사용하는 언어의 구문으로 변환한다.
5. 검증
구현된 프로그램과 코드를 구동하고 테스트하고, 디버깅 과정을 거친다.
6.2 설계 과정이 필요한 이유
설계 과정을 거치지 않은 코드는 필연적으로 잠재적인 문제를 동반하게 된다. 크게, 아래와 같은 문제점이 발생할 수 있다.
1. 객체의 의존도가 상승한다
설계를 거치지 않고 객체를 필요할 때마다 생성할 경우, 특정 객체에 과도한 역할 및 데이터가 몰리는 경우가 발생할 수 있다. 이렇게 많은 객체들이 하나의 객체에 의존하게 되는 형태에서, 그 중심 객체를 갓 오브젝트(God Object)라고 칭한다.
이런 갓 오브젝트가 만들어지게 될 경우, 갓 오브젝트의 내용을 수정할 경우 다른 모든 객체의 내용을 수정해야 하는 등의 문제가 발생한다.
2. 객체의 책임을 생각하지 않은 무분별한 기능추가가 진행된다
하나의 객체가 오직 하나의 책임을 가지는 것은 객체지향의 핵심 원칙중 하나이다.
정확한 설계 없이 프로그래밍을 진행할 경우, 무분별한 기능추가로 인해 단일책임 원칙을 위배할 가능성이 높아지며, 이는 확장기능 추가를 어렵게 한다.
3. 팀원과의 협업을 힘들게 한다
사전에 약속되지 않은 코드와 객체는 코드의 가독성을 떨어뜨리고, 코드의 작성의도와 의미를 이해하기 위해 많은 시간을 들이게 한다.
코드에서 문제가 발생했을 때, 몇 백 줄에 달하는 코드를 다른 팀원에게 리뷰하게 하는 것보다, 설계 단계에서 작성했던 구조를 보여주면서 어디서 문제가 발생했는지 파악할 수 있다면 문제 해결을 위한 시간을 단축할 수 있을 것이다.
이와 같은 이유로 설계 과정은 필요한 것이며, 다양한 UML 중 두 가지에 대해 알아보려고 한다.
6.3 클래스 다이어그램
클래스 내부의 정적인 내용이나 클래스 사이의 관계를 표기하는 다이어그램이다.
시스템의 일부 또는 전체의 구조를 나타내며, 의존관계를 명확히 보여준다.
다이어그램을 통해서 순환의존이 발생하는 지점을 찾아낼 수 있으며, 어떻게 이 순환고리를 깨는 것이 가장 좋은지 결정하게 해줄 수 있다.
<옵저버 패턴 클래스 다이어그램>
이런 다이어그램을 작성하기 위한 유용한 프로그램을 링크로 남겨놓는다.
- draw.io
https://app.diagrams.net/
- 연관관계 예시 : 플레이어와 무기 (플레이어가 무기를 가지고 있고 사용할 수 있으며, 지속적으로 사용함)
- 의존관계 예시 : 플레이어와 몬스터 (플레이어가 몬스터에게 공격받았을 때, 데미지를 받는 행위만 짧게 일어남)
- 일반화 관계 예시 : 모든 상속 관계, 몬스터-슬라임 / 몬스터-드래곤 등등.
모든 몬스터는 플레이어의 데미지를 받을 수 있다. (부모의 기능을 모든 자식들이 가지고 있음) - 실체화 관계 예시 : 인터페이스 관계, IDamageable
- 합성 관계 예시 : Player를 부품처럼 나눔 - PlayerMover, PlayerAnimator, PlayerAttacker ...
플레이어가 사라지면 해당 부품들도 사라짐 - 집약 관계 예시 : Player의 공격범위
6.4 액티비티 다이어그램(플로우차트)
작업을 어떤 순서로 진행하는지 표시해주는 시각적 표현이다.
클래스 다이어그램보다는 비교적 작성이 간단하며, 플로우 차트를 통해 세부 계획을 들어가기 전 빠르고 명확하게 프로세스를 확인할 수 있다.
복잡한 구조를 그림으로 표현하기 때문에 다른 사람이 보더라도 쉽게 이해할 수 있기 때문에, 기획자들이 이런 식으로 플로우 차트로 개요를 전달할 수도 있다.
플로우 차트 관계도를 설명한 도형은 아래를 참고하면 좋다.
참고자료
-깃허브 프로젝트 사진
https://zdnet.co.kr/view/?no=20220801103345
