282개의 커밋, 공개 로그 첫 주말

중요했던 커밋은 C API였다: 런타임이 안정적인 공개 표면을 가진 순간, 에이전트가 작성한 두 갈래의 작업이 서로 걸려 넘어지는 것을 멈췄다. 이것이 루프가 맞물릴 때 AI 네이티브 런타임이 어떤 모습인지를 보여준다.

지난 토요일 나는 이슈 더미를 등록하고 자율 코딩 에이전트를 큐에 붙였다. 월요일이 되기 전 마지막으로 노트북을 열어놓은 채 부엌 식탁에 앉은 일요일 저녁까지, 런타임 저장소 전체에 282개의 커밋이 쌓였다. 그중 작은 일부만 내가 작성한 것이었다. 나머지 대부분은 자율 코딩 에이전트가 작성한 것이었다.

숫자가 마치 스프린트 주간의 작업량처럼 보이는 이유는, 내가 키보드 앞에 없을 때도 작업이 계속 일어나고 있었기 때문이다. 나는 주말에만 키보드 앞에 있다. 에이전트는 본업이 없다. 결과물은 그 배치에서 떨어져 나오는 것이다.

큐는 어떻게 작동하는가

토요일 아침은 이슈 등록일이다. 나는 커피를 놓고 앉아 GitHub 이슈를 쓴다. 각각은 엔진이 다음으로 필요한, 날카롭게 범위가 지정된 작업 단위다. 형태는 대략 이렇다.

• 이슈당 하나의 서브시스템 또는 하나의 기능
• 에이전트가 스스로 확인할 수 있는 명확한 수용 기준
• 관련 문서, 스펙, 그리고 작업이 건드려야 할 기존 파일에 대한 포인터
• 명시적인 “agent-queue” 라벨

