Gradle 알아보기

Gradle에 대해서 알아봅니다.

GOAL

• Gradle의 구조와 하는 일을 이해한다.
• Gradle의 작동 방식을 이해한다.

 

 

Gradle이란?

Spring Boot를 이용하여 개발하다보면 꼭 함께 보이는 것들이 있다. 바로 Gradle인데, build.gradle 파일로 프로젝트의 의존성을 관리하거나 ./gradlew 명령어로 build, compile, bootRun 등 프로젝트를 실행, 빌드하곤 했을 것이다. 이런 Gradle은 무엇일까?

 

Gradle은 간단하게 말하자면 빌드 자동화 도구이다. DSL(Groovy / Kotlin)로 빌드 과정을 스크립트처럼 작성하고 Task 단위로 실행하는 것이다. build.gradle와 settings.gradle에 의존성, 플러그인, 작업 순서 등을 코드처럼 작성하고 실행할 수 있다.

• settings.gradle: 프로젝트의 구조(어떤 모듈이 있는지)를 정의
• build.gradle: 각 프로젝트(모듈)의 설정(플러그인, 의존성 등)을 정의

 

Gradle이 하는 일

위에서 말했듯이 "빌드 자동화 도구"인 Gradle은 우리가 애플리케이션을 만들 때 반복적으로 하는 일들을 자동화해준다.

• 소스 코드 컴파일 (.java > .class)
• 테스트 실행
• JAR / WAR / bootJar 만들기
• 라이브러리 의존성 관리 (Spring Boot, Lombok, JPA 등)
• 코드 스타일 체크, 코드 생성, 문서 생성 등

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.5.8'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

프로젝트를 진행하면 흔히 볼 수 있는 일반적인 Spring Boot의 build.gradle구조이다.

 

Gradle의 핵심 개념은 다음 세가지로 나눌 수 있다.

1. 플러그인

• 빌드에 기능을 넣어주는 모듈로 위 예시에서는 java, springboot, spring.dependency-management 세 개가 들어가 있다.
• 기본적인 Task를 제공해주거나 의존성 버전 관리해주는 모듈을 불러온다.

2. 의존성, Configuration

• 프로젝트를 진행하면서 가장 많이 수정하게 될 부분인데, 프로젝트에서 사용될 라이브러리들을 선언한다.
• implementation, testImplementation 같은 것들을 Configuration이라고 하며 다음과 같이 적용된다.
  • implementation
    • main 코드에서 사용하는 라이브러리
    • 컴파일 + 런타임에 모두 필요
  • testImplementation
    • 테스트 코드에서만 사용하는 라이브러리
  • compileOnly, runtimeOnly
    • 컴파일 시에만 / 런타임 시에만 필요한 것

3. Task

• 가장 핵심적인 부분으로, gradle은 모든 작업을 Task로 본다.
• Task간의 의존 관계를 만들고 build를 실행하면 build가 필요한 Task들을 순서대로 실행한다.

./gradlew build 하면 내부적으로

1. compileJava
2. processResources
3. test
4. bootJar (또는 jar)
5. 필요하면 check, assemble …

이런 Task들을 순서대로 실행한다.

 

또한 직접 Task를 만들 수도 있다.

tasks.register('hello') {
    doLast {
        println "Hello, Gradle!"
    }
}

gradlew란?
Gradle Wrapper의 약자로, 프로젝트마다 “어떤 버전의 Gradle을 써야 하는지”를 고정한다.

wrapper가 없다면 개발자마다 다른 gradle 버전을 설치하고 환경마다 실행이 되지 않는 문제가 발생할 수 있다. 따라서 wrapper는 프로젝트 안에 “Gradle 버전 정보 + 부트스트랩”을 포함하여 gradle이 없어도 지정된 Gradle 버전을 자동으로 다운로드하고 그 버전으로 빌드 실행할 수 있게 된다.

“Gradle 설치를 개발자/서버에 의존하지 않고, 프로젝트 안에 버전 정의를 포함시키는 것”이 핵심이다.

 

 

settings.gradle의 역할

위에서 간단하게 gradle의 구조에 대해서 살펴보았는데, 그 중 프로젝트 구조를 명시하는 settings.gradle을 알아보자.

 

Gradle이 실행되면 다음과 같은 작업을 거치게 된다.

1. 현재 디렉토리에서 settings.gradle 또는 settings.gradle.kts 찾기
2. 이 파일을 읽어서 “어떤 프로젝트들이 있는지” 파악
3. 루트 프로젝트 / 서브 프로젝트 목록 만들기

 

// settings.gradle
rootProject.name = "my-app"

include("app", "common", "user", "order")

 

이런 settings.gradle이 있다고 한다면 Gradle은 다음과 같이 해석하게 된다.

 

:          (root project, 디렉토리 = .)
:app       (디렉토리 = ./app)
:common    (디렉토리 = ./common)
:user      (디렉토리 = ./user)
:order     (디렉토리 = ./order)

즉, settings.gradle은 "폴더 구조를 Gradle 프로젝트/모듈로 인식시키는 파일" 이라고 생각할 수 있다.

 

단일 모듈 프로젝트일 때는 보통 include 블록이 생략되고 rootProject.name만 명시되어있거나, 아예 settings.gradle을 없이 진행하는 경우가 많다.

 

그래서 단일 모듈로 프로젝트를 진행한다면 신경 쓰지 않아도 되고, 멀티모듈 할 때부터 settings.gradle이 중요해진다.

 

 

build.gradle의 역할

위에서도 간단하게 설명했듯이 build.gradle은 각 프로젝트의 설정과 빌드 방법을 명시한 파일이다.

 

settings.gradle에서 “어떤 프로젝트(모듈)가 있는지”를 정했다면, 각 프로젝트(모듈)가 “어떻게 빌드될지”는 build.gradle에서 정하게 된다.

 

멀티모듈일 때는 루트 build.gradle에 공통 설정을 명시하고 각 모듈의 build.gradle에서 모듈별 설정을 해주게 된다.

 

root
 ├─ settings.gradle
 ├─ build.gradle        # 공통 설정
 ├─ app
 │   └─ build.gradle    # app 모듈 설정 (Boot 플러그인 등)
 ├─ common
 │   └─ build.gradle    # common 모듈 설정
 └─ user
     └─ build.gradle    # user 모듈 설정

 

정리해보자면 Gradle은 다음과 같은 순서로 동작하게 된다.

1. Init 단계
   • settings.gradle 읽어서 프로젝트 트리 구성
2. Configuration 단계
   • 각 프로젝트의 build.gradle 읽어서 플러그인, 의존성, Task 그래프 구성
3. Execution 단계
   • ./gradlew build 같은 명령에서 지정한 Task들 실제 실행