[Java] Gradle 9.0

Spring 7.0, JDK 25 그리고 Gradle 9.0?

2025년 7월 31일 Gradle 9.0이 릴리즈 되었다. 마침 Spring 7.0, JDK 25의 출시가 임박하였을 때 릴리즈되어 JVM 진영이 꽤 많이 바뀌고 있을 때 릴리즈된 메이저 업데이트인 만큼 변경점을 정리하는 글을 적게 되었다.

Gradle

Gradle은 JVM 진영의 대표적인 빌드 도구로 컴파일, 테스트 등의 작업을 자동화해 준다. 기존에는 Maven이 많이 사용되었지만 Maven의 XML을 기반으로 하는 방대한 빌드 설정과 대규모 프로젝트에서 복잡성으로 인해 최근에 사실상 JVM 진영 기본 빌드 도구로 자리를 잡아가고 있다.

Maven?

JVM 진영의 빌드 도구로 자동으로 라이브러리를 관리해 주며 XML 스크립트 기반으로 동작하였다. 라이프사이클 개념이 도입되어 빌드 순서 등을 정의할 수 있었다.

내부사양의 변동

우선 메이저 버전 업데이트인 만큼 Gradle의 내부 사양이 변경되었는데 큰 변경은 다음과 같다.

• JDK 17 - Gradle 데몬의 실행을 위해 이제 JVM 17 이상의 런타임을 요구한다. 물론 빌드 대상은 JDK 8 이상으로 개발되었다면 빌드할 수는 있고 Java 툴체인을 설정하여 JDK 버전을 지정할 수 있다.
• Kotlin 2.2.x - Kotlin 런타임이 2.2.x로 업그레이드되었으며 언어 자체의 버전도 2.2 버전으로 변경되었다. Gradle 8.x 버전에서 런타임 자체는 2.0을 내장하고 언어는 1.8 버전을 사용하였던 것과 비교하면 상당히 급진적이고 최신 기술 변동을 따라갔다고 볼 수 있다.
• Groovy 4.0 - Gradle 7.x 이후로 사용되던 Groovy 3.0을 업그레이드하였다.

Semantic Versioning

이젠 버저닝 방식이 변경되어 'MAJOR.MINOR.PATCH' 형식을 따른다. 이전에는 마이너 버전에서 패치 세그먼트를 무시하였는데 이젠 9.0.1과 같은 방식으로 버저닝 된다.

Configuration Cache 개선

Configuration Cache가 이제 선호되는 실행 모드로 지정되었다. 이제 Configuration Cache 호환성이 있는 빌드에서 아직 활성화하지 않은 경우에는 활성화를 권장하는 코멘트가 로그에 출력되고 만약 Configuration Cache를 지원하지 않는 의존성이 있다면 빌드를 실패 처리하는 것이 아닌 자동으로 일반 모드로 전환되도록 하여 공식 문서의 표현을 빌리자면 '우아한 폴백'을 지원한다. 그리고 Configuration Cache 리포트가 강화되어 직렬화 문제, 안전하지 않은 동시 접근, Groovy DSL 클로저 캡처 등에 관한 더 자세한 로깅을 지원한다.

Configuration Cache가 뭐야

Gradle의 설정 단계(Configuration Phase) 결과를 캐싱하는 기능으로 Configuration Phase는 매 빌드마다 실행되는데, 큰 프로젝트에서는 이 단계만 수십 초가 걸릴 수 있다. 해당 페이즈에선

• 플러그인 적용
• 의존성 해석
• Task 그래프 구성

다음과 같은 과정을 수행하는데 해당 결과를 캐싱해 두는 것이다.

 

Kotlin DSL 스크립트 컴파일 회피

Kotlin의 내장 ABI 핑거프린팅을 사용하여 불필요한 재컴파일을 대폭 줄이는 데 성공하였다. 덕분에 인라인 함수 처리가 개선되어, Gradle 빌드 자체에서 최대 60%의 설정 시간 단축이 가능해졌다. 기존에는 non-ABI 변경사항에 대해서도 불필요한 재컴파일이 있었는데 이젠 non-ABI 변경사항은 재컴파일을 수행하지 않는다.

ABI?

ABI(Application Binary Interface)는 컴파일된 바이너리 수준에서의 인터페이스를 의미하며 ABI가 변경되었다는 것은 쉽게 이야기하면 메서드의 시그니쳐가 변경되었음을 의미한다.

// Non-ABI 변경 - 재컴파일 불필요
fun calculateVersion(): String {
    // 이전: return "1.0.0"
    return "1.0.1"  // 내부 구현만 변경
}

// ABI 변경 - 재컴파일 필요
fun calculateVersion(prefix: String): String {  // 파라미터 추가
    return "$prefix-1.0.0"
}

JSpecify Nullability 어노테이션

기존 JSR-305 어노테이션 대신 JSpecify를 사용한다. Kotlin 2.1과 결합하여 더 엄격한 null 처리가 적용되어 타입 안정성이 개선되었다.

JSR-305? JSpecify?

JSR-305는 소프트웨어 결함 탐지를 위한 표준 어노테이션을 만들기 위해 제안된 Java Specification Request이며 @NonNull, @Nullable 같은 어노테이션을 표준화하여 정적 분석 도구가 더 쉽게 사용하도록 하는 것을 목표로 했지만, 2012년부터 공식적으로 중단(dormant) 상태가 되었다.

 

JSpecify는 JSR-305와 동일한 목적으로 진행되고 있는 오픈소스로 Spring 7.0에 포함되면서 JVM 진영의 표준 규약으로 떠오르고 있다.

JAVA_HOME 환경변수 자동 감지

툴체인 자동 감지 시 JAVA_HOME 환경변수를 소스로 사용하며 덕분에 IDE에선 JDK 버전을 25로 설정하였지만 CLI 환경에선 JDK 17로 되어있어 Gradle 빌드가 실패하는 등의 편의성 관련 문제가 해결되었다.

결론

개인적으로 기대하였던 성능개선과 같은 부분은 없었지만 변화하는 JVM 생태계를 따라가는 버전업이라고 생각한다. 특히 JAVA_HOME 환경변수와 관련된 변경사항은 혁신이라고 생각이 들었던 것이 여러 프로젝트를 하다 보면 JDK 버전이 계속 달라졌는데 그럴 때마다 CLI에서 이런 명령어를 입력하여

export JAVA_HOME=$(/usr/libexec/java_home -v [JDK 버전])

 

JAVA_HOME을 바꿔가면서 작업했던 나에게는 정말 편한 업데이트였다. 또 이번 변경점을 보다 보면 느낄 수 있는 건데 JVM 진영에서 날이 갈수록 Kotlin의 영향력이 커지는 것이다. JVM 진영의 변동사항들이 Kotlin만을 위한 것들도 많아지고 있고 여러므로 최근 JVM 진영에 지각변동이 일어나고 있다는 것을 알 수 있었다.

참고문서

• https://docs.gradle.org/9.0.0/release-notes.html - Gradle 9.0 릴리즈 노트