[개인 개발 공부] 그래서, MAVEN이 뭔데?

 

Q. 왜 만들었어?

 

이 시리즈는 어떤 강의에서도 가르침 받지 못한 궁금한 것을 별도로 적어보기 위해서이다. 부트캠프에서 배우지 않았다고 그냥 넘어가는 건 내 성미에 맞지 않는다. 그렇다고 블로그만 보고 넘어가면 까먹을 거 같고, 그리고 무엇보다도 공부 기록을 남기고 싶었기 때문에 조금 시간을 들여서라도 개인 공부 시리즈를 추가했다.

 

여기는 편하게 말하는 페이지라, 보는 사람들은 이렇게 공부를 왜 하는 거지? 싶을 수도 있다. 하지만 다른 곳에서 열심히 적고 있으니 이곳에서만큼은 자유로이 공부한다고 생각해주길 바란다.

 

 

Q. 그래서 오늘 다룰 내용은?

 

바로 Maven이다. Maven에 대해서 지금부터 다뤄볼 예정이다. Maven이란, Java 프로젝트의 빌드, 의존성 관리 및 프로젝트 생명주기 관리를 위해 사용하는, 오픈 소스 빌드 자동화 도구이다. Maven을 알아두면 java 웹 프로그래밍에서 편한 부분이 많기 때문에 알아두면 좋을 것이라고 생각했기 때문에 이 토픽을 정했다. 최근에는 Gradle이 대세라고는 하지만, 아직 업계 표준은 Maven이라고 하니 알아둬서 나쁠 것은 없다.

 

 

Maven의 탄생

Maven은 아파치Apache 메이븐이라고도 한다. 여기서 아파치란 아파치 소프트웨어 재단(ASF)를 의미하며, 메이븐은 아파치 소프트웨어 재단에서 개발한 툴이다. 이 녀석 이전에 사용한 빌드 도구는 바로 Apache Ant이다. 이것도 ASF에서 개발한 것인데, 아파치에 대해서도 추후에 다뤄볼 생각이 있다. 여하튼, 이 Apache Ant의 고질적인 문제점이 있었으니, 바로 프로젝트마다 빌드 방식이 제각각이라는 지점이다.

 

 

지금으로선 상상도 할 수 없는 끔찍한 이야기인데, Maven이 나타나게 된 년도가 2004년이라는 걸 생각하면 이해가 된다. 그때는 아직 체계 하나가 제대로 되어 있지 않은 인터넷의 무법시대였다. exe 파일을 다운로드 받으면 바로 컴퓨터가 바이러스에 걸리는, 그런 시대였으니 어찌보면 당연한 것이라고 할 수밖에는. 심지어 HTML5의 탄생 이전의 HTML에는 웹표준이랄 것도 제대로 지켜지지 않고 있었다.

 

심지어 java의 라이브러리는 매우 방대한데, 그 라이브러리를 하나하나 가져오는 방식을 취해야했다. 개발자 입장에서 java 개발은 거의 노가다 행위에 가깝다. 

 

 

자, 내 말대로 해.

Maven의 가장 큰 장점 중 하나는 바로 빌드의 규격화에 있다. 무슨 소리냐면, 묻지도 따지지도 말고 이 폴더에 넣어라, 아니면 작동하지 않겠다라고 으름장을 놓았던 것이다. 소스 코드는  src/main/java 안에, 설정 파일은  src/main/resources 안에, 이 구조를 지키면 Maven은 알아서 컴파일하고 패키징하게 된다. 이 규칙 덕분에 해당 파일을 받은 다른 사람도 쉬이 프로젝트 구조를 파악할 수 있게 되었다.

 

pom.xml과 함께라면 두렵지 않아!

Maven을 깔게 되면 가장 먼저 보게 되는 파일이 있는데, 바로  pom.xml  이다. 이 pom은 바로 Project Object Model의 약자로, 하나의 설계도 같은 것이다. xml에 대해서도 생소한 사람이 있을 텐데, xml은 Extensible Markup Language라는 의미로, 데이터를 저장하고 전달하기 위해 고안된 텍스트 기반의 데이터 형식이다. 당장 티스토리 스킨에서도 index.xml을 사용하는데, 이에 대해서 지금은 다루지는 않겠다. 중요한 건, 이 pom.xml  덕분에 라이브러리 춘추전국시대를 어느정도 해결할 수 있었다는 점이다. 이 pom.xml 에 라이브러리를 적으면, Maven이 중앙 저장소에서 파일을 가져와 자동으로 컴파일해준다.

 

일반적인  pom.xml 은 다음과 같은 구조로 이루어져 있다.

<project>
  <modelVersion>4.0.0</modelVersion> <!-- Maven 필수 버전 -->
  
  <!-- 1. 내 프로젝트 정보 -->
  <groupId>com.mycompany</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0-SNAPSHOT</version>

  <!-- 2. 공통 변수 설정 (자바 버전 등) -->
  <properties>
    <maven.compiler.source>17</maven.compiler.source>
    <maven.compiler.target>17</maven.compiler.target>
  </properties>

  <!-- 3. 의존성 관리 (라이브러리 목록) -->
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.10.0</version>
      <scope>test</scope> <!-- 테스트 할 때만 쓸게! -->
    </dependency>
  </dependencies>

  <!-- 4. 빌드 관련 설정 (플러그인 등) -->
  <build>
    <plugins>
      <plugin> ... </plugin>
    </plugins>
  </build>
