시리즈: AI와 함께 코딩 배우기

GDC와 모바일 플랫폼 블리츠를 돌아보며

GDC 전야 릴리스와 두 플랫폼 모바일 푸시.

하나의 C API, 모든 표면에서 GDC 데모 빌드, iOS와 Android가 같은 주에 출시 RakuAI C API 터치 / 오디오 / GPU / 에셋 iOS · Metal Android · Oboe 데스크톱 데모 브라우저 폴백 공간 오디오: 모든 플랫폼에서의 HRTF 위치화
새로운 플랫폼을 추가하는 것은 열린 결말의 아키텍처 문제가 아니라 알려진 형태다.

실제 코드를 실행하는 진짜 엔진은 어떤 슬라이드 덱도 이긴다. RakuAI는 그것을 GDC에 들고 가서, 같은 주에 두 개의 모바일 플랫폼을 출시했고, 새로운 표면을 추가하는 것이 다시 쓰는 것이 아니라 알려진 형태임을 증명했다.

GDC는 한 달 전이었다. 돌아오는 비행기는 메모로 가득 찼다. 복도와 사이드 미팅에서 시작된 대화들은 여전히 받은편지함에 메아리치고 있다. 오늘은 그 여행을 앞두고 무엇이 출시됐는지, 무엇이 거의 그렇지 못했는지, 그리고 그것으로부터 무엇이 나왔는지 적어두기에 적당한 토요일이다.

GDC는 사흘 동안의 밀도 높은 대화 속에서 당신의 어떤 가정이 유지되고 어떤 것이 사실로 취급해왔던 추측이었는지 알게 되는 곳이다. 나는 두 종류의 답 모두를 안고 돌아왔고, 예상보다 더 긴 팔로업 대상자 목록을 가지고 왔다.

릴리스 태그가 이야기를 들려준다

내가 가져간 노트북에서 돌아간 버전은 v1.3.8.26.10.09였다. 그 버전을 올린 커밋에는 한 줄짜리 메시지가 있었다. “GDC 2026 Eve Release.” 그날은 3월 25일이었다. 나는 다음 날 아침 비행기에 있었다.

GDC 전야의 그 커밋이 내가 쓰고 싶은 것이다. 그것은 거의 들어가지 못할 뻔했기 때문이다.

비행기를 타기 48시간 전

모두가 “그 데모 빌드”라고 동의했던 빌드는 GDC 일주일 전에 네 가지 다른 방식으로 실패했다. 수정 커밋은 3월 7일의 b70a48dc로, “fix(demos): fix black screens, crashes, and expand API test coverage”라는 제목의 단일 PR로 들어왔다. 그 네 가지 방식은 다음과 같다.

검은 화면. 애니메이션 쇼케이스, AI 행동 테스트, CSG 불리언 테스트, 게임플레이 프레임워크 테스트가 모두 검은 화면을 렌더링했다. 원인은 데모들이 디버그 드로우 리소스를 등록하기 위해 필요로 했던 raku_editor_init() 호출이 누락된 것이었다. CMake 링크 타깃이 한 스프린트 전에 리팩터되면서 아무도 데모 바이너리가 에디터 라이브러리에 의존한다는 것을 눈치채지 못한 채 그것이 잘려나갔다. 수정: 링크를 다시 추가하고, init 호출을 복원.

널 크래시. SLM 대화 데모가 시작 시 널 QA 포인터로 크래시했다. 대화 모델 로더가 설정-찾을-수-없음 경로에서 에러를 표시하지 않고 일찍 반환하고 있었다. 수정: 에러를 드러내고, 작동하는 설정을 배포.

즉시 연결이 끊기는 네트워크 데모. 네트워크 에코 데모는 소켓을 열고, 핸드셰이크를 받고, 그다음 닫혔다. 연결 끊김 감지가 실제 타임아웃 이후가 아니라 첫 번째 유휴 프레임에서 발동하고 있었다. 수정: “첫 번째 유휴” 대신 실제 타임아웃.

OpenXR 런타임 없이 종료 코드 1로 나가는 XR 테스트. 런타임이 없을 때 0이 아닌 종료 코드로 나가는 것은, XR 런타임이 설치되어 있지 않을 수 있는 데모 머신에 맞지 않는 기본값이다. 수정: 우아하게 종료 코드 0으로 나가고, 그 부재를 로깅.

