Spring Initializr 완전 분석(Spring Boot 프로젝트 생성 가이드)

누구나 다 아는 Spring Initializr를 무슨 완전 분석을 한다는 걸까?라고 의아해 하는 분들이 많이 계실 겁니다.

하지만 저는 Spring Boot Initializr로 처음 프로젝트를 만들 때 궁금한 점들이 몇 가지 있었습니다. 실무에서는 항상 만들어져 있는 프로젝트 안에서 작업을 해서 신경 쓸 일이 없었고, 공부할 때도 그냥 기본값 그대로인 상태에서 사용할 의존성만 추가하면 되기 때문에 그냥 넘어갔었죠.

제가 궁금하고, 신경 쓰였던 부분들은 크게 2가지였습니다. 첫 번째는 Gradle – Groovy와 Gradle – Kotlin의 차이가 신경 쓰였고, 두 번째는 Project Metadata의 각 항목이 정확히 어떤 역할을 하는지와 나중에 쉽게 바꿀 수 있는지였습니다.

그 2가지에 대해서만 글을 쓰기에는 분량이 너무 적으니 Spring Initializr의 모든 것들과 프로젝트 생성하면서 신경 써야 할 것들에 대해서도 같이 알아보겠습니다.

1. Project (프로젝트 빌드 툴 선택)

새로 시작하는 프로젝트는 거의 Gradle을 선택합니다. 일단 빌드 시간이 훨씬 빠릅니다. 그리고 요즘은 다들 Gradle을 많이 쓰기 때문에 최신 자료도 Gradle이 훨씬 많습니다. 특별한 이유가 없다면 Gradle을 선택하는 게 일반적입니다. Gradle 중에서도 Gradle – Groovy가 우리가 일반적으로 많이 봐왔던 Gradle입니다. 특별한 이유가 없다면 기본값대로 Gradle – Groovy를 선택하는 걸 추천합니다.

Gradle – Groovy와 Gradle – Kotlin의 차이는?

아래 내용을 보면 아시겠지만 일반적인 개발에서는 익숙한 Groovy에서 Kotlin으로 넘어갈 만한 이점이 없어 보입니다. Java가 아닌 Kotlin이 주 언어인 프로젝트라면 Gradle – Kotlin을 적극 검토해 보겠지만 Java가 주 언어이고, Kotlin이 익숙하지 않다면 굳이 Gradle – Kotlin을 할 이유는 없어 보입니다.

Gradle – Groovy

• 빌드 스크립트를 Groovy 언어로 작성
• 전통적으로 많이 사용되어 온 방식
• 간결한 표현이 가능하지만 오타나 존재하지 않는 기능으로 접근을 했을 때 실행하고 나서야 에러인지 알 수 있는 단점이 있음
• 사용자가 많기 때문에 관련 자료가 많음

Gradle – Kotlin

• 빌드 스크립트를 Kotlin 언어로 작성
• 비교적 새로운 방식
• Kotlin이 익숙하지 않다면 보기 어렵고, 빌드 스크립트 작성 시 자동완성이나 오류 검출 등이 강력함
• Gradle – Groovy보다는 사용자가 훨씬 적지만 점점 늘어나는 추세

2. Language (주 개발 언어 선택)

Java나 Kotlin 둘 중 주로 사용하는 언어를 선택하면 됩니다. 대부분은 Java일 거고, 요즘 Kotlin의 인기도 점점 높아지기 때문에 Kotlin을 선택하는 경우도 어느 정도 있을 것 같네요. Kotlin으로 Spring Boot를 활용해 개발하는 걸 요즘은 코프링이라고 하더라고요. Java는 자프링이라고 하고요.

Groovy는 너무 일반적이지 않기 때문에 그냥 넘어가겠습니다.

3. Spring Boot (스프링 부트 버전 선택)

숫자만 있는 버전 중 제일 높은 버전이 기본으로 선택되어 있습니다. 기본값 그대로 가는 게 꼭 답은 아닙니다. 자세한 이유는 아래 Dependencies에서 보면 됩니다. 목록에 없는 이전 버전을 꼭 사용해야 하는 경우라면 일단 만들고 나서 build.gradle이나 pom.xml에서 수정을 해야 하겠네요.

버전 뒤에 붙은 단어의 의미에 대해서 간략하게 알아보겠습니다.

• SNAPSHOT : 현재 개발 중인 불안정한 버전
• M(Milestone) : 정식 릴리즈 전 테스트 버전, 순서에 따라 M1, M2 등으로 표시됨
• RC(Release Candidate) : 정식 릴리즈 후보 버전
• GA(General Availability) : 정식 릴리즈 버전, 숫자만 있는 버전을 GA 버전이라고 부름

