매주의 리듬을 시작하다

브라우저 안의 생성형 콘텐츠는 괜찮다. 당신의 실제 부엌 벽에 고정된 생성형 콘텐츠가 바로 이 제품이다. 이것이 매 시뮬레이션 스텝마다 당신의 모델로부터 지시를 받도록 만들어지고 있는 엔진이다 - 0일차, 공개적으로.

이번 토요일부터 이 블로그의 정기적인 매주 리듬이 시작된다. 이 글 아래의 네 개 항목은 여름 초반의 설계 문서 토요일들이었다: 에이전트 명단, 데모 스위트, 폴더 구조, 코드가 시작되기 전의 마지막 성찰. 여기서부터 앞으로의 리듬은 매주다. 이 블로그가 다루는 것은 새로운 것이 아니다.

나는 AR 글래스, 실제 세계에 고정된 공간 경험, 그리고 그것을 구동하는 런타임의 올바른 형태에 대해 10년 넘게 생각해 왔다. 그 생각 중 일부는 2010년대 초반 특허가 되었다. 지금 우리가 만들고 있는 것 뒤의 IP를 여전히 뒷받침하는 안경 폼팩터 자산이다. 그중 일부는 결코 세상 빛을 보지 못한 프로토타입이 되었다. 대부분은 내가 다른 일을 하는 동안 백그라운드에서 돌아갔다.

지난 한 해 동안 바뀐 것은 세상의 나머지 부분이 마침내 따라잡았다는 것이다. 컴퓨트는 충분히 작아졌다. 광학은 충분히 좋아졌다. 클라우드 LLM은 충분히 진짜가 되었다. 온디바이스 추론은 충분히 빨라졌다. 10년 너무 일렀던 아이디어였던 제품이, 마침내, 출시할 수 있는 제품이 되었다.

그래서 나는 출시를 시작했다. 현재 진행 중인 코드는 몇 달째 진행되고 있다. 커밋들은 비공개 저장소에 살고 있었고, 나는 그것을 정리하고 코드베이스를 통합하면서 이제 공개로 가져오고 있다. 이 블로그는 여기서부터 앞으로의 공개 기록이다.

앞으로 몇 달은 어떤 모습일까

이번 토요일 계획의 형태, 다가올 것의 느낌으로:

• 런타임: 초안 AR1+ 스마트 글래스 스펙이 오늘 아침 책상 위에 있다. PDF, PowerPoint, Markdown 버전이 모두 있어서 LLM이 그것에 대해 추론할 수 있고, 파트너가 읽을 수 있고, 디자이너가 검토할 수 있다. 핵심은 스펙이지 형식이 아니다. 형식은 독자를 위한 것이다.
• 방금 커밋된 main.cpp와 런타임 메인 루프 뼈대.
• 레이턴시 트래커 헤더와 구현 스텁. 레이턴시는 이 엔진을 정의하는 지표가 될 것이다.
• 모든 푸시가 깨끗한 머신에서 깨끗한 빌드를 얻도록 하는 CI의 CMake 빌드 워크플로우.
• 팀의 에이전트들이 팀이 어떻게 돌아가는지 알 수 있도록 하는 Copilot 온보딩 가이드.

SDK 저장소도 이번 토요일 자신만의 스캐폴딩을 얻었다. 초기 Unity HelloAR 샘플. 초기 Unreal HelloAR 샘플. 두 바인딩 모두를 위한 헤더 뼈대. 패키지 퍼블리시 워크플로우.

그 어느 것도 아직 출시 가능하지 않다. 그 모두는 출시 가능한 무언가가 가능해지기 전에 필요한 것들이다. 두 저장소를 동시에 움직이되 이음매에서 의도적으로 결합시키는 이 패턴이 앞으로의 테마가 될 것이다.

공개 첫날에 왜 스마트 글래스 스펙인가

스펙은 의도적인 것이다. 대부분의 엔진은 런타임 아키텍처를 먼저 정한 다음, 거기에 그럴듯하게 출시될 수 있는 제품을 쇼핑하러 나선다. 나는 이것을 반대 순서로 하고 있다. 제품은 사람들이 세상에서 착용하는 AR 글래스이고, 엔진은 그 제품에 맞는 올바른 형태여야 한다. 그래서 스펙은 거칠더라도 먼저 쓰인다.

이것은 마케팅 문서가 아니다. 강제 요인이다. 그것은 엔진이 어떤 종류의 하드웨어 위에서 돌아가야 하는지, 레이턴시 예산이 무엇인지, 실제로 AI 표면이 어떤 모습이어야 하는지를 말해준다. 하류의 모든 아키텍처 결정은 그 스펙을 가리키며 “이 결정이 스펙에 봉사하는가, 아니면 내가 대신 만들고 싶어하는 다른 어떤 엔진에 봉사하는가”라고 물을 수 있다. 그 두 번째 카테고리가 엔진 프로젝트들이 죽으러 가는 곳이고, 나는 전에도 거기서 벗어나 있었고 지금도 그럴 작정이다.

