입문 이후의 확장 경로 설계하기

첫 게임을 완성한 다음, 가장 위험한 순간

첫 게임을 완성하면 이상한 일이 벌어집니다. 분명히 기뻐야 하는데, 며칠 지나면 머릿속이 다시 복잡해집니다.

"이제 C++을 해야 하나?"

"멀티플레이어도 배워야 하지 않을까?"

"GAS가 실무에서 중요하다던데, 바로 들어가야 하나?"

"메타휴먼, VR, 모바일, PCG, 시네마틱, 플러그인 제작까지 다 해야 하나?"

언리얼 엔진의 무서운 점은 입문 장벽만 높은 것이 아닙니다. 입문을 넘은 뒤에도 갈림길이 너무 많습니다. 첫 화면을 여는 데 성공했고, 블루프린트로 게임 로직을 만들었고, 라이팅과 머티리얼을 만졌고, 패키징까지 해봤습니다. 그러면 이제 무엇이든 할 수 있을 것 같은 기분이 듭니다. 동시에 무엇부터 해야 할지 모르는 상태가 됩니다.

이 장의 목적은 그 혼란을 줄이는 것입니다. 입문 이후의 언리얼 학습은 "더 많이 공부하기"가 아니라 "어디로 갈지 정하기"에 가깝습니다. 언리얼은 게임 엔진이면서 동시에 실시간 3D 제작 플랫폼입니다. 그래서 모든 기능을 한꺼번에 배우려는 순간, 학습은 다시 늪이 됩니다. 반대로 자신의 목표 직무와 결과물을 먼저 정하면, 공부해야 할 기술의 우선순위가 선명해집니다.

첫 게임 완성은 결승선이 아니라 면허 취득에 가깝습니다. 이제 도로에 나갈 수 있습니다. 하지만 산길을 달릴지, 고속도로를 달릴지, 경주장에 들어갈지는 스스로 정해야 합니다.

기능이 아니라 목표 직무부터 고르기

입문 이후 가장 흔한 실수는 기능 목록을 공부 계획으로 착각하는 것입니다. C++, 네트워킹, GAS, 메타휴먼, VR, 모바일 최적화, 플러그인, 에디터 확장, 렌더링, 셰이더, AI, 시네마틱, PCG를 모두 적어놓고 하나씩 지우려고 합니다. 이 방식은 성실해 보이지만 오래가기 어렵습니다. 각각의 기술이 요구하는 배경지식과 프로젝트 성격이 다르기 때문입니다.

먼저 "나는 어떤 결과물을 만들 사람인가?"를 정해야 합니다. 이 책을 따라온 독자라면 크게 네 갈래를 생각해볼 수 있습니다.

여기서 중요한 것은 "하나만 영원히 선택하라"는 뜻이 아닙니다. 적어도 다음 4~8주 동안의 방향을 하나로 고정하라는 뜻입니다. 언리얼 학습 로드맵을 다룬 여러 자료에서도 작은 목표, 시간 제한, 명확한 결과물 정의가 초보자 탈락을 줄이는 핵심 원칙으로 반복해서 강조됩니다.¹ 실제로 "언리얼을 더 잘하고 싶다"는 목표는 너무 흐립니다. 반면 "6주 안에 2인 협동으로 문을 열고 보스를 잡는 데모를 만든다"는 목표는 무엇을 배워야 하는지 바로 드러납니다.

목표가 바뀌면 같은 기능도 다르게 보입니다. 예를 들어 C++은 게임플레이 프로그래머에게는 시스템 설계의 언어입니다. 멀티플레이어 개발자에게는 복제와 권한을 정확히 제어하는 도구입니다. 비게임 제작자에게는 반복 작업을 줄이는 플러그인이나 에디터 유틸리티의 기반이 될 수 있습니다. 그러니 기능을 먼저 고르지 말고, 만들 결과물을 먼저 고르세요.

4~8주 단위로 프로젝트를 쪼개는 법

입문을 마친 개발자에게 1년짜리 대작 계획은 위험합니다. 특히 AI와 함께 작업하면 초반 속도가 빨라져서 더 큰 착각에 빠지기 쉽습니다. Claude나 ChatGPT가 기획서도 써주고, 블루프린트 구조도 설명해주고, C++ 코드 초안도 만들어줍니다. 그러면 "이 정도면 오픈월드 액션 RPG도 가능하지 않을까?"라는 생각이 듭니다.

가능은 합니다. 다만 완성 가능성이 낮습니다.

이 단계에서는 4~8주 단위의 작은 프로젝트가 가장 좋습니다. 기간이 너무 짧으면 엔진의 깊이를 경험하기 어렵고, 너무 길면 완성 전에 지칩니다. 4주는 하나의 핵심 기능을 깊게 파기에 좋고, 8주는 작은 포트폴리오 결과물을 만들기에 좋습니다.

프로젝트를 설계할 때는 다음 네 문장을 먼저 채우면 됩니다.

• 나는 누구에게 보여줄 결과물을 만든다.

• 핵심 기능은 하나 또는 두 개만 선택한다.

• 완성 기준은 영상으로 설명 가능한 상태다.

• 마지막 주에는 새 기능을 넣지 않고 정리와 문서화만 한다.

