SDK가 표류하기 전에 따라잡기

프로젝트 초반에 구축된 패리티는 출시 후 사후에 끼워 맞춘 패리티보다 천 배는 저렴하다. RakuAI의 바인딩은 런타임과 함께 개발되고, 모든 PR에서 게이트를 통과해야 한다 - 그래서 당신의 바인딩 선택이 나중에 어떤 기능도 막지 않는다.

전에 멀티 저장소 프로젝트를 죽이는 것을 지켜본 적 있는 특정 실패 양상에 대해 이미 긴장하고 있었고, 그것이 이번 토요일 아침의 출발 상태였다. 런타임이 어느 주말 기능을 추가하는데 SDK가 다음 달까지 따라잡지 못한다. 한 바인딩의 샘플은 작동하는데 다른 바인딩의 샘플은 조용히 퇴행한다. 버전 번호가 더 이상 맞지 않는다. 각 저장소의 CI는 초록불인데 그들 사이의 통합은 깨져 있다.

그 영화는 2년 후 재플랫폼으로 끝난다. 나는 Raku를 그런 식으로 만들지 않는다. 이번 주말의 계획은 격차가 형성되기 전에 SDK를 런타임을 따라잡게 하고, 그 격차가 다시는 형성될 수 없도록 충분한 인프라를 남겨두는 것이었다.

SDK 쪽에서 무엇이 안착했는가

