Gradle 프로젝트 Lombok 컴파일 오류부터 IDE 문제까지 해결법 ~ Dev.

자바(Java) 개발 생태계에서 'Lombok'은 반복적인 코드(Boilerplate Code)를 획기적으로 줄여주는 필수 라이브러리로 자리매김했습니다. 생성자, Getter, Setter, `toString()` 등의 메서드를 단 하나의 애너테이션으로 자동 생성해주니, 개발자는 비즈니스 로직에 더 집중할 수 있고 코드 가독성은 비약적으로 향상됩니다. 하지만 이 강력한 편의성 뒤에는 복잡한 동작 원리가 숨어 있으며, 이로 인해 Gradle 기반 프로젝트에서 Lombok을 처음 연동할 때 많은 개발자들이 예상치 못한 컴파일 오류와 IDE의 비정상적인 동작에 부딪히게 됩니다.

`cannot find symbol` 오류가 콘솔을 가득 채우거나, IDE에서 분명히 존재해야 할 메서드를 인식하지 못해 빨간 줄이 그어지는 경험은 개발 의욕을 꺾는 주범 중 하나입니다. 이 문제는 단순히 의존성 하나를 `build.gradle` 파일에 추가하는 것만으로 해결되지 않습니다. Lombok은 빌드 도구(Gradle), 컴파일러(javac), 그리고 통합 개발 환경(IDE)이라는 세 가지 요소가 완벽한 삼각편대를 이루어야만 정상적으로 작동하기 때문입니다.

이 글에서는 Lombok이 왜 그토록 많은 설정 문제를 야기하는지에 대한 근본적인 원인을 파헤치고, Gradle 프로젝트에서 Lombok을 '올바르게' 설정하는 방법부터 IntelliJ IDEA와 Eclipse(STS) 환경에서 발생하는 구체적인 문제 해결 전략까지, A부터 Z까지 심도 있게 다룹니다. 단순히 "이렇게 하세요" 식의 나열이 아닌, '왜' 그렇게 해야 하는지에 대한 깊이 있는 이해를 통해 어떤 상황에서도 유연하게 대처할 수 있는 능력을 기르는 것을 목표로 합니다.

1. 모든 문제의 근원: Lombok의 두 얼굴, 애너테이션 프로세싱

Lombok 연동 실패의 원인을 이해하려면, 먼저 Lombok이 어떻게 마법처럼 코드를 생성하는지 알아야 합니다. Lombok은 자바의 애너테이션 프로세싱(Annotation Processing) 기술을 기반으로 동작합니다.

애너테이션 프로세싱은 자바 컴파일러(javac)가 소스 코드를 바이트 코드로 변환하는 과정 중간에 개입하여, 특정 애너테이션이 붙은 코드를 분석하고 새로운 소스 코드를 생성하거나 기존 코드를 수정할 수 있게 해주는 강력한 기능입니다. 즉, 우리가 `@Getter`, `@Setter`, `@NoArgsConstructor`와 같은 애너테이션을 클래스에 붙이면, 컴파일 시점에 Lombok의 애너테이션 프로세서가 이를 인지하고 실제 `getXXX()`, `setXXX()`, `public User() {}` 와 같은 자바 코드를 생성하여 컴파일 과정에 슬쩍 끼워 넣는 것입니다.

바로 이 지점에서 문제가 발생합니다. 개발 과정을 크게 두 단계로 나누어 볼 수 있습니다.

컴파일 및 빌드 단계: Gradle과 같은 빌드 도구가 `javac`를 실행하여 프로젝트 전체를 컴파일하고 `.class` 파일들을 생성하여 `jar` 또는 `war` 파일로 패키징하는 단계입니다.
코딩(IDE) 단계: IntelliJ IDEA나 Eclipse(STS) 같은 IDE가 자체적인 컴파일러와 인덱싱 기능을 통해 실시간으로 코드의 유효성을 검사하고, 자동 완성, 메서드 탐색 등의 기능을 제공하는 단계입니다.

대부분의 라이브러리는 런타임에 클래스가 로드되어 사용되지만, Lombok은 컴파일 타임에만 필요합니다. 생성된 코드는 이미 `.class` 파일에 포함되어 있기 때문에, 애플리케이션이 실행되는 시점(런타임)에는 Lombok 라이브러리 자체가 필요하지 않습니다. 또한, IDE는 Gradle의 빌드 과정과는 별개로 동작하기 때문에, IDE 역시 Lombok이 코드를 생성했다는 사실을 인지하고 있어야만 우리가 코딩하는 동안 오류를 표시하지 않습니다.

