[Kotlin Spring Boot] Spring Properties에 스마트함 더하기

자바(Java)로 작성된 스프링 부트 애플리케이션을 코틀린(Kotlin)으로 마이그레이션하거나 새로운 코틀린 스프링 프로젝트를 시작할 때, 개발자가 가장 먼저 체감하게 되는 차이는 무엇일까요? 단순한 문법의 축약을 넘어, 코틀린은 스프링 프레임워크와 결합했을 때 코드의 '안전성'과 '예측 가능성'을 극대화하는 강점을 제공합니다. 이 글에서는 단순한 마이그레이션 과정을 나열하기보다 코틀린이 자바에 비해 어떤 구조적 우위를 가지는지, 특히 application.yaml의 환경 설정 객체 매핑 과정을 중심으로 살펴보고자 합니다.

1. 상태를 통제하는 스마트함

객체의 상태가 언제든 변할 수 있다는 것은 개발자에게 지속적인 의심과 디버깅을 요구합니다. 특히 멀티스레드 환경인 스프링 부트에서 설정 값의 불변성(Immutability)은 시스템의 안정성을 결정짓는 핵심 요소입니다. 코틀린은 언어적 차원에서 이러한 불안감을 원천적으로 차단합니다.

1.1. Java에서의 프로퍼티 바인딩 한계

기존 Java 환경에서 application.yaml의 값들을 객체로 가져오기 위해 @ConfigurationProperties를 사용할 때, 우리는 종종 딜레마에 빠졌습니다. 불변성을 유지하기 위해 생성자 주입 방식을 택하면, 과거 버전에서는 장황한 @ConstructorBinding 어노테이션이 필요했고, 종종 Lombok의 @Value나 @AllArgsConstructor에 의존해야 했습니다. 반대로 빈 생성자와 Setter를 열어두는 방식을 사용하면, 애플리케이션 런타임 중에 누군가 설정 값을 변경할지도 모른다는 잠재적 위험(Side-effect)을 안고 가야 했습니다.

1.2. Kotlin data class와 val

코틀린은 data class와 읽기 전용 속성인 val을 통해 이 문제를 아주 깔끔하게 해결합니다.

@ConfigurationProperties(prefix = "app")
data class AppProperties(
    val name: String,
    val timeout: Int = 5000,
    val features: Features
) {
    data class Features(
        val enabled: Boolean,
        val maxLimit: Int
    )
}

JDK 21과 Spring Boot 3.x 환경에서는 코틀린의 단일 생성자를 자동으로 인식하여 바인딩을 수행합니다. Lombok 같은 외부 라이브러리 없이도 완벽한 불변 객체가 생성되며, toString(), equals(), hashCode()까지 자동으로 지원됩니다. 설정 객체는 애플리케이션 로드 시점에 단 한 번 안전하게 초기화되고, 이후 어떤 스레드에서도 값이 변형되지 않음을 언어 레벨에서 보장받습니다.

여기서 이렇게 생각하시는 분들도 계실 것 같습니다.

맞습니다. 최근의 Java 역시 record를 도입하여 훌륭하게 불변성을 지원합니다. 하지만 Kotlin의 data class는 기본값(Default argument) 지정이 훨씬 자유롭다는 확실한 장점이 있습니다.

Java의 record에서 특정 필드에 기본값을 설정하려면 컴팩트 생성자(Compact Constructor)를 추가로 작성하거나 오버로딩을 해야 하는 번거로움이 존재합니다. 반면, Kotlin은 위 코드의 timeout: Int = 5000처럼 매개변수 선언부에서 즉시 기본값을 할당할 수 있어, 불필요한 보일러플레이트 코드를 깔끔하게 제거해 줍니다.

2. 런타임 에러를 컴파일 타임으로 끌어올리기

이는 서버 개발의 중요한 원칙인 Fail-Fast 전략입니다. 코틀린은 강력한 타입 시스템을 통해 스프링의 검증 과정을 한 차원 끌어올립니다.

2.1. 널 안전성(Null Safety)과 @Validated의 시너지

Java에서는 YAML 파일에 필수 설정값이 누락되었을 때, 이를 런타임에 해당 속성을 호출하는 시점이 되어서야 NullPointerException으로 마주하는 경우가 많았습니다. 이를 막기 위해서는 @Value("${my.custom.property}")처럼 기본값(Default)을 주지 않고 단일 값을 매핑하거나, @Validated와 무수한 @NotNull 어노테이션을 붙여야 했습니다.

