🥰 우리 같이 .. '코틀린' 할까요?

⛔️ 코틀린 덕통사고 다발 구역입니다

주의하세요. 코틀린의 매력에 빠지면 한동안 벗어나지 못할겁니다.

그렇다. 사실 필자의 코틀린 덕질용 포스팅이다. 필자는 개인적으로 코틀린을 매우 사랑한다.
코틀린이라서 좋아하는 것이 아닌, 좋아하고 보니 코틀린이었던 것이다.
따라서 코틀린의 매력을 널리 알리고 싶어 이 글을 작성하게 되었다!

👥 왜 저래.. 왤케 호들갑이야..

이상하게 보지말고 한 번만, 딱 한 번만 이 글을 읽어보길 바란다. 특히 '자바' 를 활용한 개발을 하고 있다면..
분명 안드로이드, 스프링 부트 등 분야에서 자바 → 코틀린으로 완전히 전환되는 것은 시간 문제일 것이다!!

💁🏻‍ 우리 코틀린은 이런 아이랍니다

코틀린은 자바, 스칼라처럼 JVM 위에서 돌아가는 새로운 프로그래밍 언어다.
공식 안정판이 2016년 2월 15일 릴리즈 되었으니 정말 신생아가 따로 없다. (적고보니 벌써 5년이 넘긴 했구나)

코틀린은 간결하고 실용적이며, 자바 코드와의 상호운용성을 중시한다. 따라서 자바를 사용하고 있는 거의 모든 곳에 대부분 코틀린을 활용할 수 있고, 접목해볼 수 있다. 안드로이드, 스프링 부트 등 분야에서 말이다.

기존 자바 라이브러리나 프레임워크와도 단 1%의 호환성 문제 없이 함께 잘 동작하며, 성능도 비슷하다.

그럼, 코틀린의 핵심 주요 특성 몇 가지를 톺아보자.

1. 타이이입은.. 정적으로 지정하겠습니다. 그런데 이제 타입 추론을 곁들인.

정적 타입 지정 언어는 말 그대로 코드를 작성할 때 변수, 함수 반환 타입 등에 프로그래머가 직접 타입을 지정해주는 언어이다. 자바도 이에 해당한다.

자바와 마찬가지로 코틀린도 정적 타입 지정 언어이다. 각 변수의 타입을 컴파일 시점에 알 수 있고, 프로그램 안에서 객체의 프로퍼티나 메소드를 사용할 때마다 컴파일러가 타입을 검증해주기 때문에, 정확성이 더욱 올라간다.

🐶 : 그럼 그 반대인 '동적 타입 지정 언어'는 뭐가 좋은데요?
💁🏻‍♂️ : 타입을 상관하지 않고 모든 값을 변수에 넣을 수 있어 타입 명시가 필요없고, 그에 따라 코드가 더 짧아지겠죠!
또한, 데이터 구조를 더 유연하게 생성하고 사용할 수 있다는 장점이 있죠!

하지만, 동적 타입 지정 언어는 이름이 오타가 나거나 메소드를 잘못 접근했을 때, 컴파일 시 걸러내지 못하고
실행 시점이 되어서야 오류를 뿜으며 프로그램이 꺼질 수 있다는 단점이 있다.

필자는 정적 타입 언어의 장점이 매우 강력하여 이를 선호하는 편이다. 자바도 이런 부분에선 좋다. 하지만 자바에서 항상 귀찮게 타입을 지정해줘야 한다는 점이 그만큼 큰 불편함, 그리고 단점으로 다가오곤 했다.

반면 코틀린은, 타입을 직접 명시할 필요가 없다.

코틀린 컴파일러는 문맥상 변수 타입을 자동으로 유추할 수 있기 때문에, 프로그래머는 타입 선언을 생략할 수 있다.
또한, 어떤 경우엔 함수의 반환형도 생략할 수 있다!

잠시 아래 코드를 보자! 코틀린에서 sum() 함수를 정의하고 선언했다.

val a: Int = 3
val b: Int = 5

fun sum(a: Int, b: Int): Int {
    return a + b
}  

print(sum(a, b))  // 8

자바와 별 다를 거 없이, 타입을 지정해주는 부분이 많다.
그러나 코틀린은 다음과 같이 불필요한 코드를 줄일 수 있다!

