[Unite On-Air 2025] DOTS를 활용한 GameObject 게임플레이 최적화 – Survival Kids 사례

Survival Kids 프로젝트와 DOTS 배경

Survival Kids는 Unity 스튜디오가 처음부터 디자인하고 개발한 생존 제작 게임이에요. 최대 4인 코업이 핵심인데, 싱글 플레이도 가능하고 로컬·온라인 모드 지원하죠. 코나미와 퍼블리싱 파트너십으로 닌텐도 스위치 2 출시 첫날 론치됐고, 지금은 eShop에서 다운로드 가능해요. 유럽 실물 패키지도 크리스마스에 나온다고 하니, 가족 선물로 좋을 거예요.

이 프로젝트의 매력은 '제작 검증' 전략에 있어요. Unity가 개발 내내 피드백을 받아 에디터 업그레이드나 패키지 버그를 실전에서 검증했거든요. 결과적으로 Unity 6 퍼블릭 버전으로 출시됐고, 커스텀 패키지 없이 공식 도구만 썼어요. 그래픽은 URP 기반에 커스텀 쉐이더 그래프 추가, 어댑티브 프로브 볼륨으로 다이나믹 데이-나이트 사이클 구현했지만, 디자인상 필요 없어 슬라이더로 조절만 남겼죠. 목표는 스위치 2에서 60fps였는데, 1,000개 GameObject 스폰 레벨에서도 달성했어요. 중간 규모 싱글 A 게임 수준인데, 시각 품질과 성능 균형 잡기가 핵심이었거든요.

DOTS는 데이터 지향 기술 스택으로, 엔티티(ECS)뿐 아니라 업데이트 가능한 시스템, 버스트 컴파일러, 워커 쓰레드, Transform Access Array, 네이티브 컬렉션까지 포괄해요. 많은 분들이 DOTS=ECS로 오해하시는데, GameObject 기반 플레이를 최적화할 때 시스템 부분이 더 유용하죠. Survival Kids 사례처럼 Netcode for Entities로 네트워킹 기반을 잡고, 그 위에 '고스트 브릿지'라는 커스텀 GameObject 레이어를 쌓았어요. Unity 6.0.3 베타에 포함될 예정이니, 1인칭 샘플로 미리 테스트해보세요. 로비·릴레이는 Unity Gaming Services 썼고, 이 조합으로 퍼블릭 에디터만으로도 현실적 트레이드오프를 해결했어요.

왜 DOTS가 GameObject 최적화에 좋을까요? 전통 GameObject는 MonoBehaviour 업데이트가 랜덤 순서로 이뤄져 CPU 캐시 효율이 떨어지거든요. 현대 CPU는 L1 캐시(손에 든 맥주처럼 즉시 접근)부터 L3(냉장고)까지 계층화됐는데, 메인 메모리 접근은 가게 가는 수준으로 느려요. Survival Kids처럼 오브젝트 밀도 높은 게임에서 캐시 미스 줄이려면 업데이트 순서 제어가 필수예요. 업계 흐름 보니, Unity 6 업데이트로 DOTS 채택률 40% 상승할 전망이래요. 최근 통계를 보면, 모바일 게임 60%가 30fps 이하로 떨어지는데, DOTS로 20-30% 향상 사례 많아요.

실전 팁으로, 프로파일러부터 써보세요. 에디터 통합이라 쉽고, 프로파일러 애널라이저 패키지(무료) 다운로드하면 프레임 트레이스 비교 가능해요. 콘솔 개발 시 네이티브 프로파일러(예: Nintendo CPU 프로파일러) 병행하세요. Survival Kids 측정은 Windows 워크스테이션 기준이니, 타겟 하드웨어에서 재테스트 필수거든요. 프로젝트 제약처럼 데드라인 맞추려면, DOTS 시스템 그룹(초기화·시뮬레이션·프레젠테이션)으로 프레임 내 위치 제어하세요. 엔티티 패키지 설치만 하면 GameObject 접근 가능해요. 예를 들어, 1,000개 오브젝트 레벨에서 기본 업데이트 1ms 걸리던 게 DOTS로 0.7ms로 줄었어요. 비교해보면, 랜덤 순서 vs. 유형별 정렬 시 캐시 히트율 15% 올라가죠.

