Godot 쇼케이스 – Xogot: iPad 및 iPhone을 위한 Godot

작년에 출시되었지만 오랜 기간 준비해 온 프로젝트를 소개하게 되어 기쁩니다. Xibbon의 팀원들은 Godot Engine을 iOS 플랫폼으로 포팅하기 위해 열심히 노력해 왔습니다. 그들은 에디터(Editor)를 iOS에서 실행되도록 포팅했을 뿐만 아니라, 엔진이 Apple의 엄격한 UI 및 UX 가이드라인에 부합하도록 에디터를 커스텀 iOS 인터페이스와 성공적으로 연결했습니다. iPad와 iPhone에서 그들의 앱을 사용하는 것은 완전히 네이티브(Native)하게 느껴지는데, 실제로 네이티브이기 때문입니다! Xibbon은 코드 기여 및 이벤트 측면에서 우리 커뮤니티에서 활발하게 활동해 왔습니다. Xibbon은 미국에서 열린 첫 번째 GodotCon과 같은 이벤트에서 우리의 스폰서였습니다! 오늘, GNOME, Mono, Xamarin 프로젝트를 시작한 것으로 알려진 Miguel de Icaza가 자신의 iOS 앱을 개발한 경험을 우리와 공유합니다.

프로젝트에 대해 조금 말씀해 주실 수 있나요?

Xogot는 Godot 에디터(Editor)를 iPad와 iPhone에 네이티브 iOS 애플리케이션으로 가져옵니다. Xogot는 Godot 에디터와 Godot Engine을 사용하지만, 우리는 Apple의 네이티브 사용자 인터페이스(User Interface) 요소 위에 구축된 대안적인 사용자 인터페이스 및 셸(Shell)을 제공합니다. 우리는 사용자 경험(User Experience)을 터치 친화적으로 조정하는 동시에, 이러한 기기들의 더 제한적인 화면 공간에서도 작동하도록 최적화했습니다. 기존 Godot 에디터 위에 새로운 사용자 인터페이스를 구현함으로써, 우리는 데스크톱 Godot와의 호환성을 유지하여 사용자가 플랫폼 간을 원활하게 이동할 수 있도록 했지만, 단순히 데스크톱 경험을 iPad에서 실행하는 것이 아니라 진정으로 iPad에 속하는 제품을 만들고 싶었습니다. 저는 엔지니어이지만, iPad에서 창의적인 앱을 사용하며 얻는 즐거움은 비할 데가 없습니다. 손가락으로 세상과 상호작용하는 것은 우리가 아기 때 습득하는 가장 초기 기술 중 하나이며, 터치 사용자 인터페이스(Touch User Interface)를 사용하는 물리적 피드백은 매우 보람차다고 생각합니다. 저는 iPad로 시간을 보내는 것뿐만 아니라, 크리에이터들이 스케치, 드로잉, 모델링, 작곡, 영상 편집, 그리고 게임 제작을 위해 iPad를 사용하는 것을 보는 것도 매우 좋아합니다.

왜 Xogot를 만들고 싶었나요?

