나무모에 미러 (일반/어두운 화면)
최근 수정 시각 : 2024-10-09 05:11:59

JIT

1. just-in-time 컴파일
1.1. JIT 컴파일을 사용하는 플랫폼의 예
2. 2차산업의 생산방식 중 하나

1. just-in-time 컴파일


[[컴퓨터공학|컴퓨터 과학 & 공학
Computer Science & Engineering
]]
[ 펼치기 · 접기 ]
||<tablebgcolor=#fff,#1c1d1f><tablecolor=#373a3c,#ddd><colbgcolor=#0066DC><colcolor=white> 기반 학문 ||수학(해석학 · 이산수학 · 수리논리학 · 선형대수학 · 미적분학 · 미분방정식 · 대수학(환론 · 범주론) · 정수론) · 이론 컴퓨터 과학 · 암호학 · 전자공학 · 언어학(형태론 · 통사론 · 의미론 · 화용론 · 음운론) · 인지과학 ||
하드웨어 구성 SoC · CPU · GPU(그래픽 카드 · GPGPU) · ROM · RAM · SSD · HDD · 참조: 틀:컴퓨터 부품
기술 기계어 · 어셈블리어 · C/C++ · C# · Java · Python · BIOS · 절차적 프로그래밍 · 객체 지향 프로그래밍 · 해킹 · ROT13 · 일회용 비밀번호 · 사물인터넷 · 와이파이 · GPS · 임베디드 · 인공신경망 · OpenGL · EXIF · 마이크로아키텍처 · ACPI · UEFI · NERF · gRPC · 리버스 엔지니어링 · HCI · UI · UX · 대역폭 · DBMS · NoSQL · 해시(SHA · 브루트 포스 · 레인보우 테이블 · salt · 암호화폐) · RSA 암호화 · 하드웨어 가속
연구
및
기타 		논리 회로(보수기 · 가산기 · 논리 연산 · 불 대수 · 플립플롭) · 정보이론 · 임베디드 시스템 · 운영 체제 · 데이터베이스 · 프로그래밍 언어{컴파일러(어셈블러 · JIT) · 인터프리터 · 유형 이론 · 파싱 · 링커 · 난해한 프로그래밍 언어} · 메타데이터 · 기계학습 · 빅데이터 · 폰노이만 구조 · 양자컴퓨터 · 행위자 모델 · 인코딩(유니코드 · MBCS) · 네트워크 · 컴퓨터 보안 · OCR · 슈퍼컴퓨터 · 튜링 머신 · FPGA · 딥러닝 · 컴퓨터 구조론 · 컴퓨터 비전 · 컴퓨터 그래픽스 · 인공지능 · 시간 복잡도(최적화) · 소프트웨어 개발 방법론 · 디자인 패턴 · 정보처리이론 · 재귀 이론 · 자연어 처리(기계 번역 · 음성인식) · 버전 (버전 관리 시스템 · Git · GitHub)

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

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

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

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

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

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

1.1. JIT 컴파일을 사용하는 플랫폼의 예

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

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

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

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

80년대 서구권 업체들이 일본경제의 성공을 벤치마킹 하는 과정에서 들불 번지듯 유행했고 87년 미국 기업의 25%, 92년에는 55%가 해당 방식을 도입했다. 90년대 이후로는 린-제조방식 내지는 SCM 등 보다 개선된 방식으로 발전하였다.
[1] JIT 컴파일에 대비되는 방식으로 정적 컴파일(Static Compilation) 또는 AOT 컴파일(Ahead-Of-Time Compilation)이 있다. 정적 컴파일과 AOT 컴파일의 차이점은 원시 코드를 곧바로 기계어로 컴파일하느냐, 미리 해석되어 있는 바이트코드를 기계어로 재차 컴파일하느냐의 차이. JIT와 AOT의 'Time'은 Runtime, 즉 실행 시간을 말한다.[2] Java Virtual Machine의 경우 메소드 영역에 있는 코드 캐시(Code Cache) 공간에 JIT로 컴파일된 기계어 코드를 캐싱한다.[3] 보통 그 정도로 실행시간이 짧은 프로그램은 어차피 컴파일해서 돌리나 인터프리터로 돌리나 몇 초 차이나지도 않는 경우라 오히려 스크립트 언어로 짜고 대충 돌리는 경우가 많긴 하지만, 벤치마크를 할 때는 이것 때문에 본의 아니게 평판을 깎아먹곤 한다. 특히 초심자들이 JIT 따위 고려하지 않은 어설픈 벤치마크 코드를 짜놓고 "아 Java 구리네 C 만세" 이러는 경우가 간혹 있다.[4] 가능한 최적화의 예로, 루프 내에서 어떤 객체의 메소드를 자주 부른다는 걸 파악하면 컴파일할 때 객체의 메소드를 동적으로 찾는 대신 해당 메소드의 위치를 정적으로 바인딩할 수 있다.[5] 물론 가장 큰 이유는 애플이 서드파티 웹 브라우저 엔진을 허용하지 않아서이긴 하다.[6] LLVM API를 사용하여 LLVM IR를 컴파일하면 된다. Clang에서 LLVM IR을 생성할 수 있기 때문에, C/C++ 전용 JIT 컴파일러 프론트엔드도 있다.[7] 5.1 버전 이후의 Lua를 지원하지 않는다. 그렇다고 프로젝트가 죽은 건 아니고 현재도 활성화되어 있으니 Lua로부터 독립해 나왔다고 보는 게 맞을 듯 하다.[8] 4.4부터 6.0까지의 ART는 JIT이 아니다.[9] 안드로이드 누가부터 JIT을 같이 사용하기 시작했다.

분류