SPEAR: Unreal Engine을 파이썬으로 직접 제어해 고해상도 포토리얼리스틱 시뮬레이션을 가속하는 라이브러리

현대의 embodied AI 및 비전 연구는 고품질 렌더링과 광범위한 프로그래머블 접근성을 동시에 필요로 한다. SPEAR는 언리얼 엔진의 런타임 리플렉션을 파이썬 API로 직접 노출해 기존 UE 기반 시뮬레이터보다 훨씬 많은 함수와 속성을 제어할 수 있게 했다. 또한 고해상도 이미지를 복사 없이 NumPy 배열로 전달하고 비동기 파이프라인을 통해 프레임 전송 속도를 크게 개선함으로써 대규모 데이터 생성과 실시간 제어를 동시에 가능하게 했다.

현행 UE 기반 시뮬레이터는 일반적으로 수작업으로 제작된 소수의 Python 인터페이스와 모노리식 빌드를 사용해 확장성과 통합에서 제약이 있었다. 이 제약 때문에 외부 프로젝트나 에셋 통합이 어렵고, 대용량 데이터(예: 1920×1080 이미지)를 Python으로 넘길 때 통신 오버헤드가 병목으로 작용했다. 또한 기존 인터페이스는 UE의 모든 런타임 기능을 프로그램적으로 노출하지 못해 표현력이 제한되었다. SPEAR의 핵심은 UE의 런타임 리플렉션을 직접 노출해 문자열 기반으로 클래스·함수·속성을 동적으로 탐색·호출할 수 있게 한 것이다. 이 방식은 특정 API마다 래퍼를 만들 필요를 제거하고, 리플렉션이 허용하는 모든 함수와 프로퍼티를 자동으로 노출함으로써 제어 가능한 기능의 수를 획기적으로 늘렸다. 리플렉션 노출 위에 동기/비동기 쌍을 제공하고 트랜잭션 모델을 적용해 프레임 경계에서의 실행 순서를 엄격히 보장했다. 데이터 전송 병목을 해결하기 위해 SPEAR는 SpFunction과 인터프로세스 공유 메모리 매핑을 도입했다. Python 클라이언트는 NumPy 배열을 공유 메모리로 할당해 서버에 넘기고, 서버는 해당 메모리를 직접 스크립트 가능한 UE 함수로 연결해 추가 복사 없이 픽셀 데이터를 주고받는다. 이 조합은 통신 오버헤드를 수십 밀리초 수준으로 낮춰 렌더링 성능을 실질적으로 향상시켰다.

시스템 아키텍처는 Python 클라이언트와 UE 내 C++ 서버 플러그인으로 구성된 클라이언트-서버 모델을 채택했다. 클라이언트는 사용자의 begin_frame/end_frame 트랜잭션을 명령 스트림으로 변환해 TCP/IP(또는 로컬 IPC)를 통해 서버로 전송하고, 서버는 별도의 서버 스레드에서 명령을 수신해 게임 스레드와 작업을 조율한다. 서버는 begin_frame·end_frame용 두 개의 스레드 안전 큐를 유지해 게임 스레드가 프레임 경계에서 해당 큐를 드레인하도록 했으며, 이를 통해 트랜잭션의 실행 순서와 결정론을 보장했다. 리플렉션 노출을 위해 서버는 UE의 리플렉션 API를 이용해 함수와 속성의 메타데이터를 열람하고 JSON 기반 표현으로 Python과 주고받도록 설계했다. 리플렉션으로 노출되지 않는 핵심 기능들은 193개의 수작업 엔트리포인트로 보완되며, 각 엔트리포인트에 대해 템플릿 메타프로그래밍으로 비동기 변형을 자동 생성했다. 대용량 데이터 전송은 SpFunction 인터페이스를 통해 처리되며, SpFunction은 이름이 붙은 데이터 배열, UE 객체 JSON, 임의 문자열을 입출력 인자로 사용해 Python의 NumPy 배열을 효율적으로 매핑한다. 성능 최적화를 위해 인터프로세스 공유 메모리를 도입해 GPU에서 렌더된 이미지를 사용자 NumPy 배열로 직접 매핑하도록 했고, 필요한 경우 서버는 Python 스레드의 진행을 게이트해 게임 스레드와의 지나친 비동기 차이를 방지한다. 또한 사용자가 원하는 경우 end_frame(single_step=True) 호출로 프레임을 한 단계만 진행시키는 옵션을 제공해 완전한 동기 단위 스텝핑을 지원한다.

