RealityKit과 공간 멘탈 모델

visionOS의 SwiftUI는 3D 공간 속의 윈도우를 제공합니다. RealityKit은 그 나머지 방 전체를 제공합니다. 차이는 멘탈 모델에 있고, 멘탈 모델이 곧 아키텍처입니다.

visionOS를 처음 접하는 SwiftUI 개발자는 iOS에서 만들던 것과 똑같은 형태를 만드는 경향이 있습니다. 즉 view들이 들어 있는 WindowGroup입니다. 결과물은 공간에 떠 있는 평평한 패널입니다. 패널은 많은 앱에서 충분합니다. visionOS가 추가하는 것은 패널을 둘러싼 방이고, 그 방이 바로 RealityKit의 영역입니다.

RealityKit은 3D 속의 SwiftUI가 아닙니다. 아키텍처는 차원만 다른 것이 아니라 형태 자체가 다릅니다. SwiftUI는 observation 시스템 위에 result-builder DSL을 얹은 값 타입 view 트리이며, 프레임워크의 역할은 현재 상태로부터 다음 렌더링을 계산하는 것입니다. RealityKit은 가상 entity들을 현실 세계의 기준점에 묶어주는 앵커들을 루트로 하는 scene graph를 가진 entity-component-system(ECS)이며, 프레임워크의 역할은 사용자와 세계가 움직이는 동안 3D scene을 유지하는 것입니다. 같은 Swift 프로젝트에서 둘을 동시에 사용할 수 있고, 둘 사이의 경계가 바로 대부분의 공간 디자인 실수가 일어나는 지점입니다.

이 글은 공간 멘탈 모델을 짚어 갑니다. 이 모델이 SwiftUI 윈도우와 다른 다섯 가지 구체적인 방식, 그리고 각 프레임워크가 언제 정답인지에 관한 라우팅 질문입니다.

TL;DR

• RealityKit은 entity-component-system(ECS)입니다. entity는 노드이고, component는 노드에 부착되는 타입이 있는 데이터이며, system은 특정 component 조합을 가진 entity들에 대해 로직을 실행합니다.
• 앵커는 가상 entity를 현실 세계의 기준점에 묶어 줍니다. RealityKit은 AnchoringComponent.Target(.world, .head, .hand(_:location:), .plane(...), .image(...), .referenceObject(...))을 통해 앵커링 타깃을 노출합니다. visionOS에서는 ARKit이 앵커 업데이트 스트림을 통해 보고하는 백킹 앵커 struct(WorldAnchor, HandAnchor, ImageAnchor, ObjectAnchor, PlaneAnchor)를 공급합니다.
• 3D scene은 view 트리가 아닙니다. 렌더 루프는 연속적이고, scene graph는 시간이 흐르면서 변형되며, 렌더링 레이어는 diff 기반이 아니라 GPU 기반(내부적으로 Metal)입니다.
• RealityView는 SwiftUI 브리지입니다. RealityKit scene을 SwiftUI view 트리 안에 배치하며, 경계는 단방향입니다(SwiftUI가 RealityKit을 호스팅하지만 그 반대는 아닙니다).
• 라우팅 규칙: 사용자가 윈도우를 원한다면 SwiftUI를 출시하세요. 사용자가 방을 원한다면 RealityKit을 출시하세요. 둘 다 필요한 앱은 RealityView를 SwiftUI 윈도우 안에 두고 두 부분이 명시적으로 협력한다는 사실을 받아들입니다.

SwiftUI 윈도우와 다른 다섯 가지 차이

패널 바깥에 무언가를 두는 순간 형태는 달라집니다. 다섯 가지 차이가 중요합니다.

1. View-Body-State가 아니라 Entity-Component-System

SwiftUI view는 body computed property와 property wrapper로 뒷받침되는 state를 가진 값 타입입니다.¹ 프레임워크는 state가 변할 때 body를 다시 실행하고, diff가 렌더러에 전달됩니다.

RealityKit entity는 scene graph 안에 자리잡은 참조 타입 객체입니다. component는 entity에 부착된 타입이 있는 struct입니다(ModelComponent, Transform, CollisionComponent, PhysicsBodyComponent, 그리고 직접 정의하는 커스텀 Component 타입).² system은 System 프로토콜을 따르는 타입이며, 프레임워크는 등록된 각 system을 프레임당 한 번씩 실행하고, System.update(context:)(보통 struct에서는 mutating)는 system이 자신의 쿼리에 매칭되는 entity들의 component를 읽고 쓰는 곳입니다.

