빌드 도구! 그거 너 설명할 수 있어?

작성 계기

바야흐로 저번주 인생 첫 코드 리뷰를 받았는데!! 두둥탁
예상치도 모르게 build.gradle에 코드 리뷰가 달렸다...
(예상치도 못한 전개!)

이 사건이 도화선이 되어 이 아티클을 작성하게 됐는데~

사실 플젝을 할 때 Maven과 Gradle 중 다들 grale로 하니깐+gradle이랑 maven 중에 gradle이 더 쓰기 편하구 어쩌구... 그냥 그렇게 하라고 하니까 Gradle Project로 선택했다. 코드 리뷰를 받고 근데 '왜 이걸 쓰는거지?'에 대]대한 물음표가 머리 속에 가득 찾다.

빌드 도구는 뭐징? 그냥 빌드를 도와주는 도구? Maven 과 Gradle 뭔 차이지? 왜 다들(?) Gradle이 편하다고 하고 이걸 쓰는거지? 에 대한
를 톺아보겠다.

빌드란?

우선 빌드는 무엇일까? 빌드란 프로젝트의 소스코드 개발에서 최종 사용자에게 전달되기까지의 모든 과정을 말한다.
우리는 보통 프로그램을 만들어 코드를 실행하고 결과를 확인하려고 하면 어떤것 부터 할까? 이클립스나 인텔리제이 같은 IDE를 먼저 연다.(사실 정답은 컴퓨터부터 켠다...ㅎ) 그 후 자바로 코드를 작성한 후 RUN 실행 버튼을 누르면 우리는 코드에 대한 실행 결과를 확인할 수 있다.그런데 다른 사람들이 우리가 적성한 실행 결과들을 확인하려고 하면 우리랑 똑같이 인텔리제이를 깔고 코드를 붙여 넣기해서 실행시키지는 않는다는 것을 우리 모두가 안다. 배포하여 빌드된 파일을 서버에 업로드하여 사용자에게 제공하는 과정을 통해 사용자들은 빌드된 결과물(.war, .jar 등)을 실행하기만 하면 된다!

빌드 과정을 조금 더 자세히 살펴 보자면 다음과 같은 과정이 포함하게 된다.

1.	컴파일(Compile): 소스 코드를 기계어로 변환하여 실행 가능한 바이너리 파일(.class 등)을 생성한다.
2.	링킹(Linking): 컴파일된 코드와 필요한 라이브러리나 다른 모듈들을 결합하여 하나의 프로그램으로 만든다.
3.	패키징(Packaging): 바이너리 파일, 리소스 파일 등을 묶어 .jar, .war 같은 형식의 파일로 패키징하여, 배포 가능한 형태로 만든다.
4.	테스트(Testing): 자동화된 테스트를 통해 빌드된 프로그램이 정상적으로 동작하는지 검증한다.
5.	배포(Deployment): 최종적으로 빌드된 결과물을 서버에 업로드하여 사용자에게 제공하는 단계이다.

이러한 빌드 과정 덕분에 최종 사용자들은 개발 환경에 신경 쓰지 않고도 빌드된 결과물을 손쉽게 사용할 수 있다.

그리고 이러한 빌드를 자동화해서 도와주는 도구가 빌드 도구 인것이다.

우선 빌드 도구를 사용하지 않으면 개발자는 여러 가지 번거롭고 비효율적인 작업을 직접 처리해야 한다. 먼저 각종 라이브러리를 수동으로 다운로드하고 의존성을 직접 관리해야 하는데, 이는 시간이 많이 걸리고 의존성 충돌을 일으킬 수 있다. 또한, 소스 코드를 컴파일하고, 테스트를 실행하며, 패키징하고, 배포 파일을 만드는 과정까지 모두 수동으로 처리해야 하므로 매우매우 비효율적이다!!

빌드 도구를 사용하면 이러한 작업들이 자동화되어 효율성이 크게 향상된다. 빌드 도구는 의존성을 자동으로 관리해주어 개발자는 필요한 라이브러리를 손쉽게 추가하고, 충돌을 방지할 수 있다. 또한, 컴파일부터 테스트, 패키징, 배포까지 모든 과정을 자동으로 처리해 일관된 빌드 결과를 제공하고, 실수를 줄일 수 있다.

이제 우리가 스프링 이니셜라이져에서 봤던 Spring 프로젝트의 빌드 도구인 Maven과 Gradle에 대해 알아보도록 하겠다!

