지난 십여 년 인디의 기본 출발이 Unity 프로젝트를 열고 씬 트리에 물건을 놓는 일이었다면, 2026년 10월 중순에 겹친 두 공식 발표는 그 습관을 옆에서 밀었다. 10월 12일 Ludeon Studios는 RimWorld 1.7을 자체 엔진 Waylith로 옮긴다고 밝혔고, 자체 테스트에서 성능이 약 2~4배가 됐다고 했다. 사흘 뒤 Ahwoo와 RocketWerkz는 여러 자체 타이틀을 받쳐 온 C# 프레임워크 BRUTAL을 GitHub에 올리고 NuGet 패키지까지 공개했다.
나는 GitHub README, Ludeon 공식 블로그, Dean Hall의 r/gamedev 장문을 전재한 GameFromScratch, 그리고 Game Developer 10월 19일 보도를 맞춰 보았다. 못 박을 수 있는 사실은 많지 않다. BRUTAL은 스스로를 프레임워크라 부르며 완전한 엔진이 아니라고 쓴다. 에디터도 씬 그래프도 렌더러도 없고, 그걸 더하지 않겠다고 명시한다. Ludeon의 감사 문구는 조심스럽다. Brutal framework가 "helped make Waylith possible"이라고 되어 있다. Waylith를 가능하게 도왔다는 뜻이다. 공식 문장은 엔진 전체를 RocketWerkz에 외주했다고 쓰지 않는다.
이 글을 관통하는 이미지는 일부러 불완전함이다. 홍보 문장처럼 들리지만, 코드와 라이선스에 내려놓으면 검증 가능한 거부 목록이 된다.
1. 업계 기본값, 엔진이 아키텍처 선택을 먼저 끝낸다
오랫동안 인디 팀과 중소 스튜디오는 엔진 선택을 플랫폼 선택처럼 다뤘다. Unity, Unreal, 이후 Godot는 각각 에디터, 씬 그래프, 에셋 파이프라인, 스크립트 모델, 기본 렌더 경로를 들고 온다. 프로젝트를 연 순간 이미 남의 세계 가정 안에 들어간다. 카메라를 어떻게 걸지, Prefab을 어떻게 인스턴스화할지, 물리가 어느 레이어에서 Tick 할지, GC가 어떤 프레임에 고개를 들지. 이런 질문은 종종 게임플레이보다 먼저 엔진이 답한다.
대부분 프로젝트에서 이 기본값은 타당하다. 먼저 그림, 그다음 놀이 문턱을 낮추고, 채용과 외주에 공통 언어를 준다. 문제는 다른 종류의 게임에서 난다. 우주 비행 시뮬은 실제 스케일로 위치를 추적해야 한다. 식민지 시뮬은 후기 수천 엔티티와 대량 모드를 같은 프레임 예산에 밀어 넣어야 한다. 철도나 백과형 작품은 고전 씬 그래프가 필요 없을 수도 있다. Dean Hall은 r/gamedev 장문(GameFromScratch가 전문 전재)에서 직설한다. 현대 범용 엔진은 평균 사례에 맞춰 조율되며, 게임이 평균에서 멀수록 개발 시간은 게임에 무엇이 필요한지보다 엔진 가정에 맞추는 데 먹힌다고.
RocketWerkz 자사의 Kitten Space Agency가 그 평균에서 먼 사례다. 공개 자료에서 반복되는 요구는 위치 표현, 렌더 타이밍, 메모리 할당 리듬이다. Hall에 따르면 BRUTAL은 약 4년에 걸쳐 소수의 라이브러리에서 게임 전체나 엔진 전체를 지탱할 프레임워크로 자랐다. 처음엔 밖에서 보면 적신호에 가깝고, 팀 안에서도 비밀이었다. 2026년 10월에는 이미 KSA를 직접 떠받치고 Ludeon의 Waylith에도 들어갔다.
기본 논리와 BRUTAL의 갈림길이 여기다. 완전한 엔진은 아키텍처 선택을 대신 끝낸다. BRUTAL은 선택을 돌려주고, 먼저 무엇을 할지 알아야 한다는 점을 제품 기질에 쓴다. Hall 자신도 인정한다. 어떤 사람에게는 더 어렵지만, 팀이 만들고 싶은 종류의 게임에서는 오히려 빠르다. 엔진 저자가 어떻게 의도했는지 몇 주를 파고든 뒤 그 가정을 우회할 필요가 줄기 때문이다.
2. 거부 목록, 에디터 없음, 빗나간 PR 거절, 필요한 NuGet만
README는 BRUTAL이 아닌 것을 기능 목록보다 더 선명히 쓴다. 에디터도 씬 그래프도 없다. 렌더러도 범위 밖이며 더하지 않는다고 밝힌다. 내부에 더 넣자는 압력에도 저항한다. 분명한 용도에서 벗어난 Pull Request는 거절된다. 이유는 단단하다. 무엇이든 쑤셔 넣는 길이 바로 쓰고 싶지 않은 엔진으로 가는 길이라는 주장이다.
자세만의 이야기가 아니다. 검증 가능한 패키지 구성과 대응한다. 저장소 각 최상위 폴더가 하나의 라이브러리이고 각각 NuGet으로 나간다. `Brutal.Core`, `Brutal.Interop`, `Brutal.Memory`, `Brutal.Collections`, `Brutal.Strings`, `Brutal.Concurrency`, 수학과 수치, 로깅과 로컬라이즈에 더해 Vulkan / OpenGL, GLFW / SDL, Dear ImGui, FMOD / OpenAL, RakNet, Jolt / Box2D, glTF와 텍스처 디코드 등의 바인딩이 있다. 필요한 것만 참조하면 된다. 입문 예제는 Core와 Glfw만으로 그래픽 API 없는 창을 연다. 렌더, 디버그 UI, 잡, 오디오, 네트워크는 다음에 스스로 연결한다.
핵심은 커스텀 interop 층으로, 현대 C#이 네이티브 API와 고성능 C/C++ 라이브러리(Vulkan 포함)에 직접 닿게 한다. 주변 라이브러리는 할당과 불필요한 오버헤드를 줄이는 데 집착하고, 도움이 되는 곳에서는 비관리 메모리와 unsafe를 쓴다. README 전제 조건은 .NET 10 SDK, 렌더하려면 Vulkan 1.3 GPU, 현재 공개 나열 플랫폼은 Windows와 Linux다.
일부러 불완전함에는 두 층이 있다. 기능 경계에서는 씬을 그려 주지 않고 노드도 정렬해 주지 않는다. 렌더러도 스스로 쓴다. 공학 단위에서는 능력을 골라 담을 패키지로 나누고, 통째로 실어야만 움직이는 거석으로 만들지 않는다. Hall은 Linux 커널과 Ubuntu 관계에 비유한다. 정확하진 않지만 의도는 통한다. BRUTAL이 기초를 주고, 배포판 형태의 엔진은 각 팀이 만든다. Kitten Space Agency는 BRUTAL 위에 직접 선다. Ludeon은 그 위에 Waylith를 짓는다.
Ahwoo 엔지니어링 책임자 Rian Drake는 보도자료에서 이름 유래를 못 박는다. BRUTAL이라 부르는 이유는 쓸 때 때로 가혹하기 때문이고, 미리 말하고 싶어서라고. 가드레일은 없다. 자신이 짠 시스템과 저지른 실수에 책임지며, 동시에 바로잡을 권한도 있다. GamingOnLinux 등 이차 보도가 이 문장을 전한다. Drake는 이어, 모두가 이 도구로 게임을 만들어야 한다고 생각하지 않는다고도 말한다.
3. Waylith 장면, helped와 엔진 통째 외주 사이의 말씨
Ludeon 10월 12일 블로그는 이 기술 뉴스에서 가장 말씨를 따져야 할 1차 자료다. 업데이트 1.7은 RimWorld를 Unity에서 Waylith로 옮긴다. Waylith는 Ludeon 자체 엔진이라고 명시된다. 모습과 플레이는 같고, 테스트에서 성능은 약 2~4배. 후기 식민지 스트레스 테스트는 1.6 대비 약 2.2배. 1,500개 모드 팩은 로딩이 14분에서 6분으로. 세이브는 1.6과 1.7을 오갈 수 있다. 대다수 모드는 제작자 수정 없이 동작한다. 말미 감사는 thanks to RocketWerkz, whose Brutal framework helped make Waylith possible다.
helped라는 단어가 중요하다. 공개 서술에서 Waylith는 여전히 Ludeon의 엔진 결정과 구현 산물이다. BRUTAL은 저수준 C# 프레임워크 능력을 제공해 Unity의 남은 조각을 벗겨 내는 데 도왔다. Ahwoo 보도자료(여러 매체가 전재)도 비슷한 어조로 Ludeon used BRUTAL to help extract the last bits of Unity out of RimWorld to create their Waylith engine이라고 쓴다. RimWorld 엔진 전체를 RocketWerkz에 외주했다고 읽는 것은 공식 문장과 맞지 않는다. 자료 관찰상 더 안전한 읽기는 Ludeon이 Waylith를 직접 지었고, BRUTAL은 감사를 받은 저수준 프레임워크 중 하나라는 쪽이다.
모더를 향해 Ludeon은 몇 가지 변화도 적는다. 더 새 C# 언어 기능을 쓸 수 있다. 복잡한 모드를 써도 성능을 덜 짓누른다. 큰 비주얼 변경과 커스텀 이펙트에 손이 닿기 쉽다. 스무 명이 넘는 모더가 Waylith 공개 전 테스트와 피드백에 참여했다. 이 세부는 엔진 이전이 렌더 백엔드 교체로 끝나지 않음을 보여 준다. 후기 식민지에 거대 모드 목록을 실은, RimWorld에서 가장 비싼 경로를 유지 가능한 .NET 스택에 다시 박는다.
README 프로젝트 표는 사용 관계를 펼친다. RimWorld / Ludeon / Waylith. Kitten Space Agency, Torpedia, Art of the Rail, Gruntz는 RocketWerkz가 BRUTAL 위에 직접 구축. Afterskies는 Floating Origin Interactive. Ahwoo 보도자료는 또한 현재 세 스튜디오 여섯 게임 프로젝트를 받친다고 한다. Kerbal Space Program의 Felipe Falanghe가 KSA에 협력하고 다음 작품에도 BRUTAL을 쓴다는 언급이 있다. Unity에서 BRUTAL로 옮긴 소감은, 처음엔 조금 겁났지만 들어가면 자신이 만든 모든 것을 소유하고 어떻게 도는지 안다는 것이다.
4. 라이선스, 독립 슬로건, 일부러 불완전함을 쓰는 법
BRUTAL은 상용 게임에도 무료이며 로열티도 매출 배분도 없다. 라이선스는 MIT를 바탕으로 귀속 요건을 더한 것이다. 크레딧 또는 동등한 곳에 저작권 고지를 넣고, 플레이 시작 전 BRUTAL 로고를 보여 주며, NOTICE.txt를 함께 배포해야 한다. 조건을 맞추고 싶지 않으면 별도 상용 라이선스를 협의할 수 있다. 비영리, 그리고 로고 표시가 용도를 해치는 경우에는 README상 로고 면제가 가능하다. 라이선스는 아직 OSI에 제출되지 않았고, 팀은 제출과 커뮤니티 피드백에 따른 개정을 의도한다고 쓴다. 일부 이차 보도는 그래서 source-available이라 부르기를 선호한다. 1차 README는 여전히 open source라 자칭하며 MIT 계열 문서와 fork 가능성을 근거로 든다. 이 글 본문에서는 README 自称에 맞춰 오픈소스라 쓰고, OSI 상태는 출처 주에 두어 미승인을 승인된 것처럼 쓰지 않는다.
Hall은 서사를 한 문장으로 박는다. You are only as independent as your tools are. 독립의 정도는 도구가 아직 당신의 말을 듣는지에 달린다. 동시에 경계도 보완한다. 모두가 자체 엔진을 만들라는 말이 아니라, 모두가 4년을 들여 기초를 쌓지 않고도 그 선택지를 가져야 한다는 말이다. Game Developer 보도는 2025년 Unity 라이선스 분쟁의 공개 배경에도 닿고, Hall이 BRUTAL을 업계 단일 표준으로 올리기보다 비슷한 접근의 더 단순한 프레임워크가 다른 곳에서도 나오기를 바란다고도 전한다.
인디에게 이 슬로건은 격려로 들리기 쉽다. BRUTAL의 실체에 내려놓으면 고용 계약에 더 가깝다. 얻는 것은 interop, 할당을 줄인 컬렉션, 잡 시스템, Vulkan 바인딩, 스스로 배선할 네이티브 라이브러리 줄이다. 열자마자 플레이 가능한 프로토타입이 되는 에디터 경험은 없다. 공개 README는 소스에서 빌드할 프로젝트 파일, 솔루션, 빌드 스크립트가 아직 오는 중이며, 당분간 NuGet을 쓰고 저장소는 읽고 fork하는 데 쓰라고도 적는다. Indie Tooling 등 이차 정리는 공개 당일 문서 사이트가 일반에 열려 있지 않았을 수 있고, macOS·콘솔·모바일이 현행 README의 분명한 약속에 없다는 점도 지적한다. 이런 가장자리는 자료 관찰로 선정 체크리스트에 넣고, 성숙한 일체형 약속으로 쓰지 않는 편이 낫다.
그래서 인디 팀에게 일부러 불완전함의 실행 의미는 구체적이다. 먼저 게임이 평균 사례에서 먼지 본다. 평범한 2D/3D 콘텐츠 지향이면 Godot나 Unity, 더 완성된 프레임워크가 목숨을 덜 깎는 경우가 많다. 병목이 분명히 할당, 잡 스케줄링, 네이티브 연동, 스스로 써야 하는 렌더러라면 BRUTAL 패키지가 값을 내기 시작한다. Glfw나 SDL로 창을 열고, 아픈 Memory / Collections / Concurrency만 더하는 편이 첫날부터 자체 엔진 전모를 꿈꾸는 것보다 설계에 가깝다. LICENSE와 NOTICE를 읽고 로고와 크레딧을 릴리스 체크에 넣는다. Waylith 공개 숫자는 독려가 될 수 있지만 당신의 예산표는 아니다. Ludeon에는 기존 플레이, 모드 생태계, 수년의 C#이 있다. 당신 팀에 있다고 보장할 수 없다.
마무리, 독립은 무엇을 할지 먼저 아는 자리에서 다시 값이 매겨진다
BRUTAL을 2026년 가을 제작 현장에 되돌려 놓으면, 먼저 치는 것은 조용한 제작 관성이다. 엔진이 먼저이고 게임이 나중이며, 아키텍처는 에디터 마법사에 맡겨도 되고, 엔진 이탈은 거대 스튜디오만의 일이라는 기본값이다. RimWorld 1.7과 BRUTAL 공개가 같은 주에 겹치며 다른 길을 펼쳤다. 프레임워크 위에서 직접 게임을 만드는 사람도 있다. 그 위에 자체 엔진을 짓는 사람도 있다. 둘 다 바인딩을 연결하기 전에 요구사항을 적어 내려야 한다.
Hall은 Reddit 장문에서 가장 중요한 결정 중 하나가 BRUTAL에 무엇을 넣지 않을지라고 말한다. 거꾸로 읽어도 된다. 인디에게 가장 비싼 결정은 종종 무엇을 들여오지 않을지다. 기본 시스템이 하나 줄면, 이해하지 못한 채 우회해야 하는 가정도 하나 줄어든다. 자체 책임이 늘면, 문제가 났을 때 뿌리까지 고칠 권한도 는다. 양쪽 다 가혹하다. BRUTAL은 적어도 그 가혹함을 이름에 썼다.
실행용 짧은 지침은 다음과 같다.
- 먼저 세 목록을 쓴다. 게임이 스스로 정해야 하는 아키텍처, 기존 엔진에 맡겨도 되는 부분, 팀이 유지할 수 있는 네이티브 경계. 셋이 맞지 않으면 아직 BRUTAL을 건드릴 때가 아니다.
- NuGet으로 최소 실험을 한다. Core와 창 패키지로 창을 열고, 아픈 곳에 맞춰 Memory, Collections, Concurrency 또는 Vulkan 추상을 더한다. 주말 동안 자체 스택이 엔진에 맞추는 일보다 정말 빠른지 본다.
- LICENSE를 읽고 기획한다. 크레딧, 시작 로고, NOTICE.txt를 릴리스 검사표에 넣는다. 면제가 필요하면 서면으로 받고, 출시 직전에 발견하지 않는다.
- Ludeon 감사에서는 helped를 본다. 자체 엔진은 여전히 당신의 제품 결정이다. 프레임워크는 4년치 기초 비용만 낮출 뿐, 플레이와 내용은 스스로 진다.
10월의 두 소식은 범용 엔진을 없애지 않는다. 도구가 아직 당신의 말을 듣는지라는 값을 다시 매겼을 뿐이다. 그 값을 치를 사람에게는 적어도 읽을 수 있는 소스, 고를 수 있는 패키지, README에 이미 적힌 경고가 있다. 이름은 BRUTAL이다. 사교적 수사가 아니다.
출처와 더 읽기
ahwootech/BRUTAL, GitHub README (main에서 수집)
Tia Young, Ludeon Studios (2026-10-12) Announcing the Waylith Engine and Update 1.7
GameFromScratch (2026-10-15) BRUTAL C# Game Framework Now Free (Dean Hall r/gamedev 장문 요점 전재)
GameFromScratch (2026-10-14) RimWorld Dump Unity Game Engine
Liam Squires-Hand, GamingOnLinux (2026-10-16, 이차 보도·보도자료 전술) BRUTAL… releases its source code