코틀린을 도입하려는 기업들

어느 한 기업의 채용 공고의 일부
- Java, Kotlin, Spring Boot와 JPA(Hibernate)를 이용한 Restful API 설계/개발

최근 공고에 기술스택을 보면 기존에 java가 독식하던 언어목록 에서 최근 kotlin이 많이 추가되는 추세입니다.

kotlin 개발자의 수요는 대부분 안드로이드 개발에 치우쳐져 있었다. 하지만 최근 들어서 카카오, 당근마켓, 토스, 라인, 버킷플레이스(오늘의집) 같은 곳들에서 백엔드 기술스택에 kotlin을 추가해오고 있으며, 새로운 코드들을 코틀린으로 작성하거나, 자바를 코틀린으로 대체, 코틀린 개발자를 채용을 하는 모습을 볼수 있습니다.

이런 흐름속에서 어떤 점들이 기업들이 오랜 친구였던 자바에서 코틀린으로 넘어가려하는지 그 이유를 살펴보고자 합니다.

카카오 현직자의 후기

대학생활 중 카카오에 다니는 선배님을 만난 적이 있었는데, 그때 카카오의 기술 스택에 대해 물어봤습니다. 당시에는 코틀린을 사용한다고 말씀해주셨고, 자바에서 코틀린으로 넘어가면 다시 돌아오기 어렵다는 이야기를 해주셨습니다.

개발 블로그

여러 분야와 회사들에서 코틀린 개발에 관한 이야기를 볼만한 블로그들 을 모아 봤습니다.
최근에 많은 직무나 분야에서 코틀린의 도입이 많아진것을 볼수 있는 부분입니다.

토스 개발 블로그 DSL

자바보다 쉬운 코틀린 쿼리 짜기 | Kotlin JDSL part.2

토스ㅣSLASH 21 - 테스트 커버리지 100%

백엔드 개발자의 코틀린 입문기 - 코틀린이 얼마나 좋길래? 자바에서 옮겨가도 될까?

배민광고리스팅 개발기 (feat. 코프링과 DSL 그리고 코루틴) | 우아한형제들 기술블로그

자바의 단점

java is verbose

사진 출처, Write in Go (Fall 2014) https://www.youtube.com/watch?v=LJvEIjRBSDA

자바는 특징을 뽑으라면 현제에는 크게 와닫지 않는 플랫폼 독립적이라는 것과, 객체지향을 추구한다는 2가지가 크다고 봅니다.

자바는 모든것을 객체로 두려고 하기때문에 hello world 를 출력하는 코드를 보자면

