Hacker News 2026.04.16 28

C 인터프리터에 JIT 컴파일러를 끼워넣는다고? 생각보다 현실적인 이야기

인터프리터가 느린 건 숙명이 아니에요

프로그래밍 언어의 실행 방식을 크게 나누면 두 가지가 있어요. 소스 코드를 미리 기계어로 번역해두는 컴파일(compile) 방식과, 한 줄 한 줄 읽으면서 바로 실행하는 인터프리터(interpreter) 방식이요. 인터프리터는 개발이 편하고 유연하지만, 매번 코드를 해석하느라 실행 속도가 느린 게 오래된 단점이었거든요.

그래서 등장한 게 JIT(Just-In-Time) 컴파일이에요. 이게 뭐냐면, 프로그램을 실행하는 도중에 "이 부분이 자주 실행되네?" 하고 판단하면, 그 부분만 즉석에서 기계어로 컴파일해서 다음부터는 빠르게 실행하는 기법이에요. Java의 HotSpot JVM이나 JavaScript의 V8 엔진이 이 방식으로 놀라운 성능을 내고 있죠.

그런데 문제가 하나 있어요. JIT 컴파일러를 처음부터 만드는 건 정말 어마어마하게 복잡한 작업이에요. V8의 JIT 컴파일러 코드만 해도 수십만 줄이 넘거든요. 이미 C로 작성된 인터프리터가 있는데, 거기에 JIT을 붙이려면 처음부터 다시 만들어야 할까요? Laurie Tratt의 이 글은 기존 C 인터프리터를 크게 뜯어고치지 않으면서도 JIT 컴파일러를 끼워넣을 수 있는 방법을 탐구해요.

핵심 접근법: Copy-and-Patch JIT

이 글에서 다루는 핵심 기법은 Copy-and-Patch라고 불리는 JIT 컴파일 전략이에요. 전통적인 JIT은 중간 표현(IR)을 만들고, 최적화 패스를 돌리고, 레지스터 할당을 하고... 이런 복잡한 컴파일러 파이프라인을 런타임에 실행해야 해요. 하지만 Copy-and-Patch는 접근이 완전히 달라요.

쉽게 비유하면 이래요. 전통적인 JIT이 "주문을 받으면 재료부터 손질해서 요리하는 셰프"라면, Copy-and-Patch는 "미리 만들어둔 반조리 식품을 데워서 조합하는 방식"에 가까워요. 각 바이트코드 명령어에 대응하는 기계어 조각(stencil)을 컴파일 타임에 미리 만들어두고, 런타임에는 이 조각들을 복사(copy)한 다음 필요한 부분만 패치(patch)해서 이어붙이는 거예요.

구체적으로 어떻게 동작하는지 볼게요. 먼저 인터프리터의 각 opcode 핸들러를 별도의 C 함수로 분리해요. 이 함수들을 컴파일하면 각각에 대응하는 기계어 코드가 나오겠죠. 이걸 "스텐실"이라고 불러요. 런타임에 바이트코드 시퀀스가 주어지면, 해당하는 스텐실들을 순서대로 메모리에 복사하고, 각 스텐실 안에서 상수값이나 점프 주소 같은 부분을 실제 값으로 패치해요. 그러면 완성된 기계어 코드가 만들어지는 거예요.

이 방식이 왜 매력적인가요?

가장 큰 장점은 기존 C 코드를 거의 그대로 재활용할 수 있다는 점이에요. 인터프리터의 switch-case 안에 있는 각 opcode 처리 로직을 함수로 분리하는 정도의 리팩토링만 하면 돼요. LLVM이나 별도의 IR을 만들 필요가 없고, 레지스터 할당 알고리즘을 구현할 필요도 없어요. C 컴파일러(gcc나 clang)가 각 스텐실을 최적화해주니까, 개별 코드 조각의 품질은 이미 보장된 셈이고요.

성능 면에서도 꽤 인상적인 결과를 보여줘요. 순수 인터프리터 대비 보통 2~5배 정도의 속도 향상을 얻을 수 있다고 해요. 물론 V8이나 HotSpot 같은 고도로 최적화된 다단계 JIT에 비하면 부족하지만, 투입되는 개발 노력 대비 효과가 매우 좋은 거죠. 그리고 JIT 컴파일 자체가 매우 빨라요. 스텐실을 복사하고 패치하는 건 단순한 메모리 작업이라서, 컴파일 지연(compilation pause)이 거의 느껴지지 않아요.

업계에서의 위치

이 Copy-and-Patch 기법은 사실 최근 몇 년간 꽤 주목받고 있어요. CPython(파이썬의 기본 인터프리터)이 3.13 버전부터 실험적 JIT을 도입했는데, 바로 이 Copy-and-Patch 방식을 채택했거든요. 세계에서 가장 많이 쓰이는 스크립팅 언어의 공식 구현체가 이 기법을 선택했다는 건, 그만큼 실용성이 검증됐다는 의미예요.

LuaJIT은 다른 접근을 취한 사례인데, Mike Pall이 거의 혼자서 만든 이 JIT은 수작업으로 어셈블리를 최적화해서 놀라운 성능을 냈지만, 유지보수가 극히 어렵다는 문제가 있었어요. Copy-and-Patch는 이런 "천재 한 명에 의존하는" 방식이 아니라, 일반적인 C 개발자가 유지보수할 수 있다는 점에서 훨씬 지속 가능해요.

또 하나 흥미로운 맥락은 WebAssembly 런타임이에요. Wasmer, Wasmtime 같은 Wasm 런타임들도 빠른 시작 시간을 위해 경량 JIT 기법을 활용하는데, Copy-and-Patch와 비슷한 아이디어가 적용되고 있어요.

한국 개발자에게 주는 시사점

자체 DSL(도메인 특화 언어)이나 스크립팅 엔진을 운영하는 팀이라면 이 글이 특히 유용할 거예요. 게임 업계에서 루아(Lua) 기반 스크립팅을 쓰는 경우가 많은데, 성능 병목이 생겼을 때 전체 엔진을 갈아엎지 않고 JIT을 점진적으로 도입할 수 있는 현실적인 경로를 보여주거든요. 또한 CPython의 JIT 도입이 한국에서도 많이 쓰이는 파이썬 생태계에 어떤 성능 변화를 가져올지 지켜보는 것도 의미 있어요.

컴파일러나 언어 구현에 관심 있는 분이라면, 이 글을 시작점으로 Copy-and-Patch 논문(Xu & Kjolstad, 2021)까지 읽어보시는 걸 추천해요. 생각보다 구현이 접근 가능하고, 개인 프로젝트로 장난감 언어에 JIT을 붙여보는 것도 아주 좋은 학습 경험이 될 거예요.