모바일
스마트폰은 현존하는 가장 널리 배포된 SLAM 플랫폼입니다: 모든 최신 아이폰과 대부분의 안드로이드 기기는 시각-관성 추적을 시스템 서비스로 실행합니다 (ARKit과 ARCore). 따라서 “모바일 SLAM”을 다룬다는 것은 두 가지 별개의 역량을 의미합니다: 네이티브 앱 언어에서 플랫폼 추적 스택을 사용하는 것, 그리고 — SLAM 엔지니어 본연의 업무로서 — 커스텀 C++ 인지 코드를 폰 하드웨어에서 잘 돌아가게 만드는 것입니다.
안드로이드 (Java/Kotlin). 애플리케이션은 Kotlin(또는 Java)으로 작성되지만, SLAM급 코드는 NDK를 통해 C++로 실행되며 JNI로 연결됩니다. 중요한 플랫폼 구성 요소: 프레임 접근을 위한 Camera2/CameraX(타임스탬프와 노출 메타데이터 포함), IMU 데이터를 위한 센서 API, 그리고 자체 모션 추적을 실행하는 대신 Google의 내장 모션 추적을 사용하고 싶다면 ARCore입니다. 안드로이드 SLAM 작업의 실질적인 현실에는 기기마다 카메라-IMU 시간 동기화 품질이 크게 다르다는 점, 그리고 열 스로틀링이 “실시간”의 의미를 좌우한다는 점이 있습니다.
iOS (Objective-C/Swift). 애플리케이션은 Swift(레거시 코드는 Objective-C)로 작성되며, C++가 직접 통합됩니다(Objective-C++ 또는 Swift의 C++ 상호운용). AVFoundation이 카메라 프레임을, CoreMotion이 IMU를 제공하며, ARKit은 애플의 긴밀하게 통합된 VIO를 노출합니다 — 공장에서 캘리브레이션되고 잘 동기화된 카메라-IMU 하드웨어 덕분에 소비자용 추적 품질의 기준으로 널리 인정받고 있습니다. Metal과 CoreML/ANE는 학습된 구성 요소를 위한 GPU 연산과 신경망 추론을 처리합니다.
센서 배선: 모바일 VIO의 생사가 갈리는 지점
- 클록 도메인. 카메라와 IMU 타임스탬프는 동일한 클록 위에 있어야 합니다. 안드로이드에서는
SENSOR_INFO_TIMESTAMP_SOURCE가 카메라 타임스탬프가 IMU의 클록 기준을 공유하는지 (REALTIME) 아니면 자체 기준(UNKNOWN)에 있는지를 알려줍니다 — 후자의 경우 오프셋을 직접, 그리고 기기별로 추정해야 합니다. - 롤링 셔터. 거의 모든 폰 카메라는 행 단위로 순차 판독하므로, 각 이미지 행은 약간 다른 시간에 촬영됩니다; 빠른 움직임에서는 이것이 기하학을 왜곡시키므로 모델링(또는 오차 원인으로 받아들이는 것)이 필요합니다. 플랫폼 트래커는 이를 내부적으로 처리합니다 — 커스텀 파이프라인도 마찬가지로 해야 합니다.
- OIS/EIS. 광학 이미지 안정화는 렌즈를 물리적으로 움직여, 프레임마다 유효 내부 파라미터를 조용히 바꿔놓습니다; 전자식 안정화는 이미지를 왜곡합니다. 둘 다 영상에는 좋지만 기하학에는 적입니다 — SLAM에서는 이들을 끄거나 그 효과를 모델링해야 합니다.
- 노출 메타데이터. 자동 노출은 프레임마다 이미지 밝기를 바꿉니다; 직접법/광도 기반 방법은 Camera2/AVFoundation이 보고하는 노출 시간과 ISO 값이 필요합니다.
엔지니어링 체크리스트
SLAM 엔지니어에게는 모바일에 특화된 체크리스트가 두 플랫폼에서 동일하게 보입니다:
- 센서 접근과 동기화 — 카메라와 IMU의 하드웨어 타임스탬프, 롤링 셔터 인식, 노출/ISO 메타데이터 (위 참조).
- 연산 예산 — (앱과 공유하는) 몇 개의 CPU 코어, NEON SIMD, 모바일 GPU, NPU; 전력과 발열이 지속 가능한 부하를 최대치보다 훨씬 낮게 제한하므로, 차가운 상태가 아니라 뜨거워진 상태에서 벤치마크해야 합니다.
- 언어 브리징 — 공유 C++ 코어 위에 Kotlin/Swift UI를 얹는, 크로스 플랫폼 SLAM 제품의 표준 아키텍처입니다.
- 사용 대 자체 구축 — ARKit/ARCore는 훌륭하고 무료입니다; 폰에서 커스텀 SLAM은 이들이 노출하지 않는 능력(커스텀 센서, 직접 소유하는 맵, 기기 간 재위치 추정)이 필요할 때 정당화됩니다.
지속성과 공유 경험
플랫폼 스택은 내부적으로 순수한 SLAM인 맵 수준의 기능도 노출합니다: ARKit은 맵을 직렬화할 수 있어서(ARWorldMap) 앱이 세션을 저장하고 나중에 다시 그 안에서 재위치 추정을 할 수 있으며, ARCore의 클라우드 앵커는 여러 기기가 동일한 앵커를 서비스로서 크로스 기기 재위치 추정하며 찾아낼 수 있게 합니다. 이것들이 내부적으로 무엇을 하는지(장소 인식, 맵 병합, 재위치 추정) 알면, 언제 이들에 의존해도 되고 언제 자체 매핑 계층이 필요한지를 정확히 알 수 있습니다.
SLAM에서의 의미
모바일 AR은 시각-관성 SLAM이 대규모 배포를 만난 지점이며, 폰의 제약(빡빡한 전력 예산, 롤링 셔터 카메라, 소비자급 IMU)은 이 분야의 엔지니어링 우선순위를 형성해 왔습니다. ARKit/ARCore 위에서 앱을 만들든 이들과 경쟁하든, 모바일 스택 — 센서 배선, 네이티브/매니지드 언어 브리징, 열에 제약된 실시간 — 을 이해하는 것은 가장 큰 플랫폼에 SLAM을 배포하는 데 필수적입니다.