[Android] AndroidX로 마이그레이션 해야 하는 이유와 방법

AndroidX로 마이그레이션 해야 하는 이유와 방법

Android 개발을 하다 보면 Support Library와 AndroidX라는 용어를 자주 접하게 됩니다. 특히 기존 프로젝트를 유지보수하거나 새로운 라이브러리를 추가할 때 호환성 문제로 곤란을 겪는 경우가 많습니다.

AndroidX는 Google이 Android Support Library를 대체하기 위해 출시한 차세대 라이브러리 패키지입니다. 2018년 발표된 이후 모든 새로운 Android Jetpack 컴포넌트는 AndroidX를 기반으로 개발되고 있으며, Support Library는 더 이상 업데이트되지 않습니다.

이 글에서는 AndroidX가 무엇인지, Support Library와 어떻게 다른지, 왜 마이그레이션해야 하는지, 그리고 실제로 어떻게 마이그레이션하는지 단계별로 상세히 설명합니다. 기존 프로젝트를 운영 중이거나 새 프로젝트를 시작하는 개발자라면 반드시 알아야 할 내용입니다.

목차

1. AndroidX란 무엇인가

2. Support Library와의 차이점

3. AndroidX 마이그레이션 방법

4. AndroidX 사용 시 주의사항

5. 자주 묻는 질문 (FAQ)

---

#1. AndroidX란 무엇인가

AndroidX는 Android 팀이 Jetpack 내에서 라이브러리를 개발, 테스트, 패키지화, 버전 관리 및 릴리스하기 위해 사용하는 오픈소스 프로젝트입니다. Android 앱 개발의 현대화와 일관성을 위해 탄생했습니다.

1) AndroidX의 탄생 배경

Android Support Library는 오랫동안 하위 호환성을 제공하는 핵심 도구였습니다. 하지만 시간이 지나면서 여러 문제점이 드러났습니다.

(1) Support Library의 한계

① 복잡한 패키지 네이밍: android.support.v4, v7, v13 등 버전 번호가 패키지명에 포함되어 혼란스러웠습니다.
② 불규칙한 버전 관리: 모든 라이브러리가 동일한 버전 번호를 사용해야 했고, 독립적인 업데이트가 불가능했습니다.
③ 크기 증가: 시간이 지남에 따라 Support Library는 점점 비대해졌습니다.
④ 유지보수 어려움: 레거시 코드와 새로운 기능이 뒤섞여 관리가 어려웠습니다.

(2) AndroidX의 목표

이러한 문제를 해결하기 위해 Google은 AndroidX라는 새로운 라이브러리 체계를 도입했습니다. 주요 목표는 다음과 같습니다.

① 명확한 패키지 구조: 모든 패키지가 androidx로 시작하는 일관된 네임스페이스 사용
② 독립적인 버전 관리: 각 라이브러리가 독립적으로 업데이트 가능
③ Semantic Versioning: version 1.0.0부터 시작하는 명확한 버전 체계
④ 모듈화와 최적화: 필요한 라이브러리만 선택적으로 사용 가능

. . . . .

2) AndroidX의 핵심 특징

AndroidX는 단순한 이름 변경이 아닌, Android 개발 생태계의 근본적인 개선입니다.

(1) 일관된 네임스페이스

AndroidX의 모든 패키지는 androidx로 시작합니다. 이는 Android 프레임워크(android.*) 및 기존 Support Library(android.support.*)와 명확히 구분됩니다.

구분	Support Library	AndroidX
AppCompat	android.support.v7.app	androidx.appcompat
RecyclerView	android.support.v7.widget	androidx.recyclerview.widget
Fragment	android.support.v4.app	androidx.fragment.app
ConstraintLayout	android.support.constraint	androidx.constraintlayout.widget

(2) 독립적인 버전 관리

Support Library에서는 모든 라이브러리가 동일한 버전을 사용해야 했습니다. 예를 들어 appcompat과 recyclerview 모두 28.0.0을 사용해야 했습니다.

반면 AndroidX에서는 각 라이브러리가 독립적으로 버전을 관리합니다. appcompat이 1.2.0일 때 recyclerview는 1.1.0을 사용할 수 있습니다.

