제휴 상품 연동 프로젝트 코틀린 전환기

코틀린 도입 이유와 장점

wisdom

Published in

SSG TECH BLOG

10 min readOct 3, 2022

안녕하세요. 제휴서비스팀에서 외부 제휴사(G마켓, 옥션, 11번가, 네이버 등) 로 SSG에서 판매되고 있는 상품 연동 개발을 담당하고 있는 강지혜입니다.

저희 파트는 지난 8월 오픈한 스마일프레시 프로젝트를 시작으로 MSA 전환을 진행하고 있는데요,

사용 언어 역시 기존 자바에서 코틀린으로 전환을 하였습니다.

이 글을 통해 저희가 왜 코틀린을 선택하였는지, 코틀린의 장점, 전환하며 겪은 어려웠던 점 등에 대해 공유하고자 합니다.

시작에 앞서

우선 SSG 상품들을 제휴사에 어떻게 연동하고 있는지 간략하게 소개해 드리겠습니다.

① SSG 상품 테이블에 신규/수정 사항이 생겼을 경우 제휴 연동용 상품 집계 테이블에 적재
② 집계된 상품의 도메인(ex. 가격, 재고, 판매상태 등등) 에 맞는 제휴사 API를 호출하여 상품 연동

실제 좀 더 복잡하기는 하지만 전체적인 흐름은 위 그림과 같습니다. MSA 전환 전에는 ②에 해당하는 각 제휴사별 연동 API를 호출하는 모든 서비스가 타 팀에서도 함께 사용하는 SSG 공통 배치 프로젝트에 존재하였습니다.

저희는 이번에 MSA 전환을 하며 이 공통 배치 프로젝트에서 처리하는 로직을 저희 파트에서만 사용할 수 있는 각 제휴사별 프로젝트로 분리하였습니다. 참고로 이 제휴사별 프로젝트에선 해당 제휴사에서 제공하는 규격에 맞게 SSG 상품 데이터들을 가공하여 API를 전송하는 역할을 합니다.

이 때 기존 공통 배치 프로젝트에서 사용되던 자바로 된 로직을 100% 코틀린으로 전환하였습니다.

제휴 상품 MSA 프로젝트 파일 구성

코틀린 도입 이유

굳이 자바가 아닌 코틀린을 도입하게 된 이유는 다음과 같습니다.

러닝 커브가 적다.

실제 업무에 새로운 언어를 사용하는 것에 부담을 갖고 계실 수도 있으신데요, (저는 그랬습니다… 🥲) 코틀린은 JVM에서 동작하기에 자바에서의 라이브러리와 프레임워크를 100% 재사용 할 수 있습니다.
따라서 자바에 친숙한 개발자분들께서는 금방 적응하실 수 있으리라 생각합니다. 저희는 회사에서 지원해주시는 책과 온라인 강의를 활용하여 학습을 진행하였습니다.
또한 인텔리제이에서 Convert Java File to Kotlin File 기능을 통해 자바 코드를 코틀린으로 손쉽게 변환해 볼 수도 있습니다.

2. 이미 많은 IT회사에서 신규 프로젝트를 코틀린+스프링으로 진행하고 있다.

아무래도 신규 프로젝트에 익숙하지 않은 언어를 사용하다보니 프로젝트 오픈 후에도 과연 안정적으로 서비스를 운영할 수 있을지에 대한 고민도 하게 되었습니다. 하지만 이미 많은 IT 회사에서 코틀린+스프링을 사용하고 있기에 어느정도 검증된 조합이라 판단하였고, 이 또한 코틀린을 도입하게 된 이유 중 하나입니다.

3. 자바가 아닌 새로운 언어를 사용해보고 싶었습니다. 🙃

MSA 전환을 위한 기술 조사 당시 코틀린 이외 다른 언어(Go) 에 대해서도 고려를 하였는데요, 위 두가지 이유 및 저희 프로젝트에 가장 적합한 언어는 코틀린이라고 판단하여 결정하게 되었습니다.

코틀린 장점

코틀린의 장점은 많지만 제가 개발해보며 느낀 대표적인 3가지에 대해 말씀드리도록 하겠습니다.

1. 변경 불가능한 변수(val)와 변경 가능한 변수(var)

자바에서는 아래 코드와 같이 변수를 선언할 때 타입이 맨 앞에 옵니다.
하지만 코틀린은 기본적으로 특정 타입을 명시하지 않고도 변수 선언이 가능하며(자바는 자바 10이상부터 가능) 변수 선언 시 val 또는 var 키워드를 사용합니다.

