Ruby가 더 빨라지는 비결, ZJIT의 새 레지스터 할당기 들여다보기

Ruby의 새로운 JIT, ZJIT가 왜 중요한가

Ruby 개발자라면 한 번쯤 들어봤을 거예요. "Ruby는 느리다"는 오래된 편견 말이에요. 사실 요즘 Ruby는 그렇게 느리지 않은데, 이걸 가능하게 만든 핵심 기술이 바로 JIT 컴파일러예요. JIT(Just-In-Time)는 쉽게 말하면, 프로그램이 실행되는 중에 실시간으로 코드를 기계어로 번역해주는 기술이거든요. 그동안 Ruby에는 YJIT이라는 JIT가 있었는데, 이제 Shopify의 Rails 팀이 차세대 JIT인 ZJIT을 개발하고 있어요. 그리고 최근 이 ZJIT에 새로운 레지스터 할당기(register allocator)가 들어갔다는 소식이에요.

레지스터 할당기가 뭐냐면, CPU 안에 있는 "가장 빠른 저장 공간"인 레지스터를 어떻게 효율적으로 나눠 쓸지 결정하는 부품이에요. CPU 레지스터는 보통 16개 정도밖에 없는데, 프로그램에는 변수가 수십, 수백 개씩 나오죠. 그래서 어떤 변수를 레지스터에 올리고 어떤 변수를 메모리(RAM)에 두느냐를 영리하게 결정해야 해요. 이 결정이 잘못되면 CPU가 계속 메모리를 들락거리면서 시간을 까먹게 됩니다.

ZJIT가 택한 길: Linear Scan의 변형

ZJIT의 새 레지스터 할당기는 Linear Scan Register Allocation이라는 알고리즘을 기반으로 해요. 이게 뭐냐면, 변수들의 "수명(live range)"을 한 줄로 쭉 늘어놓고, 한 번 훑으면서 겹치지 않는 변수끼리는 같은 레지스터를 공유하게 만드는 방식이에요. 예를 들어 변수 A가 1번 줄부터 10번 줄까지 살아있고, 변수 B가 11번 줄부터 20번 줄까지 살아있다면, 둘은 같은 레지스터에 들어가도 충돌이 안 나죠. 이런 식으로 짜내는 거예요.

전통적인 컴파일러는 Graph Coloring이라는 더 복잡한 방법을 쓰는데, 이건 그래프를 그려서 색칠 문제처럼 푸는 거라 시간이 오래 걸려요. AOT(Ahead-of-Time) 컴파일러는 한 번만 컴파일하니까 오래 걸려도 괜찮지만, JIT는 프로그램이 도는 중에 계속 컴파일해야 하니까 빨라야 해요. 그래서 Linear Scan을 쓰는 거죠. JavaScript V8 엔진의 Crankshaft, .NET RyuJIT 등도 비슷한 계열의 알고리즘을 써왔어요.

SSA와 phi 노드라는 골치 아픈 친구들

ZJIT의 IR(중간 표현)은 SSA(Static Single Assignment) 형식을 따르는데요. 이게 뭐냐면, 모든 변수에 딱 한 번만 값을 대입한다는 규칙이에요. x = 1; x = 2; 같은 코드가 있으면 x1 = 1; x2 = 2;처럼 이름을 다르게 바꿔서 표현하는 거죠. 이렇게 하면 컴파일러가 분석하기 훨씬 쉬워져요. 그런데 if문이 나오면 문제가 생겨요. 분기 두 갈래에서 각각 다른 값이 들어오면 어떤 게 진짜 값인지 표시할 방법이 필요한데, 그게 바로 phi 노드예요. "여기서는 위쪽에서 왔으면 x1, 아래쪽에서 왔으면 x2를 골라"라고 알려주는 표지판인 셈이죠.

레지스터 할당기 입장에서 phi 노드는 까다로워요. 두 갈래에서 온 값이 같은 레지스터에 모이도록 미리 신경 써야 하거든요. ZJIT의 새 할당기는 이걸 깔끔하게 처리하기 위해 phi 노드의 입력과 출력이 가능하면 같은 레지스터를 쓰도록 힌트를 주는 방식을 채택했어요. 또 함수 호출 규약(calling convention)도 고려해서, 함수에 인자로 넘길 값은 미리 정해진 인자 레지스터(x86-64에서는 RDI, RSI 같은 것들)에 자리 잡도록 유도해요. 이런 작은 최적화들이 누적되면서 불필요한 mov 명령어가 줄어들고, 결과적으로 생성된 기계어가 더 짧고 빨라지는 거예요.

YJIT와는 어떻게 다른가

YJIT은 Basic Block Versioning(BBV)이라는 좀 특이한 기법을 쓰는데, 이건 같은 코드 블록이라도 들어오는 타입에 따라 여러 버전을 따로 컴파일하는 방식이에요. 빠르긴 한데 생성되는 코드 양이 많아지고 메모리를 많이 먹는 단점이 있죠. ZJIT은 좀 더 전통적인 method JIT에 가깝게 가고 있어요. 메서드 단위로 컴파일하면서 SSA 기반 최적화를 풍부하게 적용하는 방향이에요. 이게 잘 되면 YJIT보다 더 적은 메모리로 더 정교한 최적화를 할 수 있게 됩니다.

Java의 HotSpot, .NET의 RyuJIT, V8의 TurboFan 같은 성숙한 JIT들이 이미 가 있는 길을 Ruby도 따라가는 셈인데, 늦은 만큼 그들의 시행착오를 학습한 채로 출발할 수 있다는 장점이 있어요.

한국 Ruby 개발자에게 주는 의미

국내에서 Ruby는 옛날만큼 핫하지는 않지만, 우아한형제들, 직방, 마이리얼트립 같은 회사들이 여전히 Rails로 서비스를 운영하고 있어요. ZJIT이 정식 릴리스되면 별다른 코드 수정 없이도 기존 Rails 앱이 더 빨라지는 효과를 볼 수 있을 거예요. 컴파일러나 언어 런타임에 관심 있는 분이라면 ZJIT 소스를 들여다보는 것도 좋은 공부가 됩니다. Rust로 작성되어 있어서 Rust 학습도 겸할 수 있고요.

마무리

Ruby의 발걸음이 느려 보여도, JIT 같은 핵심 기술은 계속 진화하고 있어요. ZJIT의 새 레지스터 할당기는 "적당히 빠르면서 코드 품질도 좋은" 균형점을 찾아가는 과정이고요. 여러분 회사의 Ruby/Rails 앱은 YJIT을 이미 켜놓고 쓰시나요? ZJIT이 안정화되면 갈아탈 의향이 있으신가요?