BRUTAL 소개 | RimWorld가 자체 엔진을 만들고 Unity에서 벗어나는 데 도움을 준 무료 C# 프레임워크. 이제 당신도 할 수

우리 산업은 핵심부터 모든 방향으로 썩어가고 있으며, 오랫동안 그래왔습니다. 탐욕에 의해, 가격 하락 경쟁에 의해 움직이고 있습니다. 제 생각에는 게임 산업이 리버스 엔지니어링(reverse-engineering)과 강력한 에이전트적 프로세스(agentic processes)가 널리 사용 가능해지기 전부터 이미 지속 불가능한 방향으로 가고 있었다는 것입니다. 이들이 상황을 한계까지 몰아붙였습니다. 하지만 저는 가장 큰 문제 중 하나는 우리가 충분히 논의하지 않는 것이라고 생각합니다. 개발자들이 자신의 작업에 대한 엄청난 통제권을, 자신들의 이해관계와 반드시 일치하는 것은 아닌 회사들에게 넘겨주었습니다. 그래서 우리는 이에 대해 무언가를 하고 있습니다. 저희가 BRUTAL Framework를 소스 코드와 함께 공개적으로 만들고, 상업용 게임을 포함하여 사용료 없이 사용할 수 있도록 합니다(단, 출처 표기 의무 사항 준수). 저는 Dean Hall입니다. 원래 DayZ를 만들었고, 현재는 뉴질랜드의 게임 스튜디오인 RocketWerkz와 Ahwoo라는 새로운 게임 배포 플랫폼을 운영하고 있습니다. 저희 게임에는 Stationeers와 ICARUS 등이 포함됩니다. 우리는 개발 중인 여러 게임에서 엔진을 교체하기 위해 BRUTAL을 사용해 왔습니다. 이것은 우리가 Kitten Space Agency를 만드는 데 사용했던 프레임워크이며, Ludeon이 RimWorld의 새로운 Waylith 엔진의 기반으로 사용한 것이기도 합니다.

BRUTAL Framework 네, 4년 전 저희 스튜디오는 자체 커스텀 프레임워크 개발을 시작했습니다. 당시에는 '미친' 개발자만이 할 수 있는 종류의 일처럼 보였습니다. 사람들이 고개를 저을 만한 무언가였죠. 자신만의 기술을 만드는 것은 스튜디오에게 너무나도 '위험 신호(red flag)'여서 내부적으로 비밀리에 진행되는 프로젝트일 정도였습니다. 몇 가지 라이브러리로 시작했지만, 점차 성장했고, 매우 빠르게 게임이나 자체 게임 엔진을 만들 수 있는 완전한 프레임워크가 되었습니다. 저희는 이것을 BRUTAL Framework라고 이름 지었습니다. BRUTAL이 게임 엔진이 아니라 프레임워크라는 것을 설명하는 것이 중요합니다.

이 프레임워크를 사용해 Kitten Space Agency처럼 직접 게임을 만들 수도 있고, Ludeon이 RimWorld에서 했던 것처럼 완전히 별개의 엔진의 기반으로 사용할 수도 있습니다. 핵심에는 커스텀 상호운용성 계층(interop layer)이 있어 C#가 네이티브 API 및 라이브러리에 접근할 수 있게 해줍니다. 저희는 수학, 메모리 관리, 문자열, 작업 스케줄링, 로깅, 현지화 등 다른 시스템을 포함하여 이 주변에 상당히 많은 지원 라이브러리를 구축했습니다. 저희는 할당(allocations)과 불필요한 오버헤드를 줄이는 데 강박적인 초점을 맞추고 있습니다. 의미가 있는 곳에서는 언매니지드 메모리(unmanaged memory)와 unsafe 코드를 광범위하게 사용합니다. 핵심 초점은 최신 버전의 C#와 Vulkan을 사용하여 몇 가지 저수준 작업(low-level things)을 매우 잘 수행하는 것이었습니다. 예를 들어, Vulkan 바인딩을 사용하여 자체 렌더러를 만들 수 있습니다. 하지만 BRUTAL이 모든 결정을 대신 해주는 것은 아닙니다. 당신이 직접 결정하게 됩니다. 원하는 NuGet 패키지, 타사 패키지를 포함하여 무엇이든 사용할 수 있습니다. 자신만의 스택을 작성할 수 있습니다. 어떤 면에서는 Unity, Unreal, 또는 Godot보다 사용하기 훨씬 어렵게 만듭니다. 다른 면, 특히 특이한 것을 만들고 있다면, 상당히 쉽게 만듭니다. 그 이유 때문에 BRUTAL이라고 불립니다. 개인적으로는 훨씬 쉽다고 느꼈습니다. 하지만 이것은 강제하는 기능(forcing function)을 수반합니다. 실제로 무엇을 하고 싶은지 먼저 알아야 합니다. Unity나 Unreal에서는 엔진 제작자들이 무언가를 어떻게 작동시키도록 의도했는지, 그리고 그들이 세운 가정을 어떻게 우회할지 파악하는 데 종종 며칠 또는 몇 주를 소비했습니다. 그런 것들 없이도 실제로는 더 빠릅니다. 적어도 우리가 만들려고 하는 종류의 게임에 한해서는 말입니다. BRUTAL이 아닌 것은, 이 도구가 모든 사람이 게임을 만드는 데 사용해야 할 도구라고 생각하지 않습니다. 저희는 내부적으로

