NDC Replay

유니티, iOS에서 LINQ 사용하기
김대희
넥슨지티
현재 넥슨지티에서 신규 모바일 프로젝트에 클라이언트 프로그래머로 참여 중입니다.<br/>선데이토즈, 넥슨에서 인턴을 하였고, 넥슨 그리고 현재 넥슨지티에서 근무 중입니다.
C#은 유니티의 대표적인 스크립팅 언어 중 하나입니다. <br/>C#에는 LINQ라 불리는 편리한 기능이있습니다. 그러나 Unity에서 LINQ를 사용하게 되면 iOS 플랫폼에서 런타임 도중 예기치 못한 예외를 발생시킵니다. 이로 인해 Unity에서는 LINQ 사용을 금기시 하는 경향이 있습니다.<br style='line-height:240%'/>해당 세션에서는 Unity 프로젝트를 iOS로 빌드 했을 때 LINQ에서 예외가 발생하는 원인을 파악하고, Unity에서도 LINQ를 사용할 수 있는 가능성을 제시합니다.
[새 창에서 슬라이드 보기]
아 네. 안녕하세요. 유니티 ios에서 LINQ 사용하기 세션을 시작하도록 하겠습니다. 저는 넥슨GT의 김대희입니다. 잘 부탁 드립니다. 발표를 시작하기에 앞서 간단하게 제 소개를 드리겠습니다. 저는 게임 프로그래머 4년차이고, 선데이토즈, 넥슨코리아를 거쳐서 현재 넥슨GT에서 신규 모바일 게임을 제작 중입니다. 그럼 본격적으로 발표를 시작할텐데요, 이 세션이 C#에 대한 기본적인 문법에 대한 이해가 좀 부족하신 분들은 어려울 수도 있습니다. 람다식이라던지 확장 메소드, 제너릭 관련해서는 좀 익숙하셔야 무리가 없을 것입니다. 그럼 발표를 시작하겠습니다.

뭐가 문제일까요? 우리는 지금 유니티에서 LINQ를 쓰고 싶어서 이 자리에 오게 됐죠. 그걸 알아보기 전에 LINQ가 무엇인지 잠깐, 가물가물하신 분들이 계실 거 같아요. 그래서 LINQ를 간략히 한 번 살펴보겠습니다. LINQ는 Language-Integrated Query의 약어입니다. 즉 언어에 통합되어 있는 질문인데요, 이 쿼리는 뭐 많은 분들이 예상하시겠지만 관계형 데이터베이스의 쿼리를 떠올리실 것 같은데 그게 맞구요, 이게 언어에 통합되어 있는 것입니다. 다음 페이지에 LINQ 모양을 보게 되면 그게 어떤 의미인지 바로 아실 겁니다. 이런 LINQ는 LINQ to Object 즉 컬렉션 유도를 할 때 질의를 할 수 있고, 그 외에도 SQL, XML 등에도 질의를 할 수 있습니다. 본 세션은 LINQ to Object 만을 다루도록 하겠습니다. 

자 LINQ의 모습인데요, 이 왼쪽에 보시면 그, 이 query syntax 모양이 관계형 데이터베이스에 있는 query문이랑 매우 비슷하죠? 그리고 반면에 method syntax는 우리가 알고 있는 C#의 method 호출과 같습니다. 이 두 개는 완전히 동일하구요, 잠깐 해석을 드리자면 이 안에 있는 array가 numbers라는 array의 짝수들만을 필터링을 합니다. 그리고 그 결과를 orderby, 즉 sorting을 하구요. sorting된 결과물들을 2배 해서 출력을 합니다. 이게 LINQ의 기본적인 모양이고요, 자 그럼 LINQ가 이제 어떻게 생겼는지는 이제 좀 알겠어요. 기억 나셨을 거라고 생각합니다. 그럼 과연 정말 간결할지 한 번 살펴보도록 하겠습니다. 