SDK는 큰 주말을 보냈다. 런타임 쪽은 더 조용했다(그것의 큰 진전은 대부분 전 주말에 일어났다. PR #104가 VIO/SLAM, QoS 스케줄러, 퍼포먼스 하니스, 텔레메트리 파이프라인을 안착시켰다). 이번은 바인딩을 위한 따라잡기 주말이었다.

하이라이트:

• 포괄적인 검증을 갖춘 SDK v0.2.0 Unity + Unreal 패리티
• 명시적인 페일오버 시연을 갖춘 두 바인딩 모두의 HelloAR 샘플
• 다중 오브젝트 지원과 인터랙티브 튜토리얼을 갖춘 강화된 Unity 샘플 상호작용
• 포괄적인 사용 예제를 갖춘 강화된 Unreal API 문서
• SDK 저장소로 포팅된 Agent-Queue Seeder 워크플로우
• 시맨틱 버저닝과 릴리스 자동화를 갖춘 SDK v0.2 패키지 퍼블리싱을 위한 CI/CD 파이프라인
• 저장소 홈페이지와 위키 통합을 갖춘 SDK v0.2 문서 및 퀵스타트
• Epic #42: SDK & Runtime Parity Testing Infrastructure 완료

Epic #42 작업이 헤드라인이다. 이것은 두 바인딩을 동일한 정본 시나리오에 대해 실행하고 그것들이 동일하게 작동하는지 확인하는 테스트 스위트다. Unity HelloAR과 Unreal HelloAR은 각각 모델을 로드하고, 마커에 앵커링하고, 렌더링하고, 텔레메트리를 보고한다. 패리티 테스트는 두 바인딩이 보고하는 텔레메트리가 허용 오차 내에 있는지, 그리고 같은 모델이 양쪽 모두에서 올바르게 로드되는지 확인한다. 만약 런타임 변경이 한쪽 바인딩만 깨뜨리고 다른 쪽은 깨뜨리지 않는다면, 패리티 테스트가 그것을 잡아낸다.

이 단계에서 패리티 테스트가 왜 중요한가

Raku SDK는 아직 출시되지 않았다. 공개 릴리스는 없다. 팀 바깥의 누군가가 이것에 대해 코드를 쓰기까지는 몇 달이 남았다. 그런데 왜 지금 패리티에 신경 쓰는가?

프로젝트 초반에 구축된 패리티 테스트는 이미 출시된 프로젝트에 사후에 끼워 맞춘 패리티 테스트보다 천 배는 저렴하기 때문이다. 런타임이 추가하는 모든 새 C API는 첫날부터 두 바인딩 모두를 통해 실행된다. 공개 표면을 건드리는 모든 PR은 패리티 테스트가 여전히 통과함을 보여주거나 그렇지 않은 이유를 설명해야 한다. 비용은 PR당 몇 분이다. 절약되는 것은 파트너가 Unreal에서만 재현되는 이슈를 보고했을 때 팀이 그 이유를 알아내야 하는 하류의 몇 달간의 트리아지다.

또 다른 이유는 패리티 테스트가 아키텍처적 문제를 드러낸다는 것이다. 어떤 기능이 Unity에서 노출하기 쉽고 Unreal에서 어려울 때, 문제는 보통 바인딩에 있지 않다. 런타임의 C API에 있다. 그 비대칭이 신호다. 이번 주말 패리티 테스트는 그런 비대칭 두 개를 드러냈고, 두 경우 모두 수정은 바인딩 중 하나에서 비대칭을 우회하는 것이 아니라 런타임의 API 표면을 바꾸는 것이었다.

두 갈래 워크플로우는 어떻게 작동하는가

에이전트를 활용한 멀티 저장소 개발을 위해 내가 안착시킨 패턴은 이렇다.

저장소당 하나의 에이전트 큐. 런타임은 자신만의 이슈 큐를 갖고, SDK도 자신만의 이슈 큐를 갖고, 문서도 자신만의 큐를 갖는다. 각 에이전트는 자신의 저장소 안에서 작업한다. 어떤 단일 에이전트도 하나의 PR에서 두 저장소 사이의 이음매를 넘나들려 하지 않는다.

이슈 수준에서의 저장소 간 조율. 어떤 기능이 두 저장소 모두에서 변경을 요구할 때, 상호 참조가 있는 두 개의 결합된 이슈가 동시에 등록된다. 런타임 PR이 먼저 안착한다. SDK PR은 런타임 PR이 병합될 때까지 보류된다. 그런 다음 SDK PR이 새 런타임 빌드에 대해 업데이트되고, 재테스트되고, 몇 시간 안에 병합된다.

각 바인딩의 정본 샘플 세트. Unity HelloAR과 Unreal HelloAR이 정본 테스트 차량이다. 모든 C API 변경은 두 곳 모두에서 실행되어야 한다. 샘플은 나중에 생각하는 것이 아니다. 공개 표면의 일부다.

CI 게이트로서의 패리티 테스트. 이번 주말 Epic #42로 안착한 패리티 테스트 인프라는 이제 어느 저장소든 건드리는 모든 PR에서 실행된다. 런타임 변경이 두 바인딩 모두를 실행하지 않으면, 그 변경이 양쪽에서 작동함을 패리티 테스트가 보여줄 때까지 PR은 병합이 막힌다.

이것이 빌더들에게 무엇을 가능하게 하는가

당신이 언젠가 Raku 위에 만들 것을 고민하는 Unity 개발자라면, 바인딩은 런타임에 뒤쫓아가는 것이 아니라 런타임과 함께 개발되고 있다. Unity API는 뒤처지지 않을 것이다. 샘플은 오늘도 작동하고 1.0 버전에서도 작동할 것이다.

당신이 Unreal 개발자라면, 마찬가지다. Unreal 바인딩은 Unity와 동일한 우선순위를 갖는다. 패리티 테스트가 그것을 증명한다.

당신이 어떤 바인딩으로 시작할지 결정하는 중이라면, 답은 당신 팀의 기존 스킬에 맞는 쪽이다. 패리티 테스트가 바인딩 선택이 나중에 기능을 막지 않을 것이라고 내가 약속할 수 있게 해주는 것이다.

당신이 이 엔진이 당신의 스택에 어떻게 통합될지 고민하는 파트너라면, 표면은 C API 더하기 Unity 바인딩 더하기 Unreal 바인딩, 그리고 결국 몇 개 더(Godot이 로드맵에 있고, 웹 네이티브도 로드맵에 있다)가 될 것이다. 새로운 바인딩이 출시되기 전에 정본 세트에 대한 자신의 패리티 테스트를 안착시켜야 한다. 그 규율은 내장되어 있다.

아직 거친 것에 대해 솔직히

패리티 테스트는 기본적인 것들을 다룬다. 마커 기반 앵커링은 두 바인딩 모두에서 작동한다. HelloAR은 양쪽 모두에서 로드되고 렌더링된다. 텔레메트리는 양쪽 모두에서 올바르게 보고된다. 더 어려운 패리티 문제들, 완전한 핸드 트래킹, 음성 파이프라인, 멀티플레이어 자세 동기화, 이것들은 런타임 쪽이 완료되지 않았기 때문에 아직 패리티 테스트되지 않는다. 완료되면 같은 게이트 아래로 들어올 것이다.

SDK v0.2 퍼블리싱을 위한 CI 파이프라인은 가동 중이지만, 실제로 퍼블리시된 패키지는 아직 그것에 대해 통합을 권장할 만큼 안정적이지 않다. 10월까지는 SDK를 개발 중인 것으로 취급하라. 11월까지는 패리티 테스트가 충분히 깊어져서 권장 사항이 달라질 것이다.

이번 주말에서 기억하고 싶은 것

두 가지가 있다.

멀티 저장소 패리티는 기능이 아니라 규율이다. SDK가 런타임을 따라잡은 주말은 런타임에 반짝이는 새 기능이 없는 주말이다. 데모할 만한 일은 아무것도 일어나지 않았다. 일어난 일은 SDK가 더 이상 뒤처지지 않는다는 것이었다. 그것은 방치하면 멀티 저장소 프로젝트를 죽이는 종류의 작업이다. 다음 큰 런타임 기능이 안착할 때 잊지 않기 위해 이것을 적어두고 싶다.

에이전트 큐는 저장소별로 스케일된다. 같은 워크플로우 안에서 두 저장소에 걸쳐 하나의 큐를 운영하는 것은, 지난 주말 런타임 수준에서 설명했던 머지 충돌 뒤엉킴의 초기 버전을 만들어냈다. 큐를 저장소별로 분리하는 것이 거의 모든 것을 제거했다. 문제 공간이 제대로 나뉘면 에이전트들은 서로 걸려 넘어지지 않는다.

토요일 저녁, SDK와 런타임은 패리티 상태다. 큰 주말. 올바른 종류의 주말.