Native AOT가 JIT보다 시작 속도가 빠른 이유는?

.NET 8 이상의 Native AOT가 기존의 JIT(Just-In-Time) 방식보다 시작 속도가 압도적으로 빠른 이유는 실행 시점에 수행해야 할 복잡한 컴파일 과정을 빌드 시점에 미리 완료하기 때문입니다.

구체적인 이유는 다음과 같습니다.

1. 런타임 컴파일 과정의 제거

• JIT 방식: 애플리케이션이 실행될 때 .NET 런타임이 중간 언어(IL)를 머신 코드로 번역하는 과정을 거칩니다. 이 "번역" 과정은 실행 시점에 수행되므로 성능 세금(Performance Tax)으로 작용하여 시작 시간을 지연시킵니다.
• Native AOT 방식: 게시(Publish) 시점에 이미 IL을 네이티브 기계어로 완전히 컴파일하여 자체 포함된(Self-contained) 바이너리를 생성합니다. 따라서 앱을 실행하는 즉시 CPU가 코드를 바로 실행할 수 있으며, 기다림이나 런타임 오버헤드가 전혀 없습니다.

2. "웜업(Warm-up)" 시간의 부재

• JIT 기반 앱은 실행 초기 단계에서 코드를 최적화하고 컴파일하는 '웜업' 시간이 필요하지만, Native AOT는 모든 코드가 이미 준비된 상태이므로 **즉각적인 실행(Instant Startup)**이 가능합니다.
• 이러한 특성 덕분에 ASP.NET Core Minimal API의 시작 시간은 약 80% 단축(1.4초 → 0.28초)되며, Azure Functions와 같은 서버리스 환경의 콜드 스타트 속도는 약 3배(1.9초 → 0.6초) 더 빨라집니다.

3. 정적 분석을 통한 효율적인 바이너리 구성

• Native AOT는 빌드 시점에 정적 분석을 수행하여 도달 가능한 모든 코드 경로를 파악하고, 실행에 필요한 최소한의 런타임 라이브러리만 포함된 단일 파일 바이너리를 만듭니다.
• 실행 시 별도의 .NET 런타임 라이브러리를 로드하거나 준비할 필요가 없으므로 로딩 속도가 비약적으로 향상됩니다.

4. 성능 비교 지표

소스에 따르면 실제 벤치마크 결과는 다음과 같은 차이를 보여줍니다:

• Stage2 앱 시작 시간: JIT 방식(528ms) 대비 Native AOT(109ms)로 약 5배 빠릅니다.
• 초기 응답성: 런타임 정보가 축적되기 전의 첫 번째 실행 속도(hyperfine 벤치마크 기준)에서 Native AOT 버전이 JIT 버전보다 훨씬 빠르게 작동합니다.

---

요약하자면: JIT가 **"문서를 읽을 때마다 실시간으로 현지어로 번역하며 읽어주는 가이드"**와 같다면, Native AOT는 **"이미 독자의 모국어로 완벽하게 인쇄되어 즉시 읽을 수 있는 책"**과 같습니다. 번역(컴파일) 과정을 실행 시점이 아닌 인쇄(빌드) 시점에 미리 마쳤기 때문에 책을 펼치자마자 내용을 바로 읽을 수 있는 것입니다.