이 글은 유니티 자습서의 Best Practices 문서 중 Resources Folder를 번역/의역한 것입니다.

Resources 폴더

이 글은 “유니티5의 에셋과 리소스 관리” 시리즈의 3번째 글입니다.

이 챕터는 Resources 시스템에 대하여 다룹니다. 이 시스템은 개발자가 여러 에셋들을 Resources 폴더에 두고 런타임동안 Resources API를 통해서 에셋을 로드/언로드할 수 있도록 해줍니다.

2.1 Resources 시스템을 위한 실용 가이드

사용하지 마세요.

다음과 같은 이유들로 사용하지 않기를 강력하게 권고합니다

• Resources 폴더를 사용하는 것은 메모리 관리를 더욱 복잡하게 만듭니다.

• Resources 폴더를 부적절하게 사용하면 어플리케이션 시작 시간과 빌드 시간을 늘리게 됩니다.

• Resources 폴더들이 많아지면 그 안에 있는 에셋들의 관리가 힘듭니다.

• Resources 시스템은 사용자 정의 컨텐츠를 특정 플랫폼으로 옮기는 것이 까다로워집니다. 컨텐츠를 업그레이드하는 경우도 마찬가지입니다.

• 디바이스에 맞는 컨텐츠를을 조정하는데 적합한 주요 기능은 에셋번들입니다.

2.2 Resources 시스템의 적절한 사용

다음과 같은 두 가지의 경우에는 개발 시 Resources 시스템을 사용하기에 적합한 경우입니다.

1. 빠른 프로토타이핑이나 검증이 필요한 경우에는 Resources를 사용하기에 좋습니다. 간단하고 사용하기 쉽기 때문입니다. 하지만, 프로젝트가 프로덕션 단계에 가게 되면 Resources 폴더 사용을 중단해야 합니다.

2. Resources 폴더는 다음 모든 경우를 만족하는 상황에서는 유용한 시스템입니다.

• Resources 폴더에 들어있는 컨텐츠들은 메모리에 민감한 것 들이 아닐 경우

• 컨텐츠가 어플리케이션의 수행 시간 동안 계속 필요한 경우

• 컨텐츠가 패치될 일이 거의 없는 경우

• 컨텐츠가 플랫폼이나 디바이스별로 달라지지 않는 경우

이 중 두 번째 케이스에 해당하는 예시는 전역으로 사용되는 싱클턴 모노비헤이비어나 페이스북 앱 ID등의 서드파티 데이터를 다루는 에셋등이 될 것입니다.

2.3 Resources의 시리얼라이제이션

프로젝트 빌드 시 “Resources” 폴더 내 모든 에셋과 오브젝트들은 하나의 시리얼라이즈된 파일에 정보가 담깁니다. 이 파일은 에셋번들처럼 메타데이터와 인덱싱 정보를 포함합니다. “에셋번들 의 근본”챕터의 “에셋번들이란 무엇인가?” 섹션에서 설명된 바와 같이, 이 인덱싱 정보는 시리얼라이즈된 룩업  트리를 포함합니다. 여기에는 주어진 오브젝트 이름을 파일 GUID와 로컬 ID와 매칭시키는데 쓰이는 정보들을 포함합니다. 오브젝트를 시리얼라이즈된 파일의 몇 바이트째 위치시키느냐등의 정보도 포함합니다.

룩업 데이터 구조가 균형잡힌 탐색 트리라서 구축 시간 비용은 O(N log(N)) 비율로 증가합니다.(대부분의 플랫폼에서는 C++ Standard Template Library의 std::multimap를 사용합니다.) 여기서 N은 트리에 들어가는 오브젝트 갯수를 의미합니다. 이러한 증가치는 인덱스의 로딩 타임에 많은 비용이 들게합니다. 따라서 Resources 폴더 안의 오브젝트들이 많을수록 성능에 좋지 않습니다.   

이 동작은 건너뛸 수 없기때문에 어플리케이션의 초기 시작 시간을 늘리게 되서 인터렉션이 불가능한 스플레시 화면이 떠 있는 시간이 길어지는 요인이 됩니다. 특히 저사양 기기일 수록 Resources 시스템에 많은 오젝트가 포함되있으면 어플리케이션 시작 시간이 매우 길어지게 됩니다. 특히, Resources 폴더의 대부분의 오브젝트들이 첫 씬에서 보여질 필요가 없는 경우에는 효율적이지 못한 상황이 되는 것입니다.

