플랫폼과 표준

증강현실 프로젝트에서 가장 오래 남는 결정은 무엇을 만들 것인가가 아니다. 무엇에 기대어 만들 것인가다. 기기와 앱 사이에는 여러 겹의 약속이 쌓여 있다. 어떤 겹은 여러 회사가 합의한 국제 표준이고, 어떤 겹은 한 회사의 사업 계획이다. 겉보기에 두 겹은 똑같이 작동한다. 차이는 몇 년 뒤에 드러난다. 이 장은 그 겹들을 하나씩 벗겨 본다. 표준이 무엇을 보장하고 무엇을 보장하지 않는지, 플랫폼이 어떤 이유로 기능을 주고 또 거두는지, 지난 십여 년 동안 어느 층이 살아남았는지를 차례로 본다.

곱셈으로 쌓이던 통합 비용

2017년 이전의 확장현실 개발은 기기마다 다른 개발도구를 상대하는 일이었다. Oculus SDK, Valve의 OpenVR, Microsoft의 Windows Mixed Reality, 소니의 PSVR SDK가 나란히 존재했다. 네 도구가 요구하는 일은 사실 같았다. 지금 머리가 어디에 있는지 알려 달라는 것, 그리고 방금 그린 이 프레임을 화면에 띄워 달라는 것이다. 그런데 부르는 함수의 이름과 좌표계의 방향과 프레임을 넘기는 순서가 전부 달랐다.

이 구조에서 통합 비용은 덧셈이 아니라 곱셈으로 쌓인다. 앱이 N개, 기기가 M개면 이어 붙일 자리가 N×M개 생긴다. 기기가 하나 늘어날 때마다 세상의 모든 앱이 일을 하나씩 더 해야 한다는 뜻이다. 결과는 예측 가능했다. 작은 팀은 기기 하나를 골라 붙는 수밖에 없었고, 그 선택이 곧 시장의 크기였다. 기기 제조사는 자기 개발도구에 붙은 앱의 수를 자산으로 여겼으므로, 서로 다르게 만들 이유가 오히려 충분했다.

서랍 가득 쌓인 충전 케이블을 떠올리면 된다. 기기마다 단자가 달랐던 시절에는 케이블 하나를 잃어버리는 일이 기기 하나를 못 쓰게 되는 일이었다. 단자가 하나로 모이자 충전기 제조사와 기기 제조사는 서로를 신경 쓰지 않고 각자 발전할 수 있게 됐다. 확장현실에서 그 단자 역할을 하겠다고 나선 것이 OpenXR이다. ^[1]

곱셈을 덧셈으로 — OpenXR의 구조

OpenXR은 앱과 기기 사이에 얇은 한 겹을 끼워 N×M을 N+M으로 바꾸는 표준이다. 구조는 두 갈래다. 위쪽은 앱이 호출하는 애플리케이션 인터페이스이고, 아래쪽은 런타임이 하드웨어에 닿는 디바이스 플러그인 계층이다. 앱은 위쪽만 알면 되고, 제조사는 아래쪽만 채우면 된다. 시스템에 설치된 활성 런타임을 찾아 연결하는 일은 로더가 맡고, 그 사이에 검증이나 디버깅용 계층을 끼워 넣을 수도 있다. 이 로더와 계층 구조는 Khronos가 OpenGL과 Vulkan에서 이미 쓰던 방식을 그대로 가져온 것이다.

가장 영리한 설계는 입력 모델이다. 앱은 A 버튼이 눌렸는지 묻지 않는다. 집기라는 행위가 일어났는지를 선언적으로 묻는다. 실제 버튼과 행위의 연결은 런타임이 인터랙션 프로파일로 대신 묶어 준다. 그래서 2017년에 존재하지 않던 컨트롤러가 여러 해 뒤에 나와도, 예전에 만든 앱이 코드를 한 줄도 고치지 않고 동작한다. 앱이 하드웨어의 모양을 모르게 만든 것이 표준의 수명을 늘렸다.

라이선스는 자주 잘못 인용된다. 스펙 본문과 레퍼런스 페이지, 문서의 소스는 Creative Commons Attribution 4.0 국제 라이선스를 쓴다. Apache License 2.0이 적용되는 대상은 헤더 파일과 스크립트, 프로그램, XML, 빌드 툴링이다. XML 레지스트리와 메인 헤더, 로더는 Apache-2.0과 MIT의 이중 라이선스다. 스펙 전체에 Apache 2.0이 붙어 있다는 설명은 사실과 다르다. 로열티가 없다는 점은 Khronos의 공식 서술대로 맞다.

표 출처: ^[1] (본문 기준으로 재구성)

엔진 쪽 지원 시점도 정리해 둘 만하다. Unreal은 4.24부터, Unity는 2020.2부터, Godot은 4.0부터, Blender는 2.83 LTS부터 OpenXR을 다룬다. SteamVR의 정식 지원은 v1.16, 2021년 2월이며 그 이전에는 베타 경로가 있었다. 주의할 점이 있다. Unity의 2020.2는 최초 지원 버전이고, 현행 OpenXR 플러그인은 에디터 2021.3 LTS 이상을 요구한다. 같은 항목의 두 숫자는 기준이 다르다.

