R8: 개념, 기능 및 ProGuard와의 비교

R8이란?

R8은 Android 생태계에서 ProGuard를 대체하기 위해 Google이 개발한 바이트코드 처리 및 변환 프로그램입니다. class 파일 단계에서 별도 도구로 작동하는 ProGuard와 달리 R8은 DEX 컴파일러(D8/R8)에 직접 통합됩니다. 이를 통해 R8은 더 깊은 수준에서 분석 및 최적화를 수행할 수 있으며, 외부 도구는 접근할 수 없습니다.

R8 아키텍처

R8은 class 파일 또는 JAR 아카이브 형태의 Java 바이트코드를 입력으로 받아 단일 패스로 최적화된 DEX 코드로 변환합니다. 내장된 R8 최적화 도구는 단순한 것(상수 인라인화)부터 복잡한 것(필드 수준 정밀도의 유형 도달 가능성 분석)까지 50가지 이상의 다양한 변환을 수행합니다. Google에 따르면 R8 아키텍처는 멀티스레드 작동을 위해 특별히 설계되어 높은 빌드 속도를 보장합니다.

개발 역사

R8은 Google I/O 2018에서 발표되었으며 Android Gradle Plugin 3.4(2019)에 ProGuard의 선택적 대체품으로 처음 포함되었습니다. AGP 7.0에서 R8은 모든 프로젝트의 기본 도구가 되었고, AGP 8.0(2023)에서는 ProGuard 지원이 플러그인에서 완전히 제거되었습니다. 2025년 현재 R8은 Google이 권장하는 Android용 유일한 공식 난독화 및 최적화 도구입니다.

R8의 주요 기능

R8은 효율성에서 ProGuard를 크게 능가하는 강력한 기능 세트를 개발자에게 제공합니다. 주요 기능을 살펴보겠습니다.

축소 및 코드 압축

R8은 애플리케이션 코드와 모든 종속성을 전역적으로 분석하여 진입점에서 호출 그래프를 통해 도달 가능한 클래스와 메서드를 결정합니다. R8의 분석은 코드의 DEX 표현에 접근할 수 있기 때문에 ProGuard보다 더 정확합니다. R8은 전체 클래스와 메서드뿐만 아니라 사용되지 않는 개별 필드도 제거할 수 있습니다. Google 테스트에 따르면 R8은 동일한 프로젝트에서 ProGuard보다 평균 15% 더 많은 코드를 제거합니다.

Java 8+ 디슈가링

내장 디슈가링은 ProGuard에는 없는 R8의 고유한 기능입니다. R8은 람다 표현식, 메서드 참조, 기본 메서드가 있는 인터페이스 및 Java 8+ try-with-resources를 모든 Android API 수준에서 작동하는 하위 호환 코드로 자동 변환합니다. 이를 통해 개발자는 별도의 desugar_jdk_libs 라이브러리를 추가하거나 수동으로 디슈가링을 구성할 필요가 없습니다.

DEX 수준 최적화

R8은 최종 DEX 형식을 볼 수 있기 때문에 ProGuard에서는 불가능한 최적화를 수행할 수 있습니다. R8은 동일한 문자열 상수를 병합하고, 사용되지 않는 예외를 제거하고, switch 구문을 최적화하고, 호출 그래프를 다시 작성하면서 적극적인 인라인화를 수행합니다. 이러한 최적화는 APK 크기를 줄일 뿐만 아니라 ART에서 코드 실행 성능도 향상시킵니다.

// build.gradle에서 R8을 명시적으로 활성화(AGP 8.0+에서는 선택 사항)
android {
    compileSdk 34
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt'
            ), 'proguard-rules.pro'
        }
    }
}

// gradle.properties — R8을 강제로 활성화
android.enableR8.fullMode=true

R8과 ProGuard 비교

R8과 ProGuard 중 선택은 AGP 8.0 이전 버전을 사용하는 프로젝트에만 관련됩니다. 아키텍처 차이를 이해하기 위해 주요 매개변수별 비교를 살펴보겠습니다.

최종 APK 크기

Play Store의 인기 앱 100개를 대상으로 한 Google 테스트에 따르면 R8은 ProGuard와 비교하여 APK 크기를 평균 18% 줄입니다. Java 8+ 구문과 타사 라이브러리를 많이 사용하는 일부 프로젝트에서는 차이가 28%에 달했습니다. 40MB 애플리케이션의 경우 5~11MB의 절감 효과로, 대역폭이 제한된 사용자에게 중요합니다.

Kotlin 호환성

두 도구 모두 Kotlin 코드를 올바르게 처리하지만 R8은 람다, 인라인 함수, 코루틴 및 null 안전 유형과 같은 Kotlin 특정 구문을 더 잘 최적화합니다. R8은 Kotlin 메타데이터 의미론을 이해하고 불필요한 null 검사를 안전하게 제거하고 인라인 함수를 포함할 수 있습니다. Kotlin 프로젝트의 경우 R8이 Google의 권장 도구입니다.

