유니티는 오늘(21일), 서울 코엑스 그랜드볼룸에서 자사 엔진 개발자 컨퍼런스, '유나이트 서울 2026'을 개최했다. 이번 유나이트 서울 2026에서는 전 세계 최초로 유니티 엔진7이 공개되는 한편, 세계 각지의 유니티 개발자들이 모여서 자신들의 노하우를 공유했다.

그 중에는 지난 1월 22일 출시한 '명일방주: 엔드필드'도 있었다. 명일방주: 엔드필드는 밀도가 높은 필드에, 유저가 각종 공업 시설을 짓고 발전해나가는 공장 시스템이 공존하는 게임이다. 이를 고퀄리티의 NPR과 PBR 하이브리드 그래픽으로 구현하면서, 콘솔과 PC는 물론 모바일에서도 원활하게 구동할 수 있게끔 했다.

이를 구현하기 위해 명일방주: 엔드필드 개발진은 어떤 과정을 거쳤을까, 유나이트 서울 2026 현장에 방문한 하이퍼그리프의 홍후이 페이 시니어 테크 디렉터는 강연에서 이 과정을 풀어나갔다.

ECS로 극대화한 캐시 친화적 메모리 구조

페이 시니어 디렉터는 명일방주: 엔드필드 렌더링에 적용한 핵심 기술을 크게 ▲자체 ECS 구축 ▲컬링·소팅·배칭 최적화 ▲C++ 렌더 파이프라인 및 렌더 그래프 ▲로우레벨 디바이스 추상화의 4가지 축으로 나누어 설명했다.

우선 자체 데이터 아키텍처, ECS는 수만 개의 렌더링 대상을 매 프레임 빠르게 처리하기 위해 채택한 구조였다. 실제로 명일방주: 엔드필드에는 일반 필드는 물론이고, 공장에서는 매번 수도 없이 많은 오브젝트들이 생성되고 사라진다. 이 모든 것을 매 프레임 빠르게 처리하지 않으면 과부하가 걸리기 쉬운 구조였다.

이러한 다수의 오브젝트를 처리할 때 유니티에서 자주 활용되는 것이 ECS지만, 엔드필드에서는 범용 엔진의 ECS에 다소 조정을 했다. 범용 ECS는 런타임 유연성을 확보하기 위해 다양한 예외 처리를 남기지만, 엔드필드 개발진은 이를 컴파일 타임에 고정했다. 그러면서 런타임 타입을 등록하고, 리플렉션과 해시 맵 조회를 제거한 뒤 128비트 마스크를 사용해 오프셋 산술 연산을 단 3싸이클 내에 처리하게끔 했다.

그리고 동일한 컴포넌트 세트를 가진 엔티티들을 하나의 연속된 메모리 블록(Chunk)에 배치하는 SoA(Structure of Arrays) 방식의 청크 메모리를 활용, CPU 캐시 적중률을 극대화했다. 한편으로는 청크와 디스크 파일을 직접 매핑해 포인터 추적이 없게 하고, 구조적 변경은 일괄적으로 스왑 앤 팝(삭제하려는 요소를 배열의 가장 마지막 요소와 자리를 바꾼 뒤, 마지막 요소를 제거하는 방식)으로 처리해 엔티티당 연산 단가를 극도로 낮췄다.

"병렬 처리 극대화로 뷰가 20개여도 컬링은 단 1번이 되어야"

오브젝트 외에도 씬의 처리도 엔드필드의 과제였다. 특히 엔드필드는 NPR과 PBR이 혼합된 구조인 만큼, 그림자에 반사, 레이트레이싱, 스트리밍 등 한 프레임에 10~20개가 넘는 뷰가 존재했다. 기존 방식대로 가시성 리스트를 생성하면 메모리 할당과 복사 비용이 훌쩍 뛰는 상황이었다.

그래서 엔드필드 개발진은 컬링을 통합하는 방향으로 설계했다. 즉 여러 뷰의 프러스텀 테스트를 개별 수행하지 않고, 한 번에 처리해서 결과를 공유하는 식으로 처리했다. 그리고는 GPU에서 저해상도 깊이 버퍼를 생성한 뒤, CPU에서 SIMD 연산을 활용해 변환/클리핑, 타일 정렬, 병렬 래스터라이제이션으로 빠르게 가림 처리를 수행하는 소프트웨어 오클루전 컬링을 도입했다. 이를 통해서 불필요한 뷰를 줄이고, 타일별로 스레드를 분리해 락과 원자적 연산도 제거했다.