예를 들어 게임플레이 프로그래머라면 "8주 안에 타깃 락온, 회피, 콤보 공격, 체력 UI가 있는 3D 전투 데모를 만든다"가 좋은 목표입니다. 멀티플레이어 개발자라면 "6주 안에 두 명의 플레이어가 같은 맵에 접속해 서로의 이동, 공격, 체력 변화를 볼 수 있는 데모를 만든다"가 좋습니다. 비게임 제작자라면 "4주 안에 건축 모델을 언리얼로 가져와 Lumen 조명, 카메라 시퀀스, 인터랙티브 문 열기 기능을 붙인 프레젠테이션을 만든다"가 적절합니다.

이런 작은 프로젝트는 학습 과부하를 줄여줍니다. 더 좋은 점은 실패하더라도 손실이 작다는 것입니다. 4주짜리 프로젝트에서 네트워크 구조가 꼬이면, 다음 프로젝트에서 구조를 바꾸면 됩니다. 1년짜리 프로젝트에서 같은 문제가 생기면 프로젝트 전체가 무너집니다.

Unity 개발자, 웹 개발자, 3D 아티스트의 다음 선택

이 책의 독자는 출발점이 서로 다릅니다. 그래서 입문 이후의 확장 경로도 같을 수 없습니다. 모두에게 같은 C++ 로드맵을 던지는 것은 친절하지 않습니다.

Unity에서 온 개발자라면 가장 먼저 해야 할 일은 "언리얼식 프레임워크를 C++로 다시 읽는 것"입니다. 이미 C#과 컴포넌트 기반 사고에 익숙하므로 문법 자체보다 엔진의 소유권, 생명주기, 리플렉션, 에셋 참조 방식이 중요합니다. Unity의 MonoBehaviour에서 자연스럽게 처리하던 일을 언리얼에서는 Actor, Component, Controller, GameMode, GameInstance, Subsystem 등이 나누어 맡습니다. 이 구조를 C++ 코드로 이해하면 블루프린트도 훨씬 명확해집니다.

웹이나 일반 프로그래밍에서 온 독자라면 "엔진의 시간 감각"을 잡는 것이 먼저입니다. 웹 서버는 요청이 들어오고 응답을 내보내는 흐름이 중심입니다. 반면 게임은 매 프레임 세계가 갱신됩니다. BeginPlay, Tick, 입력 이벤트, 물리 업데이트, 애니메이션 업데이트, 렌더링이 계속 맞물립니다. 따라서 C++로 들어가기 전에 작은 블루프린트 프로젝트를 여러 개 만들며 엔진 라이프사이클을 몸에 익히는 편이 좋습니다.

Blender, Maya, 영상, 건축 시각화 쪽에서 온 독자라면 프로그래밍을 무리하게 깊게 파기보다 "반복 가능한 인터랙션"부터 익히는 편이 좋습니다. 버튼을 누르면 조명이 바뀌고, 문이 열리고, 카메라가 이동하고, 캐릭터가 반응하는 수준이면 충분합니다. 여기서 블루프린트와 AI 어시스턴트가 큰 힘을 발휘합니다. 코드를 완벽히 이해하지 못해도, 구조를 질문하고 결과를 검증하는 습관을 들이면 제작 범위가 빠르게 넓어집니다.

세 그룹 모두에게 공통으로 필요한 것은 하나입니다. 튜토리얼을 더 보는 것이 아니라, 튜토리얼에서 배운 것을 자신의 프로젝트에 옮기는 연습입니다. 눈으로 본 지식은 쉽게 사라집니다. 내 프로젝트에서 한 번 깨진 지식은 오래 남습니다.

언리얼 C++은 문법 공부가 아니다

입문을 마치면 C++이 눈앞에 나타납니다. 언리얼 커뮤니티를 조금만 둘러봐도 "실무에서는 C++이 필요하다", "블루프린트만으로는 한계가 있다", "성능을 생각하면 C++을 해야 한다"는 말을 자주 듣습니다. 모두 어느 정도 맞는 말입니다. 하지만 여기서 함정이 있습니다.

언리얼 C++ 학습을 일반 C++ 문법 복습으로 시작하면 금방 지칩니다.

물론 포인터, 참조, 클래스, 상속, 템플릿, 스마트 포인터 같은 기본기는 중요합니다. 하지만 언리얼에서 초보자를 정말 혼란스럽게 만드는 것은 문법 자체가 아닙니다. UCLASS, UPROPERTY, UFUNCTION, GENERATED_BODY() 같은 매크로, 에디터에 노출되는 변수, 블루프린트에서 호출되는 함수, 가비지 컬렉션, 모듈 빌드, 헤더 도구, 리플렉션 시스템이 더 낯섭니다.

리플렉션은 프로그램이 자기 자신의 클래스, 변수, 함수 정보를 런타임이나 에디터에서 다룰 수 있게 하는 구조입니다. 언리얼에서는 이 리플렉션 덕분에 C++로 만든 클래스가 에디터 Details 패널에 나타나고, 블루프린트 노드로 호출되고, 직렬화되고, 네트워크 복제에도 참여합니다. 즉 언리얼 C++은 "C++ 문법 + 언리얼 객체 시스템"입니다. 둘 중 하나만 알아서는 실전에서 막힙니다.