핵심 요약: Lombok 연동 문제는 '빌드 도구(Gradle)'와 'IDE', 이 두 곳에 각각 "이제부터 애너테이션 프로세싱을 사용할 것이니, Lombok을 활용해서 소스 코드를 제대로 읽고 처리해줘!" 라고 명확하게 알려주지 않았기 때문에 발생합니다.

이제 이 두 가지 축을 중심으로 올바른 설정 방법을 살펴보겠습니다.

2. 첫 번째 관문: build.gradle 완벽 설정 가이드

모든 설정의 시작은 빌드 스크립트인 `build.gradle` (또는 Kotlin DSL의 경우 `build.gradle.kts`) 파일입니다. Lombok을 Gradle 프로젝트에서 사용하기 위해서는 최소 두 가지 의존성 설정이 필요합니다.

2.1. `compileOnly` vs `annotationProcessor` - 역할의 명확한 구분

Gradle 4.6 이전 버전에서는 `provided` 스코프와 `apt` 같은 플러그인을 사용했지만, 현재는 네이티브하게 지원되는 `compileOnly`와 `annotationProcessor`를 사용하는 것이 표준입니다. 이 둘의 차이를 이해하는 것이 매우 중요합니다.

compileOnly: 이름 그대로 '오직 컴파일 시점에만 필요한' 의존성을 의미합니다. 소스 코드에서 `@Getter`와 같은 Lombok 애너테이션을 사용하려면 컴파일러가 해당 애너테이션의 존재를 알아야 합니다. 따라서 `compileOnly` 스코프에 Lombok을 추가하여 컴파일러에게 애너테이션 정보를 제공합니다. 이렇게 설정된 라이브러리는 컴파일 클래스패스에만 포함되고, 최종 빌드 결과물(JAR, WAR)에는 포함되지 않습니다. 이는 Lombok의 특성과 완벽하게 부합합니다.
annotationProcessor: 애너테이션 프로세서 자체를 지정하는 스코프입니다. `javac`에게 "이 경로에 있는 애너테이션 프로세서(`lombok.jar` 안에 있는 `AnnotationProcessor` 구현체)를 사용해서 코드를 처리해라"고 지시하는 역할을 합니다. 즉, 실제 코드 생성 작업을 수행할 주체를 명시하는 것입니다.

과거에는 `compile`이나 `implementation` 스코프에 Lombok을 포함시키는 경우가 많았으나, 이는 불필요하게 런타임 라이브러리에 Lombok을 포함시켜 패키징 크기를 늘리고 잠재적인 충돌을 야기할 수 있는 잘못된 방식입니다.

2.2. 표준 `build.gradle` (Groovy DSL) 설정 예시

다음은 Spring Boot 3.x 버전을 기준으로 한 가장 표준적인 `build.gradle` 설정입니다. Spring Boot를 사용하지 않는 순수 Gradle 프로젝트에서도 동일하게 적용할 수 있습니다.


plugins {
    id 'java'
    id 'org.springframework.boot' version '3.2.5' // 예시 버전
    id 'io.spring.dependency-management' version '1.1.4'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
    sourceCompatibility = '17'
}

// Lombok 설정을 위한 전용 configuration 블록 (권장)
configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    // Spring Boot Starter
    implementation 'org.springframework.boot:spring-boot-starter-web'
    // ... 기타 의존성들

    // --- Lombok 설정의 핵심 ---
    // 1. 컴파일 시점에만 Lombok 애너테이션 API를 사용
    compileOnly 'org.projectlombok:lombok'
    
    // 2. 애너테이션 프로세서로 Lombok을 지정
    annotationProcessor 'org.projectlombok:lombok'

    // Spring Boot Configuration Processor (선택 사항, 그러나 권장)
    // @ConfigurationProperties를 사용할 경우 필요
    annotationProcessor 'org.springframework.boot:spring-boot-configuration-processor'
    
    // 테스트 코드에서도 Lombok을 사용하기 위한 설정
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testCompileOnly 'org.projectlombok:lombok'
    testAnnotationProcessor 'org.projectlombok:lombok'
}

