로블록스로 만들면 안 될까: 부적합 판정을 받은 플랫폼과, 같이 부적합했던 웹

기술 선택 검토 노트에서 한 대목만 옮깁니다. 결론보다, 그 결론이 뒤집힌 과정이 남을 만해서입니다.

"로블록스나 앱 같은 친숙한 환경에는 무리가 있을까?"

새 엔진을 배우는 비용을 피하고 싶었습니다. 이미 익숙한 도구가 있는데 굳이 돌아가야 하나 싶었습니다.

• 성능: 스크립트 런타임(Luau)은 수천 명 규모의 개별 시뮬레이션을 감당하도록 설계된 것이 아닙니다. 검토 당시 판단으로는 100명 수준에서도 지연이 생길 가능성이 높다고 보았습니다. 대규모 데이터 처리를 위한 아키텍처도 그곳에서는 쓸 수 없습니다.
• 데이터: 크루 한 명 한 명의 경험치와 계급, 스킬을 장기간 누적해 저장해야 하는데 제약이 많습니다.
• UI: 함대 현황, 크루 목록, 능력치 비교처럼 정보 밀도가 높은 화면을 만들기에 불편합니다.
• 플랫폼 정체성: 진중한 전략 시뮬레이션은 그곳 이용자들이 기대하는 경험과 결이 다릅니다.

프로토타입으로는 쓸 수 있지만 본 게임의 터전으로는 아니다, 가 결론이었습니다.

HTML5/JavaScript — 성능 한계 명확, 복잡한 시뮬레이션에 부적합. 가볍고 간단한 게임에 적합.

웹도 비추천이었습니다. 로블록스와 같은 칸이었던 셈입니다. 그래서 Unity로 갔고, 처음부터 데이터 지향 아키텍처를 전제로 설계했습니다.

비추천 판정이 틀렸던 걸까요. 그렇지는 않다고 봅니다. 표가 재던 것은 플랫폼의 성능이었고, 실제로 결과를 가른 것은 다른 지점이었습니다. 덧붙이면 지금 웹에서 돌리는 것은 함대 전투 시뮬레이션이며, 초기 구상에 있던 수천 명 규모의 크루 개별 시뮬레이션을 웹이 감당한다는 뜻은 아닙니다.

이 구조 덕분에 옮길 때 다시 만든 것은 렌더 레이어뿐이었습니다. 코어는 언어만 바꿔 건너왔고, 브라우저에서는 도트 그래픽을 그리는 얇은 층 하나만 새로 얹었습니다.

돌아보면 로블록스가 어려웠던 진짜 이유도 성능 수치가 아니었습니다. 그곳에서는 코어가 플랫폼 런타임에 묶입니다. 떼어내서 다른 곳으로 옮기기가 어렵습니다. 처음에 "여기서 시작해도 되나"를 물었지만, 정작 중요한 질문은 "여기서 시작하면 나중에 나갈 수 있나"였습니다.

이 글의 판단은 S3 World라는 특정 프로젝트의 요구사항을 기준으로 한 것입니다. 플랫폼의 성능과 기능은 계속 바뀌므로, 다른 프로젝트에서는 각자의 요구사항으로 다시 재어 보아야 합니다.