Maven과 Gradle

 

Java로 Spring Boot 개발을 해봤다면 프로젝트 초기 생성 시에 Maven과 Gradle 두 가지 방법 중 무엇을 선택해야 하는지 의문이 있었을 것이다.

 

그 궁금증을 해결하기 위해 Maven과 Gradle에 대해 알아보자.

 

Build 란?

 

Java로 열심히 코딩을 하면 .java라는 파일이 만들어진다.

하지만 이 파일은 그냥 메모장에 적힌 글씨일 뿐, 컴퓨터가 바로 읽어서 실행할 수는 없다.

 

빌드(Build)란 우리가 작성하는 소스코드와 이미지, 설정 파일들을 모아서 컴퓨터가 실행할 수 있는 하나의 제품(.jar 또는 .war 파일)으로 만드는 과정을 말한다.

=> 정확하게는 Java의 빌드 결과물인 .jar이나 .war 파일은 특정 OS(윈도우, 리눅스 등)에 종속된 파일이 아니라, JVM이 읽는 바이트코드(.class 파일)로 이루어져 있음. 이 파일 하나만 있으면 각 OS용 JVM이 실행 시점에 해당 OS에 최적화된 기계어로 번역하여 프로그램을 구동함

 

(즉, Java를 Build할 때는 윈도우용, 리눅스용 Build를 따로하는게 X)

 

JAR(Java ARchive)는 자바 프로젝트를 압축하는 가장 표준적인 방법으로 자바 클래스 파일(.class), 라이브러리, 설정 파일들을 하나로 묶을 때 사용한다.

자바 런타임(JRE)만 설치되어 있다면 어디서든 바로 실행할 수 있고 주로 라이브러리나 독립적인 프로그램을 만들 때 사용한다.

=> 요즘은 Spring Boot로 빌드하면 내장 Tomcat이 포함된 Fat JAR가 만들어지기에 서버 설치 없이 파일 하나만 실행하면 바로 웹 서비스가 구동 가능함

WAR(Web Application ARchive)는 웹 어플리케이션을 위해 별도로 규격화된 포자 방법으로 웹 브라우저를 통해 접속하는 '웹 서비스' 전체를 배포할 때 사용한다.

=> 혼자서는 실행될 수 없고, 반드시 WAS(Tomcat 같은 서버) 안에 넣어줘야 작동하며 외부 서버 환경에 내 프로그램을 얹어서 실행해야 하는 경우(ex. 회사 공용 서버를 쓰는 경우)에 주로 사용함

 

Java/Spring Boot에서 빌드를 생각해보면

 

 

1. 우리가 쓴 자바 코드를 컴퓨터 언어(바이트 코드)로 번역하는 컴파일 과정

 

2. 웹사이트에 들어갈 사진이나 설정값들을 적절한 위치로 옮기는 리소스 복사 과정

(이미지나 설정 파일 같이 변하지 않는 정적 파일들은 번역 과정 없이 바이트코드 파일들과 함께 .jar 안에 원본 그대로 포함되어 패키징됨)

 

3. 코드가 제대로 작동하는지 시험해보는 테스트 과정

 

4. 번역된 코드와 자원들을 하나로 묶어 .jar라는 압축 파일을 만드는 패키징 과정

 

을 거쳐서 파일이 완성되어야만 WAS(Wep Application Server)라는 웹 프로그램을 돌려주는 엔진(ex. Tomcat) 위에 올려서 웹 사이트를 다른 사람들에게 보여줄 수 있게 된다.

 

Build Tool 이란?

 

예전에는 개발자가 직접 명령어를 입력해서 위에 적힌 것처럼 컴파일하고, 파일을 옮기고, 압축을 해야 했기에 프로젝트가 커지면 수 천 개의 파일을 일일이 관리하기가 거의 불가능했다.

 

그래서 이런 노가다를 대신 해줄 자동화 비서가 생긴건데, 그게 바로 빌드 도구(Build Tool)이다.

 

Java(정확히는 JVM위에서 돌아가는 언어들)의 대표적인 빌드 도구들을 살펴보자

 

Ant

 

출처 : 위키백과

 

가장 초창기에는 Ant라는 도구가 있었는데 이 Ant는 매우 자유로웠지만, 하나부터 열까지 개발자가 지시 사항을 다 적어줘야했다.

 

"A 폴더 파일 번역해, B 폴더로 옮겨, 그 다음 압축해..."

 

이렇게 보면 수동으로 빌드하는거랑 다를게 뭐지? 라는 생각이 들 수 있는데 처음 한 번만 build.xml 에 지시 사항을 적어두면, 그 뒤로는 ant build 같은 명령어 한 줄만 치면 끝나기 때문에 수동 빌드 시 발생할 수 있는 실수를 방지할 수 있다.

 

