부록: Unity에서 Unreal로 옮겨 가는 용어와 개념 매핑

이 부록은 Unity를 이미 아는 독자를 위한 "번역 사전"입니다. 언리얼 엔진을 처음 열었을 때 가장 당황스러운 점은 기능이 없어서가 아니라, 익숙한 기능이 다른 이름과 다른 위치에 숨어 있다는 데 있습니다. Unity에서 GameObject, MonoBehaviour, Scene, Prefab, ScriptableObject, Coroutine으로 생각하던 습관을 언리얼의 Actor, Component, Level, Blueprint Class, Data Asset, Timer/Latent Action으로 연결하면 학습 속도가 눈에 띄게 빨라집니다.

다만 이 표를 볼 때 한 가지를 꼭 기억해야 합니다. 아래 대응 관계는 "번역"이지 "복제"가 아닙니다. Unity의 어떤 개념이 언리얼의 어떤 개념과 비슷하다고 해서 내부 구조와 사용 철학까지 완전히 같지는 않습니다. 특히 GameObject ↔ Actor, Prefab ↔ Blueprint Class, MonoBehaviour ↔ ActorComponent/Actor C++ Class는 처음에는 비슷해 보이지만, 프로젝트가 커질수록 차이가 크게 드러납니다. Epic도 Unity 개발자를 위한 언리얼 안내에서 Unity C# 경험자가 언리얼의 C++와 블루프린트 개념을 새 방식으로 이해해야 한다고 설명합니다.¹

가장 먼저 외울 20개 핵심 매핑

처음 언리얼을 배우는 Unity 개발자에게는 모든 용어를 한 번에 외우는 것보다, 자주 마주치는 개념부터 연결하는 편이 훨씬 효과적입니다. 아래 표는 언리얼 에디터를 열고 실습을 시작한 첫날부터 계속 보게 되는 핵심 용어입니다.

에디터 화면 용어 매핑

Unity에서 언리얼로 넘어오면 첫 번째 장벽은 코드가 아니라 화면입니다. 메뉴 이름과 패널 이름만 익숙해져도 불안감이 크게 줄어듭니다.

Unity에서는 Hierarchy에서 오브젝트를 고르고 Inspector에서 컴포넌트를 조정하는 흐름이 거의 모든 작업의 중심입니다. 언리얼도 비슷하게 Outliner에서 Actor를 선택하고 Details에서 편집하지만, 실제 작업은 Content Browser의 에셋, Blueprint Editor의 그래프, Level Viewport의 배치 작업 사이를 더 자주 오갑니다. 즉, Unity가 "씬 안의 오브젝트를 고쳐 가는 느낌"이라면, 언리얼은 "에셋으로 클래스를 만들고 레벨에 배치해 인스턴스를 조정하는 느낌"에 가깝습니다.

오브젝트 모델: GameObject 사고에서 Actor 사고로

Unity의 GameObject는 빈 그릇이고, Transform과 여러 Component를 붙여서 의미를 부여합니다. 언리얼의 Actor도 월드에 배치되는 기본 단위라는 점에서는 비슷하지만, 언리얼에는 Pawn, Character, Controller, GameMode처럼 게임 규칙을 나누어 담는 상위 프레임워크가 함께 존재합니다. 그래서 Unity식으로 "일단 빈 오브젝트 만들고 스크립트 붙이자"라고 접근하면 언리얼이 쓸데없이 복잡해 보입니다.

언리얼에서 특히 중요한 것은 Actor와 Component의 역할 분리입니다. 언리얼의 컴포넌트는 재사용 가능한 기능 단위이고, 트랜스폼을 가지는 컴포넌트는 SceneComponent, 실제 렌더링이나 충돌에 관여하는 컴포넌트는 PrimitiveComponent 계열로 볼 수 있습니다.² Unity에서도 컴포넌트 조합을 사용하지만, 언리얼에서는 Root Component와 Attach 구조가 Actor의 위치와 계층을 결정하기 때문에 더 의식적으로 설계해야 합니다.