적합 런타임의 수를 세는 일도 함정이 있다. Khronos의 적합 제품 목록에 제출한 회사는 15곳이고, Khronos의 OpenXR 소개 본문이 인용하는 수는 XREAL을 포함해 14곳이다. 더 중요한 것은 목록의 행 단위가 회사가 아니라 제품이라는 점이다. Meta만 Quest 2와 3, 3S, Pro, XR Simulator로 다섯 건이고 Varjo는 XR-3와 VR-3, Aero, XR-4로 여러 건이다. 런타임이 열몇 개라는 서술은 회사 수와 제품 수를 섞은 결과다. 또 목록에 오른 Sony의 제품은 Spatial Reality Display 계열이고 Acer는 Spatial Display 시리즈, Canon은 MREAL 플랫폼이다. 모두 데스크톱형 입체 디스플레이나 산업용 기기이며, PlayStation VR2용 OpenXR 런타임은 존재하지 않는다. 소니가 목록에 있다는 사실을 가정용 기기의 표준 채택으로 읽으면 안 된다. ^[1]

확장에서 코어로 — 승격이라는 신호

OpenXR은 코어 스펙을 작게 유지하고 새 기능을 확장으로 먼저 내보낸다. 흔히 확장 이름의 접두사를 신뢰도 등급으로 설명하지만 그것은 오해다. 접두사는 저자와 승인 경로를 나타낸다. 벤더 이름이 붙은 확장을 다른 회사의 런타임이 구현하는 것은 규약상 허용되고 실제로도 흔하다. XR_EXT_가 붙었다는 사실도 복수 벤더의 저작을 뜻할 뿐이며, 구현한 런타임이 하나뿐인 EXT 확장도 많다.

그렇다면 실무에서 진짜로 달라지는 것은 무엇인가. 앱 코드의 모양이다. 확장은 있으면 쓰고 없으면 대체 경로로 빠지는 분기를 강제한다. 코어 기능은 분기 없이 호출하면 된다. 그 버전을 지원하는 모든 런타임이 반드시 제공하기 때문이다. 어떤 기능이 아직 확장이면 그 기능을 전제로 제품을 설계하는 일은 도박에 가깝고, 코어에 들어왔다면 가정해도 된다. 사투리가 널리 쓰이다가 사전에 표준어로 등재되는 과정과 같다. 등재 전에는 통할지 모르는 말이고, 등재 후에는 모두가 알아야 하는 말이 된다.

표 출처: ^[2] (본문 기준으로 재구성)

1.1은 이 승격이 실제로 작동함을 보여준 첫 사례다. 눈동자를 추적해 보고 있는 곳만 고해상도로 그리는 최적화가 한 회사의 확장에서 표준 기능으로 옮겨 갔다. 이름은 출처에 따라 갈린다. Khronos 스펙의 명칭은 Stereo with Foveated Inset이고, 2024년 4월 15일 UploadVR의 보도는 Stereo with Foveated Rendering으로 적었다. 같은 개정에서 인터랙션 프로파일 13종이 새로 추가됐고 스타일러스, 트리거 컬 감지, 근접 감지 관련 항목이 들어왔다.

Local Floor의 승격은 소박하지만 실용적이다. 그전까지는 바닥 높이를 아는 공간과 세션 시작점을 원점으로 삼는 공간 둘뿐이었다. 바닥은 알되 원점은 지금 사용자가 선 자리로 하자는 흔한 요구가 표준에 없었다. 지지 표명 명단은 출처마다 다르다. Khronos 페이지의 회원사 인용문에는 Collabora, Meta, PICO, Qualcomm, Valve, HTC가 있고 UploadVR의 기사에는 Meta, Pico, HTC, Valve, Varjo, Unity가 나온다. 두 출처가 공통으로 확인하는 사실은 하나 더 있다. Apple은 이 워킹그룹에 참여하지 않는다. 1.1 이후의 개정 여부는 이 자료로 확인되지 않는다. ^[2]

설치 없이 도달하기 — WebXR

WebXR Device API는 웹 페이지가 헤드셋과 카메라의 자세 정보를 받아 3차원 화면을 그리게 하는 브라우저 표준이다. 세션은 세 모드로 나뉜다. inline은 일반 페이지 안에 놓인 3차원 뷰, immersive-vr은 헤드셋 전체 화면, immersive-ar은 현실 영상 위에 겹치는 모드다. 웹 페이지가 카메라를 빌려 쓰는 일과 비슷하지만 성격이 다르다. 카메라는 사진 한 장을 주고 끝나는데, 이쪽은 매 프레임 지금 사용자의 머리가 어디를 향하는지를 계속 넘긴다.

핵심 개념은 참조 공간이다. 무엇을 흔들리지 않는 원점으로 삼을지 고르는 일이며, 이 선택이 곧 누적 오차를 어디로 밀어낼지의 선택이다.

표 출처: ^[3] (본문 기준으로 재구성)

렌더링 루프도 일반 웹과 다르다. 브라우저의 requestAnimationFrame이 아니라 XRSession의 requestAnimationFrame을 써야 한다. 브라우저 화면의 초당 60프레임이 아니라 헤드셋 디스플레이의 실제 프레임 타이밍에 정확히 물려야 하기 때문이다. 표준의 상태는 W3C 후보 권고 초안이며 문서 일자는 2026년 6월 9일이다. 편집자는 Google의 Brandon Jones와 Manish Goregaokar, Meta의 Rik Cabanier다. 히트 테스트, 앵커, 깊이 감지, 조명 추정, DOM 오버레이, 손 입력은 본 스펙이 아니라 별도 모듈로 분리해 관리한다. ^[3]

브라우저 지원의 비대칭과 그 뒤의 논리