import RealityKit

let cube = Entity()
cube.components.set(ModelComponent(
    mesh: .generateBox(size: 0.1),
    materials: [SimpleMaterial(color: .blue, isMetallic: false)]
))
cube.components.set(InputTargetComponent())
cube.components.set(CollisionComponent(shapes: [.generateBox(size: [0.1, 0.1, 0.1])]))

cube에는 body가 없습니다. cube에는 component의 집합이 있습니다. InputTargetComponent와 CollisionComponent를 추가하는 것이 cube가 제스처에 반응하게 만드는 일입니다. 이것들을 제거하면 제스처는 cube를 그대로 통과해서 그 뒤의 entity로 갑니다. PhysicsBodyComponent를 추가하는 것이 cube가 중력에 따라 떨어지게 만드는 일입니다. 제거하면 cube는 떠다닙니다. component의 구성이 entity의 동작을 결정합니다.

멘탈의 전환: SwiftUI에서는 화면에 무엇이 있어야 하는지를 state의 함수로 기술합니다. RealityKit에서는 entity가 무엇인지(그 component들)를 기술하고, 그것에 무슨 일이 일어날지는 system이 결정하게 둡니다.

2. 좌표가 아니라 앵커

SwiftUI view의 좌표계는 윈도우입니다. 0,0은 좌측 상단 모서리이고, 위치는 포인트 단위이며, view의 frame이 그 공간입니다. 윈도우가 곧 우주입니다.

RealityKit scene의 좌표계는 그 앵커에 따라 달라집니다. 앵커링 레이어는 두 얼굴을 가지고 있습니다. RealityKit의 AnchorEntity(AnchoringComponent.Target이 구동)는 entity를 그 위에 배치하는 대상이고, ARKit의 앵커 struct는 시스템이 해당 타깃을 현실 세계와 동기화 상태로 유지하기 위해 사용하는 백킹 데이터입니다.³

AnchorEntity나 AnchoringComponent 안에서 사용할 수 있는 RealityKit 앵커링 타깃은 다음과 같습니다.

• .world(transform:): transform으로 정의되는 현실 세계 공간상의 한 지점
• .head: 사용자의 머리 자세에 잠금됩니다. entity가 사용자의 시선을 따라옵니다
• .hand(_:location:): 특정 손 관절(손바닥, 손가락 끝, 손목 등)에 잠금됩니다
• .plane(...): 감지된 수평 또는 수직 표면(테이블, 벽, 바닥)에 잠금됩니다
• .image(...) / .referenceImage(...): 환경 안에서 인식된 2D 이미지에 잠금됩니다
• .referenceObject(...): 인식된 현실 세계의 3D 객체에 잠금됩니다

visionOS에서는 ARKit이 ARKitSession 앵커 업데이트 provider를 통해 전달되는 WorldAnchor, HandAnchor, ImageAnchor, ObjectAnchor, PlaneAnchor struct를 통해 백킹 앵커 데이터를 공급합니다. (Body tracking은 Apple의 body tracking 영역에서 iOS/iPadOS 전용입니다. visionOS는 .body를 RealityKit 앵커링 타깃으로 노출하지 않습니다.)

앵커는 scene을 “실제처럼” 만드는 요소입니다. 사용자의 테이블에 대한 .plane 타깃에 배치된 가상 체스판은 사용자가 그 주위를 걸어다녀도 테이블 위에 그대로 머무릅니다. .head 타깃 기준의 고정 좌표에 배치된 체스판은 사용자의 머리를 따라다니며 환각처럼 느껴집니다.

멘탈의 전환: 위치는 숫자가 아닙니다. 위치란 앵커가 무엇인지, 그리고 entity가 그 앵커를 기준으로 어디에 있는지입니다. 합리적인 앵커가 없는 가상 객체는 환각입니다. 앵커야말로 그 객체가 방에 속한다는 사실을 사용자에게 말해 주는 요소입니다.

3. Diff 기반이 아니라 연속적인 렌더 루프

SwiftUI는 state가 변할 때 렌더링합니다. 프레임워크는 다시 렌더링이 필요한 시점을 결정하고 최소한의 트리 변경을 계산합니다. 렌더링 사이에 화면은 정적입니다.

