[Server] gradle에 대해서 알아보자

gradle이 무엇일까?

빌드 도구에는 gradle이나 maven 방식이 있다는 건 어렴풋이 알았지만, 오래동안 gradle을 사용했음에도 새로운 프로젝트를 만들 때면 습관적으로 build.gradle 파일을 복사해서 사용해왔다. 하지만 gradle에 대해 너무 이해없이 사용하는 것 같아서 gradle의 핵심 개념을 공식 문서를 통해 알아보고자 한다.

참고 자료 : https://docs.gradle.org/current/userguide/gradle_basics.html#gradle

Core Concepts

 

---

 

핵심 개념

Gradle은 빌드 스크립트의 정보를 기반으로 소프트웨어의 빌드, 테스트, 배포를 자동화한다.

Gradle 빌드는 프로젝트와 작업(Task)의 관점에서 정의되며, Groovy 또는 Kotiln으로 작성된 빌드 스크립트를 사용하여 구성된다.

 

앞으로 나오게 될 개념을 정리하면 아래와 같다.

개념	설명
빌드, Build	결과물을 생성하는 프로세스와 환경이다. 빌드는 하나 이상의 프로젝트와 빌드 스크립트를 포함한다.
프로젝트, Project	애플리케이션이나 라이브러리처럼 빌드 가능한 소프트웨어이다. 빌드에는 루트 프로젝트 혹은 여러 개의 하위 프로젝트가 포함될 수 있다.
작업, Task	코드 컴파일이나 테스트 실행과 같은 기본 작업 단위이다. 작업은 빌드 스크립트에서 선언되거나 플러그인을 통해 추가된다.
빌드 스크립트, Build Script	Configuration 파일로써 작업, 의존성 및 기타 지침을 정의하여 Gradle이 프로젝트를 빌드하는 방법을 알려준다. build.gradle 파일이다.
플러그인, Plugin	기능을 확장하는 데 사용된다. 플러그인은 종종 프로젝트에 작업과 규칙을 추가한다.
의존성(종속성), Dependency	프로젝트에 필요한 외부 또는 내부 리소스이다. Gradle은 빌드 과정에서 이러한 리소스를 자동으로 해결한다.

 

이 표만 봐서는 이해하기가 쉽지 않으니 조금 더 알아보자

 

 

프로젝트 구조

우리는 보통 아래와 같은 프로젝트 구조를 지니고 있다.

하위 프로젝트가 여러개 있는 구조가 헷갈린다면 오른쪽의 구조랑 같다고 생각하면 된다.

 

1. Gradle 폴더 - wrapper 파일 등을 저장한다.
2. Gradle wrapper 스크립트 - Gradle 프로젝트이다.
3. Gradle setting file - 루트 프로젝트 이름과 하위 프로젝트를 정의하는 설정 파일이다.
4. Gradle build script - 프로젝트의 Gradle 빌드 스크립트이다. 하위 프로젝트 별로 존재한다.
5. source code - 프로젝트의 소스코드

 

 

Gradle 호출

[ IDE에서 호출 ]

많은 IDE에 이미 Gradle이 내장되어 있다. 이를 클릭하여 호출할 수 있다.

 

[ Command Line에서 호출 ]

Gradle을 설치한 후 Command Line에서 호출할 수 있다.

gradle build
gradle test
gradle clean build

 

하지만 대부분은 Gradle을 설치하여 사용하는 것이 아닌 Gradle Wrapper를 사용한다.

 

[ Gradle Wrapper로 호출 ]

Wrapper는 선언된 Gradle 버전을 호출하는 스크립트이며 Gradle 빌드를 실행하는 데 권장되는 방법이다.

./gradlew build

 

 

 

Wrapper 기본 사항

래퍼는 다음과 같은 이점을 제공한다.

1. 특정 Gradle 버전을 자동으로 다운로드하여 사용한다.
2. 주어진 Gradle 버전에 따라 프로젝트를 표준화한다.
3. 다양한 사용자와 환경에 동일한 Gradle 버전을 제공한다.
4. Gradle을 수동으로 설치하지 않고도 Gradle 빌드를 쉽게 실행할 수 있다.

즉, 시스템에 직접 Gradle을 설치하여 사용하는 경우에는 아래와 같은 명령어를 사용하고