4. Project Metadata (프로젝트 메타데이터 입력)

제가 이 블로그 글을 쓴 이유가 바로 이 부분이 신경 쓰여서였습니다. 프로젝트 기본 정보를 입력하는 부분인데 각 항목이 정확히 무슨 역할을 하고, 어떤 부분에 영향을 미치는지가 궁금했습니다. 그리고 무엇보다 이걸 대충 입력하고 넘어갔는데 나중에 바꿔야 할 때 쉽게 바꿀 수 있는지가 너무 궁금했습니다. 공부할 때는 어떻게 해도 상관없겠지만 실전에서는 중요한 문제이니까요.

Group

여기에서 입력한 값이 새로 생성되는 프로젝트의 기본 패키지 구조에 영향을 미칩니다. 이 값을 입력하면 아래 Package name도 같이 변경되는 걸 볼 수 있습니다.

com.회사명으로 하기도 하고, org.조직명으로 하기도 합니다. 맨 앞의 com이나 org를 없애기도 하고, 완전히 다른 방식으로 하기도 합니다. 정해진 규칙이 있으면 따르면 되고, 정해진 게 없으면 일반적인 방법을 따르면 됩니다.

제일 중요한 건 나중에 쉽게 바꿀 수 있냐는 것인데…

일단 IntelliJ나 Eclipse에는 기본 패키지명을 쉽게 바꿀 수 있는 기능이 있습니다. 쉽게 바꿀 수는 있는데 프로젝트의 모든 java 파일의 import 문과 패키지 구조가 변경되는 것이기 때문에 아무래도 찝찝할 수 있습니다. 되도록 처음에 잘 정하고 가는 게 좋겠습니다. 혹시라도 나중에 변경을 해야 되는 상황이 생기더라도 IDE에서 제공하는 기능으로 쉽고 안전하게 변경하면 됩니다. 물론 build.gradle이나 pom.xml의 group 항목도 수정해 줘야 합니다.

만약 다른 프로젝트가 내 프로젝트를 라이브러리로 사용한다고 하면 그 부분도 확인을 해봐야 합니다. 멀티 모듈 프로젝트일 경우에도 이상이 없는지 확인해 봐야 합니다. 이런 경우에는 Group이 변경되면 더 심혈을 기울여서 확인해 봐야겠네요.

Artifact

프로젝트 빌드 결과물 파일(Jar나 War 파일)의 이름입니다. settings.gradle이나 pom.xml에서 관련 항목을 수정해 주면 됩니다. Jenkins 등으로 자동 배포 스크립트를 만들어놨거나 모니터링 툴 등이 빌드 결과물 파일을 참조하는 등의 경우에는 좀 귀찮아질 수도 있겠네요.

그리고 일반적으로 Artifact와 Name과 Package name의 제일 마지막은 동일한 값으로 가는 게 관행이므로 이 부분도 고려해야 합니다.

Artifact 이름도 초반에 신중하게 정하는 게 좋을 것 같습니다.

Name

이 프로젝트의 이름을 의미합니다. 메인 클래스 이름 앞에 이 Name 속성이 붙습니다. 프로젝트 이름이 demo라면 프로젝트 생성하면 생기는 메인 클래스 이름이 DemoApplication.java가 됩니다. 이것도 역시 수정하려면 build.gralde이나 pom.xml에서 관련 항목을 수정해야 합니다.

이 항목은 제가 알고 있는 기준에서는 나중에 변경돼도 별 영향이 없을 것으로 보입니다. 여기저기 뒤져봐도 별 내용이 안 나옵니다.

Description

이 프로젝트에 대한 설명입니다. 이건 당연히 바꿔도 영향 없겠죠?

제가 테스트해 본 바로는 gradle은 이 항목을 저장하지 않았고, maven만 pom.xml에 저장이 되었습니다. 이 항목이 꼭 필요하다면 gradle은 프로젝트가 생성된 후에 수동으로 다시 build.gradle에 추가해 줘야 합니다.

버전이 변경되면서 바뀔 수도 있겠지만 현재는 gradle은 Description에 뭔가를 입력해도 저장을 하지 않습니다.

Package name

위에서 설정한 Group + Artifact 값으로 자동 세팅됩니다. 이 값이 이 프로젝트의 기본 패키지가 됩니다. 기본 세팅 값을 무시하고, 완전히 다른 값으로 만들 수도 있지만 권장되지 않는 방법이니 그냥 바꿀 생각도 하지 않는 게 좋다고 생각합니다. 나중에 큰 문제가 될 수도 있어요.