RealityKit은 프레임 기반의 시뮬레이션과 렌더링 루프를 구동합니다. 물리, 애니메이션 system, 입력 처리기가 entity의 transform과 component 값을 업데이트하면서 scene graph는 시간에 따라 변형되고, 렌더러(Metal 기반)는 매 프레임 활성 scene을 그립니다. 프레임 단위 로직은 System.update(context:)에 들어갑니다. 이 훅은 매 틱마다 scene을 변형하라는 프레임워크의 초대장입니다.⁴

멘탈의 전환: 시간이 scene의 일부입니다. 한 번 실행되는 SwiftUI view body는 괜찮습니다. RealityKit entity는 N+1, N+2, N+3 프레임에 무슨 일이 일어날지를 고려해야 합니다. 커스텀 System의 update(context:) 메서드는 프레임 단위 로직을 작성하는 곳입니다. update 안에서 변형하는 Component 값은 다음 패스에서 렌더러가 읽는 값입니다.

4. RealityView는 한 방향의 브리지입니다

SwiftUI view는 다른 SwiftUI view를 구성합니다. RealityKit entity는 다른 RealityKit entity를 구성합니다. 둘 사이의 경계는 RealityKit scene을 호스팅하는 SwiftUI view 타입인 RealityView입니다.⁵

import SwiftUI
import RealityKit

struct ContentView: View {
    var body: some View {
        RealityView { content in
            // Build the scene
            let cube = Entity()
            cube.components.set(ModelComponent(
                mesh: .generateBox(size: 0.1),
                materials: [SimpleMaterial(color: .blue, isMetallic: false)]
            ))
            content.add(cube)
        } update: { content in
            // Mutate the scene in response to SwiftUI state changes
        }
    }
}

make 클로저는 view가 처음 나타날 때 한 번 실행됩니다. update 클로저는 view가 의존하는 SwiftUI state가 변할 때마다 실행됩니다. 두 클로저 안에서 모두 content 매개변수를 통해 RealityKit scene에 접근할 수 있습니다. entity를 추가하고, transform을 변형하고, system을 등록합니다.

경계는 단방향입니다. SwiftUI가 RealityKit을 호스팅합니다. RealityKit은 SwiftUI를 호스팅하지 않습니다. SwiftUI subview가 부모 안에 렌더링되는 것처럼 SwiftUI view를 entity “안에” 넣어 3D scene의 일부로 렌더링되리라 기대할 수 없습니다. 예외는 attachments(RealityView의 attachments: 매개변수)입니다. 이름이 부여된 SwiftUI view를 선언하고, ViewAttachmentEntity 값으로 가져와서, 다른 entity처럼 3D scene 안에서 위치를 지정하고 크기를 조절합니다.⁵ attachments는 entity 안에 임베드된 SwiftUI view가 아닙니다. entity로 감싸진 2D SwiftUI 표면이고, 렌더러가 이를 3D 안에 배치할 수 있습니다. 기본적으로는 고정된 방향을 유지하며, 착용자를 향하게 하려면 attachment entity에 BillboardComponent를 부착하세요.

5. 3D에서의 제스처는 다릅니다

SwiftUI 제스처(.onTapGesture, DragGesture 등)는 화면 공간에서 작동합니다. 시스템은 손가락이 view를 기준으로 어디에 있는지 알며, 프레임워크는 2D 히트 테스트를 기반으로 디스패치합니다.

RealityKit 제스처는 scene 공간에서 작동합니다.⁶ 시스템은 사용자가 어디를 보고 있는지(시선 광선), 사용자의 손이 어디에 있는지(hand tracking 관절), 시선과 탭이 어떤 entity와 교차하는지를 압니다. 디스패치 모델은 “사용자가 이 entity를 보고 핀치했다”이며, 이것이 탭의 등가물입니다.

entity가 제스처를 받으려면 InputTargetComponent와, 히트 테스트 기하 형태를 정의하는 CollisionComponent가 필요합니다. InputTargetComponent가 없으면 entity는 제스처 시스템에 보이지 않습니다. CollisionComponent가 없으면 제스처 시스템은 히트 테스트할 형태가 없습니다. 둘 다 있어야 합니다.

멘탈의 전환: 제스처 타깃은 화면 영역이 아닙니다. 제스처 타깃은 입력에 명시적으로 옵트인한 3D entity입니다. scene의 나머지는 “사용자가 그대로 통과해서 볼 수 있는 장식”입니다.

SwiftUI만으로 충분한 경우

흔한 visionOS 앱은 RealityKit이 필요하지 않습니다. SwiftUI 단독이 정답인 세 가지 패턴.