표준이 존재하는 것과 쓸 수 있는 것은 다르다. caniuse의 집계에서 WebXR의 완전 지원은 0퍼센트이고 부분 지원이 77.15퍼센트다. 합계 77.15퍼센트 전부가 부분 지원이라는 뜻이며, 일부만 부분 지원인 상태로 읽으면 실제보다 낙관적으로 보인다.

표 출처: ^[4] (본문 기준으로 재구성)

Chrome과 Edge를 한 괄호에 묶어 2020년 1월로 적은 인용이 널리 돌지만, Chrome 79의 출하는 2019년 12월 10일이다. Firefox에서 77이라는 분기점을 특정하는 서술도 근거가 확인되지 않는다. caniuse의 Firefox 행은 전 구간이 미지원이거나 기본 비활성이다. Opera는 출처가 충돌한다. caniuse는 Opera Mobile 80만 부분 지원으로 적고 위키백과의 WebXR 문서는 Opera 66 이상, Opera Mobile 64 이상으로 적는다. 두 수치가 맞지 않으므로 어느 한쪽을 단정하면 안 된다. 데스크톱 Opera와 Meta Quest Browser가 지원 목록에서 빠지는 일도 흔하다.

이 비대칭에는 기술 외의 이유가 있다. immersive-ar 세션은 페이지에 사실상 방의 형태와 사용자의 움직임을 넘긴다. 지문 채취와 감시의 새로운 표면이 열리는 것이다. Apple이 Vision Pro에서 웹의 공간 기능을 열 때 새 입력 모델을 발명한 것이 그 태도를 잘 보여준다. 기존 입력은 컨트롤러나 화면 터치를 가정했는데, 이 기기의 조작은 눈으로 보고 손가락을 맞대는 방식이다. 시선을 그대로 넘기면 사용자가 무엇에 관심을 두는지가 페이지로 새어 나간다. 그래서 핀치하는 순간에만 잠깐 존재하는 transient-pointer라는 입력 소스를 만들었다.

WebKit의 2024년 3월 19일 설명에 따르면 이 광선은 사용자의 두 눈 사이에서 출발한다. 방향은 핀치를 시작한 시점의 시선을 가리키고, 그 뒤로는 눈이 아니라 손의 움직임에 따라 갱신된다. 손을 왼쪽으로 옮기면 광선도 왼쪽으로 움직인다. 페이지가 아는 것은 사용자가 어디를 보고 있었는지가 아니라 방금 무엇을 골랐는지다. 식당에서 메뉴판을 훑는 시선까지 알려 주는 대신 최종 주문만 말하는 셈이다. 주문은 정확히 전달되고 고민의 흔적은 남지 않는다. 핀치한 손가락의 위치는 gripSpace로 주어지고, 손 추적은 선택적으로 요청해야 하는 기능이다.

시점도 확인이 필요하다. 플래그 뒤에 제공되던 단계는 Safari 17.4와 visionOS 1.1의 이야기이며, WebKit은 visionOS 2용 Safari 18.0에서 immersive-vr 세션 지원을 정식으로 발표했다. 여기서 주의할 것이 있다. 정식 출하가 확인된 것은 immersive-vr이고, 이 기기의 Safari에서 immersive-ar 세션이 되는지는 확인되지 않는다. 설치 없는 증강현실의 사례로 이 기기를 들 수는 없다. 배포 대상에 iPhone이 포함된다면 웹만으로 겹쳐 보이는 체험을 만드는 경로는 아직 성립하지 않으며, 모델 뷰어 수준의 대체 표시나 네이티브 앱을 함께 준비해야 한다. ^[4]

평면에서 지구까지 — ARKit이 넓혀 온 근사

ARKit의 역사는 세상을 무엇으로 근사하는가의 확장사로 읽힌다. 처음에는 방을 바닥이라는 큰 종이 한 장으로 알았다. 그다음 벽을 알게 되고, 방 안의 사람을 알게 되고, 마침내 방 전체의 울퉁불퉁한 형상까지 알게 됐다. 눈을 뜬 순서가 아니라 이해의 해상도가 올라간 순서다.

자기 위치는 카메라 영상의 특징점과 관성 센서를 융합해 푼다. 같은 높이에 모인 특징점을 묶어 평면으로 추정하는 방식이 1세대다. 이때의 평면 추정이 무한히 뻗은 면이었다는 설명은 정확하지 않다. 초기부터 중심과 크기를 가진 유한한 사각형 추정이었고, 임의의 경계 폴리곤은 iOS 11.3에서 추가됐다. 무한 평면은 광선을 쏠 때 고르는 옵션의 이름이다.

질적 도약은 사람을 인식한 시점에 왔다. 매 프레임 신경망으로 사람 형태의 마스크와 사람까지의 대략적 깊이를 추정해, 사람이 가상 물체보다 앞에 있으면 그 픽셀을 지운다. 가상 물체가 진짜로 그 공간에 있다는 느낌의 상당 부분이 여기서 나온다. 다만 이 기능과 골격 추적은 iOS 13의 모든 기기에서 되지 않았다. A12 Bionic 이상이라는 조건이 붙는다.

라이다는 접근 방식을 바꿨다. 두 시점의 시차를 계산하는 대신 빛의 비행시간을 직접 재기 때문에, 특징점이 없는 흰 벽이나 어두운 방에서도 깊이가 나온다. 위치 기반 앵커는 위성 항법이 못 하는 일을 한다. 도심에서는 건물에 반사된 전파 때문에 수평 오차가 수십 미터까지 벌어지지만, 카메라가 본 건물 파사드를 지도 서비스의 거리 영상과 대조하면 훨씬 좁게 수렴한다.