라이프사이클: Awake, Start, Update를 다시 번역하기

Unity 개발자가 가장 자주 찾는 질문은 이것입니다. "언리얼의 Start는 뭐고, Update는 뭐지?" 짧게 답하면 Start는 대체로 Begin Play, Update는 Tick입니다. 하지만 실제로는 이것보다 조금 더 섬세합니다.

Unity에서는 Awake → OnEnable → Start → Update 흐름이 익숙합니다. 언리얼에서는 생성자, Construction Script, 컴포넌트 초기화, Begin Play, Tick, End Play가 각각 다른 책임을 가집니다. 생성자는 "이 Actor 클래스가 어떤 기본 부품을 가지는가"를 정하는 곳이고, Construction Script는 "에디터에서 배치될 때 어떤 모습으로 구성되는가"를 정하는 곳이며, Begin Play는 "이제 실제 플레이가 시작되었으니 게임 로직을 시작하라"는 신호에 가깝습니다.

실무적으로는 다음 기준을 기억하면 됩니다. 기본 컴포넌트 생성은 생성자에서, 에디터 배치에 따른 시각적 구성은 Construction Script에서, 런타임 참조 연결과 게임 시작 로직은 Begin Play에서, 매 프레임 꼭 필요한 처리만 Tick에서 다룹니다. AI에게 코드를 요청할 때도 "Begin Play에서 초기화하고 Tick은 쓰지 말고 Timer로 처리해줘"처럼 말하면 훨씬 좋은 답을 얻습니다.

Prefab, Blueprint, ScriptableObject의 차이

Unity의 Prefab에 가장 가까운 언리얼 개념은 Blueprint Class입니다. 하지만 이 둘은 느낌이 다릅니다. Prefab은 "미리 조립해 둔 오브젝트 묶음"이라는 인상이 강하고, Blueprint Class는 "에디터에서 만든 클래스"라는 성격이 강합니다. 블루프린트는 변수, 함수, 이벤트 그래프, 컴포넌트 구성, 기본값을 모두 가질 수 있습니다.

Unity에서 아이템 정보를 ScriptableObject로 만들었다면, 언리얼에서는 Primary Data Asset이나 Data Table을 먼저 떠올리면 됩니다. 아이템 개수가 적고 개별 에셋 편집이 중요하다면 Data Asset이 좋고, 엑셀처럼 대량 데이터를 다루고 싶다면 Data Table이 편합니다. AI에게 요청할 때도 "Unity의 ScriptableObject 기반 아이템 데이터 구조를 Unreal의 Data Asset으로 바꿔줘"라고 말하면 의도가 훨씬 선명해집니다.

입력 시스템: Input System에서 Enhanced Input으로

Unity의 새 Input System에 익숙하다면 언리얼의 Enhanced Input은 비교적 빨리 이해할 수 있습니다. 둘 다 "키보드 W를 눌렀다"보다 "Move 액션이 발생했다"는 방식으로 생각하게 해 줍니다.

Unity에서는 PlayerInput 컴포넌트를 GameObject에 붙여 입력을 받는 흐름이 많습니다. 언리얼에서는 보통 PlayerController나 Character에서 Enhanced Input을 설정하고, Mapping Context를 Local Player Subsystem에 추가합니다. 여기서 중요한 차이는 언리얼의 입력이 Controller, Pawn, Character 구조와 강하게 연결된다는 점입니다. 플레이어가 조종하는 대상이 바뀔 수 있고, 입력을 해석하는 주체와 실제 움직이는 Pawn이 분리될 수 있습니다.

카메라: Cinemachine 감각을 언리얼로 옮기기

Unity에서 Cinemachine을 사용했다면 "카메라를 직접 움직이기보다 카메라 시스템에 의도를 전달한다"는 감각이 있을 것입니다. 언리얼에도 비슷한 구성이 가능하지만, Cinemachine이라는 단일 패키지에 해당하는 것이 하나로 존재한다기보다 여러 기능을 조합합니다.