공간 콘텐츠가 없는 윈도우 형태의 앱. 명상 타이머, 노트북, 설정 패널, 채팅 인터페이스. 앱은 2D 어포던스를 통해 읽거나 상호작용하는 정보입니다. WindowGroup에 넣고 평평하게 유지하는 것이 옳은 선택입니다. visionOS는 SwiftUI 윈도우를 시스템 크롬이 있는 떠다니는 유리 패널로 다룹니다. 사용자는 RealityKit 코드 한 줄도 작성하지 않아도 편안한 읽기 경험을 얻습니다.

공간에 평평한 패널들을 구성하는 멀티 윈도우 앱. 에디터, 터미널, 문서를 위한 별도 윈도우가 있는 코드 에디터. 사용자는 윈도우들이 3D 공간(왼쪽, 오른쪽, 뒤)에 배치되기를 원하지만, 각 윈도우 자체는 SwiftUI view입니다. 3D 배치는 OS의 일이고, 패널은 평평합니다.

문서 뷰어, 사진 갤러리, 비디오 플레이어. 사용자가 패널을 통해 소비하는 콘텐츠입니다. 패널이 렌더링 표면이고, 세 번째 차원은 단순히 방 안에서 패널의 공간적 위치일 뿐입니다.

규칙: 콘텐츠가 2D(텍스트, 이미지, 비디오, 컨트롤)라면 정답인 프레임워크는 SwiftUI입니다. 세 번째 차원은 패널이 배치되는 위치이지, 그 안에 렌더링되는 것이 아닙니다.

RealityKit이 필요한 경우

SwiftUI만으로 충분하지 않은 경우들입니다.

사용자가 주위를 걸을 수 있는 3D 콘텐츠. 사용자의 테이블 위 가상 객체(모델 자동차, 조각품, 건물). 객체에는 부피가 있고, 사용자는 그 주위를 움직일 수 있으며, 객체는 방과 올바르게 가려져야 합니다. 정답인 프레임워크는 .plane 타깃에 앵커링된 RealityKit입니다.

방에 반응하는 공간 UI. 현실 세계의 키보드 위에 떠 있는 버튼, 현실 세계 객체에 부착된 주석, 실제 벽을 따라 놓인 가상 줄자. UI의 위치는 윈도우의 좌표 공간이 아니라 세계 기하에 의해 결정됩니다. RealityKit 앵커가 그 결합을 수행하고, RealityView 안의 SwiftUI attachments가 2D 어포던스를 제공합니다.

연속적인 공간 시뮬레이션. 새 떼, 바닥을 굴러가는 공, 유체 시뮬레이션, scene 상태가 시간에 따라 진화하는 모든 것. 연속 렌더 루프가 정답인 도구입니다. SwiftUI의 diff 기반 렌더러는 프레임을 놓치거나 배터리를 낭비할 것입니다.

Hand tracking 상호작용. 잡기 위한 핀치, 양손 스케일링, 허공에서의 그리기. 입력 모델은 ARKit의 HandTrackingProvider(HandAnchor 업데이트 포함)와 .hand(_:location:) 앵커 타깃을 요구합니다. SwiftUI는 그 영역을 노출하지 않습니다.

Body tracked AR. 사용자의 자세를 가상 캐릭터에 미러링하기, 피트니스 앱을 위해 사용자의 신체 추적하기, 현실 세계 객체 인식하기. 캡처와 추론은 ARKit(RealityKit의 하위 레벨 동반자)에서 일어나고, RealityKit이 결과를 렌더링합니다.

규칙: 콘텐츠가 3D이고 방 안에 살아 있다면(부피가 있거나, 앵커링되거나, 시뮬레이션되거나, 손으로 구동되거나), 정답인 프레임워크는 RealityKit입니다. SwiftUI는 그 주위의 크롬입니다.

구성 패턴

대부분의 단순하지 않은 visionOS 앱은 결국 둘 다 사용하게 됩니다. 잘 출시되는 패턴.

1. 앱의 크롬(설정, 내비게이션, 리스트, 폼, 인스펙터 패널)은 SwiftUI 윈도우에 자리잡습니다.
2. 공간 scene(사용자가 조작하는 부피 콘텐츠)은 자체 윈도우 또는 볼륨 안에 있는 RealityView에 자리잡습니다.
3. 둘은 SwiftUI state를 통해 통신합니다. SwiftUI 패널의 버튼이 @State 불리언을 토글하고, RealityView의 update: 클로저가 그 불리언을 읽고 scene 안의 entity를 변형합니다.
4. SwiftUI에 표면화되어야 하는 RealityKit 측 state 변경은 RealityView의 make: 클로저가 등록하는 콜백(scene의 이벤트 publisher에 대한 subscribe(to:))을 통해 전달됩니다.⁷

