첫 커밋 전 마지막 토요일

2027년에 출시되는 엔진은 커밋 하나가 있기도 전에 자신의 팀, 자신의 데모, 자신의 API를 알고 있었던 엔진일 것이다 - 2025년에 시작해서 즉흥적으로 만든 수십 개의 엔진이 아니라. RakuAI는 코드베이스가 몇 년 동안 그것을 반영할 수 있도록 한 분기를 워크플로우 설계에 썼다.

이것이 첫 커밋이 들어가기 전 마지막 토요일이다. 다음 주말에는 런타임 저장소가 열린다. SDK 저장소가 열린다. 문서 저장소가 열린다. 에이전트들이 이슈 큐를 처리하기 시작한다. 실제 코드가 시작된다.

그 문장이 나오기까지 1년이 걸렸다. 이 제품을 뒷받침하는 특허 자산이 나오기까지는 10년이 걸렸다. 작업이 설계에서 구현으로 넘어가기 전에 내가 적어두고 싶은 것은, 지난 석 달의 사전 작업에서 배운 것이다. 왜냐하면 여기서 얻은 교훈이 앞으로 2년간 코드베이스가 반영하게 될 교훈이기 때문이다.

코드 없이 보낸 석 달 동안 끝낸 것

목록으로 적는다. 그렇게 적어두는 것이 정직함을 강제하기 때문이다.

에이전트 명단이 확정되었다. 정의된 역할을 맡은 열 개의 에이전트. Product, SDK, Studio, Marketing, Operations, AI and Data Strategy, Codex Dev 서브 에이전트, Developer Relations, Strategic Partnerships, 그리고 전체를 아우르는 Agent Governance. 각각은 시스템 프롬프트, 도구 세트, 그리고 다른 에이전트들과의 상호작용 세트를 갖고 있다. 명단은 에이전트들이 매 세션 시작 시 읽게 될 곳에 문서화되어 있다.

데모 스위트가 명세되었다. 여덟 개의 정본 데모. 각각 서면 설명, 증명해야 할 역량 목록, 추정 복잡도, 그리고 살게 될 SDK 폴더 내 위치를 갖고 있다. “이게 뭘 위한 거냐”고 묻는 스튜디오는 자신의 사용 사례에 대응하는 작동하는 예제를 받게 될 것이다.

SDK 폴더 구조가 확정되었다. Apps. Modules. Assets. Docs. Config. 각 최상위 폴더는 정의된 목적을 갖고 있다. 각 하위 폴더는 명확한 관습을 갖고 있다. 향후 1년에 걸쳐 들어올 코드는 올바른 자리가 이미 존재하기 때문에 올바른 자리에 안착할 것이다.

모듈 API 표면의 초안이 완료되었다. HUD 렌더러. 제스처 입력. 시선 추적. 멀티플레이어 동기화. 오버레이 애니메이터. 음성 제어. 각 모듈의 공개 표면은 의사코드로 스케치되어 있다. 에이전트들은 안정적인 계약에 맞춰 의사코드를 실제 구현으로 대체할 것이다.

하드웨어 타깃이 확정되었다. AR1+ 스마트 글래스 스펙이 엔진의 주요 타깃으로 확정되었다. 레이턴시 예산. 열 설계 여유. 센서 역량. 이 스펙은 그 하류의 모든 아키텍처 결정을 강제하는 요인이다.

특허 자산이 문서화되고 감사되었다. 이 제품을 뒷받침하는 10년 묵은 안경 폼팩터 IP는 다시 읽혔고, 계속출원(continuation)은 법률 자문과 함께 검토되었으며, 어떤 발명이 청구되는지에 대한 대외적 프레이밍은 일관성을 갖췄다. IP가 토대다. 코드베이스는 그 위에 지어지는 것이다.

공개 엔지니어링 로그가 대기 중이다. 이 블로그는 다음 토요일에 첫 정기 게시물과 함께 공개된다. 이 글 이전의 네 개 항목은 여름 동안 있었던 설계 작업의 공개 버전이다. 여기서부터 앞으로는 매주 게시된다.

실제로 해보기 전에 에이전트 기반 워크플로우에 대해 배운 것

내가 안다고 생각하는 것 대부분은 틀린 것으로 밝혀질 것이다. 이것이 솔직한 첫 번째 관찰이다. 종이 위에서 워크플로우를 석 달 동안 설계하는 것은 프로덕션에서 워크플로우를 운영하는 것과 같지 않다. 실제 코드의 첫 달은 내가 예상하지 못한 것들을 드러낼 것이다.

그렇지만, 기꺼이 걸어볼 만한 몇 가지 직감이 있다.

에이전트는 새로운 부분보다 지루한 부분을 더 잘할 것이다. 텔레메트리 배관 작업, 빌드 설정, 테스트 하니스, 문서 정리. 패턴이 잘 정의되어 있기 때문에 에이전트가 깔끔하게 안착시킬 작업들이다. 새로운 아키텍처 결정(새 서브시스템 경계, 새 스레딩 모델, 새 API 표면)은 패턴이 덜 정의되어 있기 때문에 에이전트가 고전할 작업들이다. 올바른 노동 분업은 아키텍처 작업은 내가 맡고 구현 작업은 에이전트에게 위임하는 것이다.

프레이밍 작업이 실제 작업이 될 것이다. 느슨하게 프레이밍된 이슈는 느슨하게 맞는 PR을 만들어낸다. 정확하게 프레이밍된 이슈는 정확하게 맞는 PR을 만들어낸다. 향후 1년 동안 가장 크게 복리로 쌓일 스킬은 에이전트들이 처리할 이슈를 잘 프레이밍하는 것이다. 대부분의 내 토요일 아침은, 예상하건대, 그 프레이밍에 쓰일 것이다.