게임을 개발하는 과정에서 콘솔 로그를 출력하는 것은 필수적입니다. 당연히 유니티에서도 로그를 출력하는 함수가 존재하고 Debug.Log()를 많이 사용하시죠.

Manual : https://docs.unity3d.com/ScriptReference/Debug.Log.html 

근데 많이들 오해하시는게, 이 Debug.Log 함수는 Debug클래수 함수니까 Development Build일 때에만 작동하고 릴리즈 빌드때는 자동적으로 제거된 다고 오인하시는 것입니다. 콘솔 출력용으로 남발해서 사용되도 최종 릴리즈에는 영향 미치지 않는다고 오인하시는 경우가 많습니다, 하지만 아쉽게도 그렇지 않습니다. Debug.Log()는 릴리즈 빌드때고 고스란히 작동합니다. 따라서 쓸데 없는 성능을 쉽게 잡아먹는 녀석중 하나가 되버리죠.

예를 들어서 다음과 같이 콘솔 출력용 로그를 수없이 찍는 코드를 만들고

public class TestLog : MonoBehaviour {

public int logCount = 500;

public string testStr;

void Update () {

for( int i=0; i< logCount; i++) {

UnityEngine.Debug.Log("test log : " + testStr + "!" );

}

}

}

빈 프로젝트에서 위 코드만 돌린 프로젝트를빌드하여 홍미 폰에 띄우니 30FPS로 돌아갑니다. 디벨롭먼트 빌드가 아닌데도 불구하구요. 물론 실제로 매 프레임마다 500번의 출력을 하는 경우는 실존하지 않을 것입니다. 테스트를 보여주기 위하여 극악의 상황을 만들어본 것 뿐입니다. 다만, Debug.Log()가 쓸데 없이 작동하는 것을 증명하기에 충분한 코드겠지요. 

이러한 쓸데없는 행위를 막기 위해서 #if 디파인문을 많이들 사용하십니다. 다음과 같이요

#if TRACE_ON

UnityEngine.Debug.Log("test log : " + testStr + "!" );

#endif

이렇게 두고 플레이어 셋팅의 Scripting Define Symbols이나 .rsp 파일에 TRACE_ON을 추가하한 경우에만 수행되고 아닌 경우에서는 Debug.Log()가 수행되지 않고 60FPS가 잘 나옵니다.

Manual : https://docs.unity3d.com/Manual/PlatformDependentCompilation.html

이제 문제가 전혀 없습니다. 없을까요? 

있습니다. 귀찮은게 문제지요.

Debug.Log()를 출력하는 곳이 한두군데도 아니고 매번 작성할 때 마다 #if #endif로 묶으려면 매우 귀찮습니다. 게다가 실수로 잘못 묶으면 짜증이 짜증이 아휴~

대안으로는 Conditional를 사용하시면 편합니다. Debug.log()를 래핑하는 클래스를 만들고 함수에다가 Conditional를 선언하면 됩니다.

using UnityEngine;

using System.Collections;

using System.Diagnostics;

public class TestLog : MonoBehaviour {

public int logCount=500;

public string testStr;

[Conditional("TRACE_ON")]

void DebugLogWrap( string str) {

UnityEngine.Debug.Log(str);

}

void Update () {

for( int i=0; i< logCount; i++) {

DebugLogWrap("test log : " + testStr + "!" );

}

}

}

TRACE_ON 디파인이 켜져있지 않는 경우에는 DebugWrap을 호출하는 라인이 통채로 무시됩니다. 따라서 #if 디파인을 매번 사용하지 않고도 같은 효과를 볼 수 있습니다. 사실 저도 얼마 전에 알게 된 것인데 굉장히 편하네요 ㅋ C# 짱짱맨 :)

MSDN : https://msdn.microsoft.com/en-us/library/4xssyw96(v=vs.90).aspx

궁극적으로는 다음 링크처럼 사용하시면 됩니다 : 

https://gist.github.com/kimsama/4123043

끗!

