Gradle, Maven, Ant는 모두 빌드 도구다. 빌드 도구란 무엇인가?!

우리가 열심히 작성한 코드를 서버에 배포한다고 가정하자. 이 과정에서 필요한 라이브러리를 다운 받고(이 때 버전이 맞지 않다면 다시 다운 받아야한다..), 테스팅을 거쳐 배포하는 작업까지를 모두 일일이 한다고 했을 때 정말 힘들 것이다.

빌드 도구란, 코드를 실행 가능한 파일로 만들어주는 과정에서 라이브러리 관리, 테스팅, 배포 등을 자동화 하여 수행해주는 도구라고 할 수 있다.

태초에 Ant가 있었으니.

// build.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- 프로젝트 빌드용 Ant 스크립트. build.properties의 내용을 기본 설정으로 사용한다.-->
<project name="common" default="compile">
    <property name="src.dir" value="src" />
	 
  	<target name="clean">
        <delete dir="build"/>
    </target>

    <target name="compile">
        <mkdir dir="build/classes"/>
        <javac srcdir="src" destdir="build/classes"/>
    </target>

    <target name="jar">
        <mkdir dir="build/jar"/>
        <jar destfile="build/jar/HelloWorld.jar" basedir="build/classes">
            <manifest>
                <attribute name="Main-Class" value="oata.HelloWorld"/>
            </manifest>
        </jar>
    </target>

    <target name="run">
        <java jar="build/jar/HelloWorld.jar" fork="true"/>
    </target>
</project>

• Maven과 같은 XML을 사용하고, XML을 사용해서 그런지 가독성이 떨어진다.

• Ant는 Remote Repository를 사용할 수 없는데, Remote Repository는 Gradle이나 Maven을 사용할 때 mavenRepository에서 의존성을 찾아서 넣어주기만 하면 되는데, Ant는 이게 불가능하다. 직접 jar를 받아서 넣어줘야 한다..(아래 예시)

// maven
<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.16</version>
    <scope>provided</scope>
</dependency>

providedCompile group: 'org.projectlombok', name: 'lombok', version: '1.18.16'

Ant를 보완한 Maven

Ant와 같은 Apache에서 개발되었다.

• 생명주기(Lifecycle)의 개념이 도입되었다.

  • 빌드 도구의 Lifecycle은 개발자가 프로젝트를 빌드하거나 배포할 때 어떤 단계들을 거쳐야 하는지를 정의한다.
  • **clean**, compile, test, package, install, deploy 등이 있다.

• POM 파일을 통해 mavenRepository에서 플러그인과 의존성을 받아올 수 있고, 관리까지 가능하다.

• 하지만 메이븐은 Ant와 마찬가지로 XML을 기반으로 한다. 즉 프로젝트가 복잡해지고, 의존성이 많아지고, 플러그인이 많아질 수록 가독성이 떨어진다. 아래는 그 예시다.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>my-project</artifactId>
    <version>1.0.0</version>
    <dependencies>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.12.0</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.13.2</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

• XML기반의 빌드 도구는 또 한가지 문제점이 있다. XML은 정적인 데이터를 저장하는데 적합한 언어고, 동적인 행위인 빌드에 크나큰 제약이 걸린다.

• Maven은 멀티 모듈 구현을 지원하는데, 이를 상속 구조로 표현하고 있다.

  • 이는 프로젝트 구조가 복잡해질수록 이해하기 어려워지고, 유지보수가 어려워질 가능성이 높다.
  • 상속 구조는 유연성과 확장성이 제한될 수 있다. Parent 모듈을 상속받은 Child모듈에서 새로운 의존성을 추가할 때 문제가 발생할 수 있으며, 당연히 자식이 많아지고 구조가 복잡해지면 결합도가 강해져 다른 의존성을 추가할 때 제약이 발생할 수 있다.

Maven을 넘어 Gradle로 가자.

그렇게 등장한 Gradle

• Gradle은 build.gradle로 관리된다. Ant와 Maven과 다르게 Groovy기반의 DSL(Domain Specific Languages)을 사용한다.
  • XML은 태그가 많아서 가독성이 떨어졌지만, Groovy를 통해 많이 간결해졌다.

//예제 코드
plugins {
    id 'org.springframework.boot' version '2.3.4.RELEASE'
    id 'io.spring.dependency-management' version '1.0.10.RELEASE'
    id 'java'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

//동적 빌드
**def gradleProfile = project.hasProperty("profile") 
										? project.property("profile").tostring() : "local"**

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
        exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
		//동적 빌드
		if (gradleProfile == "local"){
			implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
		}
}

test {
    useJUnitPlatform()
}

• Gradle은 Groovy 기반으로 동작하기 때문에 Groovy 스크립트로 플러그인을 호출하거나 코드를 작성할 수 있다. ⇒ 동적인 빌드가 가능하다!

  • 프로젝트의 조건을 체크할 수 있는데, 이를 통해 유연한 설정이 가능하다.
  • 특정 상황에서만 동작하게끔 설정 가능하다. (위 코드의 주석 확인)

그래들의 성능상 이점

Daemon

• Gradle 빌드시에 daemon 상태로 동작하게 되어 인스턴스를 유지하고 빌드가 끝난 뒤에도 background에서 동작되어 사라지지 않는다.

• Gradle Daemone 유무 차이

  • 빌드 시간이 daemon을 실행하기 전 59초에서 daemon을 실행한 후 2초로 확연히 줄어든 것을 볼 수 있다. (이는 코드 변경 없이 그대로 재시작 했을 때의 경우다.)
    

    

병렬 처리(Parallel)

- 프로젝트를 멀티 모듈(Multi Module) 혹은 MSA(Micro Service Architecture)를 구성할 때 각 프로젝트를 개별적으로 빌드할 수 있다.
- 다음은 Gradle 공식 홈페이지에서 가져온 병렬처리 유무에 따른 실행 시간 비교 분석이다.

![](https://velog.velcdn.com/images/789456jang/post/566536d8-0547-44f8-a9ea-7a13528a7ba7/image.png)

![](https://velog.velcdn.com/images/789456jang/post/3a9ad394-e09b-435a-a68e-1951ac8421ac/image.png)

• Paralell 처리를 하지 않고 실행 했을 때 8초 가량 소요, 반면에 Paralell 처리를 한 결과 40% 가량 시간이 단축
  

캐시(cache)

• 이전에 실행한 작업의 결과를 저장하고 재사용하는 매커니즘이다.

• 대표적으로 의존성 캐싱과 태스크 캐싱이 있다.

  • 의존성 캐싱: 외부 Repository에서 가져온 의존성 라이브러리를 로컬 캐시에 저장하여 다음 빌드에 재사용하게끔 만들어준다.
  • 태스크(Task) 캐싱: 태스크 수행 중 중복되는 부분을 재사용함으로써 빌드 시간을 단축한다. 태스크 캐싱은 이전에 성공적으로 실행된 태스크에 동일한 입력 값이 주어진 경우에만 태스크를 다시 실행합니다.