ProGuard — 개요, 기능 및 난독화 구성

ProGuard란?

ProGuard는 Guardsquare에서 개발한 Java 바이트코드 처리를 위한 무료 배포 도구입니다. Android SDK에 내장되어 있으며 코드 축소, 최적화 및 난독화의 세 가지 주요 기능을 수행합니다. ProGuard는 애플리케이션과 그 종속성의 모든 바이트코드를 분석하고 사용하지 않는 클래스와 메서드를 식별하여 제거한 다음 나머지 코드를 난독화합니다.

역사 및 위치

ProGuard는 2000년 Eric Lafortune이 Java 애플리케이션 최적화 도구로 만들었습니다. 2008년 Android의 등장과 함께 ProGuard는 Android SDK에 통합되어 애플리케이션 보호의 표준 도구가 되었습니다. Guardsquare 통계(2024)에 따르면 ProGuard는 Google Play의 80% 이상의 애플리케이션에서 사용되며, 주요 은행 및 기술 기업의 앱을 포함합니다.

ProGuard가 코드를 처리하는 방법

ProGuard는 네 단계로 처리를 수행합니다. 첫 번째 단계(축소)에서 도구는 애플리케이션의 진입점을 분석하고 실행 중에 도달할 수 있는 클래스, 메서드 및 필드를 결정합니다. 두 번째 단계(최적화)에서 ProGuard는 성능 향상을 위해 바이트코드를 변환합니다. 세 번째 단계(난독화)는 식별자의 이름을 변경합니다. 마지막 단계에서 preverify는 가상 머신에서 바이트코드 검증에 필요한 메타데이터를 추가합니다.

ProGuard의 주요 기능

ProGuard의 세 가지 주요 기능인 축소, 최적화 및 난독화를 각각 자세히 살펴보겠습니다. 각 메커니즘을 이해하면 도구를 최적으로 구성하는 데 도움이 됩니다.

코드 축소

ProGuard는 진입점(main 메서드, Activity, BroadcastReceiver)에서 호출 그래프를 분석하고 사용하지 않는 코드를 제거합니다. Retrofit, OkHttp 및 Gson과 같은 라이브러리를 사용하는 일반적인 Android 프로젝트에서 축소는 사용하지 않는 라이브러리 메서드, 디버그 코드 및 테스트 클래스를 포함하여 최대 40%의 바이트코드를 제거할 수 있습니다. 이는 APK 크기를 직접 줄이고 애플리케이션 로드 시간을 단축합니다.

최적화

최적화 단계에서 ProGuard는 20가지 이상의 다양한 바이트코드 변환을 수행합니다: 짧은 메서드 인라인화, 사용하지 않는 매개변수 제거, 논리식 단순화, 동일한 코드 블록 병합. 예를 들어 짧은 getter와 setter는 직접 필드 액세스로 대체될 수 있습니다. 최적화는 애플리케이션 구조에 따라 코드 실행을 5-15%까지 가속화할 수 있습니다.

난독화

ProGuard의 난독화는 클래스, 메서드 및 필드를 a, b, c, a.a, a.b 등과 같은 짧은 문자 시퀀스로 이름을 변경하여 작동합니다. 이름이 변경된 요소에 대한 모든 참조는 코드 전체에서 자동으로 업데이트됩니다. 난독화는 프로그램 동작을 변경하지 않으며 디컴파일된 코드의 이해를 어렵게 만들 뿐입니다. 라이브러리와 공개 API는 keep 규칙을 통해 난독화에서 제외되어야 합니다.

// ProGuard 난독화 전
public class LoginManager {
    public User authenticateUser(String username, String password) {
        // 인증 로직
    }
}

// ProGuard 난독화 후
public class a {
    public Object a(String b, String c) {
        // 이름이 변경된 식별자가 있는 동일한 로직
    }
}

Android 프로젝트에서 ProGuard 구성

ProGuard 구성은 Android 애플리케이션 빌드 설정의 중요한 단계입니다. 잘못된 규칙은 필요한 클래스의 제거로 이어져 릴리스 버전에서 충돌이 발생할 수 있습니다.

build.gradle의 기본 설정

Android 프로젝트에서 ProGuard를 활성화하려면 릴리스 빌드 유형에 대해 minifyEnabled 플래그를 true로 설정합니다. 표준 ProGuard 규칙은 proguard-android-optimize.txt 파일로 Android SDK에 포함되어 있습니다. 사용자 정의 규칙은 별도의 proguard-rules.pro 파일에 추가됩니다. 빌드 중에 ProGuard는 먼저 표준 규칙을 적용한 다음 사용자 정의 규칙을 적용하여 기본 구성을 재정의할 수 있습니다.

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt'
            ), 'proguard-rules.pro'
        }
    }
}

proguard-rules.pro 파일