Xogot는 매우 애정 어린 노력의 산물이며, 완벽한 조건들이 맞물린 결과이자 우리 자신의 지평을 넓히고 안주하던 영역(comfort zone)에서 벗어나기 위한 방법입니다. 우리는 거의 14년 동안 모바일 세계에서 작업해 왔으며, .NET 개발자들이 모바일 플랫폼을 타겟팅할 수 있도록 돕는 개발자 도구들을 구축해 왔습니다. 주로 IDE와 도구들을 제작하고, 소프트웨어를 사용자에게 전달하려는 다른 이들의 여정을 지원해 왔습니다(그 과정에는 .NET을 Godot에 가져오기 위한 초기 노력을 지원하는 것도 포함되었습니다). 우리는 안주하던 영역에서 벗어나, 고도로 다듬어진 앱에 집착하는 iOS 개발자들의 정신(ethos)을 따르는 엔드 유저(end-user) 제품을 만들고 싶었습니다. 사용자 경험(user experience)의 세부 사항에 집착하고 즐거운 사용자 인터페이스(user interface)를 만들기 위해 노력하는 제품 말입니다. 거의 16년 동안 우리는 게임 산업 종사자들이 게임 개발을 위해 .NET을 채택하도록 도왔으며, 우리의 컴파일러와 도구들을 그들의 시스템에 가져오려는 다양한 게임, 엔진, 하드웨어 벤더들의 노력을 지원해 왔습니다. 우리가 iOS 커뮤니티로부터 영감을 받았던 것처럼, 우리는 게임 개발자 커뮤니티로부터도 영감을 받았습니다. 즉, 우리를 즐겁게 하고 놀라게 할 방법을 탐구하며 온 마음을 쏟는 사람들로부터 영감을 받았으며, 우리는 이 즐거운 세상에 더 가까워지고 싶었습니다. 마지막으로, 우리는 Unity의 경영진이 커뮤니티 전체의 개발자 신뢰를 흔드는 결정을 내렸을 때 게임 엔진 산업의 중대한 전환점을 모두 목격했습니다. 우리는 업계가 대안을 찾기 위해 서두르는 모습을 지켜보았고, 이미 Godot에 정서적으로 깊이 몰입해 있었기에 우리는 "어떻게 하면 Godot 커뮤니티에 우위를 제공할 수 있을까?"라는 입장에 서 있었습니다.

Godot 에디터를 iPad와 iPhone으로 가져오는 과정에서 어려웠던 점은 무엇인가요? 이것은 미끄러운 경사로(slippery slope)의 전형적인 사례이자, 야크 털 깎기(Yak Shaving, 본질적인 목표를 달성하기 위해 부수적인 작업에 매달리는 현상)의 극단적인 사례입니다. 도전 과제는 세 가지 범주로 나뉩니다: 멀티 프로세스(Multi-process), 사용자 경험(User experience), 임베딩(Embedding). 처음에는 "iPad에서 Godot를 실행하는 게 얼마나 어렵겠어?"라고 생각했지만, iPad에서 Godot를 실행하는 것은 꽤 간단하면서도 몇 가지 제약 조건이 따른다는 사실이 밝혀졌습니다.

가장 먼저 해결해야 할 문제는 Godot의 워크플로우(workflow)가 세 가지 프로세스를 사용한다는 점입니다. 즉, 필요할 때마다 새로운 Godot 에디터(Editor)를 생성하는 홈 화면, Godot 에디터 자체, 그리고 “재생(play)”을 누를 때마다 실행되는 새롭고 깨끗한 Godot 인스턴스입니다. 문제는 iPadOS가 각 단계마다 새로운 프로세스를 생성하는 위와 같은 모델을 제대로 지원하지 않고, 대신 단일 프로세스 내에서 모든 것을 처리해야 한다는 점입니다. 만약 새로운 프로젝트를 실행할 수 없더라도 Godot가 작동은 했겠지만, 사용자들에게 그리 흥미로운 경험은 아니었을 것입니다.

우리는 먼저 Godot의 상태를 새로운 프로세스 상태로 초기화하는 개념 증명(proof of concept)을 실험했습니다. 이 방식은 작동했으며, 하나의 게임을 편집한 뒤 두 번째 게임을 편집하는 것을 가능하게 했습니다. 우리는 이를 “상태 초기화(reset state)” 작업이라고 불렀습니다. 하지만 이 역시 여전히 충분히 유용하지는 않았습니다. 두 번째 단계는 에디터가 자식 프로세스(child process)를 실행하도록 만드는 것이었습니다. 이를 위해 우리는 Godot의 모든 전역 변수(global variable)를 “가상화(virtualize)”하여 여러 인스턴스를 동시에 실행할 수 있도록 했습니다. 이 방식은 매우 잘 작동했지만, 전역 변수 및 정적 변수(static variable)에 대한 모든 접근을 제거하기 위해 Godot의 방대한 코드 덩어리를 직접 수정해야 하는 매우 수동적인 과정에 의존해야 했습니다.