gradle build

 

Gradle Wrapper를 사용한다면 아래와 같은 명령어를 사용한다.

./gradlew build (Linux)
gradlew.bat build (Windows)

 

특별한 경우가 아니라면 gradlew를 권장하니 이를 사용하도록 하자

 

Wrapper 구성요소

아래는 Gradle Wrapper의 일부이다.

1. gradle-wrapper.jar - 프로젝트에 맞는 Gradle 버전이 설치되지 않은 경우 해당 버전을 다운로드하고 설치하는 역할을 한다.
2. gradle-wrapper.properties - Gradle Wrapper의 구성 속성이 포함되어 있다. 배포 URL(Gradle을 다운로드할 위치) 및 배포 유형이 포함된다.
3. gradlew - wrapper 역할을 하는 셸 스크립트이다. gradle-wrapper.jar의 wrapper 역할을 하는 셸 스크립트(Unix 기반 시스템)이다.
4. gradlew.bat - gradlew와 동일한 역할을 하며 windows 시스템에서 사용한다.

gradlew-wrapper.properties 

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.14.3-bin.zip
networkTimeout=10000
validateDistributionUrl=true
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

 

주의 

gradle-wrapper.jar, gradlew, gradlew.bat 를 변경해서는 안된다.

 

또한 Gradle의 버전을 수정하기 위해 임의로 gradle-wrapper.properties를 열어서 직접 수정하면 안된다.

( 업데이트 명령어를 사용해야 Url도 올바른 주소로 수정해줄 뿐 아니라, 파일의 무결성을 검증하기 위한 체크섬 값도 함께 업데이트 되기 때문이다.)

 

버전 확인 명령어 및 버전을 업데이트하는 명령어를 이용하자

$ ./gradlew --version
$ ./gradlew wrapper --gradle-version 7.2

---

$ gradlew.bat --version
$ gradlew.bat wrapper --gradle-version 7.2

 

 

명령 기본 사항

아래와 같은 구조로 Task를 지정할 수 있다.

gradle [taskName1 taskName2...] [--option-name...]

 

예를 들어 clean을 하고 build를 하고 싶다면 다음과 같다.

gradle clean build

 

옵션에 값을 허용하는 경우는 = 를 사용하고 토글 옵션은 아래와 같이 사용하면 된다.

gradle build --console=plain
gradle build --build-cache
gradle build --no-build-cache

 

 

설정 파일 기본 사항

설정 파일(setting.gradle)은 모든 Gradle 프로젝트의 진입점이다.

 

설정 파일의 목적은 프로젝트 구조를 정의하고, 일반적으로 빌드에 하위 프로젝트를 추가하는 것이다.

 

따라서 단일 프로젝트 빌드의 경우에는 선택이지만 다중 프로젝트 빌드의 경우 설정 파일은 필수이며 모든 하위 프로젝트를 선언해야 한다.

 

setting.gradle

rootProject.name = 'root-project' // 1

include('sub-project-a') // 2
include('sub-project-b') 
include('sub-project-c')

1. 프로젝트 이름을 정의 - 빌드 당 루트 프로젝트는 하나만 있다.
2. 하위 프로젝트를 추가한다.

 

빌드 파일 기본 사항

빌드 스크립트(build.gradle)에는 빌드 구성, 작업 및 플러그인에 대한 세부 정보가 포함된다.

모든 Gradle 빌드는 최소한 하나의 빌드 스크립트로 구성된다.

 

 

Build Script

다중 프로젝트 빌드에서는 일반적으로 각 하위 프로젝트가 자체 빌드 파일(build.gradle)을 갖는다.

빌드 스크립트 내부에서는 일반적으로 다음을 지정한다.

 

플러그인 : 코드 컴파일, 테스트 실행, 아티팩트 패키징과 같은 작업을 위해 Gradle의 기능을 확장하는 도구
종속성 : 프로젝트에서 사용하는 외부 라이브러리 및 도구

plugins {  // 1
    id 'application'
}
dependencies {  // 2
    testImplementation libs.junit.jupiter

    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

    implementation libs.guava
}
application {  // 3
    mainClass = 'org.example.App'
}