사실 저희가 내린 가장 중요한 결정 중 하나는 BRUTAL에 무엇을 넣지 않을 것인지입니다. 이는 저희가 그 범위를 매우 엄격하게 유지할 것이라는 의미입니다. 명확한 목적에서 벗어나는 풀 리퀘스트(Pull requests)는 거부될 것입니다. 이것은 기여를 높이 평가하지 않기 때문이 아니라, 모든 것을 추가하는 방식이야말로 업계가 우리가 사용하고 싶지 않은 종류의 엔진을 갖게 된 정확한 이유이기 때문입니다. Linux 커널과 Ubuntu 같은 것의 관계를 생각해 보세요. 기술적으로 정확한 비교는 아니지만, 그 아이디어를 전달합니다. 저희가 기술적 기반을 제공하면, 개발자들이 그 위에 자신들만의 시스템을 구축하는 것입니다. 제가 모든 사람이 자신만의 게임 엔진을 만들어야 한다고 제안하는 것은 아닙니다. 저는 모든 개발자가 먼저 4년을 들여 기초를 다질 필요 없이 그렇게 할 수 있는 선택권을 가져야 한다고 제안하는 것입니다. 그리고 자신의 작업에 대한 통제권을 너무 많이 포기할 필요 없이 말입니다.

RimWorld와 Waylith Engine

5월 1일, RimWorld의 제작자인 Tynan Sylvester가 저에게 한 가지 문제로 다가왔고, 저는 그에게 BRUTAL Framework를 제안했습니다. 그 이후로 Ludeon은 BRUTAL을 활용하여 Waylith라는 자체 게임 엔진을 구축하는 데 도움을 받을 수 있었습니다. 그들이 얼마나 놀라운 성과를 짧은 시간 안에 이뤄냈는지 직접 확인하실 수 있습니다. 그 대화부터 발표까지는 겨우 5개월밖에 걸리지 않았습니다. 그들의 팀은 RimWorld에서 Unity의 마지막 부분들을 추출하여 Waylith 엔진을 만들었습니다. 거대한 모딩 커뮤니티를 가진 이미 확립된 게임을 아무것도 고장 나지 않게 Unity에서 분리하는 것은 엄청나게 복잡한 작업입니다. 저는 그들이 이뤄낸 성과에 매우 깊은 인상을 받았습니다. 또한 이것이 BRUTAL이 의도했던 바를 보여주는 훌륭한 시연이라고 생각합니다. 매우 특정한 문제 세트를 가진 확립된 스튜디오가 수년간 기초를 다지는 대신, 프레임워크를 가져와 자신들의 게임을 중심으로 설계된 엔진을 구축할 수 있다는 것을 말입니다. Ludeon이 이룬 성과에 대해서는 그들의 Steam 발표에서 더 읽어보실 수 있습니다.

