[2019] PAYCO 매거진 서버 Kotlin 적용기

안드로이드에 이어 스프링 5.0이 코틀린을 정식 지원하며 서버사이드 적용이 늘어난 배경을 설명한다. 이번 마이그레이션에서 주목한 네 피처로 널 안정성, 확장 함수, 자바 100% 호환, 데이터 클래스를 꼽는다.

자바는 박싱 타입에 널이 들어갈 수 있어 오토 언박싱 과정에서 런타임 NPE가 나지만, 코틀린은 물음표로 널 허용 여부를 타입에 표기해 컴파일 타임에 널 오류를 잡아낸다는 점을 유즈케이스 코드로 비교한다.

모델·컨피그를 먼저, 이후 비즈니스 로직, 마지막에 리팩터링하는 3단계 계획과 인텔리J 자동 변환 기능을 소개한다. 자동 변환된 코드에서 롬복 어노테이션이 무력화되는 첫 이슈를 만나, 빌드 시 컴파일 순서 문제까지 짚고 롬복을 제거해 데이터 클래스로 대체한다.

필드 주입 시 널 불가 타입 때문에 컴파일 에러가 나는 문제를 `lateinit`으로, 생성자 주입은 자바와 동일하게 `val`로 푼다. `@RequestParam(required=true)`가 코틀린에선 무시돼 물음표 제거로 필수화하고, static은 컴패니언 오브젝트와 `@JvmStatic`으로 대체하는 등 스프링+코틀린 차이를 설명한다.

자동 변환만으론 언어 장점을 못 살린 코드를 개선한다. if-else를 when으로 바꿔 분기를 정리하고, 확장 함수로 스프링 모델의 `addAttribute`를 딕셔너리 스타일로 쓰는 등 인텔리J 단축키를 활용한 리팩터링 사례를 보여준다.

빌드타임은 30~40초로 체감 차이가 없고 주요 API 응답시간도 영향이 없었다. 소나큐브로 측정한 코드 라인은 약 6%, 텍스트는 약 10% 감소했는데, import 등 고정 비중을 감안하면 의미 있는 수치라고 해석한다.

구문 수 약 13%, 순환 복잡도 약 12% 감소는 널 안정성으로 널 체크·try-catch·중첩 분기가 줄고 when으로 분기를 몰아넣은 덕분이라 설명한다. 자동 변환을 쓰되 코틀린 사용법을 알아야 매끄럽고, 장점을 살린 리팩터링으로 가독성과 복잡도가 개선됐다고 발표를 종합한다.