코틀린(Kotlin)을 배워보면서 느낀 모던 랭귀지(modern language)

이런 저런 이유로 요즘 코틀린(Kotlin) 언어를 조금씩 보고 있다. 내용을 보면서 단지 코틀린이라는 하나의 언어를 본다기 보다는 소위 모던 랭귀지라고 부르는 최근의 프로그래밍 랭귀지를 전제적으로 본다는 느낌을 가지고 있는데, 모던 랭귀지 초보자의 입장에서 이에 대한 감상을 적어보고자 한다.

우선, 코틀린을 포함해 스위프트(Swift) 같은 언어는 프로그래밍 언어를 작성하는 개발자의 편의에 많은 초점이 맞추어져 있다는 생각이 든다. 컴파일된 바이너리 자체의 성능 향상을 위한 방편들 대신, 개발자가 편리하게 작성하고 쉽게 이해하는데 중점이 있어 보인다. 코틀린의 경우 Java의 수다스러운(verbose) 미사여구를 들어내고 개발자가 직관적으로 표현할 수 있도록 하는 장치들이 많이 보인다. 스위프트도 마찬가지인데, 과거 스위프트 언어에 대한 소감에서 밝힌 바와 같이 개발자가 편리하게 표현할 수 있도록 마음껏 표현의 범위를 넓혀 놓았다.

이런 것이 최종적으로 생산되는 바이너리 자체에 성능이나 특성에 영향을 주는 요소는 아니라는 점이 독특하게 나가온다. 코틀린의 경우 소스코드 작성에 어떤 장치를 마련해도 최종 산출물은 기존 형태의 자바 바이트 코드(Java Byte Code)인 것이다(kotlin native는 제외하고). 다만 그것을 개발자가 빨르게 그리고 편리하게 작성하게 하고 다른 리뷰어들이 쉽게 파악할 수 있게 함으로써 개발 생산성을 높이는 역할을 할 뿐일 것이다.

다만 폭넓은 언어의 표현력이 랭귀지 학습을 어렵게 만들 수 있을 것 같다. 로직을 어떻게 구성하는지와 더불어 어떻게 표현할 수 있는지를 배워야 하기 때문이다.

그리고, 모던 랭귀지는 로직 구현을 될 수 있으면 개발자의 기술(description)이 아닌 컴파일러/빌더의 기능에 맞기려는 듯한 느낌도 받았다. 이것은 대부분의 모던 랭퀴지에 함수형(functional) 기능이 도입된 원인이기도 해 보인다. 프로그래머가 명령형(imperative)으로 절차를 기술하지 않고 필요한 상태를 정의(declarative)하면, 컴파일러가 알아서 최대한의 리소스를 사용하여 최적의 바이너리 코드를 만드는 형태를 사용하는 것이다. 컴파일러나 빌더의 지능화는 높아지고 개발자의 실수는 생산성에 더욱 치명적이기에 이러한 방향으로 가고 있는 것이 아닌가 싶다.

코틀린의 특징 중 두 가지인 null safety와 functional programming 지원 기능도 이런 의미에서 바라볼 수 있을 것 같다. 과거 C 프로그래밍에서 프로그래머에게 맞기던 메모리 관리 부분을 될 수 있으면 시스템으로 넘기려고 하며 null 체크 마저 구조적으로 시스템이 할 수 있게 만든 것이 null safety 기능으로 보이며, 기본적인 오퍼레이션은 선언으로 수행될 수 있도록 기능을 제공하는 것이 funcional programming 지원 기능으로 볼 수 있기 때문이다.