이후 우리는 기존 Godot 코드베이스를 입력받아 필요할 때마다 가상화된 Godot를 생성해 주는 clang 기반의 리라이터(rewriter)에 투자했습니다. 이것이 현재 우리가 기반으로 삼고 있는 기술입니다. 이 시스템을 통해 우리는 여러 프로젝트를 열 수 있었을 뿐만 아니라, 개발 중인 게임을 반복해서 시작하고 중단할 수도 있게 되었습니다. 이제 드디어 제대로 탄력을 받기 시작한 것입니다. 마지막 구성 요소는 단순히 Godot의 별도 인스턴스를 실행하는 것을 넘어, 이들이 나란히(side-by-side) 실행되도록 하는 것이었습니다. 이는 동일한 주소 공간(address space)에서 실행 중인 “가상” 프로세스에 대해 디버깅(debugging)을 구현하는 데 필수적이었습니다. 우리는 플랫폼의 제약 사항을 해결해야 할 즐거운 도전 과제로 받아들였으며, 저는 그 결과에 대해 엄청난 자부심을 느낍니다. 이는 해결하기 매우 만족스러운 기술적 문제였지만, 그렇다고 해서 그것이 곧바로 훌륭한 iPad 경험으로 이어지는 것은 아니었습니다.

Godot는 공간이 넉넉하고 작은 사용자 인터페이스 (UI) 요소에 마우스를 쉽게 조준할 수 있는 데스크톱 컴퓨터를 위해 설계되었습니다. iPad 및 iPhone의 경우, Apple은 사용자가 편안하게 상호작용할 수 있도록 요소의 크기를 최소 44포인트 (points) 이상으로 유지할 것을 권장합니다. 실제로 제가 "이번 한 번만" 더 작은 사용자 인터페이스 (UI)로 넘어가도 괜찮을 것이라고 생각할 때마다, 사용자도 저 자신도 그것을 탭할 수 없다는 사실을 뼈아프게 깨달았습니다. 우리는 그 교훈을 반복해서 배웠습니다. 44포인트. 이제는 잊지 않기 위해 제 책상 옆에 종이에 적어 붙여두었습니다. 하지만 컨트롤의 크기를 조정하더라도 iPad에서의 사용자 인터페이스 (UI) 느낌은 좋지 않았습니다. Godot는 분명 마우스와 키보드로 사용하도록 의도되었기에, 우리는 사용자들에게 가장 문제가 되는 영역들을 해결하기로 했습니다. "이 버튼을 더 크게 만들어라" 또는 "이것을 다른 곳에 표시하라"와 같은 기계적인 문제도 있었지만, 어떤 것들은 더 철학적인 문제였습니다. GNOME 데스크톱에서의 이전 경험에서 우리는 Godot와 유사한 경로를 추구했습니다. 즉, 사용자 인터페이스 (UI)를 제공하려고 노력하되, 의도된 동작에 대해 의견 차이가 있을 때마다 편집자적인 결정이나 디자인 결정을 내리는 대신 선택지를 제공했습니다. 하나를 주거나, 세 개를 주거나, 네 개 혹은 다섯 개, 즉 의견이 있는 만큼 많은 선택지를 제공했습니다. 선택지를 제공하는 것은 이론적으로는 훌륭해 보이지만, 실제로는 끔찍합니다. 옵션은 사용자를 마비시킬 수 있고, 각 옵션은 두 개의 코드 경로 (codepaths)를 테스트하도록 강제합니다. 운이 좋아 옵션들이 서로 상호작용하지 않을 때의 이야기입니다. 만약 옵션들이 서로 상호작용한다면, 이제 그 기능들의 조합을 테스트해야 합니다. 그리고 나서 이 모든 조합을 문서화해야 하죠. 우리는 훌륭한 iOS 애플리케이션의 정신 (ethos)에 부합하는 애플리케이션을 원했습니다. 우리는 편집자로서 행동하여 적절한 기본값 (defaults)이 드러나도록 디자인 결정을 내려야 한다고 느꼈고, 우리가 필요하다고 생각하는 것들만 노출하기로 결정했습니다. 전반적으로 우리는 꽤 잘 해냈다고 생각하지만, 가끔씩 사용자들은 불만을 제기하며 왜 특정 옵션이 정말로 필요한지에 대해 논거를 제시하곤 했습니다.

