Maven과 Gradle

💡
Maven과 Gradle은 대표적인 빌드 관리 도구이다. 빌드 관리 도구가 무엇이며 어떻게 발전해 왔는지 이해하고, Maven과 Gradle에 대해 자세히 알아보자 :>

📌 빌드 관리 도구란?

• 빌드(Build)
  소스 코드를 실행 가능한 프로그램으로 변환하는 과정으로서, 컴파일과 링킹 등의 다양한 단계를 포함한다(소스 코드의 구성 요소들을 모아 실행 파일 또는 라이브러리로 만들어내는 것이 목적이다).

• 빌드 관리 도구
  : 빌드와 더불어 라이브러리 관리, 테스팅 등을 '자동화'하여 수행해 주는 도구이다.

• 빌드 관리 도구를 사용하는 이유
  • 반복적인 작업을 자동화해 효율성을 높일 수 있다.
  • 라이브러리를 직접 다운로드 및 버전 업데이트할 필요가 없어진다.
  • 프로젝트의 의존성을 파악하기 쉬워진다.

📌 빌드 관리 도구의 역사

1세대 Make

: 유닉스 계열 OS(운영체제)에서 사용되는 빌드 관리 도구

• 빌드의 개념을 처음 가져온 것이 Make이다.
• 주로 Makefile이라는 파일명을 가진다.
• C언어로 개발된 소프트웨어에서는 현재도 Make를 사용한다.

2세대 Ant

: 자바 언어에서 사용되는 자동화된 소프트웨어 빌드 관리 도구

• 1990년대 등장한 Java에 Make를 적용하려니 문제가 발생해 Ant가 등장했다.
• XML 기술을 도입해(기본적인 파일명은 build.xml) 플랫폼 독립성을 확보했다.
• 간단하고 사용하기 쉽지만, 프로젝트 규모가 커지면 빌드 스크립트가 장황해진다.
• 라이브러리 의존관계를 관리하는 구조가 없어서[빌드의 기능'만' 가지고 있어서] 수작업으로 라이브러리를 조합하는 고생이 있었다.

3세대 Maven

: 자바 언어에서 사용되는 프로젝트 관리 도구

• Ant의 대안으로서 만들어진 도구 : Ant와 동일하게 XML을 사용하지만, POM(프로젝트 객체 모델)을 도입하면서 '장황한 빌드 스크립트' 문제를 해결했다.

4세대 Gradle

: 그루비(Groovy)를 이용한 빌드 자동화 시스템
(그루비(Groovy) - 자바에 파이썬, 루비, 스몰토크 등의 특징을 더한 JVM의 동적 객체 지향 프로그래밍 언어)

• XML에서 벗어나 (Make처럼) 스크립트로 회귀하며 유연성을 높였다.

📌 메이븐(Maven)

Maven은 앞서 살펴본 것처럼, Ant의 대안으로 등장한 Java의 프로젝트 관리 도구이다. POM(Project Object Model)의 개념을 도입해 프로젝트의 외부 라이브러리를 쉽게 참조할 수 있게 하고, Lifecycle의 개념의 도입으로 유지보수의 편리성을 높인 것이 가장 두드러지는 특징이다. 이 개념들은 아래에서 자세히 살펴보자.

메이븐의 POM

: Project Object Model(프로젝트 객체 모델)로, 프로젝트의 다양한 정보를 처리하기 위한 객체 모델이며, pom.xml 파일을 말한다.
(하나의 자바 프로젝트에 빌드 툴을 Maven으로 설정하면, 프로젝트 최상위 디렉토리(root)에 "pom.xml"이라는 파일이 생성된다.)
Maven의 기능을 이용하기 위해서 사용되는 POM은 프로젝트마다 1개만 존재하며, pom.xml만 보면 프로젝트의 모든 설정, 의존성 등을 알 수 있다. 모든 정보가 pom.xml 파일에 들어 있기에 pom 파일이 존재해야 빌드가 가능하다.