tasks.named('test') {
    useJUnitPlatform()
}

💡 `configurations` 블록은 왜 필요한가?

위 예제의 `configurations` 블록은 `compileOnly`가 `annotationProcessor`를 상속하도록 설정합니다. 이는 `dependencies` 블록에서 Lombok 의존성을 두 번 선언하는 대신, 아래와 같이 한 번만 선언할 수 있게 해주는 편의 설정입니다.
// configurations 블록을 사용했을 경우
dependencies {
    // ...
    compileOnly 'org.projectlombok:lombok'
    // annotationProcessor 'org.projectlombok:lombok' 는 자동으로 포함됨
    // ...
}
    
하지만 코드의 명확성을 위해 두 스코프에 각각 명시적으로 선언하는 방식을 더 선호하는 개발자도 많습니다. 어느 쪽을 선택하든 기능상의 차이는 없습니다. 이 글에서는 명시성을 위해 두 번 선언하는 방식을 기준으로 설명합니다.

2.3. Kotlin DSL (`build.gradle.kts`) 설정 예시

Kotlin DSL을 사용하는 프로젝트의 경우 문법만 다를 뿐, 원리는 동일합니다.


import org.springframework.boot.gradle.plugin.SpringBootPlugin

plugins {
    id("java")
    id("org.springframework.boot") version "3.2.5"
    id("io.spring.dependency-management") version "1.1.4"
}

group = "com.example"
version = "0.0.1-SNAPSHOT"

java {
    sourceCompatibility = JavaVersion.VERSION_17
}

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    
    // --- Lombok 설정 ---
    compileOnly("org.projectlombok:lombok")
    annotationProcessor("org.projectlombok:lombok")

    // 테스트 코드용 Lombok
    testCompileOnly("org.projectlombok:lombok")
    testAnnotationProcessor("org.projectlombok:lombok")
    
    // 기타 의존성
    testImplementation("org.springframework.boot:spring-boot-starter-test")
}

tasks.withType<Test> {
    useJUnitPlatform()
}

이처럼 `build.gradle` 파일에 정확한 스코프로 Lombok 의존성을 추가했다면, 이제 Gradle은 빌드 시점에 Lombok을 올바르게 사용하여 코드를 생성할 준비를 마친 것입니다. 하지만 이것만으로는 충분하지 않습니다. 이제 두 번째 관문인 IDE 설정을 통과해야 합니다.

3. 두 번째 관문: IDE와의 완벽한 동기화

Gradle 빌드가 성공하더라도 IDE에서 `cannot find symbol` 오류가 발생한다면, 이는 IDE가 Lombok이 생성한 코드를 인지하지 못하고 있다는 명백한 증거입니다. 각 IDE 별로 해결 전략을 자세히 알아봅시다.

3.1. IntelliJ IDEA: 가장 흔한 함정과 해결책

IntelliJ는 현대적인 자바 개발 환경에서 가장 널리 사용되는 IDE이며, Lombok 지원 기능이 매우 강력하지만 몇 가지 핵심 설정을 놓치기 쉽습니다.

3.1.1. 필수 조건 1: Lombok 플러그인 설치 및 활성화

IntelliJ는 Lombok을 기본적으로 지원하지 않습니다. 반드시 Lombok 플러그인을 설치해야 합니다.

File > Settings (Windows/Linux) 또는 IntelliJ IDEA > Preferences (macOS)로 이동합니다.
왼쪽 메뉴에서 Plugins를 선택합니다.
Marketplace 탭에서 "Lombok"을 검색하여 설치합니다.
설치 후 IDE를 재시작하라는 메시지가 나타나면 반드시 재시작합니다.

플러그인이 이미 설치되어 있다면, 비활성화(disabled) 상태는 아닌지 확인해야 합니다. Installed 탭에서 Lombok을 찾아 체크박스가 선택되어 있는지 확인하세요.

3.1.2. 필수 조건 2: 애너테이션 프로세서 활성화 (Annotation Processing Enable)

이것이 IntelliJ 사용자들이 가장 많이 놓치는 설정입니다. 플러그인을 설치하는 것만으로는 충분하지 않으며, IntelliJ가 Gradle 프로젝트를 임포트할 때 애너테이션 프로세싱을 사용하도록 명시적으로 설정해주어야 합니다.

