📚 지식 노트

VR, AR, MR, XR

이름이 많지만 한 줄 위에 놓으면 정리된다. 1994년 Milgram 등은 가상성 연속체(reality–virtuality continuum)라는 선을 제안했다. 한쪽 끝은 아무것도 더하지 않은 실제 환경, 다른 끝은 모두 컴퓨터가 만든 가상 환경(VR)이다. 그 사이 전부가 혼합 현실(MR)이다. 실제 세상이 중심이고 가상 물체를 얹으면 증강 현실(AR), 가상 세계가 중심이고 현실의 일부(내 손, 책상)를 끌어오면 증강 가상(AV)이다.

제품 이름에서 쓰는 말은 이 정의와 조금 다르다. 업계에서는 VR 헤드셋이 카메라 영상으로 방을 보여 주며 가상 물체를 얹는 것을 흔히 MR이라 부르고, 이 모두를 묶어 XR(확장 현실)이라 한다. "공간 컴퓨팅"은 창과 앱을 화면이 아니라 방 안 공간에 놓고 쓰는 방식을 부르는 말이다. 이 노트에서는 렌더링·추적 원리가 거의 같으므로 구분이 필요할 때만 이름을 나눈다.

기기의 종류

기기는 두 질문으로 나눈다. 바깥 세상을 어떻게 보여 주는가(안 보여 줌, 카메라 영상을 화면에, 투명한 렌즈 너머 그대로), 그리고 계산을 어디서 하는가(PC, 헤드셋 안 칩)다. 카메라로 보여 주는 방식(패스스루)은 가상 물체를 완전히 불투명하게 덮을 수 있지만 세상이 화면 해상도와 카메라 지연을 거친다. 투명 렌즈(광학 투과)는 세상을 지연 없이 보지만, 빛을 더하는 방식이라 검은색을 그릴 수 없고(검정 = 투명) 밝은 곳에서 가상 물체가 옅어진다.

대표 기기 하나씩을 아래에 적었다. 2026년 10월에 각 출처를 열어 확인한 내용이고, 기기는 빨리 바뀌므로 갈래를 이해하는 예로만 본다.

6DoF와 3DoF

강체가 공간에서 움직일 수 있는 방식은 여섯 가지다. 세 축을 도는 회전(요·피치·롤)과 세 축을 따라가는 이동(앞뒤·좌우·위아래)이다. 회전만 재는 기기를 3DoF, 둘 다 재는 기기를 6DoF라 한다. 3DoF는 가속도계·자이로(IMU)만으로 되지만, 몸을 기울이거나 한 걸음 걸어도 장면이 따라오지 않아 눈과 몸이 어긋난다. 그래서 360° 영상처럼 고개만 돌리는 용도에 맞다. 요즘 헤드셋과 컨트롤러는 6DoF가 기본이다.

이동을 재려면 IMU만으로는 부족하다. 가속도를 두 번 적분하면 위치가 나오지만 작은 오차가 시간 제곱으로 불어나 금방 틀어진다. 그래서 바깥 기준(기지국이나 방의 모습)과 견줘 위치를 계속 바로잡는다. 다음 절이 그 방법이다.

인사이드아웃 추적과 SLAM

초기 PC VR은 방에 장치를 세워 위치를 쟀다. Valve Index의 Lighthouse 방식은 방 모서리의 기지국이 신호를 보내고 헤드셋·컨트롤러의 센서가 받아 위치를 푼다. 정확하지만 장치를 설치해야 하고 그 방에서만 쓴다.

요즘 독립형 헤드셋은 인사이드아웃 추적을 쓴다. 헤드셋에 붙은 카메라가 방의 모서리·무늬 같은 특징점을 보고, 그 점들이 화면에서 움직이는 모양으로 내 위치를 거꾸로 푼다. 처음 보는 방이면 지도가 없으므로 지도 만들기와 내 위치 찾기를 동시에 하는 SLAM(simultaneous localization and mapping)이다. Meta Quest 3는 추적 카메라 네 대로 광학 SLAM을 하고, 컨트롤러는 몸체의 적외선 LED를 카메라로 찾아 위치를 잰다. 카메라는 프레임 사이가 비고 IMU는 빠르지만 틀어지므로, 둘을 섞어(센서 융합) 빠르고 안 틀어지는 자세를 얻는다. SLAM의 원리는 로보틱스 노트의 SLAM 절, 특징점을 찾고 짝짓는 법은 컴퓨터 비전 노트의 특징점 절에 있다.