Packaging

프로젝트 빌드를 하면 여기에서 선택한 값이 확장자가 되어 파일이 생성됩니다.

Jar는 내장 WAS가 포함되어 있어서 Jar 파일 하나만 실행하면 자동으로 프로젝트가 배포됩니다. 특별한 이유가 없으면 대부분 Jar를 사용합니다.

특정 WAS를 써야 한다거나 JSP로 개발된 프로젝트라면 War를 써야 합니다.

Jar를 추천하지만 War를 써야만 하는 경우가 있기도 하니 프로젝트 상황에 맞게 판단해야 합니다.

Java

여기에 나오는 Java 버전은 LTS(Long Term Support) 버전들이 나오고 있고, 기본값은 Spring에서 제일 권장하는 버전인 듯합니다.

회사에서 Java 버전을 정해 놓았다면 그걸 선택하면 되고, 목록에 없는 버전이라면 일단 프로젝트 생성한 후에 build.gradle이나 pom.xml에 가서 Java 버전을 바꿔야겠네요. 이 경우에는 Spring Boot 버전과 선택한 Java가 호환되는지도 확인해 봐야겠네요.

본인에게 선택권이 있다면 보이는 버전 중에 마음에 드는 걸 선택하면 될 것 같네요. 저라면 Spring에서 권장하는 기본값 그대로 갈 것 같습니다.

Dependencies

프로젝트에서 사용할 의존성 선택하는 건데 여기에서 선택해도 되고, 프로젝트 생성하고 나서 build.gradle이나 pom.xml에 직접 추가해도 됩니다.

여기에서 주의해서 봐야 할 점은 몇몇 라이브러리는 Requires Spring Boot >= 3.3.0 and <3.4.0_M1. 과 같은 문구가 표시되어 있다는 것입니다. Spring Boot 버전을 낮춰보면 저 문구가 사라지는 걸 볼 수 있습니다. 최신 버전에서는 아직 호환성이 검증되지 않았거나 뭔가 개발이 완료되지 않았을 경우 그렇다고 하네요.

프로젝트 생성하고, 직접 의존성을 추가해도 되겠지만 사용이 확정되어 있는 의존성들은 여기에서 최대한 추가하고 가야 나중에 Spring Boot 버전을 다운그레이드 하지 않을 수 있습니다.

화면 하단 버튼 (GENERATE, EXPLORE, …)

GENERATE

모든 설정이 완료되면 이 버튼을 클릭해야 생성된 프로젝트 압축파일을 다운로드할 수 있습니다.

EXPLORE

프로젝트 소스 파일들이 어떻게 생성될지 여기에서 미리 볼 수 있습니다. 설정값들을 변경하면 프로젝트 소스가 어떻게 변하는지 바로바로 확인해 볼 수 있습니다. 잘 사용하면 Spring Boot 프로젝트 생성에 대한 이해를 많이 높일 수 있는 중요한 기능입니다.

…

현재 설정된 값을 즐겨찾기 하거나 다른 사람에게 url로 공유할 수 있습니다.

기타 궁금한 점

Spring Initializer가 아니고, Spring Initializr인 이유는?

저는 한참을 Spring Initializer로 알고 있다가 얼마 전에 Spring Initializr라는 사실을 알았습니다. 왜 이름을 헷갈리게 만들었을까요? 조사해 보니 중간에 철자 하나씩 빼고 짓는 게 과거에 유행했던 작명 방법이었다네요.

Spring Initializr를 사용하지 않고, Spring Boot 프로젝트를 생성하는 경우도 많을까?

거의 없습니다. IntelliJ나 Eclipse에서 Spring Boot 프로젝트 생성을 지원하는데 이것도 Spring Initializr와 거의 동일합니다.

결론

프로젝트 생성하고, 개발만 하고 있었다면 Project Metadata를 바꾸는 건 별문제가 없다.

자동 배포가 세팅되었거나 다른 프로젝트에서 우리 프로젝트를 라이브러리로 사용하고 있거나 멀티 모듈 프로젝트라면 세심하게 신경 써서 변경하고, 확인해야 한다.

프로젝트 생성 단계에서 너무 깊은 고민하지 말고, 일단 기본값과 비슷하게 세팅해 놓고, 나중에 변경이 필요하면 변경하자. 하지만 그 변경은 최대한 개발 초반에 끝내자.

참고 사이트