기록

바이너리와 텍스트(YAML) 비교

비주얼 스튜디오에서 바이너리를 볼 수 있는 확장 툴을 설치해서 해당 파일을 분석해 본다.

프로젝트 설정 중에서 에셋 데이터를 관리하는 방식인 바이너리와 텍스트 두 가지에 대해서 몇 가지 테스트를 해볼 것이다.

두 방식을 비교해 보기 위해서 프로젝트에서 모든 컴포넌트의 데이터가 동일한 오브젝트를 생성해 보고 차이점을 비교한다. 

하이어라키에서 큐브를 생성하고 프리팹으로 만들어 파일을 확인해 본다.

파일의 크기는 3kb이며 파일 내용은 YAML 형식으로 오브젝트의 모든 컴포넌트의 정보가 저장되어 있다.

길이는 100줄 정도 된다.

데이터 내용을 그대로 보아도 어떤 정보를 담고 있는지 파악하기 쉽다.

그대로 프로젝트 세팅에서 Asset Seriailization 모드를 Force Binary로 변경한다.

용량이 더 줄어들었을 거라고 예상했지만 반대로 증가했다.

파일의 마지막은 다음과 같이 정보를 보여준다.

좌측의 메모리주소와 우측의 아스키코드에 대응하는 문자는 편집기의 기능으로 데이터에 포함되지 않는 정보일 것이다.

맨 앞의 8자리 숫자+알파벳의 조합은 16진수로 보인다.

이 주소가 16 단위로 증가하고 뒤에 오는 정보는 8 + 8 총 16으로 정보의 개수를 의미하는 것 같다.

메모리 주소 뒤에 오는 행렬 형태의 정보는 아스키코드로 보이는데 아스키 테이블에서 20은 공백, 3C는 < 로 확인할 수 있다. 따라서 맨 우측에는 테이블에 대응하는 문자를 확인된다.

마지막 주소가 2030으로 10진법으로 변환 시 8240이다. 즉 총 8240개의 데이터가 담겨있으며 파일의 크기가 9kb인 것으로 생각해 볼 때 하나에 1byte로 떨어지고 각 데이터가 아스키코드이므로 1byte라고 생각하면 얼추 맞아떨어지는 거 같다.

파일크기는 9kb로 나오는데 해당 파일을 속성을 열어서 자세히 보면

더 근접한 크기임을 알 수 있다. 

좀 더 정밀하게 계산하면 마지막 줄에는 데이터 4개가 빠져있어서 8236이다. 즉 최종적으로 16byte가 모자라다.

만약 마지막 메모리가 온전히 16을 차지한다고 해도 8240이 최대일 텐데 그래도 12byte가 채워지지 않는다.

어디서 계산이 잘못된 건지 이 부분은 다시 확인해 볼 필요가 있다.

다시 본래의 목적으로 돌아가서 YAML 형식이 바이너리보다 용량이 적은 것은 의문이 들어서 프리팹의 크기를 키워보기로 한다. 기존의 큐브 프리팹에 자식으로 큐브를 추가해서 수정해 결과를 확인해 본다.

바이너리의 경우 768 byte 가 추가되었다.

모드를 변경해서 Text의 크기를 확인해 보니 6kb로 처음 경우에서 2배로 사이즈가 커졌다. 증가량만 따졌을 때는 엄청난 크기 차이가 있다.

몇 번 더 큐브를 추가해 보면서 살펴본다.

프리팹에 오브젝트가 많이 포함되어 있을수록 파일의 사이즈는 확연히 차이가 난다.

게임을 만들다 보면 프리팹 하나에 여러 오브젝트들이 붙어있게 되는 경우는 많기 때문에 거의 일반적으로 Text 모드가 용량이 크다고 보인다.

비교

테스트 결과로 비교해 보면 바이너리를 사용하는 것이 데이터의 크기를 줄여주기 때문에 프로젝트를 열고 데이터를 저장하는 과정에서 시간이 단축될 수 있다.

하지만 유니티를 사용한 프로젝트를 협업할 때에는 바이너리보다는 Text 가 권장된다. Github에서는 공식문서에서 해당 부분에 대하여 Force Text로 설정해야 한다고 명시해 두었다.

Github - Git and Unity

