Gradle 설치 후 gradle init 프로젝트 초기화 경험 – 기본 템플릿의 한계

이번 포스트에서는 Gradle 설치 후 gradle -v 명령어로 버전을 확인하고, gradle init 명령어를 사용하여 프로젝트를 초기화한 경험을 공유하려고 합니다.
예전에는 build.gradle 파일부터 직접 작성하여 프로젝트를 구성했는데, 기본 템플릿 방식인 gradle init으로 생성된 프로젝트 구조와 패키지 명이 제 기대와는 달라 고민했던 사례를 중심으로 이야기를 진행합니다.

2. Gradle 설치 및 환경 변수 설정

먼저, Windows 환경에서 Gradle을 설치하고 환경 변수를 설정했습니다.

• 설치 확인: 터미널에서 gradle -v를 실행하여 정상 동작하는지 확인
• VS Code 적용: VS Code 터미널에서도 환경 변수가 반영되도록 재시작 및 설정 확인

https://bong-day.tistory.com/17

3. gradle init을 통한 프로젝트 초기화

프로젝트 초기화를 위해 터미널에서 다음 명령어를 실행했습니다.

gradle init

 

그리고 여러 옵션들을 선택했습니다:

• 빌드 스크립트 DSL: Kotlin DSL
•  

Groovy DSL : Gradle의 전통적인 기본 DSL입니다.
많은 예제와 자료들이 Groovy DSL 기반으로 작성되어 있어 참고하기 편리합니다.
자바 프로젝트에서는 널리 사용되는 선택입니다.

Kotlin DSL : 
최근에 인기를 끌고 있으며, 정적 타입 체크와 향상된 IDE 지원을 제공합니다.
Kotlin에 익숙하다면 더욱 편리하게 느낄 수 있습니다.
다만, 문법이나 예제가 Groovy DSL보다 적을 수 있습니다.

 

• 테스트 프레임워크: JUnit Jupiter (JUnit 5)

JUnit 4: 오랫동안 사용되어 온 전통적인 테스트 프레임워크입니다. 기존 프로젝트나 호환성이 필요한 경우 선택할 수 있습니다.
TestNG: JUnit과 유사하지만, 더 유연한 어노테이션과 기능을 제공하여 복잡한 테스트 시나리오에 적합합니다.
Spock: Groovy 기반의 BDD 스타일 테스트 프레임워크로, 자바와도 사용할 수 있으나 주로 Groovy 프로젝트에서 인기가 높습니다.
JUnit Jupiter (JUnit 5): 최신 JUnit 버전으로, 모듈화, 확장성, 개선된 기능 및 깔끔한 문법을 제공합니다.

• 프로젝트 이름: "first-prj" 입력
• 애플리케이션 구조: Single application project 선택

 

하지만 실제 생성된 결과는,

• 애플리케이션 소스: 실제 코드는 app이라는 서브 디렉터리 안에 생성됨

이러한 기본 템플릿은 빠른 스캐폴딩에는 유용하지만, 원하는 디렉토리 구조나 패키지 명을 얻기에는 한계가 있었습니다.

4. 기본 템플릿의 한계와 대안

기본 템플릿(gradle init) 방식은 A의 경우, 즉 간단한 테스트나 학습용 프로젝트에는 적절할 수 있습니다.
그러나 실제 업무 프로젝트나 디렉토리, 패키지 명을 세밀하게 관리해야 하는 경우에는 다음과 같은 대안이 필요합니다.

• Spring Initializr 사용: Spring Boot 프로젝트의 경우, Spring Initializr를 이용하면 보다 세밀하게 원하는 설정을 적용할 수 있습니다.
• 직접 build.gradle 파일 작성: 예전처럼 build.gradle부터 직접 작성하여 프로젝트 구조를 원하는 대로 구성하는 방법도 고려해볼 수 있습니다.
• IDE 리팩토링 활용: VS Code나 IntelliJ IDEA의 리팩토링 기능을 사용해 프로젝트 생성 후 구조를 수정하는 방법도 있습니다.

결국, 각 프로젝트의 요구사항에 따라 도구와 방법을 유연하게 선택하는 것이 중요하네요.

5. 결론

gradle init 명령어는 빠른 초기 스캐폴딩 도구로는 유용하지만, 제가 원하는 세밀한 디렉토리 구조나 패키지 명을 얻기에는 한계가 있음을 경험했습니다.
조금 더 확정성을 고려한 프로젝트 구조를 구성할 계획입니다.