추천하는 학습 순서는 다음과 같습니다.

처음부터 모든 시스템을 C++로 다시 만들 필요는 없습니다. 오히려 좋은 언리얼 개발자는 블루프린트와 C++의 경계를 잘 나눕니다. 빠르게 바뀌는 기획 값, 레벨별 연출, UI 연결, 간단한 이벤트 흐름은 블루프린트가 편합니다. 복잡한 상태 관리, 반복 호출되는 계산, 대규모 데이터 처리, 여러 블루프린트에서 공통으로 쓰는 기반 클래스는 C++이 좋습니다.

예를 들어 대시 기능을 생각해봅시다. 처음에는 블루프린트로 입력, 쿨다운, 이동 거리, 이펙트를 모두 구현합니다. 작동이 확인되면 C++에 UDashComponent를 만들고, 실제 판정과 쿨다운 계산을 옮깁니다. 이펙트 종류, 사운드, 카메라 흔들림, 입력 연결은 블루프린트에 남겨둡니다. 이렇게 하면 코드의 안정성과 블루프린트의 유연성을 함께 얻을 수 있습니다.

AI를 활용할 때도 질문을 바꿔야 합니다. "언리얼 C++ 알려줘"라고 묻지 말고, 다음처럼 엔진 구조 중심으로 물어보세요.

나는 블루프린트로 만든 대시 기능을 C++ Component로 옮기려 한다.
현재 구조는 Enhanced Input → BP_Character 이벤트 → Launch Character → Cooldown 변수다.
언리얼 5.6 기준으로 UActorComponent를 만들고,
쿨다운 계산은 C++에 두되 이펙트와 사운드는 블루프린트에서 설정할 수 있게 설계해줘.
UPROPERTY와 UFUNCTION 노출 방식도 함께 설명해줘.

이 질문에는 목표, 현재 구조, 엔진 버전, 역할 분담, 원하는 설명 범위가 들어 있습니다. AI가 좋은 동료가 되려면, 여러분이 먼저 좋은 기술 리더처럼 지시해야 합니다.

C++ 전환을 위한 6주 미니 프로젝트

C++을 제대로 익히려면 책이나 문서만 읽는 것으로는 부족합니다. 작은 프로젝트 하나를 정해 블루프린트와 C++을 오가야 합니다. 다음은 입문 이후 바로 시도하기 좋은 6주 계획입니다.

이 프로젝트의 목표는 C++로 거대한 게임을 만드는 것이 아닙니다. 언리얼 C++이 블루프린트를 대체하는 것이 아니라, 블루프린트의 뼈대를 튼튼하게 만드는 도구라는 감각을 얻는 것입니다.

멀티플레이어는 Replication부터, 매치메이킹은 나중에

멀티플레이어는 언리얼의 강력한 분야입니다. 하지만 입문 직후 가장 쉽게 무너지는 분야이기도 합니다. 이유는 간단합니다. 혼자 실행할 때는 모든 것이 내 컴퓨터 안에서 일어납니다. 멀티플레이어에서는 "누가 진짜 상태를 가지고 있는가?"가 모든 문제의 출발점이 됩니다.

멀티플레이어를 배울 때 처음부터 로비, 친구 초대, 매치메이킹, 전용 서버, 클라우드 배포, 안티치트까지 가면 안 됩니다. 먼저 Actor Replication과 RPC를 이해해야 합니다. Replication은 서버의 Actor 상태를 클라이언트에 동기화하는 기능입니다. RPC는 Remote Procedure Call의 약자로, 한 머신에서 다른 머신의 함수를 호출하는 방식입니다. 쉽게 말해 "서버가 모두에게 알려주는 값"과 "클라이언트가 서버에 요청하는 행동"을 구분하는 기술입니다.

추천 순서는 다음과 같습니다.

Unreal과 Unity의 멀티플레이어를 비교할 때 자주 언급되는 차이 중 하나는 Unreal이 엔진 레벨의 Replication과 Dedicated Server 흐름을 강하게 제공한다는 점입니다.² Unity 생태계에서 Photon, Mirror, Netcode for GameObjects 같은 선택지를 직접 조합하던 개발자라면, 언리얼의 기본 네트워크 모델이 처음에는 무겁게 느껴질 수 있습니다. 하지만 FPS, 액션, PC·콘솔 중심 프로젝트에서는 이 내장 구조가 큰 장점이 됩니다.

멀티플레이어 6주 프로젝트는 단순해야 합니다. 예를 들어 "두 명이 접속해 서로를 보고, 발사체를 쏘고, 체력이 줄고, 죽으면 리스폰한다" 정도면 충분합니다. 여기서 중요한 것은 재미가 아니라 권한 구조입니다. 클라이언트에서 총알을 맞았다고 우기면 안 됩니다. 서버가 판정하고, 클라이언트는 결과를 받아 보여줘야 합니다. 이 원칙을 몸에 익히면 이후 세션, 매치메이킹, 전용 서버로 넘어갈 준비가 됩니다.

AI에게 멀티플레이어를 질문할 때는 반드시 "서버 권한 기준으로"라는 말을 넣으세요.