표 출처: ^[5] (본문 기준으로 재구성)

이 표는 조심해서 써야 한다. Apple의 ARKit 문서는 API 단위로 구성되어 있고 버전과 기능을 대응시킨 표를 제공하지 않는다. 위 계보는 1차 출처에 없는 2차 재구성이며, 위치 앵커가 ARKit 4에 속하는지 5에 속하는지, 방 스캔 기능과 사진 기반 모델 생성의 정확한 도입 시점은 확인되지 않았다. 해상도 수치는 조건을 반드시 함께 적어야 한다. 3840×2160의 16 대 9 캡처는 초당 30프레임 고정이고 HD는 60프레임이다. iPhone 11 이상과 M1 계열 iPad Pro로 한정되며, HDR은 화소 병합을 쓰지 않는 포맷에서만 가능하고 성능 비용이 따른다. 방 스캔 기능은 라이다를 요구하는 별도 프레임워크다. ^[5]

카메라를 주지 않는 방식 — 헤드셋의 권한 모델

visionOS의 ARKit은 이름만 같을 뿐 휴대폰의 그것과 권한 모델이 근본적으로 다르다. 시스템이 먼저 세상을 해석하고, 앱에는 해석 결과만 넘긴다. 평면과 재구성된 메시, 손 관절 좌표, 월드 앵커가 그 결과다. 통역사를 통해서만 대화하는 것과 같다. 상대가 실제로 어떤 표정을 지었는지는 볼 수 없지만 의미는 정확히 전달되고, 하지 말아야 할 말은 통역사가 걸러 준다.

이유는 상시 착용 기기의 특성에 있다. 이런 기기를 쓴 사람이 방에 들어가면 카메라 원본에는 그 방의 모든 얼굴과 책상 위 서류가 담긴다. 이걸 앱에 그대로 주면 사용자가 아니라 주변 사람들의 사생활이 앱 개발자에게 위임된다. 그래서 공간 사용 모드에 따라 제공 데이터가 달라진다. 여러 앱이 창처럼 떠 있는 공유 공간에서는 제공이 제한되고, 앱 하나가 시야를 독점하는 전용 공간에서 명시적 허가를 받아야 전체 데이터가 나온다.

여기서 설계 원리와 구현 사실을 분리해야 한다. 시스템이 먼저 해석한다는 것은 이 플랫폼의 설계 원리다. 일반 앱이 패스스루 카메라의 원본 프레임을 받지 못한다는 것은 visionOS 1의 기본 권한 상태다. visionOS 2 이후 Apple은 기업용 엔타이틀먼트로 메인 카메라 접근을 제공했고 이후 배포 조건도 완화됐다. 카메라를 영구히 주지 않는 아키텍처라고 일반화하면 시점을 놓친다.

표 출처: ^[6] (본문 기준으로 재구성)

개발자에게 이는 제약이면서 동시에 선물이다. 손 추적의 품질을 직접 손볼 수 없지만, 직접 만들지 않아도 된다. 실무에 주는 함의는 분명하다. 독자적인 인식 기술로 차별화하려는 계획은 플랫폼 정책 하나로 불가능해질 수 있으므로, 설계 초기에 어떤 데이터가 실제로 앱까지 도달하는지 확인해야 한다. Apple은 표준 런타임 워킹그룹에 참여하지 않고 ARKit과 RealityKit의 독자 스택을 유지한다. ^[6]

화이트리스트로 파편화를 푸는 법 — ARCore

ARCore가 푸는 문제는 성격이 다르다. Apple은 자기가 만든 열몇 종의 기기만 상대하므로 카메라의 초점거리와 왜곡 계수, 관성 센서의 시간 지연을 공장 단계에서 안다. Google은 수백 종을 상대해야 한다. 시각과 관성을 융합하는 위치 추정은 이 값들이 정확해야 성립한다. 카메라의 노출 시각과 관성 센서의 샘플 시각이 몇 밀리초만 어긋나도 추정이 발산한다.

그래서 Google은 화이트리스트를 택했다. 제조사가 기기를 제출하면 Google이 카메라 품질과 모션 센서, 하드웨어 설계와 통합된 충분한 연산 성능을 검증하고 캘리브레이션 프로파일을 만든다. 그 과정을 통과한 모델만 지원 기기가 된다. 여기에 Google Play 탑재라는 조건이 붙어 중국 내수 기기는 별도 목록으로 관리된다.

깊이 API의 설계도 같은 제약의 산물이다. 전용 센서를 요구할 수 없으므로 사용자가 기기를 조금 움직일 때 생기는 프레임 사이의 시차로 깊이를 추정한다. 한쪽 눈을 감고 고개를 좌우로 흔들면 가까운 물건이 멀리 있는 것보다 훨씬 크게 움직인다. 정확히 그 원리이고, 그래서 사용자가 가만히 서 있으면 깊이가 채워지지 않는다.

표 출처: ^[7] (본문 기준으로 재구성)

두 가지를 덧붙여야 한다. Android 13 이상을 요구하는 기기가 있다는 서술은 공식 문서에서 확인되지 않는다. 그리고 2024년 8월의 1.45를 안정 버전으로 인용하는 자료가 많지만 이는 백과사전 정보상자에 굳어 있는 값이므로 현행 버전으로 읽으면 안 된다. 실무에서 더 중요한 함의는 도달 범위의 계산법이다. 앱이 닿는 기기의 수는 운영체제 점유율이 아니라 인증 기기 목록이 정한다. 기획 단계에서 대상 시장의 실제 기기 구성을 확인하지 않으면 출시 후에 되는 기기가 없다는 상황이 온다. ^[7]