// Support Library - 모든 버전이 동일해야 함
implementation 'com.android.support:appcompat-v7:28.0.0'
implementation 'com.android.support:recyclerview-v7:28.0.0'
implementation 'com.android.support:cardview-v7:28.0.0'

// AndroidX - 각 라이브러리가 독립적인 버전 사용 가능
implementation 'androidx.appcompat:appcompat:1.3.1'
implementation 'androidx.recyclerview:recyclerview:1.2.1'
implementation 'androidx.cardview:cardview:1.0.0'

(3) Semantic Versioning 적용

AndroidX는 Semantic Versioning(유의적 버전)을 엄격하게 따릅니다. 버전 번호는 MAJOR.MINOR.PATCH 형식을 사용합니다.

① MAJOR: 호환되지 않는 API 변경 시 증가
② MINOR: 이전 버전과 호환되는 기능 추가 시 증가
③ PATCH: 이전 버전과 호환되는 버그 수정 시 증가

이를 통해 개발자는 업데이트로 인한 영향을 예측할 수 있습니다. 예를 들어 1.2.3에서 1.2.4로 업데이트는 안전하지만, 2.0.0으로 업데이트는 주의가 필요합니다.

. . . . .

3) AndroidX와 Jetpack의 관계

AndroidX는 Android Jetpack의 기술적 기반입니다. Jetpack은 Android 앱 개발을 가속화하기 위한 라이브러리, 도구, 가이드의 모음이며, 대부분의 Jetpack 컴포넌트는 AndroidX 라이브러리로 제공됩니다.

(1) Jetpack 주요 컴포넌트

① Foundation: AppCompat, Android KTX, Multidex
② Architecture: Lifecycle, ViewModel, LiveData, Room, WorkManager
③ Behavior: Notifications, Permissions, Sharing, Slices
④ UI: Animation, Emoji, Fragment, Layout, Palette

이 모든 컴포넌트는 androidx 패키지를 사용하며, Support Library를 기반으로 하지 않습니다.

(2) 왜 Jetpack이 중요한가

Google은 모든 새로운 기능과 업데이트를 AndroidX/Jetpack을 통해서만 제공합니다. Support Library는 28.0.0을 마지막으로 더 이상 업데이트되지 않습니다.

따라서 최신 Android 기능을 사용하고, 최신 보안 패치와 버그 수정을 받으려면 AndroidX 마이그레이션이 필수입니다.

---

#2. Support Library와의 차이점

AndroidX와 Support Library는 같은 목적을 가지고 있지만, 구조와 철학에서 큰 차이가 있습니다. 두 라이브러리의 구체적인 차이를 이해하면 마이그레이션의 필요성을 명확히 알 수 있습니다.

1) 패키지 구조 비교

가장 눈에 띄는 차이는 패키지 네이밍 체계입니다. Support Library의 복잡한 버전 번호 시스템이 AndroidX에서는 깔끔하게 정리되었습니다.

(1) Support Library의 혼란스러운 구조

Support Library는 android.support.v숫자 형식을 사용했습니다. 문제는 이 버전 번호가 실제 지원 API 레벨과 관련이 없다는 것입니다.

예를 들어 android.support.v4는 API 4(Android 1.6) 이상을 지원한다는 의미가 아니라, 단순히 역사적인 이름일 뿐입니다. v7은 실제로 API 14 이상을 지원합니다.

Support Library	실제 최소 API 레벨	주요 컴포넌트
support-v4	API 14 (ICS)	Fragment, ViewPager, Loader
appcompat-v7	API 14 (ICS)	AppCompatActivity, Toolbar
recyclerview-v7	API 14 (ICS)	RecyclerView
support-v13	API 13 (HC)	Fragment for tablet

(2) AndroidX의 명확한 구조

AndroidX는 기능별로 논리적인 패키지명을 사용합니다. 패키지명만 봐도 어떤 기능인지 바로 알 수 있습니다.

// Support Library - 버전 번호 포함
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.RecyclerView;
import android.support.v4.app.Fragment;

// AndroidX - 기능별 명확한 네임스페이스
import androidx.appcompat.app.AppCompatActivity;
import androidx.recyclerview.widget.RecyclerView;
import androidx.fragment.app.Fragment;

. . . . .

2) 버전 관리 방식 비교