약점은 카메라가 볼 것이 없을 때다. 어두운 방, 아무 무늬 없는 흰 벽, 거울, 카메라 시야 밖(등 뒤·머리 위)으로 손을 뻗을 때 추적이 흔들린다.

손 추적과 눈 추적

손 추적은 같은 추적 카메라 영상에서 손을 찾아 손가락 관절 위치를 추정한다. 컨트롤러 없이 집고 누르고 가리킬 수 있지만, 버튼처럼 눌렸다는 촉감이 없고 손이 카메라 시야를 벗어나거나 서로 가리면 놓친다. 그래서 손 추적 UI는 누르는 대상을 크게 두고, 눌렸을 때 소리·빛으로 분명히 알려 준다.

눈 추적은 헤드셋 안쪽 카메라로 동공을 보고 시선 방향을 잰다. 쓰임은 두 가지다. 하나는 입력이다. Apple Vision Pro는 바라본 것을 고르고 엄지와 검지를 맞대는 동작(핀치)으로 누른다. 시선은 빠르지만 의도치 않게 이리저리 흔들리므로, 고르기는 시선으로 하고 확정은 손으로 나눈다. 다른 하나는 뒤에서 볼 포비티드 렌더링이다. 시선은 사람이 무엇에 관심을 두는지 드러내는 민감한 정보이기도 하다.

모션 투 포톤 지연과 타임워프

머리를 돌린 순간부터 그 움직임이 반영된 빛이 눈에 닿기까지의 시간을 모션 투 포톤 지연이라 한다. 센서를 읽고, 자세를 계산하고, 장면을 그리고, 화면이 그 그림을 내보내는 시간이 모두 쌓인다. 90 Hz면 그리기에만 프레임당 11.1 ms가 있고, 120 Hz면 8.3 ms로 준다. 이 지연 동안에도 머리는 돌므로 화면 속 세상이 머리를 늦게 따라와 미끄러지듯 보인다. 초당 100°로 고개를 돌릴 때 지연이 20 ms면 2°만큼 늦고, 20 PPD 화면에서는 약 40픽셀이 밀린다.

얼마나 짧아야 할까. 흔히 인용되는 기준은 약 20 ms로, John Carmack은 절대 지연이 대략 20 ms 아래면 대체로 느끼지 못한다고 썼다. 엄밀한 문턱이라기보다 오래 쓰인 설계 목표에 가깝다. 렌더링 한 프레임만으로 이 예산의 절반을 쓰므로, 헤드셋은 그리기를 빠르게 하는 것 말고 두 가지 꾀를 더 쓴다.

• 타임워프(리프로젝션): 화면에 내보내기 직전 최신 자세를 다시 읽어, 이미 그린 그림을 그 차이만큼 돌려 다시 투영한다. 머리 회전에 대한 지연이 렌더링 시간과 거의 무관해진다. Oculus는 이것을 렌더링과 따로 돌리는 비동기 타임워프로 앱이 프레임을 놓쳐도 회전이 끊기지 않게 했다. 다만 공식 설명대로 만능은 아니다. 돌리기만으로는 가까운 물체의 시차(머리 이동)와 장면 속 움직임을 고칠 수 없어, 프레임을 놓치면 그쪽은 여전히 덜컥인다.
• 예측: 빛이 나올 순간의 머리 자세를 지금의 속도로 미리 계산해 그 자세로 그린다. 예측은 근사라서 머리가 갑자기 멈추거나 방향을 바꾸면 틀리고, 남은 차이는 다시 리프로젝션이 메운다.

멀미

VR 멀미는 주로 감각 불일치로 설명한다. 눈은 "앞으로 달린다"고 보는데 속귀의 전정 기관은 "가만히 앉아 있다"고 느끼면, 뇌가 두 신호를 맞추지 못해 메스꺼움·어지러움·식은땀이 난다. 그래서 조이스틱으로 하는 인공 이동과 회전, 가속·감속, 사용자가 시키지 않은 카메라 움직임이 가장 큰 원인이다. 지연이 크거나 주사율이 낮아 화면이 머리를 늦게 따라오는 것, 앞 절의 덜컥임도 같은 불일치를 만든다.

