JIT

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

보통 인터프리터 방식의 언어 구현들이 성능 향상을 목적으로 도입하는 경우가 많은데, JIT 컴파일러는 같은 코드를 매번 해석하는 대신 처음 실행될 때 인터프리트를 하면서 자주 쓰이는 코드를 캐싱한 뒤[2], 이후에는 캐싱된 코드를 가져다 쓰기 때문에 인터프리터의 느린 실행 속도를 개선할 수 있다. 따라서 사실 JIT '컴파일러'보다는 JIT '인터프리터'가 더 정확한 표현이다. 바이트코드 컴파일을 사용하는 Java도 바이트코드를 기계어로 번역할 때 JIT 컴파일러를 사용한다.

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

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

미리 컴파일된 코드를 실행하는 것이 아닌, 런타임에 동적으로 코드를 생성하여 실행한다는 특징 때문에 JIT 컴파일러는 잠재적으로 상당한 보안 문제를 가지고 있다. 특히 JIT 컴파일러 자체에 버그가 있는 경우 곧바로 보안취약점이 되는 경우가 많다. 대표적으로 인텔 CPU 게이트로 유명한 스펙터 보안취약점은 JIT에 의존하는 JavaScript 엔진을 가진 브라우저에서만 발생했다. 오라클의 HotSpot VM 또한 JIT 컴파일러 버그로 인한 다수의 보안취약점이 있었다.

참고로 iOS에서는 상기한 보안문제를 이유로 네트워크로 바이너리나 코드를 다운받아 실행하는 것을 금지하고 있다. 구글 크롬이나 파이어폭스의 iOS 버전이 자체 엔진을 쓰지 못하고 애플이 제공하는 WebKit의 웹뷰를 사용할 수밖에 없는 주요 이유 중 하나다.[5] 요즘 브라우저들은 JavaScript 엔진으로 JIT를 쓰기 때문. iOS도 편법으로 구현이 가능하나 정책이 이를 허용하지 않아 스토어에 올릴 때 Reject된다.

한글로 적기생산방식 내지는 적시생산방식으로 불리며 1950년대에 일본에서 연구, 1960년대에 일본 조선소 등지에서 널리 사용되다가 동시기 토요타 자동차에서 적극적으로 사용하면서 유명해진 방식으로 흔히 "칸반(간판) 시스템"이라고도 알려져 있다. 다만 칸반 시스템은 JIT의 하위 구성 개념 중 하나일 뿐으로 JIT는 훨씬 넓은 범위를 포괄한다.

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

시스템 조절 방법 중 하나로 생산 카드, 컨테이너 등이 있는데, 카드의 경우 B 작업장에서 생산을 위한 부족한 부품이나 제품을 A 작업장에 카드를 제출함으로서 생산 요청을 하는 방식으로 필요한 만큼만 생산할 수 있다는 장점이 있다. 컨테이너의 경우 A, B 작업장 사이를 개수가 정해진 컨테이너로 물품을 수송하는 방식인데, 만약 A 작업장에 컨테이너가 많이 남아있다면 A의 작업량이 뒤쳐져 있다는 의미이므로 후속 작업장인 B 작업장에서 작업 차질이 생길 수 있다는 것이 눈에 확실히 보인다. 반대로, B 작업장에 컨테이너가 많이 남아있다면, A 작업장에서 너무 작업을 빨리 했다던가, B 작업장에의 작업이 뒤쳐져 있다는 의미가 된다. 컨테이너라는 시각적인 생산 지표가 있으므로 현장에서 작업을 서두를지, 조금 속도를 늦출지 한눈에 파악이 가능한 것.

80년대 서구권 업체들이 일본경제의 성공을 벤치마킹 하는 과정에서 들불 번지듯 유행했고 87년 미국 기업의 25%, 92년에는 55%가 해당 방식을 도입했다. 90년대 이후로는 린-제조방식 내지는 SCM 등 보다 개선된 방식으로 발전하였다.