언리얼 5.6 멀티플레이어 프로젝트에서 서버 권한 방식으로 발사체 공격을 만들고 싶다.
클라이언트는 입력만 보내고, 서버가 발사체 Spawn과 데미지 판정을 수행해야 한다.
Actor Replication, Server RPC, Multicast RPC가 각각 어디에 필요한지 단계별로 설명해줘.
블루프린트 기준으로 먼저 설명하고, C++로 옮길 경우 클래스 구조도 제안해줘.

이런 질문은 AI의 답변을 훨씬 안전하게 만듭니다. 멀티플레이어에서 잘못된 예제는 겉으로는 작동하지만 구조적으로 위험합니다. 특히 클라이언트가 직접 체력을 줄이거나 아이템 획득을 확정하는 방식은 치트와 동기화 문제의 출발점이 됩니다.

GAS는 작은 전투 프로토타입에서 검증하기

GAS, 즉 Gameplay Ability System은 언리얼에서 능력, 상태, 버프, 디버프, 스탯, 태그 기반 전투 시스템을 구조적으로 만들기 위한 강력한 프레임워크입니다. 많은 실무 프로젝트와 포트폴리오에서 GAS 경험을 높게 평가합니다. 공개된 언리얼 포트폴리오 예시에서도 GAS, Gameplay Tags, Enhanced Input, UMG, AI, DataTable 등을 함께 묶어 전투 시스템과 웨이브 구조를 설명하는 경우를 볼 수 있습니다.³

하지만 GAS는 입문 직후 바로 삼키기에는 큽니다. 용어부터 낯섭니다. Attribute는 체력, 마나, 공격력 같은 수치입니다. Gameplay Tag는 State.Stunned, Ability.Dash, Weapon.Sword처럼 상태와 분류를 표현하는 이름표입니다. Gameplay Ability는 대시, 공격, 회복, 스킬처럼 실행 가능한 능력입니다. Gameplay Effect는 체력 감소, 이동 속도 증가, 독 데미지처럼 수치를 바꾸는 효과입니다.

이 개념들을 문서로만 읽으면 머리가 아픕니다. 작은 전투 프로토타입으로 시작해야 합니다.

첫 GAS 프로젝트의 범위는 이렇게 제한하는 것이 좋습니다.

• Attribute는 Health와 Stamina만 둔다.

• Gameplay Tag는 공격 가능, 회피 중, 기절 상태 정도만 둔다.

• Ability는 기본 공격, 대시, 회복 하나씩만 만든다.

• 적은 한 종류만 둔다.

• UI는 체력바와 스태미나바만 연결한다.

이 정도만 해도 GAS의 핵심 흐름을 경험할 수 있습니다. 입력이 Ability를 활성화하고, Ability가 Effect를 적용하고, Effect가 Attribute를 바꾸고, Attribute 변화가 UI에 반영됩니다. 이 흐름을 이해한 뒤에야 콤보, 장비, 스킬 트리, 네트워크 복제, 예측 처리로 확장할 수 있습니다.

GAS를 배울 때 AI에게 "GAS 전체 구조 설명해줘"라고 묻는 것은 좋지 않습니다. 답변이 길고 추상적이기 쉽습니다. 대신 작게 잘라야 합니다.

언리얼 GAS를 처음 적용하려 한다.
목표는 Health와 Stamina만 가진 1인칭 또는 3인칭 전투 프로토타입이다.
기본 공격은 Stamina를 10 소모하고, 적에게 20 데미지를 준다.
필요한 AttributeSet, Gameplay Tag, Gameplay Ability, Gameplay Effect를 최소 구성으로 설계해줘.
블루프린트와 C++ 중 무엇을 어디에 두면 좋은지도 알려줘.

GAS는 "멋져 보이는 실무 기술"이 아니라 "복잡해질 전투 시스템을 견디기 위한 구조"입니다. 아직 전투 시스템이 복잡하지 않다면 GAS를 쓰지 않아도 됩니다. 반대로 상태, 스킬, 장비, 버프, 네트워크가 얽히기 시작했다면 GAS를 검토할 때입니다.

XR, 모바일, 콘솔은 플랫폼 제약을 먼저 배운다

XR과 모바일은 화려해 보이지만, 사실 가장 먼저 배워야 할 것은 제약입니다. PC에서 120프레임으로 잘 돌아가는 장면도 VR 헤드셋에서는 멀미를 유발하거나 프레임을 유지하지 못할 수 있습니다. 모바일에서는 메모리, 발열, 배터리, 입력 방식, 패키지 용량이 문제가 됩니다. 콘솔은 성능만이 아니라 인증, 플랫폼 SDK, 저장 데이터, 네트워크 정책 같은 현실적인 절차가 따라옵니다.

XR을 시작한다면 OpenXR과 VR Template부터 확인하는 것이 좋습니다. Android XR 문서에서도 Unreal Engine을 활용해 OpenXR 표준과 VR 템플릿 기반으로 초기 설정을 진행하는 흐름을 안내합니다.⁴ 여기서 OpenXR은 여러 XR 기기에서 공통으로 사용할 수 있는 표준 API라고 이해하면 됩니다. 특정 기기 전용 기능은 나중에 붙이더라도, 처음에는 표준 흐름으로 손을 익히는 편이 안전합니다.