대책은 불일치를 줄이는 것이다. 프레임을 꾸준히 지킨다(Microsoft는 최소 60 FPS, 기기가 지원하면 그 이상을 권한다). 이동은 사용자가 직접 시키게 하고, 사용자가 시키지 않은 위아래 움직임은 특히 피한다. 시야를 줄이는 비네트, 조종석처럼 움직이지 않는 기준 틀을 둔다. 사람마다 민감도가 크게 다르고 여러 번 쓰며 적응하기도 하므로, 편안함 설정을 고를 수 있게 하는 것이 기본이다.

스테레오 렌더링

사람은 두 눈이 조금 다른 자리에서 본 두 그림의 차이(양안 시차)로 깊이를 느낀다. 그래서 헤드셋은 장면을 한 번이 아니라 두 번, 두 눈 위치에 놓은 카메라 둘로 그린다. 두 카메라 사이 거리가 동공 간 거리(IPD)다. 성인 평균은 대략 62~64 mm이고 사람마다 50 mm대에서 70 mm대까지 퍼져 있어, 헤드셋은 렌즈 간격을 조절하거나 보정 과정에서 IPD를 잰다. IPD가 실제 눈과 어긋나면 보기 불편해진다.

두 눈이 한 물체를 볼 때 시선이 만나는 각(수렴각)은 가까울수록 크다. IPD 63 mm로 0.5 m 앞을 보면 7.2°, 10 m 앞은 0.36°뿐이다. 그래서 입체감은 손 닿는 거리에서 가장 강하고 멀리 갈수록 약해져, 먼 배경은 크기·가림 같은 단안 단서에 기댄다. 그리는 쪽에서는 같은 장면을 두 번 그리므로 CPU·GPU 부담이 그만큼 늘어난다. 투영·래스터화 자체는 컴퓨터 그래픽스 노트에 있다.

또 하나의 함정이 수렴-조절 충돌이다. 실제로는 눈이 모이는 거리와 초점을 맞추는 거리가 함께 움직이는데, 헤드셋 화면은 초점 거리가 고정돼 있다. 가상 물체가 30 cm 앞에 있어도 눈의 초점은 화면의 고정 거리에 맞춰야 해서 오래 보면 눈이 피로하다. Microsoft 지침이 콘텐츠를 1 m보다 가까이 오래 두지 말고, 앞뒤로 움직이는 물체를 조심하라고 하는 이유다.

렌즈 왜곡 보정

헤드셋은 눈앞 몇 cm의 작은 화면을 넓은 시야로 보이게 하려고 볼록 렌즈를 쓴다. 볼록 렌즈는 가장자리를 더 크게 늘이는 실패형(pincushion) 왜곡을 낸다. 곧은 격자를 그대로 보여 주면 가장자리가 휘어 늘어나 보인다. 그래서 렌더러는 그린 그림을 화면에 내보내기 전에 반대 방향인 술통형(barrel)으로 미리 줄여 둔다. 두 왜곡이 서로 상쇄되어 렌즈를 지난 뒤에는 다시 곧게 보인다.

왜곡은 보통 중심에서의 거리 r에 대한 다항식(r′ = r(1 + k₁r² + k₂r⁴ + …))으로 본뜨고, 계수는 렌즈마다 잰다. 미리 줄인 그림에서는 가장자리 픽셀이 눌려 촘촘해지므로, 원래 해상도로 그린 가장자리 픽셀 상당수가 버려진다. 이 낭비가 다음 절의 포비티드 렌더링이 노리는 곳 가운데 하나다. 렌즈는 색마다 굴절이 조금씩 달라 가장자리에 색 번짐도 생긴다. 카메라 사진의 렌즈 왜곡도 같은 꼴의 식으로 본떠 보정하며, 사진에서 3D를 되살리는 이야기는 컴퓨터 비전 노트의 3D 비전 절에 있다.

포비티드 렌더링

