---

저런 이유들도 있지만 결정적인 건 자바와 코틀린의 차이가 커지고 있다는 것이다. 원래 코틀린은 자바에 문법 설탕만 추가해서 자바랑 거의 같지만 더 편하게 쓸 수 있는 걸 목표로 했다. 그런데 그게 어긋나고 있다

1. 레코드. 코틀린이 데이터 클래스를 먼저 추가했고 자바가 나중에 레코드를 추가했다. 그런데 둘의 구조는 아예 다르다. 그래서 코틀린 측에서 @JvmRecord 라는 어노테이션까지 도입했다. 분기가 일어나고 있다는 증거다

2. 코틀린은 언어 차원에서 동시성을 지원하기 위해 코루틴(suspending functions) 루트를 탔다. 그런데 자바는 프로젝트 룸을 진행하면서 그린 스레드를 부활시키려 하고 있다. 이건 코틀린 입장에서 상당한 리스크다. 자바의 동시성 생태계가 그린 스레드 기반으로 정립될 경우 코틀린의 코루틴 기반 동시성 생태계는 무의미해진다

3. 자바가 코틀린보다 앞서는 부분도 나타나기 시작했다. 자바의 instanceof 연산자가 코틀린보다 강력하다. 자바는 getter, setter에서 벗어나고자 하는데 코틀린은 아예 언어 구조 자체에 getter, setter가 강하게 융합되어 있다. 또 하나의 생태계 불일치다

4. 코틀린 프로젝트의 목표가 너무 분산되어 있다. 코틀린 JVM만 제대로 잡아도 큰 업적이라고 생각한다. 그런데 코틀린 JS, 코틀린 네이티브, 코틀린 멀티플랫폼 등 전선을 너무 많이 벌려 놓았다. 이들 플랫폼 간에는 다른 점이 너무 많아서 하나의 코드베이스가 호환되지도 않는다. 여러 플랫폼을 지원하려면 어차피 어노테이션 도배를 해야 한다. 게다가 플랫폼별로 메모리 모델이 다른 것은 큰 골칫거리다. 힘을 이렇게 분산하지 말고 JVM이나 제대로 잡는 게 좋을 것이다

5. 코틀린이 "자바의 엄격한 상위 호환" 노선을 포기한다면 그냥 JVM 플랫폼의 흔한 게스트 언어 중 하나가 되는데, 역사상 JVM 게스트 언어 중에서 자바에 대적하여 이긴 언어가 없다. 스칼라, 그루비, 클로저 등등 시작은 찬란했지만 지금은 그저 그렇다. 어찌 보면 당연하다. 플랫폼을 장악하고 있는 언어는 플랫폼을 자기 마음대로 주무를 수 있는 힘이 있다. 자바에 새로운 기능을 추가하면서 그에 맞게 JVM의 바이트코드 포맷을 바꾸는 것조차 가능한 것이다. 다른 언어들은 이러한 변화를 온전히 활용할 수 없다. 코틀린이 이걸 극복하려면 코틀린 가상 기계(KVM)라도 만들어야 할 텐데 대단히 어려운 일이다

나도 코틀린의 미래에 낙관적이었으나 이런 이유들 때문에 점점 비관적이 되고 있다. 구글이 강하게 푸시해도 이 상황이 나아질 수 있을지 모르겠는데, 오라클과의 소송에서 승리하면서 오히려 손을 뗄 명분까지 얻었다



어캐 생각하냐? 삼성 다니는분이더라