유니티에서도 기본값은 Force Text이며 이렇게 Force Text를 권장하는 이유는 바이너리 형식으로는 파일을 수정하고 병합하는 것이 불가능하다. 따라서 변경된 사항을 파악하는 것이 불가능한데 협업뿐만 아니라 개인 프로젝트 또한 버전 컨트롤을 사용하는 것이 일반적인데 해당 기능을 사용하지 못하는 Mixed 또는 Binary 모드는 더 이상은 사용되지 않는 기능으로 생각된다.

에디터 버전 : 2021.3.28f1 (LTS)

유니티 에디터의 전체적인 설정을 변경할 수 있는 항목이다.

Unity Remote [Depricated]

Android, iOS 등 앱을 개발할 때 사용하기 위한 기능으로 유니티 플레이 모드에서 화면 출력과 입력이 디바이스와 연결되도록한다. 따라서 빌드 이전 단계에서 타겟 디바이스를 통한 테스트가 가능하다.

2020.1 및 이후 버전에서는 depricated 되었으며 Device Simulator Package가 기능을 대신한다.

Device Simulator Package

2020 이후 버전이라면 에디터에 기능이 포함된 상태로 Window > General > Device Simulator 를 통해 사용할 수 있다.

이전 버전의 경우 패키지를 설치해 주어야 창을 열 수 있다.

패키지 매니저를 통해서 설치가 가능하며 이 때 패키지가 검색해도 나오지 않는 경우 

패키지 매니저 창에서 어드밴스 설정에 들어가서 

Pre-release Package 옵션을 활성한 이후에 패키지를 검색하면 찾을 수 있다.

Asset Serialization

프로젝트를 저장할 때 에셋들의 정보를 저장하는 방식에 대해서 설정할 수 있는 옵션이다.

Serialization 옵션에는 세가지가 있다.

Mixed

에셋이 바이너리와 문자열 각각의 저장된 상태로 유지된다. 새로 추가되는 에셋의 경우 바이너리가 적용된다.

Force Binary

에셋을 바이너리로 저장한다. 

임의의 프리팹을 생성하고 파일을 열어보면 바이너리로 저장된걸 확인할 수 있다.

비주얼 스튜디오에서 파일이 열리지 않는 경우 Extensions > Manage Extensions 에서 HexVisualizer 를 설치하면 된다. 이때 실행중인 비주얼 스튜디오는 모두 종료해야 설치가 진행된다.

Force Text

에셋을 문자열로 저장한다.

저장된 정보는 텍스트 기반으로 데이터 직렬화 언어로 많이 사용되는 YAML 형식이다.

프리팹의 정보가 키&밸류 형태로 정리되어있어  바이너리와 달리 사람이 쉽게 읽을 수 있도록 표현되었다.

Force Text 모드에서 프리팹을 생성하고 Mixed 모드로 변경시 기존 프리팹은 텍스트, 새로 생성된 프리팹은 바이너리로 저장된다.

Mixed 또는 Force Text 를 선택한 경우 Serialize Inline Mappings On One Line 토글이 활성화된다.

이 옵션은 참조 및 인라인 맵핑을 한 줄에 쓸것인지 여부를 정한다. 비활성화시 한 줄의 총 문자가 80자 이상이 되면 텍스트가 분할된다.

Default Behaviour Mode

프로젝트를 처음 생성시 2D 또는 3D를 선택하는데 프로젝트 생성 이후에도 해당 설정에서 변경이 가능하다.

유니티에서는 프로젝트가 Full 2D 인 경우 이외에는 모두 3D 로 작업환경을 정할 것을 추천한다.

2D와 3D 설정에는 프로젝트의 몇가지 기본세팅에서 차이가 있다.

2D

- Import 하는 모든 영상은 2D 이미지로 간주되며 Sprtie로 설정된다.

- Scene View 가 2D로 세팅된다.

- 게임 오브젝트가 기본적으로 실시간 Directional light 의 광원을 받지 않는다.

- 카메라의 기본 위치가 0, 0, -10 으로 설정된다.

- 카메라가 Orthographic 으로 설정된다.