3인칭 게임에서 가장 자주 쓰는 조합은 Character → Spring Arm → Camera Component입니다. Spring Arm은 카메라 붐대처럼 동작해서 캐릭터와 카메라 사이의 거리, 충돌 회피, 회전 지연 등을 처리할 수 있습니다. Unity에서 카메라 Follow 스크립트를 직접 짜던 습관이 있다면, 언리얼에서는 먼저 Spring Arm으로 해결할 수 있는지 확인하는 편이 좋습니다.

물리와 충돌: Layer보다 Channel을 먼저 생각하기

Unity에서 충돌을 다룰 때는 Rigidbody, Collider, Layer, Physics Material을 많이 사용합니다. 언리얼에도 비슷한 요소가 있지만, 충돌 설정에서는 Collision Channel, Object Type, Trace Channel, Collision Preset이 매우 중요합니다.

Unity 개발자가 흔히 하는 실수는 언리얼에서도 태그와 레이어만으로 충돌을 해결하려는 것입니다. 언리얼에서는 Collision Preset을 잘 설계하는 것이 훨씬 중요합니다. 예를 들어 플레이어 총알이 플레이어 자신은 무시하고 적과 벽에는 반응해야 한다면, 태그 비교를 매번 하는 것보다 Projectile 채널과 Pawn, WorldStatic 응답을 명확히 나누는 편이 좋습니다.

애니메이션: Animator에서 Animation Blueprint로

Unity의 Animator Controller와 언리얼의 Animation Blueprint는 둘 다 상태 머신을 사용해 애니메이션을 전환합니다. 그러나 언리얼의 Animation Blueprint는 단순한 상태 전환 도구를 넘어, 애니메이션 포즈를 계산하는 전용 그래프 시스템에 가깝습니다.

Unity에서는 캐릭터 스크립트가 Animator 파라미터를 직접 세팅하는 구조를 자주 씁니다. 언리얼에서도 Character Blueprint가 속도, 공중 여부, 공격 상태 등을 Animation Blueprint에 전달하지만, 애니메이션 계산은 Anim Blueprint 쪽에서 분리해 관리하는 것이 일반적입니다. 이 분리를 이해하면 "캐릭터 로직은 Character에, 포즈 계산은 Anim BP에"라는 깔끔한 기준이 생깁니다.

AI와 내비게이션: NavMeshAgent에서 AIController로

Unity에서 NPC 이동을 만들 때는 NavMeshAgent를 붙이고 목적지를 지정하는 흐름이 익숙합니다. 언리얼은 조금 더 프레임워크가 강합니다. AI가 조종하는 Pawn이 있고, 그 Pawn을 AIController가 Possess하며, 판단은 Behavior Tree와 Blackboard로 나누어 관리하는 식입니다. Epic의 언리얼 AI 문서도 Behavior Tree, Blackboard, AI Perception, Environment Query System 같은 내장 시스템을 중심으로 AI 엔티티를 구성한다고 설명합니다.³

언리얼 AI를 처음 배울 때는 "적 캐릭터가 스스로 움직인다"라고 생각하지 않는 편이 좋습니다. 더 정확히는 "AIController가 Pawn을 조종한다"입니다. Unity에서는 Enemy GameObject에 EnemyAI 스크립트와 NavMeshAgent를 붙이는 방식이 자연스럽지만, 언리얼에서는 Pawn/Character, AIController, Behavior Tree, Blackboard를 나누어 생각해야 구조가 깨끗해집니다.

렌더링과 머티리얼: URP/HDRP 감각을 언리얼로 옮기기

Unity의 렌더링 경험은 Built-in, URP, HDRP 중 무엇을 사용했는지에 따라 크게 다릅니다. 언리얼은 기본적으로 고품질 렌더링 기능이 엔진에 깊게 통합되어 있으며, Lumen, Nanite, Virtual Shadow Maps, MegaLights 같은 기능을 프로젝트 설정과 에셋 설정에서 함께 다룹니다.

