HMD마다 OS가 다른 이유와 유니티 빌드가 서로 호환되지 않는 이유

3D 컨텐츠를 만들다보면 HMD 기기간 프로그램 호환이 안되는 걸 알 수 있습니다.

“메타 퀘스트에서 만든 유니티 빌드가 왜 갤럭시 XR에서는 실행되지 않을까?”
“같은 안드로이드 기반이라는데, 왜 서로 호환이 안 될까?”

메타 퀘스트, 갤럭시 XR, 애플 비전 프로처럼 HMD 종류가 늘어나면서
이제는 단순히 기기 이름을 아는 것보다, 각 디바이스가 속한 생태계와 구조를 이해하는 것이 훨씬 중요해졌습니다.

이 글에서는 HMD OS 구조부터, 유니티 빌드가 왜 서로 호환되지 않는지,
그리고 앞으로 개발자와 모델러가 어떻게 대응해야 할지까지 흐름 중심으로 정리해보겠습니다.

 

---

HMD는 전부 각자 OS를 쓸까?

결론부터 말하면 모든 HMD가 완전히 다른 OS를 사용하는 것은 아닙니다.

겉보기에는 기기가 매우 다양해 보이지만, OS 기준으로 보면 실제 구조는 생각보다 단순합니다.

• 몇 개의 OS 계열로 나뉘고
• 그 안에서 제조사별로 커스터마이징이 이루어지는 구조

즉, 기기 이름 = 완전히 새로운 OS는 아니라는 점이 핵심입니다.

---

HMD OS 구조를 크게 나누면

구분	대표 디바이스	OS 환경	비고
안드로이드 XR	메타 퀘스트, 갤럭시 XR, PICO	Meta Quest OS, Android XR	독립형 HMD 주류
PC VR	Valve Index, Vive	Windows + SteamVR	PC 의존
애플 계열	Apple Vision Pro	visionOS	독자 생태계
콘솔 종속	PS VR2	PS5 OS 기반	콘솔 전용

이제 중요한 건 같은 안드로이드 XR 계열인데 왜 서로 호환이 안 되느냐는 점입니다.

---

메타 퀘스트와 갤럭시 XR는 왜 서로 호환되지 않을까?

많이들 이렇게 생각합니다.

“둘 다 안드로이드 기반이면 유니티에서 한 번 빌드해서 같이 쓰면 되는 거 아닌가?”

하지만 실제로는 그렇지 않습니다.

 

---

겉으로는 같아 보여도 내부 구조는 다르다

메타 퀘스트와 갤럭시 XR는
기반 OS는 안드로이드지만, 플랫폼 계층이 완전히 다릅니다.

• 사용하는 XR SDK가 다르고
• 입력 시스템 구현 방식이 다르며
• 스토어와 배포 구조도 완전히 분리되어 있습니다

이 차이를 한 번만 비교해서 정리해보면 다음과 같습니다.

구분	메타 퀘스트	갤럭시 XR
OS	Meta Quest OS	Android XR
플랫폼 주도	Meta	Google + Samsung
XR SDK	Meta XR SDK	Android XR SDK
스토어	Meta Quest Store	Google Play 기반
생태계 방향	메타 중심	안드로이드 확장

---

유니티에서 만든 것 중, 어떤 건 되고 어떤 건 안 될까?

이 부분은 표보다 구조적으로 이해하는 게 더 중요합니다.

공통으로 가져갈 수 있는 영역

• 3D 모델 데이터 (FBX, GLB)
• 텍스처, 머티리얼
• 애니메이션
• 유니티 프로젝트 구조 자체
• OpenXR 기반으로 작성된 로직의 큰 틀

즉, 에셋과 기본 구조는 충분히 공유 가능합니다.

---

문제되는 영역

반대로 아래 요소들은 그대로 가져갈 수 없습니다.

• 메타 전용, 구글 전용 SDK 코드
• 컨트롤러 입력을 하드코딩한 로직
• 특정 디바이스 전용 기능
• 스토어 연동, 플랫폼 서비스 기능

이 차이를 요약하면 이렇게 정리할 수 있습니다.

구분	호환 여부	이유
에셋(모델, 텍스처)	가능	엔진 공통 자산
OpenXR 기반 구조	부분 가능	구현 차이 존재
플랫폼 SDK	불가	디바이스 종속
입력 하드코딩	불가	컨트롤러 구조 차이

핵심은
엔진 레벨은 공유, 플랫폼 레벨은 분기입니다.

---

그럼 호환되게 만들려면 어떤 접근이 필요할까?

실무에서는 다음과 같은 방식이 가장 현실적입니다.

• Unity 프로젝트는 공통 베이스로 유지
• OpenXR을 기준으로 전체 구조 설계
• 입력 시스템은 Action 기반으로 추상화
• 플랫폼 SDK는 조건 분기 처리
• 빌드는 디바이스별로 개별 생성

“하나의 프로젝트, 여러 개의 빌드” 구조입니다.

완전히 하나의 빌드로 모든 HMD를 커버하는 것은 어렵지만,
재작업 비용을 최소화하는 구조는 충분히 만들 수 있습니다.

---

모델러는 어떻게 대응해야 할까?

모델러 입장에서도 방향이 분명해지고 있습니다.

• 독립형 HMD 성능을 기준으로 폴리곤 관리
• 실시간 렌더링 기준 모델링
• LOD 대응 가능한 구조
• 특정 셰이더, 디바이스 기능 의존 최소화

특정 기기 전용 모델이 아니라, 범용 XR 자산 제작이 중요해지는 흐름입니다.

---

개발자는 어떤 기준으로 설계해야 할까?

개발자 역시 디바이스 중심 사고에서 벗어날 필요가 있습니다.

• 특정 HMD API에 과도하게 의존하지 않기
• OpenXR 중심 구조 유지
• 입력·트래킹·UI 계층 분리
• 배포 스토어 정책을 초기 단계부터 고려

이렇게 설계해두면 새로운 XR 디바이스가 등장하더라도 대응 비용을 크게 줄일 수 있습니다.

---

앞으로 XR 생태계는 어떻게 갈까?

현재 흐름을 보면 방향은 비교적 명확합니다.

• 기술 표준은 OpenXR 중심으로 통합
• 안드로이드 XR 계열은 계속 확장
• 하지만 스토어와 서비스는 더 분화
• 완전한 단일 생태계는 당분간 어려움

즉, 기술은 하나로 모이지만, 생태계는 나뉘는 구조로 갈 가능성이 큽니다.

---

 

이제 XR에서 중요한 질문은 “어떤 HMD를 쓰느냐”가 아니라,

“어떤 생태계를 이해하고 대응하느냐”입니다.

기기 이름에 흔들리기보다는

• OS 계열
• 플랫폼 구조
• 런타임과 배포 방식

이 세 가지를 기준으로 접근하시면 XR 콘텐츠 제작 방향이 훨씬 명확해질 것입니다.

이 시장이 커질수록 아마도, 스마트폰 OS처럼 점점 한 두개의 생태계로 좁아지지 않을까 생각합니다.