따라서 그러한 경우에 우리는 이전에는 표시되지 않았던 설정 수준을 다시 가져오거나 요소들을 다시 표면화했습니다. 우리의 디자인 프로세스는 블로그에 기록되어 있으며, 여러분은 우리의 프로세스와 시간이 흐름에 따라 개념이 어떻게 반복(iteration)되었는지 확인할 수 있습니다. 처음에는 씬 패드(scene pad), 파일 패드(file pad)와 같은 몇 가지 부분만 다룰 것이라고 생각했습니다. 하지만 시간이 지나면서 우리는 Godot의 거의 모든 사용자 인터페이스(UI)를 다시 작성하게 되었습니다. 이는 UI가 훨씬 더 나은 느낌을 주었기 때문이기도 하지만, 사용자들이 UI의 서로 다른 부분에서 어려움을 겪었기 때문이기도 합니다. 이 과정은 매우 광범위하면서도 꽤 즐거운 과정이었습니다. SwiftUI 덕분에 이 작업은 즐거운 연습이 되었습니다. 처음에는 단순히 Godot 에디터(Editor) 위에 새로운 UI를 레이어로 쌓았고, 실행 시 더 적은 UI 요소가 표시되도록 Godot을 커스터마이징했습니다. 이것은 한동안 효과가 있었지만, 어느 시점에 이르면 하단 바 패널(bottom bar panels), 인스펙터(inspector) 내부에서 렌더링되는 플러그인(plugins), 그리고 커스텀 Godot 사용자 인터페이스 코드에 대한 폴백(fallback)과 같이 우리가 제어하는 SwiftUI 뷰(view) 내에 Godot UI의 일부를 "호스팅(host)"해야 할 필요성을 느꼈습니다. 이를 위해 우리는 Godot UI의 일부를 "재호스팅(rehost)"할 수 있게 해주는 시스템을 사용했습니다. 이러한 방식은 Godot으로 작업하는 데 필요한 모든 것이 그대로 유지되도록 보장하면서, 사용자 경험(UX)을 완전히 제어하기 위해 중요했습니다. 데스크톱 애플리케이션인 Godot을 쾌적하고 터치 우선적인 iPad 애플리케이션으로 적응시키는 것은 많은 작업이 필요했으며, 우리는 앞으로 더 이상의 축소나 조정은 없을 것이라고 확신했습니다. 하지만 iPad 버전을 출시하기 전 베타 기간 중에도 테스터들은 계속해서 iPhone 버전을 요청했습니다. 우리는 이것이 반드시 필요하다고 확신하지 않았지만, 사용자들은 앱을 튜닝하거나, 이동 중에 실험하거나, 짧은 휴식 시간 동안 아이디어를 테스트하거나, 버스나 기차를 타고 이동하는 중 혹은 점심시간에 게임의 속성을 조정하는 등 왜 이것을 원하는지에 대한 모든 이유를 우리에게 계속해서 말해주었습니다.

