LLVM 커뮤니티에서 제안된 JSIR — JavaScript에도 고수준 중간 표현이 필요할까?

JavaScript 최적화의 새로운 접근법

LLVM 커뮤니티에서 흥미로운 RFC(Request for Comments, 공식 제안서)가 올라왔어요. 바로 JSIR(JavaScript Intermediate Representation)이라는 건데요, 쉽게 말하면 JavaScript 코드를 더 잘 최적화하기 위한 '중간 언어'를 만들자는 제안이에요.

중간 표현(IR)이 뭔지부터 짚어볼게요. 여러분이 C나 Rust 같은 언어로 코드를 짜면, 컴파일러가 이걸 바로 기계어로 바꾸는 게 아니라 중간 단계의 표현으로 먼저 변환해요. 이 중간 단계에서 온갖 최적화를 수행한 다음에야 최종 기계어가 나오는 거죠. LLVM이 바로 이 중간 표현(LLVM IR)을 중심으로 돌아가는 컴파일러 프레임워크인데요, C, C++, Rust, Swift 등 수많은 언어가 LLVM을 통해 최적화 혜택을 보고 있어요.

그런데 JavaScript는 그동안 이런 혜택을 제대로 못 받아왔어요. 왜냐하면 JavaScript는 동적 타입 언어라서 LLVM IR처럼 낮은 수준의 표현으로 바로 변환하기가 까다롭거든요.

JSIR이 해결하려는 문제

JSIR의 핵심 아이디어는 JavaScript의 고수준 의미(semantics)를 그대로 보존하면서도 최적화할 수 있는 중간 표현을 만드는 거예요. 기존 LLVM IR은 C나 Rust처럼 타입이 명확한 언어에 최적화되어 있어서, JavaScript의 동적인 특성 — 예를 들어 변수가 숫자였다가 갑자기 문자열이 되는 것 같은 — 을 제대로 표현하기 어려웠어요.

JSIR은 이런 JavaScript만의 특성을 IR 레벨에서 일급(first-class)으로 지원하겠다는 거예요. 프로토타입 체인, 동적 프로퍼티 접근, 클로저 같은 JavaScript 고유의 개념들을 IR에서 직접 표현할 수 있게 되면, 지금까지 각 JavaScript 엔진이 독자적으로 수행하던 최적화를 공통 프레임워크 위에서 할 수 있게 되는 거죠.

이게 뭐가 좋냐면, 마치 여러 나라 언어를 각각 따로 번역하는 대신 공통 중간 언어를 두고 한번에 처리하는 것과 비슷해요. V8(Chrome), SpiderMonkey(Firefox), JavaScriptCore(Safari) 같은 엔진들이 각자 비슷한 최적화 코드를 중복으로 구현하고 있는데, JSIR이 표준화되면 이 노력을 공유할 수 있는 가능성이 열리는 거예요.

업계 맥락에서 보기

사실 JavaScript를 더 빠르게 만들려는 시도는 계속 있어왔어요. V8의 TurboFan, SpiderMonkey의 WarpMonkey 등 각 엔진의 JIT(Just-In-Time) 컴파일러들이 대표적이죠. 하지만 이들은 모두 각 엔진에 종속된 구현이에요.

한편 WebAssembly(Wasm)도 비슷한 문제의식에서 출발했다고 볼 수 있어요. Wasm은 웹에서 네이티브에 가까운 성능을 내기 위한 저수준 바이트코드인데, JavaScript 자체를 대체하는 게 아니라 보완하는 역할이에요. JSIR은 Wasm과는 다르게 JavaScript 코드 자체의 최적화에 초점을 맞추고 있다는 점에서 차별화돼요.

또 하나 주목할 점은 이 제안이 LLVM 커뮤니티에서 나왔다는 거예요. LLVM은 컴파일러 인프라의 사실상 표준이니까, 여기서 JavaScript를 위한 IR이 공식적으로 논의된다는 것 자체가 의미 있어요. 물론 아직 RFC 단계라서 실제로 채택될지는 미지수지만요.

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

당장 실무에서 뭔가 달라지는 건 아니에요. 이건 컴파일러 인프라 수준의 장기적인 제안이니까요. 하지만 몇 가지 관전 포인트가 있어요.

첫째, 서버사이드 JavaScript(Node.js, Deno, Bun) 성능에 관심이 있다면 주목할 만해요. JSIR 같은 공통 IR이 자리 잡으면 런타임 간 최적화 기술 공유가 가능해지면서 전체적인 JavaScript 실행 성능이 올라갈 수 있거든요.

둘째, 컴파일러나 언어 구현에 관심 있는 분들에게는 좋은 학습 자료가 될 수 있어요. LLVM 디스코스에서 진행되는 논의를 따라가면 고수준 동적 언어를 어떻게 효율적으로 컴파일할 수 있는지에 대한 인사이트를 얻을 수 있어요.

셋째, JavaScript/TypeScript 생태계가 점점 더 컴파일 타임 최적화 방향으로 가고 있다는 큰 흐름을 읽을 수 있어요. SWC, esbuild, 그리고 최근 TypeScript 네이티브 컴파일러까지 — 모두 'JavaScript 세계도 컴파일러 기술이 중요하다'는 방향으로 가고 있는 거죠.

정리

LLVM 위에 JavaScript 전용 고수준 IR을 올리겠다는 JSIR 제안은, JavaScript 최적화의 새로운 가능성을 열어줄 수 있는 흥미로운 시도예요. 아직 초기 논의 단계이지만, 동적 언어 최적화라는 난제에 대한 학계와 업계의 접근을 엿볼 수 있는 좋은 기회이기도 하고요.

여러분은 JavaScript 성능 최적화에서 가장 아쉬운 부분이 뭐라고 생각하시나요? 이런 컴파일러 레벨의 접근이 실제로 체감 가능한 차이를 만들어낼 수 있을까요?