JIT

1 Just-in-time 컴파일

컴퓨터 과학프로그래밍 언어에서 사용하는 용어. CC++에서 하는 것처럼 프로그램을 실행하기 전에 처음 한 번 컴파일[1]하는 대신, 프로그램을 실행하는 시점에서 필요한 부분을 즉석에서 컴파일하는 방식을 말한다.

보통 인터프리터 방식의 언어 구현들이 성능 향상을 목적으로 도입하는 경우가 많은데, 같은 코드를 매번 해석하는 대신 실행하기 전에 그 부분만 컴파일을 해 두고 다음부터는 컴파일된 코드를 쓰기 때문에 인터프리터의 느린 실행 성능을 개선할 수 있다. JIT 이전부터 실행 성능 문제 때문에 바이트코드 컴파일을 도입했던 Java와 같은 언어들도 바이트코드를 해석하는 대신 컴파일된 기계어 코드를 직접 실행하는 쪽이 어쨌든 빠르기 때문에 역시 도입하고 있다.

단점이라면 초기 구동 후 얼마간은 소스코드(혹은 바이트코드)를 컴파일하는 데에 시간과 메모리를 소모하기 때문에 정적 컴파일된 프로그램에 비해 초기 실행 속도와 메모리 사용량에서 손해를 본다는 것으로, 특히 실행 시간이 매우 짧은 경우에는 애써 컴파일된 코드를 제대로 울궈먹기도 전에 프로그램이 끝나는 배보다 배꼽이 더 큰 상황이 벌어지기도 한다.[2]

크게 나눠서 HotSpot VM과 같이 메소드(함수) 단위로 JIT 컴파일을 하는 방식과, 그보다 더 작은 단위에서 프로그램 실행 흐름을 실시간으로 추적하며 컴파일할 코드를 탐색하는 tracing JIT 방식으로 분류할 수 있다. 특히 tracing JIT의 경우에는 실행 시점에만 알 수 있는 정보를 컴파일에 적극적으로 반영[3]하기 때문에 이론적으로는 정적 컴파일 방식보다 더 빨라질 수도 있다.

1.1 JIT 컴파일을 사용하는 구현의 예

2 2차산업의 생산방식 중 하나

한글로 적기생산방식 내지는 적시생산방식 으로 불리며 1950년대에 일본에서 연구, 1960년대에 일본 조선소 등지에서 널리 사용되다가 동시기 토요타 자동차에서 적극적으로 사용하면서 유명해진 방식으로 흔히 "칸반(간판) 시스템"이라고도 알려져 있다. 다만 칸반 시스템은 JIT의 하위 구성 개념 중 하나일 뿐으로 JIT는 훨씬 넓은 범위를 포괄한다.
흔히들 토요타가 창안한 것으로 잘못 알려져 있지만 이는 토요타의 미국시장 성공으로 인해 토요타를 벤치마킹 하자는 움직임의 일환으로 서구권 경영학이나 산업공학 쪽에서 토요타에 초점을 맞춰 연구하면서 학문적 체계를 세우다가 보니 벌어진 오해로 JIT 자체는 전반적으로 일본 제조업에 널리 자연스럽게 시행되었던 방식에 가깝다.
대체로 공급망 내의 재고를 최대한 낮추기 위해 생산 시스템 전반을 기민화하여 과생산, 재고, 대기, 배송, 불량품 등과 같은 낭비를 없앤다는 개념인데, 말로는 간단해 보이지만 60년대에서 70년대 시점에서 요즈음 같은 인터넷이나 컴퓨터도 없이 이러한 체계를 구축한 다는 것이 쉬운 일은 아니었다.

80년대 서구권 업체들이 일본경제의 성공을 벤치마킹 하는 과정에서 들불 번지듯 유행했고 87년 미국 기업의 25%, 92년에는 55%가 해당 방식을 도입했다. 90년대 이후로는 린-제조방식 내지는 SCM등 보다 개선된 방식으로 발전하였다.
  1. JIT 컴파일에 대비해서 정적 컴파일(static compilation)이라고 부르기도 한다.
  2. 보통 그 정도로 실행시간이 짧은 프로그램은 어차피 컴파일해서 돌리나 인터프리터로 돌리나 몇 초 차이나지도 않는 경우라 오히려 스크립트 언어로 짜고 대충 돌리는 경우가 많긴 하지만, 벤치마크를 할 때는 이것 때문에 본의 아니게 평판을 깎아먹곤 한다. 특히 초심자들이 JIT따위 고려하지 않은 어설픈 벤치마크 코드를 짜놓고 "아 Java 구리네 C만세" 이러는 경우가 간혹 있다.
  3. 가능한 최적화의 예로, 루프 내에서 어떤 객체의 메서드를 자주 부른다는 걸 파악하면 컴파일할 때 객체의 메서드를 동적으로 찾는 대신, 해당 메서드의 위치를 정적으로 바인딩해버릴 수 있다.
  4. 4.4부터 추가된 ART는 JIT가 아니다. 5.0부터 ART가 기본으로 지정됨에 따라 어느 순간 없어질 것으로 보인다