// Java
int num1 = 10;
final int num2 = 20;// Kotlin
var num1 = 10 (참고로 코틀린은 구문 끝에 오는 ; 를 생략할 수 있습니다!)
val num2 = 20

이 두 키워드의 차이는 다음과 같습니다.

① val (값을 뜻하는 value에서 따옴)

변경 불가능한 변수에 사용
자바의 final 변수에 해당
값 변경 시 컴파일 에러 발생

② var (변수를 뜻하는 variable에서 따옴)

변경 가능한 변수에 사용
자바의 일반 변수에 해당
값 변경이 가능하지만 다른 타입의 값으로 변경은 불가능

결과적으로 val로 선언된 변수는 값이 변경되지 않는 다는 것을 보장하기 때문에 변수의 값이 어느 지점에서 바뀌는지 알기 위해 코드 전체를 확인해 볼 필요가 없다는 장점이 있습니다.

2. 안전한 null 처리

자바로 개발을 하다보면 NullPointerException(NPE)을 마주치는 경우가 많습니다. NPE는 많은 분들이 아시다시피 참조된 레퍼런스 변수가 null일 때 발생합니다.
이를 방지하고자 많은 코드에서 아래와 같이 null 체크를 하고 있습니다.

// Java
if (itemInfo != null) {
    ...
}if (StringUtils.isNotBlank(itemId)) {
    ...
}try {
    ...
} catch (NullPointerException e) {
    ...
}

이러한 구문을 계속 사용하게 되면 가독성도 안 좋아지고 개발자가 의식적으로 null 체크 구문을 써줘야하는 불편함이 발생합니다.

이에 반해 코틀린은 함수나 메소드가 null을 받거나 null을 리턴할 수 있는지 명확하게 표현할 수 있으며 그 시점도 알 수 있습니다.
nullable 변수를 만들 수 있기는 하지만 이 변수를 사용할 때에는 null 체크없이는 코드가 컴파일이 되지않습니다.

그렇다면 코틀린에서 null을 어떻게 다루고 있는지 말씀드리도록 하겠습니다.

① Null 가능 변수 타입: ?

코틀린은 기본적으로 모든 타입에 대해 null을 허용하지 않습니다.
하지만 null 허용 키워드를 통해 null 을 가능하게 할 수 있습니다.
사용방법은 타입 뒤에 ?를 붙이는 것입니다.

val str1: String? = null // 가능val str2: String = null // 불가능 (Null can not be a value of a non-null type String 오류 발생)

② Safe Call 연산자: ?.

nullable한 변수인지 검사하여 null 이면 그대로 null 을 반환합니다.
사용되는 연산자는 ?. 입니다.

val str1: String? = null

println(str1?.toUpperCase()) // null 출력

str1?.run { // str1이 null이므로 실행되지 않음
        println(toUpperCase())
        println(toLowerCase())
}

③ Elvis 연산자: ?:

참조한 객체가 null일 경우 default 값을 정해 이 값을 반환합니다.
사용되는 연산자는 ?: 입니다.
이 연산자의 이름이 엘비스인 것은 연산자를 시계방향으로 90도 돌리면 엘비스 프레슬리의 헤어스타일 같다고 하여 지어진 이름이라고 합니다.

val str1: String? = null
 
println(str1 ?: "ssg".toUpperCase()) // str1이 null 이므로 SSG 출력

④ 널 아님 단언: !!

null이 절대 들어오면 안되는 경우에 사용합니다.
!!는 “나는 이 값이 null이 아님을 확신하니, null 이라면 오류가 발생해도 감수할게!” 라는 의미를 내포하고 있습니다.
따라서 !!로 선언한 변수가 null 이라면 NPE 가 발생합니다.

val str1: String? = null  println(str1!!.toUpperCase()) // str1이 null 이 아니라고 단언하고 있으나 null 이므로 NPE 발생

이러한 방법들을 통해 코틀린은 컴파일 단계에서 NPE를 방지할 수 있도록 도와줍니다.
코틀린에 익숙하지 않으신 분들이라면 아직 각각의 연산자들이 와닿지 않으실 수도 있는데요, 점차 익숙해지니 이만한 null 처리 방안이 있을까 생각하게 됩니다.

3. 명시적 파라미터

자바에서는 파라미터가 있는 함수를 호출 할 때 함수 생성에 사용한 파라미터 순서에 따라 값을 매핑합니다.

// Java
void createPerson(String name, int age, int weight, int height) {
      ...
}// 함수 호출
createPerson("Mike", 56, 170, 67);

