배포된 VIO

세계에서 가장 대량으로 사용되는 SLAM 시스템은 연구용 코드베이스가 아니라, 소비자용 XR 및 모바일 기기 안에 있는 VIO 스택이다. Meta Quest 헤드셋, Apple의 ARKit(아이폰/아이패드, Vision Pro), Google의 ARCore는 각각 수억 대의 기기에서 시각-관성 추적을 실행한다. 이들이 최적화 대상으로 삼는 제약 조건이 학술 시스템이 최적화하는 벤치마크와 크게 다르기 때문에, 사례 연구로서 살펴볼 가치가 있다.

상용 XR 스택의 모습

공통적인 레시피는 인사이드-아웃 트래킹이다:

센서: 여러 대의 넓은 시야각 그레이스케일 카메라(헤드셋은 일반적으로 여러 대를, 폰은 한 대를 사용)와 하나 이상의 IMU를 하드웨어적으로 동기화하여 사용.
추정기: 온디바이스에서 연속적으로 실행되는 긴밀 결합 시각-관성 추정기 — 슬라이딩 윈도우 최적화 또는 필터링.
헤드셋의 추가 기능: 손에 든 컨트롤러와(최신 기기에서는) 손의 추적이 헤드 자세 추정 위에 레이어로 추가됨.
개발자 인터페이스: ARKit, ARCore 같은 폰 AR 프레임워크는 VIO 출력을 6-DoF 카메라 자세와 희소 특징점, 평면 검출, 추적 품질 상태, 영구 앵커로 노출한다.

공개된 기술적 세부 사항은 제한적이다(이들은 독점 시스템이다), 그러나 넓은 아키텍처 — 다중 카메라 + IMU 긴밀 결합 추정과 재위치추정/매핑 계층 — 는 이 레벨이 다루는 공개 문헌과 일치한다.

벤치마크 우선순위 vs 제품 우선순위

	학술 벤치마크	출시된 기기
주요 지표	궤적 RMSE	시간당 인지되는 추적 실패
환경	정제된 데이터셋	모든 침실, 사무실, 기차, 거울
컴퓨팅	데스크탑 CPU/GPU	공유 모바일 SoC, 엄격한 전력 예산
캘리브레이션	오프라인에서 수행, 정확하다고 가정	온도와 낙하에 따라 변동; 온라인으로 보정
초기화	전문가가 기록한 여기(excitation) 운동	훈련받지 않은 사용자가 제공하는 임의의 운동
실패 처리	시퀀스 제외 / 보고	우아하게 저하되고, 눈에 띄지 않게 복구되어야 함

배포가 문제를 어떻게 바꾸는가

강건성이 정확도를 이긴다. 벤치마크는 RMSE를 신경 쓰지만, 헤드셋은 어두운 침실, 텅 빈 벽, 거울, 움직이는 기차, 격렬하게 머리를 흔드는 사용자에서도 추적이 절대 눈에 띄게 실패하지 않아야 한다. 최고 정확도보다는 저하 모드 동작, 빠른 재위치추정, 우아한 폴백(예: 시각적 특징이 사라지면 3-DoF 회전 추적으로 전환)에 엄청난 엔지니어링 노력이 들어간다. 저조도, 저텍스처, 동적 장면, 센서 포화 같은 실패 유형 분류가 벤치마크 순위표보다 로드맵을 더 많이 이끈다.
지연 시간과 전력은 엄격한 제약이다. 모션-투-포톤 지연 시간은(자세 예측 및 렌더링된 프레임의 지연 단계 재투영과 결합하여) 멀미를 피할 만큼 충분히 낮아야 하며, 전체 스택은 렌더링과 SoC를 공유하면서 모바일 전력 예산 내에서 계속 실행되어야 한다. 이는 경량 프론트엔드, 고정소수점/DSP 구현, 전용 코프로세서, 신중한 스레드 스케줄링을 이끌며 — MSCKF 계열의 효율성(CPU 사이클당 정확도)이 다른 어느 곳보다 여기에서 더 중요한 이유다.
대규모 캘리브레이션. 수백만 대의 기기가 있다는 것은 공장별 개별 캘리브레이션에 더해 카메라-IMU 외부/내부 파라미터와 시간 오프셋의 온라인 보정이 필요하다는 것을 의미한다 — 기기는 온도와 낙하에 따라 변형된다. OpenVINS 시대 논문들의 연구 주제였던 온라인 캘리브레이션이 프로덕션에서는 기본 요구 사항이다.
매핑은 제품 기능이다. 영구 앵커, 다중 사용자 AR를 위한 공유/클라우드 앵커, 헤드셋의 “룸스케일” 경계 시스템은 맵 재사용과 재위치추정 문제이다 — 공개 문헌에서 maplab이 다루었던 루프 클로저와 다중 세션 매핑의 배포판 사촌이다.
프라이버시와 안전 제약은 무엇을 저장하거나 업로드할 수 있는지를 결정한다: 맵은 일반적으로 (사진이 아니라) 특징 디스크립터와 기하 정보로 추상화되며 가능한 경우 온디바이스에서 처리된다.
사용자가 시스템의 일부다. 초기화는 훈련받지 않은 사용자가 제공하는 임의의 운동으로 작동해야 하며(“모든 축을 여기시키라”는 지침이 없이), 관측 가능성에 기인한 저하(정지에 가까운 호버링, 순수 회전)는 눈에 띄지 않게 처리되어야 한다 — VIO가 필요로 하는 것을 아는 전문가가 기록한 데이터셋과는 뚜렷이 대조된다.

소스 코드 없이 이들을 연구하는 이유

세 가지 이유가 있다. 첫째, 제약 조건의 집합이 공개 문헌이 왜 그런 모습을 하고 있는지를 설명한다: 효율성에 집착하는 필터, 온라인 캘리브레이션, 빠른 재위치추정, 일관성 관련 장치는 정확히 출시되는 제품이 필요로 하는 것이다. 둘째, 공개된 산출물 — 개발자 API(앵커, 평면 검출, 추적 상태 알림), 기기 분해 조사, 이 팀들의 발표/논문 — 은 구현이 비공개로 유지되더라도 아키텍처에 대한 정보를 제공한다. 셋째, 이 로드맵의 많은 오픈 시스템은 이 팀들에서 왔거나 이 팀들로 간 사람들이 작성했다 — 설계 DNA가 공유된다.

무엇을 취해야 하는가

배포된 VIO를 이 레벨의 요구 사항 문서로 다루라: 여러분이 연구하는 어떤 공개 시스템도 배포 체크리스트에 따라 평가할 수 있다 — 어두운 곳에서는 어떻게 되는가? 재위치추정은 얼마나 빠른가? 자체 캘리브레이션을 추정하는가? 우아하게 저하되는가? 몇 밀리와트인가? — 그리고 여러분이 발견하는 격차가 바로 업계가 실제로 대가를 지불하는 연구 문제이다.

SLAM에서의 의미

배포된 VIO는 이 레벨의 내용이 학술적인 것만은 아니라는 증거다: MSCKF 스타일 필터링, 사전 적분, 온라인 캘리브레이션, 관측 가능성을 고려한 설계가 정확히 소비자 기기에 탑재되는 것들이다. 배포 제약 조건(강건성, 지연 시간, 전력, 캘리브레이션 드리프트)을 연구하면 업계가 실제로 대가를 지불하는 연구 문제가 무엇인지 알 수 있으며 — 이 팀들에서 왔거나 이 팀들로 간 저자들이 작성한 공개 시스템의 설계 선택도 설명해준다.