Maven은 XML 기반의 설정 파일(pom.xml)을 사용하여 프로젝트의 의존성과 빌드 과정을 관리한다. XML은 데이터를 구조화하는 데 적합하지만, 빌드와 같은 동적인 요소를 정의하기에는 제한적이다. Maven은 표준화된 프로젝트 구조와 라이프사이클을 제공하여 일관된 빌드 환경을 유지하는 데 도움이 되지만, 설정이 길어지면 가독성이 떨어지고, 복잡한 의존성을 가진 프로젝트에는 적합하지 않을 수 있다.

- Maven 라이프 사이클 

Clean : 이전 빌드에서 생성된 파일들을 삭제하는 단계
Validate : 프로젝트가 올바른지 확인학고 필요한 모든 정보를 사용할 수 있는 지 확인하는 단계
Compile : 프로젝트의 소스코드를 컴파일하는 단계
Test : 유닛(단위) 테스트를 수행하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능)
Package : 실제 컴파일된 소스 코드와 리소스들을 jar등의 배포를 위한 패키지로 만드는 단계
Verify : 통합테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
Install : 패키지를 로컬 저장소에 설치하는 단계
Site : 프로젝트 문서를 생성하는 단계
Deploy : 만들어진 Package를 원격 저장소에 release하는 단계

Gradle은 Groovy나 Kotlin 기반의 DSL(Domain Specific Language)을 사용하여 빌드 스크립트를 작성하는 4세대 빌드 도구이다. 이 DSL은 빌드 과정을 유연하고 간결하게 표현할 수 있어, Maven의 XML 설정보다 가독성이 뛰어나다. Gradle은 JVM 위에서 동작하는 Groovy라는 스크립트 언어로 작성되어, 소스 코드를 그대로 실행할 수 있으며, 컴파일이 필요하지 않는다. 덕분에 동적인 빌드 설정이 필요할 때 플러그인을 호출하거나 직접 코드를 작성하여 손쉽게 구현할 수 있습니다.

Gradle은 의존성 캐싱, 증분 빌드, 병렬 빌드 등 다양한 최적화 기능을 통해 빌드 속도를 크게 향상시킬 수 있으며, Maven보다 빠른 성능을 제공한다. 또한, 기존의 Maven이나 Ivy 등과 같은 빌드 도구들과도 호환이 가능하여, 기존 프로젝트에서 Gradle로의 전환이 쉽다. Gradle은 Configuration Injection 방식을 사용해 공통 설정을 주입하면서도 프로젝트의 조건을 체크하여 프로젝트별로 다른 설정을 적용할 수 도 있다. 이렇게 공통 구성은 유지하되, 프로젝트마다 상이한 부분만 따로 주입할 수 있어 유연한 빌드 환경을 제공한다.

다음은 Gradle을 사용하여 스프링 부트 애플리케이션의 빌드 스크립트 예시이다.

plugins {
        id 'org.springframework.boot' version '2.3.1.RELEASE'
        id 'java'
    }

    repositories {
        mavenCentral()
    }

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

Maven vs Gradle

1. 스크립트 길이와 가독성 면에서 gradle이 우세하다.
2. 빌드와 테스트 실행 결과 gradle이 더 빠르다. (gradle은 캐시를 사용하기 때문에 테스트 반복 시 차이가 더 커진다.)
3. 의존성이 늘어날 수록 성능과 스크립트 품질의 차이가 심해질 것이다.

maven은 프로젝트가 커질수록 빌드 스크립트의 내용이 길어지고 가독성이 떨어지는 반면 gradle은 적은 양의 스크립트로 짧고 간결하게 작성할 수 있다. 또한 maven이 정적인 형태의 XML 기반으로 작성되어 동적인 빌드를 적용할 경우 어려움이 많다면, gradle은 Groovy를 사용하기 때문에 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 짜면 된다. 뿐만 아니라 maven의 경우 멀티 프로젝트에서 특정 설정을 다른 모듈에서 사용하려면 상속을 받아야 하지만 gradle은 설정 주입 방식을 사용하기 때문에 멀티 프로젝트에 더 적합하다.

다음은 maven과 gradle의 속도 비교표이다.

이 결론이 맞나 싶긴한데 앞으로도 정리하면서 더 느낀 것이지만 앞으로도 Maven 대신 Gradle을 쓸 것 같다!ㅎ

[출처]
출처: https://dev-coco.tistory.com/65 [슬기로운 개발생활:티스토리]