Support Library와 AndroidX는 버전 관리 철학이 근본적으로 다릅니다.

(1) Support Library의 일괄 버전 관리

Support Library는 모든 라이브러리가 동일한 버전을 사용해야 했습니다. 이는 다음과 같은 문제를 야기했습니다.

① 강제 업데이트: 하나의 라이브러리를 업데이트하려면 모든 라이브러리를 함께 업데이트해야 함
② 의존성 충돌: 서로 다른 버전을 요구하는 라이브러리들 간의 충돌 발생
③ 불필요한 업데이트: 필요 없는 라이브러리도 함께 업데이트되어 APK 크기 증가

// 잘못된 예시 - 버전 불일치로 빌드 실패
implementation 'com.android.support:appcompat-v7:28.0.0'
implementation 'com.android.support:recyclerview-v7:27.1.1' // 에러 발생!

(2) AndroidX의 독립적 버전 관리

AndroidX는 각 라이브러리가 독립적인 버전을 가집니다. Semantic Versioning을 따르므로 업데이트의 영향을 예측할 수 있습니다.

// 각 라이브러리가 독립적인 버전 사용 - 정상 작동
implementation 'androidx.appcompat:appcompat:1.3.1'
implementation 'androidx.recyclerview:recyclerview:1.2.1'
implementation 'androidx.lifecycle:lifecycle-runtime:2.4.0'
implementation 'androidx.room:room-runtime:2.3.0'

이를 통해 필요한 라이브러리만 선택적으로 업데이트할 수 있어, 안정성과 유연성이 크게 향상됩니다.

. . . . .

3) 기능 및 유지보수 차이

(1) Support Library 지원 종료

Support Library 28.0.0(2018년 9월 릴리스)이 마지막 버전입니다. 이후 버그 수정, 보안 패치, 새로운 기능이 전혀 제공되지 않습니다.

이는 Support Library를 계속 사용하는 앱이 다음과 같은 위험에 노출된다는 의미입니다.

① 보안 취약점: 발견된 보안 문제가 수정되지 않음
② 버그 지속: 알려진 버그가 해결되지 않음
③ 최신 기능 사용 불가: Android 새 버전의 기능 활용 불가
④ 라이브러리 호환성 문제: 새로운 서드파티 라이브러리와 충돌 가능

(2) AndroidX 지속적 개발

AndroidX는 활발히 개발 및 유지보수되고 있습니다. Google의 모든 새로운 Jetpack 컴포넌트는 AndroidX로만 출시됩니다.

최근 추가된 주요 기능들은 모두 AndroidX를 기반으로 합니다.

① Jetpack Compose: 현대적인 선언형 UI 프레임워크
② CameraX: 간소화된 카메라 API
③ Hilt: 의존성 주입 라이브러리
④ DataStore: SharedPreferences 대체
⑤ Paging 3: 대량 데이터 로딩 최적화

. . . . .

4) 성능과 크기 비교

AndroidX는 Support Library보다 더 모듈화되고 최적화되어 있습니다.

(1) 모듈화 개선

Support Library의 경우 support-v4가 매우 비대했습니다. 필요하지 않은 기능까지 포함되어 APK 크기가 불필요하게 증가했습니다.

AndroidX는 세분화된 모듈 구조를 채택했습니다. 예를 들어 v4는 다음과 같이 분리되었습니다.

① androidx.core: 핵심 유틸리티
② androidx.fragment: Fragment 관련 기능
③ androidx.loader: Loader 기능
④ androidx.viewpager: ViewPager
⑤ androidx.drawerlayout: DrawerLayout

이를 통해 필요한 기능만 선택적으로 포함할 수 있어 APK 크기를 줄일 수 있습니다.

(2) ProGuard 최적화

AndroidX는 더 나은 ProGuard 규칙을 제공하여 빌드 시 불필요한 코드를 효과적으로 제거할 수 있습니다.

---

#3. AndroidX 마이그레이션 방법

기존 프로젝트를 AndroidX로 마이그레이션하는 것은 생각보다 간단합니다. Android Studio가 대부분의 작업을 자동으로 처리해주기 때문입니다.

1) 마이그레이션 전 준비사항

