JIT - Just in Time Compiler

JIT 라는 용어가 요즘 나름 핫하게 떠오르고 있다. 이런 컴파일러에 관련된 기술이 새삼 주목받는 이유는 결국 실행 속도다. 자바스크립트가 빨리 돌아야 우리가 쓰는 인터넷 환경이 더 편리해 지고 웹 상의 온갖 서비스의 성능도 올라가고 IoT 세상에서 엣지가 해줘야 할 일들도 빨라진다. 

그럼 JIT는 무엇일가? Just In Time 컴파일러의 준 말인데, Just In Time이란 실행하는 시점까지 미루었다가 컴파일한다는 의미다. 이것이 어떨 때 필요할까를 이해하기 위해 자바와 C의 실행에 대해 이전의 포스트에서 다루었던 내용을 다시 돌이켜 보자.

자바 언어는 바이트코드라고 하는 특수한 형태의 어셈블리 코드로 컴파일된다고 했다. 이것은 타겟 머신(CPU와 운영체제)에 상관없이 이식성을 가져야 하는 자바 언어의 특징에서 나온다. 타겟에 따라 달라져야 하는, 또는 실행환경의 특징을 많이 고려해야 하는 메모리IO나 특수한 연산(ALU가 어떤 연산을 할 줄 아는가는 칩마다 다르다)의 사용 등은 제외하고 VM이 정해준 바이트코드에 맞게 일단 프로그램을 컴파일한다. 주소 계산이나 명령문 선택, 점프나 goto의 계산 등은 어느 정도 해둔 상태다. 그런 의미에서 바이트 코드를 중간코드라고도 한다. VM은 .class 파일을 로드하고 바이트코드 명령문을 차례로 가져와(load) 이해하고(decode) 그것이 의도하는 바를 VM 내부의 로직과 메모리를 이용해서 실행(execute)시킨다. VM은 운영체제나 CPU나 레지스터, 메모리의 역할까지도 소프트웨어적으로 시뮬레이트한다. 그러므로 아마도 명령문 몇 개로 될 일을 그것을 실행시키는 VM의 함수를 호출해서 실행하게 될 것이다. 반면에 C를 컴파일해서 얻어진 네이티브 코드는 CPU가 명령문을 가져다가 바로 실행시킨다. CPU는 1초에 1억개의 명령문을 실행시킬 수 있다. 그러므로 네이티브 코드는 VM의 실행속도와는 비교할 수 없을 정도로 빠르다.

JIT 컴파일이란 네이티브가 아닌 코드를 실행시키기 직전에 네이티브 코드(또는 좀더 빠른 코드)로 바꾸는 컴파일과정을 말한다. 일단 한번 네이티브로 바뀌고 나면 훨씬 빠른 속도로 실행될 것이다. 그럼 코드는 소스프로그램, 중간코드 프로그램, 네이티브 프로그램의 세 단계로 존재할 수 있고 어느 것으로 실행해야 할지, 그리고 다시 JIT 컴파일 해야 할지 그냥 실행할지 등을 운영체제나 VM이 판단해야 한다. C의 exe는 링크까지 해서 필요한 명령문 코드를 다 하나의 파일 안에 뭉쳐서 가지고 있어야 OS에 의해 실행될 수 있는데, 일부만 JIT 컴파일하고 섞여있는 상태로 실행도 필요하다. 이런 여러 가지 문제가 기존의 실행환경(C든 자바든)에서는 쉽게 해결되기 어렵다. 그래서 JIT를 지원하는 실행환경들이 다양한 형태로 시도되고 있다.

먼저 자바의 경우를 생각해 보자. 일부 자바 VM은 JIT 기능을 지원해서 클래스 파일을 네이티브 코드로 바꾸어 실행시킬 수 있다. 그 경우 VM이 바이트 코드 그대로도 실행할 수 있고 네이티브 코드로 바뀐 부분도 실행시킬 수 있어야 할 것이다. 프로그램 전체를 .exe로 만들 것인지 각 .class 파일을 네이티브로 바꿀 것인지에 따라 달라지는데, 후자의 경우 (윈도우 환경이라면) .class와 .obj가 섞여있는 상태로 실행시킬 수 있는 방법이 필요하다. JIT 기술은 아직은 실행환경마다 달라지고 표준도 없어 약간씩 다른 방식으로 구현한다고 볼 수 있다.

자바스크립트의 경우 HTML 페이지 안에 포함되어 내려오는 자바스크립트는 컴파일조차 되지 않은 소스 코드 그대로이다. 이것을 내려받은 다음 브라우저는 그 코드를 해석하여 "인터프리트" 방식으로 실행한다. 즉 컴파일러를 거치지 않고 고급 언어 프로그램 코드를 그대로 해석해서 실행한다. 그러나 자바스크립트 코드가 커지고 점점 더 많은 일을 담당하면서 이런 방식은 도저히 속도를 낼 수가 없는 문제가 생긴다. 브라우저가 JIT 기술을 도입하는 방식은 자바스크립트 코드를 내려받아서 브라우저가 컴파일을 해서 네이티브 코드(또는 중간코드)로 만들어 가지고 있다가 해당 함수나 부분이 불려지면 컴파일한 코드 부분을 실행시키는 방식이 될 것이다. ^[각주:1] 그러면 컴파일하는 시간은 좀더 걸리지만 일단 한번 컴파일해 두면 페이지의 동작 속도는 훨씬 빨라진다. 

