Maven vs Gradle 선택 기준: web.xml과 pom.xml은 XML만 같았다

web.xml과 pom.xml은 확장자만 같고 읽는 주체가 다르다. Gradle과 web.xml도 같이 쓴다. Maven과 Gradle 중 무엇을 고를지, 속도보다 중요했던 판단 기준.

조회
목차

프론트만 하다가 백엔드를 배우려고 JSP/Servlet 게시판을 만들기로 했다. 코드를 짜기 전에 두 가지를 정해야 했다.

  1. 서블릿을 어떻게 등록할까 — web.xml이냐 애노테이션이냐
  2. 빌드 도구는 Maven이냐 Gradle이냐

둘 다 첫날부터 헛발을 짚었다.

확장자가 같으면 한 세트인 줄 알았다

web.xml을 쓰기로 정하고 나서 이렇게 생각했다.

"그럼 Gradle은 못 쓰는 거 아냐? XML은 Maven인 것 같은데"

아무 관계가 없었다. 두 파일은 읽는 사람이 다르다.

파일누가 읽나
web.xml톰캣
pom.xmlMaven
build.gradleGradle (XML도 아니다)

web.xml은 톰캣에게 "이 주소로 오면 이 클래스를 불러라"라고 알려주는 파일이고, pom.xml은 Maven에게 "이 라이브러리 받아와라" 하는 파일이다. 서로 상관이 없으니 Gradle + web.xml 조합도 흔하다.

"빠른 게 좋은 거 아냐?"로 골랐다가 다시 골랐다

Gradle이 빠르다는 말을 보고 Gradle로 정했다. 근데 이 프로젝트는 파일이 수십 개라 빌드 시간 차이가 몇 초다. 속도가 결정 근거로는 너무 약했다.

진짜 걸리는 건 따로 있었다. JSP/Servlet 자료가 거의 다 Maven 기준이다. 오래된 스택이라 강의도 블로그 예제도 pom.xml 조각으로 나온다.

바꿔 적는 것 자체는 어렵지 않다. 문제는 막혔을 때다. 에러로 검색하면 Maven 기준 답이 나오는데 그게 내 설정에 안 맞는다. 그 시간은 서블릿 배우는 시간이 아니다.

그래서 코드 짜기 전에 Maven으로 바꿨다.

남길 것

  • 확장자가 같다고 같은 도구가 아니다. 설정 파일은 "누가 읽는 파일인가"로 구분한다.
  • 빠른 게 항상 이득은 아니다. 이 규모에서 빌드 속도 차이는 몇 초였고, 실제 비용은 자료가 없어서 검색이 안 먹히는 시간이었다.
  • 오래된 스택은 자료 생태계까지 세트로 따라온다. 기술을 고를 때 "자료가 어느 쪽에 몰려 있나"가 성능 지표보다 실제 비용에 가깝다.

웃긴 건 2주차에 쓸 Spring Boot는 반대로 Gradle 자료가 많다는 거다. 같은 기준을 대면 답이 반대로 나온다.

더 봐야 할 것

  • 서블릿이 몇 개를 넘어가면 web.xml에 다 적는 게 부담이 되는지. 실무에선 서블릿 하나만 두고 그 안에서 갈라낸다는데, 그 전환점이 어디인지
  • 2주차에 Gradle을 처음 만나는데, 1주차에 Maven 쓴 게 걸림돌이 될지

사이트 내 검색

제목·태그·설명·본문으로 발행 글을 찾습니다