코틀린은 타입 자체에 Null 허용 여부를 명시(String vs String?)합니다. 여기에 스프링의 @Validated를 결합하면, 컴파일러가 검증하는 널 안전성과 프레임워크가 검증하는 값의 유효성이 깔끔하게 맞아떨어집니다.

@Validated
@ConfigurationProperties(prefix = "app")
data class AppProperties(
    @field:NotBlank(message = "앱 이름은 필수입니다.")
    val name: String, // String? 가 아니므로 Null 원천 차단

    @field:Min(1000)
    val timeout: Int = 5000 // 누락 시 기본값으로 스마트하게 대처
)

타입 시스템 자체가 Null을 거부하기 때문에, 애플리케이션은 부팅 시점에 누락된 프로퍼티를 즉각적으로 감지하고 실행을 중단합니다. 이는 개발자의 휴먼 에러를 시스템이 안전하게 방어해 주는 대표적인 사례입니다.

3. 비즈니스 로직에 집중할 수 있는 환경

개발을 하다 보면 인프라성 코드나 타입 변환을 위한 보일러플레이트 코드(Boilerplate code)가 비즈니스 로직을 가리는 경우가 많습니다. 코틀린과 스프링의 조합은 객체 지향의 원칙을 지키면서도 코드를 간결하게 만들어줍니다.

3.1. 커스텀 Converter로 타입 변환 은닉

YAML 설정 파일에는 문자열(String)로 들어오지만, 애플리케이션 내부에서는 특정 객체(예: Location)로 다루고 싶을 때가 있습니다. Java에서는 Setter 내부에서 로직을 태우거나, 임시 String 필드를 두고 Getter에서 변환하는 꼼수를 쓰기도 합니다.

하지만 코틀린 기반의 스프링에서는 data class의 순수성을 유지한 채, 스프링의 Converter 인터페이스를 활용하여 변환 로직을 완전히 격리할 수 있습니다.

@Component
@ConfigurationPropertiesBinding
class StringToLocationConverter : Converter<String, Location> {
    override fun convert(source: String): Location {
        val (lat, lon) = source.split(",") // 코틀린의 구조 분해 할당
        return Location(lat.toDouble(), lon.toDouble())
    }
}

이러한 접근을 통해 AppProperties는 단순히 val location: Location이라는 명확한 타입만을 가지게 되며, 설정 객체는 본연의 역할(데이터 보관)에만 충실할 수 있게 됩니다.

4. 마무리하며 - 예측 가능성을 지향하는 언어와 프레임워크의 만남

이처럼 자바에서 코틀린으로 넘어오는 것은 단순히 코드 타수를 줄이는 문제로 끝나지 않습니다.

1. 완벽한 불변성 확보: val과 data class를 통해 부작용(Side-effect) 없는 안전한 설정 관리가 가능해집니다.
2. Fail-Fast의 구현: 코틀린의 강력한 널 안전성(Null Safety) 타입 시스템이 스프링 부팅 시점에 오류를 조기에 차단합니다.
3. 보일러플레이트 제거: 언어적 간결함과 프레임워크의 기능이 만나, 비즈니스 로직 외의 불필요한 코드를 깔끔하게 분리할 수 있습니다.

코틀린이 제공하는 이러한 '스마트함'은 결국 개발자가 시스템을 통제하고 있다는 '예측 가능성'과 '자신감'으로 이어집니다. 언어의 철학이 프레임워크의 아키텍처와 결합했을 때 코드의 품질이 어떻게 향상되는지, 설정 관리 영역만 보더라도 명확히 체감할 수 있습니다.

저는 예측가능하고, 안정성있는 코드를 선호합니다. Python보단 C++이나 Go를, JavaScript보단 TypeScript를 선택한 이유도 그러했습니다. Kotlin 또한 마찬가지입니다. 예측 가능하고 안정성있는 코드를 선호했기 때문에, Java Spring Boot에서도 @Value 보다는 @ConfigurationProperties를 선호했습니다.

Spring Boot는 Java와 Kotlin을 동시에 지원합니다. 덕분에 Multicampus에서 진행했던 프로젝트를 점진적으로 마이그레이션 하면서 Kotlin을 접할 기회를 얻었습니다. 그리고 그 과정에서 처음 마주친 Spring Boot의 Kotlin 설정 관리 방식은 너무나 안정적이면서도, Java보다 훨씬 간결했습니다. 이는 제가 Kotlin에 푹 빠지게 된 계기가 되었습니다. Java를 사용하면서 설정 관리의 불안함이나 불편함을 느껴보신 적이 있으시다면, 다음 프로젝트에는 Kotlin을 도입해보는 것도 좋은 선택일 겁니다.