이전 글에서는 Epic이 왜 새로운 언어인 벌스(Verse)를 만들기 시작했는지를 정리해보았습니다.
언리얼 엔진에는 이미 강력한 C++와 블루프린트가 존재합니다.
그럼에도 Epic은 새로운 언어를 준비하기 시작했고,
UEFN(Unreal Editor for Fortnite)을 통해 실제로 벌스를 공개했습니다.
그리고 이 흐름은 단순히 “새로운 문법을 가진 언어 하나를 추가”하는 수준이라기보다,
앞으로의 언리얼 엔진과 사용자 제작 콘텐츠 플랫폼 방향성과 깊게 연결되어 있는 것처럼 보입니다.
이번 글에서는 벌스가 실제로 어떤 언어인지,
그리고 기존 C++나 블루프린트와 비교했을 때 어떤 특징을 가지는지를 조금 더 자세하게 정리해보려고 합니다.
벌스는 기존 게임 스크립트 언어와 분위기가 다르다
처음 벌스 코드를 보면 기존 게임 스크립트 언어와는 조금 다른 느낌을 받게 됩니다.
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!")
예를 들어 Lua나 C# 기반 게임 스크립트를 먼저 접해본 개발자라면, 벌스 문법이 익숙하면서도 동시에 어딘가 낯설게 느껴질 수 있습니다.
표면적으로 보면 함수와 클래스, 변수 같은 일반적인 프로그래밍 요소들을 사용하고 있기 때문에 완전히 새로운 언어처럼 보이지는 않습니다.
하지만 벌스로 작성된 코드를 자세히 들여다보면 기존의 스크립트 언어들과는 방향성이 조금 달라 보입니다.
특히 벌스는 단순히 “순서대로 명령을 실행하는 스크립트 언어”라기 보다
조건과 상태 변화,
그리고 실패 가능성을 언어 안에서 직접적으로 표현하려는 특징을 가지고 있습니다.
일반적인 게임 스크립트 언어들은 변수 값을 변경하고,
함수를 호출하면서 상태를 순차적으로 변경하는 형태 중심으로 구성됩니다.
반면, 벌스는 현재 어떤 조건이 만족되는지,
어떤 연산이 실패할 수 있는지,
그리고 어떤 상태가 실제로 유효한지를 코드 안에서 조금 더 명시적으로 표현하려는 의도가 보입니다.
특히 실패(Failure) 개념을 언어 안으로 가져온 부분은 기존 게임 스크립트 언어들과 다르다고 할 수 있습니다.
일반적인 스크립트 언어에서는 특정 값이 존재하지 않거나 조건을 만족하지 않는 경우,
null 체크나 bool 반환, 예외 처리 같은 방식으로 실패 상황을 처리합니다.
하지만 벌스는 실패 가능성 자체를 코드 안에서 조금 더 자연스럽게 표현하려는 것처럼 보입니다.
Epic은 벌스를 단순히 로컬 게임 스크립트를 넘어서
대규모 온라인 환경과 사용자 제작 콘텐츠 플랫폼,
그리고 멀티플레이 기반 시스템 안에서 안정적으로 동작할 수 있는 언어를 목표로 발전시키려는 것 같습니다.
따라서 벌스 문법이 처음에는 조금 낯설게 느껴질 수 있지만,
이런 배경까지 함께 생각해보면 왜 Epic이 기존 게임 스크립트 언어와 다른 형태의 언어를 만들려고 했는지도 이해될 것이라고 생각합니다.
문법이 굉장히 간결함
벌스 코드를 처음 보면 가장 먼저 눈에 들어오는 특징 중 하나는 문법이 비교적 간결하다는 점입니다.
특히 C++를 공부해본 개발자라면 이 차이를 더 크게 느끼실 겁니다.
일반적인 C++에서는 세미콜론과 중괄호,
헤더 파일 구성,
명시적인 타입 선언,
메모리 관리 같은 다양한 요소들을 계속 신경 써야 합니다.
물론 C++가 강력한 저수준 제어 능력을 제공하기 때문에 필요한 부분들이기도 합니다.
하지만 코드 양 자체가 많아지기 쉽고, 초보자 입장에서는 문법 장벽이 높게 느껴질 수 있습니다.
반면 벌스는 상대적으로 훨씬 단순하고 간결한 형태로 코드를 작성할 수 있습니다.
예를 들어 함수 정의 역시 비교적 짧은 형태로 구성되고, 클래스 선언도 기존 C++보다 훨씬 단순한 느낌으로 작성됩니다.
# 함수 예시 코드
BuyMousetrap() : void =
set Coins = Coins - CoinsPerMousetrap
Print("Mousetrap bought! You have {Coins} coins left.")
# 클래스 예시 코드
using { /Fortnite.com/AI }
using { /Fortnite.com/Characters }
using { /Fortnite.com/Game }
using { /Verse.org/Simulation }
on_damaged_behavior<public> := class(npc_behavior):
# This function runs when the NPC is spawned in the world and ready to follow a behavior.
OnBegin<override>()<suspends>:void=
if:
Agent := GetAgent[]
FortCharacter := Agent.GetFortCharacter[]
then:
# Subscribe the character's damaged event to OnDamaged
FortCharacter.DamagedEvent().Subscribe(OnDamaged)
따라서 처음 벌스 코드를 보면 “생각보다 코드가 짧다”라는 느낌을 줍니다.
그리고 이런 언어의 설계 철학은 단순히 “보기 좋은 문법”을 위해서만은 아니라고 생각합니다.
Epic 입장에서는 더 많은 크리에이터가 쉽게 접근할 수 있어야 하고,
온라인 플랫폼 안에서 빠르게 로직을 작성할 수 있어야 하며,
복잡한 메모리 문제 역시 최대한 줄일 필요가 있었을 가능성이 있습니다.
특히 UEFN처럼 사용자 제작 콘텐츠 중심 환경에서는 수많은 사용자가 다양한 로직을 작성하게 됩니다.
이런 환경에서는 복잡한 구조의 언어보다,
상대적으로 간결하고 안전하게 코드를 작성할 수 있는 환경이 훨씬 중요할 수 있습니다.
따라서 벌스 문법의 간결함은 단순하게 배우기 쉬운 언어를 만들어야 겠다는 아이디어라기 보다는
사용자 제작 콘텐츠 플랫폼 환경과 연결된 고민의 결과라고 생각됩니다.
벌스는 메모리를 직접 제어하지 않는다
C++와 비교했을 때 가장 큰 차이 중 하나는 메모리 관리 방식입니다.
C++에서는 객체 수명과 포인터, 참조, 메모리 해제 등 메모리 관리를 개발자가 직접 해야합니다.
물론 최근 C++는 스마트 포인터와 RAII 같은 구조 덕분에 과거보다 훨씬 안전하게 메모리를 관리할 수 있게 되었습니다.
하지만 여전히 메모리 관리 자체는 중요한 문제이고,
잘못된 메모리 접근이나 객체 수명 문제는 실제 프로젝트에서 다양한 버그의 원인이 되기도 합니다.
특히 언리얼 엔진처럼 규모가 큰 프로젝트에서는 객체가 언제 생성되고,
언제 제거되는지를 정확하게 관리하는 것이 굉장히 중요합니다.
반면 벌스는 이런 저수준 메모리 제어를 거의 드러내지 않습니다.
사용자는 포인터나 메모리 해제 같은 문제보다,
로직과 상태 흐름 자체에 더 집중할 수 있도록 구성되어 있습니다.
즉, 메모리 관리 자체를 개발자가 직접 처리하기보다,
언어와 런타임 시스템이 더 많이 담당하는 방향에 가깝습니다.
이런 구조는 단순히 편의성만 고려한 결과는 아닐 가능성이 높다고 생각합니다.
Epic은 벌스를 대규모 온라인 환경과 사용자 제작 콘텐츠 플랫폼 안에서 동작하는 언어 방향으로 발전시키려 하고 있기 때문입니다.
이런 환경에서는 수많은 사용자가 작성한 코드가 동시에 실행될 수 있습니다.
따라서 플랫폼 입장에서는 사용자가 메모리를 직접 제어하는 구조보다, 플랫폼이 더 안전하게 관리할 수 있는 구조가 훨씬 유리합니다.
이는 최근 많은 현대 언어들이 개발자가 직접 메모리를 제어하도록 하기 보다,
런타임과 언어 차원에서 더 안전하게 관리하려는 방향으로 발전하는 것과도 어느 정도 연결되어 있다고 할 수 있습니다.
특히 예측하기 어려운 메모리 접근이나 객체 수명 문제를 줄일 수 있다면, 플랫폼 전체 안정성 역시 훨씬 높아질 것입니다.
따라서 벌스가 저수준 메모리 제어를 드러내지 않는 이유 역시 단순히 “쉬운 언어”를 만들기 위한 선택이라기보다,
플랫폼 안정성과 연결된 설계 방향이라고 볼 수 있습니다.
Failure를 언어 구조 안으로
벌스를 이야기할 때 가장 독특하게 느껴지는 부분 중 하나는 Failure 개념입니다.
기존 프로그래밍 언어에서는 특정 값이 존재하지 않거나 조건이 만족되지 않는 상황을 처리할 때,
보통 null 체크나 bool 반환, 예외 처리 같은 방식을 사용하는 경우가 많습니다.
예를 들어 어떤 객체를 찾지 못했거나, 조건이 충족되지 않았을 때 함수가 false를 반환하거나 예외를 발생시키는 방식입니다.
이런 구조는 오랫동안 다양한 프로그래밍 언어에서 사용되어 왔고, 게임 개발에서도 굉장히 익숙한 방식입니다.
하지만 벌스는 실패 가능성 자체를 코드 안에서 더 직접적으로 다루려는 특징을 가지고 있습니다.
예를 들어 어떤 객체가 실제로 존재하는지,
특정 조건이 만족되는지,
혹은 어떤 연산이 성공 가능한 상태인지를 코드 안에서 더 명시적으로 표현하려는 방향성이 보이기 시작합니다.
즉, 실패를 단순 런타임 오류처럼 처리하기보다, 프로그램 안에서 자연스럽게 다루려는 의도로 보입니다.
이런 접근은 조금 낯설게 느껴질 수도 있습니다. 특히 기존 명령형 언어에 익숙한 개발자라면 “왜 이렇게까지 실패를 중요하게 다루지?”라는 생각을 할 수도 있습니다.
하지만 최근의 게임 환경을 생각해보면 이런 설계 방향이 점점 더 중요해질 가능성이 있습니다.
특히 멀티플레이 환경과 사용자 제작 콘텐츠 플랫폼에서는 예상 가능한 실패 상황을 안전하게 처리하는 것이 굉장히 중요해집니다.
수많은 사용자가 만든 코드가 동시에 실행되고,
다양한 상태 변화가 계속 발생하는 환경에서는 단순히 “실행된다”보다,
실패 상황을 얼마나 예측 가능하고 안전하게 제어할 수 있는지가 훨씬 중요해질 수 있기 때문입니다.
그리고 벌스는 바로 이런 방향성을 어느 정도 염두에 두고 설계된 언어처럼 보입니다.
따라서 Failure 개념은 단순 특이한 문법 요소라기보다,
Epic이 앞으로 만들고자 하는 대규모 온라인 플랫폼 환경과 연결된 중요한 특징 중 하나라고 볼 수 있습니다.
벌스는 동시성(Concurrency)을 중요하게 바라본다
현대 게임은 점점 더 복잡한 멀티플레이 환경으로 발전하고 있습니다.
특히 포트나이트 같은 플랫폼에서는 수많은 플레이어가 동시에 접속하고, 다양한 이벤트와 상호작용이 실시간으로 계속 발생하게 됩니다.
예를 들어 여러 플레이어가 같은 공간 안에서 이동하고,
아이템을 사용하고,
이벤트를 발생시키며,
서로 다른 행동을 동시에 수행하는 상황이 계속 이어지게 됩니다.
이런 환경에서는 단순히 코드를 순서대로 실행하는 구조만으로는 표현하기 어려운 문제들이 점점 많아질 수 있습니다.
어떤 이벤트는 동시에 처리되어야 하고,
특정 작업은 다른 작업이 끝날 때까지 기다려야 하며,
여러 상태 변화가 충돌 없이 안전하게 관리되어야 하기 때문입니다.
그리고 벌스는 이런 동시성 문제를 언어 차원에서 어느 정도 고려하고 있는 것처럼 보입니다.
물론 현재 공개된 벌스 기능만으로 Epic의 모든 방향성을 단정하기는 어렵습니다.
하지만 Epic이 최근 실시간 온라인 월드와 사용자 제작 콘텐츠,
그리고 대규모 상호작용 환경을 굉장히 중요하게 바라보고 있다는 점을 생각하면,
벌스 역시 이런 구조를 염두에 두고 발전할 가능성이 높아 보입니다.
특히 기존 게임 스크립트 언어들이 비교적 “하나의 게임 로직을 순차적으로 실행하는 구조”에 가까웠다면,
벌스는 더 복잡한 실시간 상호작용 환경을 고려하는 방향성이 일부 보이기 시작합니다.
그리고 이런 특징은 벌스를 단순 로컬 게임 스크립트 언어보다,
차세대 온라인 플랫폼 환경과 연결된 언어처럼 보이게 만드는 이유 중 하나이기도 합니다.
벌스는 블루프린트를 완전히 대체할까?
현재 시점에서 벌스가 블루프린트를 완전히 대체한다고 보기는 어렵습니다.
블루프린트는 여전히 언리얼 엔진에서 굉장히 강력한 도구이기 때문입니다.
특히 시각적인 노드 기반 구조 덕분에 코드에 익숙하지 않은 개발자도 비교적 쉽게 게임 로직을 구성할 수 있습니다.
예를 들어 간단한 상호작용이나 이벤트 흐름, UI 연결,
프로토타이핑 같은 작업은 블루프린트만으로 굉장히 빠르게 구성할 수 있습니다.
그리고 이런 직관적인 작업 방식은 블루프린트의 큰 장점 중 하나입니다.
특히 기획자나 아티스트처럼 프로그래밍을 전문적으로 하지 않은 입장에서는 텍스트 코드보다 훨씬 접근하기 쉬운 경우도 많습니다.
반면 벌스는 조금 다른 방향성을 가지고 있는 것처럼 보입니다.
블루프린트가 시각적인 로직 구성에 강점을 가지고 있다면,
벌스는 텍스트 기반 코드 작성과 구조적인 로직 관리,
그리고 장기 유지보수 측면에 조금 더 가까운 방향성을 가지는 것처럼 보이기 때문입니다.
또한 Epic이 벌스를 단순 로컬 게임 스크립트보다,
대규모 온라인 환경과 사용자 제작 콘텐츠 플랫폼 안에서 동작하는 언어 방향으로 발전시키려 하고 있다는 점 역시 함께 생각해볼 필요가 있습니다.
이런 환경에서는 코드 구조를 명확하게 유지하는 것과 안정적으로 실행 흐름을 관리하는 것이 점점 더 중요해질 수 있습니다.
따라서 앞으로는 블루프린트와 벌스,
그리고 C++가 서로 완전히 대체 관계로 가기보다
각자의 역할을 나누어서 함께 사용될 가능성도 충분히 있어 보입니다.
블루프린트가 처음 등장했을 때 C++를 대체할 수 있다는 시선도 있었지만,
결국 C++과 블루프린트는 서로 공존하는 관계이며,
각각의 장단점을 살려서 동작하고 있는 것처럼 말입니다.
예를 들어 빠른 프로토타이핑과 시각적 로직 구성은 블루프린트가 담당하고,
조금 더 구조적인 게임 로직이나 플랫폼 중심 코드는 벌스가 담당하며,
엔진 핵심 시스템과 저수준 성능 처리는 여전히 C++가 담당하는 형태로 발전할 가능성도 생각해볼 수 있습니다.
개인적으로는 앞으로 저수준에는 C++,
그 위에 Verse,
그리고 상위 레벨 로직 구성에는 블루프린트가 놓이는 형태로 발전할 가능성도 있다고 생각합니다.
벌스는 “미래 엔진 구조”와 연결되어 있을 수 있다
벌스를 단순히 새로운 문법을 가진 프로그래밍 언어 정도로만 바라보면,
“왜 Epic이 굳이 새로운 언어를 만들려고 했을까?”라는 생각이 들 수도 있습니다.
이미 언리얼 엔진에는 강력한 C++와 블루프린트가 존재하기 때문입니다.
하지만 Epic이 앞으로 어떤 방향으로 플랫폼과 엔진을 확장하려 하는지를 함께 생각해보면 이야기가 조금 달라집니다.
최근 Epic은 단순 게임 엔진 개발사를 넘어,
대규모 온라인 월드와 사용자 제작 콘텐츠 플랫폼,
그리고 실시간 멀티플레이 환경을 굉장히 중요시하며 개발 방향을 정하는 것처럼 보입니다.
특히 포트나이트와 UEFN을 보면 단순한 “게임 제작”보다,
수많은 사용자가 콘텐츠를 만들고 공유하며,
같은 공간 안에서 상호작용하는 플랫폼 방향으로 계속 확장하고 있는 것으로 보입니다.
그리고 이런 환경에서는 단순히 코드를 제대로 실행하는 시스템을 구축하는 것만으로는 충분하지 않을 수 있습니다.
수많은 사용자가 만든 코드가 동시에 실행되어야 하고,
멀티플레이 환경 안에서도 안정적으로 동작해야 하며,
예측하기 어려운 상태 변화 역시 안전하게 관리할 수 있어야 하기 때문입니다.
따라서 앞으로의 엔진 구조에서는 안전성과 동시성, 확장성,
그리고 플랫폼 차원의 제어 가능성이 점점 더 중요해질 가능성이 있습니다.
그리고 벌스는 바로 이런 환경을 어느 정도 염두에 두고 설계된 언어가 아닐까 생각합니다.
따라서 벌스를 공부하는 것은 단순히 새로운 문법을 익히는 것 이상의 의미를 가질 수도 있습니다.
Epic이 앞으로 게임 엔진과 콘텐츠 플랫폼을 어떤 방향으로 발전시키려 하는지,
그리고 왜 기존 C++와 블루프린트만으로는 부족하다고 판단했는지를 이해하는 과정이 될 수도 있기 때문입니다.
마무리
벌스는 단순히 “언리얼 엔진용 새로운 스크립트 언어”라고 보기에는 꽤 흥미로운 특징들을 가지고 있습니다.
간결한 문법과 Failure 중심 구조, 동시성에 대한 접근, 그리고 플랫폼 안정성을 고려하는 방향까지 기존 게임 스크립트 언어와는 다른 특징들을 보여줍니다.
물론 아직 벌스는 발전 중인 언어이고, 앞으로 언리얼 엔진 전체에서 어떤 위치를 차지하게 될지는 더 지켜봐야 합니다.
하지만 현재까지 공개된 언어의 방향만 보더라도,
벌스는 게임 엔진에 더 쉬운 언어 시스템을 추가하는 수준을 넘어서
차세대 게임 엔진과 그 엔진이 발전될 가능성을 염두에 두고 개발하고 있는 것으로 판단됩니다.
다음 글에서는 벌스의 변수와 타입 시스템이 기존 언어들과 어떻게 다른지를 실제 문법 기준으로 조금 더 자세하게 정리해보겠습니다.
👉 게임 엔진 구조를 더 깊이 이해하고 싶다면
아래 강의를 통해 직접 구현해보는 것을 추천드립니다.
👉 C++로 만드는 게임 엔진 프레임워크 강의 바로가기