- Lighting 창의 옵션의 경우

   * 새로운 씬에 대해서 Skybox가 비활성화

   * Ambient Source 는 Color(54, 58, 66) 로 설정

   * Realtime Global Illumination(Enlighten) 꺼짐 상태

   * Baked Global Illumination 꺼짐 상태

   * Auto-Building 꺼짐 상태

3D

- Import 한 모든 이미지가 2D 이미지로 간주되지 않는다.

- Sprite Packer 가 비활성화된다.

- Scene View 는 3D로 설정된다.

- 기본 게임 오브젝트가 리얼 타임 Directional Light 광원을 받는다.

- 카메라의 기본 포지션은 0, 1, -10 으로 설정된다.

- 카메라가 Perspective 로 설정된다.

- Lighting 창의 경우

  * Skybox 는 built-in Default Skybox 로 설정

  * Ambient Source 는 Skybox 로 설정

  * Realtime Global Illumination (Enlighten) 켜짐 상태

  * Baked Global Illumination 켜짐 상태

  * Auto-Building 켜짐 상태

차이점을 보면 2D에서 3D 작업을 한다고 해서 치명적인 문제가 발생하지는 않는다.

하지만 몇가지 기본 설정들은 각 상황에서만 사용하는 경우가 많기 때문에 맞춰서 작업하는것이 권장된다.

새로운 시작을 위해서 머나먼 타국으로 떠나 있던 누이가 잠시 귀국을 했다.

나의 기준에서는 엄두도 못할 과감한 결단이였기에 걱정이 앞섰지만 종종 전해오는 소식들이 그 결정이 좋은 방향으로 나아가는 듯 보여서 안도가 되면서도 항상 무슨 일을 하기에 앞서 걱정부터 하며 섣불리 행동으로 옮기지 못하는 삶의 태도에 대해서도 다시 한번 생각해 보게 된다.

같은 땅을 밟고 있을때에도 각자의 삶이 이끄는 대로 흘러가다 보면 좀처럼 보기가 쉽지 않다. 이제는 드넓은 바다 저편에서 지내게 되면서 그 만남은 더 어려워졌기에 이번 재회는 아주 귀중한 시간이었다. 

이것저것 챙겨온 선물 속에서도 재밌는 것이 눈에 띄었다.  

치토스 로고를 보고 당연히 과자겠거니하고 그중에서도 맥 앤 치즈맛이라는 생소한 제품일 거라 생각했다.

그래서 퇴근 후 심심풀이로 선물받은 과자나 먹어볼까 하고 포장을 뜯고 내용물을 본 순간 잠시 다음 동작을 이어가지 못했다.

사실 포장을 뜯고나서도 뿌셔뿌셔와 비슷하게 가루를 넣고 흔들어 먹는 과자가 아닐까 잠깐 생각을 해봤지만 너무 나도 날것인 내용물에 뒤늦게 포장지를 살펴보기 시작했다.

언어의 장벽을 기술의 힘을 빌어 허물고 찬찬히 살펴보았고 단순한 과자가 아닌 약간의 조리가 필요한 레트로트 식품이라는 걸 깨달았다. 조리 방법은 냄비에 물을 올려 조리하는 것과 전자레인지를 사용한 두 가지가 있었다.

사실 처음 조리법만 읽고 추가적으로 필요한 재료를 사오느라 두 번째 방법이 있다는 사실은 사진을 다시 보게 되는 시점에서 알게 되었다.

즉시 우유와 버터를 사 와서 조리에 들어갔다.

조리법은 간단했다. 

면을 삶은 후 버터를 녹이고 우유와 동봉된 가루를 넣어 잘 섞어준다.

가루에서는 꼬릿꼬릿한 치즈와 약간의 매콤한 향이 난다. 섞어주다 보면 점점 맥엔치즈 냄새에 가까워진다.

마지막으로 후추를 뿌려서 마무리하고 나니 꽤 먹음직스러워 보인다. 

치토스의 맛은 잘 모르겠지만 일반적인 맥엔치즈 맛이 나고 맥주랑 먹기 좋은 맛이다.

생각보다 양이 많아서 혼자서 다 먹으려니 배가 불렀다. 딱 둘이서 안주 삼아 먹는 게 좋을 것 같다.

뜻밖의 재밌는 선물 덕분에 평범한 일상 속에서 잠시나마 소확행을 즐길 수 있었다.