그 어느 것도 영리한 것은 아니다. 모두 개발자의 머신에서는 괜찮아 보이지만 낯선 사람의 머신에서는 망가져 보이는 종류의 것이다. 이런 여행 48시간 전은 정확히 그런 실패들이 드러나는 시점이다. 데모가 마침내 다음 한 주 동안 실제로 살게 될 노트북에서, 15초 안에 의견을 형성할 사람들 앞에서 실행되기 때문이다.

제시간에 작동해야 했던 마무리 손질 커밋들

내가 떠나기 하루 전인 3월 26일에 두 개의 커밋이 더 있었다.

땅 평면의 반사광. 월드 모델 데모에는 초록색 바닥 평면과 몇 개의 떠 있는 도형들이 있었다. 전역 스펙큘러 머티리얼이 적용되면서 초록색 바닥이 데모 조명 아래에서 흰색으로 씻겨나가고 있었다. 수정은 열 줄이었다. 바닥 평면에는 무광 머티리얼, 동적 오브젝트에만 스펙큘러. 갑자기 데모는 디버깅 도중인 엔진이 아니라 의도적인 아트 디렉션처럼 보였다.

컨퍼런스 노트북에 강제로 NVIDIA dGPU 사용. Intel UHD와 별도의 NVIDIA 카드를 둘 다 가진 하이브리드 노트북은 명시적인 힌트가 없으면 기본적으로 Intel 칩을 쓴다. 그 힌트는 두 개의 익스포트된 심볼이다. NVIDIA Optimus용 NvOptimusEnablement, AMD의 대응물인 AmdPowerXpressRequestHighPerformance. 이것들을 데모 바이너리에 추가하니 dGPU가 강제로 쓰였다. 이제 HUD는 타이틀 바에 GPU 이름도 출력해서, 데모가 실제로 무엇 위에서 돌아가는지 한눈에 볼 수 있다. 결과: 내장 UHD 대신 Quadro T2000에서 실행됨. 프레임 타임이 절반 넘게 줄었다.

두 커밋 모두 쉰 줄을 넘지 않는다. 둘 다 “데모가 30프레임으로 돌아간다”와 “데모가 90프레임으로 돌아가고 의도적으로 보인다”의 차이다.

더 나은 시연 도구가 된 브라우저 폴백

GDC 주간에 들어온 또 다른 것은 web/seed-explorer/에 있는 독립형 브라우저 데모였다. 단일 HTML 파일, 의존성 제로, 네이티브 쪽에서 런타임이 사용하는 심플렉스 노이즈 지형 생성기의 JavaScript 포트다. putImageData를 사용해 512x512 캔버스에 생성된 세계의 세 가지 뷰를 렌더링한다. 바이옴 맵, 높이 맵, 온도 맵. 시드를 공유할 수 있도록 raku://seed/ URL 스킴이 내장되어 있다.

이것은 노트북이 말썽을 부리거나 행사장의 와이파이가 엉망일 경우를 대비한 백업이 될 예정이었다. 그것은 사이드 대화에서 내가 실제로 가장 자주 여는 것이 되었다. 커피숍 테이블 위의 다른 누군가의 노트북은 그 자리에서 우리 SDK를 설치할 수 없지만, URL은 로드할 수 있다. 대화는 “바이너리를 보내달라”에서 “이 링크를 열어보라”로 바뀐다. 그것은 다른 종류의 대화다. 브라우저 데모는 로테이션에 남을 것이다.

모바일 플랫폼 블리츠

3월의 나머지 절반은 iOS와 Android였고, 둘 다 같은 주에 출시됐다.

Android. F1 시리즈(F1.2부터 F1.15까지)의 열두 개 커밋이 NativeActivity와 JNI 브릿지 스캐폴드로 시작해 Android 성능 프로파일러로 끝났다. 그 사이에는 JNI를 통해 연결된 터치 입력, AAB 빌드를 위한 GitHub Actions 워크플로우, Firebase Crashlytics 통합, 그리고 오디오 백엔드로 활성화된 Oboe가 있었다. Oboe는 Android에서 저지연 오디오를 위한 옳은 선택이다. 그 주위의 C API 래퍼는 같은 오디오 콜백이 크로스플랫폼으로 작동하게 해준다.