사용자 정의 규칙 파일에는 특정 프로젝트에 대한 지시문이 포함됩니다. 일반적인 규칙에는 리플렉션을 통해 사용되는 클래스, Gson/Moshi 직렬화를 위한 데이터 모델, 라이브러리 콜백 인터페이스 및 특정 애너테이션으로 애너테이션된 클래스의 유지가 포함됩니다. 각 지시문은 -keep, -dontwarn 또는 -keepclassmembers 키워드로 시작하며 ProGuard가 수정해서는 안 되는 클래스의 패턴을 정의합니다.

# Gson용 데이터 모델 유지
-keep class com.example.data.model.** { *; }

# 리플렉션을 통해 사용되는 클래스 유지
-keep class * implements com.google.gson.TypeAdapterFactory

# 라이브러리 경고 무시
-dontwarn okhttp3.internal.**
-dontwarn retrofit2.**

# 열거형 유지 (ProGuard 기능)
-keep class * extends java.lang.Enum { *; }

ProGuard 규칙: keep, dontwarn 등

ProGuard 구성 문법에는 여러 범주의 지시문이 포함되며, 각각은 처리의 특정 측면을 관리합니다. 올바른 구성에 필요한 주요 지시문을 살펴보겠습니다.

리플렉션 및 동적 로딩

ProGuard는 리플렉션(Class.forName()), ServiceLoader 또는 동적 DEX 파일 로딩을 통해 로드된 코드를 정적으로 분석할 수 없습니다. 클래스가 문자열 이름으로 생성되는 경우 ProGuard는 그 존재를 알지 못하며 사용되지 않는 것으로 간주하여 제거할 수 있습니다. 이러한 모든 클래스는 -keep을 통해 명시적으로 유지되어야 합니다. 이는 ProGuard 활성화 후 릴리스 빌드에서 충돌의 가장 일반적인 원인입니다.

라이브러리 및 AAR 종속성

라이브러리에는 AAR 파일에 포함된 consumer-rules.pro를 통해 빌드에 자동으로 추가되는 자체 ProGuard 규칙이 포함되는 경우가 많습니다. Android Gradle Plugin은 빌드 중에 이러한 규칙을 자동으로 적용합니다. 개발자는 사용된 모든 라이브러리가 올바른 규칙을 제공하는지 확인하고 필요한 경우 프로젝트에서 이를 보완하기만 하면 됩니다.

ProGuard 문제 디버깅

ProGuard 활성화 후 오류가 발생하면 매핑 파일을 사용하여 스택 추적을 역난독화합니다. 진단을 위해 -whyareyoukeeping 키를 사용하면 출력 빌드에서 클래스가 유지되는 이유를 보여줍니다. -optimizationpasses와 -obfuscation을 일시적으로 비활성화하면 문제를 찾을 수 있습니다. Guardsquare에 따르면 80%의 ProGuard 문제는 리플렉션 클래스에 -keep 규칙을 추가하여 해결됩니다.

ProGuard와 R8 비교 및 마이그레이션

Android Gradle Plugin 3.4(2019)의 출시와 함께 Google은 D8/R8 컴파일러에 직접 통합된 R8을 도입했습니다. 2023년까지 R8은 AGP 8.0에서 ProGuard를 완전히 대체했지만, 프로젝트 마이그레이션을 위해서는 아키텍처 차이를 이해하는 것이 중요합니다.

아키텍처 차이

ProGuard는 DEX로 변환하기 전에 Java 바이트코드(.class 파일)를 처리하는 별도의 도구로 작동합니다. R8은 DEX 컴파일러에 통합되어 더 낮은 수준에서 코드를 처리하므로 ProGuard에서는 사용할 수 없는 최적화가 가능합니다. R8은 또한 디슈가링(Desugaring)을 지원합니다. 즉, Java 8+ 구문 설탕을 이전 Android API 수준에 대한 하위 호환 코드로 변환합니다.

R8의 장점

Google Android Performance Team(2025)에 따르면, R8은 동일한 규칙으로 ProGuard보다 10-15% 더 나은 코드 축소를 제공합니다. R8은 더 빠르며 빌드 시간이 20-30% 단축됩니다. 또한 R8은 클래스 파일 수준이 아닌 DEX 수준에서의 분석 덕분에 더 많은 데드 코드를 제거합니다. R8은 ProGuard 규칙 구문과 완전히 호환되므로 개발자에게 마이그레이션이 투명합니다.

마이그레이션 프로세스

ProGuard에서 R8로 전환하는 것은 간단합니다: AGP 8.0+에서는 R8이 기본적으로 사용됩니다. 이전 프로젝트의 경우 classpath에서 ProGuard를 제거하고 gradle.properties를 업데이트해야 합니다: android.enableR8=true. ProGuard 규칙은 대부분의 경우 변경 없이 R8과 호환됩니다. 전환 후에는 R8이 ProGuard가 유지했던 코드를 제거할 수 있으므로 모든 대상 기기에서 릴리스 빌드를 테스트하는 것이 좋습니다.