val a = 3
val b = 5

fun sum(a: Int, b: Int): Int {
    return a + b
}  

print(sum(a, b))  // 8

함수에 표현식 (Expression) 대입을 하면, 이런 것도 가능하다.

val a = 3
val b = 5

fun sum(a: Int, b: Int) = a + b

print(sum(a, b))  // 8

그러니까, 타입은 정적으로 엄격히 지정하는 건 맞으나 프로그래머의 편의성과 간결한 코드를 위해 컴파일러 차원에서 이를 알아서 처리해준다는 것이다!

이를 통해 코틀린의 철학 중 하나인 '간결성'에서 한 발짝 더 앞서가는 것이다.

코틀린을 사용하면, 자바처럼 타입 명시를 해줄 필요 없이 컴파일러에게 믿고 맡길 수 있다.
이것 하나만으로 쓸 데 없는 코드를 확 줄일 수 있다!

2. 함수형 프로그래밍 + 객체지향 프로그래밍 언어

코틀린은 자바처럼 객체지향 프로그래밍 패러다임을 따르기도 하지만, 새롭게는 함수형 프로그래밍 패러다임도 동시에 챙긴 언어이다. 객체지향 프로그래밍 이야기는 두 말 할 것도 없는데, 몇몇 사람들에겐 함수형 프로그래밍이 생소하게 다가올 수 있다.

함수형 프로그래밍의 핵심 개념 3가지

• 함수는 일급 시민 : 함수를 일반 값처럼 변수에 저장할 수 있고, 다른 함수의 인자로도 넘길 수 있음
• 불변성 : 생성 이후 절대로 내부 상태가 바뀌지 않는 불변 객체를 사용하여 프로그램 작성
• 사이드 이펙트 없음 : 입력이 같으면 항상 같은 출력을 보장하며, 함수 외부 다른 객체를 건드리지 않음 (순수함수)

특히 '함수는 일급 시민'이 뭔 소린지 이해가 안 될 수 있다. 아래 코드를 보자!

fun findAlice() = findPerson { it.name == "Alice" }  // 이름 프로퍼티가 Alice 인 객체 탐색
fun findBob() = findPerson { it.name == "Bob" } // 이름 프로퍼티가 Bob 인 객체 탐색

위 예제는 특정 사람을 찾을 수 있는 동작을 수행하는 함수 findPerson 에 이름이 없는 함수 (코드 블럭) 을 인자로 넘겼으며, 그 결과값을 리턴으로 갖는다.

findPerson 은 사람을 찾는 일반 로직이 담겨있는 것이고, { } 로 감싸진 부분은 이름이 없는 코드블럭, 그러니까 엄연한 '함수'이다.

이 구문을 바로 '람다 식 (Lambda Expression)' 이라고 부른다. 정말 코드가 간결하고 우아해진다.
이렇듯 함수를 값처럼 활용할 수 있다면, 더욱 강력한 추상화를 할 수 있고, 많은 코드의 중복을 제거할 수 있다.

👮🏻‍♀️ : 엥 ㅋㅋ 자바도 람다 되는데요? 코틀린만 되는 척 억빠 오지네요 ㅋㅋ루삥뽕

동의 못 한다. 자바의 람다는 아무래도 의미가 없다. 형태를 비교하기 위해 잠시 안드로이드 코드를 보자.
아래는, 안드로이드에서 버튼에 클릭 이벤트를 달아주는 순수 자바로 작성된 코드이다. 벌써 더럽다

button.setOnClickListener(new View.OnClickListener() {
    @Override public void onClick(View view) {
        // 버튼이 클릭되었을 때 수행할 동작 정의
    }
});

그리고 이를 그나마 자바8 에서 지원하는 람다 식으로 변환하면...
음. 꽤나 간결하게 줄어든 모양이다. 그러나 아직 별로 맘에 안 든다.

button.setOnClickListener(view -> { 
    // 버튼이 클릭되었을 때 수행할 동작 정의 
});

아래 코틀린 코드를 보자.

button.setOnClickListener { 
    // 버튼이 클릭되었을 때 수행할 동작 정의 
}

몇 글자 차이로 훨씬 깔끔해보인다. 억빠 아니고 팩트다. 자바 코드의 저 view 라는 놈은 쓰지도 않는다.