마이그레이션 전에 반드시 확인해야 할 사항들이 있습니다. 이를 건너뛰면 예상치 못한 문제가 발생할 수 있습니다.

(1) 프로젝트 백업

Git 커밋 또는 프로젝트 전체 백업을 반드시 수행하세요. 마이그레이션은 프로젝트 전체의 import 문을 변경하므로, 문제 발생 시 롤백할 수 있어야 합니다.

# Git 사용 시
git add .
git commit -m "Before AndroidX migration"
git branch backup-before-androidx

(2) 빌드 환경 확인

AndroidX를 사용하려면 다음 요구사항을 만족해야 합니다.

① Android Studio 3.2 이상 (최신 버전 권장)
② Gradle Plugin 3.2.0 이상
③ compileSdkVersion 28 이상
④ 모든 Support Library 버전 28.0.0으로 통일

// build.gradle (Project level)
buildscript {
    dependencies {
        classpath 'com.android.tools.build:gradle:7.0.0' // 3.2.0 이상
    }
}

// build.gradle (App level)
android {
    compileSdkVersion 33 // 28 이상
}

(3) 서드파티 라이브러리 확인

프로젝트에서 사용 중인 서드파티 라이브러리가 AndroidX를 지원하는지 확인하세요. 대부분의 주요 라이브러리는 이미 AndroidX를 지원하지만, 오래된 라이브러리는 업데이트가 필요할 수 있습니다.

. . . . .

2) Android Studio 자동 마이그레이션

Android Studio는 원클릭 마이그레이션 기능을 제공합니다. 이것이 가장 권장되는 방법입니다.

(1) 마이그레이션 실행

① Android Studio 메뉴에서 Refactor → Migrate to AndroidX 선택
② 프로젝트 백업 여부를 묻는 대화상자가 표시됨 - 반드시 백업 선택
③ AndroidX로 변환될 클래스 매핑을 보여주는 프리뷰 확인
④ "Do Refactor" 버튼 클릭하여 마이그레이션 시작

Android Studio는 다음 작업을 자동으로 수행합니다.

① 모든 import 문을 Support Library에서 AndroidX로 변경
② build.gradle 파일의 의존성을 AndroidX 라이브러리로 교체
③ XML 레이아웃 파일의 클래스명을 AndroidX로 업데이트
④ ProGuard 규칙 파일 업데이트

(2) gradle.properties 설정

마이그레이션 후 gradle.properties 파일에 다음 플래그가 자동으로 추가됩니다.

# gradle.properties

# AndroidX 사용 활성화
android.useAndroidX=true

# 서드파티 라이브러리를 AndroidX로 자동 변환
android.enableJetifier=true

① android.useAndroidX=true: Android 플러그인이 Support Library 대신 AndroidX 라이브러리를 사용하도록 설정합니다.
② android.enableJetifier=true: 아직 AndroidX를 지원하지 않는 서드파티 라이브러리를 자동으로 변환합니다. 이는 과도기적 호환성 도구입니다.

. . . . .

3) 수동 마이그레이션

자동 마이그레이션이 실패하거나 특정 부분만 변경하고 싶은 경우, 수동으로 마이그레이션할 수 있습니다.

(1) build.gradle 의존성 변경

build.gradle 파일의 모든 Support Library 의존성을 AndroidX로 교체합니다.

// 변경 전 - Support Library
dependencies {
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation 'com.android.support:recyclerview-v7:28.0.0'
    implementation 'com.android.support:cardview-v7:28.0.0'
    implementation 'com.android.support:design:28.0.0'
    implementation 'com.android.support.constraint:constraint-layout:1.1.3'
}

// 변경 후 - AndroidX
dependencies {
    implementation 'androidx.appcompat:appcompat:1.3.1'
    implementation 'androidx.recyclerview:recyclerview:1.2.1'
    implementation 'androidx.cardview:cardview:1.0.0'
    implementation 'com.google.android.material:material:1.4.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.1.0'
}

전체 매핑 목록은 Android 공식 문서의 Package Refactoring 페이지에서 확인할 수 있습니다.

(2) Java/Kotlin 파일 import 변경

모든 Java 및 Kotlin 파일의 import 문을 변경해야 합니다. Android Studio의 Find and Replace(Ctrl+Shift+R) 기능을 활용하면 효율적입니다.

