Spring Boot 프로젝트 시작 시 생기는 모든 파일의 역할

Spring Initiailzr를 이용하며 Spring Boot를 다음 설정으로 시작했다.
- Gradle-Kotlin
- 4.0.5
- Group: me.junbyeol (프로젝트를 만드는 조직명을 반대로 쓴것 junbyeol.me <-> me.junbyeol)
- Artifact: main-server (프로젝트 명)
- Package name: 보통은 (Group) + (Artifact)의 형태로 자동 생성
- Jar, yaml, java 25
- Dependencies: Spring web, Spring Data JPA, Mysql driver, Spring Boot DevTools

그 결과 아래의 디렉토리 구조로 프로젝트가 생성 됐다. 각 파일들이 무엇을 의미하는지 정리한다. 그 전에, 코틀린과 JVM, 그리고 Gradle에 대해 간단히 정리한다.

 

코틀린과 JVM

코틀린(Kotlin)은 자바(Java)의 실행환경을 그대로 이용하면서도 자바의 문법적인 한계 등을 해결한 언어다.
NPE(Null Point Exception)로부터 앱을 보호하거나, 간결한 문법 및 함수형 프로그래밍의 개념을 적극 도입했다.

자바는 javac라는 컴파일러에 의해 자바 바이트코드(.class 파일)로 컴파일된다.
대신 kotlin은 kotlinc라는 컴파일러에 의해 자바 바이트코드(.class 파일)로 컴파일된다.
즉, 컴파일러만 다를 뿐 컴파일 결과물은 동일하기에, 동일하게 JVM(Java Virtual Machine)으로 실행 가능하다.

흥미로운 사실은, javac와 kotlinc는 컴파일러지만 이들도 각각 자바와 코틀린으로 작성된 후 바이트코드로 컴파일된 프로그램이라는 것이다. 그렇다면 최초의 자바 컴파일러는 어떻게 만든걸까? 자바 바이트코드로 직접 작성되었거나, C 언어로 작성된 컴파일러로 컴파일되었을 것이다. 후자가 정답이다. 그럼 최초의 C언어 컴파일러는 무엇으로 만들었을까? 또 다시 다른 언어(B 언어)의 컴파일러로 만들어졌다. 거슬러 올라가면, 정말 최초 최초의 컴파일러는 기계어로 사람이 작성했을 것이다!

참고로, JRE(Java Runtime Environment)라는 말은 자바를 실행할 수 있도록 JVM과 일부 라이브러리만을 포함한 단어다.
컴파일러를 포함하지 않으므로, 코드를 작성할수는 없고 실행만 할 수 있다.
코드를 작성하려면, JRE에 javac와 jdb(java debugger)가 포함된 JDK(Java Developer Kit)를 이용해야한다.
그렇다면 코틀린 코드를 작성하려면 kotlinc를 따로 내려받아야하는가?
그렇지 않다. kotlinc는 다음에 소개할 gradle이 알아서 내려받아주기 때문이다.

.jar 파일은 실행가능한 자바 바이트코드(.class)와 라이브러리를 압축해둔 파일이다.
압축을 해제하면 JVM이 실행할 수 있다.

Gradle

Gradle은 의존성 관리, 빌드, 스크립트 실행 등 우리의 spring 프로젝트를 실행하는데에 거의 모든것을 담당하는 녀석이다.
이 Gradle조차도 자바 바이트코드(.class 파일)로 컴파일되어 있기에, JVM을 통해서 실행된다.

Gradle의 경쟁자로는 Maven이 있다
Maven은 Gradle과 비슷한 역할을 하지만 결정적인 차이가 있다.
Gradle의 설정 파일은 코틀린을 이용하기에 코드 작성과 동일한 언어를 사용하여 간결하게 표현할 수 있지만, Maven은 XML을 사용하여 좀 더 번거롭다.
실행 속도면에서도, Gradle이 코드의 변경점만을 감지하여 더 빠르게 실행하기에 Gradle이 생태계에서 더 우위를 점하고 있는 것으로 보인다.

이제야 Spring의 모든 파일 이해하기!

Gradle-wrapper 관련 파일

- gradle/wrapper/gradle-wrapper.jar: Gradle을 다운받을 수 있는 자바 프로그램이다.
- gradle/wrapper/gradle-wrapper.properties: 위의 gradle-wrapper.jar가 내려받을 gradle의 버전이나 내려받을 저장소 등의 설정을 정의한다. 이 파일이 없었더라면, 다운받고 싶은 gradle의 버전을 바꾸고 싶을때마다 gradle-wrapper.jar 파일 자체를 매번 교체해야 했을 것이다.

- gradlew과 gradlew.bat: 실행 머신의 java 설치 여부 등을 체크하고, gradle-wrapper.jar를 실행하여 Gradle을 내려받은 후, 실행까지 하는 쉘 스크립트 파일이다. gradlew와 gradlew.bat의 차이는 실행하는 OS가 Mac/Linux(Unix계)냐 Window냐의 차이다. 즉, 직접 gradle-wrapper.jar를 개발자가 직접 실행해도 실질적인 동작은 같으나, 그 번거로운 과정을 gradlew가 추상화했다고 이해하면 된다.

- .gitattributes: gradlew와 gradlew.bat는 OS에 종속적인 파일이다. 그런데 Unix계와 Window는 파일에서 줄바꿈을 다루는 방식이 다르다. .gitattributes는 이 차이가 git의 파일 변화 추적에 쓸데없는 기록을 만들지 않도록 하는 역할을 한다. 또, .jar 파일은 바이너리니까 쓸데없는 줄바꿈을 하지 않도록 제어한다.

Gradle 관련 파일

- settings.gradle.kts: 처음 spring boot를 시작하면, rootProject의 이름을 정의할 뿐이다. 이 파일은 우리 프로젝트안에 서브 프로젝트(서브모듈)들이 추가되면 진가를 발휘하는 파일이니 일단 넘어간다.
- build.gradle.kts: 의존성을 관리하고 프로젝트 실행에 관한 정보를 기술한다. 앞서, Maven은 XML을 사용한다고 했는데 이 파일은 코틀린(.kts)으로 기술되어 있음을 확인하자. 파일 내용을 살펴보면, 여러개의 블록들로 관리되어 있는데, 주요 블럭은 다음과 같다.

plugins {}	빌드에 필요한 버전 정보와 플러그인들의 버전정보를 기술한다.
repositories {}	의존성을 내려받을 저장소를 기술한다.
dependencies {}	사용할 의존성들을 기술한다. - implementation: 항상 필요한 라이브러리 - developmentOnly: 개발 환경에서만 사용할 라이브러리(개발을 위한 편의 기능들) - runtimeOnly: 실행할때만 필요한 라이브러리(DB 드라이버 등) - testImplementation: 테스트 할때만 필요한 라이브러리

 

애플리케이션 파일

src/main/kotlin: 본격적으로 우리가 작성하게 애플레케이션 코드가 있는 곳. xxxApplication.kt가 실행 시 진입점이 된다.
src/main/resources: 쉽게 말하자면 코틀린 파일이 아닌데, 서비스에 필요한 이미지, yaml/json, html/css 등 모든것이 들어가는 곳. 여기 있으면 컴파일러가 이 파일들은 건드리지 않고 그대로 jar에 담는다.
src/test: 프로젝트의 테스트 코드들을 작성하는 곳