AGP 9.3 조용히 나왔습니다 — 6년차가 실무에서 체감한 변화만

 

얼마 전에 릴리스 빌드 돌려놓고 keep 규칙 하나 고치려고 또 5분을 멍하니 기다리고 있었어요. 그러다 AGP 9.3 릴리스 노트를 봤는데, 빌드 안 돌리고 R8 리포트만 뽑는 태스크가 딱 들어와 있더라고요.

 

배포 트윗 하나 없이 릴리스 노트만 조용히 갱신됐습니다(2026-07-14 기준). 근데 그 안에, 제가 3년째 "혹시 몰라서" 넣어둔 -keep 규칙을 점수로 까발리는 도구가 들어 있었어요. 6년차가 실무에서 진짜 만질 것만 골라서 정리해봤습니다.

 

AGP 9.0에서 터진 지진, 9.3은 그 안정화 라인

일단 흐름부터 짚어야 9.3이 왜 얇은지 이해가 됩니다. 2026년 리듬을 보면 9.0.1(1월) → 9.1.1·9.2.0(4월) → 9.3.0(7월), 분기 단위로 올라왔어요.

 

진짜 지진은 9.0이었습니다. built-in Kotlin 기본 활성화, CommonExtension 파라미터화 제거, Wear OS 앱 임베딩(wearApp)이랑 화면 밀도 기반 split APK 제거까지 전부 여기 몰려 있었거든요. 파괴적 변경이 9.0에 다 터진 거죠.

 

그 뒤로 9.1은 R8이 -repackageclasses를 사실상 기본으로 걸기 시작했고, 9.2는 테스트 결과·커버리지를 모듈·variant 통합해서 보여주는 HTML 대시보드 태스크가 들어왔습니다. 그러니까 9.3은 여진이에요. 근데 실무 접점은 오히려 여진 쪽이 더 자주 옵니다.

 

 

Android Gradle Plugin 9.3 올릴 때 Gradle·JDK 요구사항

Android Gradle Plugin 9.3으로 갈아탈 때 libs.versions.toml에서 버전 한 줄 바꾸는 걸로 끝나면 좋겠지만, 그렇게 간단하진 않습니다.

 

9.1.0 기준 요구사항이 큰 틀은 9.3에도 그대로 이어지는데요.

 

1. Gradle 9.1.0 이상
2. Build Tools 36.0.0
3. JDK 17 이상, compileSdk·targetSdk는 9.3에서 최대 API 37까지

 

여기서 제일 아픈 게 8.x에서 9.x로 갈 때 Gradle 메이저 업그레이드가 강제라는 점이에요. 우회가 안 됩니다. 그러니까 "마이너 하나 올리는 거 아냐?" 하고 접근하면 안 돼요.

 

AGP 업그레이드는 안드로이드 스튜디오(Android Studio)의 Upgrade Assistant가 자동으로 처리해주는 게 기본인데, 서드파티 그래들 플러그인이 신 androidComponents API에 대응 안 돼 있으면 손으로 만져야 하는 구간이 나옵니다. 참고로 9.3 정확한 최소 버전은 alpha/dev 채널이 섞여 있어서, stable 릴리스 노트를 다시 확인하시는 게 안전할 것 같습니다.

 

JDK 21 조합으로 빌드가 더 최적화됐다는 사례도 보고되고 있는데요. 개인적으로는 서드파티 플러그인 호환이 확실해지기 전까진 17을 유지하고 있어요. 빌드가 도는 게 최우선이라서요.

 

R8 Configuration Analyzer로 keep 규칙 진단하기

이번 9.3의 헤드라인이 바로 이겁니다. :app:analyzeReleaseR8Config 라는 단독 태스크예요.

 

원래는 assembleRelease나 bundleRelease를 돌려야 리포트가 나왔거든요. 컴파일 파이프라인 전체를 다 태우고 5분 기다렸다가 keep 하나 고치고 또 5분. 이 루프가 진짜 사람 잡았습니다. 근데 이제 빌드 없이 리포트만 뽑는 태스크가 생기면서 그 피드백 시간이 확 짧아졌어요.

 

리포트는 build/outputs/mapping/release/configanalyzer.html에 떨어집니다(9.3.0-alpha05 이상 기준). 열어보면 세 영역 점수가 분리돼 나와요.

 

