Maven의 기초

1️⃣ Maven 기본 개념 — 빌드 자동화의 시작

섹션	주요 내용
Maven의 등장 배경	왜 Maven이 필요한가
Maven이란 무엇인가	Maven의 개념과 역할
빌드 생명주기	Maven이 무엇을 자동화하는가
표준 디렉토리 구조	Maven이 프로젝트를 어떻게 구조화하는가
의존성 관리 기본 개념	Maven이 라이브러리를 어떻게 관리하는가
플러그인	Maven에는 어떤 plugin들을 지원하는가

📖 Maven의 등장 배경

초기의 Java 개발 환경에서는 프로젝트 빌드와 라이브러리 관리가 매우 번거로운 작업이었습니다. 개발자는 필요한 라이브러리 .jar 파일을 웹에서 내려받고, lib/ 폴더에 복사한 뒤, classpath를 수동으로 지정해야 했습니다.

문제는 프로젝트가 커질수록 이 과정이 복잡하고 오류가 잦아진다는 점이었습니다. 예를 들어,

• 라이브러리 버전이 다르면 충돌이 발생함.
• 팀 내에서 환경이 달라 빌드가 실패하거나, 다른 프로젝트로 옮길 때 같은 라이브러리를 다시 설치해야 해야함.

이런 문제를 해결하기 위해 등장한 도구가 바로 Apache Ant입니다.
Ant는 build.xml 스크립트를 통해 빌드 작업을 자동화했지만,
여전히 의존성 관리 기능이 없어서 라이브러리는 여전히 수동으로 추가해야 했습니다. 이 방식은 다음과 같은 문제점이 있었습니다.

• 🧩 반복적이고 수동적인 설정: 각 프로젝트마다 build.xml 파일을 직접 작성해야 했습니다.
• ⚠️ 의존성 관리의 어려움: 여러 라이브러리를 수동으로 다운로드하고, 버전 충돌이 빈번하게 발생했습니다.
• 🗂️ 프로젝트 구조의 불일치: 팀이나 회사마다 디렉토리 구조가 달라 협업과 유지보수가 어려웠습니다.
• 🔄 일관성 없는 빌드 결과: 개발자마다 환경이 달라, 같은 코드를 빌드해도 결과가 다를 수 있었습니다.

이러한 한계를 해결하기 위해 2004년경 등장한 것이 Apache Maven입니다. Maven은 단순한 빌드 도구를 넘어, 프로젝트의 생명주기를 표준화하고, 의존성 관리를 자동화하는 통합 빌드 관리 시스템으로 발전했습니다.

이후, Maven은 Java 생태계의 사실상 표준 빌드 도구로 자리 잡았으며, 다양한 오픈소스 프로젝트와 기업 환경에서 널리 사용되고 있습니다.

✨ 요약하자면, Maven은 Ant의 한계를 극복하고 빌드 과정을 표준화하기 위해 등장한 도구입니다.

---

🧩 Maven이란 무엇인가?

Maven은 Java 기반 프로젝트의 블드와 관리를 자동화하는 도구입니다. 단순히 코드를 컴파일하는 수준을 넘어 다음과 같은 역할을 수행합니다.

• 📁 프로젝트의 디렉토리 구조를 표준화
• 🔗 필요한 라이브러리를 자동으로 다운로드 및 버전 관리
• ⚙️ 테스트, 패키징, 배포 등 프로젝트 생명주기 전반을 자동화

즉, Maven은 단순한 빌드 도구를 넘어 “프로젝트 생명주기를 관리하는 통합 플랫폼”에 가깝습니다. Maven의 가장 큰 장점은 일관성입니다. 모든 프로젝트가 동일한 규칙(src/main/java, src/test/java 등)을 따르기 때문에, 새로운 팀원 또는 프로젝트를 시작하거나 기존 프로젝트를 유지보수할 때 훨씬 빠르게 구조를 이해하고 개발에 참여할 수 있어 효율적입니다.

또한, POM(Project Object Model)기반 설정 방식을 통해 복잡한 빌드 스크립트 대신 XML 파일 하나로 프로젝트 정보를 선언적으로 관리할 수 있습니다.

✨ 요약하자면, Maven은 “Java 프로젝트의 전 과정을 체계적으로 관리해주는 빌드 관리자” 입니다.

---

🔁 빌드 생명주기 (Build Lifecycle)