// 변경 전
import android.support.v7.app.AppCompatActivity;
import android.support.v7.widget.RecyclerView;
import android.support.v4.app.Fragment;
import android.support.design.widget.FloatingActionButton;

// 변경 후
import androidx.appcompat.app.AppCompatActivity;
import androidx.recyclerview.widget.RecyclerView;
import androidx.fragment.app.Fragment;
import com.google.android.material.floatingactionbutton.FloatingActionButton;

(3) XML 레이아웃 파일 변경

XML 레이아웃 파일에서 Support Library 위젯을 사용한 경우, 전체 클래스 경로를 AndroidX로 변경해야 합니다.

<!-- 변경 전 -->
<android.support.v7.widget.RecyclerView
    android:id="@+id/recycler_view"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

<!-- 변경 후 -->
<androidx.recyclerview.widget.RecyclerView
    android:id="@+id/recycler_view"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

. . . . .

4) 새 프로젝트에서 AndroidX 사용

새로운 프로젝트를 시작하는 경우 처음부터 AndroidX를 사용하는 것이 좋습니다.

(1) 프로젝트 생성 시 설정

Android Studio 3.4.2 이상에서 새 프로젝트를 생성하면 기본적으로 AndroidX가 활성화됩니다. 프로젝트 생성 마법사에서 "Use androidx.* artifacts" 옵션이 체크되어 있는지 확인하세요.

(2) gradle.properties 확인

새 프로젝트의 gradle.properties에 다음 설정이 포함되어 있는지 확인합니다.

android.useAndroidX=true
android.enableJetifier=true

(3) build.gradle 설정

compileSdkVersion을 최신 버전으로 설정하고, AndroidX 라이브러리를 사용합니다.

android {
    compileSdkVersion 33
    defaultConfig {
        minSdkVersion 21
        targetSdkVersion 33
    }
}

dependencies {
    implementation 'androidx.appcompat:appcompat:1.5.1'
    implementation 'com.google.android.material:material:1.7.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.1.4'
}

---

#4. AndroidX 사용 시 주의사항

AndroidX로 마이그레이션하거나 새 프로젝트를 시작할 때 주의해야 할 사항들이 있습니다. 이를 미리 알고 있으면 많은 시행착오를 줄일 수 있습니다.

1) Support Library와 AndroidX 혼용 금지

절대로 Support Library와 AndroidX를 동일 프로젝트에서 함께 사용해서는 안 됩니다. 이는 심각한 빌드 오류와 런타임 충돌을 일으킵니다.

(1) 문제 상황

다음과 같은 상황에서 혼용 문제가 발생합니다.

① 메인 프로젝트는 AndroidX를 사용하는데, 서드파티 라이브러리가 Support Library를 사용하는 경우
② 멀티 모듈 프로젝트에서 일부 모듈만 AndroidX로 마이그레이션한 경우
③ 개발자가 실수로 Support Library 의존성을 추가한 경우

(2) 해결 방법

① android.enableJetifier=true: 이 플래그는 Support Library를 사용하는 라이브러리를 자동으로 AndroidX로 변환합니다.
② 라이브러리 업데이트: 서드파티 라이브러리를 AndroidX를 지원하는 최신 버전으로 업데이트합니다.
③ 전체 마이그레이션: 모든 모듈을 동시에 AndroidX로 마이그레이션합니다.

. . . . .

2) Jetifier 사용과 한계

Jetifier는 편리한 도구이지만, 영구적인 해결책이 아닙니다. 가능한 한 빨리 모든 라이브러리를 AndroidX 버전으로 교체해야 합니다.

(1) Jetifier란

Jetifier는 빌드 시점에 Support Library를 사용하는 바이너리를 AndroidX로 자동 변환하는 도구입니다. android.enableJetifier=true로 활성화됩니다.

하지만 Jetifier는 모든 경우를 완벽하게 처리하지 못합니다. 특히 리플렉션을 사용하거나 JNI 코드가 있는 라이브러리는 제대로 변환되지 않을 수 있습니다.

(2) Jetifier 비활성화 전략

장기적으로는 android.enableJetifier=false로 설정하는 것이 목표입니다. 이를 위해 다음 단계를 따르세요.