어느 날 자고 일어나니 다리가 넷 아니 뜬금없이 두통이 생겼다. 혹시 생일날 선물 안사줬다고 나 자는사이에 몰래 뒷빡 갈긴건 아닌가 하고 와이프를 추궁해봤지만 지는 결백하댄다. 내년 생일도 쌩까야지 하고 소심하게 다짐하면서 냅뒀는데 계속 두통이 사라지질 않는 것이다.

참다 못해 동네 약국에 갔더니 약사 아재는 쿨하게 두통약을 던져주더라. 허나 두통약을 먹어도 그때 뿐 여전히 두통은 심해져만 갔다.

이등병의 남은 군생활마냥 두통이 계속 사라지지 않자 일주일째 지속되던 날 결국 회사 근처 아무 내과에 들렀다. 의사 아재는 내 설명을 차근차근 듣더니 갑자기 윗도리를 벗으랜다. 그러고는 내 등 뒤로 가서는 등짝 등짝을 보잔다. 머리아프다는데 웬 등짝이지 이게 뭔 피카츄 파이어볼 쏘는 소린가 내가 역시 마성의 게이라서 노말벡터도 바이노말벡터로 만들어버린건가 싶었지만, 너무나도 당당한 의사 아재의 눈빛에 그만 등짝을 내주어버리고 말았다. 

비루한 내 염통은 눈치도 없이 쫄깃해지며 발랑발랑 거리던 순간 아재의 보드라운 손길이 내 등짝과 목덜미를 어루만졌고 나는 그만 비명인지 신음인지 모를 단말마의 비명소리를 내지르고 말았다. 

아프다. 분명 갱킹을 갔는데 뜻하지 않게 렝가에게 부쉬칼빵을 맞고 갱승당한 것 마냥 뜻하지 않게 아프다. 분명 머리가 아파서 병원엘 갔는데 등짝이 아프다.

알고보니 이유인 즉슨 이러했다. 나는 사실 머리가 아픈게 아니라 등짝이 아픈거였다. 신경이 등짝부터 머리까지 연결되어있기 때문에 등짝 근육이 뭉쳤는데 애꿏은 머리가 아팠던 것이였다. 그러니 두통약을 쳐먹어봤자 발업 안한 저글링마냥 스팀팩 없는 마린새끼마냥 골골댔던 것이였던 것이였다.

의사 아재의 안내대로 피카츄 전기 공격으로 등짝을 몇 분 맛사지 해주니 두통이 대통령 선거 공약같이 말끔히 사라졌다.

마냥 신기했다. 처음에는 마냥 신기했는데 곰곰히 생각해보니 내가 곰이네 아니 곰곰히 생각해보니 의사 아재는 훌륭한 필드 엔지니어였다. 비록 내 몸뚱아리는 신이라는 개발자가 자연의 섭리라는 거대한 플랫폼 하에 만들어낸 것이지만, 의사 아재는 시스템을 정확히 이해하고있는 통찰력으로 내 몸뚱아리를 너 로맨틱 성공적으로 디버깅 한 것이다. 그렇기에 그의 눈빛은 자신감에 차있었으며 나는 그 자신감 넘친 눈빛에 매료되어 등짝을 내주고 말았다.

하지만 나는 어떠한가? 나는 시스템을 깊이 이해하는 통찰력을 가지고 코딩을 해왔는가? 난 그저 머리아프다고 무조건 두통약을 내어준 동네 약사와 다를 바 없이 디버깅하지는 않았는가? 

많은 고민을 하고 나를 돌아보게 만들어준 두통이였다.

(페북에 올렸던 글인데 나름 호응?이 좋아서 백업 ㅋㅋ)

게임 수학을 다루는데, 다른 서적들보다 난이도를 낮게 잡고 있으며 유니티 예제들로 직접 확인을 해 볼 수가 있습니다.

원고 참여는 안하였고 감수로만 간간간간간접적으로 참여했습니다 :)

링크 : http://www.yes24.com/24/goods/30119802?scode=032&OzSrank=9

제목 그대로 텍스쳐와 모델링에 중점. 

TA 혹은 그래픽스 프로그래머라면 필수인 것 같습니다.

참여 원고 :

- 텍스쳐 압축 이해하기

링크 : http://vielbooks.com/215