이 사례 통해 알 수 있듯, DOTS는 내부 프로젝트가 아닌 퍼블리셔 마일스톤 맞춘 실전에서 빛나요. Unity 스튜디오처럼 고객 프로젝트 지원 경험 쌓은 베테랑 팁이니, 여러분도 Survival Kids 트레일러 보면서 영감 얻어보세요. 다음 섹션에서 MonoBehaviour 업데이트 구체적으로 파보죠.

시스템으로 MonoBehaviour 업데이트 최적화

MonoBehaviour 업데이트는 매 프레임 자동 호출되지만, 순서가 랜덤해 캐시 효율 떨어지는 게 문제예요. Survival Kids에서 시스템으로 이걸 제어해 12% 속도 향상 봤거든요. DOTS 시스템 베이스 상속받아 업데이트 그룹 지정하면, 프레임 내 위치(초기화·시뮬레이션·프레젠테이션) 고정하고 순서 정렬 가능해요. 엔티티 패키지 필요하지만, ECS 안 써도 돼요.

시스템 만드는 법부터 설명할게요. SystemBase 클래스 상속하고, UpdateInGroup 속성 붙이세요. 업데이트 함수에 [BurstCompile]로 벡터화 처리하면 병렬성 좋아져요. 싱글턴 패턴으로 외부 접근 쉽게 하려면, 정적 인스턴스 생성 후 해시(OnGUI 등 에디터 콜백)로 플레이 모드 리셋 처리하세요. 도메인 리로드 비활성화(플레이 모드 옵션)하면 에디터 속도 빨라지는데, 정적 변수 리셋 안 돼서 이 콜백 필수거든요.

MonoBehaviour 수집은 일반 List로 하되, 등록 함수 만들어 Awake에서 호출하세요. 인터페이스 IManualUpdate 구현해 업데이트 함수 이름 바꾸면, 자동 호출 피하고 시스템에서만 매뉴얼 호출돼요. 이중 호출 문제 해결되면서, 인터페이스만 있으면 어떤 컴포넌트든 수집 가능하죠. 등록 해제는 Destroy에서, null 체크 필수예요. 순서 보장 안 돼서 시스템 존재 확인 후 unregister 하세요.

정렬은 유형별로 해보세요. Survival Kids처럼 GameObject 유형(예: AI 에이전트, UI 요소, 콜렉터블) 분류해 리스트 플래그로 변경 감지 후 Sort 호출. 매 프레임 정렬 피하려면 dirty 플래그 쓰고, 스폰/디스트로이 시만 트리거하세요. 예시로 A/B/C 유형 오브젝트 랜덤 순서 vs. 그룹화: 프로파일러 애널라이저에서 병렬 업데이트 0.99ms → 0.87ms, 최악 프레임 2.18ms → 1.43ms로 개선됐어요. 60fps 게임에서 12% 향상은 엄청나죠. 알고리즘 그대로인데 순서만 바꿔 캐시 머무르게 한 거예요.

비교 분석 해보면, 랜덤 순서 시 캐시 미스율 20% 높아 메모리 접근 지연 생겨요. L3 캐시(최신 CPU 30MB+) 활용 시 2-3배 빠르거든요. 업계 사례 보니, 비슷한 코업 게임에서 이 방법으로 CPU 부하 15% 줄였대요. 실전 팁: 프로파일러에서 Behavior Update 항목 추적하세요. 마커 클릭으로 세부 트레이스 보면, 그룹화 후 평균 프레임 시간 중간값 확인 가능해요. 대규모 오브젝트(500개 이상)일 때 효과 커요. 만약 공유 데이터 접근 많으면, 유형별 묶기 전에 의존성 그래프 그려 순서 조정하세요. 싱글턴 싫으면, 서비스 로케이터 패턴 대안으로 써보세요 – 등록 시 약점 참조 저장하면 유연해져요.

주의사항은, 버스트 호환 안 되는 매니저 작업 피하세요. GameObject.Find 대신 태그/레이어로 필터링하면 성능 좋고요. Survival Kids처럼 퍼블릭 에디터만 써서 재현성 높이세요. 이 최적화로 메인 쓰레드 덜어내기 시작하면, 다음 Transform Access Array로 넘어가기 딱이에요. 워커 쓰레드 오프로드 전, 이 순서 정렬부터 적용해보는 게 좋겠어요.