XR 4주 프로젝트의 목표는 "VR 게임"이 아니라 "VR 상호작용 데모"가 적절합니다. 예를 들어 한 방 안에서 물체를 집고, 버튼을 누르고, 문을 열고, UI를 바라보며 선택하는 정도면 충분합니다. 이 작은 데모에서 이미 입력, 카메라, 손 컨트롤러, 충돌, UI, 성능 문제가 모두 등장합니다.

모바일 4주 프로젝트라면 기존 미니게임을 모바일로 옮기는 것이 좋습니다. 새 게임을 만들지 마세요. 이미 완성한 프로젝트를 터치 입력으로 바꾸고, 해상도와 UI 스케일을 조정하고, 머티리얼 복잡도를 줄이고, 패키징과 기기 테스트를 해보는 것이 훨씬 실전적입니다.

콘솔은 개인 입문자가 바로 접근하기 어려운 영역입니다. 개발자 등록, SDK, 인증 절차가 필요하기 때문입니다. 따라서 콘솔을 목표로 한다면 먼저 PC 게임패드 대응, 저장 시스템, 해상도 옵션, 성능 옵션, 입력 리바인딩처럼 콘솔 친화적인 기본기를 준비하는 편이 좋습니다.

XR·모바일·콘솔 경로에서 AI는 코드 생성보다 체크리스트 작성에 더 유용합니다.

내 언리얼 5.6 3D 액션 미니게임을 Meta Quest 또는 Android XR 스타일의 VR 상호작용 데모로 줄이려 한다.
목표는 4주 안에 방 하나, 집기 상호작용, 버튼 UI, 문 열기 기능을 구현하는 것이다.
성능, 입력, UI, 멀미 방지 관점에서 체크리스트를 만들어줘.
각 항목마다 언리얼에서 확인해야 할 설정도 알려줘.

플랫폼 개발은 "기능을 더하는 일"보다 "불필요한 것을 덜어내는 일"에 가깝습니다. 이 감각을 빨리 익힐수록 프로젝트가 현실적으로 변합니다.

비게임 분야로 확장하기: 언리얼은 게임 엔진을 넘어선다

언리얼을 배우는 이유가 꼭 게임일 필요는 없습니다. 실시간 렌더링, 고품질 라이팅, 카메라, 시퀀서, 메타휴먼, 대규모 씬 처리 기능은 다양한 산업에서 쓰입니다. 특히 3D 아티스트나 영상 제작자, 건축 시각화 작업자라면 게임 로직보다 장면 구성과 인터랙션을 중심으로 확장하는 편이 자연스럽습니다.

비게임 분야는 크게 네 갈래로 나눌 수 있습니다.

디지털 휴먼 경로에서는 캐릭터의 사실감보다 "상호작용의 설득력"이 중요합니다. 메타휴먼이 아무리 실제 사람처럼 보여도, 질문에 늦게 반응하거나 시선이 어색하거나 표정이 고정되어 있으면 금방 인공적으로 느껴집니다. 따라서 대화 API 연결, 애니메이션 상태, 표정, 카메라 구도, UI 피드백을 함께 다뤄야 합니다.

버추얼 프로덕션 경로에서는 게임 플레이보다 샷 구성이 중요합니다. 카메라 렌즈, 초점 거리, 조명 변화, 시퀀서 타임라인, 렌더 출력 설정을 익혀야 합니다. 이 분야에서는 "플레이 가능한 게임"보다 "30초짜리 완성도 높은 영상"이 더 강한 포트폴리오가 될 수 있습니다.

건축 시각화는 언리얼의 실시간 조명 장점을 바로 체감할 수 있는 분야입니다. 낮과 밤을 바꾸고, 조명을 켜고 끄고, 재질을 변경하고, 카메라 북마크로 공간을 이동하는 기능만 있어도 클라이언트에게 강한 인상을 줄 수 있습니다.

시뮬레이션과 디지털 트윈은 더 기술적입니다. 데이터가 들어오고, 언리얼 장면이 그 데이터를 시각적으로 표현해야 합니다. 처음부터 실제 센서나 서버와 연결하지 않아도 됩니다. CSV나 JSON 파일을 읽어 공장 라인의 온도, 건물의 혼잡도, 차량의 이동 경로를 시각화하는 데모부터 시작하면 됩니다.

5.7 로드맵 기능은 '당장 필수'가 아니라 '추적 대상'이다

언리얼은 빠르게 변합니다. UE 5.7 로드맵에서는 PCG, Motion Design, Substrate Materials, First-person Rendering 등이 Production Ready로 이동하고, MegaLights는 Beta 단계로 올라가며 여러 지원 범위가 확장될 것으로 소개되었습니다. 또한 에디터 안에서 질문, 코드 생성, 단계별 안내를 받을 수 있는 실험적 AI Assistant도 예고되었습니다.⁵

이런 소식을 보면 마음이 급해집니다. "지금 당장 PCG를 배워야 하나?", "Substrate를 모르면 뒤처지는 건가?", "MegaLights가 Beta면 기존 라이팅 공부는 의미 없나?" 같은 질문이 생깁니다.