기획서를 받았는데 기획서에 퀘스트를 출력해주라는 요구사항이 있었습니다. 근데 이 퀘스트는 입장한 맵에 해당하는 맵 인덱스들이 같은 퀘스트를 보여줘야 되구요, 현재 진행 중, 액티브 상태여야 됩니다. 그리고 진행 중인 녀석들 중에서 진행 상태, progress 상태가 높은 퀘스트들을 먼저 출력을 하고요, 진행 상태가 같은 경우에는 퀘스트 아이디가 낮은 순서대로 출력을 하라는 기획서의 요구가 있었습니다. 보기만 해도 지금 아찔한, 굉장히 많은 그런 요구사항들인데요, 이거를 LINQ를 사용하지 않고 구현을 해 보겠습니다. 지금 생각보다 작아서 잘 안 보이는데, 보시면 처음에 퀘스트들을 순회를 하면서 그, 활성화되어있는 퀘스트들을 확인합니다. 그 다음에 MapIndex가 같으면 result array에 집어 넣고요, 그리고 result array에 있는 애들을 sorting을 해 주는데, 이렇게 compare, 진행 상태를 비교를 하고요, 진행 상태가 같은 경우는 아이디로 한 번 더 비교해줍니다. 대략 한 20열 정도 나온 것 같아요. 그 다음에 LINQ로 이걸 구현하면 얼마만큼 간결하게 바뀔까요? LINQ로 구현하면 이렇게 굉장히 간결하게 나오게 됩니다. 확대가 되네요. 네, 확대해서 살펴보면 지금 이전에 사용했던 Where를 사용해서 어, active되어있는 퀘스트들을 필터링했고, 해당 MapIndex에 해당하는 것들만 필터를 했습니다. 그리고 Progress 상태에서 이런 내림차순 정렬을 했고요. 그리고 그, ThenBy는 위에 OrderBy 정렬된 것 중에서 같은 게 나왔을 경우에 이제, 추가적으로 정렬해줍니다. 
좀 쉽죠? 네. 

자, 그 외에도 LINQ는 여러 가지 다양한 장점들이 존재하는데, 지금 시간 관계상 이거는 생략하도록 할게요. LINQ가 좀 오해가 있습니다. LINQ가 느리다는 많은 생각을 가지고 계시는데요, LINQ는 충분히 빠르구요, 이 ‘충분히’라는 말은 써먹을 수 있을 정도라고 생각하시면 됩니다. 이 테스트를 좀 해 봤는데, 앞서 보았던 기획서의 요구사항을, Galaxy3랑 iPhone6+에서 테스트를 해 보았습니다. 어, 퀘스트가 대략 천 개일 경우에는 둘 다 눈 깜짝할 사이에 실행이 된 거고, 만 개 쯤 왔을 때 이제 좀 차이가 보이더니, 10만 개 쯤 됐을 땐 이제 좀 저사양 핸드폰에서는 이런 식으로 차이가 나기 시작하는데, 사실 우리 디바이스 성능은 점점 발전합니다. Galaxy3를 사용하시는 분들은 점점 줄어들 거고요, 그리고 80.20법칙이라고 해서, 실행시간의 80%는 코드의 20%가 좌지우지합니다. 즉, 최적화가 필요한 부분은 20% 정도죠. 유니티 같은 경우에는 매 프레임마다 실행되는 업데이트문 정보겠네요. 그 외에는 LINQ를 사용하셔도 괜찮습니다. 그리고 클라이언트 사이드에서 대용량의 데이터를 사용하는 곳은 많지 않죠. 그래서 유니티에서 LINQ를 사용하는 것은 좋은 선택이라고 말씀을 드리고 싶네요. 

자, 그럼 지금까지 LINQ, 왜 못 썼을지 한 번 살펴보도록 하겠습니다.

어, LINQ에 이런 first or default라는 method가 있어요. 아, 그 전에 LINQ를 ios에서 사용하면 예외가 나서 그, 못 썼었거든요? 그래서 지금 ios에서 LINQ를 사용해 봤습니다. 어, first or default라는 method를, LINQ에 있는 method예요. 사용을 해 보았는데, 이 method는 음, first or default라는 method는 이처럼 안에 있는 컬렉션 중에 첫 번째 value를 리턴해 줍니다. 만약에 컬렉션에 아무 것도 없으면 string의 default 값인 너를 리턴하구요, 이 경우는 첫 번째 값이니까 0이 나오겠죠. 

