build-logic 모듈 buildSrc 모듈로 마이그래이션

[kangeunchan]

현재 프로젝트 설계에서는 공통의존성과 빌드 스크립트를 목적으로 build-logic 이라는 composite build 모듈로 관리하려고 하였으나,
build-logic 은 Gradle의 독립 composite build 특성상 다음과 같은 한계점이 존재하여, 기존 계획 및, 개발 중인 build-logic 모듈을 buildSrc 모듈로 재설계 및, 마이그래이션 하려고 합니다.

1. 직접 import 불가능

build-logic 내 객체나 상수를 루트 및 하위 모듈의 build.gradle.kts에서 직접 import할 수 없다.
반면 buildSrc는 자동 컴파일 후 모든 빌드 스크립트 classpath에 포함되어 import가 가능하다.
따라서, 공통 상수(Dependencies)를 모듈별 빌드스크립트에서 쉽게 재사용하기 어렵다.

2. 빌드 스크립트 코드 가독성 및 유지보수 저해

플러그인 형태로 build-logic을 적용하는 경우, 공통 의존성 관리가 복잡해지고 유지보수가 어려워진다.
빌드 스크립트마다 의존성을 재정의하거나 별도 wrapper plugin이 필요한 상황 발생.

3. Gradle 표준 및 생태계와의 정합성 문제

Gradle 공식 문서와 권장사항은 buildSrc를 통해 공통 빌드 로직과 상수를 공유하는 방식을 우선 권장한다.
composite build는 주로 독립 빌드 및 복잡한 멀티 프로젝트 설정에 적합하며, 공통 의존성 단순 공유에는 부적합하다.

참고 자료

Gradle 공식 문서에서는 buildSrc가 자동으로 컴파일되고 모든 build script의 classpath에 포함된다고 명시되어 있다.
“Gradle automatically compiles the code in buildSrc and includes it in the classpath of all build scripts.”

build-logic은 includeBuild("build-logic")로 설정되는 composite build 이기에 Composite build는 다음과 같은 특성을 가진다.
“Included builds do not share any configuration with the composite build or the other included builds. Each included build is configured and executed in isolation.”

Gradle 사용자 문서의 “Using Plugins” 섹션에는 다음과 같은 설명이 있다.
“To use the build logic encapsulated in a plugin, Gradle needs to perform two steps. First, it needs to resolve the plugin, and then it needs to apply the plugin… “