① 프로젝트의 모든 직접 의존성을 AndroidX 버전으로 교체
② 간접 의존성(의존성의 의존성)도 AndroidX를 사용하는지 확인
③ Jetifier를 비활성화하고 빌드가 성공하는지 테스트
④ 실패 시 원인이 되는 라이브러리를 찾아 업데이트 또는 대체

# Jetifier 의존성 확인 명령어
./gradlew :app:dependencies | grep "support"

. . . . .

3) 버전 관리 전략

AndroidX는 독립적인 버전 관리를 하므로, 버전 호환성을 체계적으로 관리해야 합니다.

(1) BOM(Bill of Materials) 사용

일부 AndroidX 라이브러리는 BOM을 통한 버전 관리를 지원합니다. 이를 사용하면 호환되는 버전이 자동으로 선택됩니다.

dependencies {
    // Compose BOM 사용 예시
    def composeBom = platform('androidx.compose:compose-bom:2023.10.01')
    implementation composeBom
    androidTestImplementation composeBom

    // BOM 덕분에 버전 명시 불필요
    implementation 'androidx.compose.material3:material3'
    implementation 'androidx.compose.ui:ui'
    implementation 'androidx.compose.ui:ui-tooling-preview'
}

(2) 안정 버전 사용 권장

AndroidX 라이브러리는 alpha, beta, rc, stable 단계로 릴리스됩니다. 프로덕션 앱에는 stable 버전 사용을 권장합니다.

① alpha: 초기 개발 버전, API 변경 가능
② beta: 기능 완성, API 거의 확정
③ rc(Release Candidate): 최종 테스트 버전
④ stable: 안정 버전, 프로덕션 사용 권장

. . . . .

4) ProGuard/R8 설정

AndroidX는 자체 ProGuard 규칙을 포함하고 있지만, 일부 경우 추가 설정이 필요할 수 있습니다.

(1) 자동 규칙 포함

대부분의 AndroidX 라이브러리는 consumer-proguard-rules를 포함하고 있어, 추가 설정 없이도 정상 작동합니다.

(2) 리플렉션 사용 주의

AndroidX 클래스를 리플렉션으로 접근하는 경우, ProGuard 규칙에 -keep 규칙을 추가해야 합니다.

# proguard-rules.pro
-keep class androidx.** { *; }
-keep interface androidx.** { *; }

다만 이렇게 전체를 keep하면 APK 크기가 증가하므로, 필요한 클래스만 선택적으로 keep하는 것이 좋습니다.

. . . . .

5) 멀티 모듈 프로젝트 관리

멀티 모듈 프로젝트에서는 모든 모듈이 일관되게 AndroidX를 사용해야 합니다.

(1) 중앙 집중식 버전 관리

프로젝트 루트의 build.gradle 또는 별도의 versions.gradle 파일에서 버전을 중앙 관리하는 것이 좋습니다.

// versions.gradle
ext {
    androidxAppcompat = '1.5.1'
    androidxCore = '1.9.0'
    androidxLifecycle = '2.5.1'
}

// 각 모듈의 build.gradle
dependencies {
    implementation "androidx.appcompat:appcompat:$androidxAppcompat"
    implementation "androidx.core:core-ktx:$androidxCore"
}

(2) Gradle Version Catalog 활용

Gradle 7.0 이상에서는 Version Catalog를 사용하여 더욱 체계적인 의존성 관리가 가능합니다.

# gradle/libs.versions.toml
[versions]
androidx-appcompat = "1.5.1"
androidx-core = "1.9.0"

[libraries]
androidx-appcompat = { module = "androidx.appcompat:appcompat", version.ref = "androidx-appcompat" }
androidx-core-ktx = { module = "androidx.core:core-ktx", version.ref = "androidx-core" }

// build.gradle
dependencies {
    implementation libs.androidx.appcompat
    implementation libs.androidx.core.ktx
}

---

#5. 자주 묻는 질문 (FAQ)

1) Q: 기존 프로젝트를 반드시 AndroidX로 마이그레이션해야 하나요?

