실리콘이 도착하기 전에 하드웨어를 검증하기

실리콘을 기다리는 것에 대한 전통적인 답은 앉아서 기다리는 것이다. 현대적인 답은 하드웨어보다 하류에 있는 모든 것을 먼저 만들어서 부품이 도착하기 전에 전부 초록불로 만드는 것이다 - 그래서 당신의 하드웨어가 경쟁자보다 더 빠르게 RakuAI 위에서 출시된다.

주중 내내 곱씹고 있던 결정이 주말이 시작되자 부엌 식탁에서 기다리고 있었다. 제품 타깃을 AR1+에서 AR2 Gen1으로 전환한다. 실리콘이 도착하기 전에 새 스펙보다 하류에 있는 모든 것을 만들어서, 실리콘이 실제로 도착했을 때 검증이 90일차가 아니라 첫날부터 시작되게 한다.

모든 하드웨어 제품이 거치는 단계가 있다. 스펙이 존재하고, 검증 계획이 존재하고, 테스트 하니스가 존재하는데, 실제 실리콘은 존재하지 않는 단계. 전통적인 답은 앉아서 기다리는 것이다. 현대적인 답은 하드웨어보다 하류에 있는 모든 것을 먼저 만들고, 부품이 출시되기 전에 전부 초록불로 만드는 것이다.

이번 주말이 그것이었다. 타깃 플랫폼은 공식적으로 AR1+에서 AR2 Gen1으로 옮겨갔고, 엔지니어링의 대응은 우리 중 누구도 새 플랫폼을 만지기 전에 새 플랫폼이 필요로 할 검증 인프라를 즉시 만드는 것이었다.

무엇이 안착했는가

이번 주말에 안착한 다섯 가지.

• AR2 Gen1 디바이스 브링업 및 센서 통합 인프라
• Wi-Fi 7 연결성 및 트래킹 안정성 테스트 스위트
• 열 및 전력 검증 프레임워크
• 메트릭 분석 및 보고를 갖춘 CI 스모크 테스트
• AR2 Gen1 하드웨어 검증 문서 및 프로덕션 표준 스펙

모두 기능 플래그로 게이트되어 있어서 AR1+ 코드 경로는 여전히 작동하고 기존 런타임의 어느 것도 퇴행하지 않는다. 이 PR들을 안착시킨 에이전트들은 지루한 규율을 올바르게 수행했다. 모든 새 파일은 빌드 플래그 뒤에 숨겨져 있고, 모든 API 추가는 파괴적이지 않으며, AR2 디바이스가 실행할 대상이 없음에도 모든 테스트는 CI에서 실행된다. 테스트는 시뮬레이션한다. 그 시뮬레이션은 인터페이스 드리프트, 누락된 export, 깨진 센서 흐름을 잡아낼 만큼 충분히 좋다.

이것은 77개 커밋의 주말이었다. 그 커밋의 대부분은 내가 손에 쥘 수 없는 디바이스를 위한 것이다.

왜 이것이 합리적인가

몇 가지 이유가 있다.

하드웨어와 함께 출시되는 하드웨어 검증은 6개월 늦게 도착하는 하드웨어 검증이다. 이번 주말에 쓰인 열 및 전력 프레임워크는 첫 AR2 개발 키트가 내 책상에 도착하는 그날 사용될 것이다. 3개월 후가 아니라. 플랫폼의 첫 열 퇴행은 사람이 디바이스가 뜨겁다는 것을 알아채서가 아니라 기존 테스트에 의해 잡힐 것이다.

디바이스 없는 테스트 하니스도 여전히 테스트 하니스다. 그것은 시뮬레이션된 센서 트레이스에 대해 실행된다. 그 트레이스는 AR1+ 시대와 스펙에서 나온다. 완벽하지 않다. 인터페이스 버그, 통합 버그, 메트릭 수집 버그를 잡아낸다. 실제 실리콘 아래에서만 나타날 버그는 잡아내지 못한다. 괜찮다. 그것이 잡아내는 버그는 우리가 실제 하드웨어 시간의 첫 주를 사냥하며 보냈을 버그들이고, 이제 우리는 그럴 필요가 없다.