다음으로, 이제 int(인티져) 리스트예요. 앞서 봤던 것과는 차이가 별로 없어 보입니다. string이 int로 바뀐 것 뿐이에요. 이것도 0이 나와야겠죠. 그런데 이렇게 ios에서 first or default method를 int 리스트를 사용하면 아래와 같이 뭔가 예외가 납니다. 차이점은 리스트에 string이었었고, 리스트에 int로 바뀐 것이죠. string은 클래스, 레퍼런스 타입임을 기억을 하시고, int는 struct, value type임을 기억을 하셨으면 합니다. 이처럼 예외가 나왔는데 LINQ는 System.Core.dll이라는 파일 안에 이 소스가 있어요. 근데 dll이라 디버깅이 좀 어렵죠, 그래서 대부분의 유니티 사용자들은 LINQ를 포기하게 됩니다. 그래서 이 부분이 도대체 무엇이 문제인지 알아보기 위해서 좀 디컴파일을 해 봤어요. 그래서 FirstOrDefault method를 발췌를 좀 했는데, 소스가 좀 많이 나와요. 
예. 여기서 필요 없는 부분을 일단 좀 없애고, 요정도만 필요한데, 지금 처음 FirstOrDefault method를 호출하면 이 소스에 리스트가 들어옵니다. 그, 확장 메소드로서 들어오겠죠. 이 T소스는. 아.. 다 떼어내서 이게 안 나오네요. 이 T소스는 인티져이구요, 예, 그 다음에 내부적으로 first method를 호출하게 됩니다. 사실 벌써 이 사항에서 예외가 났어요. 이미. 어디서 났을까요? 음 눈치가 빠르신 분들은 아시겠지만 제가 이 아래 PredicateOf를 안 지웠죠. 네. 이 PredicateOf의 arrays를 호출할 때 예외가 발생했습니다. 이 T소스는 인티져였죠. 자, 그러면 어 이게 예외가 왜 발생했을지 저는 굉장히 궁금해서 여러 가지 테스트를 좀 해봤어요. 그랬는데, 이렇게 아래에 어디에서도 호출되지 않는 method를 정의를 하고 이 PredicateOf 인티져, 아까 우리 T소스가 인티져인 거 기억하시죠, 이런 식으로 구체적으로 명시를 해 두니까, ios에서 예외가 나질 않았어요.  이게 도대체 무슨 일이 발생한 건지 한 번 알아보도록 하겠습니다.