하지만 무엇보다 라이브러리 관리 기능이 없어서, 개발자가 직접 인터넷에서 파일을 찾아 다운로드하고 프로젝트에 수동으로 넣어줘야하는 큰 불편함이 있었다.

 

Maven

 

출처 : 위키백과

 

 

이런 Ant의 불편함을 해결하기 위해 2004년 아파치 재단에서 만든 것이 Maven이다.

 

Ant의 불편함 속에서 탄생한 Maven은 확실한 장점이 존재한다.

 

• 우선 Maven은 pom.xml 이라는 문서에 "나 이 라이브러리 필요해"라고 이름과 버전만 적으면, Maven이 인터넷 창고에서 알아서 다운로드를 해온다.
  
  => 인터넷 창고의 정확한 명칭은 Maven Central Repository라는 곳으로, 전 세계 Java 개발자들이 만든 검증된 라이브러리들이 모여 있음
  
  
• 모든 Maven 프로젝트는 폴더 구조가 똑같기에 처음 보는 프로젝트라도 어디에 코드가 있는지 쉽게 알 수 있다.
  
  => Maven은 Java 코드는 무조건 src/main/java, 설정 파일은 무조건 src/main/resources, 테스트 코드는 무조건 src/test/java 와 같은 빌드 시 폴더 구조의 표준화가 되어있지만
  Ant의 경우 소스 코드를 my_code 폴더에 둘거면 빌드 스크립트에 srcDir = "my_code" 와 같이 직접 일일이 적어줘야했음
  
  (Maven도 설정을 바꾸면 폴더 위치를 변경할 수 있지만 이러면 Maven의 장점이라고 할 수 있는 기능을 포기하는 꼴임)
  
  
• clean(청소 - 이전 빌드 결과물 삭제) -> compile(번역 - .java를 .class 바이트 코드로 컴파일) -> test(테스트) -> package(포장 - 컴파일된 코드와 리소스를 묶어 .jar나 .war로 만듬) -> install(설치 - 내 컴퓨터의 로컬 저장소에 생성된 패키지 저장) -> deploy(배포 - 최종 패키지를 원격 저장소에 올림) 이라는 라이프 사이클이 이미 정해져있다.
  
  => 이런 라이프사이클이 존재하기에 특정 단계를 명령하면 그 앞의 단계들이 순서대로 자동 실행되는 편리함이 존재함

 

하지만 당연하게도 이런 Maven도 단점이 존재하는데

 

• XML 형식을 사용하기에, 설정이 길어지면 파일이 너무 복잡해져서 읽기가 어렵다.
  
  
• 정해진 규칙을 벗어나 독특한 방식으로 빌드하고 싶을 때 수정하기가 까다롭다.
  (이런 유연성 부족은 규칙이 자유보다 편하다는 Convention over Configuration이라는 철학을 가지고 Maven이 등장했기 때문)

 

Gradle

 

출처 : 위키백과

 

 

Maven 이후, 2008년에 등장한 Gradle은 Maven의 장점과 Ant의 자유로움을 결합한 빌드 도구이다.

 

우선 Maven보다 훨씬 빠른 빌드 속도를 가지고 있고 XML 대신 Groovy나 Kotlin 언어를 사용하기에 설정 파일이 훨씬 짧고 가독성이 좋다.

 

=> 증분 빌드(바뀐 부분만 빌드)와 캐싱(이미 했던 빌드는 다시 안함) 기술 덕분에 대규모 프로젝트에서 빌드 속도에서 큰 차이가 발생함

 

그리고, 프로그래밍 언어의 특징을 가지고 있기에, 빌드 과정을 개발자 마음대로 세밀하게 조정이 가능하다.

 

하지만, 워낙 기능이 강력하고 자유롭다 보니, 초보자가 설정을 완벽히 이해하고 활용하기까지의 러닝커브가 존재한다.

 

Gardle과 Maven 무엇을 선택해야 할까?

 

빌드 도구는 결국 코딩에만 집중할 수 있게 도와주는 도구일 뿐이지만 둘 중 하나를 선택하는 상황을 비교해본다면

 

새로 Spring Boot나 Android 개발을 시작하는 입장에서 성능과 편의성 면에서는 최신 트렌드의 중심인 Gradle을 공부하며 사용해보는 것이 좋다고 생각하고 

 

오래된 레거시 프로젝트나 보수적인 금융권, 대기업에서는 여전히 Maven을 선호하는 경우가 있고 전통의 강자이다보니 공부 자료가 굉장히 많고 안정적이라는 장점이 있기에 상황에 맞춰 선택하는 것이 좋아보인다.

 

Reference

 

https://www.youtube.com/watch?v=3Jp9kGDb01g