그들은 자체 테스트에서 2배에서 4배의 성능 향상을 보고했으며, 기존 모드의 대다수는 여전히 호환성을 유지하고 있습니다. 새로운 엔진은 현재 RimWorld의 불안정한 베타 브랜치를 통해 이용 가능합니다. 이것은 놀라운 공학적 성과이며, BRUTAL이 이 과정에 일부 기여할 수 있게 되어 매우 기쁩니다. Kitten Space Agency는 저희의 무료 우주 비행 시뮬레이션 게임이며, 저희가 BRUTAL을 직접 사용하여 구축한 첫 번째 주요 프로젝트입니다. 영감은 Kerbal Space Program에서 얻었으며, 그러한 종류의 게임을 더 발전시키고자 하는 열망이 있었습니다. 우리는 범용 엔진이 만든 가정들 때문에 하고 싶은 것을 포기하지 않으면서도, 엄청난 규모와 높은 정밀도의 복잡한 물리학을 가진 우주 비행을 시뮬레이션하고 싶었습니다. 또한 이 프로젝트에는 제가 함께 일할 수 있었던 가장 특별한 개발자 그룹 중 한 명이 모였습니다. Kerbal Space Program의 원작자인 Felipe Falanghe가 프로젝트 방향을 이끌고 있습니다. Stefan Moluf는 SpaceX에서 거의 12년 동안 실제 우주선의 비행 소프트웨어를 작성한 후 저희 팀에 합류했습니다. 실제로 로켓을 프로그래밍하는 것을 도왔던 사람이 이제 가짜 로켓을 프로그래밍하는 것을 도와주고 있다는 것이 다소 터무니없게 느껴집니다. 또한 Kerbal 모딩 커뮤니티에서 가장 영향력 있는 사람들을 몇 명 보유하고 있습니다. Casper는 저희의 지형 및 행성 표면에 대해 작업합니다. Scatterer를 만들고 KSP에서 시각적으로 가능한 것을 변화시키는 데 도움을 준 Blackrack은 대기 렌더링 및 관련 시스템을 담당합니다. Kerbal Space Program의 전임 리드 엔지니어이자 QA 매니저였던 Jamie Leighton (JPLRepo)은 KSP 개발과 가장 중요한 모드 제작 경험 모두에서 광범위한 지식을 가져왔습니다. 이들은 이미 Kerbal Space Program 같은 게임으로 가능한 한계를 밀어붙이는 데 수년의 시간을 보낸 사람들입니다. 이제 우리는 그들에게 자신이 원하는 방식으로 작업을 수행할 수 있도록 근본적인 기술에 대한 직접적인 접근 권한을 제공하고 있습니다.

이 게임은 복잡한 궤도 운동, 거대한 거리, 그리고 렌더링, 좌표, 시뮬레이션에 대한 매우 다른 요구 사항을 가진 태양계를 실제 규모로 구동합니다. 이 발표에서 중요한 부분은 이것들이 전통적인 게임 엔진을 중심으로 구축되지 않았다는 것입니다. 우리는 BRUTAL을 사용하고 KSA가 실제로 필요로 하는 시스템을 개발합니다. Kitten Space Agency는 Ahwoo를 통해 완전히 무료인 프리 알파 버전으로 이용 가능합니다. 다운로드하여 직접 기술을 확인해 볼 수 있습니다. Kerbal Space Program의 제작자인 Felipe Falanghe와 저는 DayZ를 만들던 시절에 처음 만났고, 게임 산업에 대한 우리의 생각 방식에서 즉각적인 유대감을 느꼈습니다. 우리가 Kitten Space Agency를 만들기 시작했을 때 재회했습니다. 제 생각에 Felipe는 우리 업계에서 가장 저평가된 개발자 중 한 명입니다. 그는 과학자와 우주인들이 언급하는 등 우리 세대의 가장 영향력 있는 게임 중 하나를 만들었습니다. 하지만 저는 그가 마땅히 받아야 할 인정만큼 받지 못했다고 생각합니다. 또한 그는 BRUTAL을 사용한 최초의 외부 개발자였습니다. 그의 팀이 외부 사용자로서 참여했다는 것은 프레임워크가 개발자 사용 측면에서 진정으로 독립적(agnostic)임을 보장하는 데 엄청나게 유용했습니다. Felipe와 저는 작년 말 Game Developer와 BRUTAL에 대해 이야기한 적이 있습니다. 그는 무언가를 매우 잘 설명할 수 있는 환상적인 습관을 가지고 있는데, 특히 제가 너무 감성적으로 설명을 하려는 경향이 있을 때 더욱 그렇습니다. 그는 BRUTAL로 작업하는 것을 Godot과 같은 엔진을 사용하는 다른 사람들이 편안한 소파에 앉아 있는 동안 바 의자(bar stool)에 앉아 있는 것에 비유했습니다. 저는 그것이 정말 환상적인 설명 방식이라고 생각합니다. 아마도 가장 흥미로웠던 부분은 Felipe가 프레임워크 자체에 접근하는 방식이었습니다. 엔진이 무언가를 어떻게 기대하는지부터 시작하기보다는, 문제 자체에서부터 시작할 수 있었습니다. 한 예는 렌더링에서 고정밀 좌표를 사용하는 것이었습니다. 그는 자신의 접근 방식으로