코틀린은 함수형 프로그래밍 언어로 태어난 만큼 자바와 달리 함수형 프로그래밍의 장점을 더욱 굴리기 위해 언어 차원에서 아래와 같은 지원을 해준다!

• 어떤 함수가 다른 함수를 파라미터로 받거나, 함수가 새로운 함수를 반환할 수 있음
• 람다 식을 지원함으로써 일부 코드 블럭을 함수의 인자로, 혹은 변수 등으로 대입할 수 있음
• 객체와 컬렉션을 함수형 스타일로 다룰 수 있는 다양한 고차함수 API 제공

실제로 컬렉션 고차함수는 상당히 많이 쓰이게 된다. 이를테면 이런 예를 들어볼 수 있다.

val a = listOf(-1, -2, 1, 2)
val b = a.filter { it > 0 }  // x > 0 이라는 익명 함수를 인자로 넘김

이렇게 하면 b 에는 [1, 2] 가 담긴 리스트가 들어가게 된다. 이 외에도 폭 넓고 다양한 컬렉션 고차함수를 지원하며, 실제로 사용할 일이 많아 편리하다.

그리고 함수형 프로그래밍에 대해 잘 모른다고 걱정하지 않아도 된다. 코틀린이 함수형 프로그래밍 패러다임을 강요하는 건 아니고, 본인이 편한대로 사정에 맞게 상황에 맞게 명령형 코드를 작성하는 등 적절히 원하는 스타일로 코드를 작성하면 된다. 적합한 패러다임을 선택하는 것은 개발자의 몫이다.

어차피 함수형 프로그래밍을 천천히 익히다보면 그 세계에서 빠져나오지 못한다 ㅎ

3. 오빠 차 뽑았다 Null 없애러 가

코틀린의 가장 핵심이다! 바로 Null-safety 를 언어 차원에서 지원한다는 것이다.
자바로 무언가 개발을 하다보면, 아래 오류가 우릴 심심하지 않게 반겨주곤 했다. (으 보기만 해도 환멸난다)

오빠, 제발 좀 그만 질척대.

자바를 사용하는 개발자들은 NullPointerException 에게 계속하여 당하고 있다..

실행해놓고 보니 갑자기 NullPointerException 이 로그에 찍히여 프로그램이 강제 종료되던 악몽이 떠오른다.
NPE 는 보통 개발자의 실수로 인해 의도치 않게 변수에 null 을 담게 되어 발생하는 경우가 많은데, 개발자도 사람인지라 실수를 줄이는 것은 또 다른 차원의 고민이고 어쩌면 해결 불가능한 영역이라고 할 수 있겠다.

따라서 코틀린은 이 NPE 를 획기적으로 줄이기 위해, 컴파일 시점에 null 위험성 검사를 하여 오류를 훨씬 많이 방지해준다.

코틀린 타입 시스템은 null 이 될 수 없는 값을 추적하며, 실행 시점에 NPE 발생 가능성이 있는 연산 및 코드를 사전에 아예 금지시킨다. 애시당초 빌드도 못 하게 하는 것이다.

그러니까 즉, 일반적으로 변수에 null 을 담을 수 없게 되어있다.

그렇다고 아예 null 자체가 없는 건 아니고, 아래와 같이 null 이 담길 수 있는 타입과 아닌 타입을 구분한다. 이 때, null 이 담길 수 있는 타입을 Nullable 타입이라고 하며, 자료형에 ? 를 붙여 명시한다.

val data1: String? = null
val data2: String = ""

그리고 이 Nullable 타입이 아니면, 무조건 null 이 담길 수 없음을 보장하게 되는 것이다. 따라서 Non-Nullable 타입에 null 이 담기는 동작 등을 사전에 IDE 차원에서 금지시켜준다.

이 말을 몸소 실감나게 하기 위해 잠시 아래 코드를 보자.

var a = 5
var data: Int? = null

a = data ?: 100

println(a)

이 코드의 출력결과는 무엇일까? 바로 100 이다. 중간에 생소한 ?: 연산자가 이 결과를 이끌은 것이다.
대충 보면 a 변수가 5로 초기화 되어있고 data 가 Nullable Int 로 선언되어있고, null 로 초기화 되어있다.
3번째 코드 라인에서 ?: 동작은 이러한 동작을 한다.