pom.xml에 들어가는 내용

• 기본 정보 : 프로젝트 정의, 연관 정보
• 프로젝트 정보(선택)
• 빌드 설정 : 빌드 정의, 리포트 정의
• 환경설정(선택)
  (+) project, modelVersion, groupId, artifactId, version 이 5가지는 메이븐이 허용한 최솟값이다.

pom.xml의[Maven의] 태그(tag)

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>maven-pom-project</artifactId>
    <version>1.0-SNAPSHOT</version>
</project>

pom.xml 파일은 위와 같은 형태로, 태그<>를 사용해 정보를 표시한다. 다음은 POM의 대표적인 태그들이다.

• project : 프로젝트의 정보를 기술한다.
• modelVersion : maven의 버전을 의미
• groupId : 프로젝트 그룹 Id를 뜻하며, 일반적으로 대표하는 사이트 도메인을 역술로 적어 사용(ex. tukorea.tino -> tino.tukorea)
• artifactId : groupId 외에 다른 프로젝트와는 구분될 수 있는 프로젝트의 Id를 작성
• version : 프로젝트의 버전을 의미하며 개발 단계에 따라 구분하여 작성
• name : 프로젝트의 이름
• description : 해당 프로젝트의 간략한 설명을 작성
• properties : pom.xml 파일 내에서 빈번하게 사용되는 중복 상수를 정의하는 영역 (해당 영역의 상수를 사용하기 위해서는 ${태그명}의 형태로 사용하면 된다.)
• dependencies : 해당 프로젝트에서 의존성을 가지고 사용하는 라이브러리를 정의하는 영역 (각 라이브러리마다 dependenncy 태그를 사용하여 구분한다.)
  // 사실상 가장 중요한 부분. 사용하는 라이브러리의 아이디를 기입해 줌으로써 의존성을 부여해 주는 것이다!
• build : 프로젝트 빌드와 관련된 정보를 설정하는 영역
  // 어떤 파일을 만들어낼지, 어떤 식으로 배포할지 정해두는 것이다.

메이븐의 라이프사이클(Lifecycle)

메이븐은 프레임워크이기 때문에 작업 방식이 정해져있고, 미리 정해진 빌드 순서가 있는데 이를 라이프사이클(Lifecycle)이라고 한다.

라이프사이클에 대한 이해를 위해, 다음의 용어들을 우선적으로 살펴보자.

• Phase : 빌드 라이프사이클의 각 단계
• Plugin : 각 Phase에서 실행되는 도구나 소프트웨어 모듈
• Goal : 특정 작업 [최소한의 실행 단위]

💡 설명을 붙이자면, 사용자는 필요에 따라 각 페이즈의 플러그인을 추가하고 설정할 수 있으며 하나의 플러그 안에서는 여러 작업을 수행할 수 있도록 지원한다. 각 페이즈는 의존관계(Dependency)를 가지고 있어 순서대로 실행되며, 페이즈에 아무런 Goal이 없다면 해당 페이즈는 실행되지 않는다.
phase는 빌드 순서에 맞게 지정이 돼있으므로 바꿀 수도 바꿀 필요도 없다. 대신 phase단계에 수행할 명령을 추가하거나 삭제하고 싶으면 phase에 연결되어 있는 goal을 수정함으로 Maven을 유연하게 확장시킬 수 있다(페이즈 하나에 여러 플러그인이 있을 수 있고, 각각에는 Goal이 있다).

Maven에서는 크게 3가지의 Lifecycle을 제공하며, 각각의 Build Lifecycle은 사전에 정의된 작은 Phase들을 가지고 있다. 다음은 3가지 Lifecycle인 Clean, Default, Site와 각 라이프사이클의 주요 단계를 정리한 것이다.

[Lifecycle - Clean]
역할 : Maven의 결과물/산출물 제거