</project>

 

여기서 라이브러리는 바로  dependencies 라는 블록 안에 들어가는데,  dependency 라는 블록으로 시작하여,  groupId ,  artifactId ,  version 이라는 필수적인 좌표로 라이브러리를 지정하게 된다. 아래에 있는 scope는 의존성의 유효 기간을 나타내는 것인데, 기본 값은  compile 로서, 컴파일, 테스트, 실행 모든 단계에서 사용한다는 의미가 된다.

 

근데 왜 .XML이었을까?

왜냐하면 Maven이 탄생할 당시(2000년대 초반) XML은 가장 신뢰받는 데이터 표준이었기 때문이다. 텍스트 파일이라 메모장에서도 읽히고 수정이 쉽고, 형식이 틀리면 빌드 자체가 안 되도록 엄격하므로 오류를 잡아내기 쉬웠다. 다만 아래에서 후술할 Gradle에서는 .xml의 대체로서 .yml이라는 것이 사용 되고 있기는 하다.

 

 

메이븐의 Life Cycle

메이븐은 생명주기를 가지고 있는 빌드이다. 그 중에서도 엄격한 방식의 라이프사이클을 가지고 있는데, clean, default, site의 라이프 사이클을 가지고 있다.

출처는 Maven 공식 홈페이지

 

이 중 가장 많이 사용되는 것은 default로, 이는 또한 여러 가지의 단계로 나눠진다. 각 단계는 간단히 말하면 다음과 같다.

 

1. validate 프로젝트 상태가 정상인지, 필요한 정보가 다 있는지 확인
2. compile  자바 소스 코드( .java )를 컴퓨터가 읽는 클래스 파일( .class )로 변환
3. test  단위 테스트 코드를 실행해서 버그가 없는지 검증
4. package 컴파일된 코드와 설정 파일을 하나로 묶음
5. install 생성된 패키지를 내 컴퓨터의 로컬 저장소에 저장
6. deploy 최종 결과물을 원격 서버에 배포

이런 라이프 사이클을 통하면 두 가지 장점이 있는데, 첫 번째로는 이전 단계는 자동으로 실행된다는 지점이다. 우리가 4번째 단계인 package를 하려고 하면, Maven이 알아서 1-3단계를 처리해줄 수 있다는 것. 두 번째로는, 이러한 엄격함을 통해 이전 단계를 통과하지 못하면 다음 단계로 넘어가지 못하게 해 검증을 도와준다는 점이다.

 

 

Gradle이 더 낫다고?

그러나 최근에는 Maven보다 Gradle이 더 선호되고 있다고 한다. 물론 아직도 Maven이 점유율이 높지만, Gradle이 선호되는 이유는 속도, 유연성, 가독성 이 세 가지라고 할 수 있다.

 

가장 크게 느껴지는 것은 속도로, 프로젝트 규모가 작다면 둘의 속도는 비슷하지만 프로젝트 규모가 커질 수록 Gradle이 더 빠르다. 이것은 Gradle이 마지막 빌드 이후 변경된 파일만 골라서 빌드하기 때문이다. 이걸 듣고 어디서 많이 떠올랐는데, React 방식도 이와 비슷하다. 변경된 것만 확인해서 그 부분만 고친다. 그렇게 되면 속도 면에서 훨씬 더 우위를 점할 수 있게 되는 것이다.

 

다음으로는 유연성이라고 할 수 있는데, 사용하고 있는 YAML(.yml)의 경우, maven이 사용하는 XML 보다 더 유연하다. XML의 경우 정적이기 때문에 복잡한 로직을 쓰지 못하는 반면, YAML 은 프로그래밍 언어를 그대로 사용할 수 있다. 이 부분은 if 나 for 을 사용할 수 있기 때문에 간편하고 다양한 상황에 대처할 수 있다는 의미가 된다.

 

그리고 가독성인데, XML의 경우 위 코드에서 보면 알겠지만 여는태그와 닫는 태그로 이루어져 있는 반면, YAML은 다음과 같이 사용되고 있다

 

dependency:
  groupId: org.springframework.boot
  artifactId: spring-boot-starter-web
  version: 3.2.0

 

길지 않고 알아보기 편하다. 익숙한 느낌이라면 바로 그렇다, 파이썬처럼 들여쓰기와 :로 이루어져 있다. 이 덕분에 Gradle은 최근에 그 영향력을 조금씩 늘려가고 있다. 현재 구글 또한 Gradle을 사용하고 있다.

 

 

마무리하며

그래서, Maven이 뭔데? Maven은 ASF에서 개발한 빌드 툴로, 2004년부터 그 강한 규칙을 사용하여 빌드 형식을 규격화하는 등의 큰 영향을 끼쳐 왔다. 새로운 툴이 생기더라도 java에서의 Maven의 영향력은 무시할 수 없다. java도 엄격한 언어인 걸 생각하면 어쩌면 둘은 천분연생일지도?