지구를 좌표계로 — VPS와 지오스페이셜

위성 항법은 전파의 도달 시간을 재는 방식이라 도심 협곡에서 치명적으로 흔들린다. 건물에 반사된 신호가 직진 신호보다 늦게 도착하는 다중 경로 때문에 오차가 수십 미터까지 벌어진다. 방향은 자기 나침반에 의존하므로 철골 구조물 옆에서는 더 나쁘다.

시각 위치 확인 서비스는 반대 방향으로 접근한다. 카메라가 지금 보는 픽셀에서 특징점을 뽑아, 15년 넘게 수집한 거리 영상으로 만든 전 지구 규모의 3차원 점군에 신경망으로 정합한다. 건물 파사드의 모양은 반사되지도 흔들리지도 않으므로 훨씬 안정적이다. 처음 가 본 도시에서 주소를 몰라도 주변 건물 실루엣을 사진첩과 대조해 위치를 짚는 일과 같다. 기계가 그 대조를 지구 규모로 한다.

문제는 데이터 크기다. 전 세계 점군을 기기에 넣을 수 없으니 먼저 위성 항법으로 후보 지역을 좁힌다. 수십 미터 오차면 후보를 좁히는 데는 충분하다. 그다음 그 지역의 국소 모델만 받아 정합한다. 커버리지는 거의 모든 국가로 서술되지만 기기별 지원 편차가 있고, 일부 기기는 지오스페이셜 기능을 지원하지 않는다고 명시된다.

표 출처: ^[8] (본문 기준으로 재구성)

앵커가 세 종류인 것에는 실무적 이유가 있다. 콘텐츠를 놓을 지점의 정확한 해발고도를 아는 기획자는 드물다. 그래서 절대 고도 외에 땅 위에 놓으라는 지정과 옥상에 놓으라는 지정이 필요하다. 정확도 수치는 이 자료로 단정할 수 없다. 수평 오차 몇 미터, 방향 몇 도라는 공개 수치는 공식 문서에서 확인되지 않으므로, 실제 값은 런타임이 돌려주는 자세 정확도 필드로 측정해야 한다. 그래도 판단 기준은 분명하다. 커버리지 안이면 배포가 좌표 입력으로 끝나고, 밖이면 현장마다 스캔과 앵커 등록이라는 물리적 작업이 붙는다. ^[8]

좌표가 아니라 약속 — 앵커

앵커를 저장된 좌표로 이해하면 왜 앵커가 따로 필요한지 설명되지 않는다. 증강현실의 좌표계는 세션마다 원점이 다르고 시간이 지나면 누적 오차로 흘러간다. 어제 특정 숫자 위치에 놓은 물건을 오늘 같은 숫자로 불러오면 엉뚱한 데 나타난다. 앵커는 숫자가 아니라 이 특징점 뭉치 옆이라는 상대적 약속이다. 시스템은 매 프레임 그 약속을 다시 풀어 현재 좌표계상의 위치를 갱신한다. 기준이 물리적 세계 쪽이므로 좌표계의 흐름이 물건을 끌고 다니지 않는다.

친구에게 위치를 알려 줄 때 위경도를 부르지 않고 우리 집 앞 은행나무 밑이라고 말하는 것과 같다. 좌표는 오차가 있지만 은행나무는 제자리에 있다. 다만 그러려면 친구도 그 은행나무를 알아야 한다. 그 알게 하는 데이터가 점군이다.

클라우드 앵커는 이 약속을 남에게 전달하는 기능이고, 전달되는 것이 좌표가 아니라 특징 지도라는 점이 결정적이다. 앵커를 올리려면 기기가 주변을 여러 각도에서 촬영해 3차원 특징 맵을 만들어 서버로 보내야 한다. 다른 기기가 같은 장소를 비추면 서버가 특징을 대조해 상대 자세를 복원한다. 그러므로 공유 앵커는 본질적으로 남의 집 거실 구조를 서버에 올리는 일이다. 저장 비용과 사생활, 수익화 문제가 동시에 발생하는 지점이며, 앵커 서비스들이 줄줄이 문을 닫은 이유도 여기에 있다.

표 출처: ^[9] (본문 기준으로 재구성)

Meta의 방식은 저장과 공유, 불러오기를 비동기 호출로 나눈다. 앵커를 저장하고, 공유하고, 받은 식별자를 다른 기기에 알리고, 그 기기가 묶이지 않은 공유 앵커를 불러오는 순서다. 향상된 공간 서비스를 켜야 동작하고, 저장 앵커가 많아지면 설정에서 물리 공간 기록을 지우라는 안내가 붙는다. 이 기능은 여러 사람이 같은 가상 물체를 같은 자리에서 보는 다중 사용자 체험의 유일한 기반이다. 동시에 공간 데이터가 외부로 나간다는 뜻이므로, 기업과 공공 현장에서는 보안 검토의 첫 번째 항목이 된다. ^[9]

전송을 위한 형식 — glTF