Maven은 “무엇을 언제 실행할 것인가?“를 정의한 빌드 생명주기(Build Lifecycle) 개념을 기반으로 동작합니다. 즉, clean, compile, test, package, install, deploy 등의 단계가 미리 정의되어 있으며, 명령어 한 줄로 이 전체 과정을 순차적으로 실행할 수 있습니다.

예를 들어, 터미널에 다음과 같이 입력하면:

$mvn package

Maven은 내부적으로 다음 단계를 자동으로 수행하게 됩니다.

1. validate – 프로젝트 구조 및 POM 유효성 검증
2. compile – Java 소스 코드 컴파일
3. test – 단위 테스트 실행
4. package – 결과물을 JAR/WAR 파일로 패키징

대표적인 빌드 생명주기와 단계

이처럼 Maven은 “개발자가 일일이 명령을 나열하지 않아도“ 프로젝트의 생명주기를 자동으로 관리합니다.
대표적인 생명주기는 clean, default, site 세 가지이며, 각 생명주기는 여러 단계(phase)로 구성됩니다.

예를 들어, default 생명주기에는 다음과 같은 단계가 있습니다.

단계	설명
clean	이전 빌드 결과를 삭제
compile	소스 코드를 컴파일
test	단위 테스트 실행
package	JAR/WAR 파일 생성
install	로컬 저장소에 설치

이를 터미널의 명령어로 표현하면 다음과 같습니다.

mvn clean       # 이전 빌드 결과 삭제
mvn compile     # 소스 코드 컴파일
mvn test        # 단위 테스트 실행
mvn package     # JAR/WAR 생성
mvn install     # 로컬 저장소에 설치

각 명령어는 단독으로 실행될 수도 있지만, 상위 단계를 실행하면 그 이전 단계들도 자동으로 함께 수행됩니다. 예를 들어 mvn package를 실행하면,compile과 test도 선행됩니다.

🧠 요약하자면, Maven의 빌드 생명주기는 “프로젝트의 생성부터 배포까지 일관된 절차를 자동화한 체계” 입니다.

---

🗂️ Maven 표준 디렉토리 구조 (Standard Directory Layout)

Maven은 단순히 빌드 과정을 자동화할 뿐 아니라, 모든 Java 프로젝트가 동일한 구조를 따르도록 표준 디렉토리 체계를 제공합니다. 이를 통해, 프로젝트 간 일관성을 유지하고, 빌드 스크립트나 설정을 최소화할 수 있습니다.

🧩 기본 디렉토리 구조

Maven 프로젝트의 기본 구조는 다음과 같습니다:

project/
 ├── src/
 │   ├── main/
 │   │   ├── java/              # 애플리케이션 소스 코드
 │   │   ├── resources/         # 설정 파일, 리소스 (e.g. application.yml)
 │   │   └── webapp/            # 웹 애플리케이션 (WAR 프로젝트인 경우)
 │   └── test/
 │       ├── java/              # 테스트 코드
 │       └── resources/         # 테스트용 리소스
 ├── target/                    # 빌드 결과물 (컴파일된 클래스, 패키징 파일)
 ├── pom.xml                    # Maven 설정 파일 (Project Object Model)

💡 Tip: Maven은 디렉토리 이름을 기준으로 어떤 역할을 하는지 인식합니다.

예를 들어, src/main/java는 컴파일 대상, src/test/java는 테스트 대상으로 자동 구분됩니다.

이 구조는 Maven의 표준 프로젝트 구조로, 빌드 도구나 IDE(IntelliJ, Eclipse 등)가 자동으로 인식합니다.
따라서, Maven 프로젝트를 사용하면 개발자마다 폴더 구조가 달라 혼란스러웠던 과거의 문제를 해결할 수 있습니다.

📦 주요 폴더 설명

폴더 경로	역할
src/main/java	실제 애플리케이션의 Java 소스 코드
src/main/resources	설정 파일, 리소스 파일 (예: application.properties, XML 등)
src/main/webapp	웹 애플리케이션 리소스 (HTML, JSP, JS, CSS 등)
src/test/java	테스트 코드 (JUnit 등)
src/test/resources	테스트 실행에 필요한 리소스 파일
target	컴파일된 .class 파일과 빌드 결과물(JAR, WAR 등)이 저장되는 폴더
pom.xml	Maven의 핵심 설정 파일로, 프로젝트 정보와 의존성, 플러그인을 정의

🤔 왜 표준 구조가 중요할까?

