don

AGP(Android Gradle Plugin) 버전 숫자가 10.0으로 넘어가는 메이저(Major) 업데이트가 이루어지면 빌드 시스템 구조가 대폭 현대화되고 strict(엄격)해집니다.
구글과 Gradle 팀이 AGP 10.0을 통해 달성하고자 하는 핵심 목표와 변화 방향은 다음과 같습니다.
1. 레거시 APIs의 완전한 제거 (Breaking Changes)
* 내부 클래스(Private Internal) 접근 완전 차단: 이전 버전까지는 커스텀 플러그인이나 빌드 스크립트에서 AGP의 내부 internal 클래스에 직접 접근해 꼼수를 쓸 수 있었으나, 10.0부터는 완전히 캡슐화되어 차단됩니다.
* 구형 Variant API 및 옵트아웃(Opt-out) 제거: AGP 7~8 시절부터 경고해 온 구형 Variant API와 기존 DSL 복구 옵션(newDsl = false 등)이 완전히 삭제되어, 신규 New Variant API와 Kotlin-friendly DSL 사용이 강제됩니다.
2. Configuration Cache (격리된 빌드 환경)의 정식 의무화
* Isolated Projects (프로젝트 격리): 멀티모듈 프로젝트에서 각 모듈의 빌드 컨텍스트를 완전히 분리하여 evaluation 속도를 극대화합니다.
* afterEvaluate 및 암시적 참조 엄격 제한: 모듈 간 결합도를 낮추고 완벽한 병렬 빌드 및 캐싱을 위해 타 모듈을 직접 참조하는 스크립트 작성 방식이 완전히 제한됩니다.
3. K2 컴파일러 & Kotlin Multiplatform (KMP) 완벽 밀착
* Kotlin 2.x 기반 K2 컴파일러와 린트(Lint) 검사가 빌드パイプライン에 더욱 깊게 통합되어 증분 빌드(Incremental Build) 속도가 혁신적으로 빨라집니다.
* Android에 국한되지 않고 KMP(Kotlin Multiplatform) 빌드 프로세스와의 경계가 희미해질 만큼 빌드 타깃 유연성이 넓어집니다.
💡 구글의 궁극적인 목표
구글의 목표는 단순히 버전을 올리는 것이 아니라, "개발자는 코드 작성에만 집중하고, 빌드 시스템은 백그라운드에서 완전히 신뢰할 수 있는 속도로 동작하게 만드는 것"입니다.
이를 위해 구형 API나 구조적 허점을 10.0에서 깔끔하게 청소(Deprecation Cleanup)하여 극단적인 빌드 속도 향상과 안정성을 확보하는 것이 핵심 전략입니다.

AGP 10.0을 향해 갈 때 개발자들이 현장에서 가장 크게 체감하고 우려하는 부분들은 정확히 짚어주신 포인트들과 일맥상통합니다.
구글이 빌드 시스템을 현대화하고 성능을 극대화하려는 의도와는 별개로, 실제 개발 현장에서는 다음과 같은 현실적인 마이그레이션 고통이 발생할 수 있습니다.
1. 오래된 라이브러리 및 커스텀 플러그인과의 '충돌' (레거시 지옥)
* 관리되지 않는 외부 라이브러리: 이미 업데이트가 중단된 서드파티 SDK나 오픈소스 라이브러리 중에는 내부적으로 구형 AGP API(afterEvaluate나 내부 클래스 호출 등)를 사용하고 있는 경우가 많습니다.
* 빌드 마비 현상: 프로젝트 코드 자체는 문제가 없는데, 특정 광고 SDK, 결제 SDK, 혹은 분석 툴 하나가 AGP 10의 엄격해진 규격을 지원하지 않아 빌드 자체가 아예 안 되는 상황이 발생할 수 있습니다. 이 경우 해당 라이브러리가 업데이트될 때까지 프로젝트 업그레이드를 강제로 멈춰야 합니다.
2. 개발자들의 따라가지 못하는 점 (학습 곡선과 마이그레이션 비용)
* 작성 방식의 전면 수정: build.gradle에서 관습적으로 쓰던 편법적인 코드들(afterEvaluate로 타이밍 맞추기, 다른 모듈의 프로퍼티를 마구 끌어다 쓰기 등)이 일제히 에러를 뿜어냅니다.
* 인력과 시간의 한계: 혼자서 앱을 개발하거나 소규모 팀으로 운영하는 경우, 비즈니스 로직(기능 개발)을 구현하기도 바쁜데 빌드 에러를 잡고 새로운 Variant API나 격리된 프로젝트 구조에 맞춰 스크립트를 싹 갈아엎는 작업은 엄청난 시간적·정신적 부담이 됩니다.
3. 빌드 최적화 규칙 위반으로 인한 디버깅 난이도 상승
* AGP 10부터는 Configuration Cache와 Isolated Projects가 매우 엄격하게 적용됩니다.
* 만약 빌드 스크립트나 플러그인에 미세한 실수(예: 캐시할 수 없는 동적 변수 사용 등)가 있으면, 빌드가 그냥 실패하거나 캐시가 계속 무효화되어 오히려 빌드가 더 느려지거나 원인을 알 수 없는 에러 메시지(스택 트레이스)와 씨름해야 하는 상황이 늘어날 수 있습니다.
💡 요약하자면
구글의 청사진은 "빠르고 안전한 빌드"이지만, 개발자 입장에서는 "잘 돌던 프로젝트를 굳이 왜 이렇게까지 다 뜯어고치게 만드냐"는 피로감이 가장 큰 걱정거리입니다.
결국 메이저 버전(10.0) 전환 시기에는 바로 뛰어들기보다, 서드파티 라이브러리 생태계가 10.0 호환 버전을 충분히 제공할 때까지 여유를 두고 마이그레이션 기간을 잡는 것이 현업의 일반적인 대처법이 됩니다. 동우님처럼 개인 개발로 여러 앱을 빌드하고 관리하시는 환경에서도 라이브러리 의존성 정리가 가장 큰 관건이 되겠네요!