Unity Shader Graph를 써본 사람은 언리얼 Material Editor가 반갑게 느껴질 수 있습니다. 다만 언리얼에서는 Material과 Material Instance를 나누는 습관이 특히 중요합니다. 모든 색상이나 거칠기 변화를 새 Material로 만들기보다, 공통 Material을 만들고 Instance에서 파라미터만 바꾸면 관리와 성능 면에서 유리합니다.

UI, 사운드, 이펙트 매핑

게임 완성 단계에서 자주 마주치는 UI, 사운드, 이펙트 용어도 한 번에 정리해 두면 좋습니다.

Unity UI에서 Canvas와 RectTransform에 익숙한 개발자는 UMG의 Slot 개념에서 처음에 약간 멈칫할 수 있습니다. 언리얼 UI는 "부모 패널이 자식 위젯의 배치 규칙을 결정한다"는 감각이 강합니다. 버튼을 Canvas Panel에 넣었는지, Vertical Box에 넣었는지, Overlay에 넣었는지에 따라 위치와 크기 설정 방식이 달라집니다.

코드와 데이터 타입 매핑

C#에서 C++로 넘어갈 때 문법 자체보다 더 자주 막히는 것은 언리얼 특유의 타입과 매크로입니다. 언리얼 C++은 일반 C++ 위에 리플렉션, 에디터 노출, 블루프린트 연동을 위한 매크로 시스템을 얹은 형태입니다.

가장 헷갈리는 문자열 타입만 따로 정리하면 이렇습니다. FString은 일반적인 문자열 조작에 좋고, FText는 현지화가 필요한 사용자 표시 텍스트에 적합하며, FName은 이름 식별자처럼 빠른 비교가 필요한 곳에 자주 사용합니다. Unity에서 전부 string으로 처리하던 습관을 그대로 가져오면 언리얼 코드가 어색해집니다.

씬 관리와 월드 구조

Unity에서는 보통 Scene을 로드하고 언로드한다고 말합니다. 언리얼에서는 World, Level, Persistent Level, Sublevel, World Partition 같은 용어가 등장합니다.

Unity의 Scene은 게임 상태를 담는 큰 컨테이너처럼 쓰이는 경우가 많습니다. 언리얼의 Level도 비슷하지만, 게임 전체의 규칙은 GameMode, 플레이어 제어는 PlayerController, 영속 데이터는 GameInstance나 Subsystem에 두는 식으로 역할이 더 분리됩니다. 따라서 "이 데이터를 씬에 있는 매니저 오브젝트에 둘까?"라는 Unity식 질문은 언리얼에서는 "이 데이터가 Level에 속하는가, GameInstance에 속하는가, World Subsystem에 속하는가?"라는 질문으로 바뀝니다.

빌드, 패키징, 플랫폼 용어

프로젝트를 실행 파일로 만드는 단계에서도 용어가 달라집니다.

Unity에서는 빌드 버튼을 누르고 플랫폼 설정을 바꾸는 흐름이 비교적 단순하게 느껴집니다. 언리얼은 Cook, Stage, Package 같은 단계가 더 명시적으로 드러납니다. 처음에는 복잡하지만, 큰 프로젝트에서는 어떤 에셋이 어떻게 포함되고 어떤 플랫폼 설정이 적용되는지 추적하기 좋습니다.

AI 도구와 워크플로우 매핑

이 책의 핵심은 AI와 짝을 이루어 언리얼을 빠르게 흡수하는 것입니다. Unity에서 이미 Claude, ChatGPT, Cursor, Copilot, MCP 같은 도구를 써 봤다면 언리얼에서도 같은 사고방식을 가져갈 수 있습니다. 다만 AI에게 전달해야 하는 엔진 맥락은 달라집니다. Unity AI는 Unity 6.3 이상에서 에디터 내 AI 버튼을 통해 패키지를 설치하고 Unity Cloud 프로젝트와 연결하는 흐름을 안내하고 있으며,⁴ 언리얼 쪽은 블루프린트, C++, 플러그인, 외부 API를 조합해 AI 워크플로우를 구성하는 경우가 많습니다.

