Godot 4.7 버전 리뷰: 아키텍처 혁신, 개발자 생태계 및 프로덕션 표준
오픈 소스 게임 엔진 생태계에서 가장 중요하고 혁신적인 대표 주자 중 하나인 Godot는 2026년 6월 18일에 출시된 4.7 안정 버전(stable release)과 함께 아키텍처 유연성, 그래픽 정확도, 개발자 인체공학 측면에서 비판적인 성숙도 수준에 도달했습니다 1. 이전 버전들이 엔진 기본 시스템의 안정화와 코어 버그 수정에 집중했던 반면, 4.7 버전은 직접 생산 단계의 스튜디오와 인디 개발자들이 일상적인 워크플로우에서 마주하는 병목 현상을 해결하는 것을 목표로 하는 "생산 및 워크플로우 중심" 구조를 보여줍니다 3. 2026년 8월 18일에 출시된 4.7.2 유지보수 업데이트와 함께 PCSS 그림자 좌표, 고 폴링 레이트(polling rate) 마우스의 Windows 상에서의 성능, 멀티플레이어(multiplayer) 복제 시나리오의 사소한 문제들도 해결되어 엔진의 프로덕션 환경(production-ready) 안정성이 강화되었습니다 5.
Godot 4.7은 처음부터 완전히 새로운 물리 엔진이나 완전히 재작성된 렌더 파이프라인을 제공하기보다는, 기존 Forward+ 및 Mobile 렌더 인프라를 확장하고, 사용자 인터페이스(UI) 애니메이션의 고질적인 문제를 해결하며, 모바일 개발 프로세스를 표준화하고, 고동적 범위(HDR)와 같은 최신 하드웨어 요구 사항을 충족하는 심층적인 개선 패키지입니다 2. 커뮤니티와 업계 전문가들의 평가에서, 특히 수년 동안 서로 다른 폐쇄 소스 엔진(예: Unity)을 사용해 온 개발자들이 Godot 4.7의 렌더링 기능과 빠른 프로토타이핑 기회에 깊은 인상을 받고 있음이 확인됩니다 2. 이 보고서는 Godot 4.7이 제공하는 기술적 혁신, 이러한 혁신이 소프트웨어 아키텍처에 미치는 영향, 커뮤니티 피드백, 그리고 프로젝트의 새 버전 마이그레이션 프로세스에 대한 전략적 평가를 매우 포괄적인 분석 프레임워크로 검토합니다.
렌더 엔진 및 3D 그래픽 인프라의 혁신
그래픽 처리 파이프라인은 Godot 4.7이 가장 두드러진 진전을 이룬 영역 중 하나입니다. 현대 게임 개발에서 포토리얼리즘과 성능 최적화 사이의 섬세한 균형은 렌더 엔진이 제공하는 도구의 다양성과 하드웨어 가속 용량에 달려 있습니다. 새 버전은 조명 계산부터 머티리얼 관리까지 여러 레이어에서 업계 표준을 충족하는 분석 기능을 제공합니다.
에어리어 라이트(AreaLight3D)와 조명 물리
조명 모델은 3D 렌더 엔진의 시각적 신뢰성을 결정하는 가장 기본적인 요소입니다. Godot 4.7 이전에는 개발자들이 직사각형 또는 넓은 표면의 광원(예: 네온사인, 거대한 산업용 창문, 텔레비전 화면, 형광등, 또는 부드러운 스튜디오 조명)을 시뮬레이션하기 위해 포인트 라이트(point lights)를 군집화하거나 글로벌 Illumination(Global Illumination)으로 지원되는 발광(emissive) 머티리얼을 사용해야 했습니다 1. 이러한 임시방편적이고 간접적인 솔루션은 GPU에 불필요한 성능 비용을 발생시킬 뿐만 아니라, 생성된 그림자의 가장자리 부드러움(penumbra)과 물리적 정확성 측면에서 부족했습니다.
Godot 4.7과 함께 코어 노드 아키텍처에 추가된 AreaLight3D 노드는 빛이 무한히 작은 단일 지점이 아닌, 경계가 정의된 2차원 직사각형 표면적에서 방출되도록 하는 분석적 실시간 렌더링 솔루션을 제공합니다 1. 이 구조적 아키텍처는 광원의 물리적 크기에 따라 자연스럽고 점진적으로 부드러워지는 그림자 전환을 생성하는 동시에, 장르의 매끄럽고 반사되는 표면(specular reflections)에서 광원의 직사각형 모양이 올바르게 반사되도록 보장합니다 1. 레이 트레이싱(ray tracing)이 필요 없는 이 접근 방식은 성능 예산을 초과하지 않고 장면의 조명 품질을 극적으로 향상시킵니다. 건축 시각화, 실내 공포 게임(indoor horror), 시네마틱 분위기 디자인 측면에서 이 발전은 장면 디자이너에게 훨씬 더 깔끔한 워크플로우와 우수한 시각적 품질을 제공합니다.
고동적 범위(HDR) 이미지 출력 지원
디스플레이 기술의 발전과 함께 표준 sRGB 색공간의 한계를 뛰어넘는 하드웨어가 최종 사용자 시장에서 표준이 되기 시작했습니다. Godot 4.7은 엔진이 내부적으로 부동 소수점(floating point) 형식으로 계산한 고동적 범위 조명 데이터를 OS 수준의 HDR API를 통해 직접 지원되는 화면으로 전송할 수 있는 기능을 획득했습니다 2. 이론적으로 최대 10,000니트의 밝기 값을 지원하는 이 기능은 폭발, 네온사인, 마법 효과 또는 직사광선 같은 요소가 화면에서 눈이 멀 정도의 밝기, 깊은 암부, 그리고 훨씬 더 넓은 색 영역(color gamut)으로 제공되도록 허용합니다 3.
HDR 출력을 지원하려면 하드웨어 드라이버 및 OS 창 관리자(window manager)와의 매우 낮은 수준의 통합이 필요하므로 플랫폼 및 렌더 엔진 종속성이 구체적입니다. 이 기능의 통합에 관한 구성 매트릭스는 다음 표에 자세히 설명되어 있습니다:
운영 체제 / 플랫폼HDR 지원 상태필요한 렌더 엔진아키텍처 및 통합 참고 사항Windows전체 지원Forward+ 또는 Mobile운영 체제 수준에서 Windows 색상 설정이 켜져 있어야 하며 호환되는 모니터를 사용해야 합니다.macOS전체 지원Forward+ 또는 MobileApple의 기본 HDR 관리 API 및 Metal 인터페이스와 직접 통합됩니다.iOS & visionOS전체 지원Forward+ 또는 Mobile모바일 Apple 기기의 고휘도 기능 및 XDR 디스플레이 구조와 호환됩니다.Linux (Wayland)전체 지원Forward+ 또는 Mobile최신 Wayland 컴포지터에서만 작동합니다. 포괄적인 창 관리 프로토콜이 필요합니다.Linux (X11)지원되지 않음해당 없음이전 X11 아키텍처의 색심도 제한으로 인해 비활성화되어 있습니다. 개발자는 Wayland로 전환해야 합니다.Android지원되지 않음해당 없음광범위한 Android 하드웨어 단편화(fragmentation)로 인해 현재 사용할 수 없습니다.Web (HTML5)지원되지 않음해당 없음WebGL 및 WebGPU 브라우저 그래픽 API 제한으로 인해 아직 HDR 출력이 표준화되지 않았습니다.
표에서 알 수 있듯이, HDR 사용은 전체적인 요구 사항(requirement)이라기보다는 지원되는 플랫폼에서 활성화되는 선택적 시각적 보완 레이어로 다루어져야 합니다 4. 개발자는 HDR을 모든 아트 디렉션(art direction)의 기반으로 삼는 대신 표준 동적 범위(SDR)에서 잘 보이는 프로젝트를 더욱 풍부하게 만드는 마무리 작업으로 간주해야 합니다 4.
Vulkan 하드웨어 레이 트레이싱(Ray Tracing) 인프라
게임 산업에서 가장 큰 기술적 전환점 중 하나인 하드웨어 레이 트레이싱 기술은 Godot 4.7과 함께 엔진의 Vulkan 아키텍처에 저수준(low-level) 배관(plumbing) 인프라로 통합되었습니다 2. 이 버전에는 플레이어와 개발자가 단일 클릭으로 활성화할 수 있는 "레이 트레이스드 반사"(Ray-traced reflections) 또는 "패스 트레이싱"(Path tracing)과 같은 최종 사용자 기능이 직접 포함되어 있지 않습니다 10. 대신 레이 트레이싱의 핵심 요구 사항인 가속 구조(acceleration structures) 구축 및 Vulkan 렌더 파이프라인 내에서 직접 레이 디스패치(ray dispatch) 기능이 엔진에 제공되었습니다 2.
이 전략적 엔지니어링 움직임은 대규모 스튜디오가 고유한 레이 트레이싱 솔루션(예: 커스텀 조명 셰이더 또는 거울 시스템)을 작성할 수 있는 표준화된 기반을 제공합니다. 과거에 하드웨어 레이 트레이싱을 사용하고자 했던 팀은 NVIDIA 또는 독립 개발자가 유지 관리하는 특수 Godot RTX 포크(fork)에 의존해야 했습니다 2. 4.7과 함께 제공되는 이 코어 통합은 Godot 4.8 및 4.9와 같은 향후 버전에서 기본(built-in) 레이 트레이싱 기능이 메인 엔진(mainline)에서 직접 작동할 것임을 보여주는 확실한 증거입니다 2.
DrawableTexture2D 및 런타임 텍스처 처리
게임 메카닉에서 자주 요구되는 "런타임 중 텍스처에 그리기"(runtime texture drawing) 작업은 이전 버전에서 별도의 Viewport를 생성하여 장면을 해당 뷰포트 내에 렌더링하거나 복잡한 RenderingDevice API를 통해 저수준 GPU 명령을 보내는 간접적이고 비용이 많이 드는 작업으로 수행되었습니다. Godot 4.7은 이러한 어려움을 추상화하고 매우 액세스하기 쉽고 성능이 뛰어난 API인 DrawableTexture2D 클래스를 도입했습니다 2.
DrawableTexture2D를 사용하면 개발자는 표준 블릿(blit) 호출을 사용하여 텍스처(texture)에 직접 픽셀 데이터나 브러시 스트로크를 쓸 수 있습니다 2. 이 기능을 통해 렌더링 API에 깊이 익숙하지 않은 개발자도 복잡한 효과를 쉽게 만들 수 있습니다. 예를 들어, 전략 게임의 탐험 가능한 전장의 안개(fog of war) 마스크, 레이싱 게임의 동적 타이어 자국, 캐릭터가 표면에 페인트를 던지는 메카닉(paint tools), 플레이어가 자유롭게 그림을 그릴 수 있는 도구, 긁기/드러내기(reveal mask) 게임, 또는 피해를 입을 때 변형되는 갑옷 텍스처(scratch effects)를 이 API를 사용하여 메인 시스템에 추가 부하를 주지 않고 개발할 수 있습니다 1.
픽셀 아트와 3D 비주얼: Nearest-Neighbor 스케일링
기존 3D 렌더 엔진은 저해상도 텍스처, 래핑 또는 화면 출력을 화면에 투영할 때 기본적으로 이중 선형(bilinear) 필터링을 사용합니다. 이 부드러움 알고리즘은 포토리얼리즘 그래픽에서는 완벽한 결과를 제공하지만, 특히 90년대 복고풍 스타일(PS1 미학)을 모방하거나 저해상도 3D 픽셀 아트 게임에서 원치 않는 흐림(blurring) 현상을 유발합니다 2. 커뮤니티의 많은 개발자는 이러한 문제를 제거하기 위해 커스텀 셰이더를 작성해야 했습니다. Godot 4.7은 3D 뷰포트(viewport)를 위한 Nearest-Neighbor(최단 이웃) 스케일링 옵션을 표준 엔진 기능으로 통합하여 해상도가 낮아질 때도 픽셀의 선명함과 선의 끊김을 유지하는 완벽한 미적 제어 도구를 제공합니다 1. 이 기능은 현대적인 3D 기능과 향수를 불러일으키는 픽셀 아트 접근 방식을 결합하는 인디 제작물을 위한 필수 인프라를 형성했습니다.
셰이더(Shaders), 효과 및 머티리얼 개선
게임의 시각적 언어를 정의하는 포스트 프로세싱(post-processing) 효과와 파티클 시스템도 세부적인 최적화를 거쳤습니다. 코드 기반 텍스트 셰이더(text shaders)를 작업하는 개발자를 위한 가장 큰 혁신은 편집기 내 인라인(inline) 셰이더 미리보기입니다. 이제 셰이더 코드에서 수학적 변경이 이루어질 때(예: 파동 함수의 주파수가 변경될 때), 엔진을 다시 컴파일하거나 다른 작업 공간으로 전환할 필요 없이 변경 사항을 실시간으로 코드 편집기 배경에서 직접 미리 볼 수 있습니다 2. 이는 반복 속도를 엄청나게 향상시키는 발전입니다.
물리 기반 렌더(PBR) 머티리얼 측면에서는 자동차 도색이나 젖은 바닥과 같은 표면을 시뮬레이션하는 데 사용되는 클리어코트(clearcoat) 렌더 알고리즘이 개선되었으며, 빛이 이러한 투명 레이어에서 굴절되는 방식이 더 정확해졌습니다 1. 렌더 패스(render passes)는 이제 고유한 별도의 환경(environment) 유니폼 버퍼(uniform buffers)를 가질 수 있으며, 이는 복잡한 포스트 프로세싱 체인에서 유연성을 제공합니다 1. 3D 파티클 시스템에서는 개발자에게 파티클의 크기(scale)와 회전(rotation)에 대한 확장된 제어 기능이 제공되었으며, 파티클의 각속도(angular velocity)에 대한 수학적 수정이 적용되어 시뮬레이션이 더 유기적으로 보이도록 했습니다 1.
사용자 인터페이스(UI) 엔지니어링 및 애니메이션
시스템
게임 개발 과정에서 사용자 인터페이스 디자인은 일반적으로 게임의 핵심 메커니즘 코딩보다 훨씬 더 많은 시간이 걸리며, 반복 작업이 필요하고 극도로 취약한 구조를 가진 분야입니다 9 . UI 요소가 게임 화면의 변화하는 해상도에 적응할 수 있도록 Godot은 처음부터 강력한 노드 기반(node-based) 레이아웃 시스템을 제공해 왔습니다. 그러나 4.7 버전은 애니메이션과의 상호작용에서 발생하던 UI 요소의 근본적인 구조적 문제를 해결하여 업계에서 가장 뛰어난 UI 툴킷 중 하나를 선보였습니다 9 .
Control 노드 오프셋 변환(Offset Transforms)
Godot의 UI 레이아웃 시스템은 계층적 Container(컨테이너) 노드를 기반으로 구축됩니다. HBoxContainer(가로 상자) 또는 VBoxContainer(세로 상자) 내부에 배치된 Control 노드(버튼, 패널, 스크롤바 등)는 컨테이너의 자동 정렬 및 배치 알고리즘에 의해 엄격하게 관리됩니다 1 . 과거 버전에서는 디자이너가 버튼에 마우스를 올렸을 때(hover state) 시각적 피드백을 만들기 위해 Tween 애니메이션으로 버튼의 크기(scale), 회전(rotation), 또는 위치(position)를 키웠을 때, 이 변화가 부모 컨테이너에 의해 "레이아웃 깨짐"으로 인식되었습니다. 컨테이너가 즉시 재계산을 수행하여 UI 요소를 자체 알고리즘 논리에 따라 제자리로 돌려놓으려 했고, 이로 인해 버튼이 원치 않는 방식으로 튀어 오르거나(snap back), 메뉴가 깜빡이고, 개발자가 컨테이너 시스템과 말 그대로 싸우게(fighting layout) 되는 원인이 되었습니다 1 .
Godot 4.7이 UI 엔지니어링에 도입한 가장 핵심적인 해결책은 시각적 변환과 논리적 박스 모델(box model)을 서로 분리하는 Control 오프셋 변환(offset transforms) 시스템입니다. 새로 추가된 offset_transform_* (위치, 회전, 크기) 속성은 UI 요소가 시각적으로 어떻게 그려질지 결정하는 동시에, 논리적 좌표와 차지하는 영역은 원래 상태로 둡니다 1 . 즉, 오프셋 변환을 사용하여 버튼을 시각적으로 20% 확대하거나 화면에서 이동시켰을 때, 부모 컨테이너는 이 변경을 레이아웃 업데이트로 인식하지 않고 배치 계산을 유지합니다 4 . 이러한 격리를 통해 UI 프로그래머와 테크니컬 아티스트는 컨테이너 구조나 앵커링(anchoring) 로직을 망가뜨리지 않고 부드럽고 역동적이며 유연한 UI 애니메이션을 완벽하게 디자인할 수 있습니다 4 . 커뮤니티 피드백에 따르면 이 기능은 메뉴 디자인에서 수백 줄의 임시방편(workaround) 코드를 없애주었으며 "생명의 은인"과 같다고 확인바 있습니다 9 .
리치 텍스트 레이블(RichTextLabel) 및 원추형 그라데이션
사용자 인터페이스의 데이터 표시 기능은 현대 게임의 동적 폰트 크기 조정 요구사항에 대응할 수 있도록 개선되었습니다. RichTextLabel 내부에 [img] 태그를 사용하여 삽입된 이미지(예: 텍스트 내에 표시되는 Xbox 컨트롤러 "A" 버튼 또는 특수 이모지 아이콘)를 이제 인라인 텍스트 크기에 반응하여 배치할 수 있습니다 1 . 개발자는 [img height=1em]과 같은 상대적(relative) CSS 유사 정의를 사용하여 게임의 해상도, 언어 번역 또는 접근성 설정이 변경될 때 텍스트 폰트와 함께 이미지도 자동으로 비례하여 크기가 조절되도록 할 수 있습니다 3 .
또한 2D 효과 및 UI 디자인 분야에서 색상 스펙트럼을 생성하는 데 사용되는 GradientTexture2D 클래스에 FILL_CONIC(원추형 채우기) 모드가 추가되었습니다. 표준 선형 또는 원형 그라데이션과 달리 이 원추형 그라데이션 기능은 CSS 스타일에 유사한 방식으로 중심 주위로 색상을 쓸어내듯(sweep) 분산시킵니다. 이 수학적 추가는 2D 셰이더 작성에서 원형 진행 막대, 탄약 표시기, 레이더 스캔 효과 또는 가짜 3D 원통형 셰이딩(fake 3D shading) 환상을 만드는 데 매우 실용적인 기초를 제공합니다 3 .
에디터 생태계 및 개발자 워크플로 개선
게임 엔진은 단순히 실행 파일을 생성하는 컴파일러 엔진일 뿐만 아니라 디자이너, 아티스트, 프로그래머가 수천 시간을 보내는 생산성 및 개발 소프트웨어(IDE)이기도 합니다. 이러한 맥락에서 에디터 자체의 인터페이스 유창성은 개발 시간에 직접적인 영향을 미칩니다. Godot 4.7은 에디터 경험을 최적화하고 클릭 횟수를 줄이며 대규모 프로젝트에서의 인지 부하(cognitive load)를 완화하는 수많은 삶의 질(Quality of Life - QoL) 업데이트를 포함하고 있습니다.
에셋 스토어의 탄생 (구 에셋 라이브러리)
수년 동안 Godot 개발자에게 커뮤니티에서 만든 도구를 다운로드하는 서비스를 제공해 온 에셋 라이브러리(Asset Library)가 처음부터 현대적인 API 표준으로 다시 작성된 에셋 스토어(Asset Store) 개념으로 대체되었습니다 2 . 이것은 단순히 외형적인 이름 변경이 아니라 인프라적 아키텍처 개편입니다. 이전 시스템에서는 방대한 에셋 패키지를 서버에서 가져오거나 검색 쿼리를 처리하는 동안 메인 에디터 스레드(main thread)가 잠겨 멈춤 현상으로 이어졌습니다. 새로운 스토어 API는 백그라운드 스레드(background threading)를 적극적으로 활용합니다 1 . 덕분에 콘텐츠가 다운로드되는 동안 에디터 인터페이스가 완전히 반응형(responsive) 상태를 유지합니다 3 . 또한 에셋을 더 자세히 살펴보기 위한 미리보기 이미지 확대(zoom) 기능, 커뮤니티에서 부여한 최신 평점(rating) 표시, 훨씬 더 깔끔한 카테고리 트리(쇼케이스)가 통합되었습니다 3 .
대규모 3D 프로젝트에서 개발자들이 가장 많은 시간을 낭비하는 지점 중 하나는 복잡한 데이터 구조를 노드(nodes) 간에 전달하는 것입니다. Godot 4.7의 Inspector 패널에 추가된 새로운 패널 도구를 덕분에 서로 유사한 노드 간에 변수(예: X, Y, Z 회전 또는 재질 색상 코드)를 하나씩 복사하고 전달하는 대신, 전체 속성 그룹(property section)을 일괄적으로 복사하여 다른 노드의 동일한 영역에 원클릭으로 붙여넣는 것이 가능해졌습니다 1 . 이 메커니즘은 특히 재질(material) 파라미터나 계층적 물리 구성을 일괄적으로 전송할 때 수동 오류 발생 확률을 0으로 줄여주며 엄청난 시간 절약을 제공합니다 2 .
복잡한 씬의 애니메이션을 관리하는 데 사용되는 AnimationPlayer 및 애니메이션 트랙(Animation Tracks) 패널도 인체공학적으로 개편되었습니다. 40~50개의 서로 다른 트랙이 있는 복잡한 캐릭터 스켈레톤(skeleton)을 애니메이션화할 때 화면이 트랙으로 가득 차서 스크롤(scrolling)이 복잡해지는 것을 방지하기 위해 "사용하지 않는 노드 트랙 접기"(track collapsing) 기능이 도입되었습니다 1 . 접힌 트랙에 있는 키프레임(keyframes)은 단일 행에서 "집합 표현"(aggregate representation)으로 제공되므로, 애니메이터는 접힌 트랙 내부의 구체적인 세부 정보를 보지 않고도 전체 애니메이션 타이밍(timing)에 대한 시각적 가이드를 계속 유지할 수 있습니다 3 .
3D 씬 스냅(Snapping) 및 눈금자 개선
레벨 디자인과 월드 구축(world building)을 수행하는 3D 아티스트와 레벨 디자이너를 위해 씬 조작 도구가 크게 강화되었습니다. Godot 4.7 이전에는 에셋을 결합하고 바닥에 맞추는 작업이 대부분 눈대중이나 수치 입력으로 이루어졌습니다. 새 버전은 업계 표준을 충족하는 세 가지 핵심 툴킷을 제공합니다:
정점 스냅(Vertex Snapping): 에디터에서 키보드의 지정된 단축키(기본값 'B')를 누른 상태에서 개발자가 3D 메시(mesh)의 특정 정점을 직접 선택하여 다른 오브젝트의 정점에 밀리미터 단위의 정확도로 고정(snap)할 수 있습니다 1 . 이것은 모듈식 던전 디자인이나 빌딩 블록을 만들 때 틈이 생기는 것을 방지합니다.
Path3D 및 콜라이더 스냅(Collider Snapping): 씬에 경로를 그리는 데 사용되는 Path3D 노드 포인트는 이제 뷰포트의 카메라 평면(camera plane)뿐만 아니라 씬에 있는 물리적 콜라이더(colliders)의 표면에 직접 스냅될 수 있습니다 1 . 이 기능은 산악 지형이나 경사진 지형 위를 이동하는 인공지능 순찰 경로(patrol paths)나 경주 트랙 경로를 그릴 때 극적인 편의성을 제공합니다 3 .
향상된 눈금자(Ruler): Shift 수정자 키와 함께 사용되는 3D 측정 도구는 이제 두 점 사이의 절대 거리(예: 15미터)뿐만 아니라 3D 공간의 각 좌표 축(X, Y, Z)을 따라 형성되는 상대적 길이 벡터(예: X축에서 10m, Y에서 5m, Z에서 10m)도 각각 별도로 표시합니다 1 . 블록아웃(Blockout)이라고 하는 초기 단계 레벨 디자인에서 이 기하학적 피드백은 매우 중요합니다. 또한 3D 카메라 컨트롤이 엔진 내부의 내장 게임 창(embedded game view)과 통합(unified)되어 개발자가 양쪽에서 키보드 단축키나 탐색 레이아웃을 동일하게 유지할 수 있습니다 3 . 긴 목록에서 원하는 오브젝트를 쉽게 찾을 수 있도록 PopupMenu 창에 검색 바가 추가되었으며, 새 노드(Node) 또는 리소스(Resource) 생성 화면(Create Dialog)에는 "사용자 지정 페이지만 표시"(Show Custom)와 같은 필터링 메커니즘이 통합되었습니다 1 . 코드 에디터에서 작업 중인 개발자가 스크립트 창 상단의 파일 이름을 더블 클릭하면, 파일 시스템에서 해당 파일이 왼쪽에 어디에 위치하는지가 자동으로 강조 표시(highlighted)되어 넓은 데이터 트리 속에서 길을 잃는 것을 방지합니다 3 . Remote Scene Inspector(원격 씬 검사기) 화면에서는 Enum 값이 단순한 무의미한 정수(0, 1, 2)가 아니라 코드 내에서 표현되는 문자열 이름(string names)으로 표시되기 시작했습니다 3 .
모바일 개발, 가상현실(XR) 및 성능 최적화
게임 산업에서 모바일 기기와 가상현실 헤드셋(플랫폼)의 비중이 점차 증가함에 따라, Godot 4.7은 이러한 기기의 하드웨어 제약 사항을 해결하는 전용 소프트웨어 훅(hooks)을 표준 코어 기능으로 채택했습니다.
내장 VirtualJoystick(가상 조이스틱) 통합
모바일 플랫폼용 액션이나 롤플레잉 게임을 개발하는 팀들은 오랫동안 화면의 가상 터치 컨트롤을 위해 타사 플러그인이나 처음부터 직접 작성해야 하고 유지보수가 어려운 입력(input) 코드에 의존해 왔습니다. 커뮤니티 플러그인은 엔진이 업데이트될 때마다 깨질 위험이 있습니다4. Godot 4.7은 엔진 코어에 직접 통합된 VirtualJoystick(가상 조이스틱) 노드를 제공하여 이러한 단편화를 근본적으로 해결합니다1.
이 통합은 모바일 게임 디자인의 고전적인 컨트롤 체계와 완벽하게 호환되는 세 가지 서로 다른 상호작용 모델을 지원합니다.
조이스틱 모드메커니즘 및 사용자 동작이상적인 사용 시나리오고정형 (Fixed)조이스틱의 화면 상 위치가 고정되어 있습니다. 플레이어는 엄지손가락을 화면의 특정 영역으로 드래그해야 합니다. 중앙에 고전적인 "데드 존(dead zone)" 설정이 있습니다.레트로 아케이드 포트, 콘솔 스타일의 고정형 컨트롤러1.동적형 (Dynamic)플레이어가 화면의 지정된 영역을 터치하는 순간 그 지점에 조이스틱이 나타납니다. 손가락을 떼면 즉시 사라지며 위치가 초기화됩니다.빠른 반응이 요구되는 슈터(shooter) 게임들1.추종형 (Following)동적 모드와 동일한 원리로 시작되지만, 플레이어의 엄지손가락이 이동 한계를 초과하면 조이스틱의 중심축도 손가락을 따라 이동하여 플레이어가 지속적인 접촉을 유지할 수 있도록 합니다.캐릭터가 멈추지 않고 이동하는 RPG 또는 무한 러너 게임들1.
또한 컨트롤러(gamepad)의 가속도계(accelerometer) 및 자이로스코프(gyroscope) 데이터를 API를 통해 읽을 수 있게 되었으며, 모바일 또는 콘솔 게임 패드가 제공하는 기울기 및 모션(motion) 컨트롤의 통합이 안정화되었습니다3.
GABE(Godot Android Build Environment) 및 온디바이스 개발
Godot은 단순히 Android용 게임을 개발하는 것에 그치지 않고, 철학적 입장으로서 "Android 운영체제가 탑재된 태블릿 및 모바일 기기에서 직접 게임 개발하기"(Godot Editor for Android) 비전을 4.7 버전에서 크게 도약시켰습니다. GABE(Godot Android Build Environment)라는 특수 컴패니언(companion) 앱 덕분에, Android 기기(예: 삼성 갤럭시 Tab)에서 실행되는 Godot 에디터는 APK 또는 AAB를 생성하는 데 필요한 Gradle 내보내기 지원을 기기 내부에서 직접 갖추게 되었습니다3. 이는 개발자가 컴퓨터 없이 기기에서 작성한 코드를 직접 컴파일하여 완전한 배포 패키지(APK)를 생성할 수 있음을 의미합니다4.
Android에서 실행되는 에디터의 인체공학적 제약도 극복되었습니다. 런타임의 임베디드 게임 창(embedded game window)은 이제 고정되어 있지 않고 크기 조절 및 드래그가 가능해졌으며, 이를 통해 가로, 세로, 태블릿 포맷 등 다양한 화면 종횡비(aspect ratios)를 단일 기기에서 테스트할 수 있게 되었습니다1. 스크립트(script) 작성 화면은 기기의 가로/세로 센서에 반응하여 회전이 가능(landscape coding)해졌으므로, 키보드를 연결했을 때의 인체공학적 편의성이 향상되었습니다4. 또한 화면 속 화면(Picture-in-Picture) 기능을 통해 테스트 과정이 훨씬 모듈화되었으며, 백그라운드에서 실행되는 동안에도 게임을 모니터링할 수 있게 되었습니다1. 내보내기 옵션이 확장되어 Android 프로젝트의 시작(splash) 화면을 이제 커스터마이징 가능한 구조로 설정할 수 있게 되었습니다1.
그러나 이 시점에서 개발자 생태계로부터 들어오는 성능 경고에 주목할 필요가 있습니다. Godot의 3D 엔진은 고급 기능을 갖추고 있지만, 특히 모바일 기기에서 Compatibility(GLES3/OpenGL) 엔진을 사용할 때 Mali G68과 같은 중급형 GPU를 탑재한 기기에서는 렌더링 제약이 발생할 수 있습니다. 업계 분석(예: Reddit 테스트 보고서)에 따르면, 배경 객체가 매우 적고 3,000개의 폴리곤만 포함하는 단순한 장면에서도 해상도 스케일을 낮추지 않으면 프레임 속도가 38 FPS까지 떨어질 수 있음을 보여줍니다16. 따라서 개발자는 Android 플랫폼용 3D 제품을 개발할 때 뷰포트 해상도 스케일(viewport resolution scale), 머티리얼 단순성, 테스트 기기의 다양성에 최대한 주의를 기울여야 합니다16.
확장 현실(XR): 컴포지션 레이어와 포비디 렌더링
가상현실(VR) 및 증강현실(AR) 시장에서 업계 표준이 된 OpenXR 아키텍처는 Godot 4.7을 통해 더욱 실용적인 프로덕션 중심으로 개선되었습니다2. Steam Frame 및 Android XR 플랫폼에 프로덕션 수준(production-ready)의 지원이 제공되는 한편, OpenXR 액션 맵(action maps)이 가장 기본적인 4개의 프로필로 간소화되어 컨트롤러 통합의 복잡성이 완화되었습니다1.
VR 개발 과정에서 사용자 인터페이스(UI)의 가독성은 가장 중요한 인체공학적 문제입니다. 헤드업 디스플레이(HUD)나 텍스트를 일반적인 3D 지오메트리처럼 장면에 배치하는 경우(eye-buffer rendering), 렌즈의 초점 거리와 픽셀 밀도로 인해 떨리고 흐리며 읽기 힘든 텍스트가 발생합니다. OpenXR 컴포지션 레이어(composition layer) 시스템은 인터페이스를 일반적인 게임 월드 버퍼 외부로 이동시켜 바이저의 투사 레이어(프로젝터 위)에 직접 렌더링합니다3.
Godot 4.7은 이러한 컴포지션 레이어에 대한 제어력을 심화했습니다. 개발자는 이제 다음과 같은 작업을 수행할 수 있습니다.
컴포지션 레이어를 장면의 XRCamera3D 노드에 직접 고정(lock)하여, 플레이어가 고개를 얼마나 빨리 돌리더라도 시야각에서 밀리초 단위의 지연조차 없이 유지되는 초고선명(crisp) HUD 화면을 설계할 수 있습니다3.
컴포지션 레이어 객체를 월드 지오메트리(world geometry)와 페어링(pairing)하여 텍스트 레이어를 공간의 특정 좌표에 고정(world-locked)된 상태로 남겨둘 수 있습니다3.
그래픽 성능 측면에서 VR 헤드셋(예: Meta Quest)은 해상도가 엄청난 기기이며, 단 1밀리초라도 아끼는 것이 편안함(comfort) 측면에서 매우 중요합니다4. Godot 4.7의 모바일 렌더 엔진에는 Vulkan "서브샘플링된 이미지(Subsampled images)" 기술이 통합되었습니다1. 이 기술은 포비디 렌더링(foveated rendering; 사용자가 응시하는 중앙은 선명하게, 주변 시야는 낮은 해상도로 렌더링하는 기술) 과정에서 처리된 픽셀을 더 낮은 밀도로 저장하여 GPU 메모리 대역폭(memory bandwidth)을 극적으로 감소시킵니다3. 이를 통해 성능과 모바일 기기 배터리
소모 측면에서 엄청난 이득을 얻을 수 있습니다 1 . XR 프로젝트의 경우 기본적으로 모바일 렌더 엔진을 사용하는 것이 권장됩니다 1 .
물리 철학과 향상된 2D 툴셋
물리 시스템과 충돌 알고리즘은 게임 엔진의 행동적 심장부를 구성합니다. Godot은 4.6 버전을 통해 고성능 Jolt Physics 애드온을 기본 3D 물리 엔진으로 코어 생태계에 편입시킨 바 있습니다. 업계의 일부 소문과 달리 4.7 버전은 Jolt Physics를 교체하거나 폐기하지 않았으며, Jolt 엔진은 새로운 3D 프로젝트와 4.7 아키텍처의 기본(default) 물리 엔진으로서 프로덕션 환경에서의 안정성을 유지하고 있습니다 1 . 그러나 4.7 버전은 2D 충돌 아키텍처의 오랜 제약을 극복함으로써 진정한 물리 혁신을 이루어냈습니다.
단방향 충돌 방향의 자유도 (One-way Collision)
2D 플랫폼 게임(예: 마리오나 할로우 나이트처럼 캐릭터가 아래에서 뛰어올라 통과한 뒤 위를 밟고 설 수 있는 구름이나 현수교 플랫폼 등)에서는 단방향 충돌이 자주 사용되는 메커니즘입니다. Godot 4.7 이전에는 물리 엔진이 단방향 충돌 벡터가 해당 CollisionShape2D 노드 자체의 로컬 "위쪽(Up)" 방향(0, -1 벡터)을 향한다고 엄격하고 변경 불가능하게 가정하고 있었습니다 3 . 게임 디자이너가 충돌 방향을 변경하고자 할 때(예: 캐릭터가 오른쪽에서는 통과하지만 왼쪽과는 충돌하는 벽), 콜라이더(collider)의 물리적 구조나 회전을 시각적 그래픽 노드와 완전히 독립적으로 회전시키고 이 두 구조를 동기화해야 하는 고통스러운(painful) 꼼수를 써야 했습니다 3 .
4.7 업데이트를 통해 CollisionShape2D 클래스에 one_way_collision_direction(단방향 충돌 방향)이라는 새로운 변수가 추가되었습니다 3 . 이 기능을 통해 단방향 상호작용의 방향 벡터는 충돌 모양의 전체적인 기하학적 구조(상자 또는 캡슐 구조)를 전혀 손상시키지 않고 360도 로컬 공간에서 자유롭게 지정할 수 있습니다 3 . 이로 인해 강한 바람 흐름, 캐릭터를 밀어내는 컨베이어 벨트, 각도가 있는 중력 영역, 또는 플랫폼 슬라이딩 메커니즘의 코딩이 불필요한 회전 계산에서 벗어나 훨씬 우아하고 수학적으로 정확한 방식으로 처리될 수 있게 되었습니다.
동적 CSG 스무딩 (Autosmooth)
구성적 솔리드 지오메트리(Constructive Solid Geometry - CSG)는 게임 디자이너가 Blender나 Maya 같은 외부 3D 모델링 프로그램 없이도, 엔진 내부에서 교차하는 단순한 기하학적 모양(상자, 구, 실린더)을 사용하여 (합집합, 차집합, 교집합 연산을 통해) 즉시 3D 레벨(level)을 프로토타이핑할 수 있게 해주는 도구입니다 3 . 하지만 생성된 CSG 바닥은 항상 날카롭고 저폴리곤이며 거칠어 보였습니다.
Godot 4.7의 CSG 루트 노드에 추가된 새로운 Autosmooth(자동 스무딩) 기능은 이러한 날카로운 다각형 구조를 하드웨어 수준에서 절차적(procedurally)으로 부드럽게 만들어 줍니다 3 . 스무딩 각도(Smoothing Angle) 파라미터는 기본적으로 50도로 설정되어 있으며, 이 임계값 미만의 표면 접합부는 자동으로 부드러운 표면(smooth faces)으로 처리되는 반면 각도가 더 높고 가파른 교차점은 모서리 라인(sharp faces)을 계속 유지합니다 3 . 값이 클수록 더 공격적인 스무딩 프로파일이 적용되며, 이 기능은 프로토타이핑을 하는 팀뿐만 아니라 로우 폴리(low-poly) 제작을 하는 스튜디오도 CSG 구조를 최종 제품(final asset) 품질로 게임에 직접 적용할 수 있게 해줍니다 3 .
API 변경 사항, 스크립팅 및
마이그레이션(전환) 전략 모든 주요 .x 버전 업데이트(마이너 release)는 새로운 기능을 추가하는 한편 백그라운드에서 엔진 성능을 향상시키기 위해 일부 API(응용 프로그램 프로그래밍 인터페이스) 시그니처를 변경하며 코드 수준의 호환성 파괴 변경(breaking changes)을 포함합니다 3 . Godot 4.7의 기본 철학은 하위 호환성을 유지하는 것이지만, 개발자가 기존 4.6(또는 그 이전) 프로젝트를 업데이트할 때 고려해야 하는 엄격한 마이그레이션 계층 구조가 존재합니다.
마이그레이션 과정에서 가장 핵심적인 방법론은 현재 활발히 작업 중인 프로젝트의 기존 디렉토리를 엔진의 새로운 4.7 버전으로 직접 열지 않는 것이며, 대신 프로젝트의 버전 관리 시스템(VCS - 예: Git)에서 새로운 테스트 브랜치(branch)를 생성하거나 전체 폴더의 완전한 복사본을 만드는 것입니다 1 . 에디터가 프로젝트를 4.7 형식으로 처음 열 때 모든 텍스처, 텍스트 및 모델 가져오기 파이프라인(import pipeline) 과정을 처음부터 다시 작성하기 때문에, 이 작업은 되돌릴 수 없으므로 격리를 통해 치명적인 데이터 손실과 역호환성 손상을 방지할 수 있습니다 13 .
프로그래밍 및 스크립트 작성 신기능
Godot의 자체 동적 스크립팅 언어인 GDScript는 4.7 버전에서 흐름 제어 및 시스템 통합 측면에서 강화되었습니다.
Java 인터페이스(Interfaces) 구현: 이전에는 Android 기기의 특수 하드웨어(카메라 API, 특수 센서 또는 결제 시스템)에 접근하기 위해 C++ 또는 Java로 중간 플러그인을 작성해야 했습니다. 4.7 버전부터 GDScript는 엔진 내부에서 직접 Java 인터페이스를 통합할 수 있는 기능을 획득하여 외부 플러그인에 대한 의존도를 크게 완화했습니다 1 .
트윈 일시 정지(tween_await): 코드 기반 애니메이션을 생성하는 데 사용되는 Tween 시스템은 이제 tween_await() 함수를 호출하여 시스템 내의 다른 객체로부터 오는 시그널(signal)이 트리거될 때까지 자체 런타임을 일시 정지(pause)할 수 있습니다. 이 기능은 비동기(asynchronous) 애니메이션 체인을 생성하는 데 엄청난 편의성을 제공합니다 1 .
C# (.NET) 사용자를 위한 구조적 시스템은 유지됩니다. Godot 4.7은 "Standard"(GDScript 및 GDExtension을 통한 C++ 지원)와 ".NET"(C#을 지원하며 .NET SDK 필요)이라는 두 가지 별도의 실행 가능 바이너리(binary) 배포판을 계속 제공합니다 1 . 과거의 C# 기반 프로젝트를 새로운 Standard 엔진으로 열 경우 스크립트가 컴파일되지 않고 오류가 발생하므로 올바른 버전을 다운로드하는 것이 필수적입니다 1 .
주요 호환성 파괴 변경 사항(Breaking Changes) 표
아래 표는 Godot 4.6에서 Godot 4.7로 전환할 때 기존 코드 구조, 데이터 형식 및 API 호출에 영향을 주어 리팩토링이 필요한 핵심 변경 사항을 요약한 것입니다.
영향을 받는 클래스 / 시스템특징변경 된 메서드 / 변경 내용 및 상세 설명아키텍처의 호환성 상태 (GDScript / C#)Object (코어 - Core)is_class()class 파라미터의 타입이 일반 String 타입에서 C++ 레벨에서 훨씬 빠르고 정적 메모리를 사용하는 StringName 타입으로 변경되었습니다18. 객체 쿼리 성능이 향상됩니다.GDScript: 호환됨.
C#: 바이너리 및 소스 호환됨.ZIPPacker (코어)start_file()보안을 위한 permissions(파일 권한)과 타임스탬프를 위한 modified_time(수정 시간)이라는 두 가지 새로운 파라미터가 API에 추가되었습니다18.GDScript: 호환됨.
C#: 바이너리 및 소스 호환됨.OptimizedTranslationgenerate()언어 현지화(localization) 함수의 성공 여부를 보고할 수 있도록 반환(return) 값이 void 타입에서 불리언(bool) 타입으로 변경되었습니다18.GDScript: 호환됨.
C#: 바이너리 호환되지 않음, 소스 호환됨.GPU/CPUParticles2D 및 3Drequest_particles_process()파티션 시뮬레이션의 물리적 정확성을 높이기 위해 미세 조정용 process_time_residual 파라미터가 추가되었습니다18.모든 언어에 대해 호환됨.Control (인터페이스 - GUI)accessibility_live스크린 리더와 같은 접근성(accessibility) 기능이 그래픽 디스플레이 서버(DisplayServer)에서 분리되어 자체 AccessibilityServer.AccessibilityLiveMode 타입으로 이전되었습니다18.GDScript: 호환됨.
C#: 완전히 호환되지 않음 (수동 리팩토링 필요).RichTextLabel (인터페이스)Constant (상수) 열거형너비 지정 파라미터인 ImageUpdateMask.UPDATE_WIDTH_IN_PERCENT 변수명이 논리적 구조에 더 적합한 ImageUpdateMask.UPDATE_WIDTH_UNIT으로 업데이트되었습니다18.GDScript: 호환되지 않음.
C#: 바이너리 호환되지 않음, 소스 호환되지 않음.RichTextLabel (인터페이스)add_image() / update_image()크기 조절 유연성을 제공하고 1em과 같은 상대적(relative) 소수점 스케일을 지원하기 위해 width 및 height 파라미터가 정수(int) 타입에서 부동소수점(float) 타입으로 변경되었습니다18.모든 언어에 대해 호환됨.
업데이트 후 검증 및 테스트 절차
프로젝트가 4.7 환경의 버전 관리 시스템에서 성공적으로 열린 후, 컴파일이 되더라도 특정 모듈의 런타임(runtime) 회귀 테스트를 거쳐야 합니다.
UI 계층 구조: 새로 도입된 offset_transform 동적 기능이 기존의 깊게 중첩된 부모-자식 노드 레이아웃, 스크롤 뷰(scroll views) 또는 팝업 메뉴(popup menus) 계산 알고리즘에 영향을 줄 수 있으므로 메인 메뉴, 인벤토리, 설정(HUD) 화면을 처음부터 끝까지 테스트해야 합니다 1 .
재질 표현 및 렌더 채널: 표준 동적 범위(SDR)에서 환경에 포함된 HDR 지원 렌더 채널로의 전환 및 클리어코트(clearcoat) 알고리즘으로 인해 PBR 재질 외형에서 색상 틀어짐(color shifting), 빛 새어 나옴 또는 그림자 차이가 관찰될 수 있으므로 모든 조명 구조를 검증해야 합니다 1 .
Android 설정 및 XR 프로필: 내보내기 프리셋(export presets)의 Android 스플래시 화면, OBB 데이터 패키징 변경 사항 및 4개의 기본 프로필로 단순화된 OpenXR 모션 맵(action maps)을 처음부터 검증해야 합니다 1 .
C++ GDExtension 플러그인: 프로젝트에서 사용되며 엔진의 C++ 소스 코드에 바인딩(bind)되는 라이브러리(GDExtensions)가 Godot 4.7의 새로운 API 시그니처를 지원하도록 업데이트되지 않은 경우 엔진이 충돌할 수 있습니다. 업그레이드 전에 불필요한 플러그인을 비활성화하고 프로젝트 설정에서 각 플러그인이 성공적으로 로드되었는지 확인해야 합니다 1 .
결과
Godot 4.7 버전은 단순한 게임 엔진에 "미디어 기능 추가"라는 마케팅 철학에서 벗어나, 전문적인 게임 제작 주기의 고질적인 고통을 체계적으로 겨냥한 성숙한 엔지니어링 업데이트입니다 4 . 업계와 Reddit 같은 독립 커뮤니티 중심의 분석이 명확히 보여주듯, Unity와 같은 기존 엔진에서 전환하는 개발자의 기대를 충족할 안정성과 제작 실용성에 도달했습니다 8 .
AreaLight3D와 HDR 이미지 통합은 아키텍처 시각화 및 고품질 3D 실사 프로젝트에서 엔진의 역량을 입증하는 동시에, 하드웨어 레이 트레이싱(Ray Tracing) 인프라가 코어에 통합됨으로써 미래의 시각적 표준에 대한 엔진의 전략적 준비 상태를 상징합니다 2 . 반면, Control 노드의 오프셋 변환은 UI 개발자의 가장 큰 악몽 중 하나인 "레이아웃 깨짐" 문제를 해결했으며, VirtualJoystick 및 GABE 통합은 모바일 시장의 외부 종속성(플러그인)을 종식했습니다 1 . 포비티드 렌더링(foveated rendering)을 지원하는 Vulkan 서브샘플링 이미지(subsampled images) 시스템을 통해 XR 하드웨어의 성능 한계도 극대화되었습니다 1 .
오픈 소스 철학과 수백 명 기여자(contributor)의 노고로 빚어진 Godot Engine은 4.7 버전을 통해 4.x 세대 중 가장 안정적이고, 개발자 친화적이며(developer-friendly), 현대적인
하드웨어 용량을 최대한 활용하는 변형을 선보였습니다. 기존 프로젝트의 세부 API 변경 사항, 호환성 한계 및 테스트 절차를 고려하여 수행되는 격리된 버전 마이그레이션(migration) 전략은 개발 스튜디오 프로젝트의 제작 속도(iteration time), 제품 유지 관리 비용, 최종 사용자 관점의 그래픽 품질을 의심할 여지 없이 최고 수준으로 끌어올릴 것입니다.
*정보 : 이미지는 Google Gemini에 의해 생성되었습니다.