class Main {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

우선적으로 Main 클래스를 생성하고, 정적 메소드인 main을 만든뒤 그 메인안에 System 객체의 out 안에있는 println 를 호출하여 객체지향적으로 사용하고 있는 것을 볼수 있습니다.

객체지향은 좋은 패러다임이다. 하지만 만능은 아닙니다. 여러 객체가 상호작용하는 것은 분업과 캡슐화의 장점이 있지만. 모든 상황에서 분업과 캡슐화가 필요한 것이 아닙니다. 위에 코드에서도 그저 단순히 출력 하나만을 원했을 뿐인데 장황하게 코드를 작성해야 합니다.

추가적으로 다른 패러다임과 자바가 만났을때 조금 더 귀찮아 지곤 합니다.
함수형 프로그래밍적인 요소인 Stream, Lambda 는 자바 1.8 때 추가된 문법이다. 함수형 프로그래밍과 객체지향은 서로 베타적인 부분은 아닙니다. 하지만 자바에서의 함수는 1급 객체가 아니기 때문에 해당 부분을 구현할때 추가적인 부분이 더 필요하는것도 불편함 점중 하나입니다.

널 안정성

null은 프로그래밍 언어를 배우면서 흔히 보게 되는 문법입니다. 동시에 우리는 NullPointException도 만나게되죠. 자바 프로젝트를 진행하면서 문제가 생기는 것들이나. 흔한 실수들이 이 Null 에서 비롯되곤 합니다.

10억달러 짜리 실수

Null potiner 의 도입은 생각보다 간단한 이유로 시작되었고 많은 문제들을 만들어왔습니다.
이러한 문제점들은 null pointer를 가지고 있는 자바역시 마찬가지 입니다. 그렇기에 자바는 이를 해결하고자 Optional 이라는 클래스를 도입하여 null을 사용하지 않도록 개발 하곤 합니다.

하지만 이러한 Optional 클래스의 추가는 추가적인 클래스를 사용하므로 조금더 성능이 필요하기도 하고, Optional 클래스를 잘못사용하는 경우의 확인은 오직 Runtime 환경에서만 확인이 가능합니다.

코틀린의 개발철학

코틀린은 자바 호환성을 기반으로 생산성을 높이기 위해 제작 되었고 크게 null 안정성과 가독성에 초점이 맞추어져 있습니다.

코틀린의 장점

널 안정성

코틀린은 이러한 null 안정성을 위하여 타입을 두가지로 나누었습니다.

타입 뒤에 ? 가 붙은 타입은 nullable 한 타입이고 붙지 않으면 null 이 들어갈 수 없는 타입이 됩니다.

컴파일 에러

만약 nullable 하지 않은 타입에 null 을 대입하려고 한다면 컴파일 시간에서 에러가 발생하게 됩니다.

컴파일 시간에서 에러가 발생하므로 개발을 하면서 발생할 실수를 미리 발견할 수 있으며.
nullable 하지 않은 변수에 대해서는 NPE의 발생가능성이 존재하지 않게 되어 신경쓰지 않을수 있게 됩니다.

이후에는 코틀린에서 제공하는 여러 문법으로 null 을 처리할 수 있습니다.

Safe call

safe call 은 nullable 한 변수가 있을때 그변수 뒤에 ? 를 붙이고 접근을 시도하는 문법입니다.
만약에 변수가 null 이라면 해당 구은 실행되지 않습니다.

Elvis Operation

엘비스 연산으로 좌항에는 null이 아닐때 실행할 구문, 우항에는 null 일때 실행할 구문을 작성할 수 있습니다.

가독성

코틀린은 앞서 이야기 했던 것처럼 가독성을 좋게 만드는것을 개발할때 염두한 언어로 여러 가독성이 좋은 문법들을 가지고 있습니다. 그중 일부를 소개해 드리고 합니다.

타입 추론

코틀린의 타입은 val, var 로 변수와 상수를 지정하고 val 변수명 : 타입 으로 선언을 합니다.

하지만 초기화 뒤의 있는 타입으로 추론할 수 있는 상황이라면 앞에서 선언할때의 타입을 생략 할수 있습니다. 이 기능은 자바11 이상에서도 사용이 가능합니다.

이러한 타입추론은 얼핏 보면 타입이 없는 것처럼 보여 코틀린은 타입이 없는 자바스크립트나 파이썬 같은 동적 타입 언어로 생각 할수 있는데 이러한 타입추론은 정적타입의 특징을 가지고 있습니다.

한번 타입추론으로 고정된 타입은 컴파일 단계에서 해당 변수에 고정되기때문에 다른 언어들처럼 변경되는 타입은 아닙니다.

싱글톤 Object

싱글톤 클래스를 만드는 대신에 Object를 이용하면 싱글톤이 보장된 객체를 바로 만들수 있습니다.

해당 클래스는 자바로 컴파일 되었을때

다음과 같은 모습으로 컴파일 됩니다. 반복적인 싱글톤 객체 작성 없이 싱글톤 객체를 이용할 수 있습니다.

No lombok, Yes data class

lombok 없이 getter, setter, toString, hashcode 를 만들어주는 data class 를 가지고 있습니다.

named argument

인자에 이름을 지정하고, 기본값을 지정 할 수 있습니다.

collection function

filter, map 같은 함수들을 Stream 클래스의 생성 없이 자연스럽게 사용할 수 있습니다.

이외에도 여러 좋은 문법을 가지고 있어 개발에 도움이 많이 됩니다. 개인적으로는 타입추론과, colllection function 을 이용하여 데이터들을 가공하고, 처리하는것이 유용했었습니다.

비동기처리

코루틴

코루틴은 실행을 일시 중단하고 재개할 수 있도록 하여 비선점형 멀티태스킹을 위한 서브 루틴을 일반화하는 컴퓨터 프로그램 구성 요소 입니다.

코루틴을 이용하면 비동기처리를 편리하게 사용할 수 있습니다.

[Android] 코틀린(Kotlin) 코루틴(Coroutine) 한 번에 끝내기
참고하면 좋은 블로그

코프링

결론

최근에 도입을 하는 회사들이나, 백엔드 코틀린 개발자를 채용하는 양이 늘어나고 있다는 것을 체감하고 있습니다. 또한 개인적으로 코틀린으로 개발을 진행하는 것이 함수형 프로그래밍과 객체지향을 함께 가독성있게 할 수 있다는 점에서 우선 재미있기도 하고, 가독성과, 성능의 면에서 장점이 있다고 봅니다. 많은 실무자 분들과 이야기를 나누어 보지 못했지만. 개발을 하셨던 개발자분들도 다들 코틀린 개발에 만족하는 것을 볼수 있었습니다.

저도 회사경력이 없는 취준생의 입장으로서 공고가 적은 언어를 공부하는 것이 꺼려진다는 점은 알고 있습니다. 하지만 코틀린을 배우는데 걸린 노력도 적고, 개발하는데 시간도 자바를 사용했을때 보다 저 적었던것을 느꼈습니다. 또 다시 자바로 돌아와 개발했을때 코틀린에서 있던 문법들이 그립기도 하더군요. 앞으로 더 많은 코틀린 개발자들이 생겨나 더 큰 커뮤니티가 생겼으면 하는 마음으로 여러분들에게도 코틀린을 추천드리고 싶습니다.