오르카의 아틀리에


Unity 2017.3의 새로운 피쳐 중 스크립트 컴파일 및 어셈블리 정의 파일(Script compilation and assembly definition files 이하 SCADF)이라는 것이 생겼습니다.


이 시스템을 도입한 이유는 '유저에게 스크립트가 어셈블리로 컴파일되는 방법을 정의하게 하고, 컴파일 결과물을 분리할 수 있게 만들어 결과적으로 컴파일이 필요한 구획만 컴파일해 컴파일 시간을 줄이고 싶다!'라는 이유입니다.


일단 말로 들었을 때 정말 어썸한 기능입니다. 프로젝트가 커져서 많은 스크립트를 들고 있으면 자연스럽게 컴파일 타임이 늘어나게 됩니다. 이 시스템을 도입하면 컴파일 타임이 줄어들 것이라고 기대됩니다. 흔히 격는 코드 수정 후 유니티 하단에 동글뱅이가 돌아가는 시간이 줄어든다는 것이죠.


그래서 한번 이 기능을 조사&사용해보았고 후기를 공유하고자 합니다.



이 기능을 한마디로 정리하면,

리스크가 있는 기능이다!

라고 할 수 있습니다.



Example

인터넷에 떠도는 예제가 있습니다. 여기에서 다운받아서 실행해 보실 수 있습니다.


예제를 간단하게 설명하면 다량의 코드를 많이 만들고 그냥 컴파일하는 시간과 SCADF를 이용해 컴파일하는 시간을 비교한 것입니다. 각각 최악의 경우와 최상의 경우가 있습니다.



프로젝트를 다운받고 실행해보면 위와 같은 탭이 하나 있을 것입니다.



Interdependent Scripts


interdependent는 최악의 경우입니다. 코드를 보면 아시겠지만 60개의 메소드를 가진 800여 라인의 스크립트 파일을 15개씩 15개의 폴더로 구분해서 생성합니다. 컴파일 타임은 저의 맥북 기준으로 9초였습니다.


컴파일 타임을 확인했다면 Assembly Definition Files를 만들어 줍시다. 만들게 되면 동시에 .scadf파일이 만들어지고 컴파일을 진행합니다. 초기 컴파일이 저의 맥북 기준으로 21초가 걸렸군요. 컴파일 타임이 약 2배 조금 넘게 증가했습니다.


하지만, 주목할 점은 edit and compile 타임이겠죠? 일단 0번째 스크립트들을 살짝 변경하고 저장한 뒤 컴파일 타임을 살펴봅시다. 역시 저의 맥북 기준으로 22초 정도 걸렸습니다. 왜 빨라지지 않았을까요?


interdependent는 15개의 폴더간의 종속성이 일렬로 구성되어있습니다. 1번째 폴더의 스크립트들은 0번째 스크립트를 알아야하고, 2번째 폴더의 스크립트들은 1번째 폴더의 스크립트들을 알아야합니다. 결과적으로 2번째 폴더의 스크립트는 0번과 1번을 전부 알아야겠죠?


그렇다면, 결과적으로 0번째 스크립트들을 알아야하는 친구들은 0번을 제외한 나머지 전부가 됩니다. 때문에 0번째 스크립트가 업데이트 되면 0번을 알아야하는 친구들이 전부 업데이트되어야할 것입니다. 그림으로 나타내면 다음과 같겠죠. 특정 노드에 업데이트가 일어나면 화살표로 연결된 친구들도 컴파일 되어야할겁니다.





그럼 14번째 스크립트를 건들면 어떻게 될까요? 저의 맥북 기준으로는 7초가 나왔습니다. 연결된 하위 노드들이 없으니 자기 자신만 컴파일 하면 되겠지요. 12번째 스크립트를 건들면 9초가 좀 넘게 나왔습니다. 즉 그 이상으로 올라가면 원래 컴파일 타임보다 늘어나니 손해라는 계산이 나오네요.



Independent Scripts

independent는 최상의 경우입니다. 말 그대로 스크립트 간의 종속성이 없기 때문에 SCADF의 특성을 최대한 살릴 수 있습니다.


컴파일 타임은 마찬가지로 9초였습니다. Assembly Definition Files를 만들어 줍시다. 만들고나면 0번째 스크립트를 고쳐봅시다. 결과가 어떨까요? 저의 맥북에서는 6초 정도 컴파일 타임이 기록되었습니다. 약 2/3로 줄어든 것을 볼 수 있습니다. 원리를 이해하셨을 테니 그림을 보면 이해가 가실 겁니다.



그 어느 스크립트를 수정하더라도 종속성이 걸린 친구들이 없기 때문에 추가 컴파일이 일어나지 않기 때문에 컴파일 타임이 줄어든 것입니다.



결론

결론을 쓰자면 최상의 경우에는 확실히 컴파일 타임에 이득을 볼 수 있습니다. 하지만, 실제로는 스크립트별로 종속성이 묶여있을 수밖에 없습니다. 그럼 해결책은 무엇일까요?



네, 좋은 경험이라고 생각하고 잘 나누셔야 합니다.... 종속성 같은 경우는 프로젝트별로 다 다르기 때문에... 어썰수가... 그래도 가이드라인이라면 Standard Asset같은 절대로 건드이지 않을 것 같은 친구들을 위주로 한 묶음 묶어버리면 컴파일 타임이 줄어든다고 합니다. 이것도 그런 에셋들이 많다는 가정하에 갰지요...