새로운 전자책 소개: 고급 개발자를 위한 Unity DOTS(데이터 지향 기술 스택)
관련주제
- #Monobehaviour
- # DOTS
- # Unity ECS
2024.08.26
Unity의 DOTS(데이터 지향 기술 스택)는 타겟 하드웨어를 최대한 활용하는 데 도움이 되는 성능 향상 툴 세트를 제공하여 복잡한 게임을 대규모로 제작할 수 있도록 지원합니다.
고급 Unity 개발자를 위한 데이터 지향 기술 스택 소개는 50페이지가 넘는 전자책이며 지금 무료로 다운로드할 수 있습니다. 데이터 지향 프로그래밍을 더 깊이 이해하고 자체 신규 프로젝트에 DOTS가 적합한 선택인지 평가하기 위한 입문서로 활용해 보세요. 새로운 DOTS 기반 프로젝트를 시작하거나 Monobehaviour 기반 게임의 성능상 중요한 부분에 DOTS를 구현하려고 하시나요? 이 가이드는 체계적이고 명확한 방식으로 필요한 모든 내용을 소개합니다.
Unity 6 프리뷰 버전이 출시되고 DOTS 1.0을 정식으로 제작에 사용할 수 있는 지금이야말로 DOTS가 제공하는 기회를 탐색할 좋은 시기입니다. 유니티의 시니어 소프트웨어 엔지니어인 브라이언 윌이 작성한 이 전자책은 업데이트된 Unity Learn 샘플, 최신 DOTS 부트캠프, GitHub 샘플을 포함하고 있어 DOTS로 작업하는 방법을 배우려는 개발자에게 유용한 리소스 모음입니다.
ㅣDOTS가 게임에 적합한지 결정하는 데 도움이 되는 가이드
이 전자책의 목표는 DOTS 패키지 및 기술의 일부나 전부를 구현하는 것이 기존 또는 향후 Unity 프로젝트에 적합한지에 대해 결정을 내리는 데 도움이 되는 정보를 제공하는 것입니다. 스택의 각 부분은 게임의 실행 속도와 효율성을 향상하는 역할을 합니다. 이 가이드에서는 이러한 각 부분을 소개하고 이들을 함께 사용할 수 있는 방법, 그리고 공통 기반인 Unity ECS(엔티티 컴포넌트 시스템)를 설명하고자 합니다.
DOTS를 사용하는 주된 이유는 타겟 하드웨어의 성능을 최대한 활용하기 위해서이며, 이를 위해서는 멀티스레딩과 메모리 할당을 이해해야 합니다. 또한 DOTS를 활용하려면 C# 기반 Monobehaviour 프로젝트와 달리 높은 추상화 수준을 통해 데이터 지향 코드와 프로젝트를 설계해야 합니다.
전자책 내용을 자세히 살펴보겠습니다.
고급 Unity 개발자를 위한 데이터 지향 기술 스택 소개 를 다운로드하세요.
ㅣ DOTS 전자책 내용
가이드의 첫 번째 섹션에서는 아래에 포함된 대로 가비지 컬렉션 오버헤드, 캐시 친화적이지 않은 데이터 및 코드, 최적이 아닌 컴파일러 생성 머신 코드 등 게임에서 CPU 성능 저하의 원인이 될 수 있는 몇 가지 요인을 소개합니다.
다음 섹션에서는 CPU 성능 저하를 피하는 코드를 작성하는 데 도움이 되는 각 DOTS 패키지와 기능에 대해 설명합니다. 다음에 대한 유용한 설명을 찾을 수 있습니다.
● C# 잡 시스템
● 버스트 컴파일러
● 컬렉션
● 수학
● 엔티티
● 엔티티 그래픽스
● Unity Physics
● Netcode for Entities
스택의 각 부분에 대한 설명이 끝나면 기본 및 고급 DOTS 기능을 소개하는 많은 샘플이 포함된 EntityComponentSystemSamples GitHub 저장소에 대한 소개가 제공됩니다.
Github 저장소에 있는 샘플 중 일부는 DOTS에 대한 새로운 Unity Learn 교육 과정 DOTS 익히기에 구현되어 있습니다.
DOTS 가이드의 또 다른 핵심 섹션은 바로 부록입니다. 부록에서는 메모리 할당 및 가비지 컬렉션, 메모리 및 CPU 캐시, 멀티스레드 프로그래밍, 객체 지향 프로그래밍의 한계, 데이터 지향 프로그래밍 등 Unity ECS와 관련된 개념에 대한 자세한 설명이 제공됩니다.
ㅣ발췌: 성능 정보
숙련된 게임 개발자라면 타겟 플랫폼의 성능 최적화가 전체 개발 사이클 내내 진행되는 작업이라는 점을 잘 알고 있을 것입니다. 게임이 고사양 PC에서는 잘 작동할 수 있지만, 저사양 모바일 플랫폼에서는 어떨까요? 한 프레임이 다른 프레임보다 훨씬 오래 걸려서 눈에 띄는 문제가 발생하나요? 로딩 시간이 짜증 날 정도로 길고 플레이어가 문을 통과할 때마다 게임이 몇 초 동안 멈추나요? 이러한 시나리오에서는 현재 환경의 품질이 떨어질 뿐만 아니라 더 많은 기능을 추가하는 것이 사실상 불가능합니다. 이제는 환경 디테일과 스케일, 메카닉, 캐릭터와 동작, 물리, 플랫폼이 더욱 향상되었습니다.
문제의 원인은 무엇일까요? 많은 프로젝트에서 렌더링을 실행하다 보면 텍스처가 너무 크거나, 메시가 너무 복잡하거나, 셰이더가 너무 비싸거나, 배칭, 컬링 및 LOD를 효과적으로 사용하지 못합니다.
또 다른 일반적인 함정은 복잡한 메시 콜라이더를 과도하게 사용하여 물리 시뮬레이션 비용을 증가시키는 것입니다. 또는 게임 시뮬레이션 자체가 느릴 수 있습니다. 게임을 고유하게 만드는 요소를 정의하는 C# 코드가 프레임당 너무 많은 밀리초의 CPU 시간을 소비하고 있을지도 모릅니다.
그렇다면 어떻게 해야 빠르거나 적어도 느리지 않은 게임 코드를 작성할 수 있을까요?
지난 수십 년 동안 PC 게임 개발자는 기다리는 것만으로 이 문제를 해결할 수 있었습니다. 1970년대부터 21세기에 들어서까지는 CPU 단일 스레드 성능이 일반적으로 몇 년마다 두 배씩 증가했기 때문에(무어의 법칙으로 알려진 현상) PC 게임은 라이프사이클에 걸쳐 급속도로 빨라졌습니다. 그러나 지난 20년 동안 CPU 단일 스레드 성능의 향상은 상대적으로 미미했습니다. 대신 CPU의 코어 수는 계속 증가하고 있으며, 스마트폰과 같은 소형 휴대 기기에도 여러 개의 코어가 탑재되어 있습니다. 또한 고사양 게이밍 기기와 저사양 게이밍 기기 간의 격차가 더 벌어졌으며, 플레이어 기반의 상당수는 몇 년 된 하드웨어를 사용하고 있습니다. 더 빠른 하드웨어를 기다리기는 더 이상 효과적인 전략이 아닌 것으로 보입니다.
그렇다면 질문해야 할 것은 ‘왜 내 CPU 코드가 느린 것인가?’입니다. 몇 가지 일반적인 함정이 있습니다.
● 가비지 컬렉션은 눈에 띄는 오버헤드와 일시 정지를 유도합니다. 이는 가비지 컬렉터가 애플리케이션의 메모리 할당 및 해제를 관리하는 자동 메모리 관리자 역할을 하기 때문에 발생합니다. 가비지 컬렉션은 CPU와 메모리 오버헤드를 발생시킬 뿐만 아니라 때로는 코드의 모든 실행을 수 밀리초 동안 일시 정지시킵니다. 사용자는 이러한 일시 중지를 작은 버벅거림이나 거슬리는 끊김 현상으로 경험할 수 있습니다.
● 컴파일러에서 생성된 머신 코드는 최적화되지 않은 상태입니다. 일부 컴파일러는 다른 컴파일러보다 훨씬 덜 최적화된 코드를 생성하며, 플랫폼에 따라 결과가 달라집니다.
● CPU 코어가 충분히 활용되지 않습니다. 이제 저사양 기기에도 멀티코어 CPU가 탑재되어 있지만, 멀티스레드 코드를 작성하는 것이 어렵고 오류가 발생하기도 쉽기 때문에 대부분의 게임에서는 대부분의 로직을 메인 스레드에 유지합니다.
● 데이터가 캐시 친화적이지 않습니다. 캐시에서 데이터에 액세스하는 것이 메인 메모리에서 데이터를 가져오는 것보다 훨씬 빠릅니다. 그러나 시스템 메모리에 액세스하려면 CPU가 수백 번의 CPU 사이클을 기다리는 대신 가능한 한 캐시에서 데이터를 읽고 쓰는 것이 나을 수 있습니다. 이를 배열하는 가장 간단한 방법은 메모리를 순차적으로 읽고 쓰는 것이므로, 데이터를 저장하는 가장 캐시 친화적인 방법은 밀집된 연속 배열을 사용하는 것입니다. 반대로 데이터가 메모리 전체에 비연속적으로 흩어져 있는 경우 데이터에 액세스하면 일반적으로 비용이 높은 캐시 부적중(cache miss)이 많이 발생하며, CPU는 캐시 메모리에 없는 데이터를 요청하고 대신 느린 메인 메모리에서 데이터를 가져와야 합니다.
● 코드가 캐시 친화적이지 않습니다. 코드가 실행될 때 캐시에 아직 저장되어 있지 않은 경우 시스템 메모리에서 로드해야 합니다. 한 가지 전략은 시스템 메모리에서 함수를 로드해야 하는 빈도를 줄이기 위해 가능한 한 적은 위치에서 함수를 호출하는 것입니다. 예를 들어 특정 함수를 프레임 전체에 흩어져 있는 여러 위치에서 호출하는 것보다 단일 루프에서 호출하여 프레임당 최대 한 번만 코드를 로드하는 것이 좋습니다. 코드가 지나치게 추상화되어 있습니다. 추상화는 데이터와 코드 모두에 복잡성을 야기하는 경향이 있어 앞서 언급한 문제를 악화시킵니다. 가비지 컬렉션 없이 할당 관리가 더 어려워지고, 컴파일러가 효과적으로 최적화하지 못할 수 있으며, 안전하고 효율적인 멀티스레딩이 더 어려워지고 데이터와 코드가 캐시 친화적이지 않게 되는 경향이 있습니다. 무엇보다도 추상화는 성능 비용을 중심으로 분산되는 경향이 있어 전체 코드가 느려지고 최적화할 병목 현상이 명확하게 드러나지 않습니다.
위의 모든 문제는 Unity 프로젝트에서 흔히 볼 수 있습니다. 좀 더 구체적으로 살펴보겠습니다.
● C#을 사용하면 수동으로 할당된 오브젝트(가비지 컬렉션을 거치지 않은 오브젝트)를 만들 수 있지만, C#과 대부분의 Unity 프로젝트에서는 가비지 컬렉션을 수행한 C# 클래스 인스턴스를 사용하는 것이 기본 표준입니다. 애초에 가비지 컬렉션 언어를 사용하는 목적에 반하는 것이긴 하지만, 실제로 Unity 사용자들은 풀링이라는 기술을 통해 이 문제를 완화해 왔습니다. 오브젝트 풀링의 주요 이점은 미리 할당된 풀에서 오브젝트를 효율적으로 재사용할 수 있어 오브젝트를 자주 생성하고 할당 해제할 필요가 없다는 점입니다.
●Unity 에디터에서 C# 코드는 일반적으로 Mono Compiler를 사용하여 머신 코드로 컴파일됩니다. 스탠드얼론 빌드의 경우 IL2CPP(C++로 크로스 컴파일된 C# 중간 언어)를 사용하면 더 나은 결과를 얻을 수 있지만, 빌드 시간이 길어지고 모드 지원이 더 어려워지는 등의 몇 가지 단점이 있습니다.
●Unity 프로젝트에서는 메인 스레드에서 모든 코드를 실행하는 것이 일반적인데, 많은 경우 그렇게 해야 Unity를 쉽게 사용할 수 있기 때문입니다.
●MonoBehaviour의 Update() 메서드 같은 Unity 이벤트 함수는 모두 메인 스레드에서 실행됩니다.
●대부분의 Unity API는 메인 스레드에서만 안전하게 호출할 수 있습니다.
●일반적인 Unity 프로젝트의 데이터는 메모리 전체에 흩어져 있는 임의의 오브젝트로 구성되어 있어 캐시 활용도가 떨어지는 경향이 있습니다. 다시 한 번 강조하자면, 많은 경우 그렇게 해야 Unity를 쉽게 사용할 수 있기 때문입니다.
●게임 오브젝트와 그 컴포넌트는 모두 개별적으로 할당되므로 메모리의 서로 다른 부분에 할당되는 경우가 많습니다.
●일반적인 Unity 프로젝트의 코드는 캐시 친화적이지 않은 경향이 있습니다.
●기존 C#과 Unity의 API는 대부분 수많은 작은 메서드와 복잡한 호출 체인을 사용하는 객체 지향 코드 스타일을 권장합니다. 이는 데이터 중심 접근 방식과 달리 비교적 하드웨어 친화적이지 않습니다.
●모든 MonoBehaviour 이벤트 함수는 개별적으로 호출되며, 호출이 반드시 MonoBehaviour 유형별로 그룹화되지는 않습니다. 예를 들어 1000개의 Monster MonoBehaviour가 있는 경우, 각 Monster는 개별적으로 업데이트되며 반드시 다른 Monster와 함께 업데이트되지는 않습니다.
기존 C#과 많은 Unity API의 객체 지향 스타일은 일반적으로 추상화가 많은 솔루션으로 이어집니다. 그 결과 코드 전체에 비효율적인 요소가 얽혀 있어 분리하기 어려운 경향이 있습니다.
ㅣDOTS 전자책의 대상
이 전자책은 누구나 무료로 이용할 수 있으나, 특히 Monobehaviour 기반의 오브젝트 지향 게임 개발 경험은 있지만 Unity DOTS 및 데이터 지향 설계 개발은 처음인 Unity 개발자를 대상으로 합니다.
DOTS를 이해하고 이러한 기능이 자체 신규 Unity 프로젝트에 어떤 이점을 제공할 수 있는지 알아보는 데 이 가이드가 도움이 되기를 바랍니다. GitHub 저장소에서 제공되는 샘플도 최대한 활용해 보세요.