일단 이걸 알아보기 위해서 우리는 C#의 실행 환경을 좀 살펴볼 필요가 있습니다. 일반적으로 C#은, JIT, JustInTime의 약어인데요, C# 코드를 컴파일 타임에 IL로 컴파일을 합니다. 그리고 런타임 도중에 JIT 컴파일러가 JIT컴파일, JITTING이라고도 하는데, 이 JITTING을 해서, 실시간으로 기계어로 바꿉니다. 그렇지만 ios에서는 동적으로 코드 생성이 금지가 돼요. 이 커널에서 그거를 방지, 금지시키고 있어요. 그래서 일반적인 이 C#의 실행 환경은 ios에서 구동이 불가능합니다. 그렇기 때문에 AOT라는 기술을 사용해서 ios에서 C#을 사용하는데요, AheadOfTime의 약어로서, 여기까지는 동일하죠, 여기까지는 뭐 별로 달라질 게 없어 보이는데, 이걸 전부 컴파일 타임에 실행을 합니다. 그래서 기계어를 미리 생성을 하는 것이죠. 그래서 ios에서 C#이 돌아갈 수 있어요. 
그런데, 어 유니티는 MS의 닷넷 프레임워크를 사용하지 않고 오픈소스인 모노를 사용합니다. 이 모노의 AOT는 많은 한계점을 가지고 있어요. 예를 들어, 여러 가지 한계점이 있는데 그 중에 Generic과 관련해서 특정 사항에서 Generic Type Parameter가 Value Type, 우리 아까 int 얘기했죠? value type일 때 여러 가지 한계를 보입니다. Generic Type Parameter가 이, 다들 아시겠지만 이런 int의 이 <> 안에 있는 타입들 있죠, List<int>, List<string>, List<float>. 얘네들이 Generic Type Parameter예요. 이 Generic Type Parameter가 달라지면 이 리스트들이 각기 다른 타입이 됩니다. 각기 다른 타입이기 때문에 실제로 기계어, 코드들도 다른 타입으로 각기 다르게 생성이 되어야 하겠죠. 
그런데 이렇게 각기 다르게 생성하게 되면 Generic Code Explosion이라는 현상이 일어납니다. 그, 머신 코드가 굉장히 많아져서 코드량이 폭발하게 되는 것이죠. 이거는 성능에 부정적인 영향을 끼치게 됩니다. 따라서 이러한 문제점을 해결하기 위해서 Generic Sharing이라는 기술을 사용합니다. 레퍼런스 타입 같은 게 이런 식으로, 메소드들 간에 이 리스트 안에 있는 스트링, 파일 전부 다 레퍼런스 타입이거든요. 이렇게 Generic Type Parameter가 string인 경우에는 메소드를 공유할 수 있습니다. 코드를 한 번만 생성해요. 반면에 value type 같은 경우는 이걸 공유를 할 수 없습니다. 왜 레퍼런스 타입만 공유가 가능하게 되냐 하면, 실제로 레퍼런스 타입은 내부적으로 포인터 멤버만 가지고 있어요. 이게 사이즈가 중요한데, 포인터가 전부 다 같은 사이즈이고, 그리고 동작이 다 같죠, 이 포인터, 10을 가리키는 포인터죠. 그렇기 때문에 레퍼런스 타입만 공유가 일반적으로 됩니다. 물론 구현에 따라서 value type도 몇몇은 된다고 합니다. 
이처럼 Generic Sharing이라는 기술 때문에 Generic Type Parameter가 레퍼런스 타입인가, 밸류 타입인가에 따라서 각기 다른 매커니즘을 가지게 돼요. 그래서 어, 다른 결과물이 나오게 되는 것이죠. 상대적으로 레퍼런스 타입 같은 경우엔 한 번만 코드를 생성을 하게 되면 문제가, 어 다른 타입들이 들어와도 이 코드를 쉐어하기 때문에 문제가 없습니다. 하지만 밸류 타입 같은 경우는 들어올 때마다 무조건 생성을 해야죠. 이게 인제 AOT될 때, 누락이 되어 버리면 문제가 되는 것입니다. 

예, 이거는 좀 제 의견이 들어가 있어요. 아까 말씀 드렸던 예외 한 번 살펴볼게요, 이 쪽 보시면, JITTING, 이 메소드를 지팅을 하다가, 지팅을 시도한 거예요. 그, ios에서는 지팅을 하면 안 된다고 말씀을 드렸죠, PredicateOf에 T소스가 int인 cctor, cctor은 Class Constructor예요. 그러니깐 이, Class Cons, static 생성자가 없어서, 지금 AOT가 그걸 캐치를 못 해서, 예외가 났던 것이죠. 그래서 이렇게 AOT가 캐치하지 못한 상황이 발생을 하기 때문에 아래와 같이 이렇게 사용하지 않는, 어디에서도 호출되지 않는 메소드지만 AOT한테 이렇게 힌트를 준 거예요. 코드를 분석할 때 이렇게 인티져로 타입을 명시하게 되면  AOT가 아, 이 타입 쓰는구나. 하고 AOT 컴파일 할 때 해당 타입에 관련된 메소드들을 생성을 합니다.

유니티는 모노 2점대를 사용해요. 뭐 사실 모노 최신 버전은 3점대도 나왔고 4점대도 나왔고, 버전이 나왔는데 유니티가 아직 업그레이드를 못 하고 있는데, 그, 유니티 3점대 LINQ 소스를 보면 아까 우리가 문제 있었던 PredicateOf 관련된 것들이 이처럼, 이와 같이 AOT가 아닐 때에만 실링을 하도록 이렇게 디파인이 되어 있습니다. 즉, AOT일 땐 이 코드가 아예 없어져요. 여기도 마찬가지로 문제가 됐었던, 내부적으로 first를 부르는 이 이부분도요. 그래서, 모노 3점대에서는 이러한 문제가 일어나지 않습니다. 하지만 유니티 2점대에서 못 올리고 있죠, 지금. 그 외에도 여러 가지 다양한 문제점들이 있는데, 이건 시간 관계상 좀 생략을 하도록 하겠습니다. 그 외에도 여러 패턴들은 아래 링크를 보시면 아실 수 있구요. 

