Gradle 이란?

Gradle 이란?

자바를 이용해서 코딩을 하다보면 Gradle 을 사용해서 빌드하는 경험을 많이 한다.

근데 이 Gradle 은 정확히 어떤 역할을 할까?

공식문서를 먼저 찾아보면,

Gradle is an open-source build automation tool flexible enough to build almost any type of software.

 

Gradle 은 스스로 빌드 자동화(build automation) 툴이라고 소개하고 있다.

 

🧐 빌드란 무엇일까?

자바코드를 컴파일 과정을 거쳐서 컴퓨터가 실행할 수 있는 파일로 만들어 주는 과정을 말한다.

 

 

그렇다면 일단 Gradle이 이러한 과정을 관리해줌으로써 개발자의 삶을 좀 더 윤택하게 해준다는 것은 알거같다.

구체적으로 Gradle은 다음과 같은 일을 한다. (스프링 기준)

 

Compile

- 자바 파일을 컴퓨터가 읽을 수 있는 바이트 코드로 변환해준다.

 

Test

- 프로그램이 제대로 돌아갈 수 있는 지에 대한 테스트를 지원해준다.

 

Pakaging

- 컴파일 된 코드로 실행 파일을 만든다.

 

Deploy & Run

- 실제로 프로그램을 실행시킨다. 예를 들면 스프링 서버를 돌리는 것과 같다.

 

하지만 Gradle이 다른 툴과 비교했을 때 어떤 장점이 있어서 많은 개발자들이 사용하는 걸까?

 

Gradle, 왜 쓰는 걸까?

 

다른 툴들과 비교해봤을 때 Gradle이 가지는 장점이 몇가지 있다.

그 장점들에 대해서 하나씩 알아보자

 

간결한 스크립트

 

Gradle의 장점은 먼저 스크립트만 봐도 알 수 있다.

먼저 경쟁자인 Maven의 스크립트를 보자 !

 

Maven의 경우에는 XML 형식의 스크립트 구조를 사용하고 있어서 가독성도 떨어지고 작성하기도 어렵다.

하지만 Gradle 같은 경우 설정 주입 방식으로 스크립트를 작성해줌으로써 가독성도 좋아지고 프로젝트 구조를 보다 쉽게 파악할 수 있다.

 

 

멀티 프로젝트 빌드

프로젝트를 진행하다 보면 여러 개의 모듈로 구성되는 경우가 많다.

하지만 이 때 여러 개의 모듈을 따로 빌드하게 되면 번거롭기도 하고 실수할 가능성도 생긴다.

 

Gradle은 이런 문제를 해결하기 위해 여러 개의 모듈들을 동시에 빌드할 수 있다.

또한 모듈마다 공통된 코드 , 별도의 코드를 분리해 줌으로써 코드의 중복을 줄일 수 있다.

 

빠른 빌드 속도

위에서 말한 것들만 모두 해준다고 해도 충분히 쓸만한 툴이다.

근데 여기에 속도까지 빠르다면 ? 그 어려운 걸 Gradle 이 다시 해내버렸다.

 

표를 보면 Gradle 은 경쟁사 대비 월등히 빠른 속도를 보여주고 있다.

편리하고 빠른 Gradle .. 안 쓸 이유가 없지 않을까?

잠깐 Gradle 은 대체 어떻게 만들었길래 빠른걸까?

 

Gradle, 왜 빠른 걸까?

다시 Gradle의 공식 문서를 보자

Gradle avoids unnecessary work by only running tasks that need to do work because inputs or outputs have changed. Gradle uses various caches to reuse outputs from previous builds. With a shared build cache, you can even reuse outputs from other machines.

 

 

이 문장을 요약하면 Gradle은 기본적으로 불필요한 작업을 방지하고 캐시를 통해 재사용한다는 것을 알 수 있다.

 

이것을 구현하는 방법은 대표적으로 3가지가 있다.

 

점진적 빌드

빌드를 할 때 모든 파일들을 다시 빌드하는 게 아닌 , 바뀐 파일들만 추적해서 해당 파일만 빌드하는 것을 말한다.

 

예를 들어 20개의 파일을 빌드할 때 15개의 파일이 그대로면 나머지 5개의 파일만 빌드하는 형식이다.

 

빌드 캐시

여러 번의 빌드를 실행할 때 Gradle은 이미 빌드가 된 결과물들을 빌드 캐시에 담아놓는다.

추후에 해당 파일에 대해 다시 빌드를 하게 되면, 다시 빌드할 필요성을 줄여줌으로써 빌드를 더욱 빨리할 수 있다.

 

혹은 빌드 캐시를 로컬에서만 사용하는 것이 아닌 , 팀원들끼리 빌드 캐시를 공유해서 빌드 결과들을 캐시에 담아 재사용할 수 있다.

 

 

데몬 프로세스

 

데몬 프로세스를 알아보기 전에 데몬은 무엇일까?

Gradle에서 또 친절하게 데몬의 정의를 말해주고 있다.

