1년동안 Server side를 Kotlin으로 개발하면서 느낌 점.

TITICACA로 이직하면서 서버 사이드 언어를 Kotlin으로 쓰게 되었다.

현재 거의 1년 정도 쓰고 있는데 몇가지 느낀 점을 써보려고 한다.

1. JVM 생태계 호환성. 

코틀린을 만든 젯브레인은 100% 호환이 된다고 이야기 한다.(둘 다 JVM에서 돌아가니..) 언어 자체만 보면 분명 100% 호환되는 것이 맞는데 Java가 가지고 있는 개발 생태계에는 ver 1.2의 경우 98% 정도 호환되는 듯 하다(나머지 2%도 대체제가 있다.)

1년간 플젝하면서 문제가 있다기 보단 방식이 바뀌어서 좀 시간이 걸렸던 것은 QueryDSL의 설정과 ORM 사용을 위해 entity의 관계 설정을 할 때 mutable에 대한 이슈 정도였으나 사실 금방 해결 되었다.


코틀린 ver1.2가 나오고 나선 훨씬 더 호환이 잘되는 것들이 생기면서 딱히 어떤 생태계의 호환성의 문제로 java로 돌아가야겠다는 생각은 해본 적이 없다. 

(내가 사용한 기술 스택이 젯브레인에서 전적으로 지원하는 것이라 문제가 없었을지도 모른다.) 


2. 개발 편의성

언어마다 철학이 조금씩 달라서 개발 편의성을 논하기는 좀 그렇지만 대략적으로 써보면서 편했던 것은 다음과 같다. 

• Null에 대한 고민이 많이 사라졌다.
• 변수 선언을 할 때부터 이미 Null과 Not Null을 구분하기 때문에 null pointer exception에 대한 방어코드를 별도로 작성 할 필요가 거의 없어서 코드가 깔끔해졌다.
• 예전에는 로직 속에 어떤 때 null인지를 생각했다면 코드에 바로 드러나기 때문에 도메인에 대한 이해도를 높인다.
• 타입추론으로 인해 코드가 감소했다.
• 이건 호불호가 좀 갈릴 수 있는데 개인적으로는 타입추론을 좋아하지 않았다가 코틀린을 쓰면서 익숙해졌다. 일단 intellij로 개발을 하다보니 추론된 타입이 tool에 이미 표기되기 때문에 금방 익숙해진 듯 하다. 
• var와 val은 개발 실수를 줄여준다.
• val이 사실 자바에서 final이기 때문에 같은 것이지만 온갖 변수에 final이 달리면 가독성이 떨어지기 때문에 잘 안썼지만 코틀린은 이를 나누고 보기도 좋다.
• final 변수를 선언하는 것을 나눔으로서 개발 실수를 줄여주는 것도 좋았다.
• extension function은 정말 유용하다.
• 기본적으로 지원하는 것만으로도 굉장히 코드가 줄어들고 가독성이 높은 코드를 짤 수 있다. 전에는 util lib를 사용했다면 내장되어 있는 것이 많아서 바로 쓸 수 있다.
• 범위 지정이 가능하기 때문에 특정 class 안에서만 쓴다거나 할 수 있어서 오남용(?)을 방지 할 수 있어서 좋았다.
• 각종 convert를 할 때 많이 활용하는 편이다. 
• let, apply, run, also 등이 참 마음에 들었다.
• 좀 더 편한(?) lambda 식
• 평소 개발할 때 많이 쓰는 lambda식이 기본으로 제공되서 별도 구현이 필요없다.
• 필요하면 더 만들 수도 있는데 그냥 가지고 있는 것 만으로도 충분했다.
• FT 개발자들과 코드를 공유 할 수 있다.
• javascript를 주로 다루는 front-end 개발자들에게 코틀린 소스를 보여주면 읽는 것은 금방 읽을 수 있는데(요즘 모던 랭귀지가 다 비슷 비슷하니..) 어쨋든 이부분도 좋았다.
• 코드 리뷰를 할 때 FT개발자들도 같이 참여 할 수 있는 것이 장점이었다.
• Inner Class가 아닌 kt 파일로 Class를 여러개 선언 한다.
• 이건 개취가 심한 것 같다. 나같은 경우는 비슷한 일을 하는 Class를 package 기준으로 모아두는 편인데  kt 파일로 이걸 package 레벨이 아닌 file 레벨로 묶을 수 있어서 마음에 들었다.

3. 가시성 제어

코틀린의 가시성 제어 방식은 Module을 기초로 public, private, interal, inline 등을 제공한다.
이는 코틀린의 기본 철학과도 관계가 있는데 뭔가 숨기려면 module로 쪼개라는 것이다. 프로젝트가 크면 당연히 맞는 말인데.. 가시성 제어를 package 단위로 하고 싶을 때가 있는데 그럴 때 마다 module을 쪼개는 것도 비용이라 나중에 얘네들이 생각을 바꿔서 package 단위로도 해줬으면 한다.

4. learning curve
나는 익숙해지는데 2주정도 걸렸는데 기존 프로젝트를 kotlin으로 임의로 변경해보면서 감을 익혔다.
Javascript를 해본 사람이면 훨씬 빨리 익힐 수 있고 코드 자체를 보는 것도 매우 빠를 것 같다.
아직 코틀린의 구조(file, module, class, function)에 대해서는 그 철학대로 쓰지 못하고 java스럽게 쓰는 부분이 있지만 조금씩 변화하고 있긴 하다. (물론 이게 맞는 건지는...)

5. Data Class 
이건 뭐.. Java에도 lombok이 있어서 비슷하다고 볼 수 있는데 개인적으로는 Class간 VO 역할을 하는 Class의 경우 명시적으로 Data Class로 정의할 수 있어서 개념적으로 마음에 들었다.

결론
일단 딱 두가지, 코드가 깔끔하게 줄어든다는 것과 Null을 제어하는 것 만으로도 상당히 만족스럽다.
하지만 Java도 점점 타입추론을 지원하게 되고 extension method 등을 지원하기 때문에 몇년 뒤면 두 언어가 비슷해 질 것 같지만 kotlin의 판올림 속도를 보면 정말 빠르기 때문에 Java에서 따라 올 수 있을까 싶은 생각이 좀 든다.

그리고 딱히 Java로 꼭 개발해야 하는 환경이 아니라면 계속 Kotlin으로 Server side를 개발 할 예정이다.