1. 플러그인을 추가한다.
2. 종속성을 추가한다.
3. 규칙 속성을 사용한다.

1. 플러그인 추가

plugins {  // 1
    id 'application'
}

 

위 예제에서 사용한 application 플러그인은 실행 가능한 JVM 애플리케이션을 만드는 데 사용된다. 

 

 

2. 종속성 추가

dependencies {  
    testImplementation libs.junit.jupiter

    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

    implementation libs.guava
}

 

프로젝트에는 compile, run, test를 위한 외부 라이브러리가 필요하다. 이 예제에서는 junit.jupiter 테스트를 위해 guava 라이브러리를 메인 애플리케이션 코드(implementation)에 사용한다.

 

Gradle 의존성 정리

 

 

3. 컨벤션 속성 사용

application {   
    mainClass = 'org.example.App'
}

 

플러그인은 프로젝트에 task을 추가하며 속성과 메서드도 추가한다. application 플러그인은 애플리케이션을 패키징하고 배포하는 작업을 정의한다. application 플러그인은 코드를 실행하는 데 필요한 Java 애플리케이션의 메인 클래스를 선언하는 방법을 제공한다.

원래 Gradle에는 application 블럭이 없는데 application 플러그인을 사용해서 추가된 것이다.

 

 

 

종속성 및 종속성 관리 기본 사항

Gradle에는 종속성 관리에 대한 지원이 내장되어 있다.

종속성 관리란 프로젝트에 필요한 외부 리소스를 선언하고 해결하기 위한 자동화 기술이다. 종속성에는 프로젝트 빌드를 지원하는 JAR, 플러그인, 라이브러리 또는 소스 코드가 포함된다. Gradle은 종속성을 다운로드, 캐싱 및 해결하는 작업을 자동으로 처리하여 수동으로 관리할 필요가 없다. 또한 버전 충돌을 처리하고 유연한 버전 선언을 지원한다.

 

 

종속성 선언

 

종속성을 추가하려면 build.gradle의 dependencies 블록에 종속성을 지정한다.

dependencies {
    implementation "com.google.guava:guava:33.0.0-jre"
    testImplementation "org.junit.jupiter:junit-jupiter:5.10.0"
}

 

 

 

 

버전 카탈로그 사용

전체 빌드에서 종속성을 중앙에서 일관되게 관리할 수 있는 방법을 제공한다. 

각 build.gradle에 버전을 직접 선언하는 대신, libs.version.toml 파일에 한 번만 정의하면 된다.

 

버전 카탈로그는 4개의 섹션으로 구성된다.

1. [versions] 플러그인과 라이브러리가 참조할 버전 번호를 선언한다.
2. [libraries] 빌드 파일에서 사용되는 라이브러리를 정의한다.
3. [bundles] 종속성 집합을 정의한다.
4. [plugins] 플러그인을 정의한다.

 

 

버전 카탈로그가 효과적인 상황

프로젝트가 멀티 모듈로 커지면 각 모듈마다 같은 버전의 라이브러리를 여러번 적게된다. 이때 각 모듈이 직접 입력하는 방식은 버전 관리가 어려워진다.

dependencies {
    implementation "com.google.guava:guava:33.0.0-jre"
    testImplementation "org.junit.jupiter:junit-jupiter:5.10.0"
}

 

 

gradle/libs.version.toml 파일을 추가하여 버전 카탈로그를 사용할 수 있다.

 

gradle/libs.version.toml 

[versions]
guava = "33.0.0-jre"
junit = "5.10.0"

[libraries]
guava = { group = "com.google.guava", name = "guava", version.ref = "guava" }
junit.jupiter = { group = "org.junit.jupiter", name = "junit-jupiter", version.ref = "junit" }

 

 

build.gradle

dependencies {
    implementation libs.guava
    testImplementation libs.junit.jupiter
}

 

모듈 별로 일관된 버전을 사용할 수 있게 된다.

 

 

 

 

Task(작업) 기본 사항

Task는 빌드가 수행하는 독립적인 작업 단위를 나타낸다. 

 

일반적인 Task 유형은 다음과 같다.

• 소스 코드 컴파일
• 테스트 실행
• 패키징 출력(JAR 생성)
• 문서 생성(javadoc)
• 빌드 아티팩트를 저장소에 게시