핸드폰이나 IoT 디바이스 등 모바일 환경은 기존 운영체제와 달리 자체 실행환경을 가지고 제조사에 따라 공개되지 않은 브라우저 기술을 사용하므로 온갖 형태가 다 혼재해 있을 것이다. 오늘날 인터넷의 성공과 번영은 OS나 브라우저의 표준화 덕을 크게 보았으나 요즈음의 IT 환경은 자유경쟁 하에서 빠른 속도로 복잡 다양해지고 있다. 그래서 브라우저가 사용하는 JIT 기술도 매우 다양한 형태로 나타나고 있다. 그래서 서버에서 아예 컴파일해서 브라우저가 이해해서 돌릴 수 있는 중간코드 형태로 내려보내는 모델도 시도되고 있다(웹어셈블리). 그런가하면 JIT를 구현하는 방식(예를 들면 컴파일한 결과를 캐싱하는 것)도 제각각인데, 그 영역이 브라우저 전쟁의 핵심 기술인 것은 분명하다.

다음으로 파이썬의 경우를 생각해 보자. 파이썬은 나름 유연하고 쉽게 코드를 연결하여 일부나 부분만 실행하거나 바꿔끼는 일이 가능한 실행환경을 제공한다. 다른 언어와의 결합도 비교적 쉽다. 기본적인 파이썬 실행환경은 PVM이라는 가상기계 상에서 돌아가는 것이지만 이러한 파이썬의 특징 덕에 JIT 컴파일러와 실행의 구현도 쉬울 것이다. 또는 파이썬 코드가 네이티브 코드 부분과 결합하여 동작하기도 쉽다.. 사실 파이썬 프로그램은 대부분 성능이 관건이라기 보다는 빠른 개발로 쉽게 프로토타입을 구축하거나 글루 코드(여러 부분 시스템을 연결시키는 역할)로 쓰이므로 파이썬의 JIT가 관건은 아니다.

다음으로 중요한 JIT 실행환경으로 C#의 닷넷 기술을 들 수 있다. 사실 현재의 JIT 기술의 상당부분은 윈도우즈의 닷넷 덕을 보고 있다. C#과 닷넷은 C/C++의 장점을 살리면서 자바가 가진 이식성과 안전성을 따라가 보려고 마이크로소프트에서 개발한 기술이다. C#은 자바처럼 중간코드(IL:Intermediate Language)로 컴파일된다. 그리고 닷넷이 VM의 역할을 하는데, IL 코드는 처음 로드될 때 네이티브 코드로 바뀐다. 이렇게 바뀐 네이티브 코드는 다음 실행시에는 다시 JIT를 돌릴 필요 없이 바로 찾아서 실행된다. 즉 닷넷 환경이 IL과 네이티브 코드를 구별해서 필요할 때 JIT 컴파일러를 돌리는 일을 담당한다. 또한 닷넷은 자바 VM처럼 개방형으로 다른 곳에서 컴파일된 IL 코드를 받아다가 보안검사와 링크 등의 수행하고 실행할 수 있다. (안전성, 이식성, 개방성 가능)

그럼 JIT가 C처럼 아예 처음부터 네이티브 코드로 바꾸어서 프로그램을 배포하는 것과 어떤 차이가 있을지 생각해 보자. 아예 자바 프로그램을 네이티브 코드 exe를 만들어서 유통하면 굳이 JIT 컴파일하지 않아도 빠르고 복잡하지도 않을텐데... 그러나 그 방법은 자바의 이식성, 안전성, 표준화 등의 장점을 잃게 된다. (이건 C/윈도우 진영에 맞서서 자바 진영에서 무슨 일이 있어도 막으려고 하는 방향 중에 하나다.) 자바 언어의 VM은 단순히 프로그램을 실행시키는 역할만 하는 것이 아니고 .class 파일의 보안 검사와 실행 제어도 담당한다. 그러므로 자바 프로그램으로는 바이러스 프로그램을 짜기가 더 어렵다. 요즘같이 보안이 핫이슈인 상황에서 모르는 사람에게서 받은 네이티브 코드의 파일을 그대로 돌리는 것은 바보스러운 일이다. 그러므로 뭐가 됐든 중간코드나 고급언어 코드로 전달된 것을 받은 쪽에서 안전하게 검사한 후 JIT 컴파일러로 돌려서 빠르게 실행시키는 방법이 더 설득력이 있는 것이다. 그런가 하면 내려받는 코드에 대한 통제와 제어가 확실하게 되는 안전한 환경이라면 아예 네이티브 코드를 보내는 것이 훨씬 더 빠르고 경제적인 방법일 것이다.

1. 요즘은 웹페이지의 구조가 복잡해져서 한번 페이지가 열리면 다른 페이지로 이동하지 않고 그 안에서 엄청나게 많은 일을 하게 된다. 그리고 Ajax 기술 덕분에 서버나 다른 시스템과 통신하면서 부분부분 갱신하면서 그 페이지 안에서 한참을 머무르게 되는 경우가 많다. 그럼 이것은 커다란 하나의 프로그램이라고 봐도 무방하다. (물론 자바스크립트 코드가 거의 없는 페이지도 있다.) [본문으로]