도입
옛날 게임보이 게임을 PC나 브라우저에서 돌리는 “에뮬레이터”, 한 번쯤 써보셨죠? 에뮬레이터가 뭐냐면, 게임보이라는 옛날 기계의 동작을 소프트웨어로 흉내 내서 그 게임 코드를 다른 기기에서 실행해주는 프로그램이에요. 그런데 WATaBoy라는 프로젝트가 재밌는 걸 해냈어요. 게임보이 명령어를 웹어셈블리(WebAssembly, 줄여서 WASM)로 그때그때 번역해서 돌렸더니, C나 러스트로 짠 네이티브 인터프리터보다 더 빨랐다는 거예요. “브라우저용 기술이 네이티브를 이겼다고?” 싶죠. 왜 이런 일이 가능한지 풀어볼게요.
인터프리터 vs JIT
에뮬레이터를 만드는 가장 흔한 방법은 “인터프리터”예요. 게임 코드를 한 줄 한 줄 읽어서, “아 이건 더하기 명령이네” 하고 해석한 다음 실행하고, 다시 다음 줄 읽고... 이걸 무한 반복해요. 문제는 매 명령마다 “이게 무슨 명령이지?” 하고 분류하는 과정(fetch-decode-dispatch라고 해요)에 오버헤드가 붙는다는 거예요. 게임보이 CPU가 초당 수백만 번 명령을 실행하니까, 이 작은 낭비가 쌓이면 꽤 커요.
JIT(Just-In-Time 컴파일)는 발상을 바꿔요. 게임 코드를 한 줄씩 해석하는 대신, 게임보이 명령 덩어리를 통째로 다른 기계어로 번역해두고, 다음부턴 그 번역본을 바로 실행하는 거예요. 이걸 에뮬레이터 쪽에선 다이나렉(dynarec, 동적 재컴파일)이라고 불러요. 한 번 번역해두면 “이게 무슨 명령이지?” 묻는 과정이 사라지니까, 같은 코드를 반복 실행할 때 훨씬 빨라요.
WATaBoy의 핵심은 그 번역 대상을 WASM 바이트코드로 잡았다는 거예요. 게임보이 명령을 실시간으로 WASM 코드로 만들어내면, 브라우저의 WASM 엔진이 그걸 다시 진짜 네이티브 기계어로 컴파일해서 굉장히 빠르게 돌려줘요. 즉 “번역을 두 단계로” 하는 셈인데, 이 덕분에 단순 인터프리터의 줄줄이 해석 오버헤드를 없애버려서 네이티브 인터프리터보다도 빨라진 거예요. 인터프리터의 적은 바로 그 반복되는 ‘해석 비용’인데, JIT는 그 비용 자체를 제거하니까요.
물론 공짜는 아니에요. 게임보이는 코드가 스스로를 바꾸거나(자기수정 코드), 메모리 뱅크를 갈아끼우는(뱅크 스위칭) 같은 까다로운 동작이 있어서, 번역해둔 코드가 무효가 되는 경우를 잘 처리해야 해요. 번역에 드는 비용과 실행으로 얻는 이득 사이의 균형도 맞춰야 하고요.
업계 맥락
다이나렉은 사실 고성능 에뮬레이터의 단골 기술이에요. 게임큐브/Wii 에뮬레이터 돌핀(Dolphin), PS2의 PCSX2 같은 무거운 에뮬레이터들이 다 동적 재컴파일로 속도를 끌어올려요. WATaBoy가 신선한 건 그 타깃을 WASM으로 잡았다는 점이에요. WASM은 원래 브라우저에서 빠른 코드를 돌리려고 만든 건데, 요즘은 “어디서나 도는 범용 컴파일 타깃”으로 위상이 올라가고 있거든요. WASM을 런타임에 생성해서 실행하는 이 접근은, 에뮬레이션뿐 아니라 동적 언어 런타임이나 플러그인 샌드박스 등 다양한 곳에 응용될 수 있어요.
한국 개발자에게
당장 게임보이 에뮬레이터를 만들 일은 없더라도, 여기서 배울 게 많아요. 첫째, “해석을 반복하지 말고 한 번 번역해 캐싱하라”는 JIT의 발상은 인터프리터형 언어나 정규식 엔진, 쿼리 엔진 등 성능 최적화 전반에 통하는 사고방식이에요. 둘째, WASM을 코드 생성 타깃으로 쓰는 경험은 점점 값어치가 높아지고 있어요. 브라우저에서 무거운 계산을 돌려야 하는 프론트엔드, 플러그인 샌드박스가 필요한 백엔드 등에서 WASM 코드젠 능력은 확실한 차별점이 되거든요. “느린 줄 알았던 환경이 사실 똑똑하게 쓰면 네이티브급”이라는 이 사례 자체가 좋은 영감이에요.
마무리
한 줄 정리: WATaBoy는 “JIT로 WASM을 뽑아내면 브라우저에서도 네이티브 인터프리터를 이길 수 있다”는 걸 보여준 사례예요. 여러분은 성능이 중요한 코드를 짤 때, 인터프리터식으로 매번 해석하는 방식과 미리 컴파일해 캐싱하는 방식 중 어디에 무게를 두시나요?
🔗 출처: Hacker News