struct GalleryView: View {
    @State private var selectedSculpture: SculptureID?

    var body: some View {
        HStack {
            // SwiftUI side: list of sculptures
            List(allSculptures) { sculpture in
                Button(sculpture.name) {
                    selectedSculpture = sculpture.id
                }
            }
            .frame(width: 300)

            // RealityKit side: 3D rendering of the selected sculpture
            RealityView { content in
                // Build initial scene
            } update: { content in
                guard let id = selectedSculpture else {
                    content.entities.removeAll()
                    return
                }
                // Mutate scene to show the selected sculpture
                presentSculpture(id, in: content)
            }
        }
    }
}

이 분리는 어떤 프레임워크가 어떤 일을 담당하는지에 대해 정직합니다. SwiftUI는 리스트, 버튼, 레이아웃, state를 담당합니다. RealityKit은 3D 렌더링, entity, 연속 시뮬레이션을 담당합니다. state는 단일 @State 값으로서 경계를 넘으며, 어느 프레임워크도 다른 쪽으로 손을 뻗지 않습니다.

제 스택에서 다르게 만들겠다고 생각하는 것들

공간 scene을 한 번 출시해 보면 인지하기 쉬워지는 세 가지 패턴.

앵커 우선, entity는 그다음. 기능을 설계할 때 기하 형태보다 앵커를 먼저 결정하세요. 사용자의 손에 앵커링된 가상 악기는 같은 악기가 테이블의 .plane 타깃에 앵커링된 것과는 다른 제품입니다. 앵커가 사용자와 객체의 관계를 결정하고, 기하 형태는 구현 세부 사항입니다.

서브클래스가 아니라 component. ChessPiece: Entity 같은 도메인 타입을 만들기 위해 Entity를 서브클래스화하고 싶은 유혹이 듭니다. 구성 패턴은 매번 상속을 이깁니다. 체스 말은 ChessPieceComponent(커스텀 데이터: 색상, 종류, 위치), ModelComponent(3D 메시), InputTargetComponent, CollisionComponent를 가진 Entity입니다. 새로운 동작은 새로운 component이지, 새로운 서브클래스가 아닙니다.

횡단 로직을 위한 system. 열 개의 entity가 같은 동작(중력, 충돌 응답, 오디오 감쇠, 제스처 state)을 필요로 한다면, 관련 component에 대해 작동하는 System을 작성하세요. system은 매칭되는 모든 entity에 걸쳐 프레임당 한 번 실행됩니다. 대안(각 entity에 로직을 두는 것)은 ECS 패턴이 회피하기 위해 발명된 n×n프레임 버그를 만들어 냅니다.

RealityView가 잘못된 답일 때

RealityView로 손을 뻗는 것이 잘못된 선택인 몇 가지 경우.

상호작용 없는 단일 3D 이미지. 정적 3D 로고나 제품 렌더. 대신 SwiftUI Model3D view를 사용하세요.⁸ Model3D는 “USDZ를 로드해서 표시한다”의 저렴한 길입니다. RealityView는 직접 만들고 변형하는 scene을 위한 것입니다.

간단한 AR 오버레이가 있는 iOS 앱. ARKit의 ARView(이전 영역)나 RealityKit의 iOS 측 ARView 통합은, AR 경험이 더 큰 iOS 앱 안의 한 기능일 때 종종 정답입니다. RealityView는 Swift와 SwiftUI 네이티브이고 SwiftUI 안에서 잘 동작합니다. 앱의 나머지가 UIKit일 때는 이전 ARView 워크플로가 더 간단할 수 있습니다.

패널 위 2D 드로잉. 화이트보드, 사진 주석 도구, 평평한 도형 에디터. 정답인 도구는 Canvas(SwiftUI의 Metal 기반 드로잉 표면)나 MetalView입니다. 3D 공간에 만드는 것이 아니라면 RealityView는 과합니다.

이 패턴이 visionOS 2+ 출시 앱에 의미하는 것

세 가지 핵심.