glTF의 설계 목표는 하나다. 그래픽 처리 장치가 바로 쓸 수 있는 상태로 저장한다. 정점 데이터를 세 층으로 나눈 것이 핵심이다. 원시 바이트 덩어리인 buffer, 그 안의 구간을 가리키는 bufferView, 구간을 어떤 타입으로 읽을지 정하는 accessor다. 이 구조 덕분에 파일에서 읽은 바이트를 변환 없이 장치 버퍼로 복사할 수 있다. 웹과 모바일에서는 파싱 시간이 곧 로딩 시간이므로 이 차이가 체감을 가른다.

두 번째 설계 결정은 재질 모델의 고정이다. 1.0은 WebGL 셰이더 코드를 파일에 담았고, 그 결과 다른 렌더러로는 이식되지 않는 실패를 낳았다. 2.0은 이를 버리고 물리 기반의 금속성과 거칠기 모델 하나로 통일했다. 두 숫자로 재질을 기술하니 어느 렌더러에서 열어도 비슷한 그림이 나온다.

압축은 코어가 아니라 확장으로 뺐다. 여기서 정직하게 짚어야 할 긴장이 있다. Draco와 meshopt는 메시를, KTX 2.0과 Basis Universal은 텍스처를 담당하는데, 이들은 모두 런타임 디코드나 트랜스코드 단계를 요구한다. 즉 변환 없이 곧바로 업로드한다는 성질을 전송량과 맞바꾸는 선택이다. 비압축 경로에서도 희소 accessor나 정규화 정수 타입은 직접 업로드의 예외에 해당한다. 텍스처 압축이 특히 까다로운 이유는 장치마다 지원 포맷이 다르기 때문이다. Basis Universal은 중간 형태로 저장했다가 기기에서 그 기기가 지원하는 포맷으로 빠르게 옮긴다.

표 출처: ^[10] (본문 기준으로 재구성)

확장자는 JSON 기반의 .gltf와 바이너리인 .glb로 나뉘고, 후자는 2.0부터 본 스펙에 포함됐다. 채택 사례로 자주 인용되는 스미스소니언의 2020년 2월 공개는 숫자를 조심해야 한다. 약 280만 건은 2차원 이미지와 3차원 모델을 합친 공개 레코드 총수이고 절대다수가 2차원 이미지다. 그중 3차원 모델에 glTF를 썼다는 것이 사실이며, 280만을 3차원 자산의 수로 읽으면 규모가 여러 자리 과장된다.

형식 선택이 체감 성능인 이유는 단순하다. 증강현실 콘텐츠는 대부분 네트워크 너머에서 즉시 열려야 한다. 모델 하나를 띄우는 데 3초가 걸리면 사용자는 카메라를 내린다. 편집 정보를 다 품은 원본 파일과 어디서나 즉시 열리는 배포 파일의 관계를 떠올리면 위치가 분명해진다. glTF는 후자의 자리를 노리고 만들어졌다. ^[10]

합성을 위한 형식 — USD와 USDZ

USD의 본체는 파일 포맷이 아니라 합성 규칙이다. 한 장면이 여러 레이어로 쪼개져 있고, 각 레이어는 같은 객체에 대해 의견을 낸다. 어떤 의견이 이기는지를 정하는 강한 우선순위 체계가 있어서, 조명 담당과 모델링 담당이 같은 장면을 동시에 편집해도 서로의 파일을 건드리지 않고 결과가 결정론적으로 합쳐진다. 여러 장의 트레이싱지를 겹쳐 놓은 도면과 같다. 각자 자기 종이에만 선을 긋고, 겹쳐 보면 완성된 그림이 된다.

이 설계는 수백 명이 한 장면을 만드는 영화 제작 파이프라인의 요구에서 나왔다. 우선순위 체계는 서브레이어, 상속, 배리언트 세트, 참조, 페이로드, 특수화의 순서로 정리된다. 그중 페이로드가 특히 중요하다. 참조만 걸어 두고 실제 데이터는 필요할 때 읽는 지연 로딩이라, 도시 한 채 규모의 장면도 열 수 있다.

USDZ는 이 형식을 배포용으로 묶은 것이며, 무압축 zip이라는 선택이 이상해 보이지만 이유가 있다. 압축하면 파일 하나를 꺼내려고 전체를 풀어야 한다. 압축하지 않고 각 파일의 시작 위치를 정렬해 두면 메모리 매핑으로 필요한 텍스처만 직접 읽을 수 있다. 다운로드가 끝나기 전에 보이는 부분부터 표시하는 일이 가능해진다.

표 출처: ^[11] (본문 기준으로 재구성)

실무 콘텐츠는 여러 사람이 여러 도구로 만든다. 변경이 잦은 프로젝트에서 합성 가능한 원본이 없으면 모델 하나를 고칠 때마다 전체를 다시 내보내야 한다. USD는 그 반복 비용을 줄이려는 형식이다. ^[11]

두 형식은 왜 공존하지 못하는가

이론적으로 두 형식은 층이 다르다. USD는 저작과 합성, 협업에 최적화된 쓰기 쪽 형식이고 glTF는 전송과 런타임에 최적화된 읽기 쪽 형식이다. USD로 만들고 glTF로 내보내면 될 일이다. 원고 파일과 인쇄본의 관계처럼 각자의 자리가 있다. 실제로 충돌이 생기는 이유는 세 가지다.

