29장. Gradle과 Kotlin 프로젝트

지금까지는 작은 코드 조각을 실행해 봤습니다.
하지만 실제 프로젝트는 파일이 수십, 수백 개입니다.

이런 프로젝트를 어떻게 조립하고,
필요한 라이브러리를 어떻게 가져올까요?

이 일을 해 주는 것이 빌드 도구(build tool)입니다.
코틀린 백엔드에서는 주로 Gradle을 씁니다.

이 장은 문법을 외우는 장이 아닙니다.
build.gradle.kts 파일을 열었을 때
“무슨 말인지 읽을 수 있게” 만드는 것이 목표입니다.

29.1 Gradle이 필요한 이유

프로그램 하나를 만들려면
여러 단계를 거쳐야 합니다.

• 필요한 라이브러리 내려받기
• 소스 코드 컴파일하기
• 테스트 실행하기
• 실행 가능한 결과물로 묶기

이걸 매번 손으로 하면 너무 번거롭습니다.

빌드 도구는 이 과정을 자동으로 처리합니다.

비유하자면 이렇습니다.

Gradle은 부품을 모아
자동으로 조립해 주는 공장입니다.
우리는 “설계도“만 적어 주면 됩니다.

그 설계도가 바로 build.gradle.kts입니다.

29.2 Gradle Wrapper

프로젝트를 받으면
gradlew라는 파일이 들어 있습니다.
이것을 Gradle Wrapper라고 합니다.

Wrapper는
“이 프로젝트에 맞는 Gradle 버전“을
자동으로 내려받아 실행해 줍니다.

./gradlew build     # 맥/리눅스
gradlew.bat build   # 윈도우

덕분에 Gradle을 따로 설치하지 않아도,
누구나 같은 버전으로 빌드할 수 있습니다.

팀원마다 Gradle 버전이 달라 생기는 문제를
Wrapper가 막아 줍니다.

29.3 build.gradle.kts

build.gradle.kts는 프로젝트의 설계도입니다.

확장자 .kts는 “코틀린 스크립트“라는 뜻입니다.
즉, 이 설정 파일도 코틀린 문법으로 씁니다.
(이것을 Kotlin DSL이라고 부릅니다.)

전형적인 파일은 이렇게 생겼습니다.

plugins {
    kotlin("jvm") version "2.0.0"
}

group = "com.example"
version = "1.0.0"

repositories {
    mavenCentral()
}

dependencies {
    testImplementation(kotlin("test"))
}

이제 각 블록을 하나씩 읽어 봅시다.

29.4 Plugin

plugins 블록은
“이 프로젝트에 어떤 기능을 더할지” 정합니다.

plugins {
    kotlin("jvm") version "2.0.0"
}

kotlin("jvm")은
“코틀린을 JVM용으로 빌드하는 기능“을 켭니다.

플러그인은
“Gradle에 끼우는 확장 부품“이라고 보면 됩니다.
스프링을 쓸 때는 스프링 플러그인을 여기에 추가합니다.

29.5 Repository

repositories 블록은
“라이브러리를 어디서 가져올지” 정합니다.

repositories {
    mavenCentral()
}

mavenCentral()은
전 세계 개발자가 쓰는 대형 라이브러리 저장소입니다.

Gradle은 여기서
필요한 라이브러리를 자동으로 내려받습니다.

29.6 Dependency

dependencies 블록은
“어떤 라이브러리가 필요한지” 적습니다.

dependencies {
    implementation("com.google.code.gson:gson:2.11.0")
    testImplementation(kotlin("test"))
}

의존성(dependency)이란
“내 코드가 기대어 쓰는 다른 라이브러리“입니다.

앞에 붙는 키워드가 용도를 정합니다.

29.7 Configuration

방금 본 implementation, testImplementation을
설정(Configuration)이라고 부릅니다.

이는 “이 라이브러리를 어떤 범위에서 쓸 것인가“를
나누는 이름표입니다.

예를 들어 테스트에만 필요한 라이브러리를
testImplementation으로 두면,
실제 배포 결과물에는 포함되지 않습니다.

덕분에 결과물이 불필요하게 무거워지지 않습니다.

29.8 Task

Gradle이 실제로 수행하는
하나하나의 작업을 태스크(Task)라고 합니다.

./gradlew build    # 전체 빌드
./gradlew test     # 테스트 실행
./gradlew clean    # 이전 결과물 삭제

build, test, clean이 모두 태스크입니다.

플러그인을 추가하면
그에 맞는 태스크도 함께 늘어납니다.

29.9 Kotlin DSL 읽기

build.gradle.kts가 처음엔 낯설지만,
사실 우리가 배운 코틀린 문법 그대로입니다.

dependencies {
    implementation("라이브러리 좌표")
}

이것은 사실
dependencies라는 함수에
람다를 넘기는 코드입니다. (14장 참고)

그 람다 안에서
implementation(...)이라는 함수를 부르는 것이고요.

그래서 코틀린을 알면
Gradle 설정도 “읽을 수 있는 코드“가 됩니다.

29.10 프로젝트 디렉터리 구조

마지막으로 표준 폴더 구조를 봅시다.

my-project
├─ build.gradle.kts      설계도
├─ settings.gradle.kts   프로젝트 이름 등
├─ gradlew               Wrapper 실행 파일
└─ src
   ├─ main
   │  └─ kotlin          실제 코드
   └─ test
      └─ kotlin          테스트 코드

핵심은 두 가지입니다.

• 실제 코드는 src/main/kotlin에
• 테스트 코드는 src/test/kotlin에

이 구조는 거의 모든 코틀린/자바 프로젝트에서
동일하게 쓰입니다.

29장을 마치며

이 장에서 우리는 다음을 배웠습니다.

• Gradle이 빌드 과정을 자동화해 준다는 점
• Wrapper 덕분에 누구나 같은 버전으로 빌드한다는 점
• build.gradle.kts의 plugins, repositories, dependencies 블록
• 의존성과 Configuration으로 라이브러리 범위를 나누는 법
• 표준 디렉터리 구조(src/main/kotlin, src/test/kotlin)

이제 프로젝트를 만들 수 있으니,
다음 장에서는 코드를 테스트하는 법을 배웁니다.