Babylon.js와 타입 스크립트로 프로젝트를 시작했습니다

그 동안 취미로만 게임 관련 코딩을 하다 처음으로 회사 프로젝트로 3D 관련 개발을 하게 됐습니다.

이런저런 이유로 WASM을 쓰기에는 무리가 있다 판단해서 직접 웹 프로젝트로 개발할 수 있는 기술을 찾아보니 Three.js와 Babylon.js가 있더군요.

API를 훑어보니 전자는 간단한 시각화 같은데 보다 적합할 느낌인데, 바빌론의 경우 거의 게임엔진에 필적할 정도의 기능을 제공하는 듯 해서 일단 그 쪽으로 방향을 잡고 초기 구현을 하는 중입니다.

원래는 지난 프로젝트에 사용했던 코틀린.js를 그대로 쓰려고 했지만 그런 수준의 방대한 API에 대한 래퍼를 만드는 건 간단한 일이 아니더군요.

Dukat이라는 자동화 도구가 있긴 한데 버그도 있고, 직접 문제를 고쳐가면서 돌려도 1,000개 넘는 컴파일 오류가 발생했습니다.

중복되는 내용이 많아서 손으로 고치자면 큰 문제까진 아닐 것 같은데, 이걸 바빌론 버전 올라갈 때마다 해야하나 생각하니 끔찍하더군요. 그래서 그냥 차라리 타입스크립트를 쓰는 것이 낫겠다고 결정했습니다.

역시 프론트엔드 쪽이 발전이 빠르다 보니 개발 관련 생태계는 참 좋더군요. 코틀린 사용시 수정할 때 마다 그레이들 웹팩 태스크가 돌던 걸 보다가 Vite에서 즉각 결과가 반영되는 걸 보니 나쁜 선택은 아니었단 생각이 듭니다.

아직 깊이 있게 써보진 않았지만, 바빌론을 보니 조만간 최소한 인디 3D 게임 정도는 유니티나 고도로부터 지분을 뺏어올 수 있을 것 같다는 생각이 듭니다.

게임 엔진을 통한 개발이 비개발자도 쉽게 게임 콘텐츠를 생산할 수 있다는 점에선 장점일 지는 몰라도 개발자 입장에선 답답한 면이 있는 것이 사실입니다.

웹 개발 같이 오픈소스 생태계가 잘 되어 있는 것도 아니고, 게임 엔진이 제공하는 API가 스프링 같은 수준으로 깔끔하게 설계 되고 높은 확장성을 제공하는 것도 아닙니다.

무엇보다 게임 엔진이 강제하는 프로그래밍 모델이 너무 구닥다리라 웹 개발 같은 분야에서 현 시점에 널리 사용하는 개발 관행이나 설계 방식을 적용하기 힘든 문제가 큽니다.

그런데 바빌론의 경우 웹 기반이라 프론트엔드 기술과의 접점을 통해 그런 추세를 어느정도 반영할 수 있는 여지가 보입니다.

예컨대, 바빌론 API를 리액트 컴포넌트로 제공하는 프로젝트가 있는데, 예시를 보면 역시 전통적인 게임 엔진의 접근 방식과 리액트의 상태 관리 개념 사이에 발생하는 충돌이 보입니다. 하지만, 적어도 비슷한 시도를 하려면 리액트 같은 것부터 직접 만들어야 하는 기존 게임 엔진을 이용한 개발보단 확실히 더 진보한 모양이라고 생각합니다.

웹 표준에도 WebGPU 등 게임에 적합한 내용이 계속 추가되고 있고 바빌론도 이미 인디게임 정도는 만들 수 있는 수준의 기능을 제공하는 것을 보면, 아마 시간이 갈수록 웹 프론트엔드 분야의 개발자나 그 쪽에서 사용하는 관행이 게임 분야에도 영향력을 미치기 시작할 것 같다는 생각이 듭니다.