첫째, 재질 모델이 일대일로 대응하지 않는다. USD 쪽은 미리보기 표면 셰이더와 MaterialX 노드 그래프를 쓰고 glTF는 금속성·거칠기 코어에 확장을 얹는다. 두 체계의 파라미터가 정확히 겹치지 않아 왕복 변환에서 재질이 깨진다. 실무자가 가장 자주 겪는 손실 지점이 여기다. 둘째, 정치적 요인이 있다. Apple이 2018년 iOS 12에서 자사 미리보기 기능의 형식을 USDZ로 못 박으면서, 그 운영체제에 콘텐츠를 올리려면 다른 선택지가 없어졌다. Khronos 진영은 그 사이 glTF를 웹과 Android 쪽에 정착시켰다. glTF는 2022년 7월 국제표준이 됐고, 같은 해 이후 두 진영은 각자의 영역을 굳혔다.

셋째, 구현 규모가 다르다. OpenUSD의 참조 구현은 수십 메가바이트 규모의 C++ 코드라 웹 페이지가 통째로 싣기 어렵다. glTF 로더는 수십 킬로바이트로도 만들어진다. 형식의 표현력과 배포 가능성이 반대 방향으로 작동하는 것이다. 두 단체가 상호운용을 위해 협력한다는 이야기가 돌지만 이 자료로는 출처를 확인하지 못했다.

결국 현장은 두 형식을 모두 유지하고 변환 파이프라인을 관리하는 쪽으로 수렴했다. 그러므로 자산 파이프라인 설계에서 가장 먼저 결정할 항목은 어느 쪽을 정본으로 삼을지다. 이 결정을 미루면 수정할 때마다 두 형식을 각각 손보다가 둘이 어긋난 상태로 굳는다. ^[12]

엔진의 두 전략 — Unity와 Unreal

Unity는 아래쪽에 제공자 플러그인을 둔다. OpenXR 플러그인과 ARCore, ARKit용 플러그인이 그것이고, 어느 제공자를 활성화할지는 XR Plugin Management가 고른다. 여기서 흔한 오해를 바로잡아야 한다. 이 스택은 위로 갈수록 좁아지는 단일 피라미드가 아니다. AR Foundation은 평면과 앵커, 메시, 이미지 추적 같은 증강현실 서브시스템의 상위 API이고, 머리 착용 기기의 컨트롤러와 햅틱, 포즈는 AR Foundation을 거치지 않는다. 입력과 상호작용은 XR Interaction Toolkit과 Input System이 담당하며 OpenXR 자체가 행위 기반 입력을 쓴다.

또 하나. AR Foundation은 스스로 인식을 하지 않는다. 평면 관리자 컴포넌트는 평면을 달라는 주문서일 뿐이고 실제 검출은 아래쪽 서브시스템이 수행한다. 그러므로 제공되는 기능은 두 플랫폼의 교집합에 가깝다. 만능 리모컨과 같다. 어느 텔레비전에서나 전원과 볼륨은 통하지만 그 기기에만 있는 버튼은 따로 배워야 한다. 실무의 결론은 한 번 작성하면 어디서나 돈다가 아니라, 한 번 작성하되 기능 가용성을 매번 질의해야 한다는 것이다. 각 기능마다 지원 여부를 묻는 서술자가 제공되며, 이 질의를 생략한 코드가 다른 기기에서 조용히 아무것도 하지 않는 것이 가장 흔한 버그다.

표 출처: ^[13][14] (본문 기준으로 재구성)

Unreal은 다른 그림이다. OpenXR 지원은 4.24에서 도입됐고 문서는 이 경로가 머리 착용 기기만 지원한다고 명시한다. 이 문장은 전략적 단일화의 선언이 아니라 커버리지의 한계를 알리는 고지다. 같은 문서가 휴대형 증강현실을 근본적으로 다른 별도 경로로 따로 다룬다. 실무에서도 Quest는 Meta의 전용 플러그인, PSVR2는 플랫폼 개발도구 경로를 쓰고, 얼굴 캡처 같은 기능은 ARKit 기반의 벤더 종속 경로로 들어온다. 이 엔진이 추상층을 한 겹 덜 쓴다는 정리도 정확하지 않다. 자체 추적 시스템 인터페이스와 헤드 마운트 디스플레이 모듈, 확장 입력 체계라는 고유 추상층을 유지한다.

그러므로 엔진 선택은 벤더 확장에 얼마나 직접 접근할 것인가의 선택으로 정리된다. 공통 API에 기대면 이식이 쉽고 기능이 좁다. 벤더 확장에 직접 붙으면 최신 기능을 먼저 쓰지만 분기 관리가 앱의 몫이 된다. 어느 쪽도 공짜가 아니다. ^[13][14]

12밀리초라는 벽

패스스루 방식에서는 사용자가 보는 현실조차 카메라를 거친 영상이다. 카메라 노출에서 판독, 처리, 합성을 지나 디스플레이가 빛을 내기까지의 전 구간 지연이 크면 고개를 돌릴 때 세상이 한 박자 늦게 따라온다. 생방송 중계의 딜레이와 같은데, 훨씬 예민하다. 중계되는 것이 남의 움직임이 아니라 사용자 자신의 움직임이기 때문이다.

안쪽 귀의 균형 기관은 머리 움직임을 즉시 감지한다. 눈이 보는 움직임이 그와 어긋나면 뇌는 이를 이상 신호로 해석해 멀미와 두통을 만든다. 여기서 자주 인용되는 20밀리초는 생리학적 상수가 아니다. 프레즌스 확보를 위한 공학 목표치로 자리 잡은 경험칙이며, 지연을 알아채는 역치는 과제와 시야, 움직임 속도에 따라 한 자릿수 밀리초에서 수십 밀리초까지 보고된다. 안구를 보상 회전시키는 반사의 반응 시간이 10밀리초 수준이라는 사실은 별개의 이야기다. 그러니 20밀리초는 업계가 합의한 예산선으로 이해하는 것이 정확하다.