또한 큐가 열려 있는 에이전트 이슈 15개 아래로 절대 떨어지지 않도록 보장하는 야간 워크플로우(이번 주말 런타임 저장소의 이슈 #37)도 있다. 만약 그 아래로 떨어지면, 워크플로우가 로드맵으로부터 자리 표시자 작업 초안을 만든다. 에이전트는 큐를 읽고, 자신이 할 수 있는 다음 것을 골라, 초안 PR을 열고, 반복하고, 결국 스스로 리뷰 준비 완료로 표시한다.

토요일부터 일요일까지 나는 리뷰하고 병합한다. 에이전트가 무언가를 잘못했으면, PR을 닫고, 이슈를 더 날카롭게 다듬고, 다시 등록한다. 에이전트가 제대로 했으면, PR이 안착하고 이슈가 닫힌다. 리듬은 주말 시작 때 등록하고, 이틀 내내 리뷰하고, 일요일 밤 노트북을 닫을 때 신선한 큐를 남기는 것이다. 내가 본업으로 돌아가 있는 동안 에이전트는 큐를 갈아치운다.

그것이 워크플로우다. 미묘한 것이 아니다. 이것을 적어둘 가치가 있는 이유는 작동하기 때문이다.

무엇이 만들어졌는가

282개의 커밋에서 나온 헤드라인들.

• 그냥 뼈대가 아닌, 진짜 런타임 메인 루프
• 센서 입력부터 렌더까지 종단 간(end-to-end) 타이밍을 측정하는 레이턴시 트래커
• 설정 가능한 임계값과 주기적 보고를 갖춘 메모리 사용량 모니터
• INFO / WARNING / ERROR 레벨, 콘솔 및 파일 출력을 갖춘 로깅 서브시스템
• 우아한 종료를 위한 신호 핸들러가 있는 에러 핸들링
• SDK가 링크할 수 있도록 런타임을 노출하는 C API
• SDK 통합을 위한 C API 안의 모듈/에이전트 관리 시스템
• 런타임 동시성 모델: 태스크 큐와 워커 스레드
• 포괄적인 테스트 하니스
• ABI 검증 및 SDK 링키지 검증
• 제품 타깃으로 확정된 AR1+ 스마트 글래스 스펙

그 어느 것도 화려하지 않다. 그 모두가 흥미로운 것들이 그 위에 만들어지기 전에 AR 런타임이 필요로 하는 것들이다.

돌이켜보면 가장 중요했던 커밋은 C API 노출이다. 런타임이 SDK가 링크할 수 있는 안정적인 공개 표면을 가진 순간, 런타임 작업과 SDK 작업은 서로 걸려 넘어지는 것을 멈췄다. 그 커밋 이전에는, 한 저장소의 모든 변경이 다른 저장소와 신중하게 동기화되어야 했다. 그 이후로는, 그것들이 분리되었다. 에이전트가 작성한 두 갈래의 작업이 머지 충돌 없이 병렬로 실행될 수 있었다.

나를 놀라게 한 것

세 가지가 있다.

에이전트는 지루한 인프라 작업에서 내가 그럴 수 있었던 것보다 더 빠르다. 텔레메트리, 로깅, 에러 핸들링, 테스트 하니스. 작업이 화려하지 않기 때문에 인간이 산만해지는 종류의 작업들이다. 에이전트는 산만해지지 않는다. 그냥 diff를 안착시킨다.

에이전트는 아키텍처에 보수적이다. “센서-투-렌더 시간을 측정하는 레이턴시 트래커를 구현하라”는 이슈를 넘기면, 정확히 그것을 만든다. 레이턴시가 무엇을 의미하는지에 대한 형이상학을 지어내거나 API에 대해 다른 형태를 제안하지 않는다. 그것은 좋은 것이다. 아키텍처는 내 일이다. 구현은 에이전트의 일이다.

큐 재충전이 병목이다. 에이전트가 하루에 열다섯 개의 PR을 출시하고 저녁까지 큐가 비어버리면, 처리량은 더 이상 에이전트가 얼마나 빨리 작업하는지에 관한 것이 아니게 된다. 내가 다음 작업 세트를 얼마나 빨리 명확히 표현할 수 있는지에 관한 것이 된다. 그것이 토요일 아침을 다시 만들었다. 첫 시간은 이슈 등록이다.

무엇이 망가졌는가

두 가지가 있는데, 어느 것도 치명적이지 않았다.

에이전트가 독립적으로는 컴파일되지만 런타임의 나머지와 링크되지 않는 코드를 안착시켰을 때 CMake 빌드가 두 번 망가졌다. 두 번 다 해결책은 같았다: 에이전트는 아직 프로젝트의 링크 타임 그래프에 대한 완전한 가시성을 갖고 있지 않다. 해결책은 이슈 프레이밍에 있다. 지금부터, 라이브러리를 건드리는 모든 이슈는 어떤 다른 라이브러리가 그것에 링크되는지 명시적으로 말한다.

테스트 하니스는 진행 후반에 추가되었고, 수동 스모크 테스트는 통과했지만 새 하니스에서는 실패한 네 개의 버그를 이전 PR들에서 즉시 드러냈다. 거기서 얻은 교훈은 화려하지 않은 것이다: 테스트를 후속 작업이 아니라 기능의 일부로 써라. 이슈가 그렇게 말하면 에이전트는 그렇게 한다. 이슈가 그렇게 말하지 않으면 그렇게 하지 않는다. 항상 그렇게 말하게 하라.

파트너와 빌더들이 알았으면 하는 것

이 엔진의 형태는 지금 바로 만들어지고 있다. 다음 달 말까지 대부분의 근본적인 결정이 정해질 것이다. 당신이 모델 랩에 있고 AI 레이어가 어떻게 연결되어야 하는지에 대한 의견이 있다면, 지금이 그 의견을 반영하기 저렴한 창이다. 당신이 Unity나 Unreal 통합을 고민하는 개발자라면, SDK는 이번 주말 만들어지고 있고 바인딩은 런타임이 할 수 있는 것을 반영한다. 나는 60주 차보다는 6주 차에 당신에게서 듣고 싶다.

런타임 저장소는 열려 있다. SDK 저장소는 열려 있다. 열려 있는 이슈의 큐도 열려 있다. 이것이 실시간으로 일어나는 것을 지켜보는 것, 그것이 요점 전부다.

282개의 커밋, 공개 로그 첫 주말. 일요일은 마감되었다. 다음은 월요일이다.