C로 만든 게임을 웹(WASM)으로 옮기며 만난 버그들 — 포팅 실전기

C로 만든 게임을 웹으로

여러분, '네이티브로 잘 돌던 프로그램을 웹으로 옮겼더니 안 돌더라'는 경험 해보셨나요? 한 개발자가 C로 만든 자기 게임 'Matchmorphosis'를 웹어셈블리(WebAssembly, 줄여서 WASM)로 포팅하면서 마주친 버그들을 하나하나 기록으로 남겼어요. 이게 같은 길을 갈 사람들한테는 보물 같은 지도거든요.

먼저 배경을 짚고 갈게요. WASM은 C, C++, 러스트 같은 네이티브 언어로 짠 코드를 브라우저 안에서 거의 네이티브에 가까운 속도로 돌릴 수 있게 해주는 기술이에요. 보통 Emscripten(엠스크립튼)이라는 도구로 C 코드를 WASM으로 컴파일하죠. 덕분에 다운로드·설치 없이 링크 하나로 게임을 돌릴 수 있게 됐는데, 막상 옮겨보면 곳곳에 함정이 숨어 있어요.

가장 흔한 함정들

1) 메인 루프 문제. 이게 거의 모든 게임이 처음 부딪히는 벽이에요. 네이티브 게임은 보통 while(1) { 입력받고; 갱신하고; 그리고; } 같은 무한 루프로 돌거든요. 그런데 브라우저에서는 이러면 화면이 그냥 멈춰버려요. 브라우저는 한 줄로 돌아가는(싱글 스레드) 구조라, 내 무한 루프가 제어권을 안 놓아주면 브라우저 자체가 화면을 그리지도, 클릭을 받지도 못하거든요. 그래서 Emscripten은 emscripten_set_main_loop라는 함수를 줘요. '한 프레임 분량만 실행하고 제어권을 브라우저에 돌려줘'라고 등록하는 방식이죠. 이 구조로 바꾸는 게 포팅의 첫 관문이에요.

2) 파일을 못 읽는다. 네이티브에서는 fopen으로 이미지나 사운드 파일을 디스크에서 척척 읽지만, 브라우저 안에는 그런 디스크가 없어요. 그래서 게임에 필요한 파일들을 미리 가상 파일시스템(MEMFS)에 담아두거나, 비동기로 미리 받아두는(preload) 작업이 필요해요. '분명 파일 경로 맞는데 왜 없다고 하지?' 하는 버그가 여기서 자주 나와요.

3) 잠자던 버그가 깨어난다. 이게 제일 무섭고도 교훈적이에요. C에는 '하면 안 되는데 어쩌다 운 좋게 돌아가던' 코드들이 있거든요. 메모리를 초기화 안 하고 쓴다거나, 정수 계산이 넘쳐버린다거나(오버플로), 정렬(alignment)이 안 맞는 메모리 접근 같은 거요. 이런 건 정의되지 않은 동작(undefined behavior)이라고 부르는데, 네이티브 PC에서는 우연히 멀쩡해 보이다가 WASM이라는 다른 환경에 가면 곧바로 터져요. 그래서 포팅은 사실 '내 코드의 숨은 버그를 들춰내는 건강검진' 같은 면이 있어요.

4) 그래픽 호환성. 데스크톱용 OpenGL로 짠 코드라면 그대로는 안 돌아요. 웹에서는 WebGL(모바일용인 OpenGL ES 기반)만 쓸 수 있어서, 데스크톱에만 있던 함수들을 ES가 지원하는 방식으로 고쳐야 해요.

5) 소리는 클릭 후에. 브라우저 정책상 사용자가 한 번 클릭(또는 키 입력)하기 전에는 소리를 못 내요. 자동재생 광고를 막으려는 정책인데, 게임 시작하자마자 BGM을 틀려다 '왜 무음이지?' 하고 헤매기 쉽죠.

업계 맥락

WASM 생태계는 이제 장난감 수준이 아니에요. 옛날 명작 게임 둠(Doom)이 브라우저에서 돌고, 유니티·언리얼 엔진도 웹으로 빌드를 뽑아주죠. 더 나아가 피그마(Figma)나 웹용 포토샵처럼 무거운 전문 프로그램의 핵심부도 WASM으로 돌아가요. 'C/C++로 짠 무거운 코드를 설치 없이 웹에서'라는 흐름이 점점 진짜가 되고 있는 거예요.

한국 개발자에게

게임을 안 만드는 분에게도 배울 점이 있어요. 가장 큰 교훈은 '정의되지 않은 동작을 방치하지 말자'예요. 지금 잘 돌아가는 코드도 컴파일러나 환경이 바뀌면 언제든 터질 수 있다는 걸 포팅이 적나라하게 보여주거든요. 또 데모나 작은 프로그램을 설치 없이 링크 하나로 배포하고 싶을 때 WASM은 정말 매력적인 선택지예요. 사내 툴이나 포트폴리오 데모에도 잘 어울리고요.