2025-11-24 version control

버전 컨트롤

프로젝트 버전별 관리의 필요성

날짜가 지나면서 프로젝트에 어떤 변화가 있고 어떤 기능을 추가했는지에 대해서 기록을 하기 위해 버전 컨트롤을 사용함

 

GitHUB가 버전 컨트롤에 있어서 기록이 눈에 띄게 잘 남고 많이 사용하는 git 저장소

 

1.     깃허브에 리포지토리 만들어 업로드 저장소 설정

2.     유니티 프로젝트 세팅에 version control 옵션

프로젝트가 외부 버전 관리 시스템과 어떤 방식으로 파일 변화를 추적할지

결정하는 설정

 

메타(meta -> GUID 연결 table) 데이터 처리 방식과 어떤 버전 관리 시스템을 쓸지 확인

 

Perforce: 퍼포스로 버전관리 하는경우 사용, 체크아웃 자동제어 등이 가능함

 

Visible meta files: 모든 어셋에 대해서 메타 파일을 프로젝트 폴더에 생성하여 외부 버전관리 시스템에서 추적 가능하도록 함

Meta file이 있어야 GUID를 통한 각가지 컴포넌트 연결이 가능하므로 github, svn와 같은 버전 컨트롤을 사용할시에 사용해야 할 옵션

 

Hidden meta files: 메타파일을 os에서 숨김 처리하여 프로젝트를 생성함

Meta 파일이 내부적으로는 존재하지만 파일 공유시 깨지므로 버전 관리에서는 맞지 않는 방식

 

 

 

Project settings -> Edit

에서 Asset Serialization

유니티에서 어셋을 어떤 형식으로 저장할것인지에 대한 옵션임

 

Force text

어셋(씬, prefab, material, animation)을 TEXT 기반 YAML로 저장

Text로 저장되기 때문에 git에서 diff툴을 사용할 때 어디 부분이 변경되었는지 정확하기 확인하기 편함

Merge시 Yaml을 병합할 때 텍스트 기반으로 가능함

GUID 구조가 명확하게 보임

 

Force Binary

텍스트 기반이 아닌 바이너리 파일 기반이기 때문에 읽기 속도 등이 빠름

파일 크기가 조금 더 작다

하지만, diff를 통한 분석이 명확하게 어렵고 사람이 분석하기 불가능함

또한 merge할때 병합 불가능하며 무조건 덮어 씌우는 형태로 처리되어야 함

è  텍스트 기반 버전 컨트롤에서 어떤 구조로 되어 있는지 파악하기 어려우므로 사람이 어떤 값을 머지하고 추가 삭제할지 처리하기 어렵다

Git의 병합 알고리즘은 LCS(line based merge)인데 YAML은 텍스트 단위로 데이터 처리가 되어 어떤 줄을 바꾸었는지 판단이 가능함

ex)

position:

  x: 1
  y: 2

이렇게 필드가 보이므로 Git이 변경 지점에 대해서만 병합 등이 가능함

바이너리의 형식은

 

ex)

0A 92 FF 00 0D 3A 01 00 0F 99 ...

 

 

로 되어 어디까지 material를 나타내고 어디까지 Transform 등을 나타내는지 어려움

바이너리 형식은 텍스트처럼 체계적으로 해당 섹션이 나누어져 있는게 아니라 전체적으로 파일이 뒤섞여서(한 줄 수정 같은 처리가 아님) 보이게 됨(이진 파일의 바이트 처리, padding 값 변경 등의 부가적인 처리가 발생함)

즉 일부가 바뀐 형태로 보이는게 아니라 파일 전체가 바뀐 형태로 보여지게 됨

Line based로 변경이 안된다는 이유가 가장 크다.

è   판단이 어려우므로 merge 알고리즘 동작이 어려워 그냥 덮어 씌우는 방식으로 작동함

 

 

Mixed

Text랑 binary 둘이 섞어서 사용함

대부분 YAML로 저장하며 복잡한 파일들은(animation, audio 등)바이너리로 저장

완전한 머지가 어렵고 어떤 파일이 바이너리로 처리되는지 예측하기 어려움-> 불안정

사용하는 경우는 프로젝트의 크기가 커서 경량화를 하거나 할 때 사용

하지만 크게 유의미하진 않고 text 기반으로 어셋을 처리하는게 훨씬더 이득이므로 일반적으로 force text 모드를 사용하는게 좋다.

 

과거 유니티 엔진의 발전 과정 역사에 따라서 모드가 나뉘어져 있고 과거 프로젝트 등을 지원하기 위해 프로젝트 어셋 관리 모드 등을 나누어 놓았다.