Android 프로젝트에서 R8 설정

R8 설정은 빌드 구성에 최소한의 변경만 필요합니다. AGP 8.0+에서는 도구가 기본적으로 사용되기 때문입니다. 주요 구성 측면을 살펴보겠습니다.

R8 전체 모드

R8 전체 모드(android.enableR8.fullMode=true)는 APK 크기를 추가로 5-10% 줄이는 더 적극적인 최적화를 활성화합니다. 이 모드에서 R8은 더 깊은 코드 분석을 수행하여 ProGuard가 도달 가능하다고 간주하는 클래스와 메서드를 제거합니다. 전체 모드에서는 리플렉션을 사용하는 라이브러리에 대한 추가 -keep 규칙이 필요할 수 있습니다.

# gradle.properties — R8 전체 모드 활성화
android.enableR8.fullMode=true

# 전체 모드에 대한 추가 규칙
-keep class com.example.reflection.** { *; }
-keep class * implements android.os.Parcelable {
    public static final android.os.Parcelable$Creator *;
}

R8 문제 디버깅

R8을 사용한 릴리스 빌드에서 오류가 발생하는 경우 Google은 다음을 권장합니다: 스택 추적 난독화 해제를 위해 매핑 파일 확인, 문제를 격리하기 위해 일시적으로 fullMode 비활성화, 클래스가 제거되지 않는 이유를 이해하기 위해 -whyareyoukeeping 추가, 상세한 R8 처리 로그를 얻기 위해 --info Gradle 플래그 사용.

CI/CD 통합

CI/CD에서 R8을 사용한 빌드를 자동화하려면 매핑 파일을 빌드 아티팩트로 저장하는 것이 중요합니다. 각 매핑 파일은 버전 번호 및 빌드 변형과 연결되어야 합니다. Google은 APK/AAB와 함께 build/outputs/mapping/을 아티팩트 관리 시스템에 보관할 것을 권장합니다. 이렇게 하면 모든 버전의 애플리케이션에서 크래시를 난독화 해제할 수 있습니다.

R8 모범 사례

Android 커뮤니티에서 R8을 사용한 수년간의 경험을 통해 일반적인 문제를 피하고 도구를 최대한 활용하는 데 도움이 되는 검증된 사례가 만들어졌습니다.

점진적 도입

ProGuard에서 R8으로 마이그레이션할 때는 R8이 기본적으로 활성화되어 있지만 fullMode가 비활성화된 AGP 7.x부터 시작하는 것이 좋습니다. 전체 장치 및 시나리오 세트에서 빌드 안정성을 확인한 후 fullMode를 활성화할 수 있습니다. 각 단계는 다양한 Android 버전이 설치된 물리적 장치에서 릴리스 빌드를 테스트해야 합니다.

매핑 파일 모니터링

R8 매핑 파일은 ProGuard와 동일한 형식이지만 더 상세한 분석 덕분에 더 많은 정보를 포함합니다. Google 권장 사항: 매핑 파일을 무기한 보관 — 이전 버전의 크래시를 난독화 해제하는 데 필요합니다; 자동 업로드를 통해 매핑 파일을 Firebase Crashlytics와 통합; Firebase 콘솔에서 난독화 해제가 클래스 이름을 올바르게 복원하는지 정기적으로 확인.

R8 전체 모드 테스트

R8 전체 모드는 표준 모드에서 도달 가능한 것으로 간주되는 코드를 제거할 수 있습니다. 테스트가 중요한 영역: WebView가 있는 화면(R8이 브리지 인터페이스 클래스를 제거할 수 있음), classLoader를 통한 플러그인이 있는 애플리케이션, 분석 및 크래시 보고 라이브러리, inflate를 통해 생성된 레이아웃 파일의 사용자 정의 뷰.

빌드 크기 모니터링

Google은 모든 빌드에서 R8을 적용한 후 APK 크기를 추적할 것을 권장합니다. Android Studio의 APK Analyzer를 사용하여 개별 구성 요소의 크기를 비교하세요: classes.dex, resources.arsc 및 네이티브 코드 라이브러리. R8은 DEX 파일 크기에 비선형적으로 영향을 미칠 수 있습니다 — 때로는 적극적인 최적화로 인해 인라인화로 인해 크기가 증가할 수 있습니다. 정기적인 모니터링은 이상 징후를 적시에 감지하고 난독화 규칙을 조정하는 데 도움이 됩니다.

// Firebase Crashlytics를 위해 보존된 클래스 예제
@Keep
class CrashLogger {
    fun logException(e: Throwable) {
        FirebaseCrashlytics.getInstance().recordException(e)
    }
}

// rules.pro — @Keep이 있는 모든 클래스 유지
// -keep @androidx.annotation.Keep class * { *; }