코틀린 vs Java

세상은 넓고 언어는 많다 !

 

 필요에 의해서 많은 언어들을 사용하게 된다. 학교 다닐때만해도 언어하나로 먹고 산다는 이야기를 많이 들었던거 같다. 학교를 졸업하고 벌써 10년차 개발자가 된 나로써는 그때 그런말한 사람들이 이해가 가질 않는다. 

 

  최초 일을 시작하면서 자바를 사용했고 중간중간 모든 스타트업회사들이 그렇듯 이가 없으면 잇몸으로 한다는 정신으로 C++ 도 사용하고 했다. 지금 생각하면 정말 위험할 정도의 퀄리티의 프로그램을 내손으로 그렇게 만들었고 웹프로그래머가 되면서 JSP 와 함께 JS 를 전문가 수준은 아니여도 서버랜더링 서비스 정도는 구축할수 있게 되었다. ( 다 스프링 덕분이 아닌가 싶다. ) 

 지금은 그래서 우여곡절끝에 java ,js, php , python 정도 사용할수 있다 수준정도 된거 같고 최근에는 코틀린에 도전 중이다. 

 

코틀린 도입 배경은 단순하다. 

 

첫번째 , 한번 써보자 ! 

회사에서 팀장님의 니즈가 있었다. 한번 써보자는것이다. 나도 부담감 없이 동참 하기로 했다. 현재는 우리팀 모두 코틀린으로 개발중이다. 

 

두번째 , 간결해진다. ! 

예전 NHN 세미나에 가서 코틀린 도입기를 들은적이 있었는데 기존 소스를 드라마틱 하게 줄이지는 못했다는 인상을 받았다. 음 이정도면 리팩토링을 위해 쓴 리소스 보단.. 너무 많이 비효율적인데 ? 라는 기억이 생생하다. 

개인적으로는 이미 자바로 된걸 코틀린으로 바꾼다? 라고 할땐 안하는게 나을거 같다. 새로 만드는 프로젝트라면 적용해보면 좋을거 같다. 정말 많이 간결해진다. 자바 특유에 긴 코드들이 완벽히 사라진다고 말할순 없지만 쓰다보면 확실히 코드라인이 줄어 든다는것을 느낄수 있다. 

예를 들면 이런 부분이 있다. 

(java)
if ( paymentCompany == null ) return "없음"

(kotlin)
paymentCompany?: return "없음"

같은 동작을 한다. 그러나 보기에도 짧아진게 보인다. 이정도의 케이스만 보고 간결해 진다고 할수 없다. 

 아래 간단한 샘플 예제를 보면 리스트에서 다른 리스트로 데이터를 간단하게 집어 넣는 로직인데 굉장히 간결하게 표현이 가능하다. map 란건 forEach 와 동일 동작을 해주는데 내부적으로 it 이란 키워드를 통해 list.get() 으로 순차적으로 가져오는 값과 동일한 역할을 한다. 좀더 명시 적으로 데이터를 컨트롤이 가능해지게 되고 코드라인도 적어지게 된다. 잘보면 깨알같게 System.out.println 도 줄여서 사용할수 있다. 

(java)
ArrayList list 
ArrayList list2 
for ( int i : i < list.size() ; i++) {
	System.out.println( list.get(i) )
    list2.add( list.get(i))
}

(kotlin)
val list2 = list.map{ 
	println( it )     
	it
}.toList()

 

세번째 , NullPointException 

 

코틀린의 장점을 검색하면 무조건 나오는 내용이다. 말로는 알겠지만 과연 어떻게 Null 컨트롤을 쉽게 해준다는건지 와닿지는 않는데 이것을 써보면 바로 알수 있다. 

class Cancle (
    val cancleKcpType : String ? = null ,
    val tno : String?=null ,
    val custIp :String?=null ,
    val cancleMsg : String? = null,
    val orderCode : String? = null
)

Cancle(
       cancleKcpType = cancellation,
       tno= tid,
       custIp =  "",
       cancleMsg = cancleMsg,
       orderCode = orderCode
)

 위에 코드는 두가지를 확인 할수 있다. 일단 저런형태의 데이터 클래스를 만들었을때 선언시 이미 null 을 허가할지 말지에 대해서 선언을 해줄수 있다. 그렇기 때문에 반대로 내가 널을 용납하지 않겠다고 변수를 만일  tno : String 으로 선언할경우 IDE 에서 컴파일하기전에 이미 체크하여 null 이 허용되지 않는 변수임을 하이라이트 처리하여 알려준다. 컴파일해서 실행 해봐야 알수 있는 부분인데 그전에 알수 있다는것은 아주 강력한 부분중 하나다. 

그리고 또한가지 알수 있는 특징은 객체를 생성할때 각 변수명을 마치 키값처럼 사용하여 값을 지정하여 대입시켜줄수 있다. 일반적이라면 순서대로 하거나 getter , setter 에 의존하여 값을 대입을 하거나 가져와야 하는데 사용해보면 명확하면서도 깔끔하게 객체를 생성 해줄수 있다. 

이외에도 문접을 찾아보면 map 을 사용시 굳이 get() 메서드를 사용하지않고도 map["키값"] 으로 사용할수 있는등 기존의 자바문법에서 올드했던 영역들이 많이 바뀌거나 개선되어져 있다. 

 

네번째 , 스프링과의 친화성 

 

현재 코틀린 + 스프링 구조로 약 4~5개월 가량 개발을 진행 하고 있고 현재까지 100%라고 할수 있을정도로 자바를 사용했을때와 동일한 환경을 제공 받고 있고 불편함 마져 없었다. 오히려 좀더 편해졌다고 느껴질만한것들이 많았고 실제 스프링도 2 버전부터는 코틀린을 아주 잘 지원해주고 있기 때문에 아주 만족 스럽게 사용중이다. 

 

스프링을 쓰면서 가장 만족 스러웠던것들은 자바로는 깔끔하게 만들수 없는것들을 어떤부분들은 스프링에서 제공하는 기능들을 응용해서 짜는 바람에 버전업시 해당기능이 변경되거나 사라지면 난감했는데  코틀린 언어 레벨에서 충분히 해결 가능한부분들이 생겨서 많지는 않지만 그런 케이스들을 해결할때 아주 만족감을 느꼈다. 

 

간단하게 사용기 를 마무리 한다. 이후에는 코틀린 과 스프링부트 사용에 관한 내용과 코틀린을 사용하기 위해 내가 봤던 체크 사항들을 같이 올릴 생각이다. 

 

누군가 코틀린을 사용하겠다면 절대적으로 막지 않을거 같다. 찬성해주고 싶다. 다만 기존 레거시 한 자바 코드를 코틀린으로 바꾼다고 한다면 말리고 싶다. 레거시의 문제는 언어적인 문제라기보단 아마 로직적 정책적 운영적 문제가 더 클것이기 때문에 개발하는 도구가 바뀐다고 절대 드라마틱한 업무효율이 나오지 않을것 이기 때문이다.