첫날에 왜 Copilot 가이드인가

이번 주말의 또 다른 의도적인 것은 Copilot 온보딩 가이드다. 첫 버전은 거칠다. 열 번은 다시 쓰일 것이다. 하지만 이 가이드가 존재하는 이유는 에이전트가 팀의 일원이고, 팀은 팀이 어떻게 돌아가는지 알아야 하기 때문이다.

가이드는 다음을 말한다.

• 전략이 무엇이고 우리가 만들지 않는 엔진이 어떤 것인지
• 로드맵이 어디에 사는지
• 이슈가 어떻게 등록되고, 처리되고, 닫히는지
• 좋은 PR이 어떤 모습인지
• 리뷰어가 무엇을 해야 하는지 (리뷰어는 때로는 나이고 때로는 다른 에이전트다)

“에이전트가 문서를 읽는다”는 프레이밍은 술책이 아니다. 팀이 주말의 한 명의 인간과 지속 근무 중인 여러 자율 코딩 어시스턴트로 이루어진 워크플로우를 운영하는 실질적인 현실이다. 가이드가 나쁘면, 작업도 나쁘다. 가이드가 좋으면, 작업은 정확하고 리뷰 비용은 떨어진다.

왜 지금 공개 로그인가

몇 가지 이유가 있다.

특허는 우리가 이야기하지 않았기 때문에 아무도 이야기하지 않는 10년 묵은 선행 기술이다. 이 엔진의 뿌리가 되는 안경 폼팩터 작업은 몇 년째 조용히 등록되고 계속되어 왔다. 나는 공개 엔지니어링 기록이 실제 계보를 가리키기를 원한다. 공간 AR은 누군가 지난여름에 갑자기 시작한 새로운 것이 아니다. 그 작업은 오래전으로 거슬러 올라간다.

파트너십 대화가 시작되고 있다. 하드웨어 파트너, AI 랩, 스튜디오. 그런 대화들은 그들이 덱 대신 읽을 수 있는 공개 엔지니어링 기록이 있을 때 더 날카로워진다. 덱은 정리된 버전이다. 블로그는 실제 버전이다.

개발 워크플로우는 진정으로 새롭고 보여줄 가치가 있다. 공개 단계 첫날부터 팀에 있는 AI 에이전트. 여러 벤더. 병렬 브랜치. 공개 이슈 큐. 그중 어느 것도 이 프로젝트를 위해 새로 발명된 것은 아니다. 이례적인 것은 이렇게 진지한 무언가에서 그 모두를 한꺼번에 하는 것이다. 교훈이 아직 정직할 만큼 신선할 때, 일어나는 그대로 적어두고 싶다.

파트너와 빌더들이 여기서 무엇을 가져갔으면 하는가

당신이 대형 AI 랩 중 한 곳에 있고 이것을 읽고 있다면, 여기 피치가 있다. 이 엔진은 당신의 모델로부터 지시를 받도록 명시적으로 만들어지고 있다. 덧붙여진 것이 아니다. 에디터 패널 안이 아니다. 런타임 안에서, 시뮬레이션 스텝에서, 매 프레임마다. 아키텍처 결정은 지금 바로, 공개적으로, 명시적인 문서 기록과 함께 일어나고 있다. 당신의 모델이 사용자가 서 있는 실제 물리적 공간을 이해하는 데 더 나아진다면, 이 엔진이 바로 그 이해로 무언가를 할 수 있는 곳이다.

당신이 언젠가 이 위에 무언가를 만들 것을 고민하는 개발자라면, SDK는 런타임과 발맞춰 움직이고 있다. Unity와 Unreal 샘플이 이번 주말 SDK 저장소에 씨앗으로 심어졌다. 아직 작동하지 않는다. 작동하게 될 것이다. 이 단계에서 두 바인딩이 모두 존재하는 이유는, 6개월 뒤 런타임 아키텍처는 고정되었는데 SDK가 거기에 맞추려고 스스로를 뒤틀어야 하는 순간에 결코 이르지 않기 위해서다.

당신이 소비자로서 초기 신호를 지켜보고 있다면, 신호는 이것이다: 이 엔진은 가장 흥미로운 경험이 실제 장소에서의 AR 경험이고, AI가 그 경험을 반응하게 만드는 것이라는 가정을 중심으로 만들어지고 있다. 브라우저 안의 생성형 콘텐츠는 괜찮다. 당신의 부엌 벽에 붙어 있는 생성형 콘텐츠가 실제 제품이다.

오늘은 토요일이다. 블로그는 공개되었다. 내일 다시 빌드로 돌아간다.