좋은 프롬프트는 단순히 "Unity의 X를 Unreal로 바꿔줘"에서 끝나지 않습니다. 어떤 언리얼 버전을 쓰는지, 블루프린트로 할지 C++로 할지, Tick 사용을 허용할지, 멀티플레이어를 고려하는지까지 함께 알려 주어야 합니다. 예를 들어 다음처럼 요청하면 AI의 답변 품질이 좋아집니다.

나는 Unity에서 3년 이상 개발했고, 지금 Unreal Engine 5.6을 배우고 있어.
Unity의 ScriptableObject 기반 아이템 시스템을 Unreal로 옮기고 싶어.
블루프린트 중심으로 설명하되, 나중에 C++로 확장하기 쉬운 구조를 원해.
Data Asset과 Data Table 중 무엇이 적합한지 비교한 뒤,
아이템 정의, 인벤토리 슬롯, UI 표시 흐름을 설계해줘.
Unity 용어와 Unreal 용어를 나란히 매핑해서 설명해줘.

이 프롬프트의 장점은 AI에게 "내가 이미 아는 세계"와 "지금 배우려는 세계"를 동시에 알려 준다는 데 있습니다. AI는 이 연결고리를 받았을 때 훨씬 덜 추상적이고, 더 실전적인 답을 줍니다.

1:1 대응하면 위험한 개념들

아래 개념들은 처음에는 대응표로 이해해도 되지만, 어느 순간 반드시 따로 다시 배워야 합니다. 여기서 오해가 생기면 언리얼 프로젝트 구조가 Unity를 어설프게 흉내 낸 모양이 됩니다.

Unity 개발자를 위한 빠른 검색표

마지막으로 실전에서 바로 찾기 좋은 형태로 한 번 더 압축해 보겠습니다. 막혔을 때 이 표에서 Unity 용어를 찾고, 오른쪽 언리얼 키워드로 문서나 AI에게 질문하면 됩니다.

이 부록을 쓰는 가장 좋은 방법

이 대응표는 한 번 읽고 외우는 자료가 아닙니다. 언리얼을 배우다가 막힐 때마다 Unity에서 내가 알고 있던 이름을 떠올리고, 이 표에서 언리얼 이름을 찾은 뒤, 그 키워드로 문서와 AI에게 질문하는 식으로 쓰면 됩니다.

예를 들어 "Unity에서는 ScriptableObject로 무기 데이터를 만들었는데 언리얼에서는 뭘 써야 하지?"라는 질문이 생기면, 먼저 Data Asset, Primary Data Asset, Data Table을 후보로 놓습니다. 그런 다음 AI에게 "세 방식의 차이를 Unity ScriptableObject와 비교해서 설명해줘"라고 묻습니다. 이때 AI는 단순히 코드를 생성하는 도구가 아니라, 이미 아는 개념과 새 개념 사이에 다리를 놓아 주는 학습 파트너가 됩니다.

언리얼을 빨리 배우는 사람은 모든 것을 처음부터 새로 외우지 않습니다. 이미 알고 있는 개념을 새 엔진의 언어로 번역하고, 번역이 어긋나는 지점만 집중해서 다시 배웁니다. Unity 경험은 버려야 할 짐이 아니라, 언리얼을 빠르게 흡수하게 해 주는 가장 강력한 발판입니다.

참고

¹Unity 개발자를 위한 언리얼 엔진에서 게임플레이 생성하기

²Unreal 에서 Actor 와 ActorComponent 의 개념 (vs. Unity 에서의 GameObject 와 비교)

³Artificial Intelligence in Unreal Engine

⁴Unity AI: AI 게임 개발 툴 및 RT3D 소프트웨어