File > Settings (or Preferences)로 이동합니다.
Build, Execution, Deployment > Compiler > Annotation Processors로 이동합니다.
오른쪽 패널에서 Enable annotation processing 체크박스를 반드시 클릭하여 활성화합니다.
그 아래 `Store generated sources relative to` 옵션은 `Module content root`로 두는 것이 일반적입니다.

이 설정은 IntelliJ에게 "이 프로젝트를 컴파일하거나 분석할 때, `annotationProcessor` 스코프에 명시된 라이브러리들을 사용하여 코드를 동적으로 생성하고, 그 생성된 코드를 소스 코드의 일부로 인식하라"고 지시하는 것과 같습니다. 이 설정이 꺼져 있으면, IntelliJ는 `build.gradle` 파일을 읽어 Lombok 의존성을 인지하더라도, 실제로 코드 생성 작업을 수행하지 않기 때문에 `@Getter`가 붙은 클래스의 `getXxx()` 메서드를 찾지 못하는 것입니다.

IntelliJ Annotation Processors 설정 화면

3.1.3. 문제 해결을 위한 추가 조치

위의 두 가지 필수 설정을 완료했는데도 문제가 지속된다면, 다음 단계를 시도해 보세요.

Gradle 프로젝트 새로고침(Reload): `build.gradle` 파일을 수정한 후에는 반드시 IntelliJ가 변경사항을 인지하도록 프로젝트를 새로고침해야 합니다. Gradle 도구 창(보통 IDE 우측에 위치)에서 'Reload All Gradle Projects' 버튼을 클릭합니다.
캐시 무효화 및 재시작 (Invalidate Caches / Restart): IntelliJ의 캐시가 꼬여서 발생하는 문제일 수 있습니다. `File` > `Invalidate Caches...`를 선택하고, 나타나는 대화상자에서 `Invalidate and Restart` 버튼을 클릭하여 캐시를 전부 지우고 IDE를 재시작합니다. 이는 많은 IDE 문제의 만병통치약과 같은 역할을 합니다.
프로젝트 재빌드: `Build` > `Rebuild Project` 메뉴를 실행하여 프로젝트 전체를 처음부터 다시 빌드합니다.

3.2. Eclipse / Spring Tool Suite (STS): 전통과 현대의 혼재

Eclipse 및 그 파생 IDE인 STS는 IntelliJ와는 다른 방식으로 Lombok을 처리하며, 때로는 더 까다로울 수 있습니다.

3.2.1. 현대적인 접근: Buildship 플러그인과 자동 설정

최신 버전의 Eclipse/STS는 Gradle 통합 플러그인인 'Buildship'을 통해 `build.gradle`의 `annotationProcessor` 설정을 자동으로 인식하고 처리하는 기능이 개선되었습니다. 따라서 이상적인 시나리오는 다음과 같습니다.

`build.gradle` 파일에 위에서 설명한 대로 `compileOnly`와 `annotationProcessor`를 정확하게 설정합니다.
프로젝트 탐색기(Package Explorer)에서 프로젝트를 우클릭합니다.
Gradle > Refresh Gradle Project 메뉴를 실행합니다.
이 과정에서 Buildship이 애너테이션 프로세싱 설정을 인지하고, Eclipse의 `.factorypath` 파일을 자동으로 구성해줍니다.
프로젝트 우클릭 > Properties > Java Compiler > Annotation Processing 메뉴에 진입하여 Lombok이 정상적으로 활성화되었는지 확인할 수 있습니다.
IDE를 재시작하여 변경사항을 완전히 적용합니다.

대부분의 경우, 이 방법으로 문제가 해결되어야 합니다.

3.2.2. 고전적이지만 확실한 방법: Lombok.jar 실행 및 설치

만약 위의 방법으로 해결되지 않거나 구버전의 Eclipse를 사용하는 경우, Lombok을 Eclipse 자체에 '설치'하는 전통적인 방법을 사용해야 합니다. 이 방법은 Lombok이 IDE의 설정 파일(`eclipse.ini`)을 직접 수정하여, Eclipse가 시작될 때부터 Lombok 애너테이션 프로세서를 자바 에이전트(java agent)로 로드하도록 만드는 것입니다.

