Maven vs Gradle 선택 기준: web.xml과 pom.xml은 XML만 같았다
web.xml과 pom.xml은 확장자만 같고 읽는 주체가 다르다. Gradle과 web.xml도 같이 쓴다. Maven과 Gradle 중 무엇을 고를지, 속도보다 중요했던 판단 기준.
목차
프론트만 하다가 백엔드를 배우려고 JSP/Servlet 게시판을 만들기로 했다. 코드를 짜기 전에 두 가지를 정해야 했다.
- 서블릿을 어떻게 등록할까 —
web.xml이냐 애노테이션이냐 - 빌드 도구는 Maven이냐 Gradle이냐
둘 다 첫날부터 헛발을 짚었다.
확장자가 같으면 한 세트인 줄 알았다
web.xml을 쓰기로 정하고 나서 이렇게 생각했다.
"그럼 Gradle은 못 쓰는 거 아냐? XML은 Maven인 것 같은데"
아무 관계가 없었다. 두 파일은 읽는 사람이 다르다.
| 파일 | 누가 읽나 |
|---|---|
web.xml | 톰캣 |
pom.xml | Maven |
build.gradle | Gradle (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 쓴 게 걸림돌이 될지