Godot 렌더러는 어떻게 느려지는 코드를 찾아내고 고칠까

무엇이 새로 나왔나

Godot Engine 공식 블로그에 엔진 개발자 Clay John이 올린 글은 새로운 기능 발표가 아니라, Godot 렌더러의 CPU 쪽 코드를 실제로 어떻게 최적화하는지 보여주는 진행 보고서입니다. 글쓴이는 겉보기에 신비로워 보이는 렌더링 최적화 작업이 사실 체계적인 절차를 따른다는 점을 강조하며, 올해 진행한 구체적인 사례 두 가지를 소개합니다.

기존과 무엇이 다른가

글은 먼저 최적화의 기본 원칙을 설명합니다. 렌더러 성능은 CPU와 GPU 중 더 느린 쪽에 의해 결정되므로, 아무리 CPU 코드를 다듬어도 셰이더가 비효율적이면 소용이 없습니다. 또한 2D에서 쓰이는 배칭처럼 GPU에는 약간 불리하지만 CPU에는 크게 유리한 기법, 3D에서 CPU 쪽으로 가져오는 오클루전 컬링처럼 상황에 따라 CPU와 GPU 작업량을 저울질하는 트레이드오프가 항상 존재한다고 설명합니다.

최적화 절차는 병목 지점을 찾고, 왜 그곳이 느린지 이해하고, 해결책을 시도한 뒤, 다시 성능을 측정하는 과정을 반복하는 식으로 요약됩니다. 이 중 가장 어려운 단계는 병목을 찾아내는 것이며, 이를 위해 Superluminal 같은 외부 샘플링 프로파일러를 사용한다고 소개합니다. Godot 에디터에는 GDScript 코드용과 렌더러 전용, 두 가지 내장 프로파일러가 있지만 엔진 코드 자체를 들여다볼 때는 외부 프로파일러가 필요하다고 설명합니다.

글에서 다루는 첫 번째 사례는 Polygon2D 관련 문제입니다. 한 개발자가 애니메이션 캐릭터 20개 정도만으로도 성능이 떨어지는 현상을 겪었고, 프로파일링 결과 정점이 변할 때마다 메시 전체를 매 프레임 새로 만들고 버리는 과정이 원인으로 드러났습니다. Godot이 이미 제공하는 저수준 정점 업데이트 API를 활용해, 정점 개수가 바뀌지 않는 경우에는 메시를 새로 만드는 대신 기존 메시의 정점 데이터만 갱신하도록 고쳤고, 그 결과 해당 시나리오에서 프레임당 처리 시간이 크게 줄어드는 성과를 얻었습니다. 다만 글쓴이는 이 최적화를 더 밀어붙일 여지(예: 변경된 정점 영역만 갱신)가 있지만, 이번 테스트 케이스에서는 모든 정점이 매 프레임 움직이기 때문에 오히려 득이 되지 않을 수 있다고 설명하며, 실제로 이득을 볼 수 있는 테스트 케이스 없이는 최적화를 제대로 할 수 없다는 점을 강조합니다.

두 번째 사례는 D3D12 백엔드에서 셰이더를 SPIRV에서 DXIL로 변환하는 과정에 관한 것입니다. 이 변환 단계가 셰이더 컴파일 파이프라인에서 가장 느린 부분이며, Vulkan 대비 D3D12에서 로딩 시간이 눈에 띄게 길어지는 원인이라고 설명합니다. Superluminal로 추적한 결과 여러 스레드가 동시에 메모리를 OS에 요청하면서 대기 상태에 빠지는 구간이 발견되었다는 내용까지 소개되며, 이어지는 구체적인 해결 과정은 원문에서 더 다뤄집니다.

한국 제작자에게 어떤 의미인가

이 글은 특정 기능 추가가 아니라 Godot 팀이 성능 문제를 실제로 어떻게 진단하고 고치는지 보여주는 사례 연구입니다. 자신의 프로젝트에서 비슷하게 프로파일러로 병목을 찾고, 가설을 세운 뒤 반드시 재측정하는 절차를 참고할 수 있습니다.

어떻게 활용/확인하나

• Godot 에디터에 내장된 GDScript 프로파일러와 렌더러 프로파일러를 먼저 활용해볼 수 있습니다.
• 엔진 코드 수준의 깊은 분석이 필요하다면 Tracy 기반 빌드나 외부 샘플링 프로파일러 사용법을 원문에서 확인할 수 있습니다.
• Polygon2D를 활용한 정점 애니메이션처럼 매 프레임 메시가 재생성되는 패턴이 있는지 자신의 프로젝트에서 점검해볼 수 있습니다.

이 글은 공식 발표를 한국어로 요약한 것이며 세부 내용은 원문을 기준으로 해 주세요.