Maven은 이 표준 디렉토리 구조를 기반으로 빌드, 테스트, 패키징, 배포 과정을 자동화합니다. 즉, 별도의 스크립트를 작성하지 않아도 Maven이 디렉토리 구조만으로 어떤 파일을 컴파일하고 어디에 결과를 저장할지 스스로 인식합니다.

이 덕분에 다음과 같은 장점이 있습니다:

• ✅ 프로젝트 간 일관성: 팀 내 다른 프로젝트도 같은 구조를 사용
• 🚀 설정 최소화: 별도의 빌드 경로 지정 없이도 자동 인식
• 🔍 가독성 향상: 다른 개발자가 와도 구조만 보면 역할을 즉시 파악

✨ 요약하자면, 표준 디렉토리 구조는 “Maven이 코드뿐 아니라 프로젝트 전체를 관리하는 근간” 입니다.입니다.

---

🔗 의존성 관리 기본 개념 (Dependency Management)

Maven의 가장 강력한 기능 중 하나는 의존성(Dependency)관리입니다. 과거에는 필요한 라이브러리(.jar 파일)을 직접 다운로드하고 lib/ 폴더에 복사하고, classpath를 수동으로 설정해야 했습니다.

이 방식은 버전 충돌, 중복 라이브러리, 배포 시 누락 문제 등 여러 불편함을 초래했습니다. 예를 들어, 라이브러리 버전이 달라 충돌이 나거나, 프로젝트를 옮길 때마다 환경이 깨지는 문제도 잦았습니다.
이러한 문제를 해결하기 위해 Maven은 자동화된 의존성 관리 시스템을 도입했습니다. Maven은 이러한 반복적인 작업을 자동화하는 데 초점을 맞추고 있습니다.

⚙️ Maven의 의존성 관리 방식

Maven에서는 모든 라이브러리 의존성을 pom.xml 파일에 선언합니다. 이후 Maven이 자동으로 원격 저장소(Central Repository)에서 해당 라이브러리를 다운로드하고 로컬 저장소(Local Repository)에 캐시합니다.

📁 기본 로컬 저장소 위치:

~/.m2/repository

로컬 저장소에 한 번 다운로드된 라이브러리는 다른 프로젝트에서도 재사용되므로, 빌드 속도와 일관성이 크게 향상이 됩니다.

🧩 pom.xml에서 의존성 선언

의존성 선언의 예를 들자면,

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>3.3.5</version>
  </dependency>
</dependencies>

이렇게 짧은 선언만으로 Maven에서는 다음을 자동으로 수행합니다.

1. 중앙 저장소에서 해당 라이브러리 다운로드
2. 필요한 하위 의존성(트랜지티브 의존성)까지 함께 설치
3. 로컬 저장소 (~/.m2/repository)에 캐시

또한, Maven은 동일 라이브러리의 버전 충돌을 자동으로 탐지하고, “가장 가까운 의존성(Nearest Dependency)” 규칙을 적용해 문제를 해결합니다.

🧠 의존성 충돌 해결 방식 – “Nearest Dependency”

Maven은 동일한 라이브러리가 여러 버전으로 의존될 때, “Nearest Dependency Rule(가장 가까운 의존성 규칙)”을 적용합니다. 즉, 프로젝트 트리 상에서 더 가까운 경로에 있는 버전이 우선 적용됩니다. 이 덕분에 버전 충돌을 자동으로 완화할 수 있습니다.

💬 주요 용어 정리

개념	설명
Central Repository	Maven이 라이브러리를 자동으로 내려받는 중앙 원격 저장소
Local Repository	내려받은 라이브러리를 캐시해두는 로컬 폴더 (~/.m2/repository)
Transitive Dependency	의존한 라이브러리가 또 다른 라이브러리를 의존하는 경우, 자동으로 함께 설치
Nearest Dependency	동일한 라이브러리 버전 충돌 시, 더 가까운 의존성이 우선 적용됨

✨ 요약하자면, Maven의 의존성 관리 시스템은 “하나의 설정 파일(pom.xml)로 모든 라이브러리를 자동 관리”하도록 설계되었습니다. 이를 통해 개발자는 코드 작성에만 집중하고, 라이브러리 버전 관리와 환경 설정의 복잡성을 크게 줄일 수 있습니다.

---

🔌 플러그인 (Plugin)

Maven의 빌드 생명주기(Build Lifecycle)는 각 단계에서 수행할 작업을 정의하지만, 실제로 그 작업을 수행하는 주체는 플러그인(Plugin)입니다. 즉, “빌드 단계 = 플러그인이 실행하는 작업” 이라고 이해하면 쉽습니다.

