언리얼 엔진 4버전이 출시된 이후로 언리얼 엔진에서는 C++와 블루프린트를 활용해 게임 로직을 개발할 수 있었습니다.
C++는 언리얼 엔진의 핵심 시스템을 구성하는 강력한 언어이고,
블루프린트는 프로그래밍 경험이 많지 않은 개발자도 게임 로직을 시각적으로 구성할 수 있게 해주는 강력한 도구입니다.
그동안 언리얼 엔진은 이 두 가지 방식을 함께 제공하면서 굉장히 강력한 개발 환경을 만들어왔습니다.
그런데 얼마전 공개된 언리얼 엔진 6의 티저와 포트나이트 생태계를 살펴보면 새로운 이름이 하나 등장합니다.
바로 벌스(Verse)입니다. 벌스는 MetaVerse에서 Verse만 따온 이름이라고 언리얼 엔진의 창시자인 팀 스위니가 밝힌 바 있습니다.
벌스는 현재 Unreal Editor for Fortnite, 즉 UEFN에서 먼저 사용되고 있는 프로그래밍 언어입니다.
그리고 Epic은 벌스를 단순히 포트나이트 크리에이터 도구에만 사용하는 작은 스크립트 언어로 바라보지 않는 것처럼 보입니다.
앞으로 언리얼 엔진이
더 큰 규모의 온라인 월드,
더 많은 사용자 제작 콘텐츠,
더 복잡한 상호작용을 다루기 위해 발전해간다면,
벌스는 매우 중요한 역할을 맡게 될 가능성이 있습니다.
이번 시리즈에서는 벌스 문법만 단순히 나열하기보다,
Epic이 왜 새로운 언어를 만들려고 했는지,
그리고 벌스가 기존 C++나 블루프린트와 어떤 다른 관점에서 설계되었는지를 함께 정리해보려고 합니다.
언리얼 엔진에는 이미 C++와 블루프린트가 있다
언리얼 엔진에는 이미 강력한 개발 도구가 존재합니다.
C++는 성능이 중요하거나 엔진 내부 구조와 깊게 연결되는 시스템을 만들 때 여전히 매우 중요한 역할을 합니다.
게임플레이 프레임워크,
렌더링,
물리,
네트워크,
메모리 관리처럼 엔진의 핵심 구조는 C++ 기반으로 구성되어 있습니다.
반면 블루프린트는 프로그래머가 아닌 개발자도 게임 로직을 만들 수 있게 해주는 강력한 비주얼 스크립팅 도구입니다.
기획자나 아티스트도 블루프린트를 사용하면 캐릭터 동작,
UI,
이벤트 처리,
간단한 게임 로직을 직접 구성할 수 있습니다.
따라서 단순히 “언리얼 엔진에 프로그래밍 언어가 부족해서 벌스가 등장했다”고 보는 것은 정확하지 않을 수 있습니다.
이미 언리얼 엔진에는 C++와 블루프린트라는 강력한 조합이 있기 때문입니다.
그렇다면 Epic은 왜 새로운 언어를 준비하기 시작했을까요?
이 질문을 이해하려면 언리얼 엔진이 앞으로 어떤 방향으로 확장되려는지를 함께 생각해볼 필요가 있습니다.
게임 개발 환경이 점점 바뀌고 있다
과거의 게임 개발은 비교적 명확한 구조를 가지고 있었습니다.
개발사가 게임을 만들고, 사용자는 완성된 게임을 플레이했습니다.
물론 모드 제작이나 유저 생성 콘텐츠도 존재했지만, 대부분의 핵심 개발 흐름은 전문 개발팀 내부에서 이루어졌습니다.
하지만 최근 게임 생태계는 점점 달라지고 있습니다.
포트나이트,
로블록스,
마인크래프트 같은 플랫폼을 보면 사용자가 단순 플레이어로만 머무르지 않습니다.
사용자가 직접 월드를 만들고,
규칙을 만들고,
게임 모드를 만들고,
다른 사용자와 공유하는 구조가 점점 중요해지고 있습니다.
이런 환경에서는 기존 게임 개발 방식과 다른 문제가 등장합니다.
전문 개발자만 코드를 작성하는 것이 아니라,
훨씬 더 다양한 배경을 가진 사람들이 게임 로직을 만들 수 있어야 합니다.
동시에 수많은 사용자가 만든 콘텐츠가 하나의 거대한 온라인 생태계 안에서 안정적으로 동작해야 합니다.
따라서 언어는 단순히 “문법이 쉬운가”만으로 평가될 수 없습니다.
대규모 온라인 환경에서 안전하게 실행될 수 있는지,
멀티플레이 구조를 잘 표현할 수 있는지,
초보자도 접근할 수 있으면서 장기적으로 복잡한 시스템도 표현할 수 있는지가 중요해집니다.
벌스는 바로 이런 문제의식에서 등장한 언어라고 볼 수 있습니다.
벌스는 단순 스크립트 언어라기보다 플랫폼 언어에 가깝다
벌스를 처음 접하면 게임 로직을 작성하기 위한 스크립트 언어처럼 보일 수 있습니다.
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }
# See https://dev.epicgames.com/documentation/en-us/uefn/create-your-own-device-in-verse for how to create a verse device.
# A Verse-authored creative device that can be placed in a level
hello_world_device := class(creative_device):
# Runs when the device is started in a running game
OnBegin<override>()<suspends>:void=
# TODO: Replace this with your code
Print("Hello, world!")
Print("2 + 2 = {2 + 2}")
Print("This is my first line of Verse code!")
하지만 벌스가 향하는 방향은 단순 스크립트 언어보다 훨씬 넓어 보입니다.
UEFN에서 벌스는 포트나이트 안의 장치,
플레이어,
이벤트,
게임 규칙을 제어하기 위해 사용됩니다.
이 관점에서 보면 벌스는 특정 게임 안에서 간단한 로직을 추가하는 도구처럼 보이기도 합니다.
하지만 포트나이트가 단순한 하나의 게임을 넘어,
수많은 사용자 제작 콘텐츠가 모이는 플랫폼으로 확장되고 있다는 점을 생각하면 이야기가 달라집니다.
플랫폼 안에서 수많은 크리에이터가 코드를 작성하고,
그 코드가 멀티플레이 환경에서 실행되며,
다양한 사용자 경험을 만들어내야 한다면,
언어 자체가 플랫폼의 안정성과 확장성을 고려해야 합니다.
따라서 벌스는 단순히 “언리얼 엔진용 새 문법 ”이라기보다,
Epic이 앞으로 만들고 싶은 대규모 실시간 콘텐츠 플랫폼을 위한 언어로 보는 편이 더 자연스럽습니다.
C++는 강력하지만 어렵다
C++는 여전히 게임 개발에서 굉장히 중요한 언어입니다.
성능이 뛰어나고,
메모리 제어가 가능하며,
엔진 내부 구조를 정교하게 만들 수 있습니다.
언리얼 엔진이 C++를 핵심 언어로 사용하는 이유도 여기에 있습니다.
하지만 C++는 배우기 쉬운 언어는 아닙니다.
포인터,
참조,
메모리 수명,
템플릿,
빌드 시스템,
헤더와 소스 분리,
컴파일 시간 같은 요소들이 초심자에게는 큰 장벽이 될 수 있습니다.
특히 사용자 제작 콘텐츠 플랫폼에서는 더 큰 문제가 됩니다.
모든 크리에이터에게 C++ 수준의 복잡도를 요구하기는 어렵습니다.
또한 플랫폼 입장에서는 사용자가 작성한 코드가 안전하게 실행되어야 합니다.
잘못된 메모리 접근이나 예측하기 어려운 런타임 오류가 플랫폼 전체의 안정성을 해치면 안 됩니다.
따라서 Epic 입장에서는 C++보다 더 안전하고,
더 통제 가능하며,
더 많은 사용자에게 열려 있는 언어가 필요했을 가능성이 있습니다.
벌스는 이런 지점에서 C++와 다른 역할을 맡기 위해 등장한 언어로 볼 수 있습니다.
블루프린트는 직관적이지만 모든 문제를 해결하지는 않는다
블루프린트는 언리얼 엔진의 가장 강력한 기능 중 하나입니다.
노드 기반으로 로직을 구성할 수 있기 때문에,
코드에 익숙하지 않은 사람도 게임 로직을 만들 수 있습니다.
간단한 상호작용이나 이벤트 흐름을 만들 때 블루프린트는 굉장히 직관적입니다.
하지만 프로젝트 규모가 커질수록 블루프린트도 한계를 가질 수 있습니다.
노드가 많아지면 흐름을 추적하기 어려워지고,
복잡한 로직은 화면 안에서 관리하기 어렵게 됩니다.
협업 과정에서도 변경 사항을 비교하거나,
버전 관리 시스템으로 코드를 리뷰하는 일이 텍스트 기반 코드보다 불편할 수 있습니다.
따라서 블루프린트는 매우 좋은 도구이지만,
대규모 로직을 장기적으로 관리하기 위한 텍스트 기반 언어의 필요성도 여전히 존재합니다.
벌스는 이 지점에서 블루프린트와 다른 위치를 차지할 수 있습니다.
시각적인 노드 구조보다 텍스트 기반으로 명확하게 로직을 작성하면서도,
C++보다 더 안전하고 접근하기 쉬운 방향을 목표로 한다면,
벌스는 사용자 제작 콘텐츠와 차세대 언리얼 엔진 구조 사이에서 중요한 연결 고리 역할을 할 수 있습니다.
벌스가 중요해지는 이유는 멀티플레이 구조 때문
현대 게임에서 멀티플레이는 점점 더 중요해지고 있습니다.
특히 포트나이트 같은 플랫폼에서는 수많은 플레이어가 같은 공간 안에서 상호작용합니다.
이런 환경에서는 단순히 로컬에서 동작하는 코드만 생각할 수 없습니다.
서버와 클라이언트가 어떻게 상태를 공유하는지,
여러 플레이어의 행동이 어떻게 동기화되는지,
동시에 발생하는 이벤트를 어떻게 안전하게 처리할 것인지가 중요해집니다.
벌스가 흥미로운 동시에 강력해 보이는 이유는 이 언어가 이런 대규모 상호작용 환경을 염두에 두고 설계된 것처럼 보이기 때문입니다.
일반적인 게임 스크립트 언어는 작은 게임 오브젝트의 동작을 작성하는 데 초점을 맞추는 경우가 대부분입니다.
하지만 벌스는 사용자 제작 콘텐츠와 멀티플레이 환경,
그리고 장기적으로 더 큰 규모의 온라인 월드를 고려하는 언어로 보입니다.
따라서 벌스를 공부할 때는 단순히 문법만 보는 것보다,
왜 이런 언어가 필요한 환경이 등장했는지를 함께 보는 것도 중요하다고 생각합니다.
벌스는 실패(Failure)를 언어 구조로 다룬다
벌스에서 특히 흥미로운 개념 중 하나는 Failure입니다.
일반적인 프로그래밍 언어에서는
조건이 맞지 않거나 값이 없을 때 null,
예외,
bool 반환값 같은 방식으로 실패를 처리하는 경우가 대부분입니다.
이렇게 처리하는 것을 보통 예외 처리라고 지칭합니다.
하지만 벌스는 실패 가능성이 있는 연산을 언어 구조 안에서 다루려는 특징을 가지고 있습니다.
이것은 단순 문법 차이가 아니라, 언어가 오류와 조건 실패를 어떤 방식으로 바라보는지를 잘 보여줍니다.
게임 로직에서는 어떤 일이 성공할 수도 있고 실패할 수도 있습니다.
플레이어가 특정 위치에 있는지,
아이템을 가지고 있는지,
대상이 유효한지,
조건이 충족되었는지 같은 판단이 계속 발생합니다.
벌스는 이런 실패 가능성을 코드 안에서 명시적으로 다루려는 방향성을 가지고 있습니다.
이 개념은 처음에는 낯설 수 있지만,
차세대 게임 로직을 안전하게 작성하는 데 중요한 기반이 될 수도 있습니다.
따라서 이 시리즈에서는 벌스 문법을 설명할 때 Failure 개념도 별도의 글로 자세히 다뤄보려고 합니다.
벌스는 차세대 언리얼 엔진을 이해하는 단서가 될 수 있다
아직 벌스가 언리얼 엔진 전체에서 어떤 방식으로 자리 잡게 될지는 최종적으로 확정된 단계라고 보기는 어렵습니다.
현재는 UEFN을 통해 먼저 공개되어 있고, 포트나이트 크리에이터 생태계 안에서 사용되고 있습니다.
하지만 Epic이 포트나이트와 언리얼 엔진,
사용자 제작 콘텐츠,
대규모 온라인 월드를 하나의 흐름으로 연결하려 한다면,
벌스는 앞으로 점점 더 중요한 언어가 될 가능성이 있습니다.
따라서 벌스를 미리 살펴보는 것은 단순히 새로운 문법을 공부하는 것 이상의 의미가 있다고 생각합니다.
Epic이 앞으로 게임 엔진과 콘텐츠 제작 환경을 어떤 방향으로 발전시키려 하는지,
그리고 왜 기존 C++와 블루프린트만으로는 부족하다고 판단했는지를 이해하는 과정이 될 수 있기 때문입니다.
특히 언리얼 엔진을 공부하는 개발자라면, 벌스를 통해 차세대 언리얼 엔진 구조의 일부를 미리 엿볼 수 있을지도 모릅니다.
마무리
벌스는 단순히 새로운 문법을 가진 스크립트 언어가 아닐 가능성이 높습니다.
C++의 강력함,
블루프린트의 접근성,
멀티플레이 플랫폼의 안정성,
사용자 제작 콘텐츠의 확장성 사이에서 Epic이 새롭게 설계하고 있는 언어라고 볼 수 있습니다.
물론 아직 벌스가 앞으로 언리얼 엔진 전체에서 어떤 위치를 차지하게 될지는 더 지켜봐야 합니다.
하지만 UEFN을 통해 이미 공개된 언어이고,
포트나이트 크리에이터 생태계 안에서 실제로 사용되고 있다는 점만으로도 충분히 살펴볼 가치가 있다고 생각합니다.
이번 시리즈에서는 벌스 문법을 단순히 기능별로 나열하기보다,
왜 이런 문법과 구조가 등장했는지를 함께 설명해보려고 합니다.
다음 글에서는 벌스가 어떤 언어인지,
그리고 기존 C++나 블루프린트와 비교했을 때 어떤 점이 다르게 느껴지는지를 이어서 정리해보겠습니다.