위 코드의 createPerson 함수 호출부만 봐서는 파라미터들이 어떤 것을 의미하는지 한 번에 알아보기 쉽지 않습니다. (인텔리제이의 도움을 받을 수는 있겠지만 코드 자체만 봤을 땐 쉽게 알 수 없습니다.)

하지만 코틀린은 이름을 붙인 파라미터(Named Arguments)를 제공합니다.

이는 함수를 호출할 때 이름을 붙이고 값을 매핑하는 방식입니다.

이 방식을 사용하여

①파라미터 순서에 구애받지 않고 값을 전달할 수 있으며
②파라미터가 어떤 값을 의미하는지 한 번에 파악할 수 있습니다.

// Kotlin
fun createPerson(name: String, age: Int, weight: Int, height: Int) {
					....
}// 함수 호출
// 파라미터 순서 상관없이 호출 가능.
createPerson(name = "Mike", age = 12, height = 67, weight = 170)

운영을 하다보면 함수의 파라미터가 점점 늘어나게 되는 경우가 있는데요,
자바를 사용했을 땐 파라미터 순서를 잘못 매핑하여 의도하지 않은 결과값을 리턴하거나 오류가 발생하기도 했습니다.
하지만 코틀린의 Named Arguments 방식을 사용하여 이러한 오류에서 벗어날 수 있었으며 코드의 가독성도 높아졌습니다!

전환하며 겪은 어려웠던 점

1. 프로젝트 환경설정

프로젝트 생성 후 build.gradle.kts 에 환경 설정을 할 때 자바에 비해 자료가 적어 어려움을 겪었습니다. 구글링을 통해 참고할 수 있는 코드들은 대부분 자바로 되어 있었습니다. 하지만 더 열심히(?) 구글링 및 여러가지 방법을 시도하였고 결국 원하던 환경 구성을 할 수 있었습니다. 정리하자면 자바에 비해 참고할 수 있는 자료가 적어 환경 구성에 시간이 좀 더 소요되었다! 라고 할 수 있겠습니다.

2. val , var ..?

앞서 코틀린에서 val과 var 의 차이점을 말씀드렸는데요, 실제로 개발을 시작하니 어떤 값을 val 로 선언하고 어떤 값을 var로 선언해야할지 판단하기가 어려웠습니다. 저희는 기본적으로 모든 변수를 val 로 선언하고 디테일한 로직 개발에 들어가며 변경이 필요한 변수일 때 var 로 변경하였습니다.

전환 이점

MSA 전환을 하며 그대로 자바를 사용하였더라면 기존 소스 복사+붙여넣기에 지나치지 않았을 것 같습니다. 하지만 전체 소스를 코틀린으로 새로 개발을 해야했기에 기존 로직에 대해 다시 한 번 정리할 수 있었고, 기존의 복잡한 로직을 좀 더 단순화하여 리팩토링 할 수 있었습니다.
저는 이 부분이 가장 큰 이점이라고 생각합니다.
이 밖에도 앞서 코틀린의 장점에서 말씀드렸던 내용들을 적용함으로써 코드 생산성 측면에서도 아주 좋아졌고, 코드가 자바에 비해 상대적으로 간결화 되었기 때문에 가독성이 좋아졌습니다!

마무리

신규 프로젝트에 익숙하지 않은 새로운 언어를 도입하는 것은 큰 결정이였습니다.

하지만 팀원 모두 코틀린이라는 언어에 대해 관심이 있었고, 새로운 언어를 도입할 수 있는 쉽게 오지 않는 기회라고 생각하기에 결정을 하게 되었습니다. 결과적으로는 모두 만족하며 코틀린의 매력에 빠져들게 되었습니다.

사실 도입 당시 우려(과연 잘 돌아갈 수 있을까..? 😶) 와는 달리 프로젝트를 성공적으로 오픈하기는 했지만, 아직 코틀린의 기본적인 문법에 친숙해졌을 뿐이라고 생각합니다.

현재 저희 파트에선 신규 제휴사와 기존 레거시 프로젝트에 남아있는 제휴사에 대해서도 MSA 전환 작업을 진행중이며, 코틀린이 제공하는 다양한 라이브러리와 기능들을 활용하여 끊임없이 고도화하고 있는 중입니다. 🙂

이 글을 통해 코틀린 도입을 고민하시는 분께 조금이라도 도움이 되었으면 좋겠습니다.

읽어주셔서 감사합니다!

참고

- 드미트리 제메로프, 스베트라나 이사코바. 『Kotlin IN ACTION』. 오현석(역). 에이콘, 2017.