• Clean : 이전 빌드에서 생성된 파일들을 삭제
  (기본적으로 Maven은 {project경로}/target 폴더를 생성하여 산출물을 저장하기 때문에 해당 goal이 실행되면 target 폴더를 삭제한다.)

[Lifecycle - Default]
역할 : 소스코드 컴파일, 테스트, 압축(패키징), 배포

• compile : 소스코드를 컴파일하여 자바코드를 바이트코드(*.class)로 변환한다.
• test : JUnit과 같은 단위테스크 프레임워크로 단위 테스트를 한다. 테스트가 실패하면 빌드 실패로 간주한다.
• package : pom.xml의 값(jar, war 등)에 따라 압축한다.
• install : 로컬 저장소(개인 PC)에 압축할 파일을 배포한다.
• deploy : 원격 저장소에 압축한 파일을 배포한다.

[Lifecycle - Site]
역할 : 프로젝트의 도큐먼트 사이트를 생성

• site : Maven 설정 파일 정보를 이용하여 프로젝트를 문서화한 간단한 웹을 만들어 준다.
• site-deploy : 생성된 문서 사이트를 설정된 서버에 배포한다.

📌 그래들(Gradle)

Gradle은 JVM의 Groovy 스크립트를 활용한 빌드 관리 도구로, Ant와 Maven를 보완한 오픈소스 기반의 build 자동화 시스템이다.

XML을 사용한 Ant, Maven과 달리 Gradle은 기존의 (1세대) Make와 같이 스크립트를 사용한다. 따라서 동적으로 실행 가능하고, 추가적인 로직을 작성하고 싶을 때 스크립트 로직을 직접 작성할 수 있다.

✔️ 그래들의 특징

• 안드로이드 프로젝트의 표준 빌드 시스템으로 채택
• 멀티 프로젝트(Multi-Project)의 빌드에 최적화하여 설계됨
• Maven에 비해 더 빠른 처리 속도를 가지고 있음(최대 100배)
• Maven에 비해 더 간결한 구성이 가능함 // 아무래도 Groovy Script를 사용하기에 xml의 태그와 위상에 대한 정렬이 없으므로!

📌 Maven / Gradle 비교

• Maven은 XML을 사용, Gradle은 Groovy Script를 사용한다.
• Gradle의 성능이 더 뛰어나다.
• Gradle의 구성이 더욱 간결해 대규모 프로젝트에서 유리하다.

가장 큰 차이점은, XML을 사용하지 않는 Gradle이 훨씬 간결하다는 것이다. 즉, Gradle은 Groovy를 사용하기에 (XML이 아닌 Java로 쓸 수 있어서) 훨씬 간결하게 표현이 가능하다. 다음의 예시는 '간결함'에 대한 직관적 이해를 돕는다.

의존관계 표현 예시 : Maven과 Gradle

다음의 첫 번째 사진은 XML로 의존 관계를 정의한 것, 두 번째 사진은 Groovy로 의존 관계를 정의한 것이다. 둘은 동일한 내용을 담고 있다.

이처럼 Groovy를 사용한 Gradle(후자)의 표현 방식이 훨씬 간결함을 한눈에 확인할 수 있다. 코드의 길이가 짧고, 가독성도 높다. 길이 자체가 짧으므로 컴퓨터에서도 더 빨리 읽어낼 수 있다. 이것이 Maven과 Gradle의 가장 큰 차이점이다.

위에서 언급했듯이 Gradle은 앞선 빌드 관리 도구들인 Make, Ant, Maven의 장단점을 절충해 만들어낸 결과물이다. 따라서 위처럼 Gradle은 Maven보다도 뛰어난 성능과 확실한 장점을 가진다. 그러나 지금까지 Maven이 주로 사용되어 왔기에 현재는 Gradle보다 Maven의 점유율이 더 높은 상황이다. 물론 Gradle의 점유율도 오르는 중이기에, Maven과 Gradle 모두 알아둠이 좋겠다.