안드로이드 컴파일 과정 완전정리 ① - Kotlin, D8/R8, DEX, ART 등

핵심 한 줄
코틀린 코드는 Android에서 Kotlin 컴파일(.class) -> Android 변환(.dex) -> 설치/최적화 -> ART 해석/JIT/AOT -> CPU 기계어 실행으로 동작한다.

1. 코틀린 소스가 컴파일러에 들어간다
   fun sum(a:Int,b:Int)=a+b 같은 .kt 파일을 Kotlin 컴파일러가 파싱(문법 해석), 타입체크, null 안정성 검사 후 중간표현(IR)을 만들고 JVM 바이트코드인 .class를 만든다.
2. .class는 JVM용 바이트코드다
   예를 들어 sum은 JVM 바이트코드로는 대략 iload, iadd, ireturn 같은 명령 형태가 된다.
   이건 CPU 기계어가 아니라, “JVM 계열 런타임이 이해하는 명령”이다.
3. Android 빌드가 .class를 .dex로 바꾼다
   Android는 JVM .class를 직접 실행하지 않아서 D8/R8 단계가 필요하다.
   D8은 .class -> .dex 변환(및 desugaring), R8은 릴리즈에서 코드 축소/최적화/난독화까지 수행한다.
4. DEX란 무엇인가
   DEX는 Android용 바이트코드 포맷이다. JVM 바이트코드가 스택 기반이라면 DEX는 레지스터 기반에 가깝다.
   예시로 sum은 DEX에서 add-int v0, v1, v2 같은 형태가 된다.
5. APK는 실행파일이 아니라 패키지다
   APK 안에는 classes.dex, 리소스, 매니페스트, 서명 정보가 들어간다.
   설치 후 실행 시 ART가 APK 내부 DEX를 로드한다.
6. 설치 시 시스템이 하는 일
   PackageManager가 서명을 검증하고 앱을 등록한다.
   ART는 설치 시점 또는 백그라운드에서 dex2oat로 일부 AOT 최적화를 할 수 있고, 검증/quickening/프로파일 기반 최적화 준비를 한다.
7. 앱 실행 시 프로세스 생성
   런처가 Activity 시작 요청을 보내면 system_server(ActivityManager)가 앱 프로세스를 확인한다.
   없으면 Zygote를 fork해서 새 앱 프로세스를 만들고, ActivityThread가 메인 루프를 시작한다.
8. 클래스 로딩과 메서드 해석
   PathClassLoader가 APK의 DEX를 열고 클래스/메서드를 해석 가능한 형태로 연결(resolve)한다.
   처음 호출 시엔 인터프리터 경로를 탈 수 있다.
9. 인터프리터 실행의 실제 의미
   CPU가 DEX를 직접 실행하는 게 아니다.
   “인터프리터 프로그램(이미 기계어)”이 DEX opcode를 한 개씩 읽고, 해당 동작을 CPU 명령으로 수행한다.
   즉 CPU는 항상 기계어만 실행한다.

1. JIT/AOT가 왜 필요한가
   인터프리터만 쓰면 매 opcode마다 dispatch 비용이 든다.
   자주 실행되는 메서드는 JIT가 네이티브 기계어로 컴파일해서 엔트리포인트를 바꿔 더 빠르게 돌린다.
   프로파일이 쌓이면 이후 AOT로 더 안정적인 성능을 낸다.
2. 최종 CPU 레벨
   JIT/AOT가 만든 ARM64 기계어(예: add w0, w0, w1; ret)를 CPU가 fetch/decode/execute한다.
   실행 중 데이터/코드는 L1/L2 캐시, TLB, 메모리 계층 영향을 받는다. 캐시 미스가 나면 느려진다.
3. 용어 혼동 정리

• .class: JVM 바이트코드
• .dex: ART용 바이트코드
• 기계어: CPU가 직접 실행
• ART: DEX를 해석/JIT/AOT로 기계어화해 실행시키는 런타임
• 결론: “DEX도 컴파일된 코드”가 맞고, “최종 실행은 항상 CPU의 기계어”도 맞다.

 

다음 글

2026.02.19 - [안드로이드] - 안드로이드 컴파일 과정 완전정리 ② - 코틀린 컴파일러란?

안드로이드 컴파일 과정 완전정리 ② - 코틀린 컴파일러란?