각 Task는 독립적이지만 다른 Task가 먼저 실행될 수 있다. Gradle은 이 정보를 사용하여 Task를 실행하는 효율적인 순서를 파악하고, 이미 최신 상태인 Task는 건너뛴다.

 

Task 실행

 

작업을 실행하려면 다음과 같이 입력한다.

./gradlew build

 

빌드 파일에 application 플러그인을 적용했다면 run 작업을 사용할 수 있다.

./gradlew run

 

run에 필요한 모든 작업을 실행한다.

 

 

사용 가능한 작업 나열

Gradle 플러그인과 빌드 스크립트는 프로젝트에서 사용 가능한 작업을 정의한다. 이를 확인하는 명령어는 아래와 같다.

./gradlew tasks

 

증분 빌드 및 빌드 캐싱 기본

Gradle은 빌드 시간을 줄이기 위해 증분 빌드와 빌드 캐싱이라는 두 가지 주요 기능을 사용한다.

 

작업 결과 레이블

verbose 모드를 켜고 Gradle build를 하면 실행 중 발생한 상황을 설명하는 짧은 결과 라벨을 확인할 수 있다.

> Task :compileJava UP-TO-DATE
> Task :processResources NO-SOURCE
> Task :jar FROM-CACHE
> Task :test SKIPPED
> Task :publish

 

작업 라벨의 의미

 

증분 빌드

증분 빌드는 이전 빌전 빌드 이후 입력 내용이 변경되지 않은 작업은 실행하지 않는 빌드이다. 개발자가 단일 파일을 지속적으로 변경하는 경우, 프로젝트의 다른 모든 파일을 다시 빌드할 필요는 없기 때문이다. 증분 빌드는 항상 활성화되어 있다.

 

빌드 캐싱

하지만 브랜치를 바꾸거나, 새로운 워크스페이스에서 빌드를 하면, 이전에 빌드한 결과가 없어지기 때문에 모든걸 새로 빌드해야 한다. 빌드 캐싱은 이전 빌드 결과물을 저장해두었다가, 동일한 입력이 들어오면 저장된 결과를 재사용한다.

./gradlew compileJava --build-cache

 

플러그인 기본 사항

Gradle은 유연한 플러그인 시스템을 기반으로 구축되었다. Gradle은 기본적으로 종속성 해결, 작업 오케스트레이션, 증분 빌드와 같은 핵심 인프라를 제공한다. Java 컴파일, Android 앱 빌드, 아티팩트 게시와 같은 대부분의 기능은 플러그인을 통해 제공한다.

플러그인은 Gradle 빌드 시스템에 추가 기능을 제공한다.

• 빌드에 새로운 Task 추가(예: compileJava 또는 test)
• 새로운 구성 추가(예: implementation 또는 runtimeOnly)
• DSL 요소(예: application {} 또는 publishing {})

플러그인은 build script의 plugin block에 적용되며, 특정 도메인이나 workflow에 필요한 모든 로직을 가져온다.

 

 

플러그인 배포 및 가용성

Gradle 플러그인은 다양한 소스에서 제공된다.

1. Core Plugins - Gradle 배포판 자체에 포함된 플러그인 세트
2. Community Plugins - Gradle 커뮤니티에서 개발한 플러그인 (https://plugins.gradle.org/)
3. 사용자 정의/로컬 플러그인 - 플러그인을 직접 작성할 수도 있다.

 

빌드 스캔 기본 사항

빌드 스캔은 빌드를 실행할 때 캡처된 메타데이터를 표현한 것이다.

 

빌드 스캔 정보

Gradle은 빌드 메타데이터를 캡처하여 빌드 스캔 서비스로 전송한다. 그러면 빌드 스캔 서비스는 해당 메타데이터를 분석하고 다른 사용자와 공유할 수 있는 정보로 변환한다. 빌드 스캔에서 수집한 정보는 빌드 문제를 해결하거나 성능을 최적화할 때 중요한 리소스가 될 수 있다. 또한 오류 메시지를 복사하여 붙여넣을 필요 없이 대신 최신 빌드 스캔 링크를 복사하면 된다.

 

빌드 스캔 활성화

./gradlew build --scan