Transform Access Array와 공간 쿼리 활용

Transform Access Array(TAA)는 트랜스폼을 네이티브 컬렉션으로 모아 워커 쓰레드·버스트 처리하게 해요. Survival Kids에서 UI HUD 요소(플레이어 위 헬스 바, 이모트 등) 20-50개 변환에 썼는데, 4개 카메라(분할 화면) 고려해 메인 쓰레드 부하 줄였죠. 기본 Camera.WorldToViewportPoint는 메인 쓰레드만 가능하지만, 행렬 연산 복제하면 워커로 옮길 수 있어요. Unity 소스나 LLM으로 수학 로직 파악하세요.

TAA 구현 단계: 시뮬레이션 그룹 시스템 만들어 TAA 생성하세요. 매 프레임 CollectTransforms로 오브젝트 트랜스폼 리스트 모으되, FindGameObjectsWithTag 피하고 미리 레이어로 필터링하세요. BurstCompile 잡으로 데이터 카피(포지션 추출) 후, IJobParallelForTransform 스케줄. 배치 크기 1로 단일 잡 쓰면 오버헤드 적어요. 커스텀 WorldToViewport 함수(버스트 호환)로 변환 처리하고, 화면 내 여부 플래그 세팅하세요. 완료 후 Complete 핸들 호출 필수 – 안 하면 메모리 오류 나요.

결과 적용은 후속 시스템(프레젠테이션 그룹)에서: 네이티브 어레이 읽어 GameObject.transform.position 설정. 워커 잡 후 바로 붙이지 말고, 지연 업데이트로 시간 주세요. Survival Kids 사례: 500개 HUD+4카메라 처리 0.21ms(카피 0.03ms, 처리 0.01ms), 원래 0.75ms에서 대폭 줄었어요. 더 많은 UI 추가해도 60fps 유지됐죠. 비교하면, 메인 쓰레드만 시 0.9ms vs. TAA 워커 0.21ms, 4배 효율이에요. 콘솔처럼 느린 하드웨어에서 빛나거든요.

공간 쿼리 최적화로 KD-Tree 활용하세요. MegaCity 2019 샘플(GitHub 검색)에서 가져오면 돼요. 아이템 1,000개 레벨에서 반경 내 쿼리: 기본 리스트 순회 5ms → KD-Tree 0.08ms, 60배 빨라요. 빌드(0.06ms, 워커 병렬) 후 쿼리 버스트 처리로 공간 분기 타서 불필요 영역 스킵하죠. 초기화 그룹 시스템에 KDTree 생성, 업데이트에서 트랜스폼 카피 후 BuildTree 호출. 싱글턴으로 GetInRange(반경, maxResults=10) 쿼리하세요. 콜라이더 대신 쓰면 물리 비용 0, AI·프레스 플레이트 과제에 딱이에요.

실전 팁: TAA 쓰면 메인 쓰레드 트랜스폼 접근 금지 – 예외 번거로워요. 프로파일러에서 메인 포화(회색 워커) 보면 오프로드 대상: Netcode 대기 시 녹색 바 활용하세요. Burst Job.Run으로 메인 실행 대안, Complete 불필요해요. KD-Tree 메모리 4KB(1,000개)라 부담 적고, 동적 오브젝트 시 dirty 플래그로 재빌드. 주의: 트랜스폼 유효성 IsValid 체크 필수, 디스트로이 시 null 피하세요. 대안으로 Job.WithCodegen 쓰면 코드 간단해지지만, 커스텀 행렬 필요 시 TAA가 나아요. Survival Kids처럼 네트워크 트랜스폼·비활성 시스템에도 적용: 플레이어 거리 계산으로 업데이트 스킵, 비용 50% 줄어요.

이 방법들로 GameObject 플레이가 DOTS와 조화되면, Survival Kids급 최적화 가능해요. 업계 주목 이유는 Unity 6.0.3 고스트 브릿지처럼 표준화되기 시작한 거예요.