오래된 멀티플레이어 게임을 현대 웹 기술로 되살리는 작업은 생각보다 까다롭다. 기존 서버·클라이언트 생태계를 그대로 유지하면서도, 설치 없이 접속할 수 있는 경험을 얹어야 하기 때문이다. Battlezone Online(bzo)은 이 문제를 정면으로 다룬 오픈소스 프로젝트다. 20년 넘게 이어져 온 3D 탱크 대전 게임 BZFlag를 브라우저 안으로 끌어들여, 데스크톱과 스마트폰은 물론 VR 헤드셋에서도 아무것도 설치하지 않고 바로 플레이할 수 있게 만들었다.
핵심은 호환성이다. bzo는 완전히 새로운 게임을 만든 것이 아니라, 기존 BZFlag 클라이언트 및 서버와 그대로 어울려 돌아가는 웹 레이어를 올렸다. 공개 서버 목록은 bz.rikers.org/list에서 확인할 수 있으며, 여기에는 bzo 서버뿐 아니라 그 서버들이 프록시하는 BZFlag 서버까지 함께 나열된다. 목록의 한 줄을 클릭하면 바로 해당 게임에 입장하고, Launch 링크는 설치된 BZFlag 클라이언트에서 bzflag:// 프로토콜로 서버를 여는 방식도 지원한다. 즉 웹 접속자와 기존 네이티브 사용자가 같은 공간에서 만날 수 있다는 뜻이다.
통신 계층과 배포 구조
서버는 Node.js로, 클라이언트는 Three.js로 작성됐고, 통신에는 WebSocket·WebTransport·WebRTC가 함께 쓰인다. 하나의 전송 방식에 의존하지 않고 환경에 따라 가용한 채널을 활용하는 구조다. 배포 측면에서는 Docker가 권장 경로로 제시된다. GitHub Container Registry에서 받는 이미지는 linux/amd64와 linux/arm64 두 아키텍처를 모두 포함하므로, x86 서버든 ARM 기반 장비든 동일하게 다룰 수 있다. 이미지는 Ubuntu 26.04 위에서 우분투가 제공하는 nodejs 패키지(Node.js 22)로 빌드되며, CI도 같은 Node 버전을 쓰는 Ubuntu 26.04 컨테이너에서 돈다. 소스 tarball이나 git 체크아웃으로 직접 설치할 수도 있지만, 대부분에게는 설치와 업데이트가 간결한 Docker 쪽이 낫다는 것이 프로젝트의 입장이다. 리버스 프록시 뒤에서 운영하거나, 자신의 서버를 목록에 등록하거나, BZFlag 서버를 프록시하는 방법은 설치 문서에 정리돼 있다.
VR을 1급 시민으로 다룬 설계
bzo에서 눈여겨볼 지점은 VR 지원을 부가 기능이 아니라 처음부터 고려한 흔적이다. VR 모드는 네이티브 WebXR을 사용하며 immersive-vr을 지원하는 브라우저와 헤드셋을 요구한다. 로컬 검증은 http://localhost:5154에서 가능하지만, 원격 접속은 반드시 https로 제공해야 한다. 페이지가 HTTPS로 서빙되면 클라이언트는 WebSocket 연결도 자동으로 wss://로 전환한다. TLS는 서버 자체 인증서나 리버스 프록시 중 하나로 처리하면 된다.
헤드셋 브라우저가 설치된 앱을 실행할 때는 2D 랜딩 페이지 없이 곧장 VR로 들어가려 한다. 이를 위해 xr-launch.js는 나머지 클라이언트가 로드되기 전에 세션을 요청하고, 몰입형 세션에 필요한 사용자 활성화가 담길 수 있는 신호마다, 즉 window load, focus, page show, visibility change, 그리고 Launch Handler마다 반복해서 요청을 건다. 어느 신호에서도 세션이 잡히지 않으면 버튼에서 VR 모드를 시작한다. 저장된 이름이 있으면 즉시 입장하고, 없으면 2D 입장 대화상자와 동일한 이름·팀·탱크 선택지를 담은 Join 화면이 XR 메뉴에 뜨도록 해, 플레이어가 볼 수 없는 화면에서 무언가 멈추는 일을 피했다. 다만 세심한 제약도 남아 있다. Chrome on Android가 Cardboard를 통해 모든 폰에서 immersive-vr 지원을 보고하기 때문에, 원탭 VR 버튼은 실제 헤드셋이 있는 기기에서만 노출되고 안드로이드 폰에서는 설정 메뉴 안에 머문다. XR 입력은 헤드셋의 시스템 키보드를 쓰는데, Quest Browser 26.1 이상이 이를 제공하며 그렇지 못한 헤드셋에서는 해당 입력 행이 Desktop only로 표시된다.
실무자가 눈여겨볼 지점
운영자 입장에서 유의할 세부가 몇 가지 있다. 배포 환경이 제한적인 Permissions-Policy 헤더를 설정한다면 xr-spatial-tracking=(self)를 허용해야 VR이 동작한다. 새 브라우저·헤드셋·배포를 점검할 때는 WebXR 검증 체크리스트를 쓰도록 안내하는데, WebGPU 렌더링은 이 체크리스트의 범위 밖이라는 점은 분명히 못 박아 둔다. 또한 WA(Wide Angle) 같은 깃발은 BZFlag의 모든 플래그를 그대로 싣되, VR에서는 헤드셋이 투영을 담당하므로 시야각을 넓히는 효과가 실제로는 아무것도 하지 않는 식으로, 원작과의 호환을 유지하면서 환경 차이를 흡수한다.
라이선스 문제는 이 프로젝트가 솔직하게 미완성임을 인정하는 영역이다. 코드는 AGPLv3를 따르지만, 모델·텍스처·사운드·맵 같은 에셋은 출처가 제각각이다. 일부는 BZFlag 프로젝트의 것이고, 일부는 bzo를 위해 제작됐으며, 일부는 기여와 함께 들어왔다. 프로젝트는 "파일이 저장소 안에 있다는 이유만으로 저장소의 라이선스를 물려받지는 않는다"는 원칙을 명확히 하면서, 출처가 기록되지 않은 에셋은 앞으로 풀어야 할 과제로 남겨 둔다. 서버에서 내려받거나 클라이언트가 저장한 맵 역시 별도의 권리 부여가 따라오지 않는다는 점을 함께 짚는다. AGPLv3 특성상 네트워크 사용자는 실행 중인 앱의 /source 경로에서 소스 코드에 접근할 수 있다.
릴리스 규율도 흥미로운 대목이다. 릴리스 태그는 vX.Y.Z 형식의 안정 SemVer만 사용하고 프리릴리스나 빌드 메타데이터는 발행하지 않는다. 태그는 트리를 가리키므로 작업 디렉터리에 커밋되지 않은 변경이 남아 있으면 그 내용은 릴리스에 포함되지 않는다는 점, 그래서 태그 전후로 git status가 깨끗해야 한다는 점을 반복해 강조한다. 클라이언트가 보고하는 버전 문자열을 담는 public/version.mjs는 스크립트가 생성하고 태그에 대해 검증하므로 손으로 고치지 말라는 지침도 있다. 워크플로가 실패한 릴리스는 태그를 지우거나 옮기지 않고 그대로 두되 원인을 고쳐 다음 버전으로 넘어가며, CHANGELOG가 그 기록을 대신한다. 재현 가능성을 중심에 둔 이런 운영 규칙은 소규모 오픈소스 프로젝트가 배포 혼란을 피하는 방식으로서 참고할 만하다.