A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

 

 

해석하자면 , 데몬은 사용자가 직접 제어하지 않고 백그라운드 프로세스로 돌아가는 프로그램이다.

 

이것을 빌드에 어떻게 도입했을까?

Gradle은 JVM이라는 가상 장치 위에서 실행되며 이 JVM은 여러 초기화 라이브러리들을 사용하며, 이 과정은 꽤 시간이 걸릴 수 있다.

때문에 매번 새로 빌드하는 것이 아닌 동일한 빌드는 이미 실행중인 데몬을 이용하여서 빌드 시간을 줄여준다.

 

 

 

예를 들어서 노트북을 사용하지 않을 때 아예 끄는 것이 아니라 다음 사용을 위해 슬립 모드로 두는 것과 같다.

 

Gradle, 어떻게 쓰는 걸까?

이렇게 좋은 Gradle , 어떻게 쓰는 지 정도는 알아보자 !

오늘은 빌드 스크립트에서 의존성을 설정하는 부분을 알아볼 것이다.

의존성 설정을 위해선 build.gradle의 dependencies 부분을 봐야한다.

 

 

Gradle에선 예시 코드처럼 간편하게 의존성을 설정할 수 있다.

근데 앞에 있는 코드를 보면 모두 다른 코드를 사용하고 있다.

이 코드들은 왜 있고 어떤 기능들을 수행하는 지 알아보자!

 

compileOnly

컴파일 시에만 의존성을 정의한다.

예를 들어 롬복같은 경우 , 어노테이션을 보고 getter , setter를 컴파일 해주고 런타임에는 넣지 않는다.

runtimeOnly

런타임 시에만 의존성을 정의한다.

예를 들어 DB관련 혹은 로그 의존성 주입 시에 사용한다.

test

앞에 test가 붙어있으면 해당 의존성을 테스트 시에만 사용한다는 의미이다.

 

의존성이란?

모듈 간의 관계를 예로 들면, A 모듈이 B 모듈을 사용하고 있다.

이것을 A 모듈이 B 모듈에 의존하고 있다고 말한다.

즉 의존성이란 모듈 간 서로 사용하는 관계이다.

 

 

Api vs Implementation

dependencies를 보면 api 도 있고 implementation도 있다.

둘은 어떤 차이가 있을까?

먼저 전이 의존성이란 개념을 짚고 넘어갈 필요가 있다.

 

 

만약 서로 의존하고 있는 모듈 3개가 있다고 가정하자

여기서 A 모듈이 변경된다면 나머지 모듈들은 어떻게 될까?

 

만약 여기서 의존하고 있는 모듈들이 모두 영향을 받는다면 전이 의존성이 허용된 경우이다.

여기서 말한 전이 의존성의 특성을 가지고 있는 지가 차이를 결정한다.

 

공식 문서를 참고해보자

api 또는 compile(지원 중단됨) 대신 이 종속 항목 구성을 사용하면 빌드 시스템에서 다시 컴파일해야 하는 모듈 수가 줄어들기 때문에 빌드 시간이 크게 개선될 수 있습니다.

 

 

예를 들어 implementation 종속 항목이 API를 변경하면 Gradle은 이 종속 항목과 이에 직접적으로 종속된 모듈만 다시 컴파일합니다. 대부분의 앱과 테스트 모듈은 이 구성을 사용해야 합니다.

 

implementation을 사용하면, 종속 항목과 직접적으로 종속된 모듈만 다시 컴파일한다고 나와있다.

그래서 모듈 하나가 변경 된다고 해서 다른 모듈들까지 모두 영향을 주지 않는 것이다.

즉 전이 의존성을 가지지 않는다고 할 수 있다.

 

반대로 api는 전이 의존성을 가지기 때문에 의존하고 있는 모든 모듈들이 영향을 받고 이것은 곧 컴파일 시간에 영향을 준다.

 

왜 api를 사용하면 다른 모듈들까지 영향을 받을까?

API는 컴파일 class-path 에도 노출되어 있기 때문에 컴파일 시에 다른 모듈들이 영향을 받게 된다.

하지만 implementation은 런타임 class-path 에만 노출이 되어 있기 때문에 다시 컴파일 할 필요가 없다.

 

🧐 두 가지 class-path 의 차이를 알아보자

컴파일 class-path : Java 코드를 class 파일로 컴파일 할 때 탐색하는 경로

런타임 class-path : 컴파일 된 자바 코드를 JVM이 실행할 때 탐색하는 경로

 

정리하자면,

api 는 컴파일 class-path , 런타임 class-path 에 노출된다.

implementation은 런타임 class-path에만 노출된다.

 

implementation을 사용하면 꽤 많은 장점들이 있다.

1. 컴파일 , 런타임 class-path를 분류함으로써 더 빠른 컴파일이 가능하다.
2. 컴파일 시에 다른 모듈에서 원치않는 라이브러리까지 의존할 필요가 없다.