[유니티] 컴파일링(Compiling)과 어셈블리 정의 (Assembly Definition)

오늘의 키워드

 

• 컴파일링
• Assembly
• IL

---

 

안녕하세요, 오늘은 Assembly Definition에 대해서 공부해보고자 합니다.

 

 

 

컴파일링

 

컴파일링이란 우리가 고급 언어(C#, C++, Java 등)로 작성한 소스코드를 컴퓨터가 실행할 수 있는 (IL/DLL)로 변환하는 작업입니다.

 

 

위와 같이, 새로운 스크립트를 생성하거나 코드 작성 또는 변경 시 하나의 프로세스 진행을 보여주는 다이얼로그 보입니다.

이는 생성 또는 변경한 코드의 컴파일링을 처리를 보여줍니다.

 

 

참고로 유니티에서의 컴파일링 방식은 2가지가 존재합니다.

MONO

IL2CPP

 

또한 위 프로세스 다이얼로그를 살펴보면 크게 4가지 정도의 동작이 발생합니다.

 

 

컴파일을 통해 C# 코드를 IL 코드와 메타데이터를 포함한 어셈블리(DLL)로 생성하고, 이를 로드하여 메모리에 올립니다.

그 후, 유니티의 도메인 환경을 초기화합니다.

---

어셈블리

어셈블리라는 단어를 처음 봤을 때 생각나는 것은 어셈블리 언어였습니다.

하지만, 어셈블리 언어와 유니티에서 말하는 어셈블리는 전혀 다른 개념입니다.

 

 

유니티에서의 어셈블리는 .NET 환경의 코드 묶음을 의미합니다.

즉, 코드를 하나로 묶은 배포 단위 (DLL / EXE) 라고 생각하면 됩니다.

 

개발자들이 생성 및 구현하는 스크립트 코드도 전부 Assembly-CSharp.dll에 합쳐져서 어셈블리 단위로 컴파일링이 일어납니다.

물론, Editor 라는 폴더를 생성하고 해당 폴더에서 작성한 스크립트는 기본적으로 Assembly-CSharp.Editor.dll로 컴파일링이 일어납니다.

 

Editor 관련 코드는 빌드할 수 없기 때문에, 툴을 개발할 때는 기본적으로 Editor 폴더를 만들면 빌드 시 걱정이 없습니다.

빌드 시 Assembly-CSharp.Editor.dll 컴파일링은 동작하지 않기 때문입니다.

---

어셈블리 정의 (Assembly Definition)

 

위에서 언급했듯이, 개발자가 Editor 폴더 또는 그 외에 생성한 스크립트는 모두 Assembly-CSharp.dll과Assembly-CSharp.Editor.dll에 자동으로 합쳐집니다.

 

하지만, 이는 하나의 큰 문제점이 있습니다.

작은 프로젝트의 경우에는 크게 영향이 없지만, 큰 프로젝트의 경우는 대량의 게임 로직, 데이터 로직, 툴 등의 스크립트가 존재하기 합니다. 스크립트가 많을 수록 컴파일링 시간은 길어집니다. 

 

예를 들어, 유저가 단순히 변수명을 변경하는 것과 같은 작은 수정만 하더라도, Assembly-CSharp.dll과 Assembly-CSharp-Editor.dll에 포함된 모든 코드가 다시 컴파일됩니다. 이로 인해 컴파일 시간이 길어지고, 전체적인 작업 속도가 저하되는 문제가 발생할 수 있습니다.

 

이러한 문제를 해결하기 위해 Unity는 기본적으로 모든 스크립트를 하나의 어셈블리로 자동으로 묶지만, Assembly Definition Asset을 통해 개발자가 어셈블리를 직접 분리하고 관리할 수 있도록 합니다.

 

어셈블리 정의 생성 위치

 

유니티 6 기준으로 Create -> Scripting -> Assembly Definition을 통해서 어셈블리 정의 에셋을 생성할 수 있습니다.

 

 

어셈블리 정의 에셋을 생성하면 Inspector에서 어셈블리명과 NameSpace의 Root명, 참조 가능한 Assembly Definition, 사용 범위를 정하는 Platforms 등을 설정할 수 있습니다.

 

이를 사용해서 스크립트들을 어셈블리 정의를 통해서 분리하면 컴파일링 속도, 의존성 관리, Editor / Runtime 분리가 가능해집니다.

 

주의점

Assembly Definition References에 각 정의를 참조시킬 때, 의존성을 고려하여 연결해야 합니다.

그렇지 않으면, 컴파일링 발생 시 무한 참조가 발생하는 문제가 발생할 수 있습니다.

 

예를 들어서 Assembly Definition을 3가지 생성했다고 가정해보겠습니다.

• Editor
• Runtime
• Data

 Editor -> Runtime, Data

Runtime -> Data 

Data -> Editor, Runtime

 

위와 같이 참조를 설정할 경우, Data → Editor → Runtime → Data와 같은 순환 참조가 발생하게 됩니다.

이러한 순환 구조는 컴파일 순서를 결정할 수 없게 만들어, 컴파일 에러를 유발하거나 예상치 못한 동작을 일으킬 수 있습니다.

따라서 Assembly Definition을 설계할 때는 의존성이 한 방향으로만 흐르도록 구성하는 것이 중요합니다.