[BOOK_P] 프로젝트 생성
자바 버전 선택
일단 자바 버전을 선택하기 위해 대략적으로만 알고있던 각 버전을 조금 깊게 찾아보았습니다.
이중 LTS는 Long Term Support. 말그대로 오랜 기간 지원되는 버전이기에 LTS버전 중 선택하게 되었습니다.
그 중에서도 버전 8, 11, 17버전은 유독 긴 기간 지원되는 것을 알 수 있었는데, 가장 최근 버전의 LTS는 21이나 Java21 사용시 외장톰캣을 사용하면 아직 불안정하게 작동하는 부분이 있다고하여 향후 CI/CD 구축해야 하는 단계를 고려해 보수적으로 선택지에서 제외했습니다.
통계적으로 최근 Java17의 사용량이 상당히 늘어나고 있기도 하고, String에서 다중라인을 사용할때 텍스트 블록 기능을 사용할 수 있게 되었으며, 프로젝트 시 Date 타입을 많이 접하게 되는데 NumberFormat와 DateTimeFormatter 의 기능이 향상되었다고 해 프로젝트 구현하며 사용해보고 싶어 17버전을 선택하게 되었습니다.
Spring Boot 3 프레임워크 선택
- EJB vs Spring
- EJB는 단위 테스트가 어렵다. 테스트를 할때마다 컨테이너 배포를 해야하는데 스프링은 의존성 주입이 도입되어 단위 테스트를 하기위해 전체 프로젝트를 구동하지 않아도 된다.
- 초기 서블릿 공부를 할때 느꼈지만 EJB는 쿼리문 하나를 작동하기 위해 부수적인 많은 구문을 작성해야 한다. 하지만 스프링은 JDBC를 위해 훨씬 간결하게 작업을 할 수 있다.
- EJB는 배포가 어렵고 예외처리를 함에 있어서 개발자의 입장에서 번거로운 면이 많으나 스프링을 통해 쉽게 해결할 수 있다.
따라 스프링 프레임워크를 선택하였으며, Spring과 Spring Boot 중에서 선택을 진행하게 되었습니다.
- EJB는 단위 테스트가 어렵다. 테스트를 할때마다 컨테이너 배포를 해야하는데 스프링은 의존성 주입이 도입되어 단위 테스트를 하기위해 전체 프로젝트를 구동하지 않아도 된다.
- Spring vs Spring Boot
- 가장 큰 부분은 AutoConfiguration인데, 스프링부트 메인 클래스에 있는 @SpringBootApplication를 보면 @ComponentScan, @EnableAutoConfiguration 등이 속해 있다. 컴포넌트 또는 컨트롤러,리포지토리 등 어노테이션이 붙은 객체를 자동으로 빈에 등록하고, 또 프로젝트 셋팅시 사전정의한 라이브러리들을 조건에 따라 등록해준다.
- 스프링 사용시에는 war 파일을 수동으로 웹서버에 담아 배포했었는데 스프링부트는 내장서버를 가지고 있기에 더욱 간편하게 배포할 수 있다.
- configuration 설정 시 스프링은 모든 어노테이션과 Bean 설정을 해주어야 하지만 스프링부트에서는 properties 또는 yml 파일을 통해 설정해줄수 있다.
이에 최종적으로 Spring Boot를 선택하였으며, java17을 사용하는만큼 프레임워크 역시 최대한 최신기능을 사용하고 싶어 java17 이상을 필수로 지원하도록 업데이트 된 Spring Boot 3을 택했습니다. 정확히는 3.2.1를 사용합니다
- 가장 큰 부분은 AutoConfiguration인데, 스프링부트 메인 클래스에 있는 @SpringBootApplication를 보면 @ComponentScan, @EnableAutoConfiguration 등이 속해 있다. 컴포넌트 또는 컨트롤러,리포지토리 등 어노테이션이 붙은 객체를 자동으로 빈에 등록하고, 또 프로젝트 셋팅시 사전정의한 라이브러리들을 조건에 따라 등록해준다.
빌드 관리 도구 선택
최대한 최신 기능을 사용하고 싶다고 했기에 처음에는 Gradle를 우선순위로 두었습니다. 우선 속도 면에서도 Maven에 비해 Gradle이 우세하고, 가독성이 좋으며, 버전을 관리하기에도 훨씬 편하기 때문입니다. 특히 gradle은 캐시를 사용하기에 테스트를 반복하는 경우 더욱 실행차이가 커질 것이라 생각했습니다.
그럼에도 Maven을 제가 선택한 명확한 한가지 이유가 있었습니다. 회사에서 Gradle과 Maven을 각각 빌드도구로 선택했던 프로젝트를 경험해보았고 Gradle은 위와같은 장점으로 쉽게 익히는 것이 가능했습니다. 다만 Maven은 버전이 꼬이거나 설정하는데서 오류가 발생해 애를 먹었던 적이 있었습니다.
회사 프로젝트는 다른사람과 협업을 하기 때문에 위험을 감수하면서 이것저것 만져보는 것이 불가능했는데 혼자 프로젝트를 해보는 지금은 각종 어려움에 부딪혀보고 익힐수있는 기회가 될 것이라 생각했고 지금 저에게 더 필요한 Maven을 선택했습니다.
빌드 방식은 향후에도 변경이 가능한 부분이기에 위와 같은 결정이 가능했으며, 만약 프로젝트 완료 후 지속적으로 배포관리를 하게 된다면 마이그레이션 해보는 방안도 고려하고 있습니다.