하니스를 쓰는 행위가 스펙을 명확하게 한다. 일요일 저녁까지 안착한 프로덕션 표준 문서의 절반은 주말 시작 시점에는 흐릿한 의도로만 존재했다. 검증 테스트를 쓰는 것이 스펙을 구체적인 숫자로 밀어붙였다. 프레임 예산. 열 설계 여유. Wi-Fi 7 안정성 임계값. 하니스가 문서를 날카롭게 만들었다. 그것이 실제 산출물이다.

에이전트가 전환을 어떻게 다루었는가

AR1+에서 AR2 Gen1으로의 전환이 처음부터 깔끔하게 처리된 것은 아니었다. 주말 중반, 에이전트는 새 코드 경로가 “AR2”라고 말해야 할 곳에 “AR1+”를 참조하는 PR을 안착시켰다. 이슈 프레이밍이 이름 변경을 표시하지 않았기 때문에 그것이 안착했다. 수정은 “문서와 copilot 지시문에서 AR1+ 대 AR2 디바이스 불일치 수정”이라는 제목의 별도 PR이었고, 121개의 개별 참조를 훑어서 정렬시켰다.

이것은 한 명의 인간이 모든 코드를 쓸 때는 일어나지 않는 종류의 일이다. 그 인간은 그냥 진행하면서 이름을 바꾸기 때문이다. 이것은 에이전트가 이름 변경 이전의 이슈를 집어들고 옛 이름을 충실하게 쓸 때 에이전트 기반 워크플로우에서 일어난다. 해결책은 에이전트가 입력으로 읽는 문서를 현재의 현실과 완전히 동기화된 상태로 유지하는 것, 그리고 이름 변경 PR을 그 자체의 독립된 작업으로 쓰는 것이다.

나는 에이전트의 문서가 팀의 문서이기도 한 시스템을 만들고 있다. 문서가 거짓말을 하면, 에이전트는 같은 방향으로 거짓말을 한다. 그것은 내가 제대로 하려고 하는 워크플로우의 특징이지, 버그가 아니다.

특히, Wi-Fi 7 테스트 스위트

이것이 이번 주말에서 내가 가장 자랑스러워하는 것이다.

AR2 Gen1 스펙은 오프로드된 렌더링과 테더링된 컴퓨트를 위해 Wi-Fi 7 연결성을 가정한다. 실제로 Wi-Fi 7은 Wi-Fi 6E만큼 안정적이지 않고, 실패 양상도 다르다. 이번 주말에 쓰인 테스트 스위트는 실패 양상의 스위트(저하된 처리량, 간헐적 손실, 재인증 폭풍)를 특성화하고 각각에 대한 런타임의 동작을 경계 짓는다. 런타임은 모든 실패를 견딜 수 없다. 테스트 스위트의 임무는 런타임이 우아하게 저하되며 견디는 실패와 크게 실패하는 실패를 구체적으로 구분하는 것이다.

이것이 중요한 이유는 연결이 끊길 때 사용자가 경험하는 AR 경험이 끊겨서는 안 되기 때문이다. 런타임은 끊김의 지속 시간에 따라 한 프레임, 또는 두 프레임, 또는 스무 프레임 동안 로컬 렌더링으로 폴백해야 하고, 연결성이 돌아오면 다시 수렴해야 한다. 그 로직은 스펙 안에 흐릿한 의도로 존재했다. 이번 주말 이후로는, 테스트 케이스로 존재한다.

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

두 가지가 있다.

당신이 AR 글래스를 고민하는 하드웨어 파트너라면, 이 엔진이 함께 출시하는 검증 프레임워크는 이 엔진이 경쟁자보다 더 빠르게 당신의 하드웨어 위에서 출시되는 이유 중 하나가 될 것이다. 프레임워크는 이식 가능하다. 새 디바이스 타깃을 추가하는 것은 몇백 줄의 코드에 디바이스별 테스트 벡터를 더한 것이다. 비싼 부분은 이미 지불되었다.

당신이 레이턴시에 민감한 온디바이스 추론을 고민하는 AI 랩이라면, AR2 Gen1 스펙이 가정하는 레이턴시 예산은 공개되어 있다. 센서부터 렌더까지의 종단 간 트레이스는 지금 계측되고 있다. 그래서 당신의 모델이 그 예산 안에 맞아야 할 때, 추론을 위해 실제로 얼마의 예산이 남아 있는지 볼 수 있다. 그것이 11월에 당신과 나누고 싶은 대화다.

주말 동안 77개의 커밋. 문서화로 끝났다. 마무리하기에 올바른 종류의 주말이다.