먼저 Gradle 캐시에서 `lombok.jar` 파일의 위치를 찾아야 합니다. 보통 사용자 홈 디렉토리 아래의 `.gradle/caches/modules-2/files-2.1/org.projectlombok/lombok/...` 경로에 존재합니다. 정확한 위치를 찾기 어렵다면, 터미널이나 CMD에서 프로젝트 루트 디렉토리로 이동한 뒤 다음 명령어를 실행하여 의존성의 실제 파일 경로를 확인할 수 있습니다.
```
# Windows
gradlew dependencies | findstr lombok

# macOS/Linux
./gradlew dependencies | grep lombok
        
```
찾은 `lombok-{version}.jar` 파일을 직접 실행합니다. 터미널에서 `java -jar lombok-1.18.32.jar` 와 같이 실행하거나, 파일 탐색기에서 더블클릭하여 실행합니다. (GUI 인스톨러가 없는 경우도 있으니 터미널 실행을 권장합니다.)
Lombok 인스톨러 창이 나타나면, 자동으로 시스템에 설치된 Eclipse/STS를 찾아 목록에 보여줍니다. 만약 목록에 나타나지 않는다면 `Specify Location...` 버튼을 눌러 수동으로 `eclipse.exe` 또는 `SpringToolSuite4.exe` 파일의 위치를 지정해줍니다.
설치할 IDE를 선택하고 `Install / Update` 버튼을 클릭합니다.
"Installation successful" 메시지를 확인한 후 인스톨러를 종료합니다.
반드시 Eclipse/STS를 완전히 종료했다가 재시작합니다.

이 과정을 거치면 `eclipse.ini` 파일 끝에 `-javaagent:...(경로).../lombok.jar`와 같은 라인이 추가된 것을 확인할 수 있습니다. 이로써 Eclipse는 모든 프로젝트에 대해 Lombok을 인지할 준비를 마치게 됩니다.

Lombok Jar 인스톨러 실행 화면

3.2.3. Eclipse/STS 문제 해결을 위한 추가 조치

프로젝트 클린 (Project Clean): Eclipse 메뉴에서 `Project` > `Clean...`을 선택하고, 해당 프로젝트를 클린하여 이전 빌드 아티팩트를 제거합니다.
Gradle 프로젝트 새로고침은 필수: `build.gradle`을 변경했다면, IntelliJ와 마찬가지로 `Gradle` > `Refresh Gradle Project`를 항상 실행하는 습관을 들여야 합니다.

4. 고급 시나리오: 또 다른 복병들과의 만남

기본 설정을 모두 마쳤음에도 불구하고 문제가 발생한다면, 좀 더 복잡한 상황일 수 있습니다.

4.1. 다른 애너테이션 프로세서와의 충돌 (e.g., MapStruct, QueryDSL)

프로젝트에 Lombok 외에 MapStruct(객체 매핑), QueryDSL(타입-세이프 쿼리 생성)과 같이 다른 애너테이션 프로세서를 함께 사용하는 경우, 프로세서 실행 순서가 중요해질 수 있습니다.

예를 들어, MapStruct는 Lombok이 Getter/Setter, 생성자를 모두 생성한 *이후에* 동작해야 올바른 매핑 코드를 생성할 수 있습니다. 대부분의 경우 Gradle은 이 순서를 자동으로 처리하지만, 문제가 발생한다면 `annotationProcessor` 의존성 순서를 명시적으로 조정하거나, `lombok-mapstruct-binding`과 같은 특수 바인딩 라이브러리를 추가해야 할 수 있습니다.


// build.gradle 예시
dependencies {
    // ...
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'

    implementation 'org.mapstruct:mapstruct:1.5.5.Final'
    annotationProcessor 'org.mapstruct:mapstruct-processor:1.5.5.Final'

    // Lombok과 MapStruct를 함께 사용할 때 순서 보장을 위한 바인딩
    annotationProcessor 'org.projectlombok:lombok-mapstruct-binding:0.2.0'

    // QueryDSL 설정
    implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
    annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta"
    annotationProcessor "jakarta.annotation:jakarta.annotation-api"
    annotationProcessor "jakarta.persistence:jakarta.persistence-api"
    // ...
}

