여덟 개의 데모, 제로 코드: SDK가 위해 존재해야 하는 것

데모를 설명할 수 없다면, 잘못된 엔진을 만들게 된다. RakuAI의 여덟 개 정본 데모가 곧 스펙이다 - 당신의 AI가 실제 방을 보고 그 안에서 행동할 수 있게 되었을 때 무엇을 하는지 증명하는 여덟 가지 방법.

이전 세 개의 회사를 거치며 힘들게 배운 패턴이 하나 있다. 엔진을 만들기 전에 데모를 설명할 수 없다면, 잘못된 엔진을 만들게 된다는 것이다. 데모가 곧 스펙이다. 엔진은 이 각각을 전달해야 한다. 나머지 모든 것(아키텍처, API, 언어 바인딩, 하드웨어 추상화)은 데모가 무엇을 해야 하는지에 종속된다.

이번 토요일은 SDK가 출시될 때 함께 제공될 여덟 개의 데모를 명세하는 데 쓰였다. 아직 코드는 하나도 없다. 하지만 모두 유능한 엔지니어(또는 유능한 에이전트)가 내일 당장 만들기 시작할 수 있을 만큼 충분히 상세한 명세를 갖추고 있다.

왜 여덟 개인가

세 개는 부족했을 것이다. 스무 개는 잘 해내기에 너무 많았을 것이다. 여덟은 각 데모가 서로 다른 역량 카테고리를 증명하고, 전체 스위트가 SDK가 가능하게 하는 것의 표면적을 보여주는 숫자다. 여덟 개를 보는 스튜디오는 자신의 제품에 대응하는 것을 찾아 소스 코드를 작동하는 예제로 읽을 수 있어야 한다. 여덟 개를 보는 파트너는 그 폭을 볼 수 있어야 한다.

내가 확정하고 있는 여덟 개 카테고리는 다음과 같다.

1. 솔로 아레나 모드

플래그십 싱글플레이어 AR 데모. 점수, 시간, 목표가 HUD 오버레이로 렌더링되는 시뮬레이션 멀티플레이어 매치. 모션 트래킹. 제스처 트리거. 사용자는 실제 방 안에서 움직이고, 가상 콘텐츠가 그에 반응한다.

이것이 증명하는 것: 엔진이 AR을 겉도는 느낌이 아니라 땅에 발을 딛은 느낌으로 만드는 수준의 레이턴시와 트래킹 품질로 실시간 인터랙티브 경험을 구동할 수 있다는 것. 이 데모가 잘 작동하면, 다른 모든 데모가 더 쉬워진다. 그렇지 않으면, 나머지는 중요하지 않다.

2. AR 코칭 및 트레이닝

스포츠 드릴 시뮬레이터. 쿼터백 던지기 동작. 민첩성 드릴. 사용자의 실제 신체 움직임 위에 겹쳐지는 실시간 동작 피드백. 공간에서 보이는 플레이 다이어그램. 코칭 오디오. 세션 통계.

이것이 증명하는 것: 엔진이 신체 자세 데이터를 받아들여 유용한 실시간 피드백을 만들어낼 수 있다는 것. 사용 사례는 스포츠지만, 기저의 역량은 물리 치료, 댄스 교습, 수술 트레이닝 등 전문가가 학습자의 손을 자유롭게 둔 채 물리적 작업을 코칭해야 하는 모든 곳으로 확장된다.

3. HUD 오버레이 디자이너

개발자 대면 도구. 설정 가능한 HUD 위젯이 있는 테스트 씬. 드래그 앤 드롭 배치. 다양한 뷰포트 크기에서 레이아웃 미리보기. 다른 데모들이 불러올 수 있는 파일로 구성을 내보내기.

이것이 증명하는 것: SDK가 런타임 스토리뿐 아니라 HUD 레이어에 대한 진짜 제작 스토리를 갖고 있다는 것. 자신만의 HUD 구성을 만들고 싶은 스튜디오는 그것을 할 수 있는 작동하는 도구를 갖게 된다. 내보내기 형식은 나머지 데모들이 준수하는 계약이 된다.

4. 스트리머 모드와 POV 레코더

콘텐츠 크리에이터를 위해 만들어진 데모. 라이브 카메라 오버레이. AR 콘텐츠로 표면화된 팬 채팅 버블. 제스처로 트리거되는 시각 효과(파이어볼, 축하 이모트). 하이라이트 릴 캡처를 위한 녹화 오버레이. 킬캠 스타일 리플레이.

이것이 증명하는 것: 엔진이 게임플레이뿐 아니라 라이브 콘텐츠 제작에서도 작동한다는 것. 멀티플레이어 매치를 구동하는 것과 같은 원시 요소가 스트림 오버레이를 구동한다. 스트리밍 사용 사례는 소비자 가시성으로 가는 가장 빠른 경로 중 하나이기도 하다. 스트리머는 수요 창출자이기 때문이다.

5. 매장 접점 오버레이

상업용 등급의 데모. 시뮬레이션된 레스토랑 또는 소매 경험. 메뉴를 훑어보는 시선 및 제스처 내비게이션. 맥락에 맞게 표면화되는 로열티 혜택. 체크아웃 플로우. 사용자는 실제 매장에서 글래스를 착용한 채 실제 메뉴를 보고 있고, 가상 콘텐츠가 둘 다를 증강한다.