Apple이 내건 12밀리초도 정의역을 정확히 알아야 한다. 공식 서술은 R1 칩이 새 이미지를 12밀리초 안에 디스플레이로 스트리밍한다는 것이다. 센서 입력에서 디스플레이 전달까지의 칩 파이프라인 구간이며, 센서의 노출과 판독 시간, 디스플레이의 주사와 발광 지속은 포함되지 않는다. 눈 깜빡임보다 8배 빠르다는 표현도 깜빡임을 100밀리초쯤으로 잡은 환산이다. 이 수치를 카메라의 광자에서 눈의 광자까지의 전 구간 지연으로 읽으면 실제를 과소평가한다.

표 출처: ^[15] (본문 기준으로 재구성)

경쟁 기기의 구성을 나란히 두면 설계 예산이 더 잘 보인다. Quest 3는 2023년 10월 10일 출시됐고 눈당 2064×2208의 RGB 스트라이프 LCD를 90에서 120헤르츠로 구동한다. 컬러 패스스루에 400만 화소 카메라 두 개, 깊이에는 적외선 패턴 투사 방식, 추적에는 400×400 적외선 카메라 네 개를 쓰고 Snapdragon XR2 Gen 2를 얹었다. 가격은 시점을 함께 적어야 한다. 출시가는 128기가바이트 $499.99, 512기가바이트 $649.99였으나 2024년 9월까지 128기가바이트 모델이 $429.99로 내려간 뒤 단종되고 512기가바이트가 $499.99가 됐다.

지연 예산은 다른 모든 사양을 위에서 누른다. 패스스루 카메라의 해상도를 디스플레이보다 낮게 잡는 이유가 그것이다. 화소를 늘리면 읽고 옮기고 처리하는 시간이 같이 늘어난다. 패스스루 영상이 실제보다 뿌옇게 보이는 것은 기술이 모자라서가 아니라 예산을 지키려 치른 대가다. 사양표에서 실제로 중요한 숫자는 해상도가 아니라 지연이며, 이 숫자를 모르면 제조사들이 왜 더 좋게 만들 수 있는데도 만들지 않는지 설명할 수 없다. ^[15]

플랫폼은 어떻게 죽는가

플랫폼의 죽음에는 반복되는 패턴이 있다. 첫 번째는 3단계 소멸이다. 판매 중단, 클라우드 서비스 종료, 기기 무력화의 순서로 진행된다. 치명적인 것은 두 번째 단계다. 기기의 핵심 기능이 클라우드에 의존하면 회사의 결정 하나로 사용자 손에 있는 하드웨어가 벽돌이 된다. Magic Leap 1이 정확히 이 경로로 죽었다.

두 번째는 운영체제 업데이트에 묻히는 소멸이다. Windows Mixed Reality는 별도의 종료 공지 없이 컴포넌트가 제거되면서, 사용자가 업데이트를 받는 순간 헤드셋이 인식되지 않게 됐다. 세 번째는 조용한 사업부 해체다. 공식 발표보다 인력 감축이 먼저 온다. Microsoft는 2023년 1월 관련 개발팀을 해체했다.

표 출처: ^[16] (본문 기준으로 재구성)

인용이 자주 어긋나는 대목을 짚어 둔다. Google Glass의 2013년 2월은 일반인 공모가 열린 시점이고 개발자 배포일이 아니다. HoloLens 2의 해상도로 돌아다니는 1440×936과 도당 약 20화소는 제조사 스펙이 아니다. Microsoft의 공식 하드웨어 문서는 2K 3 대 2 광학 엔진과 라디안당 2,500 광점 초과로 적으며 이는 도당 44화소 수준이다. 도당 20화소 미만은 디스플레이 분석가 Karl Guttag의 비판적 추정이고, Microsoft 측 주장으로는 47화소가 병기된다. 세 숫자는 출처 등급이 다르므로 한 문장에 섞으면 안 된다. Magic Leap의 누적 조달 35억 달러 이상과 사우디 국부펀드의 7억 5천만 달러도 2024년 8월 기준 회사 전체 수치이며, 특정 제품 한 종의 개발 투자로 읽으면 오해가 생긴다. 단일 투자로 확인되는 것은 2018년 3월 7일의 시리즈 D 참여분이다.

여기서 도출되는 실무 원칙은 단순하다. 전용 단자를 쓰는 가전은 제조사가 사라지면 충전기를 구할 수 없어 못 쓰게 되고, 표준 단자를 쓰는 가전은 아무 충전기나 꽂아 계속 쓴다. 표준에 붙은 자산은 벤더가 사라져도 살아남고, 벤더 개발도구와 벤더 클라우드에 붙은 자산은 같이 죽는다. 클라우드 앵커의 구 엔드포인트가 2023년 8월 31일 종료된 사례가 작은 예다. 조직이 가장 자주 묻는 질문은 이걸 몇 년이나 쓸 수 있는가다. 그 답의 근거는 하드웨어 사양표가 아니라 지원 종료 이력과 표준 준수 여부다.

플랫폼과 표준을 읽는 일은 결국 의존성 그래프에서 어느 노드가 남의 사업 판단에 달려 있는지를 세는 일이다. 기능이 멋진가는 그다음 질문이다. ^[16]