과거 유니티 에셋 처리는 binary로 처리되어 버전 컨트롤 등에 불편함이 있었는

유니티 4.0부터 asset text 모드를 지원하여 보다 편하게 만들어 놓음

지금까지도 지원하는 이유는 과거에 만들어 놓은 legacy 프로젝트도 지원하기 때문임

혹은 용량이 매우 큰 대규모 프로젝트의 경우 바이너리 형태로 어셋을 관리해야 캐싱 및 I/O 처리에 유리한 경우도 있기 때문에 일부 사용하기도 함

---

 

게임 개발시 animation compression, Texture import settings등의 처리가 중요하다

일반적으로 디자이너 들은 어셋 등을 만들 때 최대한 높은 퀄리티의 이미지 파일, 텍스쳐 파일, 스무스한 애니메이션 처리를 만들기 위해 노력함

프로젝트 실무에서 어셋 파일등에 대해 용량 등을 제약을 걸지 않거나 하면

후기 작업에 프로젝트 비용(cost)가 매우 높아짐

따라서 초기에 어셋 스펙 가이드라인을 두는 것이 좋다.

 

제한 두는 어셋 종류들

텍스쳐 최대 해상도, 포맷 -> 텍스쳐 용량 gpu 병목

캐릭터 vertex 개수 -> 메모리 -> cpu -> gpu 데이터 이동 병목

Armature Bone 개수 -> 애니메이션 x armature joint 수 * SRT Flops

애니메이션 clip, fps, 길이 제한, 압축 정도 -> 애니메이션 실행 객체 + 용량 제한

오브젝트 서브 메쉬 머터리얼 적용 개수 -> drawcall 제한

LOD 단계, mipmap -> gpu 최적화

VFX 이펙트, 파티클 수 -> 파티클(plane 조각들), 렌더링 입자 개수 증가, drawcall 증가

 

이러한 부분에 대한 기준 규약, 평가 처리하는것이

 

TA(Technical Artist)가 하는 직군이다.

 

1.     하드웨어 타겟 선정

2.     기존 개발 과거 데이터 바탕으로 스펙 지정

3.     만들고자 하는 게임의 사용자층 타겟팅 + 이전 데이터를 바탕을 통한 기술적 한계 명세

4.     어셋 사용 및 제작시 해당 명세에 따라서 재가공 -> 재가공 자동화 처리 등의 도구 등을 만드는것도 TA의 역할이 될 수 있음

5.     아트 직군에서 고퀄리티의 어셋을 먼저 만든 이후에 나중에 기준점에 대한 컴프레션 처리

6.     개발 시작 시 처음에는 기준이 변동이 있을지라도 적어도 2개월 내에는 미래에 개발될 게임에 대해 어느정도 draft를 그리고 해당 기준을 정확하게 선정하는게 나중에 되서 헤매지 않고 비용 등을 절감 할 수 있음 .

---

 

Submesh의 생성의 경우, DCC(digital create contents, maya, blender, 3dsmax) 등에서 관리하고 제작하며 유니티, 언리얼 등의 게임 엔진에서는 제작된 pmx, obj 파일로부터 특정 메쉬에 할당되어 있는 머터리얼에 대한 정보를 불러와 연결 및 사용하는 역할을 수행함

 

SubMesh의 개수에 따라서 cpu ->gpu로 전달되는 drawcall 횟수가 증가하므로 그만큼 하드웨어 리소스를 잡아먹는 시간 및 비용이 커짐

 

---

 

깃허브 desktop을 설치

깃허브 desktop에는 내장으로 GUI 형태로 git을 사용할 수 있도록 되어 있음

 

CMD에서 CLI 환경에서 git을 사용하려면 따로 git을 설치해야 하고, github desktop으로 사용시 그냥 GUI로 사용하면 됨

 

데스크탑에서 리포지토리 생성하면 문서 -> github에 자동으로 해당 리포지토리 디렉토리가 생성됨

 

해당 문서에다가 이제껏 만든 프로젝트를 폴더 안에 던져 놓으면 해당 디렉토리를 git 저장소로서 사용할 수 있음

 

è  Commit 및 push 하여 main에 올리고 branch를 나누어 날짜별로 변경 사항 커밋 푸시하여 github에다가 반영하도록 하면 됨

 

 

 

 

최종적으로 기능 동작이 잘 되는 프로젝트만 main + branch로 나누고

아직 개발 진행 중인 dev에 대해서는 branch로 만 나누도록 하자.

 

https://github.com/backlow/UnityStudy