Felipe가 BRUTAL을 사용해 다음 게임을 만들고 있습니다. 저는 그에 대해 세부적으로 설명하지 않으려고 하는데, 그것은 그가 이야기할 이야기이기 때문입니다. 그리고 Felipe는 이야기를 할 때 사람들을 사로잡는 종류의 사람입니다. 제가 그가 준비하는 것을 봤는데, 모두가 그걸 보는 것이 기대됩니다. 그의 경험을 가진 사람이 프레임워크와 직접 작업하고, 우리의 결정에 도전하며, 문제를 다르게 접근하는 것은 엄청나게 가치 있었습니다. 당신은 도구만큼만 독립적입니다. 저는 Unity와 Unreal이 개발자들에게 책임을 지지 못하는 것을 꾸준히 목격해 왔습니다. 그리고 이 문제는 에이전트 워크플로우(agentic workflows)가 기존 소프트웨어 기업들을 보호해 온 경쟁 우위를 훼손하기 시작하면서 훨씬 더 나빠질 수 있다고 생각합니다. 저의 걱정은, 그러한 우위가 침식됨에 따라 관련된 회사들이 스위칭할 수 없다고 느끼는 개발자들로부터 점점 더 많은 수익을 추출하려고 할 것이라는 점입니다. 로열티(royalties), 구독료(subscriptions) 또는 더 제한적인 라이선싱(licensing)을 통해서 말이죠. 제가 GDC에 참석할 때면 종종 Tencent Summit에 가는데, 그곳에서 Epic의 CEO인 Tim Sweeney가 기조연설을 했습니다. Tim은 오랫동안 저의 영웅이었습니다. 어린 시절 존경했던 마음을 가진 강력한 프로그래머였습니다. 하지만 시간이 지나면서 논의의 상당 부분이 최신 유행어(buzzwords)를 중심으로 돌아가는 것 같아 좌절감을 느꼈습니다. 어느 해는 메타버스였고, 다음 해는 AI였습니다. 그동안 개발자들은 성능(performance), 안정성(stability), 그리고 엔진 공급업체들이 내린 결정들의 실질적인 결과와 씨름하고 있었습니다. GDC 2025에서 질의응답 시간에 저는 Tim에게 Unreal이 특히 성능과 안정성 측면에서 개발자들에게 책임을 지고 있다고 생각하는지 물었습니다. 그의 답변은

저는 그의 답변에 만족하지 못했고, 언리얼(Unreal)이 개발자들에게 충분히 책임감을 느끼지 못한다고 계속 믿습니다. 특히 라이선스 임계점을 초과하는 게임 수익에 대해 5%의 로열티를 부과할 수 있다는 점을 고려하면 더욱 그렇습니다. 저는 개발자들이 이러한 관계를 의문 없이 받아들여야 한다고 생각하지 않습니다. 유니티(Unity) 역시 개발자들과 관련하여 공론화된 문제들을 여러 차례 겪었으며, 이는 에세이 한 편 분량으로 다룰 만큼 충분합니다. 아이러니하게도, 제가 이 글을 쓰는 지금도 유니티 개발자들은 필수 보안 변경과 관련된 계정 정지 문제를 처리하고 있습니다. 필요한 절차를 따랐음에도 접근 권한을 잃은 사람들이 있습니다. 유니티의 비즈니스 결정들은 게임 산업 전반에 걸쳐 반복적으로 불안정한 파장을 일으켜 왔습니다. 당신이 전혀 통제할 수 없는 회사의 결정에 따라 자신의 게임 개발 능력이 좌우된다고 상상해 보십시오. 하지만 저는 이 모든 것이 개발자들이 내일 당장 유니티나 언리얼을 포기해야 한다는 의미는 아니라고 생각합니다. 많은 프로젝트에서 여전히 최적의 선택지입니다.