마츠모토 유키히로가 직접 만든다: Ruby AOT 컴파일러 'Spinel'의 의미

Ruby의 아버지가 GitHub에 새 레포를 열었다

개발 커뮤니티에서 "matz"라는 이름은 설명이 필요 없죠. Ruby라는 언어를 30년 넘게 이끌어온 마츠모토 유키히로(Yukihiro Matsumoto), 바로 그 사람이에요. 그런 matz가 최근 본인 GitHub 계정에 Spinel이라는 새 프로젝트를 공개했어요. 부제는 간단명료합니다. "Ruby AOT Native Compiler". 우리말로 풀면 Ruby를 사전 컴파일(Ahead-Of-Time)해서 네이티브 바이너리로 만드는 컴파일러라는 뜻이에요.

Ruby를 써본 분들은 아시겠지만, Ruby는 전통적으로 인터프리터 언어예요. MRI(CRuby)는 YARV라는 바이트코드 VM 위에서 돌고, 최근에는 YJIT이라는 JIT 컴파일러가 추가되면서 실행 중에 핫한 코드를 네이티브 코드로 바꿔주고 있죠. 하지만 이것들은 전부 런타임에 일어나는 일이에요. Spinel이 노리는 건 그 반대 지점, 즉 실행하기 전에 미리 다 컴파일해두는 방식이에요.

AOT가 뭐고, 왜 지금 Ruby에 필요한가

AOT 컴파일은 쉽게 말해 "돌리기 전에 기계어로 만들어 놓는다"는 접근이에요. Go나 Rust처럼 실행 파일 하나 달랑 만들어서 서버에 올리면 끝나는 방식이죠. 반대로 JIT은 프로그램이 돌아가는 도중에 "어, 이 함수가 자주 불리네?" 하고 그때그때 기계어로 번역해요. JIT은 실행 패턴에 맞춰 최적화할 수 있다는 장점이 있지만, 워밍업 시간이 필요하고 메모리도 더 먹어요. 서버 부팅 직후 첫 요청이 느린 이유가 여기 있죠.

Ruby가 AOT를 원하는 이유는 분명해요. 첫째는 시작 시간이에요. Rails 앱을 띄워본 분들은 아시죠, 부팅하는 데 몇 초씩 걸리는 게 이제 기본이잖아요. 서버리스나 CLI 도구로 Ruby를 쓰기 힘든 결정적 이유가 바로 이거였어요. 둘째는 배포의 간편함이에요. Ruby 런타임과 수백 개의 gem을 서버에 설치하는 대신, 바이너리 하나만 복사하면 되는 세상. 셋째는 성능이고요. JIT이 따라잡기 전에 이미 최적화된 코드가 돌아가니까요.

Spinel의 현재 단계와 접근 방식

레포를 들여다보면 아직 초기 단계라는 게 보여요. matz 본인도 실험적 프로젝트라는 점을 명시해뒀고, 완전한 Ruby 스펙을 커버하지는 못해요. 이름이 왜 Spinel이냐면, 루비(보석)와 비슷한 광물인 스피넬에서 따온 거예요. "Ruby는 아니지만 Ruby를 닮은 뭔가"라는 작명 센스가 matz답죠.

컴파일러의 일반적인 구조를 보면, Ruby 소스를 파싱해서 AST(Abstract Syntax Tree, 추상 구문 트리)를 만들고, 이를 중간 표현(IR)으로 내린 다음, 최종적으로 네이티브 코드 생성기에 넘기는 흐름이 될 거예요. Ruby의 동적 타입과 오픈 클래스(언제든 클래스를 다시 열어서 메서드 추가), method_missing 같은 메타프로그래밍 기능들을 AOT에서 어떻게 처리할지가 핵심 난제예요. 이런 기능들은 근본적으로 "실행 시점에 뭐든 바뀔 수 있다"는 걸 전제하거든요.

그래서 보통 Ruby용 AOT는 두 가지 타협을 해요. 하나는 전체 프로그램 분석으로 실제로 쓰이는 패턴만 컴파일하는 방식이고, 다른 하나는 제한된 서브셋만 지원하는 방식이에요. Spinel이 어느 쪽을 택할지는 앞으로 커밋을 따라가며 지켜봐야 할 부분이에요.

경쟁자들과의 비교

Ruby 네이티브 컴파일 시도는 처음이 아니에요. Crystal 언어는 Ruby 문법을 거의 그대로 차용하면서 정적 타입과 AOT를 얹은 독자 언어고요. TruffleRuby는 GraalVM 위에서 돌면서 Native Image로 AOT 바이너리를 만들 수 있어요. mruby는 matz가 직접 만든 경량 Ruby로, 임베디드에서 많이 쓰이고 바이트코드를 C 파일로 변환하는 기능이 있죠.

Spinel이 이들과 구별되는 지점은, matz 본인이 표준 Ruby의 공식 AOT 경로를 실험하고 있다는 상징성이에요. 다른 프로젝트들은 제3자가 만든 대안이지만, Ruby 언어 설계자가 직접 관여하는 AOT라면 미래의 CRuby에 통합될 가능성도 있는 셈이죠.

한국 개발자에게 의미

당장 프로덕션에 쓸 수 있는 물건은 아니에요. 그렇다고 무시할 뉴스도 아니고요. 국내에도 Rails로 서비스를 운영하는 팀들이 꽤 있는데, 배포 크기와 부팅 시간 문제는 공통된 고민이거든요. 만약 Spinel이 성숙하면, 지금까지 Go나 Rust로 다시 짜야 했던 CLI 도구나 엣지 워커를 Ruby로 유지할 수 있는 길이 열릴 수 있어요.

언어 구현에 관심 있는 분들에게는 컴파일러 공부 자료로도 훌륭해요. matz의 코드 스타일과 설계 결정을 실시간으로 따라가며 볼 수 있는 기회는 흔치 않으니까요. 레포를 watch 걸어두고 커밋을 읽어보는 것만으로도 얻는 게 많을 거예요.

마무리

30년 된 언어의 창시자가 아직도 새 컴파일러를 손수 만들고 있다는 사실 자체가 인상적이에요. Ruby가 AOT 시대에 어떻게 적응할 수 있을지, 여러분은 어떻게 보시나요? Ruby를 써보신 분이라면 AOT가 생긴다면 어떤 용도에 가장 먼저 쓰고 싶으신지 댓글로 들려주세요.