A: 네, 가능한 한 빨리 마이그레이션하는 것을 강력히 권장합니다. Support Library는 28.0.0 이후 더 이상 업데이트되지 않으며, 보안 패치와 버그 수정도 제공되지 않습니다. 또한 새로운 Android 기능과 Jetpack 컴포넌트는 모두 AndroidX를 기반으로 하므로, Support Library를 계속 사용하면 최신 기능을 활용할 수 없습니다. 마이그레이션은 Android Studio가 대부분 자동으로 처리하므로 생각보다 간단합니다.

. . . . .

2) Q: 마이그레이션 후 앱이 빌드되지 않습니다. 어떻게 해야 하나요?

A: 먼저 오류 메시지를 자세히 확인하세요. 대부분의 경우 다음 중 하나가 원인입니다. ① Support Library와 AndroidX가 혼재된 경우: gradle.properties에서 android.enableJetifier=true로 설정하세요. ② 서드파티 라이브러리 충돌: 라이브러리를 최신 버전으로 업데이트하거나, AndroidX를 지원하는 대체 라이브러리를 찾으세요. ③ import 문 누락: Android Studio의 "Optimize Imports" 기능(Ctrl+Alt+O)을 사용하여 누락된 import를 자동으로 추가할 수 있습니다. 그래도 해결되지 않으면 Clean Project → Rebuild Project를 시도하세요.

. . . . .

3) Q: android.enableJetifier는 언제까지 사용해야 하나요?

A: Jetifier는 과도기적 호환성 도구로, 영구적으로 사용하도록 설계되지 않았습니다. 모든 직접 및 간접 의존성이 AndroidX를 네이티브로 지원하게 되면 android.enableJetifier=false로 설정해야 합니다. 이는 빌드 시간을 단축하고 잠재적인 변환 오류를 방지합니다. 프로젝트의 의존성 트리를 확인하여 Support Library를 사용하는 라이브러리가 없다면 Jetifier를 비활성화할 수 있습니다.

. . . . .

4) Q: 새 프로젝트를 시작할 때 AndroidX를 사용하지 않을 이유가 있나요?

A: 없습니다. 새 프로젝트는 처음부터 AndroidX를 사용해야 합니다. Android Studio 3.4.2 이상에서는 새 프로젝트 생성 시 기본적으로 AndroidX가 활성화됩니다. AndroidX는 Support Library의 완전한 대체재이며, 더 나은 구조와 지속적인 업데이트를 제공합니다. Support Library로 시작하는 것은 곧 마이그레이션해야 할 기술 부채를 만드는 것과 같습니다.

. . . . .

5) Q: AndroidX 버전 번호가 너무 낮은데(1.x.x) 안정적인가요?

A: 네, 매우 안정적입니다. AndroidX는 Semantic Versioning을 사용하므로 1.0.0부터 시작합니다. 이는 초기 버전이라는 의미가 아니라, 안정적인 첫 메이저 버전이라는 의미입니다. 실제로 AndroidX 1.0.0은 Support Library 28.0.0과 기능적으로 동등하거나 더 나은 수준입니다. 버전 번호가 낮다고 해서 품질이 낮은 것은 아닙니다.

. . . . .

6) Q: 각 AndroidX 라이브러리의 버전이 달라도 호환성 문제는 없나요?

A: 일반적으로 호환성 문제가 없습니다. AndroidX의 핵심 장점 중 하나가 바로 독립적인 버전 관리입니다. 각 라이브러리는 자체 Semantic Versioning을 따르므로, 다른 버전을 사용해도 문제가 없도록 설계되었습니다. 다만 특정 라이브러리 간에 의존성이 있는 경우(예: lifecycle-runtime과 lifecycle-viewmodel), 호환되는 버전 조합을 사용하는 것이 좋습니다. 공식 문서나 라이브러리의 릴리스 노트에서 권장 버전을 확인하세요.

. . . . .

7) Q: Support Library v4와 v7의 차이가 무엇이었나요? AndroidX에서는 어떻게 바뀌었나요?

A: Support Library에서 v4는 Fragment, ViewPager 등 범용 컴포넌트를, v7은 AppCompat, RecyclerView 등 Material Design 관련 컴포넌트를 포함했습니다. 하지만 이 구분은 역사적인 이유일 뿐 실제 API 레벨과는 관련이 없었습니다. AndroidX에서는 기능별로 논리적인 패키지 구조로 재편되었습니다. v4는 androidx.fragment, androidx.viewpager 등으로 분리되었고, v7은 androidx.appcompat, androidx.recyclerview 등으로 분리되었습니다. 이제 패키지명만 보고도 어떤 기능인지 명확히 알 수 있습니다.