결론적으로 이제 말씀을 드리면 유니티의 LINQ에서 에러가 나는 이유는 그, LINQ 자체 소스의 결함이 아니라 모노 AOT 컴파일러의 버그가 원인인 것을 알 수 있었습니다. 자, 그럼 이제 우리 원인은 뭔지 대충 알겠어요. 근데 어떻게 해야 될지 한 번, 어떻게 해야 LINQ를 사용할 수 있을지 한 번 살펴보도록 하겠습니다. 가장 간단한 방법은 문제가 없는 소스, 누가 만들어 준 거 가져다 쓰면 되죠. 저 같은 경우는 Unil.inq라는 Third party library를 사용했었는데, 이거는 모노 3점대 LINQ 코드를 기반으로 작성된 겁니다. 이 코드를 사용하시면 LINQ를 무리 없이 사용하실 수 있구요, 대망의 IL2CPP가 나왔네요. 유니티가 지금 백엔드로 돌리는, 그, 모노로 돌릴 수도 있지만 IL2CPP를 이용해서 돌릴 수도 있습니다. 이 IL2CPP는 유니티에서 만든 또 다른 AOT 기술이에요. 유니티에서 새로 구현했기 떄문에 모노에서 발생했던 문제가 발생하지 않을 수 있겠죠? 물론 반대로 모노에서 발생하지 않았던 문제가 발생을 할 수도 있구요. 그래서 IL2CPP의 경우는 지금 현재 LINQ를 안정적으로 지원을 합니다. 그냥 빌드 옵션에 가셔서 모노 2점대를 IL2CPP로 바꿔서 컴파일 하시면 LINQ 쓰실 수 있어요. 이 IL2CPP 어떻게 돌아가는지 한 번 살펴보도록 하겠습니다. 위에 있는 것은 아까 살펴 보았던 모노의 과정이고요, IL2CPP는, 뭐 여기까지는 똑같아요. 그 다음에 이 IL2CPP AOT 컴파일러가 이 IL을 CPP로 변환을 합니다. 그리고 이 변환된 CPP를 각자 맞는 C++ 컴파일러를 사용해서 각 타깃 플랫폼에 맞게 기계어로 변환을 해 주는 거죠. 물론 이 모든 것들은 컴파일 타임에 이뤄집니다. IL2CPP에서 과연 아까 우리 누락됐던 FirstOrDefault 메소드가 제대로 생성이 됐는지 한 번 살펴보도록 할게요. 

아, 좀 작네.. 지금 어, 그냥 유니티에서 Test : MonoBehaviour에서, 그냥 간단하게 만들었어요. 
int리스트, float리스트, string리스트, Material리스트. 사실 볼 메소드는 이 int 의 FirstOrDefault만 볼 건데요, 이것들은 좀 float, string, material 리스트는 좀 볼 게 있어서, 보여드릴 게 있어서 만들어 봤습니다. 그, 보시면 지금 IL2CPP 코드를 보면, 원 타입은 이렇게 위에 주석으로 명시가 되는데요, 이 아래 두 개의 타입은 뭐 유니티에서 내부적으로 사용한다고 했으니까 신경 쓰지 마시고, 이 위에 세 가지 타입을 좀 볼게요. 어 int, int32. 인티져예요. 이 리스트에 int type이 이런 식으로 맵핑이 됐어요. 이 타입으로 생성이 된 거고, single은 float이거든요, 예. 리스트에 float이 생성이 됐습니다. 우리 아까 앞서 보았던 material과 string이 없죠. 리스트에 material과 string. 이게 없는 이유는, 어. 이 리스트에 오브젝트 타입으로 전부 다 통하게 되기 때문입니다. 아까 Generic Sharing 말씀 드렸죠, 그. string과 material은 레퍼런스 타입이에요. 그렇기 때문에 코드 공유가 가능합니다. 이러한 타입을 플리 쉐어드 타입이라고 합니다. 

