자바와 코틀린에 대한 생각 정리
미래를 대비하자. 항상 그래왔듯이…
Java vs. Kotlin
최근 코틀린에 대해 많은 관심이 생겨 문법도 보고, 이런저런 책도 보고, 코딩도 해보는 시간을 2주가량 가졌는데, 일단 굉장히 주관적인 생각이지만 결론부터 말하자면 코틀린이 자바에 비해 모든 부분에서 우세하지 않나 싶다.
간결함, 확장성, Null Safety, 코루틴 등…
자바로 할 수 있는 모든 것을 코틀린으로 할 수 있으면서도 자바로 하기 힘든 것들을 오히려 코틀린으로 더욱 쉽게 할 수 있는, 그러니까 코틀린은 자바의 슈퍼셋이다.
한마디로 코틀린에 익숙하다면 굳이 자바를 사용해야 하느냐? 라는 의심마저 들 언어라는 생각이 들었다.
이제 코틀린을 맛만 본 셈이지만 익숙하지 않은걸 한다는게 역시 굉장히 어렵다.
무엇보다 프로그래밍 패러다임의 변화에 따른 사고방식 전환에서 엄청난 어려움을 겪는 것 같다.
예를 들어 최근 카타를 하고있는 코틀린으로 RPG만들기 같은 경우, 플레이어가 물약을 사용하는 메서드가 있는데, 자바였다면 이 메서드가 호출될 때 물약이 없다면 IllegalStateException 같은 예외를 던졌을 것이다.
하지만 함수형 프로그래밍에서는 함수에서 예외가 발생하면 해당 함수가 순수함수가 아니게 되기 때문에, 모나드 연산을 통한 여러 값을 리턴하게 되는 것 같은데, 이 때 물약이 없다면 물약을 먹지 않은 플레이어가 리턴될 것이고, 물약이 있었다면 물약을 먹은 플레이어가 리턴될 것이다.
그렇다면 클라이언트는 해당 플레이어가 물약을 먹었는지 먹지 않았는지를 어떻게 판단해야 하는가?
이러한 고민들로 인해 흐름이 자꾸 끊겨, 사실 코딩이 쭉쭉 이어지지는 않고 있다.
결국 내 함수형 프로그래밍에 대한 이해도가 개세적인 수준이기 때문인 셈이다. 🤣
코틀린도 객체지향적으로 사용하면 별 문제없겠지만, 사실 함수형도 맛깔나게 써볼 수 있는 언어를 공부 해보는데 함수형을 해보지 않는다는것도 말이 안되지 않는가?
아무튼 이 사고전환의 어려움으로 인해 자바와 객체지향에 너무 깊게 심취한 나머지 내 개발 스타일이 갈라파고스화된 느낌이 없지 않아 있다는 자각을 하게 된 계기가 되기도 했다.
자바는 하위호환성을 굉장히 잘 지켜주는 언어이다.
별도로 JVM 튜닝을 빡세게 한게 아니고서야 당장 자바8로 작성된 프로그램을 자바17로 변경하여 돌려도 별 무리없이 돌아갈거라 장담할 수 있을 정도다.
자바 진영의 하위호환성에 대한 집착은 나도 굉장히 좋게 생각하는 부분이지만(A/B테스트 마냥 올려버린 파이썬2와 3의 선례를 생각하면…), 이렇게 하위호환성에 집착한 나머지 자바는 성장 동력을 잃어버렸다는 생각도 든다.
코틀린은 이러한 자바와의 상호호환성을 100% 보장해주며, 자바에 더 이상 도입하기 힘든 피쳐들을 도입할 수 있게 해준다.
그러면서도 코틀린은 자바와의 상호호환성에 굉장히 집착한다고도 느꼈다.
아무리 편리한 기능이라도 자바와의 상호호환성을 보장할 수 없다면 도입하지 않는?
이는 아마 코틀린을 창조해낸 JetBrains의 상황 때문인 것 같은데, 이미 JetBrains가 상업용으로 판매하고 있는 소프트웨어들은 자바를 마개조하다시피 해서 사용하고 있는데, 이것이 한계에 부딪혀 코틀린이라는 이름의, 일종의 모던 자바를 만들어낸 셈이다.
즉, 자바와의 상호호환성이 보장되지 않는다면, JetBrains는 자신들의 비즈니스에도 어느정도 타격을 입을 수 밖에 없을 것 같다.
내가 코틀린에 관심을 가지게 된 계기는, 코틀린에 대해 잘 알지 못하던 시절에도 이미 자바 LTS가 계속해서 릴리즈되며 여러 모던 언어들의 피쳐들을 도입하고 있다는걸 알고는 있었고, 특히 이번 LTS인 자바17에서는 거의 자바8에 준하는 굉장히 큰 변화가 일어났는데, 그중에서도 대부분의 변화들이 코틀린의 피쳐를 차용해와 생긴 부분임을 알았기 때문이다.
자바17을 공부하고 사용하게 되며 자연스럽게 코틀린에도 많은 관심이 가게 됐고, 자바 진영의 이러한 기조와 업계 여러 회사들의 현황, 자바와 코틀린의 상호호환성을 볼 때 근 5년 내, 길어야 10년 내에 코틀린이 국내에서 굉장히 큰 파이를 가져갈 것이라는 확신도 생겼다.
국내의 고연차 개발자분들(대략 20년차 까지도?)은 사실상 자바 하나로 평생을 먹고살았다 봐도 무방할 정도라고 생각된다.
하지만 우리 세대 개발자들은 어떨까?
최근 100년의 변화가 지난 수천년의 변화보다 더욱 눈부신 인류의 역사에 대비해 생각해볼 때 개발 업계도 이와 크게 다르지 않을 것 같다는 생각이 든다.
미친듯이 급변하는 업계에 발맞춰 살아남기 위해서는 보다 근본적인, 보다 더 로우 레벨의 컴퓨터과학 지식에 시간과 노력을 투자해, 그 어떤 변화가 일어나도 그것들을 쉽게 수용해낼 수 있는 기반을 다져야 하며, 그 와중에도 업계가 어떤 방향으로 향하는지 계속해서 추이를 살펴야만 한다.
시스템이 발달하며 데이터는 미친듯이 불어나고 있는데 반해, 하드웨어는 더이상 과거처럼 눈부시게 발전하기 어렵다. 무어의 법칙은 이제 옛말이다.
이 막대한 데이터를 처리해내기 위해서는 우리에게 허락된 하드웨어 성능을 최대한 효율적으로 사용해내야 하며, 현 시점 이에 대한 답은 병렬 프로세싱이다.
그리고 이러한 병렬 프로세싱을 잘 활용하기 위해서는 부수효과가 없는 함수형 프로그래밍이 제격이다.
그러니 현 세대 개발자인 나는 시대의 흐름에 맞춰 함수형 프로그래밍에도 시간을 투자해야만 하고, 특히 자바 개발자인 나에게 코틀린은 이 미션을 수행하기 위한 좋은 수단이 된다.
자연스레 코틀린을 트래킹해야 한다는 생각이 들었다.
하지만 그러면서도 나는 자바를 자바스럽게 사용하는데에만 1년이 넘게 걸렸고, 아직도 잘 못한다고 생각하기 때문에 새로운 언어를 배운다는게 굉장히 막막하게 느껴진다.
자바를 어떻게 써야 자바스럽게 쓸 수 있는지, 자바의 SDK에는 어떤것들이 존재하는지, 자바의 코드가 어떤 instruction set으로 변환되는지, 자바는 어떤 원리로 돌아가는지, JVM은 대략적으로 어떻게 생겨먹었고 어떻게 돌아가는지 등에 관심을 가져왔고, 아직도 이러한 주제들에 대해 제대로 알지 못한다는 생각을 하곤 한다.
이런 상황에 다른 언어에 눈을 돌린다?
당연히 다른 언어를 공부하며 새롭게 깨달아가는 것도 있겠지만, 아무튼 막막한건 막막한거다.
자바에 쏟아부은 시간과 노력, 그 이상을 코틀린에 또 쏟아부어야 하는 것이기 때문에…
비유하자면, 예전에 getting over it 이라는 이름의 게임이 하나 있었는데, 이것과 굉장히 비슷하다.
어떤 아저씨가 항아리에 하반신이 갇힌 채, 오함마 하나로 벽을 타고 올라가는 게임인데, 어디서 추락하건 한번 추락하면 사실상 처음부터 다시 시작해야 한다.
물론 1회차보다 2회차가 더 쉽기는 하겠다만… 그럼에도 불구하고, 종류를 막론하고 처음부터 다시 시작한다는 것은 굉장히 힘든 일임에 틀림없다.
언어하나 새로 배우는게 뭐가 어렵냐? 라고 생각할수도 있다.
결국 이 아젠다에 대한 견해는 사바사일 것 같은데, 어차피 언어의 문법이야 길어야 한두시간정도면 다 배우는 것인데, 나는 고작 이정도 했다고 새로운 언어를 배웠다고 생각하지는 않는다.
내가 생각하는 문제는 그 언어의 철학, 그 이면의 동작원리, 그 언어를 그 언어스럽게 사용하는 것 등인데, 이것들은 결국 굉장히 많은 시간과 노력을 들여야만 체득되는 것이라는 생각을 갖고 있기 때문이다.
C언어만 해도 기능도 별거 없고 문법은 아주 쉽지만, C언어를 잘 활용하기 위한 이런저런 트릭들이 많은걸로 알고 있다.
즉, 새로운 언어 하나를 배운다는 것은 생각보다 많은 시간과 노력이 담보 되어야만 하는, 어렵고 고단한 일이다.
아무튼 징징대는건 이쯤하고, 미래를 보자면 나는 이걸 해야만 하기는 한다.
위에 말한 게임과 관련된 관용어로 get over it이라는 게 있는데, 불평 그만하고 상황을 받아들이라는 뜻을 가졌다. (이 또한 지나가리~~~)
정확하게 내 상황과 일치하는데, 그나마 코틀린은 자바 개발자에게 아주 좋고 훌륭하고 상대적으로 쉬운 언어이기도 하니 다행이다 싶기도 하다.
열심히 하자.