1. shrinking — 얼마나 버릴 수 있는지
2. obfuscation — 이름을 얼마나 바꿀 수 있는지
3. optimization — 재작성 효율이 얼마나 나오는지

 

여기서 오해 하나 짚고 갈게요. R8 Configuration Analyzer 자체가 9.3 신규는 아닙니다. 애널라이저는 전부터 있었고, 9.3의 새 점은 "빌드 없이 독립 실행되는 태스크"라는 것입니다.

 

이게 왜 좋냐면, 과도한 keep을 느낌이 아니라 숫자로 잡아주기 때문이에요. -keep을 남발하면 축소 효율이 떨어지고 그게 곧 용량·성능 손해로 오는데, 그걸 점수로 정량화해서 보여주니까 keep 감사(監査)가 됩니다.

 

다만 한계도 분명합니다. 코드 축소·난독화를 켠 릴리스 빌드에서만 의미가 있어요. minifyEnabled false거나 디버그 빌드, 라이브러리 모듈에선 체감이 거의 없습니다. 그리고 점수 낮다고 무리하게 keep을 걷어내면 리플렉션·직렬화·JNI 경로에서 런타임 크래시가 날 수 있어요. 도구는 진단만 해주고, 걷어낼지 말지 판단은 사람 몫이라는 거죠.

 

 

built-in Kotlin과 DSL 에러, AGP 9 마이그레이션 함정

"9.0에서 kotlin-android 플러그인 지웠는데 빌드가 멀쩡히 돌아서 당황했다" — 이게 built-in Kotlin입니다. 9.0부터 기본 활성화라 플러그인을 명시 안 해도 코틀린(Kotlin)이 컴파일돼요. opt-out만 걸어두고 방치된 프로젝트가 아직도 많다고 합니다.

 

진짜 빌드를 깨는 건 DSL 쪽이에요. CommonExtension의 파라미터화가 제거되면서, 블록 메서드들이 ApplicationExtension·LibraryExtension·DynamicFeatureExtension·TestExtension으로 이사를 갔습니다. 그래서 8.x 스타일 DSL이 컴파일 단계에서 깨져요. applicationVariants 같은 옛 variant API도 deprecated 되면서 androidComponents로 넘어갔고요.

 

해소 순서는 이렇게 잡으시면 됩니다.

 

1. 플러그인 선언 정리 (built-in Kotlin opt-out 여부부터 확인)
2. DSL 블록을 새 Extension 위치로 재배치
3. variant 관련 코드를 androidComponents API로 이전

 

세 개 다 만져야 하니까, 레거시 대형 프로젝트라면 이건 "실무 며칠 멈추는 변화"에 가깝습니다. 가벼운 업데이트라고 생각하고 덤비면 리스크가 큽니다.

 

 

AGP 9.3 지금 올릴까, 더 기다릴까

정리하면 판단은 세 가지 질문으로 갈립니다.

 

1. 릴리스 빌드에서 minify를 실제로 쓰는가 → 쓰면 애널라이저 이득이 큽니다
2. 의존하는 서드파티 플러그인이 9.x, androidComponents에 대응하는가
3. Gradle 9 메이저 업그레이드를 감당할 여력이 있는가

 

이미 9.x에 안착했고 릴리스 R8을 적극적으로 쓰는 팀이라면, 9.3의 애널라이저는 바로 이득을 봅니다. 반대로 아직 8.x(심지어 7.x) 붙잡고 있는 팀이라면, Gradle 메이저 업에 DSL 리팩터링까지 딸려 오니까 조기 도입 리스크가 작지 않아요. 다수 팀이 아직 8.x인 게 현실이라, 9.3이 "남의 집 최신형"으로 들릴 수도 있습니다.

 

결국 9.3 릴리스 노트에서 실무자가 진짜 손대는 건 R8 규칙, 빌드 속도, DSL 에러 이 셋뿐이에요. Wear 임베딩 제거 같은 건 대부분 무관하고요.

 

지금 켜놓은 프로젝트의 shrinking·obfuscation·optimization 점수를 바로 말할 수 있으신가요? 저는 못 했습니다. 그래서 다음 릴리스 빌드 전에 :app:analyzeReleaseR8Config 부터 한 번 돌려볼 생각이에요. 3년 묵은 keep 몇 개는 아마 거기서 걷어내게 되겠네요.