iOS. F2 시리즈(F2.1부터 F2.7까지)의 일곱 개 커밋이 이틀에 걸쳐 들어왔다. Xcode 프로젝트와 Swift 앱 셸로 시작했다. arm64 크로스 컴파일 툴체인을 추가했다. Metal을 렌더러로 연결했다(F2.2 커밋 메시지는 “iOS Metal renderer integration, glue layer, CMake toolchain, 51 tests”라고 적혀 있고, 그 테스트 숫자가 내가 가장 자랑스러워하는 부분이다). UIGestureRecognizer를 통해 제스처 입력을 추가했다. AVAudioEngine 위에 공간 오디오 백엔드를 구축했다. URLSession을 통해 에셋 번들 다운로드와 캐싱을 연결했다.

두 플랫폼 모두 같은 형태를 얻었다. 터치, 오디오, GPU, 에셋 전달을 데스크톱 런타임이 쓰는 것과 같은 C API에 노출하는 얇은 네이티브 레이어다. 그것이 계약이다. 플랫폼별 코드는 그 구현이다. 여기서부터 새로운 플랫폼을 추가하는 것은 열린 결말의 아키텍처 문제가 아니라 알려진 형태다.

공간 오디오는 과소평가된 성과다

내가 계속 질문을 받는 작업물은 공간 오디오다. 헤더는 include/raku/raku_spatial_audio.h에 있다. 구현은 플랫폼별로 나뉘어 있다. 공간 위치화를 위한 HRTF 처리, 채널별 제어를 위한 믹서 그룹, 이펙트(리버브, 딜레이), 그리고 룸 음향을 위한 리버브 존. Android에서 오디오 경로는 Oboe다. iOS에서는 AVAudioEngine이다. 공간 오디오 커밋은 3월 6일의 e0aef6c6이다.

이것이 AR 엔진에 중요한 이유는 오디오가 프레즌스의 절반이기 때문이다. 스테레오(또는 더 나쁘게는 모노) 오디오를 가진 시각적 AR은 사용자가 고개를 돌리는 순간 몰입감을 깬다. 사용자가 움직일 때 업데이트되는 공간 오디오는 가상 콘텐츠가 실제로 그 방 안에 있는 것처럼 느껴지게 만든다. 비용은 실재한다. HRTF 처리는 공짜가 아니다. 이득도 실재한다. 좋은 공간 오디오 데모를 경험하고 나서 그것을 끄고 싶어 한 사람은 아무도 없었다.

GDC가 실제로 움직인 것

적어둘 가치가 있는 세 가지다.

파트너 대화. 복도 대화와 사이드 미팅이 이제 달력에 자리 잡고 있는 것들이다. 컨퍼런스 강연들은 훌륭했다. 강연 사이의 대화들이 그 여행의 값을 하게 만든 이유였다. 미래의 어느 토요일에 파트너 방향에 대해 구체적으로 쓸 때, 그 스레드들이 그 내용이 될 것이다.

이 분야가 어디에 있는지에 대한 더 명확한 판단. 월드 모델에 대한, AI 주도 콘텐츠 파이프라인에 대한, 연구 데모와 배포 가능한 런타임 사이의 격차에 대한, 몇몇 다른 벤더들이 내놓는 공간 AR 하드웨어 로드맵에 대한 세션들이 있었다. 경쟁 환경에 대해 내가 가정했던 것 중 일부는 옳았다. 조용히 걱정하고 있던 몇 가지는 생각했던 것보다 덜 위협적인 것으로 드러났다. 걱정하지 않고 있던 몇 가지는 더 많은 주의를 받을 가치가 있는 것으로 드러났다. 그 재보정만으로도 그 비행은 가치가 있었다.

계속할 허락. GDC는 강제하는 계기였다. 내가 들고 다닌 데모는 완벽하지 않았다. 그것은 구체적이었고, 실제 코드를 실행하는 진짜 엔진이었으며, 슬라이드 덱과는 다른 종류의 질문에 답했다. “팔로업 이메일 보내주세요”라는 응답의 수가 이 방향이 옳다는 것을 확인해줄 만큼 충분히 높았다. 그것이 지표다.

모바일 플랫폼들이 출시됐다. 내가 보여준 데모들은 작동했다. 브라우저 폴백은 기능이 되었다. 잘 쓰인 토요일이었다.

당신의 얼굴 위 기기를 위해 만들어진 런타임

하나의 C API, 어디서나 작동하는 공간 오디오, 그리고 억지로 줄여넣은 PC 엔진이 아니라 스마트글래스를 위해 엔지니어링된 열 인지 런타임. 당신의 AI가 실제 세계 어디에 사는지 확인하라.

← 전체 글