또한 16바이트 정렬 키 구조를 64비트 정렬키로 설계, 표준 정렬 연산 한 번으로 파이프라인과 메시 배칭도 완료할 수 있게끔 설계했다. 또한 Vulkan의 Descriptor Set 2는 거대한 단일 버퍼를 가리키게 한 뒤 동적 오프셋(Dynamic Offset)만 옮겨 프레임당 메모리 할당을 '0'으로 만들어서 프레임을 확보했다.

네이티브 C++ 렌더 파이프라인 활용과 벌칸 구조도 참고

그 다음으로 페이 시니어 디렉터는 유니티 렌더 파이프라인이 아닌 네이티브 C++ 렌더 파이프라인을 활용했다고 설명했다. 매 프레임 수천 번 이상 실행되는 핵심 렌더 루프에서 언어 간 바인딩 오버헤드가 일어났기 때문에 렌더 파이프라인을 C++로 손수 구현하는 방식으로 조정했다.

그러면서 각 렌더 패스가 읽고 쓰는 자원을 타입 태그 기반으로 프론트엔드 선언 시점에 명시, 자원 의존성을 그래프가 미리 파악할 수 있게끔 했다. 이를 통해 배리어 호출 횟수를 그래프 플러시에 맞춰 조정할 수 있게 되면서 드라이버가 보수적으로 배리어를 크게 잡는 낭비를 막았다. 또한 명시된 자원을 체크해 라이프사이클이 겹치지 않는 임시 자원과 전환 자원이 동일한 메모리 할당을 공유, 수동 관리 없이도 VRAM 피크 점유율을 낮췄다.

마지막으로는 Vulkan에서 영감을 받은 디바이스 추상화 레이어 구축이 키였다고 설명했다. Vulkan은 상위 레이어에 드로우메시 같은 고수준 API로 드라이버가 처리하게 두는 대신, 명시적인 디스크럽터 세트, 렌더 패스, 배리어 개념을 외부에 그대로 노출해서 개발자가 명시하도록 한다. 즉 API를 설계할 때 개발자가 직접 복잡하게 구현해야 하지만, 그만큼 최적화 자유도가 보장되는 방식이다.

이러한 구조에서 영감을 받아 페이 시니어 디렉터 및 엔드필드 개발진은 플랫폼별 그래픽 PI와 엔진 사이 경계를 로우레벨로 유지했다. 즉 렌더 패스, 배리어 등을 외부에 그대로 노출하고 개발진이 이를 앞서 언급한 것처럼 직접 명시하는 식으로 구현했다. 이러한 구조를 채택한 이유는, 하이레벨 추상화를 쓰면 고수준 API를 추가해야 하는데 예상치 못한 씬 구조를 만나면 폴백 현상이 발생하기 때문이었다. 그리고 C++ 파이프라인을 활용했던 만큼, 이를 통해 최적화된 데이터 구조가 GPU 백엔드로 즉시 전달되도록 설계해 오버헤드 제로를 구현했다.

이러한 설계 끝에 스냅드래곤8 Gen1 칩셋의 모바일 디바이스 기준 50만 개 후보 오브젝트가 컬링을 거쳐서 실제 렌더링에 필요한 수만 개 수준으로 줄였다. PC에서는 60만 개 중 6만 개 수준으로 압축, 이와 같은 강력한 컬링 단축 비율로 프레임 연산 비율을 매우 가볍게 유지, 배칭 작업이 안드로이드 모바일 기준 3ms, PC 기준 1ms만 소요됐다.

페이 시니어 디렉터는 "유니티의 생산성 위에 자체 ECS 구축, 단일 컬링 및 정렬 패스, C++ 렌더 파이프라인, 로우레벨 디바이스 추상화로 대규모 오브젝트를 안정적인 프레임으로 구동했다"면서 기존 오브젝트 구조를 넘어 좀 더 다각화된 분석과 프로세스 구축을 위한 연구가 필요하다고 강조하며 발표를 마쳤다.