SPEAR는 프로그래머블 기능성과 렌더-전달 성능에서 기존 UE 플러그인 대비 유의미한 개선을 보였다. 논문이 보고한 주요 수치는 SPEAR가 14K개 이상의 UE 함수를 파이썬에서 접근 가능하게 만들었고, 1920×1080 이미지를 NumPy 배열로 직접 전달할 때 최대 73 프레임/초 수준의 처리율을 달성한 점이다. 또한 Table 2의 비교에서 SPEAR는 UnrealCV+ 대비 통신 오버헤드 측면에서 9–21배 빠른 성능을 보고했다. 추가로 플랫폼 간 비교에서 SPEAR는 AirSim보다 12배 빠르고 CARLA보다 약 10% 빠른 최종 엔드투엔드 렌더 전달 시간을 기록한 실험 결과가 제시되었다. 성능은 비동기 통신, 공유 메모리 사용, 그리고 인위적 렌더링 지연(프레임 레이턴시) 설정에 따라 달라지며, 논문은 각 구성별 프레임 시간(ms)과 FPS를 표로 제공해 구체 수치를 확인할 수 있게 했다. 예제 응용에서 SPEAR는 다중 에이전트 제어, PCG 조작, 상세한 인간 얼굴의 동기화된 멀티뷰 렌더링, MuJoCo와의 코시뮬레이션, 자연어 기반 장면 편집 등 기존 UE 기반 시뮬레이터로는 구현하기 어려운 사례들을 성공적으로 실행했다.

전체 시스템은 Python 클라이언트와 UE 내부 C++ 서버 플러그인으로 구성된 클라이언트-서버 아키텍처로 구현되었다. 클라이언트는 nanobind 바인딩을 통해 강타입 C++ 엔트리포인트를 호출하며 서버는 rpclib 기반의 통신을 처리한다. 서버는 별도 스레드(server thread)에서 동작하며 begin_frame과 end_frame 작업용 큐를 유지해 게임 스레드와의 상호작용을 조율한다. 리플렉션 기반 노출을 통해 SPEAR는 14,485개의 UE 함수와 53,537개의 UE 프로퍼티를 자동으로 노출했고, 리플렉션으로 노출되지 않는 기능을 보완하기 위해 193개의 수작업 서버 엔트리포인트를 구현했다. 각 동기 엔트리포인트에 대해 템플릿 메타프로그래밍으로 비동기 변형을 자동 생성해 async.* API를 제공했다. 이 구조는 API 표면적을 크게 확장하면서도 구현 코드량은 27,193라인 수준으로 상대적으로 작게 유지했다. 대용량 데이터 경계에서는 SpFunction과 인터프로세스 공유 메모리를 결합해 NumPy 배열을 직접 매핑했다. SpFunction은 호출 시 이름이 붙은 데이터 배열, UE 객체 JSON, 문자열을 입출력 인자로 사용하도록 서명 제한을 두었고, 클라이언트-서버 경계에서 NumPy 배열을 효율적으로 매핑해 추가 복사 비용을 회피했다. 렌더러 측에서는 사용자가 설정한 렌더링 레이턴시(0~2 프레임 등)에 따라 처리량과 지연을 상호 조정할 수 있도록 설계되어 있으며, 실험에서 비동기 통신과 공유 메모리는 모두 성능 개선에 기여했다.

논문은 SPEAR의 설계상 일부 제약을 명시적으로 언급했다. 첫째, 트랜잭션 모델은 기본적으로 각 트랜잭션이 단일 프레임 내에서 실행되도록 보장하지만 연속 트랜잭션이 연속 프레임에서 실행된다는 보장은 제공하지 않는다. 둘째, 리플렉션으로 노출 가능한 타입에 제약이 있어 모든 C++ 타입을 자동으로 전달할 수 없고, 복잡한 타입은 수작업 엔트리포인트 또는 SpFunction으로 보완해야 한다. 셋째, 성능은 비동기 모드, 공유 메모리 사용, 렌더링 레이턴시 설정 등 운영 파라미터에 민감하며 실사용 시 적절한 구성 튜닝이 필요하다.