입문을 막 끝낸 단계라면 답은 간단합니다. 당장 필수는 아닙니다. 다만 자신의 분야와 연결되는 기능은 추적해야 합니다.

PCG는 Procedural Content Generation의 약자로, 규칙을 기반으로 지형, 식생, 오브젝트 배치 등을 자동 생성하는 흐름입니다. 오픈월드, 건축 시각화, 시뮬레이션에 관심 있다면 추적 가치가 큽니다. Motion Design은 그래픽 영상, 방송, 브랜드 콘텐츠, 모션그래픽 쪽에 가깝습니다. Substrate는 머티리얼 표현력을 확장하는 렌더링 기술이므로 테크니컬 아티스트나 고급 머티리얼 작업자에게 중요합니다. MegaLights는 많은 동적 라이트를 다루는 장면에서 매력적이지만, 아직 Beta 성격의 기능이라면 프로젝트의 핵심 의존성으로 삼기보다 실험 브랜치에서 테스트하는 편이 안전합니다.

새 기능을 대하는 기준은 세 가지입니다.

• 내 다음 4~8주 프로젝트에 직접 필요한가?

• 기존 방식보다 문제를 명확히 줄여주는가?

• 버전 변경이나 기능 변동을 감당할 여유가 있는가?

세 질문에 모두 "예"라고 답할 수 있을 때만 새 기능을 본격 도입하세요. 그렇지 않다면 북마크해두고, 샘플 프로젝트에서 1~2일 정도 실험하는 것으로 충분합니다. 최신 기술을 아는 것과 프로젝트를 완성하는 것은 다른 능력입니다. 포트폴리오에서는 대개 후자가 더 강합니다.

학습 리소스는 '적용 과제'와 함께 써야 한다

언리얼 학습 자료는 많습니다. 문제는 자료가 부족한 것이 아니라, 자료를 본 뒤 내 프로젝트가 그대로라는 점입니다. Epic Developer Community Learning에는 Epic Games와 커뮤니티가 만든 튜토리얼, 강의, 데모가 모여 있어 공식 학습 출발점으로 활용하기 좋습니다.⁶ 공식 문서, 샘플 프로젝트, 포럼, 유료 강의까지 더하면 공부할 자료는 끝이 없습니다.

하지만 자료를 소비하는 방식이 바뀌어야 합니다. 튜토리얼 하나를 보기 전에 반드시 "이걸 보고 내 프로젝트에서 무엇을 바꿀 것인가?"를 정하세요.

예를 들어 Enhanced Input 강의를 들었다면, 강의 프로젝트에서 끝내지 말고 여러분의 미니게임 입력 구조를 바꿔야 합니다. Lumen 최적화 글을 읽었다면, 내 맵에서 GPU 프로파일링을 해보고 조명 비용을 기록해야 합니다. GAS 튜토리얼을 봤다면, 예제 캐릭터가 아니라 내 캐릭터의 체력과 스태미나에 붙여야 합니다.

AI에게도 같은 원칙을 적용할 수 있습니다. "이 문서 요약해줘"에서 끝내지 말고, "이 문서의 내용을 내 프로젝트 구조에 적용할 체크리스트로 바꿔줘"라고 요청하세요.

아래 언리얼 공식 문서 내용을 읽고,
내 프로젝트 BP_PlayerCharacter, BP_Enemy, WBP_HUD 구조에 적용할 작업 목록으로 바꿔줘.
각 작업은 30분~2시간 안에 끝나는 단위로 쪼개고,
작업 후 확인 방법도 함께 적어줘.

학습의 단위는 영상 시간이 아니라 프로젝트 변화입니다. 3시간짜리 강의를 봤는데 프로젝트가 그대로라면 학습은 아직 끝나지 않았습니다. 20분짜리 문서를 읽고 내 프로젝트의 구조가 개선되었다면 그것이 진짜 학습입니다.

포트폴리오는 실행 파일이 아니라 설명 가능한 자산이다

첫 미니게임을 완성했다면 이제 그것을 포트폴리오 자산으로 바꿔야 합니다. 여기서 많은 입문자가 실수합니다. 실행 파일 하나, 스크린샷 몇 장, "언리얼로 만든 액션 게임입니다"라는 한 줄 설명으로 끝냅니다. 보는 사람은 알 수 없습니다. 무엇을 직접 만들었는지, 어떤 문제를 해결했는지, 어떤 기술적 판단을 했는지, AI가 어디까지 도와줬고 본인은 무엇을 검증했는지 드러나지 않습니다.

포트폴리오는 결과물만이 아니라 사고 과정을 보여주는 문서입니다. 특히 AI 시대에는 더 그렇습니다. 이제 단순히 "만들었다"는 사실만으로는 부족합니다. AI가 만들어준 것을 붙인 사람인지, AI를 활용해 구조를 설계하고 검증한 사람인지 구분되어야 합니다.

최소 구성은 다음과 같습니다.

README는 단순 소개문이 아닙니다. 기술 면접관이나 협업자가 빠르게 읽고 "이 사람은 구조를 생각하면서 만들었구나"라고 느끼게 해야 합니다. 다음 흐름을 추천합니다.