사람 눈이 또렷하게 보는 곳은 시선 둘레 좁은 범위(중심와)뿐이고, 주변 시야는 흐릿하다. 포비티드 렌더링은 이 점을 써서 시선 둘레만 제 해상도로 그리고 바깥은 거칠게 그린다. 눈 추적이 있으면 그 원을 시선을 따라 옮기고(동적), 없으면 렌즈 중심에 고정한다(고정 포비티드). PlayStation VR2, Meta Quest Pro, Apple Vision Pro는 눈 추적을 넣어 동적 방식을 쓴다.

구현 방법 하나는 화면 구역마다 셰이딩 빈도를 다르게 주는 것이다. 2×2 픽셀을 셰이딩 한 번으로 칠하면 그 구역 비용이 1/4이 된다. 아래 예처럼 구역을 나누면 비용이 원래의 5분의 1 아래로 떨어진다. 실제 절감은 구역 크기, 눈 추적의 정확도와 지연, 장면에 따라 크게 달라서, 시선이 빠르게 옮겨 갈 때 거친 구역이 눈에 띄지 않도록 여유를 둔다.

해상도와 PPD

헤드셋 해상도는 "한 눈 2000×2000"처럼 적지만, 체감 선명도는 그 픽셀을 얼마나 넓은 시야에 펴는지에 달렸다. 그래서 PPD(pixels per degree, 시야 1°에 든 픽셀 수)로 비교한다. 대략 가로 픽셀 수 ÷ 가로 시야각이다. 가로 2000픽셀을 100°에 펴면 20 PPD다. 27인치 QHD(2560픽셀) 모니터를 60 cm에서 보면 약 48 PPD라, 같은 글자도 헤드셋에서 훨씬 거칠게 보인다. 렌즈 왜곡 때문에 실제로는 가운데가 더 촘촘하고 가장자리가 성기다.

목표는 사람 눈이다. 1.0 시력(20/20)은 1분각(1/60°) 떨어진 두 점을 가르는 능력으로 정의되므로, 픽셀 하나를 1분각에 맞추려면 60 PPD가 필요하다. 시야를 넓히면 같은 패널에서 PPD가 떨어지므로, 시야와 선명도는 서로를 깎아 먹는 관계다. 모니터의 화면 원리와 스펙 읽는 법은 모니터 노트에 있다.

공간 UI 원칙

화면 UI는 사각형 안에서 끝나지만, 공간 UI는 사람의 목·눈·팔을 함께 설계해야 한다. Microsoft의 혼합 현실 편안함 지침이 수치로 잘 정리해 두었다.

• 거리: 콘텐츠는 1.25~5 m에 두는 것이 가장 편하고, 1 m보다 가까이 오래 두지 않는다. 40 cm부터는 흐리게 사라지게 하고 30 cm 안은 잘라 낸다.
• 각도: 수평선보다 10° 넘게 올려다보거나 60° 넘게 내려다보게 하지 않고, 목을 좌우 45° 넘게 돌리게 하지 않는다. 편히 쉬는 시선은 수평보다 10~20° 아래다. 자주 쓰는 것은 가로로 늘어놓고, 위아래 움직임은 드문 일에 남긴다.
• 머리에 붙은 UI를 피한다: 화면 구석에 고정된 HUD처럼 머리를 따라 1:1로 도는 UI는 불편하다. 몸을 따라 오되 머리가 일정 각도 넘게 돌았을 때만 따라 도는 방식(body-lock)을 쓴다.
• 팔: 손을 오래 들고 있게 하면 금방 지친다(공중에 든 팔이 무거워진다). 반복 제스처를 줄이고 음성 같은 다른 입력과 섞는다.

글자 크기는 픽셀이나 pt가 아니라 눈에 차지하는 각도로 정한다. 높이 = 2 × 거리 × tan(각도 / 2)이다. Microsoft가 사용자 조사로 정한 "편히 읽히는" 크기는 아래와 같다. 앞의 20 PPD 헤드셋이라면 0.6°는 겨우 12픽셀 높이라, 모니터보다 글자를 훨씬 크고 굵게 써야 한다. 가는 글꼴은 획이 떨려 보이므로 피한다.