// data 가 null 이 아니면 data 의 값을 a 에 대입하고,
// data 가 null 이라면 오른쪽에 있는 100 을 a 에 대입한다.
a = data ?: 100

// 따라서 a 에는 100 이라는 값이 담기게 되어 100 이 출력된다.

이를 엘비스 연산자 (Elvis Operator) 라고 한다. a 변수에는 분명하게 null 이 담길 수 없으므로
이러한 연산자를 지원함으로써 Nullable 타입과 Non-Nullable 타입의 명확한 구분을 도와준다.

(TMI : 엘비스 연산자 의 엘비스는 우리가 아는 엘비스 프레슬리가 맞다. 연산자 모양을 오른쪽으로 90도 꺾어보면
엘비스 프레슬리의 트레이드마크 헤어스타일과 닮았다고 해서 엘비스 연산자라고 부른다고 한다.. 오피셜이다.)

코틀린의 Null-safety 를 위한 지원은 이 뿐만이 아니며, 이 밖에도 많은 연산자 및 API 를 제공해준다.
따라서 NPE 발생 확률이 훨씬 줄어들고, 개발자가 실수를 범할 확률을 프로그램 실행 이전에 줄여버리는 것이다.

실제로 자바로 작성되어있던 안드로이드 앱을 코틀린으로 마이그레이션 한 이후로, ANR (앱 비정상 종료) 횟수가 눈에 띄게 줄어들었다는 통계 자료도 있을만큼, 획기적인 성과를 이루어 낸 것이다.

😎 요약 : 완전 쩔탱 간지 철철 언어임

농담이고, 지금까지 내용을 요약하자면 다음과 같다!

• 코틀린은 타입 추론을 지원하는 정적 타입 지정 언어이다. 기존 자바의 경우는 타입을 일일히 명시해줘야 하는 번거로움이 있었고 이것은 정적 타입 지정 언어의 단점 중 하나이기도 했었다. 하지만 코틀린은 타입 추론을 지원하기 때문에, 정확성과 성능을 보장하면서도 소스코드를 간결하게 작성하고 유지할 수 있다!

• 객체지향, 함수형 프로그래밍 스타일 모두 지원한다. 일급 시민 함수를 사용하여 수준 높은 추상화가 가능하며, 불변 값 지원을 통해 위험한 자원 공유를 막을 수 있어 다중 스레드 애플리케이션 개발을 더욱 편리하고 쉽게 할 수 있다!

• 실용성, 간결성, 안전성, 상호운용성이 좋다. 일반적 작업에 대해 이미 잘 알려진 실용적인 해법을 채택하고, NPE 등의 오류를 방지하며 사람이 읽기 쉽고 간결한 코드를 지원하며 자바와 아무런 호환 문제 없이 통합될 수 있는 언어이다!

어떤가, 이 정도면 우리 모두 '코틀린'을 할 필요가 있다.

당연히 이 글에서 열거한 것보다 훨씬 무수히 많은 장점들이 존재한다.
글이 많이 길어질까봐 대표적인 특징을 나열했을 뿐이다. (하루종일도 할 수 있다)

괜히 필드에 있는 스프링 부트 개발자들이 코틀린을 공부하고 있는 것이 아니다.
괜히 구글에서 안드로이드 공식 개발 언어로 코틀린을 지목한 것이 아니다.
모든 일엔 합리적 이유가 따르는 법이다.

이미 수차례 검증이 된 언어고, 앞으로의 로드맵도 창창하다.

필자는 안드로이드 개발자이지만 코틀린을 어떤 한 프레임워크에만 국한해서 좋다고 왈가왈부하는 것이 아닌, 언어 차원에서의 장점, 개발자로서의 편리함을 매우 많이 느꼈기 때문에 이러한 글을 작성한 것이다.
(다 쓰고 나니 무슨 거의 신천지 신도 급으로 적어놨는데, 아무튼 코틀린은 최고다 ㅠㅠ)

자바를 사용하는 여러분이라면, 한 번쯤은 고려해보세요!

코틀린은 당신에게 완전히 새로운 개발 경험을 선보일 것입니다.

"코틀린을 당신의 코드에 들이십시오."