⚙️ 대표적인 플러그인

플러그인	역할
maven-clean-plugin 🧹	빌드 디렉토리 정리
maven-compiler-plugin 🏗️	Java 소스 코드 컴파일
maven-surefire-plugin ✅	단위 테스트 실행
maven-jar-plugin 📦	JAR 파일 생성
maven-war-plugin 🌐	WAR 패키징 (웹 프로젝트)
maven-install-plugin 💾	로컬 저장소 배포
maven-deploy-plugin 🚀	원격 저장소 배포
maven-resources-plugin 📁	리소스 처리 (복사, 필터링 등)
maven-dependency-plugin 🔗	의존성 분석/복사
maven-assembly-plugin 🗜️	배포용 ZIP/TAR 묶음 생성
maven-shade-plugin 🌑	Uber JAR 생성
maven-javadoc-plugin 📖	Javadoc 생성
maven-pmd-plugin 🛡️	코드 정적 분석(PMD)
maven-checkstyle-plugin 🎨	코드 스타일 검사
maven-enforcer-plugin ⚖️	환경 제약 조건 검사
maven-release-plugin 🏷️	릴리즈 및 버전 태깅
maven-site-plugin 🖥️	HTML 사이트 생성
maven-source-plugin 📂	소스코드 JAR 생성
maven-gpg-plugin 🔑	GPG 서명
maven-help-plugin 💡	도움말 및 POM 확인

💡 Tip: Maven은 기본 플러그인을 내장하고 있으며, 필요 시 버전과 설정을 직접 지정할 수 있습니다.

🔗 플러그인 선언 예시 (pom.xml)

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.11.0</version>
      <configuration>
        <source>17</source>
        <target>17</target>
      </configuration>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>3.1.2</version>
    </plugin>
  </plugins>
</build>

• <build> 안에 <plugins>를 선언하여 프로젝트별로 플러그인을 커스터마이징할 수 있습니다.
• 플러그인 설정으로 Java 버전, 테스트 환경, 패키징 방식 등을 자유롭게 지정할 수 있습니다.
• 표준 디렉토리 구조와 결합하면, Maven은 소스 컴파일 → 테스트 → 패키징 → 배포를 일관된 방식으로 수행합니다.
• 필요에 따라 플러그인을 추가/변경하면 Maven의 기능을 확장할 수 있습니다.

⚡ 기타 플러그인

플러그인	역할
maven-antrun-plugin 🛠️	Ant 태스크 실행
maven-changelog-plugin 📜	CVS/SVN 로그 추출 (구버전)
maven-changes-plugin 📝	JIRA 변경 이력 리포트
maven-doap-plugin 📄	RDF 문서 생성 (사실상 사용 안 함)
maven-docck-plugin 🔗	문서 링크 및 포맷 검증
maven-ear-plugin 🎧	EAR 패키징
maven-ejb-plugin 🏢	EJB 모듈 빌드용
maven-invoker-plugin 🔄	통합 테스트에서 Maven 호출
maven-jarsigner-plugin ✍️	JAR 디지털 서명
maven-jxr-plugin 🔍	소스 코드 크로스레퍼런스
maven-linkcheck-plugin 🔗	하이퍼링크 유효성 검사
maven-one-plugin 🕰️	Maven 1.x 호환 (중단됨)
maven-pdf-plugin 📚	PDF 문서 생성
maven-plugin-plugin 🧩	Maven 플러그인 생성 지원
maven-project-info-reports-plugin 📊	프로젝트 정보 리포트
maven-rar-plugin 🗃️	RAR (JCA) 패키징
maven-remote-resources-plugin 🌐	공통 리소스 재사용
maven-scribe-plugin ✒️	사이트 블로그 글 작성 (중단됨)
maven-stage-plugin 🚦	릴리즈 후보 staging (중단됨)
maven-surefire-report-plugin 📈	테스트 리포트 생성
maven-toolchains-plugin 🛠️	Toolchains 관리
maven-verifier-plugin ✅	파일 비교 검증
maven-xdoc-plugin 📖	xdoc 문서 생성 (중단됨)

이처럼 여러 plugin들을 통해서 원하는 형태의 빌드를 제어할 수 있습니다. 자세한 내용은 plugin 편에서 다루겠습니다.

✨ 요약하자면, 플러그인은 Maven의 핵심 실행 단위로, 빌드 생명주기와 결합해 자동화된 빌드를 가능하게 합니다.