프로젝트 소개
- 어떤 게임인지 한 문단으로 설명

핵심 구현
- 입력 처리
- 전투 시스템
- AI 또는 적 행동
- UI
- 저장, 데이터, 최적화 중 해당 항목

기술적 의사결정
- 왜 블루프린트로 구현했는지
- 왜 일부 기능을 C++로 옮겼는지
- 어떤 구조를 버리고 어떤 구조를 선택했는지

문제 해결 사례
- 가장 어려웠던 버그 2~3개
- 로그와 프로파일러를 어떻게 활용했는지

AI 활용 방식
- 사용한 도구
- 대표 프롬프트
- 그대로 쓰지 않고 어떻게 검증했는지

AI 협업 기록을 공개하는 것이 어색할 수 있습니다. 하지만 잘 정리하면 오히려 강점이 됩니다. "Claude가 만들어줬습니다"가 아니라 "Claude에게 세 가지 설계를 제안받았고, 이 중 두 번째 방식은 Replication 구조상 문제가 있어 제외했으며, 최종적으로 서버 권한 방식으로 수정했습니다"라고 쓰면 개발자의 판단력이 드러납니다.

플레이 영상은 1~2분이면 충분합니다. 처음 10초 안에 가장 멋진 장면을 보여주세요. 이후 핵심 기능을 자막으로 짧게 설명합니다. 마지막에는 GitHub 주소나 기술 문서 링크를 보여줍니다. 포트폴리오를 보는 사람은 바쁩니다. 긴 소개보다 빠른 이해가 중요합니다.

AI 시대의 포트폴리오: 프롬프트보다 검증이 중요하다

AI와 함께 만든 프로젝트를 포트폴리오에 넣을 때 가장 중요한 단어는 "검증"입니다. AI가 코드를 제안할 수 있고, 블루프린트 구조를 설명할 수 있고, 에러 로그를 해석할 수 있습니다. 그러나 최종 책임은 개발자에게 있습니다.

따라서 포트폴리오에는 다음과 같은 기록이 있으면 좋습니다.

• AI에게 처음 요청한 프롬프트

• AI가 제안한 구조의 장단점

• 실제 엔진 버전에서 맞지 않았던 부분

• 수정한 코드 또는 블루프린트 구조

• 테스트 방법과 결과

• 나중에 다시 만든다면 바꿀 점

예를 들어 AI가 존재하지 않는 노드를 추천했을 수 있습니다. 이때 "AI가 틀렸다"에서 끝내지 말고, 공식 문서와 에디터 검색으로 대체 노드를 찾은 과정을 적으면 좋습니다. AI가 C++ 코드를 제안했지만 컴파일이 실패했다면, 어떤 include가 빠졌고 어떤 모듈 의존성을 Build.cs에 추가했는지 기록하세요. 이런 기록은 단순한 완성작보다 훨씬 강한 신뢰를 줍니다.

AI 활용 능력은 앞으로 더 보편화될 것입니다. 차별점은 "AI를 썼는가?"가 아니라 "AI 결과를 엔진 안에서 검증하고, 프로젝트 맥락에 맞게 고쳤는가?"입니다.

12주 확장 로드맵 예시

이제 실제 계획을 세워봅시다. 입문을 마친 뒤 12주를 어떻게 쓸 수 있을까요? 모든 독자가 같은 계획을 따를 필요는 없습니다. 아래는 방향별 예시입니다.

게임플레이 프로그래머 경로

이 경로의 핵심은 "기능을 많이 넣기"가 아니라 "구조가 보이게 만들기"입니다. 전투가 단순해도 클래스와 데이터 흐름이 명확하면 좋은 포트폴리오가 됩니다.

멀티플레이어 개발자 경로

이 경로에서는 재미보다 정확성이 중요합니다. 클라이언트에서만 맞는 것처럼 보이는 코드를 경계하세요. 항상 서버 권한, 복제 대상, 호출 방향을 문서에 적는 습관을 들이면 좋습니다.

XR·모바일 개발자 경로

이 경로의 핵심은 제약을 즐기는 것입니다. PC에서 멋진 기능 하나를 더 넣는 것보다, 실제 기기에서 안정적으로 돌아가게 만드는 경험이 더 중요합니다.

리얼타임 3D·비게임 제작자 경로

이 경로에서는 코드량보다 연출과 전달력이 중요할 수 있습니다. 하지만 인터랙션이 하나라도 들어가면 단순 렌더 이미지와 차별화됩니다. 버튼을 눌러 재질을 바꾸거나, 사용자가 공간을 걸어 다니거나, 디지털 휴먼이 반응하는 순간 결과물의 성격이 달라집니다.

커뮤니티에 질문하는 법도 실력이다

입문 이후에는 혼자 해결하기 어려운 문제가 늘어납니다. 이때 포럼과 커뮤니티를 잘 활용하는 것도 실력입니다. 언리얼 공식 포럼에는 초보자 로드맵, 전환 경험, 문제 해결 사례가 꾸준히 올라옵니다. 어떤 개발자는 언리얼 학습 곡선을 "페라리를 몰고 절벽으로 돌진하는 느낌"에 비유하기도 했습니다.⁷ 과장처럼 들리지만, 처음 언리얼의 복잡도를 마주한 사람에게는 꽤 정확한 표현입니다.

