안녕하세요, 10년 차 개발자 김현수입니다.
요즘 사이드 프로젝트로 간단한 멀티플레이어 게임 하나 만들어볼까 고민하던 중이었어요.
근데 다들 아시잖아요. 멀티플레이어 게임 개발이란 게 정말 산 넘어 산이라는 거.
동기화(Synchronization) 맞추느라 머리 빠지고, 랙 보정(Lag Compensation) 하느라 밤새고, 클라이언트 변조 막느라 보안 신경 쓰고...
"아, 그냥 싱글 게임 만들까?" 하던 찰나에 재미있는 물건을 하나 발견했습니다.
바로 'Cleoselene'이라는 게임 엔진입니다.
이 녀석의 컨셉이 아주 도발적입니다.
"클라이언트 코드는 필요 없다. 서버가 다 그려서 보내준다."
처음엔 "에이, 그게 되겠어? 클라우드 게이밍(Stadia 같은) 말하는 건가?" 싶었는데, 자세히 들여다보니 접근 방식이 꽤 신선하더라고요.
오늘 커피 한 잔 하면서 이 신박한 엔진 이야기 좀 해볼까요?
1. 픽셀이 아니라 '그리기 명령'을 보낸다?
우리가 흔히 아는 클라우드 게이밍(GeForce Now, Xbox Cloud)은 서버에서 게임 화면을 렌더링한 뒤, 이걸 비디오 스트림(영상)으로 압축해서 클라이언트에 쏩니다.
당연히 대역폭을 엄청나게 잡아먹고, 네트워크가 조금만 불안해도 깍두기 현상이 생기죠.
그런데 Cleoselene은 'Primitives Streaming'이라는 방식을 씁니다.
쉽게 말해서, 서버가 "여기 빨간 네모 그려, 저기 파란 원 그려, 텍스트는 이거 써"라는 명령어(Draw Command)만 WebRTC로 쏘는 겁니다.
클라이언트는 뇌가 없습니다. 그냥 서버가 시키는 대로 브라우저 캔버스에 그림만 그리는 '더미(Dummy)'일 뿐이죠.
이게 왜 대박이냐면요.
데이터 전송량이 영상 스트리밍보다 훨씬 가볍습니다.
그리고 클라이언트에 게임 로직이 1도 없으니, 자연스럽게 보안 문제가 해결됩니다.
2. 10년 차 개발자도 감동한 포인트: 강제된 보안
솔직히 고백하자면, 저도 예전에 주니어 시절 만든 게임이 해킹당해서 멘탈이 나간 적이 있습니다.
클라이언트 메모리 변조해서 이동 속도를 10배로 만들거나, 벽을 뚫고 다니는 핵 유저들...
그거 막으려고 서버 검증 로직 넣다 보면 코드가 스파게티가 되기 십상이죠.
그런데 Cleoselene은 구조적으로 '월핵(Wall Hack)'이나 '에임봇'이 불가능합니다.
왜냐고요?
클라이언트는 "지금 내 눈앞에 보이는 것" 외에는 아무런 정보가 없거든요. 벽 뒤에 적이 있는지, 맵 전체 구조가 어떻게 생겼는지 클라이언트 코드는 알 길이 없습니다.
서버가 함수에서 으로 보이는 것만 딱 찝어서 보내주니까요.
게다가 소스 코드 유출 걱정도 없습니다.
Lua 스크립트가 서버에만 존재하니까, 클라이언트 단을 뜯어봐야 리버스 엔지니어링할 건덕지가 없는 거죠.
기업 비밀이나 독특한 알고리즘을 숨겨야 하는 프로젝트라면 꽤 매력적인 선택지 아닐까요?
3. 성능, Rust 형님이 지켜주신다
"아무리 그래도 Lua 스크립트로 서버에서 물리 연산 다 돌리면 느리지 않을까?"
저도 이 생각부터 들었습니다. Lua가 가볍긴 해도 연산이 많아지면 버겁거든요.
다행히 이 엔진, 꽤 영리하게 설계됐습니다.
핵심 로직인 물리 엔진(Physics)과 길 찾기(Pathfinding)는 Rust로 구현되어 있습니다.
우리는 Lua로 "이 물체 움직여!", "충돌했어?"라고 명령만 내리면, 무거운 계산은 뒤단에서 Rust가 미친 속도로 처리해 주는 구조입니다.
개발자는 Lua의 생산성을 챙기고, 엔진은 Rust의 퍼포먼스를 챙긴 셈이죠.
4. 코드를 보니... 이건 그냥 '싱글 게임' 개발인데?
API 문서를 쓱 훑어봤는데, 멀티플레이어 개발의 복잡함이 전혀 안 보입니다.
그냥 파일 하나에 , , 함수만 채워 넣으면 끝이에요.
-- 서버 루프 (30 TPS)
function update(dt)
phys:step(dt) -- 물리 계산 한 방에 끝
-- 충돌 처리 로직...
end
-- 클라이언트별 그리기
function draw(session_id)
-- 이 유저한테 보여줄 것만 그리면 됨
api.draw_text("HP: 100", 10, 10)
end상태 동기화? 패킷 직렬화? 예측 이동?
그런 거 없습니다. 그냥 하나의 루프 안에서 모든 게 돌아갑니다.
마치 2000년대 초반 플래시 게임이나 싱글 인디 게임 만들 때의 그 단순함이 느껴져서 좀 설레더군요.
5. 물론, 은탄환은 없습니다
너무 장점만 늘어놓았나요? 냉정하게 현실적인 제약도 짚어봅시다.
일단, 이 방식은 고사양 3D 게임에는 부적합합니다.
서버가 모든 드로우 콜(Draw Call)을 처리해서 보내야 하는데, 화려한 3D 그래픽 데이터를 실시간으로 프리미티브 단위로 쪼개서 보내는 건 무리겠죠.
현재 API도 , 같은 2D 기본 도형 위주입니다.
그리고 네트워크 레이턴시(지연)에 민감할 수밖에 없습니다.
클라이언트 예측(Client-side Prediction)이 없기 때문에, 핑이 튀면 입력 반응이 즉각적으로 밀립니다.
격투 게임이나 FPS처럼 0.1초가 중요한 장르보다는, 퍼즐, 턴제 전략, 혹은 가벼운 캐주얼 IO 게임에 딱 맞는 엔진입니다.
마치며: "빠르게 만들고, 빠르게 검증하라"
Cleoselene은 아직 초기 단계(Preview)입니다. 당장 상용화 프로젝트에 쓰기엔 리스크가 있죠.
하지만 "멀티플레이어 게임 프로토타입을 하루 만에 만들고 싶다"면?
이보다 더 좋은 도구는 없을 것 같습니다.
복잡한 네트워크 코딩 없이, 아이디어 하나만 가지고 친구들과 바로 테스트해 볼 수 있으니까요.
저도 주말에 시간 내서 간단한 '술래잡기' 게임 하나 뚝딱 만들어볼까 합니다. (Rust도 찍먹해 볼 겸 해서요)
혹시 아나요? 여기서 제2의 '뱀파이어 서바이벌' 같은 대박 아이디어가 나올지.
개발자 여러분, 기술 스택 고민만 하다가 밤새지 마시고 일단 뭐라도 만들어 보시죠.
우리의 코드는 실행될 때 가장 빛나니까요.
행복한 코딩 하세요!
