Ant 빌드와 MAVEN 빌드 차이(수정필요)

1) 빌드 철학: 선언형 vs 절차형

Ant = 절차형(Imperative)

• 개발자가 **빌드 과정(절차)**을 “순서대로” 직접 작성합니다.
• 즉, “컴파일하려면 폴더 만들고 → 소스 모으고 → javac 실행하고 → jar 만들고 → 복사하고 …” 를 스크립트처럼 작성.

장점

• 원하는 대로 커스터마이징이 매우 자유롭다.
• 작은 작업 자동화에 빠르게 붙일 수 있다.

단점

• 프로젝트마다 build.xml 스타일이 제각각이라 표준화가 약함
• 유지보수 시 “이 빌드가 뭘 하는지” 이해 비용이 큼

Maven = 선언형(Declarative)

• 개발자는 “무엇을 만들지(결과물)” + “의존성(라이브러리)” + “플러그인 설정”을 선언하면,
• Maven이 정해진 Lifecycle(생명주기) 에 따라 자동으로 수행합니다.

장점

• 표준 Lifecycle + 표준 디렉토리 구조로 협업/유지보수에 강함
• 의존성 관리가 내장되어 있어 빌드 재현성이 좋음(누가 빌드해도 동일)

단점

• Maven 방식에 맞추는 학습이 필요
• 극단적으로 커스텀한 빌드 파이프라인은 플러그인/설정이 복잡해질 수 있음

2) 의존성(Dependency) 관리 차이: “Maven이 실무 표준인 핵심 이유”

Ant

• 기본적으로 의존성 관리 기능이 없습니다.
• 보통 /lib 폴더에 jar를 수동으로 넣고 classpath에 붙입니다.
• 버전 충돌/전이 의존성(라이브러리가 또 다른 라이브러리 요구) 관리가 어려움.

예)

• A.jar가 B 1.0 필요
• C.jar가 B 2.0 필요
  → Ant는 사람이 판단해서 jar 정리해야 함

(참고: Ivy 같은 외부 도구로 보완은 가능하지만, Ant 자체의 기본 철학은 “직접 관리”에 가깝습니다.)

Maven

• 의존성 관리가 핵심 기능입니다.
• pom.xml에 선언하면 Maven Central/사내 Nexus(Artifactory)에서 자동 다운로드
• Transitive Dependency(전이 의존성) 를 자동으로 끌고 옴
• 의존성 트리/충돌 해결 규칙이 있음

→ “내 PC에는 되는데 서버에서는 안 된다” 같은 상황이 줄어듦

3) 빌드 라이프사이클(Lifecycle) 유무

Ant

• lifecycle이 없습니다.
• target을 만들고, target 간 의존관계를 수동으로 연결합니다.

즉, 각 프로젝트마다:

• compile target
• test target
• package target
  이런 이름/순서가 다 다를 수 있음

Maven

• 정해진 lifecycle이 존재합니다.

대표적으로:

• clean : 이전 산출물 삭제
• compile : 컴파일
• test : 테스트 실행
• package : jar/war 패키징
• install : 로컬 저장소에 설치
• deploy : 원격 저장소(사내 repo 등)에 배포

mvn install 한 줄이면 “표준 순서”로 전체 수행됩니다.

4) 프로젝트 구조 표준화

Ant

• 소스 구조가 자유로움
• src가 어디인지, 리소스가 어디인지, 테스트가 어디인지 전부 build.xml에 직접 정의

→ 팀/프로젝트마다 구조가 달라져 새로 투입된 사람이 적응하기 힘듦

Maven

• 표준 디렉토리 구조가 사실상 “규격”입니다.

대표 구조:

• src/main/java
• src/main/resources
• src/test/java
• src/test/resources

→ “처음 보는 프로젝트라도 어디에 뭐가 있는지” 바로 예측 가능

5) 확장 방식: Task vs Plugin

Ant

• task 중심: javac, copy, jar 같은 태스크를 조합
• 고급 기능은 custom task를 추가해야 하고, 경우에 따라 Java로 task를 직접 개발

Maven

• plugin 중심: 빌드의 대부분 기능이 plugin으로 제공됨
• 예: 컴파일, 테스트, 패키징, shading(uber-jar), 코드 품질(SpotBugs/Checkstyle), 커버리지(JaCoCo), 배포 등

→ “표준 plugin + 설정”으로 해결되는 범위가 넓음

6) 멀티모듈/대규모 프로젝트 적합성

Ant

• 멀티모듈 구성은 가능하지만 보통 스크립트가 복잡해지고
• 의존성/버전 관리가 사람 손을 많이 탑니다.

Maven

• 멀티모듈에 매우 강함 (parent pom, dependencyManagement 등)
• 버전 통합 관리, 공통 플러그인 관리가 쉬움

대기업 SI/플랫폼에서 Maven을 많이 쓰는 이유 중 하나가 이 부분입니다.

7) CI/CD 관점

Ant

• 환경 의존적이 되기 쉬움(경로, lib, 특정 서버 설정 등)
• 빌드 재현성(reproducible build)을 맞추려면 규율이 필요

Maven

• 의존성/빌드 단계가 표준화되어
• CI 파이프라인이 단순해짐 (mvn clean verify 같은 방식)
• 사내 저장소(Nexus/Artifactory)와 연동해 운영하기 쉬움

8) 산출물/버전 관리 방식

Ant

• 버전 관리 체계가 빌드 스크립트에서 제각각
• jar/war 이름 규칙도 프로젝트마다 다름

Maven

• groupId:artifactId:version 좌표로 아티팩트를 관리
• 배포/저장소 관리까지 빌드 프로세스에 자연스럽게 통합

9)  Ant 와 Maven 비교표

항목	Ant	Maven
철학	절차형(How)	선언형(What)
표준 구조	없음(자유)	있음(강제에 가까움)
의존성 관리	기본 없음(수동)	내장(자동, 전이 의존성)
라이프사이클	없음(직접 구성)	있음(표준 단계)
확장	task/custom task	plugin 생태계
대규모/멀티모듈	관리 난이도 상승	강력 지원
재현성/CI 친화성	규율 필요	기본적으로 유리