같은 1만 개라도 드론과 광석은 비용이 달랐다

자동화 경로 자체에 비용이 있었습니다

EntityForge의 기존 자동 모드는 원래 Renderer를 남긴 채 대상 10,000개의 속성을 매 프레임 다시 조회하고 DOTS 프록시를 동기화했습니다. 구 경로 진단에서 동기화는 평균 8.1414ms였습니다. 렌더링을 돕기 위한 작업이 별도의 부담을 만들고 있었습니다.

이번에는 자동 대상에 프록시 엔티티를 만들지 않고 네이티브 Renderer 인스턴싱과 공유 재질 동기화를 사용했습니다. 같은 재질의 속성만 한 번씩 확인하며, 엔진이 컬링과 변환·렌더러 변경을 처리하도록 했습니다. 명시적 Forge 이동·수명·스폰은 DOTS/Burst를 유지합니다.

드로우 콜 감소와 프레임 시간은 같지 않습니다

새 드론 경로의 동기화 평균은 0.0026ms였습니다. 하지만 실제 플레이어 전체 프레임 시간은 드론 10,000개 조건에서 14.9838ms에서 14.5818ms로, 약 2.68% 줄었습니다. 드로우 콜이 10,002에서 24로 줄어도 GPU 부하는 여전히 컸기 때문입니다.

별도의 경량 광석 10,000개 조건에서는 9.3457ms에서 2.5174ms로 약 73.06% 감소했습니다. 두 수치는 다른 부하의 결과이며, 광석의 개선율을 드론 씬에 적용할 수 없습니다. 또한 FPS 증가율이 아니라 프레임 시간 감소율입니다.

드론 10,000개를 표시한 기능 OFF 상태의 실제 플레이어 화면입니다.

같은 개체와 형상을 유지한 기능 ON 상태입니다. 전후 RGB 픽셀 차이는 없었습니다.

같은 조건의 반복 측정으로 비교했습니다

측정은 Windows x64, Unity 6000.0.83f1, Entities 1.3.15, Built-in, i5-12400F와 GTX970, 1280×720에서 진행했습니다. OFF와 ON을 교차 순서로 세 쌍 실행하고, 매번 180프레임 워밍업 뒤 포그라운드 600프레임을 수집했습니다.

각 부하의 전후 삼각형 수는 동일했고 개체 수나 형상을 줄이지 않았습니다. 원본 재질은 보존하고 복사본을 사용하며, 사용자 재질 교체와 비활성·재활성, 해제 후 복원도 회귀 검사에 포함했습니다.

개선을 말할 때는 병목을 함께 남깁니다

드론은 별도 진단에서도 GPU 사용률이 98~99%였고 GPU 시간은 약 14.5ms였습니다. CPU 쪽 작업을 크게 줄여도 전체 프레임이 그만큼 짧아지지는 않는 사례입니다.

이번 결과는 측정한 두 부하와 해당 하드웨어 범위에서 확인한 개선입니다. 전체 제품의 출시 QA, 에디터 UI와 언어별 배치, 공식 판매 검증까지 완료한 것은 아닙니다. 최적화 결과에는 바뀐 경로뿐 아니라 동일하게 유지한 조건과 남은 병목도 함께 기록해야 합니다.

자동 렌더링과 명시적 DOTS 기능을 구분합니다

아래는 변경한 경로의 범위를 설명한 도표입니다. 모든 MonoBehaviour를 DOTS로 자동 번역한 결과가 아닙니다. 기존 명시적 기능을 유지하면서 자동 렌더링 대상의 중복 작업만 덜어 냈습니다.

flowchart TD
  A["Entity Forge 대상"] --> B["자동 렌더링 대상"]
  A --> C["명시적 이동과 수명과 스폰"]
  B --> D["네이티브 Renderer와 공유 재질"]
  C --> E["DOTS와 Burst 유지"]

평균에는 인접한 최종 12회 실행만 사용했고, 별도 GPU 진단은 포함하지 않았습니다. 측정 자료에는 부하 ID와 개체 수도 남겨 다른 씬의 결과가 섞이지 않도록 했습니다. 숫자가 크게 좋아진 광석 사례보다 드론의 남은 GPU 병목을 함께 보여 주는 편이, 어떤 프로젝트에서 이 경로를 시험할지 판단하는 데 도움이 됩니다.

작업 근거

• 개발 기록 원문