Ruby의 새 JIT 컴파일러 ZJIT, 불필요한 객체 로드·스토어를 제거하는 방법

Ruby 성능의 새로운 장을 열다

Ruby는 오랫동안 "개발자 행복"을 최우선 가치로 내세워온 언어입니다. 하지만 그 대가로 성능 면에서는 늘 아쉬움이 있었죠. CPython과 함께 "느린 동적 언어"의 대표 주자로 꼽혀왔고, Rails 애플리케이션의 응답 시간을 줄이기 위해 수많은 캐싱 레이어와 인프라 최적화가 필요했습니다. 이런 상황을 근본적으로 바꾸기 위해 Ruby 커뮤니티는 JIT(Just-In-Time) 컴파일러에 꾸준히 투자해왔습니다. MJIT에서 YJIT으로, 그리고 이제 ZJIT이라는 새로운 실험적 JIT 컴파일러가 등장했는데, 최근 Shopify의 Rails at Scale 블로그에서 ZJIT이 불필요한 객체 로드와 스토어를 어떻게 제거하는지에 대한 기술적 심층 분석이 공개되었습니다.

JIT 컴파일러가 왜 중요한가

전통적으로 Ruby는 인터프리터 방식으로 코드를 실행합니다. 소스 코드를 바이트코드로 변환한 뒤, VM(가상 머신)이 바이트코드를 한 줄씩 해석하며 실행하는 방식이죠. 이 방식은 유연하지만, 같은 코드를 반복 실행할 때마다 동일한 해석 과정을 거치기 때문에 오버헤드가 발생합니다. JIT 컴파일러는 이 문제를 해결합니다. 프로그램이 실행되는 동안 "자주 호출되는 코드 경로"를 식별하고, 해당 부분을 네이티브 머신 코드로 직접 컴파일합니다. C나 Rust처럼 미리 컴파일하는 AOT(Ahead-Of-Time) 방식과 달리, 실행 시점의 실제 타입 정보와 호출 패턴을 활용할 수 있다는 장점이 있습니다.

YJIT은 이미 Ruby 3.1부터 포함되어 Rails 애플리케이션에서 15~25%의 성능 향상을 보여주고 있습니다. ZJIT은 YJIT의 후속 실험 프로젝트로, 더 공격적인 최적화를 시도하는 연구형 JIT 컴파일러입니다.

ZJIT의 핵심: 불필요한 로드·스토어 제거

Ruby의 객체 모델은 내부적으로 상당히 복잡합니다. Ruby에서 객체의 인스턴스 변수(@name, @age 같은 것들)에 접근할 때마다, VM은 객체의 내부 데이터 구조에서 해당 값을 읽어오는(load) 작업을 수행합니다. 마찬가지로 값을 변경할 때는 스토어(store) 작업이 발생합니다.

문제는 이런 로드와 스토어가 실제로는 불필요한 경우가 많다는 것입니다. 예를 들어, 하나의 메서드 안에서 @name을 두 번 읽는다고 해봅시다. 첫 번째 읽기와 두 번째 읽기 사이에 @name이 변경되지 않았다면, 두 번째 로드는 완전히 불필요합니다. 첫 번째 로드의 결과를 그대로 재사용하면 되니까요. 이것이 바로 "중복 로드 제거(redundant load elimination)"입니다.

비슷하게, 어떤 값을 저장한 직후에 같은 위치에 다른 값을 저장한다면, 첫 번째 스토어는 어차피 덮어씌워지므로 의미가 없습니다. 이것이 "데드 스토어 제거(dead store elimination)"입니다. C/C++ 컴파일러에서는 수십 년 전부터 적용해온 고전적인 최적화 기법이지만, Ruby처럼 동적 타입 언어에서는 적용이 훨씬 까다롭습니다.

동적 언어에서의 도전 과제

C 컴파일러가 이런 최적화를 비교적 쉽게 할 수 있는 이유는, 컴파일 시점에 변수의 타입과 메모리 레이아웃이 확정되어 있기 때문입니다. 반면 Ruby에서는 객체의 "shape"(형태)가 런타임에 동적으로 변할 수 있습니다. 같은 클래스의 인스턴스라도 서로 다른 인스턴스 변수 집합을 가질 수 있고, 메서드 호출 중간에 객체의 구조가 바뀔 수도 있습니다.