코드가 좀 많은데, 필요한 것만 보겠습니다. 그, 주석 보시면  FirstOrDefault 메소드, T소스가 int가 생성이 된 코드를 보실 수 있구요, 뭐 내부적으로 PredicateOf, 아까 문제가 있었던 거 있었죠. 이 PredicateOf도 잘 사용을 하구 있고요, 이게 잘 되어있는지 한 번 이것도 내부를 살펴볼텐데, 그 전에 PredicateOf. 이 모양 기억하시나요? Generic Class에 내부적으로 static 멤버를 들고 있었죠, Func라는 델리게이트와 함께, 항상 true를 리턴하는 람다식이 있었고요. 뭐 PredicateOf C++, 생성된 거 봤는데 아무 것도 없어요. 왜 없을까 하고 좀 더 주위를 살펴 보았는데, 보면 어, IL2CPP에서는 static 멤버를 따로 관리를 합니다. 따로 클래스를 만들어서. 그래서, 아까 봤던 Func. 그 델리게이트로서 Always가 생성이 된 걸 볼 수 있었고요, 이 아래 cache는 우리 아까 봤었던 항상 true를 리턴하던 람다식 있죠, 이 람다식이 사용이 되면 내부적으로 C#은 컴파일 도중에 델리게이트로 감싼 걸 멤버 변수로 캐싱을 합니다. 그게 지금 잘 반영이 된 거구요. 그리고 자 우리 아까 문제가 있었던 PredicateOf의 CCTOR 이 코드가 생성이 된 걸 볼 수가 있네요. 지금 내부적인 코드는 너무 복잡해서 좀 어, 여기에선 볼 필요까지는 없을 거 같아서 좀 뺐구요. 이 cctor이 생성이 된 것을 확인을 할 수 있었습니다. 그리고 이 아래 항상 우리 true를 리턴하던 람다식 기억하시죠. 그것도 잘 생성이 된 거를 확인을 했구요. 

예 이제 결론적으로 사실 말씀을 드리자면, IL2CPP 사용하시면 됩니다. 사실 이게 결론이에요. 앞에 제가 뭐라뭐라 막 말했는데, 아 뭔 말인지 못 알아 듣겠어. 그러면 그냥 빌드하실 때 IL2CPP 쓰세요. 그럼 됩니다. 그리고 뭐 낮은 버전의 유니티 사용해서 IL2CPP에서 LINQ가 불안정할 수도 있거든요? 그런 경우는 말씀 드렸던 Third party library를 사용하시면 되구요, 뭐 그래도 뭔가 찝찝하다 싶으시면 Third party library를 사용하시면 됩니다. 그, IL2CPP에서도. Third party library 아까 제가 소개 드린 거는 그 코드가 있어요. LINQ 코드가. 그래서 문제가 생기면 그 코드를 그냥 바로 수정을 하시면 됩니다. 사실 그 유니티가 사용하고 있는 모노 소스가 공개되어 있어요. 그래서 오늘 제가 말씀 드렸던 PredicateOf 관련 그 예외, 에러는 제가 한 2주 전 쯤인가? 컨트리뷰팅해서 수정이 됐구요, 아마 그래서 다음 유니티 버전에선 수정이 될 거라고 생각 됩니다. 여러분들도 그렇게 문제 있는 코드들, 사실 LINQ에 제가 고친 거 말고도 아직 문제 있거든요? 그거 컨트리뷰팅하셔서 다들 다같이 고치면 좋을 것 같아요. 그리고 사실 결론만 말씀 드리면 간단하죠, IL2CPP써라. 근데 유니티에서 LINQ를 사용하지 못한다는 편견이 있었어요. 많이 있었죠. 그걸 좀 깨고 싶었구요, 이걸 좀 깨려면 기존에 어떻게 동작했는지, 뭐가 문제였는지 좀 알아볼 필요가 있었어요. 그래서 이런 발표를 준비하게 됐구요. 제 발표는 여기까지고, 다들 좋은 코드, 아름답고 우아한 코드 만드셔서 네, 좋은 게임 만드셨으면 좋겠습니다. 네. 급마무리할게요. 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