질문할 때는 "안 돼요"라고 쓰면 답을 받기 어렵습니다. 좋은 질문에는 재현 가능한 정보가 들어 있습니다.

환경
- Unreal Engine 5.6
- Windows 11
- Blueprint 기반 Third Person 프로젝트

목표
- 클라이언트가 공격 입력을 누르면 서버에서 데미지를 적용하고 싶음

현재 구조
- BP_PlayerCharacter에서 InputAction_Attack 처리
- Server_Attack 커스텀 이벤트를 Reliable Server로 설정
- BP_Enemy에 Apply Damage 호출

문제
- 호스트에서는 데미지가 적용되지만 클라이언트에서는 적 체력 UI가 갱신되지 않음

시도한 것
- Enemy Actor Replicates 체크
- Health 변수 Replicated 설정
- Print String으로 Server_Attack 호출 확인

궁금한 점
- Health UI 갱신은 RepNotify로 처리해야 하는가?
- Enemy 위젯은 서버와 클라이언트 중 어디에서 생성해야 하는가?

이 정도로 질문하면 답변자가 문제를 훨씬 빨리 파악할 수 있습니다. AI에게 질문할 때도 같은 형식을 쓰면 좋습니다. 결국 좋은 질문은 좋은 디버깅의 절반입니다.

다음 전문 분야를 고르는 기준

마지막으로, 어떤 분야로 갈지 아직 모르겠다면 다음 질문에 답해보세요.

• 나는 화면에 보이는 결과물이 빨리 좋아지는 것이 즐거운가, 내부 구조가 깔끔해지는 것이 즐거운가?

• 혼자 만드는 작은 게임이 좋은가, 여러 사람이 접속하는 시스템이 좋은가?

• 코드와 수학을 더 파고들고 싶은가, 장면 구성과 연출을 더 파고들고 싶은가?

• 취업이나 외주를 목표로 하는가, 개인 창작과 출시를 목표로 하는가?

• PC·콘솔 고품질 게임이 목표인가, 모바일·XR·전시·시각화가 목표인가?

화면 결과가 빨리 좋아지는 것이 즐겁다면 라이팅, 머티리얼, 시네마틱, 비게임 시각화 쪽이 잘 맞을 수 있습니다. 내부 구조가 깔끔해지는 것이 즐겁다면 C++, 게임플레이 시스템, GAS, 멀티플레이어가 어울립니다. 기기에서 직접 실행되는 경험이 좋다면 XR·모바일 경로가 좋습니다. 사람과의 상호작용, 서버 권한, 동기화 문제가 흥미롭다면 멀티플레이어가 강한 선택입니다.

정답은 없습니다. 다만 한 번에 모두 선택하지 마세요. 언리얼은 넓습니다. 넓은 지도를 앞에 두고 가장 좋은 전략은 전체를 외우는 것이 아니라, 다음 목적지를 정하고 걸어가는 것입니다.

입문은 끝났고, 이제 방향을 정할 시간이다

여기까지 왔다면 여러분은 더 이상 "언리얼을 한 번도 안 열어본 사람"이 아닙니다. 에디터를 알고, Actor와 Component를 알고, 블루프린트로 로직을 만들고, AI에게 질문하고, 장면을 꾸미고, 미니게임을 완성해봤습니다. 이 정도면 충분히 다음 단계로 갈 자격이 있습니다.

하지만 다음 단계는 무조건 더 어려운 기술을 공부하는 것이 아닙니다. C++을 할 수도 있고, 멀티플레이어를 할 수도 있고, XR을 할 수도 있고, 메타휴먼 기반 디지털 휴먼을 만들 수도 있고, 건축 시각화 쇼릴을 만들 수도 있습니다. 중요한 것은 "내가 무엇을 만들 사람인지"를 먼저 정하는 것입니다.

AI 시대의 학습자는 혼자 걷지 않습니다. Claude, ChatGPT, Cursor, 언리얼 특화 플러그인, 공식 문서, 커뮤니티가 옆에 있습니다. 그러나 방향을 정하는 일은 여전히 여러분의 몫입니다. AI는 길을 설명해줄 수 있지만, 어떤 산을 오를지는 대신 골라주지 못합니다.

첫 게임은 이미 완성했습니다. 이제 다음 4주짜리 목표를 하나 정하세요. 작아도 됩니다. 오히려 작아야 합니다. 대시 시스템을 C++로 옮기기, 2인 멀티플레이어 체력 동기화 만들기, VR 방 탈출 상호작용 만들기, 메타휴먼 NPC와 대화하기, 건축 공간을 실시간 프레젠테이션으로 바꾸기.

하나를 고르고, 만들고, 기록하고, 공개하세요.

그 반복이 입문자를 개발자로 바꿉니다.

참고

¹UE5 Learning Roadmap and Goal Setting Strategy

²Unity vs Unreal for Multiplayer Games

³Unreal Engine Portfolio 예시

⁴Android XR용 Unreal Engine으로 개발

⁵Unreal Engine 5.7 Roadmap 정리

⁶Epic Developer Community Learning

⁷Epic Developer Community Forums: Guidance / roadmap for new developer