이처럼 복수의 애너테이션 프로세서가 있다면, 각 라이브러리의 공식 문서를 참조하여 Gradle 설정 가이드를 정확히 따르는 것이 중요합니다.

4.2. Lombok 설정 파일 `lombok.config`

프로젝트의 루트 디렉토리나 특정 소스 패키지에 `lombok.config` 파일을 위치시켜 Lombok의 동작을 세밀하게 제어할 수 있습니다. 예를 들어, 특정 로그 라이브러리를 사용하도록 `@Log` 애너테이션의 기본 동작을 변경하거나, 생성되는 필드 이름의 접두사를 제거하는 등의 설정이 가능합니다.


# lombok.config 예시

# @Log, @Slf4j 등의 로그 필드 이름을 'log'가 아닌 'logger'로 설정
lombok.log.fieldName = logger

# @Data, @Getter 등에서 생성하는 메서드에 final 키워드 추가
lombok.addLombokGeneratedAnnotation = true

# 특정 애너테이션 비활성화
lombok.setter.flagUsage = error

팀 전체가 일관된 규칙을 따르기 위해 `lombok.config` 파일을 버전 관리에 포함시키는 것은 좋은 전략입니다.

4.3. 빌드 서버(CI/CD)에서의 실패

로컬 환경에서는 빌드가 잘 되는데 Jenkins, GitLab CI, GitHub Actions 같은 CI/CD 파이프라인에서 빌드가 실패하는 경우가 종종 있습니다. 이는 거의 100% `build.gradle` 설정 문제입니다. CI 서버는 IDE 없이 오직 `gradlew build` 명령어에만 의존하기 때문에, `build.gradle`에 `compileOnly`와 `annotationProcessor` 설정이 완벽하게 되어 있지 않다면 컴파일 오류가 발생할 수밖에 없습니다. 로컬에서 IDE의 도움으로 어찌어찌 동작했던 것일 뿐, 근본적인 설정이 잘못되었을 가능성이 높습니다. 이 경우, 이 글의 2번 챕터로 돌아가 `build.gradle` 설정을 다시 한번 꼼꼼히 점검해야 합니다.

결론: 체계적인 접근이 해답이다

Gradle 프로젝트에서 Lombok 연동 오류를 마주했을 때, 인터넷에서 발견한 단편적인 해결책을 무작정 적용하기보다 체계적인 접근 방식을 취하는 것이 중요합니다. 문제를 해결하는 핵심 원리는 다음과 같이 요약할 수 있습니다.

원리의 이해: Lombok은 컴파일 타임에 코드를 생성하는 애너테이션 프로세서이며, 이로 인해 '빌드 도구'와 'IDE' 양쪽에 모두 정확한 설정이 필요하다는 사실을 인지하는 것이 가장 중요합니다.
Gradle 설정 점검: `build.gradle` 파일에 `compileOnly`와 `annotationProcessor` 스코프를 사용하여 Lombok 의존성이 올바르게 명시되었는지 최우선으로 확인합니다. 이것이 모든 것의 기초입니다.
IDE 설정 점검:
- IntelliJ: Lombok 플러그인 설치와 함께 'Enable annotation processing' 설정이 켜져 있는지 반드시 확인합니다.
- Eclipse/STS: `Gradle > Refresh Gradle Project`를 통해 설정을 동기화하거나, 전통적인 `lombok.jar` 인스톨러를 사용하여 IDE 자체에 Lombok을 인식시킵니다.
캐시와 재시작 활용: 문제가 해결되지 않을 때 'Invalidate Caches / Restart'(IntelliJ) 또는 'Project Clean'과 IDE 재시작(Eclipse)은 가장 효과적인 문제 해결 도구 중 하나입니다.

Lombok은 분명히 자바 개발자의 생산성을 극대화하는 강력한 도구입니다. 초반의 설정 과정이 다소 까다롭게 느껴질 수 있지만, 이 글에서 제시한 원리와 해결 전략을 충분히 이해한다면 더 이상 Lombok으로 인해 개발 흐름이 끊기는 일은 없을 것입니다. 이제 지루한 보일러플레이트 코드의 속박에서 벗어나, 창의적인 코드 작성의 즐거움을 만끽하시기 바랍니다.

Thursday, June 7, 2018

Gradle 프로젝트 Lombok 컴파일 오류부터 IDE 문제까지 해결법