OpenXR는 골격, 듀얼링크 라디오는 신경

모든 것을 직접 만들면 다른 무엇도 이해하지 못하는 언어로 말하는 채로 1년 늦게 출시하게 된다. RakuAI는 다른 길을 택한다. 맞는 곳에서는 OpenXR 위에 서고, 스스로 전환하는 듀얼 라디오 테더처럼 표준이 아직 도착하지 않은 어려운 부분은 직접 엔지니어링한다.

AR 글래스용 엔진을 만들 때의 유혹은 모든 것을 직접 만드는 것이다. 자체 포즈 API를 만든다. 자체 그래픽 바인딩을 만든다. 자체 입력 모델을 만든다. 자체 컨트롤러 추상화를 만든다. 그 각각의 결정은 40시간의 에이전트 작업과 또 다른 40시간의 사람 리뷰를 요구한다. 그것이 쌓이면 1년의 노력과, 생태계 안 다른 무엇도 그 언어를 말하지 못하는 엔진이 된다.

나는 다른 길을 택하고 있다. 사용 사례에 맞는 표준이 존재하는 곳에서는 엔진이 그 표준을 채택한다. OpenXR이 그 대표적인 예다. 이번 주말 런타임은 두 달 동안 필요로 했던 OpenXR 백본을 갖추게 되었다.

OpenXR에서 들어온 것

이번 주말에 걸쳐 대부분의 무거운 작업이 들어왔다.

• 세션과 스왑체인 관리를 갖춘 OpenXR 그래픽 API 바인딩
• 디바이스 유실 처리를 갖춘 OpenXR 프레임 라이프사이클 통합
• OpenXR 액션 동기화와 뷰 위치 연산
• XR_FB_passthrough, XR_FB_foveation, XR_EXT_hand_tracking을 위한 OpenXR 확장 지원
• OpenXR 컴포지션 레이어 매니저와 액션 스페이스

이 PR 제목들을 연달아 읽으면 벤더 적합성 체크리스트처럼 들리는데, 실제로 그렇다. 핵심은 OpenXR 적합 런타임을 출시하는 어떤 하드웨어 파트너의 어떤 디바이스든 이제 Raku의 실행 가능한 타깃이 된다는 것이다. 디바이스와 대화하는 엔진의 부분들이 디바이스의 런타임이 말하는 것과 같은 프로토콜을 말하기 때문이다.

에이전트들이 이 작업의 대부분을 처리했다. 이번 주말에 들어온 PR들은 유난히 깔끔한데, OpenXR이 공개된 헤더와 작동하는 테스트 스위트를 갖춘 잘 명세된 표준이기 때문이다. 에이전트는 헤더를 읽고, 스펙 섹션을 읽고, 구현을 작성하고, 적합성 테스트를 실행하며, PR은 큰 모호함 없이 그린이거나 레드다. 그것이 자율 코딩 에이전트가 가장 잘하는 종류의 작업이다.

듀얼모드 RF/광학 링크 매니저

이번 주말의 다른 큰 항목은 듀얼모드 링크 매니저다. 이것은 표준에 관한 것이라기보다는 Raku 고유의 것이다.

그림을 그려보면, 외부 컴퓨팅 테더를 갖춘 AR 글래스가 있다. 테더는 때로는 폰이고, 때로는 벨트팩이고, 때로는 데스크톱이다. 글래스와 테더 사이의 링크는 오늘은 Wi-Fi 7이고, 어떤 디바이스 타깃에서는 내일 자유공간 광학이 될 수도 있다. 런타임은 하나의 링크 기술을 가정할 수 없다. 전환할 수 있어야 한다.

이번 주말 들어온 링크 매니저가 그것을 처리한다. 런타임은 RF 링크와 (지원되는 경우) 광학 링크를 둘 다 연다. 각각의 지연 시간과 처리량을 모니터링한다. 더 나은 성능을 내는 링크로 트래픽을 옮기고, 하나가 저하되면 다른 쪽으로 폴백한다. 그 전환은 위쪽의 애플리케이션에 지장을 주지 않는다.

이것은 사실상 나중에 소급해서 적용할 수 없는 종류의 서브시스템이다. 두 번째 링크 기술이 도착할 때까지 추상화를 만드는 것을 미루면, 첫 번째 링크 기술이 그 위의 모든 레이어에 슬며시 심어놓은 가정들을 풀어내는 데 석 달을 쓰게 된다. 우리는 추상화를 먼저 만들었다. 이제 하드웨어 파트너가 어떤 링크 기술을 선택하든 런타임은 준비되어 있다.

