Danny Preussler이 기고한 글의 번역입니다. (원문) Android Weekly에서 읽고 공감되는 바가 많아 번역해보았습니다. 이해를 돕고자 의역을 한 부분이 있으니 문제 있는 부분을 발견하여 알려주시면 수정하도록 하겠습니다. 감사합니다.
요즘 안드로이드 세계에서 Kotlin은 어디에나 있는 것처럼 보입니다. 이제는 Kotlin 언급 없이 안드로이드에 관한 컨퍼런스나 블로그를 읽는 것이 어려워질 정도이죠. 작년 Droidcon Berlin에서 대부분 사람들이 이미 프로젝트에 코틀린을 사용하기 시작했다는 이야기가 기억이 납니다. (저는 2개월 후 Kotlin을 포함한 첫 번째 앱 업데이트를 게시했습니다.) 실제로 Kotlin은 Java 커뮤니티보다 Android 커뮤니티에 훨씬 더 큰 영향을 미쳤습니다. JetBrains 조차도 놀랐다고 확신하고요.
안드로이드가 출시된 이후 우리 개발자들은 다른 언어와 플랫폼들이 진화하고 있을 동안, 시대에 뒤진 언어에 갇혀있었죠. 그런 우리에게 Kotlin은 경쟁력이 생기도록 도와주었습니다.
The stop sign (정지 신호)
하지만 이러한 개발자들의 열정이 이해 당사자들에 의해 막히는 경우가 생깁니다. Kotlin은 개발자의 코드 베이스와 개발 속도에 다양한 혜택을 가져다 주지만 대부분 Kotlin을 사용할 수 있는 기회가 없습니다. 몇 개의 사실로 그들의 주장을 꺾을 수 있습니다.
몇 가지를 살펴보죠 :
Everyone in the team needs to learn a new language
(팀의 모든 사람들이 새로운 언어를 배워야 한다)
명백하게 타당한 논쟁이죠. 그렇지만 Kotlin의 러닝 커브는 정말로 낮다는 점입니다. 예를 들어, RxJava의 러닝 커브는 Kotlin의 러닝 커브보다 훨씬 가파릅니다. 처음에는 Kotlin 키워드로 Java 스타일로 작성해보고, 작성한 코드가 잘 작동하는지 의심스럽다면 IDE에 복사-붙여 넣기를 통해 직접 빌드를 해보세요. 물론 모든 사람들이 자연스럽게 녹아들 수 있는 방법을 찾아야 합니다. 이것은 시간을 의미하고 이 시간은 이해 당사자들에게 돈을 의미합니다. 위험 없이 시작하는 가장 좋은 방법은 테스트해보는 것입니다. 테스트는 새로운 도구를 사용해 볼 수 있는 안전한 환경입니다. 기존의 테스트를 마이그레이션 하거나 적어도 Kotlin 으로 새로운 테스트를 작성해보세요. 사실, Kotlin은 테스트 코드를 향상하는 훌륭한 기능을 제공합니다. 시간이 지남에 따라 모두가 Kotlin이 어떻게 작동하는지 이해하면 다음 단계로 나아갈 수 있습니다. 어쨌든 팀이 새로운 언어를 배우는 것은 좋은 일입니다.
Hard to find developers with Kotlin experience
(Kotlin 경험이 있는 개발자를 찾기가 어렵습니다)
사실, 대부분의 개발자는 새로운 것을 찾기를 열망하지만 그렇지 않은 개발자는 채용할 때에 고려해야 합니다. 따라서 취업 지원자들이 Kotlin을 사용할 수 있다면 채용될 기회가 많아 질 것입니다. Swift의 경우를 보면, Swifit는 겨우 3살이지만 이제는 Objective C를 사용하는 사람을 찾기가 더 어렵습니다. 문제는 현실입니다. 우리가 살고 있는 세상을 기억하세요 : 이 세상은 기존에 있는 프로젝트에서 최고의 사람을 얻으려면 채용 담당자가 필요합니다. 우리는 지원하는 개발자보다 많은 포지션을 가지고 있습니다. 새로운 기술을 가지고 있는 도전적인 지원자는 여러분의 프로젝트를 주도하여 다룰 수 있는 사람을 찾는 좋은 방법이 될 것입니다.
Kotlin is not backed by Google
(Kotlin은 Google에서 지원하지 않습니다)
사실 Android는 byte code를 사용합니다. 그리고 Kotlin과 Java 둘 다 byte code 기반이죠. 우리는 코드로 쓸 수 있는 언어에 대해서만 이야기하고 있는데요. Google은 Jack toolchain을 포기하고, Java8 javac compiler를 지원하기로 하였습니다. 그래서 우리는 밝은 미래를 기대할 수 있죠. 여기서 여러분이 필요한 진정한 질문은 Jetbrains이 Android를 위해 Kotlin을 지원해줄 것인가입니다. 다행히도 Jetbrains은 헌신적으로 지원하고 있습니다. 이것은 많은 노력을 통한 성공적인 스토리입니다. 지난번에 Android Studio Canary(!) 버전에서 Kotlin plugin이 문제가 발생했는데 다음 날 바로 고쳤었죠.
수정: 실제로 Google은 이미 Kotlin을 사용 중입니다! Android용 databinding compiler를 확인해보세요. 이것을 지적해준 Ľuboš Mudrák에게 감사드립니다.
It’s too risky to put Kotlin in a production app.
(프로덕션 앱에 Kotlin을 적용하는 것은 너무 위험합니다)
Kotlin으로 만들어진 앱은 위험할 것이 없습니다. 앞에서 언급했듯이, 언어는 바이트 코드로 변환되고 끝이 나죠. 아마도 여러분이 하고 있는 모든 라이브러리 업데이트가 Kotlin을 추가하는 것보다 훨씬 위험할 수 있습니다. Null Safety와 같은 많은 기능들은 코드를 더 안전하게 만들어줍니다. 또한, Kotlin은 더 이상 새로운 언어가 아닙니다. 첫 번째 릴리즈가 된 이후로 시간이 많이 지날수록 안정되었습니다. 매우 많은 사용자를 가진 큰 회사들은 부분적 또는 완전히 Kotlin으로 전환했습니다. 그들이 “위험”을 감수했으므로 여러분도 그렇게 할 수 있을 겁니다.
Its just another JVM language
(이것은 또 다른 JVM 언어입니다)
모든 JVM 언어로 안드로이드 앱을 만들 수 있었지만 아무도 하지 않았던 것을 왜 우리가 지금 해야 할까요? 저는 Scala로 안드로이드 앱을 만들려고 노력했던 사람들이 고통받던 기억이 납니다. 왜냐하면 Scala는 런타임 라이브러리를 다뤄야 하기 때문이죠. 반면에 Kotlin은 안드로이드를 염두에 두고 설계되어있기 때문에 매우 작은 런타임 라이브러리를 가지고 있습니다. 여러분이 사용하는 대부분의 라이브러리는 이것보다 훨씬 더 큽니다. 이것이 다른 부분이죠!
We don’t have time to rewrite our app
(우리는 앱을 다시 작성할 시간이 없어요)
그럴 필요 없어요! Kotlin과 Java는 완벽하게 함께 동작합니다. Kotlin에서 Java를 쓸 수 있고 그 반대의 경우도 마찬가지입니다. 예를 들어, Objective C와 Swift의 관계가 상호운용이 필요치 않은 것처럼 말이죠. 그래서 클래스를 하나하나 만들 때마다 더 좋은 언어로 선택해서 만들 수 있습니다.
A new language slows us down
(새로운 언어는 우리를 느리게 만듭니다)
Uncle Bob wrote about this (Uncle Bob이 얼마 전에 쓴 글입니다) : 모든 새로운 언어들을 맨 처음에 쓸 땐 우리가 쓰는 툴들의 준비가 되지 않아 막힐 때가 있습니다. Swift를 보면, 지금까지도 XCode에서 Objective C를 지원해주는 것보다 좋지 않습니다. Kotlin의 큰 장점은 툴 제조업체에서 나왔다는 것입니다. Intellij를 만든 사람들로부터 Android Studio가 만들어졌습니다. Android Studio의 지원은 Intellij에서 자바를 지원하는 것만큼 우수합니다. 좋은 소식 중 하나는 Gradleware가 Gradle 스크립트 용 Kotlin을 지원하기 시작했다는 것이죠. 왜냐하면 이 툴을 지원한다는 뜻이니깐요! 현재 Groovy와 같은 언어는 나온지 수년이 지났지만, Kotlin이 지원하는 것만큼 훌륭한 지원을 받지 못하였습니다.
(바이트 코드와 동작하는) 모든 여러분의 코드 분석 툴은 바깥에서 돌아갈 겁니다. 이제 남은 것은 아마 소스코드에서 직접 동작하는 정적 확인 툴 일 것입니다. 이것은 조금 늦어지긴 하겠지만 금방 커뮤니티에서 해결 방법이 나올 것입니다. 게다가 우리는 고품질의 코드를 제공할 수 있는 대안으로 Klint를 가지고 있죠.
So why do our stakeholders hesitate?
(그렇다면 왜 이해 당사자들은 망설일까요?)
모바일은 대부분의 기업에서 핵심 비즈니스가 되었습니다. 어디에 있더라도 대부분 여러분의 고객들은 앱을 통해 만날 수 있는 기회가 많아졌습니다. 하지만 여러분의 핵심 사업에서 여러분은 변화에 주의를 기울이는 경향이 있는데, 전적으로 타당한 의견입니다.
Change, the essence of mobile
(변화, 모바일의 본질)
기억하세요 : 모바일 개발은 지속적으로 변화하고 있습니다. 백엔드 개발 세계가 달리, 빠르게 변화하고 있습니다. 몇 년 전까지 안드로이드는 완전히 다른 유저 인터페이스가 적어도 3개(Pre Holo, Holo and Material Design)는 존재했습니다. 또, 푸시 노티피케이션을 보내는 것도 3개(XXX, GCM and Firebase)가 다른 API도 존재했었죠. 불과 몇 년 전 가장 널리 전파된 앱 아키텍처에는 HTTP 호출을 숨길 수 있는 Content Provider에 포함되어 있었죠. REST 클라이언트 (아마도 Apache 기반)는 항상 SQLite 데이터베이스에 결과를 저장해야 합니다. 몇 년 전에 성능 상의 이유로 의존성 주입은 안티 패턴이었고요. ReactiveX와 함수형 프로그래밍은 아마도 백엔드에서 머물렀겠죠.
우리 모바일 개발자가 한 가지 배운 것이 있다면 변화는 끊임없이 계속된다는 것입니다. 여러분이 코드를 작성한 순간 그것은 이미 오래된 것 일 수 있습니다. 3년간 아무도 건드리지 않은 앱은 버려질 수 있습니다. 이는 Android 뿐만 아니라 미래에도 가능한 얘기입니다. Android 2(이클레어, 프로요, 진저브레드) 나 ContentProvider 패턴을 아직도 사용해서 만드는 개발자를 열심히 채용하도록 노력해보세요! 행운을 빌어 드리죠.
Don’t get left behind
(뒤처지지 마세요)
Kotlin은 이러한 변화 중 하나입니다. 변화를 놓치지 마세요. 여러분이 현재 보호하고 있는 Java는 우리가 지금 레거시 시스템이라고 부르는 것들로 끝날지 모릅니다.