이동 방식은 멀미와 직결된다. 텔레포트는 겨눈 곳으로 순간 이동해 눈에 흐름이 생기지 않아 편하지만, 갑자기 자리가 바뀌어 방향 감각을 잃기 쉽다. 짧게 화면을 깜빡이거나 공간 소리로 새 위치를 알려 준다. 연속 이동은 몰입감이 크지만 멀미를 가장 잘 일으킨다. 속도를 멈춤·걷기(약 1.4 m/s)·달리기(약 2.8 m/s)처럼 몇 단계로 고정하고, 가속은 짧고 드물게, 움직이는 동안 시야 가장자리를 가리는 비네트를 둔다. 회전은 부드럽게 돌리는 대신 일정 각도씩 끊어 도는 스냅 회전으로 흐름을 줄일 수 있지만, 이것도 순간 방향이 바뀌어 헷갈릴 수 있다. 어느 쪽이든 고를 수 있게 둔다.

사람의 지각·운동 한계 자체(피츠의 법칙, 응답 시간)는 HCI와 UX 노트, 게임 HUD와 메뉴 설계는 게임 UI 노트에서 이어진다.

개발 도구: OpenXR과 WebXR

예전에는 헤드셋 회사마다 SDK가 달라 앱을 기기마다 따로 옮겨야 했다. OpenXR은 Khronos가 만든 무료 공개 표준 API로, 앱은 OpenXR만 부르고 각 기기 회사의 런타임이 그 기기의 추적·화면 출력을 맡는다. 현재 판은 OpenXR 1.1이다. Meta, Valve, Google, Microsoft, Sony, HTC, Qualcomm 등이 런타임을, Unity·Unreal Engine·Godot·Blender 등이 엔진 쪽을 지원한다고 Khronos가 밝히고 있다.

웹에서는 WebXR Device API가 같은 역할을 한다. 페이지가 navigator.xr로 세션을 요청하면 브라우저가 헤드셋 화면과 자세를 넘겨준다. 세션 종류는 페이지 안에 그리는 inline, 헤드셋 화면을 독차지하는 immersive-vr, 그리고 별도 AR 모듈이 정의하는 immersive-ar가 있다. 바닥 높이 기준(local-floor)이나 방 경계(bounded-floor) 같은 기준 공간은 사용자 동의를 거친다. HTTPS 같은 보안 컨텍스트에서만 쓸 수 있고, 세션은 사용자의 클릭 같은 동작에 이어서 연다. 명세는 W3C 후보 권고 초안 단계이고 MDN은 실험적 기능으로 표시하므로, 브라우저 지원을 확인하고 쓴다.

애플 기기는 OpenXR 대신 자체 visionOS SDK를 쓴다. SwiftUI로 창을, RealityKit으로 3D 콘텐츠를 만들고, 손 추적 같은 ARKit 기능은 앱이 전체 공간(Full Space)을 차지하고 사용자 허락을 받았을 때 쓴다.

흔한 오해

• "해상도만 높으면 선명하다." 같은 픽셀도 넓은 시야에 펴면 PPD가 낮다. 렌즈 품질과 가장자리 왜곡도 체감 선명도를 깎는다.
• "평균 FPS가 높으면 된다." 한 프레임이라도 놓치면 덜컥임이 보인다. 평균보다 프레임 시간을 꾸준히 지키는 것이 중요하다.
• "타임워프가 있으니 프레임은 떨어져도 괜찮다." 타임워프는 머리 회전만 고친다. 가까운 물체의 시차와 움직이는 물체는 그대로 덜컥인다.
• "20 ms는 정확한 문턱이다." 흔히 인용되는 설계 목표다. 사람과 상황(빠른 고개 돌림, 밝은 장면)에 따라 느끼는 정도가 다르다.
• "멀미는 익숙해지면 다 사라진다." 적응하는 사람도 있지만 민감도는 사람마다 크게 다르다. 이동·회전 방식을 고를 수 있게 하는 것이 기본이다.
• "AR 안경은 무엇이든 그릴 수 있다." 광학 투과는 빛을 더하기만 해서 검은색과 어두운 그림자를 그릴 수 없고, 밝은 곳에서는 가상 물체가 옅어진다.
• "화면 UI를 그대로 띄우면 된다." 글자는 각도로 키우고, 목·팔이 편한 범위에 두고, 머리에 붙이지 않아야 한다.

핵심 자료

설계는 Microsoft·Meta의 지침, 지연과 렌더링의 원리는 Carmack의 글과 Oculus 블로그, 구현은 OpenXR·WebXR 명세에서 시작하면 된다.