OpenXR 확장과 그것이 부족한 부분

이 글을 읽는 OpenXR 관계자를 위한 구체적인 메모다. 이번 주말 지원을 추가한 XR_FB_passthrough와 XR_FB_foveation 확장은 우리가 도달하고 싶은 포비에이션과 패스스루 품질 기준에 맞는 것들이며, 손 추적 확장 XR_EXT_hand_tracking은 벤더 간 손 추적 인터페이스에 맞는 것이다.

확장 세트에서 빠져 있고 우리가 자체 코드를 만들고 있는 것은, (올가을 초의 캘리그래피 사용 사례인) 서브밀리미터 앵커링, 우리가 원하는 시간 규모에서의 저지연 멀티플레이어 포즈 동기화, 그리고 모델 레이어가 매 프레임 씬 추론에 참여할 수 있게 하는 AI 런타임 훅이다. 이 영역들은 OpenXR이 아직 표준화하지 않은 곳이며, 우리 엔진은 그동안 자체 인터페이스를 출시하고 있다. 의도는 OpenXR이 따라잡으면(그리고 워킹 그룹에서 이 중 일부에 대해 실제로 작업이 진행 중이다) 그 표준을 채택하고 우리 자체 인터페이스는 폐기하는 것이다.

그것이 내가 이 엔진이 유지하기를 바라는 패턴이다. 표준이 존재하는 곳에서는 채택한다. 존재하지 않는 곳에서는 만든다. 표준이 따라잡는 곳에서는 채택할 준비를 해둔다.

텔레메트리와 스텁 완전성

이번 주말 조용히 들어온 항목 하나는 OpenTelemetry 통합을 갖춘 구조화된 JSON/OTLP 로깅이다. 이것은 자체 발표를 받지는 못하는 종류의 배관 작업이지만, 매번 코드를 손으로 계측하지 않고도 “지연 시간 예산이 어디로 가고 있는가”라는 질문에 답할 수 있게 해주는 것이다. 텔레메트리 파이프라인은 이제 모든 서브시스템을 통해 연결되어 있고, Phase 1이 만들어내는 대시보드들은 실재한다.

이번 주말에 또 있었던 것은, 코드베이스 안의 스텁 구현들을 면밀히 살펴보고 각각을 “실제로 유용한 테스트 유틸리티”이거나 “실제로는 구멍”으로 분류한 문서화 PR이다. 유용한 것들은 이름이 바뀌고 문서화되었다. 구멍들은 추적되었다. 에이전트들이 그 분류 작업을 스스로 작성하고 착지시켰다. 작은 일이다. 하지만 너무 오래 방치되면 심각한 엉망이 되는 종류의 작은 일이기도 하다.

빌더와 파트너들이 이 글에서 가져갔으면 하는 것

당신이 OpenXR 워킹 그룹 관계자라면, 이 엔진은 표준의 좋은 시민으로서 만들어지고 있다. 우리는 맞는 곳에 확장을 채택한다. 우리의 구현이 적합성 버그를 발견하면 그것을 신고한다. 표준이 아직 따라잡지 못한 곳에서는 우리가 만든 것을 공개할 것이고, 우리는 포크를 유지하기보다는 표준화하는 쪽을 택하겠다.

당신의 디바이스가 OpenXR 적합인 하드웨어 파트너라면, 이 엔진은 지난 주말보다 이번 주말에 당신의 디바이스 위에서 실행되는 것에 더 가까워졌다. 남은 작업은 벤더 고유의 글루다. 우리는 그 작업을 함께 하게 되어 기쁠 것이다.

당신이 글래스와 테더 사이의 차세대 링크 기술(Wi-Fi 7+, 자유공간 광학, mmWave, 무엇이든)을 작업하고 있다면, 링크 매니저 추상화가 연결할 수 있는 레이어다. 위쪽의 런타임은 당신이 어떤 라디오인지 알 필요가 없다. 아래쪽의 런타임이 당신을 추상화한다.

주말 동안 아흔여덟 개의 커밋. 엔진은 골격 하나와 신경 하나를 얻었다. 길었던 이틀 뒤 일요일 밤 노트북을 닫는 기분이 좋다.