. . . . .

8) Q: 마이그레이션 후 APK 크기가 증가했습니다. 정상인가요?

A: 초기에는 약간의 크기 증가가 있을 수 있습니다. 하지만 장기적으로는 AndroidX의 모듈화된 구조 덕분에 APK 크기를 더 효과적으로 관리할 수 있습니다. 크기가 크게 증가했다면 다음을 확인하세요. ① ProGuard/R8이 제대로 적용되었는지 확인 ② 불필요한 AndroidX 라이브러리를 포함하고 있지 않은지 확인 ③ android.enableJetifier가 활성화된 경우 Support Library와 AndroidX 코드가 중복될 수 있으므로, 가능하면 Jetifier를 비활성화하세요.

. . . . .

9) Q: AndroidX를 사용하면 최소 SDK 버전이 올라가나요?

A: 아니요. AndroidX는 Support Library와 동일한 하위 호환성을 제공합니다. 대부분의 AndroidX 라이브러리는 API 14(Android 4.0) 이상을 지원하며, 일부는 더 낮은 버전도 지원합니다. 따라서 AndroidX로 마이그레이션해도 지원 가능한 Android 버전 범위는 변하지 않습니다. 오히려 AndroidX의 지속적인 업데이트를 통해 최신 Android 버전의 기능을 하위 버전에서도 사용할 수 있게 됩니다.

. . . . .

10) Q: 서드파티 라이브러리가 AndroidX를 지원하지 않으면 어떻게 하나요?

A: 다음 단계로 대응할 수 있습니다. ① 라이브러리 업데이트: 최신 버전으로 업데이트하면 대부분 AndroidX를 지원합니다. ② Jetifier 사용: android.enableJetifier=true로 설정하여 자동 변환을 시도하세요. ③ 대체 라이브러리 찾기: 동일 기능을 제공하는 AndroidX 지원 라이브러리로 교체하세요. ④ 직접 수정: 오픈소스 라이브러리라면 fork하여 직접 AndroidX로 마이그레이션할 수 있습니다. ⑤ 라이브러리 제거 고려: 필수적이지 않은 라이브러리라면 제거하고 직접 구현하는 것도 방법입니다.

---

마무리

AndroidX는 Android 앱 개발의 미래입니다. Support Library의 모든 기능을 포함하면서도, 더 명확한 구조, 독립적인 버전 관리, 지속적인 업데이트를 제공합니다.

이 글에서 다룬 핵심 내용을 정리하면 다음과 같습니다.

① AndroidX는 필수: Support Library는 더 이상 업데이트되지 않으며, 새로운 기능은 모두 AndroidX로 제공됩니다.
② 명확한 구조: androidx로 시작하는 일관된 네임스페이스와 기능별 패키지 구조로 혼란이 사라졌습니다.
③ 독립적 버전 관리: 각 라이브러리가 Semantic Versioning을 따르며 독립적으로 업데이트됩니다.
④ 쉬운 마이그레이션: Android Studio의 자동 마이그레이션 도구가 대부분의 작업을 처리합니다.
⑤ 장기 지원: Google은 AndroidX를 통해 지속적으로 새로운 기능과 개선사항을 제공합니다.

기존 프로젝트를 운영 중이라면 가능한 한 빨리 AndroidX로 마이그레이션하는 것이 좋습니다. 시간이 지날수록 의존성이 복잡해져 마이그레이션이 어려워질 수 있습니다.

새 프로젝트를 시작한다면 처음부터 AndroidX를 사용하세요. Android Studio 최신 버전은 기본적으로 AndroidX를 활성화하므로, 별도의 설정 없이도 바로 시작할 수 있습니다.

AndroidX로의 전환은 단순한 라이브러리 교체가 아닌, 현대적이고 유지보수 가능한 Android 앱 개발로 나아가는 중요한 단계입니다. 이 가이드가 AndroidX 이해와 마이그레이션에 도움이 되기를 바랍니다.

긴 글 읽어주셔서 감사합니다.

끝.