ZJIT은 이 문제를 Ruby 3.2에서 도입된 Object Shapes 시스템을 활용하여 해결합니다. Object Shapes는 객체의 인스턴스 변수 레이아웃을 트리 구조로 추적하는 메커니즘입니다. 같은 shape를 공유하는 객체들은 동일한 메모리 레이아웃을 가지므로, shape가 변하지 않았다면 특정 인스턴스 변수의 오프셋이 동일하다는 것을 보장할 수 있습니다. ZJIT은 이 shape 정보를 IR(Intermediate Representation, 중간 표현)에 인코딩하여, 컴파일 시점에 "이 두 로드는 같은 shape의 같은 슬롯을 읽으므로 하나를 제거해도 안전하다"는 판단을 내릴 수 있게 됩니다.

SSA 기반 중간 표현의 역할

ZJIT이 이런 최적화를 체계적으로 수행할 수 있는 핵심 기반은 SSA(Static Single Assignment) 형태의 중간 표현입니다. SSA는 컴파일러 이론에서 가장 널리 쓰이는 IR 형식으로, 모든 변수가 정확히 한 번만 정의되도록 코드를 변환합니다. 이렇게 하면 데이터 흐름 분석이 극적으로 단순해집니다. 어떤 값이 어디서 왔는지, 어디서 사용되는지를 정확히 추적할 수 있기 때문이죠.

YJIT은 설계 철학상 SSA 기반 IR을 사용하지 않고, 더 단순한 선형 IR을 채택했습니다. 이 덕분에 컴파일 속도가 빠르고 구현이 간결하지만, 고급 최적화를 적용하기에는 한계가 있었습니다. ZJIT은 이 트레이드오프에서 반대쪽을 선택한 것입니다. SSA 기반 IR을 도입함으로써 컴파일 파이프라인은 더 복잡해지지만, 중복 로드 제거 같은 고급 최적화를 자연스럽게 표현하고 적용할 수 있게 되었습니다.

YJIT과 ZJIT의 관계, 그리고 업계 맥락

ZJIT은 YJIT을 대체하려는 프로젝트가 아닙니다. 오히려 YJIT에서 검증된 아이디어들을 더 공격적으로 밀어붙이는 실험적 테스트베드에 가깝습니다. YJIT은 이미 프로덕션에서 안정적으로 사용되고 있고, Shopify의 대규모 Rails 인프라에서 검증되었습니다. ZJIT에서 효과가 입증된 최적화 기법들이 향후 YJIT으로 역수입될 가능성이 높습니다.

이런 접근은 다른 언어 생태계에서도 찾아볼 수 있습니다. JavaScript의 V8 엔진은 Turbofan이라는 최적화 컴파일러에서 이미 수십 년간 이런 종류의 최적화를 적용해왔고, Python 진영에서도 3.13부터 실험적 JIT 컴파일러가 도입되고 있습니다. Java의 GraalVM이 Truffle 프레임워크를 통해 동적 언어에 고급 최적화를 적용하는 것도 같은 맥락입니다. Ruby의 ZJIT은 이러한 업계 흐름에서 "동적 언어도 정적 컴파일러 수준의 최적화를 받을 수 있다"는 방향으로 한 걸음 더 나아간 것입니다.

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

Ruby on Rails를 사용하는 한국 팀이라면, 당장은 YJIT을 활성화하는 것만으로도 유의미한 성능 개선을 얻을 수 있습니다. Ruby 3.3 이상을 사용하고 있다면 --yjit 플래그 하나면 됩니다. ZJIT 자체는 아직 실험 단계이므로 프로덕션 도입은 시기상조이지만, 이 프로젝트가 보여주는 컴파일러 최적화 기법들은 언어를 불문하고 배울 가치가 있습니다.

특히 SSA 기반 IR에서의 데이터 흐름 분석, shape 기반 타입 추론, 그리고 불필요한 메모리 접근 제거 같은 개념들은 시스템 프로그래밍이나 고성능 애플리케이션 개발에 관심 있는 개발자라면 반드시 이해해두면 좋은 주제입니다.