1. RealityKit과 SwiftUI는 구성됩니다. 합쳐지지 않습니다. 윈도우 형태의 크롬과 2D 어포던스에는 SwiftUI를, 방 형태의 3D 콘텐츠에는 RealityKit을 사용하세요. 경계는 RealityView이며, 경계는 단방향입니다.

2. 멘탈 모델은 ECS와 앵커입니다. entity는 그것을 구성하는 것입니다. 앵커는 entity가 사용자의 실제 공간과 어떻게 관계 맺을지를 결정합니다. (component, anchor) 쌍이 디자인 단위입니다.

3. 렌더 루프는 연속적입니다. 시간이 scene의 일부입니다. 프레임 단위 로직은 System.update(context:)에, state 변경 단위 로직은 RealityView.update:에 들어갑니다. 두 레이어를 섞는 것(SwiftUI body에 프레임 단위 로직을 작성하고, System.update에 state 기반 로직을 작성하는 것)이 가장 흔한 아키텍처 실수입니다.

전체 Apple Ecosystem 클러스터: Apple Intelligence를 위한 타입이 있는 App Intents; 크로스 LLM 에이전트를 위한 MCP 서버; 둘 사이의 라우팅 질문; 온디바이스 LLM과 Tool 프로토콜을 위한 Foundation Models; iOS 잠금 화면 state 머신을 위한 Live Activities; Apple Watch에서의 watchOS 런타임 계약; 프레임워크 기반에 대한 SwiftUI 내부; 시각 레이어를 위한 Liquid Glass 패턴; 크로스 디바이스 도달을 위한 멀티 플랫폼 출시. 허브는 Apple Ecosystem 시리즈에 있습니다. 더 넓은 iOS와 AI 에이전트 맥락은 iOS Agent Development 가이드를 참고하세요.

FAQ

RealityKit은 visionOS에서 SwiftUI를 대체하나요?

아닙니다. RealityKit과 SwiftUI는 구성됩니다. SwiftUI는 2D 윈도우, 컨트롤, 크롬을 처리하고, RealityKit은 현실 세계 기준점에 앵커링된 3D scene을 처리합니다. 대부분의 단순하지 않은 visionOS 앱은 둘 다 사용하며, RealityView가 RealityKit scene을 SwiftUI view 트리 안에 배치하는 브리지 역할을 합니다.

RealityView와 Model3D 중 무엇을 언제 사용해야 하나요?

단일 정적 3D 에셋(USDZ 파일, 단일 제품 렌더)을 표시하려면 Model3D를 사용하세요. 시간에 따라 3D scene을 만들거나 변형하려면(여러 entity, 물리, 제스처, hand tracking, 앵커링된 콘텐츠) RealityView를 사용하세요. Model3D는 저렴한 길이고, RealityView는 전체 ECS 영역입니다.

RealityKit에서 Entity와 Component의 차이는 무엇인가요?

entity는 scene graph의 노드입니다. component는 노드에 부착된 타입이 있는 데이터입니다. ModelComponent는 entity에 메시를 부여하고, InputTargetComponent는 제스처를 받을 수 있게 만들고, CollisionComponent는 히트 테스트 기하를 정의하고, PhysicsBodyComponent는 중력에 반응하게 만듭니다. 직접 정의하는 커스텀 Component 타입은 도메인 데이터를 담습니다. 동작은 상속이 아니라 구성입니다. entity의 동작은 그 component의 합입니다.

앵커는 무엇이고 왜 중요한가요?

앵커는 가상 콘텐츠를 현실 세계 기준점에 묶어 줍니다. 사용자의 머리, 손, 감지된 표면, 인식된 이미지, 인식된 객체, 또는 영구적인 세계 지점입니다. 앵커가 사용자와 entity의 관계를 결정합니다. .plane 타깃(테이블) 위의 가상 객체는 사용자가 주위를 걸어도 그 자리에 머무릅니다. .head 타깃 위의 가상 객체는 사용자의 머리를 따라옵니다. 올바른 앵커를 고르는 것이 공간 기능의 첫 디자인 결정입니다.

RealityKit은 visionOS뿐 아니라 iOS에서도 실행할 수 있나요?

네. RealityKit은 iOS, iPadOS, macOS, visionOS에 출시됩니다. ARKit이 구동하는 AR 경험은 RealityKit의 iOS 영역을 사용합니다. visionOS 영역은 iOS가 노출하지 않는 공간 특화 앵커 타입(머리, 손, 세계)을 추가합니다. 핵심 ECS 패턴은 공유됩니다.

References