이것이 증명하는 것: 엔진이 게이밍이 아닌 상업용 애플리케이션에서도 작동한다는 것. 이것이 파트너십 파이프라인이 제품과 만나는 지점이다. 퀵서비스 레스토랑, 소매 체인, 호스피탈리티 매장. 이 카테고리의 경제학은 게이밍과 다르며, 엔진은 이를 일급(first-class) 사용 사례로 지원해야 한다.

6. AR 컴패니언 HUD

세컨드 스크린 데모. 사용자는 TV로 콘솔 또는 PC 게임을 플레이하고 있다. 글래스는 TV 옆에 AR로 컴패니언 정보를 표시한다. 미니맵. 탄약 카운터. 친구 온라인 표시기. 게임 개발자가 무언가를 통합할 필요 없이 기존 게임과 연결된다.

이것이 증명하는 것: 엔진이 포팅을 요구하는 대신 기존 콘텐츠와 통합된다는 것. 이것은 여덟 개 데모 중 가장 반직관적이고 아마도 전략적으로 가장 중요한 것이다. 사용자는 이미 하고 있는 게임이 글래스를 지원하기를 기다릴 필요 없이 글래스를 채택할 수 있다.

7. AR 에임 트레이너

타깃 갤러리. 다양한 거리에서 팝업되는 타깃. 스코어링 오버레이. 타깃 포착을 위한 아이 트래킹 또는 제스처. 사용자는 AR 공간에서 피드백과 함께 정밀 사격을 연습한다.

이것이 증명하는 것: 정밀도 사용 사례. 에임 트레이너는 비기술적 청중에게 즉시 이해되기 때문에 행사에서 전시될 것이라 예상하는 데모다. 또한 목록의 다른 어떤 데모보다 트래킹 레이턴시 예산에 더 큰 부담을 준다. 즉, 이것이 잘 작동한다면 엔진의 레이턴시 스토리는 진짜라는 뜻이다.

8. 멀티플레이어 HUD 동기화

같은 방 안의 두 대 이상의 글래스 디바이스. 각 사용자는 자신의 정보를 보여주도록 구성된 자신만의 HUD를 갖지만, 그룹 전체에 걸쳐 공유되는 요소도 있다. 팀 컬러 네임플레이트. 공유 목표 마커. 그룹 체력바. 동기화는 LAN이나 블루투스를 통해 일어난다. 클라우드 왕복 없음.

이것이 증명하는 것: 클라우드 의존성 없이 다중 사용자 케이스가 작동한다는 것. 이것은 LAN 파티 게이밍 카페가 신경 쓸 데모다. 또한 클라우드 멀티플레이어 인프라가 존재하기 전에 엔진의 로컬 멀티플레이어 스토리를 증명하는 데모이기도 하다.

스위트 전체가 증명하는 것

위의 각 데모는 하나의 역량 카테고리다. 스위트를 합치면 더 큰 것을 증명한다.

엔진은 범용이다. 같은 SDK와 같은 런타임을 공유하면서 여덟 가지 매우 다른 일을 하는 여덟 개의 데모는 엔진이 단일 장르 수직 제품이 아님을 보여준다.

SDK는 진짜다. 여덟 개 중 어느 데모의 소스라도 보는 스튜디오는 그것을 읽고 작동하는 예제로부터 SDK를 배울 수 있다. 이것은 “여기 API 문서가 있으니 알아서 하라”보다 훨씬 강력한 온보딩 스토리다.

HUD 오버레이 모델이 기저의 원시 요소다. 여덟 개 데모 모두 HUD 기반 상호작용 모델을 공유한다. 그것이 엔진 팀에게 무엇을 먼저 만들어야 하는지 알려주고, SDK 팀에게 무엇을 쉽게 만들어야 하는지 알려준다.

하드웨어 타깃은 그럴듯하다. 특정 하드웨어 역량(모션 트래킹, 아이 트래킹, 제스처, 오디오, 비디오 캡처, LAN 동기화)을 활용하는 여덟 개의 구체적인 데모는 하드웨어 파트너에게 무엇을 최적화해야 하는지 구체적으로 알려준다.

다음은 무엇인가

다음 토요일은 SDK 자체의 폴더 구조로 들어간다. 데모가 확정되었으니, SDK는 각 데모가 자기만의 자리를 갖고, 공유 모듈이 분리 가능하며, 문서가 그 모든 것을 찾을 수 있게 조직되어야 한다. 그다음 토요일은 여덟 개의 데모 모두가 소비하는 API 표면으로 들어간다.

이 제품을 뒷받침하는 특허 자산은 하드웨어가 따라잡기를 10년 넘게 기다려왔다. 하드웨어는 따라잡고 있다. 위의 여덟 개 데모는 하드웨어가 도착했을 때 제품이 무엇을 위한 것인지에 대한 베팅이다.

데모가 곧 스펙이다. 엔진은 이 각각을 전달해야 한다. 내일 코드가 시작되지 않는다. 그다음 토요일도 코드가 시작되지 않는다. 코드가 시작되기에 적절한 토요일은 데모가 완전히 명세되고, SDK가 완전히 설계되고, 그것을 만들 에이전트들이 완전히 조립된 그 토요일이다.

나는 시간을 들이고 있다. 출시될 버전은 첫 줄이 쓰이기 전에 자신이 무엇을 위한 것인지 알고 있던 버전일 것이다.