개요
내 포트폴리오가 부실한 이유는 눈여겨볼만한 프로젝트 기록이 없는 것도 있겠지만
그것은 여태 진행했던 프로젝트가 엉망진창임의 반증이기도하다.
실제로 마감기한에 맞추어 급하게 완성하느라,,, 소수 혹은 1인개발로서 컨벤션 통일보다 그때그때 물어가며 개발한다던가,,,해서 기존 프로젝트들 깃허브 링크를 자랑스럽게 보여주기 어려웠던 것 같다ㅠㅠ
그래서 이번 기회에 관용적인 유니티 파일구조와 컨벤션을 익히며 졸업전시 코드를 리팩토링하는 시간을 가지겠다.
https://www.youtube.com/watch?v=zMcf4qkh75Y&t=379s
엔케이 스튜디오라고 실무경험도 많으시고 작업을 할때 근원적인 부분을 좀더 중시하는 분이라 이론공부하며 많이 참고한 유튜브다! 오늘은 이 분 영상을 가지고 학습하겠다.
Project 구조관리
아키텍처
아키텍처를 공부하면 흔히 나오는 말이 파일을 계층형으로 분리할지, 도메인형으로 분리할지에 대해 고민한다.
계층형이란 어플리케이션에서 사용하는 계층별로, 개발 기능적으로 구분하는 방법이고,
도메인형이란 기획적으로, 구어적으로 구분되는 도메인들 즉 UI, player, enemy01 등으로 구분하는 방법이다.
영상에서 소개하는 프로젝트 파일구조 표본을 보면 도메인형을 기본으로 하되 도메인별로 그래픽작업과 재사용할 프리펩, 코드스크립트별로 개발 효율성을 생각한 계층을 나눠놓은 것을 볼 수 있었다.
유니티도 결국은 클라이언트 프로그래밍 툴이기 때문에 보여지는 오브젝트에 따라 구분하고 오브젝트별로 로직이 들어가니 그에 맞춰 분업하려면 이런 방식이 타당한것 같다.
 |  |
|---|
- Game Resources : 일반적으로 팀 이름을 표기, 없을 경우 Game Resources 그대로 사용
- Asset Type : 에셋 종류를 작성한다 UI, plyaer, Enemy, Effect 등이 있다.
- Asset Title : 해당 에셋의 정식 이름을 작성한다. ReRe(캐릭터이름), Portal(포탈이펙트)
- 에셋 종류 -> 타이틀로 들어가는 도메인구조는 좀더 폴더 뎁스가 들어가도 상관없을 것 같다.
- Art : 그래픽 리소스들을 모아서 관리
- Audio : 음향 리소스 (카테고리 또한 자기가 필요한 만큼 분리해서 사용! 다른 사람이 보기에 직관적이면 됌)
- Plugins : 외부에셋 관리
- Scenes : 씬들
- Scripts : 특정 도메인에 속하지 않는 스크립트 파일들
- Settings : 스크립터블 오브젝트나 따로 만든 세팅파일
지양해야할 네이밍
라고 한다.
따로 설명해주지 않아서 간단히 공부해보니 유니티 내에서 Resources 키워드가 붙으면 빌드 시 해당 파일들을 메모리에 포함시키기 때문에 빌드 시간이 의도치 않게 늘어날 수 있고,
사용되지 않는 파일이더라도 메모리에 상주해 있을 수 있기 때문이다. 그러니 특별한 이유없이는 위와 같이 활용해서는 안된다.
script 인코딩 방식 문제
windows-949
C#은 다른 언어들에 비해 비교적 한글을 활용하기 적절한 언어이다. 하지만 windows에서 VS를 사용하면 유니티가 자동으로 windows-949포맷으로 텍스트를 생성하게 된다.
나는 여러 환경에서 작업을 했었는데 클론과정에서 이렇게 주석들까지 깨진 모습을 확인 할 수 있다.
참고로 공개된 위 ip는 전시때 활용하고 이미 릴리스한 ip이다 ㅎㅎ
이렇게 복구를 할 수도 있지만 파일 일일히 처리하기가 애매할 경우
https://rito15.github.io/posts/unity-editorconfig-encoding/
이 블로그에서 소개하는 대로 editorconfig 파일을 따로 생성하여 일괄 처리해줄 수 있다.
졸전 프로젝트에 적용
이미 개발을 완료한 프로젝트이지만, 앞으로 개발을 해나가야한다는 관점에서 생각한다면 결국 파일구조를 정리하는 이유는
- 필요한 에셋의 위치를 기억 없이 네이밍만 보고 폴더를 찾아갈 수 있게
- 여러 폴더를 뒤적거릴 필요없이 하나의 개발에 딱 정해진 폴더들만 열어두고 사용하는 편의성을 위해
라고 생각한다. 그에 맞춰 리팩토링 하고자 한다.
당시 후반갈수록 마감에 쫒겨 파일관리없이 우선 기능만 구현하자 했던 최후가 이렇게 남아있다.... 엉망진창인 모습 ㅎㅎ
도시의 모습이 총 세가지로 나뉘어 보여졌어야 했기 때문에 각각의 에셋을 도시 모습별로 나누어 관리했었다.
그래서 각 색깔의 도시모습에만 필요한 오브젝트가 있고, 기본적으로 모든 도시모습에 사용되는 오브젝트가 있어서 이 구분에 고민이 되었다.
그렇다고 City라는 상위폴더에 범용에셋을 위치시키고, 아래 폴더인 Gray City에 나머지 에셋을 위치시키는건 컨벤션에 위반된다고 생각하여 Only와 Variable라는 키워드로 구분하였다.
그리고 얼마나 디테일적으로 폴더를 줄일지, 하나로 합쳐서 관리할지도 고민되었는데 너무 줄여도 작업할때 번거로울 것 같아서 그 편리성을 기준으로 적당한 선을 찾아갔다
예를들어 Gray City의 씬에 Lab이라고 명명한 구역이 있다. 
이 씬에는 여러 꾸미기용에셋이 들어가고, 소소한 애니메이션들도 들어간다. 하지만 이 구간을 꾸미기 위한 에셋들은 다른 곳에서 쓰이지 않기 때문에 개발 시 편의를 고려하여 한번에 폴더링 해보았다.
또한 스크립트 중에서는 씬에 배치된 에셋을 움직이는 코드말고도, 안개와 같은 enviroment 값이나, 서버에서 받아오는 api를 관리한다던가하는 코드들이 있다.
이들은 따로 빼내어 Controller라고 아예 계층을 구분하였고 그 안에서 도메인을 나누어 Main Sphere Controller, Game Manager 등으로 명명하여 관리하고자하였다.
또한 Dto와 같이 아예 도구적으로 활용되는 클래스는 가장 바깥에서 따로 관리하고자 했다.
개발 당시엔 달마다 월간 보고서 작성도 해야했고, 중간 전시도 끼여있었기 때문에 이런 부분을 언제 신경쓰고 있냐~ 하면서 등한시 했었는데..
막상 정석대로 공부하면서 리팩토링까지 해보니 얼마나 미련하게 시간낭비를 했는지 모르겠다.
프로젝트 초기에 좀만 더 투자해서 틀을 잡아 두었다면 디자이너가 에셋 뿌려다 줄 때 확실히 관리할 수 있었을텐데 와닿는다