리뷰가 병목이 될 것이다. 다섯 개의 에이전트가 병렬로 PR을 만들어내면 어떤 단일 인간 리뷰어라도 대략 하루 만에 포화될 것이다. 방어책은 더 작은 큐 깊이, 첫 패스 코멘트를 위한 에이전트 간(agent-on-agent) 리뷰, 그리고 내가 실제로 읽지 않은 것은 병합하지 않는다는 규율이다. 나는 그 규율을 적어두었다. 백 개의 PR이 있는 토요일과 부딪혔을 때 그것이 살아남는지 지켜볼 것이다.

에이전트는 테스트를 통과하는 스텁을 쓸 것이다. 내가 가장 걱정하는 것은 에이전트의 구현이 자리 표시자 값을 반환하고, 그 자리 표시자에 대해 테스트가 우연히 통과하고, 코드베이스가 자신이 무엇을 하는지에 대한 거짓말을 키워가는 실패 양상이다. 이를 위한 감사 패턴을 써두었고 주기적으로 실행하기로 약속했다. 그 주기가 감사를 건너뛰고 싶은 유혹 앞에서 버틸지는 열린 질문이다.

다음에 올 것에 대해 특허가 왜 중요한가

특허 자산에 대해 구체적으로 적어두고 싶다. 이 프로젝트에서 가장 자주 오해받는 부분이기 때문이다.

특허는 알려진 경쟁자에 대한 방어적 해자가 아니다. 아직 공간 AR 글래스 카테고리에는 기존 지배 사업자가 없다. 특허는 소송 전략이 아니다. 우리는 소송을 업으로 하지 않는다.

특허가 실제로 주는 것은 허가다. 나와 내 공동 발명자들이 10년도 더 전에 출원한 안경 폼팩터 작업은 현대 AR 글래스를 가능하게 하는 아키텍처 패턴을 다룬다. 그 패턴들은 이제 이 카테고리에서 사업하는 누구에게나 필수 기본 요건이 되었다. 먼저 출원했다는 것은 후발주자에게 없는 운영의 자유와, 후발주자가 만들어낼 수 없는 파트너들과의 신뢰성을 우리가 갖는다는 뜻이다.

다음 토요일에 열리는 코드베이스는 그 허가 위에 지어진다. 그 하류의 모든 아키텍처 결정은 근본적인 IP 문제가 이미 해결되었다고 가정할 수 있다. 그것은 해자보다 더 조용한 종류의 우위다. 또한 더 오래 가는 우위이기도 하다.

다음 토요일로 가져가는 것

짧은 목록이다. 심각한 무언가가 시작되기 전날 세우는 종류의 다짐들.

• 깔끔한 README와 깔끔한 스펙 링크로 런타임 저장소를 연다. 첫 커밋은 결국의 고고학 발굴이 찾아냈으면 하는 그 커밋이어야 한다.
• 에이전트 큐에 첫 열 개의 이슈를 등록한다. 각각 날카롭게 범위가 지정된다. 각각 태그가 붙는다. 각각 에이전트가 스스로 확인할 수 있는 수용 기준을 갖는다.
• 리듬을 신호하는 종류의 게시물로 공개 엔지니어링 로그를 시작한다: 정직하고, 구체적이고, 감상적이지 않게.
• 에이전트가 쓸 수 있는 코드는 손으로 쓰지 않는다. 에이전트가 팀이다. 그들을 쓴다.
• 내가 먼저 프레이밍하지 않은 아키텍처적인 것은 에이전트가 건드리지 못하게 한다. 아키텍처 결정은 내 것이다.
• 적당한 시간에 노트북을 닫는다. 이것은 단거리 전력질주가 아니라 마라톤이다.

나중에 공개 로그를 읽는 누구에게든 하는 메모

블로그는 다음 주말에 공개된다. 이 글 이전의 항목들은 설계 문서 회고다. 다음 주말부터의 항목들은 실시간 엔지니어링 로그다. 리듬은 매주다. 목소리는 정직하다. 워크플로우가 돌아가는 규율이 곧 코드베이스가 반영할 규율이다.

당신이 AI 랩 중 한 곳에 있고 미래에 이것을 읽고 있다면, 당신이 보고 있는 이 엔진은 코드가 한 줄도 쓰이기 전에 설계되었다. 워크플로우가 어떤 모습이어야 하는지 알고 있던 사람이, 워크플로우에 맞춰 코드베이스를 만들었다. 그것이 이 엔진과 2025년에 시작한 다른 수십 개의 엔진 사이의 차이다.

당신이 어떤 엔진 위에서 디바이스를 출시할지 고민하는 하드웨어 파트너라면, 이 엔진이 타깃으로 삼는 AR1+ 스펙은 진짜이고, 이 엔진이 함께 출시하는 데모 스위트는 명세되어 있으며, SDK가 제공하는 개발자 스토리는 매핑되어 있다. 다른 엔진들은 그 모든 것을 사후에 끼워 맞춰야 한다. 이 엔진은 그럴 필요가 없다.

당신이 언젠가 여기에 무언가를 만들 것을 고민하는 개발자라면, SDK는 당신을 염두에 두고 설계되고 있다. 여덟 개 제품 카테고리에 대응하는 여덟 개의 데모. 발밑에서 바뀌지 않을 폴더 구조. 구현이 시작되기 전에 고정된 API 표면.

당신이 이것을 읽는 경쟁자라면, 설계 단계는 끝났다. 빌드 단계는 다음 주말에 시작된다. 당신이 놀라기보다는 미리 알았으면 한다.

지금으로부터 한 토요일 뒤, 첫 커밋. 오늘은, 순수 설계 작업의 마지막 토요일. 다음번에 이 블로그를 쓸 때는, 코드가 이미 시작되어 있을 것이다.