하지만 사람들이 원하는 것이라고 말하는 것과 실제로 행동에 옮기는 것 사이에는 큰 격차가 있기 때문에, 우리는 오랫동안 회의적인 태도를 유지했습니다. 우리가 이 문제를 처음으로 재고하게 된 계기는 Chad Stewart가 Android에서 Godot를 사용하는 것에 대해 발표하며, 이동 중에 작업하며 겪은 실제 경험을 공유했을 때였습니다. 그 후 Godot Foundation은 휴대폰과 태블릿 등 Android에서의 Godot 사용에 관한 정보를 공유했고, 그때 우리는 어떤 이들에게는 휴대폰이 유일한 컴퓨팅 장치라는 점을 깨달았습니다. 즉, 이것은 가능할 뿐만 아니라 어떤 이들에게는 필수적인 사항이었습니다. 따라서 iPad와 iPhone에 전체 Godot Editor를 제공하는 것은 단순히 데스크톱 앱을 포팅하는 것 이상의 의미를 가졌습니다. App Store의 요구 사항을 충족하고 Apple 사용자들의 기대에 부응하기 위해, 우리는 인터페이스를 진정한 네이티브(Native) 방식이자 터치 우선(Touch-first) 방식으로 재구축했습니다. 이는 단순히 터치 기기에 맞춰 적응시킨 것이 아니라, 터치 기기에서 마치 원래 제자리인 것처럼 느껴지도록 만든 것입니다. Xogot는 수년간의 노력과 상당한 엔지니어링 투자가 투입된 결과물입니다. 이는 Godot와 Apple 플랫폼 모두에 깊은 열정을 가진 소규모 팀이 만든 상용 제품입니다. Xogot는 모든 사람에게 열려 있는 무료 티어(Free tier)를 포함하며, 완전한 버전은 학생들과 Godot 오픈 소스 프로젝트의 기여자들에게 무료로 제공됩니다. Xogot와 Godot Editor의 가장 큰 차이점은 무엇인가요? Xogot에는 두 가지 주요 제한 사항이 있습니다. 첫째, 네이티브 코드(Native code)로 작성된 제3자 플러그인을 실행할 수 없으며, .NET 코드를 실행할 수 없습니다. 전자의 이유는 Apple의 보안 시스템이 프로세스에 제3자의 동적 코드(Dynamic code)를 로드하는 것을 허용하지 않기 때문에 이러한 플러그인들이 모두 작동하지 않기 때문입니다. 그리고 .NET 코드를 실행하는 기능은 우리가 아직 작업하지 않은 부분입니다. 새로운 폼 팩터(Form factor)에 적응하기 위해 이루어진 개선 사항들을 고려할 때, Xogot를 다른 플랫폼으로 확장할 계획이 있나요? 우리는 Xogot를 Apple Vision Pro로 가져오고 싶습니다. 일화적으로 말씀드리자면, 우리가 Godot를 iPad로 가져오기로 결정하기 직전에 우리는 Vision Pro를 위한 프레임워크와 게임을 구축하는 작업을 하고 있었습니다.

우리는 Unity와 Vision에 대해 더 자세히 배우기 위해 첫 번째 Boston Unity 모임에 가려던 참이었으나, Unity의 라이선스 변경에 대응하여 Boston Unity 그룹이 해체되었습니다. 이러한 혼란 속에서 우리는 Godot의 세계로 거침없이 뛰어들 영감을 얻었습니다. 헤드셋 내부에서 직접 몰입형 경험 (Immersive experiences)을 구축하고 테스트한다는 아이디어는 우리가 지금까지 해온 일의 자연스러운 확장처럼 느껴집니다. 즉, 바로 눈앞에서 손으로 무언가를 만드는 과정은 그 과정을 즉각적이고 물리적으로 느끼게 해줍니다. 하지만 iPad 작업과 마찬가지로, 사용자의 기대치를 충족하는 제품을 출시하기 전에는 해결해야 할 매우 흥미로운 문제들이 많이 남아 있으며, 우리는 그 문제들을 하나씩 해결해 나가야 할 것입니다. 현재로서는 Xogot를 Apple 이외의 플랫폼으로 확장할 계획은 없습니다. 우리의 초점은 바로